这是我参与「第四届青训营 」笔记创作活动的的第9天。
本节课程主要分为 4 个方面：
1.元数据高可用
2.数据存储高可用
3.元数据高扩展性
4.数据存储高扩展性
一.元数据服务高可用
1.1.服务高可用的需求
高可用：系统在困境（adversity，比如硬件故障、软件故障、人为错误）中仍可正常工作（正确完成功能，并能达到期望的性能水准)。
故障类型：
■ 硬件故障
■ 软件故障
■ 人为故障
灾难：
■ 机房断电
■ 机房空调停机
■ 机房间网络故障、拥塞
1.1.1.高可用的衡量
■ MTTR(Mean Time To Repair)：平均修复时间，系统能多快恢复。
■ MTTF(Mean Time To Failure)：平均失效时间，运行到故障间的时间，一般用于不可修复的系统(制造业)。
■ MTBF(Mean Time Between Failures)：平均无故障时间，两次故障间的间隔，一般用于可修复的系统(软件)。
1.1.2.可用性的年化
全年不可用时间：系统运行一整年的不可用时间的目标。
● 可用性 99.9%，全年8.76小时不可用
● 可用性 99.99%，全年52.6小时不可用
● 可用性 99.999%，全年5.26小时不可用
1.1.3.高可用的形式
✔ 服务高可用
◎ 热备份
主服务和备服务同时运行，在主服务故障时，随时可以切换到备服务。
◎ 冷备份
备份服务的数据，可以和数据归档相结合。在主服务故障时，利用备份的数据重启。
✔ 故障恢复操作
◎ 人工切换
在故障发生时，运维人员接收报警后，手动执行服务切主操作。一般较慢，难以满足全年不可用时间的目标。
◎ 自动切换
通过探活组件、分布式共识协议等手段，系统能自动发现主服务的故障，并切换到备份不符。
单点故障 SPOF：指系统中一旦失效，就会让整个系统无法运作的组件。
1.2.HDFS NameNode高可用架构
✔ 组件介绍
● Active NameNode：提供服务的NameNode主节点，生产 editlog。
● Standby NameNode：不提供服务，起备份作用的 NameNode 备节点，消费 editlog。
● editlog：用户变更操作的记录，具有全局顺序，是 HDFS 的变更日志。
● ZooKeeper：开源的分布式协调组件，主要功能有节点注册、主节点选举、元数据存储。
● BookKeeper：开源的日志存储组件，存储 editlog。
● ZKFC：和 ZK、NN 通信，进行 NN 探活和自动主备切换。
● HA Client：处理 StandbyException，在主备节点间挑选到提供服务的主节点。
1.2.1.理论基础-状态机复制和日志
状态机复制是实现容错的常规方法。
组件：
◌ 状态机以及其副本：
一个状态机从“初始”状态开始，每一个输入都被传入转换函数和输出函数，以生成一个新的状态和输出。在新的输入被接收到前，状态保持不变，而输出同时被传输给恰当的接受者。
确定性的状态机具有「处理确定的输入后，状态唯一确定」的特性。状态机复制利用这个特性实现多个相同的状态机副本的同步更新。
◌ 变更日志：
触发状态机更新的变更操作，具有全局确定的顺序。
◌ 共识协议
确保每个副本都能收到相同的日志的共识协议，常见的有 Paxos、Raft、ZAB。
1.2.2.NameNode状态化持久化
◆ FSImage 文件：较大的状态记录文件，是某一时刻NN全部需要持久化的数据的记录。大小一般在GB级别。
◆ EditLog 文件：是某段时间发生的变更日志的存储文件。大小一般在KB~MB级别。
◆ checkpoint 机制：将旧的 FSImage 和 EditLog 合并生成新的 FSImage的流程，在完成后旧的数据可以被清理以释放空间。
1.2.3.NameNode操作日志的生产
Active生产，Standby(可能有多个)消费
物理日志：存储了物理单元(一般是磁盘的 page)变更的日志形式。
逻辑日志：存储了逻辑变更(例如 rename /a to /b)的日志形式。
日志系统：
○ 高扩展性 ○ 高可用 ○ 高性能 ○强一致(有序)
1.3.分布式协调组件-Zookeeper
一般用于提供选主、协调、元数据存储
HA核心机制：Watch
1.3.1.自动主备切换流程-Server侧:
□ 轮询探活
□ 脑裂问题：
因为网络隔离、进程夯住(例如 Java GC)等原因，旧的 active NN 没有完成下主，新的 active NN 就已经上主，此时会存在双主。client 的请求发给两者都可能成功，但不能保证一致性(两个 NN 状态不再同步)和持久化(只能保留一个 NN 状态)。
□ Fence机制：
在新active NN上主并正式处理请求之前，先要确保旧active NN 已经退出主节点的状态。一般做法是先用 RPC 状态检测，发现超时或失败则调用系统命令杀死旧active NN的进程。
1.3.2.自动主备切换流程-Client侧
□ 核心机制：StandbyException
□ Client自动处理
1.4.BookKeeper架构
BookKeeper存储日志；
○ 低延迟 ○ 持久性 ○ 强一致性 ○读写高可用
对比：日志系统和文件系统的复杂度
1.4.1.Quorum机制
Quorum机制：多副本一致性读写
1.4.2.Ensemble机制
优势：数据均衡
二.数据存储高可用
2.1.单机存储的数据高可用机制
2.1.1.回到单机存储-RAID
RAID：将多个廉价、不可靠、低性能、容量小的磁盘组装在一起，提供高可靠、高性能、大容量逻辑磁盘服务的一组磁盘列阵方案。
◎ RAID 0 ：将数据分块后按条带化的形式分别存储在多个磁盘上，提供大容量、高性能。
◎ RAID 1：将数据副本存储在多个磁盘上，提供高可靠。
◎ RAID 3：在数据分块存储的基础上，将数据的校验码存储在独立的磁盘上，提供高可靠、高性能。
特点：◎ 廉价
◎ 高性能
◎ 大容量
◎ 高可用
2.2.HDFS的数据高可用机制
2.2.1.HDFS副本
多副本方案：将数据块存储在多个 DN 上
优点：
◎ 读写路径简单 ◎ 副本修复简单 ◎ 高可用
2.2.2.Erasure Coding原理
Erasure Coding 方案：将数据分段，通过特殊的编码方式存储额外的校验块，并条带化的组成块，存储在 DN 上。
特点：
◎ 条带化：原本块对应文件内连续的一大段数据。条带化后，连续的数据按条带（远小于整个块的单位）间隔交错的分布在不同的块中。
◎ Reed Solomon 算法
◎ 成本更低：多副本方案需要冗余存储整个块，EC 方案需要冗余存储的数据一般更少。
2.3.考虑网络架构的数据高可用
2.3.1.网络架构
机架/机柜(Rack)：将几个服务器统一供电、提供对外网络的固定的物理设备。
TOR(top of rack)：机架顶部（或底部）的交换机，负责机架内服务器和数据中心的其他服务器的网络通信。
数据中心(Data Center)：集中部署服务器的场所。
网络拓扑：按数据中心->机架->机器的顺序，描述进程在网络空间中所处的位置。
2.3.2.副本放置策略-机架感知
一个TOR故障导致整个机架不可用 VS 降低跨rack流量
trade-off：一个本地、一个远端
2.4.案例
2.4.2.多机房容灾实践:
多机房容灾：服务和数据需要存放在多个机房，并配合合理的架构。使得发生机房故障时依然可以提供服务。
三.元数据高扩展性
3.1.元数据扩展性挑战
3.1.1.元数据节点扩展性的挑战
scale up VS scale out
■ 扩容单个服务器的能力
■ 部署多个服务器来服务
◇ scale up：通过单机的 CPU、内存、磁盘、网卡能力的提升来提升系统服务能力，受到机器成本和物理定律的限制。
◇ scale out：通过让多台机器组成集群，共同对外提供服务来提升系统服务能力。一般也称为高扩展、水平扩展。
3.1.2.常见的Scale out方案
KV模型的系统可以使用partition:
● Redis
● Kafka
● MySQL(分库表)
3.2.社区的解决方案
3.2.1.BlockPool:
✔ 将文件系统分为文件层和块存储层，对于块存储层，DN 集群对不同的 NN 提供不同的标识符，称为 block pool。
✔ 解决了多个 NN 可能生成同一个 block id，DN 无法区分的问题。
文件服务分层：
◎ Namespace
◎ Block Storage
用BlockPool来区分DN的服务:
◎ 数据块存储
◎ 心跳和块上报
3.2.2.viewfs
Federation 架构：
○ 使得多个集群像一个集群一样提供服务的架构方法，提供了统一的服务视图，提高了服务的扩展性。
○ 文件系统的目录树比 kv 模型更复杂，划分更困难。
○ 邦联架构的难点一般在于跨多个集群的请求，例如 HDFS 的 rename 操作就可能跨多个集群。
viewfs：
○ 邦联架构的一种实现，通过客户端配置决定某个路径的访问要发送给哪个 NN 集群。
○ 缺点：客户端配置难以更新、本身配置方式存在设计（例如，只能在同一级目录区分；已经划分的子树不能再划分）
3.3.字节跳动的NNProxy方案
NNProxy：
✔ ByteDance 自研的 HDFS 代理层，于 2016 年开源
✔ 主要提供了路由管理、RPC 转发，额外提供了鉴权、限流、查询缓存等能力。
✔ 开源社区有类似的方案 Router Based Federation，主要实现了路由管理和转发
3.4.案例
小文件问题：
✔ HDFS 设计上是面向大文件的，小于一个 HDFS Block 的文件称为小文件。
✔ 元数据问题：多个小文件相对于一个大文件，使用了更多元数据服务的内存空间。
✔ 数据访问问题：多个小文件相对于一个大文件，I/O 更加的随机，无法顺序扫描磁盘。
✔ 计算任务启动慢：计算任务在启动时，一般会获得所有文件的地址来进行 MapReduce 的任务分配，小文件会使得这一流程变长。
✔ 典型的 MR 流程中，中间数据的文件数和数据量与 mapper*reducer 的数量成线性，而为了扩展性，一般 mapper 和 reducer 的数量和数据量成线性。于是，中间数据的文件数和数据量与原始的数据量成平方关系。
✔ 小文件合并任务：计算框架的数据访问模式确定，可以直接将小文件合并成大文件而任务读取不受影响。通过后台运行任务来合并小文件，可以有效缓解小文件问题。通过 MapReduce/Spark 框架，可以利用起大量的机器来进行小文件合并任务。
✔ Shuffle service：shuffle 流程的中间文件数是平方级的，shuffle service 将 shuffle 的中间数据存储在独立的服务上，通过聚合后再写成 HDFS 文件，可以有效地缓解中间数据的小文件问题。
四.存储数据高扩展性
4.1.超大集群的长尾问题
4.1.1.延迟的分布和长尾延迟
延迟的分布：
1).将所有请求的响应速度从快到慢排序，取其中某百分位的请求的延迟时间。
2).例如 pct99 代表排在 99% 的请求的延迟。相对于平均值，能更好的衡量长尾的情况。
长尾延迟：
1). 二八定律：在任何一组东西中，最重要的只占其中一小部分，约20%，其余80%尽管是多数，却是次要的。
2).长尾：占绝大多数的，重要性低的东西就被称为长尾。
4.1.2.尾部延迟放大
1).木桶原理：并行执行的任务的耗时取决于最慢的一个子任务。
2).尾部延迟放大：一个请求或任务需要访问多个数据节点，只要其中有一个慢，则整个请求或任务的响应就会变慢。
3).固定延迟阈值，访问的集群越大， 高于该延迟的请求占比越高。
4).固定延迟百分位，访问的集群越大，延迟越差。
4.1.3.长尾问题的表现-慢节点
慢节点：读取数据过慢，导致客户端阻塞。
1).尾部延迟放大+集群规模变大，使得大集群中，尾部延迟对于整个服务的质量极为重要。
2).慢节点问题：网络不会直接断联，而是不能在预期的时间内返回。会导致最终请求不符合预期，而多副本机制无法直接应对这种问题。
3).高负载：单个节点处理的请求超过了其服务能力，会引发请求排队，导致响应速度慢。是常见的一个慢节点原因。
4.2.超大集群的可靠性问题
4.2.1.超大集群下的数据可靠性
✔ 超大集群下，一定有部分机器是损坏的，来不及修理的。
✔ 随机的副本放置策略，所有的放置组合都会出现。而DN容量够大，足够。
✔ 三副本，单个DN视角：容量一百万，机器数量一万。那么另外两个副本的排列组合有一亿种，容量比放置方案大约百分之一。
✔ 三副本，全局视角：一万台机器，每台一百万副本，损坏1%(100台)。根据排列组合原理，大约有1009998/(1000099999998)(100000010000)=9704个坏块。
✔callback一下，叠加长尾问题。每个任务都要访问大量的块，只要一个块丢失就整个任务收到影响。导致任务层面的丢块频发，服务质量变差。
4.2.2.Copyset
◌ 降低副本放置的组合数，降低副本丢失的发生概率。
◌ 修复速度：DN机器故障时，只能从少量的一些其他DN上拷贝数据修复副本。
4.3.超大集群的不均匀问题
4.3.1.超大集群的负载均衡和数据迁移
负载均衡：
■ 避免热点：
□ 机器热点会叠加长尾问题，少数的不均衡的热点会影响大量的任务。
■ 成本：
□ 数据越均衡，CPU、磁盘、网络的利用率越高，成本更低。 □ 集群需要为数据腾挪预留的空间、带宽更少，降低了成本。
■ 可靠性：
□ 全速运行的机器和空置的机器，以及一会全速运行一会空置的机器，可靠性表现都有不同。负载均衡可以降低机器故障的发生。 □ 同一批机器容易一起故障，数据腾挪快，机器下线快，可以提升可靠性。
4.3.2.数据写入不均衡
1).节点容量不均匀
2).数据新旧不均匀
3).访问类型不均匀
4.3.2.DN冷热不均衡
1).节点容量不均匀
2).数据新旧不均匀
3).访问类型不均匀
4.4.数据迁移工具速览
4.1.1.数据迁移工具-跨NN迁移
■ DistCopy 工具：
◎ 通过 MapReduce 任务来并行迁移数据，需要拷贝数据和元数据。
◎ 网络流量较大，速度较慢。
■ FastCopy 工具：
◎ 基于 hardlink 和 blockpool 的原理
◎ 元数据直接在 NN 集群间拷贝，而数据则在 DN 上的不同 blockpool(对应到 NN 集群)进行 hardlink，不用数据复制。
◎ 迁移速度要大大优于 DistCopy。
4.4.2.数据迁移工具-Balancer
■ Balancer 工具:
◎ 代替 NN 向 DN 发起副本迁移的命令，批量执行副本迁移。
◎ 场景：大规模数据平衡、机器上下线。
