Databricks Cross-Engine ABAC与Snowflake Scan Plan API将治理执行推至目录层；Snowflake Parquet Direct与Zero-Copy集成让数据就地治理成为可能；Google Cloud Serverless Spark Runtime 3.0以75%启动加速进入4.x时代

第十六期追踪到DataInfra领域三条重要动态：Databricks 6月2日发布Cross-Engine ABAC（Beta）——Unity Catalog中定义的行过滤器与列掩码通过Iceberg REST Catalog Scan API在Spark、DuckDB（即将支持）、Starburst（即将支持）等外部引擎上强制执行，策略评估在目录层完成、引擎收到的是已过滤的扫描计划，引擎无需理解或实现任何策略逻辑，治理从”每个引擎复制策略”走向”定义一次处处执行”；Snowflake同日发布Interoperable Lakehouse架构博客——Iceberg REST Scan Plan API（私有预览）实现跨引擎行级访问控制与动态数据掩码，与Databricks Cross-Engine ABAC使用相同的Iceberg REST Catalog机制但架构表述不同（Databricks”目录过滤扫描计划”vs.Snowflake”目录返回授权扫描计划”），Parquet Direct（私有预览）让现有Parquet文件无需格式转换即享Iceberg级目录/治理/元数据能力——消除”Parquet湖”到”Iceberg湖”的迁移障碍，Zero-Copy集成SAP（GA）和Salesforce（GA）让业务数据留在原系统中、治理和访问来到数据端，外部Iceberg表治理（私有预览）将Horizon Catalog从”Snowflake数据的目录”扩展为”所有Iceberg表的通用治理层”，托管Iceberg复制与故障转移（即将GA）预览客户体验1.6倍至22倍复制性能提升——Databricks和Snowflake在跨引擎治理上的同日发布标志着竞争从Vol.12追踪的”格式层统一”正式升级到”治理层开放”：格式层Iceberg/Delta已统一，目录层Unity Catalog/Horizon Catalog/Polaris在竞争，治理层现在是新战场——谁的目录能让更多引擎以更细粒度执行治理策略，谁就掌握开放湖仓的治理话语权；Google Cloud 6月3日发布Serverless Managed Service for Apache Spark Runtime 3.0——启动时间减少75%适用于SLA敏感型工作负载，Apache Spark 4.x一等支持含Spark Connect解耦客户端-服务器架构，DWS Flex Start模式在GPU不可用时自动排队解决高需求加速器短缺，跨区域流量零额外成本实现多区域高可用且无需传统多区域成本，客户使用量同比增长近一倍——三条动态共同指向DataInfra治理架构的根本性迁移：访问控制从”引擎运行时执行”（每个引擎各自实现ABAC）走向”目录层强制执行”（目录评估策略并返回已授权数据），数据互操作从”搬过来”（ETL到目标平台）走向”就地治理”（治理和访问来到数据端），云托管引擎从”兼容新版本”走向”深度集成新架构”（Spark Connect解耦、GPU调度、多区域零成本）。

Cross-Engine ABAC vs. Iceberg REST Scan Plan API：治理执行从引擎回到目录

事件概述

6月2日，Databricks和Snowflake在同一天发布了基于Iceberg REST Catalog的跨引擎治理方案——Databricks推出Cross-Engine ABAC（Beta），Snowflake在Interoperable Lakehouse架构博客中发布Iceberg REST Scan Plan API（私有预览）。两者的核心思路高度一致：在Iceberg REST Catalog层评估访问策略，将已授权的扫描计划返回给查询引擎，引擎无需理解或实现策略逻辑。但架构表述和路径有所不同。

Databricks Cross-Engine ABAC解决的核心问题是：开放湖仓实现了数据互操作（任何引擎可读Iceberg/Delta表），但治理能力仍然孤立——行级过滤器和列掩码被限制在各个引擎的运行时内，安全团队要么在每个引擎中手动复制策略（难以保持同步），要么维护多个数据副本（成本和一致性风险），要么授予过于宽泛的访问权限（安全风险）。Cross-Engine ABAC通过Unity Catalog的Iceberg REST Catalog Scan API消除这一权衡：在Unity Catalog中定义一次ABAC策略（基于标签的行过滤器、列掩码、SQL UDF），外部引擎查询时Unity Catalog评估策略并返回过滤后的扫描计划——仅包含用户有权访问的数据文件。当前支持Apache Spark（通过Iceberg-Spark和Delta-Spark连接器），DuckDB和Starburst（Trino商业版）即将支持。

Snowflake的Iceberg REST Scan Plan API走相同的路径但表述不同：外部引擎通过Iceberg REST Catalog协议向Horizon Catalog发送扫描请求，Horizon Catalog评估用户的权限和所有适用的访问策略（行级访问控制、动态数据掩码），返回一个授权的扫描计划。同时发布的Snowflake Connector for Apache Spark（GA）为Spark用户提供生产就绪的策略执行。两家的方案都基于Iceberg REST Catalog的开放规范，不与特定连接器绑定——任何Iceberg REST客户端都可支持。

技术解析

• Databricks Cross-Engine ABAC执行流程：①外部引擎通过Iceberg REST Catalog Scan API向Unity Catalog发送数据扫描请求 → ②Unity Catalog评估用户权限和所有适用的ABAC策略（行过滤器、列掩码） → ③Unity Catalog返回过滤后的扫描计划（仅包含用户有权访问的数据） → ④引擎针对过滤后的文件执行查询。关键设计：策略评估在目录层完成，数据在到达引擎前已被过滤——引擎无需理解策略逻辑，即使引擎没有原生治理运行时也能工作。
• Databricks支持的策略类型：行过滤器（基于标签的规则过滤行）、列掩码（隐藏或转换敏感列值）、SQL UDF（自定义函数实现复杂访问逻辑）。所有策略在Unity Catalog中定义一次，通过Iceberg REST Scan API跨引擎执行。当前支持Spark（通过Iceberg-Spark和Delta-Spark连接器），DuckDB和Starburst即将支持——这意味着Vol.13报道的DuckDB-Iceberg扩展在”完整操作Iceberg”之后，下一步是”受管地操作Iceberg”。
• Snowflake Iceberg REST Scan Plan API：与Databricks使用相同的Iceberg REST Catalog机制。外部引擎查询Snowflake托管Iceberg表时，Horizon Catalog评估行级访问控制和动态数据掩码策略，返回授权扫描计划。Snowflake Connector for Apache Spark已GA，为Spark用户提供生产级策略执行。私有预览阶段。
• Snowflake外部Iceberg表治理：Horizon Catalog不仅治理Snowflake托管Iceberg表，还可治理外部Iceberg表——通过Horizon Iceberg REST Catalog API进行读写操作。这使Horizon Catalog从”Snowflake数据的目录”（Vol.14-15的定位）扩展为”所有Iceberg表的通用治理层”——与Unity Catalog的定位直接对标。
• 架构差异：Databricks的方案强调”集中式强制执行”（centralized enforcement）——目录评估策略、过滤数据，引擎无感知；Snowflake的方案同时提供”集中式强制执行”和未来的”元数据交换”（metadata exchange）——目录间共享治理元数据，引擎本地强制执行。Databricks博客明确了长期规划：Apache Iceberg社区的标签共享提案将允许引擎在本地强制执行策略——两种方法（集中式+元数据交换）将并行发展。
• 与Vol.12-15的治理主线的演进：Vol.12报道Databricks Iceberg v3 GA时判断”格式层功能差距已被弥合，竞争转向目录层”；Vol.14报道Snowflake Cortex AISQL将AI操作符注入SQL引擎；Vol.15报道Horizon Context从数据目录走向AI理解层。本期Cross-Engine ABAC和Scan Plan API将竞争推向更深一层——不是”谁的目录能管理更多数据”（管理广度），而是”谁的目录能在更多引擎上强制执行更细粒度的策略”（治理深度）。目录层的竞争正式从”发现和注册”走向”强制执行和互操作”。

行业影响

Databricks和Snowflake在同一天发布基于相同开放标准（Iceberg REST Catalog）的跨引擎治理方案，这不是巧合——治理执行从”引擎运行时”迁移到”目录层”是开放湖仓架构的必然演进。当数据格式统一为Iceberg/Delta后，任何引擎都能读取数据；但读取能力带来的是治理缺口——如果任何引擎都能读，谁确保每个引擎都执行相同的访问策略？此前的答案是”每个引擎各自实现ABAC”，但策略不一致、同步困难、运维成本高昂。Cross-Engine ABAC和Scan Plan API给出了新的答案：目录层评估策略、引擎执行已授权数据——治理不再依赖引擎的善意（每个引擎都正确实现策略），而是由目录层保证（引擎收到的数据已经是被授权的）。

这与Vol.14报道的Cortex AISQL和Vol.15报道的Horizon Context形成递进关系：Cortex AISQL解决”AI如何查询数据”（操作层），Horizon Context解决”AI如何理解数据”（语义层），Cross-Engine ABAC/Scan Plan API解决”AI如何被授权访问数据”（治理层）。三层组合让AI代理在开放湖仓中”既能查、又懂含义、还受管控”——这是开放数据架构走向企业生产就绪的最后一公里。

DuckDB即将支持Cross-Engine ABAC尤其值得关注——Vol.13报道DuckDB-Iceberg从”只读”走向”完整操作”，Cross-Engine ABAC将让DuckDB进一步从”无管控操作”走向”受管控操作”。当轻量级嵌入式引擎也能通过Iceberg REST Catalog获得企业级治理能力时，“轻量级=无治理”的假设被打破——治理不再是重型平台的专利，而是开放目录的标配。

相关链接

• Introducing Cross-Engine ABAC
• Build the Interoperable Lakehouse: Agency Over Your Data

---

Snowflake Parquet Direct与Zero-Copy集成：数据互操作从”搬过来”走向”就地治理”

事件概述

6月2日，Snowflake在Interoperable Lakehouse架构博客中发布多项数据互操作新功能，核心逻辑是从”将数据搬到Snowflake”转向”将治理和访问带到数据端”。Parquet Direct（私有预览）让现有Parquet文件无需格式转换即享Iceberg级目录管理、治理策略和元数据能力——消除”Parquet湖”到”Iceberg湖”迁移的最后障碍。Zero-Copy集成SAP（GA）和Salesforce（GA）让业务数据留在原系统中，Snowflake直接查询和治理，无需ETL管道。外部Iceberg表治理（私有预览）将Horizon Catalog扩展为所有Iceberg表的通用治理层。托管Iceberg复制与故障转移（即将GA）基于日志的复制引擎实现1.6倍至22倍性能提升。Google Cloud Lakehouse集成GA实现自动表发现和跨云读写。

技术解析

• Parquet Direct——消除格式迁移障碍：现有Parquet文件无需转换为Iceberg格式即可获得Iceberg级的目录管理能力——包括Horizon Catalog的治理策略、分类、血缘、元数据管理和查询优化。这解决了开放湖仓采纳的经典困境：企业有大量现有Parquet数据（数据湖的默认格式），迁移到Iceberg需要全量格式转换（重写所有数据文件+生成元数据），成本和风险令人生畏。Parquet Direct让这些文件”就地”Iceberg化——不移动数据，不转换格式，但获得Iceberg的管理和治理能力。这与本期主题1的Cross-Engine ABAC形成互补：ABAC解决”跨引擎治理执行”，Parquet Direct解决”跨格式治理管理”——两者共同让治理从平台特定走向数据特定。
• Zero-Copy集成——业务数据的就地治理：SAP（GA）和Salesforce（GA）让业务数据留在原系统中，Snowflake通过零复制集成直接查询。Workday（私有预览）和AVEVA/IBM（新合作）扩展了覆盖面。这些集成保留业务定义和上下文，数据AI就绪。核心价值：业务系统（ERP/CRM/HR）的数据不需要先ETL到数据平台再分析——治理和分析直接来到业务数据端。这与传统ETL模式”数据搬到平台→平台治理→平台分析”的方向相反：“治理和查询来到数据端→数据留在原系统→业务上下文自动保留”。
• 外部Iceberg表治理——Horizon Catalog的边界扩展：此前Horizon Catalog治理Snowflake托管Iceberg表（Vol.14-15报道的Cortex AISQL/CoCo/Horizon Context都在Snowflake托管表上运行）。外部Iceberg表治理将Horizon Catalog扩展到非Snowflake托管的Iceberg表——通过Horizon Iceberg REST Catalog API进行读写操作和策略执行。结合本期主题1的Scan Plan API，Horizon Catalog从”Snowflake数据的目录”（管理Snowflake内的数据）走向”所有Iceberg表的治理层”（管理任何位置的Iceberg数据）。
• 托管Iceberg复制与故障转移：扩展Snowflake账户复制到托管Iceberg表。基于日志的复制引擎（公开预览）仅应用需要更新的内容，预览客户体验1.6倍至22倍的复制性能提升，降低关键工作负载的RPO。这对企业级Iceberg部署是关键能力——此前Iceberg表的跨区域复制需要自建方案或依赖对象存储复制。
• Google Cloud Lakehouse集成GA：自动表发现和跨云读写，Hologres等Google Cloud数据可直接在Snowflake中查询和治理——这回应了本期阿里云Hologres也在做”SQL调用AI”的竞争态势。
• Catalog Linked Databases（即将GA）：共享联合目录，让数据共享跨越Snowflake账户边界。任何IRC兼容引擎可消费数据共享（公开预览），无需Snowflake账户——进一步开放Snowflake数据生态。

行业影响

Parquet Direct的深层意义不是”又一个格式转换工具”，而是数据互操作理念的范式变更——从”将数据搬到平台”走向”将平台能力带到数据端”。此前数据湖仓的采纳路径是：选择平台→迁移数据到平台格式→在平台上治理和分析。Parquet Direct和Zero-Copy集成反转了这个路径：数据留在原处→平台的治理和分析能力覆盖到数据端。这个反转的驱动力与本期主题1一致——当格式层统一为Iceberg后，竞争从”谁的数据格式更好”转向”谁的治理和智能能覆盖更多数据”。

Parquet Direct直接回应了Vol.7报道的Apache Iceberg 1.11.0和Vol.12报道的Databricks Iceberg v3 GA所建立的格式层统一趋势——当Iceberg成为行业标准格式后，现有Parquet数据的Iceberg化不再是”迁移”问题而是”管理”问题。Parquet Direct的”就地Iceberg化”让企业在不承担迁移风险的前提下获得Iceberg的管理收益，降低了格式统一的理论门槛到实践门槛之间的差距。

Zero-Copy SAP/Salesforce GA与Vol.14报道的Openflow GA形成互补——Openflow解决”如何将数据摄入Snowflake”（流式/批量摄入），Zero-Copy解决”如何在不摄入的情况下使用数据”（就地查询）。两者不是替代关系而是并存：实时需要的数据用Openflow持续摄入，偶尔需要的业务数据用Zero-Copy按需查询。

相关链接

• Build the Interoperable Lakehouse: Agency Over Your Data
• Snowflake Horizon Catalog Press Release

---

Google Cloud Serverless Spark Runtime 3.0：云托管Spark进入4.x时代

事件概述

6月3日，Google Cloud发布Serverless Managed Service for Apache Spark Runtime 3.0。这是该服务自推出以来的代际升级，优先考虑速度、简洁性和可靠性。核心改进包括：启动时间减少75%适用于SLA敏感型工作负载、Apache Spark 4.x一等支持（含Spark Connect解耦架构）、DWS Flex Start模式解决GPU可获得性问题、跨区域网络流量零额外成本实现多区域高可用。Google Cloud表示，自推出以来Managed Service for Apache Spark的客户使用量同比增长近一倍。

技术解析

• 75%启动加速：通过优化服务端初始化流程，启动时间减少75%，适用于标准和高级层级。无需代码或配置更改，无额外成本。这对SLA敏感型工作负载（如实时仪表板数据刷新、定时报表生成、交互式Notebook会话）至关重要——此前Serverless Spark的启动延迟是其对比自建Spark集群的主要劣势之一，75%加速显著缩小了这一差距。这与本期主题1和2的”治理即服务”理念形成互补——治理能力通过目录层自动提供（无需引擎配置），启动性能通过服务端优化自动提升（无需用户调优）。
• Spark 4.x一等支持：支持当前和即将推出的Apache Spark 4.x创新，包括Spark Connect——解耦的客户端-服务器架构，支持从任何客户端远程连接。这是Vol.7报道的Spark 4.1+Databricks Runtime 18 Beta在云端落地的延续。Spark Connect的解耦架构让开发者可以在本地IDE中编写Spark代码、远程在Serverless Spark上执行——开发体验与执行效率兼得。
• DWS Flex Start——GPU可获得性：支持动态工作负载调度器（Dynamic Workload Scheduler）Flex Start模式。当GPU不可用时（如NVIDIA A100和L4高需求加速器），自动排队客户请求而非返回失败。提高延迟敏感型AI/ML工作负载的可靠性——此前GPU不可用时任务直接失败需要重试，Flex Start将失败转为排队，减少运维干预。这与Vol.8-9追踪的AI推理基础设施GPU利用率优化方向一致——GPU资源调度从”可用即分配、不可用即失败”走向”不可用时排队等待”。
• 零成本多区域高可用：默认自动在单个区域内的多个可用区分配执行节点。跨区域网络流量零额外费用——提供高可用性而无传统多区域成本。这对全球企业的Spark工作负载部署是重要简化——此前跨区域Spark需要自建VPC对等连接和流量成本预算，Runtime 3.0将其变为默认行为。
• 零配置快速入门：自动配置必要的IAM角色和权限、启用私有Google访问和系统防火墙策略、简化API管理流程。减少从创建项目到运行第一个工作负载的时间。

行业影响

Serverless Spark Runtime 3.0的深层意义不是”又一个Spark托管服务升级”，而是云托管Spark从”兼容新版Spark”走向”深度集成新架构”的代际跃迁。此前云托管Spark的升级模式是”Spark出新版→云服务跟进支持”，Runtime 3.0在此基础上做了更深度的集成：Spark Connect解耦架构让客户端-服务器交互模式变为原生、DWS Flex Start将GPU调度与Spark工作负载管理整合、零成本多区域让跨区域部署从配置选项变为默认行为。

这与Vol.7报道的Spark 4.1在自建集群上的能力发布形成互补——Spark 4.1定义了引擎层的新能力（SDP/RTM/SQL Scripting），Runtime 3.0在云托管层将这些能力与云平台的服务（GPU调度/多区域/Serverless启动）深度整合。Vol.10报道的阿里云Hologres CLI & Skills从”AI代理操作数据仓库”角度做云原生整合，Runtime 3.0从”云托管Spark深度集成”角度做同样的事——云托管不再是简单包装开源软件，而是将开源能力与云平台服务深度编织。

启动时间减少75%直接对标AWS EMR Serverless和Azure Synapse Spark——Serverless Spark的核心竞争力不是Spark本身（所有云都用同样的开源Spark），而是启动速度、资源调度效率和多租户隔离。75%启动加速让Serverless Spark在交互式和SLA敏感型场景的竞争力显著提升。

相关链接

• What’s new in serverless Managed Service for Apache Spark

---

编者评

第十六期的三条动态，将Vol.12以来追踪的”目录层竞争”主线推进到新的深度。Vol.12判断”格式层功能差距已被弥合，竞争转向目录层”；Vol.14-15看到目录层竞争从”注册发现”扩展到”语义理解”（Horizon Context/Fabric IQ）；本期看到目录层竞争进一步深化为”治理执行”——目录不再只是”告诉引擎数据在哪里”，而是”控制引擎能看到什么”。

第一个维度是治理执行架构的根本性迁移：从”引擎运行时”到”目录层”。 Databricks Cross-Engine ABAC和Snowflake Scan Plan API使用相同的Iceberg REST Catalog机制，在数据到达引擎前由目录评估策略、返回已授权数据。这不是治理策略的增量改进，而是治理执行点的根本性迁移——此前ABAC策略在引擎运行时内执行（每个引擎各自实现），现在ABAC策略在目录层执行（所有引擎共享同一个策略评估点）。执行点的迁移带来三个根本变化：①策略一致性——定义一次处处执行，消除了跨引擎策略同步的永恒难题；②引擎无关性——即使引擎没有原生治理运行时也能受管控，DuckDB这样的轻量级引擎也可以获得企业级治理能力；③零信任基线——引擎收到的数据已经是被授权的，不需要信任引擎的善意。

第二个维度是数据互操作理念的范式变更：从”搬过来”到”就地治理”。 Parquet Direct让现有Parquet文件无需迁移即享Iceberg治理，Zero-Copy集成让SAP/Salesforce数据留在原系统即受Snowflake治理。这个范式变更的核心逻辑是：当格式层统一后，数据在哪里不再是治理的前提条件——此前只有迁移到平台格式的数据才能被治理，现在任何格式的数据都可以被治理。这与主题1形成互补：主题1解决”跨引擎治理执行”（水平维度——同一个数据在不同引擎上受相同策略管控），主题2解决”跨格式治理管理”（垂直维度——不同格式的数据受相同治理体系管理）。两个维度组合，治理从”平台围墙内的特权”变为”开放目录上的标配”。

第三个维度是云托管引擎的代际升级：从”兼容新版本”到”深度集成新架构”。 Runtime 3.0不只是支持Spark 4.x，而是将Spark 4.x的新架构能力（Spark Connect解耦）与云平台服务（GPU调度/多区域/Serverless启动）深度整合。这与主题1和2的方向一致——治理能力通过目录层自动提供（不需要引擎配置），启动性能通过服务端优化自动提升（不需要用户调优），GPU调度通过平台集成自动管理（不需要运维干预）。当基础设施能力从”需要手动配置”变为”平台自动提供”时，用户的操作从”管理基础设施”简化为”定义业务逻辑”——治理策略在目录中定义一次自动执行，数据互操作在目录中注册一次自动可用，Spark工作负载提交一次自动优化运行。

将十六期主线串联，一个完整的竞争图谱正在收拢：格式层统一完成（Iceberg/Delta），目录层竞争从”注册发现”深化到”治理执行”和”语义理解”（Unity Catalog/Horizon Catalog/Cross-Engine ABAC/Scan Plan API/Horizon Context/Fabric IQ），数据互操作从”搬过来”走向”就地治理”（Parquet Direct/Zero-Copy），云托管从”兼容新版”走向”深度集成”（Runtime 3.0/Spark Connect/DWS）。 竞争的终极焦点不是”谁的功能更多”或”谁更快”，而是谁能让数据在格式、引擎、平台、云之间的每一步流动都自动获得正确的治理、语义和性能——无需手动配置，无需数据迁移，无需引擎适配。Cross-Engine ABAC回答了”治理如何自动跟随数据”，Parquet Direct回答了”治理如何无需迁移即达”，Runtime 3.0回答了”计算如何无需调优即优”。当这三个”即”同时实现时，开放湖仓从架构愿景走向工程现实。