开放表格式与开放目录的融合：Catalog Commits 正式发布

DATA + AI 峰会 ![Image 3: Data+ai summit promo 6月15–18日|旧金山参加全球最大的数据、应用和AI盛会。立即注册](https://www.databricks.com/dataaisummit?itm_source=www&itm_category=home&itm_page=home&itm_location=navigation&itm_component=navigation&itm_offer=dataaisummit)

产品 2026年5月11日

开放表格式与开放目录的融合：Catalog Commits 正式发布

Catalog Commits 是开放湖仓一体架构的下一步演进

作者：Benjamin Mathew、Michelle Leon、Lukas Rupprecht 和 Ryan Johnson

Catalog Commits 通过将 Delta 与 Iceberg 的目录导向模型对齐，在统一湖仓方面迈出了重要一步。借助 Catalog Commits，目录成为 Delta 表的协调系统，负责管理跨引擎的表发现、访问和状态。

今天，我们很高兴宣布 UC 托管表的 Catalog Commits 正式发布。这是一次重大的平台升级，扩展了 UC 托管表的互操作性，增强了 Unity Catalog 的治理能力，并解锁了包括多语句、多表事务在内的新功能。

在本文中，我们将介绍……

Delta 与 Unity Catalog 如何协同发展
Catalog Commits 解决的问题
Catalog Commits 的工作原理
如何在 Unity Catalog 托管表上启用 Catalog Commits

Delta Lake 与 Unity Catalog 的演进历程

当 Delta Lake 创立时，湖仓架构首先需要在开放的云存储上实现可靠的事务处理。当时，数据目录（catalog）并未被设计用于协调现代数据工作负载，因此 Delta 做出了一个革命性的架构选择：将 ACID 保证直接引入到数据湖的文件系统中。这一基础使得湖仓架构成为可能。

随着湖仓逐渐成为更多团队、计算引擎和 AI 工作负载的权威数据源，跨不同资产的统一治理需求变得至关重要。Unity Catalog 正好填补了这一缺失的治理层：它提供了一个统一的位置，用于发现、保护、审计以及协调跨云平台、数据格式和计算引擎的数据与 AI 资产访问。

Delta Lake 和 Unity Catalog 共同构成了现代湖仓架构的基础。然而，它们最初是并行运作的：Delta 在存储层管理事务状态，而 Unity Catalog 在目录层控制访问权限。这种架构在早期尚可满足需求，但随着企业扩展至更多计算引擎和工作负载，该设计开始引发新的协调挑战。

当前在表与目录之间协调面临的挑战

Delta 最初以文件系统为中心的架构在为数据湖带来事务能力方面非常强大，但它并未针对“目录需在多个计算引擎间持续协调表身份、访问权限和状态”的场景进行设计。随着企业对数据提出更高要求，目录缺乏协调能力的问题暴露出了三大长期存在的挑战：

“脑裂”问题：外部引擎直接向对象存储中的 Delta 表写入数据，会导致目录元数据（如表结构 schema）与实际表状态悄然偏离。
多引擎、多代理访问扩散：每个引擎、工具和代理都可以以不同方式访问表，导致表发现碎片化、审计不一致，并且无法跨系统标准化实施行级或列级访问控制。
跨多表事务协调困难：开放湖仓架构历史上不支持跨越多个表的原子写入操作，因此企业被迫保留传统数据仓库，专门用于处理事务型工作负载。

#### 挑战一：“脑裂”问题——保持治理目录与表状态同步

目前，目录并不参与 Delta 引擎的读写路径。因此，如果某个引擎（如 Apache Flink）想要通过直接写入存储层来修改表结构，目录将无法感知这些变更，从而形成“脑裂”状态，即目录元数据与实际表状态发生偏离。这可能导致静默的元数据漂移，并引发下游数据管道的失败。

展开

#### 挑战二：多引擎、多代理访问扩散

现代企业使用多种引擎和工具进行数据分析、构建数据管道以及驱动 AI 应用。传统上，这些系统通过静态路径直接从对象存储中读取数据。这种方式使工作负载与物理存储紧密耦合，导致表难以被发现。此外，由于每个引擎都直接从存储层读取 Delta 表，而存储层通常仅支持粗粒度的权限控制，因此很难在所有引擎之间实施一致的行/列级治理策略。同样，数据访问审计也支离破碎，因为缺乏统一的访问层来记录跨引擎的操作行为，管理员因而难以全面了解数据的实际使用情况。

企业迫切需要一个集中化的场所来发现、治理和审计其数据资产。随着 AI 代理逐渐成为企业数据的主要消费者，这一需求变得更加紧迫。

#### 挑战三：跨多个表的事务协调

数据仓库类工作负载通常需要多表事务支持，例如原子性地更新 _sales_（销售）和 _inventory_（库存）表，以确保下游读取方始终看到一致的数据视图。然而，Delta Lake 历史上基于文件系统的架构限制了事务只能作用于单个表。结果，即使许多企业希望完全迁移到湖仓架构，也不得不保留传统的数据仓库来处理这类事务型工作负载。

展开

Catalog Commits：开放湖仓的下一代演进

Catalog Commits 是 Delta 表与目录集成的开放标准，它让目录负责协调表访问并追踪最新的表状态。如今，Delta 和 Iceberg 都已转向以目录为中心的设计，客户可以依赖标准化的模型来实现表的发现与治理。要深入了解 Catalog Commits 规范，请阅读 Delta 协议文档，并查看 Unity Catalog 的参考实现。

在 Databricks 平台上，Catalog Commits 可在 UC 管理的 Delta 表上启用。启用后，Unity Catalog 将代理所有表访问请求，为任意计算引擎提供一致的发现和授权模型。这使企业能够真正实现对其数据资产的集中化治理。

展开

目录提交（Catalog Commits） 解决了长期存在的“脑裂”问题、多引擎混乱访问以及多表协调等挑战。

1. 消除脑裂问题： 表状态与目录始终保持同步，因为所有引擎都通过相同的 API 访问表，彻底消除了元数据静默漂移的风险。

解锁外部引擎向 Unity Catalog 管理的 Delta 表写入数据的能力

“传统上，将数据流式传输到受治理的湖仓意味着需要在带外协调目录元数据，并寄希望于不会发生漂移。而目录提交完全消除了这一差距。借助 StreamNative 原生的 Kafka 服务——基于 Ursa 构建的无盘、无主架构——数据可以直接通过 Unity Catalog 流式传输并提交，每一条记录都会作为受治理的数据行落地，并立即可供任何计算引擎查询。”
—— Sijie Guo，StreamNative 联合创始人兼 CEO

2. 解决多引擎访问混乱问题： 所有引擎和代理均通过标准化的目录 API 来解析表，组织不再需要硬编码存储路径或管理粗粒度的文件系统级权限。

实现对所有引擎的一致且增强的治理能力

3. 支持在湖仓上运行传统数仓工作负载： Databricks 引擎与 Unity Catalog 可协调跨多个表的原子写入操作，将多表 ACID 语义引入湖仓，从而支持传统的数据仓库工作负载。

解锁在 Databricks 上执行多表事务的能力

“事务功能结合一系列新的 SQL 特性，如 SQL 脚本和存储过程，使我们能够自信地将最关键的数据仓库工作负载迁移至 Databricks。这些工作负载支撑着我们整个业务的核心分析，而在湖仓上拥有强大的事务保障，堪称变革性的突破。”
—— Gal Doron，AnyClip 数据主管

此外，在 UC 管理的表上启用目录提交后，还可获得以下能力：

全面可审计性：Unity Catalog 集中管理表的元数据和访问策略，团队可通过统一的目录接口查看权限和表所有权，而不再依赖底层存储日志。
自动化的表优化：Unity Catalog 利用其对所有表访问行为的可见性，通过 Liquid Clustering 和 Predictive Optimization 技术，为组织的数据按特定查询模式进行最优布局。
更高性能的基础：Unity Catalog 可直接向引擎提供表级元数据，无需引擎从云存储中拉取，从而消除主要的元数据延迟来源。

上述能力共同使启用了目录提交的 UC 管理表成为现代湖仓最开放、最受控且性能最优的基础。

立即在您的表上启用目录提交

Databricks 上的目录提交现已正式发布！在 Unity Catalog 管理的表上启用该功能后，您将解锁以下特性：

升级的互操作性：外部引擎写入 UC 管理的 Delta 表
更强的治理能力：实现对所有引擎的一致且增强的治理
新功能支持：多语句、多表事务

从数据摄入到黄金层消费，所有读写 UC 管理表的 Databricks 产品现已支持目录提交。包括流式表（Streaming Tables）、Delta Sharing、Zerobus、Lakeflow Connect、AI Gateway、MLflow 和 Lakeflow Job Triggers。同时，生态系统中的多种引擎也已支持目录提交，包括 Delta Spark、Delta Flink、Starburst Trino、DuckDB 和 StreamNative。

任何引擎都可以通过集成 Delta Kernel 轻松支持目录提交。Delta Kernel 是一个共享的 API 库，封装了协议层面的复杂细节，使得连接器只需简单升级版本即可支持最新的 Delta 功能。

创建启用了目录提交的 UC 管理 Delta 表非常简单。使用 Databricks Runtime 16.4+，运行以下命令：

sql

CREATE TABLE main.default.sales_data (
  sale_id BIGINT,
  amount DECIMAL(10,2),
  sale_date DATE
) TBLPROPERTIES ('delta.feature.catalogManaged' = 'supported');

要将现有的 UC 管理 Delta 表升级以启用目录提交，请使用 Databricks Runtime 18.0+ 并运行：

sql

ALTER TABLE main.default.sales_data 
SET TBLPROPERTIES ('delta.feature.catalogManaged' = 'supported');

立即开始使用目录提交，并加入我们的数据与 AI 峰会，了解更多关于构建开放湖仓生态的进展！

将最新文章发送到您的邮箱

订阅我们的博客，即可将最新文章直接收件至您的邮箱。

注册

*

工作邮箱

*

国家国家*

点击“订阅”即表示我理解我将收到 Databricks 的通讯信息，并同意 Databricks 按照其隐私政策处理我的个人数据。

查看所有博客

为什么选择 Databricks

了解详情

客户案例

客户故事

合作伙伴

为什么选择 Databricks

了解详情

客户案例

客户故事

合作伙伴

产品

Databricks 平台

定价

开源项目

集成与数据

产品

Databricks 平台

定价

开源项目

集成与数据

解决方案

Databricks 行业解决方案

跨行业解决方案

数据迁移

专业服务

解决方案加速器

解决方案

Databricks 行业解决方案

跨行业解决方案

数据迁移

专业服务

解决方案加速器

资源

文档

客户支持

社区

学习

活动

博客与播客

资源

文档

客户支持

社区

学习

活动

博客与播客

关于

公司

职业发展

新闻

安全与信任

关于

公司

职业发展

新闻

安全与信任

Databricks 公司

160 Spear 街，15 楼

加利福尼亚州旧金山 94105

1-866-330-0121

[](https://www.linkedin.com/company/databricks)
[](https://www.facebook.com/pages/Databricks/560203607379694)
[](https://twitter.com/databricks)
[](https://www.databricks.com/feed)
[](https://www.glassdoor.com/Overview/Working-at-Databricks-EI_IE954734.11,21.htm)
[](https://www.youtube.com/@Databricks)

查看职位

在 Databricks 工作

[](https://www.linkedin.com/company/databricks)
[](https://www.facebook.com/pages/Databricks/560203607379694)
[](https://twitter.com/databricks)
[](https://www.databricks.com/feed)
[](https://www.glassdoor.com/Overview/Working-at-Databricks-EI_IE954734.11,21.htm)
[](https://www.youtube.com/@Databricks)

我们重视您的隐私

Databricks 使用 Cookie 和类似技术来增强网站导航、分析网站使用情况、个性化内容和广告，详情请见我们的 Cookie 声明。要禁用非必要 Cookie，请点击“拒绝全部”。您也可以通过点击“管理偏好设置”来管理您的 Cookie 设置。

管理偏好设置

拒绝全部接受全部

隐私偏好中心

尊重退出偏好信号

隐私偏好中心

### 您的隐私
### 必要 Cookie
### 性能 Cookie
### 功能性 Cookie
### 目标 Cookie
### TOTHR

#### 您的隐私

当您访问任何网站时，它可能会在您的浏览器上存储或检索信息，通常以 Cookie 的形式存在。这些信息可能是关于您本人、您的偏好或您的设备，并主要用于确保网站按预期运行。这些信息通常不会直接识别您，但可以让您获得更个性化的网络体验。由于我们尊重您的隐私权，您可以选择不允许某些类型的 Cookie。点击不同的类别标题可了解更多信息并更改我们的默认设置。但是，阻止某些类型的 Cookie 可能会影响您对网站的使用体验以及我们能够提供的服务。

#### 退出销售、共享和定向广告

根据您的所在地，您可能有权选择退出个人数据的“销售”或“共享”，或退出为在线“定向广告”目的处理您的个人数据。您可以通过在此处禁用可选 Cookie 来基于 Cookie 和类似标识符进行退出。若要基于其他标识符（例如您的电子邮件地址）退出，请在我们的隐私请求中心提交请求。

更多信息

#### 必要 Cookie

始终启用

这些 Cookie 对网站正常运行是必需的，在我们的系统中无法关闭。它们有助于实现基本功能，例如设置您的隐私偏好、登录或填写表单。您可以将浏览器设置为阻止或提醒您这些 Cookie，但网站的部分功能将不再可用。

#### 性能 Cookie