关于《Unity Catalog: Open and Universal Governance for the Lakehouse and Beyond》的学术报告

本文《Unity Catalog: Open and Universal Governance for the Lakehouse and Beyond》由 Ramesh Chandra, Haogang Chen, Ray Matharu 等人共同撰写，作者单位均为 Databricks Inc., San Francisco, CA, United States。该论文发表于2025年6月22日，收录于 SIGMOD/PODS ‘25: International Conference on Management of Data 会议的配套文集（SIGMOD-Companion ‘25）中，是ACM的开放获取论文。

研究的学术背景 本研究隶属于数据管理系统领域，具体聚焦于数据湖仓（Lakehouse）架构中的元数据目录（Catalog）系统。随着企业日益采用数据湖仓架构来管理其数据资产，目录在其中扮演着核心角色，负责组织元数据、提供统一的资产命名空间，并支撑数据治理。然而，作者指出现有的湖仓目录（如广泛使用的Hive Metastore）存在显著局限性，主要包括：治理策略不一致（例如通过目录名访问与通过原始存储路径访问的权限控制可能不同）；互操作性狭窄且非开放；缺乏对数据发现（如血缘追踪、基于标签的搜索）的原生支持。此外，现代企业需求已超越传统的表格数据，扩展至非结构化数据（如图像、文本）和AI模型等资产，而现有目录无法有效管理和治理这些新型资产。

基于上述背景，本研究旨在解决这些关键挑战，并提出了一个理想湖仓目录应满足的三个核心要求：一致性治理、普遍性（支持多样资产类型、多种客户端、跨云环境）和高性能。为了满足这些要求，作者所在的Databricks团队设计并开发了Unity Catalog (UC)。

论文主要观点及论证

一、 UC的核心设计挑战与架构概览 论文首先系统性地阐述了设计UC所面临的四大关键挑战：1) 统一的访问控制：确保无论通过目录名还是底层存储路径访问资产，治理策略都一致。2) 支持多样化的资产类型：超越表格，涵盖非结构化数据、ML模型等。3) 支持外部访问：允许不兼容原生存储格式的外部工作负载（如仅支持Apache Iceberg的引擎）访问UC管理的数据，而无需复制数据。4) 内置发现目录功能：提供高效的元数据索引、血缘追踪和搜索能力，而无需依赖独立的外部发现系统。

针对这些挑战，UC采用了目录与引擎分离的原则。UC作为一个独立的服务，通过开放的REST API与各种计算引擎（如Apache Spark, Trino）交互。这种分离带来了两大核心优势：增强的可管理性与安全性，UC作为中心化的治理权威，成为所有资产元数据、命名空间和访问控制策略的唯一真实来源；提升互操作性，不同的引擎可以基于同一套元数据和治理策略工作，用户可以根据工作负载选择最佳引擎。

二、 UC的通用数据模型与资产类型扩展机制 为了成为一个通用目录，UC设计了分层的服务架构和一个可扩展的实体-关系数据模型。底层是一个通用的持久化层，为所有资产类型提供基础的CRUD操作、父子关系查找、权限检索等功能。其上是一个适配器层，允许开发者通过声明式清单（manifest）添加新的资产类型，定义其操作、权限、生命周期管理逻辑等。核心服务层则利用这个通用模型，为所有资产类型统一实现命名空间管理、生命周期、访问控制、审计日志等关键功能。这种设计使得增加新资产类型变得相对直接，核心行为的一致性得到保证。

论文以将UC扩展为MLflow模型注册表为例，具体说明了这一机制的可行性。通过创建一个名为“registered_model”的新资产类型，并利用UC的通用功能（命名空间组织、CRUD API、权限管理、云存储凭证下发、审计等），UC可以完整地支持ML模型的版本管理。同时，只需实现MLflow框架中特定的抽象接口（RestStore和ArtifactRepository），即可让现有的MLflow客户端无缝接入UC，从而获得UC提供的统一治理能力。这证明了UC能够有效管理非表格类AI资产。

三、 实现统一和细粒度访问控制的设计 UC通过两项核心机制确保统一的访问控制。首先，它强制执行 “一路径一资产”原则，确保云存储中的每个对象最多只映射到一个UC资产，消除了通过不同路径访问同一数据时可能出现的策略歧义。其次，UC采用了凭证下发模型。客户端（计算引擎）不直接拥有云存储的长期访问凭证。当需要访问数据时，引擎向UC请求特定资产的临时、降权的访问凭证。如果请求是基于存储路径的，UC会先将路径解析为对应的唯一资产，验证请求者的权限，然后下发仅限该资产存储路径的临时凭证。这确保了无论是通过逻辑名（catalog.schema.table）还是物理路径访问，都经过相同的权限验证。

对于更精细的控制需求，UC支持细粒度访问控制（FGAC），包括行级过滤和列级脱敏。然而，FGAC的实现需要“可信引擎”的协作。UC在元数据响应中提供FGAC规则，由可信引擎（如Databricks Runtime，其用户代码执行环境被LakeGuard系统隔离）在查询处理时负责应用这些规则。对于不可信引擎（如某些需要GPU访问的ML工作负载），UC支持通过一个独立的数据过滤服务来安全地执行涉及FGAC的查询。此外，论文还提到UC即将支持基于属性的访问控制（ABAC），允许管理员基于资产标签等元数据动态定义高层策略，实现更灵活、可扩展的治理。

四、 支持外部访问与发现目录功能 为实现开放性，UC通过提供多种开放接口来支持外部访问。例如，通过Delta Sharing协议与外部Delta Sharing客户端共享数据；通过Delta Uniform功能，允许外部的Apache Iceberg和Apache Hudi客户端读取UC中的Delta Lake表；通过实现Iceberg REST Catalog接口，让Iceberg客户端能够与UC目录交互。这些机制使外部生态系统无需数据拷贝即可访问UC管理的数据。

UC在设计之初就考虑了发现目录功能，避免了传统上将运营目录（Operational Catalog）与发现目录（Discovery Catalog）分离所带来的元数据新鲜度、同步开销和访问控制复杂性等问题。UC核心服务会发布元数据变更事件流，供第二层服务（如搜索、血缘）异步消费以更新索引。同时，UC提供高效的授权API，让发现服务在展示搜索结果或血缘关系时，能够根据UC中定义的策略过滤用户无权查看的资产。血缘信息则由计算引擎通过UC提供的API主动提交，实现了端到端的数据追踪。

五、 性能优化设计与实践验证 作为一个处于所有工作负载关键路径上的服务，UC必须实现高性能。论文分析了UC工作负载的特点：元数据量相对数据量很小，读多写少（约98%的API调用为读操作），操作按元存储（Metastore）范围界定，且具有良好的时空局部性（例如，90%的容器资产在10秒内被重复访问）。基于这些特点，UC实施了多项优化：

1. 批处理：将单个查询所需的所有元数据请求合并到一个批处理的API调用中，减少网络往返。
2. 多层缓存：对于从云提供商获取的临时凭证等不可变或弱一致性元数据，使用TTL缓存。对于表提交信息等需要强一致性的可变元数据，UC实现了一个直写式多版本内存缓存。该缓存以元存储版本为基线，保证了元存储级别的快照读隔离和可串行化写隔离，同时通过惰性淘汰机制管理内存使用。缓存可以推送到客户端（引擎），进一步降低高频访问元数据的延迟。

论文通过实际客户使用数据和性能基准测试验证了UC的设计有效性。数据显示，UC管理着超过1亿张表、55万个卷（Volume）、40万个模型，每秒处理约6万次API请求。性能对比测试显示，尽管UC作为远程服务且提供了比Hive Metastore更丰富的治理功能，但其在TPC-DS和TPC-H基准测试中的端到端性能与最佳配置（本地模式）下的HMS相当。缓存机制带来了显著的吞吐量提升和延迟降低（3到40倍）。此外，UC还催生了新的应用场景，如预测性优化，通过分析UC中的元数据自动优化表文件布局，实现了高达20倍的查询延迟提升。

六、 研究的价值与意义 本文系统地介绍了Unity Catalog的设计、实现与实践，其价值主要体现在以下几个方面：

1. 学术与实践的桥梁：论文深入剖析了现代数据湖仓架构中元数据目录这一关键但研究不足的组件的实际挑战，并提出了一个系统性的解决方案。它对“一致性治理”、“通用性”、“目录-引擎分离”等设计原则的论述，对学术界和工业界构建类似系统具有重要的参考价值。
2. 推动开放标准与互操作性：UC的核心API、服务器和客户端实现自2024年6月起已开源。通过支持Delta Sharing、Iceberg REST Catalog等多种开放协议，UC致力于打破数据孤岛，促进不同工具和引擎之间的互操作，这与当前数据生态系统开放化的发展趋势一致。
3. 重新定义数据治理的范畴：UC将治理的范围从传统的表格数据扩展到非结构化数据和AI模型，并通过统一的模型和API进行管理，回应了企业向AI和数据驱动转型过程中对统一治理平台的迫切需求。
4. 高性能工程实践的典范：论文详细阐述了如何针对特定的工作负载模式（读多写少、强局部性、强一致性要求）设计高效的内存缓存、批处理和一致性模型，这些工程优化策略对于构建高可用、低延迟的分布式元数据服务具有普适性的指导意义。

本文不仅是对Unity Catalog这一工业级系统的技术报告，更是一篇关于如何设计下一代开放、通用、高性能数据治理平台的深度研究，为数据管理领域在湖仓时代面临的元数据与治理挑战提供了重要见解和可行路径。