2. Databricks平台数据架构基础

在 Databricks 上谈数据质量与元数据治理，必须先厘清四层对象之间的“职责边界”：Lakehouse 是整体架构形态，Delta Lake 是承载数据的存储与事务层，Unity Catalog 是跨工作区的统一元数据与权限控制面，而数据治理则是运行在这三者之上的策略与流程。很多团队在排查“为什么表查不到”“为什么质量规则没生效”时，往往把问题归错层，导致修复方向偏离。本节用一张分层关系图先建立定位，再逐层说明各自能做什么、不能做什么。

Lakehouse：不是“湖 + 仓”的简单拼接

Lakehouse 的核心主张是：数据以开放格式（Parquet + 事务日志）存放在低成本对象存储上，同时通过事务层获得数仓级别的可靠性。在 Databricks 中，这意味着同一份 Delta 表既能被 SQL Warehouse 做 BI 查询，也能被 Spark 做 ETL，还能被 ML 运行时读取特征。对数据质量而言，Lakehouse 带来的关键变化是：质量检查不再只能发生在入库前的 ETL 阶段，而是可以在表级别持续进行，因为表本身具备版本和事务语义。

需要明确的边界是：Lakehouse 本身不定义质量规则，它只提供“可被规则作用的对象”。如果一张表没有注册到 Unity Catalog，或者没有启用 Delta 格式，那么后续的约束、监控、血缘都无从附着。

Delta Lake：质量规则的物理落点

Delta Lake 是质量约束真正生效的地方。它提供三类与数据质量直接相关的机制：

• 表约束：在 Delta 表上定义 NOT NULL 和 CHECK 约束，写入时自动校验，违反则事务失败。例如 ALTER TABLE silver.orders ADD CONSTRAINT valid_amount CHECK (amount >= 0)。
• 变更数据捕获（CDF）：开启 delta.enableChangeDataFeed = true 后，可以读取行级变更记录，用于下游质量比对和增量校验。
• 时间旅行：通过 VERSION AS OF 或 TIMESTAMP AS OF 回溯历史快照，当质量异常发生时，可以对比异常版本与正常版本的差异行。

一个常见的实操判断是：如果质量规则是“行级硬约束”（如主键非空、金额非负），应优先用 Delta 约束；如果是“统计级软监控”（如空值率突增、分布漂移），则应放在治理层的监控工具中，而不是硬编码为约束，否则会阻塞正常写入。

Unity Catalog：治理的“户口本”与“门禁”

Unity Catalog 解决的是“谁、在哪个工作区、能访问哪张表、这张表是什么”的问题。它用 catalog.schema.table 三级命名空间统一了原本分散在 Hive Metastore 和工作区本地的元数据。对数据治理而言，Unity Catalog 提供三个不可替代的能力：

• 统一权限模型：GRANT SELECT ON TABLE 等语句在账户级生效，跨工作区一致，避免“同一个表在不同工作区权限不同”的治理盲区。
• 自动血缘：表与表、列与列之间的读写关系被自动记录，质量问题的根因可以沿血缘向上游追溯。
• 标签与注释：通过 COMMENT 和 TAG 为表和列附加业务含义、敏感级别、责任人，这些元数据是质量规则配置的输入。

四层之间的因果链：一个排障视角

假设业务反馈“昨天的订单表金额出现负数”。按四层定位：

1. 治理层：检查是否配置了金额非负的质量规则，规则是否处于启用状态，告警是否发出。
2. Unity Catalog 层：确认该表是否已注册、血缘上游是哪张源表、最近是否有权限变更导致异常写入路径被放开。
3. Delta Lake 层：用时间旅行对比异常版本与前一正常版本，定位是哪次 MERGE 或写入引入了负数；检查是否缺少 CHECK 约束。
4. Lakehouse 层：确认写入作业使用的计算集群和写入模式（batch 还是 streaming），是否存在并发写入未走事务路径的情况。

这个顺序的价值在于：先确认规则是否存在，再确认元数据是否完整，最后才查数据本身。很多团队一上来就查数据，结果发现规则根本没配，或者表根本没注册，排查成本被浪费在错误层级。

定位速查表