当数据规模越来越大，存储成本也水涨船高。随着时间推移，数据热度分布往往呈 2⁄8 原则，即 80% 的访问集中在 20% 的数据上。对于那不经常访问的 80% 数据来说，使用多个 SSD 来存储真是巨大的浪费，需要将冷数据迁移到其他存储成本更低的系统里。这时 JuiceFS 成了理想之选，成本下降 20 倍，同时又提供跟 HDFS 一样高性能的元数据能力（避免Metastore 遍历元数据时雪崩），大量扫描冷数据时也有很高的吞吐量。如果 80% 的数据转移到 JuiceFS 上来，整体成本可节省 90%。如果再给 JuiceFS 提供 适当的空间做缓存，还可以完整替换 HDFS (20% 的热数据通过 JuiceFS 管理的缓存盘来服务，也可以有极高的性能）。
2019 年里，我们就实施过几个这样的案例。当数据迁移到 JuiceFS 上之后，HDFS 容量降下来了，就需要做好缩容才能最终把存储成本降下来。扩容大家都做过，但是缩容很多人还不熟悉，下面我们就详细说说如何做好 HDFS 缩容，尤其是这个背景下的缩容。
三种缩容方案
第一种缩容方法，如果 DataNode 的节点数目比较多，并且允许缩减存储空间的同时缩减 CPU 和内存资源，则可以缩掉若干个 DataNode 节点，直接使用 HDFS 提供的 decommission。这是最常见的方法，缩减过程中涉及大量数据的跨节点迁移，会产生大量的内网流量可能影响线上负载，需要运维人员保持密切关注和手动调优，通常需要一两周的时间。如果集群只剩 3 个 DataNode 节点，或者上面的 CPU 或者 内存资源不能同步缩减时，就不能用这个方法了。
第二种缩容方法，即在保持 DataNode 节点数不变的情况下，缩减每个节点上的磁盘空间，可以修改 DataNode 上的 dfs.data.dir参数，删掉一个或者多个磁盘目录，然后等待 HDFS 自动补充副本。这个方法统一也会导致节点间的大量数据移动，会产生大量的内网流量可能影响线上负载，需要运维人员保持密切关注和手动调优，可能也需要一两周时间。此外，如果数据只有 2 副本，相对会比较危险，一旦删除一个磁盘目录时正好有节点出问题或者某块磁盘坏掉，极有可能造成数据缺失。
这两种方法都会产生大量的网络流量，可能会影响在线服务，增加数据丢失的风险。本文提供了第三种方法，如何最大限度地减少缩容过程中的数据丢失风险，同时避免内网流量对在线工作负载的影响。
[En]
Both of these methods generate a large amount of network traffic, which may affect online services and increase the risk of data loss. This paper provides a third method, how to minimize the risk of data loss in the process of downsizing while avoiding the impact of private network traffic on online workloads.
方案分析
首先我们看一下 DataNode 在磁盘上的目录结构：
└── dn
├── current
│ ├── BP-847673977-192.168.0.120-1559552771699
│ │ ├── current
│ │ │ ├── dfsUsed
│ │ │ ├── finalized
│ │ │ │ ├── subdir0
│ │ │ │ │ ├── subdir1
│ │ │ │ │ │ ├── blk_1073742303
│ │ │ │ │ │ ├── blk_1073742303_1479.meta
│ │ │ ├── rbw
│ │ │ └── VERSION
│ │ ├── scanner.cursor
│ │ └── tmp
│ └── VERSION
└── in_use.lock
BP-847673977-192.168.0.120-1559552771699：这是块池目录，如果以 Federation 方式部署的时候，会有多个块池目录。dfsUsed：保存的是磁盘的使用统计数据，每 10 分钟刷新一次。finalized和 rbw 目录：这两个都是用于存储数据块的，finalized 放的是已经完成写入的数据块，rbw 是正在写入的数据块。每个数据块对应 2 个文件，blk 文件存放数据，另外一个以 meta 结尾的存放校验和等元数据。VERSION文件：主要包含布局版本、集群 ID、DataNode ID、块池 ID 等信息。scanner.cursor文件：DataNode 会定期的对每个blk文件做校验，这个文件是用来记录校验到哪个位置的。- 不难看出所有的数据文件都存在
finalized和rbw里面，并且同一个DataNode上面不会存在相同 Block ID 的数据文件。因此完全可以通过迁移 blk 文件的方式来将一块磁盘上面的数据移动到另外一块磁盘上，然后在卸载此磁盘来达到缩容的目的。
缩容步骤
本文示例的 HDFS 是 CDH 5.16 版本，使用 ClouderaManager 管理集群。集群只有 3 个节点，每个节点有多块 SSD 盘，数据两副本，存储利用率很低，每个节点都可以卸载掉一块磁盘，但是无法使用前面两种常见的缩容方法，同时缩容过程要尽可能可能减小对线上服务的影响。
以下操作均是针对单一 DataNode 的操作，其他 DataNode 也需要按照以下步骤执行（可以适当并行）：
被卸载磁盘： /dfs1，此磁盘上的 DataNode 数据目录： /dfs1/dfs/dn
数据接收盘： /dfs，此磁盘上的 DataNode 数据目录： /dfs/dfs/dn
ionice -c 2 -n 7 rsync -au /dfs1/dfs/dn/ /dfs/shrink_temp/dn
ionice -c 2 -n 7 rsync -au /dfs1/dfs/dn/ /dfs/shrink_temp/dn
ionice -c 2 -n 7 rsync -au --link-dest=/dfs/shrink_temp/dn --ignore-existing --remove-source-files /dfs/shrink_temp/dn/ /dfs/dfs/dn
sudo -u hdfs hdfs fsck /
为什么不直接将被卸载盘的数据复制合并到接收盘的 DataNode 数据目录里面呢？ 这是因为，在第一次拷贝的时候，DataNode 仍然在运行，因此 DataNode 会定期检查副本数量，此时拷贝过去的数据算是额外副本，有可能会被 DataNode 删除掉。
整个缩容过程中 DataNode 停止的时间只是步骤 4 和步骤 5 所需时间。步骤 4 是增量拷贝，速度很快，步骤 5 只是文件元数据操作，同样很快。
以上步骤看起来比较多，手动操作会容易出错，因此我们将以上缩容过程写了一个脚本（部分操作依赖 Hadoop 发行版的 API，目前支持 CDH5），请下载setup-hadoop.py，运行命令，并按照提示输入进行缩容：
python setup-hadoop.py shrink_datanode
未来改进
在上面的缩容过程里，需要将数据是从一块磁盘完整地拷贝到另外一块磁盘，需要它有足够的剩余空间，另外也可能导致 DataNode 内磁盘间数据不均衡。未来可以改进下这个缩容过程，在复制数据时根据某个规则将 blk 文件复制到多块盘，确保多块磁盘之间的数据均衡。
Original: https://www.cnblogs.com/JuiceData/p/16009475.html
Author: JuiceFS
Title: 怎么做 HDFS 的原地平滑缩容？
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/522559/
转载文章受原作者版权保护。转载请注明原作者出处！