还在为大模型洗数据熬夜？蚂蚁拿下VLDB工业最佳论文，一套宽表搞定35PB语料，效率狂飙5.6倍
内容提要
蚂蚁集团研发的统一宽表系统OmniTable获VLDB 2026工业赛道最佳论文。该系统管理超35PB、3050亿条大模型训练数据，通过逻辑统一、物理分离设计，将数据批次和特征列作为一等对象，简化数据定位、特征回刷和结果追溯。实际应用中，SFT数据准备周期从14天缩短至2.5天，手工步骤减少73.3%，显著提升数据工程效率。
延伸解读
逻辑统一、物理分离：宽表设计的核心思路
OmniTable 的核心是“逻辑统一、物理分离”：上层将同一数据域的所有数据呈现为一张逻辑宽表，每行对应一条可追踪的数据实体，每列代表一个处理阶段或衍生特征；底层则按规模、访问方式和引擎拆分为多张物理表，由 Catalog 维护映射。这种设计让工程师无需关心物理布局变化，同时为数据定位、特征回刷和血缘追踪提供了稳定锚点。
记录级容错：避免单条坏数据拖垮整批任务
面对 PB 级数据中极低比例的异常记录，传统批任务常因单条 UDF 故障而整体失败。OmniTable 将故障隔离到记录级：每次 UDF 调用带超时和内存检查，异常记录被标记为 NULL 并进入错误表，其余记录继续处理。实验显示，在 500GB 数据中仅 0.005% 异常时，开启该能力可一次完成，耗时 6.2 小时，而旧流程需三轮人工排查，总耗时约 52 小时。
算子融合与自适应调优：降低计算与试错成本
多个特征读取同一列时，OmniTable 会将它们融合为一次扫描，减少重复 I/O。在 2.5PB 数据的实验中，8 个特征融合后扫描次数从 8 次降为 1 次，CPU 耗时减少 55.9%，端到端时间提速 2.7 倍。此外，系统根据历史信息自动调整资源参数，在受控实验中首次提交成功率达 100%，成本与专家手调相差不超过 5%，减少了人工试错。
工程效率提升的代价与适用边界
OmniTable 的优化并非没有成本：热点列物化增加约 8%–15% 存储，记录级容错带来 3%–5% 执行开销，后台治理也需占用集群资源。论文中的端到端提速 5.6 倍、手工步骤减少 73.3% 等数据，均基于特定 SFT 任务，不代表所有场景都能达到同等效果。因此，它更适合作为大规模数据工程的设计参考，而非普适方案。
Q&A
OmniTable是什么？它获得了什么奖项？
OmniTable是蚂蚁集团研发的一套统一宽表系统，用于管理PB级大模型训练数据。其论文《OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration》获得了VLDB 2026工业赛道最佳论文奖。
OmniTable的核心设计原则是什么？
OmniTable的核心设计原则是“逻辑统一、物理分离”。在逻辑层，同一数据域呈现为一张宽表，每行代表一条可追踪的数据实体，每列代表处理状态或衍生特征；物理层则按数据规模、访问方式和计算引擎拆分，由Catalog管理逻辑列与物理位置的映射。
OmniTable如何解决数据定位、特征回刷和结果追溯的问题？
OmniTable通过将数据批次和特征列作为一等对象，并引入两个系统字段：_ai_unique_id_作为全局主键，_ai_append_name_记录接入批次、来源和版本，从而为数据回刷、点查和血缘追踪提供稳定锚点。特征注册时记录输入列、输出列、逻辑、版本等，回刷时系统自动计算依赖闭包并生成执行计划，完成后原子登记状态和血缘，使得结果可追溯。
OmniTable在真实SFT数据准备任务中取得了哪些效果？
在一项真实SFT数据准备任务中，端到端周期从约14天缩短到2.5天，提速5.6倍；手工操作步骤从45步降至12步，减少73.3%；独立管道和脚本从24条降至10条，减少58.3%。
OmniTable如何处理异常数据？
OmniTable将常见UDF故障隔离到记录级，每次UDF调用带有超时和内存检查，遇到异常时记录样本ID、异常类型和错误摘要，将该条结果写为NULL，其余记录继续处理。错误记录进入error table，便于后续修复。在实验中，开启failover后，99.995%的记录一次处理完成，无需人工介入。
OmniTable如何优化计算资源利用？
OmniTable根据用户声明、算子画像、引擎能力和集群负载，在Spark、MaxCompute SQL与GPU推理平台之间选择执行后端，并结合历史运行信息调整资源参数。同时，通过算子融合将多个读取同一列的特征合并为一个任务，减少重复扫描。在实验中，8个特征融合后扫描次数从8次降为1次，CPU Hours减少55.9%，端到端时间提速2.7倍。
OmniTable的物理布局是如何动态调整的？
OmniTable的后台治理服务持续监控小文件累积、分区倾斜、列数增长和查询热点变化，自动执行小文件合并、行拆分、列拆分和物化视图构建。治理过程采用Prepare-Execute-Commit模式，先准备新布局并物理重写，验证通过后原子切换Catalog映射，旧布局在切换前继续服务查询，失败可回滚。
OmniTable的存储开销和局限性是什么？
OmniTable的存储开销包括：为热点列组建立物化结果可能增加约8%-15%的存储开销；记录级容错会增加约3%-5%的执行开销；后台治理会占用集群资源。此外，它无法消除机器故障、网络中断等所有失败，且不同企业的数据域、计算引擎和团队习惯不同，因此更适合作为系统设计参考。
