HDFS——Hadoop分布式文件系统

本文是HDFS论文的翻译，并非通篇翻译，只摘了关键部分帮助更好的理解HDFS是什么，架构如何设计。
原文：The Hadoop Distributed File System

摘要

Hadoop分布式文件系统（HDFS）被设计用来可靠地存储大规模数据集，并以高带宽将这些数据集流式传输给用户程序（原文：stream to user applications）。在一个大型集群中，几千台服务器直接充当附加存储，并且执行用户任务。通过在大量服务器之间分配存储和计算，资源可以按需增长，在各种大小下都保持经济实惠。我们描述了HDFS的架构以及用其在Yahoo管理25PB的企业数据的经验。

介绍

Hadoop提供了一个分布式文件系统和一个利用MapReduce范式的大数据分析转换框架。HDFS是Hadoop的文件系统组件。

接口风格：虽然HDFS接口是参考UNIX文件系统设计的，但是为了性能，牺牲了部分标准和忠实性。

节点类型：HDFS将文件系统元数据和用户应用数据分开存储，有一个专门用于存储元数据的服务器称作NameNode，这和GFS、PVFS、Lustre等不同。其它的服务器存储应用数据，称作DataNodes。所有的服务器都彼此完全连接并基于TCP通信。

数据可靠性：和GFS相似，通过在多个节点复制同一份内容来达到可靠性。而不像Lustre和PVFS这种，它们使用RAID技术。

• 数据传输带宽倍乘，因为好几个节点都有数据
• 有更多机会将计算任务选到靠近的节点执行

架构

NameNode

存储什么：文件、文件夹、层次结构、文件块在DataNode上的物理位置、等元数据信息。

存储结构：文件和目录被使用inode结构进行存储，其记录了权限、修改访问时间等属性。文件内容被分成了128MB的大块，每个块独立的被复制到3个DataNode，块大小和副本数都是可以以文件级别配置的。

读数据：client先找NameNode，NameNode返回数据块的位置信息，client找离它最近的读。

写数据：先找NameNode选中3个数据节点来承载block副本（数量应该是可配置的），客户端以流水线形式将数据写到DataNode。如下图是HDFS客户端创建一个文件的新块并写入数据的示例：

节点数量：每一个集群只有一个NameNode，有几千个DataNode，DataNode需具备并发处理client请求的能力

持久化数据：HDFS将整个命名空间保存在内存中，inode数据以及每个文件的块列表数据被称作映像（image），将映像持久化到本地文件系统的持久化记录称作检查点（checkpoint）。映像的修改日志也被持久化到本地文件系统了，称作日志（journal）。允许将检查点和日志复制到其它服务器上。重启时，NameNode通过读取映像、重放日志来完成恢复。块的物理位置由于会动态变更，所以不作为持久化的一部分。

DataNode

每一个块副本都被表示成两个本地文件，一个是实际文件内容，另一个是文件的checksum和generation stamp。

握手过程：启动过程中，每一个DataNode都连接到NameNode，并执行握手来校验命名空间ID（集群唯一，格式化文件系统时分配）和软件版本，不匹配就自动shutdown。新节点刚要连接到集群的会收到集群的命名空间id。

注册过程：握手后，DataNode将要向NameNode注册。此时需要提供它的唯一存储ID，NameNode靠这个ID来识别DataNode，这样可以忽略IP和端口的变更（甚至机器变了应该都行吧）。存储ID第一次注册时得到，永远不变。

发送块报告：数据块发送块报告，以让NameNode了解它身上有哪些块。块报告中包括块ID、generation stamp、块长度等。注册后立即执行一次块报告的发送，随后1小时执行一次，确保NameNode有最新的块位置视图。

心跳：DataNode以3秒为间隔发送心跳到NameNode以确定它在运行，以及它上面的块是可用的。如果NameNode 10分钟没收到一个DataNode的心跳，就认为它挂了，于是需要将它身上的块副本都调度到一个新的DataNode上。心跳消息中还包含存储容量、正在使用的存储大小、正在进行的数据传输任务数量等，这些数据会影响到NameNode的空间分配以及负载均衡决策。

单向控制流：NameNode并不直接call DataNode，它使用heartbeat的回复消息来发送指令。包括：

• 复制块到其它节点
• 移除本地块副本
• 重新注册或shutdown节点
• 立即发送块报告

HDFS客户端

HDFS提供了一个能够暴露文件块位置的API，这允许像MapReduce这样的框架能够将任务直接调度在数据节点上以提升读性能，降低网络带宽使用率。

HDFS允许设置文件的副本因子，对于关键文件或频繁访问的文件，具有更高的副本因子将提升读取带宽和容错能力。

Image和Journal

image是文件系统元数据的记录，对应磁盘上的持久化记录称作checkpoint。

journal是文件系统变更的预写日志。对于任何的客户端事务，其变更记录都在journal中，并且journal文件需要在给客户端返回提交之前刷盘。

checkpoint文件永远不会被NameNode更改，只在下面情况中完整的替换原来的检查点文件

• 当在重启过程中一个新的检查点被创建时
• 当被管理员请求，或被CheckpointNode请求时

在启动时，NameNode从checkpoint初始化命名空间的image，然后它从journal中重放变更，直到image更新为文件系统的最新状态，然后，在NameNode提供服务之前，一个新的检查点和空日志被写回。

问题：这journal不会很大吗！？？？大到难以重放？？(下一节解答)

checkpoint或journal丢失或损坏，命名空间信息就会部分或全部丢失，HDFS通过在多个目录存储这些文件来规避这一点。实践中，通常推荐将其放到不同的卷中，而且有一个在远程NFS服务器上。

CheckpointNode

周期性的组合现有checkpoint和journal来创建新的checkpoint，由于它和NameNode需要相同的内存，所以通常运行在不同的机器上。

它下载当前检查点和日志文件，本地将它们合并，返回新的检查点到NameNode。

这个操作可以缩小日志文件的长度，降低其损坏的风险，加速HDFS的启动速度。对于一个大型集群，通常需要1小时来处理一周的日志，所以每天创建检查点是好的。

BackupNode

HDFS最近引入的特性。

它拥有CheckPoint的功能，并额外维护一个内存中的，总是与NameNode的状态保持同步的image。

BackupNode接受NameNode发送的journal流，将其保存到本地文件，并且应用这些事务到自己的内存image中，如果NameNode故障，BackupNode的内存image和磁盘checkpoint就是命名空间的最新状态。

BackupNode可以创建checkpoint而无需从NameNode下载checkpoint和journal，因为它永远是up-to-date的。

BackupNode可以被看作是一个只读的NameNode，它包含所有文件系统元数据信息，除了块位置。它可以执行除了与命名空间修改或块位置相关的所有操作，使用一个BackupNode可以让NameNode无需持久存储，将状态持久的责任交给BackupNode。

更新，文件系统快照

我只是需要搭一个HDFS，目前的知识貌似已经足够了，我未来会回来的