蚂蚁VLDB最佳论文：用一张“逻辑表”驯服3050亿条训练数据
训练一个大模型之前，语料需要经过解析、清洗、去重、质量评分、Token化和样本组装。
规模来到PB级，工程团队每天面对的不止算力账单，还有数百张表、不断增加的特征，以及少数几条就可能让整批任务重跑的异常数据。
以此为背景，论文《OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration》介绍了一套由蚂蚁集团研发的统一宽表系统——OmniTable。
论文已获今年的VLDB工业赛道最佳论文，聚焦的正是大模型训练中非常重要，但也常被忽视的环节——数据准备。论文披露，OmniTable已在生产环境管理超过35PB、3050亿条以上的大模型训练数据，覆盖Web、代码、PDF和SFT等数据域。在一项真实SFT数据准备任务中，端到端周期从约14天缩短到2.5天，手工操作步骤从45步降至12步。
这个结果并非来自一台更快的机器。OmniTable改了数据工程师组织数据和特征的方式：同一数据域在上层呈现为一张逻辑宽表，底层继续按数据规模、访问方式和计算引擎拆分；特征也从脚本中的临时计算，变成带有定义、版本、依赖和血缘的系统资产。一个特征，为什么会牵出106张表 传统的大模型数据加工通常围绕物理表展开。
一个数据源接入后，解析结果落一张表，清洗结果再落一张，质量分、领域标签、去重签名和安全标记继续产生新的表或中间结果。Web、代码、PDF、SFT又各自维护一套流程。单条管道并不难理解。数据源和特征持续增加后，维护对象会迅速膨胀。
新增一个质量特征，工程师需要先找到所有相关表，核对字段和版本，再为每个数据集配置任务、资源、检查点和失败处理。论文记录了一个实际案例：为了补一个特征，工程师需要在任务画布上处理106张表。更麻烦的是，表只保存结果，很少完整记录结果是怎样算出来的。
UDF分散在不同代码库，输入列、算子版本、运行批次和下游训练任务之间缺少稳定关联。排查一条异常样本时，工程师往往要跨表、跨脚本追溯；特征版本一旦变化，还要判断哪些历史批次需要重新计算。OmniTable将这类问题概括为三项工程成本：数据难定位、特征难回刷、结果难追溯。
系统的设计起点也很直接——让数据批次和特征列成为一等对象，把物理表退回到存储实现层。“一张表”位于逻辑层 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继续管理特征怎样产生。一个特征注册时，需要写清输入列、输出列、UDF/SQL/模型推理逻辑、版本，以及CPU或GPU的执行偏好。工程师提交回刷任务时，只需指定目标批次和目标特征。
OmniTable会查询当前计算状态，沿列级依赖DAG找到尚未完成的最小依赖闭包，再按拓扑顺序生成物理执行计划。例如，某个质量分依赖清洗文本，而清洗文本又依赖解析结果。旧流程需要工程师确认三段任务是否齐全，并分别定位输入输出表。
OmniTable直接检查这些列在目标批次上的状态：已经完成的结果复用，缺失的祖先列进入计划。共享输入、执行引擎相同的多个算子还能合并到一次扫描中。任务成功完成后，Catalog原子登记“批次—特征列”的状态、版本、物理位置和列级血缘；未提交的结果不会进入稳定逻辑视图。
此后再查询一列数据，系统能够回答它用了哪个输入批次、依赖哪些父列、采用哪个特征版本、由什么引擎计算，以及结果落在什么位置。过去分散在脚本、调度平台和人工记录里的信息，由此进入同一个元数据面。工程师仍然负责定义特征语义，系统接手依赖展开、执行路由、状态管理和结果提交。
少数坏样本，不再拖着整批数据重跑 非结构化语料里总会混入异常编码、超长文本或损坏内容。数据达到数亿、数十亿条后，极低的异常比例也会产生大量坏样本。传统批任务常以任务为失败单位，一次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映射。旧布局在切换前继续服务查询，失败的治理任务可以回滚。用户仍然查询同一组逻辑列，无需感知文件和表族怎样变化。
列拆分让逻辑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%。
这组数字只对应论文评测中的同一项生产任务。它清楚展示了时间省在什么地方：逐表编排变少，共享输入不再重复扫描，少量异常不会频繁触发整批重跑，物理布局也不必等到性能下降后再人工调整。宽表只是入口，完整生命周期才是重点 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 一键三连「点赞」「转发」「小心心」 欢迎在评论区留下你的想法！ — 完 — 【学术投稿】请在工作日发送邮件至：[email protected]，标题注明【投稿】，并告诉我们：你是谁，从哪来，投稿内容附上项目/主页链接，以及联系方式。
🌟 点亮星标 🌟 内容中包含的图片若涉及版权问题，请及时与我们联系删除