蚂蚁 OmniTable 获 VLDB 工业最佳论文：35PB 大模型语料，为什么一张宽表能提速 5.6 倍

蚂蚁集团的统一宽表系统 OmniTable 获得了 VLDB 2026 工业赛道最佳论文，公开报道显示，该系统已经用于处理规模达到 35PB 的大模型语料，整体数据处理效率最高提升 5.6 倍。

这件事的重点不只是又一篇数据库论文获奖，而是大模型基础设施的竞争正在从训练框架、推理引擎，进一步下沉到数据工程。模型参数可以通过堆 GPU 扩大，但训练数据的抓取、清洗、去重、过滤、打分和版本管理，往往决定了这些 GPU 到底是在学习，还是在等待数据。

先说结论：OmniTable 解决的是数据链路碎片化

**统一宽表是把同一条数据的原始内容、清洗结果、质量分数、去重特征和处理状态等信息，集中组织在一张可持续演进的数据表中的数据管理方式。**它与传统数据库里的“宽表”概念相近，但服务对象不是单纯的业务报表，而是大模型训练数据的全生命周期。

在很多大模型团队里，一条语料并不会只经历一次处理。它可能先经过网页解析，再经过语言识别、格式清洗、敏感信息过滤、质量打分、规则去重、语义去重，最后还要被切分成不同版本，分别服务于预训练、指令微调、偏好训练或评测集构建。

问题在于，这些环节通常由不同脚本、不同任务调度器和不同存储系统完成。上游任务输出一批文件，下游任务重新读取；某个字段变化后，团队往往需要重新跑完整条流水线；同一份原始语料还可能被多个团队复制保存。数据规模一旦进入 PB 级，真正拖慢系统的就不只是计算，而是反复扫描、重复落盘、跨系统搬运和元数据失控。

OmniTable 的核心判断是：**大模型数据处理不应该被拆成一串彼此隔离的离线任务，而应该被视为一张持续更新、可追溯、可复用的统一数据表。**这也是“统一宽表”比普通数据仓库宽表更有价值的地方。

35PB 是什么概念？难点不只是容量

**PB 是数据容量单位，1PB 等于约 1000TB；35PB 级语料意味着系统面对的是数千万亿字节的数据资产。**如果按照每份数据都需要经历多轮处理来估算，实际读写量通常会远高于原始数据量。

大模型语料的麻烦还在于，它不是一堆结构整齐的数据库记录。数据可能来自网页、文档、代码、论坛、电子书、问答内容和企业内部知识库，格式包括 HTML、PDF、Markdown、JSON、纯文本以及各种压缩文件。不同来源的编码、语言、重复程度和内容质量差异很大。

一条看似简单的网页文本，可能同时需要保存以下信息：

• 原始页面或原始文档的定位信息；
• 抽取后的正文、标题、链接和页面结构；
• 语言识别、广告识别、模板噪声和乱码检测结果；
• 文本长度、困惑度、规则质量分和模型质量分；
• 精确去重指纹、近似去重特征和语义相似度结果；
• 是否包含个人信息、版权风险内容或安全风险内容；
• 处理使用的规则版本、模型版本和时间戳；
• 最终进入哪个训练集、数据集版本和采样批次。

如果这些字段分散在对象存储、消息队列、关系数据库和任务日志中，研究人员很难回答几个看似基础的问题：这条数据为什么被过滤？它被哪个版本的规则处理过？某次模型训练到底使用了哪些版本的语料？重新计算一个质量字段，能不能只处理发生变化的部分？

OmniTable 的价值，就在于把这些信息组织到相对统一的数据视图中，让数据本身不仅能被读取，还能携带处理历史和质量状态。对于需要频繁试验数据配方的团队来说，这比单纯把文件存得更快更重要。

5.6 倍提升，可能来自哪里

**大模型数据处理的效率提升，通常来自减少重复 I/O、避免全量重算、复用中间结果和降低跨系统调度开销，而不只是把单个算子跑得更快。**公开信息给出了 OmniTable 最高 5.6 倍的效率提升，但并未在参考材料中完整披露测试硬件、基线系统、任务构成和成本口径，因此这个数字应理解为特定工业场景下的实测结果，而不是所有数据任务都固定提速 5.6 倍。

从系统设计角度看，统一宽表至少可能带来四类收益。

1. 从“文件接力”变成“字段增量更新”

传统流程经常是：任务 A 生成新文件，任务 B 读取整个文件，加入几个字段后再写出一份更大的文件。数据每经过一次处理，就可能触发一次完整扫描和一次完整落盘。

统一宽表更适合把处理结果直接映射为新增或更新字段。例如，语言识别只负责更新语言字段，质量模型只负责更新质量分，去重任务只负责写入指纹和保留状态。这样做的前提是底层存储、索引和并发更新机制足够成熟，但一旦成立，很多局部任务就不必反复搬运整条记录。

2. 从“任务级复用”变成“结果级复用”

同一份语料可能同时服务多个模型训练项目。传统做法往往是每个项目各自复制一份清洗后的数据，再根据需求继续过滤。统一表可以让公共字段和处理结果复用，项目差异只体现在筛选条件、采样策略或派生字段上。

这对大模型团队尤其关键。预训练数据需要重视规模和覆盖面，指令数据需要重视任务质量，评测数据又需要重视分布稳定性。如果底层数据资产可以复用，团队就能快速切换数据配方，而不必每次都从原始文件重新启动。

3. 从“全量重跑”变成“变更驱动”

数据规则会持续变化。今天发现某类网页模板污染严重，明天可能新增一个版权过滤器，后天又希望用更强的模型重新评估高价值语料。如果每个字段都依赖前一步输出，规则变化就容易造成整条流水线重跑。

统一宽表的思路是记录字段来源、版本和依赖关系，只对受影响的数据范围和字段进行更新。它并不能消除所有重算，但可以让“重新处理 35PB”变成“只更新受影响的子集”，这正是 PB 级数据系统能否实际运转的分水岭。

4. 从“数据能不能读”扩展到“数据能不能解释”

训练数据质量已经成为模型能力的重要变量。只保留最终文本、不保留中间判断结果，会让数据团队在出现模型退化、重复率升高或安全问题时缺乏排查依据。

宽表把质量分、过滤原因、版本信息和血缘信息放在同一数据对象附近，降低了追溯成本。它更像是给每条语料建立一份持续更新的“档案”，而不是把数据处理成一次性消费品。

OmniTable 与传统数据处理方式有什么区别

**OmniTable 的主要创新方向不是发明新的清洗算法，而是改变大模型数据处理任务之间的组织方式。**下表用工程视角概括两种模式的差异：

| 对比维度 | 传统多阶段流水线 | OmniTable 统一宽表思路 | |---|---|---| | 数据组织 | 多个文件、表和任务分别维护 | 以统一记录承载多类处理结果 | | 处理方式 | 常见全量读取、全量输出 | 更强调字段级更新和结果复用 | | 中间结果 | 容易散落在临时目录或独立表中 | 中间状态成为数据记录的一部分 | | 版本追踪 | 依赖日志、命名规则和人工约定 | 通过字段、版本和血缘信息关联 | | 规则变更 | 可能触发大范围重跑 | 更适合针对受影响字段增量更新 | | 多项目复用 | 经常复制数据集后各自加工 | 共享公共数据资产，按需派生 | | 主要风险 | 链路复杂、重复 I/O、数据不一致 | 表结构治理和并发更新复杂度上升 |

这张表也说明了，统一宽表并不是“把所有东西都塞进一张表”这么简单。如果只是把字段数量堆起来，最后得到的可能是一张难以维护的超级表。真正的工程难点在于：如何管理字段依赖，如何支持不同处理任务并发写入，如何保证数据版本一致，如何让查询和更新性能不会随着字段增长而失控。

为什么 VLDB 工业最佳论文值得关注

**VLDB 是数据库与数据管理领域的国际顶级会议之一，工业赛道则更看重技术是否经受真实生产规模和复杂业务环境的验证。**因此，OmniTable 获得 VLDB 2026 工业赛道最佳论文，意味着它的价值不仅在于概念新颖，还在于论文所描述的系统具备较强的产业落地属性。

数据库领域的工业论文与纯算法论文关注点不同。算法论文可能用一个公开数据集证明某个方法在特定指标上更优，而工业系统论文需要回答更多问题：在数据量扩大后是否还能稳定运行？失败任务怎么恢复？数据更新和查询是否互相影响？资源成本是否可控？不同业务团队接入后，系统是否仍能保持一致性？

从这个角度看，35PB 和 5.6 倍是两个重要信号。前者说明系统面对的是大型生产数据资产，而不是小规模实验数据；后者说明统一数据组织方式可能已经转化为可测量的工程收益。对数据库研究者来说，这是面向 AI 数据工作负载的系统化探索；对大模型团队来说，这更接近一套能减少数据基础设施摩擦的生产工具。

它对大模型开发者有什么实际意义

**OmniTable 最直接的影响对象不是普通模型使用者，而是负责数据平台、语料治理和训练基础设施的团队。**如果你的团队每天处理的是几十 TB 到 PB 级数据，并且经常重复做清洗、过滤和数据集重构，这类系统思路值得关注。

具体来说，以下几类场景可能收益更明显：

1. **预训练语料持续扩充。**新数据不断进入，旧数据需要重新去重和打分，统一表可以减少公共处理结果的重复计算。
2. **多模型、多数据配方并行实验。**不同模型项目需要不同过滤条件和采样策略，统一数据资产可以降低复制成本。
3. **高频质量规则迭代。**当团队不断替换质量模型、敏感信息识别器或版权过滤规则时，字段级更新和版本追踪更有价值。
4. **训练问题需要回溯。**模型出现数据污染、重复样本或领域分布异常时，数据血缘和处理状态可以帮助定位原因。
5. **数据合规要求较高。**原始来源、处理过程、过滤理由和最终去向被统一记录后，审计与删除请求更容易执行。

不过，小团队不需要因为这条新闻就立刻搭建一套 35PB 级系统。对只有几十 GB 或几 TB 数据的团队来说，Parquet、Iceberg、Delta Lake、数据湖仓和成熟的任务调度器可能已经足够。统一宽表真正解决的是数据规模、处理频率和协作复杂度同时上升后的问题。

这套方案仍然有三个现实限制

**统一宽表不能替代数据质量策略，也不能自动保证训练数据更好。**它首先是一种数据组织和处理系统，能让流程更高效、更可追溯，但最终质量仍取决于清洗规则、质量模型、去重方法和人工抽检。

第一，宽表会带来模式治理压力。随着数据处理任务增加，字段可能快速膨胀。哪些字段是稳定公共属性，哪些字段只是一次性实验结果，哪些字段必须保留，哪些字段可以归档，都需要明确规范。

第二，增量更新并不等于低成本更新。如果一个规则依赖全局统计信息，或者语义去重需要跨越大量数据重新构建索引，那么局部字段更新仍可能触发较大范围的计算。系统需要准确识别依赖关系，不能只在表面上宣称“增量”。

第三，数据治理与计算性能之间存在取舍。保留更多原始内容、中间结果和版本信息，有利于追溯，但也会增加存储、索引和元数据管理成本。对 35PB 级数据而言，任何一个字段设计错误，都可能被放大成显著的存储和计算开销。

因此，评价 OmniTable 不能只看 5.6 倍这个结果，还应继续关注它的基线系统、硬件配置、数据读写比例、失败恢复机制、查询延迟、存储开销以及在不同工作负载下的稳定性。工业系统的价值，最终要看它能否在真实业务中持续运行，而不是某一次基准测试的峰值。

从“训练算力竞争”转向“数据系统竞争”

**大模型基础设施的下一阶段竞争，很可能不只是比谁拥有更多 GPU，也要比谁能更低成本地管理高质量数据。**模型训练中，GPU 集群可以通过并行扩展获得更高吞吐，但如果数据管道无法持续供给，昂贵的计算资源就会被 I/O、网络传输和任务等待消耗掉。

过去，数据清洗常被看作训练前的准备工作；现在它越来越像模型系统本身的一部分。训练集版本、去重率、质量分布、语言比例、版权状态和安全标签，都会影响模型的最终行为。能够快速建立数据版本、验证数据变化并回溯训练来源，已经成为模型研发效率的重要组成部分。

蚂蚁 OmniTable 获奖释放出的信号很明确：面向大模型的数据基础设施正在成为数据库领域新的工业战场。统一宽表未必是所有团队的最终答案，但它把一个长期被脚本和临时文件掩盖的问题摆到了台面上——当训练数据达到 35PB，真正需要优化的可能不是某个清洗函数，而是整条数据链路的组织方式。

对开发者和深度用户而言，5.6 倍效率提升值得关注；对 AI 基础设施团队而言，更值得借鉴的是背后的系统思路：让数据处理结果可复用，让规则变化可追踪，让大规模语料不再被一次次重复搬运。模型越来越大之后，谁能把数据管得更快、更准、更可解释，谁才更可能把算力真正转化成模型能力。

参考来源

• GitHub OmniTable 项目检索页：用于核查是否存在公开的 OmniTable 开源代码或相关项目；截至本文成稿，参考资料未提供官方开源仓库链接。
• 本文核心事实依据为 2026 年 9 月 2 日公开报道：蚂蚁集团统一宽表系统 OmniTable 获 VLDB 2026 工业赛道最佳论文，并在 35PB 级大模型语料处理场景中实现最高 5.6 倍效率提升。由于来源网站不在本文限定的可引用域名范围内，正文未附外链。