这是我参与「第四届青训营 」笔记创作活动的第9天
1. 元数据服务高可用需求
高可用：系统在困境（adversity，比如硬件故障、软件故障、人为错误）中仍可正常工作（正确完成功能，并能达到期望的性能水准）
故障类型：
- 硬件故障
- 软件故障
- 人为故障
灾难：数据中心级别不可用
- 机房断电
- 机房空调停机
- 机房间网络故障、拥塞
故障不可避免，灾难时有发生
而如果HDFS系统不可用：
- 无法核算广告账单，直接引发收入损失
- 无法生产数据报表，数据驱动无从谈起
- 无法进行模型训练，用户体验越来越差
业务停止的损失极大，所以HDFS系统的高可用性就至关重要
1.1 服务可用性的衡量指标
- MTTR（Mean Time To Repair）：平均修复时间，指系统从发生故障到维修结束之间的时间段的平均值。
- MTTF（Mean Time To Failure）：平均失效时间，指系统两次故障发生时间之间的时间段的平均值，一般用于不可修复的系统（制造业）。
- MTBF（Mean Time Between Failures）：平均无故障时间，两次故障间的间隔，一般用于可修复的系统（软件）
1.2 高可用的形式
服务高可用
- 热备份
- 冷备份
故障恢复操作
- 人工切换
- 自动切换
人工的反应、决策时间都更长，高可用需要让系统自动决策。HDFS的设计中，采用了中心化的元数据管理节点NameNode，NameNode容易成为故障中的单点（single point of failure）
1.3 可用性的年化
全年不可用时间：
- 可用性 99.9%，全年8.76小时不可用
- 可用性 99.99%，全年52.6分钟不可用
- 可用性 99.999%，全年5.26分钟不可用
2. HDFS主备同步实现
2.1 HDFS NameNode高可用架构
2.1.1 组件介绍
- ActiveNamenode:主节点，提供服务，生产日志
- StandbyNamenode:备节点，消费日志
- ZooKeeper:为自动选主提供统一协调服务
- BookKeeper:提供日志存储服务
- ZKFC: NameNode 探活、触发主备切换
- HA Client: 提供了自动切换的客户端
- edit log:操作的日志
2.1.2 围绕三个问题来看高可用
- 节点状态如何保存
- 操作日志如何同步
- 如何做到自动切换
2.2 数据存储高可用
2.2.1 单机存储的数据高可用机制
RAID (Redundant Array of Independent Disks) 将多个廉价、不可靠、低性能、容量小的磁盘组装在一起，提供高可靠、高性能、大容量逻辑磁盘服务的一组磁盘列阵方案，比如：
- RAID 0: 条带化。将数据分块后按条带化的形式分别存储在多个磁盘上，提供大容量、高性能
- RAID 1: 冗余。将数据副本存储在多个磁盘上，提供高可靠
- RAID 3: 容错校验。在数据分块存储的基础上，将数据的校验码存储在独立的磁盘上，提供高可靠、高性能
2.2.2 案例：字节跳动的HDFS多机房实践
字节跳动的HDFS集群，从单机房演进到双机房，再从双机房演进到更多的机房
多机房解决的问题
- 容量问题
- 容灾问题
HDFS双机房放置的设计
- 写入时，每个数据块在两个机房至少各有一个副本，数据实时写入到两个机房
- 读取时，优先读本地的副本，避免了大量的机房读取
3. 元数据高扩展性
3.1 元数据节点扩展性的挑战
HDFS NameNode是个集中式服务，部署在单个机器上，内存和磁盘的容量、CPU的计算力都不能无限扩展
scale up vs. scale out
- 扩容单个服务器的能力
- 部署多个服务器来服务
挑战
- 名字空间分裂
- DataNode汇报
- 目录树结构本身复杂
3.2 常见的Scale Out方案
KV模型的系统可以使用partition
- Redis
- Kafka
- MySQL（分库分表）
右图：三种数据路由方式
- 服务端侧
- 路由层
- 客户端侧
3.3 字节跳动的NNProxy
字节跳动应用 HDFS 已经非常长的时间了，经历了许多年的发展，目前已直接支持了十多种数据平台，间接支持了上百种业务发展。从集群规模和数据量来说，HDFS 平台在公司内部已经成长为总数几万台服务器的大平台，支持了 EB 级别的数据量。
NNProxy是ByteDance自研的HDFS代理层，提供了路由服务
- 于2016年开源，项目地址：bytedance/nnproxy: Scalable NameNode RPC Proxy for HDFS Federation (github.com)
- 开源社区的Router Based Federation在2017年上线
NNProxy主要实现了路由管理和RPC转发
- 以及鉴权、限流、查询缓存等额外能力
下图：NNProxy所在系统上下游
3.4 案例：小文件问题
小文件问题（LSOF,lots of small files）：大小不到一个HDFS Block大小的文件过多
- NameNode瓶颈
- I/O变小，数据访问变慢
- 计算任务启动慢
图：MapReduce的worker数量过多容易引起小文件问题
解决方案：
- 后台任务合并小文件
- Shuffle Service
4. 存储数据高扩展性
4.1 延迟的分布和长尾延迟
延迟的分布：
- 用百分数来表示访问的延迟的统计特征
- 例如p95延迟为1ms，代表95%的请求延迟要低于1ms，但后5%的请求延迟会大于1ms
长尾延迟：尾部（p99/p999）的延迟，衡量系统最差的请求的情况，会显著的要差于平均值
图：延迟的长尾、延迟的分布
4.2 尾部延迟放大
木桶原理 尾部延迟放大：访问的服务变多，尾部的请求就会越发的慢
如何变慢
- 固定延迟阈值
- 固定延迟百分位
4.3 长尾问题的表现 - 慢节点
慢节点：读取速度过慢，导致客户端阻塞
慢节点的发生难以避免和预测
- 共享资源、后台维护活动、请求多级排队、功率限制
- 固定的损耗：机器损坏率
- 混沌现象
离线任务也会遇到长尾问题
- 全部任务完成时间取决于最慢的任务什么时候完成
- 集群规模变大，任务的数据量变大
- 只要任何数据块的读取收到长尾影响，整个任务就会因此停滞
集群扩大10倍，问题扩大N（>10）倍
4.4 数据迁移工具 - 跨NN1迁移
DistCopy
√ 基于MapReduce，通过一个个任务，将数据从一个NameNode拷贝到另一个NameNode
√ 需要拷贝数据，流量较大，速度较慢
FastCopy
√ 开源社区的无需拷贝数据的快速元素迁移方案
√ 前提条件：新旧集群的DN列表吻合
√ 对于元数据，直接复制目录树的结构和块信息
√ 对于数据块，直接要求DataNode从源BlockPool hardlink到目标BlookPool，没有数据拷贝
√ hardlink：直接让两个路径指向同一块数据
总结
- HDFS作为大户数据离线分析场景的核心组件，高可用和高扩展性是架构设计的重中之重。
- 高可用确保了业务能稳定运行，HDFS上存储的数据随时可以访问。
- 高扩展性确保了HDFS能存储的数据量能随着资源投入无限扩展下去，业务发展不被基础组件拖累。
