本文旨在向研究人员介绍一篇名为《Databricks LakeGuard: Supporting Fine-Grained Access Control and Multi-User Capabilities for Apache Spark Workloads》的学术论文。该论文由来自Databricks Inc.的 Martin Grund、Stefania Leone、Herman van Hövell、Sven Wagner-Boysen、Sebastian Hillig、Hyukjin Kwon、David Lewis、Jakob Mund、Polo-Francois Poli、Lionel Montrieux、Othon Crelier、Xiao Li、Reynold Xin、Matei Zaharia、Michalis Petropoulos 以及 Thanos Papathanasiou 共同完成。该研究发表于2025年6月22日，收录于ACM SIGMOD/PODS ‘25国际数据管理会议的会议录中。这是一篇研究性论文，报告了一项原创性的系统设计与实现工作，符合前述报告类型a的要求。以下是对该研究的全面报告。

背景与动机

该研究属于数据工程与系统软件领域，特别是大数据处理和治理的交叉方向。随着企业数据量激增和数据分析场景多样化，如何在复杂的数据治理要求下实施精细化的访问控制，成为一个日益严峻的挑战。传统的数据仓库能够通过动态视图、行级过滤（row-level filter）和列掩码（column mask）等机制实现细粒度访问控制，但这些特性难以在Apache Spark这类大数据处理框架中高效、安全地实现。Apache Spark为数据科学家和工程师提供了使用Python、Scala、R等多种语言编程的灵活性，但这也带来了安全风险：用户代码与Spark引擎运行在同一Java虚拟机内，可以直接访问底层数据。这导致了一个“治理碎片化”的困境：细粒度访问控制只能强制执行于SQL工作负载，而对于使用Spark框架的大数据处理，往往只能依赖文件级别的粗粒度权限控制，或者通过牺牲利用率来隔离用户。

因此，该研究的目标是设计并实现一个统一的治理系统，能够在企业内部所有数据和AI工作负载上，无论其使用何种语言或计算框架，都能一致、高效、安全地执行细粒度数据访问策略。研究旨在克服现有解决方案的碎片化问题，支持多用户共享计算资源，同时提供与数据仓库相当的丰富访问控制策略。

系统设计与实现流程

这项研究并非传统的实验科学，而是一项系统性工程研发，其“工作流程”体现在系统架构的设计、核心组件的实现与集成中。研究的核心成果是名为“Databricks LakeGuard”的系统。其实现流程主要包含以下几个关键步骤和组件：

1. 问题定义与架构设计：研究团队首先深入分析了在企业Apache Spark工作负载中实施细粒度访问控制所面临的具体挑战。这包括：(1) 数据访问权限从“集群绑定”向“用户绑定”的转变需求；(2) 在存在用户自定义函数等用户代码时，强制执行细粒度访问控制的安全挑战；(3) 实现多用户共享集群计算资源所需的安全隔离需求。基于这些分析，研究提出了一个双层隔离架构：一方面将用户应用与Spark引擎分离，另一方面将用户代码与核心引擎隔离。

2. 核心组件一：Spark Connect API的开发与集成。这是研究的基础性工作。研究团队向Apache Spark开源社区贡献了Spark Connect，这是一种类似JDBC的查询执行协议。其工作原理如下：

   • 协议设计：定义了一种基于Google Protocol Buffers的语言无关、版本兼容的协议格式，用于封装Spark DataFrame API操作形成的逻辑查询计划。
   • 客户端与服务端分离：用户应用（如笔记本代码）在“客户端”运行，通过gRPC协议将序列化的查询计划发送给远程的“Spark Connect服务”。服务端运行在Spark Driver上，负责解析计划、执行常规的Spark查询优化与处理流程。
   • 结果返回：查询结果通过Arrow IPC格式流式传输回客户端。这个设计彻底解耦了客户端应用与Spark引擎，确保了版本兼容性，并为后续的安全隔离奠定了基础。

3. 核心组件二：用户代码隔离机制的实现。这是保证细粒度访问控制安全性的关键技术。由于用户代码可能以UDF或应用程序逻辑的形式存在，并需要访问数据，必须确保其无法绕过访问策略。

   • 容器化沙箱：LakeGuard利用Databricks集群管理器中的容器隔离技术，在Spark执行器节点上为运行用户代码创建安全的沙箱环境。当查询需要执行UDF时，Spark进程会通过一个“调度器”组件与集群管理器交互，请求创建一个新的沙箱。
   • 安全执行：用户代码在沙箱内执行，与宿主机的Spark引擎进程完全隔离。沙箱拥有独立的网络命名空间，其出口网络流量受到动态控制，防止数据外泄。
   • 信任域管理：系统支持从Unity Catalog中调用的、由不同用户创建的UDF。LakeGuard引入了“信任域”概念，将属于同一用户的代码分组执行，防止不同用户代码在同一沙箱内产生侧信道攻击。
   • 查询优化集成：为了实现性能优化，系统引入了查询优化规则，尽可能将多个UDF调用融合到尽可能少的沙箱中执行，以减少开销，但信任域之间的代码不会融合。

4. 核心组件三：与Unity Catalog的深度集成。Unity Catalog是Databricks的统一治理目录，管理表、文件、ML模型等多种资产的访问权限。LakeGuard的核心在于将此目录的治理策略在计算层强制执行。

   • 权限验证：Spark Driver在处理查询时，会向Unity Catalog请求表元数据和访问凭证。所有访问凭证的请求都与发出请求的用户身份关联，实现了“用户绑定”的权限。
   • 策略注入：对于定义了行级过滤或列掩码的表，查询规划器会在逻辑计划中自动注入安全的视图或过滤条件，确保在数据读取时即应用策略。

5. 应对特殊场景：外部细粒度访问控制的实现。部分工作负载需要特权访问底层机器，例如使用GPU的机器学习任务，无法在沙箱中运行。为此，LakeGuard设计了外部细粒度访问控制机制。

   • 查询重写：当检测到工作负载运行在需要特权的“专用计算”集群上时，系统会对查询计划进行动态重写。
   • 远程子查询执行：将涉及受治理数据表的部分查询逻辑（扫描、过滤、投影等）包装成一个远程扫描操作符。这个子查询会通过Spark Connect协议提交给Databricks的无服务器Spark服务执行。
   • 结果回传：无服务器Spark端点从Unity Catalog获取完整策略并安全执行子查询，将结果（小型结果内联返回，大型结果持久化到云存储）传回原集群。这使得即使在没有本地隔离能力的专用集群上，也能透明地强制执行精细的治理策略。

6. 性能评估流程：研究对用户代码隔离机制的性能开销进行了量化评估。

   • 实验对象：在两个简单的Python UDF场景下进行测试：一个执行简单的加法运算（评估调用开销），一个执行100次SHA256哈希计算（评估CPU密集型开销）。
   • 实验环境：使用由3个AWS r6id.xlarge实例节点组成的Databricks集群。
   • 测试方法：比较在启用隔离的“标准计算”集群与未启用隔离的“专用计算”集群上，执行相同查询的耗时。
   • 数据分析：计算相对开销百分比，并观察沙箱启动的“冷启动”时间以及UDF调用融合对性能的影响。

主要结果与发现

研究的成果主要体现在系统功能、性能和安全性的验证上。

1. 系统功能完整性：LakeGuard成功实现了设计目标，构建了一个统一的治理系统。结果证明，该系统能够对SQL、Python、Scala、R等多种语言编写的Spark工作负载，在单用户及多用户共享的计算资源上，强制执行包括动态视图、行级过滤、列掩码在内的丰富访问控制策略。与论文中对比的其他平台解决方案相比，LakeGuard是唯一能在所有Spark主要编程语言上实现统一策略执行和多用户能力的系统。

2. 安全隔离有效性：通过Spark Connect和容器化沙箱的组合，LakeGuard实现了客户端应用代码与Spark引擎的物理分离，以及用户执行代码与引擎的安全隔离。这使得即使用户编写了恶意UDF，也无法直接访问Spark JVM中的原始数据、临时凭证或其他用户的数据，从根本上解决了用户代码绕过治理策略的安全隐患。同时，这种隔离为实现安全的多用户集群共享提供了基础。

3. 性能开销可控：性能评估的结果为系统可用性提供了关键数据支持。实验数据显示，对于计算开销极小的加法UDF，在沙箱中运行的最坏情况开销约为10%；对于计算密集型的哈希UDF，开销降至约4.8%。这表明，虽然隔离带来了额外开销，但在典型的Spark工作负载中，UDF执行时间通常只占总运行时间的一小部分，因此整体性能影响是可控且可接受的。此外，沙箱的“冷启动”时间约为2秒，但仅在用户会话中首次调用Python UDF时发生，后续查询可重用现有沙箱，开销被快速摊销。

4. 架构演进的积极影响：研究结果不仅限于LakeGuard本身，还展示了其基础架构Spark Connect带来的更广泛价值。例如，基于此架构的Databricks Connect产品允许开发者从本地IDE远程连接并调试Databricks上的Spark作业，极大提升了开发体验。更重要的是，它催生了真正的“无服务器Spark”产品，实现了计算资源的自动弹性伸缩和高密度多用户共享，显著降低了成本和运营负担。Spark Connect协议提供的版本兼容性也为用户提供了稳定的API接口，缓解了升级痛苦。

这些结果之间逻辑连贯：首先，通过Spark Connect实现客户端分离，为安全隔离创造了条件；其次，基于容器隔离实现用户代码沙箱化，解决了细粒度策略在混合代码环境下的强制执行难题；性能评估结果则验证了该方案的可行性；最终，整个架构的灵活性不仅满足了最初的治理需求，还推动了Spark使用模式的根本性进化。

结论与价值

该研究的核心结论是：通过将Spark Connect客户端-服务器架构与安全的用户代码容器化隔离相结合，可以构建一个能够跨所有数据和AI工作负载统一、高效、安全地实施细粒度访问控制和支持多用户能力的平台系统——Databricks LakeGuard。

其科学价值在于，为解决大数据生态中长期存在的“治理与灵活性”矛盾提供了一个系统性的、可实践的架构范式。它深入研究了在开源、通用计算框架中嵌入企业级安全治理模型所面临的独特挑战，并提出了创新的解决方案，特别是在处理用户自定义代码的安全隔离方面。

其应用价值极为显著。对于企业而言，LakeGuard使得在复杂的数据湖仓架构中实施一致的数据治理成为可能，无需在安全性、灵活性和成本之间做出妥协。它降低了数据泄露风险，简化了合规管理，并通过支持多用户共享计算提高了资源利用率，降低了总体拥有成本。对于Apache Spark社区而言，Spark Connect的引入标志着该框架从集群中心化向解耦的客户端-服务器架构的重大演变，为Spark的未来发展开辟了新的可能性。

研究亮点

1. 创新性的双重隔离架构：研究提出了结合“客户端-服务端分离”和“用户代码沙箱化”的双重隔离机制，这是实现Spark工作负载统一细粒度访问控制的关键创新。它巧妙地将兼容性与安全性问题分解并各个击破。
2. 解决核心安全难题：首次在大规模生产环境中，系统性地解决了在支持任意用户代码的Spark框架内强制执行行/列级别访问控制这一核心安全挑战，填补了该领域的技术空白。
3. 催生新范式：研究不仅是构建了一个治理工具，更是推动Apache Spark使用范式发生转变。其基础工作Spark Connect引领Spark向更灵活、更易集成、更易管理的服务化方向发展，具有深远的行业影响。
4. 工程与开源的结合：研究深度结合了开源贡献与企业级产品化。将核心协议Spark Connect贡献给开源社区，同时基于此构建了具有竞争力的商业产品特性，展现了产学研良性互动的成功案例。

其他有价值内容

论文还展望了未来，认为Spark Connect有望像JDBC标准化数据库访问一样，成为连接Spark计算的标准接口。此外，论文详细对比了LakeGuard与AWS EMR Membrane、AWS Lake Formation、Google BigLake等竞品方案，清晰阐述了各自在统一策略、多用户支持、细粒度方法等方面的优劣，为读者提供了全面的技术格局视野。论文也坦诚讨论了在权衡设计决策时对Substrait等其他协议格式的考量，体现了研究的严谨性。