datainfra前沿动态 · Vol.22

Databricks Genie Ontology以PageRank式权威图谱解决AI代理上下文危机；Google Cloud Lightning Engine借Gluten/Velox实现4.9x Spark加速；Delta Lake 4.3将UniForm与Catalog-Managed Tables推向生产

第二十二期聚焦DataInfra三条动态：6月16日Databricks在DAIS 2026上宣布Genie Ontology——通过类PageRank算法自动从表、查询、仪表盘、管道和连接应用中提取知识片段，构建企业业务上下文的活图谱，使Genie在复杂企业数据分析问题上首次尝试正确率达84.5%（最强编码代理仅52.4%），Genie One将AI同事嵌入Slack/Teams/移动端，Genie Agents让单提示创建自主代理——AI代理的上下文危机从'强行记忆'走向'语义图谱'；同期Google Cloud在Next '26上发布Lightning Engine GA（6/11）——基于Gluten+Velox的向量化原生执行层让Managed Service for Apache Spark性能提升4.9倍、性价比提升2倍，向量化排序/窗口函数加速/智能回退JVM/直接路径连接Cloud Storage/单HashTable缓存Broadcast Join/聚合下推/自动Shuffle分区，Spark性能优化从'运行时调优'走向'原生向量化执行'；Delta Lake 4.3于6/22发布——所有表操作通过Unity Catalog Delta REST APIs路由（服务端提交验证/服务端公布表功能/声明式意图元数据更新），UniForm转换变为原子和增量（大提交原子转换Iceberg元数据/增量转换仅重生成变更日志范围），流式CDF支持CDC流式处理+Row Tracking读取+模式演变生存上游变更，Delta Kernel成为Spark/DuckDB/Flink共享表的统一内核——三条动态共同指向数据基础设施的'执行层优化'主线：Genie Ontology优化AI代理的数据上下文获取效率（消除迭代探测），Lightning Engine优化Spark查询执行效率（消除JVM开销），Delta Lake 4.3优化跨引擎表访问效率（消除日志探测）。

DataInfra Databricks DAIS 2026 Genie One Genie Agents Genie Ontology AI代理 上下文图谱 PageRank Unity Catalog Google Cloud Lightning Engine Gluten Velox SIMD 向量化执行 Apache Spark Managed Service for Apache Spark 原生C++执行 Direct Path Connection Broadcast Join缓存 Delta Lake 4.3 Delta REST Catalog Unity Catalog REST API Catalog-Managed Tables Delta UniForm Iceberg元数据同步 原子转换 增量转换 流式CDF Row Tracking Delta Kernel 跨引擎互操作 Spark 4.3 DuckDB Flink

第二十二期追踪到DataInfra领域三条重要动态：6月16日Databricks在DAIS 2026（6/15-18，旧金山，30,000+参会者）上宣布Genie Ontology——通过类PageRank算法自动从表、查询、仪表盘、管道和连接应用中提取知识片段，构建企业业务上下文的活图谱（Living Context Graph），使Genie在28道真实企业数据分析题套件上首次尝试正确率达84.5%（最强通用编码代理仅52.4%，最弱仅25%），同时Genie One将AI同事嵌入Slack/Teams/移动端（iOS/Android应用），Genie Agents让从单提示创建自主代理成为可能——AI代理的上下文危机（数据上下文分散在仪表盘/查询/管道/维基/工单/文档/聊天线程中，AI强行推断产生错误答案）从”强行记忆”走向”语义图谱”；同期Google Cloud在Next ‘26上发布Lightning Engine GA（6/11）——基于开源Gluten和Velox运行时的向量化原生执行层让Managed Service for Apache Spark性能提升4.9倍、性价比提升2倍（相较领先高速Spark替代方案），向量化排序/窗口函数加速/智能回退JVM（不支持的算子自动回退JVM避免数据格式转换）/直接路径连接Cloud Storage（双向流式+seek操作+向量化readV API）/单HashTable缓存Broadcast Join/聚合下推/自动Shuffle分区，经过100万+真实生产工作负载验证——Spark性能优化从”运行时调优”走向”原生向量化执行”；Delta Lake 4.3于6/22发布——所有表操作通过Unity Catalog Delta REST APIs路由（服务端提交验证/服务端公布表功能/声明式意图元数据更新），Spark 4.1+Delta 4.3+Unity Catalog Spark连接器0.5开箱即用，UniForm转换变为原子和增量（大提交原子转换Iceberg元数据/IcebergCompatV3实验性支持删除向量与UniForm共存/基于Iceberg-spark 1.11.0支持Spark 4.0和4.1），流式CDF支持CDC流式处理（SELECT … CHANGES FROM VERSION/TIMESTAMP）+Row Tracking读取（_metadata.row_id和_metadata.row_commit_version）+模式演变生存上游变更（allowSourceColumnRename/allowSourceColumnDrop/failOnDataLoss=false），Delta Kernel成为Spark/DuckDB/Flink共享表的统一内核——三条动态共同指向数据基础设施的”执行层优化”主线：Genie Ontology优化AI代理的数据上下文获取效率（消除迭代探测，2倍快于最强编码代理），Lightning Engine优化Spark查询执行效率（消除JVM开销，4.9倍加速），Delta Lake 4.3优化跨引擎表访问效率（消除日志探测，REST API统一提交路径）。

Databricks Genie Ontology：以PageRank式权威图谱解决AI代理的上下文危机

事件概述

6月16日，Databricks在DAIS 2026（Data + AI Summit，6/15-18于旧金山举行，30,000+参会者）上宣布Genie Ontology——这是继Vol.21报道AWS EMR Spark 4.0 GA后，本周最重要的AI+数据基础设施融合公告。Genie Ontology是一个自动上下文层，自动从表、查询、仪表盘、管道和连接应用（Gmail/Slack/Teams）中提取知识片段，将其组织为企业业务上下文的活图谱（Living Context Graph）。

其核心创新是”权威判定算法”——类似PageRank的原理，权衡定义来源、作者相对权威、依赖频率、与认证资产的关联度、新鲜度，从最权威来源回答。在Databricks内部基准测试（28道真实企业数据分析题，2026年6月）中，Genie回答84.5%的题目正确（首次尝试），而最强通用编码代理仅52.4%，最弱仅25%。Genie不牺牲准确率换取速度——同时实现高准确率和低延迟，比最强编码代理快2倍。

同期宣布的还有Genie One（数据智能AI同事，嵌入Slack/Teams/移动端）和Genie Agents（从单提示创建自主代理，可推理非结构化数据+采取自主行动）。

技术解析

  • Genie Ontology的权威判定算法——类PageRank的上下文权重：传统AI代理获取数据上下文的方式是”向量相似性搜索”——用户提问后，代理将问题转换为嵌入向量，在知识库中检索最相似的文档片段。这种方法有两个问题：（1）向量相似性不等同于权威相似性——最相似的文档片段不一定是最权威的数据来源；（2）静态知识库无法反映数据的实时状态（表结构变更、新管道上线、仪表盘更新）。Genie Ontology的权威判定算法解决这两个问题：类似PageRank，它不仅看”哪个文档与问题最相似”，还看”哪个来源最权威”——权威来源的定义类似PageRank的链接分析：被更多认证资产引用的定义更权威、被更多用户依赖的定义更权威、来自认证数据资产的定义更权威。权重因子包括：定义来源（表/查询/仪表盘/文档）、作者相对权威（在Unity Catalog中的权限和认证状态）、依赖频率（多少查询/管道依赖这个定义）、与认证资产的关联度（是否链接到广用的Golden Dataset）、新鲜度（最近更新的定义权重更高）。

  • 活图谱（Living Context Graph）——上下文自动更新而非手动策划：传统企业知识图谱需要手动策划（数据管理员定义实体、关系、属性），Genie Ontology自动提取和更新。提取源包括：表（列名、数据类型、分区键、约束）、查询（SQL逻辑、JOIN关系、聚合规则）、仪表盘（指标定义、筛选条件、 drill-down 路径）、管道（数据流转逻辑、转换规则）、连接应用（Gmail中的数据分析讨论、Slack中的指标解释、Teams中的数据事件）。这些信息被组织为图谱：节点是”概念/指标/表/团队”，边是”关系（指标A基于表B，指标C由团队D维护）“。当新表注册、新查询运行、新仪表盘发布时，图谱自动更新——无需数据管理员手动维护。

  • Genie One的全方位集成——AI同事嵌入工作流：Genie One是Genie的产品形态——不是独立应用而是嵌入工作流的AI同事。（1）Slack/Teams原生集成：在任意对话中@mention Genie，用自然语言提问，秒级获取准确答案（通过Unity Catalog执行权限，仅返回用户有权访问的内容）；（2）iOS/Android移动应用：随时随地提问、接收告警、采取行动；（3）Genie MCP App：允许使用现有AI代理或自建代理的用户无需改变工作流即可获得Genie能力（通过MCP协议将Genie接入其他AI代理）；（4）计划与告警、监控、文档创建、自定义技能和自定义MCP支持。

  • Genie Agents——从单提示到自主代理：Genie Spaces（Vol.15报道已有100万+创建）演进为Genie Agents。（1）自主行动：使用与Genie One相同的工具（MCP连接、计划任务、文档和构件生成、外部系统写入）完成多步工作流无需监督；（2）非结构化数据推理：不仅基于表和视图，还基于文档、文件和知识源；（3）单提示创建：在Genie One或Genie Code中描述需求，旋转出一个Genie Agent，设定范围，基准测试，分享给团队成员使用或定制。这与Vol.17报道的AliSQL DuckDB（HTAP）和Vol.19报道的华为云Agentic Infra（Token工厂）形成AI代理基础设施的三层：AliSQL DuckDB提供OLTP+OLAP融合存储，华为云提供Token工厂算力，Genie Agents提供企业数据上下文。

  • 准确率基准测试详情：Databricks内部基准测试使用28道真实企业数据分析题套件（2026年6月），涵盖多表JOIN、时间窗口分析、比率计算、异常检测等典型企业数据分析场景。Genie回答84.5%正确（首次尝试），最强通用编码代理52.4%，最弱25%。关键不是”Genie更聪明”而是”Genie有更好的上下文”——通用编码代理需要多轮迭代探测（先探索表结构、再理解指标定义、再写查询、再验证结果），Genie通过Ontology直接获得权威上下文，首次尝试即生成正确查询。延迟对比：Genie比最强编码代理快2倍（消除迭代探测轮次）。

行业影响

Databricks Genie Ontology的深层意义不是”又一个AI聊天分析助手”，而是AI代理的数据上下文获取范式从”向量检索”走向”权威图谱”。

此前AI代理获取数据上下文的主流方法是RAG（检索增强生成）——将企业文档、表结构、查询历史存入向量数据库，用户提问时检索最相似的片段。RAG有两个固有局限：（1）向量相似性≠语义正确性——检索到的片段可能与问题字面相似但语义错误（如”月活跃用户”在不同表中定义不同）；（2）静态索引≠实时状态——数据管道更新后向量索引可能不会立即更新，导致代理基于过时上下文回答。Genie Ontology通过”权威权重+活图谱”解决这两个局限：权威权重确保回答来自最可信的数据源（而非最相似的文本片段），活图谱确保上下文反映数据的最新状态（而非静态快照）。

与Vol.15报道的Snowflake Horizon Context（Collect→Enrich→Activate三段式架构/Metadata Connectors/端到端列级血缘/AI生成文档）相比，Genie Ontology和Horizon Context都试图解决”AI代理如何理解企业数据”的问题，但路径不同：Horizon Context从”数据目录”切入（Metadata Connectors连接外部系统、AI生成文档丰富元数据），Genie Ontology从”上下文图谱”切入（自动提取知识构建活图谱、权威算法确定信息权重）。两者殊途同归——都是让AI代理获得”企业数据意味着什么”的理解能力。

将本期三条动态串联，Genie Ontology、Lightning Engine和Delta Lake 4.3分别从三个层面优化数据路径效率：Genie Ontology优化”AI代理获取上下文”的效率（消除迭代探测），Lightning Engine优化”查询执行”的效率（消除JVM开销），Delta Lake 4.3优化”跨引擎访问表”的效率（消除日志探测）。三者都通过”原生层优化”而非”运行时调优”实现加速——Genie Ontology在原数据层构建权威图谱（而非让代理在查询时探测），Lightning Engine在原执行层使用C++向量化（而非在JVM层调优），Delta Lake 4.3在原协议层使用REST API（而非让各引擎各自解析Delta日志）。

相关链接

Google Cloud Lightning Engine：Gluten+Velox向量化原生执行让Spark性能跃升4.9倍

事件概述

6月11日，Google Cloud宣布Managed Service for Apache Spark的Lightning Engine正式GA（General Availability），覆盖Serverless和Managed Clusters两种部署模式。Lightning Engine基于开源Gluten和Velox运行时，通过向量化原生执行（C++，SIMD）绕过JVM执行开销和垃圾回收暂停，在超过100万真实生产工作负载上验证，实现比标准开源Spark快4.9倍、比领先高速Spark替代方案性价比高2倍。

核心技术包括：（1）向量化原生执行——将Spark物理查询计划编译为C++指令，针对SIMD向量化处理优化；（2）优化的Cloud Storage和BigQuery连接器——直接路径连接（双向流式+seek操作）、元数据调用减少、Arrow格式原生消费；（3）Broadcast Join单HashTable缓存、聚合下推、自动Shuffle分区。此公告与Vol.21报道的AWS EMR Spark 4.0 GA（emr-spark-8.0运行时）形成云厂商Spark优化的两条路径：AWS通过捆绑最新开源版本（Spark 4.0 + Iceberg 1.10 + Delta 4.0 + Hudi 1.0.2）和优化运行时，Google通过原生执行层（Lightning Engine）加速Spark查询。

技术解析

  • 向量化原生执行——Gluten+Velox架构：Gluten是Intel发起的开源项目，提供Spark的向量化执行能力；Velox是Meta发起的开源向量化执行引擎（C++，SIMD优化）。Lightning Engine将两者整合：Spark的Catalyst优化器仍用Scala编写（生成物理查询计划），但物理计划的执行从JVM移至原生C++层。（1）向量化排序：按列处理数据在原生内存中，显著减少CPU周期开销；（2）加速窗口函数：直接在原生C++层执行（移动平均、聚合、去重），无需在JVM和原生层之间序列化；（3）智能回退：如果查询包含不支持的原生算子或自定义Java UDF，引擎的智能下推层自动优雅地将该特定子树回退至JVM，避免不必要的数据格式转换并保持整体执行稳定性。这与Vol.7报道的Spark 4.0的向量化执行（Arrow原生UDF）方向一致但实现层面不同：Spark 4.0在JVM内使用Arrow列式内存格式，Lightning Engine将执行完全移至C++层。

  • 优化的Cloud Storage连接器——消除I/O瓶颈：高性能计算在无数据时可读取时是无用的。（1）直接路径连接：绕过多个节点跳跃，使用双向流式与Cloud Storage通信，允许seek操作和向量化readV API无需重新打开流，加速复杂深层嵌套Parquet或ORC文件的扫描时间；（2）元数据调用减少：管理大规模分区表时，列出文件的隐藏性能税很高——Lightning Engine利用词典式列表（lexicographic listing）在Driver端收集元数据并直接传输给Executor，消除冗余的Cloud Storage API调用并显著减少Cloud Storage元数据成本；（3）原生BigQuery连接器：直接以Arrow格式消费BigQuery数据，避免从Arrow到JVM UnsafeRow的昂贵转换，消除序列化开销加速扫描时间。

  • Broadcast Join单HashTable缓存——消除冗余CPU周期：标准Broadcast Join中，Spark在每个任务中重复构建Join哈希表。Lightning Engine在每个Executor中构建哈希表一次并缓存它，消除冗余CPU周期并减少Executor内存占用。这与Vol.4报道的DuckDB的Broadcast Join优化（如果有的话）方向一致——在内存中缓存哈希表避免重复构建。

  • 聚合下推和自动Shuffle分区：（1）聚合下推：自动将部分聚合下推至Join Shuffle之前，最小化必须通过网络安全传输的数据量，大幅减少昂贵的Shuffle阶段；（2）自动Shuffle分区：基于运行时统计动态自适应确定每个查询阶段的最佳Shuffle分区数，防止OOM溢出且不过度分区。这与Spark 3.x的Adaptive Query Execution（AQE）功能类似但实现在原生层。

  • 与Vol.21的AWS EMR Spark 4.0对比：AWS EMR Spark 4.0（emr-spark-8.0运行时）通过捆绑Spark 4.0 + Iceberg 1.10 + Delta 4.0 + Hudi 1.0.2和优化运行时（EMR优化运行时比开源Spark快4.5倍）实现加速。Google Cloud Lightning Engine通过原生执行层（C++，SIMD）实现加速。两者路径不同但目标一致：让Spark在云上运行更快。值得注意的是，Lightning Engine兼容现代Spark工作负载且无需更改现有数据管道（零代码修改），这与AWS EMR的Spark 4.0 GA类似（Spark 4.0向后兼容3.x）。

行业影响

Google Cloud Lightning Engine GA的深层意义不是”又一个云Spark性能优化”，而是Spark性能优化范式从”运行时调优”走向”原生向量化执行”。

此前Spark性能优化的主要方法是”运行时调优”——调整Spark配置参数（spark.sql.shuffle.partitions、spark.executor.memory、spark.memory.fraction等）、使用Kryo序列化、启用Adaptive Query Execution、使用Broadcast Join提示等。这些方法依赖Spark用户在JVM层面优化，效果有限且需要专业知识。Lightning Engine将执行从JVM移至原生C++层，从根本上消除JVM开销（GC暂停、解释执行开销、对象创建开销），实现数量级性能提升。

与Vol.16报道的Google Cloud Serverless Spark Runtime 3.0（75%启动加速）结合，Google Cloud的Spark策略是双管齐下：Runtime 3.0优化”启动速度”（让Spark应用更快开始执行），Lightning Engine优化”执行速度”（让Spark查询更快完成）。这与AWS EMR的策略（Serverless Storage降低20%成本 + emr-spark-8.0运行时优化执行速度）形成对比：Google重执行速度（4.9倍），AWS重成本优化（20%降本）。

将Lightning Engine开源（Gluten和Velox都是开源项目）尤其值得关注。这意味着Spark性能优化的”原生执行层”路径不再是Google Cloud专有技术——任何Spark部署（本地、其他云、混合云）都可以通过部署Gluten+Velox获得类似加速。这与Vol.12报道的Databricks Iceberg v3 GA和Vol.16报道的Snowflake/ Databricks跨引擎治理竞争形成有趣对比：Spark执行引擎层通过开源项目（Gluten/Velox）实现跨平台统一优化，而目录层通过开放规范（Iceberg REST Catalog）实现跨引擎统一治理。

相关链接

Delta Lake 4.3：REST Catalog统一提交路径与UniForm原子转换完善Catalog-Managed生态

事件概述

6月22日，Delta Lake发布4.3版本。这是继Vol.21报道Delta Lake 4.0（EMR Spark 4.0 GA同期提及）后，Delta Lake最重要的版本更新。核心变化是将Catalog-Managed Tables（Vol.13报道的”Delta-next evolution”）从”提交协调”深化到”全操作面统一API”：所有表操作（LOAD、CREATE、CTAS、REPLACE、CREATE OR REPLACE、RTAS、元数据变更写入如DML模式演变和ALTER TABLE更新）现在都通过Unity Catalog Delta REST APIs路由。同期UniForm（让Iceberg读者查询Delta表无需复制数据）变为原子和增量转换，流式CDF支持CDC流式处理+Row Tracking读取+模式演变生存上游变更。

Delta Lake 4.3与Spark 4.1（Vol.7报道的Spark 4.1+Databricks Runtime 18 Beta）和Unity Catalog Spark连接器0.5（io.unitycatalog:unitycatalog-spark_4.1_2.13:0.5.0）开箱即用。这是Vol.21报道的”格式层功能差距已弥合、竞争转向目录层”的延续和深化——Delta Lake通过REST API将提交验证、表功能公布、意图式元数据更新统一到目录层，让Spark/DuckDB/Flink（通过Delta Kernel）共享同一套表操作API。

技术解析

  • Delta REST Catalog——全操作面统一API：Delta 4.2使提交（commit）由目录协调，Delta 4.3将其余操作面置于统一API下。此前Catalog-Managed Tables的提交已通过Unity Catalog协调（目录作为表状态单一真相来源），但表操作（如CREATE TABLE、ALTER TABLE、schema evolution）仍通过Delta事务日志协调。Delta 4.3将所有操作路由至Unity Catalog Delta REST APIs：（1）服务端提交验证（server-side commit validation）：在提交污染表状态之前拒绝格式不正确或冲突的提交；（2）服务端公布表功能（server-advertised table features）：引擎从目录了解表支持什么功能，而非探测日志；（3）意图式元数据更新（intent-based metadata updates）：将模式变更表达为声明式意图，由目录验证和应用。这让每个连接引擎（Spark、DuckDB、Flink及任何采用UC Delta REST APIs的基于Delta-Kernel的连接器）获得定义良好的行为。

  • UniForm原子和增量转换——Iceberg元数据同步的可靠性提升：UniForm保持Apache Iceberg元数据与Delta提交同步，使Iceberg读者可查询Delta表无需复制数据。Delta 4.3在两个方面改进UniForm：（1）原子转换：大提交在Delta事务内原子性转换为Iceberg元数据——此前UniForm转换可能在Delta提交成功后Iceberg元数据转换失败，导致不一致；（2）增量转换：仅重生成变更日志范围而非每次提交后全量快照——这显著减少UniForm的转换开销，让高频率写入的Delta表也能启用UniForm。此外，IcebergCompatV3（实验性）让使用删除向量（DVs）的Delta表也能启用UniForm（delta.enableIcebergCompatV3=true），DVs和UniForm共存于同一表。UniForm现在基于Iceberg-spark 1.11.0构建，支持Spark 4.0和4.1。

  • 流式CDF与Row Tracking——模式演变生存能力：Structured Streaming现在支持CDC流式处理（变更数据捕获作为流式源）、Row Tracking读取（_metadata.row_id和_metadata.row_commit_version在流式读取中暴露）、模式演变跟踪（schema-tracking log记录模式变更，列重命名不再中断流）。关键功能是”模式演变生存”——此前如果上游表重命名列或删除列，流式作业会失败（ schema mismatch），现在通过allowSourceColumnRename和allowSourceColumnDrop选项，流可以存活上游模式变更。failOnDataLoss=false现在在日志文件已被清理时跳至最早可用版本而非抛出错误。这与Vol.4报道的Daft v0.7.14（arrow-rs重写Parquet读取器）和Vol.19报道的阿里云Flink VVR 11.7（Flink Agents+ Paimon向量搜索）的流式数据管道可靠性改进方向一致。

  • Delta Kernel作为跨引擎统一内核：Delta Kernel是Delta Lake的Java库，提供轻量级API让引擎读取和写入Delta表。Delta 4.3的持续投入（Unity Catalog REST API集成、流式CDF、UniForm）使Delta Kernel成为跨引擎互操作的核心——Spark通过Delta-Spark连接器（delta-spark_2.13:4.3.0）使用Delta Kernel，DuckDB通过Delta扩展（Vol.5报道的Delta扩展实验性标签移除，写入+Unity Catalog+时间旅行支持）使用Delta Kernel，Flink通过新的基于Delta Kernel的连接器（Delta 4.2引入的实验性Flink连接器）使用Delta Kernel。这与Vol.16报道的”跨引擎治理竞争”（Databricks Cross-Engine ABAC/Snowflake Scan Plan API）形成互补：Cross-Engine ABAC和Scan Plan API解决”跨引擎授权执行”，Delta Kernel解决”跨引擎表访问”。

行业影响

Delta Lake 4.3的深层意义不是”又一个Delta版本更新”，而是Delta Lake的Catalog-Managed Tables从”提交协调”走向”全操作面目录原生”的范式完成。

Vol.13报道的”Delta-next evolution: Catalog-Managed Tables”（2026年2月）引入了将事务协调从文件系统移至Unity Catalog的概念——目录成为表状态的单一真相来源。Delta 4.2（2026年4月）将提交协调落地。Delta 4.3（2026年6月）将全操作面（CREATE/ALTER/ schema evolution/ metadata change writes）落地。从概念到提交协调到全操作面，Delta Lake用了4个月完成Catalog-Managed Tables的完整实现——这是开放表格式历史上最快架构演进之一。

与Iceberg v3（Vol.12报道的Databricks Iceberg v3 GA）和Apache Polaris（Vol.20报道的Cloudera采纳Polaris）相比，Delta Lake的Catalog-Managed Tables路径是”通过REST API将目录集成内置到表格式中”，而Iceberg的路径是”通过开放规范（Iceberg REST Catalog）让任何目录实现提供服务”。两者殊途同归——都是让目录层成为表操作的中枢——但Delta的路径更集成（Unity Catalog REST API是Delta Lake的内置功能），Iceberg的路径更开放（任何实现Iceberg REST Catalog规范的目录都可以服务Iceberg表）。

将二十二期主线串联，开放表格式的竞争焦点从”格式功能”（Vol.1-7：删除向量、VARIANT、时间旅行、模式演变）经过”目录集成”（Vol.8-16：Unity Catalog、Polaris、Cross-Engine ABAC）走向”全操作面目录原生”（Vol.22：Delta REST Catalog全操作面统一API、服务端提交验证、服务端公布表功能、意图式元数据更新）。当表格式的所有操作都通过目录REST API路由时，“表格式”从”文件系统上的事务日志”变为”目录服务中的数据资产”——这是开放湖仓架构的根本性转变。

相关链接

编者评

第二十二期的三条动态，从三个不同层面共同指向数据基础设施的”原生层优化”主线——通过原生层重构而非运行时调优来提升效率。

第一个层面是AI代理的上下文获取优化：Databricks Genie Ontology将上下文获取从”向量检索”推进到”权威图谱”。 此前AI代理获取数据上下文的主流方法是RAG（检索增强生成）——将企业文档存入向量数据库，用户提问时检索最相似的片段。这种方法的固有局限是向量相似性不等同于语义正确性、静态索引无法反映数据实时状态。Genie Ontology通过类PageRank的权威判定算法和活图谱自动更新解决这两个局限：权威权重确保回答来自最可信的数据源，活图谱确保上下文反映最新状态。将本期与Vol.15的Snowflake Horizon Context（Metadata Connectors/AI生成文档）对比，两者都解决”AI代理如何理解企业数据”，但路径不同：Horizon Context从”数据目录”切入，Genie Ontology从”上下文图谱”切入。更深层看，这是AI代理基础设施从”模型层智能”走向”数据层智能”——代理的准确率提升不仅来自更大更好的模型，还来自更权威更及时的数据上下文。

第二个层面是Spark查询执行优化：Google Cloud Lightning Engine将执行从JVM推进到原生C++向量化。 此前Spark性能优化的主要方法是运行时调优（配置参数、AQE、Broadcast Join提示），依赖用户在JVM层面优化。Lightning Engine将执行移至原生C++层，从根本上消除JVM开销（GC暂停、解释执行开销、对象创建开销），实现4.9倍加速。将本期与Vol.21的AWS EMR Spark 4.0 GA对比，两者都优化Spark在云上的执行速度，但路径不同：AWS通过捆绑最新开源版本和优化运行时，Google通过原生执行层。更有趣的是Lightning Engine的开源基础（Gluten+Velox）——这意味着原生执行层优化不再是云厂商专有技术，而是可以通过开源项目部署在任何Spark环境中的通用能力。当原生执行层成为Spark的标配时，Spark性能优化的焦点从”调什么参数”走向”是否启用了原生执行层”。

第三个层面是跨引擎表访问优化：Delta Lake 4.3将表操作从”日志解析”推进到”REST API统一提交”。 此前跨引擎访问Delta表需要每个引擎各自解析Delta事务日志（LogStore），理解Delta协议，处理并发提交。Delta 4.3将所有表操作路由至Unity Catalog Delta REST APIs，让引擎通过标准HTTP API提交表操作、获取表功能、更新元数据——无需理解Delta日志格式。这与Vol.16报道的”跨引擎治理竞争”（Databricks Cross-Engine ABAC/Snowflake Scan Plan API）形成完整图景：Cross-Engine ABAC解决”跨引擎授权执行”（目录层强制执行行过滤器/列掩码），Delta REST Catalog解决”跨引擎表操作”（目录层统一提交路径/验证/表功能公布）。当跨引擎互操作性在目录层统一时，“开放湖仓”从”共享文件”走向”共享目录服务”——数据互操作不再需要复制数据，而是共享同一套目录API。

将二十二期主线串联，数据基础设施的效率优化正在从”运行时层”深化到”原生层”和”协议层”。 运行时层的优化（查询优化器、执行引擎调优、缓存策略）是在现有架构内提升效率，原生层的优化（Lightning Engine的C++执行、Genie Ontology的活图谱）是通过架构重构提升效率上限，协议层的优化（Delta REST Catalog的统一API、Iceberg REST Catalog的开放规范）是通过标准接口提升互操作效率。当效率优化从”调优”走向”重构”时，性能提升不再是线性的而是数量级的——Lightning Engine的4.9倍、Genie Ontology的84.5% vs 52.4%、Delta REST Catalog的统一提交路径，都不是微调可以实现的，而是架构重构的结果。 这对DataInfra从业者的启示是：当面临性能瓶颈时，先问”是否在正确的层优化”——如果是原生层或协议层的问题，运行时调优可能无法根本解决。