蚂蚁集团｜OmniTable获VLDB工业最佳论文，服务约35PB语料准备

训练大模型前，语料解析、清洗、去重、打分与样本组装，往往比「再加一张卡」更耗工程师生命。蚂蚁集团研发的统一宽表系统OmniTable，以论文《OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration》拿下VLDB 2026工业赛道最佳论文，并于9月1日在波士顿大会场景中获颁相关奖项；论文刊于PVLDB Vol.19 No.12。

蚂蚁集团长期在支付、风控与大规模数据处理上积累工程能力，近年把同类能力延伸到大模型训练的数据准备环节。OmniTable要解决的不是单次任务「能不能跑通」，而是PB级语料持续增长时，特征、批次与血缘如何长期可管理——这正是很多模型团队熬夜洗数据却仍频繁整批重跑的根因。

论文披露的生产与评测要点：

1. 规模：生产环境管理超过约35 PB、约3050亿条以上记录，覆盖Web、代码、PDF与SFT等域；最大Web逻辑宽表约25 PB、约3000亿条以上，含800多个逻辑列与200多个已注册特征
2. 设计：逻辑统一、物理分离——上层一张可查询逻辑宽表，底层按规模与引擎拆分物理表；特征注册为带版本、依赖与血缘的系统资产
3. 端到端：真实SFT数据准备由约14天、约45个手工步骤，缩至约2.5天、约12步，提速约5.6倍
4. 工程能力：记录级容错（少数坏样本不拖垮整批）、算子融合减少重复扫描、后台自动整理小文件与物化热点列
5. 代价：热点列物化可能增加约8%–15%存储开销；记录级包装增加约3%–5%执行开销

所谓逻辑宽表，白话是让数据工程师少在成百上千张中间表之间找路；所谓记录级容错，白话是一条异常编码不再逼你整TB重跑；所谓列级血缘，白话是每个特征「怎么算出来的」都能追到输入批次与算子版本。论文还记录过一个现实痛点：补一个特征，工程师曾要在任务画布上处理106张表——宽表要把这类协调成本从人手里收回系统。

放在大模型基建上下文里，行业叙事长期偏算力与模型分数，数据准备常被当成「脏活」。当语料进入几十PB量级，脏活会变成主瓶颈：定位难、回刷难、追溯难。OmniTable把讨论从「算力够不够」拉回「数据准备能不能工业化」，对同行模型厂与数据平台团队是一份可引用的系统设计样本。

产业影响上，若同类宽表/特征平台成为标配，训练迭代周期与人力成本曲线都会改写；若仍停留在论文与内部系统，外部客户仍要自己拼管道。需要把边界读清楚：提速与规模数字来自论文评测与生产披露口径；不同企业引擎与组织习惯不可直接照搬。下一观察点是开源或对外产品化节奏，以及更多厂商是否公开对标同类指标。