【Azure 架构师学习笔记】- Azure Databricks (5) - Unity Catalog 简介

发布时间:2024年01月08日

本文属于【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”(进入后有什么权限)都校验成功后这些对象就可以正常访问允许的数据。

在这里插入图片描述

小结

简单来说,UC 是一个统一的数据治理解决方案。它通过集中控制数据访问, 细粒度权限控制,自动化负载的血缘,跨组织的数据共享来保证Databricks中的数据资产得到控制和治理。

文章来源:https://blog.csdn.net/DBA_Huangzj/article/details/135332512
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。