这是我参与「第四届青训营」笔记创作活动的第9天
0 引言
HDFS通过将文件分块来存储大文件，HDFS的组件有NameNode和DataNode，分别负责提供元数据和数据服务。
在读/写数据时，HDFS客户端需要先从NameNode上获取数据读取/写入的DataNode地址，然后和DataNode交互来完成数据读/写。
1 元数据高可用
1.1 高可用的需求
当系统软硬件出现故障或者机房出问题时，防止造成项目损失，有效的高可用系统就显得很重要。
故障处理流程：
故障发生
->故障发现(notification)->故障定位(location)->
开始修复
->修复(fix)->测试(testing)->恢复(recovery)->
恢复正常
衡量高可用的指标有：
- 平均修复时间（Mean time to repair，MTTR）
- 平均失效前时间（mean time to failures，MTTF）
- 平均无故障工作时间（Mean Time Between Failure，MTBF）
可用性定义：
服务高可用：热备份（A故障，紧急启动B）、冷备份（A故障，备份数据导入B再启动）
HDFS作为分布式结构，采用了中心化的元数据管理节点NameNode。NameNode容易成为故障中的单点(single point of failure)。【在分布式系统或多系统共用的ESB系统容易造成单点故障，很严重，因此高可用性很重要】
1.2 HDFS主备同步实现
HDFS高可用架构：
组件介绍：
- ActiveNamenode：主节点，提供服务，生产日志
- StandbyNamenode：备节点，消费日志
- ZooKeeper：为自动选主提供统一协调服务
- BookKeeper：提供日志存储服务
- ZKFC：NameNode探活、触发主备切换
- HA Client：提供了自动切换的客户端
- editlog：操作的日志
节点状态如何保存？
状态机复制是实现容错的常规方法。组件包括状态机以及其副本、变更日志、共识协议。
应对状态持久化（FSlmage和EditLog、Checkpoint机制）
操作日志如何同步？
Active生产，Standby(可能有多个)消费。物理日志与逻辑日志。日志系统：高可用、高扩展性、高性能、强一致(有序)。
如何做到自动切换？
DataNode中Heartbeat（心跳）和Block Report（状态上报）可以对块信息上报给NN。
Active接收和发起变更，Standby只接收不发起变更。
使用Content Stale状态，主备切换后，避免DN的不确定状态（假如有多个NN可工作，找到适合的）。
1.3 HDFS自动主备切换
分布式协调组件：ZooKeeper（一般用于提供选主、协调、元数据存储）
HA（High Available）核心机制:Watch
Server端：
ZKFailoverController（ZKFC）：作为外部组件，驱动HDFS NameNode的主备切换。
轮询探活：
脑裂问题：
Fence机制：
Client端：
核心机制: StandbyException
Client自动处理
1.4 日志系统BookKeeper简介
BookKeeper架构：
BookKeeper存储日志：低延时、持久性、强一致性、读写高可用。
Quorum机制:
多副本一致性读写（多副本对象存储，用版本号标识数据新旧）
规则：
Sloppy Quorum机制：
Write Quorum:写入副本数。Ack Quorum:响应副本数（日志场景:顺序追加、只写）
Ensemble机制：
优势:数据均衡
2 数据存储高可用
2.1 单机存储的数据高可用机制
Redundant Array of Independent Disks（RAID）：独立磁盘冗余阵列是一种将多个磁盘驱动器组件（通常是多块硬盘或多个分区）组合为一个逻辑单元的存储技术，从而提供比单个硬盘更高的存储性能和更可靠的数据备份技术。（他的特点有：廉价、高性能、大容量、高可用）
- RAID0:条带化
- RAID 1:冗余
- RAID 3:容错校验
2.2 HDFS的数据高可用机制
HDFS多副本（HDFS版本的RAID1。优点：读写路径简单、副本修复简单、高可用）
Erasure Coding原理（HDFS版本的RAID2/3。业界常用Reed Solomon算法实现）
HDFS Erasure Coding（HDFS版本的RAID2。）
2.3 考虑网络架构的数据高可用
机架(Rack):放服务器的架子。
TOR(Top of Rack):机架顶部的交换机。
数据中心(Data Center):集中部署服务器的场所
副本放置策略―机架感知（trade-off:一个本地、一个远端）
2.4 案例:字节跳动的HDFS多机房容灾方案简介
HDFS双机房放置的设计：
- 写入时，每个数据块在两个机房至少各有一个副本，数据实时写入到两个机房。
- 读取时，优先读本地的副本，避免了大量的跨机房读取。
3 元数据高扩展性
3.1 元数据扩展性挑战
元数据由NN存储，HDFS NameNode是个集中式服务，部署在单个机器上，内存和磁盘的容量、CPU的计算力都不能无限扩展。
因此，两种办法：scale up（扩容单个服务器的能力）、scale out（部署多个服务器来服务）。
需要格外注意：名字空间分裂、DataNode汇报、目录树结构本身复杂问题。
KV模型的系统可以使用partition：Redis、Kafka、MySQL(分库分表)
三种数据路由方式：服务端侧、路由层、客户端侧
3.2 社区的解决方案
BlockPool：
解决DN同时服务多组NN的问题
文件服务分层： Namespace、Block Storage
用blockpool来区分DN的服务：数据块存储、心跳和块上报
viewfs：
Federation架构:将多个不同集群组合起来，对外表现像─一个集群一样。
图表示:viewfs通过在client-side的配置,指定不同的目录访问不同的NameNode。
局限性:运维复杂
3.3 字节跳动的NNProxy方案
NNProxy是HDFS代理层，提供了路由服务
NNProxy主要实现了路由管理和RPC转发，以及鉴权、限流、查询缓存等额外能力。 （路由规则、目录树采用路径最长匹配规则）
3.4 案例:小文件问题
小文件问题(LSOF，lots of small files)：大小不到一个HDFS Block大小的文件过多，导致NameNode瓶颈 、I/O变小，数据访问变慢、计算任务启动慢等问题。
解决方案：后台任务合并小文件、Shuffle Service
4 数据存储高扩展性
4.1 超大集群的长尾问题
延迟的分布：用百分数来表示访问的延迟的统计特征。
例如p95延迟为1ms，代表95%的请求延迟要低于1ms，但后5%的请求延迟会大于1ms。
长尾延迟:尾部(p99/p999/p999)的延迟，衡量系统最差的请求的情况。会显著的要差于平均值。
尾部延迟放大：访问的服务变多，尾部的请求就会越发的慢（木桶原理）。变慢原因是固定延迟阈值，固定延迟百分位。
4.2 超大集群的可靠性问题
Copyset：
将DataNode分为若干个Copyset，选块在Copyset内部选择
原理：减少了副本放置的组合数，从而降低副本丢失的概率。
思考：缺陷是什么?
我个人认为是会增加读写的复杂度，相当于在DN上面套了一层。通过查资料：节点数相对变化太大不适合，初始的copyset数量的不确定。
4.3 超大集群的不均匀问题
数据的不均匀（节点容量不均匀、数据新旧不均匀、访问类型不均匀）和资源负载不均匀，在HDFS中表现为数据写入不均、DN冷热不均。解决办法就是负载均衡。
4.4 数据迁移工具速览
跨NN迁移
DistCopy
- 基于MapReduce，通过一个个任务，将数据从一个NameNode拷贝到另一个NameNode。
- 需要拷贝数据，流量较大，速度较慢。
FastCopy
- 开源社区的无需拷贝数据的快速元数据迁移方案。
- 前提条件:新旧集群的DN列表吻合。
- 对于元数据，直接复制目录树的结构和块信息。
- 对于数据块，直接要求DataNode从源BlockPool hardlink到目标BlookPool，没有数据拷贝。
- hardlink:直接让两个路径指向同一块数据。
Balancer
工具向DataNode发起迁移命令，平衡各个DataNode的容量。
使用场景：单机房使用、多机房使用限流措施。
评价标准：稳定性成本、可运维性、执行效率。
参考信息
1.【大数据专场 学习资料三】第四届字节跳动青训营
2. 字节跳动10万节点HDFS集群多机房架构演进之路
3. 带你入坑大数据（一） --- HDFS基础概念篇
4. Hadoop HA
5. 轮询和长轮询的区别
6. ZooKeeper集群脑裂问题处理，值得收藏！
7. 器 | 快速入门RAID
8. Copyset Replication及其在Curve分布式存储数据均衡分布策略的应用
