HDFS 架构官文理解

HDFS 使命

实现硬件级别的容错
提供数据流方式的访问文件
提供超大数据量的存储，GB、TB、PB，这其中还包含了访问速度的要求。
实现简单的一致性，为了保证整个集群里面不同副本之间的数据是一致的，所以
HDFS 只之支持了文件简单的文件接口，包括文件的打开、关闭、读、写、附加、删除。
对应的操作英文为 create、close、read、write、append、truncate
移动计算程序比移动数据的开销更小下面是官网的原文：

HDFS applications need a write-once-read-many access model for files.
A file once created, written, and closed need not be changed except for appends and truncates.
Appending the content to the end of the files is supported but cannot be updated at arbitrary point.
This assumption simplifies data coherency issues and enables high throughput data access. A MapReduce application or a web crawler application fits perfectly with this model.

我来试着翻译一下：

基于 HDFS 的应用程序对文件访问的需求场景是这样的，一次写多次读。
在这种场景中，一个文件一旦在文件系统里面创建、写入内容、关闭后，那么这个文件
除了附加、删除操作之外，不会被修改了。
这种文件系统支持将内容附加到文件的末尾，但是不支持随机修改文件中的内容。
这种设计弱化了数据一致性的带来的挑战，确保了文件访问的高吞吐量。这种文件访问
模式完美的满足了 MR 应用或者网络爬虫的需求。

可移植性，我觉得这种可移植性是基于 java 的可移植性。由于 HDFS 是使用 Java 实现的，所以 HDFS 继承了 Java 在可移植性方面的基因。

NameNode 和 DataNode

NameNode 好像是一个大公司的财务，财务的职责就是记录一切和钱相关的事件。同样的
NameNode 不存储数据，而是存储数据的数据，也就是记录元数据（metadata）。元数据
包括如下：
- 一个文件中有多少块
- 一个文件相关的块的位置
- DataNode 的状态，这里涉及到 Heartbeat and Blockreport
  - 每隔一段时间，DataNode 会主动发送一次心跳，一次心跳主要发送 Blockreport
  - Blockreort 包含了每个块对应的文件，副本的数量，以及副本号等。

元数据的保存到硬盘的规则

Editlog
- 类似 MySQL 的 binlog ,会将每次 create、write、append、truncate 操作记录下来
- 这是 transaction log 事务性的 log
- 根据实际查看 editlog 所在的目录是 配置文件中的文件路径/dfs
fsImage
- the mapping of blocks to files and file system properties.这是保存文件系统的块信息对应
  关系的
- 根据实际查看 fsImage 所在的目录是 配置文件中的文件路径/namenode

协议

HDFS 的客户端通过 ClientProtocol 和 NameNode 进行通信
NameNode 和 DataNode 直接通过 DataNode Protocol 进行通信
NameNode 从不主动发起一次 RPCs 通话，只接受客户端和 DataNode 的请求并且返回信息

HDFS block 副本（replicas）部署方式

一般文件的每个块的副本数量为 3 个，这三个是按照下面的规则进行存储的

在一个举例上传客户端最近的 dataNode 服务器中存储一份副本
然后在同一个机架上的另外一台 DataNode 上存储一份副本
最后，在不同机架上的一个 DataNode 上存储一份副本

健壮性

健壮性面临了三种大的挑战：

NameNode 故障
DataNode 故障
网络故障

对应这三种挑战，HDFS 下面几种机制进行了应对

HeartBeats and Re-replication

为了防止备份风暴，DataNode 链接超时的时间一般为 10 分钟以上，文档上只是提了一下备份风暴（replication storm）是由于 DataNode 的状态震动造成的，从字面上可以理解为 DataNode 状态频繁的变懂，导致了
NameNode 要经常的处理重备份的请求，这就类似网站的恶意攻击了。忘记说重点了，DataNode 会周期性向
NameNode 发送心跳信息，如果没有按时收到，NameNode 会任务那个 DataNode 出现了故障，处于不可用的状态，
此时 NameNode 会发起一次重备份的操作，将故障的 DataNode 的上的 block 进行复制。

集群的负载均衡

当一个 DataNode 的可用空间低于某个临界值的时候，HDFS 的负载均衡计划自动的将数据从一个 DataNode 上
复制到另外一个 DataNode 上去，可惜的是 2.8.2 版本中的文档中说，这个屌屌的功能还没试实现，敬请期待。

Data integrity()数据的完整性

HDFS 使用的是 checksum 的方法进行完整性的检查，在 NameNode 的 namespace 中会保留一份文件的 checksum 的值，当从 DataNode 上读取数据后，会教研 checksum 值。

快照

快照机制可以保存运行时的数据实例，可以回滚到这个点上。

数据的管理

数据块

一个文件在 HDFS 可能会切分成一个块文件，一个块文件一般是 128 M，也可以调低，各个 block 有多个副本，
每个块的副本可以分散到不同的 DataNode 中。

备份管道

客户端上出文件块的时候，先传给一个最进的 DataNode 上，然后第一 DataNode 再把多余的块传到下一个
DataNode 上，以此类推。所以客户端到 DataNode 的数据上传是一种链式的，不是从客户端到 DataNode 的
辐射状的。

可达性

HDFS 支持多种 API ，有 java API 、C 语言接口、REST API、使用 HTTP 浏览器、将 HDFS 挂在到 NFS 文件
中。另外还有 shell 命令，其中，我觉得比较新鲜的是 DFSAdmin 命令。可以看看。

存储空间的再利用

当使用 shell 删除文件后，文件不会立即删除，而是放到删除目录里面，NameNode 会周期性的检查删除目录
里面的文件，并且设置成一个检查点，文档上说，检查点过期后，会将其删除的，没有讲清楚检查点删除的
规则，但达到一个过期值的时候，会将清空文件在 NameNode 中的 namespace 的元数据，这样文件在 DataNode
中所占的空间会彻底释放。

HDFS 读写的过程

读

首先，HDFS 的客户端想 namenode 发送读数据的请求，namenode 收到请求以后，
会将请求文件的位置，即在文件块所在主机的 IP等等信息返回给客户端，