Iceberg Catalog层选型指南：Horizon、Polaris、Glue与Nessie对比

Iceberg 目录层解析：Snowflake Horizon、Open Catalog、Polaris、Glue 和 Nessie 对比

Apache Iceberg 精通系列第 3 部分

你已经承诺使用 Iceberg。你的数据将以 Parquet 格式存储在对象存储中。你的引擎可能是 Snowflake、Spark、Trino、Dremio，或者同时使用这四种。只剩下一个决定，而正是这个决定让大多数团队悄悄出错：

所有这些引擎指向哪个目录？

在第 2 部分中，我称目录层为有意的薄层，一个指针存储，其唯一真正的工作是原子比较并交换，这赋予了 Iceberg 其 ACID 保证。这仍然是事实。但薄不等于不重要。目录是每个引擎必须达成一致的唯一组件。如果做对了，你的一份数据可以从市场上的每个工具查询。如果做错了，你就用新装束重建了你采用 Iceberg 想要避免的供应商锁定。

这篇文章是截至 2026 年中期目录格局的工作工程师地图。而头条发现并不是大多数“目录比较”文章会告诉你的。这个领域不是分裂成十几个相互竞争的目录。它正在整合围绕一个单一开放 REST 标准，并在其上附加了一个治理层。三个信号说明了这一点，我们将逐一讨论：Polaris 毕业成为 Apache 顶级项目、Nessie 并入 Polaris、Snowflake 将其自己的双目录故事整合进 Horizon。

让我们构建这个地图。

每个目录真正负责什么

在比较之前，让我们对工作描述毫不留情。剥离营销，每个 Iceberg 目录正好拥有四个职责：

1. 保存当前元数据指针对于每个表，以及最新 metadata.json 的路径。
2. 保证原子交换当写入者提交新快照时，指针的交换，以便读者永远不会看到半写状态。
3. 仲裁乐观并发当两个写入者同时提交时——恰好一个获胜；另一个干净地重试。
4. 暴露协议引擎可以说的语言。

第四点就是世界分叉的地方。一个目录可以给引擎提供必须导入的专有客户端库（Hive Metastore 时代和早期 Glue）。或者它可以讲Iceberg REST 目录规范，一个普通 HTTP API，任何引擎，任何语言，都可以调用。

值得精确描述那个提交实际是什么样的，因为“原子比较并交换”隐藏了机制。当引擎提交时，它发送新元数据位置给目录连同关于预期状态的断言，实际上，“我相信当前快照是 X；用 Y 替换它。”目录仅在断言仍然成立时才应用更改。如果另一个写入者先溜进了一个提交，断言失败，目录拒绝提交，失败者必须重新读取新的当前状态并在其上重放其更改。没有锁，没有阻塞，只是一个快速、乐观的重试循环。这就是整个并发模型，下面的每个目录都实现了它的某个版本。

REST 规范是自 Iceberg 发布以来目录层发生的最重要的事情。这就是为什么你笔记本电脑上的 PyIceberg 脚本、Kubernetes 中的 Trino 集群和 Snowflake 的 SQL 引擎可以写入同一个表，而只需同意一个端点 URL 和一个认证令牌。本文中的每个严肃目录都讲 REST。有趣的差异在于每个目录在它周围包装了什么——而比较它们的最有用的轴是凭证发放，我们将反复回到这一点。

Snowflake 目录家族：一个血统，和一个情节转折

大多数读者在 Snowflake 这边迷失，因为有三个名字非常相似的产品。一旦解开它们并注意 Snowflake 现在引导你到哪里，这篇文章的其余部分就各就各位了。

Apache Polaris——开源基础

Snowflake 于 2024 年 6 月开源了 Polaris，并将其捐赠给 Apache 软件基金会。2026 年 2 月 18 日，Polaris 毕业成为顶级项目，ASF 的标志表明它已达到社区治理、供应商中立和生产成熟度的标准。到毕业时，它已经发布了六个版本，吸引了大约 100 名贡献者，并关闭了超过 2800 个拉取请求。

Polaris 是一个纯粹的、符合 REST 规范的 Iceberg 目录。你自行部署它；它是一个基于 Quarkus 的 JVM 服务；用 PostgreSQL、MySQL 或 CockroachDB 作为后端，并将任何 Iceberg 客户端指向它：Spark、Flink、Trino、Dremio、Doris、StarRocks，或一次性 PyIceberg 作业。

两个能力比草案级别的“这是一个开放目录”的总结更重要：

• 凭证发放。Polaris 在查询时向引擎发放短期、细粒度的存储凭证，范围精确到请求所需的数据。引擎从不持有你存储桶的长期密钥。这是一个真正的安全原语，而不是复选框，这正是 Glue 的 REST 端点，范围恰好限定在请求所需的数据上。引擎从不持有对你存储桶的常驻密钥。这是一个真正的安全原语，而非一个勾选框，这正是Glue的REST端点所做的不做的。
• 目录联邦自 1.1（Hive）和 1.2（Hive + Glue）以来逐步扩展。这使得增量采用成为可能，而无需大规模元数据迁移，并消除了旧的“Polaris 还不能联邦”的警告。

采用信号不容忽视：Fivetran 的托管数据湖服务使用 Polaris 作为其默认目录；Dremio 的 Cloud Open Catalog 是在其上原生构建的。当竞争的商业供应商都标准化在同一个开源基础上时，这个基础实际上已经赢了。

Snowflake Open Catalog——托管的 Polaris（现在处于软淘汰状态）

Snowflake Open Catalog 是 Apache Polaris 作为托管服务运行。Snowflake 托管它、修补它、扩展它，并给你一个 Iceberg REST 端点（https://<org>-<account>.snowflakecomputing.com/polaris/api/catalog）。不需要看护 PostgreSQL，不需要修补 JVM。

这里是大多数比较忽略的情节转折。 Snowflake 现在引导新客户远离 Open Catalog，转向Horizon Catalog。根据 Snowflake 自己的文档，新客户应使用 Horizon Catalog 来实现 Iceberg 和多引擎互操作性，并且从未创建过 Open Catalog 的账户无法注册第一个。现有的 Open Catalog 客户可以继续使用并创建更多，但新采用的入口正在关闭。

所以，如果你在 2026 年进行绿地设计，Open Catalog 不再是默认推荐；它是遗留的托管 Polaris路径。你会转而选择的中性、自运营的等效方案是Apache Polaris 本身，自托管。可移植性保证在双向都是诚实的：因为 Open Catalog是基于 Polaris，你可以搭建自己的 Polaris，迁移元数据，并重新指向引擎，两边代码相同。

Snowflake Horizon Catalog：Snowflake 押注的对象

这曾经很容易被轻视为只是治理。这种说法现在错了。Horizon Catalog 已经吸收了目录角色：你可以使用 CATALOG = 'SNOWFLAKE' 创建 Snowflake 托管的 Iceberg 表，将文件存储在你自己的外部卷中，Horizon 通过其自己的 Iceberg REST 端点提供这些表，以便外部引擎（Spark、Oracle Autonomous Database、PyIceberg）动态解析当前快照并直接从云存储读取，无需硬编码的 metadata.json 路径。

除了目录功能，Horizon 仍然是 Snowflake 账户内所有内容的完整治理和发现层：RBAC、基于属性的访问控制、分类、血缘、动态掩码、行访问策略、对象标记，以及为 AI 代理提供治理的意义地图的语义层。

2026 年最清晰地区分三者的方式：

• Polaris（及其托管形式，Open Catalog）= 你在外部运行的开放、中立的目录，适用于许多引擎写入的表。
• Horizon Catalog = Snowflake 的内置目录以及治理层，推荐给新客户，现在也向外提供 Iceberg REST。

对于任何进行连接的人，一个精确的注意点：路径/polaris/api/catalog 对于 Open Catalog 和 Horizon 是相同的。区别在于账户标识符前缀。Open Catalog 使用其自己的独立账户；Horizon 使用你的主 Snowflake 账户标识符。不要将引擎指向你的 Open Catalog 账户期望访问你的 Horizon 原生表；它们是不同的账户，不是不同的路径，并且使用程序化访问令牌交换短期 OAuth 进行身份验证。不要将外部引擎指向 /polaris/api/catalog 期望访问你的 Horizon 原生表；它们不是同一个表面。

战略性的部分是向外联合。目录链接的数据库让 Horizon 从外部 Polaris、Open Catalog 或 Glue 目录同步元数据，然后在上面叠加 Snowflake 的治理。表保持开放；访问规则、标签和血缘随它们一起移动。AWS 现在也向另一个方向联合——Glue 可以通过 Horizon 的 REST 端点在 Lake Formation 控制下读取 Horizon 托管的 Iceberg 表。

AWS Glue Data Catalog——云原生的选择

Glue 比 Iceberg REST 规范早出现多年，但 AWS 已将其改造为你可以选择的最实用的目录之一，如果你的工作负载已经在 AWS 上。

现代 Glue Iceberg 的故事有三个组成部分：

• Glue Iceberg REST 端点 一个 SigV4 签名的端点（通常为 https://glue.<region>.amazonaws.com/iceberg；请根据当前 AWS 文档确认确切主机）实现 Iceberg REST 目录 OpenAPI。任何兼容的引擎——Spark、Trino、StarRocks、PyIceberg——都可以使用 IAM 角色连接并讲标准 REST。
• S3 Tables 集成： S3 Tables 是 AWS 的 Iceberg 原生存储层，有自己的 REST 端点，但 AWS 引导你通过 Glue 路由超越单桶原型，因为 Glue 是治理所在。
• 目录联合（2025 年 11 月 GA）： Glue 可以与远程 Iceberg REST 目录联合，包括 Snowflake Horizon、Open Catalog、Polaris 以及任何符合规范的目录。远程表在 Glue 和 Lake Formation 中表现为本地表，Lake Formation 向底层 S3 数据提供作用域凭据，而无需复制数据。

治理模型是 Snowflake 的镜像：Horizon 包裹 Snowflake 自己的引擎，而 Glue 依赖AWS Lake Formation进行细粒度访问控制、列掩码和行过滤器。当你的身份边界、审计和分析服务 Athena、EMR、Redshift 已经终止在 AWS 时，这是正确的赌注。

现在，大多数“Glue 很好”的说法忽略的部分是具体的 REST 缺口，当你将 Glue 视为真正的多引擎目录而不是 AWS 内部目录时，你会立即遇到这些缺口：

• UpdateTable 对 Iceberg 表通过 REST API不支持。
• Iceberg v3 表无法创建通过 CreateTable API（仅支持 v1 和 v2）。
• REST 端点不提供凭据；每个引擎仍然需要自己的 IAM 凭据，这与 Polaris/Horizon 模型相反。
• 每个 Glue 目录是区域性的；跨区域访问需要额外配置或复制。

所有这些在 AWS 内部都不是致命问题。但当非 AWS 引擎或 v3 工作负载进入时，它们都会成为摩擦。这就是 Glue 权衡的真正形态：极好的引力井，坚硬的墙壁。

Project Nessie：数据湖的 Git（以及它的发展方向）

Nessie 是概念上的异类。其他每个目录回答“最新的元数据文件是什么？”，而 Nessie 回答“这个分支上最新的元数据文件是什么？”

它将 Git 的分支和合并模型应用于目录层。每次写入都是提交。分支是提交的命名引用。标签是不可变指针。你从 main 切出一个暂存分支，在那里运行 ETL，验证，然后原子地合并整个分支跨多个表一次。如果结果错误，你丢弃分支，main 从未移动。

两个属性使其真正强大：

• 多表原子性。单个 Nessie 提交可以同时触及多个 Iceberg 表。这在 Hive Metastore 或第一代 Glue 中很难甚至实际上不可能实现。
• 真正的写入-审计-发布。分析师和数据科学家在隔离的 experiment_x 分支上工作，绝不会危及生产读取。CI/CD 流水线像暂存代码一样暂存数据变更。

Nessie 曾经需要自己的原生客户端协议，这阻碍了采用。后来它增加了完整的 Iceberg REST 支持端点（http://<nessie-host>:19120/iceberg 和 /api/v2），现代 Iceberg 客户端无需专用驱动程序即可工作。在引擎盖下，Nessie 将其提交日志持久化到可插拔后端：PostgreSQL、RocksDB、Cassandra、DynamoDB、MongoDB 或用于本地开发的内存。

对常规叙述的两处更正，两者都很重要：

1. Nessie 不是“Dremio Sonar 背后的目录”。 Sonar 是 Dremio 的 查询引擎。由 Nessie 驱动的 目录 产品是 Dremio Arctic（现在是 Dremio Enterprise Data Catalog 的一部分）。Sonar 像 Spark 和 Flink 一样 消费 Nessie/Arctic 目录；它本身不是目录。
2. Nessie 正在走向与 Polaris 合并并退役的道路。 Dremio 已公开承诺将 Nessie 的目录级版本控制、多表事务和 Git-for-data 语义合并到 Apache Polaris，并在读写对等实现后退役独立 Nessie。用 Dremio 自己的话说：“我们将把 Polaris 视为我们的目录，并将 Nessie 合并到 Polaris 中。”

因此，诚实的 2026 年建议是微妙的：如果你的痛点确实是 数据 CI/CD 实验、回滚、多表事务、ML 可复现性——Nessie 的模型仍然是 今天 的最佳匹配，并且值得其运营成本。但要以开放心态进行架构：你正在购买的分支功能正在迁移到 Polaris，而 Polaris 是长期开源中心所在。2026 年选择 Nessie 越来越像是在采用 带分支功能的 Polaris 早期版本，而不是押注于一个永久独立的产品。

荣誉提名

还有三个你应该认识，但这里不值得深入探讨：

• Hive Metastore。 在大型企业中仍然无处不在。它可以与 Iceberg 配合使用，但它从未为 REST 提交模型而构建，并且在规模扩大时成为瓶颈。2026 年从头开始，选择其他方案；迁移离开时，Polaris 和 Nessie 都有文档化的导入路径。
• JDBC Catalog。 Iceberg 内置的基于任何 JDBC 数据库的目录。适用于本地开发和演示；避免在生产环境中使用；没有真正的多租户、治理或联邦。
• Unity Catalog。 Databricks 的开源目录，现在支持 Iceberg，外部 REST 读取已 GA，写入处于预览阶段。战略上很重要——它联邦到 Glue、Hive Metastore 和 Horizon——但它值得单独一篇文章而不是一个脚注。

直接对比：实际差异

这是我十八个月前希望有人给我的表格。Medium 不会干净地渲染原始 Markdown 表格，所以这是一个符合品牌的信息图；先读状态行：

有三个值得大声说出的脚注：

1. “Horizon 中的多表事务” 意味着 在 Snowflake 引擎内 跨 Snowflake 管理的 Iceberg 和原生表的 SQL 事务语义。在 Nessie 中，多表原子性是目录本身的属性，因此跨引擎成立。
2. 凭据提供是对安全审查最重要的行。 Polaris 和 Horizon 提供有范围、短期的存储令牌；Glue 不提供。如果“任何引擎都不应持有长期存储桶密钥”是一个要求，那么这一行就决定了候选名单。
3. 状态列是故事。 这五个中的两个（Open Catalog、Nessie）明确是过渡性的。规划时要围绕它们的方向，而不仅仅是当前状态。

一个真正有效的决策框架

功能表格永远不会告诉你选择哪个。这是我在实际审查中使用的决策树。它从一个问题开始：

你的治理边界在哪里？

• 在 Snowflake 内部，用户登录 Snowsight，策略是 RBAC 角色，血缘由 Snowflake 跟踪 → Horizon Catalog 是默认（也是 Snowflake 现在积极推荐的）。对于外部引擎也必须 写入 的 Iceberg 表，通过目录链接的数据库将它们联邦进来。
• 在 AWS 内部，IAM 是你的身份源，Lake Formation 是你的权限模型，Athena 和 EMR 是你的引擎 → Glue 是默认。添加目录联邦以访问在其他地方管理的表——但验证你的引擎是否能容忍 Glue 的 REST 缺口（无 UpdateTable、无 v3 创建、无凭据提供）。
• 我们与引擎无关，且希望零供应商参与：一个平台团队构建中立的湖仓，多个业务单位通过不同工具访问 → Apache Polaris，自托管。自己运行，用 PostgreSQL 支持，依靠凭据提供和 1.4 联邦，将目录视为基础设施。（这是 Open Catalog 过去为新客户提供的角色；Polaris 现在是更干净的答案。）
• “我们需要数据 CI/CD 分支、隔离、可复现性、安全回滚” 在受监管和 ML 密集型团队中越来越不可协商 → Nessie 今天，并明确理解你是在合并前采用带分支功能的 Polaris。

在决策树之上有两条规则：

1. 目录选择是可逆的，但痛苦地可逆。 REST 规范意味着你可以迁移元数据并让数据文件留在原地。真正的工作是迁移 治理模型——策略、标签、血缘、掩码，以及在 Snowflake 的两个目录之间，甚至 权限词汇有所不同（Horizon 使用 SELECT/INSERT；Open Catalog 使用 TABLE_READ_DATA/TABLE_WRITE_DATA）。根据治理契合度选择，而不是根据功能表逐点计数。
2. 多目录现在很平常。最成熟的2026年环境运行Horizon和Glue以及一个Polaris实例，共同联邦。不要让自己架构进单一目录的角落。从第一天起就为联邦而设计。

真实世界模式：联邦多目录

让我以我在大型企业中越来越多看到的架构作为结尾，我认为这将成为2026年的默认架构。

想象一家零售商，拥有三个环境：用于客户分析和BI的Snowflake，用于运营数据工程的AWS（含EMR和Athena），以及用于ML训练的Databricks（含Spark）。三年前，每个环境运行自己的格式，并在它们之间不断复制数据。他们的“单一事实来源”是一个Slack频道，三个团队在那里争论哪个数字是正确的。

以下是Iceberg原生的2026版本：

• 原始数据以Iceberg表形式落入S3，由Spark写入，录入AWS Glue（接受其REST差距，因为这是全AWS摄取路径）。
• 一个子集通过目录链接数据库暴露给Snowflake，同步元数据到Horizon，并在其上应用Snowflake RBAC、掩码和沿袭。
• ML团队在Glue旁边的Nessie实例中把表检出到实验分支，使用Nessie的REST接口，以便Spark和Dremio都能访问。
• 对于少数必须可被每个引擎——Snowflake、Spark和自定义Python摄取作业——写入的表，团队运行自托管的Apache Polaris作为共享的、颁发凭据的写入路径。

不是一个供应商。不是一个目录。每个数据集一个Iceberg表，在需要的地方都可见，使用限域凭据而不是长期密钥。这就是Iceberg真正兑现的承诺——而目录层是你兑现支票的方式。

关键要点

1. 目录的工作很小，但你选择的产品塑造了你整个治理模型。每个人都处理原子指针交换。区别在于他们围绕它包装了什么——而最锐利的单一差异化因素是凭据颁发。
2. Iceberg REST规范是低调的英雄。这就是为什么你今天能以三年前不可能的方式混合引擎和目录。现在每个严肃的目录都说这种语言。
3. 这个领域正在整合，而不是碎片化。Polaris是ASF标准；Nessie正在合并进Polaris；Snowflake正在把Open Catalog折叠进Horizon。押注标准，而不是碎片。
4. Horizon，而不是Open Catalog，是Snowflake推荐用于新构建的目录。如果你最后的心理模型是“Open Catalog用于互操作，Horizon用于治理”，更新它：Horizon现在两者都做，新的Open Catalog注册已关闭。
5. 根据你的治理边界在哪里选择，而不是根据功能分数。错误的契合度会花费你策略迁移和身份管道，即使不同目录的权限词汇不同，而不是缺少功能。
6. 联邦是发展方向。多目录很平常。从第一天起就为它设计，避免单一目录的角落。

下一步

在第4部分“动手实践：搭建Apache Polaris并从Spark、Trino和Snowflake查询一个Iceberg表”中，我们从理论走向键盘。我将带你完成端到端的凭据颁发目录设置，在外部存储上注册一个Iceberg表，并从三个引擎并发读写它，包括真实世界的坑：凭据颁发与外部卷、Lake Formation冲突、/polaris/api/catalog-vs-Horizon-endpoint陷阱，以及第一次花了我两个小时的一个认证边界情况。

如果你正在构建多引擎湖仓，设置篇文章是这个系列开始在实际操作中回报你的地方。

这是Apache Iceberg掌握系列的第3部分。在 Medium 和 LinkedIn 上关注我，以获取每一篇文章。

你在生产中运行哪个目录，它让你吃惊的是什么？留下评论——我每一条都读。

本系列之前的内容：

• 第1部分：为什么Apache Iceberg不仅仅是“另一种表格式”
• 第2部分：Apache Iceberg架构深度解析：支撑你湖仓的三层结构

Iceberg目录层详解：Snowflake Horizon、Open Catalog、Polaris、Glue和Nessie……最初发表于Snowflake Builders Blog: Data Engineers, App Developers, AI, & Data Science在Medium上，人们在那里通过高亮和回应继续讨论这个故事。