Databricks

Unlocking Data Portability: Preventing Catalog Lock-in with REGISTER and UNREGISTER APIs

8.5内容质量

TL;DR · AI 摘要

Databricks推出REGISTER和UNREGISTER API，通过元数据转移实现数据目录无损迁移，解决湖仓架构中的目录锁定问题。

核心要点

  • REGISTER通过元数据指针转移实现表的跨目录迁移，无需复制数据文件
  • UNREGISTER强制原目录释放表所有权，避免split-brain场景导致的数据不一致
  • 该方案基于Apache Iceberg 1.3+的REST API规范实现

结构提纲

按章节快速跳转。

  1. §引言

    介绍数据目录锁定问题及REGISTER/UNREGISTER的解决方案

  2. ·湖仓架构数据管理挑战

    解析传统目录迁移导致的数据冗余和一致性风险

  3. ›REGISTER机制详解

    通过元数据指针转移实现零拷贝表迁移

  4. ›UNREGISTER安全保障

    强制原目录释放控制权防止数据冲突

  5. ·技术实现

    基于Apache Iceberg REST API的扩展实现方案

  6. ›实践案例

    展示跨云厂商目录迁移的典型应用场景

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • 数据目录可移植性解决方案
    • 核心机制
      • REGISTER API
        • 元数据指针转移
      • UNREGISTER API
        • 控制权释放
    • 技术背景
      • 湖仓架构挑战
        • 目录锁定问题

金句 / Highlights

值得收藏与分享的关键句。

#湖仓一体#数据目录#Apache Iceberg#Databricks
打开原文

实现数据可移植性：通过REGISTER和UNREGISTER API防止目录锁定 | Databricks 博客

跳至主要内容

平台

2026年10月5日

实现数据可移植性：通过REGISTER和UNREGISTER API防止目录锁定

REGISTER和UNREGISTER：目录管理的新开放标准

作者：Ryan Blue 和 Marco Kroll

摘要

  • REGISTER和UNREGISTER提供了一种标准方法，可在不复制数据的情况下安全地转移表的目录管理。
  • 当开放表格式存储在客户自有存储桶中时，现在可以轻松在不同目录之间进行转移。
  • UNREGISTER通过确保原始目录在转移前明确放弃控制权，消除了危险的"脑裂"场景风险。

随着组织采用湖仓一体架构，数据正从专有数据仓库转移到开放存储和表格式中，这些数据可以通过Spark和Trino等多引擎访问而无需复制。

然而，开放格式只是开放性方程的一部分。真正的开放性还需要在数据管理和治理方式上的互操作性和灵活性。为了充分发挥湖仓一体的潜力，组织需要在架构演进过程中自由选择和切换目录。

为支持这种可移植性，REGISTER和UNREGISTER端点使用户能够在不重写、导出或复制任何文件的情况下在目录之间移交表。REGISTER可将现有表附加到任何IRC目录。在移动表时，不能仅仅通过DROP命令从旧目录中删除表，因为这会清理其底层数据和元数据。我们向Apache Iceberg™ REST目录规范添加了UNREGISTER端点，使您能够指示旧目录忘记该表，并返回新目录接管所需的精确指针。

在本文中，我们将深入探讨开放表格式生态系统的发展，这些新增功能解决的关键挑战，以及REGISTER和新UNREGISTER命令的实际工作原理。

背景：目录的作用

当引擎查询表时，首先会向目录请求加载表以确保获取最新状态。目录会返回表的当前元数据，包括表数据在对象存储中的位置。从那里，引擎使用这些元数据找到模式并直接从对象存储中读取Parquet文件。

这种协调对于开放表格式至关重要，因为所有重要元数据（模式、历史记录、统计信息）和数据本身都存储在存储中，与计算完全解耦。通过作为最新状态的中央权威，目录协调提交并确保两个写入者永远不会静默覆盖彼此。

图1：读取路径

  • 引擎请求目录加载表。
  • 目录返回表的当前元数据及其在对象存储中的位置。
  • 引擎直接从您的存储桶读取元数据和数据文件。

REGISTER端点的工作原理

将现有表附加到目录只是将加载表的元数据位置移交的问题。这正是REGISTER通过Iceberg REST规范中已定义的端点所执行的操作。

图2：REGISTER操作

  • 客户端发送POST请求，包含所需的表名称和现有元数据位置的URI。
  • 在基本验证之后，目录会写入一条记录，将表名与现有的metadata.json关联起来。不会复制、移动或修改任何数据文件。

关键问题是，单独使用REGISTER会导致“脑裂”场景，即两个目录都认为自己拥有该表并会协调提交。由于Iceberg目录是独立且不通信的，单独使用REGISTER会在新目录中添加一条记录，而旧目录仍然完全处于活动状态。如果两个目录都相信自己是表的唯一拥有者，两者都不会抛出错误，但第一次写入操作会分叉表，导致查询结果不一致和静默数据丢失。

图3：脑裂场景

  • 通过目录A进行的写入对目录B完全不可见，这会永久破坏你单一的事实来源。

缺失的部分是UNREGISTER

历史上，生态系统缺乏一种标准的方式来干净地终止目录对表的管理。运行DROP TABLE不起作用，因为它会删除表的数据和元数据！没有UNREGISTER，REGISTER的交接方程缺少了第二部分。我们向Apache Iceberg™ REST目录规范贡献了UNREGISTER，用于从管理目录中删除表的条目，而无需触碰任何底层数据文件。

关键的是，它会返回表的最新元数据位置——下一个目录需要的精确指针。通过确保原始目录明确放弃控制权，这消除了脑裂场景的风险。

请求是对表资源的空POST：

POST <uc-iceberg-rest-base>/v1/{prefix}/namespaces/{namespace}/tables/{table}/unregister

响应是下一个目录需要的指针：

$

/$

图4：交接过程

  • UNREGISTER从目录A中删除表的条目（文件保留在原处）。
  • 响应返回表的最新元数据位置。
  • 目录B使用REGISTER端点获取指针。目录B现在成为表的唯一管理目录。

通过结合这三个步骤——注销、接收位置、注册——交接确保表始终只有一个管理目录。（注意：生产环境迁移仍涉及操作步骤，例如安全停止写入器和重新指向作业，我们将在后续文章中介绍。）

入门

通过REGISTER和UNREGISTER，你现在可以自由地将表迁移到其他目录。我们添加此功能是因为开源可移植性对我们的客户至关重要。Unity Catalog仍然是管理数据最开放的湖仓一体平台，提供智能时代所需的统一治理。它为你的本体论提供上下文层，在数据和智能体之间提供一流的访问控制和可观测性，并在云、区域和计算方面提供灵活性。

要尝试在Unity Catalog的私有预览版中使用REGISTER和UNREGISTER，请联系你的账户团队。

在邮箱中获取最新文章

订阅我们的博客，获取最新文章发送到你的邮箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"