第 1 部分. 简介：面向数据的 SDD
在第一卷中，SDD 应用于 Web 应用：使命、技术栈、路线图、特性规范、计划、验证和实现。在数据平台中，同样的逻辑仍然成立，但主要风险发生了变化。在应用中，代理可能会在路由或 UI 上出错。在数据领域，代理可能会在不知不觉中改变指标的语义、数据集的粒度、时效性、个人数据策略或与下游消费者的兼容性。
因此，SDD Data 不是从 SQL 开始的。它从这样一个问题开始：数据产品向消费者做出了什么承诺？
您将构建的内容
教学项目是虚构银行 北方桥梁银行 的 DataLakeHouse。到本书结束时，您将拥有一个本地 dbt 项目，用于构建最终的指标层：
mart_customer_360；mart_card_turnover_daily；mart_payment_risk_signals；mart_credit_portfolio_quality；mart_open_api_consents。
所有数据均为合成数据。俄罗斯银行业务背景用作一组约束条件：个人数据、支付、同意、风险信号、监管报告。这是一个教学架构，而非法律指南。
SDD Data 与普通 dbt 课程的区别
普通 dbt 课程通常从 select * from source 开始。这里的顺序不同：
- 首先是平台的使命。
- 然后是产品规范和契约。
- 然后是原始/staging 层。
- 然后是指标层。
- 然后是验证事实和评审报告。
dbt 仍然是转换的主要工具，但不再是意义的来源。意义存在于规范中。SQL 应该执行已确定的承诺，而不是事后创造它。
SDD 简要回顾
SDD 是一个循环，其中代理不从实现开始。首先，人和代理确定意图、边界、决策和验证事实。然后代理根据已批准的文件编写代码或 SQL。实现之后，单独的评审不仅检查"测试是否通过"，还检查结果是否与规范一致。
对于数据，这个循环如下：
描述数据产品 -> 定义契约 -> 实现 dbt 模型
-> 执行验证事实 -> 评估对契约的影响 -> 收集发布证据从第一章开始需要记住的三条规则：
- 规范存在于代码仓库中，而不是聊天中；
- 验证事实必须包含命令、SQL 或评审者的手动步骤；
- 作者和评审者必须以不同的模式工作，即使它是同一个
/clear之后的 CLI 代理。
第一个风险：意义的不可见变化
假设代理在 mart_customer_360 中添加了 product_code。SQL 可以编译，dbt 测试可以通过，但粒度不再是"每个 customer_id 一行"。对于下游消费者来说，这是一个破坏性契约变更：原本统计客户的报表开始统计客户-产品对。在 Web 应用中，此类缺陷通常立即可见。在数据领域，它可能在一周后进入报表、KPI 或风险模型。
SDD Data 正是针对这些情况。它强制在 SQL 之前编写：
- 承诺的粒度是什么；
- 哪些字段是必需的；
- 哪些字段被禁止；
- 哪些检查允许更改；
- 谁确认漂移或破坏性变更。
读者解读
第一次阅读时，很容易把这本书当作另一本 dbt 路线图：安装适配器、编写模型、运行 dbt build、获得绿色输出。这是错误的框架。这里的 dbt 扮演与普通应用程序中测试框架相同的角色：它使部分行为可验证，但不决定业务上什么应该是真的。如果读者没有从第一章就保持这种区别，那么接下来所有的工件都会显得像官僚作风。
将教学银行想象成一个组织，在那里一张表经过多个人的手。运营团队导出源数据。数据工程师整理类型。分析师构建报表。风险团队查看信号。领导阅读聚合。SQL 中的错误可能是局部的，但数据集中意义的错误会沿这条链条蔓延。因此，SDD Data 试图保护的不仅是代码，还有人与人之间的约定：行的含义、允许的字段、可接受的数据时效性、谁确认变更。
从这里出现了本卷的主要节奏。首先，读者记录承诺，然后使其可执行，然后用事实证明，然后提交独立评审。这看起来比直接编写 SQL 慢，但在教学项目中，差异很快显现：一旦出现 PII、同意或风险信号，"快速 SQL"就开始做出它无权做出的决定。优秀的代理只有在边界已经被命名时才能加速工作。
如果读完本章后仍有"所有词都可以用一条'构建指标层'的命令替换"的感觉，那么应该停下来。这样的命令要求代理同时充当分析师、架构师、评审者和风险负责人。在第一卷中，这对特性是危险的。在数据领域，这更危险：最终表可能看起来很整洁，但已经在说假话。
实践
打开示例：
cd book3/examples/bank-lakehouse
bash smoke_all.sh如果未安装 dbt，smoke 仍然会生成合成数据并检查结构。安装依赖项后，它将执行完整的 dbt build。
最小输出
在本部分之后，您应该已选择阅读模式：
- DuckDB 上的教学本地轨道；
- 与生产环境的映射作为参考层，而非必需的基础设施；
- 理解本书构建的不是"银行本身"，而是一个可重现的数据产品流程。
在工作笔记中记下：
第一遍：在 dbt-duckdb 上构建银行的本地 DataLakeHouse；在实践考核之前不实施与生产环境的映射。常见错误
初学者试图立即用"真实"的技术栈替换 DuckDB。这是
为时过早。在第一遍中，更重要的是看到规范和可验证指标层之间的联系。如果本地版本无法保持粒度、测试和 PII 策略，生产集群只会加速错误。
检查问题
- 为什么在数据项目中不能从 SQL 开始？
- 如果最终的指标层包含 PII，会发生什么变化？
- 什么是真理的来源：dbt 模型还是数据产品规范？