一、HDFS体系结构
1 HDFS假设条件
数据流访问
大数据集
简单相关模型
移动计算比移动数据便宜
多种软硬件平台中的可移植性
2 HDFS的设计目标
非常巨大的分布式文件系统
运行于普通硬件上
优化批处理
用户控件可以位于异构的操作系统中
在整个集群中使用单一的命名空间
数据一致性
文件被分为各个小块
智能客户端
程序采用“数据就近”原则分配节点执行
客户端对文件没有缓存机制
3 HDFS 架构
1 HDFS架构-文件
文件被切分为块（默认大小64M），以块为单位，每个块有多个副本存储在不同的机器上，副本数可在文件生成时指定（默认3）。
NameNode是主节点，存储文件的元数据如文件名，文件目录结构，文件属性（生成时间，副本数，文件权限），以及每个文件的块列表以及块所在的DataNode等等。
DataNode在本地文件系统存储文件块数据，以及块数据校验和。
可以创建、删除、移动或重命名文件，当文件创建、写入和关闭之后不能修改文件内容。
2 HDFS文件权限
与 linux文件权限类似。
r:read;w:write;x:execute，权限x对于文件忽略，对于文件夹表示是否允许访问其内容。
如果linux系统用户zhangsan使用hadoop命令创建了一个文件，那么这个文件在HDFS中owner就是zhangsan。
HDFS权限目的：阻止好人做错事，而不是阻止坏人做坏事。HDFS相信，你告诉我你是谁，我就认为你是谁。
3 HDFS架构-组件功能
| NameNode | DataNode |
| 存储元数据 | 存储文件内容 |
| 元数据保存在内存中 | 文件内容保存在磁盘中 |
| 保存文件、block、DataNode之间的映射关系 | 维护了blockId到DataNode本地文件的映射关系 |
NameNode：
是一个中心服务器，单一节点（简化系统的设计和实现），负责管理文件系统的名字空间（namespace）以及客户端对文件的访问。
文件操作，NameNode负责文件元数据的操作，DataNode负责处理文件内容的读写请求，跟文件内容相关的数据流不经过NameNode，只会询问跟哪个DataNode的联系，否则NameNode会成为系统瓶颈。
副本存放在哪些DataNode上由NameNode来控制，根据全局情况作出块放置决定，读取文件时NameNode尽量让用户先读取最近的副本，降低带宽消耗和读取延时。
NameNode全权管理数据块的复制，它周期性地从集群中的每一个DataNode接收心跳信号和块状态报告（BlockReport）。接收到心跳信号意味着该DataNode节点工作正常。块状态报告包含了一个该DataNode上所有数据块的列表。
DataNode：
一个数据块在DataNode以文件存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据包括数据块的长度，块数据的校验和，以及时间戳。
DataNode启动后向NameNode注册，通过后，周期性（1小时）地向NameNode上报所有的块信息。
心跳是每3秒一次，心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器，或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳，则认为该节点不可用。
集群运行中可以安全加入和退出一些机器。
4 HDFS副本放置策略
| hadoop 0.17之前 | hadoop 0.17之后 |
| 副本1：同机架的不同节点 | 副本1：同Client的节点上 |
| 副本2：同机架的另一个节点 | 副本2：不同机架中的节点上 |
| 副本3：不同机架的另一个节点 | 副本3：同第二个副本的机架中的另一个节点 |
| 其他副本：随机挑选 | 其他副本：随机挑选 |
5 HDFS数据损坏（corruption）处理
当DataNode读取block的时候，它会计算checksum。
如果计算后的checksum与block创建时值不一样，说明该block已经损坏。
Client读取其他DN上的block。
NameData标记该块已经损坏，然后复制block达到预期设置的文件备份数。
DataNode在其文件创建后三周验证其checksum。
6 HDFS架构-Client&SNN
| Client | Secondary NameNode |
|
文件切分 与NameNode交互，获取文件位置信息 与DataNode交互，读取或写入数据 管理HDFS 访问HDFS |
并非NameNode的热备 辅助NameNode，分担其工作量 定期合并fsimage和fsedits，推送给NameNode 在紧急情况下，可辅助恢复NameNode |
7 HDFS架构-NN&SNN
NameNode两个重要的文件：
fsimage：元数据镜像文件（保存文件系统的目录树）
edits：元数据操作日志（针对目录树的修改操作）
元数据镜像：
内存中保存一份最新的
内存中的镜像=fsimage+edits
定期合并fsimage和edits：
edits文件过大导致NameNode重启速度慢
Secondary NameNode负责定期合并他们
NameNode启动过程与fsimag和edits的变化：
执行过程：
Secondary NN通知NN切换editlog -->
Secondary NN从NN获得fsimage和editlog（通过http方式）-->
Secondary NN将fsimage载入内存，然后开始合并editlog -->
Secondary NN将新的fsimage发回给NN -->
NN用新的fsimage替换旧的fsimage