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