datainfra前沿动态 · Vol.76

阿里云 OpenLake 迈向 Agentic Lake 并发布 AI 原生大数据服务 ADA；新一代 CPFS 把模型启动耗时压掉一半，KVCacheStore 插进显存与共享存储之间；Delivery Hero 用托管 Flink 将广告测量从 61 分钟降到 1.2 秒；Databricks 让 open-Jev 决策模型直接跑在 SQL 里

本期聚焦四条落在 9 月 22 至 24 日的进展：2026 云栖大会上阿里云把 OpenLake 升级为 Agentic Lake，推出多智能体形态的 AI 原生大数据服务 ADA，并发布新一代全栈自研高性能存储 CPFS 与 KV Cache 加速引擎 KVCacheStore；Delivery Hero 借助 Amazon Managed Service for Apache Flink 重写实时广告测量，端到端延迟从 61 分钟降到 1.2 秒、月运营成本下降约 57%；Databricks 用 serverless GPU 加 ai_query 把开源决策模型接进受治理数据的 SQL 查询。

DataInfra 阿里云 OpenLake Agentic Lake ADA MaxCompute Hologres CPFS KVCacheStore Apache Flink Amazon Managed Service for Apache Flink 实时计算 Databricks ai_query Lakehouse AI 基础设施

本期四条里有三条来自 9 月 22 至 24 日举办的 2026 云栖大会，一条来自同一周的 AWS 与 Databricks。四条分属数据平台形态、AI 存储底座、实时广告测量与 SQL 内的模型调用，动作却指向同一件事：把过去要等的东西变成一直在线的东西。阿里云让 GPU 不再等数据，让 BI、向量库、流处理引擎在同一份数据上不必各存一份；Delivery Hero 让广告预算不再等一个小时的批处理窗口；Databricks 让模型输出不再等一次服务化改造。四处提速都附带了自己没做完的部分——0.8% 的客户 ID 仍然缺失、报表库仍是 5 分钟粒度、决策模型没有给出吞吐基准——这些残余比提速倍数更值得先读。

阿里云 OpenLake 升为 Agentic Lake，ADA 把多引擎收进一个对话入口

事件概述

9 月 22 日，2026 云栖大会技术主论坛上，阿里云副总裁、计算平台事业部负责人汪军华发表《数据·智能·进化：Agent 时代的数据与 AI 基础设施》主题演讲。他把数据、智能、Agent 描述成一个自我驱动的飞轮，并围绕「模型生产效率、智能落地效率、系统进化效率」给出一组产品升级。

这组升级的核心是把已经运营两年的 OpenLake 从「开放湖仓」推进到 Agentic Lake。按官方表述，OpenLake 以统一、实时的开放湖存储承载全模态数据，推动大数据、搜索与 AI 引擎跨引擎协同并做到智能体就绪；DataWorks 构建的跨引擎语义层负责把数据赋能给智能体服务。OpenLake 上的计算引擎同步完成 Agentic 化——各引擎不只围绕同一份数据工作，也把自身能力开放出来供 Agent 直接调用。

在此基础上，阿里云发布了 AI 原生大数据服务 ADA。这是一款智能体形态的产品，采用多智能体协同架构：用户在统一的对话入口用自然语言调用离线、实时、流式分析、AI 训推、搜索等不同计算引擎，由多个 Agent 协同完成数据分析、工程、治理、运维与数据科学等端到端任务。DataWorks Data Agent 则提供统一的数据开发、治理与任务编排能力，用户围绕业务目标提需求，由 DataWorks 组织处理流程、调用相应引擎完成计算。

技术解析

  • MaxCompute AI 计算引擎：CPU、GPU、大模型 Token 三类计算资源统一调度，MaxFrame 分布式 Python 引擎与 SQL AI Function 引擎深度集成 Qwen 旗舰模型能力，一行代码即可调用，实现全模态数据理解与计算处理。面向数据开发代码编写、自动驾驶、具身智能三类场景首次发布行业 Skill，一句自然语言即可搭建完整数据产线。
  • EMR Serverless Spark：支持 Spark / Ray / Daft 全模态引擎，原生对接 Paimon / Iceberg 湖表格式，配合 Serverless 秒级弹性架构，具身智能数据处理耗时减少 40%，PB 级原始采集数据可直接产出 LeRobot / RLDS 格式数据集。
  • EMR Serverless StarRocks：在极速 OLAP 能力上新增全文检索、向量检索与 KV 点查，多路召回写进同一条 SQL，做到「一份数据、一套引擎、一条查询」。
  • Flink Streaming Agent：支持全模态数据的变更接入与流式 AI 处理理解，提供 Agent OS 运行时能力，支持 Per-Record 动态编排与长中短期记忆。央视体育用其支撑赛事直播实时 AI 解说，Agent 结合画面、音频与事件实时理解赛况并生成同步解说。
  • Hologres 查询优化器自进化：官方给出的路径是 Workload 分析、候选集提炼、最小改动实现、沉淀进化、性能门禁、正确性门禁、持续反馈迭代，把调优从专家经验变成持续运行的工程闭环。实测数据为 4 个月内自主发现并完成 28 项优化点，优化器性能提升 100%，湖上查询性能提升 38%，Hologres 在 TPC-H 3000GB 规模测试中拿到性能与性价比双料第一。
  • PAI-CrystalLLM：高保真模型仿真训练引擎，用不到 1% 的 GPU 资源消耗 1:1 模拟万卡集群训练效果，阿里云内部实践带来训练任务 2% 至 10% 的 MFU 绝对提升，相关论文已被 SOSP’26 接收。
  • 客户侧量化：义乌小商品城用 MaxCompute AI Function 做海量商品图片理解，每日处理量超 100 万张，较自建方案性能翻倍；穹彻智能基于 MaxCompute、Hologres、DataWorks 与 PAI 搭建 Umi Data + AI Pipeline，整体吞吐提升超 10 倍，模型训练效率提升约 50%。

行业影响

真正值得注意的不是 ADA 这个新产品本身，而是「跨引擎语义层」这个位置被单独拎了出来。过去让 BI 工具、向量库、图引擎和实时流处理共用一份数据，靠的是每一方各自实现一遍连接器与元数据解析；DataWorks 把这个翻译层收成平台能力之后，新引擎接入的成本从「实现一套适配」降到「接一份语义」。代价是语义层的表达力成为上限——凡是语义层没法描述的计算，仍然要回到某个具体引擎上手工处理。

Hologres 那条线更值得看。查询优化器历来是「英雄淘金」式的专家经验活，难复制也跟不上负载变化；把它改成带门禁的持续闭环，等于承认优化是一个永远在跑的过程而不是一次发版。4 个月 28 项、性能提升 100% 这个数字需要打折看待——它反映的是存量欠账被集中偿还，而不是长期可持续的增速，读者更该关注的是它把性能门禁和正确性门禁写进了流程。

相关链接

新一代 CPFS 商业化，KVCacheStore 插进显存与共享存储之间

事件概述

同一场大会上，阿里云发布面向下一代 AI 训练集群的新一代全栈自研高性能存储 CPFS（Cloud Parallel File Storage），并同步推出面向大模型推理的 KV Cache 加速引擎 KVCacheStore 与大模型 KV Cache 管理调度系统 Tair KVCM。存储产品负责人蒋江伟把这次更新概括为围绕 Token 生产和缓存调用所做的极致优化。

CPFS 给出的规格是百 TB/s 级吞吐与亿级 IOPS，单文件系统规模提升 5 倍至 100PiB。官方同时披露，新一代 CPFS 的元数据性能提升 10 倍、文件数量规模提升 100 倍，单文件系统可承载万亿级文件。在 Qwen 大模型训练实测中，模型启动平均耗时降低 50%，峰值算力利用率提升 30%，AI 存储成本降低 69%，业务承载能力翻倍。

技术解析

  • 分离式架构：数据服务与元数据服务分离，实现容量与性能的水平扩展。GPU、CPU 节点通过 EFC 弹性客户端和虚拟存储通道接入分布式元数据与数据服务，结合飞天盘古的分布式持久化存储底座与高性能存储网络，形成从客户端、协议处理到数据落盘的全链路自研链路。
  • 针对的瓶颈：大模型训练的数据集从文本扩展到图片、视频、语音后规模可增长 50 倍甚至百倍，模型参数规模增长约 10 倍，Checkpoint 保存更频繁。海量小文件并发读取与 Checkpoint 突发写入成为新瓶颈，存储跟不上就会让 GPU 集群空转。
  • 冷热分层：智能生命周期管理让不同访问频率的数据自动匹配合适介质，官方口径是整体存储成本最高降低 69%。
  • 统一命名空间：训练语料、模型参数、Checkpoint 与实验结果可在同一文件系统中管理，不必为不同训练阶段反复拆分或迁移数据，容量与吞吐随 GPU 集群同步扩展。
  • KVCacheStore 的层级定位：它位于 GPU 显存、主机内存与远端共享存储之间，是基于近计算部署、高性能网络和弹性共享存储构建的新型 G3.5 存储层，以「存储换计算」承接长上下文、多轮对话和复杂 Agent 任务产生的缓存。
  • KVCacheStore 规格：支持与算力亲和部署，单计算节点吞吐达 40GB/s，通过 Batch 接口实现百万 QPS，单实例可满足千亿级 KV 存储规模，实测缓存命中率提升 20% 以上。

行业影响

把这两款产品放在一起看，阿里云在存储上做的是同一件事的两头：CPFS 解决训练侧「数据进不去加速器」，KVCacheStore 解决推理侧「算过的结果留不下来」。前者把容量与元数据性能做成可水平扩展的两条独立轴，后者在显存与远端存储之间插入一层新的持久化位置。

对数据基建从业者的实际意义在于，AI 负载正在把存储层次从「热/温/冷」三段推向更细的分层，而且每一层的判定标准不再是访问频率，而是「离算力多远」。KVCacheStore 被称为 G3.5 层就是这个思路的直接体现。需要注意的是，69% 与 50% 这类数字来自厂商自测且口径是「最高」「平均」，跨厂商可比性有限。

相关链接

事件概述

AWS Big Data Blog 于 9 月 24 日刊出 Delivery Hero 的迁移案例。这家总部位于柏林、业务覆盖约 65 个国家、合作超过 150 万家商户的公司，2025 年广告收入接近 15 亿欧元，广告平台每日处理数十亿广告事件、每秒数万条消息。其广告测量系统原先是小时级批处理，事件从发生到被记录平均间隔 61 分钟，无法支撑预算控制与实时投放决策。

改造后的系统以 Amazon Managed Service for Apache Flink 为核心，配 Kinesis Data Streams 摄入、DynamoDB 异步富化、RocksDB 大状态与 S3 增量 checkpoint。结果是端到端延迟从 61 分钟降到 1.2 秒，月度运营成本下降约 57%，峰值维持 20,000 条/秒吞吐。

技术解析

  • 旧架构的三条硬伤：按处理时间而非事件时间分桶，摄入延迟或乱序时结果偏斜；富化靠每个事件触发一串阻塞式外部 API 调用，高峰时连接池耗尽并级联影响计费、投放与报表，且没有背压机制；去重键、归因历史与滚动汇总压在一套继承自前流处理时代的 NoSQL 文档数据库上，每个事件触发完整文档读写，造成读写放大，峰值负载时常导致生产中断。
  • 数据质量基线：缺失会话率 30–40%，缺失客户 ID 5%，缺失 impression 时间戳 91%——正因为多数 impression 没有可靠事件时间，系统才被迫用处理时间近似。
  • 重放是项目不是能力：计费重放需要手工组合 BigQuery 表、Pub/Sub 主题与自定义 CLI 脚本；报表重放是一套独立每日 Airflow 作业，每天耗时 1 小时、回溯窗口 6 个月；campaigns 与 credits 事件完全没有重放路径。
  • 摄入链路：两个 SNS 主题分别接收用户事件动作（压缩加密的广告 token，内含 campaign、vendor、placement 元数据）与订单事件，经 SQS 缓冲后送入 Kinesis。MVP 阶段用 EventBridge Pipes 无代码桥接 SQS 到 Kinesis，省下约两周上线时间；生产环境换成 Fargate 转发服务。解密密钥存于 Secrets Manager，作业启动时取一次。
  • Flink 五阶段流水线：解压解密 → 去重（按 entity、ad、event、customer 复合键 keyed，RocksDB 跟踪 30 小时窗口内已见事件，约 20GB 状态，重复事件落 S3 供审计）→ 富化（Async I/O 并发查 DynamoDB，DynamoDB 由 Fargate 消费者持续从上游 Kafka 主题写入）→ 归因（多日 keyed interval join，按 entity、customer、vendor、campaign 维度匹配用户事件动作与后续订单，约 100GB 状态）→ 聚合（RocksDB 中累计指标，每 5 分钟批量 upsert 到报表数据库）。
  • 有效精确一次：Kinesis 与上游是 at-least-once，去重阶段会丢弃恢复期间重放的事件，计费因此达到 effectively exactly-once。所有状态通过增量 checkpoint 写入 S3，原始事件以 Avro 格式落地 S3，Kinesis 源流保留 7 天。
  • 选型取舍：摄入层选 Kinesis 而非 MSK，理由是该拓扑下成本更优；计算层选托管 Flink 而非 EKS 自管，理由是自管 JobManager / TaskManager 与 checkpoint 存储的运维负担。
  • 改造后的数据质量：缺失会话率降到 0%，缺失客户 ID 降到 0.8%，缺失 impression 时间戳降到 0.2%。

行业影响

这个案例最有价值的部分不是 61 分钟到 1.2 秒的倍数，而是它把「实时化」拆成了三件可以分别验收的事：事件时间语义替换处理时间、阻塞富化替换成 Async I/O、工作数据集从文档库搬到 RocksDB keyed state。三件事各自对应一类故障——窗口偏斜、连接池耗尽、读写放大——也各自对应一个可度量的前后对比。

0.8% 与 0.2% 的残余同样值得记下来。会话匹配做到 100% 之后，剩下的问题落在客户 ID 与 impression 时间戳这类上游埋点字段上，实时化解决不了埋点缺失。另外，真正秒级的信号走的是 Kafka 计费事件，报表数据库仍是 5 分钟批量 upsert，亚秒级预算 pacing 被明确列为下一步而非已完成项。

相关链接

Databricks 把 open-Jev 决策模型直接跑进 SQL

事件概述

Databricks 于 9 月 24 日发布一篇工程博客，介绍如何用 serverless GPU 加 ai_query，把开源权重的决策模型直接跑在受治理的 Databricks 数据上。

文中提到的背景是一类被称为「System One」的决策模型近期的出现，它们能从一组离散选项中产出经过校准的决策，速度极快且成本低，适合在大规模数据上应用。开源社区已经给出若干开放权重版本，博客点名 Smelf-open-jev、Laya、Kev 等，并以 SemIf-OpenJev 为例演示酒店评论的好评/差评分类。

技术解析

  • 三步起步：选模型名与 schema、选择 Serverless GPU、点击 Run All。配套 notebook 由 Databricks AI Runtime 提供按需 GPU 算力，随后下载 SemIf-OpenJev 模型文件，用 Express Deployments 记录并注册模型，并自动创建 GPU Model Serving endpoint。
  • 不必伪装成 chat-completions：ai_query 支持任意自定义模型 API，可以直接从 SQL 发送 SemIf 的结构化请求格式，端点无需暴露标准 chat-completions 接口。
  • 结构化返回：请求体用 named_struct 传入 id、state、question 与 options（每个 option 带 id 与 description），returnType 声明为 STRUCT<id: STRING, choice: STRING, options: ARRAY<STRUCT<id: STRING, probability: DOUBLE>>>，返回选中项与各选项概率，作为结构化列落在结果表里。
  • 落点在生产链路：同一调用既能从 SQL console 发起，也能放进 Lakeflow 作业；AI Runtime 允许对这些模型做定制或后训练以适配企业场景。
  • 局限：博客是示例性质，没有给出吞吐、延迟或单位成本基准；实际吞吐受 serverless GPU 配额约束；输出结果的质量高度依赖 options 里描述文字的写法，description 写得含糊会直接影响概率校准。

行业影响

这一条的信号在于「推理调用的形状」正在收敛成 SQL 里的一列。过去要在数仓数据上跑模型，通常是导出样本、在外部服务上推理、再把结果写回，中间多一次数据移动和一份需要单独治理的结果表；ai_query 把这一步折叠成一个表达式，权限、血缘与审计都沿用原有表。

折叠之后新增的风险是口径：模型版本、options 描述、GPU 配额任何一个变化都会改变同一段 SQL 的输出，而这些变化发生在 SQL 文本之外。对习惯了「SQL 是确定性」的数据团队来说，这需要在血缘与变更记录里补上模型侧的版本维度。

相关链接

编者评

本期四条都在缩短「数据到决策」的距离，手法却分成两路。阿里云与 Databricks 走的是加一层：跨引擎语义层、G3.5 缓存层、ai_query 表达式层，每一层都让上层少做一次适配或多复用一次结果。Delivery Hero 走的是拆一层：把同步富化拆成 Async I/O，把文档库里的读写放大拆成 RocksDB keyed state，把「重放一个项目」拆成 Avro 原始日志加增量 checkpoint。加层的收益是复用，代价是新层自己的表达力成为天花板；拆层的收益是可分别验收，代价是边界处会留下必须单独治理的东西——报表库仍是 5 分钟粒度，0.8% 的客户 ID 依旧缺失。

对数据基建从业者来说，评估这类公告时更该看它把复杂度挪到了哪里，而不是看倍数。CPFS 把容量与元数据性能拆成两条可独立扩展的轴，就比单纯报出的 100PiB 更能说明架构选择；Hologres 把性能门禁和正确性门禁写进优化闭环，就比 100% 这个数字更能说明它准备长期运行。本期三条来自同一场大会，覆盖范围难免偏重阿里云一家，AWS 与 Databricks 两条提供了不同厂商的对照；Flink、Iceberg、Trino、dbt、DuckDB、LanceDB、Delta Lake 等侧本窗口无值得单列的发布，火山引擎公开文档与开发者社区在 9 月 22 至 25 日亦未检索到匹配的产品更新。