1. What is a Catalog

Catalog，中文翻译“数据目录”，从字面意思上可以看出，它就像一个可搜索的数据集目录，类似于图书馆目录对书籍的整理方式。广义上讲，数据目录是组织内数据资产的清单。它能帮助用户发现、理解和管理可供使用的数据。数据目录通常包含元数据（关于数据的信息），如数据源、描述、所有者、质量指标、血缘关系和访问控制。

具体而言，数据目录是对组织内部的数据资产进行整理和归纳的工具。它通过包含丰富的元数据，为用户提供了解数据的途径，使得用户可以快速发现所需的数据，并清楚地知道数据的来源、所有者等信息。同时，数据目录也有助于对数据进行管理，比如通过设置访问控制来确保数据的安全性。类似于图书馆目录将书籍进行分类整理以便读者查找，数据目录对数据集进行整理，方便用户在大量数据中快速定位到所需的数据资源。

Catalog 通常应用于以下场景：

数据探索与发现。只要企业存在数据，无论规模大小，都会存在数据发现问题。而数据目录在跟踪和呈现可用数据资产方面起着关键作用。在这个场景中，Catalog 起到存储、搜索和发现的作用。最基本的形式下，Catalog 可能只是存储表名、模式以及数据位置等信息，并且提供索引服务方面对信息进行查找。更高级的功能包括主动的数据集发现和收集，比如通过爬虫自动收集和归纳数据信息。
访问控制。数据在提供价值的同时，也可能带来潜在风险，需要进行安全管理。良好的访问控制需要在严格控制和为被授权用户提供流畅访问体验之间取得平衡。访问控制主要涉及三个方面：1. 认证，包括如何验证用户身份以及管理凭证和密钥。2. 授权，明确谁有权访问哪些数据，例如可以通过基于角色的访问控制（RBAC）为不同身份分配特定的访问权限。3. 查询引擎访问控制，主要关注存储中的原始数据的访问是否由数据目录进行安全控制。查询引擎在访问数据时，是否必须通过数据目录获取访问权限，还是可以绕过数据目录直接从存储中获取数据。
数据合规。企业面临着满足各种合规认证（如 SOC II、PCI/DSS、HITRUST、FedRAMP 等）的挑战，其中一个关键组成要素是维护一个数据清单，根据敏感性和监管要求（如个人、机密或公共类别）对数据进行分类。合规性相关的功能包括：1. 数据分类，为数据设置合适的分类，以确保根据合规政策安全地处理数据。2. 保留策略，能否设置数据的自动过期、删除或防止删除，以满足合规标准。3. 审计，是否记录所有活动以用于监管审计。
数据血缘。数据血缘（Data Lineage）提供了数据在企业中流动的详细路径，包括跟踪其起源、转换方式和目的地，在异常数据识别、跟踪数据依赖关系、明确数据的所有权和责任归属方面起到重要作用。
数据质量管理。数据质量管理确保数据准确、可靠。数据质量管理通常涉及以下方面：1. Schema 管理，数据开发人员对数据集进行 Schema 定义，如数据类型、约束等，以确保数据的一致性和正确性。2. 数据质量策略，定义数据准确性、完整性和有效性的标准和规则，确保与企业监管要求保持一致。3. 数据新鲜度，确保数据集是最新的，反映最当前的信息。

2. Categories of Catalogs

Kyler Weller 在文中将 Catalog 分为三类。

类型	解释
Metastore	下文会对 Metastore 的 Catalog 的关系做更多介绍。简单来说，Metastore 主要专注于存储有关数据表、Schema、分区和统计信息的元数据，并主要针对结构化数据。Metastore 更多地是配合查询引擎，在查询执行时提供相关元数据信息。但更多高级功能如数据管理、数据发现等通常并不涉及。
Catalog	Kyler Weller 在文中将这一类别命名为“Business Catalog”。但其实本意并不专指“商业”元数据服务，而是指代一种以用户为中心，提供更多包括元数据和数据资产相关的信息的服务。比如数据发现、数据质量、数据血缘管理。
Catalog of Catalogs	这一类是指为多种 Catalog 提供统一视图和管理模式的服务。通常它们会将其他 Catalog 的信息汇聚到一个地方进行管理和操作，如 Datahub；或者作为“代理”以统一的视图查看所有其他被代理的 Catalog，如 Gravitino。

当然，大多数 Catalog 的功能边界并不是按照这些类别严格区分的。所以下图只是做大致划分，以帮助读者对 Catalog 的分类有初步的印象。

如果相对这些类别有更深入地了解，可以观看由Shirshanka（来自 Acryl）和 Vinoth（来自 Onehouse）对话：

Taming the Chaos: A Deep Dive into Table Formats and Catalogshttps://www.youtube.com/watch?v=yPqSR18BzO4

Catalog vs Metastore

上文说过，Metastore 是一种更为狭义的元数据服务定义，用于定义和组织数据的基本特征，包括模式、表和数据库定义，以及其他构造如统计信息。这些信息可以使访问数据（如分区）更快。当查询引擎访问或分析存储在数据湖中的数据时，它们通常通过元数据存储库进行通信。

当我们提到 Metastore，必然会联想到 Hive Metastore。诚然，Hive 的查询引擎和存储格式正在被其他新的系统所取代，正逐渐成为历史的产物。但 Hive Metastore 在现代数据栈中依然活跃，甚至可以被视为当前元数据存储服务的标准之一。很多 Catalog 在提供元数据访问服务时都会提供兼容 Hive Metastore 的接口，如 AWS Glue，Databricks（现在正逐步迁移到 Unity Catalog）等。

如果读者对 Hive Metastore 的发展、讨论、演化感兴趣，Kyler 在文中给出了很多不错的文章供参考：

Useful queries for the Hive metastorehttps://analyticsanvil.wordpress.com/2016/08/21/useful-queries-for-the-hive-metastore/
Hive Metastore – It Didn’t Age Wellhttps://lakefs.io/blog/hive-metastore-it-didnt-age-well/
Fresher Data Lake on AWS S3https://newsroom.aboutrobinhood.com/fresher-data-lake-on-aws-s3/
How Amazon Transportation Service enabled near-real-time event analytics at petabyte scale using AWS Glue with Apache Hudihttps://aws.amazon.com/cn/blogs/big-data/how-amazon-transportation-service-enabled-near-real-time-event-analytics-at-petabyte-scale-using-aws-glue-with-apache-hudi/
Building and scaling Notion’s data lakehttps://www.notion.com/blog/building-and-scaling-notions-data-lake

Relationship of Iceberg, Hudi, Delta and Catalogs

本文从数据湖的角度出发来谈论 Catalog，所以有必要了解目前主流数据湖格式和 Catalog 之间的关系。

Delta Lake 和 Apache Hudi 在最初的设计中，并没有对 Catalog 严格依赖。Delta Lake 是在实现多表事务[1] 支持时开始依赖 Catalog。Hudi 使用了不同的方式[2] 尽可能的避免对 Catalog 的严格依赖。

Iceberg 在设计之初就因为事务安全性而对 Catalog 有很强的依赖。所以 Iceberg 与包括 Hive Metastore、JDBC、Nessie 等 Catalog 都有很好的集成。2022 年 7 月发布 Apache Iceberg 0.14.0 版本时，引入了 Iceberg REST Catalog API [3]。REST Catalog API 引入了一个很好的抽象，允许使用同一套客户端代码与任何实现了 Rest Catalog API 的服务后端进行通信。这种做法方便了 Iceberg 的上下游生态系统进行各自的实现，并保持与 Iceberg 的兼容性。需要注意的是，Iceberg 社区仅提供了 REST Catalog API 定义，但并未给出具体实现。所以目前包括 Glue、Gravitino、Unity、Polaris 等众多 Catalog 正在进行一场小型竞赛，以在 REST Catalog API 规范之上成为行业最佳的 Iceberg Catalog 实现。

关于湖格式和 Catalotg 的演进与讨论，Kyler 也给出了很多有意思的参考文章：

[Protocol Change Request] Delta Coordinated Commits [1]https://github.com/delta-io/delta/issues/2598
HUDI RFC-73: Multi-Table Transactions [2]https://github.com/codope/hudi/blob/rfc-multi-tbl-txn/rfc/rfc-73/rfc-73.md
Iceberg rest-catalog-open-api.yaml [3]https://github.com/apache/iceberg/blob/main/open-api/rest-catalog-open-api.yaml
The Evolution of Apache Iceberg Catalogshttps://www.dremio.com/blog/the-evolution-of-apache-iceberg-catalogs/#the-purpose-of-iceberg-catalogs
A Brief History of REST Catalogs for Apache Iceberghttps://medium.com/m/global-identity-2?redirectUrl=https%3A%2F%2Fblog.det.life%2Fa-brief-history-of-rest-catalogs-for-apache-iceberg-39823ea13198
The Life of a Write Query for Apache Iceberg Tableshttps://www.dremio.com/blog/the-life-of-a-write-query-for-apache-iceberg-tables/
Understanding Apache Iceberg’s Consistency Model Part 2https://jack-vanlightly.com/analyses/2024/8/5/apache-icebergs-consistency-model-part-2
What Apache Iceberg REST Catalog is and isn'thttps://dev.to/alexmercedcoder/what-apache-iceberg-rest-catalog-is-and-isnt-3143

3. How to choose a catalog?

当我们选择一款产品时，首先应当提出的问题是，“我的需求是什么？”，从需求角度出发选择产品。而不是根据产品的特性列表来反向匹配自己的需求。

Kyler 从 6 个维度出发，帮助读者如何选择合适的 Catalog。必须强调的是，

1. 功能是否满足需求和中期目标

如果最低需求都不满足，产品再酷或再便宜也不用考虑。“锦上添花”的功能需要评估其相对成本、复杂性等因素的投资回报率。

2. 社区

活跃的社区意味着能得到更多的支持和更快的需求响应。即使不是开源项目也可能建立强大的社区。

3. 开源

开源项目不仅意味着你可以参与其中，还有机会与其他开发者交流讨论。这里有必要说明下“开源项目”和“开源定义”。比如 Apache Polaris 和 Snowflake Open Data Catalog 都基于开源定义（Iceberg REST Catalog API），但前者是开源项目，而后者是闭源项目。Unity Catalog 目前比较特殊，其商业版本和开源项目虽然使用相同的名称，但其具体实现并不相同。

4. 生态系统

Catalog 需要覆盖大量的数据源、数据类型，并支持丰富的连接器。缺少对数据源的支持通常是一个致命问题。

5. 成本

Catalog 的成本因场景而异，要关注不同供应商的定价模型，同时记住开源并不等于免费，还需要部署和维护基础设施。

6. 时间复杂性

包括上线、部署 Catalog 所需的工作量大小，以及维护和使用 Catalog 的工作量。

4. Catalog Comparison

目前市面上有近 50 种 Catalog 产品，由于时间原因，Kyler 在文中对 7 款 Catalog 产品进行了全面的比较，包括：

- Unity Catalog OSS - (v0.2.0)

- Unity Catalog Databricks Product (DBR 16.0)

- Apache Polaris(Incubating) - (v0.9.0-rc1)

- DataHub (v0.14.1)

- AWS Glue (v4.0)

- Apache Gravitino(Incubating) (v0.7.0)

- Atlan (v4.7.49)

比较的方面包括：

- 数据发现（Data Discovery and Exploration）

- 支持的连接器和数据类型（Data Connectors and Objects Covered）

- 数据治理：权限控制（Data Governance: Access Control）

- 数据治理：合规管理（Data Governance: Compliance）

- 数据血缘管理（Data Lineage and Documentation）

- 数据质量管理（Data Quality Management）

每一类比较都采用了 A-F 的评分机制进行评分，A 表示最佳解决方案，B 表示很好的解决方案，C 表示勉强存在，D 表示不完整的解决方案，F 表示缺少该功能。并在最后给出了各个产品的综合评分。当然，Kyler 在文中表示，这个评分只是根据个人理解做出的判断，并不代表最科学的评判标准，也欢迎大家与之交流。

虽然 Kyler 在文章中对每个类别给出了详细的对比、评分和结果。但由于篇幅以及客观性等原因，这里译者只给出各比较类目的关注点以及一些个人观点，感兴趣的读者可以阅读原文了解更详细的评比内容。

4.1. 数据发现（Data Discovery and Exploration）

关注点	解释
数据发现方式	主要关注的是将所有数据注册到 Catalog 的容易程度。比如一些 Catalog（如 Unity 和 Polaris）需要用户手动注册表格并定义详细的模式，而另一些（如 Glue、Datahub 和 Atlan）则提供自动抓取工具，可以自动遍历数据并将其注册到目录中。这对于数据发现和管理非常重要，因为它决定了数据在目录中的可见性和可访问性。如果抓取功能易于使用，用户可以更轻松地将所有数据纳入目录，从而更好地进行数据发现、探索和治理。
元信息的详细程度	指的是从 Catalog 中能了解到多少关于数据的信息。例如，在某些 Catalog 中，数据详情可能包括数据表的 Schema，以及基本元数据，如创建时间等。在一些更完善的 Catalog 中，数据详情可能会有更丰富的元数据、统计信息、文档、标签、业务上下文等内容，让用户能够更深入地了解数据集。它反映了用户从数据目录中获取有关数据信息的丰富程度。Atlan 和 Datahub 在提供数据集的详细信息方面有很好的体验，包括丰富的元数据、统计信息、文档、标签和业务上下文等。而其他一些 Catalog 可能只显示表 Schema 等基本的元数据。
检索便利性	指的是在数据目录中查找所需数据的容易程度。具体来说，它关注的是用户在数据目录中寻找特定数据时的便捷性。例如，一些数据目录可能提供高级搜索功能，允许用户使用复杂的过滤器进行搜索，同时还能解释 Schema、统计信息等，以便更好地理解搜索结果并找到所需的数据。

这一节更多的是关注 Catalog 对元数据的智能化管理程度。一些成熟的产品无疑具有非常大的优势，如下面是 Atlen 的元数据检索能力：

4.2. 支持的连接器和数据类型（Data Connectors and Objects Covered）

关注点	解释
开放表格式的支持	关注对 Iceberg、Hudi、Dela Lake、Paimon 等开放表格式的支持程度。
文件格式的支持	关注对文件类型如 Parquet、ORC、JSON，以及半结构化和非结构化数据的支持程度。
数据源连接器	有哪些计算引擎或数据处理引擎可以访问 Catalog。

这一节主要关注的是 Catalog 的生态繁荣度。大部分系统都支持包括 Iceberg、Hudi、Dela Lake 在内的主流开放表格式。在文件格式方面，只有 Unity 和 Gravitino 关注到了非结构化数据的支持，并且 Parquet 似乎是唯一的开放文件格式共识，其他文件格式都在不同程度上被忽略。在连接器方面，商业项目的连接器丰富度要远高于新兴的开源项目，但不可忽视的是，同样是新兴的开源项目如 Apache Doris 会优先支持开源的 Catalog。

4.3. 数据治理：权限控制（Data Governance: Access Control）

关注点	解释
授权方式	在数据治理的上下文中，这涉及到授予数据访问权限的方式。例如，不仅仅是简单地给予或拒绝对某个表的访问，还包括给予只读权限、允许写入但不能更改模式等更细粒度的权限控制。通过基于角色的访问控制（RBAC）等方式，用户可以为不同的 “身份” 分配特定的 “角色”，以描述允许的访问粒度。
认证方式	一些 Catalog 通过与第三方身份提供商（如 Google Auth、Okta 等）集成进行身份认证，使用由身份提供商提供的令牌进行授权。不同的 Catalog 在身份认证和授权的方式上可能有所不同，有的可能使用客户端 ID 和密钥结合 OAuth2 获取访问令牌等方式。
数据湖的访问控制	主要关注 Catalog 是否能够对存储在数据湖中的根数据进行访问控制。例如，在某些 Catalog 中，只有特定的查询引擎在经过目录授权后才能访问数据湖中的数据，以确保数据的安全性和合规性。
计算引擎的访问控制	指的是在对根数据的访问进行强制管理的情况下，哪些查询引擎可以与 Catalog 协同工作，即能够在 Catalog 的授权下访问数据。例如，Unity Catalog 当前文档中仅列出了 5 个兼容的查询引擎（Spark、Daft、DuckDB、PuppyGraph、SpiceAI），而 Polaris 由于扩展了 Iceberg Rest Catalog APIs，对于已经与 Iceberg 兼容的查询引擎都可以支持。

这一节 Kyler 提出了一个非常有意思的观点：“过去几十年供应商的策略是将用户数据存储锁定在其平台上，让用户依赖其计算服务。而开放表格式（Hudi、Delta、Iceberg）催生了湖仓一体架构，挑战了这种策略，使数据存储更加开放和可互操作。作者认为供应商现在将把带有目录的访问控制作为新的锁定点，以保持用户对其平台的粘性，这也是 Tabular 被 Databricks 大量收购的原因之一”。这里我们谈论“权限控制”时，实际上分为两个部分：对元数据的访问控制和对数据的访问控制。一些 Catalog 仅提供对元数据的访问控制，比如可以访问哪些表、哪些列，而另一些 Catalog 则更近一步，可以对控制对数据存储目录的访问权限。

4.4. 数据治理：合规管理（Data Governance: Compliance）

关注点	解释
标注和分类	数据治理中，分类通常是根据数据的敏感性、类型等进行组织，以确保敏感数据资产有适当的安全措施。常见的分类类别包括公共、内部、机密和高度敏感数据，每种分类都需要特定的访问控制和合规协议。DataHub 有自动分类功能，Databricks Unity Catalog（商业版本）有主动警报功能，可以检测并自动为数据添加分类。如果一个 Catalog 具有分类功能，用户可以更方便地管理和保护数据，根据不同的分类制定不同的访问策略和保留政策等。
数据保留策略	数据保留策略是管理数据的关键部分，通常用于满足合规性和监管要求。它涉及根据数据的敏感性确定数据需要保留的时间，例如某些数据可能需要保留三年然后删除，而有些数据可能在 30 天后就需要删除。
审计	审计是在数据出现问题、违反策略或进行常规合规检查时非常重要的环节。存储对数据和元数据采取的所有操作的完整历史记录很关键。Atlan 在这方面提供了良好的体验，除了原始审计日志外，还有丰富的用户界面。

似乎大部分 Catalog 在都没有很好的支持“数据保留策略”，目前还没有找到具有完善的数据保留策略功能的目录产品。但这是一个可能对某些项目很有价值的功能点，可以添加到未来的发展路线图中。

4.5. 数据血缘管理（Data Lineage and Documentation）

关注点	解释
数据血缘	是否能够清晰地追踪数据的来源、数据在系统中的流动路径以及随着时间的推移数据是如何被转换的过程。它可以帮助组织进行错误排查、保持合规性并确保数据质量，通过识别瓶颈或不准确之处来实现。例如，当出现数据质量问题时，可以通过数据沿袭快速找到问题的源头，了解数据从哪里来、经过了哪些处理步骤。在数据管理中，良好的数据沿袭可以提高数据的可追溯性和透明度。
数据所有权管理	指的是数据的所有权是否清晰，以及如何维持这种责任。具体来说，就是要确定谁拥有特定的数据，并且在出现问题时能够明确责任方。例如，当数据出现错误或质量问题时，能够快速找到数据的所有者，以便进行问题的排查和解决。同时，通过明确数据所有权，可以更好地管理和保护数据，确保数据的安全和合规使用。在数据管理中，通常会通过分配所有者角色、记录数据的使用情况等方式来维持数据所有权的责任。
	在数据治理的场景中，不同团队可能对诸如活跃用户、客户流失率或用户参与度等业务指标有不同的定义。如果 Catalog 能够明确度量指标的定义，并对其进行追踪和监测，可以避免在创建或维护数据管道时出现错误。此外，明确度量指标的定义及其依赖关系，有助于确保对关键数据维持严格的数据约束。例如，在数据仓库或数据湖中，对于销售数据的分析可能涉及多个度量指标，如销售额、销售量、平均售价等。如果 Catalog 能够清晰地定义这些指标，记录它们的计算方式以及依赖的数据源和数据处理步骤，就可以更好地进行数据质量管理和问题排查。同时，通过对这些指标的追踪和监测，可以及时发现数据异常，确保数据的准确性和可靠性。

同数据血缘，数据质量管理也是业务的核心关注点。目前看，大多数 Catalog 系统对这方面支持的都不充分。AWS Glue 主要是借助 AWS 上强大的生态，依托整合其他系统来提供完善的解决方案。当然，译者个人认为，数据血缘和数据质量管理是非常专业的场景，可能并不太适合完全内嵌到 Catalog 系统中，这可能使得系统变得异常复杂且不标准。或者从另一方面说，Catalog 只是是广义上的数据管理的一环。

4.6. 数据质量管理（Data Quality Management）

关注点	解释
Schema 管理	在数据质量管理中，Schema 管理非常重要，因为它有助于维护数据的一致性和完整性，防止错误数据的引入，并提高数据的可理解性和可维护性。其主要包括：Schema 注册，能够将数据表的 Schema 信息注册到数据目录中，以便用户可以查看和理解数据。监控 Schema 变化：跟踪数据表 Schema 的变化，以便及时发现和处理数据结构的变更。检查 Schema 规则：确保数据符合特定的Schema 要求，例如数据类型、约束条件等。
数据质量策略	关注设定和监测数据准确性、完整性和有效性等标准和规则的机制，确保数据符合业务和监管要求。例如，使用类似 Great Expectations 这样的开源项目对数据进行表达性和可扩展性的单元测试，设定预期并监测是否满足这些预期。不同的 Catalog 可能在数据质量策略方面有不同的功能实现。有些数据目录可能内置了这些功能，而有些如 AWS Glue 则利用开源项目 DeeQu 来管理数据质量。数据质量策略有助于维护数据的质量，确保数据可靠且适合特定目的。
数据新鲜度	指的是能够监测数据最近一次更新的时间间隔或状态。它关注数据集是否是最新的，反映了数据的时效性。例如，一些使用场景可能要求数据新鲜度在 1 分钟以内，即数据不能滞后超过 1 分钟；而另一些场景可能满足于 24 小时内的数据更新。在数据管理中，确保数据新鲜度很重要，因为过时的数据可能导致错误的决策。在 Catalog 中，数据新鲜度通常通过监控和跟踪数据的更新情况来实现，本次对比的系统中，只有 AWS Glue 提供了这种能力。

同数据血缘，数据质量管理也是业务的核心关注点。目前看，大多数 Catalog 系统对这方面支持的都不充分。AWS Glue 主要是借助 AWS 上强大的生态，依托整合其他系统来提供完善的解决方案。当然，译者个人认为，数据血缘和数据质量管理是非常专业的场景，可能并不太适合完全内嵌到 Catalog 系统中，这可能使得系统变得异常复杂且不标准。或者从另一方面说，Catalog 只是是广义上的数据管理的一环。

结束语

2024年可以作为 Catalog 生态发展的元年（尤其针对数据湖领域），相信在2025年这个赛道的发展会更加繁荣。

目前并没有一个 Catalog 能够 All-in-One 的满足所有需求。从对比结果看，一些老牌的数据目录（如 DataHub、Atlan）在用户界面、高级数据管理功能方面非常优秀。但同时，对于一些新的技术和方向，如半结构化数据的支持、Apache Paimon 格式的支持等，在新诞生的数据目录项目（如 Apache Gravitino(Incubating)）中会得到更快的发展。

AWS 的用户可能没有比 Unity Catalog 商业版本更好的选择，因为它天然对 AWS 上的服务有深度集成。但另一方面，企业都在避免的一个被供应商锁定的风险。所以 Onehouse 也在推进包括 Apache XTable(Incubating)[1] 和 Multi-Catalog Sync[2] 这类的数据和元数据交换层。