HDFS总结
思维导图请看博客:HDFS思维导图
HDFS
HDFS存储管理
各个角色及作用
NameNode
- 接收客户端的读写请求
- 管理元数据
- 上传文件的权限
- 上传文件的属主以及属组
- 上传文件的时间
- 上传文件的block数以及ID号
- 每个block的位置信息 是由DN在集群启动时汇报的 不会持久化
- 各个位置的DN位置
- 管理DataNode
DataNode
- 接收客户端的读请求
- 存储block块
- 向active NN汇报心跳信息
- 构建管道pipeline
- 管理本机上block元数据
SecondaryNameNode
- 负责持久化
- 拉取NN节点上的edits+fsimage文件合并
- edits文件存储客户端对HDFS的操作
- 使用edits来存储操作是怕某个NN挂掉
- 合并过程
- 文件拉取之时,在NN节点创建edits_new 目的为了存储在合并期间产生的操作
- 基于拉来的edits文件重演 产出了元数据
- 将重演产出的元数据合并到fsimage中
- 将合并后fsimage推送给NN
- 将edits.new文件的后缀去掉
- 合并触发机制
- 超过3600s合并一次
- edits文件大小超过64M
- 拉取NN节点上的edits+fsimage文件合并
ZKFC
- 监控各自的NN,将监控的情况汇报给ZooKeeper集群
- 接收zk的选举结果,确认一下另外一个NN是否真的挂了,将自己监控的NN提升为active状态
journalNode
- 写数据的时候只需要保证半数以上的节点写入成功就可以了
- 防止出现脑裂问题 也成为网络分区问题
- 最终一致性/弱一致性
- 存储的是edits文件
备用的NN(standby)
- 监控journalnode中数据变化,实时更新自己的内存元数据
- 将内存中元数据持久化到fsimage中,然后推送给NN
备份机制
集群外操作
- 第一个block存储在负载不高的节点上
- 第二个存储在相邻的机架的节点上
- 第三个存储在第二个机架的另一随机节点上
集群内操作
- 第一个block存储在本机
- 第二个 第三个同集群外操作
HDFS读写流程
读流程
- 从NN中获取block块的Id和相对于的DN地址
- 通过以上信息去相对于的DN中读取数据
写流程
- 计算文件的block数量 文件大小/block大小128MB
- client向namenode汇报
- 当前大文件的block数量
- 当前大文件属主 属组
- 当前大文件 权限
- 上传时间
- client切割出来一个block
- 请求block的id以及存放block的地址
- 由于NN掌控全局,管理所有的DN,所以他将负载不高的DN地址返回的client
- client拿到地址后,找到DN 去上传数据
- 从NN得到了block信息 包括ID等
- 通过id查询到该把这些block存储到哪些datanode中
- 再把block切割成一个个packet 64k
- 并在客户端和DN间建立了管道,源源不断的传输packet
- 使用管道 与 切割成packet的理由:并行存储 增加效率
- DN将block存储完毕后,会向NN汇报当前的存储情况
搭建集群的三种模式
- 伪分布式
- 完全分布式
- 高可用的完全分布式
HDFS优缺点
优点
- 副本机制,数据更安全
- 分布式的,所以适合批处理
- 高可用性
- 元数据持久化
- 禁掉了一些功能,使得集群更加完美
- 不能修改文件
- 文件上传成功后,不能修改block大小
缺点
- 无法毫秒级的读写数据
- 读写复杂 需要找nn请求
- 形成管道 文件切割block 形成packet
- 不适合存储大量的小文件
- 容易造成元数据,NN内存溢出
- 解决的办法
- 小文件合成大文件
- 联邦机制
- 不能并发写入,但可以并发的读