学习指南: 第22部分。实践考核

模块「第22部分。实践考核」中第 3 / 5 节课

您正在未登录状态下查看课程。请登录，以保存进度并参加测试。

主题: 第 22 部分。实践考核：从规范到审阅者报告的 SDD Data 完整周期

难度等级: 中级

预计学习时间: 3–4 小时独立工作（包括编写规范、实现模型以及准备审阅者报告）

前置要求: 熟练掌握 SQL（聚合、窗口函数、JOIN）

了解 dbt 基础知识（模型、测试、sources、schema.yml）

理解 data contracts 和 SDD Data（Specification-Driven Development for Data，规格驱动数据开发）的概念

了解 PII（Personally Identifiable Information，个人可识别信息）处理原则

具备 git 和命令行使用经验

理解 staging、intermediate 和 mart 层之间的区别

学习目标: 批判性地评估数据规范，并在开始 SQL 实现前发现其中至少 10 个薄弱之处

将薄弱的需求文档（ТЗ）改写为完整的 SDD Data 规范，包含 grain、PII、contract、验收事实等章节

设计 dbt mart 层模型，保证 grain 为「每个键对应一行」并覆盖必需的测试

区分作者和审阅者角色，生成审阅者报告，将事实、假设和待确认事项分开

开展 SDD Data 回顾，并确定下一项功能（feature）的哪个阶段需要缩小或更详细地描述

概述: 课程的最终部分考查的不是对 dbt 语法的记忆，而是从规范到审阅者报告全程坚守数据产品承诺的能力。考核特意从一个糟糕的规范（例如「做一个有用的数据表」）开始，以检验学生是否能在编写 SQL 之前阻止这种薄弱的任务。考核由四个模块组成：12 个关于 SDD Data 术语理解的快速书面问题；在刻意薄弱规范中找出问题的任务；将其重写为正确的 SDD Data 格式；最后，使用完整证据包——SQL 之前的规范、测试、对 contract 的影响、审阅者报告和回顾——在 dbt 中实现 mart_customer_risk_summary 数据表。考核可以单独完成，也可以结对（作者 + 审阅者）完成——结对形式说明审阅是积极的工程角色，而不是被动阅读 SQL。工作按 25 分评分量表进行评估：21 分以上表示流程已准备好可迁移到真实的数据产品。

关键概念: Grain（粒度）：grain 的真相来源是模型规范或数据产品的 contract，而不是 SQL。Grain 规定输出数据表的每一行恰好对应一个业务对象（例如 customer_id）。grain 的任何变更都需要人工确认，即使 SQL 能够「干净」地执行。

Odps vs odcs：ODPS（Open Data Product Specification）描述产品及其消费者：数据表的目的、读者、回答的问题。ODCS（Open Data Contract Standard）是技术 contract：schema、SLA、格式、所有者、版本管理。SDD Data 同时使用两者：ODPS 用于产品语义，ODCS 用于技术承诺。

Dbt 测试与数据 contract 的区别：dbt 测试（not_null、unique、accepted_values、relationships）仅检查部分形式和部分数据属性。它们不能证明规范的完整性、指标计算方法的正确性，也不能替代产品 contract。dbt build 全绿只是卫生指标，不是承诺。

PII 政策与禁用字段：禁止的直接 PII 列表（姓名、email、电话、护照数据）必须记录在模型规范、AGENTS.md 和审阅者检查清单中。尽可能将其转换为 singular 测试或扫描最终 schema 的宏。这可以将政策从口号转变为可验证的产物。

Contract drift（合同漂移）：contract/规范与实际实现的模型之间的偏差。当进行「小改进」的作者悄悄更改 grain、添加字段、削弱测试或重命名实体时，就会出现漂移。在发布前捕获漂移是审阅者的首要任务。

破坏性变更：更改 grain、重命名或删除 contract 字段、更改指标语义、修改 PII 政策、修改 SLA。添加 nullable 列通常不是破坏性的，但如果下游系统将其解读为新的业务指标或它改变了 grain，则可能成为破坏性的。

作者与审阅者角色分离：审阅者应核查作者的假设，而不是为它们辩护。因此，作者和审阅者是不同的角色（在结对考核中为两个不同的学生）。审阅者不编辑作者的文件，而是准备一份对 contract、SQL、测试和流程分别给出意见的报告。

dbt build 能证明什么：dbt build 只能证明 DAG 的可执行性以及已声明的测试在当前数据上通过。它不能证明规范的完整性、方法的正确性、测试的充分性以及对消费者 contract 的符合性。

Schema manifest 与模型规范的区别：Schema Manifest（或 schema.yml）描述可观察的来源：实际的列、类型、测试。模型规范描述承诺的数据表：grain、消费者、方法、PII 政策、验收事实。它们相关，但不能互换。

Raw 数据与为绿色 build 而「修补」：Raw 层保留输入原样，不会为了 dbt build 全绿而「修补」。空值和 null 的语义在 staging 层解决，或在规范中明确说明。否则你只是把糟糕的数据质量隐藏在看似有效的模型背后。

验收事实（acceptance fact）：这是一个产物，必须包含四个要素：命令（SQL/dbt/手动步骤）、预期结果、执行状态以及确认人。没有这四个要素，「检查」就只是注释而已。

人工确认（human confirmation）：在更改 grain、PII 政策、SLA、contract 字段或风险指标计算方法时需要人工确认。这是 AI 助手不应自行决策、而应停下来请求确认的场景列表。

重要日期: 阶段 1 — SQL 之前的规范：在任何代码变更之前创建 specs/models/mart_customer_risk_summary.md 和验收事实

阶段 2 — 关于 contract 影响的备注：在实现之前确定该数据表是新产品还是对现有产品的扩展

阶段 3 — 实现与验证：编写 dbt 模型，更新 models/schema.yml，运行 dbt build --profiles-dir .

阶段 4 — 审阅者报告：结对审阅者运行 data-contract-review，并生成将事实、假设和确认分开的报告

阶段 5 — 回顾：填写回顾模板，评估规范的哪些部分描述得好以及哪些部分在 SQL 之后才需要澄清

练习题: 名称: 模块 1。关于 12 个 SDD Data 快速问题的书面回答

问题: 不借助 AI 助手书面回答以下 12 个问题：（1）grain 的真相来源是什么？（2）ODPS 与 ODCS 有什么区别？（3）为什么 dbt 测试不能替代数据 contract？（4）禁用 PII 列表应在哪里描述？（5）什么是合同漂移（contract drift）？（6）什么时候添加 nullable 列会成为破坏性变更？（7）为什么作者和审阅者应该是不同的角色？（8）dbt build 能证明什么，不能证明什么？（9）Schema Manifest 与模型规范有什么区别？（10）为什么不需要为了 dbt build 全绿而「修补」原始数据？（11）验收事实应包含什么内容？（12）什么时候需要人工确认？

解决方案: 参考答案：（1）模型规范或数据产品 contract，而不是 SQL。（2）ODPS 描述产品和消费者；ODCS 是技术 contract。（3）dbt 测试检查部分形式/数据，但不覆盖完整的产品语义。（4）记录在规范、AGENTS.md、审阅者检查清单中，尽可能记录在 singular 测试中。（5）contract/规范与实际模型之间的偏差。（6）如果它表现为新的业务指标、改变 grain 或影响下游 API。（7）审阅者应核查作者的假设，而不是为它们辩护。（8）dbt build 证明 DAG/测试的可执行性，但不证明规范的完整性。（9）manifest 描述可观察的来源；模型规范描述承诺的数据表。（10）raw 保留输入；空值和 null 的语义在 staging 层/规范中解决。（11）命令、SQL 或审阅者手动步骤、预期和状态。（12）更改 grain、PII 政策、SLA、contract 字段或风险方法时。

难度: 中级

名称: 模块 2。在薄弱规范中找出 10+ 个问题

问题: 给出一个刻意薄弱的规范。请分析它并找出所有薄弱之处。规范文本：「# 客户风险汇总。做一个有用的客户风险数据表。## 数据。使用 customer_360 和支付数据。添加所需的风险字段。## 验证。检查数据是否正确，且不含个人数据。」

解决方案: 逐步分析：1) 未指定数据表名称——无法在 contract 中引用该产物。2) 未指定消费者——无法验证其有用性。3) 未指定粒度（grain）——无法证明行的唯一性。4) 「有用的」——这个词不可验证，不是验收标准。5) 「所需字段」未定义——消费者无法理解他们将得到什么。6) 没有强制指标——无法测试。7) PII 政策未转化为基于禁用字段列表的测试——这只是口号，而不是检查。8) 未描述对 contract 的影响——无法理解这是扩展还是新产品。9) 没有以 source 形式列出输入模型——在 DAG 中无法验证。10) 没有 dbt 命令——没有可复现的检查。11) 没有供审阅者使用的手动事实——没有证据基础。12) 未说明这是新产品还是扩展——无法评估变更风险。

难度: 中级

名称: 模块 3。将规范重写为 SDD Data 格式

问题: 将模块 2 中的薄弱规范重写为完整的 SDD Data 格式，包含以下章节：目的、消费者、Grain、输入、输出字段、PII 政策、对 contract 的影响、验收事实、待确认事项。约束：grain 为每个 customer_id 一行；输入为 mart_customer_360 和 mart_payment_risk_signals；字段为 customer_id、risk_event_count、large_amount_event_count、last_risk_event_date；不含直接 PII；检查包括 customer_id not_null/unique，风险计数器 not_null；不修改 mart_customer_360 的现有 contract。

解决方案: 重写后的规范示例：

# Спецификация модели: mart_customer_risk_summary

## Назначение
Витрина агрегированных риск-сигналов по клиенту для команд скоринга и антифрода. Не используется для маркетинга.

## Потребитель
Команда риск-моделирования, downstream-дашборд в BI; вторичный потребитель — антифрод-алерты.

## Grain
Одна строка на customer_id. Изменение grain запрещено без подтверждения владельца продукта.

## Входы
- mart_customer_360 — справочник клиентов, контракт зафиксирован, не меняется.
- mart_payment_risk_signals — события риск-признаков платежей.

## Выходные поля
- customer_id (PK, BIGINT, NOT NULL, UNIQUE)
- risk_event_count (INT, NOT NULL) — общее число риск-событий за 90 дней.
- large_amount_event_count (INT, NOT NULL) — число событий с суммой выше порога.
- last_risk_event_date (DATE, NULLABLE) — дата последнего события; NULL допустим, если событий нет.

## Политика PII
Запрещены прямые PII: ФИО, email, телефон, паспорт, адрес. Используется только customer_id как квазиидентификатор. Список запрещённых полей проверяется singular-тестом no_pii_columns на схему итоговой модели.

## Влияние на контракт
Новый дата-продукт, не расширение существующего. Контракт mart_customer_360 не меняется. Зависимости downstream: BI-дашборд риска начинает читать mart_customer_risk_summary вместо ad-hoc SQL.

## Приёмочные факты
1. dbt run на модели mart_customer_risk_summary — успех.
2. dbt test на not_null + unique customer_id — успех.
3. dbt test на not_null риск-счётчиков — успех.
4. singular-тест no_pii_columns — успех.
5. Ручной факт ревьюера: визуальная проверка 5 случайных customer_id через BI — соответствие.

## Открытые подтверждения
- Порог large_amount: требует подтверждения владельца риск-модели.
- Окно 90 дней: требует подтверждения потребителя BI-дашборда.

难度: 中级

名称: 模块 4。最终项目——实现 mart_customer_risk_summary

问题: 在 dbt 项目中添加新的 mart_customer_risk_summary 数据表。要求：grain 为「每个 customer_id 一行」；输入为 mart_customer_360 和 mart_payment_risk_signals；字段为 customer_id、risk_event_count、large_amount_event_count、last_risk_event_date；不含直接 PII；dbt 测试；模型规范和验收事实；关于 contract 影响的备注；审阅者报告。遵循 10 步流程：从工作树到回顾。

解决方案: 按流程的逐步解决方案：

创建一个干净的 git 分支：git checkout -b feat/mart-customer-risk-summary。

在任何 SQL 之前，使用模块 3 中的规范创建文件 specs/models/mart_customer_risk_summary.md。

在 SQL 之前描述验收事实：dbt 命令列表、手动步骤和预期。例如：「在 mart_customer_risk_summary 上运行 dbt test -m 期望 4 个绿色测试」。

描述对 contract 的影响：「新产品，没有扩展 mart_customer_360，下游 BI 仪表板切换到新的数据表」。

实现模型 models/marts/mart_customer_risk_summary.sql。SQL 示例：

{{ config(materialized='table') }}

with payments as (
  select customer_id, event_date, amount, is_risk_event
  from {{ ref('mart_payment_risk_signals') }}
),
agg as (
  select
    customer_id,
    count(*) filter (where is_risk_event) as risk_event_count,
    count(*) filter (where is_risk_event and amount > 100000) as large_amount_event_count,
    max(event_date) filter (where is_risk_event) as last_risk_event_date
  from payments
  group by 1
)
select c.customer_id, a.risk_event_count, a.large_amount_event_count, a.last_risk_event_date
from {{ ref('mart_customer_360') }} c
left join agg a using (customer_id)

更新 models/schema.yml：添加模型、描述、customer_id 上的 not_null 和 unique 测试、风险计数器上的 not_null 测试。

运行 dbt build --profiles-dir . — 所有测试都应为绿色。

准备审阅者报告（结对考核的伙伴）：将意见分为事实（已检查的内容）、假设（默认接受的内容）和待确认事项（需要产品负责人的内容）。

在 specs 中记录：该数据表是否修改了现有的 contract（在这种情况下——没有修改，mart_customer_360 保持不变）。

如果审阅者发现了漂移（例如，last_risk_event_date 变成了 NOT NULL 而不是 NULLABLE）——在合并前修复规范或 SQL。

难度: 中级

案例研究: 名称: 案例 1：客户风险数据表——从零开始的新数据产品

场景: 一家金融科技公司的风险建模团队请求数据工程师构建按客户聚合的风险信号数据表。在此之前，BI 仪表板直接通过 ad-hoc SQL 在 mart_customer_360 和原始支付数据之上收集数据。该数据表应取代 ad-hoc 查询，并成为反欺诈告警的数据源。

挑战: 分析师最初提出的规范只是「做一个有用的客户风险数据表」。未指明：数据表名称、消费者、grain、必需字段、PII 政策、对现有 mart_customer_360 contract 的影响、验收标准。风险：数据工程师做出一个技术上能跑通的「方便」join 模型，但不回答风险团队的问题并破坏了 BI 仪表板。

解决方案: 工程师在编写 SQL 之前停止了工作。与产品负责人和分析师共同确定：grain = 每个 customer_id 一行；三个必需字段（risk_event_count、large_amount_event_count、last_risk_event_date）；禁用 PII 列表（姓名、email、电话、护照、地址）已转化为 singular 测试 no_pii_columns；对 contract 的影响——新产品，mart_customer_360 不变；验收事实包括 dbt 测试以及在 BI 中手动检查 5 个随机 customer_id。在规范获批后，编写了模型，运行了 dbt build，审阅者准备了将事实与假设分开的报告。

结果: 数据表在一个 sprint 内投入生产。BI 仪表板切换到了新的数据表，ad-hoc SQL 脚本已删除。由于消除了 ad-hoc 查询的差异，反欺诈告警变得更加稳定。按评分量表考核：23/25 分——在「验收事实」部分丢了 2 分（在第一轮迭代中审阅者的手动步骤未描述）。

经验教训: 薄弱的规范是正常的起点；工程师的任务是在 SQL 之前阻止它，并将其转化为完整的 SDD Data 产物

禁用 PII 列表应转化为可执行的 singular 测试，而不是聊天中的口号

手动的验收事实（在 BI 中的可视化检查）是必需的——dbt 测试不能覆盖产品语义

「新产品」与「现有产品的扩展」的区分是一个 contract 决策，而不是技术决策