【跨国数仓迁移实践 10】 MMS 助力 GoTerra 实现 BigQuery 到 MaxCompute 50PB 数据迁移

本系列文章将围绕东南亚头部科技集团 GoTerra 的真实迁移历程展开，逐步拆解 BigQuery 迁移至 MaxCompute 过程中的关键挑战与技术创新。本篇为第 10 篇，MMS 如何助力 GoTerra 实现 BigQuery 到 MaxCompute 50PB 数据迁移。

注：客户背景为东南亚头部科技集团，文中用 GoTerra 表示。

2025 年 6 月，随着 GoTerra 集团最后一个 GCP BigQuery 分区 19.5 GB 的数据迁移到阿里云 MaxCompute，历时 6 个月、总量高达 50PB 的数据迁移项目终于圆满收官。这是一个跨越大洲(从美国到印尼)、涉及 10 多个公司实体、数十个 project、数十万张 table 的大规模迁移工程，目标是在仅 6 个月内完成迁移——任务艰巨，挑战空前。

这不是一次传统的全量同构迁移，还包含增量异构迁移，对迁移工具、数据处理能力、网络传输、协同机制都提出了极高要求。而这一切，都由为大数据迁移而生的 MMS（MaxCompute Migration Service） 轻松承载。

1、项目背景与挑战

GoTerra 集团把大数据业务从 BigQuery 迁移到 MaxCompute，项目涉及非常广泛：

• 数据规模：按 BigQuery logical size 统计，大约 50PB

• 数据对象：大约 70 个 Project、10 万张 table

• 业务范围：10+个 Account，每个 Account 背后是一个子公司实体

• 项目节奏：2025 年 1 月启动迁移，6 月底完成

除此之外，还有技术上的挑战：

1. DataType 复杂:客户大量使用 Array、JSON 和 Struct 类型，其中存在多层 Struct 类型嵌套的情形，还使用到 Decimal、timestamp、datetime 等类型

2. 分区策略多样: BigQuery 支持非常灵活的分区策略，比如 Time-unit column partitioning 和 Ingestion time partitioning

3. 迁移速度要求高: 6 个月迁移 50PB，不出任何差错的情况下，至少每周迁移 2PB。因此每周 3PB 才有较大容错空间

4. 迁移灵活调度: 需要满足不同业务方多样化优先级需求

5. API first：所有迁移功能，必须以 API 的形式提供给 GoTerra 客户

2、对象迁移方案

2.1 数据对象映射

BigQuery 采用三层对象模型：Project -- Dataset -- Table

因此迁移到 MaxCompute，继续保持三层模型：Project -- Schema -- Table

2.2 数据类型映射

2.3 分区策略映射

BigQuery 提供非常丰富的分区策略

2.3.1 Integer range partitioning

- 按指定integer column的range 分区- 由于客户没用到该分区策略，MaxCompute没有支持

2.3.2 Time-unit column partitioning

- MaxCompute通过 auto partitioned 机制 生成一个伪列来等价实现BigQuery Time-unit 分区效果- DDL demo如下：

2.3.3 Ingestion time partitioning

- BigQuery在处理Ingestion time partitioning时，通过在insert record时，自动记录insert timestamp，并存储在 伪列_PARTITIONTIME上- MaxCompute通过auto partitioned 来实现BigQuery的Ingestion time分区效果- DDL demo 如下：

3、迁移系统架构

迁移系统在技术选型上

3.1 方案一

• 先把 BigQuery table 数据 dump 到 GCS

• 再通过传输工具把 GCS 文件传到 OSS

• 最后使用 MaxCompute external table 技术把 OSS 文件导入

3.2 方案二

基于 BigQuery Read API，通过 MaxCompute Spark 直接读 BigQuery 数据，直接写入 MaxCompute

3.3 方案选型

综合考虑了易用性、成本与架构简洁性，MMS 选择方案二。

3.4 网络专线方案

4、迁移关键技术

提供对象映射能力只是“万里长征第一步”，在此之上还要解决迁移速度、迁移原子性、优先调度、Column-Reorder-Fillback、双跑追增量等关键问题。

4.1 迁移速度优化

为了做到每周 3PB 的迁移速度，MMS 主要从以下三方面着手：

• 网络带宽层面，需要专线保障，规划 50Pbs

• 迁移系统读 BigQuery 数据时，启用压缩

• 为 Spark 迁移任务预备了数千 CU 计算资源，随时待命

经过以上优化后，迁移专线带宽常态化接近用满的状态

每周 3PB 的目标也很轻松达到，顶峰时期，单天跑出 1.92PB 的极限速度。

4.2 迁移原子性

客户有一天在群里问我们，有个 partition 明明有数据，为什么有时查不到数据。

经过分析发现，MMS 在迁移的时候，采用的做法是

drop if exists partitioncreate if not exits partitioninsert into ... select ...

以上流程明显有问题，在 drop 和 commit 之间，从数据使用者角度 这个 partition 就是没数据的。

假如这个时候迁移系统因为网络或 pod 资源问题，可能会造成更大时间跨度的不一致。

因此，一种具备原子性的迁移方案呼之欲出：

insert overwrite ... select ...

由于 MaxCompute 只支持 statement 级别的原子性，insert overwrite 语句的效果，相当于 DBMS

begin;drop if exists partitioncreate if not exits partitioninsert into ... select ...commit;

4.3 优先调度

GoTerra 客户内部有上百个业务团队，他们对不同 table、partition 迁移紧迫性是不一样的。

1. 有的部门说，我今天就要在 MaxCompute 用到这些数据，越快越好

2. 有的部门说，这批数据，我这几天还不需要的，但是我下周一定要用到

3. 有的部门说，这批数据，量非常大，我几个月后才需要

由于上述第 1 类场景的存在，GoTerra 客户负责数据迁移的平台团队，一开始每天向内部收集迁移需求，然后向 MMS 提交一批迁移任务。要确保这批任务全部完成后，他们才会启动下一批迁移任务。

有时客户内部有紧急迁移需求，还不得不暂停正在迁移的任务，让 MMS 优先处理紧急的。

等到这批紧急的迁移完成后，再人工重启刚刚暂停的任务。

沟通成本非常高！

这样运行了一周后，MMS 团队被客户搞崩溃了，于是设计了基于优先级的调度功能。

这里的优先级 priority 不是传统的自然数 ( 比如 0~9 ) ，毕竟确定 priority 每个 value 的语义，也不是容易的事。

MMS 团队借用了平时排需求的**ETA（Estimated Time of Arrival）**概念，作为实际的优先级定义，无论是客户，还是 MMS 团队，都很容易理解哪天需要完成这个迁移任务。

有了基于 ETA 优先调度能力后，客户就可以更好的统筹迁移任务，并且 MMS 可以做到 7*24 全天候迁移。

4.4 Column-Reorder-Fillback

为什么会出现 column reorder

GoTerra 客户存在一批实时写入的 streaming 表，数据架构大致如下：

Kafka 系统的 message 是带 record schema 的

客户自建了一个 X-Flink 系统(类似 Flink 的流计算系统)，根据上游 kafka 的 message，按需执行 add column。

对于这一类 streaming 表，靠迁移 BigQuery 端的数据，是永远无法把 X-Flink 系统迁移到 MaxCompute 的

因此迁移过程，源端 streaming 表与目标端 streaming 表将在一段时间同时被写入的情况，即双跑局面：

• 1 实时系统 推送消息到 kafka

• 2 GCP 侧 X-Flink 拉取 kafka 数据

• 3 GCP 侧 X-Flink 实时写入 GCP 侧 Streaming 表-A

• 4 阿里云侧 X-Flink 拉取 kafka 数据

• 5 阿里云侧 X-Flink 实时写入阿里云 Streaming 表-B

• 6 GCP 侧 Streaming 表-A Fillback 数据到阿里云 Streaming 表-B

在双跑期间，由于各种各样的原因，阿里云 Streaming 表与 GCP 侧 Streaming 表数据将存在差异

因此需要步骤 6 Fillback 来修正两边 Streaming 表的差异。

同时，由于步骤 3 与步骤 5 执行 add column 的时机不同，就导致表 A 与表 B 的字段顺序不同。

如何处理 Column reorder Fillback

• 对于基本类型的字段，column reorder fillback 是比较简单的

• 对于 Struct 嵌套类型的字段，需要逐级对 sub field 做旋转操作

以 struct 类型为例，

create table a(  c1 struct<c1_1:String,c1_2:struct<c1_2_1:String,c1_2_2:String>,c1_3:String>);
create table b(  c1 struct<c1_3:String,c1_2:struct<c1_2_2:String,c1_2_1:String>,c1_1:String>);

以下是 column reorder 的 fillback 过程如下：

4.5 双跑期间增量数据迁移优化

双跑期间，GoTerra 客户几乎所有的 ETL 都要在 BigQuery 与 MaxCompute 两边同时运行。

为了能在 MaxCompute 侧运行当日 ETL，需要提前准备好对应的上游数据分区。

客户要求 MMS 在 2 小时内把这些分区的数据从 BigQuery 迁移到 MaxCompute。

为此，MMS 系统对任务调度算法进一步升级。

为了方便描述，下文把 SLA=2 小时的迁移任务，称为紧急迁移任务。

原有的调度算法

原来调度 priority(ETA)只在 Project 内生效，即不同的 Project 的迁移任务完全隔离。

如下图，MMS 会从每个 Project 中挑选 ETA 最小的 task 执行

如上图，Project A 有 4 个紧急迁移任务，ETA 都在 2024 年 5 月份，

Project B 有 4 个普通迁移任务，ETA 都在 2025 年 5 月份。

此时 task1 与 task5 同时被调度执行。

客户双跑第一天，紧急迁移任务平均完成时间超过 6 小时，远低于客户要求。

改进后的调度算法

只要把 Prority 改为全局调度就解决了客户问题

改进后，紧急任务的平均完成时间在 30 分钟以内，顺利保障了客户双跑期间对上游分区的紧急同步需求。

5、未来规划

在完成 GoTerra 客户迁移后，MaxCompute 与 MMS 产品依然在演进：

• 未来将全面对齐 BigQuery 数据类型，尤其是 Geography 与 BigDecimal

• MMS 将支持 View 的迁移

• 支持更智能的调度算法，动态感知带宽并调整迁移任务资源分配