训练一个大模型之前，语料要经过解析、清洗、去重、质量评分、Token 化和样本组装。规模一到 PB 级，数据工程师面对的就不只是算力账单（算力正加速向云巨头集中），还有几百张表、不断新增的特征，以及少数几条就能让整批任务重跑的异常数据。
蚂蚁集团研发的统一宽表系统 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 分别对应原始数据、处理中间态和训练可用形态，后面再按需追加质量、领域、安全、去重等特征列。一个数据域，一个逻辑视图。
这其实是数据库领域几十年前就做过的动作：把「你推理用的 schema」和「底层服务它的存储」分开。大模型数据工程终于等到了对应的东西——在混乱的物理表之上加一层 schema。
为什么这事不止是一家公司
模型能力越来越不被架构、而被数据纪律决定。所有前沿实验室都在跑同一条训练回路，真正的差异在于它背后的数据有多干净、多可追溯、多可复现（数据质量驱动进化是共同主线）。OmniTable 是一个信号：AI 的数据工程层正在成熟为一门真正的工程学科，有工具、有抽象、有实打实的性能数字。
只要你在跑正经的训练或微调管线，这条经验都可迁移：把特征当作有版本、有血缘的资产，而不是脚本里的临时变量；给每一行一个身份；在底层再乱的物理之上，保持一个干净的逻辑视图。