北京
大模型训练前最磨人的环节是什么？不是调参，不是选架构，而是洗数据。动辄几十PB的语料，要经过清洗、去重、格式化、特征提取，每一步都可能因为一条脏数据让整个任务重跑。蚂蚁集团最近在VLDB 2026工业赛道上拿下的最佳论文，给出的解法有点反直觉：与其在流程上打补丁，不如把数据全部塞进一张"大宽表"里。
这套名为OmniTable的系统，已经在蚂蚁的生产环境里管理超过35 PB、3050亿条大模型训练数据，覆盖Web、代码、PDF和SFT等多个数据域。论文披露的真实SFT数据准备任务中，端到端周期从约14天压缩到2.5天，提速5.6倍，手工步骤从45步降到12步。
为什么宽表能省这么多时间？
传统数据准备流程里，每个环节各管一摊：清洗脚本读一遍数据，特征提取又读一遍，过滤再读一遍。数据在多个系统间搬来搬去，每搬一次就要重新扫描、重新校验，时间全耗在重复I/O上。OmniTable的思路是逻辑统一、物理分离——把所有数据域的逻辑视图合并成一张宽表，但底层存储仍然分开。
这样一来，数据批次和特征列被提升为一等对象，配合全局唯一ID和Catalog，系统能跨表追踪血缘关系。某个特征需要回刷时，不用再写一堆临时脚本，系统自动定位到对应列并完成更新。论文里提到，接入阶段缩短到约0.5天，特征回填约1.7天，过滤导出约0.3天，总计约2.5天。
算子融合：扫描8次变1次
提速的关键动作之一是算子融合。在真实任务中，8个特征共享同一列读取，传统做法是每个特征各扫一遍数据。OmniTable把多次扫描合并为一次，扫描次数从8次降为1次，CPU Hours从4.2万降到1.85万，减少55.9%；端到端时间从38小时降到14小时，提速2.7倍。
另一个细节是记录级容错。以前一条异常数据可能导致整批任务失败，现在系统对异常样本进行单条捕获并写入error table，避免整批重跑。这个机制只增加约3%-5%的执行开销，换来的是更高的整体可靠性。
后台治理：PB规模下保持查询性能
数据量大了之后，小文件堆积、分区倾斜这些问题会拖慢查询。OmniTable的后台治理模块持续监控这些指标，自动执行合并、拆分和物化视图构建。也就是说，系统自己会整理房间，不用等人来打扫。
这套系统的价值在于，它把数据准备从"手工作坊"变成了"流水线"。手工步骤从45步降到12步，独立管道和脚本减少58.3%。对于每天要处理PB级数据的大模型团队来说，省下的不只是时间，还有大量人工排查和调试的成本。
论文标题是《OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration》，感兴趣的读者可以找原文细看。数据准备这件事，可能比想象中更有优化空间。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
