HDFS
Hadoop-HDFS
1、存储模型:字节
- 文件线性切割成块(Block),偏移量(假设100bytes切割成10块,偏移量为0,10,20…,作用就是知道数据在哪里,方便管理)
- Block分散存储在集群节点中
- 单一文件Block大小一致,文件与文件之间可以不一致
- Block可以设置副本,副本无序分散在不同节点上,且副本数不能超过节点数量。(设置副本是为了保证在一台服务器出现问题时,其他服务器还能继续工作,不超过节点数量是因为没有意义)
- 文件上传可以设置Block大小和副本数
- 已上传的文件Block副本数可以调整,大小不变(因为如果大小变了,那么偏移量就要变,所有的索引都要变,工作量很大)
- 只支持一次写入多次读取,同一时刻只有一个写入者
- 可以append追加数据,在末尾添加
2、架构模型
- 文件元数据MetaData:元数据保存的不是数据本身,而是数据的信息,比如数据的大小,数据的偏移量等
- (主节点)NaneNode节点保存文件元数据:单节点(单个服务器存储)
- (从节点)DataNode节点保存文件Block数据:多节点
- DataNode与NameNode保持心跳,NameNode提交Block列表(当DataNode里面的数据发生变化时,应该主动向NameNode提交Block列表信息,NameNode可以及时更新信息)
- HdfsClient与NameNode交互元数据信息(HdfsClient只与NameNode一次交互,因为Client拿到元数据之后就不需要再访问NameNode了,直接去与DataNode交互就可以了)
- HdfsClient与DataNode交互文件Block数据
- DataNode利用服务器本地文件系统存储数据块(分发给DataNode的数据都是存储在服务器本地的)
总结:NameNode相当于图书馆管理员,HdfsClient只要去NameNode拿到图书信息,就可以去找到想要的DataNode里面的数据了。NameNode要与DataNode保持联系,DataNode数据发生变化需要向NameNode回报。
3、NameNode(NN)
— 基于内存存储
- 只存在内存中
- 持久化(NameNode只存在内存中会出现一个问题,那就是内存会满或者断电,所以需要定期持久化操作,将数据存入磁盘中,这是单向的)
— NameNode主要功能
- 接受客户端的读写操作
- 收集DateNode汇报的Block列表信息
— NameNode保存metadata信息包括
- 文件ownership和permissions
- 文件大小,时间
- Block列表:Block偏移量,位置信息(持久化不存)
- Block每个副本的位置(由DataNode上传)
— NameNode持久化
- NameNode的metadata信息在启动后会加载到内存
- matedata存储到磁盘文件为“fsimage”(时点备份,因为不需要不停的备份,这样内存跟磁盘又在交互,速度会下降。)
4、NameNode持久化
(将内存中的元数据信息永久的保存在磁盘之上)
- NameNode的metadata信息在启动后会加载到内存
- metadata存储到磁盘文件名为“fsimage”(磁盘镜像快照,是一个序列化的过程,转换成二进制文件,方便传输以及跨平台使用,恢复的时候只要做反序列化操作即可,且速度很快。时点备份)
- Block的位置信息不会保存到fsimage
- edit记录对metadata的操作日志—>Redis(写的时候速度很快,但是文件大的话,恢复就会很慢)
总结:fsimage写很慢,恢复快;edits写很快,恢复慢,所以可以结合两者的优势。
合并方法:在hadoop集群还没有开始跑起来的时候,就进行格式化操作,在格式化操作后,会产生fsimage文件以及edits的日志文件,将两者合并生成一个新的fsimage文件。
fsimage + edits —> fsimage
由于edits生成的文件比较大,且恢复很慢,所以定期重复上述的合并操作,生成fsimage文件。因为fsimage文件恢复快,所以当需要恢复时,只是恢复fsimage文件,速度很快。
谁做合并工作?
答:SecondaryNameNode(SNN)hadoop1.0有。
它不是NN的备份(但是可以做备份),它的主要工作时帮助NN合并edits log,减少NN启动时间。
SNN执行合并时机
- 根据配置文件设置时间间隔,默认为3600秒
- 根据配置文件设置edit log大小 fs.checkpoint.size规定edits文件的最大值默认为64MB
5、DataNode(DN)
- 本地磁盘目录存储数据(Block),文件形式
- 同时存储Block的元数据信息文件(仅本磁盘数据信息)
- 启动DN时会向NN汇报block信息
- 通过向NN发送心跳保持与其联系(3s/次),如果NN 10 分钟没有收到DN的心跳,则认为其已经lost,并copy其上的block到其它DN(为什么要等10分钟,因为文件可能比较大,如果很短时间就copy的话花费比较大,可能NN是发生了断网或者其他情况,等待10分钟会比copy的代价小很多)
6、HDFS的优点
— 高容错性
- 数据自动保存多个副本
- 副本丢失后,自动回复
— 适合批处理
- 移动计算而非数据(将计算框架移到数据身边,因为移动数据成本太大)
- 数据位置暴露给框架(Block偏移量)
— 适合大数据处理
- GB、TB、PB数据
- 百万规模以上文件数量
— 可构建在廉价机器上
- 通过多副本提高可靠性
- 提供容错恢复机制
7、HDFS的缺点
— 低延迟数据访问
- 比如毫秒级
- 低延迟与高吞吐量
— 小文件存取
- 占用NameNode大量内存
- 寻道时间超过读取时间
— 并发写入、文件随机修改
- 一个文件只能有一个写者
- 仅支持append
8、Blcok的副本放置策略
- 第一个副本:放置在上传文件的DN;如果是集群外提交,则随机挑选一台磁盘不太满,CPU不太忙的节点。
- 第二个副本:放置在与第一个副本不停机架的节点上。
- 第三个副本:与第二个副本相同机架的不同节点
- 更多副本:随机节点
9、HDFS写流程
— Client
- 切分文件Block
- 按Block线性和NN获取DN列表(副本数)
- 验证DN列表后以更小的流式传输数据(各节点两两通信确认可用)
- Block传输结束后:
— DN向NN汇报Block信息
— DN向Client汇报完成
— Client向NN汇报完成
- 获取下一个Block存放的DN列表
- 。。。。。
- 最终Client汇报完成
- NN会在写流程更新文件状态
10、HDFS读流程
— Client:
- 和NN获取一部分Block副本位置列表
- 线性和DN获取Block,最终合并为一个文件
- 在Block副本列表中按距离择优选择服务器
- MD5验证完整性
总结:
角色(NameNode)= = 进程
— NameNode
- 数据的元数据
- 内存存储,不会有磁盘的交换
- 持久化(fsimage、edits log)
不会持久化block位置信息
- block不可调整大小,hdfs不支持修改文件
— DataNode
- block块
- 本节点元数据
- 磁盘
- 面向文件,大小一样,不可调整
- 副本数,可调整(备份,高可用,容错/可以调整很多歌,为了计算向数据移动)
— SNN
— NN&DN
- 心跳机制
- DN向NN汇报block数据
- 安全模式