HDFS严格遵循了由谷歌的GFS奠定的架构路线，延续了它的三层，单管理服务器模型。每个Hadoop集群有一个叫做“名字节点”的管理服务器， 它来追踪关于位置和每个64M存储“块”副本的状态的元数据。数据通过集群中的“数据节点”复制——从属系统处理数据的读写。默认情况下每个块都会被复制 三次，而且复制的次数还可以通过改变集群设置来增加。

像GFS一样，HDFS让管理服务器尽可能快地避开读写循环，避免产生性能瓶颈。当从HDFS上访问数据的请求产生时，名字节点发回与这个请求最近 的数据节点上的块的位置信息。名字节点还可以通过一个“心跳”协议追踪每个数据节点的健康度并停止向不响应的数据节点发送请求，把它们标记为“死的”。

在切换后，名字节点就不处理任何更进一步的交互。对数据节点上数据的编辑被报告回名字节点并记录在日志里，之后用变动的数据副本对其他数据节点进行 复制。同GFS一样，这导致了一致性上相应的懒散形式，而且虽然名字节点将为最近修改的数据块发送新的请求，正在进行的工作仍然会碰到它们被分配到的数据 节点上的陈旧数据。

那不应该是经常发生的，然而，因为HDFS数据应该被“写入一次”——变动通常是扩充数据，而不是改动现有数据，为了更简单的一致性。而且由于Hadoop应用的性质，数据往往会大批量地写入HDFS。

当一个客户端发送要写入HDFS的数据时，它首先被客户端程序安置在一个临时的本地文件中，直到写入的数据达到了数据块的大小——默认64MB。之 后客户端联系名字节点并获得一个数据节点和要写入数据的块位置。这一过程对每个块的数据重复进行，一次一个块。这减少了产生网络阻塞的数量，但也减慢了写 入过程。但是HDFS是用于读取的，而不是写入。

HDFS可以减少网络写入流量的另一个办法是在于它处理复制的方式。通过激活一个叫做“机架感知”的HDFS特性来管理分布的副本，管理员可以为每 个节点指定一个机架序号，通过网络配置脚本中的一个变量指定它的物理位置。默认情况下，所有的节点都在同一个“机架”中。但是当机架感知被配置以 后，HDFS把每个块上的一个副本放置于同一个数据中心机架的另一个节点上，另一个则在不同的机架上，来减少网络中数据写入量——基于如下理由，就是一整 个机架出错的几率比一个单一节点出错的几率要小。理论上，它整体改善了HDFS的写入性能而没有牺牲掉可靠性。

与GFS早期版本一样，对于一个要成为高度可用的分布式系统，HDFS的名字节点创建一个单一的故障点。如果名字节点中的元数据丢失了，整个 HDFS环境就变成不可读了——就像一个缺少了文件分配表的硬盘。HDFS支持使用“备份节点”，它能与内存中的名字节点的元数据保持版本同步，并储存前 一系统状态的快照，以便能够在需要时回滚。快照也可以被分开储存在叫做“检查节点”的地方。然而，根据HDFS的文档，目前还不支持自动重启一个破坏的名 字节点，而且备份节点不会自动移除和替代管理服务器。

HDFS和GFS都是用搜索引擎式任务的思想而开发的。但是对于面向更多通用计算类型的云服务，“写入一次”的方法和其他妥协办法使得大数据查询性能不尽理想——这就是为什么亚马逊开发了自己的分布式存储平台，叫做Dynamo。

相关阅读： 云端磁盘：网络巨头如何存储数据（下）