训练一个大模型之前，语料要经过解析、清洗、去重、质量评分、Token化和样本组装。规模来到PB级，工程团队每天面对的不止算力账单，还有数百张表、不断增加的特征，以及少数几条就可能让整批任务重跑的异常数据。今年的VLDB工业赛道最佳论文，关注的正是大模型训练中非常重要却常被忽视的环节——数据准备。
蚂蚁集团研发的统一宽表系统OmniTable，已在生产环境管理超过35PB、3050亿条以上的大模型训练数据，覆盖Web、代码、PDF和SFT等数据域。在一项真实SFT数据准备任务中，端到端周期从约14天缩短到2.5天，手工操作步骤从45步降至12步。这个结果并非来自一台更快的机器，而是改了数据工程师组织数据和特征的方式。
传统大模型数据加工围绕物理表展开：一个数据源接入后，解析结果落一张表，清洗再落一张，质量分、领域标签、去重签名继续产生新的表，Web、代码、PDF、SFT又各自维护一套流程。数据源和特征持续增加后，维护对象迅速膨胀，论文记录了一个实际案例：为了补一个特征，工程师需要在任务画布上处理106张表，表却只保存结果，很少记录结果是怎么算出来的。
OmniTable的核心原则是逻辑统一、物理分离。在逻辑层，每一行代表一条可追踪的数据实体，每一列保存某个处理阶段的状态或一项衍生特征，两类系统字段负责把列对齐：全局主键让同一条数据在不同来源与阶段使用同一标识，接入批次、来源和版本也有记录。数据回刷、点查和血缘追踪因此都有了稳定锚点，物理层则可以拆行、拆列、合并小文件或建立物化视图，上层schema不变。
特征计算从画任务改成报目标列，系统直接检查这些列在目标批次上的状态，已完成的结果复用，缺失的祖先列进入计划。任务成功完成后，系统原子登记批次、特征列、版本与列级血缘。过去分散在脚本、调度平台和人工记录里的信息，由此进入同一个元数据面，工程师负责定义特征语义，系统接手依赖展开、执行路由与结果提交。
非结构化语料里总会混入异常编码、超长文本或损坏内容，数据达到数亿条后，极低的异常比例也会产生大量坏样本。OmniTable把常见UDF故障隔离到记录级：每次调用带超时和内存检查，遇到异常记录样本ID并写为NULL，其余记录继续处理。在一个500GB、约6亿条记录的特征任务对照中，开启故障隔离后约99.995%的记录一次处理完成、耗时约6.2小时无需人工介入，旧流程则需要三轮排查重提，总耗时约52小时。
大模型数据特征的计算形态差异很大，文本长度、规则过滤适合CPU或SQL，模型推理可能交给GPU。OmniTable根据声明、算子画像与集群负载在Spark、MaxCompute SQL与GPU推理平台之间选择后端，并把读取同一列的特征融合成一次扫描。在约2.5PB、3000亿条以上的算子融合实验中，扫描次数从8次降为1次，CPU耗时减少55.9%，端到端时间从38小时降到14小时。
当大模型训练进入PB时代，数据工程的挑战已不再是把一次任务跑通，而是让持续增长的数据、特征和计算长期保持可管理。OmniTable试图节省的，不只是机器运行的时间，还有工程师反复找表、补任务和排查异常的时间。这套逻辑宽表加统一元数据面的思路，对算力与数据协同的平台型基础设施同样有借鉴意义：算力调度与数据编排若能共用一套可观测、可追溯的底座，企业级AI的规模化迭代才会真正提速。星战科技在算力调度与平台化工程上的持续投入，正是要把这类数据与算力协同做成标准化的底座能力。