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

01.元数据高可用

（主备系统：基于日志、自动切换、实时热备）

1.1.1服务高可用的需求

故障类型:

1）硬件故障

2）软件故障

3）人为故障

灾难:数据中心级别不可用

1）机房断电

2）机房空调停机

3）机房间网络故障、拥塞

故障不可避免，灾难时有发生。

而如果HDFS系统不可用。

1）无法核算广告账单，直接引发收入损失

2）无法生产数据报表，数据驱动无从谈起

3）无法进行模型训练，用户体验越来越差

业务停止的损失极大，所以HDFS系统的高可用性就至关重要。

1.1.2高可用的衡量

服务可用性指标

1）MTTR

2）MTTF

3）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高可用架构

➢组件介绍

1）ActiveNamenode:主节点，提供服务，生产日志

2）StandbyNamenode:备节点，消费日志

3）ZooKeeper:为自动选主提供统一协调服务

4）BookKeeper:提供日志存储服务

5）ZKFC: NameNode 探活、触发主备切换

6）HA Client:提供了自动切换的客户端

7）edit log:操作的日志

➢围绕三个问题来看高可用

▪️ 节点状态如何保存

▪️ 操作日志如何同步

▪️ 如何做到自动切换

1.2.2理论基础一状态机复制和日志

状态机复制是实现容错的常规方法

组件

1）状态机以及其副本

2）变更日志

3）共识协议

1.2.3 NameNode状态持久化

Checkpoint机制

FSImage 和 EditLog

1.2.4 NameNode操作日志的生产消费

Active生产，Standby (可能有多个)消费

物理日志与逻辑日志

日志系统

1. 高可用

2. local disk

3. 高扩展性

4. 高性能

5. 强一致(有序)

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侧

ZKF ailoverController作为外部组件，驱动HDFS NameNode的主备切换

轮询探活

脑裂问题

Fence机制

1.3.3自动主备切换流程一Client侧

核心机制: StandbyException

1.4.1 BookKeeper架构

BookKeeper存储日志

1）低延时 2）持久性 3）强一致性 4）读写高可用

对比:日志系统和文件系统的复杂度

1.4.2 Quorum机制

Quorum机制:多副本-致性读写

场景:

多副本对象存储，用版本号标识数据新旧

规则

1. Qp + Qw> Q

2. Qw> Q/2

思考:日志场景比对象保存更简单

1.4.3 BookKeeper Quorum

Sloppy Quorum机制

日志场景:顺序追加、只写

Write Quorum:写入副本数

Ack Quorum:响应副本数

思考: Client 挂掉导致不确认写入了多少数据，如何恢复?

1.4.4 BookKeeper Ensemble

Ensemble机制

Round-Robin L oad 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设备

特点

1）廉价 2）高性能 3）大容量 4）高可用

2.1.2 RAID方案讲解

RAID0:条带化

RAID 1:冗余

RAID 3:容错校验

其他RAID方案可以课后了解

2.2.1 HDFS多副本

HDFS版本的RAID 1

图: Hadoop 的多副本放置

优点

1）读写路径简单 2）副本修复简单 3）高可用

2.2.2 Erasure Coding RT

HDFS H4ÉS RAID 2/3

业界常用Reed Solomon算法

图：Reed Solomon算法原理

2.2.3 HDFS Erasure Coding

HDFS版本的RAID 2

图:直接保存的EC和Stripe (条带化)后保存的EC

和多副本比较

1）读写速度 2）成本 3）修复速度 4）读写路径的实现

2.3.1网络架构

机架(Rack):放服务器的架子。

TOR(Top of Rack):机架顶部的交换机。

数据中心(Data Center):集中部署服务器的场所

图:机架的样子

图:网络拓扑

2.3.2副本放置策略一机架感知

一个TOR故障导致整个机架不可用 vs 降低跨rack流量

trade-off: 一个本地、一个远端

图: HDFS的多机架放置

2.4.1案例:字节跳动的HDFS多机房实践

字节跳动的HDFS集群，从单机房演进到双机房，再从双机房演进到更多的机房。

多机房解决的问题

1)容量问题

2)容灾问题

HDFS双机房放置的设计

1)写入时，每个数据块在两个机房至少各有-一个副本，数据实时写入到两个机房。

2)读取时，优先读本地的副本，避免了大量的跨机房读取。

多机房部署的组件

1)ZooKeeper

2)BookKeeper

3)NameNode

4)DataNode

容灾期间的策略

1)容灾期间，限制跨机房写入

2)容灾期间，限制跨机房副本复制

#03.元数据高扩展性

3.1.1元数据节点扩展性的挑战

HDFS NameNode是个集中式服务，部署在单个机器.上，内存和磁盘的容量、CPU的计算力都不能无限扩展。

scale up Vs. scale out

1)扩容单个服务器的能力

2)部署多个服务器来服务

挑战

1)名字空间分裂 2)DataNode汇报 3)目录树结构本身复杂

3.1.2常见的Scale Out方案

KV模型的系统可以使用partition

1)Redis 2)Kafka 3)MySQL (分库分表)

右图:三种数据路由方式

1)服务端侧 2)路由层 3)客户端侧

3.2.1社区解决方案一BlockPool

解决DN同时服务多组NN的问题

文件服务分层

1)Namespace

2)Block Storage

用blockpool来区分DN的服务

1)数据块存储 2)心跳和块上报

3.3.2 NNProxy路由规则保存

回顾:三种数据路由方式

1)服务端侧 2)路由层 3)客户端侧

考虑点:扩展性、运维性

图:路由规则的保存

3.3.3 NNProxy路由转发实现

图:目录树视图

路径最长匹配规则

● /

● /home

● /user/bob

● /user/tiger/warehouse

● /user/tiger/dump

进一步思考:

1)单个NN不会遇到瓶颈了么?

2)跨集群rename

3.4案例:

小文件问题(LSOF，lots of small files) :大小不到一个HDFS Block大小的文件过多

1. NameNode瓶颈
2. I/O变小，数据访问变慢
3. 计算任务启动慢

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

解决方案:

1. 后台任务合并小文件

2. Shuffle Service

04.存储数据高扩展性

4.1.1延迟的分布和长尾延迟

延迟的分布:

1. 用百分数来表示访问的延迟的统计特征

2. 例如p95延迟为1ms,代表95%的请求延迟要低于1ms,但后5%的请求延迟会大于1ms

长尾延迟:尾部( p99/p999/p999)的延迟，衡量系统最差的请求的情况。会显著的要差于平均值

上图:延迟的长尾

下图:延迟的分布

4.1.2尾部延迟放大

木桶原理

尾部延迟放大:访问的服务变多，尾部的请求就会越发的慢。

如何变慢

1. 固定延迟阈值 2) 固定延迟百分位

4.1.3长尾问题的表现一慢节点

➢慢节点:读取速度过慢，导致客户端阻塞。

慢节点的发生难以避免和预测

1. 共享资源、后台维护活动、请求多级排队、功率限制

2. 固定的损耗:机器损坏率

3. 混沌现象

离线任务也会遇到长尾问题

1. 全部任务完成时间取决于最慢的任务什么时候完成。

2. 集群规模变大，任务的数据量变大。

3. 只要任何数据块的读取受到长尾影响，整个任务就会因此停滞。

集群扩大10倍，问题扩大N(>10)倍

4.2.1超大集群下的数据可靠性

➢条件一:超大集群下，有一部分机器是损坏来不及修理的。

➢条件二:副本放置策略完全随机。

➢条件三: DN的容量足够大

推论:必然有部分数据全部副本在损坏的机器上，发生数据丢失。

估算:三副本，10000 台机器，每台一百万副本。

1. 有多少种放置的组合数?

2. 损坏100台机器，会有多少副本丢失?

叠加长尾问题，容易导致整个任务无法执行下去。

4.2.2 Copyset

将DataNode分为若干个Copyset选块在copyset内部选择

原理: 减少了副本放置的组合数，从而降低副本丢失的概率。

4.3.1超大集群的负载均衡和数据迁移

4.3.2数据写入不均

数据的不均匀

1. 节点容量不均匀 2) 数据新旧不均匀 3) 访问类型不均匀

资源负载不均匀

4.3.3 DN冷热不均

数据的不均匀

● 节点容量不均匀 ● 数据新旧不均匀 ● 访问类型不均匀 ● 资源负载不均匀

4.3.4负载均衡和数据迁移的典型场景

4.4.1数据迁移工具一跨NN迁移

➢DistCopy

1. 基于MapReduce,通过一个个任务，将数据从一个NameNode拷贝到另一个NameNode。

2. 需要拷贝数据，流量较大，速度较慢。

➢FastCopy

1. 开源社区的无需拷贝数据的快速元数据迁移方案

2. 前提条件:新旧集群的DN列表吻合

3. 对于元数据，直接复制目录树的结构和块信息。

4. 对于数据块，直接要求DataNode从源BlockPool hardlink到目标BlookPool,没有数据拷贝。

5. hardlink: 直接让两个路径指向同一块数据。

4.4.2数据迁移工具一Balancer

工具向DataNode发起迁移命令，平衡各个DataNode的容量。

场景

1. 单机房使用、多机房使用

2. 限流措施

评价标准

1. 稳定性成本 2) 可运维性 3) 执行效率

结语

HDFS作为大数据离线分析场景的核心组件，高可用和高扩展性是架构设计的重中之重。

高可用确保了业务能稳定运行，HDFS .上存储的数据随时可以访问。

高扩展性确保了HDFS能存储的数据量能随着资源投入无限扩展下去，业务发展不被基础组件拖累。

字节跳动HDFS依然在持续迭代，在元数据扩展性、数据治理与调度、数据生态体系、单机存储引擎、云上存储等方向依然大有可为。