Hadoop分布式文件系统：架构和设计要点.pdfVIP

Hadoop 分布式文件系统：架构和设计要点 目录 Hadoop 分布式文件系统：架构和设计要点1 一、前提和设计目标1 二、Namenode 和Datanode2 三、文件系统的namespace 3 四、数据复制3 五、文件系统元数据的持久化5 六、通讯协议6 七、健壮性6 八、数据组织7 九、可访问性8 一、前提和设计目标 1、硬件错误是常态，而非异常情况，HDFS 可能是有成百上千的server 组成，任何 一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是HDFS 的核心架构目标。 2、跑在HDFS 上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理； 比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。 3、HDFS 以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至 T 字节，一个单一HDFS 实例应该能支撑数以千万计的文件。 4、 HDFS 应用对文件要求的是write-one-read-many 访问模型。一个文件经过创 建、写，关闭之后就不需要改变。这一假设简化了数据一致性问题，使高吞吐量的数据访问 成为可能。典型的如MapReduce 框架，或者一个web crawler 应用都很适合这个模型。 5、移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越 近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据 移动到应用所在显然更好，HDFS 提供给应用这样的接口。 6、在异构的软硬件平台间的可移植性。 二、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 包括了该D