使用Unity Catalog在Databricks上实现数据治理

数据治理历来是数据工程中最不吸引人的部分。工程师们热衷于构建事物、设计可扩展的流水线、整理高质量的数据集，以及实现能够带来实际业务影响的机器学习模型。而治理则通常被视为繁文缛节，包括权限、审计日志、合规性检查和文档记录。它并不令人兴奋，而且很少被优先考虑，直到为时已晚。

这就是为什么在许多组织中，治理变成了事后才考虑的事项。团队将流水线投入生产，数据集不断增长，仪表盘成倍增加。业务用户每天依赖这些洞察，机器学习模型开始影响关键决策。但随后合规性要求就会出现：“谁在上个季度访问了客户电子邮件？"、“我们能否保证在此仪表盘中个人身份信息（PII）被屏蔽？"、“这个关键绩效指标（KPI）源自何处？“突然间，缺乏集中治理框架的问题暴露无遗。访问控制分散在Hive Metastore、云IAM和ML注册表中。血缘关系不完整，迫使工程师手动查阅日志。屏蔽规则不一致，通常使用脆弱的正则表达式实现，仅对部分数据有效。治理故事脆弱且被动，而非主动。

这正是Unity Catalog（UC）填补的空白。UC是Databricks的统一治理层，一个单一的控制平面，不仅管理数据，还管理跨SQL、机器学习甚至AI工作负载的元数据（血缘关系、策略、标签）。UC不是事后才添加治理，而是将其作为平台本身的一部分。

在本文中，我们将逐步介绍如何在熟悉的bakehouse数据集上部署UC，将访问和策略映射到组织内的不同用户组。到最后，您将看到Bakehouse数据如何能够：

由合适的人安全访问
在保护PII的同时保留分析价值
跨团队和地区自信地共享
通过完整的血缘关系进行端到端追踪

借助Unity Catalog，治理从减缓项目进度的负担转变为安全加速创新的基础。

步骤1：创建目录和模式

Unity Catalog的核心是一个简单但强大的理念：按照业务思考的方式组织数据，而不仅仅是数据库存储的方式。

Unity Catalog引入了一个3级命名空间，标准化了数据资产的引用方式：

1

<catalog>.<schema>.<table>

目录 - 最高级别的容器，通常代表业务领域或数据产品边界。
模式 - 目录内的逻辑分组，通常与功能领域对齐（例如，评论、销售、供应商）。
表 - 受治理的数据集本身，以Delta格式存储，但通过Unity Catalog策略进行管理。

1
2
3
4
5
6
7


CREATE CATALOG bakehouse;

CREATE SCHEMA bakehouse.reviews;

CREATE SCHEMA bakehouse.sales;

CREATE SCHEMA bakehouse.supplier;

步骤2：注册数据表

目录和模式准备就绪后，下一步是将现有数据集纳入Unity Catalog治理。您可以通过在目录中注册表来实现这一点。对于Bakehouse，这包括客户反馈、销售交易和供应商发票。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


CREATE TABLE bakehouse.reviews.customer_feedback
USING DELTA
AS SELECT * FROM samples.bakehouse.media_customer_reviews;

CREATE TABLE bakehouse.sales.transactions
USING DELTA
AS SELECT * FROM samples.bakehouse.sales_transactions;

CREATE TABLE bakehouse.supplier.vendors
USING DELTA
AS SELECT * FROM samples.bakehouse.sales_franchises;

在这里：

目录（bakehouse）代表Bakehouse数据的整个领域。
模式（评论、销售、供应商）反映了该数据的功能划分。
表存储实际的受治理资产。

步骤3：定义用户组

与其为单个用户微观管理权限，不如定义反映实际工作家族或功能的组。这些组直接映射到Unity Catalog中的主体，然后可以在SQL语句中使用。好处巨大：新团队成员在加入组后自动受到治理，而离职只需将其从身份提供商（IdP）中的该组移除即可简单完成。治理既关乎人也关乎数据。

Unity Catalog与您的身份提供商（Azure AD、Okta、IAM）集成，以强制执行基于角色的访问控制，我们可以创建组来基于工作家族管理访问。

对于Bakehouse，我们定义了四个关键组：

分析师 - 查询数据，但PII被屏蔽。
数据科学家 - 构建模型，需要完整的评论文本。
财务 - 访问原始销售和供应商数据。
合规 - 跨所有领域的审计可见性。

转到设置 → 身份和访问 → 创建上述组。

组创建后，在每个组的权利中启用工作空间。

组链接到工作空间后，我们可以基于模式和表授予组访问权限。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


GRANT SELECT ON TABLE bakehouse.reviews.customer_feedback TO `analyst_group`;

GRANT SELECT ON SCHEMA bakehouse.reviews TO `ds_group`;

GRANT SELECT ON TABLE bakehouse.sales.transactions TO `ds_group`;

GRANT SELECT ON SCHEMA bakehouse.sales TO `finance_group`;

GRANT SELECT ON SCHEMA bakehouse.supplier TO `finance_group`;

GRANT SELECT ON CATALOG bakehouse TO `compliance_group`;

步骤4：应用细粒度安全

Unity Catalog支持列屏蔽和行过滤器，支持按角色组进行访问。

为分析师屏蔽客户电子邮件：

1
2
3
4
5
6
7
8


CREATE OR REPLACE VIEW bakehouse.reviews.customer_feedback_masked AS
SELECT
 *,
 CASE
   WHEN is_account_group_member('analyst_group') THEN '[MASKED]'
   ELSE review
 END AS customer_email_masked
FROM bakehouse.reviews.customer_feedback;

步骤5：血缘关系和元数据

现在我们已创建Bakehouse目录并注册了我们的模式和表，下一步是在Catalog Explorer中探索它们。这是Unity Catalog开始展示其真正力量的地方；它不仅仅是存储表，而是在一个地方使数据和元数据易于发现和治理。

当您在Databricks UI中浏览Catalog Explorer时，您会注意到每个表都带有一套丰富的元数据。这包括技术细节，如列名、数据类型、所有者和创建历史，以及帮助团队理解数据集用途的描述。Unity Catalog的新功能是这些描述也可以是AI驱动的——自动生成表包含内容的人类可读解释。

您将发现的另一个关键功能是Lineage选项卡。这为您提供了一个数据在平台中流动的可视化地图，从摄取流水线到Delta表，通过转换和连接，一直到下游的仪表盘或机器学习模型。

结论

Unity Catalog通过统一数据（表、模型、文件）和元数据（权限、血缘关系、分类和策略），将数据视为产品，确保每个数据集在组织内可发现、可信赖且可消费。

在Bakehouse示例中，我们看到了评论、销售和供应商数据如何可以作为受治理的产品进行打包，每个产品都有明确的所有权、访问规则和内置保护措施，如屏蔽和行过滤器。分析师消费经过整理的评论，财务审计原始交易，合规监控血缘关系，所有这些都来自同一个治理层。