HDFS [MSST‘10] 论文阅读笔记

原论文：The Hadoop Distributed File System (MSST’10)

HDFS关键技术要点概览

设计目标：HDFS旨在可靠地存储大型数据集，并以高带宽流式传输这些数据集到用户应用程序。它通过在大量服务器上分布存储和计算资源，使得资源可以随着需求的增长而扩展，同时保持经济高效。
架构组成：HDFS是Hadoop项目的一部分，包括了分布式文件系统、MapReduce计算框架、HBase列式存储系统、Pig数据流语言、Hive数据仓库基础设施、ZooKeeper分布式协调服务等多个组件。
存储和元数据分离：HDFS将文件系统元数据和应用数据分开存储。元数据存储在专用的NameNode服务器上，而应用数据存储在DataNode服务器上。
数据复制：HDFS不像传统的文件系统使用RAID等数据保护机制，而是通过在多个DataNode上复制文件内容来确保数据的可靠性。这种策略不仅保证了数据的持久性，还提高了数据传输带宽，并为计算任务提供了更多的机会来靠近所需数据。
NameNode和DataNode：NameNode维护文件系统的namespace tree和block到DataNode的映射关系。DataNode则存储实际的数据块，并与NameNode通信以报告其健康状况和存储状态。
客户端操作：HDFS客户端提供了一系列文件系统操作，如读写文件、创建和删除目录等。客户端与NameNode交互以获取文件块的位置信息，然后直接与DataNode通信来读取或写入数据。
容错和数据完整性：HDFS通过复制数据块来提高容错能力。如果检测到数据块损坏，HDFS会从其他DataNode获取有效副本。此外，HDFS还提供了块扫描器来定期检查数据块的完整性。
平衡器（Balancer）：为了确保集群中数据的均匀分布，HDFS提供了一个平衡器工具，它可以将数据从一个DataNode复制到另一个DataNode，以平衡集群中的磁盘空间使用。
升级和快照：HDFS支持在软件升级期间创建文件系统快照，以便在升级导致数据损坏时可以回滚到升级前的状态。
性能基准测试：论文提供了HDFS在不同操作（如读取、写入、追加）下的性能基准测试结果，以及在生产环境中的实际性能表现。
未来工作：论文讨论了HDFS未来的发展方向，包括提高NameNode的可扩展性、实现自动化故障转移、支持多个namespace以及改进集群间的协作。

HDFS原论文阅读

Introduction

Hadoop提供了一个分布式文件系统和一个基于MapReduce实现的对超大数据集的分析和转换的框架。
Hadoop的重要特点：数据的分割、横跨成千上万个主机的计算、在接近数据的地方并行执行应用程序的计算。
Hadoop集群通过简单地增加服务器来扩展计算容量、存储容量和IO带宽。
Hadoop 项目的组成元件
Hadoop将元数据存储在NameNode上，将应用程序数据存储在DataNode上，所有服务器通过TCP-based协议连接和通信。
和GFS类似，Hadoop通过存储多个副本在DataNodes上来实现数据的可靠性。
一个文件通过一个哈希函数将名称映射到特定的MDS（namespace服务器）。

Architecture

NameNodes

HDFS namespace是一个文件和目录的层级结构。在NameNode中，文件和目录是通过inodes来呈现的，内容包括属性值（如允许的权限）、修改和访问时间、namespace和磁盘空间配额等。
文件内容被分割成（默认为128MB大小的）块，然后每个块独立地在其他DataNodes上有多个副本（一般为三副本）。
Namenode保存着namespace tree以及blocks到DataNode的映射表（文件数据的物理位置）。
想要读取文件的 HDFS clients首先会联系 NameNode 以获取组成文件的数据块位置，然后从最靠近client的 DataNode 读取块内容。在写入数据时，clients会要求 NameNode 指定由三个DataNodes来管理数据块副本。然后，clients以流水线方式向DataNodes写入数据。
HDFS将整个namespace存储在RAM中。命名系统元数据image由inode的数据和属于每个文件的block list组成，存储在本地主机本地文件系统中的image持久记录称为checkpoint，NameNode 还会在本地主机的本地文件系统中存储名为journal的image修改日志。为了提高耐用性，可在其他服务器上创建checkpoint和journal的副本。当重启时NameNode通过读取namespace和重新应用journal来恢复namespace。块的副本的位置是经常发生变化的，因此不属于持久checkpoint的一部分。

DataNodes

每个block在DataNode中的副本由本地主机本地文件系统上的两个文件来表示。第一个文件包含数据本身，第二个文件是该block的元数据：数据的校验和checksum和generation stamp（世代戳）。数据文件的大小等于实际块的长度而不需要向传统文件系统那样基于block size对齐。
handshake：在启动阶段，每个DataNode与NameNode建立连接并执行一次handshake，handshake的目的是校验DataNode的namespace ID和software version，如果有其中之一不匹配则DataNode自动关机。
- namespace ID会在格式化文件系统实例时分配给它，namespace ID可以持久化地存储在集群中的所有节点。拥有不同的namespace ID的节点不能加入到集群中，从而保证文件系统的完整性。如果一个DataNode是最新初始化的且没有namespace ID，它是被允许加入集群的并会收到集群的namespace ID。
- 不一致的（不兼容的）software version会导致数据冲突和丢失，并且在大型集群中，很容易忽略那些在软件升级前没有正常关闭或在升级过程中无法使用的节点。
register：handshake完成后，DataNode需要向NameNode注册。DataNode持久地保存它们自己唯一的storage IDs，storage ID作为DataNode的一个内部标识，当DataNode以另一个IP地址或端口重启时可以被识别出来。storage ID是由DataNode在第一次注册的时候从NameNode处获取并且之后不会再改变。
block report：DataNode通过向NameNode发送block report来提供它拥有的block副本信息，block report包含block id、generation stamp和每个block 副本的长度。第一次的block report在DataNode注册完成后立即被发送，之后每小时发送一次以向NameNode提供实时更新的block副本信息。
heartbeats：NameNode通过heartbeats来确认DataNode存活以及它管理的block replicas是可用的。默认heartbeat间隔是3秒。如果DataNode超过10分钟没有发送heartbeats，则被当作已不能提供服务以及它存储的block副本变为不可用，NameNode就会调度在其他DataNodes上创建新的副本。
- DataNode发出的heartbeats信息包括总的存储容量、已经使用的比例以及当前正在传输的数据量。用于NameNode进行空间分配和负载均衡的决策。
- NameNode不会直接调用DataNode，而是通过响应heartbeats来向DataNode传递instructions，instructions包括的命令有：复制blocks到其他节点、移除本地block副本、重新注册或者关机、立即发送block report。

HDFS Client

用户程序通过HDFS client访问文件系统，通过namespace中的路径来访问文件和目录，同时不需要知道文件系统的细节信息如元数据、数据存储在多少个服务器上、blocks有多少副本。
HDFS支持的操作：读、写、删除文件，创建和删除目录。
当应用程序请求读取一个文件时，HDFS client首先会向NameNode查询存储该文件的block的DataNode列表，然后直接和其中一个DataNode直接交互请求传输想要的块。当有一个client写请求时，client首先请求NameNode选出用于存储文件第一个block的副本的DataNodes，然后组织从节点到节点的流水线并发送数据；当第一个block写完毕后，则会以相同的流程处理下一个block的写。
与传统的文件系统不同的是，HDFS提供一个API用于查询一个文件的所有blocks的位置，这种方式允许应用程序如MapReduce框架根据数据分布调度任务从而提高读性能。同时允许一个应用程序设置文件的replication factor（默认为3），一些关键的或访问频率高的文件会有更高的replication factor。

Image and Journal

namespace image是文件系统元数据，用于将应用程序数据的组织描述成目录和文件，一个checkpoint是被写入磁盘的image的一个持久性记录。
journal是在每次提交文件系统修改到HDFS client之前就写入磁盘的日志文件。
NameNode 绝不会更改checkpoint文件；在重启过程中创建新的checkpoint时，或在管理员提出要求时，或在下一节中描述的CheckpointNode提出要求时，checkpoint文件将被全部替换。在启动过程中，NameNode 会根据checkpoint初始化namespace image，然后重复日志中的更改，直到image与文件系统的最后状态保持一致。在 NameNode 开始为client提供服务之前，新的checkpoint和空的journal会被写回存储目录。
如果checkpoint和journal其中之一丢失或损坏，则namespace信息会部分或全部丢失。为了避免这点，HDFS将checkpoint和journal存储在多个存储目录下，建议的做法是将目录放在不同的volume上，并将一个存储目录放在远程 NFS 服务器上（避免single volume failures和entire node failures导致信息丢失）。如果 NameNode 在将journal写入某个存储目录时遇到错误，它会自动将该目录从存储目录列表中排除。如果没有可用的存储目录，NameNode 会自动关闭。

CheckpointNode

NameNode除了可以扮演为client的请求服务的角色外，还可以当作CheckpointNode和BackupNode，这些角色在节点启动的时候被指定。
CheckpointNode会阶段性整合现有的checkpoint和journal，然后创建一个新的checkpoint和空的journal。它会从NameNode下载当前的checkpoint和journal文件，然后在本地对它们进行合并，然后将新的checkpoint返回给NameNode。
当新的checkpoint上传到NameNode后，NameNode会在journal的尾部进行截断。journal在不断地增长，需要每天创建新的checkpoint来保持journal不会增长过大。

BackupNode

BackupNode和CheckpointNode相似，阶段性地创建checkpoints，同时保持实时更新、存储在内存中、和NameNode同步的文件系统namespace的image，作为NameNode的备份。
BackupNode接受来自NameNode的namespace transactions的journal stream，将其保存到自己的存储目录中，并将这些事务应用到内存中自己的namespace image中。NameNode将BackupNode视为日志存储，就像对待其存储目录中的日志文件一样。如果NameNode发生故障，BackupNode内存中的image和磁盘上的checkpoint将作为namespace的最新状态记录。
因为BackupNode有实时的namespace image，所以创建checkpoint时不需要从NameNode处下载checkpoint和journal文件，从而提高效率。
BackupNode可以被视为read-only NameNode，它包含了除block位置信息外文件系统所有的元数据信息。它可以执行NameNode中除了namespace的修改和block位置信息的获取外其他的常规操作。

Upgrade, File System Snapshots

软件升级风险：在软件升级过程中，由于软件缺陷或人为错误，系统可能会损坏，从而增加数据损坏的风险。
快照的目的：HDFS提供了创建快照的机制，以最小化在系统升级期间可能对存储在系统中的数据造成的潜在损害。快照允许管理员持久化地保存文件系统的当前状态。
快照的创建：系统管理员可以在系统启动时选择创建快照。如果请求了快照，NameNode首先读取检查点和日志文件，并将它们合并在内存中。然后，它将新的检查点和空的日志写入到一个新的位置，这样旧的检查点和日志保持不变。
快照的使用：如果升级导致数据丢失或损坏，管理员可以选择将HDFS回滚到快照状态。NameNode恢复在创建快照时保存的检查点，DataNode恢复之前重命名的目录，并启动后台进程删除在快照创建后创建的数据块副本。
快照的限制：一旦选择了回滚到快照状态，就没有提供向前滚动的选项。管理员可以通过命令系统放弃快照，从而最终确定软件升级，并恢复被快照占用的存储空间。
布局版本（layout version）的变化：系统演变可能导致NameNode的检查点和日志文件格式或DataNode上数据块副本的数据表示格式发生变化。布局版本标识了数据表示格式，并持久化存储在NameNode和DataNode的存储目录中。
数据格式转换：在启动时，每个节点都会比较当前软件的布局版本与存储在其存储目录中的版本，并自动将数据从旧格式转换为新格式。转换需要在系统重启时使用新软件布局版本强制创建快照。
协调快照的必要性：HDFS不针对NameNode和DataNode分别设置布局版本（layout version），因为快照创建必须是整个集群的努力，而不是节点选择性事件。如果升级后的NameNode由于软件缺陷而清除了其image，仅备份namespace状态仍然会导致数据丢失，因为NameNode将无法识别DataNode报告的数据块，并命令删除它们。在这种情况下，回滚将恢复元数据，但数据本身将丢失。需要协调的快照来避免灾难性的破坏。

FILE I/O OPERATIONS AND REPLICA MANGEMENT

File Read and Write

写入数据：应用程序通过创建一个新文件并向其写入数据来向HDFS添加数据。文件关闭后，写入的字节不能被修改或删除，但可以通过重新打开文件进行追加。
写入租约（lease）：打开文件进行写入的HDFS客户端会获得该文件的租约；没有其他客户端可以写入该文件。写入客户端定期通过向NameNode发送心跳来续订租约。关闭文件时，租约将被撤销。
租约限制：租约的持续时间受到软限制和硬限制的约束。在软限制到期之前，写入者对文件具有独占访问权。如果软限制到期且客户端未能关闭文件或续订租约，其他客户端可以抢占租约。如果硬限制到期（一小时），并且客户端未能续订租约，HDFS假定客户端已退出，并代表写入者自动关闭文件并回收租约。
数据块的构成：HDFS文件由数据块组成。当需要新块时，NameNode分配一个具有唯一块ID的块，并确定一个DataNode列表来托管该块的副本。
数据管道：DataNode形成管道，客户端将数据推送到管道中。数据以数据包序列的形式推送，一旦数据包缓冲区填满（通常为64 KB），数据就被推送到管道中。
数据可见性：写入HDFS文件后，HDFS不保证数据对新读者立即可见，直到文件关闭。如果用户应用程序需要可见性保证，可以显式调用hflush操作。
读取数据：当客户端打开文件以读取时，它从NameNode获取块列表和每个块副本的位置。读取操作首先尝试最近的副本。如果读取尝试失败，客户端会按顺序尝试下一个副本。
打开文件的读取：HDFS允许客户端读取正在打开写入的文件。在读取正在写入的文件时，NameNode不知道最后一块的长度。在这种情况下，客户端在开始读取内容之前会询问一个副本以获取最新长度。
优化I/O：HDFS的I/O设计特别优化了批处理系统（如MapReduce），这些系统需要高吞吐量的顺序读写。然而，为了支持像SCRIBE这样的应用程序，它们提供实时数据流到HDFS，或者HBase这样提供对大型表的随机、实时访问，已经做了很多努力来提高读写响应时间。

Block Placement

在这里插入图片描述

集群拓扑：在大型集群中，可能不实际将所有节点以扁平拓扑连接。常见的做法是将节点分布在多个机架（Rack）上，每个机架内的节点共享一个交换机，而机架间的交换机通过一个或多个核心交换机连接。通常，同一机架内节点间的网络带宽大于不同机架间节点的网络带宽。
网络带宽估计：HDFS通过节点间的距离来估计网络带宽。节点到其父节点的距离被假设为一。两个节点之间的距离可以通过累加它们到最近公共祖先的距离来计算。节点间距离越短，它们可用于数据传输的带宽越大。
副本放置策略：副本放置策略对于HDFS数据的可靠性和读写性能至关重要。HDFS提供了可配置的块放置策略接口，允许用户和研究人员实验和测试任何对他们的应用最优化的策略。
默认块放置策略：HDFS的默认块放置策略在最小化写入成本和最大化数据可靠性、可用性以及聚合读取带宽之间提供了折中。创建新块时，第一个副本放置在写入者所在的节点上，第二和第三个副本放置在另一个机架上的两个不同节点上，其余副本则放置在随机节点上，同时遵守以下限制条件：
- 一个DataNode最多放置任意block的一个副本
- 一个Rack最多放置某个block的两个副本，并且两个副本在不同节点上。
读取操作：对于读取操作，NameNode首先检查客户端主机是否位于集群内。如果是，块位置按其靠近读者的顺序返回给客户端。这种策略减少了读取数据时使用的总网络带宽，因为一个块只放置在两个机架中，而不是三个。
副本分布：默认的HDFS副本放置策略确保了数据块的副本不会全部放置在同一机架上。如果NameNode检测到一个块的所有副本都在同一个机架上，它会将该块视为副本不足，并使用上述块放置策略将该块复制到不同的机架上。

Replication management

复制策略：HDFS的NameNode负责确保每个数据块始终具有预期数量的副本。NameNode通过DataNode的块报告来检测数据块是否处于欠复制或过复制状态。
过复制处理：当一个数据块过复制时，NameNode会选择一个副本来移除。NameNode倾向于不减少存储副本的机架数量，并优先从具有最少可用磁盘空间的DataNode上移除副本，以平衡存储利用而不降低数据的可用性。
欠复制处理：当一个数据块欠复制时，它会进入复制优先级队列。只有一个副本的块具有最高的优先级，而副本数量大于复制因子的三分之二的块具有最低的优先级。一个后台线程定期扫描复制队列的头部，以决定在哪里放置新的副本。
副本放置：新的副本放置遵循与新块放置相似的策略。如果现有副本数量为一，HDFS将下一个副本放置在不同的机架上。如果块有两个现有副本，并且这两个副本在同一个机架上，则第三个副本被放置在不同的机架上；否则，第三个副本被放置在与现有副本相同机架的不同节点上。
机架多样性：NameNode确保一个块的副本不会全部位于同一个机架上。如果NameNode检测到一个块的副本最终都位于同一个机架上，它会将该块视为欠复制，并使用上述块放置策略将该块复制到不同的机架上。
副本的移除和替换：当NameNode收到通知表明新的副本已经创建后，该块变得过复制。然后NameNode将决定移除旧副本，因为过复制策略倾向于不减少机架数量。

Balancer

数据分布不均：由于HDFS的块放置策略不考虑DataNode的磁盘空间利用率，数据可能不会均匀分布在所有DataNode上。当新的节点加入集群时，也可能导致数据分布不均。
平衡器的目的：平衡器是一个工具，用于调整HDFS集群中的磁盘空间使用，以确保集群中的每个DataNode的利用率与整个集群的平均利用率相差不超过预设的阈值。
平衡操作：平衡器作为一个应用程序，由集群管理员部署和运行。它通过迭代地将副本从一个利用率较高的DataNode移动到一个利用率较低的DataNode来实现平衡。
数据可用性：在移动副本和决定目标位置时，平衡器确保该操作不会减少副本的数量或机架数量，从而维持数据的可用性。
最小化跨机架数据复制：平衡器通过优化平衡过程来减少跨机架的数据复制。如果平衡器决定需要将副本A移动到不同的机架，而目标机架上已经有了同一数据块的副本B，那么数据将从副本B复制，而不是从副本A。
带宽限制：平衡器的另一个配置参数限制了重新平衡操作消耗的带宽。允许的带宽越高，集群达到平衡状态的速度就越快，但这也意味着与应用程序进程的竞争更加激烈。

Block Scanner

数据块扫描：每个DataNode运行一个块扫描器（Block Scanner），它定期扫描其上存储的数据块副本，并验证存储的校验和是否与数据块内容匹配。
校验和验证：块扫描器在每次扫描周期内调整读取带宽，以确保在可配置的时间段内完成校验和的验证。如果客户端读取了完整的数据块并且校验和验证成功，它会通知DataNode。
校验时间记录：每个DataNode都有一个内存中的扫描列表，按照数据块的校验时间排序。每个顶级DataNode目录下有当前和之前的日志文件，新校验时间会被追加到当前文件中。
损坏块处理：当读取客户端或块扫描器检测到损坏的数据块时，它会通知NameNode。NameNode会将该副本标记为损坏，但不会立即安排删除该副本。相反，它会开始复制一个好的数据块副本。只有当好的副本数量达到数据块的复制因子时，损坏的副本才会被安排移除。
数据保护策略：这种策略旨在尽可能长时间地保留数据。即使一个数据块的所有副本都损坏了，该策略也允许用户从损坏的副本中检索数据。

Decommissioning

节点退役：集群管理员可以指定哪些节点可以加入集群，通过列出允许注册和不允许注册的节点主机地址。管理员可以命令系统重新评估这些包括和排除列表。
标记退役节点：如果一个集群中的现有成员变得不再允许加入集群，它会被标记为退役。一旦DataNode被标记为退役，它将不再被选为副本放置的目标，但会继续服务于读取请求。
副本复制：NameNode开始安排将退役DataNode上的块复制到其他DataNode。这个过程确保数据的可用性不会因为节点的退役而受到影响。
节点安全移除：当NameNode检测到退役DataNode上的所有块都已经复制到其他节点后，该节点进入退役状态。此时，它可以安全地从集群中移除，而不会危及任何数据的可用性。
退役过程的目的：退役过程的目的是为了在不中断服务的情况下，逐步替换掉性能较差或过时的节点，同时确保数据的完整性和集群的稳定性。

Inter-Cluster Data Copy

数据复制挑战：处理大型数据集时，将数据复制进出HDFS集群可能是一项艰巨的任务。为了简化这一过程，HDFS提供了一个名为DistCp的工具，用于大型的集群间或集群内的数据并行复制。
DistCp工具：DistCp是一个基于MapReduce的作业，它通过多个map任务并行地将源数据复制到目标文件系统。MapReduce框架自动处理并行任务调度、错误检测和恢复。
自动化错误处理：DistCp工具能够自动处理复制过程中的错误，确保数据的一致性和完整性。如果复制过程中出现错误，DistCp可以重新尝试失败的任务，或者在必要时跳过某些文件。
使用场景：DistCp特别适用于需要在集群之间迁移大量数据的场景，例如数据备份、灾难恢复、集群升级或数据重新分配等。