HDFS知识点整理
优缺点
优点
-
高容错性：多副本，自动恢复
-
处理的数据规模大：可处理PB级别的文件，可支持百万级数量的文件
缺点
- 不适合低延迟的数据访问
- 无法高效存储小文件
- 文件元数据过多，耗尽NameNode内存
- 小文件寻址超过文件读取时间，违背HDFS设计初衷
- 不支持并发文件写入
- 仅支持数据追加，不支持文件随机写
组成架构
NameNode
文件系统的管理者：
- 管理HDFS命名空间
- 配置副本策略
- 维护数据块映射
- 处理客户端读写请求（控制流）
DataNode
数据存储节点：
- 存储数据块
- 执行数据块读写（数据流）
Client
客户端：
- 通过API或shell执行命令
- 按数据块大小切分文件
Secondary NameNode
- 并非NameNode热备份，当NameNode宕机，不能马上替代NameNode对外提供服务
- 分担NameNode一部分工作，例如Edits和FsImage操作
- 当NameNode宕机时辅助NameNode恢复
HDFS数据块大小
- Hadoop2中默认的数据块（
dfs.blocksize）大小为128M：取决于磁盘传输速率 - 原则：寻址时间为传输时间的1%, HDFS中寻址时间平均为10ms, 因此比较好的传输时间为1s
- 磁盘的传输速率普遍为100MB/s，决定了一个HDFS数据块的大小在100MB左右
- HDFS数据块太小，元数据增加，寻址时间增加
- HDFS数据块太大，MapReduce任务的一个map处理的数据过多，处理时间过长，不符合MapReduce设计原则
HDFS读写数据
写数据流程
流程图来自《Hadoop权威指南_第四版》，几个注意点：
- 在一个副本（该数量由
dfs.namenode.replication.min设定）写入成功后，写操作就会返回成功 - 客户端会根据NameNode的返回信息，向网络拓扑上最近的DataNode写入，副本的写入由DataNode按照最短路原则接力写入，即DataNode1调用DataNode2，DataNode2调用DataNode3
- 如果需要写入多个block，写入一个block完成之后，Client会向NameNode请求下一个block的地址
- 一个block分成固定大小的package（默认64k）传输
网络拓扑的节点距离
节点距离：在网络拓扑树上，两个节点到最近的公共祖先的距离和
- 同一节点上的不同进程距离为0
- 同一机架的不同节点距离为2
- 同一数据中心的不同机架距离为4
- 不同数据中心的距离为6
副本存储策略
详见官方文档（以Hadoop2.7.2版本为例）
- 当副本数为3时，在Client所在的本地机架放置一个副本（如果Client不在HDFS集群的机器上，则随机选一个集群节点），在本地机架的另一个节点放置一个副本，在不同机架放置一个副本
- IO效率和可用性之间的平衡
读数据流程
流程图来自《Hadoop权威指南_第四版》，注意：对于需要读取的每一个block，总是读距离最近的DataNode
NameNode与Secondary NameNode
- NameNode元数据存储在内存中（为了提高效率）
- 元数据的磁盘备份：FsImage，保障NameNode元数据断电后可恢复
- 更新内存元数据的同时，如果更新FsImage，仍然是低效的
- 磁盘上的Edits文件，类似于元数据更新日志，记录元数据的修改
- FsImage和Edits合并可以得到此刻内存元数据一致的结果
- 如果Edits过长，从FsImage和Edits恢复元数据的时间过长，因此需要定期合并Edits更新FsImage，该操作由Secondary NameNode完成
- 定时时间（默认1小时）到或Edits中数据满（默认100万），则Secondary NameNode向NameNode请求执行Checkpoint，NameNode备份当前Edits（之后的Client请求全部写入新的Edits），将FsImage和老的Edits文件发给Secondary NameNode，Secondary NameNode在内存中对FsImage和Edits进行合并，生成新的FsImage，发送给NameNode替换老的FsImage
DataNode
数据完整性
- 当DataNode读取Block时，会计算CheckSum
- 如果计算的CheckSum与Block创建时值不一样，说明Block已损坏
- Client会读取其他DataNode上该Block的副本