ScaleOut元数据文件系统已经存储了大量数据。 这些是什么？

TL; DR：在Google，Facebook和Microsoft拍摄了一个具有扩张元数据的新类别分布式文件系统，并提供了一个单一的集中文件系统，管理整个数据中心的数据，缩放到大小的exabytes。这些系统的常见架构特征是缩放元数据，因此我们调用它们扩张元数据文件系统。

分层文件系统通常提供定义的行为（POSIX API），了解客户端如何安全地创建，读取，写入，修改，删除，组织和查找文件。

此类文件系统中的数据存储在文件中作为块或范围。分布式文件系统在许多服务器上传播并复制这些块/范围，以提高性能和高可用性。但是，系统中有关文件，目录，块和文件系统权限的数据历史上存储在一个名为MetaServer或NameNode的单个服务器中。我们调用关于文件系统对象元数据的此数据。在像HDF等文件系统中，NameNode将其元数据存储在内存中，以提高它可以支持每秒支持的元数据操作的延迟和吞吐量。示例元数据操作是：创建目录，移动或重命名文件或目录，更改文件权限或所有权。

随着分布式文件系统管理的数据的大小增加，它很快发现元数据服务器成为瓶颈。例如，HDFS可以按推送，脚本，但不处理超过100K的读取/秒，只有几千条写入/秒。

它长期以来希望重新建立分布式文件系统，以在许多服务器上分离它们的元数据，以使它们能够支持（1）更大的元数据和（2）更多操作/秒。但这是一个非常艰难的问题。

现在，我们讨论了今天公开知名的唯一四个扩展元数据文件：谷歌巨蟹座，Facebook构造，Microsoft ADLSv2和逻辑时钟的啤酒花。

尽管我们在2009年首次听到巨大的建筑和2012年的名称，但谷歌令人惊讶地暗中秘密地秘密地阐述了其可扩展存储和计算架构的最低层。然而，在2021年初发布构造（巧合？）后，谷歌在2021年5月发布了更多关于巨大的细节。

Colossus的Metadata Storage Service是Bigtable，它不支持交叉碎片交易。我们假设这意味着巨大缺乏原子重命名，一个漏洞填充用于表格数据（至少）的扳手，它支持交叉碎片交易。

在巨大的情况下，文件系统客户端连接到策展程序来执行元数据操作，谁又与Bigtable交谈。托管人执行文件系统维护操作，并“D”服务提供块存储服务，其中客户端直接从/到“D”服务器读取/写入块。

巨大的不同客户端可以将他们的数据存储在不同的卷上（元数据碎片）。在卷内可​​能进行原子重命名，但不会横跨卷。

Tectonic首次在Usenix Fast 2021宣布为文件系统，它统一Facebook之前的存储服务（联合HDFS，Haystack等）以提供数据中心缩放文件系统。

类似于巨蟹座，构造在键值存储中存储其元数据，但在这种情况下在Zippydb中。由于ZippydB缺少跨分区事务，不支持跨名称空间文件系统操作。也就是说，您不能从一个卷（元数据碎片）到另一个卷（元数据碎片）原子上的文件。通常，不需要这种操作，因为给定服务的所有数据都可以适合单个命名空间，并且在不同的应用程序之间没有文件系统操作。有单独的无状态服务来管理名称空间，块，文件和文件系统维护操作。

Azure Data Lake Storage（ADL）首次在Sigmod 2017宣布，它支持Hadoop分布式文件系统（HDFS）和Cosmos API。它已被重新设计为Azure数据湖Gen 2（ADLSv2），它使用Hadoop文件系统API，Azure Data Lake Storage API和Azure Blob Storage API为同一数据提供多协议支持。与巨型和构造不同，它可以作为服务使用 - 但仅限于Azure。

有关ADLS架构的最新信息是描述2017年的ADL的原始文件 - 尚未为ADLSv2发布架构。但是，ADL使用RSL-HK存储元数据，它具有使用状态机复制（PaxoS）的碎片碎片键值存储（环），并且在内存引擎中的碎片中的交易（“它实现了一种新颖的组合paxoS和新的交易内存块数据管理设计。“）。

HOPSFS首次在Usenix Fix于2017年宣布，并提供了HDFS API。 HOPSFS是一种重写HDFS，它支持多个无状态NameNode（元数据服务器），其中Leader执行文件系统维护操作，以及可插拔元数据存储层。

HOPSFS提供DAL API来支持不同的元数据存储引擎。目前，HOPSFS的默认引擎是RONDB（NDB集群的叉子，MySQL群集的存储引擎），具有SQL功能的可伸缩键值存储。 Rondb可以扩展到每秒处理数亿个交易读数，每秒10多个事务写入，并且它通过MySQL服务器提供本机键值API和SQL API。 Rondb还提供CDC（Change-Data-Capture）API，以允许我们自动将元数据的变化复制到Elasticsearch，为HoPSFS的元数据提供自由文本搜索API（包括其扩展元数据）。可以使用3个API中的任何一个来查询元数据：Rondb，SQL API的本机键值API，或在Elasticsearch中使用自由文本搜索。

HOPSFS将命名空间层与RONDB和无状态Namenodes缩放，而块层是云对象存储。

在多个服务器上分离元数据服务器的状态时，您需要做出关于如何执行此操作的决定。谷歌使用现有的Bigtable键值商店来存储巨大的元数据。同样，Facebook撰写了构造的Zippydb键值存储。 Microsoft内置了自己的复制状态库 - Hebakaton Ring Service（RSL-HK），以扩展ADLS的元数据。 RSL-HK环形架构将基于PaxoS的元数据与Hebkaton（来自SQL Server的内存引擎）相结合。 HOPSFS使用NDBCLUSTER（现在RONDB）扩展其元数据。

这些底层存储引擎的功能反映在更高级文件系统提供的语义中。例如，构造和（可能）巨大不支持从任何目录到任何其他目录的文件的原子移动。它们的键值存储不支持碎片的协议协议（仅在碎片内）。因此，在文件系统级别，您将介绍一个像文件系统卷（构造调用它们租户）的抽象，然后用户知道它们可以在该卷内执行原子重命名/移动，但不会跨越卷。 Google通过实现两阶段提交事务，在具有扳手的结构化数据的较高层中解决此问题，以确保横跨分片的一致性。相比之下，Microsoft和Rondb的RSL-HK环通过逻辑时钟支持跨碎片事务，使得ADLSv2和HOPSF在文件系统中的任何两个路径之间都能支持原子重命名/移动。

要将其放在数据库术语中，缩放元数据文件系统提供的一致性模型紧紧地耦合到基础元数据存储器提供的功能。如果商店不支持跨分区事务 - 跨多个碎片的一致操作，则不会获得强烈一致的交叉分区文件系统操作。例如，如果元数据存储器是键值存储，则每个碎片通常使用paxoS维护强烈一致的键值数据。但PaxoS不撰写 - 您无法在两个碎片之间运行PaxoS，它们本身使用paxoS保持一致性。相比之下，RONDB支持横跨分片的2阶段提交（2PC），在碎片和碎片中都能在碎片中实现强烈一致的元数据操作。

一旦大规模的元数据存储层到位，可以使用无状态服务来提供访问控制并实现类似于维护数据，磁盘空间平衡和修复块的耐用性和可用性的背景维护任务。

从更强大的POSIX的文件系统到较弱的对象存储范式并再次回到近年来数据库的旅程中的平价。数据库使从强大一致的单主机系统（关系数据库）转换为高可用性（HA），最终一致的分布式系统（NoSQL系统）来处理数据库管理的数据中的大规模增加。但是，NoSQL对于开发人员来说太难了，数据库返回强烈一致（但现在可扩展）的NewsQL系统，数据库，如扳手，蟑螂，SingleSQL和NDB集群。

缩放元数据文件系统介绍此处，显示分布式分层文件系统完成了类似的旅程，从强烈一致的POSIX - 符合文件系统到对象存储（具有较弱的一致性模型），并返回分布式分层文件系统通过重新设计围绕可变的缩放元数据服务来解决文件系统来解决可伸缩性问题。

Ismail Mahmoud，Salman Niazi，Gautier Berthou，MikaelRonström，Seif Haridi，Jim Dowling。 HOPSFS-S3：使用POSIX的语义和更多扩展对象存储。 ACM / IFIP中间件2020。