课程资料
课程链接：https://live.juejin.cn/4354/yc_HDFSavailability
学员手册：https://juejin.cn/post/7124948585614934029#heading-24
课程PPT：https://bytedance.feishu.cn/file/boxcn9VL4rJ4pBplxDzBiMOLqpc
完整手册：https://bytedance.feishu.cn/docx/doxcnECGEFkCKYqbxaDipK1qrVf
一、元数据高可用
高可用的需求
故障类型：硬件故障、软件故障、人为操作不当、机房断电、机房空调停机、机房网络拥塞
可用性：99.9%，全年8.76小时不可用；99.99%，全年52.6分钟不可用；99.999%，全年5.26分钟不可用（难度高）
HDFS高可用架构
- Active NameNode：提供服务的 NameNode 主节点，生产 editlog。
- Standby NameNode：不提供服务，起备份作用的 NameNode 备节点，消费 editlog
- editlog：用户变更操作的记录，具有全局顺序，是 HDFS 的变更日志。
- ZooKeeper：开源的分布式协调组件，主要功能有节点注册、主节点选举、元数据存储。
- BookKeeper：开源的日志存储组件，存储 editlog
- ZKFC：和 ZK、NN 通信，进行 NN 探活和自动主备切换。
- HA Client：处理 StandbyException，在主备节点间挑选到提供服务的主节点。
HDFS主备切换
- DataNode 心跳与块汇报需要同时向 active NN 和 standby NN 上报，让两者可以同时维护块信息。但只有 active NN 会下发 DN 的副本操作命令。
content stale 状态：在发生主备切换后，新 active NN 会标记所有 DN 为 content stale 状态，代表该 DN 上的副本是不确定的，某些操作不能执行。直到一个 DN 完成一次全量块上报，新 active NN 才标记它退出了 content stale 状态。
- 例子，多余块的删除：NN 发现某个块的副本数过多，会挑选其中一个 DN 来删除数据。在主备切换后，新 active NN 不知道旧 active NN 挑选了哪个副本进行删除，就可能触发多个 DN 的副本删除，极端情况下导致数据丢失。content stale 状态的引入解决了这个问题。
- 脑裂问题：因为网络隔离、进程夯住（例如 Java GC）等原因，旧的 active NN 没有完成下主，新的 active NN 就已经上主，此时会存在双主。client 的请求发给两者都可能成功，但不能保证一致性（两个 NN 状态不再同步）和持久化（只能保留一个 NN 状态）。
- fence 机制：在新 active NN 上主并正式处理请求之前，先要确保旧 active NN 已经退出主节点的状态。一般做法是先用 RPC 状态检测，发现超时或失败则调用系统命令杀死旧 active NN 的进程。
日志系统BookKeeper简介
- 高可靠：数据写入多个存储节点，数据写入就不会丢失。
- 高可用：日志存储本身是高可用的。因为日志流比文件系统本身的结构更为简单，日志系统高可用的实现也更为简单。
- 强一致：日志系统是追加写入的形式，Client 和日志系统的元数据可以明确目前已经成功的写入日志的序号（entry-id）。
- 可扩展：整个集群的读写能力可以随着添加存储节点 Bookie 而扩展。
二、数据存储高可用
RAID方案
多副本方案
数据中心架构
- 机架/机柜：将几个服务器统一供电、提供对外网络的固定的物理设备。
- TOR top of rack：机架顶部（或底部）的交换机，负责机架内服务器和数据中心的其他服务器的网络通信。
机房和数据中心都是指大量服务器集中放置的场所。
- 机房：强调的基础设施建设，例如物理承重、空调、防水、消防。
- 数据中心：强调机房的业务属性。
- 网络拓扑：按数据中心->机架->机器的顺序，描述进程在网络空间中所处的位置。
跨机房专线：由网络服务商提供，连接机房的专用网络。
- 稳定性和安全性好于公网。
- 相比于数据中心内网络，吞吐更为有限、延迟更高、成本更高。
三、元数据高扩展性
扩展性方案
- scale up：通过单机的 CPU、内存、磁盘、网卡能力的提升来提升系统服务能力，受到机器成本和物理定律的限制。
- scale out：通过让多台机器组成集群，共同对外提供服务来提升系统服务能力。一般也称为高扩展、水平扩展。
partition 方法
- 水平分区和垂直分区：水平分区指按 key 来将数据划分到不同的存储上；垂直分区指将一份数据的不同部分拆开存储，用 key 关联起来。partition 一般都水平分区，又称 shard。
- 常用于 KV 模型，通过 hash 或者分段的手段，将不同类型 key 的访问、存储能力分配到不同的服务器上，实现了 scale out。
- 重点：不同单元之间不能有关联和依赖，不然访问就难以在一个节点内完成。例如 MySQL 的分库分表方案，难以应对复杂跨库 join。
federation 架构
- 使得多个集群像一个集群一样提供服务的架构方法，提供了统一的服务视图，提高了服务的扩展性。
- 文件系统的目录树比 kv 模型更复杂，划分更困难。
- 邦联架构的难点一般在于跨多个集群的请求，例如 HDFS 的 rename 操作就可能跨多个集群。
blockpool
- 将文件系统分为文件层和块存储层，对于块存储层，DN 集群对不同的 NN 提供不同的标识符，称为 block pool。
- 解决了多个 NN 可能生成同一个 block id，DN 无法区分的问题。
viewfs
- 邦联架构的一种实现，通过客户端配置决定某个路径的访问要发送给哪个 NN 集群。
- 缺点：客户端配置难以更新、本身配置方式存在设计（例如，只能在同一级目录区分；已经划分的子树不能再划分）。
NNProxy
- ByteDance 自研的 HDFS 代理层，于 2016 年开源，项目地址： github.com/bytedance/n…
- 主要提供了路由管理、RPC 转发，额外提供了鉴权、限流、查询缓存等能力。
- 开源社区有类似的方案 Router Based Federation，主要实现了路由管理和转发。
小文件问题
- HDFS 设计上是面向大文件的，小于一个 HDFS Block 的文件称为小文件。
- 元数据问题：多个小文件相对于一个大文件，使用了更多元数据服务的内存空间。
- 数据访问问题：多个小文件相对于一个大文件，I/O 更加的随机，无法顺序扫描磁盘。
- 计算任务启动慢：计算任务在启动时，一般会获得所有文件的地址来进行 MapReduce 的任务分配，小文件会使得这一流程变长。
- 典型的 MR 流程中，中间数据的文件数和数据量与 mapper*reducer 的数量成线性，而为了扩展性，一般 mapper 和 reducer 的数量和数据量成线性。于是，中间数据的文件数和数据量与原始的数据量成平方关系。
- 小文件合并任务：计算框架的数据访问模式确定，可以直接将小文件合并成大文件而任务读取不受影响。通过后台运行任务来合并小文件，可以有效缓解小文件问题。通过 MapReduce/Spark 框架，可以利用起大量的机器来进行小文件合并任务。
- Shuffle service：shuffle 流程的中间文件数是平方级的，shuffle service 将 shuffle 的中间数据存储在独立的服务上，通过聚合后再写成 HDFS 文件，可以有效地缓解中间数据的小文件问题。
四、数据存储高扩展性
长尾问题
- 尾部延迟放大+集群规模变大，使得大集群中，尾部延迟对于整个服务的质量极为重要。
- 慢节点问题：网络不会直接断联，而是不能在预期的时间内返回。会导致最终请求不符合预期，而多副本机制无法直接应对这种问题。
- 高负载：单个节点处理的请求超过了其服务能力，会引发请求排队，导致响应速度慢。是常见的一个慢节点原因。
数据可靠性
- 超大集群下，一定有部分机器是损坏的，来不及修理的。
- 随机的副本放置策略，所有的放置组合都会出现。而 DN 容量够大，足够
- 三副本，单个 DN 视角：容量一百万，机器数量一万。那么另外两个副本的排列组合有一亿种，容量比放置方案大约百分之一。
- 三副本，全局视角：一万台机器，每台一百万副本，损坏 1%（100 台）。根据排列组合原理，大约有 1009998/(1000099999998) (100000010000)=9704 个坏块
- callback 一下，叠加长尾问题。每个任务都要访问大量的块，只要一个块丢失就整个任务收到影响。导致任务层面的丢块频发，服务质量变差。
copyset
- 降低副本放置的组合数，降低副本丢失的发生概率。
- 修复速度：DN 机器故障时，只能从少量的一些其他 DN 上拷贝数据修复副本。
负载均衡的意义
避免热点
- 机器热点会叠加长尾问题，少数的不均衡的热点会影响大量的任务。
成本：
- 数据越均衡，CPU、磁盘、网络的利用率越高，成本更低。
- 集群需要为数据腾挪预留的空间、带宽更少，降低了成本。
可靠性
- 全速运行的机器和空置的机器，以及一会全速运行一会空置的机器，可靠性表现都有不同。负载均衡可以降低机器故障的发生。
- 同一批机器容易一起故障，数据腾挪快，机器下线快，可以提升可靠性。
\
