1. 为什么说AI原生是大数据平台的必然转向而不是概念包装先说结论ODPS这次全面升级把AI原生和全模态同时放进标题里看起来像两个热词叠在一起实际上是在回答一个问题——当数据量和数据形态都发生变化时大数据平台的基础架构到底该怎么重构。过去十年大数据平台的核心逻辑可以用一句话概括把数据搬到计算附近然后用SQL去查询它。ODPS作为国内最典型的大数据底座之一支撑了海量离线批处理、实时计算、数据仓库建模这类经典场景。它的核心架构围绕存储—计算—调度三件事展开SQL是统一的交互语言。这套体系在结构化数据时代非常好用跑批任务稳定调度可靠成本也可控。但到了今天数据形态早已不是一张张规整的表。文本、图片、音频、视频、向量数据散落在不同系统里大模型训练和推理产生的数据流与传统ETL完全不同AI Agent在运行过程中还会持续产生对话、工具调用、中间推理结果这类新型数据。如果平台的核心仍然停留在以SQL为中心、以结构化为主的逻辑上那么AI应用需要的支撑就变成了一件很别扭的事——要靠外部组件补、要在链路里打补丁、要自己管理多套系统之间的数据流转。AI原生这个说法我理解的重点不在平台能跑AI任务而是平台从底子上就按AI负载的特征来设计。传统大数据平台是为批量扫描和聚合计算设计的AI负载的特色是高并发小请求、向量相似度检索、GPU算力调度、流式增量更新、非结构化数据的统一管理。这些负载特征用老架构硬跑不是跑不动而是每一层都要做额外的适配。比如向量检索在传统数仓里没有原生的索引和距离计算能力图像数据进了数仓也只能先转成二进制对象等要用的时候再去外部服务里取。这种适配不仅浪费研发精力还会在系统边界处反复出现性能损耗。全模态(All-Modal)这个关键词在存储层面意味着平台要能把结构化表、半结构化的JSON/日志、非结构化的文本与图片视频、以及AI时代的向量表示全部纳入统一的管理体系。不是每个模态单独建一套存储而是同一个存储底座、同一套元数据体系、同一套权限管控对不同的数据形态提供差异化的存取方式。对一个数据平台而言这其实是过去很多年没人敢做的事因为它牵扯到元数据模型的重构、存储引擎的底层调整、计算引擎的接入方式。但从数据治理的角度讲全模态又是非常自然的终局——企业不可能长期容忍结构化数据在数仓里、非结构化数据在对象存储里、向量数据在向量库里三套系统算力存储彼此隔离数据打通靠导出导入这种局面造成的隐性成本远大于账面上的组件费用。再往下拆一层ODPS的这次升级目标用户其实不只是技术团队而是所有在构建AI应用的数据团队。过去一个AI项目落地团队通常要维护至少三套基础设施——数据仓库管历史结构化数据、向量数据库管Embedding、对象存储管原始文件。三套系统的数据同步、权限一致性、监控告警都是问题。AI原生全模态的思路是把这三件事重新收拢到一个平台里对应用层提供统一的存储接口、统一的计算入口、统一的数据管理界面。这套逻辑对中小团队尤其有吸引力因为大部分团队根本没有足够的运维人力去管三套分布式系统。我自己的判断是这轮升级的核心难点不在于新功能多少而在于架构转换过程中的兼容性和平滑性。ODPS有大量的存量用户存量任务、存量表、存量权限体系一旦底层架构变化导致原有SQL行为改变用户代价是非常大的。因此全模态的引入应该是以新增能力的方式渐进展开——老的数据表继续用老的方式工作新的数据类型和新的计算形态以增量模式接入老用户不被迫迁移新用户可以按需使用新能力。这个思路在技术演进里是比较健康的。2. 从存储和计算分离到多模态统一底座底层架构到底变了什么2.1 存储层一个底座接管结构化、半结构化、非结构化与向量数据传统数仓的存储单元是表表的每一行有明确定义的列。但在全模态场景下数据这个概念需要重新定义。文本片段长度不一、图片没有天然的行列结构、向量数组动辄上千维这些数据如果强行塞进二维表结构要么大量使用JSON字段要么做成对象存储加外部索引后一种方式是当前主流AI应用的常见做法。ODPS在这次升级里做的事情我理解是把数据形态的差异下沉到存储引擎内部对外保留统一的命名空间和元数据视图。你可以继续像操作表一样操作数据对象但这张表里的字段可以是任意模态的引用。存储引擎自身至少需要解决三件事不同模态数据的物理布局、跨模态数据的关联关系、以及生命周期和版本管理。物理布局上结构化数据继续走列存压缩文本和图片可以走对象存储语义向量数据要以支持近邻检索的索引结构存放比如HNSW图索引或者IVF倒排。这些不同的存储引擎要共享同一套元数据服务这样才能实现一条SQL从结构化表里JOIN一个图片特征向量的操作。这个过程如果经历过从Hadoop到数据湖演进的人会很有感触。早期数据湖解决的是把各种文件统一放进一个存储池但缺乏表格式管理和事务能力后来湖仓一体引入了统一的表格式让非结构化文件也能获得类似表的治理能力。ODPS的全模态底座可以理解为这个方向的彻底形态——不只是文件级别的统一而是存储引擎、索引引擎、元数据服务的统一。2.2 元数据与权限全模态数据治理的真正难点一旦数据形态扩张元数据模型就必须跟着变化。传统元数据描述的是表有哪些字段、字段什么类型、谁可以访问全模态场景下的元数据要额外描述数据模态、Embedding模型、切分策略、向量索引配置、来源标注、许可证信息等。这些信息对于AI应用至关重要——模型训练数据能不能用、数据有没有敏感信息、数据切分粒度是否合理全部要能在元数据层回答。权限模型也要重做。结构化表的权限可以精细到列级图片和文本文件一样可以做到对象级但向量数据就比较微妙——Embedding本身是从原文提取的特征严格意义上不能被还原出原文但通过某些逆向方法可以部分逼近原始语义。这意味着向量数据即便看似脱敏了隐私风险依然存在。平台在权限策略上需要更谨慎的设计比如向量数据的访问控制要绑定其源数据的权限状态源数据被回收权限时派生向量也应该同步失效。这个设计在业界还没有统一标准ODPS如果能在平台层面原生支持数据血缘驱动的权限联动会是很有价值的能力。2.3 调度层面大数据任务与AI任务在资源编排上的冲突传统的ODPS调度以离线批处理为主任务按天/小时调度资源池稳定流量曲线可预测。但AI负载的资源使用模式完全不同——训练任务会持续占用GPU推理请求是突发型高并发小请求Embedding批量生成又需要海量短期算力。如果这些负载混在同一个调度器里很容易出现资源抢占批处理任务被推理高峰拖慢或者训练任务占用大量资源导致在线服务响应变差。合理的做法是引入弹性分区调度按任务类型划分资源域但允许域的边界动态伸缩。离线批处理任务可以被抢占到低峰期执行推理服务保证稳定的弹性资源水位训练任务使用专门的GPU资源池并且支持Checkpoint快速恢复。这套调度逻辑在互联网公司的内部实践里已经很常见但把它产品化到通用平台上需要做很多工程工作。ODPS这轮升级如果能把面向AI资源的调度能力做成标准功能对用户来说价值非常直接不需要自己构建混合资源调度层一个平台同时管理CPU和GPU资源的预算、优先级和配额。3. 计算引擎升级SQL、向量检索与机器学习的三位一体3.1 从SQL为主到SQL向量ML的统一计算语义ODPS这么多年积累下来最有价值的资产之一就是SQL引擎的成熟度和生态兼容性。用户习惯了用它来写ETL、做数仓建模、出报表。全模态升级并不意味着推翻SQL而是把SQL的能力边界向外扩展。一个重要变化是SQL可以直接表达向量操作。比如用户可以在SQL里声明一个字段是文本经过某个Embedding模型生成的向量然后对向量字段调用相似度搜索函数和结构化条件组合成一条完整的查询。这种能力让找相似商品检索相关文档这类需求可以用相对简洁的语法完成而不需要单独写一套向量检索服务的调用逻辑。具体到语法层平台需要提供类似VECTOR_EMBEDDING()、VECTOR_DISTANCE()这样的函数并且查询优化器要能识别这些操作将向量索引的候选集剪枝下推到存储层去执行避免全量暴力计算。另一个方向是机器学习能力的融合。传统大数据平台跑模型的方式是训练数据导出→外部训练→模型文件上传→批量推理链路长、中间环节多。全模态基础设施要做的是把训练和推理以更内聚的方式接入平台。比如平台能否在存储层直接读取分布式训练框架的数据输入训练完成后模型自动注册到平台的模型仓库推理时模型文件直接从平台加载而不需要额外的文件搬运。这些少一步的工程优化叠加在每天跑几十上百个任务的项目里节省的人力成本非常可观。3.2 批流一体与增量计算的升级压力AI场景有一个显著特点数据是不断流入的。用户行为日志在实时产生对话记录在持续追加文档库在不停更新对应的Embedding索引也需要保持新鲜度。传统大数据平台对增量的处理通常是T1级别的批量调度但AI应用通常需要分钟级甚至秒级的索引更新。这就要求计算引擎在底层具备流批统一的能力。ODPS在升级方向上需要做到的是同一份数据既可以按批方式做大规模回溯计算也可以按流方式持续消费并更新下游存储。Embedding生成的增量更新要能无缝写入向量索引而不是每次重建整个索引。系统要支持主键级别的更新/删除语义——某个文档被修改后旧的向量被标记失效新的向量写入索引并且这一过程用户无感知。这些能力对搜索引擎、推荐系统、智能客服这类高频更新场景是必须的。3.3 仿真推演向量任务下系统资源消耗的直观对比为了理解全模态带来的资源结构变化我经常在团队内部做一个小推演。假设一个文档型RAG应用需要支持100万条文档的语义检索每个文档被切分成平均5个片段每个片段Embedding为768维向量向量数据总量大概是100万×5×768×4字节≈15.36GB。如果采用HNSW索引加上索引膨胀系数约1.2大约需要18GB左右内存常驻。文档原文和切分后的文本存储在对象存储单日新增文档按1万条计算新增Embedding任务跑一次大约消耗一定的CPU/GPU资源增量索引更新耗时分钟级。把这一整套逻辑放进传统架构里团队需要自己部署一套向量数据库、写同步任务、维护索引重建脚本放进全模态数据平台里这些流程在平台层面被统一编排——文档进入存储触发切分切分触发EmbeddingEmbedding写入向量索引索引随权限和血缘自动管理。整个链路不需要额外开发和运维。这个差异对中小团队来说是非常现实的一个是引入新组件专职运维一个是平台功能开通即用。4. 开发者视角的变化数据工程师要怎么调整自己的技术栈4.1 技能结构从SQL优化向SQL模型数据链路复合演进ODPS全面升级之后受影响最大的其实是存量数据工程师。过去一个优秀的数据工程师的核心竞争力在于复杂SQL写得好、任务调度调得顺、数据质量把控稳、数仓分层设计清晰。这些能力不会失去价值但需要在新架构上生长出新的枝杈。全模态平台上的数据工程师至少要开始接触向量和模型这两个过去认为不属于数仓范畴的东西。具体来说你要理解一个文档是怎么被切分、怎么被Embedding的因为存储结构的设计直接决定检索效果你要会为向量索引选择合适的参数比如HNSW的M值和efConstruction值它们影响索引构建时间和召回率你要了解模型推理的批处理大小对算力利用率的影响这关系到调度配置的合理性。我个人的建议是还在岗的数据工程师不用慌也不用急着转型提示词工程师。这个方向真正的核心技能变化是你要能同时在数据的世界和模型的世界里建模。数据的世界关心准确性、一致性、血缘模型的世界关心向量的语义距离、上下文的召回质量。能把这两套思维在同一个平台上融合使用就是未来最稀缺的能力。4.2 开发模式AI辅助编程与自然语言交互在数据开发中的真实占比这轮升级的另一层变化是开发交互方式。ODPS面向的是数据开发场景SQL脚本和任务配置是日常开发的主要工作对象。过去写一个复杂的多阶段SQL脚本可能要反复调试现在有了AI辅助很多重复性的编码工作可以被自动完成。比如根据字段注释和表结构自动生成ETL模板、根据历史任务自动推荐调度参数、根据SQL执行计划自动提示优化项。但我要泼一点冷水AI辅助编程在数据开发里的占比会提升但不会替代人理解业务意图的过程。原因很简单SQL写出来容易难的是确认这到底是不是业务想要的那份数据。尤其是涉及多表关联、口径定义、异常处理时AI能帮你生成代码但代码背后的业务规则需要人来校验。所以我的态度是AI辅助开发要大胆用但每一个生成的任务都要当成新人写的代码去审——逻辑对不对、边界清不清楚、空值怎么处理、类型是否安全。自然语言交互在查询层面的应用也会变多。用户可以直接问上个月华东区的订单金额排行前20的商品有哪些平台自动生成查询计划并返回结果。这类功能在数据量可控、语义清晰的前提下效果很好但要小心语义歧义——金额是按成交额还是毛利上个月是自然月还是滚动30天这些口径问题如果用户没有在问题里明确AI猜错的概率不容低估。平台可以考虑通过追问确认机制来降低错误率这也应该是产品设计中的重点。5. 落地方案企业架构向AI原生数据平台演进的三个阶段5.1 第一阶段存量业务平滑运行新增AI场景孤岛试点任何迁移和升级最大的风险都是老业务被搞坏了。所以第一阶段的策略必须是存量不动增量先行。具体做法是原有结构化数仓继续在原架构上稳定运行所有报表、ETL、实时计算任务不受影响。新架构上选择1到2个AI场景做试点比如智能客服知识库或者文档检索系统。这一阶段的核心目标是验证平台能力跑通文档入库→文本切分→Embedding→向量索引→相似度检索→结果返回的完整链路。团队在这个阶段要特别关注几个数据点检索准确率是否达到业务预期、索引更新的时延是否满足数据保鲜需求、全模态存储的成本与原来对象存储向量库的组合相比差异有多大。这个阶段的坑主要在数据准备环节。很多团队低估了清洗文档的工作量——网络上抓取的原始文本有大量噪声HTML标签残留、乱码、重复段落、不同格式混排都会严重影响切分质量和Embedding效果。平台即使提供了全模态存储也不会替你完成数据清洗。这一环需要投入充分的精力。5.2 第二阶段数据资产通存通取跨模态应用规模化铺开试点验证之后第二阶段要做的核心事情是打通数据资产。企业里的文本数据可能分散在对象存储、文件服务器、业务数据库里结构化数据在数仓里图片在CDN里。全模态平台的统一元数据能力能给所有数据一个统一的访问入口和权限视图。跨模态应用在这个阶段可以规模化推进用全模态存储作为数据底座把各类业务数据汇聚进来支撑搜索增强、个性化推荐、内容审核、数字人交互等场景。团队需要重点建设的是数据血缘与治理规则——哪些数据可以被AI消费、跨部门的数据共享走什么审批流程、数据脱敏和权限联动策略如何落地。这些治理机制在试点阶段可能不觉得紧迫一旦规模化缺少治理会从麻烦变成事故。技术层面第二阶段的重点是把计算任务的编排做得更细。混合负载调度、GPU资源配额管理、任务优先级策略这些都需要有明确的规范。可以按业务线划分资源域核心AI服务域保证稳定的最低资源批处理任务在低峰期享受弹性资源避免互相影响。5.3 第三阶段AI应用与数据平台深度融合形成自演进闭环到了第三阶段数据平台和AI应用不再是平台供数据给应用而是形成了一个闭环AI应用消费平台的数据产生的分析结果和知识沉淀再写回平台成为新的数据资产。比如大模型微调产生的训练数据需要持续更新回数据平台线上推理的bad case需要回流到数据平台用于再训练报表需求从看数变成看结论由AI直接给出趋势分析和异动归因。这个阶段对平台的要求是最高的。数据回流要有清晰的血缘链路否则数据治理会乱成一锅粥模型生命周期管理和数据生命周期管理要统一视图一个版本的数据对应哪些模型的哪些版本训练要能可靠追踪成本和算力的优化要更加精细化哪些任务值得跑、哪些数据应该降冷、哪些索引应该重建都需要有数据支撑的决策机制。从ODPS的角度讲这轮AI原生全模态升级如果能把这套闭环能力做成产品化的形态而不仅仅是提供存储和计算能力它对这个时代的价值才会真正显现。平台竞争的终局不是比谁屯的算力多而是比谁能帮助用户以更高的效率把数据转化为AI时代的竞争壁垒。5.4 团队配置建议全模态平台对组织能力的新要求最后补充一个很多人忽视的点——平台升级之后团队的组织分工和技能矩阵需要同步调整。过去一个大数据团队由数仓工程师、数据开发、平台运维构成就够了全模态阶段团队里至少要有人懂向量检索的调优逻辑、有人理解Embedding模型的选择和切换、有人能规划多模态数据治理规则。换句话说数据团队的边界正在向数据AI基础设施方向扩展。比较务实的做法是分两个小组一个组专注存量数仓的稳定和优化维持基本盘另一个组专攻AI场景的落地负责算法模型与数据平台的衔接。两个组之间定期同步把AI侧沉淀的工程实践逐步反哺到存量架构的演进中去。这样做的好处是既不会让老业务没人管也不会让新方向缺乏推进力。企业在这个阶段的常见误区是等平台完全成熟再动手。但实际上全模态平台这类基础设施是在使用中成长的——通过真实的业务负载去暴露问题、迭代功能比闭门讨论理论上需要什么有效得多。任何平台都不是等齐了所有能力才值得用而是先用起来再在过程中看到它真正的上限和需要补的短板。