datainfra前沿动态 · Vol.8

华为发布AI DC全栈方案——业界首个异构算力CMS将KV Cache推入PB级共享时代；Databricks Catalog Commits GA让Unity Catalog成为湖仓事务协调者；Databricks Runtime 18.2 GA与Lakeflow Designer用户定义算子开启可视化管道可扩展时代

第八期聚焦DataInfra三条动态：华为5月21日在巴黎IDI论坛发布AI DC数据基础设施全栈方案——业界首个支持异构算力的上下文记忆存储CMS可扩展为PB级共享KV Cache池，TTFT降低90%；首创3+1 AI数据平台集成KV Cache加速+95%检索精度知识库+持续进化记忆库+UCM统一调度，推理准确度提升30%；OceanStor Pacific 2U空间11PB高密度存储；ModelEngine Nexent自然语言生成Agent上线周期缩短80%；Databricks 5月8日Catalog Commits GA——Unity Catalog从元数据目录升级为表状态协调者，实现多表跨表事务、外部引擎安全写入、元数据延迟消除；Databricks Runtime 18.2 GA搭载Spark 4.1正式版，Lakeflow Pipelines Editor GA提供代理优先的管道开发体验，Lakeflow Designer默认启用并新增用户定义算子Public Preview

DataInfra 华为 AI DC CMS KV Cache OceanStor Pacific ModelEngine Nexent Databricks Catalog Commits Unity Catalog 多表事务 Lakeflow Runtime 18.2 Spark 4.1 Designer 用户定义算子

第八期追踪到DataInfra领域三条重要动态：华为5月21日在巴黎创新数据基础设施论坛发布AI DC数据基础设施全栈方案——这是首个从数据湖到Agent框架的AI数据中心完整基础设施栈，业界首个支持异构算力的上下文记忆存储（CMS）将KV Cache从单GPU缓存推入PB级共享池时代，TTFT降低90%；3+1 AI数据平台将KV Cache加速、95%检索精度知识库、持续进化记忆库和UCM统一调度整合为推理效率闭环，推理准确度提升30%；Databricks 5月8日Catalog Commits正式GA——Unity Catalog从”元数据目录”升级为”表状态协调者”，事务协调从文件系统上移到目录层，首次实现跨多表原子事务，外部引擎（Spark/DuckDB/Flink/Starburst）可安全写入Unity Catalog管理表，元数据延迟因跳过云存储直读而消除；Databricks Runtime 18.2正式GA搭载Spark 4.1稳定版，Lakeflow Pipelines Editor正式GA提供代理优先（Genie Code）的管道开发体验，Lakeflow Designer默认启用并新增用户定义算子Public Preview（uc-udf/uc-udtf/python-run-function三种类型）——可视化数据准备从”有限算子”进入”无限扩展”时代。

华为AI DC全栈方案：从数据湖到Agent框架的AI基础设施系统化构建

事件概述

5月21日，华为在巴黎创新数据基础设施论坛（IDI Forum 2026）发布AI DC数据基础设施全栈方案。华为副总裁、数据存储产品线总裁袁远在《数据觉醒，存力跃迁》主题演讲中指出，企业要加速AI落地需将现有IT架构向AI数据中心基础设施快速演进，围绕数据湖、知识与记忆平台、算力、模型、Agent框架与数据韧性六大方向系统性规划与建设。该方案是业界首个从存储层到Agent层的完整AI DC基础设施栈，覆盖OceanStor Pacific高密度存储、DME Omni-Dataverse统一数据空间、CMS上下文记忆存储、3+1 AI数据平台、ModelEngine模型工程与资源调度、Nexent智能体平台和端到端数据韧性平台。

技术解析

  • OceanStor Pacific高密度存储：2U空间内实现11PB容量，为AI训练和推理的海量数据提供最优TCO存储底座。DME Omni-Dataverse统一数据空间支持多模态、跨站点、实时数据入湖，实现全局数据可视可管，同时具备千亿千维向量数据秒级检索能力——这标志着数据湖从”存数据”进化为”供给AI”。
  • CMS（Context Memory Storage）——业界首个异构算力KV Cache共享存储：面向超大规模推理集群，CMS支持KV语义直通或采用专用DPU进行语义卸载，可扩展为PB级共享KV Cache池，将推理首Token时延（TTFT）降低90%。此前Vol.6报道的SGLang分层稀疏注意力将KVCache显存从8GB降至200MB，解决的是”单GPU内如何更高效使用KV Cache”的问题；华为CMS则从”跨GPU共享”维度解决问题——将KV Cache从GPU私有缓存变为集群共享资源，推理服务可以跨节点复用上下文，无需每个GPU维护独立副本。
  • 3+1 AI数据平台：华为首创的推理闭环架构——“3”是KV Cache加速（推理效率）、95%检索精度知识库（推理准确性）、持续进化记忆库（推理持续性），“+1”是UCM（Unified Cache Manager）统一调度管理。UCM实现三者的无缝协调：推理请求优先命中KV Cache（快速路径），缓存未命中则检索知识库（语义路径），推理结果写入记忆库（进化路径），整个调度过程由UCM统一编排。实测推理准确度提升30%。
  • ModelEngine模型工程与资源调度：零代码适配新模型、一键部署模型；细粒度计算资源切分与智能调度支持xPU 1:10分区比，实现”一卡多用”提升资源利用率。
  • Nexent智能体平台：通过自然语言交互直接生成Agent，上线周期缩短80%；自动优化Skill、提示词和记忆，Agent持续演进越用越聪明。与Vol.7报道的dbt Developer Agent和Confluent Agent Skills不同——后者是”在开发工具中嵌入AI代理”，Nexent是”用AI生成AI代理”，是从辅助到自动化的跃迁。
  • 数据韧性平台：端到端防护覆盖Agent、模型、平台和基础设施四个维度，防止工具滥用、数据投毒、篡改和勒索攻击。这是Vol.3报道的Unity AI Gateway治理能力在基础设施层的对应——前者在云平台层治理AI代理行为，华为在数据中心层守护AI数据资产。

行业影响

华为AI DC全栈方案的意义不在于某个单点技术突破，而在于首次将AI数据中心的六层基础设施（数据湖→知识记忆→算力→模型→Agent→安全）作为统一系统设计。此前行业讨论AI基础设施多聚焦某一层——Vol.4-6的KVCache优化（推理层）、Vol.5的DuckDB Lance扩展（存储层）、Vol.7的SDP声明式管道（计算层）——华为的方案将各层统一编排：数据湖供给训练语料和知识库，知识记忆平台加速推理，模型引擎调度算力，Agent框架编排应用，数据韧性全程守护。

CMS是其中最值得关注的创新。与Vol.6报道的SGLang分层稀疏注意力（CPU卸载+稀疏加载）和Tair KVCache HiSim（仿真驱动配置优化）形成三层递进：SGLang解决”单机如何高效使用KV Cache”（运行时优化），HiSim解决”如何找到最优KV Cache配置”（设计时优化），华为CMS解决”集群如何共享KV Cache”（架构层优化）。三者共同指向一个趋势：KV Cache正在从GPU的临时缓存变为AI数据中心的持久化共享基础设施——这与数据库从内存缓存到分布式共享存储的演进路径一致。

相关链接

Databricks Catalog Commits GA：Unity Catalog从元数据目录升级为湖仓事务协调者

事件概述

5月8日，Databricks宣布Catalog Commits正式GA（Generally Available）。这是Unity Catalog架构演进的重要里程碑——事务协调从文件系统（Delta Lake事务日志）上移到Unity Catalog目录层，使Unity Catalog从”元数据目录”升级为”表状态协调者”。Catalog Commits带来四项核心能力：跨多表原子事务、治理化访问协调、更快的查询规划与写入、以及外部引擎安全写入Unity Catalog管理表。该特性已获得Delta Spark、Starburst Trino、DuckDB、Apache Flink和StreamNative Kafka Service等引擎的支持。

技术解析

  • 事务协调上移——从文件系统到目录：传统Delta Lake事务在表级别协调提交——每张表独立管理事务日志和冲突检测。Catalog Commits将协调上移到目录层：Unity Catalog成为表状态的”唯一真实来源”（single source of truth），统一协调所有引擎对表的访问和状态管理。这不是简单的功能叠加，而是事务语义的架构性重构——从此前的”每张表独立仲裁”变为”目录统一仲裁”。
  • 跨多表原子事务：首次支持跨多张表的SQL语句作为单个原子提交——所有变更一起成功或一起失败。这对传统数仓工作负载（如ETL中跨表更新维度和事实表）是关键需求，此前在Lakehouse架构中无法实现。
  • 元数据延迟消除：Unity Catalog直接告知Delta客户端表级元数据，跳过云存储读取——消除了元数据延迟的主要来源。查询规划和写入路径因无需等待云存储响应而加速。
  • 外部引擎安全写入：Beta版本支持外部引擎（Apache Spark、DuckDB、Apache Flink、Starburst和StreamNative Kafka Service）安全创建、读取和写入Unity Catalog管理的Delta表。UC序列化跨引擎提交，防止并发外部写入损坏事务日志；每个操作可审计；Predictive Optimization继续管理表健康（压缩、清理、统计信息）。外部引擎通过EXTERNAL_USE_SCHEMA权限和M2M OAuth认证，通过Unity REST API访问。
  • 可执行约束：Unity Catalog验证或拒绝模式（schema）和约束变更，防止可能破坏数据完整性或下游工作负载的不兼容更新。这是”治理化访问”的具体体现——目录不仅是元数据仓库，还是数据完整性守护者。
  • Iceberg管理表支持：事务写入Unity Catalog管理的Iceberg表现在处于Private Preview，通过Iceberg REST API实现。至此，Unity Catalog下的两种开放格式（Delta和Iceberg）均支持外部引擎完整读写。

行业影响

Catalog Commits GA的深层意义是湖仓架构的事务模型正在从”去中心化”走向”中心化”。此前Delta Lake的事务模型是每张表独立管理——这在单表场景下工作良好，但跨表一致性依赖应用层保证（如两阶段提交），复杂且脆弱。Catalog Commits将事务协调上移到目录层，使Unity Catalog成为Lakehouse的”分布式事务协调器”——这与传统数仓（如Oracle、SQL Server）的集中式事务管理模型一致，但保留了Lakehouse的开放格式和多云优势。

外部引擎安全写入则补上了Vol.7报道的Unity Catalog开放性叙事的最后一块拼图。此前Unity Catalog的开放性主要体现在”任何引擎都能读”（UC Open API+凭证分发），现在扩展到”任何引擎都能安全写”——结合Vol.6报道的OTel+Unity Catalog集成（可观测性数据写入Delta表），Unity Catalog正在从”元数据目录”进化为”数据基础设施的操作系统”：读（Open API）、写（Catalog Commits）、观测（OTel集成）、治理（Payload Logging+AI Gateway）——四个层面统一协调。

更值得关注的趋势是：Unity Catalog正在成为Iceberg和Delta两种格式的统一协调层。Iceberg管理表已通过Iceberg REST API支持外部写入（Public Preview），Delta管理表通过Catalog Commits支持外部写入（Beta）。当两种格式共享同一个事务协调器时，格式选择不再是”选阵营”而是”选工具”——这与Vol.7报道的Iceberg File Format API从”硬编码分支”到”插件模型”的理念完全一致。

相关链接

Databricks Runtime 18.2 GA与Lakeflow Designer用户定义算子：可视化管道进入可扩展时代

事件概述

5月4日，Databricks Runtime 18.2正式GA，搭载Apache Spark 4.1稳定版。同日，Lakeflow Pipelines Editor正式GA，提供代理优先（Genie Code）的管道开发体验。5月19日，Lakeflow Designer全面更新——默认启用、新增AI算子搜索、可配置样本大小、用户定义算子（Public Preview）支持三种类型（uc-udf、uc-udtf、python-run-function），以及Git/导入/克隆/导出功能。5月7日，Standalone pipelines（独立管道）在无服务器通用计算上进入Beta。5月14日，Lakeflow Spark声明式管道环境版本（Environment Versions）进入Beta，支持将Python运行时与Databricks Runtime升级解耦。

技术解析

  • Runtime 18.2 GA——Spark 4.1稳定版落地：Runtime 18.2搭载Vol.7详细报道的Spark 4.1.0稳定版，意味着SDP声明式管道、RTM实时模式、SQL Scripting GA和VARIANT类型GA正式进入生产就绪状态。此前Runtime 18和18.1均为Beta，18.2是首个GA版本。
  • Lakeflow Pipelines Editor GA——代理优先的管道开发：编辑器将代码与Genie Code聊天窗口并排显示，旁边是管道图和指标面板。开发者可以与AI代理协作创建、更新和调试生产管道——这与Vol.7报道的dbt Developer Agent思路一致，但Databricks将代理交互嵌入到可视化管道编辑器中而非命令行。
  • Lakeflow Designer默认启用与AI算子搜索：Designer现在对所有免费版、高级版和企业级工作区默认启用。AI算子搜索根据意图推荐算子——例如输入”按月平均”自动推荐Aggregate算子。这降低了可视化数据准备的使用门槛，与非技术用户生成AI查询的需求对齐。
  • 用户定义算子（Public Preview）——可视化管道的无限扩展：三种类型——uc-udf（Unity Catalog用户定义函数，标量运算）、uc-udtf（Unity Catalog用户定义表函数，表值运算）和python-run-function（通用Python运行函数）。用户定义算子出现在内置算子旁边，与原生算子享有相同的可视化交互体验。这是Lakeflow Designer从”有限内置算子”到”无限可扩展算子”的质变。
  • Standalone Pipelines Beta：无需专用集群，在无服务器通用计算上创建物化视图和流式表，支持SQL和Python定义。此前的管道必须绑定到专门的Databricks SQL或集群资源，独立管道将管道运行从基础设施依赖中解放。
  • 环境版本（Beta）：为管道配置固定的Python语言版本和预装库集，将管道的Python运行时与Databricks Runtime升级解耦。这是生产管道稳定性的重要保障——Runtime升级不会意外破坏管道依赖。

行业影响

Lakeflow Designer用户定义算子的意义不仅是”又多了一个自定义功能”，而是可视化数据准备从”封闭平台”走向”开放生态”的转折点。此前所有可视化ETL工具（包括Databricks自身的Lakeflow Designer、Tableau Prep、Alteryx）都面临同一个限制：用户只能使用平台提供的内置算子，自定义逻辑需要跳出可视化环境回到代码——这破坏了可视化工作流的一致性体验。用户定义算子让自定义逻辑在可视化界面中原生呈现和执行，消除了”可视化→代码→可视化”的上下文切换。

结合Lakeflow Pipelines Editor GA（代理优先的管道开发）和AI算子搜索（自然语言找算子），Databricks正在构建一个从自然语言到可视化管道到生产部署的无缝链路：非技术用户用自然语言描述意图→AI推荐算子→Designer可视化编排→用户定义算子扩展能力边界→Pipelines Editor与Genie Code协作调试→Standalone Pipelines在无服务器上运行——整条链路无需离开Databricks平台。这与Vol.7报道的Spark SDP（声明式管道从”怎么做”到”要什么”）形成互补：SDP是编程接口层的声明式抽象，Lakeflow Designer是交互层的声明式抽象——两者共同推动数据工程从”编写代码定义变换”到”描述意图编排执行”。

相关链接

编者评

第八期的三条动态，与前七期的主线形成了又一个维度的扩展。Vol.1-2确立了”AI原生基础设施”和”基础设施AI代理化”两条主线，Vol.3-4追踪到AI代理趋势渗透到治理层和存储/芯片层，Vol.5看到横切面基础设施为AI代理重新定义角色，Vol.6见证了AI推理基础设施的精细化，Vol.7看到湖仓格式插件化和AI代理成为基础设施原生操作者。本期则看到了两条更深层的线索：AI基础设施的系统性构建和湖仓事务模型的架构性重构。

华为AI DC全栈方案的深层意义不是”又一个AI基础设施产品发布”，而是AI数据中心的六层基础设施首次被作为统一系统设计——数据湖、知识记忆、算力、模型、Agent、安全不再是独立选型的拼凑，而是统一编排的系统。其中CMS上下文记忆存储最值得关注：它将KV Cache从GPU的私有缓存推入集群的共享资源层——与Vol.6的SGLang分层稀疏注意力（运行时优化）和HiSim（设计时优化）共同构成了KV Cache从”临时缓存”到”持久化基础设施”的完整演进路径。当KV Cache成为可寻址、可共享、可调度的数据中心级资源时，AI推理的架构范式从”每GPU自给自足”变为”集群资源共享”——这正是数据库从嵌入式到分布式共享存储走过的路。

Databricks Catalog Commits GA则标志着湖仓事务模型从”去中心化”到”中心化”的关键转折。此前Lakehouse的事务模型是每张表独立仲裁——这在单表场景下足够，但跨表一致性是传统数仓工作负载的结构性需求。Catalog Commits将Unity Catalog从”元数据目录”升级为”事务协调器”，使跨表原子事务成为可能。结合外部引擎安全写入和OTel+UC集成（Vol.6），Unity Catalog正在成为湖仓的”操作系统”——读、写、观测、治理四个层面统一协调。

将八期主线串联，一个更完整的演进图景浮现：DataInfra正在从”组件AI化”走向”系统AI化”。Vol.1-3是单个组件为AI代理提供接口（计算引擎、存储格式、治理框架），Vol.4-6是组件内部为AI代理重新设计（KVCache优化、可观测性湖仓化），Vol.7是组件间关系为AI代理重新组织（格式插件化、代理原生操作），Vol.8则是整个系统为AI代理统一构建（华为六层AI DC栈、Unity Catalog统一协调、Lakeflow声明式管道链路）。当数据湖、推理集群、事务协调、管道编排都围绕AI代理工作负载统一设计时，DataInfra的竞争不再是”哪个组件更好”，而是”哪个系统更完整”——系统完整性成为新的竞争壁垒。