训练一个大模型之前，语料要经过解析、清洗、去重、质量评分、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 table，方便后续修复和补算。
论文在一个 500 GB、约 6 亿条记录的特征任务上做了对照。数据中有 31,247 条异常记录，占 0.005%。开启 failover 后，除 31,247 条异常记录外，其余约 99.995% 的记录一次处理完成，耗时约 6.2 小时，无需人工介入；关闭该能力，任务直接失败。旧流程需要三轮排查、删除和重提，总耗时约 52 小时，其中约 18 小时是人工处理。
记录级包装会增加约 3%–5% 的执行开销，也无法消除机器故障、网络中断等所有失败。它处理的是生产中最常见、也最浪费工程师时间的一类问题：单条异常数据拖垮整批任务。
一次扫描多算几列，CPU 和 GPU 各做合适的工作
大模型数据特征的计算形态差异很大。文本长度、字符比例和规则过滤通常适合 CPU 或 SQL；模型推理既可能运行在 CPU，也可能交给 GPU，取决于模型规模、算子画像与资源条件。OmniTable 根据用户声明、算子画像、引擎能力和集群负载，在 Spark、MaxCompute SQL 与 GPU 推理平台之间选择执行后端，并结合历史运行信息调整资源参数。
路由之外，重复扫描也是一笔大开销。多个特征读取同一列、运行在同一引擎时，OmniTable 会把它们融合成一个任务，一次读取产生多列结果。
在论文的算子融合实验中，8 个 CPU／Spark 特征都读取 parsed_text。测试数据约 2.5 PB、3000 亿条以上。融合后，扫描次数从 8 次降为 1 次，CPU Hours 从 4.2 万降到 1.85 万，减少 55.9%；端到端时间从 38 小时降到 14 小时，提速 2.7 倍。
自适应调优则用于减少参数试错。针对 50 GB、500 GB 和 2 TB 三种批次规模的受控实验，OmniTable 的自适应配置首次提交成功率为 100%，任务成本与专家手调相差不超过 5%。这组结果对应特定 BERT 特征任务，说明系统能够给出接近专家配置的可用参数，并不代表任意任务都能自动达到最优。
图 4：算子融合减少重复扫描，自适应调优在不同批次规模下接近专家配置。来源：论文执行评测。
逻辑表持续变宽，后台持续整理物理布局
宽表上线后仍会不断增加批次和特征。小文件累积、分区倾斜、列数增长和查询热点变化都会拖慢访问。OmniTable 的后台治理服务持续观察这些指标，自动执行小文件合并、行拆分、列拆分和物化视图构建。
治理过程采用 Prepare—Execute—Commit：先准备新布局并完成物理重写，验证通过后，再原子切换 Catalog 映射。旧布局在切换前继续服务查询，失败的治理任务可以回滚。用户仍然查询同一组逻辑列，无需感知文件和表族怎样变化。
图 5：后台治理根据规模和访问模式调整物理布局。来源：论文 Figure 4。
列拆分让逻辑 schema 可以越过单个引擎的物理列数限制。在固定约 2 PB 数据、查询列集合不变的测试中，逻辑列从 200 增至 2500，P95 延迟约从 25 秒升到 38 秒，跨过了底层引擎约 1200 列的物理上限。另一组规模测试覆盖 1 TB 到 25 PB，过滤导出吞吐保持在 18–23 TB／小时。
单样本排查走另一条路径。全局 ID 索引直接把 _ai_unique_id_ 定位到物理表、分区和 row group。在 25 PB、3000 亿条以上记录、800 多个逻辑列的 Web 数据上，查询完整逻辑行的 P50 为 8.3 秒，P99 为 14.7 秒；全扫描分别需要 184 秒和 612 秒以上。
需要一次导出多列时，后台物化视图会预先消除热点列组之间的 JOIN。一个涉及 15 列、4 张物理表的代表性场景中，过滤导出吞吐从 4.8 TB／小时提升到 20.1 TB／小时。点查、批量筛选和大规模导出使用不同路径，Catalog 为它们提供统一入口。
5.6 倍提速，主要省下的是协调和重跑时间
论文用一个真实 SFT 数据准备任务做了端到端对照。任务包含 8 个数据来源和 12 个特征，其中 9 个是 CPU UDF，3 个是 GPU 推理。
旧流程需要约 2 天定位和接入数据，约 9.5 天完成特征回填，再花约 2.5 天编写多表 JOIN 并导出结果，总周期约 14 天。过程中涉及约 45 个手工步骤、24 条独立管道或脚本，以及 35 张物理表。
OmniTable 将接入阶段缩短到约 0.5 天，特征回填约 1.7 天，过滤导出约 0.3 天，总计约 2.5 天。手工步骤降至 12 个，独立命令降至 10 条，使用入口是一张 SFT 领域逻辑宽表。端到端提速 5.6 倍，手工操作步骤减少 73.3%，独立管道和脚本减少 58.3%。
图 6：SFT 数据准备任务从约 14 天缩短至约 2.5 天。来源：论文端到端实验。
这组数字只对应论文评测中的同一项生产任务。它清楚展示了时间省在什么地方：逐表编排变少，共享输入不再重复扫描，少量异常不会频繁触发整批重跑，物理布局也不必等到性能下降后再人工调整。
宽表只是入口，完整生命周期才是重点
OmniTable 把过去分散在多套工具里的四类信息放到一起管理：数据批次、特征定义、执行状态和列级血缘。逻辑宽表为用户提供稳定入口，Catalog 维护数据与特征之间的关系，执行和治理服务继续在底层选择合适的物理组织。
这套做法也有明确成本。热点列物化需要额外存储，记录级容错会增加少量执行开销，后台治理要占用集群资源。不同企业的数据域、计算引擎和团队习惯也不相同，因此 OmniTable 更适合作为一套经过 35+ PB 生产部署检验的系统设计参考。它给出的思路是：先稳定逻辑语义，再让物理布局持续演进。
当大模型训练进入 PB 时代，数据工程的挑战已不再是把一次任务跑通，而是让持续增长的数据、特征和计算长期保持可管理。OmniTable 试图节省的，也不只是机器运行的时间，还有工程师反复找表、补任务和排查异常的时间。
论文信息：OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration，PVLDB Vol. 19, No. 12，pp. 4276–4289，DOI：10.14778/3827998.3828032。
论文链接：https://www.vldb.org/pvldb/vol19/p4276-fu.pdf