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

Hadoop 分布式文件系统架构和设计要点 一、前提和设计目标 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 。 Namenod