OmniTable如何重构大模型数据工程？35PB语料管理效率提升5.6倍的底层逻辑
在大模型训练进入PB级规模的时代，数据准备环节正成为制约研发效率的关键瓶颈。传统流程中，一条原始网页或PDF文档需经历解析、清洗、去重、质量评分、领域标注、安全过滤、Token化等多个阶段，每个阶段往往对应一张独立的物理表。当数据源扩展至Web、代码、PDF、SFT等多个域，特征维度持续增加时，工程师面对的不再是清晰的数据流，而是数百张相互割裂的表、散落在脚本中的UDF逻辑，以及因单条异常记录导致整批任务失败的运维噩梦。
蚂蚁集团在VLDB 2026工业赛道获奖的OmniTable系统，正是对这一困境的系统性回应。其核心理念并非追求更快的计算引擎，而是重构数据组织方式——将物理表降级为存储实现细节，把数据批次与特征列提升为一等对象，构建一个逻辑统一、物理分离的宽表体系。这一设计在生产环境中已管理超过35PB、3050亿条训练数据，并在真实SFT任务中实现端到端效率5.6倍的提升。
逻辑宽表：用全局主键锚定数据生命周期
OmniTable的首要突破在于重新定义了“表”的语义。传统数据管道中，每一步处理都生成新的物理表，导致同一数据实体在不同阶段以不同ID存在，难以追踪。OmniTable则引入两个关键系统字段：_ai_unique_id_和_ai_append_name_。
_ai_unique_id_作为全局唯一主键，确保同一条原始数据（如一篇网页文章）在RawData、ProcessedData、TrainableData等所有处理阶段保持一致标识。这意味着无论数据经过多少次转换，工程师都能通过该ID精准定位其全生命周期状态。而_ai_append_name_则记录数据接入的批次、来源和版本信息，为回刷和版本对比提供依据。
在此基础上，系统将Web、代码、PDF、SFT等数据域分别建模为四张逻辑宽表。每张逻辑表包含数百至上千个逻辑列，涵盖原始内容、中间处理结果及各类衍生特征。例如，Web宽表管理约25PB、3000亿条记录，拥有800多个逻辑列和200多个已注册特征。这种设计使得用户查询时只需面向一张逻辑表，无需关心底层物理存储如何拆分。
值得注意的是，逻辑宽表并非简单的视图封装。其背后由Catalog系统维护逻辑列与物理位置的映射关系。当底层因性能优化需要进行行拆分、列拆分或小文件合并时，上层schema保持不变。这种解耦使得物理布局可随访问模式动态演进，而业务逻辑不受干扰。
特征即资产：从脚本执行到目标驱动的计算范式
在传统流程中，新增一个质量评分特征意味着工程师需手动编写UDF、配置调度任务、指定输入输出表，并确保与其他管道兼容。OmniTable将这一过程转变为“声明式”操作：工程师只需注册特征定义，系统自动完成依赖解析与执行规划。
特征注册包含五个关键要素：输入列、输出列、计算逻辑（支持UDF/SQL/模型推理）、版本号及执行偏好（CPU/GPU）。当提交回刷任务时，系统基于Catalog中的列级依赖DAG，自动识别目标批次中缺失的最小依赖闭包。例如，若质量分依赖清洗文本，而清洗文本又依赖解析结果，则系统会检查这三列在目标批次的状态——已完成的结果直接复用，缺失部分生成执行计划。
这种机制显著减少了重复计算。在一项涉及8个CPU/Spark特征的实验中，所有特征均读取parsed_text列。传统方式需8次独立扫描，而OmniTable将其融合为单次读取，CPU Hours从4.2万降至1.85万，端到端时间缩短2.7倍。更重要的是，共享输入的特征即使由不同团队开发，也能自动协同，避免资源浪费。
任务执行完成后，Catalog原子化登记“批次—特征列”的状态、版本、物理位置及血缘关系。这使得任何一列数据都能追溯其计算路径：使用了哪个输入批次、依赖哪些父列、采用何种特征版本、由什么引擎计算。过去分散在脚本、调度平台和人工记录中的信息，由此汇聚为统一的元数据面。
记录级容错：让异常数据不再拖垮整批任务
非结构化语料中不可避免存在异常记录，如编码错误、超长文本或损坏内容。在数十亿条规模下，即使异常率低至0.005%，也可能导致传统批处理任务频繁失败。OmniTable通过记录级容错机制解决这一问题。
系统为每次UDF调用设置超时与内存检查。当遇到Python OOM、超时或未捕获异常时，仅将该条结果标记为NULL并记录错误详情，其余记录继续处理。错误记录统一归集至error table，便于后续修复与补算。在一项500GB、6亿条记录的测试中，31,247条异常记录（占比0.005%）被隔离处理，其余99.995%的数据一次完成，耗时6.2小时；而关闭该功能时，任务直接失败，需经三轮人工排查与重提，总耗时达52小时。
尽管记录级包装带来3%–5%的执行开销，但其节省的人工干预时间远超此成本。尤其在大规模数据准备中，工程师无需再为极少数坏样本反复调整过滤规则或删除数据，大幅提升了工作流的稳定性。
自适应执行与后台治理：让物理布局持续优化
大模型特征计算形态多样：文本统计适合CPU，模型推理可能需GPU。OmniTable根据用户声明、算子画像、引擎能力及集群负载，在Spark、MaxCompute SQL与GPU推理平台间智能路由。同时，系统通过历史运行数据自适应调优资源参数。在针对BERT特征的实验中，自适应配置首次提交成功率达100%，任务成本与专家手调相差不超过5%。
随着宽表持续变宽，物理布局面临小文件累积、分区倾斜等问题。OmniTable的后台治理服务通过Prepare—Execute—Commit三阶段流程自动优化：先准备新布局并重写数据，验证通过后原子切换Catalog映射。旧布局在切换前继续服务查询，失败任务可回滚，确保用户无感知。
列拆分机制突破了单引擎的物理列数限制。在2PB固定数据测试中，逻辑列从200增至2500时，P95延迟仅从25秒升至38秒，成功跨过底层引擎约1200列的上限。同时，热点列组的物化视图预消除JOIN操作，在15列、4表场景中将过滤导出吞吐从4.8 TB/小时提升至20.1 TB/小时。
效率提升的本质：减少协调成本而非单纯加速计算
OmniTable在真实SFT任务中的5.6倍提速，并非来自硬件升级，而是系统性降低工程协调成本。旧流程需14天完成的任务中，约2天用于定位和接入数据，9.5天用于特征回填，2.5天用于多表JOIN与导出。过程中涉及45个手工步骤、24条独立管道和35张物理表。
OmniTable将接入阶段压缩至0.5天，特征回填至1.7天，过滤导出至0.3天，总计2.5天。手工步骤降至12个，独立命令减至10条。效率提升的核心在于：
- 数据定位简化：逻辑宽表提供统一入口，无需跨表查找；
- 计算复用增强：共享输入的特征自动融合执行，避免重复扫描；
- 失败影响缩小：记录级容错防止整批重跑；
- 物理优化自动化：后台治理持续调整布局，无需人工干预。
这些改进共同指向一个更深层的转变：大模型数据工程的重点已从“跑通单次任务”转向“维持长期可管理性”。OmniTable通过将数据批次与特征列作为一等公民，构建了一个可追溯、可回刷、可治理的系统，让工程师从繁琐的表管理中解放，专注于语义定义与质量优化。
宽表之外：一种面向AI时代的工程范式
OmniTable的设计并非没有代价。热点列物化增加8%–15%存储开销，记录级容错带来少量执行损耗，后台治理占用集群资源。但这些成本换来了更高的工程效率与系统稳定性。更重要的是，它提供了一种可复用的系统设计思路：先稳定逻辑语义，再让物理实现持续演进。
在大模型竞争日益激烈的今天，数据准备效率已成为核心竞争力之一。OmniTable证明，通过重构数据组织方式，即使不依赖更强大的硬件，也能在PB级规模下实现数量级的效率提升。其价值不仅在于技术实现，更在于推动数据工程从“管道思维”向“资产思维”转变——将特征视为带版本、有血缘、可追溯的系统资产，而非临时计算的副产品。
这一范式或许将成为未来AI基础设施的重要组成部分。当万亿Token模型成为常态，数据工程的挑战将不再是处理单次任务，而是如何让持续增长的数据、特征与计算在复杂系统中保持有序、高效与可解释。OmniTable为此提供了一个经过35PB生产验证的答案。