正如上一章所示，Apache Iceberg 为数据湖仓带来了强大的表管理能力，通过 ACID 事务、Schema 演进与时光回溯等特性，实现可靠且可扩展的数据操作。但要充分释放 Iceberg 表的潜能，我们需要一种方式在庞大而多样的湖仓工具生态中统一管理与组织这些表——这正是 Apache Iceberg Catalog 发挥作用的地方，为湖仓拼图补上最后一块。
Iceberg Catalog 作为集中式层，负责在湖仓环境中追踪、组织与治理不断增长的表数量。它让不同工具与框架都能发现这些表，确保数据工程师、分析师及其他用户无论数据存放在何处，都能轻松访问到任一表的最新状态。没有 Catalog，跨多查询引擎与环境管理大规模数据集将变得混乱且易出错，难以获得关于表的元数据、版本与 Schema 变更的统一视图。
Iceberg Catalog 不只是“跟踪系统”，它还是治理层：在整个湖仓中强制访问控制并提供可审计性。Catalog 能确保合适的用户访问恰当的数据，同时提供符合法规合规与运营安全所需的透明度。本章将探讨 Iceberg Catalog 如何实现上述能力，比较不同类型的 Catalog 及其带来的挑战。最后，我们将深入 Apache Iceberg REST Catalog 规范，了解其如何以灵活、可扩展的方式在任意环境中管理 Iceberg 表。
什么是、什么不是 Apache Iceberg Catalog
“Catalog（目录）”一词在数据架构中由来已久，但语境不同，含义也不同。在 Apache Iceberg 兴起之前，“Catalog”更多指的是企业元数据目录。如 Collibra、Alation 等工具，为业务用户、数据分析师与数据科学家提供了跨组织的数据集发现平台。此类目录旨在文档化数据，提供描述、血缘与访问策略，帮助用户定位所需数据、理解其上下文，并向数据负责人申请访问权。就此而言，企业元数据目录是面向人的可发现性与管理的“入口”。
与之相对，Apache Iceberg Catalog（亦称湖仓目录，lakehouse catalog） 的目的不同但同样关键。它不是给终端用户找数据集的工具，而是支撑这些用户所依赖工具的“骨干” 。湖仓目录提供面向机器的可发现性，让 Spark、Dremio、Snowflake、Flink 等各类引擎知道你的湖仓里有哪些数据集。没有湖仓目录，这些工具看到的只是存储中的原始文件——一种缺乏结构的视图；有了目录，工具就能把数据当作“表”来对待，像在传统数据仓库中一样便捷访问、查询与管理。图 2-1 总结了两者差异。
图 2-1 企业数据目录 vs. 湖仓目录的差异
Apache Iceberg Catalog 的工作机制
湖仓目录之所以必要，与 Iceberg 的数据管理方式密切相关。每当 Iceberg 表被更新时，都会生成一个新的 metadata.json 文件。该文件包含表的Schema、分区、快照等关键信息，是表当前状态的权威来源。然而，若缺少目录来管理这些文件，各工具将无法确定应使用哪一个版本的 metadata.json。不同查询引擎、处理工具甚至用户可能看到彼此不一致的表版本，导致结果矛盾。
这正是湖仓目录发挥作用之处。目录充当事实来源（source of truth） ，为各工具提供一致方式来发现并访问任一表正确的 metadata.json（见图 2-2）。当所有表与视图都注册进目录后，所有对该表发起查询的工具都将使用当前且正确的数据版本，避免访问过期元数据或读取陈旧数据等问题。
图 2-2 目录作为表元数据的事实来源
此外，目录在安全的并发事务中居于核心地位：写入开始时，工具会依据目录记录检查表的当前状态；写入完成后，目录会在提交前验证是否发生冲突性变更。若在此期间另一个写入已修改该表，当前事务将失败并可能重试，从而确保一致性并防止冲突。
作为 Iceberg 表的全局注册中心，湖仓目录确保数据生态中的所有用户与工具都能访问到每张表一致、最新的视图，奠定了稳定可靠的操作基础。
在下一节中，我们将介绍 Apache Iceberg Catalog 的多种类型及其在不同环境（从云原生到本地部署）中的实现方式。
Apache Iceberg Catalog 的类型（Types of Apache Iceberg Catalogs）
在 Apache Iceberg 初期，社区提供了多种通过不同类型的 catalog 来管理与追踪数据集的方法。总体上，这些 Iceberg catalog 可分为两大类：文件系统型（file-system catalogs） 与 服务型（service catalogs） 。两类在可扩展性、一致性与易集成性等方面各有优劣。本文将分别介绍这两类 catalog 的工作机制及其在生产环境中可能遇到的挑战。
文件系统型 Catalogs（File-System Catalogs）
文件系统型 catalog 通过直接在底层文件系统中存放元数据引用来管理 Iceberg 表。典型代表是Hadoop catalog：它在分布式文件系统（如 HDFS、Amazon S3、Google Cloud Storage）上的目录结构内维护每张 Iceberg 表的元数据。
Hadoop Catalog 的工作方式（How the Hadoop Catalog works）
在 Hadoop catalog 中，每张 Iceberg 表都有专属目录，表的元数据（如 metadata.json 与表的快照）就存放在该目录中。该 catalog 借助文件系统的目录结构来组织与引用表。当查询引擎或其他工具需要访问某张 Iceberg 表时，会查阅该目录以找到 metadata.json 文件，从而获取最新的 schema 与分区信息。
Hadoop catalog 的关键组件之一是 VERSION-HINT.TEXT 文件。它充当指向最新 metadata.json 的指针：每当表被更新，就会生成一个新的元数据文件，同时更新 VERSION-HINT.TEXT 以指向最新版本。工具在查询表时会先读取 VERSION-HINT.TEXT，以确定应使用哪一个元数据版本（见图 2-3）。
图 2-3 Hadoop（文件系统型）catalog 的工作方式
文件系统型 Catalog 的挑战（The challenges with file-system catalogs）
虽然 Hadoop catalog 在小规模或测试环境中运作良好，但在生产环境会引入一些重要挑战。首要问题是一致性：并非所有文件系统在更新与读取文件时都提供相同的保证，尤其是 VERSION-HINT.TEXT 的更新未必是原子的。例如，在某些云存储系统中，从文件被更新到其他客户端可见之间可能存在延迟（最终一致性）。这会导致查询引擎读取到旧版 VERSION-HINT.TEXT，从而引用到过期的元数据文件，造成访问数据的不一致。
此外，文件系统型 catalog 通常缺乏内建的锁机制来管理并发写入与读取。因此，对于要求高一致性、高可靠性与高可扩展性的生产环境而言，文件系统型 catalog 往往不够健壮，难以满足需求。
服务型 Catalogs（Service Catalogs）
为了解决文件系统型 catalog 面临的挑战，服务型 catalog 应运而生。与文件系统型不同，服务型 catalog 借助外部服务——通常是数据库或专用目录服务——来存储元数据并管理事务。它们利用锁机制等能力来确保数据一致性并安全处理并发操作，因此在大规模生产环境中更加可靠。图 2-4 展示了服务型 catalog 的工作方式。
图 2-4 服务型 catalog 向引擎提供元数据位置的方式
Hive Catalog
Hive catalog 是 Apache Iceberg 最早的服务型 catalog 之一，构建在 Apache Hive Metastore 之上；它通过 Hive 的表管理体系，将 Iceberg 元数据存放在关系型数据库（如 MySQL、PostgreSQL）中。对于已经依赖 Hive 管理元数据的查询引擎（如 Apache Spark、Apache Flink），该 catalog 集成良好。
与文件系统型 catalog 相比，Hive 提供更一致、更具事务安全的环境。其关系型数据库后端可在更新期间对表加锁，确保变更被正确处理，降低不一致风险。但需要注意，Hive Metastore 最初并非为现代超大规模数据湖而设计；当表与数据集数量激增时，扩展性可能成为限制。此外，Hive 的部署与运维也相对复杂。
JDBC Catalog
JDBC catalog 的工作方式与 Hive catalog 类似，但它不依赖 Hive，而是通过 JDBC 直接连接关系型数据库。这为组织在选择用于承载 Iceberg catalog 的数据库系统上提供了更大灵活性（例如使用 MySQL、PostgreSQL，或云上托管数据库）。
在一致性与事务安全方面，JDBC catalog 拥有与 Hive catalog 相同的优势。凭借关系型数据库的加锁能力，它能正确处理并发读写，避免部分更新或查询引擎读取陈旧数据的问题。对于偏好轻量化、以关系型数据库驱动的目录管理方案的组织而言，JDBC catalog 是理想选择。
Nessie Catalog
Nessie catalog 是面向目录级版本控制与多分支数据管理的服务型 catalog。其工作方式类似 Git：数据工程师可以为 Iceberg 表创建分支、标签与提交。这使得 Nessie 特别适用于协作与版本化至关重要的环境，例如需要并行维护数据集多个版本的数据科学与数据工程团队。
Nessie 将元数据存放在版本化的键值存储中，其后端可采用多种存储系统（包括关系型数据库或云原生方案，如 DynamoDB）。Nessie 提供 ACID 事务与并发写入安全，并允许团队在不影响生产主数据集的情况下，回滚到先前版本，或从分支上进行新变换的试验。
AWS Glue Catalog
AWS Glue catalog 是用于跟踪 Amazon S3 上数据元数据的全托管服务。它最初用于为多种 AWS 分析服务（如 Athena、Redshift Spectrum、EMR）管理元数据，如今也支持 Apache Iceberg 表。Glue 与 AWS 生态深度集成，是以 AWS 为核心的数据基础设施的理想之选。
Glue 提供无服务器的元数据管理，AWS 负责目录的扩缩容、可用性与运维。它支持schema 版本化、并发操作与分区发现——这些都是在生产环境管理大数据集的关键能力。作为托管服务，AWS Glue 尤其适合不愿自行承担 catalog 服务运维复杂度的组织。
多样化 Catalog 选项的挑战（Challenges of Diverse Catalog Options）
随着 Apache Iceberg 的采用扩大，围绕 Iceberg 表的 catalog 实现 也随之增多。多种选择——从文件系统型方案到 Hive、JDBC、Nessie、AWS Glue 等服务型 catalog——虽带来灵活性，但也引入了新的挑战。各 catalog 在元数据与事务管理上的实现各不相同，且与不同数据处理引擎的集成日益复杂、易出错。
其中最显著的挑战之一在于：每一种 catalog 都要求在使用 Iceberg API 的每种语言里实现一套专用的客户端类。无论是 Java、Python、Rust 还是 Go，都需要能与所选 catalog 交互的专用客户端（见图 2-5）。
图 2-5 为单一 catalog 维护所有客户端库所面临的挑战
这种要求为 catalog 维护者与开发者带来巨大负担：每个 catalog 都需确保在多语言与多环境中的兼容性。实现缺乏标准化也意味着缺陷、不一致或 catalog 版本与客户端库不匹配的问题更易出现。
客户端侧的复杂性（Client-Side Complexity）
大量 catalog 逻辑由客户端侧处理：正确管理元数据、与表快照交互、确保一致的读写，都落在使用该 catalog 的应用或计算引擎上。这导致了版本不匹配问题——例如组织升级了 catalog 服务器，却没有同步更新数据处理工具中的catalog 客户端库，查询或更新表时就可能出现不一致或错误。
此外，各个 catalog 处理元数据与与存储交互的方式各不相同，进一步带来兼容性隐患。必须确保正在运行的 catalog 服务器版本与相应的客户端版本匹配；一旦不同步，数据操作可能出现意外行为甚至直接失败。
配置层面的挑战（Configuration Challenges）
使用 Iceberg catalog 的另一大痛点是配置。不同的处理引擎（如 Spark、Flink、Dremio）需要配置正确的 catalog 凭证，同时还要配置对象存储与其访问凭证，以便读取底层存储中的元数据与数据。也就是说，每一个与 Iceberg 表交互的工具/引擎都要配置多层凭证，搭建过程既繁琐又易错。随着组织内工具与 catalog 的数量增长，管理难度愈发加剧。
对于使用托管服务的组织，情况更为复杂：各托管平台需要分别构建、测试并支持每一种 catalog。这会造成支持矩阵混乱（哪个平台支持哪些 catalog），且不同服务之间的实现差异，常常使从一个托管平台迁移到另一个需要大量重配，甚至重构 catalog 管理方式。
授权难题（Authorization Challenges）
对数据与元数据的访问权限进行治理对许多组织至关重要。尽管一些 Iceberg catalog 在表、视图与命名空间层面提供了一定的访问控制，但对实际数据的访问仍需通过对象存储配置与其凭证单独管理——迫使用户针对同一套“表数据”同时维护两套授权体系。
统一方案的必要性（The Need for a Unified Approach）
上述问题——客户端库的激增、客户端侧逻辑的复杂性、版本不匹配、繁琐配置、访问权限治理难题，以及托管服务支持的碎片化——共同凸显出需要一种全新的服务端—客户端范式。组织需要一种标准化的方式来与 Iceberg catalog 交互，以简化集成、确保在不同环境间的兼容性，并降低在元数据管理与数据访问治理上的运维负担。
Apache Iceberg REST Catalog 规范（The Apache Iceberg REST Catalog Specification）
Apache Iceberg REST Catalog 规范的诞生，旨在解决管理 Iceberg 目录（catalog）时日益增长的复杂性与挑战。该规范通过建立一个统一的客户端接口，简化 Iceberg 表与多样化目录之间的交互，使其可在多种编程语言中无缝工作。其核心是一份 OpenAPI 规范，为构建REST 风格的目录服务提供蓝图。凡遵循该规范的目录，都可以实现所需端点，既确保与 Iceberg 的兼容性，又能解决早期目录实现面临的诸多问题（见图 2-6）。
这种方式把各目录的复杂性与特性从众多客户端库迁移到服务端。元数据与数据的访问权限由目录服务治理，可对接组织的身份提供商（IdP），例如 Keycloak、Authelia、Okta，并利用 IAM 策略实现表级数据访问控制。
图 2-6 REST 目录规范带来的简化
REST Catalog 规范的关键收益（Key Benefits of the REST Catalog Specification）
统一的读/写交互方式让 REST 目录接口带来如下核心优势：
- 服务端处理逻辑（Server-side logic handling）
最大改进之一是将诸多目录特定逻辑从客户端下移到服务端。诸如元数据、快照、事务等复杂细节改由目录服务直接处理，减少了过去服务器与客户端版本不同步导致的问题，使客户端实现更轻量、简单。 - 跨目录统一客户端（Unified client across catalogs）
规范标准化了客户端与目录的交互。一旦某目录实现了 REST 规范，便可通过同一个 REST 客户端访问。数据处理引擎、查询工具或其他服务无需再为不同目录编写专用客户端，只需使用统一标准客户端即可连接多种目录，无需适配各异的 API/实现。 - 跨语言简化（Cross-language simplicity）
统一接口消除了为每个目录在不同语言中分别实现客户端类的需求。各语言（Java、Python、Rust、Go 等）只需实现一个 REST 客户端，即可与任何遵循 REST 规范的目录协同工作，显著降低跨语言维护复杂度，并确保未来更新可在所有环境一致落地。 - 简化托管服务支持（Simplified support for managed services）
过去托管平台需为每个目录分别构建与测试支持，导致支持碎片化。采用 REST 目录后，托管平台只需实现REST 客户端，即可自动支持所有符合规范的目录，既拓展了用户可用目录范围，又降低了服务商的运维负担。
REST 目录实现的演进（The Evolution of REST Catalog Implementations）
REST 目录规范初推出时，可用的选项只有 Tabular 的商用目录服务。Tabular 由 Apache Iceberg 的最初创建者创立，率先实现了 REST 规范，向企业提供完全托管的 Iceberg 目录，为早期采用者提供了稳健方案。此后，Tabular 被 Databricks 收购并关闭注册、下线产品，其商用可用性终止。
随着 REST 目录规范价值凸显，开源社区开始实现该规范，涌现出多款支持 REST 交互的开源目录服务，可自主管理、长期使用，无需担心公司层面的变动迫使迁移。如今已有多种开源目录采纳该规范，包括：
- Nessie
面向后 Hive 时代的现代湖仓而生，最初由 Dremio 创建。提供类 Git 的目录：版本控制、分支、标签，并可在多张表间实现该语义。 - Apache Gravitino
开源项目，致力于提供稳健的、基于 REST 的目录服务，满足现代湖仓需求。目标不仅是表的元数据目录，亦包含Schema 与 ML 模型注册表，支持跨地域分布；最初由 Datastrato 创建并捐赠给 Apache 基金会。 - Apache Polaris
一款 Iceberg REST 目录实现，致力成为湖仓中枢：提供RBAC、对接企业 IdP，并可连接外部目录以统一目录生态。由 Snowflake 最初创建并捐赠至 Apache 基金会；贡献者来自 Dremio、Snowflake、AWS、Google、Microsoft、Confluent、LanceDB 等众多社区与厂商。
这些开源实现让组织更容易以标准化方式采用 Iceberg 并利用其高级特性。REST 目录规范为在现代数据湖仓中组织与交互 Iceberg 表提供了一致、可扩展、可管理的道路。
Apache Polaris
随着数据湖仓的崛起，数据管理中的诸多难题——例如在分散的团队与工具之间保持数据一致性——已得到显著缓解，尤其得益于 Nessie、Gravitino 等开源目录的引入。它们各具特色：如 Nessie 的版本化能力、Gravitino 的跨地域可用性，为灵活性与引擎互操作性提供了基础。然而，现有目录生态仍有若干关键问题尚未彻底解决。
一个主要限制在于：尽管不同目录各有所长，组织往往被迫围绕单一目录构建整套湖仓架构。一旦选定某个目录，便难以同时享受其他目录的优势。举例来说，若团队希望使用 Nessie 的版本控制，就会被“锁定”在 Nessie 上，无法同时利用 Gravitino 的跨地域能力。结果就是形成孤岛效应：目录的选择反过来决定了湖仓的整体结构，降低了灵活性。
另一项关键挑战是治理。在很多场景里，访问控制与安全是在引擎层实现的——也就是每个与 Apache Iceberg 表交互的工具都要各自实现访问规则。这样会带来不一致与运维开销：团队必须在不同工具间维护多层访问控制，而且这些规则无法在工具之间复用。
Apache Polaris 的诞生
意识到这些局限后，Snowflake 宣布研发全新的目录 Polaris。在 Dremio、AWS、Google、Microsoft 等主要参与者的协作下，Polaris 很快获得推进。该项目被 Apache 软件基金会孵化器 接纳，正式成为由多家公司与组织的开发者共同驱动的社区项目。Polaris 的出现，标志着在多工具、多云环境下，目录仍存的挑战取得了重要进展与突破。
Polaris：湖仓目录的新时代
Polaris 引入多项创新特性，使其有望成为 Iceberg 目录生态的中枢（见图 2-7）。
图 2-7 Apache Polaris 统一 Iceberg 湖仓目录生态
多目录（Multi-catalog）支持
Polaris 的一大创新在于：它能在单一系统内部创建与管理多个目录。每个目录都可以拥有独立的目录角色（catalog roles） ，对表、命名空间与视图实施细粒度的访问控制。组织因此无需再用单一目录治理整个湖仓；相反，可以按需创建多个目录，各司其职，并分别设定安全与治理策略。
外部连通（External connectivity）
也许最强大的特性在于：Polaris 能连接符合 Apache Iceberg REST 规范的外部目录。这使得 Polaris 可以成为所有 Iceberg 表的统一发现入口，即便这些表由 Nessie、Gravitino 等目录管理。通过集成外部目录，Polaris 让用户既能利用其他实现的独特能力，又能在单一、统一的界面中查看与管理全部表。
基于角色的访问控制（RBAC）
Polaris 还提供强健的 RBAC，将数据访问治理提升到目录层。用户（称为 principal）可以被授予一个或多个角色，角色内包含目录特定的权限集合。这些角色决定了用户在 Polaris 中跨多个目录的访问级别，从而在整个数据环境中提供一致、集中的安全治理。有了内建 RBAC，访问控制不再取决于单个工具或引擎，而是可在湖仓范围内可移植且一致。
结语
凭借多目录支持、外部连通与RBAC 等特性，Polaris 迅速成为 Iceberg 目录生态的核心参与者。它既能统一并简化 Iceberg 表的管理，又保留了按需选择并组合不同目录特性的灵活性，从而为构建现代数据湖仓的组织提供强大助力。在云与数据领域的头部厂商支持下，Polaris 有望在分布式、多云环境中重新定义目录的运作方式。
在本书接下来的章节中，我们将更深入地探讨 Polaris 的各项能力，帮助你理解这一强大目录如何在湖仓范式下，解决一些最复杂的数据管理挑战。
