第 22 部分. 实践结业考核

最终任务是——通过完整的 SDD Data 周期完成一次变更。这不是对 dbt 语法知识的测试,而是检验你能否从规范一路到评审报告都兑现数据产品的承诺。

读者解读

实践结业考核的目的不是检查记忆。它的任务是迫使学生脱离教科书作者的提示,走完整个周期。如果一个人能写 SQL,但无法解释 grain、PII 策略、对契约的影响以及验证事实,那么他还没有真正掌握 SDD Data。在实际工作中,正是这些遗漏把原本整洁的模型变成了有风险的指标表。

考核特意从一份糟糕的规范开始。这比直接给出实现任务更重要。优秀的数据工程师必须能在写 SQL 之前拦住一份薄弱的任务。如果规范只写着"做一个有用的指标表",那么不能开始建模。需要追问消费者、grain、输入、必填字段、PII、对已有契约的影响,以及验收标准。

配对形式还体现了本卷的另一个观点:评审是一种主动的工程角色。评审员不只是寻找 SQL 中的笔误,他还检查作者是否

用方便的实现偷换了承诺,是否在失败之后放松了校验,是否把破坏性变更藏在了"小改进"里。因此,一份好的考核应当同时包含模型、测试,以及评审员的报告。

结尾的回顾是为了诚实。如果在 SQL 之后还要澄清很多事项,这并非学生的失败,而是一个信号:下一阶段需要缩小范围或更详细地写出规范。SDD Data 并不承诺所有问题都能提前关闭。它要求问题不会无影无踪地消失,并且每一次澄清都要回到项目文件中。

第 1 块. 快速问题

请书面作答,不要使用 Qwen Code。

1. grain 的真理来源是什么?
2. ODPS 与 ODCS 有什么区别?
3. 为什么 dbt 测试不能替代数据契约?
4. 禁止 PII 的列表应当写在哪里?
5. 什么是契约漂移?
6. 什么情况下,新增一个 nullable 列会变成破坏性变更?
7. 为什么作者和评审员应当是不同角色?
8. dbt build 证明了什么?它没证明什么?
9. Schema Manifest 与模型规范有什么区别?
10. 为什么要为了 dbt build 变绿去"修复"原始数据是错误的?
11. 一条验证事实应当包含什么?

1. 什么时候必须由人来确认?

第 2 块. 找出数据规范中的问题

给定如下规范:

# 客户风险汇总

做一个有用的客户风险指标表。

## 数据

使用 customer_360 和支付数据。补上需要用的风险字段。

## 验证

检查数据是否正确,并且没有个人数据。

至少找出 10 个问题。好的回答会注意到:

• 没有给出指标表的名称;
• 没有指定消费者;
• 没有指明粒度(grain);
• "有用的"无法被验证;
• "需要用的字段"未定义;
• 没有必填指标;
• PII 策略没有被转化为基于禁止字段列表的测试;
• 没有描述对契约的影响;
• 没有列出输入模型;
• 没有 dbt 命令;
• 没有给评审员的手工事实;
• 没有说明这是新产品还是对现有产品的扩展。

第 3 块. 重写规范

按 SDD Data 格式重写规范:

# 模型规范: mart_customer_risk_summary

## 用途
## 消费者
## Grain
## 输入
## 输出字段
## PII 策略
## 对契约的影响
## 验收事实
## 待人工确认

约束条件:

• 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 的契约。

第 4 块. 最终项目

新增一张指标表 mart_customer_risk_summary。

它需要满足:

• grain 为"每个 customer_id 一行";
• 使用 mart_customer_360 和 mart_payment_risk_signals;
• 计算 risk_event_count、large_amount_event_count、last_risk_event_date;
• 不暴露直接 PII;
• 包含 dbt 测试;
• 包含模型规范与验证事实;
• 包含对契约影响的说明以及评审员报告。

流程要求

1. 从一个干净的工作树开始。
2. 在 specs/models/mart_customer_risk_summary.md 中创建规范。
3. 在写 SQL 之前先写出验证事实。
4. 描述对契约的影响:新产品还是扩展。
5. 实现 dbt 模型。
6. 更新 models/schema.yml。
7. 如果已安装 dbt,运行 dbt build --profiles-dir .。
8. 准备评审员报告。
9. 记录该指标表是否会改变已有契约。

1. 如果评审员发现漂移,在发布前修改规范或 SQL。

推荐的 Qwen 场景

创建规范:

/clear
阅读 AGENTS.md、specs 以及当前的 marts。
帮我为 mart_customer_risk_summary 创建规范。
先不要写代码。首先就 grain、PII 策略、必填字段以及验证事实进行提问。

实现:

/clear
只依据已批准的规范实现 mart_customer_risk_summary。
改完之后列出涉及的文件与检查项。
未经确认不要修改已有契约。

评审:

/clear
使用 data-contract-review。
依据规范、PII 策略、测试、验证事实以及对契约的影响来检查本次变更。不要修改文件。

25 分评分标准

21 分及以上——流程可迁移到真实的数据产品。 16–20 分——结果对学习有用,但校验与评审还需要加强。 16 分以下——阶段过大,或规范没能承载其含义。

快速问题答案

1. 模型规范或数据产品契约,而不是 SQL。
2. ODPS 描述产品与消费者;ODCS 是技术契约。
3. dbt 测试只校验部分形态/数据,覆盖不到完整的产品语义。
4. 在规范、AGENTS.md、评审员检查清单,以及(若可能)singular 测试中。
5. 契约/规范与实际模型之间出现偏离。
6. 当它表现为一项新的业务指标、改变了 grain,或影响下游 API 时。
7. 评审员应当检验作者的假设,而不是为其辩护。
8. dbt build 证明了 DAG/测试是可执行的,但证明不了规范的完整性。
9. Manifest 描述的是可观测的源;模型规范描述的是被承诺的指标表。
10. 原始层保留输入;空值与 null 的语义由 staging/规范来定。
11. 命令、SQL 或评审员的手工步骤、期望与状态。
12. 当 grain、PII 策略、SLA、契约字段或风险方法论发生变化时。

结业考核的配对形式

一名学生扮演作者,另一名学生扮演评审员。

作者:

• 编写规范;
• 在 SQL 之前编写验证事实;
• 实现 dbt 模型;
• 运行校验;
• 准备证据包。

评审员:

• 在实现之前阅读规范;
• 依据规范检查变更;
• 运行或复核 dbt 命令;
• 把对契约、SQL、测试与流程的意见分开记录;
• 不编辑作者的文件。

第一张指标表完成后,双方互换角色。这能消除"评审只是被动地读 SQL"的错觉。

考核之后

撰写一份简短的回顾:

# SDD Data 回顾

## 规范中写得好的部分
## SQL 之后才不得不补足的部分
## 哪些校验抓住了错误
## Qwen Code 在哪些地方试图猜测语义
## 在迁移到生产环境之前要强化什么

如果"SQL 之后才不得不补足的部分"中超过三条,那么下一个特性应当缩小规模,或在实现之前更详细地描述。