这是我参与「第四届青训营」笔记创作活动的第8天

元数据高可用

高可用：系统在困境（adversity，比如硬件故障、软件故障、人为错误）中仍可正常工作（正确完成功能，并能达到期望的性能水准）

故障度量的指标

MTTR：Mean Time To Recovery
MTTF：Mean Time To Fix
MTBF：Mean Time Between Failures

可用性 A = MTBF/(MTBF+MTTR)

要做到高可用需要系统的自动决策，因为人的反应更慢

NameNode 容易成为故障中的单点（Single Point of Failure），因为 NN 是中心化的

HDFS高可用架构

ActiveNamenode：主节点，提供服务，是日志的生产者
StandbyNamenode：备节点，日志的消费者
ZooKeeper：为自动选主提供统一协调服务
BookKeeper：提供日志存储服务
ZKFC：NameNode 探活、触发主备切换（Hadoop 生态圈的遗留组件，更新的系统可能会将其融入到元数据节点里）
HA Client：提供了自动切换的客户端
edit log：操作的日志

数据存储高可用

RAID

将多个廉价、不可靠、低性能、容量小的磁盘组装在一起，提供高可靠、高性能、大容量逻辑磁盘服务的一组磁盘列阵方案。

廉价
高性能
大容量
高可用

RAID 方案

RAID 0 ：将数据分块后按条带化的形式分别存储在多个磁盘上，提供大容量、高性能。
RAID 1：将数据副本存储在多个磁盘上，提供高可靠。

RAID 3：在数据分块存储的基础上，将数据的校验码存储在独立的磁盘上，提供高可靠、高性能。

HDFS 的数据高可用机制

HDFS 多副本

HDFS 版本的 RAID 1

优点：

读写路径简单
副本修复简单
高可用

数据出现问题时向 NN 汇报，NN 从另一个 DN 上找一份复制过去

元数据高扩展性

元数据扩展性挑战

名字空间分裂
DN 汇报
目录树结构本身复杂
Scale up：扩容单个服务器的能力
Scale out：部署多个服务器来服务

常见的 Scale Out 方案

KV 模型的系统可以使用 Partition（按照 KEY 的值不同，让不同的节点处理）

Redis
Kafka
MySQL

社区的解决方案

BlockPoll

解决 DN 服务多组 NN 的问题

将文件系统分为文件层和块存储层，对于块存储层，DN 集群对不同的 NN 提供不同的标识符，称为 block pool。
解决了多个 NN 可能生成同一个 block id，DN 无法区分的问题。

viewfs

Federation（联邦）架构：将多个不同集群组合，对外表现为一个集群
viewfs 通过在 client-side 的配置，指定不同的目录访问不同的 NN

NNProxy

主要提供了路由管理、RPC 转发，额外提供了鉴权、限流、查询缓存等能力。
开源社区有类似的方案 Router Based Federation，主要实现了路由管理和转发。

小文件问题

HDFS 设计上是面向大文件的，小于一个 HDFS Block 的文件称为小文件。
元数据问题：多个小文件相对于一个大文件，使用了更多元数据服务的内存空间。
数据访问问题：多个小文件相对于一个大文件，I/O 更加的随机，无法顺序扫描磁盘。
计算任务启动慢：计算任务在启动时，一般会获得所有文件的地址来进行 MapReduce 的任务分配，小文件会使得这一流程变长。

MapReduce 的 worker 数量过多容易引起小文件问题

解决方案：

后台任务合并小文件
Shuffle Service（等于提前做了小文件的合并）

HDFS 高可用和高扩展机制分析 ｜ 青训营笔记