HDFS文件系统

HDFS 文件系统 译自 hadoop.apache.org/common/docs/current/hdfs_design.html 廖楠晓 2012.1.2 介绍 HDFS（Hadoop Distributed File System）是一种运行在商用硬件上的分 布式文件系统。它与其它现有的文件系统有许多相似之处，但是其差 异才是 HDFS 的重要之处。HDFS 是被成运行在廉价硬件上并具有 高容错率的文件系统，它为应用程序数据提供了很高的吞吐量，适合 处理大量数据的应用程序。HDFS 放宽了一些 POSIX 规定的要求以适 合对文件系统数据的流访问。HDFS 最初是作为 Apache 的 Nutch 网站 搜索引擎项目的基础设施而建立的，现在成了 Apache 的 HDFS 项目。 这个项目的相关的连接为:http://hadoop.apache.org/hdfs/。 设想与目标 硬件差错 应该说硬件差错是正常现象而不是异常现象。一个 HDFS 实例是成百 上千个服务机构成的，其中每一个都存放部分的文件系统数据，由于 系统中有大量的组件，而每一个组件都会有不可忽视的出错概率，这 个事实意味着 HDFS 系统中总会有不能正常工作的。因此错误的检测 与快速自动恢复 HDFS 的核心构架目标。 流数据访问 运行在 HDFS 上的数据对它们的时间集有流访问权限，它们不是一般 地运行在普通目的的文件系统上一般应用程序。HDFS 是被设计用来 批处理而不是给用户交互式的使用的。因此这就要求强调 HDFS 必须 是高吞吐量的，而不是数据访问的低延迟。在 POSIX 里规定的许多硬 件需求对于以 HDFS 文件系统目标的应用程序来说是不必要的。因此 作为一种平衡式的交换，POSIX 中的一些关键领域里的要求被放弃了， 以便增加数据的吞吐率。 大数据集 在 HDFS 上运行的程序一般都有大量的数据集，在 HDFS 中一个典型 的文件有几个 GB 到几个 TB(1000GB)的大小，因此支持大文件。在一 个集群中，它应该提供很高的聚集数据的带宽并具有数千个节点。 简单的相关模型 HDFS 的程序要有对文件的一次写多次读的访问模型。一个文件一旦 创建，写入了数据并关闭了就无需更改，这种设想简化了数据的相关 问题并使得系统有很高的数据吞吐量。一个 MapReduce 应用程序或 网络搜索器程序与完全符合这种模式。有在未来可以支持对文件 进行增量写入。 “移动运算比移动数据更便宜” 程序所要求的运算在靠近数据的地方执行效率要高得多，特别是当数 据集很大的时候更是如此。这样可以把网络阻塞降到最低，并增加系 统总的吞吐量。所有尽量在离程序的数据最近的地方执行运算，而不 是要把数据传输到远端执行运算。HDFS 为程序提供了一个把程序移 到靠近数据的位置的接口。 跨越软硬件平台的便利性（可移植性） HDFS 已经被设计成了从一个平台到另一个平台易于移植的文件系统。 这促进了 HDFS 作为大量应用程序选择平台大规模地采用。 命名节点（NameNode）与数据节点(DataNodes) HDFS 采用了 master/slave 的架构。一个 HDFS 是由一个管理文件系统 命名空间和用户访问数据的服务节点(NameNode)和大量管理隶 属于本节点的数据存储的 DataNode（一般在集群中每个节点一个 DataNode）。HDFS 公开一个文件系统的命名空间，并允许用户数据存 储在文件里，就内部来说，一个文件被分成一个或多个块，这些块被 存储在多个DataNode里。NameNode执行文件系统命名操作如打开， 关闭文件和重命名文件和目录，它也决定块对 DataNode 的映射。 DataNode 负责对文件系统用户的读和写的请求提供服务。在 NameNode 的指令下 DataNode 也完成块的创建，删除和复制。 NameNode和DataNode都是以个个被设计运行在商用电脑上的软件， 这些电脑一般运行在 GNU/Linux 操作系统上。HDFS 是用 Java 写的， 任何支持 Java 的都可以运行 NameNode 和 DataNode 高移植性的 Java 语言的使用意味着 HDFS 可以大范围的机器上，一个典型的使用情况 是一个只运行 NameNode 的专用机器，集群里的其它机器运行 DataNode 软件实体，这种架构并不排除在相同的机器上运行多个 DataNode，但是在现实的使用中很少这样做。 集群中单个 NameNode 的情况极大简化了系统的架构，NameNode 是 所有 HDFS 元数据的调配者和存储地，这样设计的好处是用户数据流 永远不会经过 NameNode。 文件系统命名空间 HDFS 支持传统的层级文件组织架构，一个用户或一个应用程序可以 创建目录并存储文件在这些目录里。文件需要的命名空间架构类似于 大多数其他已有的文件系统，用户可以创建文件，也可以把文件从一 个目录移到另一个目录里，或对一个文件重新命名。HDFS 还没有对 用户数量进行限制，HDFS 也不支持硬链接或软连接，但是 HDFS 架构 并不排除实现的功能。 NameNode 维护着文件系统的命名空间，任何对文件系统的命名空间 或它的属性的改变都会被 NameNode 记录，一个程序可以规定一个文 件的拷贝份数，这应该是 HDFS 来维护的。一个文件的拷贝数目叫该 文件的复制因子，这些信息都被存储在 NameNode 里。 数据复制 HDFS 被设计成可靠地在一个集群中的多个机器上存储很多大文件， 它把每一个文件存储成一系列的块，在一个文件中，除了最后一个块 之外，所有块的大小都相同。一个文件的复制块是为容错性准备的。 块的大小和复制因子对每个文件来说都是可以配置的。一个程序可以 规定一个文件的备份数，复制因子可以在文件被创建的时候规定，此 后也可以更改。HDFS 中的文件是一次写入的，并规定在任何时候都 只能有一个写入。 NameNode 对块的复制作出所有的决定，它会周期性地接收到来自该 集群中的每一个 DataNode 的“心跳”和块报告。接收到来自一个 DataNode 的“心跳”就意味着该 DataNode 工作正常。块报告包括在 该 DataNode 的所有块的列表。 副本存放 被复制后的副本的存放对 HDFS 的可靠性和性能来说是至关重要的， 副本存放的优化使 HDFS 明显区别于其他大多数文件系统，这需要大 量的调试和经验。Rack-aware 副本存放策略的目的是提高数据的可靠 性，有效性和网络带宽的利用。目前的副本存放策略的实现是第一个 这一方向的努力。实现这个策略的短期目标是在生产系统上验证它， 以便更多地了解它的行为方式，并建立一个依据，再对更复杂的处理 进行研究。 大型 HDFS 的实例是运行在一个由散布在许多机架计算机集群上的。 处于不同机架上的两个节点之间的通信必须经过交换机。在大多数情 况下，相同机架的节点之间通信的网络带宽比不同机架上的节点之间 通信的网络带宽要宽。 NameNode 通过 Hadoop Rack Awareness 所描述的方式决定每一个 DataNode 的所属机架 ID，一个简单但非优化的策略是把副本在单一 的机架上，这样在整个机架出问题时可以防止数据丢失，同时也在读 数据的时候使用多个机架上带宽。这种策略平均地把副本分配在集群 中，以便在组件出问题的时候可以轻易地平衡负载。但是这种策略增 加了写的开销，因为写操作需要把一些块传到多个机架上。 对普通的情形而言，当复制因子是 3 的时候，HDFS 数据存储策略是 在本机架的一个节点上放置一个副本，另一个副本放置在一个远程机 架上，最后一个副本放在相同的远程机架上的另外一个节点上。这种 策略降低了写操作时候的机架之间通信，一般来说，这样可以提高写 操作的性能。机架的出错概率要远低于节点的出错概率，这种策略不 会影响数据的可靠性和有效性的保障。然而这样会降低读数据的时候 总的带宽，因为数据块是放在两个机架上而不是放在三个机架上的。 在这种策略中，一个文件的副本不会平均分布在各个机架上，副本的 三分之一在一个节点上，三分之二在一个机架上，另外三分之一平均 分布在其余的机架上。这种方式提高了写操作性能而又不降低数据的 可靠性或读操作性能。 这里描述的目前缺省的副本存储方式是一个正在推进的工作。 副本选择 为把总带宽消耗和读延迟将到最低，HDFS 试图满足最靠近读取者的 一个副本的读请求。如果在读取者节点所在的相同机架上存在一个副 本，那个副本就非常乐于满足这个读请求。如果 engg/HDFS 集群跨越 了多个数据中心，那么常驻在本地数据中心的那个副本就比任何远程 的副本更可能满足这个读请求。 安全模式 在 NameNode 启动的时候，它会进入一个被称作安全模式的特殊状态。 数据块的复制不是发生在 NameNode 工作在安全模式状态时。 NameNode 接收到来自 DataNode 的“心跳”和块报告消息，一个块 报告包括 DataNode 所管理的数据块的列表。每一个块都有一个规定 了的最小的副本数。当一个数据块的最小副本数在 NameNode 中核准 后就认为这个块被安全地复制了。一个可配置的安全复制数据块的百 分比在 NameNode 里被核准后（另需 30 秒），NameNode 就退出安全 模式状态，然后 NameNode 再判断是否还有其它的数据块的副本数比 规定的副本因子要小。NameNode 再接着会把这些块复制到其它 DataNode 上去。 文件系统元数据的连贯性 HDFS命名空间由NameNode存储，它使用一个叫做编辑记录（EidtLog） 交易记录来连贯地记录文件系统元数据的改变。例如，在 HDFS 里创 建一个新文件会导致 HDFS 向编辑记录（EidtLog）里插入一条记录来 表示这个操作。类似地，改变一个文件的复制因子也会导致一条新记 录插入到编辑记录（EditLog）里。NameNode 使用一个本地主机的文 件系统的文件来存储编辑记录（EditLog）。整个文件系统的命名空间， 包括块到文件的映射和文件系统的属性，都被存储在一个叫 FsImage 的文件中，FsImage 也是作为 NameNode 本地文件系统的一个文件被 存储的。 NameNode 把整个文件系统命名空间的 image 和文件的块映射放在内 存中，关键的元数据项被设计紧凑，这样一个 4G 内存 NameNode 足 够支持大量的文件和目录。当 NameNode 启动的时候，它就会从磁盘 里读取 FsImage 和 EditLog，并运用预先的约定来把 EditLog 与在内存 中的 FsImage 对应起来，把这个新的版本更新到处磁盘上。然后 NameNode 就能截取旧的 EditLog，因为它的约定已经被应用到了这个 连贯的 FsImage 里了。这个过程称为“关卡”。在当前的实现中关卡 只发生在 NameNode 启动时。正在推进的工作是在不久的将来支持周 期性地“关卡”检查。 DataNode 在本地文件系统里的文件中存储数据，它没有有关 HDFS 文 件的信息，它只是把 HDFS 数据的每个块存储在本地文件系统中一个 独立的文件里。DataNode 不会在相同的目录里创建所有的文件，它 是使用试探方式来判断每个目录中文件的最优数目，并适当创建子目 录，在相同的目录中创建所有的本地文件不是优化的，因为本地文件 系统可能不能在单个目录下有效地支持大量的文件。当 DataNode 启 动时，它会全盘扫描它的本地文件系统，并产生每一个本地文件对应 的所有 HDFS 数据块列表。然后把结果发到 NameNode 中，这就是块 报告。 通信协议 使用 HDFS 的通信协议都在 TCP/IP 顶部。一个客户端与 NameNode 机 器上的一个可配置的 TCP 端口建立一个连接，它用客户端协议与 NameNode 会话。DataNode 使用 DataNode 协议与 NameNode 会话。 远程过程调用(RPC)概念包含客户协议和 DataNode。NameNode 被设 计成永不发起任何远程过程调用，而只是对 DataNode 或客户端发出 的请求作出响应。 鲁棒性 HDFS 的最初目的是即使在出错的情况下保障数据存储的可靠性。有 三种错误类型：NameNode 错误，DataNode 错误和网络断开。 数据盘错误，心跳和复制 每个 DataNode 都会周期性地向 NameNode 发送心跳消息，网络断开 可能导致一部分 DataNode 失去与 NameNode 的连接，NameNode 通 过检查心跳消息的有无来检测这种情况 NameNode 把最近没有心跳 消息的 DataNode 标记为死亡，不再向它们发送任何新的 IO 请求消息 给它们。任何曾经在一个已经死亡的 DataNode 上注册了数据对 HDFS 来说都是无效的。DataNode 可能导致一些数据块的复制因子比规定 的低，NameNode 会经常跟踪需要被复制的块，并在任何必要的时候 复制它们。重新复制可能由许多原因引起，如 DataNode 可能变得无 效了，一个副本被腐蚀了，DataNode 硬盘出错了或一个文件的复制 因子增大了等待。 集群重新平衡 HDFS 的架构与那些数据重新平衡的是兼容的。当 DataNode 的可 用磁盘空间回落到了某个确定的门限值以下时，一个方案可以自动把 数据从一个 DataNode 移到另一个 DataNode。在某个特定文件发生突 发的高需求情况下，一个解决办法可以动态地创建额外的副本，并重 新平衡集群中的其它数据。这些数据重新平衡方案的类型目前还没有 实现。 数据的完整性 取自 DataNode 的一个数据块有可能在收到时已经被腐蚀了，这可能 是因为存储设备的问题，网络的问题或是软件的问题。HDFS 客户软 件会执行 checksum 来检查 HDFS 文件的内容。当一个客户创建一个 HDFS 文件时它会计算这个文件的每个块的 checksum，并且把这些 checksum的值存储在同一个HDFS 命名空间的一个单独的隐含文件中， 当客户端取得数据块时，他就会确认从每个 DataNode 收到的数据是 否与保存在相关 checksum 文件中的 checksum 值匹配，如果不匹配， 他就可以选择从其它有那个数据块的副本的 DataNode 获取那个数据 块。 元数据磁盘错误 FsImage 和 EditLog 是 HDFS 的中心数据结构，这些文件受损可能会导 致 HDFS 实体不能正常工作。因此，NameNode 可以配置成支持能维 护多个 FsImage 和 EditLog。任何对 FsImage 或 EditLog 的更新都会导 致每个 FsImage 和 EditLog 同步更新。FsImage 和 EditLog 的多拷贝同 步更新会降低 NameNode 支持的每秒命名空间的传输速率。然而，这 种速率的下降是可以接受的，因为即使 HDFS 应用程序在本质上是以 数据以数据为核心的，但是它们不是以元数据为核心的。当一个 NameNode 启动时，它选择使用最新的相互一致的 FsImage 和 EditLog。 对一个 HDFS 集群来说，对于出错事件而言，NameNode 机器是一个 孤立的点，所以如果 NameNode 机器出错，人工干预是必要的。目前 NameNode 的自动重启和发生错误时 HDFS 自动恢复到另一个 HDFS 机器上的功能还不支持。 快照 快照功能支持在特殊时刻一个数据备份。快照功能的一个用途可以是 把一个已经被腐蚀了的 HDFS 实体退回到 HDFS 自身一个已知状态良 好的时间点时的状态。目前 HDFS 还不支持快照功能，但是在将来的 某个版本中会支持。 数据组织 HDFS被设计成很大的文件与HDFS兼容的程序是那些处理大数据集的 程序。这些程序之做一次写入操作但读取一次或多次，并且读取操作 要求满足流速率。HDFS 支持文件上的“以写多读”的语义。HDFS 使 用的数据块的典型大小是 64MB。因此一个 HDFS 文件被切割成 64MB 的块，而且可能的话，让每个块都存储在不同的 DataNode 上。 阶段 一个客户创建一个文件的请求并不能立即被 NameNode 收到。事实上， 最初时，HDFS 客户端会把文件的数据缓冲到临时的本地文件中，程 序的写操作是被透明地重新导向这个本地文件，当这个本地的临时文 件累积的数据超过一个数据块时，客户端才和 NameNode 联系， NameNode 会把这个文件名插入到文件系统的层次架构中，并为它分 配一个数据块。NameNode 会响应客户端包含 NameNode 的 ID 和目 标数据块 ID 的请求，然后客户端才会把这个数据块从本地的临时文 件刷新到指定的 DataNode 中。当一个文件关闭的时候，那些在本地 临时文件中没有被刷新的数据会被传输到 DataNode 中去，然后客户 端告诉 NameNode 这个文件要关闭了，到这个时候，NameNode 才把 文件创建的操作递交到连贯存储中去。如果在文件关闭之前 NameNode 死了，那么文件就会丢失。 在仔细考虑了运行在 HDFS 上的目标程序之后，上述方式已经被采纳。 这些程序需要对文件进行流写入，如果一个客户端没有任何客户端的 缓冲而直接把数据写入一个远程文件中网络的速度和网络阻塞就会 大大影响吞吐量，这是不允许的。早期的分布式文件系统如 AFS 就使 用了客户是缓冲来提高数据上载的性能。 复制管线 像前面所描述的那样，当一个客户端向一个 HDFS 文件写入数据是， 它的数据首先写到一个本地文件中。假设 HDFS 的复制因子为 3。当 用户数据在本地文件上累积有一个满的数据块是，客户端会从 NameNode 收到一个 DataNode 的列表，这个列表中包括那个数据块 的副本将要驻留的 DataNode。然后客户端把那个数据块刷新到第一 个 DataNode，第一个 DataNode 开始每次 4KB 地接收那个数据块，把 每个部分（portion，为 4KB）写入它的本地库中，并传输这个 4KB 的 数据到表中的第二个 DataNode 中，第二个 DataNode 因此会开始接 收这个数据块，每次接收 4KB 的数据，并把每个部分（portion，为 4KB）写入它的本地库中，再刷新这个 4KB 数据到列表中的第三个 DataNode中，最后第三个DataNode也把这些数据写到它的本地库中。 因此一个 DataNode 可以在管线中从前一个 DataNode 接收数据，同 时在管线中把数据向下一个 DataNode 转发。数据是通过管线从一个 DataNode 到下一个 DataNode。 可访问性 HDFS 可以用许多不同的方式被程序访问。HDFS 本来就为程序使用 HDFS 提供了一个 Java API。为这个 Java API 的 C 语言包也是可用的。 另外，HTTP 浏览器也能用来浏览 HDFS 实体的文件。通过 WebDAV 协议的相关工作也在推进中。 FS Shell HDFS 允许用户以文件和目录的方式组织在一起，它提供了称作 FS shell 的命令行接口，这个接口允许用户与 HDFS 里的数据交互，它的 命令集的语法与用户已经熟知的其它 shell（如 bash，csh）类似。下 面有一些 action/command 对的例子： Action Command Create a directory named /foodir Bin/hadoop dfs –mkdir /foodir Remove a directory named /foodir Bin/hadoop dfs –rmr /foodir View the contents of a file named /foodir/myfile.txt Bin/hadoop dfs –cat /foodir/myfile.txt FS shell 是为那些需要与所存储的数据进行交互的脚本语言的程序所 设计的。 DFSAdmin DFSAdmin 命令集用来管理 HDFS 集群的，只有 HDFS 才能使用这些命 令。下面是 action/command 对的例子： Action Command Put the cluster in Safemode Bin/hadoop dfsadmin –safemode enter Generate a list of DataNodes Bin/hadoop dfsamin -report Recommission or decommission DataNode(s) Bin/hadoop dfsadmin -refreshNodes 浏览器接口 一个典型 HDFS 安装一般都通过配置一个 TCP 端口配置了一个网络服 务器，用于开启 HDFS 的命名空间。这样的话，就允许用户查阅 HDFS 的命名空间，并通过网络浏览器视图查看它的文件的内容。 空间开拓 文件的删除与撤销删除 当一个文件被用户或程序删除后，它不会立即从 HDFS 中移除，而是 首先被 HDFS 重新命名到目录/trash 下的一个文件中。 只要这个文件还在/trash 中，它就可以被快速恢复。一个文件可以保 存在/trash 里一段时间，而这个时间的长度是可以配置的。在/trash 里的文件过了它的生命的有效期后会被 NameNode 从命名空间中删 除。一个文件的删除与这个文件相关的块被释放。注意：在文件被用 户删除到释放相应的 HDFS 磁盘空间之间有一段很长的时间延迟。 在用户删除一个文件之后，只要这个文件还在/trash 目录中，用户就 可以撤销删除。如果用户想要撤销删除，他/她就可以在/trash 中找到 它，并取回这个文件。目录/trash 只包含被删除的文件的最新的拷贝。 这个目录和其它目录一样，只是有一个特殊的功能：HDFS 会使用规 定的方式自动从这个目录中删除文件。当前的缺省方式是删除在中国 目录中存在超过 6 个小时的文件。将来这种策略会通过一个定义良好 的接口可以配置。 降低复制因子 当一个文件复制因子被降低时，NameNode 就会选出可以被删除的过 剩的副本，在下一次心跳中就会把这个信息传给 DataNode，然后 DataNode 就会删除相应的数据块，并释放相应的磁盘空间。再次强 调，在 setReplication API 调用到集群中的释放成自由磁盘空间之间可 能有延迟。