GFS论文解读(一)——设计概述

健鑫.

已于 2024-01-07 13:02:17 修改

阅读量879

点赞数 19

分类专栏： GFS论文解读文章标签：大数据 hadoop hdfs

于 2024-01-07 12:57:55 首次发布

本文链接：https://blog.csdn.net/weixin_62759952/article/details/135438268

版权

GFS论文解读专栏收录该内容

1 篇文章 0 订阅

订阅专栏

介绍

在当今大数据时代，分布式文件系统已经成为处理海量数据的重要工具。而在这个领域中，「GFS（Google File System）」论文无疑是一篇具有里程碑意义的文献。GFS 由 Google 公司发表于 2003 年，它介绍了 Google 公司内部使用的分布式文件系统，该系统为 Google 的大规模数据处理提供了坚实的基础。

该论文的重要性在于它提出了一种全新的分布式文件系统架构，该架构具有「高可靠性、高扩展性和高性能」等特点。同时，其中的许多设计思想和技术已经成为当今分布式文件系统的标准，例如数据一致性模型、副本机制等。

此外，GFS 还引发了学术界和工业界对分布式文件系统的研究热潮，推动了大数据技术的发展。许多著名的分布式文件系统，如 「Hadoop 的 HDFS」、AWS 的 S3 等，都受到了 GFS 论文的启发。

因此，对于从事大数据领域的研究人员和工程师来说，深入理解 GFS 论文是「非常重要」的。本文将对 GFS 进行详细解读，介绍其架构、设计思想和关键技术，并探讨其在大数据领域的应用和影响。

本文参考的论文链接为：https://github.com/night-cruise/paper-zh/blob/main/src/google%20file%20system/google%20file%20system-zh.md

特性

该论文前两章跟我们讲解了，一个分布式的文件系统应该具备哪些最基本的特性

❝
我们设计并实现了 Google GFS 文件系统，一个面向大规模数据密集型应用的、可伸缩的分布式文件系统。 GFS 虽然运行在廉价的普遍硬件设备上，但是它依然了提供灾难冗余的能力，为大量客户机提供了高性能的服务。
❞

这句话可以画出几个关键字：「大规模数据」、「可伸缩」、「分布式」、「廉价」、「灾难冗余」、「高性能」。

这几个关键字可以说明，GFS可以用多台廉价的设备组装成一个可以处理大规模数据的文件系统，同时可以具备容灾、热扩容的特性

❝
首先，组件失效被认为是常态事件，而不是意外事件。GFS 包括几百甚至几千台普通的廉价设备组装的存储机器，同时被相当数量的客户机访问。GFS 组件的数量和质量导致在事实上，任何给定时间内都有可能发生某些组件无法工作，某些组件无法从它们目前的失效状态中恢复。我们遇到过各种各样的问题，比如应用程序 bug、操作系统的 bug、人为失误，甚至还有硬盘、内存、连接器、网络以及电源失效等造成的问题。所以，持续的监控、错误侦测、灾难冗余以及自动恢复的机制必须集成在 GFS 中。
❞

在一个由大量机器组装成的分布式环境当中，个别机器出现「故障是常态」，为了避免故障的发生而影响整个环境的运作，针对故障的「监控」、适当的「冗余」以及故障发生之后的「恢复」能力是这个文件系统所必须的机制。

❝
其次，以通常的标准衡量，我们的文件非常巨大。数 GB 的文件非常普遍。每个文件通常都包含许多应用程序对象，比如 web 文档。当我们经常需要处理快速增长的、并且由数亿个对象构成的、数以 TB 的数据集时，采用管理数亿个 KB 大小的小文件的方式是非常不明智的，尽管有些文件系统支持这样的管理方式。因此，设计的假设条件和参数，比如 I/O 操作和 Block 的尺寸都需要重新考虑。文件巨大，对象繁多，针对这种情况，block的尺寸问题就需要考虑进来
❞

block过大可能会导致读取单个块用时过长，从而没有很好的利用分布式的特性；block过小可能会导致频繁的IO，从而耗费大量时间

❝
第三，绝大部分文件的修改是采用在文件尾部追加数据，而不是覆盖原有数据的方式。对文件的随机写入操作在实际中几乎不存在。一旦写完之后，对文件的操作就只有读，而且通常是按顺序读。大量的数据符合这些特性，比如：数据分析程序扫描的超大的数据集；正在运行的应用程序生成的连续的数据流；存档的数据；由一台机器生成、另外一台机器处理的中间数据，这些中间数据的处理可能是同时进行的、也可能是后续才处理的。对于这种针对海量文件的访问模式，客户端对数据块缓存是没有意义的，数据的追加操作是性能优化和原子性保证的主要考量因素。
❞

对于绝大多数对文件的修改操作而言，尾部追加数据是常态，随机写入几乎不存在

那么什么情况是尾部追加以及什么时候是随机读写呢？

「尾部追加」

「日志文件」：许多应用程序会生成日志文件，记录程序运行过程中的各种信息。这些日志信息通常是按时间顺序生成的，新的日志信息会被追加到日志文件的尾部，而不是覆盖已有的日志信息。

「数据流处理」：在处理数据流时，新的数据通常会被追加到已有的数据集合中。比如，在处理实时数据时，新的数据会被追加数据流中，而不是覆盖已有的数据。

「随机读写」

「数据库的更新操作」：当我们需要更新数据库中的某条记录时，就需要定位到这条记录在数据库文件中的位置，然后覆盖原有的数据。

「图像和视频编辑」：在图像和视频编辑过程中，可能需要修改图像或视频的某一部分，比如改变某个区域的颜色，这时就需要随机地读取和写入图像或视频文件的数据。

同时对于数据的追加操作是 「性能优化」和「原子性保证」的主要考量因素这句话如何理解？

「性能优化」：如果每次写入数据的时候都需要在文件中找到一个位置，然后覆盖原有数据，那这就涉及到「随机访问」磁盘，会消耗大量的I/O资源，降低系统性能。相比之下，如果新数据总是被追加到文件的末尾，那么数据的写入就变成了「顺序I/O操作」，大大提高了系统的处理速度。

「原子性保证」：原子性是指一个操作要么全部完成，要么全部不完成。在大规模数据中，追加操作在这方面会有一定的优势。例如：追加操作可以更简单地支持并发控制。多个线程可以同时向文件末尾追加数据，而「不需要复杂的锁机制」。而对于随机写入，可能需要更复杂的并发控制机制来防止数据冲突。

❝
第四，应用程序和文件系统 API 的协同设计提高了整个系统的灵活性。比如，我们放松了对 GFS 一致性模型的要求，这样就减轻了文件系统对应用程序的苛刻要求，大大简化了 GFS 的设计。我们引入了原子性的记录追加操作，从而保证多个客户端能够同时进行追加操作，不需要额外的同步操作来保证数据的一致性。本文后面还有对这些问题的细节的详细讨论。
❞

我们放松了对 GFS 一致性模型的要求，这里指的是该文件系统要求的是「最终一致性」而不是「严格一致性」

「严格一致性 VS 最终一致性」

「严格一致性」

在传统的数据库或文件系统中，一致性通常是指在某个时间点上，所有的数据访问都应该返回一致的结果，无论这些访问是来自同一个客户端还是多个客户端。

这意味着，如果一个数据项被更新，那么在后续的读取操作中，应该能够看到这个更新后的结果，以保证数据的完整性和准确性。

「最终一致性」

在某些情况下，最终一致性的要求可能是为了提高系统的性能、可伸缩性或灵活性。

例如，在分布式系统中，为了实现更好的容错性和可用性，可能会采用最终一致性模型，即数据在「最终」会达到一致，但在某些时刻可能会存在不一致的情况，因为数据可能还没有在所有节点上完全同步。

基础设计

基础架构

❝
一个 GFS 集群包含一个单独的 Master 节点、多台 Chunk 服务器，并且同时被多个客户端访问，如图 1 所示。所有的这些机器通常都是普通的 Linux 机器，运行着用户级别(user-level)的服务进程。我们可以很容易的把 Chunk 服务器和客户端都放在同一台机器上，前提是机器资源允许，并且我们能够接受不可靠的应用程序代码带来的稳定性降低的风险。
❞

GFS采用的是「主从结构」，一个master对应多个chunk

❝
GFS 存储的文件都被分割成固定大小的 Chunk。在 Chunk 创建的时候，Master 服务器会给每个 Chunk 分配一个不变的、全球唯一的 64 位的 Chunk 标识。Chunk 服务器把 Chunk 以 Linux 文件的形式保存在本地硬盘上，并且根据指定的 Chunk 标识和字节范围来读写块数据。出于可靠性的考虑，每个块都会复制到多个块服务器上。缺省情况下，我们使用 3 个存储复制节点，不过用户可以为不同的文件命名空间设定不同的复制级别。
❞

在存储文件的时候，不会将一整块大的文件存储在一起，而是会分成多个「固定大小」的chunk存储在「多个服务器」中

那这时，为了定位到chunk，需要给每个chunk都分配一个唯一的标识符

考虑到「灾难冗余」，将每个chunk都「复制多份」存储在不同的地方，至于存储几份，可以设置不同的「复制级别」

❝
Master 节点管理所有的文件系统元数据。这些元数据包括名字空间、访问控制信息、文件和 Chunk 的映射信息、以及当前 Chunk 的位置信息。Master 节点还管理着系统范围内的活动，比如，Chunk 租用管理、孤儿 Chunk的回收、以及 Chunk 在 Chunk 服务器之间的迁移。Master 节点使用心跳信息周期地和每个 Chunk 服务器通讯，发送指令到各个 Chunk 服务器并接收 Chunk 服务器的状态信息。
❞

master可以理解为是「管理整个系统」的存在，他需要知道所有chunk服务器的状态以及chunk存储的位置信息

那么为了及时了解当前系统的状态，就需要「周期性」的和chunk进行通讯

❝
无论是客户端还是 Chunk 服务器都不需要缓存文件数据。客户端缓存数据几乎没有什么用处，因为大部分程序要么以流的方式读取一个巨大文件，要么工作集太大根本无法被缓存。无需考虑缓存相关的问题也简化了客户端和整个系统的设计和实现6。Chunk 服务器不需要缓存文件数据的原因是，Chunk 以本地文件的方式保存，Linux 操作系统的文件系统缓存会把经常访问的数据缓存在内存中。
❞

这部分关于缓存，我认为原文已经说的够清楚了，应该不用过多论述了

单一的 Master 节点

❝
单一的 Master 节点的策略大大简化了我们的设计。单一的 Master 节点可以通过全局的信息精确定位 Chunk 的位置以及进行复制决策。另外，我们必须减少对 Master 节点的读写，避免 Master 节点成为系统的瓶颈。客户端并不通过 Master 节点读写文件数据。反之，客户端向 Master 节点询问它应该联系的 Chunk 服务器。客户端将这些元数据信息缓存一段时间，后续的操作将直接和 Chunk 服务器进行数据读写操作。
❞

整个系统中只存在一个master会简化设计，但是，客户端要进行读写操作的时候会「先和master进行通信」获取chunk的元信息

这时，如果master在一段时间收到大量来自客户端的请求，就可能造成负载过大，从而影响整个系统的运行

所以客户端对接收到的元信息会进行缓存，以此来避免频繁的和master进行通信

读取流程

❝
我们利用图 1 解释一下一次简单读取的流程。首先，客户端把文件名和程序指定的字节偏移，根据固定的 Chunk 大小，转换成文件的 Chunk 索引。然后，它把文件名和 Chunk 索引发送给 Master 节点。Master 节点将相应的 Chunk 标识和副本的位置信息发还给客户端。客户端用文件名和 Chunk 索引作为 key 缓存这些信息。
❞

客户端要对数据进行读取，首先将要读取的文件名和偏移发给master，master会返回对应chunk的元信息，客户端对这些传回来的元信息进行缓存

(老登，我要读这个文件，你告诉我chunk在哪？)

❝
之后客户端发送请求到其中的一个副本处，一般会选择最近的。请求信息包含了 Chunk 的标识和字节范围。在对这个 Chunk 的后续读取操作中，客户端不必再和 Master 节点通讯了，除非缓存的元数据信息过期或者文件被重新打开。实际上，客户端通常会在一次请求中查询多个 Chunk 信息，Master 节点的回应也可能包含了紧跟着这些被请求的 Chunk 后面的 Chunk 的信息。在实际应用中，这些额外的信息在没有任何代价的情况下，避免了客户端和 Master 节点未来可能会发生的几次通讯。
❞

由于一个chunk被复制成了多份，这时客户端进行读取的时候只需要读取最近的chunk信息

同时由于本地缓存了元信息，就不需要每次都要和master进行通信，除非过期(嘿嘿嘿，我忘了，你再告诉我一遍)

Chunk Size

❝
选择较大的 Chunk 尺寸有几个重要的优点。首先，它减少了客户端和 Master 节点通讯的需求，因为只需要一次和 Mater 节点的通信就可以获取 Chunk 的位置信息，之后就可以对同一个 Chunk 进行多次的读写操作。这种方式对降低我们的工作负载来说效果显著，因为我们的应用程序通常是连续读写大文件。即使是小规模的随机读取，采用较大的 Chunk 尺寸也带来明显的好处，客户端可以轻松的缓存一个数 TB 的工作数据集所有的 Chunk 位置信息。其次，采用较大的 Chunk 尺寸，客户端能够对一个块进行多次操作，这样就可以通过与 Chunk 服务器保持较长时间的 TCP 连接来减少网络负载。第三，选用较大的 Chunk 尺寸减少了 Master 节点需要保存的元数据的数量。这就允许我们把元数据全部放在内存中，在 2.6.1 节我们会讨论元数据全部放在内存中带来的额外的好处。
❞

chunk尺寸较大，代表的一个文件被分割成的「份数会减少」，那读取的时候需要知道的元信息就会减少，从而减少和master进行通信的需求

同时，一个chunk存储的数据也会增多，也不用频繁去读取更多的chunk，也不用去和更多的chunk服务器去建立通信

最后，不管这个chunk多大，「元信息的大小都是不变的」，所以也是降低了存储的压力

❝
另一方面，即使配合惰性空间分配，采用较大的 Chunk 尺寸也有其缺陷。小文件包含较少的 Chunk，甚至只有一个 Chunk。当有许多的客户端对同一个小文件进行多次的访问时，存储这些 Chunk 的 Chunk 服务器就会变成热点。在实际应用中，由于我们的程序通常是连续的读取包含多个 Chunk 的大文件，热点还不是主要的问题。
❞

❝
然而，当我们第一次把 GFS 用于批处理队列系统的时候，热点的问题还是产生了：一个可执行文件在 GFS 上保存为 single-chunk 文件，之后这个可执行文件在数百台机器上同时启动。存放这个可执行文件的几个 Chunk 服务器被数百个客户端的并发请求访问导致系统局部过载。我们通过使用更大的复制参数来保存可执行文件，以及错开批处理队列系统程序的启动时间的方法解决了这个问题。一个可能的长效解决方案是，在这种的情况下，允许客户端从其它客户端读取数据。
❞

这里说了较大的chunk所产生的热点问题

解决方法为：将chunk复制更多份和错峰读取文件，从而减轻单个chunk服务器的压力

元信息

❝
Master 服务器存储 3 种主要类型的元数据，包括：文件和 Chunk 的命名空间、文件和 Chunk 的对应关系、每个 Chunk 副本的存放地点。所有的元数据都保存在 Master 服务器的内存中。前两种类型的元数据同时也会以记录变更日志的方式记录在操作系统的系统日志文件中，日志文件存储在本地磁盘上，同时日志会被复制到其它的远程Master服务器上。采用保存变更日志的方式，我们能够简单可靠的更新 Master 服务器的状态，并且不用担心 Master 服务器崩溃导致数据不一致的风险。Master 服务器不会持久保存 Chunk 位置信息。Master 服务器在启动时，或者有新的 Chunk 服务器加入时，向各个 Chunk 服务器轮询它们所存储的 Chunk 的信息。
❞

这里说的是master服务器要存储的元数据类型，同时提到了变更日志，这个日志一会会有更详细的讲解

master「不会持久化」存储元信息，因为这些信息是存储在内存当中的，所以在每次启动的时候需要轮询向每个chunk服务器进行询问，以获得当前系统最新的情况

❝
将元数据全部保存在内存中的方法有潜在问题：Chunk 的数量以及整个系统的承载能力都受限于 Master 服务器所拥有的内存大小。但是在实际应用中，这并不是一个严重的问题。Master 服务器只需要不到 64 个字节的元数据就能够管理一个 64MB 的 Chunk。由于大多数文件都包含多个 Chunk，因此绝大多数 Chunk 都是满的，除了文件的最后一个 Chunk 是部分填充的。同样的，每个文件的在命名空间中的数据大小通常在 64 字节以下，因为保存的文件名是用前缀压缩算法压缩过的。
❞

这里主要说明了将元信息存储在内存的无关紧要的问题

那么，为什么不将元信息持久化呢？

❝
最初设计时，我们试图把 Chunk 的位置信息持久的保存在 Master 服务器上，但是后来我们发现在启动的时候轮询 Chunk 服务器，之后定期轮询更新的方式更简单。这种设计简化了在有 Chunk 服务器加入集群、离开集群、更名、失效、以及重启的时候，Master 服务器和 Chunk 服务器数据同步的问题。在一个拥有数百台服务器的集群中，这类事件会频繁的发生。
❞

❝
可以从另外一个角度去理解这个设计决策：只有 Chunk 服务器才能最终确定一个 Chunk 是否在它的硬盘上。我们从没有考虑过在 Master 服务器上维护一个这些信息的全局视图，因为 Chunk 服务器的错误可能会导致 Chunk 自动消失(比如，硬盘损坏了或者无法访问了)，亦或者操作人员可能会重命名一个 Chunk 服务器。
❞

可以理解为，启动时轮询可以简化设计，不需要针对chunk服务器的变更问题进行过多的考虑

同时，chunk具体是什么情况，只有chunk服务器知道，master了解的只是「元信息」，所以如果这个chunk发生一些变更，master存储的也可能是错误的数据

日志

❝
操作日志非常重要，我们必须确保日志文件的完整，确保只有在元数据的变化被持久化后，日志才对客户端是可见的。否则，即使 Chunk 本身没有出现任何问题，我们仍有可能丢失整个文件系统，或者丢失客户端最近的操作。所以，我们会把日志复制到多台远程机器，并且只有把相应的日志记录写入到本地以及远程机器的硬盘后，才会响应客户端的操作请求。Master 服务器会收集多个日志记录后批量处理，以减少写入磁盘和复制对系统整体性能的影响。
❞

如果在数据「还没持久化完毕时」就告诉客户端自己写完了，那么如果这期间发生一些故障导致数据的丢失，客户端也会默认数据已经写完了，从而造成文件的丢失。

❝
Master 服务器在灾难恢复时，通过重演操作日志把文件系统恢复到最近的状态。为了缩短 Master 启动的时间，我们必须使日志足够小。Master 服务器在日志增长到一定量时对系统状态做一次 Checkpoint，将所有的状态数据写入一个 Checkpoint 文件。在灾难恢复的时候，Master 服务器就通过从磁盘上读取这个 Checkpoint 文件，以及重演 Checkpoint 之后的有限个日志文件就能够恢复系统。Checkpoint 文件以压缩 B-树形势的数据结构存储，可以直接映射到内存，在用于命名空间查询时无需额外的解析。这大大提高了恢复速度，增强了可用性
❞

日志文件是「持久化」到硬盘当中的，这样在出现故障的时候，我们可以将日志中的行为重演一遍从而对系统进行恢复

一致性模型

❝
当一个数据修改操作成功执行，并且没有受到同时执行的其它写入操作的干扰，那么影响的 region 就是已定义的（隐含了一致性）：所有的客户端都可以看到写入的内容。并行修改操作成功完成之后，region 处于一致的、未定义的状态：所有的客户端看到同样的数据，但是无法读到任何一次写入操作写入的数据。通常情况下，文件 region 内包含了来自多个修改操作的、混杂的数据片段。失败的修改操作导致一个 region 处于不一致状态（同时也是未定义的）：不同的客户在不同的时间会看到不同的数据。后面我们将描述应用如何区分已定义和未定义的 region。应用程序没有必要再去细分未定义 region 的不同类型。
❞

对于修改后的文件，如果多个客户端读取的结果是一样的，那么就是「一致的」

如果客户端能够看到修改完的全部内容，那么就是「可定义的」

并行修改操作成功完成之后，为何region 「处于一致的、未定义」的状态?

为了确保数据的一致性和完整性,在并行修改操作期间，多个客户端可能同时尝试对同一 region 进行修改。为了避免冲突和数据不一致，系统可能采用一种锁机制或其他协调机制来确保只有一个修改操作可以成功。

一旦并行修改操作完成，系统会将 region 标记为一致但未定义的状态。这意味着所有的客户端都能看到相同的数据，但由于修改操作还没有被确认或应用到所有副本上，因此客户端无法读取到最新的修改结果。

举个例子，假设有两个客户端同时尝试修改同一 region 的数据。客户端 A 将数据的值从 10 改为 20，而客户端 B 将数据的值从 10 改为 30。为了避免冲突，系统可能会暂停其中一个客户端的修改操作，这时 region 被标记为一致但未定义的状态。在这个状态下，所有的客户端都能看到数据的值为 10

❝
数据修改操作分为写入或者记录追加两种。写入操作把数据写在应用程序指定的文件偏移位置上。即使有多个修改操作并行执行时，记录追加操作至少可以把数据原子性的追加到文件中一次，但是偏移位置是由 GFS 选择的（3.3 章）15。GFS 返回给客户端一个偏移量，表示了包含了写入记录的、已定义的 region 的起点。另外，GFS 可能会在文件中间插入填充数据或者重复记录。这些数据占据的文件 region 被认定是不一致的，这些数据通常比用户数据小的多。
❞

这里解释了为什么记录追加的时候，region可能会是不一致的，在写入文件的时候，可能会插入一些「标识」

因为GFS会有「自验证」的写入操作，自标识的记录

具体的应用场景可以看下面这段

❝
我们再来分析另一种典型的应用。许多应用程序并行的追加数据到同一个文件，比如进行结果的合并或者是一个生产者-消费者队列。记录追加方式的“至少一次追加”的特性保证了 Writer 的输出。Readers 使用下面的方法来处理偶然性的填充数据和重复内容。Writers 在每条写入的记录中都包含了额外的信息，例如 Checksum，用来验证它的有效性。Reader 可以利用 Checksum 识别和抛弃额外的填充数据和记录片段。如果应用不能容忍偶尔的重复内容(比如，如果这些重复数据触发了非幂等操作)，可以用记录的唯一标识符来过滤它们，这些唯一标识符通常用于命名程序中处理的实体对象，例如 web 文档。这些记录 I/O 功能18都包含在我们的程序共享的库中，并且适用于 Google 内部的其它的文件接口实现。所以，相同序列的记录，加上一些偶尔出现的重复数据，都被分发到 Reader 了。
❞

在写入数据时，数据中包含「checksum」，用来帮助reader对数据进行校验