还在为大模型洗数据熬夜？蚂蚁拿下VLDB工业最佳论文，一套宽表搞定35PB语料，效率狂飙5.6倍

< img id="wx_img" src="https://www.qbitai.com/wp-content/uploads/imgs/qbitai-logo-1.png" width="400" height="400"> 还在为大模型洗数据熬夜？蚂蚁拿下VLDB工业最佳论文，一套宽表搞定35PB语料，效率狂飙5.6倍 量子位的朋友们 2026-09-02 14:20:17 来源： 量子位 蚂蚁集团推出统一宽表系统OmniTable，论文获评VLDB 2026工业赛道最佳论文 训练一个大模型之前，语料要经过解析、清洗、去重、质量评分、Token 化和样本组装。规模来到 PB 级，工程团队每天面对的不止算力账单，还有数百张表、不断增加的特征，以及少数几条就可能让整批任务重跑的异常数据。 今年的 VLDB 工业赛道最佳论文，关注的正是大模型训练中非常重要，但也常被忽视的环节——数据准备。论文《OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration》介绍了一套由蚂蚁集团研发的统一宽表系统 OmniTable。 （图说：蚂蚁集团论文《OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration》获评 VLDB 2026 工业赛道最佳论文，9 月 1 日在波士顿举行的大会上获颁奖项。） 论文链接：https://www.vldb.org/pvldb/vol19/p4276-fu.pdf 论文披露，OmniTable 已在生产环境管理超过 35 PB、3050 亿条以上的大模型训练数据，覆盖 Web、代码、PDF 和 SFT 等数据域。在一项真实 SFT 数据准备任务中，端到端周期从约 14 天缩短到 2.5 天，手工操作步骤从 45 步降至 12 步。 这个结果并非来自一台更快的机器。OmniTable 改了数据工程师组织数据和特征的方式：同一数据域在上层呈现为一张逻辑宽表，底层继续按数据规模、访问方式和计算引擎拆分；特征也从脚本中的临时计算，变成带有定义、版本、依赖和血缘的系统资产。 一个特征，为什么会牵出 106 张表 传统的大模型数据加工通常围绕物理表展开。一个数据源接入后，解析结果落一张表，清洗结果再落一张，质量分、领域标签、去重签名和安全标记继续产生新的表或中间结果。Web、代码、PDF、SFT 又各自维护一套流程。 单条管道并不难理解。数据源和特征持续增加后，维护对象会迅速膨胀。新增一个质量特征，工程师需要先找到所有相关表，核对字段和版本，再为每个数据集配置任务、资源、检查点和失败处理。论文记录了一个实际案例：为了补一个特征，工程师需要在任务画布上处理 106 张表。 更麻烦的是，表只保存结果，很少完整记录结果是怎样算出来的。UDF 分散在不同代码库，输入列、算子版本、运行批次和下游训练任务之间缺少稳定关联。排查一条异常样本时，工程师往往要跨表、跨脚本追溯；特征版本一旦变化，还要判断哪些历史批次需要重新计算。 OmniTable 将这类问题概括为三项工程成本：数据难定位、特征难回刷、结果难追溯。系统的设计起点也很直接——让数据批次和特征列成为一等对象，把物理表退回到存储实现层。 图 1：异构数据经过分散管道后形成彼此割裂的数据集。来源：论文 Figure 1。 “一张表”位于逻辑层 OmniTable 的核心原则是“逻辑统一、物理分离”。 在逻辑层，每一行代表一条可追踪的数据实体，每一列保存某个处理阶段的状态或一项衍生特征。RawData、ProcessedData 和 TrainableData 分别对应原始数据、处理中间态和训练可用形态，后面还可以继续添加质量、领域、安全、去重等特征列。 两类系统字段负责把这些列对齐。_ai_unique_id_ 是全局主键，同一条数据在不同来源、处理阶段和特征列中使用同一个标识；_ai_append_name_ 记录接入批次、来源和版本。数据回刷、点查和血缘追踪都有了稳定锚点。 这里的“一张表”是一份逻辑契约。生产环境按 Web、代码、PDF 和 post-SFT 划分为四张领域逻辑宽表，合计管理 35+ PB、3050 亿条以上记录；每张逻辑表的列由其 Table Family 中的多张物理表承载，并可继续按行、按列拆分。其中最大的 Web 宽表管理约 25 PB、3000 亿条以上记录，包含 800 多个逻辑列和 200 多个已注册特征。论文还在固定约 2 PB 数据的受控实验中将逻辑列扩展到 2500 列。 逻辑列与物理位置的对应关系由 Catalog 保存。底层可以拆行、拆列、合并小文件、调整分区，或为高频列组建立物化视图，上层的 schema 和列语义保持不变。下游查询无需跟着每次物理调整修改。论文也给出了这项设计的代价：为热点列组建立物化结果，可能增加约 8%–15% 的存储开销。 图 2：Catalog 连接数据接入、特征执行、查询导出与后台治理。来源：论文 Figure 2。 特征计算从“画任务”改成“报目标列” 统一逻辑视图解决了“数据在哪”的问题，Catalog 继续管理特征怎样产生。 一个特征注册时，需要写清输入列、输出列、UDF／SQL／模型推理逻辑、版本，以及 CPU 或 GPU 的执行偏好。工程师提交回刷任务时，只需指定目标批次和目标特征。OmniTable 会查询当前计算状态，沿列级依赖 DAG 找到尚未完成的最小依赖闭包，再按拓扑顺序生成物理执行计划。 例如，某个质量分依赖清洗文本，而清洗文本又依赖解析结果。旧流程需要工程师确认三段任务是否齐全，并分别定位输入输出表。OmniTable 直接检查这些列在目标批次上的状态：已经完成的结果复用，缺失的祖先列进入计划。共享输入、执行引擎相同的多个算子还能合并到一次扫描中。 任务成功完成后，Catalog 原子登记“批次—特征列”的状态、版本、物理位置和列级血缘；未提交的结果不会进入稳定逻辑视图。此后再查询一列数据，系统能够回答它用了哪个输入批次、依赖哪些父列、采用哪个特征版本、由什么引擎计算，以及结果落在什么位置。 过去分散在脚本、调度平台和人工记录里的信息，由此进入同一个元数据面。工程师仍然负责定义特征语义，系统接手依赖展开、执行路由、状态管理和结果提交。 图 3：系统解析依赖、生成计划并调度特征计算。来源：论文 Figure 3。 少数坏样本，不再拖着整批数据重跑 非结构化语料里总会混入异常编码、超长文本或损坏内容。数据达到数亿、数十亿条后，极低的异常比例也会产生大量坏样本。传统批任务常以任务为失败单位，一次 UDF OOM 或超时就可能让多 TB 计算整体退出。 OmniTable 把常见 UDF 故障隔离到记录级。每次 UDF 调用带有超时和内存检查；遇到 Python OOM、超时或未捕获异常时，系统记录样本 ID、异常类型和错误摘要，将该条结果写为 NULL，其余记录继续处理。错误记录统一进入 error t