DistCp拷贝数据拷了一夜——HDFS数据迁移和跨集群同步
先说结论
DistCp（Distributed Copy）是Hadoop官方的分布式数据拷贝工具，底层是一个MapReduce作业。它把要拷贝的文件列表分成多个Map Task并行执行，每个Task负责拷贝一部分文件。调优方向：增加Map数量提高并行度、控制带宽避免影响线上、处理失败重试和断点续传。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
数据迁移是大数据运维的常见任务：集群扩容、机房迁移、平台升级都需要把数据从一个地方搬到另一个地方。在某知名出海硬件品牌做EMR到Databricks迁移时，第一步就是确保S3上的数据两边都能访问。虽然那次不需要跨集群拷贝（都用S3），但之前在某短视频平台做集群升级时，用DistCp从老集群拷贝30TB数据到新集群，跑了整整一夜。DistCp是HDFS自带的分布式拷贝工具，理解它的原理和调优方法在迁移场景中非常重要。
DistCp的工作原理
# DistCp的基本用法
hadoop distcp hdfs://src-cluster/warehouse/ hdfs://dst-cluster/warehouse/
# DistCp的执行过程：
# 1. 扫描源目录，获取所有文件列表
# 2. 把文件列表按大小均匀分配给多个Map Task
# 3. 每个Map Task通过HDFS API读源文件、写目标文件
# 4. 拷贝完成后校验文件大小和checksum
#
# 本质上就是一个只有Map没有Reduce的MapReduce作业
# 并行度 = Map数量 = 文件列表分成几份
# 常用参数
hadoop distcp \
-m 100 \ # 100个Map Task并行
-bandwidth 50 \ # 每个Map限速50MB/s
-strategy dynamic \ # 动态分配文件给Map
-update \ # 只拷贝新增/修改的文件
-skipcrccheck \ # 跳过CRC校验（加速）
hdfs://src/warehouse/ \
hdfs://dst/warehouse/DistCp调优——从一夜到3小时
| 调优方向 | 参数/方法 | 效果 |
|---|---|---|
| 增加并行度 | -m 200（默认20） | Map数量增加10倍，吞吐提升 |
| 动态分配 | -strategy dynamic | 避免大文件卡住单个Map |
| 带宽控制 | -bandwidth 100 | 平衡速度和线上影响 |
| 增量拷贝 | -update | 只拷贝变化的文件，省时间 |
| 跳过校验 | -skipcrccheck | 牺牲校验换速度 |
| 压缩传输 | 跨集群时开启压缩 | 减少网络传输量 |
# 我在某短视频平台迁移30TB数据的配置
hadoop distcp \
-m 200 \
-bandwidth 100 \
-strategy dynamic \
-update \
-log /tmp/distcp-log \
hdfs://old-cluster/warehouse/ \
hdfs://new-cluster/warehouse/
# 优化前（默认参数）：30TB跑了12小时
# 优化后（200 Map + dynamic + 100MB/s限速）：3.5小时
# 提升3.4倍
# 关键经验：
# 1. -m参数是最大的杠杆——从默认20调到200，吞吐翻了好几倍
# 2. -strategy dynamic很重要——避免大文件卡住Map而小文件的Map早完成空等
# 3. -bandwidth要设——不然会把源集群的网络打满影响线上作业跨云/跨存储的数据迁移
除了HDFS到HDFS的迁移，还有一些常见的跨存储迁移场景：
| 迁移场景 | 工具 | 注意事项 |
|---|---|---|
| HDFS到S3 | s3-dist-cp 或 DistCp | S3路径格式：s3://bucket/path |
| S3到S3（跨区域） | AWS S3 Replication | 自动复制，按量付费 |
| HDFS到OSS | Hadoop-AliyunOSS插件+DistCp | 需要配置OSS AccessKey |
| MySQL到HDFS | Sqoop 或 FlinkCDC | Sqoop批量、FlinkCDC实时 |
| HDFS到Databricks | 不需要迁移（都用S3） | 存算分离的好处之一 |
实战经验：在某知名出海硬件品牌做EMR到Databricks迁移时，因为两边都用S3作为存储底座，数据层面不需要迁移——只需要在Databricks里配置访问同一个S3 bucket就行。这是存算分离的核心好处之一：换计算引擎不需要搬数据。
断点续传和失败处理
# DistCp失败后的处理
# 方法一：使用-update参数重跑
# -update只拷贝目标不存在或大小不同的文件
# 已经成功的文件不会重复拷贝
hadoop distcp -update -m 200 src dst
# 方法二：使用-log查看失败文件
hadoop distcp -log /tmp/distcp-log src dst
# 日志里记录了每个文件的拷贝状态
# 失败的文件可以单独处理
# 方法三：使用-overwrite强制覆盖
# 如果怀疑部分文件损坏，用overwrite重跑
hadoop distcp -overwrite -m 200 src dst
# 常见失败原因：
# 1. 网络超时（跨集群/跨机房）
# 2. 源文件被删除（拷贝过程中有人删了文件）
# 3. 目标集群磁盘满了
# 4. NameNode压力大导致请求超时面试高频追问
追问一：DistCp和hadoop fs -cp有什么区别？
hadoop fs -cp是单线程的客户端拷贝——数据经过客户端机器，速度慢且不可靠。DistCp是分布式拷贝——数据在集群节点之间直接传输，多个Map Task并行，速度快几十倍。大数据量迁移必须用DistCp。
追问二：跨集群拷贝时怎么保证数据一致性？
DistCp默认会校验文件大小，也可以开启CRC校验（-skipcrccheck关闭校验是为了加速）。拷贝完成后建议用hadoop fs -count对比源和目标的文件数和总大小。关键表再做行数和聚合值校验。
追问三：DistCp适合实时同步吗？
不适合。DistCp是批量拷贝工具，适合一次性迁移或定期同步。实时数据同步用FlinkCDC、Kafka或者HDFS的Snapshot+DistCp组合。如果需要跨集群实时同步HDFS数据，可以考虑Apache Falcon或ClouderaReplication。
总结
DistCp面试讲清楚三点：① 原理（底层是MapReduce作业，多Map并行拷贝）；② 调优（增加Map数、动态分配、带宽控制、增量拷贝）；③ 跨存储迁移的工具选择（HDFS/S3/OSS各有对应工具）。能讲出30TB迁移从12小时优化到3.5小时的调优过程，面试官会觉得你有大规模数据运维经验。
下一篇聊Hadoop的安全机制：Kerberos认证把新人搞崩了——Hadoop安全到底怎么做？
你们做过大规模数据迁移吗？用的什么工具？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长