【Azure 架构师学习笔记】- Azure Databricks (5)

本文主要是介绍【Azure 架构师学习笔记】- Azure Databricks (5) - Unity Catalog 简介，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

本文属于【Azure 架构师学习笔记】系列。
本文属于【Azure Databricks】系列。
接上文【Azure 架构师学习笔记】- Azure Databricks (4) - 使用Azure Key Vault 管理ADB Secret

前言

DataBricks Unity Catalog（UC）是一个统一的对数据资产治理的解决方案。它对所有数资产进行集中管理，搭配一系列数据治理框架和扩展的审计功能。
还有一种描述：UC 是对data lake上的数据展示进行细粒度数据治理的解决方案。它帮助简化安全性，同时对数据治理提供一个集中区域进行统一的控制访问和审计访问。

出现的原因

Databricks已经成为很普遍的数据平台，用于存储和处理数据，在满足这种功能性之后，需要考虑现今流行的一些方向：发现和治理。

组件

UC 目前由4大部分组成：Data discovery， Governance， Lineage 和Sharing。

Data discovery

通过搜索界面，可以对元数据进行结构化组织。通过对登陆用户的授权，确保搜索功能在元数据层面的安全性。

Data Governance

UC 被设计为对所有数据资产如文件，表，试图，dashboard等都可以通过一个中央存储库来完成搜索和发现。借助data governance 框架和扩展的审计日志，把所有对数据存储的操作存放在Databricks 帐户中。

Data Lineage

数据血缘在近几年出现得越来越频繁，也意味着越来越重要，它提供了企业数据流的关键信息，通过检查数据血缘，可以减少后续低质量数据的流入，保证企业数据的质量。
想象一个场景，当一个数据表中的列，是由多个数据源的数据组合而成，那么使用UC 里面的数据血缘就可以可视化展现这个数据流。

Data Sharing

过去的数据共享缺乏足够的监控，通过UC 内置的数据共享可以控制数据的流出和使用规范。这个功能也支持多平台，不同的云之间进行数据共享。
它是一个协议，为了安全地共享数据给其他组织，并且不需要在意这些组织使用什么平台而开发的。

UC 架构

从官网的架构图可以看出UC的对象模型使用了3级命名空间来满足不同类型的数据资产。
所有存储在UC 中内容都被称为“对象(Object)” 。一旦这些内容变成了对象，就可以通过选择性访问（Selective Access）来控制对象。
在这里插入图片描述
一个UC 可以链接到多个ADB workspace，如下图。

在这里插入图片描述

元存储

首先是元存储（Metastore），是一个特定云平台的数据目录，它通过添加一层抽象层使得用户可以更好地对数据资产分类。元存储作为一个数据资产的容器。ADB 的元存储是建立在Azure的存储帐户上。

大部分的信息如数据血缘中的查询，工作流等都存储在元存储中，不过审计日志（Audit log）则不同，它需要存储在其他地方以免元存储被删除后审计日志丢失。审计日志收集所有跟UC有关的时间如建、删、改元存储中的所有组件，包括元存储本身。

Metastore 是一个“数据库”，保存着关于数据的元数据，比如表的schema，数据相关文件的实际存储路径，文件格式等。
它需要手动创建。
Metastore因为有集中metastore 层，可以在多个ADB workspace里面共享。
数据本身，数据血缘，审计日志和其他关于数据得一切都被收集和存储在元存储中。

User management

如果一个项目中，用户，组和Service Principle有权限访问特定的workspace，可以把这些对象“导入”到UC 的User Management 中。每当这些对象要访问workspace的数据时，Workspace会先跟UC 校验这些对象是否有特定数据的访问权限。当“Authentication”（有没有访问权限）和“Authorization”（进入后有什么权限）都校验成功后这些对象就可以正常访问允许的数据。

在这里插入图片描述