本系列文章将围绕东南亚头部科技集团的真实迁移历程展开，逐步拆解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将进一步释放数据资产的全生命周期价值，为云原生时代的数据革命提供中国方案。
