大数据| 青训营笔记

94 阅读2分钟

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

HDFS高可用和高扩展机制分析

故障类型:软件故障;硬件故障;人为故障 灾难:数据中心级别不可用 故障不可避免,灾难时有发生 而如果HDFS系统不可用: 无法核算广告账单,直接引发收入损失; 无法生产数据报表,数据驱动无从谈起; 无法进行模型训练,引起用户体验下滑。 服务高可用:热备份;冷备份 故障恢复操作:人工切换;自动切换

HDFS NameNode高可用架构

image.png

状态机复制是实现容错的常规方法。 组件:状态以及其副本;变更日志;共识协议 日志系统:高可用;高扩展性;高性能;强一致(有序)

分布式协调组件-ZooKeeper

一般用于提供选主,协调,元数据存储 HA核心机制:Watch BookKeeper存储日志:低延时;持久性;强一致性;读写高可用

Quorum机制

多副本一致性读写 场景:多副本对象存储,用版本号标识数据新旧 在有冗余数据的分布式存储系统当中,冗余数据对象会在不同的机器之间存放多份拷贝。但是同一时刻一个数据对象的多份拷贝只能用于读或者用于写。

该算法可以保证同一份数据对象的多份拷贝不会被超过两个访问对象读写。

算法来源于[Gifford, 1979][3][1]。 分布式系统中的每一份数据拷贝对象都被赋予一票。每一个读操作获得的票数必须大于最小读票数(read quorum)(Vr),每个写操作获得的票数必须大于最小写票数(write quorum)(Vw)才能读或者写。如果系统有V票(意味着一个数据对象有V份冗余拷贝),那么最小读写票数(quorum)应满足如下限制:

Vr + Vw > V Vw > V/2

BookKeeper Quorum

Sloppy Quorum机制 场景:顺序追加,只写 Write Quorum:写入副本数 Ack Quorum:响应副本数

RAID方案

image.png

多机房解决的问题:容量问题;容灾问题 HDFS双机房放置的设计:写入时,每个数据块在两个机房至少各有一个副本,数据实时写入到两个机房;读取时,优先读本地的副本,避免了大量的跨机房读取

元数据节点扩展性的挑战

HDFS NameNode是个集中式服务,部署在单个机器上,内存和磁盘容量,CPU的计算力都不能无限拓展, 挑战:名字空间分裂;DataNode汇报;目录树结构本身复杂

慢节点

image.png