湖仓架构中的存储层非常重要，因为它存储了整个平台的数据。为了搜索、探索和发现这些存储的数据，用户需要一个数据目录。本章将重点介绍数据目录和使湖仓平台用户能够搜索和访问数据的整体元数据管理过程。

在本章的第一部分，我将解释元数据、元存储和数据目录等基本概念。这些并不是新概念；组织长期以来一直在传统数据仓库和现代数据平台中实施数据目录。我会首先解释这些核心概念，以便为后面讨论的高级特性做好准备。

我们将讨论数据目录在湖仓架构中与传统和组合架构中的差异，以及它们如何帮助用户获得所有元数据的统一视图。我们还将讨论数据目录在湖仓架构中的额外好处，这些好处使用户能够利用元数据来实施统一的数据治理、权限控制、数据沿袭和共享机制。

在本章的最后一部分，我将讨论一些在云平台上可用的流行数据目录技术选项。你将了解设计考虑因素和实际限制，这些可以帮助你在设计湖仓平台中的数据目录时做出明智的决策。

理解元数据

正如我们需要流程来管理平台内的数据，我们也需要明确的方法来管理元数据。一个完善的元数据管理流程有助于简化平台用户的数据搜索和发现。

元数据通常被定义为"关于数据的数据"。它与数据本身同样重要。元数据通过提供描述数据的附加信息（如属性名称、数据类型、文件名和文件大小）来定义数据。

元数据提供了理解数据所需的结构和其他相关信息。它帮助用户发现、理解并找到他们特定需求的确切数据。

元数据大致分为技术元数据和业务元数据。

技术元数据

技术元数据提供有关数据的技术信息。技术元数据的一个简单例子是任何表的模式详细信息。模式包含属性名称、数据类型、长度和其他相关信息。表 4-1 列出了具有三个属性的产品表的模式。

表 4-1. 产品表模式

属性名称	属性类型	属性长度	属性约束
product_id	integer		Not Null
product_name	string	100	Null
product_category	string	50	Null

与表类似，其他对象（如文件）也具有元数据。文件元数据提供文件名、创建或更新时间、文件大小和访问权限等详细信息。CSV 文件有时具有定义数据属性名称的标题记录。JSON 和 XML 文件也包含属性名称。正如在第 3 章中所看到的，Apache Parquet、Apache ORC 和 Apache Avro 等文件格式也携带元数据信息。

业务元数据

业务元数据帮助用户理解数据的业务含义。业务元数据增强了技术元数据，为数据提供了业务背景。表 4-2 列出了产品表的业务元数据。

表 4-2. 产品表业务元数据

技术属性名称	业务属性名称	业务属性含义
product_id	产品标识符	产品的唯一标识符
product_name	产品名称	产品的名称
product_category	产品类别	产品的类别

在这个例子中，技术属性名称是不言自明的，你可以很容易地理解它们的业务含义。然而，这并不总是如此。

考虑一个场景：你使用 SAP 作为源系统，并使用 SAP 物流模块材料管理 (MM)。MARA 表是该 SAP 模块中广泛使用的表之一，保存一般材料数据。如表 4-3 所示，这些属性的技术名称并不言自明，你需要为用户添加业务背景，以理解每个属性包含的数据。

表 4-3. SAP MARA 表业务元数据

技术属性名称	业务属性名称	业务属性含义
MANDT	客户端	客户端名称
MATNR	物料号	物料的唯一标识符
ERSDA	创建日期	创建物料条目的日期

技术元数据和业务元数据对于更好地理解平台中的数据是必不可少的。一个完善的元数据管理流程应具备维护和管理技术和业务元数据的能力。它应支持治理和安全特性，如访问控制、敏感数据处理和数据共享，我们将在本章后面讨论这些内容。

什么是元数据管理？

元数据管理过程是一系列活动，旨在：

从外部和内部系统创建或导入元数据
为技术元数据添加业务背景
更新和维护元数据的各种版本
组织元数据以便于用户发现

元数据管理过程的主要目标是将元数据视为数据生态系统中的一等公民，管理和维护其整个生命周期。

元存储和数据目录如何协同工作

虽然元数据管理是管理元数据并使其对用户可用的一个过程，但我们需要解决方案和工具来实施这个过程。元存储和数据目录是帮助建立完善元数据管理过程的解决方案。

元存储是数据平台内存储元数据的存储库。它充当中央元数据存储系统。你可以从这个中央存储库访问所有元数据。

数据目录提供了一种访问存储在元存储中的元数据的机制。它提供了必要的用户界面来探索元数据并搜索各种表和属性。

图 4-1 显示了元存储和数据目录之间的关系，以及它们如何使用户能够访问元数据。

例如，在传统的本地 Hadoop 生态系统中，Hive 提供了 Hive Metastore (HMS) 来存储元数据（用于在 HDFS 数据之上创建的 Hive 表），并提供了 Hive Catalog (HCatalog) 以便从 Spark 或 MapReduce 应用程序访问 HMS 表。

现代数据目录提供了一种更有组织地管理元数据的机制。它们使你能够为正确的用户提供正确的访问控制，以便他们可以安全地访问数据。你可以将目录逻辑上划分为包含表、视图和其他对象的数据库或模式。你可以在目录级别或更细粒度的模式或表级别管理用户访问权限。

图 4-2 显示了一个现实场景，用户如何根据他们的角色和权限访问特定目录。

如图 4-2 所示，来自"X"业务单元的用户只能访问"X"业务单元的目录，来自"Y"业务单元的用户只能访问"Y"业务单元的目录。

并不总是需要根据业务单元来分类目录。可以有多种方法，你可以选择最适合你的方法。你可以根据不同的环境（如开发、测试和生产）创建目录，或者你可以创建一个单一目录并在模式或表级别控制权限。

注意

许多数据从业者使用元存储和数据目录这两个术语互换来描述元数据存储系统。大多数提供数据目录功能的现代云服务抽象了元数据的物理存储，并仅向用户公开数据目录以浏览和访问模式、表和属性。在每个目录背后，都有一个存储实际元数据的物理存储。

数据目录的特性

数据目录提供了几个关键特性，帮助平台管理员组织、管理和治理数据。本节讨论的特性能帮助平台用户快速搜索、探索和发现相关数据。

搜索、探索和发现数据

数据目录为用户提供了一种简单的机制来搜索所需数据，并了解数据存在的位置（模式、表或属性），以便他们可以查询它。数据目录还提供了为表和属性添加业务描述的功能。

用户可以遍历目录，理解业务背景，发现可能对进一步分析有帮助的数据。

数据分类

分类是根据某些规格或标准对属性进行分类的过程。你可以根据领域（如客户、产品和销售）或敏感性（如机密、内部或公开）对属性进行分类。分类有助于用户更全面地理解和利用数据。例如，一个被分类为"内部"的属性表明用户不应将数据共享给组织外部的人。

在分类过程中，你可以为元数据添加标签。例如，考虑一个为保险提供商实施湖仓的场景。你会有几个与客户相关的数据表，如客户姓名、出生日期和国家标识符。所有这些属性都是个人可识别信息（PII）属性。你可以在目录中将这些属性标记为"pii_attributes"，并使用这些标签实施治理策略，从不符合资格或外部用户那里抽象出这些敏感数据。我们将在第6章中更详细地讨论如何处理敏感数据。

注意

PII 属性是可以用来识别特定个人的数据部分，包括国家ID、电子邮件ID、电话号码和出生日期。

出于合规目的，必须从数据消费者中抽象出此类信息。你应该根据组织角色仅向特定用户组提供对 PII 属性的访问权限。

你还应该实施数据治理策略，以隐藏或掩盖不符合资格的用户看到 PII 属性中的值。

数据分类有助于管理数据、实施治理策略，并在平台内保护数据。

数据治理和安全

数据目录作为数据的守门人，有助于实施必要的数据治理和安全策略，以管理、治理和保护整个组织的数据。

数据目录提供以下治理和安全特性：

支持实施维护数据质量的标准规则和约束
实施审核过程，如跟踪访问特定表或属性的用户，符合合规报告要求
支持对访问数据的用户进行细粒度权限控制
提供过滤或抽象存储在平台内的敏感数据的能力，以保护平台数据
实现与数据消费者的安全数据共享

数据治理是一个广泛的话题，我们将在第6章中更详细地讨论。

数据沿袭

任何数据和分析生态系统都包括多个作业，这些作业从源系统摄取数据，进行转换，并最终加载到目标存储中供用户使用。在这个存储中，可能有数百个表和数千个属性，通过这些组件数据流动。随着系统的增长，数据资产不断增加。要跟踪平台中各组件的数据流，需要一种跟踪机制，提供关于数据如何通过这些属性导航的端到端详细信息。数据沿袭是提供关于这些组件中数据流动信息的过程。

数据沿袭还可以帮助在任何属性名称、类型或长度更改时进行影响分析。它可以帮助你审核冗余或没有任何消费者使用的数据资产（如表）。数据目录帮助你实现数据沿袭解决方案，以跟踪源属性和目标属性之间的关系。我们将在第6章中更详细地讨论这一点。

数据目录的特性促进了组织内不同数据团队和数据角色之间的协作，使业务用户能够通过发现和利用他们需要的数据进行自助分析，从而做出更好的决策。

统一数据目录

正如在第2章中讨论的那样，组合架构面临着许多限制，因为它使用了两个不同的存储层------一个用于数据湖，一个用于数据仓库。在这种系统中，你还会面临管理数据湖和数据仓库的独立、孤立元存储和目录的挑战。

孤立元数据管理的挑战

组合架构中与孤立的、独立数据存储层相关的大多数挑战也适用于元数据管理。这些挑战包括：

维护你需要为数据湖对象和数据仓库表维护单独的元数据，这增加了整体维护工作量。你必须频繁地在两个系统之间复制元数据以同步一个系统的更改到另一个系统。

数据发现 在组合架构中，数据发现变得具有挑战性，因为用户必须浏览两个不同的数据目录。有些对象，如汇总表和聚合视图，可能只在数据仓库中可用。在这种情况下，平台用户应该知道哪个系统包含他们需要的数据。

数据治理和安全 由于存储层是孤立的，实施访问控制、敏感数据处理和安全共享等数据治理和安全策略变得具有挑战性。在这种环境中，你无法制定一个易于实施和维护的统一数据治理策略。

数据沿袭 对于特定列的名称、数据类型或长度的任何更改，你需要进行影响分析以确定包含该特定列的表。在组合架构中，沿袭视图仅限于单个生态系统（数据湖或数据仓库）；你无法获得数据流的端到端理解。

考虑到这些挑战，使用统一数据目录可以简化元数据管理、数据发现和治理过程。湖仓架构使你能够实现这个统一数据目录。

什么是统一数据目录？

统一数据目录是一个可以包含所有数据资产（如表、视图、报告、函数）以及 AI 资产（如机器学习模型和特征表）的元数据的目录。统一数据目录使用户能够从单一的中央平台治理所有数据和 AI 资产。在湖仓架构中，所有数据和 AI 工作负载的资产都驻留在单一的云存储层中，使平台管理员能够实施统一的数据目录来管理和治理整个生态系统。

图 4-3 显示了湖仓平台中的统一数据目录及其提供的关键特性。

如前所述，数据目录提供了搜索、发现、治理和沿袭等关键特性。在统一数据目录中，组织可以在所有数据对象（如表、视图和报告）以及在AI工作负载中使用的所有资产（如模型和特征库）上实施这些特性。

统一数据目录为不同的数据角色（如数据工程师、分析师和科学家）提供了一个单一的界面，使他们能够高效地协作，共同探索和利用数据。它充当了技术和业务用户搜索和发现数据的中央存储库。

总结一下，作为数据消费者，统一数据目录是你探索平台内所有数据和AI资产、浏览这些资产的技术元数据并了解数据的业务背景的窗口。

统一数据目录的好处

统一数据目录的主要好处如下：

统一搜索和数据发现 在湖仓架构中，你可以实现单一的元存储层来保存整个生态系统的所有元数据。与组合架构不同，用户可以使用统一数据目录浏览和探索所有数据资产的元数据。这使用户能够快速搜索所需的表或属性，而无需知道数据在系统内的物理位置。

数据目录还提供了用业务背景增强技术数据的特性。数据所有者可以为属性添加业务描述和业务含义。这使业务用户和技术用户能够轻松发现数据。

一致的访问控制 管理和维护对数据的访问是困难的。当你希望在平台中实施一致的访问级别时，这变得更加具有挑战性。统一数据目录帮助在数据生态系统中实施一致的访问控制机制。

你可以为不同的人员实施一致的访问控制机制，而不管他们使用的是哪种计算引擎。考虑一个场景，你希望销售团队的数据工程师和数据科学家能够访问他们特定业务单元的数据资产。数据工程师可能使用笔记本，而数据科学家可能希望查询特征存储表以访问数据。使用统一访问控制机制，你可以为两种角色提供相同的访问级别。

统一数据治理和安全 通过统一数据目录，你可以实施适用于所有资产（包括表、文件、函数、ML模型和特征表）的统一数据治理和安全策略。你可以通过应用一致的屏蔽策略来保护湖仓中的敏感数据。无论使用什么工具访问数据，任何角色只能看到他们有资格访问的数据。

端到端数据沿袭 使用具有统一元存储和目录的湖仓，你可以轻松查看所有组件的端到端沿袭。一些先进的数据目录还提供了实施联合目录的能力，可以显示平台外部来源的元数据以及包含这些来源的沿袭。

统一各类资产的数据管理过程的各个方面，能够为湖仓平台用户提供一致的体验，无论他们从何处访问数据。

实施数据目录：关键设计考虑因素和选项

有多种工具和平台可以帮助你在湖仓中实现数据目录。每个云提供商都有自己的本地服务，并且大多数领先的第三方产品都有实现数据目录的功能。

你可以根据用例和整体技术环境设计和实现统一数据目录。在本节中，我将讨论一些领先的数据目录工具、设计考虑因素、可能的设计选择以及在湖仓平台中实现数据目录的关键限制。

我们将讨论广泛采用的 Hive 元存储；来自 AWS、Azure 和 GCP 的云原生数据目录；以及来自第三方如 Databricks 的数据目录产品。

使用 Hive 元存储

自 Hadoop 时代以来，Hive 一直很受欢迎。许多组织在实施 Hadoop 生态系统或现代数据平台时，采用 Hive 元存储 (HMS) 来支持其元数据管理需求。传统的 Hadoop 生态系统使用 MapReduce 作为计算引擎，并使用 HCatalog 作为访问 HMS 的数据目录。Spark 也有一个数据目录 API 来访问存储在 HMS 中的元数据。

你可以考虑使用 HMS 来存储数据平台的元数据。HMS 为用户提供了使用外部 RDBMS 存储元数据（如表类型、列名和列数据类型）的灵活性。它充当了一个中央存储库，用于存储和管理使用不同计算引擎（如 Hive、Spark 或 Flink）创建的表的元数据。像 AWS Glue 和 Databricks 等本地云服务和第三方产品都提供了使用 HMS 存储元数据的选项。

虽然许多组织采用 HMS 作为其主要元存储，但它有几个关键挑战：

你需要提供和管理一个单独的 RDBMS 来存储元数据，这增加了维护的工作量。
由于它不是本地云服务，你需要额外的努力来进行集成，相比云原生数据目录服务而言。

考虑到这些挑战，CSPs 引入了本地目录服务，以实现简单易行的元数据管理流程。

使用 AWS 服务

AWS 提供了两种存储元数据的选项------HMS 和 Glue Data Catalog。

Glue Data Catalog 是 AWS 的本地服务，与 AWS Glue ETL、Amazon EMR、Amazon Athena 和 AWS Lake Formation 等服务轻松集成。在 AWS 上实施湖仓平台时，你会使用大多数这些服务。

注意

以下是刚才提到的 AWS 服务的简要说明。我将在本书的后续章节中详细讨论这些内容：

AWS Glue ETL 是一个无服务器的数据集成服务，用于创建数据处理的 Spark 作业。
Amazon EMR 提供一个大数据平台，用于执行 Spark、Hive、Presto、HBase 和其他大数据框架的框架，进行数据处理、交互式分析和机器学习。
Amazon Athena 是一个无服务器服务，用于对存储在 S3 上的数据进行交互式分析。
AWS Lake Formation 提供了在 S3 中保护和治理数据的功能。

图 4-4 显示了一个简单的流程图，说明如何在 S3 中创建 Hudi 文件，解析它们以在 Glue Data Catalog 中创建元数据，使用 Lake Formation 治理 Hudi 表，并使用 Amazon Athena 引擎查询它们。你也可以使用 Iceberg 或 Delta Lake 等其他开放表格式代替 Hudi。

如图所示，Glue Data Catalog 在湖仓架构中发挥了重要作用，使不同角色能够创建、访问和查询驻留在 S3 上的数据。

与 HMS 类似，Glue Data Catalog 也为所有数据资产提供了一个中央元数据存储库。AWS Glue Data Catalog 的关键特性如下：

与其他 AWS 服务深度集成。
是一个全托管的无服务器服务，无需用户部署或维护。
你可以使用 Glue 爬虫从 S3 中解析数据文件，以在目录中创建元数据。
与 Amazon Athena 的集成提供了一个用户界面，可以轻松地浏览模式、表和属性。
使用 EMR 集群中的 Spark、Hive 和 Presto 等开源框架创建的表可以使用 Glue Data Catalog 来存储其元数据。
它与 AWS Lake Formation 集成，为用户提供细粒度的访问控制。
亚马逊还提供了一项名为 Amazon DataZone 的服务，可以帮助你实现一个数据目录，该目录能够用业务元数据增强技术元数据。你可以将存储在 Glue Data Catalog 中的元数据导入 DataZone，并为技术属性添加业务描述，以赋予其业务背景。你可以进一步使用 DataZone 进行数据治理和共享，该服务内部使用 Lake Formation 进行权限管理和数据共享。

使用 AWS 服务实现湖仓平台的数据目录时，请考虑以下关键点：

使用 Glue Data Catalog 而非 HMS

Glue Data Catalog 是 HMS 的替代方案。你可以使用 Glue Data Catalog 作为元存储，存储在 Amazon EMR 集群内使用 Hive、Spark 和 Presto 等查询引擎创建的表的元数据。Glue Data Catalog 支持存储 Hudi、Iceberg 和 Delta Lake 表的元数据。支持你首选的开放表格式是选择数据目录服务时最重要的考虑因素之一。

使用 Glue 爬虫进行自动元数据创建

你可以使用 AWS Glue 爬虫来爬取 S3 中的数据文件并获取（解析）元数据。Glue 爬虫将元数据存储在 Glue Data Catalog 中，并根据从文件解析的记录创建表。你可以使用爬虫为存储在 S3 中的所有文件生成元数据。Glue 爬虫还可以检测 S3 数据存储中的模式更改。你可以配置爬虫以更新或忽略数据目录中的表更改。

表格式支持

Glue 爬虫现在还支持 Hudi、Iceberg 和 Delta Lake 文件，自动在 Glue Data Catalog 中创建表。根据你的表格式选择，可以在创建爬虫时选择相关选项。

使用 Lake Formation 进行数据治理

Glue Data Catalog 与 Lake Formation 深度集成，帮助你实施细粒度的访问控制和其他数据治理功能，如基于角色的数据过滤和安全数据共享。

使用 Athena 进行数据探索

Glue Data Catalog 与 Amazon Athena 深度集成，Athena 是一种查询 S3 数据湖中数据的服务。我们将在第 5 章详细讨论。Athena 允许你浏览 Glue Data Catalog 中的所有数据库、表和列。

使�� Azure 服务

如果你计划使用 Azure 生态系统实现湖仓，将使用 Azure Synapse Analytics 作为计算层，使用 ADLS 作为存储层。

Synapse Analytics 提供了两个计算引擎来处理存储在 ADLS 中的数据：Synapse Spark 池和 Synapse 无服务器 SQL 池。熟悉 Spark 编程的数据工程师可以使用 Spark 池。对于更习惯使用 SQL 的数据分析师，Synapse 提供了无服务器 SQL 池。你可以使用这两者之一来处理存储在 ADLS 中的数据。我们将在第 5 章更详细地讨论这些计算引擎。

图 4-5 显示了 Synapse Analytics 提供的两种选项，用于维护和管理存储在 ADLS 中的数据的元数据------湖数据库和 SQL 数据库：

湖数据库

Synapse Spark 池管理湖数据库。你可以使用湖数据库来存储使用 Synapse 笔记本创建的对象的元数据，包括使用 Spark 池创建的 Delta 表的元数据。

SQL 数据库

无服务器 SQL 池管理 Synapse SQL 数据库。你可以使用 Synapse 无服务器 SQL 池在 SQL 数据库中创建表，并可以使用无服务器 SQL 端点将 Management Studio 或 Power BI 连接到 SQL 数据库中的表并查询数据。

注意

Synapse SQL 数据库不同于 Azure SQL 数据库（关系数据库）服务。Synapse SQL 数据库保存使用 Synapse 无服务器 SQL 池创建的表的元数据。它不保存实际数据，因为数据驻留在 ADLS 上。

根据你使用的计算引擎，你可以选择湖数据库（适用于 Spark 池）或 SQL 数据库（适用于无服务器 SQL 池）。如图 4-5 所示，使用湖数据库的优势在于你可以从 Synapse 笔记本以及 Synapse 无服务器 SQL 池访问它。

图 4-6 显示了如何在 ADLS 中创建 Delta 表，在湖数据库中创建元数据，并使用 Microsoft Purview 实现一个统一目录，以便使用 Synapse 无服务器 SQL 池进行进一步分析时安全地查询它。

如图 4-6 所示，你可以使用 Synapse 笔记本创建 Delta 表，然后使用无服务器 SQL 池端点，通过 Power BI 或任何其他数据库查询编辑器（如 SQL Server Management Studio (SSMS)）查询数据。

虽然 Synapse 湖数据库和 SQL 数据库保存了元数据，但它们不是完整的数据目录解决方案。Azure 提供了一个名为 Microsoft Purview 的服务，具有目录功能。你可以考虑使用它来为你的湖仓实现数据目录。

Microsoft Purview 提供对本地、Azure 原生和多云平台的统一数据治理支持，以及对数据分类和敏感数据处理的支持。它还提供了数据沿袭、访问控制和数据共享等功能，并提供了为业务用户创建和维护业务词汇表的功能。你可以将 Synapse SQL 数据库中的元数据导入 Microsoft Purview，并在你的平台中利用这些功能。

提示

Microsoft Purview 还支持从 Databricks 导入元数据。如果你使用 Databricks 计算进行数据处理，并希望使用 Microsoft Purview 维护数据目录，这将是一个有用的功能。

使用 GCP 服务

与 AWS 和 Azure 类似，你可以在 GCP 中按照类似的模式创建数据目录，并将其用作元数据管理的中央统一层。

图 4-7 显示了如何在 GCS 中创建 Iceberg 表，在 BigLake 中创建元数据，使用 Dataplex 集中治理元数据，并使用 BigQuery 进行进一步分析时安全地查询这些数据。

注意

以下是图 4-7 中显示的计算服务的简要说明，我将在后续章节中详细讨论这些内容：

Dataproc 是一个 GCP 托管服务，用于运行 Spark 和 Hadoop 集群。
BigQuery 是一个无服务器数据仓库服务，提供内置的 BI 和 ML 功能。
BigLake
- BigLake 是一个 GCP 服务，使 BigQuery 和其他开源框架（如 Spark）能够通过细粒度访问控制访问存储在 GCS 中的数据。它支持 Iceberg 开放表格式，使 BigQuery 用户能够查询存储在 GCS 中的 Iceberg 数据，并将其作为 BigLake 表进行权限控制。
BigLake 的主要特性如下：
- 提供一个元存储，以便从 BigQuery 访问 Iceberg 表。
- 能够同步在 Dataproc 或 BigQuery 中创建的 Iceberg 表，并通过 BigQuery SQL 接口向用户提供这些表。
- 使管理员能够对 Iceberg 表实施细粒度访问控制。
- BigLake 目前仅支持 Iceberg 的 Parquet 数据文件，并且有一些其他限制。
Dataplex
- Dataplex 是一个 GCP 服务，使组织能够发现和治理其数据资产。它提供探索数据、管理数据生命周期和使用端到端沿袭了解数据流的能力。
- BigLake 与 Dataplex 集成，为 BigLake 表提供中央访问控制机制。如果你希望从单一视图管理所有数据资产，可以考虑在平台中使用 Dataplex。

使用 Databricks

随着多云策略的兴起，许多组织开始寻找与其多云策略良好集成的第三方产品。Databricks 提供了一个使组织能够采用多云策略的产品，因为它可以利用 AWS、Azure 和 GCP 的基础设施进行计算和存储。

注意

多云策略是一种使用多个云平台以获得不同 CSP 提供的最佳功能和成本优势的方法。许多组织现在选择多个云提供商来实现其数据生态系统。

Databricks 提供了几种元数据目录选项。你可以使用 HMS 或称为 Databricks Unity Catalog 的本地服务来管理、维护和治理元数据。Unity Catalog 有助于在湖仓上的数据和 AI 资产上实施统一治理解决方案。

与 AWS Glue Data Catalog 类似，Unity Catalog 作为 Databricks 的本地服务，能够轻松与 Databricks 的功能（如 Notebooks 和 Databricks SQL）集成。

注意

Databricks SQL 是 Databricks 湖仓平台内的一个无服务器计算引擎。你可以用它在湖仓中执行交互式查询。当与查询编辑器（Databricks UI 中可用的查询编写服务）结合使用时，你可以轻松浏览 HMS 或 Unity Catalog 中的数据资产，并使用 SQL 命令执行查询。

图 4-8 显示了在使用 Azure Databricks 实现的湖仓中的一个简单流程图。你可以使用 Databricks Notebooks 创建 Delta 文件，并通过 Databricks SQL 访问 Delta 表。

Unity Catalog 在管理元数据方面发挥了重要作用，它提供了一个可被 Databricks Notebooks 和 Databricks SQL 访问的中央位置。此外，它还提供了实施数据治理策略的中央访问控制机制。

Unity Catalog 提供的关键特性如下：

能力管理和治理所有数据和 AI 资产，如表、视图、笔记本、ML 模型、特征表和仪表板。
能够添加业务上下文，从而实现轻松搜索和数据发现。
提供联合目录（在撰写本书时处于预览阶段），用于外部来源如 MySQL、PostgreSQL/Postgres、Snowflake 和 Redshift。
跨 Databricks 生态系统（包括 AI 组件）的端到端数据沿袭。
通过对数据共享提供细粒度访问控制，实现安全数据共享。
笔记本中进行的任何模式和元数据更改都能立即在 Databricks SQL 中反映出来，没有任何延迟（相比于 Azure Synapse Analytics 与 Delta Lake 的组合）。

Databricks 最近将 Unity Catalog 开源，并将很快开始支持各种数据和 AI 产品。

Unity Catalog 是在 Databricks 生态系统内实施湖仓的绝佳选择。然而，如果你希望在 Databricks 之外访问和治理元数据，你还可以考虑其他企业级目录，这些目录可以从 Databricks Unity Catalog 中获取数据，并使其对 Databricks 之外的用户可用，从而实现更轻松的发现和中央治理。

提示

本节中讨论的许多特性和服务相对较新或仍处于预览模式。这些特性将逐步演变和成熟，并且我们讨论的一些限制将会有解决方法或解决方案。在为你的用例探索这些工具时，请查阅最新文档并评估最新版本。

除了云原生目录外，还有开源目录如 Project Nessie 和企业级目录工具如 Alation、Collibra 和 Atlan，它们提供了更多的特性和好处，你可以根据具体需求进行探索。

在前面的章节中，我们讨论了各种云原生目录服务。组织可以使用多个云或实施跨本地、私有云和公共云的混合数据生态系统。这样的组织需要企业级目录工具，这些工具可以与不同的 CSP 集成，从不同的源系统获取或联合数据，并连接到各种本地或私有云平台，以提供整个组织元数据的单一视图。企业级目录也被称为"目录的目录"。Collibra 是提供此类特性的一种产品。

关键要点

在本章中，我们讨论了如何在元存储中存储所有数据资产的元数据，并根据访问权限使用数据目录进行访问。湖仓架构使你能够实现一个统一的数据目录来管理、治理和共享所有的数据和 AI 资产。

表 4-4 总结了各云平台上可用于实施元数据管理流程的各种服务。

表 4-4. 各供应商的元数据管理服务

供应商	技术元数据管理	业务元数据管理和数据治理
AWS	HMS, Glue Data Catalog	DataZone
Azure	Synapse Lake Database, Synapse SQL Database	Microsoft Purview
GCP	BigLake	Dataplex
Databricks	HMS, Unity Catalog	Unity Catalog

表 4-5 总结了在湖仓架构中实现数据目录时，每个生态系统的关键设计考虑因素。

表 4-5. 数据目录实施的关键点

生态系统	关键设计考虑因素
AWS	考虑使用 Glue Data Catalog、Lake Formation 和 DataZone 实现统一数据目录。
	你可以使用这些服务来管理、治理和共享数据。
	使用 DataZone 为技术元数据添加业务上下文。
	Glue Data Catalog 和 Lake Formation 与 DataZone 集成。
	组织可以将 Hudi、Iceberg 或 Delta Lake 的元数据存储在 Glue Data Catalog 中，并使用 Athena 查询存储在 S3 中的数据。
Azure	你可以使用 Azure Synapse Analytics 实现湖仓架构。
	使用 Synapse 笔记本在 ADLS 中创建 Delta 文件，并在 Synapse Lake 数据库中创建元数据。
	Synapse 无服务器 SQL 池可以查询来自湖数据库和 SQL 数据库的数据。
	组织可以使用 Microsoft Purview 目录化技术和业务元数据，并应用治理策略。
GCP	BigLake 存储在 GCP 中创建的表的元数据。
	BigLake 本地支持 Iceberg 表，BigQuery 可以使用 BigLake 表查询数据。
	组织可以使用 Dataplex 在 GCP 内实现统一目录以治理数据。
Databricks	组织可以使用 Unity Catalog 实现统一目录。
	Unity Catalog 提供了对所有数据和 AI/ML 资产实施细粒度访问控制的功能。
	Databricks 最近开源了 Unity Catalog，现在可以在 Databricks 之外使用。

在本章中，我们重点学习了元存储和数据目录及其在湖仓架构中的特性和优势。在下一章中，我们将讨论湖仓架构中的不同计算和数据消费选项，以及它们如何帮助不同角色高效地执行数据和分析工作负载。

实用湖仓架构——数据目录