三个月我们迁移了100PB数据

2023年马上结束，这一年做了不少事情，有一项我可以吹好几年，忍不住和大家分享一下啊。

需求

---

 

去年底收到一项需求，要求2个月内从某云存储迁移100PB数据到微软云存储，包含几百亿个文件。当时听到这个数字我都惊呆了，别说100PB，100TB之前我都没迁移过，心里完全没底。但是老板说部门目前没有开发人员可以干这个项目，希望我能参与。没办法，我只能顶着巨大的压力参与项目的推进，核心开发人员就4位，还有售前架构师若干。

第一步就是和客户对接了解业务需求和当前数据现状，分析下来发现有几点要处理：

1. 客户有很多零碎小文件，这部分带宽利用率不高，肯定无法在规定时间内传完的，需要排除在本次任务范围外。
2. 存在很多文件有事务性，文件级别传输无法保证业务数据一致性，这部分文件一般是各种数据表，但总量占比低，需要单独处理。
3. 传输期间数据源不下线，意味着要做增量传输。
4. 跨云传输带宽上限不确定有多大，一开始以500Gbps为目标，后来发现天真了。

以上只是一小部分问题，实际数个月项目做下来积攒了一堆问题。

这个项目工期太紧，而且数据量巨大，传输一次就要数十万美元的流量费，只能成功不能失败，代价及其巨大！

技术方案及开发

---

 

回到开发部分，我们是4人的小型敏捷团队，我担任开发兼项目经理兼架构师。我们只花了2天时间就完成了各种方案和工具调研，并给出了设计的传输方案。

• 开源数据迁移工具，如 Hadoop 集群 distcp 远程拷贝

Apache DistCp 是一个开源工具，可用于复制大量数据。用户可以将 DistCp 命令作为一个步 骤添加到 Hadoop 集群中。使用 DistCp，用户可以高效地将大量数据从来源云存储复制到目标 HDFS 存储服务中。

 

 

 

DistCp使用MapReduce以分布式方式进行复制。它将文件和目录列表扩展为映射任务的输入，每个任务将复制源列表中指定的文件的分区。它跨多个服务器调度复制、错误处理、恢复和报告结果等任务。因此我们经常在Hadoop集群之间使用DistCp进行大规模分布式数据复制。

 

该方案优点如下：

• • 开源工具，无任何许可成本
  • 支持Hadoop集群间大规模复制数据
  • 对HDFS支持很完善
  • Apache基金会项目，项目持续被维护更新

缺点：

• • 存在功能使用限制，如不能在预先存在的目标目录下创建父源目录等问题
  • 云端Hadoop集群使用需要适配并集成DistCp驱动
  • 难以定制复制逻辑，拓展性差
  • 无法限制带宽占用
  • 无法处理来源云存储中文件发生版本更新的情况，不满足需求
• 商用SaaS数据迁移方案，如Azure Data Factory、AWS Glue、GCP Cloud Data Fusion等

以Azure Data Factory为例，它是基于云的ETL和数据集成服务，可让你创建数据驱动型工作流，用于大规模调度数据移动和转换数据。可以使用Azure数据工厂创建和计划数据驱动型工作流（称为管道），以便从不同的数据存储引入数据，同时直观地转换数据到目标存储中。

但该类SaaS产品传输性能有限无法满足当前项目的高性能要求，适合常规数据迁移任务。 

 

因此无论是商用的传输服务还是开源的Apache DistCp，都不能做到在规定时间内完成如此高的传输目标，最终还是决定自己定制化开发传输应用。

对此我们设计了如下关键特性：

• 采用1 Master Node，N个Work Node模式，实现分布式并行调度任务机制
• 采用高可用设计，单个复制任务应当能够自动重试
• 能够限制带宽调用
• 分布式数据存储
• 完整的任务记录
• 高性能。能够吞吐量达到250Gbps

我们对AzCpoy工具做了深度魔改，为此我临时学了Go语言，将其从单机程序修改为可以群集化弹性扩张的分布式并行数据复制应用，运行在复制节点上。针对大规模任务，我们还开发了控制程序，负责管理和派发复制任务给复制节点，并引入了额外的消息队列和Redis缓存，来实现整个分布式系统的调度。

针对并发任务的监控，我们额外引入了Azure CosmosDB作为高性能可弹性扩容的NoSQL数据库，能够承受每秒数万次的查询和写入。此外还针对增量更新文件的场景，开发了事件驱动的应用，用于侦听来源云存储的文件更新事件，异步触发数据复制任务。

整套系统我们只花了1周时间就开发完成第一个版本，额外花了1周进行测试。4个开发每天除了吃饭睡觉就在写代码，投入了巨大的心血，特别敬业。

上线

---

 

去年元旦我们的分布式复制系统正式上生产，结果第一天就出bug了，数据迁移数小时后卡住。经过紧急排查发现是调度程序的循环逻辑存在问题，永远跳不出来，这是相当低级的错误。主要原因还是工期太赶，大家各干各的，没有互联交叉审阅代码，因此质量不高。紧急修复后，重新上线。

结果第二天收到迁移来源的云存储厂商投诉，因为我们的复制速度太快，已经挤爆了他们公网400Gbps总带宽，影响其他客户的使用。如果不限制数据迁移任务，将会在平台层面封掉数据流量。

这点我很欣慰，至少证明我们开发的工具性能极高，有多少带宽可以占满多少。因此紧急着手限速工作，最后将传输的吞吐速度限制在200-250Gbps。

上线第一个月，我们就传输了50PB的数据。最终传输了100PB的数据，整个过程中我们的工具总体鲁棒性不错，比较符合设计预期。

 

总结

---

 

那几个月是我8年职业生涯以来压力最大的时间，也是我这些年来做过最具挑战性的项目。当然输出的成果也非常牛，这个牛我可以吹好多年。从来没想到我们可以做到这么超大规模的任务，仅仅流量费就要几十万美元，测试一次就要几千美元，烧掉好多台iPhone。

面对极限的压力，我们程序员总能爆发出超乎想象的能力，完全吹爆！！！