解锁数据可移植性：利用 REGISTER 和 UNREGISTER API 防止目录锁定
内容提要
Apache Iceberg REST目录规范新增REGISTER和UNREGISTER端点，用于解决表在目录间迁移时的脑裂风险。REGISTER将已有表挂载到新目录，UNREGISTER让旧目录放弃管理并返回元数据指针，全程不复制或删除数据文件。三步交接确保表始终只有一个管理目录，提升湖仓开放性与可移植性。
延伸解读
目录协调机制与脑裂风险
在开放表格式中，目录作为中央权威协调提交，确保两个写入者不会静默覆盖彼此。当引擎查询表时，先向目录请求最新元数据，再直接从对象存储读取数据。如果仅使用REGISTER将表挂载到新目录，旧目录仍保持活跃，两个目录都以为自己是唯一所有者，首次写入就会导致表分叉，引发查询结果不一致和静默数据丢失。
UNREGISTER如何避免数据删除
传统DROP TABLE会删除表的数据和元数据，因此不能用于迁移。UNREGISTER端点则从管理目录中移除表条目，但不触碰任何底层数据文件，并返回表的最新元数据位置。这个指针正是下一个目录接管提交协调所需的关键信息。通过先UNREGISTER再REGISTER，确保表在任意时刻只有一个管理目录，从而消除脑裂风险。
三步交接的实际操作与限制
交接过程包括：向旧目录发送UNREGISTER请求，获取返回的元数据位置，再向新目录REGISTER该位置。请求形式为空POST到表资源路径。但文章指出，生产迁移还涉及操作步骤，如安全停止写入者和重新指向作业，这些将在后续文章中介绍。因此，REGISTER和UNREGISTER解决了目录层面的所有权转移，但完整迁移仍需配套运维措施。
Q&A
REGISTER 和 UNREGISTER 是什么？它们解决了什么问题？
REGISTER 和 UNREGISTER 是 Apache Iceberg REST 目录规范新增的端点，用于在目录之间迁移表时避免脑裂风险。REGISTER 将已有表挂载到新目录，UNREGISTER 让旧目录放弃管理并返回元数据指针，全程不复制或删除数据文件。
为什么不能直接用 DROP TABLE 来迁移表？
因为 DROP TABLE 会删除表的底层数据和元数据，而迁移表只需要转移管理权，不能丢失数据。UNREGISTER 则只从目录中移除表条目，不触碰任何数据文件，并返回元数据位置供新目录接管。
什么是脑裂场景？REGISTER 单独使用为什么会引发脑裂？
脑裂是指两个目录都认为自己是表的唯一管理者并协调提交。单独使用 REGISTER 会在新目录中添加表条目，但旧目录仍然活跃，两个目录互不通信，导致第一次写入时表被分叉，引发查询结果不一致和静默数据丢失。
UNREGISTER 请求的格式和响应是什么？
UNREGISTER 请求是一个空的 POST 请求，发送到表资源：POST <uc-iceberg-rest-base>/v1/{prefix}/namespaces/{namespace}/tables/{table}/unregister。响应返回表的最新元数据位置，即下一个目录接管所需的指针。
表迁移的三步交接流程是怎样的？
三步交接流程为：1) 在旧目录执行 UNREGISTER，使其放弃管理并返回元数据位置；2) 接收该位置指针；3) 在新目录执行 REGISTER，将表挂载到新目录。这确保表在任何时刻只有一个管理目录。
REGISTER 和 UNREGISTER 对数据可移植性有什么意义？
它们实现了目录间的自由迁移，无需重写、导出或复制任何文件，提升了湖仓的开放性和可移植性。用户可以根据架构演变自由选择和移动目录，同时保持数据治理的灵活性。
