HDFS系统架构和设计要点.docxVIP

Hadoop 分布式文件系统架构和设计要点 一、前提和设计目标 硬件错误是常态，而非异常情况，HDFS 可能是有成百上千的 server 组成，任何一个组件都有可能 一直失效，因此错误检测和快速、自动的恢复是 HDFS 的核心架构目标。 跑在 HDFS 上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理；比之关注数据访 问的低延迟问题，更关键的在于数据访问的高吞吐量。 HDFS 以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至 T 字节，一个单一 HDFS 实例应该能支撑数以千万计的文件。 HDFS 应用对文件要求的是 write-one-read-many 访问模型。一个文件经过创建、写，关闭之后就 不需要改变。这一假设简化了数据一致性问题，使高吞吐量的数据访问成为可能。典型的如 MapReduce 框架，或者一个 web crawler 应用都很适合这个模型。 移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这 在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好， HDFS 提供给应用这样的接口。 在异构的软硬件平台间的可移植性。 二、Namenode 和 Datanode HDFS 采用 master/slave 架构。一个 HDFS 集群是有一个 Namenode 和一定数目的 Datanode 组成。 Namenode 是一个中心服务器，负责管理文件系统的 namespace 和客户端对文件的访问。Datanode 在集 群中一般是一个节点一个，负责管理节点上它们附带的存储。在内部，一个文件其实分成一个或多个 block，这些 block 存储在 Datanode 集合里。Namenode 执行文件系统的 namespace 操作，例如打开、 关闭、重命名文件和目录，同时决定 block 到具体 Datanode 节点的映射。Datanode 在 Namenode 的指 挥下进行 block 的创建、删除和复制。Namenode 和 Datanode 都是设计成可以跑在普通的廉价的运行 linux 的机器上。HDFS 采用 java 语言开发，因此可以部署在很大范围的机器上。一个典型的部署场景 是一台机器跑一个单独的 Namenode 节点，集群中的其他机器各跑一个 Datanode 实例。这个架构并不 排除一台机器上跑多个 Datanode，不过这比较少见。 单一节点的 Namenode 大大简化了系统的架构。Namenode 负责保管和管理所有的 HDFS 元数据，因而用 户数据就不需要通过 Namenode（也就是说文件数据的读写是直接在 Datanode 上）。 三、文件系统的 namespace HDFS 支持传统的层次型文件组织，与大多数其他文件系统类似，用户可以创建目录，并在其间创建、 删除、移动和重命名文件。HDFS 不支持 user quotas 和访问权限，也不支持链接（link)，不过当前的 架构并不排除实现这些特性。Namenode 维护文件系统的 namespace，任何对文件系统 namespace 和文 件属性的修改都将被 Namenode 记录下来。应用可以设置 HDFS 保存的文件的副本数目，文件副本的数 目称为文件的 replication 因子，这个信息也是由 Namenode 保存。 四、数据复制 HDFS 被设计成在一个大集群中可以跨机器地可靠地存储海量的文件。它将每个文件存储成 block 序列，除了最后一个 block，所有的 block 都是同样的大小。文件的所有 block 为了容错都会被复制。 每个文件的 block 大小和 replication 因子都是可配置的。Replication 因子可以在文件创建的时候配 置，以后也可以改变。HDFS 中的文件是 write-one，并且严格要求在任何时候只有一个 writer。Namenode 全权管理 block 的复制，它周期性地从集群中的每个 Datanode 接收心跳包和一个 Blockreport。心跳包的接收表示该 Datanode 节点正常工作，而 Blockreport 包括了该 Datanode 上所 有的 block 组成的列表。 1、副本的存放，副本的存放是 HDFS 可靠性和性能的关键。HDFS 采用一种称为 rack-aware 的策略来改 进数据的可靠性、有效性和网络带宽的利用。这个策略实现的短期目标是验证在生产环境下的表现， 观察它的行为，构建测试和研究的基础，以便实现更先进的策略。庞大的 HDFS 实例一般运行在多个机 架的计算机形成的集群上，不同机架间的两台机器的通讯需要通过交换机，