青训营 HDFS 高可用与高扩展性机制分析

概述

2022の夏天，半壶水响叮当的我决定充实一下自我

一、内容介绍

青训营

总述

本节课程主要分为四个方面

HDFS 元数据服务的高可用
HDFS 数据存储高可用
HDFS 元数据服务的高扩展性
HDFS 数据存储的高扩展性

基础知识

文件目录树 Directory Tree
路径前缀匹配
Quorum

高可用

复制状态机 Replicated State Machine
操作日志 Op Log / Edit Log
RTO 与 RPO
物理日志与逻辑日志
同步复制、半同步复制
心跳
脑裂
fence
副本 replica
数据中心网络架构
机架 rack
TOR 交换机
数据中心 data center

扩展性

分片 shard
分区 partition
邦联架构 federation
路由 route
block pool
代理 proxy
负载均衡 load balance
数据分级 data classification
冷/热数据 hot/cold data
数据搬迁 migration
慢节点
长尾 long tail

回顾

HDFS通过将文件分块来存储大文件，HDFS的组件有NameNode和DataNode，分别负责提供元数据和数据服务

在读/写数据时，HDFS客户端需要先从NameNode上获取数据读取/写入的DataNode地址，然后和DataNode交互来完成数据读/写

一个“可以用”的系统和“好用”的系统，差距就是“高可用”和“高扩展性”

HDFS 的架构

HDFS 的主要服务端主要组件是 NameNode 和 DataNode，两者通过定时心跳通信。
NameNode（NN）负责维护目录树、文件和块的关系、各个块的副本放置位置等元信息。
DataNode（DN）负责维护数据副本，执行 NameNode 下发的副本迁移、副本删除等操作。
HDFS Client 属于是胖客户端（fat/rich client），客户端中实现了数据读写的容错等较为复杂的逻辑。

HDFS 的读写路径

数据读取：Client 从 NN 上获取到文件信息和块的位置（getFileInfo+getBlockLocation），从对应 DN 上读取数据。当一个 DN 读取失败时，会去尝试块的其他 DN。
数据写入：Client 要求 NN 创建文件（create），并依次获得不同的 DN 来写入数据块（addBlock）。Client 通过链式写入来同时写入数据到多个 DN。在整个写入完成后，会让 NN 关闭文件（complete）。

二、元数据高可用

主备系统:基于日志、自动切换、实时热备

2.1 服务高可用的需求

故障类型:

adversity
硬件故障
软件故障
人为故障

灾难:数据中心级别不可用

机房断电
机房空调停机
机房间网络故障、拥塞

高可用：系统在困境中仍可正常工作（正确完成功能，并能达到期望的性能水准）

而如果HDFS系统不可用：

无法核算广告账单，直接引发收入损失
无法生产数据报表，数据驱动无从谈起
无法进行模型训练,用户体验越来越差

业务停止的损失极大，所以HDFS系统的高可用性就至关重要

2.1.1 高可用的衡量

服务可用性指标：故障度量的指标

MTTR（Mean Time To Repair）：平均修复时间，系统能多快恢复。
MTTF（Mean Time To Failure）：平均失效时间，运行到故障间的时间，一般用于不可修复的系统（制造业）。
MTBF（Mean Time Between Failures）：平均无故障时间，两次故障间的间隔，一般用于可修复的系统（软件）。

2.1.2 可用性的年化

可用性:

全年不可用时间：

可用性99.9%，全年8.76小时不可用
可用性99.99%，全年52.6分钟不可用
可用性99.999%，全年5.26分钟不可用

2.1.3 高可用的形式

服务高可用/备份方式:

冷备份：备份服务的数据，可以和数据归档相结合。在主服务故障时，利用备份的数据重启。关键数据重启
热备份：主服务和备服务同时运行，在主服务故障时，随时可以切换到备服务。与主服务同行

故障恢复操作切换方式：

人工切换：在故障发生时，运维人员接收报警后，手动执行服务切主操作。一般较慢，难以满足全年不可用时间的目标。
自动切换：通过探活组件、分布式共识协议等手段，系统能自动发现主服务的故障，并切换到备份不符。

人工的反应、决策时间都更长，高可用需要让系统自动决策
HDFS的设计中，采用了中心化的元数据管理节点 NameNode
NameNode容易成为故障中的单点(single point of failure/SPOF：指系统中一旦失效，就会让整个系统无法运作的组件)

2.1.3 高可用状态机恢复

状态机复制模型：实现容错服务的一种常规方法，主要通过复制服务器，并协调客户端和这些服务器镜像间的交互来达到目标。这个方法也同时提供了理解和设计复制管理协议的一套基本框架。

状态机：一个状态机从“初始”状态开始，每一个输入都被传入转换函数和输出函数，以生成一个新的状态和输出。在新的输入被接收到前，状态保持不变，而输出同时被传输给恰当的接受者。
状态机复制：确定性的状态机具有「处理确定的输入后，状态唯一确定」的特性。状态机复制利用这个特性实现多个相同的状态机副本的同步更新。
变更日志：触发状态机更新的变更操作，具有全局确定的顺序。
共识协议：确保每个副本都能收到相同的日志的共识协议，常见的有 Paxos、Raft、ZAB。

2.2 HDFS 的高可用架构

组件介绍：

Active NameNode：提供服务的 NameNode 主节点，生产 editlog
Standby NameNode：不提供服务，起备份作用的 NameNode 备节点，消费 editlog
edit log：用户变更操作的记录，具有全局顺序，是 HDFS 的变更日志
ZooKeeper：开源的分布式协调组件，主要功能有节点注册、主节点选举、元数据存储
BookKeeper：开源的日志存储组件，存储 editlog
ZKFC：和 ZK、NN 通信，进行 NN 探活和自动主备切换
HA Client：处理 StandbyException，在主备节点间挑选到提供服务的主节点

围绕三个问题来看高可用：

节点状态如何保存
操作日志如何同步
如何做到自动切换

2.2.1 理论基础-状态机复制和日志

状态机复制是实现容错的常规方法:
组件:

状态机以及其副本
变更日志
共识协议

2.2.2 NameNode 状态持久化

FSImage 文件：较大的状态记录文件，是某一时刻 NN 全部需要持久化的数据的记录。大小一般在 GB 级别
EditLog 文件：是某段时间发生的变更日志的存储文件。大小一般在 KB~MB 级别
checkpoint 机制：将旧的 FSImage 和 EditLog 合并生成新的 FSImage 的流程，在完成后旧的数据可以被清理以释放空间

2.2.3 NameNode操作日志的生产消费

物理日志：存储了物理单元（一般是磁盘的 page）变更的日志形式
逻辑日志：存储了逻辑变更（例如 rename /a to /b）的日志形式

2.2.4 NameNode块状态维护

content Stale：一致性，处理主备状态（因更改不一致）不一致

2.3 HDFS自动主备切换

2.3.1 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 的进程

2.3.2 自动主备切换

ZooKeeper 是广泛使用的选主组件，它通过 ZAB 协议保证了多个 ZK Server 的状态一致，提供了自身的强一致和高可用。
ZooKeeper 的访问单位是 znode，并且可以确保 znode 创建的原子性和互斥性（CreateIfNotExist）。client 可以创建临时 znode，临时 znode 在 client 心跳过期后自动被删除。
ZK 提供了 Watch 机制，允许多个 client 一起监听一个 znode 的状态变更，并在状态变化时收到一条消息回调（callback）。
基于临时 znode 和 Watch 机制，多个客户端可以完成自动的主选举。
ZKFailoverController：一般和 NN 部署在一起的进程，负责定时查询 NN 存活和状态、进行 ZK 侧主备选举、执行调用 NN 接口执行集群的主备状态切换、执行 fence 等能力。
Hadoop 将集群主备选举的能力和 NN 的服务放在了不同的进程中，而更先进的系统一般会内置在服务进程中。

2.3.2.1 分布式协调组件-ZooKeeper

一般用于提供选主、协调、元数据存储

使用它的组件:

HDFS、YARN、HBase
Kafka、ClickHouse
等等

HA核心机制:

Watch（检测ZooKeeper数据，定时心跳同步删除临时节点）

2.3.2.2 自动主备切换流程-Server侧

ZKFailoverController
- 作为外部组件，驱动HDFS NameNode的主备切换
- 注册节点，检测节点状态
轮询探活（查主备active）
脑裂问题（避免多人写机制，粗暴：kill旧的无响应写入active）
Fence/栅栏机制（心跳超时检测）

2.3.2.3 自动主备切换流程- Client侧

核心机制:StandbyException Client自动处理

2.4 高可用日志系统 BookKeeper/簿记员简介

高可用日志系统 BookKeeper

高可靠：数据写入多个存储节点，数据写入就不会丢失。
高可用：日志存储本身是高可用的。因为日志流比文件系统本身的结构更为简单，日志系统高可用的实现也更为简单。
强一致：日志系统是追加写入的形式，Client 和日志系统的元数据可以明确目前已经成功的写入日志的序号（entry-id）。
可扩展：整个集群的读写能力可以随着添加存储节点 Bookie 而扩展。

Quorum 协议：基于鸽巢原理，在多个副本间确保高可用、高性能的多副本变更协议

多副本间一般通过 version-id 来描述状态的新旧。
高可用：多个副本确保了高可用（后文会再次介绍多副本高可用）。
高性能：不用等所有副本写入成功，降低了的长尾延迟（后文会再次介绍长尾延迟）。
参考：Quorum 协议

BookKeeper Quorum 协议：基于 Quorum 的多数派思想来提供高可用、高性能写入的日志写入

日志写入是追加，不是状态变更，只需要确认目前的（日志的序号） entry-id，相对更简单。
Write Quorum：一次写入需要写入到的存储节点数。
Ack Quorum：一次写入需要收到的响应数，小于 write quorum。
高性能：不用等所有副本写入成功，降低了的长尾延迟（后文会再次介绍长尾延迟）。
Ensemble：通过轮询（Round-Robin）来确认 write quorum 实际对应的存储节点实例，可以比较简单的完成副本放置和扩展。

2.4.1 BookKeeper 架构

BookKeeper存储日志：

低延时
持久性
强一致性
读写高可用

对比:

日志系统和文件系统的复杂度

2.4.2 Quorum机制

Quorum/多数派机制:

多副本一致性读写

场景:

多副本对象存储，用版本号标识数据新旧

规则：

Qr + Qw > Q
Qw > Q/2

思考:

日志场景比对象保存更简单

2.4.3 BookKeeper Quorum

Sloppy Quorum机制：

日志场景:

顺序追加、只写

Write Quorum:

写入副本数Ack Quorum:响应副本数

思考:

Client挂掉导致不确认写入了多少数据，如何恢复?

2.4.4 BookKeeper Ensemble

Ensemble/集成机制

Round-Robin Load Balancer/圆罗宾负载均衡器

第一轮:1,2,3
第二轮:2,3,4
第三轮:3,4,1
第四轮:4,1,2

优势:数据均衡

三、数据存储高可用

数据备份:多副本、纠删码、网络架构

3.1 单机存储的数据高可用机制

RAID(Redundant Array of Independent Disks/独立磁盘冗余阵列)：将多个廉价、不可靠、低性能、容量小的磁盘组装在一起，提供高可靠、高性能、大容量逻辑磁盘服务的一组磁盘列阵方案。

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

3.2 HDFS 的数据高可用机制

3.2.1 HDFS版本的RAID 1 多副本方案

多副本方案：将数据块存储在多个 DN（datanode）上

HDFS版本的RAID 1

图:Hadoop的多副本放置（三副本）

优点:

读写路径简单副本修复简单高可用

3.2.2 HDFS版本的RAID 2/3 Erasure Coding 方案（低成本）

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

条带化：原本块对应文件内连续的一大段数据。条带化后，连续的数据按条带（远小于整个块的单位）间隔交错的分布在不同的块中。
Reed Solomon 算法：参考 Reed-solomon codes
成本更低：多副本方案需要冗余存储整个块，EC 方案需要冗余存储的数据一般更少。

HDFS版本的RAID 2/3

业界常用Reed Solomon算法

图:Reed Solomon算法原理

3.2.3 HDFS版本的RAID 2 HDFS Erasure Coding

HDFS版本的RAID 2

图:直接保存的EC和Stripe(条带)

和多副本比较

读写速度
成本
修复速度
读写路径的实现

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

数据中心架构

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

TOR top of rack：机架顶部（或底部）的交换机，负责机架内服务器和数据中心的其他服务器的网络通信。
机房和数据中心都是指大量服务器集中放置的场所。
- 机房：强调的基础设施建设，例如物理承重、空调、防水、消防。
- 数据中心：强调机房的业务属性。
网络拓扑：按数据中心->机架->机器的顺序，描述进程在网络空间中所处的位置

跨机房专线：由网络服务商提供，连接机房的专用网络。
- 稳定性和安全性好于公网。
- 相比于数据中心内网络，吞吐更为有限、延迟更高、成本更高。

故障域

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

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

3.4 案例：字节跳动的 HDFS 多机房实践

3.4.1 副本放置策略―机架感知

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

trade-off :一个本地、—个远端

图:HDFS的多机架放置

3.4.2 案例:字节跳动的HDFS 多机房实践

字节跳动的HDFS集群，从单机房演进到双机房，再从双机房演进到更多的机房

多机房解决的问题：

容量问题
容灾问题

HDFS 双机房放置的设计：

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

3.4.3 多机房容灾实践

多机房部署的组件：

ZooKeeper
BookKeeper
NameNode
DataNode

容灾期间的策略：

容灾期间，限制跨机房写入
容灾期间，限制跨机房副本复制

四、元数据高扩展性

水平扩展:邦联架构、请求路由、完整名字空间

4.1. 元数据扩展性的挑战

HDFS NameNode是个集中式服务，部署在单个机器上，内存和磁盘的容量、CPU的计算力都不能无限扩展 scale up vs scale out
扩容单个服务器的能力部署多个服务器来服务

挑战：

名字空间分裂
DataNode汇报
目录树结构本身复杂

扩展性方案

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

4.1.1 scale out 方案

KV模型的系统可以使用partition

Redis
Kafka
MySQL(分库分表)

下图:三种数据路由方式：

服务端侧
路由层
客户端侧

partition 方法

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

federation 架构

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

4.2. 社区解决方案

4.2.1 blockpool

将文件系统分为文件层和块存储层，对于块存储层，DN（datanode）集群对不同的 NN（namenode）（DN三节点处理数据，NN调度）提供不同的标识符，称为 block pool
解决了多个 NN 可能生成同一个 block id，DN 无法区分的问题

解决DN同时服务多组NN的问题

文件服务分层

Namespace（目录树结构（父子关系），文件对应块与ID）
Block Storage（块存在DN上，单独目录，对应信息/NN不同blockpool，唯一ID）

用blockpool来区分DN的服务

数据块存储
心跳和块上报（校验，防止DN服务多个NN）

4.2.2 viewfs

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

Federation架构:将多个不同集群组合起来，对外表现像一个集群一样

federation 架构

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

下图: viewfs通过在client-side的配置,指定不同的目录访问不同的NameNode

局限性:运维复杂

4.3. 字节 Proxy 方案介绍

NNProxy是ByteDance自研的HDFS代理层，提供了路由服务

于2016年开源，项目地址:github.com/bytedance/n…
开源社区的 Router Based Federation在2017年上线

NNProxy主要实现了路由管理和RPC转发

以及鉴权、限流、查询缓存等额外能力

下图:NNProxy所在系统上下游

NNProxy

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

4.3.1 NNProxy路由规则保存

回顾:三种数据路由方式：

服务端侧
路由层
客户端侧

考虑点:扩展性、运维性

图:路由规则的保存

4.3.2 NNProxy路由转发实现

图:目录树视图

路径最长匹配规则

/
/home
/user/bob
/user/tiger/warehouse
/user/tiger/dump

进一步思考:

单个NN不会遇到瓶颈了么?
跨集群rename

4.4. 案例：小文件问题

小文件问题

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

五、数据存储高扩展性

超大集群:数据可靠、数据均衡、长尾问题

5.1 超大集群的长尾问题

长尾

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

百分位延迟

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

尾部延迟放大

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

长尾问题

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

5.1.1 延迟的分布和长尾延迟

5.1.2 尾部延迟放大

5.1.3 长尾问题的表现-慢节点

5.2 超大集群的可靠性问题

数据可靠性

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

5.2.1 超大集群下的数据可靠性

5.2.2 Copyset

copyset

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

5.3 超大集群的不均匀问题

负载均衡的意义

避免热点
- 机器热点会叠加长尾问题，少数的不均衡的热点会影响大量的任务。
成本：
- 数据越均衡，CPU、磁盘、网络的利用率越高，成本更低。
- 集群需要为数据腾挪预留的空间、带宽更少，降低了成本。
可靠性
- 全速运行的机器和空置的机器，以及一会全速运行一会空置的机器，可靠性表现都有不同。负载均衡可以降低机器故障的发生。
- 同一批机器容易一起故障，数据腾挪快，机器下线快，可以提升可靠性。

负载均衡性影响因素：多个复杂因素共同影响负载均衡性

不同节点上的业务量的平衡
数据放置策略
数据搬迁工具的能力
系统环境

集群的不均衡情况

节点容量不均：机器上的数据量不均衡。
- 原因可能是各种复杂情况导致，归根结底是混沌现象。
数据新旧不均：机器上的数据新旧不均匀。
- 例如：新上线的机器，不做任何数据均衡的情况下，只会有新写入的数据。而一般新数据更容易被读取，更为「热」。
访问类型不均：机器上的数据访问类型不均。
- 例如：机器学习训练需要反复读取数据，小 I/O 更多。而大数据场景一般只扫描一次，大 I/O 为主。这两种模式的读写比不同，I/O pattern 不同，就来带访问冷热的不同。
异构机器：有的机器配置高、有的机器配置低，不考虑异构情况的话配置高的机器会闲置，配置低的机器会过热。
资源不均：机器上的访问请求吞吐、IOPS 不均衡，导致最终机器冷热不均、负载不均。一般由于容量不均、新旧不均、模式不均导致

超大集群的负载均衡和数据迁移

5.3.1 案例：数据分布不均导致慢节点问题

5.3.1.1 数据写入不均

数据的不均匀:

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

资源负载不均匀

5.3.1.2 DN冷热不均

5.3.1.3 负载均衡和数据迁移的典型场景

5.4 数据迁移工具速览

需要数据迁移的典型场景

DN 上线：新上线的机器没有任何数据，而且只会有新数据写入。需要迁移其他 DN 的旧数据到新 DN 上，使得负载和数据冷热均衡。
DN 下线：需要下线的机器，需要提前将数据迁移走再停止服务，避免数据丢失的风险。
机房间均衡：因为资源供应、新机房上线等外部条件，机房规划、业务分布等内部条件，不同机房的资源量和资源利用率都是不均衡的。需要结合供应和业务，全局性的进行资源均衡。
日常打散：作为日常任务运行，不断地从高负载、高容量的机器上搬迁数据到低负载、低容量的机器上，使得整个集群的负载均衡起来。

数据迁移工具

目的：将数据从一部分节点搬迁到另一部分节点。
要求：高吞吐、不能影响前台的服务。

带元数据迁移的迁移工具

痛点：涉及到元数据操作，需要停止用户的写入。
DistCopy 工具
- 通过 MapReduce 任务来并行迁移数据，需要拷贝数据和元数据。
- 网络流量较大，速度较慢。
FastCopy 工具
- 基于 hardlink 和 blockpool 的原理
- 元数据直接在 NN 集群间拷贝，而数据则在 DN 上的不同 blockpool（对应到 NN 集群）进行 hardlink，不用数据复制。
- 迁移速度要大大优于 DistCopy。