HDFS知识点整理
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的副本