练习表 5：dbt 模型设计

预计耗时： 15–20 分钟 参考资料： ClickHouse 上的 dbt

概念

练习表 1–4 产出的是做什么：哪个引擎、哪个 ORDER BY、哪些 ClickHouse 类型。 这份练习表产出的是怎么做：在写任何 SQL 之前，把那些决策表达成 dbt 配置。

一个 dbt-clickhouse 模型有三层配置，是 Snowflake 开发者不 需要考虑的：

1. 物化方式：dbt 创建的是哪种物理对象（view、table、 incremental、ephemeral）？
2. 引擎配置：对表和增量模型而言，用哪个 ClickHouse 引擎和 版本列？
3. 增量策略：对增量模型而言，dbt 如何处理新增/更新的 行？

还有一个 ReplacingMergeTree 独有的正确性问题：

4. FINAL 的放置位置：在 dbt DAG 的哪个位置放 FINAL，才能保证读取到去重后的 结果？

物化方式请用这棵决策树：

• 仅从某个 source 做插入式读取，且不对模型本身写入？→ view
• 纯 join 逻辑，不直接被查询？→ ephemeral
• 每次 dbt 运行都全量重建，没有部分更新？→ table
• 每次运行只处理新增/变更的行？→ incremental

Staging 模型永远是视图，和练习表 1 中的规则相同。stg_trips 和 stg_taxi_zones 是直通读取，自身没有任何写入，因此无论其源数据 表现如何，它们都保持为视图。

练习 1：物化方式选择

对每个模型，选出正确的 dbt 物化方式，然后在表格下方的问题中回答 原因。

练习 2：引擎配置

只有物化方式为 table 或 incremental 的模型才需要 ClickHouse 引擎， 视图和 ephemeral 模型没有引擎。参考你在练习表 1 中的答案：dbt 引擎 配置就是你在那里已经做出的引擎决策的落地实现。

练习 3：增量策略设计

对每个增量模型，设计完整的增量配置：unique_key、 incremental_strategy，以及放在 is_incremental() 保护块内部的 SQL 过滤条件：

{% if is_incremental() %}
  WHERE <your filter here>
{% endif %}

练习 4：FINAL 的放置位置

ReplacingMergeTree 的去重是异步的。FINAL 在读取时强制去重，但把 FINAL 放错模型会带来正确性或性能后果。对下面每个 模型，回答 FINAL 是否属于该模型自身的 FROM 子句。

Loading worksheet...

转录到 migration-plan.md

完成这份练习表之后，用你的答案填写 migration-plan.md 的第 10 节， 并勾选：

- [ ] dbt model design: completed