蚂蚁OmniTable获VLDB最佳论文 优化PB级大模型数据准备

在大模型训练的全流程中，语料预处理是基础且关键的一环，从解析、清洗、去重、质量评分、Token化到样本组装，每一步都直接影响最终模型的效果。当训练数据规模达到PB级别时，工程团队面临的挑战早已不止高昂的算力成本：数百张分散的物理表、持续增长的特征维度，以及少数异常数据就可能导致整批任务返工的风险，都让数据准备环节成为极易被忽视但又至关重要的瓶颈。

今年的VLDB工业赛道最佳论文，就聚焦于大模型训练中被长期忽略的数据准备环节。该论文介绍了一套名为OmniTable的统一宽表系统，由专业技术团队研发完成，并在VLDB 2026大会（9月1日于波士顿举办）上斩获工业赛道最高荣誉。

据论文披露，这套系统已经在生产环境中完成了超35PB、总计3050亿条大模型训练数据的管理，覆盖网页、代码、PDF以及监督微调（SFT）等多个数据领域。在一项真实的SFT数据准备任务中，OmniTable将端到端处理周期从原本的约14天压缩至2.5天，手工操作步骤也从45步精简到12步。

这样的效率提升并非依赖单一的高性能硬件，而是源于系统对数据工程师组织数据与特征的方式进行了根本性重构：同一数据域在业务上层以一张逻辑宽表的形式对外呈现，底层则根据数据规模、访问模式和计算引擎的特性进行拆分存储；同时，原本分散在脚本中的临时特征计算，被升级为具备明确定义、版本管理、依赖追踪和血缘记录的标准化系统资产。

传统数据加工的核心痛点

传统的大模型数据加工流程通常围绕物理表展开。每一个数据源接入后，解析结果会单独存储为一张表，清洗后的结果又会生成新的表，质量评分、领域标签、去重签名和安全标记等处理步骤还会继续产生更多的表或中间结果。针对网页、代码、PDF和SFT等不同的数据域，团队还需要各自维护一套独立的处理流程。

单条数据管道的维护并不复杂，但随着数据源和特征数量的持续增长，维护的对象会快速膨胀。当需要新增一个质量特征时，工程师首先要找到所有相关的物理表，核对字段信息和版本兼容性，再为每一个数据集单独配置任务、资源、检查点和失败处理逻辑。论文中记录了一个真实的生产案例：为了补全一个特征，工程师需要在任务画布上处理多达106张物理表。

更棘手的问题在于，传统的物理表仅保存最终的计算结果，很少完整记录结果的生成过程。用户自定义函数（UDF）分散在不同的代码库中，输入列、算子版本、运行批次和下游训练任务之间缺乏稳定的关联关系。当需要排查一条异常样本时，工程师往往需要跨多张表、多个脚本进行追溯；而当特征版本发生变更时，还要手动判断哪些历史批次的数据需要重新计算。

OmniTable将这类问题总结为三大工程成本：数据难以快速定位、特征难以高效回刷、计算结果难以追溯。这套系统的设计起点非常直接：将数据批次和特征列升级为一等对象，把物理表降级为底层存储实现的细节。

逻辑统一、物理分离的架构设计

OmniTable的核心设计原则是“逻辑统一、物理分离”。

在业务逻辑层，每一行数据代表一个可追踪的数据实体，每一列则对应某个处理阶段的状态或是一项衍生特征。其中RawData、ProcessedData和TrainableData分别对应原始数据、处理中间态和可用于训练的最终形态，后续还可以按需添加质量评分、领域标签、安全标记、去重签名等特征列。

系统通过两类内置字段实现所有列的对齐：_ai_unique_id_作为全局唯一主键，确保同一条数据在不同来源、处理阶段和特征列中都使用同一个标识；_ai_append_name_则记录数据的接入批次、来源和版本信息，为数据回刷、单点查询和血缘追踪提供稳定的锚点。

这里的“一张逻辑宽表”本质上是一份业务层面的逻辑契约。在实际生产环境中，系统按照数据域划分为四张领域逻辑宽表，分别对应网页、代码、PDF和SFT场景，总计管理超过35PB、3050亿条数据记录。每张逻辑表的列由其所属Table Family中的多张物理表承载，并且可以根据需要继续按行或按列进行拆分。其中规模最大的网页数据宽表管理了约25PB、超过3000亿条记录，包含800多个逻辑列和200多个已注册的特征。在一项针对约2PB固定数据的受控实验中，系统还将逻辑列扩展到了2500列。

逻辑列与物理存储位置的对应关系由Catalog模块统一管理。底层存储可以根据需要进行拆行、拆列、合并小文件、调整分区，或是为高频访问的列组建立物化视图，但上层的Schema和列语义始终保持不变，下游的查询逻辑无需随着物理存储的调整而修改。论文同时指出了这项设计的潜在代价：为热点列组构建物化结果会带来约8%到15%的额外存储开销。

特征计算的全流程简化

统一的逻辑视图解决了“数据在哪里”的问题，而Catalog模块则负责管理特征的生成流程。

当一个新的特征完成注册时，开发者需要明确指定输入列、输出列、对应的UDF/SQL/模型推理逻辑、版本信息，以及适合的执行硬件（CPU或GPU）。当工程师需要提交特征回刷任务时，仅需要指定目标数据批次和需要计算的目标特征即可。OmniTable会先查询当前的计算状态，沿着列级依赖的有向无环图（DAG）找到尚未完成的最小依赖闭包，再按照拓扑顺序自动生成物理执行计划。

举个例子，某个质量评分特征依赖清洗后的文本数据，而清洗后的文本又依赖原始的解析结果。在传统流程中，工程师需要手动确认这三段任务是否齐全，并分别定位对应的输入输出表。而在OmniTable中，系统会直接检查这些列在目标批次上的计算状态：已经完成的结果会直接复用，缺失的祖先列会自动加入计算计划。如果多个特征共享相同的输入数据，且运行在相同的执行引擎上，系统还会将这些算子合并为一次扫描任务，进一步减少重复计算。

当任务成功完成后，Catalog会原子化登记“批次—特征列”的状态、版本、物理存储位置和列级血缘关系，未正式提交的结果不会进入稳定的逻辑视图中。后续当用户查询某一列数据时，系统可以完整回溯该列的生成信息：使用了哪个输入批次、依赖了哪些父列、采用了哪个特征版本、由哪种计算引擎执行，以及最终结果存储的具体位置。

过去分散在脚本、调度平台和人工记录中的元数据，现在被统一整合到了同一个元数据管理平面中。工程师只需要负责定义特征的业务语义，系统则自动接手依赖展开、执行路由、状态管理和结果提交等繁琐的工程工作。

记录级容错：避免单条异常拖垮整批任务

非结构化的训练语料中总会混入异常编码、超长文本或是损坏的内容。当数据规模达到数亿甚至数十亿条时，即使只有0.005%的异常比例，也会产生大量的坏样本。传统的批处理任务通常以整个任务为失败单位，一次UDF内存溢出（OOM）或是超时就可能导致数TB的计算任务整体失败，需要重新执行。

OmniTable将常见的UDF故障隔离到了单条记录级别。每一次UDF调用都会设置超时和内存检查阈值，当遇到Python OOM、超时或是未捕获的异常时，系统会记录该样本的ID、异常类型和错误摘要，将该条结果标记为NULL，其余的正常记录则继续完成处理。所有的错误记录会被统一存入专门的error table中，方便后续的修复和补算。

论文在一个500GB、约6亿条记录的特征任务上进行了对照实验。这批数据中共有31247条异常记录，占比0.005%。当开启记录级容错功能时，除了这3万多条异常记录外，其余约99.995%的记录可以一次处理完成，总耗时约6.2小时，全程无需人工介入；而如果关闭该功能，任务会直接失败。在传统流程中，处理这类异常需要三轮排查、删除异常数据并重新提交任务，总耗时约52小时，其中约18小时都花费在人工处理环节。

记录级容错会带来约3%到5%的额外执行开销，同时也无法消除机器故障、网络中断等全局级别的失败，但它可以有效解决生产环境中最常见、也最浪费工程师时间的一类问题：单条异常数据拖垮整批计算任务。

智能执行路由与算子融合优化

大模型数据的特征计算形态差异极大。文本长度统计、字符比例分析和规则过滤等常规处理通常适合使用CPU或SQL执行；而模型推理则可能运行在CPU或GPU上，具体取决于模型规模、算子特性和集群资源条件。OmniTable会根据开发者声明的配置、算子的运行画像、引擎的能力和当前的集群负载，在Spark、MaxCompute SQL和GPU推理平台之间选择最合适的执行后端，同时结合历史运行信息自动调整资源参数。

除了智能路由之外，重复扫描也是一笔可观的计算开销。当多个特征读取同一列数据且运行在相同的执行引擎上时，OmniTable会将这些任务合并为一个统一的任务，通过一次扫描生成多列的计算结果。

在论文的算子融合实验中，8个基于CPU/Spark的特征都需要读取parsed_text列。测试数据规模约为2.5PB，包含超过3000亿条记录。经过算子融合优化后，扫描次数从原本的8次降低到1次，CPU耗时从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多个逻辑列的网页数据场景中，查询完整逻辑行的P50延迟为8.3秒，P99延迟为14.7秒；而全表扫描的P50延迟则需要184秒，P99延迟超过612秒。

当需要一次性导出多列数据时，后台的物化视图会预先消除热点列组之间的JOIN操作。在一个涉及15列、4张物理表的典型场景中，过滤导出的吞吐从4.8TB/小时提升到20.1TB/小时。单点查询、批量筛选和大规模导出采用了不同的优化路径，而Catalog则为这些场景提供了统一的访问入口。

端到端效率提升：SFT任务周期压缩5.6倍

论文通过一项真实的SFT数据准备任务，展示了OmniTable的端到端优化效果。该任务包含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更适合作为一套经过35PB以上生产部署验证的系统设计参考，其核心思路是先稳定业务层面的逻辑语义，再让底层物理存储布局持续演进优化。

当大模型训练进入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