本系列文章将围绕东南亚头部科技集团的真实迁移历程展开，逐步拆解 BigQuery 迁移至 MaxCompute 过程中的关键挑战与技术创新。本篇为第一篇，跨国数仓迁移背后 MaxCompute 的统一存储格式创新。

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

背景

当东南亚头部科技集团 GoTerra 决定将其集团数据仓库从 BigQuery 迁移至阿里云 MaxCompute 时，这一决策背后折射出更深层的考量：全球化业务的区域合规性需求、亚太市场本地化部署的成本优化目标，以及对 PB 级数据处理能力的极致追求。

而 BigQuery 作为全球领先的云数据仓库产品，凭借其 Serverless 架构、弹性扩展能力与高并发处理性能，长期被视为全球范围内企业构建大规模分析型云数据仓库架构的标杆。其核心优势体现在：

• 全托管 Serverless 服务：屏蔽底层技术细节，免除底层基础设施维护，用户只需关注数据逻辑与业务需求；

• 与 Google 生态无缝集成：通过 Dataflow、Vertex AI 等工具实现数据处理与 AI 模型的闭环；

• 标准 SQL 与低延迟查询：支持复杂分析场景，尤其适合中小型企业快速启动大数据项目；

• 按需付费模式：避免预置资源浪费，对突发性数据增长具备天然适应性。

此次迁移属于非常复杂的跨国异构技术迁移，而是面临多重技术突破与业务挑战：

• 底层存储格式差异：BigQuery 与 MaxCompute 在底层存储格式与架构上存在巨大差异，需要在底层存储架构上进行大量的改造与优化，确保上层业务的迁移与日常使用尽可能平滑无感

• SQL 兼容性：MaxCompute SQL 与 BigQuery 的标准 SQL 在语法、函数库及执行引擎上存在差异，需开发自动化转换工具；

• 数据一致性保障：跨平台迁移过程中，如何避免数据丢失、版本冲突及 ETL 流程中断成为关键；

• 性能调优：MaxCompute 的分区表、资源组调度机制与 BigQuery 的列式存储优化策略需重新适配业务场景；

• 组织协同：跨国团队在迁移期间的系统可用性平衡与灰度发布策略设计。

本文将从底层存储格式差异与重构的技术角度，深入解析 GoTerra 在历时 9 个月的复杂迁移过程中，MaxCompute 在底层存储格式上做出的一系列技术演进与创新改造。

动机源于用户场景痛点

BigQuery 作为国际上先进的数据仓库服务商，依赖 Google 自身深厚的技术积累，以及长期以来客户场景的不断打磨，向用户提供了一套全面、灵活、免运维、高性能的数据仓库服务。特别值得注意的是，在同一套底层数据存储格式的基础上，BigQuery 向用户提供了包括数据流式写入、ACID 事务、索引、Timetravel、Auto Clustering 在内的多种底层存储数据管理能力。其支持用户根据实际业务需求来任意组合数据架构，极大降低了用户使用门槛，让用户在不需要理解底层存储原理的前提下就可便捷的应用数仓的各种数据功能。

相比之下，MaxCompute 在过去的技术路线中提供了其中包括 Standard Table 标准表，Range/Hash Cluster Table，Transactional Table, Delta Table 在内的 4 种不同的表类型，以满足多样的用户需求场景。然而多样化的表类型大大抬升了用户的使用门槛，用户需要深入每一种表类型各自的功能与限制，同时每一种表类型都有着自身较大的使用限制、表的能力没有办法随着用户场景的变化做动态适配，用户总是需要针对新的场景创建新类型表，学习、维护成本高。例如

• 追求高吞吐写入和通用性场景下使用 Standard Table 。

• 追求极致的查询性能（特别是 JOIN 和过滤）情况下使用 Range/Hash Cluster Table，存在部分写入和结构的限制。

• 需要支持行级更新（UPDATE）情况下使用的 Transactional Table 和 Delta Table 之间选择。

• 需要现代数据湖的复杂更新（UPSERT）和历史追溯能力的情况下使用的 Delta Table。

在 GoTerra 技术迁移的项目过程中，我们面临巨大的技术挑战，由于 GoTerra 集团自身业务的复杂性高。用户本身在 BigQuery 中使用到的表数量非常大，不同的互联网业务场景，数据的实时/批量写入、数据消费方式截然不同，对性能的要求也存在巨大差异，但客户有期望提供统一的表格式能够同时支持以上四种不同表所拥有的优势与特性。用户能够使用同一种表类型完成了对所有业务场景的支持。但是在 MC 当前的产品形态下，用户一方面需要对 MC 的各种表类型进行深入的学习理解，同时还需要 GoTerra 对当前已有业务的数据使用方式进行深入分析与归纳，这里涉及到各个业务部门大量人员的培训和海量数据业务场景的深入分析梳理，整体的迁移因为大量的培训分析工作迟迟无法有效推进。

综上所述，在较短的时间内完成海量数据和极端复杂业务场景的迁移，给我们提出了如下挑战：

• 统一底层存储格式，同时支持多种的数据能力并进行功能整合，在底层存储能力上打破功能碎片化的局面

• 实时化：通过流式数据写入、增量数据处理、增量计算 Pipeline 的构建，提升数仓实时能力

• 智能化：动态能力与 Auto Scaling 能力增强，进一步提升产品自适应免运维能力

存储技术方案解析

结合 MaxCompute 当前已有存储技术能力以及未来存储格式演进的规划，通过对系统工程实现和存储格式的梳理重构，我们推出了 Append DeltaTable，通过新的表格式，我们达成了以下几个技术核心功能：

• 通过单一的，可拓展的表组织结构，同时获得包括动态 Cluster 分桶、ACID 事务、数据 append，数据流式写入、timetravel、incremental read、二级索引在内的多种数据写入、访问、组织、索引能力

• 支持用户根据使用场景的变化，对表的数据组织形式与功能进行按需调整和修改

• 主要数据访问、写入链路、消费接口与存量表格式保持兼容，降低用户的使用门槛和迁移门槛

• 在能力拓展的同时，数据基础读写、访问性能与存量表格式相比不发生回退，保持我们在成本与性能上的竞争优势

Append DeltaTable 的推出，一方面是对存量表格式已有功能场景的整合，支持了包括 ACID 事务、数据 append，数据流式写入、Timetravel 等能力，让用户能够在同一种表类型内部不受限制对多种能力进行组合，按需对业务场景进行适配。

专业用词:

• MaxCompute Append DeltaTable TableFormat(表格式):MaxCompute 在 2025 年最新推出的基于 RangeCluster 表结构来构建的增量数据表格式。

• Data-Bucketing:Bucketing 就是利用 buckets（按列进行分桶）来决定数据分区（partition）的一种优化技术，它可以帮助在计算中避免数据交换（avoid data shuffle）。并行计算的时候 shuffle 常常会耗费非常多的时间和资源。MaxCompute 在 Range/Hash Cluster 表格式中初次引入了 Bucket 概念。

• Data-Clustering: Clustering 聚合是管理和优化数据仓库的数据存储和检索的基本技术方案，通过将相关数据在物理上集中存储，支持通过数据裁剪达到提升查询效率的目的

• Range Clustering 表：Range Clustering 作为一种新的数据切分方式，按照一个或多个列的范围顺序存储数据，数据按键值大小排序并存储, 提供了一个全局有序的数据分布。

• Hash Clustering 表：通过设置表的 Shuffle 和 Sort 属性，按照哈希函数将数据分布到不同的桶（buckets）中, 数据按键值哈希后的结果存储。

在这里我们着重介绍在 GoTerra 数据迁移场景中，为了倍数级提升海量数据存储与计算效率，降低业务迁移成本。在此我们介绍在 Append DeltaTable 表格式中关键几个核心特性:

Storage Service - 数据自治服务

Storage Service 是 MaxCompute 自研的分布式存储引擎核心组件，其负责海量数据在高可靠存储、高吞吐读写的情况下智能数据治理服务。随着云数仓场景从大数据规模向 AI 原生智能架构的不断演进，Storage Service 需解决以下关键挑战：

• 存储效率：PB 级数据冷热分层、压缩比优化、碎片治理。

• 计算协同：支持 Append DeltaTable 表格式的动态分区、增量读取、列式转换。

• 弹性扩展：适配跨区域集群的动态负载波动（如大促期间日均 PB 级数据迁移）。

Storage Service 通过支持以下后台数据作业任务实现数据的自运维、自优化、自愈合的能力，显著降低人工干预成本。系统的支持数据自动治理服务，其包括不限于以下工作任务：

• 文件合并与重写: 即基础的 Merge Task，合并小文件降低存储 Master 的压力，同时，支持数据重写使用更高的压缩率和编码算法，以及写出 RAID 文件等，提供数据 archive 的能力。

• Auto Tiered Storage: MaxCompute 作为跨 Region 超大存储集群，计算能力需支持每天都要在不同 Storage Tier 之间搬运 PB 级数据。

• Minor Compaction & Major Compaction: 在支持 Append DeltaTable Table 之后，存储层提供了 Minor Compaction（保存版本，但消除小 delta 文件），以及 Major Compaction（合并消除版本）两种模式，用于存储效率优化。

• Index Building: 构建包括 Bloomfilter, BitmapIndex 等数据索引。

• Streaming Compaction: 在数据管道 Tunnel 流式写入数据的场景，支持对行存文件的合并以及转换成列式文件（AliOrc）。

• Data Reclustering: 在 Streaming 写入 Hash/Range Clustering Table 的场景下面，我们支持把新 Append 追加写入的无序数据，重新进行 partitioning 分区和 ordering 排序，并合并到原有的 clustering table。

• Data Backup: 通过跨地域复制实现异地数据备份。

Storage Service 在支持以上后台自动数据治理的任务，通过数据重排/重分布/复制等多种方式持续优化数据计算/存储效率。Storage Service 数据自治服务系统分为两大部分，Service Control 和 Service Runtime，前者负责接收外部请求，排队，路由，并将请求转发到计算集群。后者则将一个请求转换成具体的执行计划，并提交 Service Job Plan 执行请求。以 Service Control 控制服务来收集后台数据任务需求，分发到计算集群，再在 Service Runtime 环境中转换成具体执行计划，提交 Service Job，完成后台工作任务。

Dynamic Bucketing - 动态 Bucket 数据优化

在创建 Range/Hash Cluster 表时，用户需要提前评估对应业务的数据规模，以此为依据设置合适的 Bucket 数量和 cluster key。在完成 Cluster 表创建后，MaxCompute 通过 clustering 算法将数据按照 cluster key 路由到各自对应的 Bucket 中。正因为此产品设置，当数据量太多但是 Bucket 数量太少，会导致单个 Bucket 数据量过大，那么查询时数据裁剪效果不佳。但是反过来，如果设置的 Bucket 数量远远大于业务数据量所需要的范围，会导致每个 Bucket 内数据量太少而产生大量碎片文件，对查询性能也会造成不良的影响。因此，在创建表时，根据业务的数据量设定合适 Bucket 数量无形中抬升了用户的使用门槛，用户需要同时对业务本身对使用模式和 MaxCompute 底层表格式都有一定的理解，才能够正确使用 clustering 的相关能力，发挥出 clustering 带来的查询性能收益。

这种用户在建表时显示指定 Bucket 数量的表固定设置方式带来了几个问题：

• 在大规模数据迁移场景，用户需要对每一张表的潜在业务使用规模进行评估，如果表的数量比较少，评估工作还可能通过专项推进，但是当面对成千上万张表时，对每一张表的数据规模进行评估就变得非常难以执行了

• 即使用户对表的数据规模在当下都做了准确的评估，但是随着业务自身的演进，实际的数据规模也会持续变化，在当下适用的 bucket 数量设置可能在未来变得不再适用

综上所述，静态的 Bucket 数量配置无论是在大规模数据迁移场景，还是在业务快速变化的日常使用环境中，都难以做出有效的支撑，更合理的方式，是平台根据用户实际数据量大小，动态地设置所需要的 bucket 数量，用户不需要对底层的 bucket 数量进行感知，一方面大大降低了用户的学习和使用门槛，另一方面对于不断变化的数据规模，也能够更好地做出适应。

因此，Append DeltaTable 表格式在设计之初就支持了 Bucket 的动态分配，所有存储在表中的数据都被自动划分为 Bucket，每一个 Bucket 都是一个逻辑是连续的存储单元，包含了 500MB 左右的数据。用户在创建和写入数据之前，并不需要在表层面指定 Bucket 的数量，随着用户数据的持续写入，新的 Bucket 会不断被按需创建出来，用于承载用户的数据。用户并不需要担心随着数据量的增加或者减少，会导致 Bucket 内数据量过大或者过小导致的数据倾斜和数据碎片问题。

Incremental Reclustering - 增量重聚合

Clustering 是数据领域最常见的数据优化手段之一，cluster key 是用户指定的表属性，通过将用户指定的数据字段进行排序并且进行连续的存储，当用户对 cluster key 进行查询时，我们可以通过下推裁剪等优化，大大缩小数据扫描的范围，从而达到提升查询效率的目的。

如上图所述，MaxCompute 之前提供了 Range/Hash Clustering 两种 Clustering 能力，支持用户通过 Range 分桶或者 Hash 分桶对数据进行分桶，并对单个桶内的数据进行排序，通过对查询过程中 Bucket 裁剪和单个桶内数据的裁剪，达到查询加速的效果。然而，Range/Hash Clustering 的表能力存在的一个限制是，数据必须在写入过程中就完成数据的分桶与排序，从而达到一个全局有序的状态，不支持。因此对数据写入的方式进行了限制，要求数据必须以 insert overwrite 的形式一次性写入，数据写入完成后，如果需要再进一步追加数据，则需要将表中原有的数据全部读取，与新增数据 union 之后再次写入，数据追加代价非常大，效率很低。

如上图所示，一般来说，业务通常不会对 ODS 层的数据表使用 clustering，原因在于 ODS 层的数据比较接近原始的业务数据，通常是通过外部的采集链路持续导入的，对数据导入的性能有很高的要求，原有 clustering 表代价巨大的写入模式无法满足低延迟高吞吐的写入要求。因此业务侧往往倾向于在 DW 层的表中设置 ClusterKey，对在前一个业务日期完成数据导入的 ODS 表进行数据清晰后导入到新的数据相对稳定的 DW 层，进而加速后续的查询业务性能。

但是这种方案带来的问题在于 DW 层数据的新鲜度上会存在一定的延迟，为了避免反复更新 DW 层带来的读写放大，DW 层的更新通常在 ODS 层数据稳定后才进行，这导致通过 DW 层查询到的数据在业务日期上是存在滞后的。然而在 GoTerra 迁移的过程中，业务方对查询性能和数据新鲜度都有着非常极致的要求，希望能够在 ODS 层之间实现 Clustering，通过对 ODS 表的数据查询加速，获取实时信息。

因此，原本 MaxCompute 提供的在写入数据时同步执行 Clustering 的方案无法在数据的实时性上满足用户诉求。Append DeltaTable 的增量 Clustering 能力，通过后台数据服务异步执行增量 Clustering 的方式，在数据导入性能，数据实时性，以及数据查询性能上做到了最大限度的平衡。

如上图所示，用户数据通过 Streaming 写入的方式导入 MaxCompute，写入阶段为了最大限度保障写入延迟与吞吐，数据直接以未排序的方式落盘，被分配到新分配到 Bucket 中。此时由于新写入到 Bucket 数据没有执行 Clustering 操作，新增 Bucket 在数据范围上会和其他已经完成 Clustering 的 bucket 产生重叠。在执行查询任务时，SQL 引擎对 Clustered Bucket 执行 Bucket 裁剪，对增量 Bucket 则执行扫描。

如上图所示，MaxCompute 后台数据服务持续对 Bucket Overlap Depth 进行监控，当 Overlap 达到特定阈值后触发增量 Reclustering，对新写入的 Bucket 执行 Reclustering 操作，确保用户数据的主题部分始终维持在一个有序状态，从而确保了整体查询性能的稳定。

Performance Improvement - 显著性能效果

Append DeltaTable 创新表格式在复杂业务场景上优秀表现从侧面反映出数据存储格式的技术优化对大数据分析场景下的核心价值。其技术价值 &性能优化总结如下：

1. 数据自治：

• 通过 Merge、Compaction、Reclustering 等后台任务，实现存储效率与查询性能的动态平衡。

2. 弹性扩展：

• 动态 Bucketing 与 Auto-Split/Merge 策略，支持从 TB 到 EB 级数据的无缝扩展。

3. 实时 Clustering：

• 增量 Reclustering 在 ODS 层实现毫秒级数据新鲜度与 Clustering 查询加速。

实践总结

Append DeltaTable 的推出一方面结束了 MaxCompute 一直以来存在的功能割裂状态，大大降低了用户对于底层存储格式的理解和使用成本，在继承 MaxCompute 一如即往优秀性能的同时，灵活性，时效性，场景的多样性上都有了巨大的提升。在 GoTerra 迁移项目中，Append DeltaTable 的推出极大提升了 GoTerra 项目总体的迁移效率。Append DeltaTable 作为 Maxcompute 用于迁移 BigQuery 数据的唯一表格式，承接了包括 55w 张表，60+PB 数据的全量迁移工作。也证明了 Append DeltaTable 在自身整体的架构设计和整体实现上能够支持和 BigQuery 等国际一流厂商的全方位能力对标。

Append DeltaTable 的成功落地不仅标志着 MaxCompute 在存储架构上的重大突破，更预示着云原生数据平台在规模化、实时化、智能化方向的演进趋势。在兼顾 MaxCompute 原有的高吞吐批处理能力的同时，填补了传统数据仓库在时效性上的短板。这种设计使 GoTerra 得以在迁移后无缝衔接历史批处理作业与新兴的实时分析需求，例如将用户行为日志的分钟级处理延迟压缩至秒级，为东南亚市场的动态定价、风控模型迭代等场景提供实时决策支持。

未来技术规划

从更宏观的未来视角看，Append DeltaTable 创新表格式的推出体现了阿里云对 Data + AI 融合架构的前瞻性布局。其底层的列式存储与向量化引擎为 AI 机器学习特征工程提供了天然数据加速路径。而未来技术规划趋势在于近实时数据处理与多模态数据存储能力。其中多模态数据（如文本、图像、时序）的统一存储能力，则为企业构建跨模态分析流水线奠定了基础。GoTerra 的海量数据迁移是国内企业迈向全球数据治理标准的关键一步——中国自主研发的数据基础设施已具备支撑跨国企业级复杂业务的完整能力。未来，随着 Append DeltaTable 与 MaxCompute 原生实时计算组件的深度集成以及 Delta Live MV 能力的进一步推出，MaxCompute 将进一步释放数据资产的全生命周期价值，为云原生时代的数据革命提供中国方案。