这是我参与「第四届青训营 」笔记创作活动的第二天
HDFS 架构原理
基本概念
全称：Hadoop Distributed File System
应用层： Hadoop MapReduce、Spark
调度层：Hadoop YARN
存储层：Hadoop HDFS
分布式文件系统：大容量、高可靠、低成本（指不需要高端硬件）
HDFS特性
- 分布式：受 GFS 启发，用 Java 实现的开源系统，没有实现完整的 POSIX 文件系统语义
- 容错：自动处理、规避多种错误场景，例如常见的网络错误、机器宕机等
- 高可用：一主多备模式实现元数据高可用，数据多副本实现用户数据的高可用
- 高吞吐：Client 直接从 DataNode 读取用户数据，服务端支持海量 Client 并发读写
- 可扩展：支持联邦集群模式，DataNode 数量可达 10w 级别
- 廉价：只需要通用硬件，不需要定制的高端硬件
-
容错能力
- 能够处理绝大部分异常场景，例如服务器宕机、网络异常、磁盘故障、网络超时等
-
一致性模型（最复杂的部分）
- 为了实现容错，数据必须多副本存放，一致性要解决的问题是如何保障这多个副本的内容都是一致的
-
可扩展性
- 分布式存储系统需要具备横向扩张 scale-out 的能力
-
节点体系模式
- 常见的有主从模式、对等模式等，都要保证高可用
-
数据放置策略
- 系统是由多个节点组成，数据时多个副本存放时，需要考虑数据存放的策略
-
单机存储引擎
- 在绝大部分存储系统中，数据都是需要落盘持久化，单机引擎需要解决的是根据系统特点，如何高效地存取硬盘数据
Pipeline 写
Client 写流程
- Client 向 NameNode 请求写入新数据块
- NameNode 向 Client 返回副本目标 DN 列表
- Client 向 DN 写数据块
- DN 向 Client 发送 ACK
- Client 向 DN flush
- Client 向 NN 发送 complete 请求
- getBlockLocations 请求
- 返回副本目标 DN 列表
- 读取数据库
HDFS组件
Client/SDK：读写操作的发起点，HDFS很多读写逻辑都是在SDK中实现的。
NameNode：元数据节点，是HDFS的中枢节点，也是服务的入口。
- 维护目录树
- 维护文件和数据块的关系
- 维护文件快存放节点信息
- 分配新文件存放节点
DataNode：实际存放用户数据的数据节点
- 数据块存取
- 心跳汇报
- 副本复制
HDFS 关键设计
NameNode 目录树维护
fsimage
- 存放文件系统的目录树
- 完整地存放在内存中
- 定时存放到硬盘上
- 修改时只会修改内存中得目录树
EditLog
- 目录树的修改日志
- Client 更新目录树需要持久化 EditLog 后才能表示更新成功
- EditLog 可存放在本地文件系统，也可存放在专用系统上
- NameNode HA 方案的一个关键点就是如何实现 EditLog 共享
需要实时地刷到硬盘上
NameNode目录树设计，重点理解EditLog的设计，可类比关系型数据库中的Transaction Log概念。
- 仅在内存中修改：fsimage
- 需要立即保存到硬盘：EditLog
NameNode数据放置
数据分散在各个节点上，如何定位找到它们？
数据块信息维护
- 目录树保存每个文件块的 ID
- NN 维护了每个数据块所在的节点信息
- NN 根据 DataNode 汇报的信息动态地维护位置信息
- NN 不会持久化数据块位置信息（只保存在内存中，需要 DN 自行扫描自己的数据并汇报）
数据放置策略
- 新数据存放到哪写节点
- 数据均衡要怎样合理搬迁数据
- 3 个副本怎样和合理放置
DataNode设计
数据如何落盘存放？
-
数据块的存放
- 文件在 NameNode 已经被分割为 block
- DataNode 以 block 为单位对数据进行存取
-
启动扫盘获得本机文件块列表
- 启动时把本机硬盘上的数据块列表加载在内存中
- 因为 NameNode 不会存文件快列表，要 DataNode 自己扫描向 NameNode 汇报
HDFS 写异常处理：Lease Recovery
场景：文件写到一半 client 宕机了
- 副本不一致
- Lease 无法释放
租约（其实就是锁）
Client 要修改一个文件时，需要通过 NameNode 上锁，这个锁就是租约（Lease）
解决方法
Lease Recovery
- 数据不一致问题：系统去比较三个版本的数据长度，选长度最小的
- 租约无法释放问题：租约需要续租，10 分钟后如果没有续约，判定为节点宕机，如果有其他节点申请租约则把原来的踢掉
HDFS 写异常处理：Lease Recovery
情景：文件写入过程中，DataNode 侧出现异常挂了
异常出现的时机
- 创建连接时
- 数据传输时
- complete 阶段
解决方法：Pipeline Recovery
Client 读异常处理
场景：读取文件的过程，DataNode 侧出现异常挂掉了
解决方法：节点 Failover
增强场景：节点半死不活，读取很慢
旁路系统
不影响正常读写，异步地解决一些问题，不是一下子完成的，有一个积累的过程
能够简化系统的实现，如果这些问题要同步解决的话系统会很复杂
举例
- Balancer：均衡 DataNode 的容量
- Mover：确保副本放置符合策略要求
-
Client读写链路的异常处理
- Server端异常
- Client端异常
- 慢节点
控制面建设：保障系统稳定运行
-
HouseKeeping组件：比如Balancer，Mover等， 这些组件不运行不会马上影响读写操作，但是长时间会积累系统性问题，例如读写不均衡导致IO热点等。
-
可观测性设施：比如系统指标监控设施等，帮助快速发现定位问题。
- 指标埋点
- 数据采集
- 访问日志
- 数据分析
-
运维体系建设：从最基本的命令行手工操作，脚本自动化再到完善的运维平台。
- 运维操作需要平台化
- NameNode 操作复杂
- DataNode 及其规模庞大
- 组件控制面 API
