这是我参与「第四届青训营 」笔记创作活动的第8天
HDFS原理与应用
课程目标:
HDFS的设计与实现
HDFS的产品化体系建设
HDFS多场景的应用
分布式存储系统通用基本概念
HDFS基本介绍
Hadoop技术体系:
Window单机文件系统
Linux单机文件系统
XFS、ZFS、BTRFS、EXT4
分布式文件系统
- 大容量:更多的机器,更多的存储介质
- 高可靠:多个副本提高容错能力
- 低成本:不需要高端硬件来扩容
分布式存储系统
HDFS功能特性
- 分布式:受GFS启发,用Java实现的开源系统,没有实现完整的POSIX文件系统语义
- 容错:自动处理,规避多种错误场景,例如常见的网络错误、机器宕机等
- 高可用:一主多备模式实现元数据高可用,数据多副本实现用户数据的高可用
- 高吞吐:Client直接从DataNode读取用户数据,服务端支持海量client并发读写
- 可扩展:支持联邦集群模式,DataNode数量可达10w级别
- 廉价:只需要通用硬件,不需要定制昂贵的硬件设备
小结:
- Hadoop 技术体系
- 分布式文件系统
- 分布式存储系统的类型
- HDFS 功能特性
- 演示环境
HDFS架构原理
HDFS组件
三大件:
- Client:从某台机器访问HDFS,常见形式SDK
- NameNode:中枢节点
- DataNode:所有用户的数据最后持久化存储在DataNode硬盘上
Client写流程
其中3.写数据块:
第一个DataNode把数据复制到第二个节点,第二个节点再发给第三个节点,叫做pipeline写
Client在写前要问NameNode写到哪个节点上 写三个副本的方式(pipeline写)
Client读流程
Client在读前要问NameNode块存储在哪些节点上 只需要和第一个数据块的进行交互就可以读到内容
源数据节点NameNode
- 维护目录树:维护目录树的增删改查操作,保证所有修改都能持久化,以便机器掉电不会造成数据丢失或不一致
- 维护文件和数据块的关系:文件被切分成多个块,文件以数据块为单位进行多副本存放
- 维护文件快存放节点信息:通过接受DataNode的心跳汇报信息,维护集群节点的拓扑结构和每个文件块所有副本所在的DataNode类表
- 分配新文件存放节点:Client创建新的文件时候,需要有NameNode来确定分配目标DataNode
数据节点DataNode
- 数据块存储
- 心跳汇报:和NameNode联系,发送本机数据块列表
- 副本复制:机器故障时补全副本
小结:
- 分布式存储系统基本概念
- HDFS 组件功能职责
HDFS关键设计
分布式存储系统基本概念
- 容错能力:能够处理绝大部分异常场景,例如服务器宕机、网络异常、磁盘故障、网络超时等
- 一致性模型:为了实现容错,数据必须多副本存放,一致性要解决的问题时如何保障这不同机器多个副本的内容都是一致的
- 可扩展性:分布式存储系统需要具备横向扩张scale-out的能力,容量不够,可以通过加节点做一些扩展等
- 节点体系:常见的有主从模式、对等模式等,不管哪种模式,高可用是必须的功能
- 数据防止:系统是由多个节点组成,数据是多个副本存放时,需要考虑数据存放的策略
- 单机存储引擎:在绝大部分存储系统中,数据都是需要落盘持久化,单机引擎需要解决的时根据兄特点,如何高效的存取硬盘数据
NameNode目录树维护(增删改查)
蓝色目录,绿色叶子节点
- fsimage
- 文件系统目录树
- 完整的存放在内存中
- 定时存放在硬盘上
- 修改时只会修改内存中的目录树
如果节点挂了,修改没有实施保存,是否会丢失?
->引入Editlog
-
Editlog
- 目录树的修改日志(修改时实时的刷到硬盘上)
- client更新目录树需要持久化Editlog后才能表示更新成功
- Editlog可循放在本地文件系统,也可存放在专用系统上
- NameNode HA方案一个关键点就是如何实现EditLog共享
NameNode数据放置
-
数据块信息维护
- 目录树保存每个文件的块id
- NameNode维护了每个数据块所在的节点信息
- NameNode根据DataNode回报的信息动态维护位置信息
- NameNode不会持久化数据块位置信息(NameNoede在自己内存中动态构建map信息)
-
数据放置策略
- 新数据存放到哪写节点
- 数据均衡需要怎么合理搬迁数据
- 3个副本怎么合理放置
DataNode
-
数据块的硬盘存放
- 文件在NameNode已分割成block
- DataNode以block为单位对数据进行存取
-
启动扫盘
- DataNode需要知道本机存放了哪些数据块
- 启动时把本机硬盘上的数据块列表加载在内存中
HDFS写异常处理:Lease Recovery (客户端挂了)
-
情景:文件写了一半,client自己挂掉了。
-
可能产生的问题:
- 副本不一致[每次读的数据不一样]
- Lease无法释放
-
租约:Client要修改一个文件时,需要通过NameNode上锁,这个锁就是租约(Lease)
-
解决方法:Lease Recovery(租约恢复)
-
- 比较三个副本大小长度,选最小的
-
- 客户端定期续租
-
HDFS写异常处理:Pipeline Recovery (服务端挂了)
-
情景:文件写入过程中,DataNode侧出现异常挂掉了
-
异常出现的时机:
- 创建连接时
- 数据传输时
- complete阶段(DN完成落盘后向上(NameNode)报新块);
-
解决方法:Pipeline Recovery
-
- 重新选一个节点
-
- 如果有一个节点挂了,pipeline到重新构建阶段,将坏的节点去除
-
- pipeline重构,重新选节点。
-
Client读异常处理
-
情景:读取文件的过程,DataNode侧出现异常挂掉了
-
解决办法:节点Failover;
-
增强情景:节点半死不过,读取很慢
旁路系统
Balancer:均衡DataNode的容量
Mover:确保副本放置符合策略要求
控制面建设
-
可观测性设施
- 指标埋点
- 数据采集
- 访问日志
- 数据分析
-
运维体系建设
- 运维操作需要平台化
- NameNode操作复杂
- DataNode机器规模庞大
- 组件控制面API
小结:
- NameNode目录树设计
- NameNode副本放置
- DataNode设计
- Client读写流程异常处理
- HDFS旁路系统
- HDFS控制面建设
HDFS应用场景
- PySpark读取分析HDFS上的文件:
- 读取本地文件系上的文件
- 把查询结果保存到本地文件
- 读取 HDFS 上的文件
- 把査询结果保存到 HDFS 上
- ETL:
- OLAP查询引擎
- HBase
- 机器学习
- 通用场景:
-
- 备份数据
-
- 海量日志
-
- 冷数据层
-
- 消息队列
-
- 对象存储
-