1. 课程导入与体系总览

在数据平台从“能跑通”走向“可信任”的过程中，数据质量与治理不是附加项，而是决定数据资产能否被业务持续消费的前提。Databricks 作为湖仓一体平台，把数据存储、计算引擎、元数据、权限、血缘与质量监控集中在同一套体系内，这让我们可以用更少的拼接工具，构建一条从数据接入到可信消费的完整链路。本课程围绕这条链路展开，目标是让学习者既能理解治理体系的设计逻辑，也能在 Databricks 上落地可执行的质量规则、权限模型与监控机制。

一、核心概念：质量、治理与可观测性的边界

数据质量关注数据本身是否满足使用要求，常见维度包括完整性、唯一性、一致性、准确性、及时性和有效性。例如，订单表的 order_id 不应为空且应唯一，amount 不应为负数，event_time 不应晚于当前时间。这些判断最终会转化为可执行的规则，并在数据写入或更新时被检查。

数据治理的范围更大，它回答“谁可以访问什么数据、数据从哪里来、变更如何被追踪、责任如何划分”。在 Databricks 中，治理能力主要落在 Unity Catalog 上：它统一管理元数据、权限、血缘和审计。质量规则、权限策略、标签分类都围绕同一份元数据展开，避免了“质量在 A 工具、权限在 B 工具、血缘在 C 工具”的割裂。

数据可观测性则是治理与质量的运行态延伸。它不仅看单条规则是否通过，还看趋势：某张表的空值率是否在上升、某条链路是否延迟、某个字段的分布是否发生漂移。三者关系可以概括为：治理定义边界与责任，质量定义标准与检查，可观测性提供持续反馈。

二、业务价值：从“有数据”到“敢用数据”

很多团队并不缺数据，缺的是对数据的信任。没有质量与治理体系时，常见代价包括：报表口径不一致导致决策反复、下游任务因脏数据失败、敏感字段被越权访问、问题发生后无法快速定位影响范围。Databricks 体系的价值在于把这些代价前置为可管理的工程能力。

具体而言，质量规则可以在数据写入阶段拦截明显异常，减少脏数据向下游扩散；Unity Catalog 的权限与血缘可以让“谁用了这张表、改这张表会影响谁”变得可查；审计日志与标签体系则让合规检查从人工盘点变为可查询的证据链。对业务而言，最终收益是更短的排障时间、更稳定的报表口径和更可控的合规风险。

三、整体架构：一条从接入到消费的治理链路

下图给出本课程贯穿始终的体系总览。数据从外部源接入 Bronze 层，经过清洗与校验进入 Silver 层，再按主题聚合为 Gold 层供业务消费。Unity Catalog 作为控制面，横向覆盖元数据、权限、血缘与审计；质量规则在关键节点执行，结果写入监控表并触发告警。这个结构不是唯一实现，但它清晰表达了“数据流”与“控制流”的分工。

图中上半部分是数据流，下半部分是控制面与质量监控。需要特别注意的是，控制面并不是“旁路系统”，它直接约束数据流中的每一次读写：当 Silver 层任务读取 Bronze 表时，权限检查、血缘记录和审计日志同时发生。质量规则则像检查站，既可以在写入时拦截，也可以在调度后批量评估。

四、学习路径：从单表规则到体系化治理

本课程按“先建立标准，再落地检查，最后形成闭环”的顺序推进。建议的学习路径如下：

• 第一阶段：概念与架构。理解质量维度、治理边界和 Databricks 各组件的职责，能画出自己团队的治理链路草图。
• 第二阶段：质量规则落地。从单表开始，定义非空、唯一、范围、引用完整性等规则，并选择写入时校验或调度后校验。
• 第三阶段：权限与血缘。使用 Unity Catalog 建立 Catalog/Schema/Table 层级，配置 GRANT，理解行级与列级过滤，并利用血缘做影响分析。
• 第四阶段：监控与闭环。把质量结果写入监控表，设置阈值告警，形成“发现—定位—修复—复盘”的闭环。
• 第五阶段：体系化与规模化。将规则模板化、标签化，覆盖更多表和链路，并考虑成本、性能与合规要求。

五、一个可参考的起步示例

假设我们有一张 Silver 层的订单表 silver.orders，字段包括 order_id、customer_id、amount、order_time。起步阶段可以先定义三条规则：order_id 非空且唯一；amount 大于 0；order_time 不晚于当前时间。下面是一个用 SQL 表达的质量检查示例，结果写入监控表 monitor.dq_results：

INSERT INTO monitor.dq_results
SELECT
  'silver.orders' AS table_name,
  'order_id_not_null' AS rule_name,
  COUNT(*) AS total_rows,
  SUM(CASE WHEN order_id IS NULL THEN 1 ELSE 0 END) AS failed_rows,
  CURRENT_TIMESTAMP() AS checked_at
FROM silver.orders;

INSERT INTO monitor.dq_results
SELECT
  'silver.orders',
  'amount_positive',
  COUNT(*),
  SUM(CASE WHEN amount <= 0 THEN 1 ELSE 0 END),
  CURRENT_TIMESTAMP()
FROM silver.orders;

执行后，如果 failed_rows 大于 0，说明存在异常记录。此时可以进一步查询异常明细，定位是上游接入问题还是清洗逻辑遗漏。这个示例虽然简单，但它已经包含了质量治理的核心动作：定义规则、执行检查、记录结果、判断异常。后续章节会在此基础上逐步引入更复杂的规则、权限模型和监控机制。