Data4Strategy

——合抱之木，生于毫末；九层之台，起于累土

azure databricks中使用Unity Catalog 01--基础概念

先总结下

  1. unity catalog是databricks的数据治理解决方案，他提供了统一的元数据管理、权限访问控制、数据审核、数据质量、数据血缘、数据发现、数据共享等功能。

  2. 数据血缘真的很不错，如果是一个新的用户，又是global的我强烈推荐您使用起来。

  3. 本人使用下来的感受：功能还是很强大，解决了以前权限集中管理、数据共享、数据血缘等问题，但是目前限制还是很多（看最后的限制一节），在新环境下使用是可以的，但是如果想从原来的workspace升级过来，尤其是使用了很多权限管理的、涉及ML、streaming的cluster就要详细看看限制带来的影响。权限切换成unity catalog也是要考虑的。如果数据治理有其它的产品了，只是想解决统一元数据的问题，我建议可以使用external hive metadata，后面我会写一篇来介绍和实操。

  4. 如果不启用凭据传递，目前还不能使用init script安装一些扩展的python pkg或者jar包，Libraries也不行，原厂说未来会解决的。目前要不启用凭据传递，要不就access mode改成Single user模式。如果一定要选一个我还是选择启用凭据传递，因为Single user只能选择的那个账户登录才能使用cluster，显然这不友好。凭据传递就要注意要去掉以前的那些配置spark config或者cluster config中的账号配置或者服务主体访问配置之类的才行，还要创建一个组将用户放入组，再给组添加到blob的对应角色（通常都是“存储 Blob 数据参与者”）。

  5. 启用凭据传递还有很多限制，使用前都要好好规划下，一般都是用来做多用户查询比较合适，不适合ADF调度。使用 Azure Active Directory 凭据传递访问 Azure Data Lake Storage - Azure Databricks | Microsoft Learn

为什么数据治理非常重要

数据治理是确保数据带来价值并支持业务战略的监督过程。数据治理封装了为安全管理组织内的数据资产而实现的策略和做法。随着数据的数量和复杂性不断增加，越来越多的组织正在关注数据治理以确保实现核心业务成果：

  • 以一致和高质量的数据作为分析和机器学习的基础。

  • 缩短获得见解的时间。

  • 数据民主化，即让组织中的每个人都能够做出数据驱动的决策。

  • 对HIPAA、FedRAMP、GDPR 或 CCPA等行业法规的风险保障与合规性支持。

  • 成本优化，例如通过阻止用户启动大型群集并制定昂贵 GPU 实例的使用准则来实现。

良好的数据治理解决方案是什么样的？

数据驱动型公司通常会在lakehouse上构建用于分析的数据体系结构。lakehouse是一种体系结构，可直接在数据湖中存储的大量数据上实现高效且安全的数据工程、机器学习、数据仓库和商业智能。lakehouse的数据治理提供以下关键功能：

  • 统一目录：除了每个数据对象的元数据之外，统一目录还存储所有数据、ML模型和分析项目。统一目录还混合了来自其他目录的数据，例如现有的Hive元存储。

  • 统一数据访问控制：跨所有数据资产和所有云的单个统一权限模型。这包括个人身份信息 (PII) 的基于属性的访问控制 (ABAC)。

  • 数据审核：数据访问通过警报和监视功能进行集中审核，从而促进问责。

  • 数据质量管理：使用内置的质量控制、测试、监视和强制执行进行可靠的数据质量管理，从而确保下游BI、分析和机器学习工作负载获得准确和有用的数据。

  • 数据血缘：通过数据血缘，可获得端到端的可见性，了解lakehouse中的数据如何从源流向使用端。

  • 数据发现：利用简单的数据发现功能，数据科学家、数据分析师和数据工程师可以快速发现和引用相关数据，并缩短实现价值的时间。

  • 数据共享：数据可以跨云和平台共享。

image-20230327160100021

image-20230327160122899

image-20230327160323799

数据治理和Azure Databricks

Azure Databricks 通过 Unity Catalog 和 Delta Sharing 提供集中的数据和 AI 治理。

Unity Catalog

Databricks Lakehouse 数据和 AI 的细化治理解决方案。 它通过提供一个集中管理和审核数据访问的位置，来帮助简化数据的安全性和治理。

image-20230327160212368

Delta Sharing

由 Databricks 开发的开放协议，用于与其他组织或组织内的其他团队进行安全数据共享，而不论他们使用哪种计算平台。

image-20230327160019298

什么是unity catalog

Unity Catalog，它是 Lakehouse 的 Azure Databricks 数据治理解决方案

在 Unity Catalog 中，管理员和数据专员在 Azure Databricks 帐户中的所有工作区集中管理用户及其对数据的访问。 不同工作区中的用户可以共享对相同数据的访问权限，具体取决于 Unity Catalog 中集中授予的权限。

with-unity-catalog

Unity Catalog 的主要功能包括：

定义一次，处处安全：Unity Catalog提供了一个单独的地方来管理适用于所有工作区和人物角色的数据访问策略。 符合标准的安全模型：Unity Catalog的安全模型基于标准ANSI SQL，允许管理员使用熟悉的语法在目录、数据库（也称为模式）、表和视图级别授予现有数据湖的权限。 内置审计和血缘：Unity Catalog自动捕获用户级审计日志，记录对数据的访问。Unity Catalog还捕获血缘数据，跟踪数据资产是如何在所有语言和人物角色中创建和使用的。 数据发现：Unity Catalog允许您标记和记录数据资产，并提供搜索界面来帮助数据消费者查找数据。

Unity Catalog 对象模型

object-model

在 Unity Catalog 中，主要数据对象的层次结构从元存储流向表：

  • Metastore：元数据的顶级容器。 每个元存储都公开了一个用于组织数据的三级命名空间 (catalog.schema.table)。

  • Catalog：用于组织数据资产的对象层次结构的第一层。

  • Schema：也称为数据库，是对象层次结构的第二层，包含表和视图。

  • Table/View：对象层次结构的最底层，可以是外部表（存储在所选云存储中的外部位置），也可以是托管表（存储在你为 Azure Databricks 专门创建的云存储中的存储容器中）。 还可以从表中创建只读视图。

uc-catalogs

Metastores

元存储是 Unity Catalog 中对象的顶级容器。它存储数据资产（表和视图），以及用于管理对数据资产的访问的权限。 Databricks帐户管理员可以为他们操作的每个区域创建一个元存储，并将其分配给同一区域的Databricks工作区。如果一个工作区想要使用 Unity Catalog，它必须附加 Unity Catalog 元存储。

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

此元存储与Databricks工作区中包含的Hive元存储不同，后者尚未为Unity Catalog启用。如果您的工作空间包括一个遗留的Hive元存储，那么该元存储中的数据仍将与Unity Catalog中定义的数据可以一起被访问，只是单独在一个名为Hive_metastore的目录中。请注意，hive_metastore目录不由Unity catalog管理，也不受益于与Unity目录中定义的目录相同的功能集。

Catalog

目录是 Unity Catalog 三级命名空间的第一层。 它用于组织数据资产。 用户可以查看分配了USAGE数据权限的所有目录。

Schema

架构（又称数据库）是 Unity Catalog 三级命名空间的第二层。 架构组织表和视图。 若要访问（或列出）架构中的表或视图，用户必须拥有对架构及其父目录的 USAGE 数据权限，以及对表或视图的 SELECT 权限。

Table/View

位于 Unity Catalog 三级命名空间的第三层。 它包含数据行。 若要创建表，用户必须对架构具有 CREATE 和 USAGE 权限，并对其父目录具有 USAGE 权限。 若要查询表，用户必须对表具有 SELECT 权限，并对其父架构和目录具有 USAGE 权限。

表可以是托管表，也可以是外部表。

视图是从元存储中的一个或多个表和视图创建的只读对象。 可以从多个架构和目录中的表和其他视图创建视图。 可以创建动态视图以启用行级和列级权限。

托管表

是在 Unity Catalog 中创建表的默认方式。 这些表存储在创建元存储时配置的根存储位置。它们使用Delta表格式。

删除托管表时，将于 30 天内从存储位置上删除其对应物理数据文件。

外部表

是其数据存储在根存储位置之外的表。 仅当需要直接访问 Azure Databricks 群集或 Databricks SQL 仓库外部的数据时，才使用外部表。

删除外部表时，Unity Catalog 不会删除基础数据。 你可以管理外部表的权限，并以与托管表相同的方式在查询中使用它们。

支持的数据文件格式

托管表必须使用 delta 表格式。

外部表可以使用 delta、CSV、JSON、avro、parquet、ORC 或 text。

存储凭据和外部位置

为了管理对外部表的基础云存储的访问，Unity Catalog 引入了以下对象类型：

存储凭据：封装提供对云存储的访问权限的长期凭据。 例如，可以访问 Azure Data Lake Storage Gen2 容器的 Azure 托管标识。 外部位置：包含对存储凭据和云存储路径的引用。

Unity Catalog 的管理员角色

管理 Unity Catalog 需要以下管理员角色：

帐户管理员（Account Admin）

可以管理标识、云资源以及工作区和 Unity Catalog 元存储的创建。

帐户管理员可以为 Unity Catalog 启用工作区。 他们可以授予工作区和元存储管理员权限。

元存储管理员（Metastore Admin）

可以管理元存储中所有安全对象的权限和所有权，例如谁可以创建目录或查询表。

创建 Unity Catalog 元存储的帐户管理员将成为初始元存储管理员。元存储管理员还可以选择将此角色委派给另一个用户或组。 建议将元存储管理员分配给组，在这种情况下，该组的任何成员都可以获得元存储管理员的权限。

image-20230327150422295

image-20230327150850298

工作区管理员

可以将用户添加到 Azure Databricks 工作区，为他们分配工作区管理员角色，并管理对工作区中对象和功能的访问权限，例如创建群集和更改作业所有权的能力。

也可以通过unity catalog来添加用户、组对于workspace的访问权限

image-20230327151152743

image-20230327151238624

Unity Catalog中的数据权限

在 Unity Catalog 中，默认情况下数据是安全的。 最初，用户无权访问元存储中的数据。 访问权限可由元存储管理员、对象所有者或包含对象的目录或架构的所有者授予。 Unity Catalog 中的安全对象是分层的，特权是向下继承的。

你可以使用数据资源管理器、SQL 命令或 REST API 分配和撤销权限。

Unity Catalog的集群访问模式

若要访问 Unity Catalog 中的数据，必须为群集配置正确的访问模式。 默认情况下，Unity Catalog 是安全的。 如果群集未配置支持 Unity Catalog 的访问模式之一（即“共享”或“单用户”），则该群集将无法访问 Unity Catalog 中的数据。

image-20230327151546442

Unity Catalog的数据血缘(lineage)

可以使用 Unity Catalog，通过以任何语言对 Azure Databricks 群集或 SQL 仓库执行的查询来捕获运行时数据血缘。血缘捕获级别低至列，包括与查询相关的笔记本、工作流和仪表板。

uc-expanded-lineage-graph

uc-lineage-column-lineage

帐户组(account groups)与本地工作区组(workspakce groups)之间的区别

虽然在工作区级别创建的用户和服务主体会自动同步到帐户，但在工作区级别创建的组不会。 相反，Azure Databricks 具有帐户组和工作区本地组的概念。

帐户组(account groups)

只能由帐户管理员使用帐户级接口创建。 帐户管理员可以将这些组分配到工作区，并在工作区中为它们配置数据访问，前提是这些工作区使用联合身份验证。

工作区本地组(workspakce groups)

只能由工作区管理员使用工作区级接口创建。 这些组在工作区管理控制台和帐户控制台的工作区“权限”选项卡上被标识为“工作区本地”。 不能将工作区本地组分配给其他工作区，也不能向它们授予对 Unity Catalog 元存储中数据的访问权限。

image-20230327153233577

Azure Databricks 建议使用帐户组而不是工作区本地组。 必须启用工作区的联合身份验证才能使用帐户组。 如果在现有工作区中启用联合身份验证，可以并行使用帐户组和工作区本地组，但 Azure Databricks 建议将工作区本地组转换为帐户组，以便利用通过 Unity Catalog 的集中式工作区分配和数据访问管理

Unity Catalog 具有以下限制

如果群集在低于 11.1 的 Databricks Runtime 版本上运行，则可能存在其他限制。 Unity Catalog 正式版依赖于使用 Databricks Runtime 11.1 或更高版本

  • Scala、R 和使用机器学习运行时的工作负载仅在使用单用户访问模式的群集上受支持。 这些语言的工作负载不支持使用动态视图（出于行级或列级安全性考虑）。

  • 将 Unity Catalog 用作克隆的源或目标时，不支持浅表克隆。

  • Unity Catalog 表不支持 Bucket。 如果运行尝试在 Unity Catalog 中创建 Bucket 表的命令，则会引发异常。

  • 如果某些群集访问 Unity Catalog，而其他群集不访问，则从多个区域的工作区写入相同的路径或 Delta Lake 表可能会导致性能不可靠。

  • Delta 表支持对外部表进行分区，但对于任何其他数据源类型则不支持分区。

  • 仅 Delta 表支持将 DataFrame 写入 Unity Catalog 的覆盖模式，不支持其他文件格式。 用户必须对父架构拥有 CREATE 特权，并且必须是现有对象的所有者，或者对该对象拥有 MODIFY 特权。

  • 流式处理目前具有以下限制：

    • 使用共享访问模式的群集中不支持流式处理。 对于流式处理工作负载，必须使用单用户访问模式。

    • StreamingQueryListener 无法使用凭据或与 Unity Catalog 管理的对象交互。

    • Databricks Runtime 11.3 及更低版本不支持异步检查点。

    • 在 Databricks Runtime 11.2 及更低版本上，在通用群集或作业群集上持续超过 30 天的流式处理查询将引发异常。 对于长时间运行的流式处理查询，请配置自动作业重试 或使用 Databricks Runtime 11.3 及更高版本。

  • 当前不支持从增量实时表管道引用 Unity Catalog 表。

  • 单用户群集支持 Spark-submit 作业，但共享群集则不支持此类作业。

  • 共享群集不支持 Python UDF。

  • 以前在工作区中创建的组（即工作区级别的组）不能在 Unity Catalog GRANT 语句中使用。 这是为了确保跨工作区的组视图保持一致。 若要在 GRANT 语句中使用组，请在帐户级别创建组，并更新主体或组管理的任何自动化（例如 SCIM、Okta 和 AAD 连接器以及 Terraform），用于引用帐户终结点，而不是工作区终结点。

资源配额

Unity Catalog 对所有安全对象强制实施资源配额。限制在整个 Unity Catalog 中都遵循相同的分层组织。 如果预期超过这些资源限制，请联系 Azure Databricks 客户代表。

下面的配额值是相对于 Unity Catalog 中的父对象表示的，例如一个schema下可以有10000个table

Object Parent Value

table

schema (database)

 10000
schema catalog 10000
catalog metastore 1000
storage credentials metastore 200
external locations metastore 500
functions schema 10000
posted @ 2023-03-28 01:13  John.Xiong  阅读(1566)  评论(0)  编辑  收藏  举报