HDFS 高可用与高扩展性机制分析笔记（二）| 青训营笔记

HDFS 高可用与高扩展性机制分析笔记（二）| 青训营笔记

这是我参与「第四届青训营 -大数据场」笔记创作活动的第14天

二、数据高可用

1. 单机存储的数据高可用机制

1.1 RAID

将多个廉价、不可靠、低性能、容量小的磁盘组装在一起，提供高可靠、高性能、大容量逻辑磁盘服务的一组磁盘列阵方案。

• RAID 0：将数据分块后按条带化的形式分别存储在多个磁盘上，提供大容量、高性能。
• RAID 1：将数据副本存储在多个磁盘上，提供高可靠。
• RAID 3：在数据分块存储的基础上，将数据的校验码存储在独立的磁盘上，提供高可靠、高性能。
• 其他可以参考 RAID

2. HDFS数据高可用机制

2.1 HDFS多副本

HDFS版本的RAID1

• 将同一块数据存放在多个dataNode上，若单个dataNode故障有其他dataNode持有该数据

• 若发现checksum不对，则知道该块上的数据错误，此时NameNode则会找正确的dataNode传输相应块到改错误块上

• 优点

  • 读写路径简单
  • 副本修复简单：从其他Node拷贝
  • 高可用：三副本很难同时损坏，丢块

• 缺点

  • 三副本在大数据下存储成本过高

2.2 Erasure Coding 方案

• HDFS版本的RAID2

  • Reed Solomon算法
  • 【单位矩阵+额外行矩阵块】*【数据源】= CodeWord (Data+Parity)
  • Data：数据/Parity：纠善码

• 和多副本比较

  • 读写速度：按照块读取，计算后速度慢

    • 切分成条带化 striping

  • 成本：成本更优 容忍丢失更少的机器

  • 修复速度：引用更多计算

  • 读写路径的实现：比存原始数据更复杂

• 将数据分段，通过特殊的编码方式存储额外的校验块，并条带化的组成块，存储在 DN 上。

  • 条带化：原本块对应文件内连续的一大段数据。条带化后，连续的数据按条带（远小于整个块的单位）间隔交错的分布在不同的块中。

• Reed Solomon 算法：参考 Reed-solomon codes

• 成本更低：多副本方案需要冗余存储整个块，EC 方案需要冗余存储的数据一般更少。

3. 考虑网络架构的数据高可用

3.1 数据中心架构

• 机架/机柜：将几个服务器统一供电、提供对外网络的固定的物理设备。

• TOR top of rack：机架顶部（或底部）的交换机，负责机架内服务器和数据中心的其他服务器的网络通信。

• 机房和数据中心都是指大量服务器集中放置的场所。

  • 机房：强调的基础设施建设，例如物理承重、空调、防水、消防。
  • 数据中心：强调机房的业务属性。

• 网络拓扑：按数据中心->机架->机器的顺序，描述进程在网络空间中所处的位置。

• 跨机房专线：由网络服务商提供，连接机房的专用网络。

  • 稳定性和安全性好于公网。
  • 相比于数据中心内网络，吞吐更为有限、延迟更高、成本更高。

3.2 副本放置策略 - 机架感知

• 一个TOR故障导致整个机架不可用 vs 降低跨rack流量

• trade-off 一个本地一个远端

• 放置strategy

  • 一个副本写在local node
  • 第二个写在remote上
  • 第三个写在同一个remote rack上
  • 更多副本随机写

• 缺点：仍然有两份数据在同一机架上

4. 故障域

• 故障域是基础设施中可能发生故障的区域或组件。每一个域都有自己的风险和挑战，由个别几个因素决定整个故障域的服务能力，需要进行架构。
• 机架感知：以 TOR 为关键点，机架是一个故障域。数据副本全部放置在一个机架中，当相应 TOR 故障时数据就无法访问。
• 机房感知：以机房的基础设施（空调、电力）和跨机房专线为关键点，它们发生故障时整个机房会发生故障，导致不可用。

5. 多机房容灾

服务和数据需要存放在多个机房，并配合合理的架构。使得发生机房故障时依然可以提供服务。

三、元数据扩展性

1. 扩展性方案

• scale up：通过单机的 CPU、内存、磁盘、网卡能力的提升来提升系统服务能力，受到机器成本和物理定律的限制。
• scale out：通过让多台机器组成集群，共同对外提供服务来提升系统服务能力。一般也称为高扩展、水平扩展。

2. partition 方法

• 水平分区和垂直分区：水平分区指按 key 来将数据划分到不同的存储上；垂直分区指将一份数据的不同部分拆开存储，用 key 关联起来。partition 一般都水平分区，又称 shard。
• 常用于 KV 模型，通过 hash 或者分段的手段，将不同类型 key 的访问、存储能力分配到不同的服务器上，实现了 scale out。
• 重点：不同单元之间不能有关联和依赖，不然访问就难以在一个节点内完成。例如 MySQL 的分库分表方案，难以应对复杂跨库 join。

3. federation 架构

• 使得多个集群像一个集群一样提供服务的架构方法，提供了统一的服务视图，提高了服务的扩展性。
• 文件系统的目录树比 kv 模型更复杂，划分更困难。
• 邦联架构的难点一般在于跨多个集群的请求，例如 HDFS 的 rename 操作就可能跨多个集群。

4.社区解决方法

4.1 blockpool

• 将文件系统分为文件层和块存储层，对于块存储层，DN 集群对不同的 NN 提供不同的标识符，称为 block pool。
• 解决了多个 NN 可能生成同一个 block id，DN 无法区分的问题。

4.2 viewfs

• 邦联架构的一种实现，通过客户端配置决定某个路径的访问要发送给哪个 NN 集群。
• 缺点：客户端配置难以更新、本身配置方式存在设计（例如，只能在同一级目录区分；已经划分的子树不能再划分）。

5. NNProxy

• ByteDance 自研的 HDFS 代理层，于 2016 年开源，项目地址： github.com/bytedance/n…
• 主要提供了路由管理、RPC 转发，额外提供了鉴权、限流、查询缓存等能力。
• 开源社区有类似的方案 Router Based Federation，主要实现了路由管理和转发。

6. 小文件问题

• HDFS 设计上是面向大文件的，小于一个 HDFS Block 的文件称为小文件。
• 元数据问题：多个小文件相对于一个大文件，使用了更多元数据服务的内存空间。
• 数据访问问题：多个小文件相对于一个大文件，I/O 更加的随机，无法顺序扫描磁盘。
• 计算任务启动慢：计算任务在启动时，一般会获得所有文件的地址来进行 MapReduce 的任务分配，小文件会使得这一流程变长。
• 典型的 MR 流程中，中间数据的文件数和数据量与 mapper*reducer 的数量成线性，而为了扩展性，一般 mapper 和 reducer 的数量和数据量成线性。于是，中间数据的文件数和数据量与原始的数据量成平方关系。
• 小文件合并任务：计算框架的数据访问模式确定，可以直接将小文件合并成大文件而任务读取不受影响。通过后台运行任务来合并小文件，可以有效缓解小文件问题。通过 MapReduce/Spark 框架，可以利用起大量的机器来进行小文件合并任务。
• Shuffle service：shuffle 流程的中间文件数是平方级的，shuffle service 将 shuffle 的中间数据存储在独立的服务上，通过聚合后再写成 HDFS 文件，可以有效地缓解中间数据的小文件问题。

四、数据扩展性

1. 长尾

• 二八定律：在任何一组东西中，最重要的只占其中一小部分，约 20%，其余 80% 尽管是多数，却是次要的。
• 长尾：占绝大多数的，重要性低的东西就被称为长尾。

2. 百分位延迟

• 将所有请求的响应速度从快到慢排序，取其中某百分位的请求的延迟时间。
• 例如 pct99 代表排在 99% 的请求的延迟。相对于平均值，能更好的衡量长尾的情况。

3. 尾部延迟放大

• 木桶原理：并行执行的任务的耗时取决于最慢的一个子任务。
• 尾部延迟放大：一个请求或任务需要访问多个数据节点，只要其中有一个慢，则整个请求或任务的响应就会变慢。
• 固定延迟阈值，访问的集群越大， 高于该延迟的请求占比越高。
• 固定延迟百分位，访问的集群越大，延迟越差。

4. 长尾问题

• 尾部延迟放大+集群规模变大，使得大集群中，尾部延迟对于整个服务的质量极为重要。
• 慢节点问题：网络不会直接断联，而是不能在预期的时间内返回。会导致最终请求不符合预期，而多副本机制无法直接应对这种问题。
• 高负载：单个节点处理的请求超过了其服务能力，会引发请求排队，导致响应速度慢。是常见的一个慢节点原因。

5. 数据可靠性

• 超大集群下，一定有部分机器是损坏的，来不及修理的。
• 随机的副本放置策略，所有的放置组合都会出现。而 DN 容量够大，足够
• 三副本，单个 DN 视角：容量一百万，机器数量一万。那么另外两个副本的排列组合有一亿种，容量比放置方案大约百分之一。
• 三副本，全局视角：一万台机器，每台一百万副本，损坏 1%（100 台）。根据排列组合原理，大约有 1009998/(1000099999998) (100000010000)=9704 个坏块
• callback 一下，叠加长尾问题。每个任务都要访问大量的块，只要一个块丢失就整个任务收到影响。导致任务层面的丢块频发，服务质量变差。

6. copyset

• 降低副本放置的组合数，降低副本丢失的发生概率。
• 修复速度：DN 机器故障时，只能从少量的一些其他 DN 上拷贝数据修复副本。

7. 超大集群的不均匀问题

• 负载均衡：可靠性/降低成本/避免热点

• 数据写入不均

  • 数据不均匀

    • 节点容量不均匀
    • 数据新旧不均匀
    • 访问类型不均匀

  • 资源负载不均

• 数据读取不均

  • 数据不均匀

    • 节点容量不均匀
    • 数据新旧不均匀
    • 访问类型不均匀

  • 资源负载不均

• 访问类型不均匀

• 目标：容量/访问低昂/数据冷热/承载能力

• 典型场景： DN上下线/机房均衡/日常打散

8. 数据迁移工具速览

8.1 元数据迁移

• DistCopy：基于mapreduce通过任务将数据从一个NN拷贝到另一个NN

  • 拷贝数据，流浪大，速度慢

• FastCopy

  • 前提：新旧集群DM列表吻合
  • 元数据直接在NN集群间拷贝，数据在DN上不同blockpool进行hardlink，不需要数据复制

8.2 数据迁移

• Balancer

  • 工具向DataNode发起迁移指令，平衡各个DN的容量
  • 场景：单/多机房、限流措施
  • 评价：稳定性成本等

五、实践

1. 字节HDFS多机房实践

• 多机房解决的问题

  • 容量问题：物理问题、场地不足
  • 容灾问题：多地部署

• HDFS双机房放置的设计

  • 写入时每个数据块在两个机房各至少有一个副本，数据实时写入到两个机房
  • 读取时优先读本地副本，避免大量跨机房读取

• 多机房部署组件支持

  • zookeeper在不同机房各部署一个，额外部署一个单独的zookeeper做调解
  • bookkeeper在不同机房各部署一个
  • NameNode/DataNode需要一定数量

• 容灾期间策略

  • 限制跨机房写入
  • 限制跨机房副本复制
  • 写在数据中心

2. 小文件问题LSOF

• 大小不到一个HDFS block大小的文件过多

  • NameNode成为瓶颈
  • IO变为小随机IO 数据访问缓慢
  • 计算任务启动慢

• 解决方法

  • 后台任务合并小文件
  • shuffle service：mapreduce中间数据缓存在内存，聚合合并

总结

• HDFS作为大数据离线分析场景的核心组件，高可用和高扩展性是架构设计的重中之重。
• 高可用确保了业务能稳定运行，HDFS上存储的数据随时可以访问。
• 高扩展性确保了HDFS能存储的数据量能随着资源投入无限扩展下去，业务发展不被基础组件拖累。
• 字节跳动HDFS依然在持续迭代，在元数据扩展性、数据治理与调度、数据生态体系、单机存储引擎、云上存储等方向依然大有可为。