主要分布式文件系统架构对比分析：GFS vs. Tectonic vs. JuiceFS

本文介绍: 随着技术的进步和数据的不断爆炸，传统的磁盘文件系统已经暴露出它们的局限性。为了满足不断增长的存储需求，分布式文件系统作为动态且可扩展的解决方案应运而生。在本文中，我们探讨了三种代表性分布式文件系统的设计原则、创新和解决的挑战：Google 文件系统 (GFS)、Tec t on ic和Jui ceFS。

随着技术的进步和数据的不断爆炸，传统的磁盘文件系统已经暴露出它们的局限性。为了满足不断增长的存储需求，分布式文件系统作为动态且可扩展的解决方案应运而生。在本文中，我们探讨了三种代表性分布式文件系统的设计原则、创新和解决的挑战：Google 文件系统 (GFS)、Tec t onic和Jui ceFS。

GFS 开创了商品硬件的使用，并影响了大数据领域的 Had oop 分布式文件系统 (HDFS) 等系统。

Tec t onic 引入了分层元数据和存储/计算分离，提高了可扩展性和性能。

Jui ceFS 专为云原生时代而设计，使用对象存储和多功能元数据引擎在云中实现可扩展的文件存储。

通过探索这三个系统的架构，您将获得设计分布式文件系统的宝贵见解。这种认识可以指导企业选择合适的文件系统。我们的目标是激励大数据、分布式系统设计和云原生技术领域的专业人士和研究人员了解优化数据存储、了解行业趋势并探索实际应用。

流行的分布式文件系统 概述

下表显示了各种广泛使用的分布式文件系统，包括开源的和专有的。

广泛使用的分布式文件系统

如表所示，大量的分布式系统在2000年左右出现。在此之前，共享存储、并行文件系统和分布式文件系统已经存在，但它们往往依赖于专门且昂贵的硬件。

表中的“POSIX兼容”列表示分布式文件系统与可移植操作系统接口（POSIX）的兼容性，POSIX是操作系统实现的一组标准，包括文件系统相关的标准。兼容 POSIX 的文件系统必须满足标准中定义的所有功能，而不仅仅是少数功能。

例如，GFS 不是 POSIX 兼容的文件系统。Google 在设计 GFS 时做了一些权衡。它抛弃了很多磁盘文件系统的特性，保留了当时谷歌搜索引擎所需的一些分布式存储需求。

在接下来的章节中，我们将重点介绍 GFS、Tect onic 和 Jui ceFS 的架构设计。让我们探讨每个系统的贡献以及它们如何改变我们处理数据的方式。

GFS架构

2003年，Google发表了GFS论文。它证明了我们可以使用经济高效的商用计算机来构建功能强大、可扩展且可靠的完全基于软件的分布式存储系统，而无需依赖专有或昂贵的硬件资源。

GFS 显着降低了分布式文件系统的进入门槛。它对许多后续系统都有不同程度的影响。HDFS是雅虎开发的开源分布式文件系统，深受GFS论文中提出的设计原则和思想的影响。它已成为大数据领域最流行的存储系统之一。尽管 GFS 于 2003 年发布，但其设计至今仍然具有相关性并被广泛使用。

GFS架构如下图所示：

GFS 集群由以下部分组成：

Ma ster，充当元数据节点。
为了维护文件系统的目录、权限和属性等元数据，需要使用中央节点（主节点）。大师采用树状设计结构。
多个存储数据的块服务器。
chunk server 依赖本地操作系统的文件系统来存储数据。
多个客户

master和chunk server之间的通信是通过网络进行的，从而形成分布式文件系统。块服务器可以随着数据的增长而水平扩展。所有组件在 GFS 中互连。当客户端发起请求时，首先从Ma ster上获取文件元数据信息，并与ChunkServer进行通信，最终获取数据。GFS 将文件存储在固定大小的块中，通常为 64 MB，并具有多个副本以确保数据可靠性。因此，读取同一个文件可能需要与不同的 chunk server 进行通信。副本机制是分布式文件系统的经典设计，当今许多开源分布式系统实现都受到GFS的影响。

虽然 GFS 本身具有开创性，但它在可扩展性方面存在局限性。为了解决这些问题，Google 开发了Colossus作为 GFS 的改进版本。Colossus 为各种 Google 产品提供存储，并作为 Google Cloud 服务的底层存储平台，使其公开可用。Colossus 具有增强的可扩展性和可用性，旨在满足现代应用程序快速增长的数据需求。

构造 结构

Tect onic 是 Meta（以前的 Fa ce book）使用的最大的分布式文件系统。这个项目最初被称为 Warm Storage，于 2014 年开始，但其完整架构直到 2021 年才公开发布。

在开发 Tectonic 之前，Meta 主要使用 HDFS、Haystack 和 f4 进行数据存储：

HDFS用于数据仓库场景（受限于单个集群存储容量，部署了几十个集群）。
Haystack和f4用于非结构化数据存储场景。

Tectonic 旨在在单个集群中支持这三种存储场景。

下图展示了 Tectonic 架构：

构造由三个部分组成：

客户库
元数据存储
大块商店

构造层位设计

构造建筑设计的创新

创新一：分层元数据

Tectonic 将分布式文件系统的元数据抽象为简单的键值（KV）模型。这样可以实现出色的水平扩展和负载平衡，并有效防止数据访问中的热点。Tectonic 引入了元数据的分层方法，使其有别于传统的分布式文件系统。Meta data Store分为三层，对应底层KV存储中的数据结构：

Name层存储与文件名或目录结构相关的元数据，按目录ID进行分片。
文件层存储文件属性，按文件ID进行分片。
块层存储有关数据块在块存储中的位置的元数据，并按块 ID 进行分片。

下图总结了三层的键值映射：

Tectonic 中的图层映射

这种分层设计解决了 Tectonic 的可扩展性和性能需求，特别是在 Meta 需要处理 EB 级数据的场景中。

创新二：元数据存储与计算分离

这三个元数据层是无状态的，可以根据工作负载进行水平扩展。它们通过网络与键值存储（元数据存储中的状态存储）进行通信。

Key-Value Store 并非由 Tectonic 团队单独开发；相反，他们使用 Zip pyDB，Meta 中的分布式 KV 存储系统。Zip pyDB 建立在 Roc ksDB 和 Pax os 共识算法之上。Tectonic 依靠 Zip pyDB 的 KV 存储及其事务来确保文件系统元数据的一致性和原子性。

事务功能在实现大规模分布式文件系统中起着至关重要的作用。水平扩展元数据存储以满足此类系统的需求至关重要。然而，水平扩展引入了数据分片的挑战。保持强一致性是文件系统设计中的关键要求，尤其是在执行重命名具有多个子目录的目录等操作时。确保整个重命名过程的效率和一致性是分布式文件系统设计中一个重大且广泛认可的挑战。

为了应对这一挑战，Tectonic 使用 Zip pyDB 的事务功能。在处理单个分片内的元数据操作时，Tectonic 保证了事务行为和强一致性。

但是，Zip pyDB 不支持跨分片事务。这限制了 Tectonic 在处理跨多个目录的元数据请求（例如在目录之间移动文件）时确保原子性的能力。

创新三：块存储中的纠删码

如前所述，GFS通过多副本保证数据的可靠性和安全性，但这种方式的存储成本较高。例如，仅存储 1 TB 数据通常需要三个副本，从而产生至少 3 TB 的存储空间。对于像 Meta 这样以 EB 级别运行的大型系统，这种成本会显着增加。

为了解决这个问题，Meta 在 Chunk Store 中实现了纠删码（EC），通过减少冗余来实现数据的可靠性和安全性，通常约为原始数据大小的 1.2 至 1.5 倍。与传统的三副本方法相比，这种方法可以节省大量成本。Tectonic 的 EC 设计提供了灵活性，允许按块进行配置。

虽然EC以最小的存储空间有效地保证了数据的可靠性，但它也存在一些缺陷。具体来说，重建丢失或损坏的数据会产生较高的计算和 I/O 资源要求。

根据 Tectonic研究论文，Meta 中最大的 Tectonic 集群由大约 4,000 个存储节点组成，总容量约为 1,590 PB，相当于 100 亿个文件。这个规模对于分布式文件系统来说是相当大的，通常可以满足目前大多数用例的要求。

JuiceFS 架构

JuiceFS诞生于2017年，与GFS和Tectonic的出现相比，外部格局发生了重大变化：

硬件资源有了显着进步。相比之下，当时谷歌数据中心的网络带宽仅为100Mb ps。如今，在 AWS 上，机器网络带宽最高可达 100 Gb ps，提升了千倍。

云计算已成为主流，企业通过公有云、私有云或混合云过渡到“云时代”。这种转变给基础设施架构带来了新的挑战。将针对 IDC 环境设计的传统基础设施迁移到云端常常会带来各种问题。最大限度地发挥云计算的优势成为将基础设施无缝集成到云环境中的关键要求。

此外，GFS 和 Tectonic 是为特定公司运营服务的内部系统，运营规模较大，但关注范围较窄。相比之下，JuiceFS 旨在满足广泛的面向公众的用户并满足不同的用例需求。因此，JuiceFS 的架构与其他两种文件系统有很大不同。

考虑到这些变化和区别，我们来看下图所示的 JuiceFS 架构：

JuiceFS 由三个组件组成：

元数据引擎
数据存储
客户端

虽然 JuiceFS 与上述系统共享相似的整体框架，但它通过各种设计方面脱颖而出。

数据存储

与GFS和Tectonic依赖专有数据存储不同，JuiceFS通过使用对象存储来顺应云原生时代的趋势。如前所述，Meta 的 Tectonic 集群使用 4,000 多台服务器来处理 EB 级数据。这不可避免地会导致管理如此大规模的存储集群的巨大运营成本。

对于普通用户来说，对象存储有几个优点：

开箱即用的可用性
弹性容量
简化操作和维护
支持纠删码，与复制相比，存储成本更低。

然而，对象存储也有局限性，包括：

对象不变性
元数据性能不佳
缺乏强一致性
随机读取性能有限

为了应对这些挑战，JuiceFS在架构设计上采取了以下策略：

独立的元数据引擎
由块、片和块组成的三层数据架构。
多级缓存

元数据引擎

JuiceFS 支持各种开源数据库作为元数据的底层存储。这与 Tectonic 类似，但 JuiceFS 更进一步，不仅支持分布式 KV 存储，还支持 Redi s、关系数据库和其他存储引擎。这种设计有以下优点：

它允许用户为他们的特定用例选择最合适的解决方案，这符合 JuiceFS 成为多功能文件系统的目标。
开源数据库通常在公共云中提供完全托管的服务，从而使用户的运营成本几乎为零。

Tectonic 通过使用事务性 KV 存储 Zip pyDB 实现了强大的元数据一致性。然而，它的事务性仅限于单个分片内的元数据操作。相比之下，JuiceFS 对事务性的要求更加严格，要求跨分片的全局强一致性。因此，所有集成为元数据引擎的受支持数据库都必须支持事务。借助TiKV等可水平扩展的元数据引擎，JuiceFS 现在可以在单个文件系统中存储超过 200 亿个文件，满足海量数据企业的存储需求。此功能使 JuiceFS 成为处理海量数据存储需求的企业的理想选择。

客户

JuiceFS客户端与其他两个系统的客户端主要区别如下：

GFS 客户端采用非标准协议，不支持 POSIX 标准。它只允许仅追加写入。这限制了其在特定场景中的可用性。
Tectonic 客户端也缺乏对 POSIX 的支持，并且只允许仅附加写入，但它采用了丰富的客户端设计，在客户端整合了许多功能，以实现最大的灵活性。
JuiceFS 客户端支持多种标准访问方式，包括 POSIX、HDFS、S3、WebDAV、Kubernetes CSI。
JuiceFS客户端还提供缓存加速功能，这对于云原生架构中的存储分离场景非常有价值。

结论

分布式文件系统已经改变了数据存储，三个著名的系统在这个领域脱颖而出：GFS、Tectonic 和 JuiceFS。

GFS 展示了经济高效的商用计算机在构建可靠的分布式存储系统方面的潜力。它为后续系统铺平了道路，并在塑造该领域发挥了重要作用。
Tectonic 引入了创新的设计原则，例如分层元数据以及存储和计算的分离。这些进步解决了可扩展性和性能挑战，提供了元数据操作的效率、负载平衡和强一致性。
JuiceFS 专为云原生时代而设计，使用对象存储和多功能元数据引擎来提供可扩展的文件存储解决方案。JuiceFS 支持各种开源数据库和标准访问方法，可满足广泛的用例并与云环境无缝集成。