某大型企业因为新业务激增，导致Hadoop集群中的RPC调用量猛增了两到三倍，系统变得不堪重负，很多重要任务都开始延迟。团队在尝试了打补丁和扩容都没见效后，决定给老集群“减负”，把压力最大的数据搬迁到新的namespace里。 这次迁移目标非常明确：要在业务低谷的两个小时内，把一个单目录下大约1000万文件、总量达10PB的数据，毫无感知地搬到新集群上。同时要把该目录日均5亿次的RPC请求“割”给新集群，让老系统重新顺畅运行。 迁移过程中遇到了好几个难题。首先是选数据，团队用物理容量、目录数和日均RPC数这三个指标筛选出了最胖的业务目录。其次是复制方式的选择，因为原生的DistCp跑10PB数据需要十天时间，远超窗口时间，所以直接被否决。再者是共享存储怎么处理，Federation环境下DN是共享的，不用物理拷贝，但社区还没给出高效方案。此外，迁移中难免有文件失败需要兜底，尤其是涉及到100万级的文件量时；还有Viewfs嵌套映射和Open file状态等兼容性问题也需要解决。 团队提出了两套方案：一种是一次全量迁移后再持续同步增量数据；另一种是先把静态历史数据搬走，只留动态当日增量在窗口期内完成。经过讨论，大家选择了第二种方案——把静态历史数据提前搬走，只留当天的增量来完成这次搬家。 为了提升DistCp的性能，他们采用了几种“黑科技”。比如把HDFS Fastcopy改动回滚到内部版本，利用hardlink秒传技术让速度翻了五倍；改造UniformSizeInputFormat来优化大小文件倾斜问题；把目录ACL权限的保存逻辑拆到每个task里并行处理以缩短commit时间；新增一个Reduce Task专门记录失败日志方便二次补拷；最后通过微调ipc.client.connect.max.retries.on.timeouts、mapreduce.task.timeout等参数加速运行。 在进行多轮压测时发现，当task数从5千增加到1万时，NN的callqueue反而从4千爬到了1万，速度反而下降了。这说明资源不是无限的，调优时要关注NN的瓶颈而不是单纯看task数量。 当天实际执行时按照如下步骤进行：上午8点到8点半关闭文件、收权并创建Snapshot；8点半到10点半使用白名单和日期过滤提前拷贝历史静态数据（占总量的约50%）；10点半到12点只留下当日新增的500到600万文件做最后冲刺。结果只用了1个半小时就完成了400到500万文件的迁移，全程没有业务投诉或数据错位。 这次操作成功后老集群日均RPC请求量下降了约5亿次，heap释放了近20GB；新namespace下同样的数据处理时间稳定在1毫秒以内。虽然技术方案跑通了但人工干预还很多沟通成本高。接下来团队打算借助HDFS RBF（Routing Bridge Framework）来实现自动白名单生成、动态增量同步和实时进度透明化，让下一次PB级搬家也能“无声无息”。