训练一个大模型之前，语料需要经过解析、清洗、去重、质量评分、Token 化和样本组装。
规模来到 PB 级，工程团队每天面对的不止算力账单，还有数百张表、不断增加的特征，以及少数几条就可能让整批任务重跑的异常数据。
以此为背景，论文《OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration》介绍了一套由蚂蚁集团研发的统一宽表系统——OmniTable。论文已获今年的VLDB 工业赛道最佳论文，聚焦的正是大模型训练中非常重要，但也常被忽视的环节——数据准备。
△蚂蚁集团论文获评 VLDB 2026 工业赛道最佳论文，9 月 1 日在波士顿举行的大会上获颁奖项
论文披露，OmniTable 已在生产环境管理超过 35PB、3050 亿条以上的大模型训练数据，覆盖 Web、代码、PDF 和 SFT 等数据域。在一项真实 SFT 数据准备任务中，端到端周期从约14天缩短到2.5天，手工操作步骤从45步降至12步。
这个结果并非来自一台更快的机器。OmniTable 改了数据工程师组织数据和特征的方式：同一数据域在上层呈现为一张逻辑宽表，底层继续按数据规模、访问方式和计算引擎拆分；特征也从脚本中的临时计算，变成带有定义、版本、依赖和血缘的系统资产。
一个特征，为什么会牵出 106 张表
传统的大模型数据加工通常围绕物理表展开。一个数据源接入后，解析结果落一张表，清洗结果再落一张，质量分、领域标签、去重签名和安全标记继续产生新的表或中间结果。Web、代码、PDF、SFT 又各自维护一套流程。
单条管道并不难理解。数据源和特征持续增加后，维护对象会迅速膨胀。新增一个质量特征，工程师需要先找到所有相关表，核对字段和版本，再为每个数据集配置任务、资源、检查点和失败处理。论文记录了一个实际案例：为了补一个特征，工程师需要在任务画布上处理106张表。
更麻烦的是，表只保存结果，很少完整记录结果是怎样算出来的。UDF 分散在不同代码库，输入列、算子版本、运行批次和下游训练任务之间缺少稳定关联。排查一条异常样本时，工程师往往要跨表、跨脚本追溯；特征版本一旦变化，还要判断哪些历史批次需要重新计算。
OmniTable 将这类问题概括为三项工程成本：数据难定位、特征难回刷、结果难追溯。系统的设计起点也很直接——让数据批次和特征列成为一等对象，把物理表退回到存储实现层。
△异构数据经过分散管道后形成彼此割裂的数据集。来源：论文 Figure 1" 一张表 " 位于逻辑层
OmniTable 的核心原则是" 逻辑统一、物理分离 "。
在逻辑层，每一行代表一条可追踪的数据实体，每一列保存某个处理阶段的状态或一项衍生特征。RawData、ProcessedData 和 TrainableData 分别对应原始数据、处理中间态和训练可用形态，后面还可以继续添加质量、领域、安全、去重等特征列。
两类系统字段负责把这些列对齐。_ai_unique_id_ 是全局主键，同一条数据在不同来源、处理阶段和特征列中使用同一个标识；_ai_append_name_ 记录接入批次、来源和版本。数据回刷、点查和血缘追踪都有了稳定锚点。
这里的 " 一张表 " 是一份逻辑契约。生产环境按 Web、代码、PDF 和 post-SFT 划分为四张领域逻辑宽表，合计管理35+PB、3050 亿条以上记录；每张逻辑表的列由其 Table Family 中的多张物理表承载，并可继续按行、按列拆分。其中最大的 Web 宽表管理约25PB、3000 亿条以上记录，包含 800 多个逻辑列和 200 多个已注册特征。论文还在固定约 2PB 数据的受控实验中将逻辑列扩展到2500 列。
逻辑列与物理位置的对应关系由 Catalog 保存。底层可以拆行、拆列、合并小文件、调整分区，或为高频列组建立物化视图，上层的 schema 和列语义保持不变。下游查询无需跟着每次物理调整修改。论文也给出了这项设计的代价：为热点列组建立物化结果，可能增加约 8% – 15% 的存储开销。
△Catalog 连接数据接入、特征执行、查询导出与后台治理。来源：论文 Figure 2 特征计算从 " 画任务 " 改成 " 报目标列 "
统一逻辑视图解决了 " 数据在哪 " 的问题，Catalog 继续管理特征怎样产生。
一个特征注册时，需要写清输入列、输出列、UDF/SQL/ 模型推理逻辑、版本，以及 CPU 或 GPU 的执行偏好。工程师提交回刷任务时，只需指定目标批次和目标特征。OmniTable 会查询当前计算状态，沿列级依赖 DAG 找到尚未完成的最小依赖闭包，再按拓扑顺序生成物理执行计划。
例如，某个质量分依赖清洗文本，而清洗文本又依赖解析结果。旧流程需要工程师确认三段任务是否齐全，并分别定位输入输出表。OmniTable直接检查这些列在目标批次上的状态：已经完成的结果复用，缺失的祖先列进入计划。共享输入、执行引擎相同的多个算子还能合并到一次扫描中。
任务成功完成后，Catalog 原子登记 " 批次—特征列 " 的状态、版本、物理位置和列级血缘；未提交的结果不会进入稳定逻辑视图。此后再查询一列数据，系统能够回答它用了哪个输入批次、依赖哪些父列、采用哪个特征版本、由什么引擎计算，以及结果落在什么位置。
过去分散在脚本、调度平台和人工记录里的信息，由此进入同一个元数据面。工程师仍然负责定义特征语义，系统接手依赖展开、执行路由、状态管理和结果提交。
△系统解析依赖、生成计划并调度特征计算。来源：论文 Figure 3 少数坏样本，不再拖着整批数据重跑
非结构化语料里总会混入异常编码、超长文本或损坏内容。数据达到数亿、数十亿条后，极低的异常比例也会产生大量坏样本。传统批任务常以任务为失败单位，一次 UDF OOM 或超时就可能让多 TB 计算整体退出。
OmniTable 把常见 UDF 故障隔离到记录级。每次 UDF 调用带有超时和内存检查；遇到 Python OOM、超时或未捕获异常时，系统记录样本 ID、异常类型和错误摘要，将该条结果写为 NULL，其余记录继续处理。错误记录统一进入 error table，方便后续修复和补算。
论文在一个500GB、约 6 亿条记录的特征任务上做了对照。数据中有 31247 条异常记录，占 0.005%。开启 failover 后，除 31247 条异常记录外，其余约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.5PB、3000 亿条以上。融合后，扫描次数从8次降为1次，CPU Hours 从4.2 万降到1.85 万，减少55.9%；端到端时间从38 小时降到14 小时，提速2.7 倍。
自适应调优则用于减少参数试错。针对 50GB、500GB 和 2TB 三种批次规模的受控实验，OmniTable 的自适应配置首次提交成功率为100%，任务成本与专家手调相差不超过 5%。这组结果对应特定 BERT 特征任务，说明系统能够给出接近专家配置的可用参数，并不代表任意任务都能自动达到最优。
△算子融合减少重复扫描，自适应调优在不同批次规模下接近专家配置。来源：论文执行评测。逻辑表持续变宽，后台持续整理物理布局
宽表上线后仍会不断增加批次和特征。小文件累积、分区倾斜、列数增长和查询热点变化都会拖慢访问。OmniTable 的后台治理服务持续观察这些指标，自动执行小文件合并、行拆分、列拆分和物化视图构建。
治理过程采用Prepare — Execute — Commit：先准备新布局并完成物理重写，验证通过后，再原子切换 Catalog 映射。旧布局在切换前继续服务查询，失败的治理任务可以回滚。用户仍然查询同一组逻辑列，无需感知文件和表族怎样变化。
△后台治理根据规模和访问模式调整物理布局。来源：论文 Figure 4
列拆分让逻辑 schema 可以越过单个引擎的物理列数限制。在固定约 2PB 数据、查询列集合不变的测试中，逻辑列从 200 增至2500，P95 延迟约从 25 秒升到 38 秒，跨过了底层引擎约1200 列的物理上限。另一组规模测试覆盖 1TB 到 25PB，过滤导出吞吐保持在 18 – 23TB/ 小时。
单样本排查走另一条路径。全局 ID 索引直接把 ai_unique_id 定位到物理表、分区和 row group。在 25PB、3000 亿条以上记录、800 多个逻辑列的 Web 数据上，查询完整逻辑行的 P50 为8.3秒，P99 为14.7秒；全扫描分别需要184秒和612秒以上。
需要一次导出多列时，后台物化视图会预先消除热点列组之间的 JOIN。一个涉及15 列、4 张物理表的代表性场景中，过滤导出吞吐从4.8TB/ 小时提升到20.1TB/ 小时。点查、批量筛选和大规模导出使用不同路径，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%。
△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
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
— 完 —
【学术投稿】请在工作日发送邮件至：ai@qbitai.com，标题注明【投稿】，并告诉我们：你是谁，从哪来，投稿内容附上项目 / 主页链接，以及联系方式。
我们会 ( 尽量 ) 及时回复你 : )
点亮星标
科技前沿进展每日见
