📚 课程目录第1章课程导入与全景认知

1. 课程导入与全景认知

在数据平台建设中，Snowflake 常被当作“高性能数仓”来使用：加载快、查询快、弹性扩缩容方便。但当数据表从几十张增长到几千张、从单一业务扩展到多域共享时，真正拖慢团队的往往不是算力，而是数据不可信与元数据不可见。数据质量问题会让下游报表、特征工程和经营决策反复返工；元数据缺失则让分析师找不到表、说不清口径、无法判断一次变更会影响谁。本课程的目标，是把 Snowflake 中的数据质量与元数据治理从“零散经验”变成“可设计、可落地、可验证”的工程能力。

一、价值定位：为什么在 Snowflake 上要同时做质量与元数据

Snowflake 的架构特点决定了治理方式。它采用存储与计算分离，计算层由 Virtual Warehouse 提供，数据对象集中在 Database → Schema → Table/View 的命名空间中，并天然带有 INFORMATION_SCHEMA、ACCOUNT_USAGE 等系统视图。这意味着：一方面，质量规则可以借助 SQL 与调度能力直接落在仓库内执行；另一方面，元数据不必完全依赖外部工具采集，Snowflake 自身就提供了对象、列、血缘、访问历史、查询历史等可查询的元数据来源。

但“能查到”不等于“治理好”。数据质量关注的是数据本身是否符合预期，例如订单金额不能为负、主键不能重复、每日分区不能断档；元数据治理关注的是数据资产是否被正确描述、分类、追踪和管控，例如表负责人是谁、字段业务含义是什么、敏感级别如何、上下游依赖怎样。两者是互补关系：没有元数据，质量规则难以定位责任人和影响范围；没有质量结果，元数据中的“可信度”标签就只是空壳。

核心判断：如果一张表没有负责人、没有口径说明、没有质量校验，那么它在 Snowflake 中即使查询性能再好，也不能算作“可用的数据资产”。

二、核心概念地图

本课程会围绕四条主线展开。第一条是数据质量维度：完整性、唯一性、有效性、一致性、及时性、准确性。第二条是质量规则与执行：在 Snowflake 中用 SQL 定义断言，通过 Task、Stream、Dynamic Table 或外部调度触发，并把结果写入审计表。第三条是元数据分层：技术元数据（库、表、列、类型、血缘）、业务元数据（指标、口径、负责人、SLA）、操作元数据（查询历史、加载历史、任务运行）。第四条是治理闭环：发现异常 → 定位影响 → 通知责任人 → 修复 → 复验 → 更新元数据与信任等级。

为了便于建立整体认知，下面用一张关系图把“数据对象、质量规则、元数据、治理动作”之间的连接关系表示出来。图中左侧是 Snowflake 中的真实对象，中间是质量与元数据的采集/定义层，右侧是治理输出与消费方。

三、学习路径：从单表校验到跨域治理

课程按“先能跑、再能管、后能规模化”的顺序推进。第一阶段聚焦单表质量校验：学会用 SQL 写出可复用的断言，把结果写入审计表，并用 Task 定时执行。第二阶段进入元数据采集：从 INFORMATION_SCHEMA.COLUMNS、ACCOUNT_USAGE.QUERY_HISTORY、ACCESS_HISTORY 中提取对象、列、访问与血缘信息，形成资产目录的基础数据。第三阶段做治理闭环：把质量结果、负责人、SLA、敏感标签关联起来，形成看板、告警和影响分析。第四阶段面向规模化：多域、多环境、多角色的权限与策略设计，以及成本与性能的平衡。

需要强调的是，Snowflake 中的治理不是“额外加一层工具”，而是尽量复用仓库自身能力。例如，质量规则可以直接写成视图或存储过程；元数据可以物化到治理库中；血缘可以从查询历史中解析。这样做的优点是链路短、权限统一、成本可控，缺点是需要在 SQL 和调度层面做较多设计。本课程会给出可执行的示例，而不是停留在概念层。

四、实战环境准备

为了让后续章节可以直接动手，建议准备一个独立的 Snowflake 试用账户或开发账户，并创建以下对象。示例中使用角色 DQ_GOVERNANCE_ROLE、仓库 DQ_WH、数据库 DQ_GOV_DB，你可以按实际命名调整。

-- 1. 创建角色与仓库（示例参数，按需调整）
CREATE ROLE IF NOT EXISTS DQ_GOVERNANCE_ROLE;
CREATE WAREHOUSE IF NOT EXISTS DQ_WH
  WAREHOUSE_SIZE = 'XSMALL'
  AUTO_SUSPEND = 60
  AUTO_RESUME = TRUE;

-- 2. 创建治理数据库与模式
CREATE DATABASE IF NOT EXISTS DQ_GOV_DB;
CREATE SCHEMA IF NOT EXISTS DQ_GOV_DB.RULES;      -- 质量规则定义
CREATE SCHEMA IF NOT EXISTS DQ_GOV_DB.AUDIT;      -- 质量结果审计
CREATE SCHEMA IF NOT EXISTS DQ_GOV_DB.META;       -- 元数据快照
CREATE SCHEMA IF NOT EXISTS DQ_GOV_DB.SAMPLE;     -- 示例业务数据

-- 3. 授权
GRANT USAGE ON WAREHOUSE DQ_WH TO ROLE DQ_GOVERNANCE_ROLE;
GRANT ALL ON DATABASE DQ_GOV_DB TO ROLE DQ_GOVERNANCE_ROLE;
GRANT ROLE DQ_GOVERNANCE_ROLE TO USER <你的用户名>;

接着创建一张示例订单表，用于后续质量规则演示。字段和约束如下：订单号唯一、金额非负、状态在枚举范围内、创建时间不能晚于当前时间。

CREATE OR REPLACE TABLE DQ_GOV_DB.SAMPLE.ORDERS (
  order_id      STRING        NOT NULL,
  customer_id   STRING        NOT NULL,
  order_amount  NUMBER(12,2)  NOT NULL,
  order_status  STRING        NOT NULL,
  created_at    TIMESTAMP_NTZ NOT NULL,
  updated_at    TIMESTAMP_NTZ
);

INSERT INTO DQ_GOV_DB.SAMPLE.ORDERS VALUES
('O1001','C001', 199.00,'PAID',   '2024-05-01 10:00:00','2024-05-01 10:05:00'),
('O1002','C002',  89.50,'PAID',   '2024-05-01 11:20:00','2024-05-01 11:20:00'),
('O1003','C001',  -5.00,'PAID',   '2024-05-02 09:10:00','2024-05-02 09:10:00'),
('O1004','C003', 320.00,'UNKNOWN','2024-05-02 14:00:00','2024-05-02 14:00:00'),
('O1004','C004',  50.00,'PAID',   '2024-05-03 08:30:00','2024-05-03 08:30:00');

这五行示例数据中已经埋入了三类典型问题：O1003 金额为负，O1004 状态不在允许枚举内，O1004 订单号重复。后续章节会围绕这些数据写出可执行的质量规则，并把结果写入审计表。你可以先用下面的查询确认问题确实存在：

SELECT order_id, COUNT(*) AS cnt
FROM DQ_GOV_DB.SAMPLE.ORDERS
GROUP BY order_id
HAVING COUNT(*) > 1;

SELECT order_id, order_amount
FROM DQ_GOV_DB.SAMPLE.ORDERS
WHERE order_amount < 0;

SELECT order_id, order_status
FROM DQ_GOV_DB.SAMPLE.ORDERS
WHERE order_status NOT IN ('PAID','PENDING','CANCELLED','REFUNDED');

建议在开发环境中使用 XSMALL 仓库并设置 60 秒自动挂起，避免练习过程中产生不必要的计算费用。所有示例数据均为教学构造，不代表真实业务数据。

五、本课程的学习方法

每章都会围绕一个可验证的目标展开：要么能写出可运行的 SQL，要么能产出可复用的元数据表，要么能形成可判断的治理结论。学习时建议按“先跑通示例 → 再替换成自己的表 → 最后固化成模板”的节奏推进。遇到质量规则时，先问三个问题：这条规则检查哪个字段、失败时严重级别是什么、失败后通知谁。遇到元数据时，先问：这条元数据从哪个系统视图来、刷新频率是多少、谁负责维护。把这两个问题养成习惯，后续的治理设计会清晰很多。

最后需要建立的一个认知是：数据质量与元数据治理不是一次性项目，而是持续运行的能力。规则会随业务变化而调整，元数据会随模型演进而更新，责任人和 SLA 也会变化。课程的目标不是给你一套永远不变的配置，而是让你掌握在 Snowflake 上设计、执行和迭代这套能力的方法。