构建 Apache Iceberg 湖仓架构——实现目录层

本章内容包括：

• 根据审计洞察定义 catalog requirements
• Catalog layer 在 Apache Iceberg 中的角色
• 评估 Apache Iceberg catalog implementations
• 应用 REST Catalog specification 以实现 interoperability
• 为你的组织选择合适的 catalog

我们已经探索了 Apache Iceberg lakehouse 的基础组件，包括 storage 和 ingestion。现在，我们将把注意力转向 catalog layer，这是任何 Iceberg deployment 的关键组成部分。Storage layer 管理物理数据，ingestion layer 转换并加载数据，而 catalog 则提供整个系统可靠且规模化运行所必需的 metadata 和 coordination。

Catalog layer 是 Iceberg tables 被注册、跟踪和组织的地方。它会跟踪 table metadata，管理 namespaces，并作为 data operations 的协调点。选择合适 catalog 并不只是技术决策，也是一项战略决策。它会影响 governance、interoperability、scalability，以及与更广泛生态系统的集成。

每个组织都有独特的架构约束、合规需求和运营目标。本章首先考察应指导 catalog selection 的 requirements，这些 requirements 基于第 4 章 audit process 中获得的洞察。随后，我们会探索 Iceberg 的 catalog interface 如何工作，包括对不断增长的一组 implementations 的支持，例如 Apache Polaris、Nessie、AWS Glue Data Catalog、S3 Tables、Dremio catalog、Snowflake Open Catalog 等。

我们还会考察 Apache Iceberg REST Catalog specification，这是一个较新的发展，旨在统一 engines 和 tools 连接 catalog services 的方式。最后，我们会通过几个真实感决策场景，看看不同 catalog features 如何与特定组织优先级对齐。

本章结束时，你将知道如何选择和配置一个与 lakehouse 需求对齐的 catalog，并有信心随着需求演进而调整。

7.1 Catalog 在 Apache Iceberg Lakehouses 中的角色

Apache Iceberg 通过 atomic、versioned metadata model，实现对分析数据集的可靠并发访问。对 table 的每次 committed change，例如添加数据、删除 rows 或演进 schema，都会产生一个新的 table metadata version，该版本会引用对应的 data 和 auxiliary files。这些 metadata versions 是 immutable 的，并形成 table states 的线性历史。这种设计允许用户查询 table 的一致视图、执行 time travel，并回滚到早期版本，而不会干扰 concurrent readers 或 writers。Iceberg 不依赖传统 database locking，而是通过 atomic replacement of table metadata 实现这些 guarantees；当它与 engine-level commit protocols 结合时，就构成了 ACID semantics 的基础。

Catalog 会把这些 metadata versions 连接成一个连贯系统，见图 7.1。它是 lakehouse 的 coordination layer，负责跟踪 Iceberg tables，并确定哪个 metadata version 代表 table 的当前状态。不同于传统数据库中 metadata 与单一 execution engine 紧密耦合，Iceberg 将这一职责委托给 catalog，使多个 compute engines 能够以一致且 transactional 的方式发现、读取和更新 table state。

图 7.1：Catalog 使访问 lakehouse tables 的工具能够验证 permissions，并定位 lake 中对应的数据。

如图 7.2 所示，catalog 管理 table locations，将 tables 组织进 namespaces，并协调所有 Iceberg metadata objects 的 transactional updates，包括那些不会产生新 snapshots 的对象。这种 storage、compute 和 metadata coordination 的分离，使 Iceberg 能够跨 tools、environments 和 clouds 扩展，同时保持 interoperable。

图 7.2：Apache Iceberg catalog 将每个 table name 映射到其最新 metadata file 的位置，该 metadata file 是工具开始扫描并与 table 交互的入口点。

下面我们拆解 catalog 的具体职责，说明它如何融入 Iceberg architecture，并看看 engines 如何依赖它来解析 tables、规划 queries 和执行 updates。在比较 catalog implementations 之前，理解这些职责非常关键，因为它会帮助你澄清哪些能力对你的 use case 是必需的。

7.1.1 Catalog 的职责

Apache Iceberg 中的 catalog 是所有 table metadata 的权威索引。Data files 存放在 cloud 或 distributed storage 中，queries 由 Spark、Flink 或 Trino 等 engines 执行，而 catalog 将所有这些连接在一起。它使 engines 能够安全且一致地定位、解释和修改 Iceberg tables。

Catalog 处理四项关键职责：

Table registration and discovery——Catalog 会跟踪给定 namespace 中所有已注册的 Iceberg tables。当用户查询 table 时，engine 会联系 catalog，将 table name 解析为 metadata location。这让多个 engines 可以共享一个共同 table catalog，确保 batch 和 streaming jobs 之间访问一致。

Metadata location management——每张 Iceberg table 都由一组 metadata objects 表示，包括 schema definitions、partition specifications、manifests 和 snapshot references。Catalog 并不依赖单一固定 metadata root，而是在任何时间点充当仲裁者，决定哪些 metadata objects 与某个 table identifier 关联，并在 commits 期间以 transaction 方式更新这种关联。这层间接性支持 Iceberg 的 versioned table history，并支持 time travel 和 rollback 等能力。随着 catalog implementations 演进，尤其是 REST-based catalogs 出现后，协调 table state 越来越成为 catalog 自身的职责，而不再只是 transactionally 写入单个 metadata.json file。

Namespace organization——Catalogs 使用 namespaces 对 tables 分组，通常反映组织边界或领域边界。例如，一张 table 可能注册在 analytics.marketing.sales_data 下。这种层级结构简化了 table discovery 和 access control，尤其适用于拥有数百或数千 tables 的大型环境。

Transaction coordination——在 write operations 期间，Iceberg 使用由 catalog 协调的 optimistic concurrency model，如图 7.3 所示。一次 write operation 会准备一组 proposed metadata changes，代表新的 table state，并将其作为 transactional commit 的一部分提交给 catalog。Catalog 会在接受 update 前验证 table state 是否已经被另一个 concurrent operation 以冲突方式修改。如果检测到 conflict，该 commit 会被拒绝，engine 必须使用最新 table state 重试。这种由 catalog 介导的 coordination 确保 concurrent writers 不会破坏 table metadata，无论底层 catalog implementation 依赖 file-based metadata、relational storage，还是 REST-based services。

图 7.3：Optimistic commits 允许 engines 写入 data 和 metadata，然后通过在写入 files 和 committing 前后检查 metadata 中的 commit sequence 位置，判断 commit 是否成功。如果两次检查之间 projected sequence number 发生变化，说明另一个 transaction 已发生，本次 transaction 应重试。

一些 catalog implementations 还可能提供额外功能，例如 audit logging 或 version history。但上述四项核心职责定义了所有 Iceberg-compatible catalogs 必须支持的内容。每次 query、update 或 schema change 都会经过这一层，使其成为 Iceberg architecture 中最关键的组件之一。

7.1.2 Catalog 与 Query 和 Processing Engines 的交互

当 query engine 或 processing job 开始处理 Iceberg table 时，catalog 是第一个接触点。无论用户运行 interactive SQL query，还是提交 streaming ingestion job，engine 都必须查询 catalog，以解析 table name、加载 metadata 并规划 operation。

这种交互通常遵循可预测序列，不过随着支持 REST catalog 的 catalogs 成为主流，其中更多逻辑会集中到 catalog 中。

图 7.4：Engines 向 catalogs 请求 tables，catalogs 返回 metadata locations。

Table resolution——Engine 按名称向 catalog 请求 table。Catalog 返回该 table 最新 metadata file 的引用，如图 7.4 所示。Table metadata file 包含 schema、partitioning、snapshot information 和 file manifests。

图 7.4：Engines 向 catalogs 请求 tables，catalogs 返回 metadata locations。

2. Snapshot planning——使用图 7.5 所示 metadata，engine 决定应该读取或写入哪些 data files。Iceberg metadata 包含 statistics 和 file-level metadata，支持 data-skipping 和 predicate pushdown。这会减少扫描的数据量并提升性能。

图 7.5：Metadata 提供不同层级的数据，使 engine 能识别 snapshot，并确定该 snapshot 中哪些 data files 应被扫描。

3. Commit coordination——对于 write operations，engines 会构造新的 metadata，其中可能包括新增或删除的 files、更新后的 schemas 和新的 snapshots。构造完成后，engines 会尝试通过 atomically 更新 catalog pointer 来 commit 这些 metadata。如果另一个 operation 在此期间更新了 table，commit 会失败，以保证 consistency 并避免 race conditions。

4. Schema and evolution management——Engines 也使用发现到的 metadata 来理解当前 schema 和历史 schemas。

5. Time travel and rollback——如果用户请求之前的 snapshot，engine 可以在 metadata file 中看到 snapshot history，以及与该 table version 匹配的 schema，从而支持 time travel 和 rollback。

这些交互使 Iceberg 能够作为 multi-engine、multipurpose lakehouse format 运作。无论你使用 Spark 做 ETL、Flink 做 streaming，还是 Trino 做 ad hoc analytics，catalog 都会提供统一 metadata view，使 operations 保持一致。

7.2 评估 Catalog Requirements

在选择 catalog 之前，必须澄清组织对它的需求。Catalog layer 不只是技术组件；它定义了团队如何在 lakehouse 中发现、访问和管理数据。如果 catalog capabilities 与组织 requirements 不匹配，可能会导致 governance gaps、integration issues 或 operational inefficiencies。

第 4 章中，我概述了 stakeholder interviews 和 technical audits 如何帮助识别平台 requirements。现在这些洞察开始发挥作用。本节会考察评估 catalog options 时应考虑的关键 requirements，包括 performance、availability、metadata governance、security，以及与 deployment environments 的兼容性。

我们会先围绕常见 enterprise concerns 来框定这些 requirements，例如 latency expectations、regional availability、access controls 和 schema tracking。随后，我们会看看这些关注点如何转化为具体 catalog features，以及如何根据组织架构、合规需求和增长计划权衡取舍。

7.2.1 Performance、Availability 和 Scale

Catalog 的核心作用，是让 query engines 和 processing tools 发现 Iceberg tables 并访问它们的 metadata。这种交互通常位于 read 和 write operations 的关键路径上，因此 catalog performance 是关键考虑因素。High-latency responses 会拖慢 table planning 和 query execution，尤其是在涉及频繁 metadata lookups 或 concurrent writes 的 workloads 中。

Availability 同样重要。如果 catalog 无法访问，即使底层 storage 完全正常，用户也可能无法查询或更新 tables。这使 catalog uptime 成为整个 lakehouse 的基础依赖。在生产环境中，high availability 通常意味着达到 99.9% uptime，也就是每年大约 8.8 小时 downtime，或更高。Mission-critical systems 通常以 99.99% availability 为目标，即每年 downtime 少于 1 小时。为了满足这些预期，应评估你的 catalog 是否支持 fault-tolerant deployment patterns，例如 clustering、multiregion replication 或 managed failover mechanisms。

随着平台增长，scalability 也发挥关键作用。在 multi-tenant environments 中，或在管理数百到数千 Iceberg tables、支持数十甚至数百 concurrent users 的组织中，catalog 必须承受高 metadata request volumes，而不能成为瓶颈。这不仅包括 read throughput，成熟 catalogs 通常可以每秒处理数千次 metadata lookups，也包括 concurrent write operations、namespace expansion 和 low-latency snapshot metadata resolution。一些 production-grade deployments 报告可处理超过 10,000 张 tables 和数百万 daily catalog interactions。

评估 catalog options 时，可以问以下问题：

• Catalog 能否以 low-latency responses 处理高 request rate？
• 它是否提供 decoupled backend database 来存储 metadata？
• Catalog 能否通过增加 compute 来扩展处理更多 requests，而不是部署新的 catalog instances？
• 它是否提供 fault-tolerant deployment modes？
• 它是否针对 latency-sensitive workloads 优化，例如 interactive queries、near-real-time 或 real-time ingestion？
• Catalog 是否开放，并能与你使用的工具生态 interoperable？

虽然没有单一 metric 能完整衡量 catalog readiness，但理解并测试预期 workloads，例如 batch versus interactive、development versus production，将帮助判断候选 catalog 能否持续满足 performance、availability 和 scalability targets。

7.2.2 Metadata Governance 和 Lineage

Catalog 不只是存储 table locations；它会成为整个 lakehouse 中 data governance 的基础。在大多数组织中，catalog 是记录数据位于哪里、结构是什么、谁有权限访问的 system of record。这使 metadata governance 成为选择 catalog 时最关键的评估维度之一。

至少，catalog 应支持 namespacing 和 access control，如图 7.6 所示。Namespaces 允许将相关 tables 逻辑分组，通常与 business domains 或 organizational units 对齐。不过，稳健 governance 需要超越基本访问限制的能力。

图 7.6：Catalogs 可以有不同级别的 access control，使你能控制谁可以访问哪些 namespaces 或 tables。

首先，catalogs 必须与 external identity providers 集成，例如 OAuth、LDAP、SAML 或 enterprise SSO systems。这些集成允许 catalog 继承 user identities 和 access contexts，确保平台 permissions 与更广泛 enterprise policies 保持一致。

第二，catalogs 应支持 role-based access control（RBAC）和 attribute-based access control（ABAC）等 fine-grained authorization models。RBAC 根据 user roles 分配权限，例如 analyst、engineer；ABAC 则根据 user attributes 做决策，例如 department 或 location。这些模型对严格控制谁可以 read、write 或 administer 特定 tables 或 namespaces 至关重要。

第三，一些 catalogs 实现 credential vending，这是一种 security pattern，其中 catalog 向 querying clients 发放 short-lived、scoped-down credentials。该机制确保 clients 只能访问 query 所需的 storage paths，降低 blast radius 并简化 auditing。

这些功能结合起来，使 catalog 能在 metadata 和 storage levels 执行 security。但 governance 还需要 lineage tracking，也就是跟踪数据如何随时间流经系统的能力。Lineage 将 identities、permissions 和 operations 连接成一条 chain of custody，支持 compliance、auditability 和 root-cause analysis。对于受 GDPR、HIPAA 或 SOC 2 等 regulatory frameworks 约束的企业，这项能力不是可选项，而是必需项。

Catalogs 应记录 metadata operations，例如 table creation、schema updates 和 snapshot rollbacks。这些 logs 有助于执行 internal controls，并在 audits 期间提供证据。Catalogs 也应记录哪些 users 或 services 发起了 changes，以及它们来自哪里。

比较 catalog implementations 时，可以考虑以下问题：

• 它是否支持连接 external identity provider？
• 它是否允许定义 fine-grained access controls？
• 它是否为你计划使用的所有 storage systems 提供 credential vending，例如 S3、ADLS、GCS？
• 它是否记录 metadata operations，并允许你审计这些操作？
• 它是否提供 metadata lineage capabilities？

强 governance features 不仅满足外部义务，也增强内部可靠性、简化 debugging，并降低未经授权的 changes 破坏 data integrity 的风险。

7.2.3 Security 和 Compliance

Security 是任何现代数据平台中的基本要求。作为 metadata 和 table discovery 的 central control point，catalog 在执行 security policies 和确保 compliance 方面发挥关键作用。Apache Iceberg 提供 schema enforcement 和 transactional integrity 方面的保证，但决定谁能看到哪些 tables、允许执行哪些 actions，以及 metadata 如何访问和管理的，是 catalog。

大多数组织已经建立了 identity and access management（IAM）systems。能够与这些系统集成的 catalogs，例如 Amazon IAM、LDAP、OAuth 或 custom token services，可以简化 user management，并让 Iceberg 与 enterprise security practices 对齐。这种集成也支持 fine-grained permissions，确保不同 roles 只能按合适权限管理、查询或修改 metadata。

Encryption，包括 in transit 和 at rest，是另一个关键关注点。虽然 storage layer 通常会加密 data files，但 catalog metadata 也必须受到保护，尤其是当它包含 snapshot history、partition values 或 schema evolution records 时。Catalogs 应使用 secure communication protocols，例如 HTTPS 或 gRPC over TLS，并支持任何 persisted state 的 storage encryption。

Compliance requirements 也经常塑造 catalog architecture。法规可能要求数据位于特定地理边界内、强制记录 administrative actions，或对 metadata retention 和 deletion 进行正式控制。在受监管环境中，生成 audit trails 并执行 metadata lifecycle policies 的能力不只是有益，而是必要。

关键问题包括：

• Catalog 是否支持与你现有 IAM 或 SSO systems 集成？
• Metadata operations 是否加密并安全存储？
• Catalog 能否提供监管合规所需 audit trails 和 controls？

满足 security 和 compliance requirements 的 catalog，有助于防止 unauthorized access，支持 regulatory alignment，并从基础层增强数据平台的可信度。

7.2.4 Deployment Flexibility 和 Ecosystem Compatibility

随着数据架构变得更加分布式和异构，catalog flexibility 变得必不可少。无论你的平台跨 on-premises clusters、多个 cloud providers，还是 hybrid environments，catalog 都必须跨这些边界可靠运行。Deployment flexibility 和 ecosystem compatibility 决定了 catalog 多容易融入基础设施，以及如何与其他工具交互。

Deployment flexibility 指 catalog 能够根据组织 infrastructure 在不同 environments 中运行的能力。有些 catalogs 与特定 compute engines 或 storage ecosystems 紧密集成，而另一些可以作为 standalone services 运行。这些 standalone catalogs 可以 self-hosted，也可以由 vendors 作为 managed services 交付。REST-based catalogs 尤其有吸引力，因为它们暴露一致 interface，使 tools 和 services 可以与 catalog 通信，而不受 programming language 或 cloud platform 限制。

虽然 REST interfaces 让 catalogs 具备 environment agnostic 特性，但 catalog service 仍然必须物理运行在某处，无论是 on premises、cloud region，还是分布在多个 locations。实践中，catalog interactions 通常 throughput 和 concurrency 比 raw request latency 更重要。与从 storage 读取 data files 的成本相比，大多数 catalog operations 涉及的 metadata calls 相对较少，因此 single-digit 与 tens of milliseconds 之间的差异，很少影响 end-to-end query performance。但在规模化下，sustained throughput 会变得关键，尤其是在有许多 concurrent writers、频繁 commits 或大量 tables 和 snapshots 的 environments 中。因此，评估 network placement 时，应关注 reliability、bandwidth，以及 catalog 处理 concurrent metadata operations 的能力，而不是单纯最小化 round-trip latency。在某些 use cases 中，例如 highly write-heavy pipelines 或跨数千 datasets 的大规模 table discovery，distance 和 network characteristics 仍可能成为因素，但应放在整体 system throughput 和 workload patterns 的上下文中考虑。

与 stack 其他部分的 compatibility 同样重要。Catalog 必须与 Apache Spark、Flink、Trino 或 Dremio 等 processing engines 无缝协作。它应在这些 engines 之间支持相同 table resolution 和 transaction models，确保无论 execution environment 如何，行为都保持一致。实现 Apache Iceberg REST specification 的 catalogs 通常在 tools 和 vendors 之间提供更广泛 compatibility。

另一个考虑因素是 catalog 对 automation 和 orchestration frameworks 集成的支持程度。CI/CD pipelines、schema registries 和 metadata governance tools 都受益于 catalogs 暴露 APIs、支持 declarative configuration，并输出 machine-readable metadata。

一些关键评估问题包括：

• Catalog 是否可以部署在你偏好的 environment 中，例如 cloud、on-premises 或 containerized？
• 它是否支持团队使用的所有 query 和 processing engines？
• 它是否 REST compliant，或是否有良好文档支持与 external systems 集成？

选择一个匹配 deployment model 并与 ecosystem 干净集成的 catalog，可以减少 operational friction，并提升 lakehouse architecture 的长期适应能力。

7.2.5 Cost 和 Operational Overhead

虽然 performance、governance 和 compatibility 常常是首要考虑，但 cost 和 operational burden 会悄悄塑造 catalog 的长期可行性。这些因素不仅包括 licensing 或 cloud usage 等直接支出，也包括长期部署、监控和维护 catalog 所需的努力。

Self-managed catalogs，例如本章讨论的许多 OSS catalogs，可能没有 licensing fees，但需要 engineering effort 来部署、配置、安全加固和升级。随着规模增长，这种投入会增加，尤其是在需要 high availability 或 multiregion deployment 的 environments 中。相比之下，managed services 会降低 operational complexity，但可能引入 vendor lock-in，或随时间增长的 usage-based costs。

Monitoring 和 observability 也会增加 operational overhead。提供清晰 metrics、structured logs，并与 alerting systems 集成的 catalog，可以帮助团队尽早发现问题并快速响应。缺少这种可见性的 catalogs 通常需要更多手动 troubleshooting，增加 support effort 和 time to resolution。

Documentation 和 community support 也是 operational equation 的一部分。拥有成熟文档、活跃 maintainers 和响应迅速 forums 的 catalogs，可以加速 onboarding，并减少对内部专家的依赖。当需要 custom integration 或 advanced tuning 时，这种支持尤其重要。

评估 catalog costs 和 overhead 时，可以考虑这些问题：

• 规模化运营 catalog 的 infrastructure 和 personnel costs 是多少？
• 它是否提供 monitoring、logging 和 automated recovery features？
• Development community 或 vendor support channel 有多活跃？

平衡 feature depth 和 operational simplicity 是关键。技术能力最强的 catalog 如果需要持续维护或超出预算，也未必合适。同样，一个轻量 catalog 如果易于集成且高效运行，即便缺少高级功能，也可能提供长期价值。

7.2.6 Catalog Federation 和 Mesh Architectures

组织结构、合规要求和区域部署约束，常常需要使用多个 catalogs。每个 catalog 独立运行，但仍然需要参与一个连贯生态。这正是 catalog federation 和 mesh architectures 变得关键的地方。

Federated catalog architecture 允许部署在不同 clouds、geographies 或 business units 的多个 catalog instances 自主运行，同时仍然提供 Iceberg tables 的统一 global view。在这个模型中，每个 catalog 管理自己的 namespace、access policies 和 metadata operations，但暴露共同 interface，使整个 mesh 中的 discovery 和 access 成为可能。

这种方法非常适合 data sovereignty mandates，允许 local catalogs 保持对 data residency、encryption 和 auditability 的控制。同时，它也通过确保 users 和 tools 可以跨边界查询，而无需手动复制 metadata 或跨团队协调，支持 enterprise-wide analytics 和 governance。

采用 catalog mesh 的常见驱动因素包括：

• Regulatory boundaries 要求数据保留在特定 jurisdictions 内
• Decentralized teams 在独立 governance models 下运营
• Cloud-specific deployments，其中 services 绑定到 provider-native catalogs，例如 AWS Glue、Azure Purview
• Operational scale，其中单个 catalog 会成为瓶颈或 single point of failure

为了支持 federation，catalogs 必须实现以下功能：

• 一致 APIs，例如 REST 或 gRPC，用于 metadata access 和 synchronization
• Namespace resolution strategies，用于区分 local 和 remote resources
• Security 和 identity propagation，用于维护跨 catalogs 的 access control integrity
• Change propagation mechanisms，例如 event-based sync 或 metadata replication，以保持 federated catalogs 对齐，同时避免 conflicts 或 stale states

评估 catalog implementations 时，可以考虑这些问题：

• 它能否参与 federation layer，或与 external discovery services 集成？
• Mesh 中 conflicts、updates 和 access controls 如何管理？

架构良好的 catalog federation 使组织能够在不牺牲 autonomy、compliance 或 visibility 的情况下扩展 Iceberg lakehouses。它体现了从 centralized control 到 distributed coordination 的转变，而这是数据生态复杂性增长时的必要演进。

7.3 Apache Iceberg REST Catalog Specification

Lakehouse architecture 的核心承诺之一是 compatibility 和 interoperability：许多 engines 和 tools 能够通过共享标准，安全地操作同一批 datasets。Apache Iceberg 在 table format 层面实现了这一点，但直到最近，catalog interoperability 仍然落后。早期 catalog integrations 高度依赖 engine-specific client libraries，这些 libraries 往往用单一语言实现，并且在不同 ecosystems 中维护水平不一。更重要的是，大部分 commit coordination 和 metadata updates 职责被推给 client 自身。每个 engine 都必须正确实现 commit logic、处理 concurrent updates，并写入 metadata artifacts，这导致不同版本之间行为不一致、微妙 correctness bugs，以及 tools 之间碎片化行为。缺少标准化 server-side commit model，使 multi-engine interoperability 在实践中变得脆弱。近期 catalog designs 开始朝着将 commit logic 完全从 clients 解耦的方向发展，把 transactional responsibility 集中到 catalog service 自身。这个转变与 common APIs 一起，是让 Iceberg 真正成为 interoperable foundation 的关键一步，也反映了整个生态正在演进的方向。

Apache Iceberg REST Catalog specification 的引入，标志着重大进步。它定义了一套一致的 HTTP-based interface，用于 catalog operations，并将 client 与 catalog implementation 解耦。这使组织可以更容易地混合搭配 query engines 和 catalog services，允许架构演进，而不被锁定在特定 vendor 或 language ecosystem 中，如图 7.7 所示。

图 7.7：使用 REST Catalog specification，用任何语言编写的 client 都可以与所有 catalogs 通信，无论 catalog server 用什么语言编写，从而提升 interoperability。

本节讨论 REST Catalog specification 出现之前存在的碎片化环境、创建它的技术理由，以及它为 Iceberg users 和 catalog implementers 带来的价值。我们也会强调支持 REST interface 的 catalog services 生态正在增长，以及这对 cross-platform lakehouse deployments 意味着什么。

7.3.1 Apache Iceberg REST Catalog Specification 之前

在 Apache Iceberg REST Catalog specification 引入之前，catalog integrations 的局面是碎片化且不一致的。Catalog functionality，例如 listing namespaces、registering tables 和 committing changes，与 language-specific client libraries 紧密耦合。每个 catalog provider 通常必须在 Java、Python、Go 和 Rust 等多种语言中实现并维护 client libraries。但这些 implementations 的支持水平和 feature completeness 差异很大。

这种不一致为 catalog providers 和 Iceberg users 带来大量挑战，其中 correctness 是最严重的问题。一个 catalog 可能在某种语言中有稳健支持，例如 Java，但在 Python 或 Go 中暴露不完整或细微不同行为。由于 commit coordination 和 metadata updates 在 client libraries 中处理，每个 engine 实际上都重新实现了 Iceberg transactional logic 的一部分。即使是 client versions、dependency resolution 或 classpath configuration 中的细小不匹配，也可能导致错误的 conflict detection、lost updates 或 inconsistent table state。虽然这些问题通常表现为 runtime errors，但更危险的情况是 silent correctness bugs：某个 write 看起来成功了，却违反了预期 transactional guarantees。这使 multi-engine environments 变得脆弱，迫使团队严格控制版本和 integrations，以维护 data integrity。

此外，将 catalog logic 嵌入每个 client library 的需求导致重复工作，并拖慢创新。Catalog 中的每项新功能都必须在所有支持的 client languages 中重新实现和测试，如图 7.8 所示。这使 catalog vendors 难以确保跨 engines 的行为和性能一致。

图 7.8：在 REST Catalog specification 之前，每个 catalog service 都必须在每种语言中维护自己的 client libraries，造成一个难以维护的碎片化环境。

问题并不是 Spark、Flink 或 Trino 等 engines 完全无法与 catalogs 通信；大多数环境都标准化在 Hive Metastore（HMS）上，它提供了广泛但并不完美的 interoperability。更深层问题在于 correctness 和 transactional behavior 很大程度上存在于 client implementations 中，而不是 catalog 本身。每个 engine 和 client library 都负责正确且一致地实现 commit logic、conflict detection 和 metadata updates。随着 Iceberg adoption 扩大，workloads 变得更加并发且涉及多个 engines，这种模型越来越脆弱。在规模化下，保持所有 clients 更新、行为对齐且不包含微妙 transactional bugs 非常困难。这种复杂性暴露了对更集中、engine-agnostic 方法的需求：correctness 和 commit coordination 应由一个地方以一致方式处理，而不是由每个 client 重复实现。

7.3.2 解决方案

为了解决碎片化 catalog client libraries 带来的 interoperability 和 maintenance challenges，Iceberg 社区引入了 Apache Iceberg REST Catalog specification。这个 spec 定义了一套一致、engine-neutral、基于 HTTP 的 API，用于与 catalogs 交互。Engines 和 applications 不再把 logic 嵌入每个 client library，而是可以使用 shared、language-independent protocol 与任何 compliant catalog 通信。

REST Catalog specification 标准化了 retrieving table metadata、listing namespaces、registering new tables 和 committing changes 等 operations。这简化了 client implementations，并确保不同 catalogs 和 engines 之间行为统一。采用 REST interface 后，catalog services 不再需要构建和维护大量 language-specific client libraries，如图 7.9 所示。Spark、Flink、Trino 等 engines 可以通过共同 interface 直接集成。

图 7.9：有了 REST Catalog specification，同一个 client library 可以用于所有 catalogs，减少碎片化，并提升 Iceberg catalogs 之间的 interoperability。

这种方法为 users 和 catalog providers 带来即时和长期收益。Users 可以选择最适合自身环境的 catalog，而不受 language bindings 或 engine-specific client implementations 限制。更重要的是，REST-based model 允许 Apache Iceberg 逐步将更多职责从单个 engines 转移到 catalog 自身。Scan planning 等 APIs 让 clients 不再需要理解 manifest parsing 或 file-level planning 等低层细节；centralized commit APIs 则使 transactional logic 和 conflict resolution 位于同一个地方。这创造了一个单一、权威的 correctness enforcement 层。对于 catalog providers，这一转变使其可以一致地实现更深能力，例如 fine-grained access control、policy enforcement 和 governance features，同时降低整个生态中 heavyweight client libraries 的复杂性和脆弱性。

REST Catalog specification 很快获得采用，几个主要 catalogs 现在都支持它，包括 AWS Glue Data Catalog、Apache Polaris、Apache Gravitino、Lakekeeper、Nessie、Dremio catalog 和 Snowflake Open Catalog。随着 adoption 增长，组织获得了演进数据基础设施的灵活性，而不必重构周边 tools 或 pipelines。

本质上，REST specification 将 Iceberg catalog layer 从一个紧耦合 integration point，转变为开放、可组合的 interface。这增强了 lakehouse architectures 的 modularity 和 durability，并在 metadata layer 实现真正 interoperability。

7.4 Catalog Options：探索生态系统

Apache Iceberg 支持灵活的 catalog interface，catalog implementations 生态仍在持续扩展。这些 catalogs 在 architecture、operational model 和 integration depth 上各不相同，但都旨在完成前面描述的核心职责：管理 table metadata、协调 transactions，并让多个 engines 能访问 datasets。

Catalogs 大致分为几类。有些，比如 Hadoop 和 JDBC catalogs，内置在 Iceberg libraries 中，除了 JDBC-compatible database 之外不需要额外 services。这些适合较简单 deployments 或希望最小化外部依赖的 development environments。

另一些，例如 Apache Polaris、Project Nessie、Apache Gravitino 和 Lakekeeper，是 open source 且 self-managed 的。这些 catalogs 被设计用于支持 REST-based access、version control 和 multi-tenant environments 等高级 metadata capabilities。它们提供更大 flexibility 和 extensibility，但需要 infrastructure planning 和 operational oversight。

最后，还有几个 catalogs 由 cloud 和 analytics vendors 提供并维护，包括 AWS Glue Data Catalog、Dremio catalog，基于 Apache Polaris，以及 Snowflake Open Catalog，同样基于 Polaris。这些 managed services 通常与各自平台深度集成，提供简化 setup、内置 security 和 scaling。但它们也可能对 customization 或 portability 施加限制。

本节将逐一介绍这些 catalog types，强调它们的 architectures、capabilities 和 tradeoffs，其中部分内容总结在表 7.1 中。通过比较它们的 features 和 deployment models，你将获得把 catalog choice 与组织 goals 和 constraints 对齐所需的背景。

表 7.1：Apache Iceberg catalogs 对比

Name	OSS	REST catalog	Features
Hadoop	Yes	No	不需要 service；可能存在 consistency issues
JDBC	Yes	No	可以使用任何 JDBC database 作为 catalog
Hive	Yes	No	利用现有 Hive catalog
Apache Polaris	Yes	Yes	RBAC；catalog federation；multi-tenancy
Project Nessie	Yes	Yes	Git-like catalog versioning
Apache Gravitino	Yes	Yes	与 Hive federation；geodistributed catalog
Lakekeeper	Yes	Yes	Rust-based；支持 data contracts
AWS Glue Data Catalog	No	Yes	集成在 AWS tooling 中
Dremio catalog	Polaris-based	Yes	构建在 Apache Polaris 上的商业服务，具备自动 table maintenance；基于 maintenance 使用的 compute 收费；external requests 不收费
Snowflake Open Catalog	Polaris-based	Yes	构建在 Polaris 上的商业服务；按 catalog requests 收费
Databricks Unity	No，OSS version 是不同 codebase	Yes	支持 Iceberg 和 Delta Lake

7.4.1 Hadoop Catalog

Hadoop catalog 是管理 Iceberg metadata 最简单的方式之一。它直接内置于 Apache Iceberg library 中，不需要任何 external service 或 runtime component。相反，它会在 Hadoop-compatible filesystem 中以结构化 directory layout 存储 table metadata，例如 HDFS、Amazon S3 或 Azure Data Lake Storage。

每张 table 的 metadata 都存储在 common warehouse root 下的单独 subdirectory 中。Catalog 将 table names 映射到这些 directories，并在本地管理它们的 metadata references。由于 metadata 与 data 本身一起存储，如图 7.10 所示，这种方法设置直接，也容易理解。

图 7.10：使用 Hadoop catalog 时，会用一个名为 VERSION-HINT.TEXT 的文件来发现 metadata file，而不是向 catalog service 发送 request。

Key characteristics：

Local state management——所有 catalog operations 都是 filesystem-based。Table registration、updates 和 deletions 通过直接操作 metadata files 来处理。

No external dependencies——没有 server 需要部署，也没有 service 要管理。Catalog 完全运行在 client 的同一 context 中，例如 Spark 或 Flink。

Namespace support——Table names 通过 directory hierarchies 被组织进 logical namespaces，例如 warehouse/analytics/marketing/sales_data。

Strengths：

• 配置快，适合 local development 或 isolated environments
• 适合 single-user 或 tightly controlled workloads
• Operational overhead 最小，不需要单独 metadata service

Limitations：

• 缺少跨 engines 的 concurrent writes 所需的 centralized transaction coordination
• 不支持 remote access 或 REST APIs，使跨 environments 或 teams 的集成更困难
• 不适合需要 access control 和 lineage tracking 的 multi-tenant 或 multiregion lakehouses
• 已 deprecated，不鼓励用于 Apache Iceberg

Hadoop catalog 最好被视为 legacy 或 transitional option，而不是现代 Iceberg deployments 的推荐选择。虽然它仍可能出现在示例或历史 setups 中，但它缺少 real-world production environments 所需的 scalability、correctness guarantees 和 centralized coordination。对于任何涉及多个 tools、concurrent writers 或 shared infrastructure 的 deployment，service-oriented catalog 不只是更可取，而几乎是必需的。

7.4.2 Hive Catalog

Hive catalog 允许 Apache Iceberg 使用现有 Hive Metastore（HMS）作为 catalog backend。这对已经重度投资 Hive-based data platforms，并希望增量迁移到 Iceberg 而不彻底重构 metadata management infrastructure 的组织来说很有吸引力。

使用 Hive catalog 时，Iceberg tables 会注册在 HMS 中，Spark、Trino 和 Flink 等 engines 可以通过各自 Hive integration layers 与 catalog 交互。这种兼容性使得在 legacy Hive tables 旁边逐步采用 Iceberg 相对直接。

Advantages：

• 使用现有 HMS infrastructure
• 被 Spark、Flink 和 Trino 等流行 engines 良好支持
• 对已经使用 Hive 的团队来说，integration patterns 熟悉

Tradeoffs：

• 缺少一些依赖更现代 catalog capabilities 的 Iceberg features，例如 namespace operations 和 fine-grained role-based access control
• 不支持 REST Catalog API，限制与新兴工具的 interoperability
• 容易受到 HMS 限制和 scalability problems 影响

Hive catalog 应被视为历史集成点，而不是新 Iceberg deployments 的推荐选项。它在早期采用阶段通过利用 HMS 发挥了重要作用，但现代 HMS implementations 如今已经直接暴露 REST interfaces。因此，使用 Apache Iceberg Hive Catalog plugin 会增加不必要的间接性和复杂性。对于今天采用 Iceberg 的团队，实现 Iceberg REST APIs 的 service-oriented catalogs，比 legacy Hive-based integrations 提供更干净、更正确、更面向未来的基础。

7.4.3 JDBC Catalog

JDBC catalog 是 Apache Iceberg 提供的另一个内置选项。它不是将 metadata pointers 存储在 filesystem 中，而是使用 relational database 管理 catalog state。Table 和 namespace information 会持久化到一组 catalog tables 中，所有 operations，例如创建、更新或删除 Iceberg tables，都会通过标准 SQL transactions 执行。

Supported databases 包括 PostgreSQL、MySQL，以及其他提供 JDBC-compliant drivers 的数据库。该方法相比 Hadoop catalog 提供更强 transactional guarantees，并让多个 compute environments 可以共享 centralized metadata store。

Key characteristics：

SQL-backed metadata store——Metadata pointers 和 namespace hierarchies 存储在 database 的 structured tables 中。

ACID guarantees——SQL transactions 确保 atomic updates，并降低 concurrent operations 期间 metadata inconsistencies 的风险。

Single-node architecture——Catalog server 嵌入在 client 中，例如 Spark job 或 application，但 backing store 支持 jobs 之间共享 state。

Strengths：

• 如果已有 JDBC-compatible database，配置简单
• 对 multi-engine access 来说，比 Hadoop catalog 更容易扩展
• 支持带 transactional integrity 的 concurrent writes，更适合 collaborative environments

Limitations：

• Catalog client 仍在每个 engine context 内运行，因此 scaling 取决于底层 database performance。
• 没有内置 REST interface，remote access 和 cross-language integration 必须通过 Iceberg client library 完成。

JDBC catalog 介于 file-based simplicity 和完整 catalog services 之间。对于希望集中协调，但又不想引入新的 catalog runtime 的团队，尤其是当可靠 relational database 已经是 stack 的一部分时，它是一个实用选择。

7.4.4 Apache Polaris

Apache Polaris 是 Apache Iceberg 的 open source、REST-based catalog implementation。Polaris 面向 multi-engine environments 设计，充当 Iceberg table metadata 的 centralized coordination layer，为 Spark、Flink、Trino 和 Snowflake 等 engines 提供一致、安全访问。

Polaris 构建在 Apache Iceberg REST Catalog specification 之上，支持与 cloud-native architectures 对齐的 decoupled metadata access。它支持 internal 和 external catalogs，并引入 service principals、RBAC 和 temporary credential vending 等高级概念。

Polaris 作为 standalone service 运行，通常部署在一个安全环境中，并拥有对 cloud object storage 的访问权，例如 S3、ADLS 或 GCS。Polaris 中配置的每个 catalog 都会映射到特定 cloud storage location，并管理一张或多张 Iceberg tables 的 metadata pointers。

Polaris 可以与 internal 和 external catalogs 协作：

Internal catalogs 完全由 Polaris 管理。Tables 通过 Polaris APIs 注册、更新和访问，而 data 和 metadata 位于你的 cloud storage 中。

External catalogs 允许 Polaris 从其他地方管理的 catalogs，例如 Glue 或 Dremio，同步 metadata。这些 tables 在 Polaris 中是 read-only 的，使这种模型适合 centralized visibility，而不接管 write operations。

Polaris 通过分层 RBAC system 执行 security：

Service principals 代表 users 或 systems，例如 Spark jobs、BI dashboards。

Principal roles 将具有共同 access requirements 的 service principals 分组。

Catalog roles 在 catalog、namespace 和 table levels 定义 privileges，并分配给 principal roles。

这种结构支持 fine-grained delegation of permissions，例如授予 data scientists read-only access，同时让 data engineers 拥有完整 table management 权限。Credential vending 确保 query engines 在 runtime 获得 temporary access credentials，避免直接暴露 cloud storage credentials。

Polaris 被设计为 query-engine agnostic。任何支持 Iceberg REST protocol 的 engine 都可以与其交互。Polaris 还支持 advanced namespace hierarchies、metadata introspection 和对 Iceberg tables 的 versioned access，从而支持稳健 lifecycle management。

Strengths：

• 跨 engines 的 centralized、REST-based metadata coordination
• 内置支持 multicloud storage backends
• 通过 RBAC 支持 fine-grained access control
• External catalog support，支持统一 metadata visibility
• Secure credential vending，降低暴露风险
• 支持不同 persistence backends，例如 Postgres 等

Limitation：

• 需要 infrastructure deployment 和 operational management

Polaris 非常适合希望拥有 centralized metadata plane 的组织，这类组织需要支持多个 compute engines 并执行一致 governance。它的 standards-compliant interface 和 extensible design，使其成为跨团队和 cloud environments 的 production-grade Iceberg lakehouses 的强候选方案。

7.4.5 Project Nessie

Project Nessie 是一种 open source catalog implementation，旨在将 Git-like version control semantics 带入数据湖。它作为 Apache Iceberg 的 metadata coordination layer，支持跨一张或多张 tables 的 atomic、isolated 和 auditable changes。Nessie 作为带有多语言 client libraries 的 REST service 构建，支持多种 backends，并可直接与 Spark、Flink 和 Trino 等工具集成。Nessie 也支持 Apache Iceberg REST Catalog interface。

Nessie 的核心是维护 metadata operations 的 versioned history。对 table 的每次 change，例如 appending files、modifying schemas 或 deleting partitions，都会记录为一次 commit。这些 commits 像 Git 中一样被分组到 branches 上，允许 experimentation、staging 和 production changes 并存且不冲突。Tags 为特定时间点提供 immutable references。

Nessie 只作为 coordination layer；它不直接管理 table metadata 或 data files。相反，它将 metadata storage 和 table operations 委托给 Iceberg，同时通过自己的 version log 维护它们演进的一致视图。这种分离支持 massive scalability 和 performance。

Nessie 的一个显著特性，是支持在 catalog level 对数据 changes 进行 branching 和 merging。Analytics jobs 或 ingestion pipelines 可以通过写入专用 branch 来隔离运行。一旦 job 成功完成，其所有 changes 可以 atomically merge 到 mainline。这种模型避免暴露 incomplete data，并提供强大的 rollback 和 debugging capabilities。

Nessie 支持跨多张 tables 的 transactions，这在 distributed data lake environments 中传统上很难实现。通过将跨 tables 的 changes 归为单次 commit，或通过 merge 专用 work branch，Nessie 保证 consistency 和 atomicity。这在 schema evolution 或 ingestion 需要同时发生在相关 datasets 上时尤其有价值。

当与 Iceberg REST protocol 一起使用时，Nessie 可以向 Spark 或 Trino 等 client engines 推送 configuration 和 temporary credentials。这种方式使这些 engines 无需配置直接访问 cloud storage credentials，从而提高安全性并简化 deployment。例如，object store credentials 可以在 query execution 期间通过 request signing 被安全发放。

Nessie 面向 high-throughput environments 设计，支持每秒数千 commits 和大规模 metadata operations。它可以部署在 Docker 或 container-native platforms 中，并支持 DynamoDB、PostgreSQL 和 Cassandra 等 pluggable metadata backends。Nessie 的 REST API 也支持与 CI/CD pipelines 或 custom data management applications 集成。

Strengths：

• 数据湖的 Git-like version control
• Branches 和 tags，用于 isolated development 和 reproducibility
• 原生支持 cross-table transactions 和 rollback
• REST API 和 multilanguage client support
• 兼容 Iceberg REST，并与 Spark 和 Trino 等 engines 集成

Limitation：

• 需要单独 deployment 和 operational footprint

Nessie 最适合重视 data reproducibility、safe experimentation 和 robust governance 的组织。它的模型弥合了传统 source control 与大规模 data lakes 不断演进需求之间的差距，使其成为现代 Iceberg-based architectures 的有吸引力选项。

7.4.6 Apache Gravitino

Apache Gravitino 是一个 federated、geodistributed metadata lake，为广泛 data 和 AI assets 提供统一访问和治理。作为 Apache project，Gravitino 提供一个可扩展平台，能够跨不同 storage systems、regions 和 data formats 管理 metadata。它既是 metadata catalog，也是 governance layer，并通过 REST catalog interface 与 Apache Iceberg 深度集成。

Gravitino 为 metadata management 引入 multilayered architecture：

Metalake 是顶层 container，通常用于按 organizational group 或 tenant 划定 metadata 范围。

Catalogs 连接到特定 data sources，例如 Iceberg、Hive、Kafka、HDFS，并通过 Gravitino 暴露 metadata。

Schemas 和 tables 表示 tabular sources 的结构化 metadata objects，而 filesets、models 和 topics 则支持 unstructured 和 AI-related metadata。

这种灵活 object model 允许 Gravitino 在单一 governance domain 中管理 data lakes、message systems 和 machine learning artifacts 的 metadata。

Gravitino 实现 Apache Iceberg REST Catalog interface，因此兼容任何 Iceberg-aware engine。它还提供 Hive、MySQL、PostgreSQL 等 connectors，使其可以作为 hybrid environments 中的 centralized metadata hub。

它的 REST API、Java SDK 和 Python SDK 让广泛平台都能访问它；Web UI 和 CLI 则简化 administration。Gravitino 可以本地运行、在 containers 中运行，也可以跨 cloud regions 部署，并支持 georeplication。

Gravitino 包含内置 metadata governance 能力：

• Access control 支持跨所有 cataloged assets 的 role-based policies。
• Tag management 支持 classification 和 discovery。
• Audit logging 和 security controls 与 enterprise authentication methods 集成，包括 OAuth 和 Kerberos。

这些功能确保跨 distributed metadata domains 的一致 security 和 visibility。

Gravitino 尤其适合以下组织：

• 拥有 heterogeneous storage systems，需要 unified metadata access
• 具备 global operations，受益于 federated catalog deployment
• 资产多样，横跨 tabular data、unstructured files 和 AI models

Strengths：

• 统一 cataloging tabular、file-based 和 AI model metadata
• REST-compatible Iceberg catalog integration
• Web UI、CLI 和 SDK support，用于全面 administration
• 可扩展到 hybrid cloud 和 multiregion use cases

Limitations：

• 仍在孵化和演进，一些 enterprise features 可能仍处于早期阶段
• Georeplication 和 advanced access control features 仍在成熟中
• 由于 scope 和 flexibility 很广，operational complexity 可能更高

Gravitino 在 metadata catalog landscape 中填补了一个独特 niche，提供跨 formats 和 domains 的广泛水平集成。对于与多种 data systems 共存的 Iceberg deployments，Gravitino 提供一个 centralized plane，用于 metadata access 和 policy enforcement，因此是复杂 federated data lakehouses 的有价值选项。

7.4.7 Lakekeeper

Lakekeeper 是 Apache Iceberg REST Catalog specification 的轻量、安全且可扩展实现。Lakekeeper 使用 Rust 构建，为 Iceberg environments 提供快速、无 JVM 的 deployment option。它支持 fine-grained access control、storage credential vending，并与 OpenID Connect 和 Kubernetes service accounts 等现代 authentication systems 集成。通过对 Trino、Spark、PyIceberg 和 StarRocks 的原生支持，Lakekeeper 交付 production-ready、scalable catalog，适合广泛 data lakehouse scenarios。

Lakekeeper 作为 standalone binary 运行，避免 JVM 或 Python environments 的 overhead。它被设计为使用 Docker 或 Helm 部署在 containerized environments 中，并可轻松集成到 Kubernetes-based infrastructure。其核心中，Lakekeeper 提供两个 APIs：

Iceberg REST API，位于 /catalog，供 client query engines 使用。

Management API，位于 /management，用于配置 Lakekeeper entities，例如 projects、warehouses、roles 和 permissions。

Lakekeeper 使用 PostgreSQL 做 catalog persistence，并支持 external secret stores，例如 Vault，以及 event stores，例如 Kafka、NATS，以实现 secure、auditable operations。

Lakekeeper 通过 projects 和 warehouses 的概念支持 multi-tenant architectures。单个 server 可以管理多个 projects，每个 project 可以有多个 warehouses。每个 warehouse 定义自己的 object store location 和 authentication configuration。Lakekeeper 会确保这些 locations 不重叠，防止因 credential misuse 造成 data leakage。

Fine-grained access control 通过 OpenFGA integration 或 custom authorizers 提供。Users 和 roles 在外部管理，authentication 委托给 OpenID-compliant identity providers。Permissions 会在 catalogs、namespaces、tables 和 views 上执行。Lakekeeper 还支持 recursive 和 force deletion APIs，以安全、灵活地管理 protected hierarchies。

Lakekeeper 包含多项高级 governance features：

Soft deletion——Tables 可以被标记删除，但保留一个可配置 expiration period，支持 recovery 和 safe rollbacks。

Change approval hooks——Integrations 可以拦截并拒绝违反 data contracts 或 quality thresholds 的 changes。

Remote signing and credential vending——Clients 在 query time 获得 temporary credentials，降低 long-lived storage credentials 暴露风险。

这些机制提升 operational safety，并执行 secure、governed data lake usage 的最佳实践。

Strengths：

• Lightweight、Rust-based deployment，无 JVM requirement
• 完整实现 Iceberg REST Catalog interface
• 集成 storage credential vending 和 soft deletion mechanisms
• 与 Kubernetes 深度集成，支持 OpenID-based authentication
• 通过 pluggable interfaces 和 trait-based extensions 高度 customizable

Limitation：

• 当前仅支持 PostgreSQL 作为 backend

Lakekeeper 非常适合希望获得 secure、scalable、cloud-native catalog service 的团队，这种服务易于部署，并与现代基础设施紧密集成。它尤其适合那些希望嵌入强 governance practices，并与 CI/CD workflows 和 custom approval systems 集成的组织。

7.4.8 AWS Glue Data Catalog

AWS Glue Data Catalog 是 Amazon 的 managed metadata service，也是 cloud-native lakehouse architectures 中 Iceberg catalog implementations 的热门选择。每个 AWS account 每个 region 有一个 Glue Data Catalog，它作为跨 databases 和 tables 的 centralized、scalable metadata repository。通过与 Athena、Redshift Spectrum、SageMaker Unified Studio、S3 Tables 和 EMR 等 Amazon services 的集成支持，Glue 为 data discovery、transformation 和 governance 提供无缝环境。

AWS Glue Data Catalog 可以作为 Apache Iceberg 的 metadata catalog，使你可以使用 Glue Catalog 注册和管理 Iceberg tables。这种集成通过配置 compute engines 连接到 Glue 的 REST endpoint 实现，使它们能够读取和写入由 AWS 管理 metadata 的 Iceberg tables。

另外，AWS Glue Spark engine versions 3.0 和 4.0 内置支持 Apache Iceberg 等 transactional table formats。这意味着 engine 已预配置必要 libraries，可以识别并操作 Iceberg tables，无需额外 setup。对于需要特定 Iceberg versions 或高级功能的 use cases，用户可以通过在 job configuration 中提供 custom JARs 或 connectors 来覆盖默认行为。

要在 AWS Glue Engine 中配置 Iceberg，通常按以下步骤：

• 设置 --datalake-formats iceberg 以启用 native support。
• 指定 org.apache.iceberg.aws.glue.GlueCatalog implementation。
• 使用 org.apache.iceberg.aws.s3.S3FileIO 在 S3 上进行 optimized I/O。

这些配置可以通过 visual tools、notebooks 或 script-based Glue jobs 应用。

AWS Glue Data Catalog 与 AWS Lake Formation 和 identity and access management（IAM）紧密集成，以提供 fine-grained access controls。通过这种模型，企业可以安全地跨部门发布和共享数据，同时限制敏感信息。结合 AWS CloudTrail，Glue Data Catalog 为 metadata 和 schema changes 提供强 auditability。

AWS Glue Data Catalog 是多个 AWS analytics 和 machine learning services 的 metadata backbone。它作为 SageMaker Lakehouse service 的底层 catalog，使 SageMaker Studio 中的用户可以创建并与 Iceberg tables 交互。这些 tables 也可以通过 Amazon Athena、Amazon Redshift 和 SageMaker 本身等 services 查询，从而统一 analytics 和 ML workloads 访问。此外，S3 Table feature 直接与 Glue Catalog 集成，使用户能够使用熟悉的 DDL commands 在 Amazon S3 上定义 Iceberg-compatible tables，而不需要管理外部 metadata services。

Strengths：

• Fully managed metadata store，深度集成 AWS ecosystem
• AWS Glue Data Catalog Spark environments 中原生支持 Iceberg
• 通过 IAM 和 Lake Formation 提供强 security、audit 和 access control features

Limitations：

• Regional scope 限制跨 regions metadata sharing，除非复制。
• Glue 与 AWS ecosystem 紧密耦合。
• 相比 self-managed catalogs，对内部机制控制较少。

AWS Glue Data Catalog 非常适合已经承诺使用 AWS infrastructure 的组织。它简化 setup 和 operations，尤其适合希望使用 serverless data integration 和 access governance，而不想管理 infrastructure 的团队。但需要 multicloud portability 或完全控制 catalog internals 的团队，可能更偏好其他选项。

7.4.9 Dremio Catalog

Dremio catalog 是嵌入在 Dremio Enterprise platform 中的 managed Iceberg catalog，构建在 Apache Polaris 之上，而 Apache Polaris 是 Iceberg REST Catalog specification 的 open source implementation。Dremio catalog 旨在简化 enterprise-grade lakehouse deployment，消除管理和运维 standalone catalogs 时常见的摩擦。

Apache Polaris 于 2024 年推出，作为 vendor-neutral、REST-compatible catalog for Apache Iceberg，正在快速获得采用。作为 Dremio catalog 的核心组件，Polaris 使 Dremio 能够为 Spark、Flink 和 Trino 等 query engines 提供 interoperable、secure access to Iceberg tables。这一开放基础允许用户使用任何兼容 engine 读写 Iceberg tables，同时在 Dremio 中集中管理 metadata。

Dremio 在 Polaris 之上扩展了面向 production workloads 的企业功能：

Fine-grained access control——支持 RBAC、row-level filters 和 column masking，确保 secure data access。

Metadata lineage and discovery——集成工具帮助 analysts 理解 data dependencies，并通过内置 lineage graphs 跟踪 transformations。

Natural language discovery——Business users 可以使用 metadata annotations 和 descriptive labels 探索和理解 datasets。

Dremio 自动化关键 Iceberg maintenance operations，例如 compaction 和 vacuum。这降低了 operational burden，并帮助在无需外部 orchestration 的情况下确保 performance。Catalog 支持 clustering keys，以优化 data layout，并完全集成到 Dremio UI 和 query interface 中，使注册、管理和查询 Iceberg tables 变得简单。

Dremio catalog 嵌入在所有 Dremio Enterprise deployments 中。Catalog operations 不需要单独 infrastructure。每个 catalog subfolder 都可以映射到不同 storage destination，Dremio 原生 access controls 会无缝扩展到所有 managed tables 和 views。

Strengths：

• 内置于 Dremio deployments，并 fully managed
• 由 Apache Polaris 驱动，提供广泛 interoperability
• Enterprise-grade security 和 metadata governance
• 自动化 Iceberg maintenance 和 performance tuning

Limitations：

• 需要采用 Dremio platform，不过你仍然可以使用其他 engines 访问该 catalog
• Dremio ecosystem 之外的 catalog flexibility 有限

Dremio catalog 非常适合标准化使用 Dremio platform，并希望最小化 catalog management overhead 的组织。它提供 production-ready、interoperable catalog experience，简化 Iceberg adoption，并加速 data product delivery。

7.4.10 Snowflake Open Catalog

Snowflake Open Catalog 是 Apache Iceberg REST Catalog specification 的 fully managed implementation，托管在 Snowflake infrastructure 上，并由 Apache Polaris 驱动。虽然它由 Snowflake 维护，但你不限于使用 Snowflake compute engine。Apache Spark、Flink、Trino 或 Dremio 等 external query engines 可以通过 REST interface 连接到 Open Catalog，以读取或写入 Iceberg tables。该设计支持对存储在 Amazon S3、Azure 或 Google Cloud 中的 Iceberg tables 进行 secure、governed access，使其成为 hybrid 和 multi-engine environments 的灵活选项。

Snowflake Open Catalog 支持 Iceberg 的 REST protocol，允许任何 compatible engine，包括 Apache Spark、Flink 和 Trino，访问并管理 tables。这与 lakehouse 的 storage 和 compute 分离原则一致，同时促进多 engines 对一致 metadata 的访问。

Snowflake Open Catalog 支持 internal 和 external catalogs：

Internal catalogs 完全由 Snowflake 管理。Query engines 使用 credential-vended access 读写这些 catalogs。

External catalogs 从其他 catalog implementations 同步而来，例如 Snowflake、Dremio Arctic。从非 Snowflake engines 视角看，这些 external catalogs 是 read-only 的。

每个 catalog 都配置 cloud storage credentials 和 base directory hierarchy。该 directory structure 强制 tables 之间的严格隔离，并支持一致 namespace mapping。Snowflake 会自动禁止 internal catalogs 中出现重叠 storage paths，以防止 unauthorized access。

Snowflake Open Catalog 采用 centralized RBAC model：

Principal roles 被分配给 Spark 或 Flink 等 engines 的 service principals。

Catalog roles 定义 catalog resources 上的 permissions，并授予 principal roles。

这种分离提供了对 metadata 和 data locations 的 granular、centralized control。Credential vending 通过为 query engines 动态配置 temporary credentials，进一步简化 secure access。

Snowflake Open Catalog 被设计为在多种 compute environments 中服务 Iceberg tables 数据。用户为每个 engine 配置 service connections，例如 Flink ingestion、Spark ETL、Trino BI，并将它们分配给具备 scoped privileges 的 service principals。这种结构支持与 shared catalog 的安全 multi-engine interaction。

Strengths：

• 由 Snowflake 托管的 fully managed service，最小化 operational overhead
• REST-compatible，支持 cross-engine interoperability
• 通过 IAM integration 和 RBAC enforcement 提供强安全态势
• 支持 multicloud storage 和 dynamic credential provisioning

Limitations：

• 当前仅在 commercial regions 可用，不支持 government clouds
• 从其他 providers 同步而来的 external catalogs 写入权限有限
• Catalog metadata API requests 会计费

Snowflake Open Catalog 对投入 Snowflake 的企业来说是强选项，适合希望跨工具统一 metadata，同时保持对存储在自有 cloud infrastructure 中的数据的控制。其 REST-based openness、Polaris foundation 和内置 security controls，使它非常适合 scalable、governed Iceberg lakehouse deployments。

7.4.11 Databricks Unity Catalog

Databricks Unity Catalog 是 Databricks 的 unified governance solution，用于在其平台中管理 data、metadata 和 access policies。它最初设计用于集中控制 Delta Lake tables，现在支持读取和写入 Apache Iceberg tables，为使用 Databricks 并标准化在 Iceberg 上的组织提供新的 interoperability 能力。

通过 Unity Catalog，Databricks 用户可以获得统一 interface，用于跨所有 workspaces 管理 structured 和 unstructured assets。它通过 shared catalog layer 集中 access controls、auditing、lineage 和 data discovery，为 data engineers、analysts 和 machine learning teams 提供一致 governance experience。这包括基于 identity 和 role 的 fine-grained access control，并跨 SQL、Python 和其他 supported languages 执行。

最近加入的原生 Iceberg support 将 Unity Catalog 的能力扩展到 Delta Lake 之外。它允许组织注册存储在 cloud object storage 中的 external Iceberg tables，例如 S3 或 ADLS，或直接在 Databricks notebooks 和 jobs 中创建新的 Iceberg tables。这使团队可以从 Databricks environment 内部操作 shared Iceberg lakehouse，同时保持与也支持 Iceberg format 的 external tools 兼容。

虽然 Unity Catalog 的 Iceberg capabilities 相对较新，但它们发展迅速。这使 Unity Catalog 成为一个可行选项，适合那些希望跨多种 data formats，包括 Delta 和 Iceberg，标准化 governance 和 security，而不碎片化平台运维的组织。

考虑将 Unity Catalog 用于 Iceberg 时，组织应思考这些问题：

• 你现有 platform strategy 是否已经以 Databricks 为中心？
• 你是否需要跨 Delta 和 Iceberg 进行 centralized governance 和 lineage tracking？
• 你是否工作在 single-cloud environment 中，且 Unity Catalog 的 hosted nature 与 deployment model 对齐？

Unity Catalog 对 Iceberg 的支持反映了行业向 open table formats 和 interoperability 发展的更广泛趋势。对于 Databricks 用户，它提供了一条采用 Iceberg 的简化路径，同时保持统一 access control、cataloging 和 auditing capabilities。

7.5 选择合适 Catalog：通过场景评估选项

在可用 catalog implementations 范围很广的情况下，从 vendor-managed services、open source projects 到 lightweight embedded libraries，为你的 Iceberg deployment 选择合适 catalog 可能是一个细致决策。Feature checklists 很有用，但很少能捕捉设计 lakehouse 时涉及的全部 operational、architectural 和 strategic considerations。

本节不会规定单一“最佳”catalog，而是通过一组 illustrative scenarios 展开。这些示例旨在帮助你框定真实 catalog selection 中会出现的问题和取舍。它们强调 governance requirements、infrastructure preferences、team skills、cloud environment 和 cost sensitivity 等因素如何影响选择。

重要的是，这些场景不是对任何具体 catalog solution 的推荐或背书。Catalog landscape 正在快速演进，今天最适合你需求的选项，明天可能会变化。请将下面示例作为思考自己 requirements、评估每种 catalog offering 优势与限制的模型。

审查这些 scenarios 时，可以考虑以下方面：

Interoperability——Catalog 是否支持 Iceberg REST Catalog specification？是否可以跨 engines 和 languages 使用？

Governance and access control——它提供哪些工具来保护和审计 metadata？

Operational overhead——你的团队需要 self-manage catalog，还是可以交给 vendor？

Performance and scale——它能否在规模化下支持 concurrency 和 latency needs？

Community and support——生态有多活跃？可获得什么级别的支持？

以下小节提供具体示例，说明不同 catalog choices 如何与不同 architecture contexts 和 operational goals 对齐。

7.5.1 场景：从 Hive 迁移的中型数据团队

一家零售公司的中型 analytics team 正在从使用 Hive Metastore（HMS）的 legacy Hadoop data warehouse 迁移。该团队熟悉 Spark，也能管理 infrastructure。他们当前运行 on-premises Hadoop cluster，并计划在接下来 12 到 18 个月内逐步迁移到 cloud-based lakehouse。

Requirements：

• 与现有 HMS 无缝兼容
• 支持 Spark 和 Flink 上的 Iceberg tables
• 初始迁移阶段使用 self-managed option
• 对当前 data pipelines 的干扰最小
• 有一条向 cloud-native 和 governed architecture 演进的路径

Evaluation

最初，该团队同时考虑 Hive 和 Hadoop catalogs。Hive catalog 的好处是可以直接集成当前 HMS，使他们无需修改 metadata layer 就能开始使用 Iceberg。这降低了转型阶段的摩擦和风险。

另一种选择是 Hadoop catalog，它提供一种简单、自包含的方法，将 metadata 直接存入 filesystem。它避免了 HMS dependencies，但需要对 metadata management processes 做更多修改。

Outcome

该团队选择从 Hive catalog 开始。这使他们可以使用现有 metadata infrastructure，并以最小干扰立即集成 Iceberg。随着 cloud migration 推进，他们计划重新评估 catalog choice，考虑 Nessie 或 Polaris 等选项，以获得更强 governance、multi-engine support 和 REST API interoperability。这种 phased approach 赋予他们灵活性，也展示了 catalog selection 可以随着组织 architecture 和 governance needs 演进而变化。

7.5.2 场景：快速扩展的 Cloud-Native Startup

一家快速增长的 fintech startup 正在基于 cloud-native stack 从零构建数据平台。公司全面采用 managed services，并优先考虑 speed、scalability 和 governance。他们广泛使用 AWS，依赖 Spark 和 Flink 做 processing，并计划使用 SageMaker 和 large language models 引入 AI workloads。

Requirements：

• Fully managed、cloud-native metadata solution
• 与 AWS services 无缝集成
• 支持 multi-engine read 和 write access
• Fine-grained access control 和 auditability
• REST compatibility，支持未来 interoperability

Evaluation

团队考虑 AWS Glue Data Catalog 和基于 Polaris 的 catalogs，例如 Dremio catalog。AWS Glue Data Catalog 与 AWS IAM、Lake Formation，以及 Athena、EMR、Redshift 等 services 深度集成。其 serverless model 和对 Apache Iceberg 的支持，使它非常适合希望 operational burden 最小化的 startup。

他们也探索 Polaris-based catalogs，因为它们遵循 Iceberg REST specification，并与 open standards 对齐。虽然 AWS Glue Data Catalog 通过 Lake Formation 提供强 fine-grained access control，并支持 multi-engine interoperability，但它绑定在 AWS 生态中。相比之下，Polaris 提供 cloud-agnostic、fully managed、REST-compliant catalog，对于需要跨多个 cloud providers 管理一致 metadata，或未来预计扩展到 AWS 之外的组织具有吸引力。

Outcome

团队选择 AWS Glue Data Catalog，因为它原生集成 AWS ecosystem、内置 Iceberg 支持，并且 fully managed、serverless operation。这使他们可以专注于交付 data products，而无需管理 catalog infrastructure。但他们也意识到 cloud portability 的重要性，并预计未来需要支持多个 cloud providers 的客户。因此，他们计划随着平台扩展和多样化，重新考察 Polaris 或其他 REST-compliant catalogs 等 cloud-agnostic options。

7.5.3 场景：具有严格 Data Governance 的跨国企业

一家 healthcare sector 的跨国企业受到严格 data residency、privacy 和 compliance regulations 约束。其 infrastructure 横跨多个 regions 和 cloud providers，一些 workloads 在 on premises，另一些在 cloud 中。它使用多种 engines，包括 Spark、Trino 和 Flink，并需要在所有 environments 中实现一致 metadata governance。

Requirements：

• Multiregion、geodistributed metadata management
• 强 access controls 和 auditing
• 支持 multiple engines 和 data types
• Open APIs 和 extensibility，用于 custom integrations
• Federated access to diverse metadata sources

Evaluation

组织评估 Apache Gravitino，它提供 geodistributed、federated metadata lake，支持 relational、file-based、messaging 和 AI assets 的 metadata。其 unified governance layer 和 REST catalog implementation，使它非常适合复杂 enterprise environments。组织也考虑 Lakekeeper 和 Nessie，但 Gravitino 广泛的 metadata model 和 connector ecosystem 让它更适合 federated governance。

Outcome

他们选择 Apache Gravitino，因为它具备 federated capabilities、unified access model 和 extensible governance framework。Gravitino 使他们能够跨 regions 整合 metadata 并执行一致 policies，同时通过 REST Catalog specification 支持 Iceberg tables。其对多种 metadata domains 的支持，包括 models 和 streams，有助于统一管理 data 和 AI assets。

7.5.4 场景：优先 Operational Simplicity 的 SaaS Startup

一家拥有小型数据团队的 SaaS startup 正在 AWS 上构建 greenfield analytics platform。他们希望使用 Apache Iceberg，因为它具备 performance 和 data management features，但他们管理 infrastructure 的资源有限。其 workloads 主要是使用 Spark 的 batch ingestion，以及通过 Athena 进行 SQL-based analytics。

Requirements：

• Fully managed catalog service
• 与 AWS-native tools 集成，例如 Athena、Redshift、Glue ETL
• Minimal setup 和 operational overhead
• 原生支持 Apache Iceberg
• Secure、scalable access control

Evaluation

他们将 AWS Glue Data Catalog 作为默认选择评估，因为它与 AWS ecosystem 深度集成，并且现在通过原生 Data Catalog 和 Glue ETL jobs 支持 Apache Iceberg。它简化 metadata management，支持 serverless ETL，并与 Athena 和 Redshift Spectrum 无缝集成。他们简单考虑了 Lakekeeper 和 JDBC catalog，但这些需要更多 infrastructure management。

Outcome

他们选择 AWS Glue Data Catalog，因为它具备 managed catalog 和 ETL capabilities，使团队可以专注构建 data products，而不是管理 metadata infrastructure。团队也看重 centralized governance、crawler-based schema discovery，以及通过 Athena 的无缝 query access。

7.5.5 场景：具有 Multicloud 和 Federated Governance 需求的大型企业

一家全球金融服务公司在多个 regions 和不同 regulatory jurisdictions 下运营。它正在采用基于 Apache Iceberg 的 lakehouse strategy，以现代化 analytics platform，同时确保严格 governance 和 compliance。其 workloads 横跨 Spark、Flink 和 Trino，并且需要一种 catalog solution，支持 distributed deployments、unified governance，以及多个 engines 跨 clouds 访问。

Requirements：

• 跨 regions 和 clouds 的 federated metadata management
• 支持多个 query engines 和 metadata types
• Centralized security 和 governance
• 通过 Iceberg REST support 实现 interoperability
• Open source 和 extensibility

Evaluation

他们评估 Apache Gravitino，因为它拥有 federated architecture，并支持 multiregional metadata management。Gravitino 的 REST-compatible catalog 和丰富 governance features，包括 access control、tags 和 unified interfaces，使他们可以统一管理 data 和 AI assets。对多种 connectors 的支持，例如 Hive、Hudi、Iceberg、Kafka 等，以及 query engines 的兼容性，与他们的 heterogeneous environment 对齐。他们也评估 Nessie 和 Polaris，但 Gravitino 的 federated metadata model 和 extensibility 更适合复杂 regulatory 和 organizational requirements。

Outcome

他们采用 Apache Gravitino，建立 federated metadata lake，用于支持跨全球团队的一致 governance 和 discovery。Gravitino 的 REST API 支持与所有 engines 集成，而它对 model 和 messaging metadata 的支持，也让他们为未来 AI initiatives 做好准备。

7.5.6 场景：金融公司需要每天克隆环境做 Stress Testing

一家金融机构每天运行 regulatory stress tests，模拟不利市场条件，并分析公司的韧性。为了确保准确性和隔离性，这些 simulations 必须在 production data 的精确 snapshot 上运行，同时不干扰 live operations。团队需要一种快速创建和管理 test environments 的方式，且不物理复制大型 datasets，因为复制既耗时又昂贵。

Requirements：

• 能够 clone 整个 production environment，且不复制数据
• Time-travel 和 versioning capabilities，用于 reproducibility
• Lightweight、branch-based metadata isolation
• 与现有 Spark-based pipeline 兼容
• 支持与 version-controlled data 的 continuous integration

Evaluation

他们考虑了多个 catalog options。AWS Glue Data Catalog 和 Polaris 支持 REST integration，但二者都没有 catalog-level branching 或 tagging semantics，无法满足他们 multitable zero-copy cloning 的需求。Apache Gravitino 和 Lakekeeper 提供 metadata federation 和 REST compatibility，但不聚焦 branching semantics。

Nessie 因其 Git-like branching 和 tagging capabilities 脱颖而出，使团队可以创建 isolated metadata views，而无需复制数据。使用 Nessie，他们可以在每个 test cycle 开始时从 production data 创建 branch，在 branch 上运行 simulations，并根据需要丢弃或 merge 结果。这支持精确、成本高效的 stress testing 和 experimentation。

Outcome

该公司采用 Nessie 管理 Iceberg catalog。他们自动创建 daily branches 用于 stress testing，并将 branch lifecycles 集成到 CI/CD workflows 中。这使他们能够维护一致 test environments、满足 auditability requirements，并在不影响 production data 的情况下迭代 testing procedures。

NOTE
这个场景强调了 data versioning 和 branch-based isolation 对于某些应用的重要性，在这些应用中 reproducibility、isolation 和 speed 至关重要。Nessie 为这些需求提供了优雅解决方案。

7.5.7 场景：分阶段 Iceberg 迁移，并跨 Legacy Systems 做 Query Federation

一家大型企业正在进行战略迁移，从 legacy data warehouses 和 Hadoop-based data lakes 混合环境，迁移到基于 Apache Iceberg 的 lakehouse。其 data ecosystem 包括 Hive、Teradata 和 Oracle systems，迁移计划分阶段进行，以最大限度减少业务中断。转型期间，公司必须通过让用户能够跨 legacy 和 Iceberg systems 查询数据，来维持 analytics continuity。

Requirements：

• 跨多个系统的 query federation，包括 Hive、Oracle 和 Iceberg
• 一个 central catalog，在转型期间简化 metadata governance
• 能够管理并暴露基于 Iceberg 构建的 data products
• 在迁移阶段为 data consumers 提供无缝访问
• Minimal operational overhead，并具备内置 governance features

Evaluation

他们考察了多个 catalog options。Hadoop 和 JDBC catalogs 不足，因为它们缺少 query federation 和 governance tooling。Polaris 和 Gravitino 提供强 REST compatibility，但需要额外 integration work 才能满足 query federation needs。AWS Glue Data Catalog 提供 ETL integration，但缺少跨 heterogeneous sources 的内置 federation。

由 Apache Polaris 驱动的 Dremio catalog 是一个实践上合适的选择。它支持与 Iceberg 的 REST-based interoperability，并与 Dremio query engine 紧密集成，而 Dremio 擅长跨不同 sources 做 federated queries。这让 analysts 可以创建跨 legacy systems 和 Iceberg tables 的 unified views，而且在迁移早期不需要移动或复制数据。

Outcome

该企业采用 Dremio catalog 作为 lakehouse migration 的基础。Dremio 允许他们增量 onboarding Iceberg tables，同时仍通过单一 SQL interface 为 analysts 提供对 legacy systems 的访问。借助 row-level security、data lineage 和 clustering key support 等内置 governance features，Dremio catalog 在整个转型期间确保 compliance 和 maintainability。

7.5.8 场景：使用 Hadoop Catalog 和 Python 的轻量级 Lakehouse Adoption

一家成长中的 startup 主要使用 PostgreSQL 和 SQLite 等 application-level databases。随着 datasets 开始超过这些系统的高效处理能力，尤其是在 analytics use cases 中，公司开始探索扩展 data infrastructure 的选择。团队讨论是否采用传统 cloud data warehouse，但担心 vendor lock-in、成本上升和僵硬 tooling。

Requirements：

• Low-friction、low-cost 进入 scalable analytics
• 完全控制 metadata 和 storage
• 能直接从 developer machines 运行
• 偏好 open standards，以及与工程文化一致的 tooling
• 强 Python support，因为大多数 data engineering 是 Python-based

Evaluation

他们探索 cloud data warehouses，但 pricing models 以及 storage 和 compute 分离透明度有限，不符合其目标。虽然 Polaris 和 Glue 等 enterprise-grade catalogs 功能丰富，但初期超出了团队需求。REST catalogs 也需要部署和配置更多 infrastructure。

随后，团队发现内置于 Apache Iceberg 的 Hadoop catalog 允许只使用 filesystem paths 直接访问 Iceberg tables。结合 PyIceberg，他们可以开始在 Amazon S3 中创建和管理 Iceberg tables，而无需 provision 额外 services。

他们可以在本地 laptops 上使用简单 Python scripts 运行 data transformations 和 metadata operations，并将结果直接以 Iceberg format 存储在 S3 中。这个 setup 以最小 operational complexity 提供了 scalable、open table format capabilities。

Outcome

该 startup 采用使用 Hadoop catalog 和 PyIceberg 的 lakehouse architecture，作为初始 catalog 和 access method。它将数据以 Iceberg format 存储在现有 cloud storage 中，并使用 Python-based tools 和 libraries 查询它。这一决策允许它增量扩展；未来需要时，也可以迁移到 REST-based 或 enterprise-grade catalog，而无需改变 table layout 或重写 pipelines。

7.6 Catalog-Based Access Control

随着 Iceberg lakehouses 向 multi-engine、multiteam 和 multicloud deployments 演进，access control 正越来越多地从 storage systems 和单个 query engines 迁移到 catalog 自身。这代表着对早期数据湖架构的根本改变，在早期架构中，permissions 必须在 object storage policies、engine-specific roles 和 user credentials 之间重复并同步。

在 catalog-centric model 中，catalog 成为判断谁可以看到和修改哪些 tables 的 primary authority，而 storage systems 则被视为 implementation details，而非 security boundaries。Users 和 engines 向 catalog 认证，catalog 在 namespaces、tables，以及 read、write 或 alter 等 operations 上执行 RBAC。这种方法通过将 policy definition 和 evaluation 集中到一个地方，而不是分散在 stack 多层中，从而简化 governance。

促成这一转变的关键能力是 credential vending。现代 catalogs 不再向 users 或 engines 授予对 object storage 的 long-lived access，而是在 query 或 job runtime 动态发放 short-lived、scoped credentials。这些 credentials 仅限于 authorized operation 所需的具体 data files，并会自动过期。因此，users 不需要直接访问底层 storage system，就能与 lakehouse tables 交互。Storage credentials 变成 ephemeral 且严格受限，降低 operational overhead 和 security risk。

这种模型也改善 portability 和 interoperability。由于 access control decisions 在 catalog layer 执行，多个 engines 可以消费相同 Iceberg tables，而不需要各自拥有 permission model 或 user management strategy。Engines 专注 query execution，而 catalog 则在所有 access paths 上一致执行 governance rules。

也就是说，catalog-based access control 仍在演进。目前，大多数 catalogs 聚焦于 namespace- 和 table-level permissions 等 coarse-grained controls。Fine-grained access control，例如 row-level 或 column-level security，在 Iceberg 生态中尚未标准化。Apache Iceberg 和 Apache Polaris 社区中的 active proposals 和 ongoing work，旨在未来定义 interoperable mechanisms，以便在 catalog level 表达和执行 FGAC policies。

在这些标准最终确定并被广泛采用前，最佳实践是尽可能将 access control 推入 catalog，同时承认一些必要例外。当使用不支持 credential vending 的 storage systems 或 catalogs 时，某些 access controls 可能仍需要在 storage layer 执行。同样，某些 fine-grained policies 可能暂时仍由 query engines 实现。应将这些视为过渡措施，而不是长期架构目标。

实践中，方向已经很清楚：catalog 正在成为 lakehouse security 的 control plane。集中 RBAC、动态发放 scoped credentials，并最小化 direct storage access，可以简化 governance、提升安全性，并为 Iceberg 生态中 interoperable fine-grained security 奠定基础。

小结

Catalog layer 是 Apache Iceberg lakehouse 的 metadata backbone，支持可靠 data discovery、governance 和 interoperability。

Hadoop 和 JDBC 等内置 catalogs 提供简单性，但在 scaling 或 integration 方面灵活性有限。

Polaris、Gravitino、Nessie 和 Lakekeeper 等开源 self-managed catalogs，为复杂 deployments 提供 customization 和 advanced features。

AWS Glue Data Catalog、Dremio catalog 和 Snowflake Open Catalog 等 vendor-managed catalogs 提供 turnkey infrastructure，并集成 security 和 enterprise support。

Apache Iceberg REST Catalog specification 支持 compute engines 和 catalogs 之间的标准化通信，改善 multi-engine compatibility。

Catalog selection 应与平台 operational model、compliance requirements、cloud strategy 和未来 growth plans 对齐。

对于计划 multicloud 或 hybrid deployments 的组织来说，cloud-agnostic catalogs 变得越来越重要。

Catalog technologies 和 integrations 正在快速演进，因此随着架构成熟，重新审视决策至关重要。