作为常年蹲云栖大会的人我每年最关心的不是又发布了多少花哨的硬件而是底层数据平台到底往哪个方向走。今年 ODPS 的升级标题非常直白——“全面升级构建 AI 原生的全模态大数据基础设施”。这几个词拆开看都认识合在一起其实就是一件事过去我们先把数据存好、算好再把结果喂给 AI现在这条路反过来了平台从底层开始就得同时伺候人和模型。ODPS 对内是阿里几乎所有数据业务的底座对外就是 MaxCompute。这次升级意味着你以后面对的不再是一个“数仓”而是一个能直接吃文本、图片、音频、视频能跑 SQL、跑 Python、跑训练的全模态数据基础设施。适合谁看数据工程师、算法工程师、做数据平台架构的人还有那些正在纠结“数仓和 AI 怎么打通”的团队这篇文章应该能帮你省掉不少自己摸索的时间。1. 为什么 ODPS 要重构传统数仓挡不住 AI 的野路子1.1 数据形态变了从“一行一列”到“一文一图一视频”过去我们做数仓默认的前提是数据必须结构化。一张订单表、一张用户表字段定死schema 固定ETL 清洗完扔进 Hive 或者 MaxCompute然后出报表、做分析。这套逻辑跑了好多年稳定可靠但到了 AI 时代它最根上的假设开始松动了。现在企业里增长最快的数据根本不是订单和用户行为日志而是客服录音、工单文本、监控视频、商品图片、产品说明书、合同文档。这些数据天生就是非结构化的你没法把它们塞进一张规规矩矩的表里。传统做法是先做一大堆 OCR、ASR、NLP 预处理把非结构化数据“榨”成结构化字段再入库。问题在于一旦数据经过这种暴力抽取信息损失非常大比如图片里的构图信息、语音里的语气情感、视频里的时序关系这些对模型来说恰恰是最有价值的部分。ODPS 这次升级抓住的核心矛盾就是这个数据形态已经不是“一行一列”能装得下的了平台必须原生支持多样化的数据表达。不是让你拿 SQL 去查一张图片而是让平台能统一管理文本、图片、音频、视频这些原始数据并且让它们之间可以互相计算、互相检索。全模态这个说法落在工程上就是一份原始数据进来平台不强行做结构化而是保留它的原始形态同时在上面叠加结构化描述、向量表达、标签体系。这样人和模型都能按自己的方式去消费它。1.2 计算模式变了批处理之外还有训练、推理、向量检索ODPS 的传统强项是批处理离线跑 T1 的报表凌晨跑几万个 SQL 任务这个能力打磨了很多年稳定性和吞吐量都没得说。但 AI 时代的计算负载和批处理完全是两码事。模型训练是 GPU 密集型的活一个训练任务跑起来就是几个小时甚至几天中途不能挂挂了要断点续训。在线推理要求的是极低延迟用户发一条请求几百毫秒内要返回结果。向量检索又是另一类它介于离线和在线之间既要做大规模的批量索引构建又要支持单条查询的快速召回。这三种负载如果分开建设就是三套集群、三套资源、三套运维体系成本直接翻倍数据还要在两个平台之间搬来搬去。传统大数据平台最大的问题就是把这些负载死死地按 CPU 批处理来设计。你让训练任务去跑数据数据 IO 跟不上你让推理服务去访问数仓延迟又压不下来。所以 ODPS 升级的核心动作之一就是让同一套基础设施同时调度多种计算模式而不是靠外部拼接。批处理继续跑 SQL训练任务直接在平台内拉起 GPU 资源向量检索走专门优化的索引路径。平台内部可以混部资源可以复用数据不用出湖。这不是一个简单的新功能而是整个调度和计算架构的底子要换。1.3 数据范式变了数据段要直接喂给模型还有一个更底层的范式变化值得所有做数据平台的人认真想想。过去我们做数据指标体系、做报表最后产出物是给“人”看的。分析师看报表业务方看大屏数据平台的价值建立在“人能看懂”这个前提上。AI 时代数据平台的价值出口变了。数据最终要变成训练样本要变成 embedding 向量要进入知识库被模型检索。换句话说数据基础设施服务的对象不再只是人还有模型。而模型消费数据的方式和人不完全一样。人看的是聚合后的趋势图、明细表模型要的是原始样本、高质量的正负例、标注信息、切分好训练集和验证集。ODPS 升级为“AI 原生”最本质的变化就在这里数据平台必须同时具备两种供给能力。一种是给人看的继续保持 SQL 分析、报表、BI 这些能力另一种是给模型吃的要支持样本集的注册、版本管理、质量评估、特征生成、向量化。数据平台不再只是一个“查询型”系统而是一个“供给型”系统。我见过太多团队在传统数仓外面自己搭一套样本管理系统数据链路又长又脆运一次样本要写一堆脚本。如果底座原生化地把这条链路做进去这些重复劳动就可以省掉了。2. 全模态大数据基础设施的底座设计存储、元数据、计算三层如何咬合2.1 存储层一份数据吃遍所有模态聊全模态第一个要解决的就是存储。传统数仓的存储是围绕表结构来设计的数据按列存、按分区组织查询引擎按需扫描。这个思路对结构化数据很高效但对图片、音视频这种大文件就很不友好。这次升级在存储层做的关键转变是把对象存储的能力和数仓的治理能力放在了一起。原始图片直接落对象存储不强制入库视频存一份配上自动抽取的帧、字幕、音频轨道文档存原文同时把解析后的层级结构、段落切片挂上去。一份数据源多种消费方式平台统一管权限、管版本、管生命周期而不是像以前那样原始文件放在 OSS 上解析结果放在表里两边各管各的。这里有个很实际的工程问题小文件治理。AI 场景下数据文件的体量往往比传统业务数据碎得多。一批图片可能就是几万个小文件如果存储层不对文件布局做优化训练任务读数据的时候就会因为文件数太多而卡在元数据操作上。传统数仓靠分区和压缩来解决全模态场景下还得考虑文件大小和模态类型的匹配图片按文件夹粒度聚合、音视频按时长切片、文档按页码切块。这套文件布局策略直接决定了后续训练和检索的效率属于越早设计越省事的环节。2.2 元数据层让模型知道数据长什么样存储解决了数据放哪的问题元数据解决的是数据是什么的问题。传统元数据管理表的 schema、分区、血缘这套体系成熟可靠但对 AI 来说远远不够。模型消费数据之前需要知道数据的质量怎么样、格式是什么、切分状态如何、有没有标注、用了哪个版本的预处理逻辑。这次 ODPS 升级把元数据的概念从“表”延伸到了“样本”和“特征”。一张原始表进来之后平台可以登记多个样本集每个样本集有自己的版本号、切分比例、标签方案、质量评分。训练用 v3 版本的样本评估用 v2 版本的样本出了问题能快速追溯是数据变了还是标注变了还是模型结构变了。血缘关系也细化到样本级一个训练任务用了哪个样本集特征是怎么从原始数据加工出来的这些链路都要能被追踪。这个能力在实际排障中特别有用。模型效果突然掉点最常见的原因不是模型代码出了问题而是训练数据悄悄变了。传统数仓里你只能看到“表更新了”但更新前后样本分布有什么变化、哪些样本被替换了很难查。有了样本级的版本和血缘管理至少能把排查范围精确到某个批次的数据变更而不是靠猜。2.3 计算层SQL、Python、ML 三种“方言”互相打通老大数据平台有个让人很头疼的问题SQL 和 Python 之间的数据流通成本太高。数仓工程师用 SQL 清洗好数据算法工程师还要用 Python 把数据导出来再加工中间隔着一层导出导入。ODPS 本身的 PyODPS 已经解决了一部分问题但这次升级想更进一步把 SQL、Python 和模型训练这三种计算模式放到同一个运行时里。可以理解为同一份数据不需要经过导出导入SQL 处理完的结果可以直接被 Python 代码引用Python 训练出来的模型可以直接注册回平台模型推理的结果又可以回到 SQL 里被查询分析。整个链路在同一个安全边界内流转权限、审计、数据加密都是一套体系。我实际用下来的感受是“方言”打通之后数仓工程师和算法工程师第一次能真正在同一份数据上协作而不是互相递文件。这背后其实是统一类型系统和统一执行引擎的支撑。表格数据、向量数据、字符串文本在底层都能互相转换不用在 Python 和 SQL 之间做序列化和反序列化。工程上这很考验兼容性但我确实看到这次已经把路线走通了不是简单地把两个引擎拼在一起而是真的在建模层做了融合。2.4 调度层CPU 与 GPU 的“混部”才是 AI 原生的标志如果只看存储、元数据、计算这三层本质上还是一个“增强版数仓”。真正把 AI 原生这个定位立住的是调度层加入了 GPU 资源的管理能力。AI 原生不是数据平台旁边挂一个 GPU 集群而是 GPU 资源成为平台内的第一类资源和 CPU 资源统一被调度、统一被分配。这个设计解决的是资源碎片化问题。一个业务团队往往有批处理任务在凌晨跑有训练任务在白天跑有推理服务全天候跑。如果 CPU 和 GPU 分属两套集群高峰期的资源利用率很难平衡。混部之后GPU 空闲时段可以跑更适合自己的推理预热CPU 集群的压力也可以借一部分给 GPU 任务做数据预处理。平台根据任务的优先级和资源特征把 CPU 和 GPU 合理搭配整体资源利用率能明显往上走。当然混部也是有代价的最大的风险是任务相互干扰。CPU 批处理任务占满内存GPU 训练任务容易出现 OOM。所以调度层必须做资源隔离和抢占策略。实际配置时要结合任务的重要程度设置优先级配额训练任务建议给保活实例批处理任务可以给弹性实例优先级低一些。这块没有统一标准得根据各自业务的重要性反复调。但方向是对的AI 原生基础设施调度层的弹性是最核心的能力。3. ODPS 全面升级的核心能力拆解从 SQL 分析到模型供给3.1 向量化与全模态表达文本图片音视频的统一语言全模态基础设施最直观的能力变化是数据的“向量化”。文本切成 token 之后转成向量图片通过 CLIP 之类的模型转成向量音视频抽帧抽字幕也能转成向量。向量成了不同模态数据之间互相检索的统一语言。图片搜文字、文字搜视频本质上都是向量距离的计算。ODPS 这次把向量索引内建到了平台里而不是让用户自己搭一个向量数据库再手动同步数据。这意味着你可以继续用 SQL 管理表和分区同时给对应的列建向量索引。平台负责索引的构建、更新、查询。数据变更之后增量索引的更新对用户是透明的不需要像外部方案那样搞一套同步链路出问题还得两头排查。我特别想提醒一点向量化不是魔法embedding 模型的选择和更新频率直接决定检索质量。很多团队建向量索引时只用了默认模型数据分布变了也不重新评估检索效果自然越来越差。最佳实践是把 embedding 模型也当成平台资产来管理定期用标注数据评估召回效果。平台提供能力是一回事你用得好不好是另一回事。3.2 AI 原生的任务编排与资源调度传统大数据平台的任务编排以 SQL 依赖为主比如 A 表算完生成 B 表B 表再算 C 表。AI 原生的任务编排要复杂得多数据预处理任务、特征生成任务、训练任务、评估任务、模型注册任务之间既有数据的依赖也有模型版本的依赖。训练任务跑完要验收评估达标才能注册服务中间任何一个环节失败都要能自动重试或者回滚。这次 ODPS 升级把 DAG 调度逻辑扩展到了“数据模型”的联合调度。任务类型不只是 SQL还可以是 Python 脚本、训练容器、推理服务。依赖关系也不再局限于表级样本集变更可能触发重新训练新模型版本上线可能触发一轮新的评测流程。调度系统等于多了一张“模型生命周期”的编排图。实操上建议团队先梳理清楚自己的模型发布流程再映射到平台的调度配置里。比如每天凌晨跑数据预处理任务完成后自动触发增量训练训练完自动跑评估集评估通过后进入 staging 环境候选发布。可以用试跑、灰度、全量三个队列来控制发布节奏。这套流程一旦跑顺了模型迭代的周期能从以周为单位缩短到以天为单位。3.3 开发体验Notebook、SQL、Python 一体化的上手变化过去数据团队和算法团队用的是两套工具链。数据工程师在 DataWorks 写 SQL算法工程师在 Notebook 里写 Python。中间通过表来衔接每次协作都要对表结构、对数据格式、对权限。升级之后平台把 Notebook 和 SQL 开发环境融合在一起同一个界面里既能写 SQL 查询又能写 Python 处理逻辑还能直接拉起训练任务。这种融合带来的最大便利是不需要“切换上下文”。查一个表用 SQL 顺手做特征工程切到 Python调试模型用 Notebook最终发布训练任务也在这个环境里。数据和逻辑始终在一个统一工作区变量可以在 SQL 和 Python 之间传递。不用像以前那样SQL 查完结果导出为 CSV再加载到 Notebook 里跑完再导回链路短了很多出错的概率也少了很多。对团队管理来说这个变化还有一层意义拉平了数据工程师和算法工程师之间的协作门槛。数据工程师能做简单的数据探索算法工程师也能直接查数仓的表不用每次都走数据工程师“代办”。职责边界仍然可以清晰但工具层面的摩擦被大幅减少了。实测下来这种融合对团队效率的提升非常直观尤其是那种数据团队和算法团队日常需要大量沟通的场景。3.4 数据治理样本、特征、模型的血缘链路“AI 原生”这个概念容易给人造成误解以为平台就只服务于模型训练。实际上 AI 原生的数据平台治理能力只会更重不会更轻。因为当数据被模型消费之后出问题的代价更高了。模型训练数据如果存在偏差影响的是线上所有的推理结果。升级后的治理体系覆盖三个新对象样本集、特征集、模型。每一个样本集要有来源信息、版本信息、质量评估信息。每一个特征集要记录它从哪些原始表加工而来加工逻辑是什么。每一个模型要关联它的训练样本版本、特征版本、代码版本。当这三个对象建立了完整血缘出了问题才能沿着链路去追踪。我见过一个典型的治理事故某个风控模型突然失灵排查到最后才发现是上游一个特征工程师误删了某段特征逻辑模型悄悄用了三个月错误的特征。如果当时有完善的血缘链路这种问题几天内就能被发现。平台层面的血缘能力搭好之后剩下的就是组织要有对应的数据治理规范来配合血缘是工具用不用才是关键。4. 落地实操从传统数仓迁到 AI 原生平台的几个关键步骤4.1 迁移前先做数据盘点别急着全量搬但凡做过迁移的人都懂最怕的就是一上来就搞全量迁移风险巨大不说出了问题回滚成本极高。升级到全模态基础设施第一步一定要先做数据盘点搞清楚存量数据里到底哪些真正需要 AI 能力哪些还能安安稳稳留在传统链路。盘点可以从三个维度看数据类型、消费方式、更新频率。纯结构化、只服务于 BI 报表的表没必要改造维持原样即可。有大量图片音视频、需要向量检索、需要给模型供数据的表才需要纳入新体系。还有一类表最尴尬——既有传统分析需求又有模型训练需求这类表要做单独设计不能简单套用老办法。盘完之后建议画一张迁移优先级矩阵。首先是“数据重要程度”其次是“AI 需求的紧迫程度”。两个维度都高的先迁比如风控特征表、推荐样本表一个维度的缓一缓都不高的基本不用动。这样的好处是每一批迁移都有明确的动机和验收标准而不是为了迁而迁。我自己做迁移项目时最早踩的坑就是贪多一口气迁了几百张表结果大部分人力和时间都花在了处理边缘表的特殊格式上核心链路反而推进得慢。4.2 建立“数据-样本-特征-模型”的登记机制真正让 AI 原生平台发挥价值的不是引擎能跑多快而是平台上的资产能被清晰登记和追溯。迁移之后的第一件正事就是把“数据表、样本集、特征集、模型”这四个对象全部登记到平台的元数据体系里并建立它们之间的依赖关系。具体落地时建议从最核心的业务场景开始打样。比如选定一个推荐场景把它的原始行为表、样本集、用到的特征、训练出的模型一整套登记完血缘跑通。然后把它当模板复制到其他场景里去。不要一开始就追求全量登记那样会陷入无穷无尽的存量盘点里无法自拔。登记机制还要配套责任机制。每一条样本集要有 owner每一个特征要有关联的 SQL 或 Python 代码地址。这听起来像管理问题但离开了平台的支撑几乎无法执行。平台把登记做成了线上化的强制动作之后血缘才会是自动生成的而不能只靠人工自觉维护。4.3 计算资源配置与成本控制的核心参数AI 原生平台因为引入了 GPU 资源成本模型会比传统数仓复杂很多。我这里的建议是不要把 GPU 当普通计算资源来分要按任务类型区分对待。训练任务分两类日常迭代型和高优攻坚型。日常迭代型可以用弹性实例允许被抢占价格便宜适合实验性质、可以重跑的任务。高优攻坚型必须用保活实例配额锁死宁可平时空闲也不放给别的任务抢占适合关键模型的正式训练。推理服务要注意的是资源水位通常要设置最小实例数和最大实例数根据线上流量做弹性伸缩。这个最小实例数就是你愿意为体验付出的保底成本。还有一个很容易被忽略的隐性成本数据预处理对 GPU 任务的影响。很多团队把资源集中投给 GPU以为 GPU 越强训练越快结果发现 GPU 经常处于等待数据的状态真正占用 GPU 的时间不到一半。这时候问题基本出在上游数据读取慢、预处理没做好、小文件太多。与其加 GPU不如先优化数据管线。我见过一个案例GPU 利用率从 30% 提到 70%不是因为加了卡而是把数据读取改成列存切块、把预处理挪到 CPU 池并行执行整个训练耗时缩短了一半以上。成本优化有时候不是靠砍资源而是靠消除等待。4.4 一个多模态检索管线的实际流程示例理论讲再多不如一个具体流程直观。我以“把存量音视频改造成可检索的知识库”为例演示一遍纯靠平台能力怎么跑通。原始数据是一批视频文件存在对象存储上。第一步用平台内置的抽取任务把视频拆成帧、音频、字幕三路数据。帧走视觉模型转成向量字幕走 NLP 模型转成文本向量音频转成语音特征向量。第二步这三路向量统一注册到同一个向量索引空间里同时保留原始文件路径、时间戳、段落信息作为关联字段。第三步建一张“视频段落”的映射表视频的每一段都能关联到对应的帧、字幕、音频向量。第四步查询的时候用户输入一段文字先转成 query 向量在向量索引里跑 topK 召回再根据映射表精准定位到某个视频的第几分几秒。这套流程如果自己拼接组件至少需要对象存储、消息队列、离线计算、向量数据库、在线服务五套系统对接每一段都要自己写胶水代码。在平台内做就是一个多模态任务编排的配置工作中间的数据流转完全透明权限管理也能统一下来。我强烈建议想入局的团队先拿这种相对标准、价值明确的场景练手跑通一个样例后再往更复杂的场景推进。5. 常见问题与排查技巧实录5.1 训练吞吐上不去八成是小文件问题问十个用 AI 平台做训练的团队可能八个都遇到过训练数据读取慢的问题。表象是 GPU 利用率低、训练 loss 下降得慢根因多半是小文件太多。传统数仓对这个问题不敏感因为查询引擎有缓存、有谓词下推能兜住一部分性能损失。但训练任务不一样它要全量扫描数据文件数越多打开文件、读元数据的开销就越大。一个 batch 的数据可能分布在几千个小文件里IO 等待自然就把 GPU 饿死了。排查思路很简单先看存储层的文件平均大小和数量。如果平均文件小于 64MB基本可以判定小文件问题。解决方法有三板斧合并小文件把碎片文件合并成大文件、分区裁剪让训练任务只读自己需要的分区、用列存格式按需读取列而不是整行扫描。合并完之后重新试一遍训练吞吐的提升会非常明显。5.2 GPU 利用率忽高忽低瓶颈往往在预处理GPU 利用率不稳定很多人第一反应是加卡或者调并发。但多数情况下瓶颈根本不在 GPU 计算本身而在 CPU 侧的数据预处理。比如图片解码、文本切分、数据增强这些操作在 CPU 上执行速度跟不上 GPU 的消费速度GPU 就会周期性地空转。我排查这类问题时的操作路径是先看 GPU 侧有没有记录“等待数据”的耗时统计如果有再去看预处理任务跑在哪个资源池。通常解决办法是把预处理任务单独放到 CPU 资源池里并行执行让预处理和训练异步进行。Pre-fetch 机制很关键意思就是提前把下一批要训练的数据准备好而不是等 GPU 要了才去现算。平台如果支持混合加载就把预处理卸载到 CPU 侧。这个调整做完GPU 利用率通常能稳定在高位。5.3 类型系统不匹配SQL 和 Python 来回倒数据SQL 和 Python 引擎打通之后还是会碰到类型对不上的问题。比如 SQL 里的 INT 和 Python 里的 int 基本能对上但 Decimal、Timestamp、Array 这些复杂类型两个体系的映射经常会出幺蛾子。最典型的坑是时区SQL 里的时间戳可能带时区Python 里读出来变成无时区的 naive datetime两边一比就错位。这类问题要尽早建立一套内部的类型映射规范团队共同遵守。比如统一规定时间字段一律用 UTC 存储展示层再转本地时区金额字段统一用 Decimal(18,4)数组字段在 SQL 里用 ARRAY在 Python 里用 list但嵌套层级不能超过两层。规范定好之后大部分类型坑都可以提前避开。万一还是出了问题排查时先看两端的类型定义再做数据抽样对比逐字段缩小范围。5.4 血缘断裂样本无法溯源平台的血缘能力再强如果资产登记不规范血缘照样会断。最常见的情况是训练任务直接读了某个表的最新分区但没有注册样本集也没有记录版本等模型出问题再想追溯数据版本已经找不到当时的快照了。这个问题的根因在流程而非工具。平台层面能做的是强制要求训练任务的输入必须是已注册的样本集而不是裸表。可以配置一条规则未注册的样本集不允许被训练任务引用类似“必须有分区”的约束。一开始团队会觉得烦但几次因为找不到数据版本而踩坑之后大家反而会主动配合。血缘的价值不是审计用的而是保护你自己的。5.5 快速排查速查表现象优先排查方向常用处理手段GPU 利用率低小文件、预处理瓶颈合并文件、预处理卸载到 CPU训练任务频繁失败数据切分、资源配额检查样本集版本、提升保活配额检索召回效果差embedding 模型是否过时更换模型、重新评估索引质量SQL 与 Python 结果不一致类型映射、时区处理建立统一类型规范模型效果掉点上游数据变更、样本集版本比对血缘、回滚到历史样本版本写在最后的体会我个人的体会是ODPS 这次升级最值得关注的不是某个具体的新功能而是它把数据平台的产品形态彻底重定义了一遍。以前我们建设数据平台默认路线是先把数据治理好、模型训练是另一个体系的事现在的思路变成模型训练嵌入到了平台的计算体系里数据、样本、特征、模型是同一个平台上的连续资产流转。对做实际工作的人来说这意味着两件事一是不要再费劲把数仓和 AI 链路拼在一起而是尽量让平台底座直接承接二是团队的知识结构要从“会 SQL”往“懂数据懂模型”的方向升级。真正吃透这套基础设施的人未来的竞争力不在某个工具本身而在于能不能把数据和模型当作一个整体来思考。
