蚂蚁VLDB最佳论文：用一张“逻辑表”驯服3050亿条训练数据

训练一个大模型之前，语料需要经过解析、清洗、去重、质量评分、Token化和样本组装。

传统的大模型数据加工通常围绕物理表展开。一个数据源接入后，解析结果落一张表，清洗结果再落一张，质量分、领域标签、去重签名和安全标记继续产生新的表或中间结果。Web、代码、PDF、SFT又各自维护一套流程。

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

统一逻辑视图解决了“数据在哪”的问题，Catalog继续管理特征怎样产生。

非结构化语料里总会混入异常编码、超长文本或损坏内容。数据达到数亿、数十亿条后，极低的异常比例也会产生大量坏样本。传统批任务常以任务为失败单位，一次UDF OOM或超时就可能让多TB计算整体退出。

大模型数据特征的计算形态差异很大。文本长度、字符比例和规则过滤通常适合CPU或SQL；模型推理既可能运行在CPU，也可能交给GPU，取决于模型规模、算子画像与资源条件。OmniTable根据用户声明、算子画像、引擎能力和集群负载，在Spark、MaxCompute SQL与GPU推理平台之间选择执行后端，并结合历史运行信息调整资源参数。

宽表上线后仍会不断增加批次和特征。小文件累积、分区倾斜、列数增长和查询热点变化都会拖慢访问。OmniTable的后台治理服务持续观察这些指标，自动执行小文件合并、行拆分、列拆分和物化视图构建。

单样本排查走另一条路径。全局ID索引直接把ai_unique_id定位到物理表、分区和row group。在25PB、3000亿条以上记录、800多个逻辑列的Web数据上，查询完整逻辑行的P50为8.3秒，P99为14.7秒；全扫描分别需要184秒和612秒以上。

论文用一个真实SFT数据准备任务做了端到端对照。任务包含8个数据来源和12个特征，其中9个是CPU UDF，3个是GPU推理。

OmniTable把过去分散在多套工具里的四类信息放到一起管理：数据批次、特征定义、执行状态和列级血缘。逻辑宽表为用户提供稳定入口，Catalog维护数据与特征之间的关系，执行和治理服务继续在底层选择合适的物理组织。