这是我参与「第四届青训营 」笔记创作活动的第8天
Review
上节课我们了解了HDFS架构和读写流程
HDFS通过将文件分块来存储大文件，HDFS的组件有NameNode和DataNode，分别负责提供元数据和数据服务。
在读/写数据时，HDFS客户端需要先从NameNode上获取数据读取/写入的DataNode地址，然后和DataNode交互来完成数据读/写。
一个“可以用”的系统和“好用”的系统，差距就是“高可用”和“高扩展性”
01 元数据服务高可用
1.1.1 服务高可用的需求
故障类型：
- 硬件故障
- 软件故障
- 人为故障
灾难：数据中心级别不可用
- 机房断电
- 机房空调停机
- 机房间网络故障、拥塞
故障不可避免，灾难时有发生
而如果HDFS系统不可用：
- 无法核算广告账单，直接引发收入损失
- 无法生产数据报表，数据驱动无从谈起
- 无法进行模型训练，用户体验越来越差
业务停止的损失极大，所以HDFS系统的高可用性就至关重要
1.1.2 高可用的衡量
服务可用性指标：
- MTTR
- MTTF
- MTBF
1.1.3 可用性的年化
可用性：
全年不可用时间：
- 可用性 99.9%，全年8.76小时不可用
- 可用性 99.99%，全年52.6分钟不可用
- 可用性 99.999%，全年5.26分钟不可用
1.1.4 高可用的形式
服务高可用
- 热备份
- 冷备份
故障恢复操作
- 人工切换
- 自动切换
人工的反应、决策时间都更长，高可用需要让系统自动决策。
HDFS的设计中，采用了中心化的元数据管理节点NameNode
NameNode容易成为故障中的单点（single point of failure）
1.2.1 HDFS NameNode高可用架构
组件介绍
- ActiveNameNode：主节点，提供服务，生产日志
- StandbyNameNode：备节点，消费日志
- ZooKeeper：为自动选选主提供统一协调服务
- BookKeeper：提供日志存储服务
- ZKFC：NameNode探活、触发主备切换
- HA Client：提供了自动切换的客户端
- edit log：操作的日志
围绕三个问题来看高可用
- 节点状态如何保存
- 操作日志如何同步
- 如何做到自动切换
1.2.2 理论基础 - 状态机复制和日志
状态机复制是实现容错的常规方法
组件
- 状态机以及其副本
- 变更日志
- 共识协议
1.2.3 NameNode状态持久化
Checkpoint机制
FSImage和EditLog
1.2.4 NameNode操作日志的生产消费
Active生产，Standby（可能有多个）消费
物理日志与逻辑日志
日志系统
- 高可用
- 高扩展性
- 高性能
- 强一致（有序）
1.2.5 NameNode块状态维护
回顾：
- DataNode Heartbeat
- DataNode Block Report
区别：
- Active即接收，也发起变更
- Standby只接收，不发起变更
Content Stale状态
- 主备切换后，避免DN的不确定状态
1.3.1 分布式协调组件 - ZooKeeper
一般用于提供选主、协调、元数据存储
使用它的组件：
- HDFS、YARN、HBase
- Kafka、ClickHouse
- 等等
HA核心机制：Watch
1.3.2 自动主备切换流程 - Server侧
ZKFailoverController
作为外部组件，驱动HDFS NameNode的主备切换
轮询探活
脑裂问题
Fence机制
1.3.3 自动主备切换流程 - Client侧
黑犀牛机制： StandbyException
Client自动处理
1.4.1 BookKeeper架构
BookKeeper存储日志
- 低延迟
- 持久性
- 强一致性
- 读写高可用
对比：日志系统和文件系统的复杂度
1.4.2 Quorum
Quorum机制：多副本一致性读写
场景：
多副本对象存储，用版本号标识数据新旧
规则：
思考：日志场景比对象保存更简单
1.4.3 Bookkeeper Quorum
Sloppy Quorum机制
日志场景：顺序追加、只写
Write Quorum：写入副本数
Ack Quorum：响应副本数
思考：Client挂掉导致不确认写入了多少数据，如何恢复？
1.4.4 BookKeeper Ensemble
Ensemble机制
Round-Robin Load Balancer
- 第一轮：1，2，3
- 第二轮：2，3，4
- 第三轮：3，4，1
- 第四轮：4，1，2
优势：数据均衡
02 数据存储高可用
2.1.1 回到单机存储 - RAID
Redundant Array of Independent Disks
图：提供RAID功能的NAS设备
特点
- 廉价
- 高性能
- 大容量
- 高可用
2.1.2 RAID方案讲解
RAID 0：条带化
RAID 1：冗余
RAID 3：容错校验
其他RAID方案可以自行了解
2.2.1 HDFS多副本
HDFS版本的RAID 1
图：Hadoop的多副本放置
优点
- 读写路径简单
- 副本修复简单
- 高可用
2.2.2 Erasure Coding原理
HDFS版本的RAID 2/3
业界常用Reed Solomon算法
图：Reed Solomon算法原理
2.2.3 HDFS Erasure Coding
HDFS版本的RAID 2
图：直接保存的EC和Strip（条带化）后保存的EC
和多副本比较
- 读写速度
- 成本
- 修复速度
- 读写路径的实现
2.3.1 网络架构
机架（Rack）：放服务器的架子
TOR（Top of Rack）：机架顶部的交换机
数据中心（Data Center）：集中部署服务器的场所
图：机架的样子、网络拓扑
2.3.2 副本放置策略 - 机架感知
一个TOR故障导致整个机架不可用 vs 降低跨rack流量
trade-off：一个本地、一个远端
图：HDFS的多机架放置
2.4.1 案例：字节跳动的HDFS多机房实践
字节跳动的HDFS集群，从单机房演进到双机房，再从双机房演进到更多的机房
多机房解决的问题
- 容量问题
- 容灾问题
HDFS双机房放置的设计
- 写入时，每个数据块在两个机房至少各有一个副本，数据实时写入到两个机房
- 读取时，优先读本地的副本，避免了大量的机房读取
2.4.2 多机房容灾实践
多机房部署的组件
- ZooKeeper
- BookKeeper
- NameNode
- DataNone
容灾期间的策略
- 限制跨机房写入
- 限制跨机房副本复制
03 元数据高扩展性
3.1.1 元数据节点扩展性的挑战
HDFS NameNode是个集中式服务，部署在单个机器上，内存和磁盘的容量、CPU的计算力都不能无限扩展
scale up vs. scale out
- 扩容单个服务器的能力
- 部署多个服务器来服务
挑战
- 名字空间分裂
- DataNode汇报
- 目录树结构本身复杂
3.1.2 常见的Scale Out方案
KV模型的系统可以使用partition
- Redis
- Kafka
- MySQL（分库分表）
右图：三种数据路由方式
- 服务端侧
- 路由层
- 客户端侧
目录树如何合理拆分
3.2.1 社区解决方案 - BlockPool
解决DN同时服务多组NN的问题
文件服务分层
- Namespace
- Block Storage
用blockpool来区分DN的服务
- 数据块存储
- 心跳和块上报
3.2.2 社区解决方案 - viewfs
Federation架构：将多个不同集群组合起来，对外表现像一个集群一样
下图：viewfs通过在client-side的配置，指定不同的目录访问不同的NameNode
局限性：运维复杂
3.3.1 字节跳动的NNProxy
NNProxy是ByteDance自研的HDFS代理层，提供了路由服务
- 于2016年开源，项目地址：github.com/bytedance/n…
- 开源社区的Router Based Federation在2017年上线
NNProxy主要实现了路由管理和RPC转发
- 以及鉴权、限流、查询缓存等额外能力
下图：NNProxy所在系统上下游
3.3.2 NNProxy路由规则保存
回顾：三种数据路由方式
- 服务端侧
- 路由层
- 客户端侧
考虑点：扩展性、运维性
图：路由规则的保存
3.3.3 NNProxy路由转发实现
图：目录树视图
路径最长匹配规则
- /
- home
- /user/bob
- /user/tiger/warehouse
- /user/tiger/dump
进一步思考：
- 单个NN不会遇到瓶颈了么？
- 跨集群rename
3.4 案例：小文件问题
小文件问题（LSOF,lots of small files）：大小不到一个HDFS Block大小的文件过多
- NameNode瓶颈
- I/O变小，数据访问变慢
- 计算任务启动慢
图：MapReduce的worker数量过多容易引起小文件问题
解决方案：
- 后台任务合并小文件
- Shuffle Service
04 存储数据高扩展性
4.1.1 延迟的分布和长尾延迟
延迟的分布：
- 用百分数来表示访问的延迟的统计特征
- 例如p95延迟为1ms，代表95%的请求延迟要低于1ms，但后5%的请求延迟会大于1ms
长尾延迟：尾部（p99/p999）的延迟，衡量系统最差的请求的情况，会显著的要差于平均值
图：延迟的长尾、延迟的分布
4.1.2 尾部延迟放大
木桶原理 尾部延迟放大：访问的服务变多，尾部的请求就会越发的慢
如何变慢
- 固定延迟阈值
- 固定延迟百分位
4.1.3 长尾问题的表现 - 慢节点
慢节点：读取速度过慢，导致客户端阻塞
慢节点的发生难以避免和预测
- 共享资源、后台维护活动、请求多级排队、功率限制
- 固定的损耗：机器损坏率
- 混沌现象
离线任务也会遇到长尾问题
- 全部任务完成时间取决于最慢的任务什么时候完成
- 集群规模变大，任务的数据量变大
- 只要任何数据块的读取收到长尾影响，整个任务就会因此停滞
集群扩大10倍，问题扩大N（>10）倍
4.2.1 超大集群下的数据可靠性
条件一：超大集群下，有一部分机器是损坏来不及修理的
条件二：副本放置策略完全随机
条件三：DN的容量足够大
推论：必然有部分数据全部副本在损坏的机器上，发生数据丢失
估算：三副本，10000台机器，每台一百万副本
- 有多少种放置的组合数
- 损坏100台机器，会有多少副本丢失
叠加长尾问题，容易导致整个任务无法执行下去
4.2.2 Copyset
将DataNode分为若干个Copyset选块在copyset内部选择
原理：减少了副本放置的组合数，从而降低副本丢失的概率
缺陷是什么？
4.3.1 超大集群的负载均衡和数据迁移
4.3.2 数据写入不均
数据的不均匀
- 节点容量不均匀
- 数据新旧不均匀
- 访问类型不均匀
资源负载不均匀
4.3.3 DN冷热不均
数据的不均匀（同4.3.2）
4.3.4 负载均衡和数据迁移的典型场景
4.4.1 数据迁移工具 - 跨NN1迁移
DistCopy
√ 基于MapReduce，通过一个个任务，将数据从一个NameNode拷贝到另一个NameNode
√ 需要拷贝数据，流量较大，速度较慢
FastCopy
√ 开源社区的无需拷贝数据的快速元素迁移方案
√ 前提条件：新旧集群的DN列表吻合
√ 对于元数据，直接复制目录树的结构和块信息
√ 对于数据块，直接要求DataNode从源BlockPool hardlink到目标BlookPool，没有数据拷贝
√ hardlink：直接让两个路径指向同一块数据
4.2.2 数据迁移工具 - Balancer
工具向DataNode发起迁移命令，平衡各个DataNode的容量
场景
- 单机房使用、多机房使用
- 限流措施
评价标准
- 稳定性成本
- 可运维性
- 执行效率
结语
HDFS作为大户数据离线分析场景的核心组件，高可用和高扩展性是架构设计的重中之重
高可用确保了业务能稳定运行，HDFS上存储的数据随时可以访问
高扩展性确保了HDFS能存储的数据量能随着资源投入无限扩展下去，业务发展不被基础组件拖累
字节跳动HDFS依然在持续迭代，在元数据扩展性、数据治理与调度、数据生态体系、单机存储引擎、云上存储等方向依然大有可为
