这是我参与「第四届青训营 」笔记创作活动的的第5天
今天的笔记主要分为四个部分：
一、元数据高可用
二、数据存储高可用
三、元数据高扩展性
四、数据存储高扩展性
一、元数据服务高可用
1.高可用的需求
1.1服务高可用的需求
故障类型：
-硬件故障
-软件故障
-人为故障
灾难：数据中心级别不可用
-机房断电
-机房空调停机
-机房间网络故障、拥塞
故障不可避免，灾难时有发生
而如果HDFS系统不可用
-无法核算广告账单，直接引发收入损失
-无法生产数据报表，数据驱动无从谈起
-无法进行模型训练，用户体验越来越差
业务停止的损失极大，所以HDFS系统的高可用性就至关重要
1.2高可用的衡量
服务可用性指标：MTTR、MTTF、MTBF
1.3可用性的年化
可用性：
全年不可用时间：
-可用性99.9%，全年8.76小时不可用
-可用性99.99%，全年52.6分钟不可用
-可用性99。999%，全年5.26分钟不可用
1.4高可用的形式
服务高可用：热备份，冷备份
故障恢复操作：人工切换，自动切换
人工的反应、决策时间都更长，高可用需要让系统自动决策。
HDFS的设计中，采用了中心化的元数据管理节点NameNode。NameNode容易成为故障中的单点。
2.HDFS主备同步实现 2.1HDFS NameNode高可用框架
组件介绍：
-ActiveNameNode：主节点，提供服务，生产日志
-StandbyNamenode：备节点，消费日志
-Zookeeper：为自动选主提供统一协调服务
-BookKeeper：提供日志存储服务
-ZKFC：NameNode探活，触发主备切换
围绕三个问题来看高可用性：
-节点状态如何保存
-操作日志如何同步
-如何做到自动切换
2.2理论基础-状态机复制和日志
状态机复制是实现容错的常规方法
组件：
-状态机及其副本
-变更日志
-共识协议
2.3NameNode状态持久化
FSimage和EditLog
3.HDFS自动主备切换
3.1分布式协调组件-ZooKeeper
一般用于提供选主、协调、元数据存储
使用它的组件：
-HDFS、YARN、HBase
-Kafka、ClickHouse
3.2自动主备切换流程-Server侧
ZKFailoverController作为外部组件，驱动HDFS NameNode的主备切换
轮询探活、脑裂问题、Fence机制
3.3自动主备切换流程-Client侧
核心机制：StandbyException、Client自动处理
4.日志系统BookKeeper简介
4.1BookKeeper架构
BookKeeper存储日志：
-低延时
-持久性
-强一致性
-读写高可用
对比：日志系统和文件系统的复杂度
4.2BookKeeper Quorum
Sloppy Quorum机制
日志场景：顺序追加、只写
Write Quorum：写入副本数
Ack Quorum：响应副本数
二、数据存储高可用
1.单机存储的数据高可用机制
1.1单机存储RAID
特点：廉价、高性能、大容量、高可用
2.HDFS的数据高可用机制
2.1HDFS多副本
图：Hadoop的多副本放置
优点：
-读写路径简单
-副本修复简单
-高可用
2.2Erasure Coding原理
业界常用Read Solomon算法（原理如图所示）
3.考虑网络架构的数据高可用
3.1网络架构
机架如下
网络拓扑图如下：
3.2副本放置策略-机架感知
一个TOR故障导致整个机架不可用 VS 降低跨rack流量
trade-off：一个本地、一个远端
图：HDFS的多机架放置
三、元数据高扩展性
1.元数据扩展性挑战
1.1挑战概述
HDFS NameNode是个集中式服务器，部署在单个机器上，内存和磁盘的容量，CPU的计算力都不能无限扩展
scale up VS scale out：
-扩容单个服务器的能力
-部署多个服务器来服务
挑战：
-名字空间分裂
-DataNode汇报
-目录树结构本身复杂
1.2常见的Scale Out方案
KV模型的系统可以使用partition：Redis、kafka\MySQL
下图：三种数据路由方式
2.社区的解决方案
2.1BlockPool
解决DN同时服务多组NN的问题
文件服务分层：Namespace、Block Storage
用blockpool来区分DN的服务：
-数据块存储
-心跳和块上报
2.2viewfs
Federation架构：将多个不同集群组合起来，对外表现像一个集群一样
下图：viewfs通过在client-side的配置，指定不同的目录访问不同的nameNode
3.字节的NNProxy方案
NNproxy是ByteDance自研的HDFS代理层，提供了路由服务
NNProxy主要是实现了路由管理和RPC转发以及鉴权、限流、查询缓存等额外能力
四、存储数据的高扩展性
1.超大集群的长尾问题
1.1延迟的分布和长尾延迟
延迟的分布：
-用百分数来表示访问的延迟的统计特征
-例如p95延迟为1ms，代表95%的请求延迟要低于1ms，但后5%的请求延迟会大于1ms
长尾延迟：尾部的延迟，衡量系统最差的请求的情况，会显著的要差于平均值
1.2尾部延迟放大
木桶原理
尾部延迟放大：访问的服务变多，尾部的请求就会越发的慢
如何变慢：固定延迟阈值，固定延迟百分位
2.超大集群的可靠性问题
2.1超大集群下的数据可靠性
条件一：超大集群下，有一部分机器是损坏来不及修理的
条件二：副本放置策略完全随机
条件三：DN的容量足够大
2.2Copyset
将DataNode分为若干个Copyset，选块在copyset内部选择
原理：减少了副本放置的组合数，从而降低副本丢失的概率
3.超大集群的不均匀问题
3.1数据写入不均匀
数据的不均匀：
-节点容量不均匀
-数据新旧不均匀
-访问类型不均匀
资源负载不均匀
3.2DN冷热不均匀
3.3负载均衡和数据迁移的典型场景
4.数据迁移工具速览
4.1跨NN迁移
DistCopy
-基于MapReduce，通过一个个任务，将数据从一个NameNode拷贝到另一个NameNode
-需要拷贝数据，流量较大，速度较慢
FastCopy
-开源社区的无需拷贝数据的快速元素数据迁移方案
-前提条件：新旧集群的DN列表吻合
-对于元数据，直接复制目录树的结构和块信息
-对于数据块，直接要求DataNode从源Block Pool hardlink到目标BlockPool，没有数据拷贝
-hardlink：直接让两个路径指向同一块数据
4.2Balancer
工具向DataNode发起迁移命令，平衡各个DataNode的容量
场景：
-单机房使用、多机房使用
-限流措施
评价标准：稳定性成本、可运维性、执行效率
