背景
最近两三个月，JuiceFS 做了这样几个项目：客户使用公有云，一开始为了追求高性能用 SSD 云盘搭建了 HDFS，SSD 云盘的价格要 ￥1/GB/月，加上 HDFS 的三副本策略，存储成本 ￥1 x 1024 x 3 = ￥3072/TB/月，假设 70% 的利用率成本是 ￥4388/TB/月，这还只算了磁盘成本，每个 DataNode 还有相应的 CPU 和内存开销，整体 TCO 要超过 ￥5000/TB/月，相比于 JuiceFS 大概 ￥260/TB/月（已包含对象存储部分）的成本，是后者的近 20 倍。
当数据规模越来越大，存储成本也水涨船高。随着时间推移，数据热度分布往往呈 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（附上 社区版文档，CDH 文档，HDP 文档）。这是最常见的方法，缩减过程中涉及大量数据的跨节点迁移，会产生大量的内网流量可能影响线上负载，需要运维人员保持密切关注和手动调优，通常需要一两周的时间。如果集群只剩 3 个 DataNode 节点，或者上面的 CPU 或者 内存资源不能同步缩减时，就不能用这个方法了。
第二种缩容方法，即在保持 DataNode 节点数不变的情况下，缩减每个节点上的磁盘空间，可以修改 DataNode 上的 dfs.data.dir参数，删掉一个或者多个磁盘目录，然后等待 HDFS 自动补充副本。这个方法统一也会导致节点间的大量数据移动，会产生大量的内网流量可能影响线上负载，需要运维人员保持密切关注和手动调优，可能也需要一两周时间。此外，如果数据只有 2 副本，相对会比较危险，一旦删除一个磁盘目录时正好有节点出问题或者某块磁盘坏掉，极有可能造成数据缺失。
以上两种方法都会产生大量网络流量，可能影响线上服务，并且会增加丢失数据的风险。本文提供第三种方法，怎么在缩容的同时，尽量避免产生的内网流量影响线上工作负载，同时尽量减少缩容过程中数据丢失的风险。
方案分析
首先我们看一下 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.lockBP-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
第一次复制数据。从 dfs.data.dir 里面挑选出在被卸载磁盘上面的目录，然后将此目录全量拷贝到接收数据盘上，为了尽量减少对 IO 的占用，用 ionice 加 rsync 的方式拷贝数据，确保不阻塞高优先级的任务。
ionice -c 2 -n 7 rsync -au /dfs1/dfs/dn/ /dfs/shrink_temp/dn需要保证数据都被拷贝过去了，所以需要将 DataNode 停掉。可以通过 ClouderaManager 界面关闭 DataNode。
第二次增量复制数据。重复步骤 2，将在步骤 2 和步骤 3 之间的新增数据增量更新到接收盘上。增量数据会比较少，估计能很快完成。
ionice -c 2 -n 7 rsync -au /dfs1/dfs/dn/ /dfs/shrink_temp/dn- 合并目录。此时被卸载盘上的数据都已经复制到接收盘上，但是数据还在原来的文件夹里面。如果同一块磁盘上面有两个 DataNode 数据目录的话，会导致 HDFS 容量计算重复，因此需要合并。可以通过
rsync的硬链的方式将数据拷贝过去，这样不涉及真正的数据拷贝，执行非常快，同时将拷贝过去的源数据删除。检查剩余数据是否有blk文件，没有就合并完成。
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通过 ClouderaManager 修改 dfs.data.dir 配置项，删除卸载磁盘上的数据目录。
通过 ClouderaManager 启动 DataNode，并检查 HDFS 的状态。
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 文件复制到多块盘，确保多块磁盘之间的数据均衡。
