蚂蚁OmniTable获VLDB 2026工业赛道最佳论文

大模型训练前的语料处理通常要经过解析、清洗、去重、质量评分、Token 化和样本组装。规模达到 PB 级后，工程团队需要维护数百张物理表和不断增加的特征，偶尔一条异常数据就可能让整批任务重跑。蚂蚁集团的一篇新论文，正好聚焦这一容易被忽视的数据准备环节。

在 9 月 1 日于波士顿举行的 VLDB 2026 上，蚂蚁集团论文《OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration》获评工业赛道最佳论文。OmniTable 是一套统一宽表系统，目前已在生产环境管理超过 35 PB、3050 亿条的大模型训练数据，覆盖 Web、代码、PDF 和 SFT 等数据域。在一项真实 SFT 数据准备任务中，端到端周期从约 14 天缩短至 2.5 天，手工操作步骤从 45 步降至 12 步。

蚂蚁集团论文获 VLDB 2026 工业赛道最佳论文

传统做法按物理表组织数据。一个数据源接入后，解析、清洗、质量分、去重签名等每一步都会落地成表，Web、代码、PDF、SFT 又各自维护一套流程。新增一个质量特征时，工程师要找到所有相关表、核对字段和版本，再为每个数据集配置任务。论文记录了一个真实案例：为了补一个特征，工程师需要在任务画布上处理 106 张表。

表只保存结果，很少完整记录结果是怎么算出来的。UDF 分散在不同代码库，输入列、算子版本、运行批次和下游训练任务之间缺少稳定关联。一旦需要排查异常样本或回刷历史特征，工程师往往要跨表、跨脚本追溯。

OmniTable 将这类问题归纳为三项工程成本：数据难定位、特征难回刷、结果难追溯。它的设计起点是：让数据批次和特征列成为一等对象，把物理表退回到存储实现层。

图 1：异构数据经过分散管道后形成彼此割裂的数据集

OmniTable 遵循“逻辑统一、物理分离”原则。在逻辑层，一行代表一条可追踪的数据实体，一列代表某个处理阶段的状态或衍生特征。RawData、ProcessedData 和 TrainableData 分别对应原始数据、处理中间态和训练可用形态，之后可继续添加质量、领域、安全等特征列。ai_unique_id 是全局主键，ai_append_name 则记录接入批次、来源和版本，为数据回刷、点查和血缘追踪提供稳定锚点。

生产环境按 Web、代码、PDF 和 post-SFT 划分为四张领域逻辑宽表，合计管理 35+ PB、3050 亿条以上记录。其中最大的 Web 宽表管理约 25 PB、3000 亿条以上记录，包含 800 多个逻辑列和 200 多个注册特征。这套对应关系由 Catalog 保存，底层可以拆行、拆列、合并小文件、调整分区，或为高频列组建立物化视图，上层 schema 和列语义不变。热点列物化的存储开销约为 8%–15%。

图 2：Catalog 连接数据接入、特征执行、查询导出与后台治理

特征定义与回刷也由系统接管。注册一个特征时，需写明输入列、输出列、UDF/SQL/模型推理逻辑、版本以及 CPU/GPU 偏好。提交回刷任务时只需指定目标批次和目标特征，OmniTable 会查询当前计算状态，沿列级依赖 DAG 找到最小依赖闭包，并按拓扑顺序生成物理执行计划。已完成的结果复用，缺失的祖先列进入计划；共享输入、执行引擎相同的算子还会合并到一次扫描中。任务完成后，Catalog 原子登记批次—特征列的状态、版本、物理位置和列级血缘。

非结构化语料中难免出现异常编码、超长文本或损坏内容。OmniTable 把常见 UDF 故障隔离到记录级：每次调用带超时和内存检查，遇到 OOM、超时或未捕获异常时，仅将该条结果写为 NULL，同时记录样本 ID、异常类型和摘要，其余记录继续处理，错误统一进入 error table。对照实验中，一个 500 GB、约 6 亿条记录的特征任务含 31,247 条异常记录（占 0.005%）。开启 failover 后，其余 99.995% 记录一次处理完成，耗时约 6.2 小时；关闭该能力，任务直接失败。旧流程需要三轮人工排查、删除和重提，总耗时约 52 小时。记录级包装会增加约 3%–5% 执行开销，但能避免单条异常拖垮整批任务。

图 3：系统解析依赖、生成计划并调度特征计算

不同特征的算力需求也不同。OmniTable 根据用户声明、算子画像和集群负载，在 Spark、MaxCompute SQL 与 GPU 推理平台间选择执行后端，并用自适应调优替代人工调参。算子融合实验里，8 个读取同一 parsed_text 的 CPU/Spark 特征被合并运行，扫描次数从 8 次降为 1 次，CPU Hours 减少 55.9%，端到端时间从 38 小时降至 14 小时。在 50 GB、500 GB 和 2 TB 三种批次规模的受控测试中，自适应配置首次提交成功率为 100%，任务成本与专家手调相差不超过 5%（对应特定 BERT 特征任务）。

图 4：算子融合与自适应调优

物理布局也不是一成不变。后台治理服务持续观察小文件累积、分区倾斜、列数增长和查询热点，自动执行小文件合并、行拆分、列拆分和物化视图构建。治理过程采用 Prepare—Execute—Commit：先完成新布局的物理重写，验证后原子切换 Catalog 映射，失败可回滚，用户查询逻辑列时不感知底层变化。

图 5：后台治理根据规模和访问模式调整物理布局

列拆分还让逻辑 schema 能越过单引擎的物理列数限制。在约 2 PB 数据的测试中，逻辑列从 200 增至 2500，P95 延迟约从 25 秒升至 38 秒，跨过了底层约 1200 列的物理上限。25 PB 规模下，用全局 ID 索引点查完整逻辑行的 P50 为 8.3 秒，P99 为 14.7 秒。物化视图消除热点列组 JOIN 后，一个涉及 15 列、4 张物理表的过滤导出场景，吞吐从 4.8 TB/小时提升到 20.1 TB/小时。