“云栖2026”第一天的主论坛我坐在媒体区旁边是几个从北京过来的数据平台团队朋友。大屏幕上打出“ODPS 全面升级构建AI原生的全模态大数据基础设施”这个主题时我们几个人的反应很一致先是一愣然后开始低头互相发消息。这不是一次普通的版本迭代——ODPSMaxCompute 的前身品牌在阿里云体系里一直承担着离线大数据处理“压舱石”的角色从 2015 年前后大规模落地到今天几乎所有中大型企业跑数仓、做报表、算指标背后都站着这套系统。它宣布“全面升级”而且升级方向是“AI原生的全模态大数据基础设施”意味着我们过去十年积累的数据架构认知、ETL 习惯、建模方式、成本模型都得重新过一遍筛子。这篇文章我不想写成发布会通稿式总结。标题里这组词——“AI原生”“全模态”“大数据基础设施”——每一个单独拎出来都是烫手概念组合在一起更需要拆开看。我会结合自己对 ODPS/MaxCompute 的使用经验以及这几年做数据平台和数据湖的实践讲清楚这场升级到底升了什么、哪些是实质能力、哪些是概念包装、对普通数据开发者和算法工程师意味着什么。文章末尾也会给出我个人的迁移与验证建议不保证全对但都是踩过坑之后得出的判断。1. 为什么是现在AI 工作负载把数据平台逼到了墙角1.1 数据管线变了从“取数算数”到“喂模型调模型”过去十年大数据平台的核心命题可以用八个字概括把数据算得快、算得稳。离线场景 T1 跑批实时场景 Kafka 加 Flink 做流式处理数仓建模、指标体系、报表加速所有的技术演进都围绕“查询效率”和“计算成本”展开。ODPS/MaxCompute 这代系统正是在这个命题下成长起来的它的 SQL 兼容性、分布式调度、列式存储压缩每一项能力都服务于“大规模结构化数据的高吞吐计算”。但这种需求结构正在被 AI 大模型亲手打破。我自己在 2024 年下半年开始接触大量大模型训练相关的数据准备工作发现传统数仓管线对这类负载几乎没有准备。训练样本的读取和清洗通常是海量图文对、视频切帧、语音转写文本特征工程开始高频产出 Embedding 向量模型上线后还要批量跑推理评估把用户反馈、标注结果、模型输出循环回流到数据平台。这些负载有共同点数据不是简单表格、计算不是简单聚合而是需要把非结构化内容变为模型可用的语义表示再反复迭代。如果让传统数仓硬接这些负载结果就是开发团队不得不在数仓之外再造一条“AI数据管道”用对象存储存原始文件用向量数据库做检索用 Python 服务来回搬运数据。数据链路越拖越长出问题的环节越来越多。ODPS 选择在 2026 年这个节点全面升级本质上是它自己也意识到数据平台的下一轮增长不来自报表计算而来自 AI 数据工程。1.2 多模态数据普及传统数仓处理不了“一张图和一段声音”“全模态”这个词在 AI 圈并不新鲜多模态大模型、视觉语言模型、语音理解模型这些年一直是热点。但它放到大数据基础设施的语境中冲击力就完全不一样了。我举一个非常典型的场景零售企业做用户洞察过去只需要把订单表、浏览记录、会员等级这些结构化数据放进数仓算 RFM 模型、算转化率。现在的业务方会直接提需求“把我们App里的商品图片、用户评价里的短视频、客服录音都拉进分析里看看不同视觉风格对购买意愿的影响。”这句话听起来简单落地时却会撞上一整面墙。传统数仓支持的数据类型围绕数字、字符串、时间、JSON 展开图片是什么“一张 JPEG”——它最多被当成一个二进制的藏字段存起来没有任何计算语义。音频呢连合理的分区粒度都很难定义。视频更不用说涉及帧级别的切分、时间轴对齐、多轨抽取这些操作在 SQL 语义里几乎没有对应的表达式。也就是说多模态数据的普及不只是“容量变大”或者“格式变多”而是整套数据模型需要把图像、音频、视频、点云、时序信号当成“一等公民”来对待。ODPS 这次升级如果真能把这一类对象纳入统一类型体系和计算语义那它的价值就不只是技术迭代而是重新划定了大数据平台的边界数仓不再只是“企业结构化数据的仓库”而是“企业一切可学习数据的底座”。1.3 数据平台与 AI 平台的分裂才是真问题过去几年大部分公司的数据架构都是物理分裂的数仓归数仓数据湖归数据湖AI 平台再单独建一套。做推荐的要向量检索于是引进了专门的向量数据库做 CV 的要用原始图片做训练集于是把样本直接丢在对象存储上做语音的又要管一批标注工具和音频转写服务。数据被切成好几份每一份由不同团队、不同系统管理。我在和不少企业的数据负责人交流时听到最多的一句话是“我们不是缺 AI 能力而是数据自己在打架”。同一个用户的特征在数仓里是一份宽表在画像系统里是一份标签在向量库里是一组 Embedding三者之间靠 UUID 硬关联血缘关系经常断。数据分成好几份一致性、时效性、权限管理全都乱掉。ODPS 的“AI 原生 全模态”组合拳真正想解决的正是这种分裂。如果一套系统既可以存结构化标签又可以存 Embedding 向量还能关联原始图像和音视频并且用统一 SQL 做跨模态查询那企业就不再需要维护好几套互不相通的数据设施。这比我预想的“给 ODPS 加几个 AI 函数”要激进得多但也恰恰是当前最需要的基础设施级变革。2. “AI原生”底牌拆解不只是给数据库加个 API2.1 AI 附加 vs AI 原生两者的本质区别“AI 原生”这几个字这几年被用滥了。有的数据库产品加了一个向量索引就自称 AI 原生有的数据平台提供调用外部大模型的 API 函数也宣称自己完成了 AI 化。但如果你对比 ODPS 这次升级对外传达的信息会发现它讲的不是“调用 AI”而是“用 AI 的方式重构数据引擎本身”。我比较喜欢用一个类比来解释两者的差别AI 附加像是给一栋老房子装了一台新空调表面功能有了但墙体内的管道、电路还是二十年前的AI 原生则是从地基就开始按新的能源系统来设计新风、温控、发电是一体化规划。前者是“我们支持了 AI”后者是“我们本身就是为 AI 设计的基础设施”。那 ODPS 的 AI 原生具体可能体现在哪些层面从我掌握的信息和 MaxCompute 既有技术积累来看至少有三层不能只当营销词看。2.2 引擎级原生算子、函数与 GPU 调度的统一第一层是引擎内部的 AI 算子原生支持。过去在 MaxCompute 里跑一个机器学习任务标准姿势是用 PyODPS 写 Python UDF或者把数据导出再交给 PAI 平台训练。这种方式能用但数据搬运成本高、链路长、迭代慢。升级后的引擎如果能把 Embedding 批量生成、向量相似度计算、特征转换这样的操作变成 SQL 中的一等表达式开发效率会有数量级的提升。我举个例子假设一段升级后的 SQL 长这样-- 对商品图片批量生成 Embedding并存入向量字段 CREATE TABLE product_vector AS SELECT product_id, img2vec(product_main_image) AS image_embedding -- 引擎内置 AI 算子 FROM product_catalog;这类写法在传统数仓里不可能出现因为它要求引擎能调度 GPU 或异构算力并且把 AI 推理当作可下推的算子。据我所知MaxCompute 之前的几次更新已经在做资源调度的多元化当时更多面向 CPU 密集的 SQL 跑批。这次强调“AI 原生”合理的推测是把 GPU、NPU 的资源调度直接纳入统一执行引擎让 SQL 跑批和模型推理可以在同一个作业图里混合执行。这样一来对一线开发者的直观影响是过去“特征工程 向量化 入库 检索”是四条分开的流水线现在可以合并成一条数据管道。变量变少了出问题的机会自然变少。2.3 数据侧的 AI 能力特征、推理、评估都在数据管道内完成第二层更隐蔽但在我看来价值更大就是 AI 链路中的数据闭环。不仅是做推理还包括数据标注、模型评估、数据回流。模型训练需要高质量的标注数据。传统做法是标注任务走专门的标注平台标注结果再导回数据平台中间需要人工对账。AI 原生的数据基础设施理论上可以把“数据打标—训练样本—模型推理—评估回流”都跑在同一套引擎上。标注结果本身就是一种数据形式可以直接 JOIN 原始样本模型评估指标也可以作为 SQL 聚合算子直接计算推理输出回流后又能直接进入下一轮特征工程。我见过太多团队在模型迭代效率上栽跟头问题几乎都出在数据环节训练样本版本和特征版本对不上、评估数据分布漂移没人发现、新采集的样本入库链路要等两三天。ODPS 往这个方向升级如果能让数据侧和模型侧共享同一份数据底座这些工程难题至少能被制度化地缓解而不是每次依赖个别工程师的“手艺”。2.4 一个容易误读的点AI 原生不等于内置大模型这里我想特别提醒一点“AI 原生”不代表 ODPS 会变成一个聊天机器人平台也不代表未来你会直接在 ODPS 里向大模型提问。从技术体系来看ODPS 的核心角色依然是“数据基础设施”它的 AI 原生更多指的是引擎对 AI 工作负载的原生亲和性而不是产品形态转向。实际上我更建议把 ODPS 升级后的定位想象成“一个认识 AI、理解向量、能调度异构算力的数据操作系统”而大模型本身可能是外面的服务也可能是引擎内部的一个算子组件。这一点理解准确了你部署自己的业务架构时才不会迷路。3. “全模态”从概念到落地一个数据对象的跨模态旅程3.1 全模态不等于多格式统一类型系统是关键很多人听到“全模态”觉得这是互联网黑话但实际上这个概念在数据库领域有非常具体的技术落点。全模态并不等于“系统支持 txt、jpg、mp4、wav 这些文件格式”因为支持文件格式只是存储问题而全模态要求的是“计算语义的统一”。传统关系型数据库用类型系统来定义计算语义你看到 “STRING” 就知道可以匹配、拼接、求长度看到 “DECIMAL” 就知道可以做加减乘除和聚合。类型就是计算能力的契约。如果 ODPS 要打造全模态基础设施它需要定义一套新的数据契约让图像、视频、音频、时序流也成为有明确计算语义的类型。举个例子“图像”类型除了支持存取还能支持什么计算至少可以做相似度检索、视觉特征抽取、图像质量打分。“视频”类型除了存储还要支持帧抽取、片段对齐、镜头分割。这些能力的背后不是 Hive 式的大字段存储而是一整套从存储格式到算子库的全链路重构。我判断这会是一个渐进式落地过程不太可能一次性把所有模态的计算语义都做完整。大概率会先从图像和文本向量入手因为这两个应用最广、技术最成熟然后逐步扩展到音视频和时序数据。企业切换的时候也可以按这个节奏来规划自己的数据资产迁移。3.2 非结构化数据的统一计算语义一扇被打开的门如果统一类型系统是“全模态”的地基那统一计算语义就是这座新建筑里最让开发者震撼的部分。先看一个概念性的例子假设我们要找出所有与某个商品描述片段语义相似的商品图片用传统 SQL 几乎无从下手但全模态数据基础设施可以写成-- 在统一 SQL 语义下完成跨模态相似度查询 SELECT p.product_id, p.product_image, cosine_similarity( text_embedding(无线降噪耳机续航二十小时), image_embedding(p.product_image) ) AS similarity_score FROM product_catalog p ORDER BY similarity_score DESC LIMIT 20;这一段 SQL 把文本向量化和图像向量化都变成了引擎可解释的算子跨模态的相似度计算直接在查询语句中完成。这种能力听上去很“未来”但它实际上就是全模态基础设施的目标让非结构化数据之间产生可计算、可比较、可 JOIN 的语义关系。再深一层多模态 JOIN 也会成为可能。过去 JOIN 两张表依赖外键或业务键未来可以按语义相似度 JOIN比如把用户评价里的图片与商品库里的图片按视觉相似度关联从而自动找到“消费者拍的照片到底对应哪个在售商品”。这类场景是电商、内容平台、智能制造的刚需但过去一直苦于没有平台级支撑。3.3 元数据与语义目录让 AI 能找到“值得学习的数据”全模态数据如果只是一堆能计算的对象没有一套足够聪明的元数据体系最终只会退化成“数据沼泽”。ODPS 升级里特别值得关注的一点是语义目录和数据资产管理的强化。我在之前的工作中有一个痛点数据平台里存了几百 TB 数据但算法团队根本不知道有哪些数据可以用。数据团队维护的数据目录通常是人工填的字段说明和业务分类颗粒度粗、更新滞后。AI 原生的全模态基础设施理论上可以自动完成更细粒度的语义标注——图片的主题、视频的场景、音频的情绪、文本的观点这些元数据由引擎在入库时自动生成并且统一登记到数据资产目录里。当数据资产目录具备语义级检索能力后算法同学找训练数据的方式也会发生改变不是说“帮我查一下 user 表里的 merchant_id”而是“找所有包含户外露营场景的图片以及过去三个月在这类图片下产生的用户评论”。这个转变的意义在于数据不再是只能按定义访问的表而是可以按语义被发现的资产。对于数据治理而言语义目录还能带来一个意外的好处隐私和合规控制可以做在更细的粒度上。比如系统知道某一段视频包含人脸信息就可以在权限策略中自动标注“仅脱敏后可访问”而不是靠人工打标签。4. 基础设施层面那些看不见却决定成败的改动4.1 存储从列存到一键向量化的演进ODPS 的存储体系一直是它的核心竞争力之一大规模列式存储加高压缩比让它的存储成本远低于不少开源方案。但在 AI 场景下存储的结构需要增加一个新维度——向量化。向量存储不是简单地存个数组而是要支持高效的相似度检索和近邻查询。传统列存索引按字段值组织数据向量场景需要的则是一种高维空间中的近邻索引。对于 ODPS 这样一个处理 PB 级数据的平台向量索引的构建和更新成本必须可控同时还要保证和原有行列数据的关联查询效率。我认为这轮升级大概率会采用“列存原生 向量索引分层”的方案对于规模较小的向量集合可以在原列存之上直接叠加向量索引对于海量向量则自动布构成分布式向量索引与主存数据保持一致性和事务语义。这不是一个“可选插件”而是存储引擎级别的改动。另外“一键向量化”是我对一个具体体验的期待。数据进入 ODPS 后用户指定一个文本字段或图片字段系统自动完成 Embedding、建立索引、纳入语义检索范围而不是用户自己去调模型服务。如果这个能力做得足够顺滑它能让大量没有专职算法工程师的企业直接受益。4.2 弹性资源与调度GPU 和 CPU 在同一个 QuotaGroup 里混部资源调度是我作为实际使用者最关注的部分因为它直接决定成本体验。MaxCompute 的 QuotaGroup 机制配额组一直是控制计算成本的核心工具不同部门、不同项目可以分配不同的计算配额避免互相抢资源。但在 AI 工作负载加入到引擎之后资源调度的复杂度上了一个台阶。模型推理对 GPU 资源的需求是突发的、碎片化的SQL 跑批则往往是周期性的、可预测的。如果两套资源池完全隔离就会出现一种尴尬局面白天 SQL 跑批高峰GPU 闲置晚上推理任务堆积CPU 跑批早就结束了。更好的做法是在一套资源池里做混部按任务类型动态调度。ODPS 全面升级里如果能把 CPU/GPU 资源统一抽象、统一计量、统一配额管理对企业用户来说意义很大。意味着后续跑 AI 特征任务可以和跑 SQL 一样在同一个平台看到成本核算不用再跨两个团队审批预算。这也是我对“AI 原生大数据基础设施”的一种最实在的理解——不是技术炫技而是让资源使用逻辑统一。4.3 数据治理与安全隐私计算不再只是“合规动作”多模态数据天然比纯结构化数据更容易触及隐私。一张图片泄露的信息量可能大于一张表的十几个字段一段录音包含的生物特征信息更是敏感资产。因此AI 原生的数据基础设施必须把安全能力内生到存储和计算里。我预期升级会重点强化几个能力一是全链路加密和脱敏尤其是面向媒体文件的细粒度脱敏例如自动识别图片中的人脸、车牌、文本区域并做处理二是安全计算能力让模型训练或推理可以在数据不出域的前提下进行三是数据血缘的自动构建对多模态数据从原始样本到特征到模型输出的完整链路做追踪。讲到数据血缘这是 AI 场景下最容易乱的地方。基础模型微调用了哪一批样本评估结果为什么在某个版本之后出现暴跌这些都需要靠血缘和数据版本管理来回答。传统数仓血缘只覆盖表到表升级后如果能覆盖“原始媒体文件—切分片段—Embedding—训练集—模型版本—评估报告”这一整条链那数据治理才算真正跟上了 AI 时代的节奏。这里面还有一层容易被忽略的治理价值数据质量监控。多模态数据的质量很难用空值率、唯一性这种传统规则衡量更需要依赖语义质量指标比如图片清晰度分布、语音信噪比、文本长度和主题分布。引擎如果能主动计算并监控这些指标对保障模型训练效果极为关键。5. 对存量用户而言迁移路径与兼容性思考5.1 兼容性策略SQL、函数、UDF 的平滑过渡我对 ODPS 过去几年每次重大升级最关注的永远是同一件事我们跑了好几年的 SQL 要不要改自定义函数还能不能用好消息是从 MaxCompute 品牌成立至今阿里云在 SQL 兼容性上做过大量工作主流的 Hive SQL、Spark SQL 语法基本都能在它上面直接跑。ODPS 这轮升级延续这一策略是大概率事件。对于数以万计的存量数仓任务来说最理想的状态是引擎升级对用户透明SQL 照跑跑批照常新能力作为增量出现。但这不意味着什么都不用做。在兼容的基础上一些历史 SQL 会错失新能力带来的性能红利。比如涉及多模态数据的表如果还是按旧的二进制大对象方式存储查询效率就不会有本质提升。所以对开发团队来说合理的动作是核心链路先确保兼容稳定非核心场景逐步用新类型、新算子重写梯次切换。5.2 迁移不是搬家语义层重建的成本容易被低估很多团队对迁移的理解是“把数据搬过去就完事”这个想法在传统数仓迁移中已经吃过亏在全模态升级场景下会更加吃亏。数据搬过去只是第一步真正的成本在语义层重建。结构化数据迁移时你要重新定义表结构、分区策略、命名规范、指标口径。而 AI 原生全模态场景下还要额外做向量化、语义建模、标签体系重建。比如原来存了一堆商品图片路径现在要把图片内容本身纳入分析体系这需要批量生成 Embedding、建立语义索引、把“图片主题”这一类新的元数据字段设计清楚再把它和已有的订单表、用户表关联起来。这块工作的颗粒度比传统 ETL 细得多而且需要数据工程师和算法工程师一起设计纯靠数据团队很难独立完成。我见过不少团队低估这一步结果“搬了三个月数据、花了半年对不上语义”。所以在规划升级时我强烈建议把语义层重建作为独立工作包立项而不是混在存储迁移里顺带处理。5.3 成本模型的变化成本视角从“行数”变成“Token/向量/算力”成本是每个数据团队负责人最终都要回答的问题。传统 ODPS/MaxCompute 的成本核算模型相对好理解——基于计算量CU和存储量计费跑一个 SQL、扫描多少数据大致能估算出账单。但引入 AI 工作负载后成本维度会明显增加。我来尝试列一下新的成本构成供大家在预算规划时参考成本维度传统数仓负载AI 原生负载计算CPU 时间、扫描数据量CPU GPU 时间、推理次数存储列存数据量、冷热分层列存 向量索引 原始媒体文件加工ETL 任务复杂度Embedding 生成、模型推理、语义索引构建治理质量监控、血缘、权限语义标注、敏感内容识别、推理审计举例说明一个每天新增 10 万张商品图片的电商场景传统成本可能主要集中在将这些图片的路径和标签清洗入库AI 原生场景则需要为每张图片生成 Embedding涉及视觉模型推理、构建向量索引涉及索引存储和更新还要定期做语义标签校验。单位成本会比传统处理高但换来的是搜索结果、推荐效果、运营分析上的质的提升。我认为比较务实的做法是在迁移前期做一个“按业务价值计算的增量成本”测试挑一个明确的业务场景对比新旧链路的总拥有成本不只是看数据平台的账单还要算节省的人力成本、缩短的迭代周期、提升的业务转化。如果只盯着平台账单很容易得出“新方案太贵”的结论而忽略了它省下的隐性成本。6. 给数据团队的几点行动建议6.1 别急着重写架构先把多模态资产盘点清楚听完发布会我第一时间在朋友圈发了一句话“大词越多越要先做摸底。”全模态升级听起来宏大但你自己的数据现状并不会因为发布会开完就自动改变。我建议每个数据团队在接下来一到两个季度内先做一次多模态数据资产盘点当前有多少图片、音视频、非结构化文本散落在各个系统里它们存放在哪由哪个业务系统产生有没有被索引或标注过管理层是否知道这些数据的存在这份盘点不需要基于 ODPS 的新功能用一张 Excel 就能起步但它会成为后续判断“要不要迁移、先迁移哪部分”的重要依据。我自己过去的经验是很多团队数据湖里堆着大量从未被消费过的图片和音视频这些数据看似垃圾实则是 AI 时代的富矿。只有盘点清楚才能在 ODPS 新能力开放时快速找到第一批落地场景。6.2 用三个“小实验”验证新能力的成熟度等待大版本完全稳定再入场从来不是最优策略。我通常的做法是选定三条非核心链路用最小成本尝试新能力验证成熟度后再决定是否扩大范围。对于 ODPS 的“AI 原生 全模态”升级我会优先做三个实验挑一张千万级行数的商品表用升级后的引擎把主图字段批量转成向量测试 SQL 内推理的性能、成本和正确性并与外部向量库方案做对比。挑一个具体的业务查询写成跨模态 SQL例如“找出与给定描述最像的商品图片”验证语法、算子和结果质量。对一段真实业务音频或视频做切分、转写、语义标注验证数据治理链路血缘、权限、脱敏是否完善。这三个实验做完基本就能判断这套新基础设施是否成熟、谁负责落地、需要补什么能力。即便结论是“还不够好”你手里也有一份真实的测试数据后续和产品团队对话时非常有底气。6.3 人才结构数仓团队需要补充 AI 工程能力最后说一个比较得罪人、但必须讲的话题。ODPS 全面升级后数据团队的人才结构会发生变化。过去数仓团队的核心技能是 SQL、建模、调度、数据治理这些依然重要但 AI 原生的数据平台要求团队里至少要有一部分人理解模型推理、Embedding、向量检索、提示词工程这些概念。不需要人人都会训练大模型但至少要有人能回答这些问题这个字段适不适合用某个 Embedding 模型处理向量化后应该用哪种距离度量和索引模型输出的置信度如何在数据管道中做质量门禁这些问题现在看起来边缘再过两三年可能会变成数据团队的日常。我的经验是不用大规模招人先在现有团队里选出对新技术敏感的一两个人做“种子”让他们深度参与 ODPS 新能力的试用再由他们向全团队输出经验和方法。这种内部培养比外招空降更稳妥也更符合数据团队重实战、重业务理解的特性。说到底数据工程师的核心竞争力从来不在于会用什么特定平台而在于能不能在平台快速迭代时第一时间把新能力转化为业务解决方案。ODPS 这轮升级窗口期恰恰是拉开团队差距的时候。个人体会放在最后我从 MaxCompute 还是 ODPS 这个名字的时代就开始用这套系统早年写 PyODPS 脚本跑特征第二天凌晨盯调度日志这些经历让我对新版本的态度一向是“先别吹跑个真实任务看看”。这次看到“AI 原生的全模态大数据基础设施”的提法我心里其实挺高兴的——数据平台终于要把 AI 当自己人而不是当外部访客了。如果你和我一样既要对老板解释预算又要在凌晨两点起来救急跑批任务我的建议很朴素别被大词吓到也别被大词忽悠。把“AI 原生”理解成引擎终于能听懂模型的语言把“全模态”理解成图片视频终于能像表格一样被查询然后回到你最熟悉的那个业务场景让它跑一遍。结果会告诉你这个故事到底值不值得跟。