Databricks 湖屋中的数据对象

Databricks 湖屋使用熟悉的关系(如数据库、表和视图)组织在云对象存储中与 Delta Lake 一起存储的数据。 此模型结合了企业数据仓库的许多优势,以及 Data Lake 的可伸缩性和灵活性。 详细了解此模型的工作原理以及对象数据和元数据之间的关系,以便在为组织设计和实现 Databricks 湖屋时应用最佳做法。

Databricks 湖屋中有哪些数据对象?

Databricks 湖屋体系结构将存储在云对象存储中的 Delta Lake 协议中的数据与注册到元存储的元数据相结合。 Databricks 湖屋中有五个主要对象:

  • 目录:数据库分组。
  • 数据库或架构:在目录中提供对象的分组。 数据库包含表、视图和函数。
  • :作为数据文件存储在对象存储中的行和列的集合。
  • 视图:保存的查询通常针对一个或多个表或数据源。
  • 函数:保存的逻辑返回标量值或行集。

Unity Catalog object model diagram

有关使用 Unity 目录保护对象的信息,请参阅安全对象模型

什么是元存储?

元存储包含定义 Lakehouse 中的数据对象的所有元数据。 Azure Databricks 提供以下元存储选项:

  • Unity Catalog 元存储:Unity Catalog 提供集中访问控制、审核、世系和数据发现功能。 可以在 Azure Databricks 帐户级别创建 Unity Catalog 元存储,单个元存储可以跨多个工作区使用。

    每个 Unity Catalog 元存储都在 Azure 帐户的 Azure Data Lake Storage Gen2 容器中配置了一个根存储位置。 此存储位置默认用于存储托管表的数据。

    在 Unity Catalog 中,默认情况下数据是安全的。 最初,用户无权访问元存储中的数据。 访问权限可以由元存储管理员或对象所有者授予。 Unity Catalog 中的安全对象是分层的,特权是向下继承的。 Unity Catalog 提供一个管理数据访问策略的位置。 用户可以从元存储附加到的任何工作区访问 Unity Catalog 中的数据。 有关详细信息,请参阅管理 Unity Catalog 中的特权

  • 内置 Hive 元存储(旧版):每个 Azure Databricks 工作区都包含一个内置的 Hive 元存储,用作托管服务。 元存储的实例部署到每个群集,并安全地从每个客户工作区的中央存储库访问元数据。

    与 Unity Catalog 相比,Hive 元存储提供了一个不太集中的数据治理模型。 默认情况下,除非为群集启用了表访问控制,否则该群集允许所有用户访问工作区的内置 Hive 元存储管理的所有数据。 有关详细信息,请参阅 Hive 元存储表访问控制(旧版)

    表访问控制不存储在帐户级别,因此必须为每个工作区单独配置它们。 为了利用 Unity Catalog 提供的集中且简化的数据治理模型,Databricks 建议将工作区的 Hive 元存储管理的表升级到 Unity Catalog 元存储

  • 外部 Hive 元存储(旧版):你还可以将自己的元存储引入 Azure Databricks。 Azure Databricks 群集可以连接到现有的外部 Apache Hive 元存储。 可以使用表访问控制来管理外部元存储中的权限。 表访问控制未存储在外部元存储中,因此必须为每个工作区单独配置它们。 Databricks 建议你改用 Unity Catalog,因其简易性和以帐户为中心的治理模型。

无论你使用哪种元存储,Azure Databricks 都会将所有表数据存储在云帐户的对象存储中。

什么是目录?

目录是 Databricks 湖屋关系模型中的最高抽象(或粗粒度)。 每个数据库都将与目录相关联。 目录作为元存储中的对象存在。

在引入 Unity 目录之前,Azure Databricks 使用了两层命名空间。 目录是 Unity 目录名称存储模型中的第三层:

catalog_name.database_name.table_name

内置 Hive 元存储仅支持单个目录 hive_metastore

什么是数据库?

数据库是数据对象的集合,例如表或视图(也称为“关系”)和函数。 在 Azure Databricks 中,术语“schema”和“database”可以互换使用(而在许多关系系统中,数据库是架构集合)。

数据库将始终与云对象存储上的某个位置相关联。 可以选择在注册数据库时指定一个 LOCATION,请记住:

  • 与数据库关联的 LOCATION 始终被视为托管位置。
  • 创建数据库不会在目标位置创建任何文件。
  • 数据库的 LOCATION 将确定注册到该数据库的所有表的数据的默认位置。
  • 成功删除数据库会递归删除存储在托管位置中的所有数据和文件。

数据库和数据文件托管的位置之间的这种交互非常重要。 为了避免意外删除数据:

  • 不要跨多个数据库定义共享数据库位置。
  • 不要将数据库注册到已包含数据的位置。
  • 若要独立于数据库管理数据生命周期,请将数据保存到不在任何数据库位置下嵌套的位置。

什么是表?

Azure Databricks 表是结构化数据的集合。 Delta 表将数据存储为云对象存储中的文件目录,并将表元数据注册到目录和架构中的元存储。 由于 Delta Lake 是 Azure Databricks 中创建的表的默认存储提供程序,因此默认情况下,Databricks 中创建的所有表都是 Delta 表。 由于 Delta 表在云对象存储中存储数据并通过元存储提供对数据的引用,因此组织中的用户可以使用其首选 API 访问数据:在 Databricks 上,这包括 SQL、Python、PySpark、Scala 和 R。

请注意,可以在不是 Delta 表的 Databricks 上创建表。 这些表不受 Delta Lake 的支持,并且不会提供 DELTA 表的 ACID 事务和优化性能。 属于此类别的表包括针对外部系统中的数据注册的表,以及针对数据湖中的其他文件格式注册的表。 请参阅连接到数据源

Databricks 中有两种类型的表,托管和非托管(或外部)表。

注意

实时表与流式处理实时表之间的增量实时表区别不是从表的角度强制执行的。

什么是托管表?

Azure Databricks 管理托管表的元数据和数据;删除表时,还会删除基础数据。 大多数在 SQL 工作的数据分析师和其他用户可能更喜欢此行为。 创建表时,托管表是默认值。 托管表的数据驻留在其注册到的数据库的 LOCATION 中。 数据位置与数据库之间的这种托管关系意味着若要将托管表移动到新数据库,必须将所有数据重写到新位置。

可通过多种方式创建托管表,包括:

CREATE TABLE table_name AS SELECT * FROM another_table
CREATE TABLE table_name (field_name1 INT, field_name2 STRING)
df.write.saveAsTable("table_name")

什么是非托管表?

Azure Databricks 仅管理非托管(外部)表的元数据,删除表时,不会影响基础数据。 非托管表在创建表期间始终指定 LOCATION;可以将现有数据文件目录注册为表,也可以在首次定义表时提供路径。 由于数据和元数据是独立管理的,因此可以重命名表或将其注册到新数据库,而无需移动任何数据。 数据工程师通常更喜欢非托管表,因为非托管表为生产数据提供更高的灵活性。

可通过多种方式创建托管表,包括:

CREATE TABLE table_name
USING DELTA
LOCATION '/path/to/existing/data'
CREATE TABLE table_name
(field_name1 INT, field_name2 STRING)
LOCATION '/path/to/empty/directory'
df.write.option("path", "/path/to/empty/directory").saveAsTable("table_name")

什么是视图?

视图通常针对元存储中的一个或多个数据源或表存储查询的文本。 在 Databricks 中,视图等效于作为数据库中的对象保存的 Spark 数据帧。 与 DataFrame 不同,你可以从 Databricks 产品的任何部分查询视图,前提是你有权执行此操作。 创建视图不会处理或写入任何数据;仅将查询文本注册到关联数据库中的元存储。

什么是临时视图?

临时视图的范围和持久性有限,并且未注册到架构或目录。 临时视图的生存期因所使用的环境而异:

  • 在笔记本和作业中,临时视图的范围限定为笔记本或脚本级别。 它们不能在声明它们的笔记本外部引用,并且当笔记本与群集分离时将不再存在。
  • 在 Databricks SQL 中,临时视图的范围限定为查询级别。 同一查询中的多个语句可以使用临时视图,但不能在其他查询中引用,即使在同一仪表板中也是如此。
  • 全局临时视图的范围限定为群集级别,可在共享计算资源的笔记本或作业之间共享。 Databricks 建议将视图与相应的表 ACL 配合使用,而不是全局临时视图。

什么是函数?

函数允许将用户定义的逻辑与数据库相关联。 函数可以返回标量值或行集。 函数用于聚合数据。 通过 Azure Databricks 可以根据执行上下文以各种语言保存函数,并且 SQL 受到广泛支持。 可以使用函数在 Databricks 产品上的各种上下文中提供对自定义逻辑的托管访问。

关系对象如何在增量实时表中工作?

Delta Live Tables 使用声明性语法来定义和管理 DDL、DML 和基础结构部署。 Delta Live Tables 在逻辑规划和执行过程中使用“虚拟架构”的概念。 增量实时表可以与 Databricks 环境中的其他数据库进行交互,Delta 实时表可以通过在管道配置设置中指定目标数据库来发布和保存表以在其他地方进行查询。

Delta Live Tables 中创建的所有表都是 Delta 表。 将 Unity Catalog 与 Delta Live Tables 配合使用时,所有表都是 Unity Catalog 托管表。 如果 Unity Catalog 不处于活动状态,则可以将表声明为托管表或非托管表。

虽然可以在增量实时表中声明视图,但这些视图应被视为限定为管道的临时视图。 Delta Live Tables 中的临时表是一个独特的概念:这些表将数据保存到存储中,但不将数据发布到目标数据库。

某些操作(例如 APPLY CHANGES INTO)将同时向数据库注册表和视图;表名称以下划线开头 (_),该视图将声明为 APPLY CHANGES INTO 操作目标的表名称。 视图查询相应的隐藏表,以具体化结果。