04 重建 dbt 流水线

在 ClickHouse 上重建 dbt 流水线的讲师指南，为什么空的聚合表不是 bug。

学员课程 04 重建 dbt 流水线的讲师配套材料。

时间安排

约 30 分钟。唯一真正有空档的时段是第 1 步中的第二次 dbt run （大约 8-12 分钟，把 5000 万行跑过增量模型），短到通常不需要为它单独安排一次休息，但又长到值得边跑边讲，而不是默默看着。第 2 步（区域 dictionary）和验证查询都很快，而且是交互式的。

把这个模块定位为验证流水线，而不是验证数据：模块 03 证明了 ClickHouse 能够容纳 5000 万行数据。本模块会验证模块 01 中的同一套 Medallion 管道，包括 staging 视图、增量事实表、维度表重载和测试，都能在 ClickHouse 上以相同结构运行。
唯一值得停下来讲的 dbt 机制：delete_insert 取代了 MERGE INTO （ClickHouse 没有 MERGE 语句），而 ReplacingMergeTree 是它底下的安全网，不是它的替代品，如果 delete_insert 正常完成，RMT 就没有什么需要清理的；它只在某次运行中途被打断时才起作用。
mv_live_trip_feed 值得点名说明：它在 Snowflake 一侧完全没有对应物。标准的 materialized view 只能看到触发它的那一批数据里的行；而 REFRESHABLE 的 materialized view 会按计划重跑整条查询，因此可以维护一个全生命周期的聚合结果。这是迁移带来的新增能力，不是一次直译移植。
在任何人开口问之前先说这一点：agg_hourly_zone_trips 在第 1 步的 dbt run 之后会是空的，而这是正确的，不是 bug。 它的增量过滤条件是 WHERE pickup_at >= now() - INTERVAL 2 HOUR，只会匹配由实时 producer 写入的行；而刚刚迁移过来的每一行都是历史数据。它会一直空着，直到模块 05 在切换时启动 ClickHouse 的 producer。搭档几乎必然会以为流水线坏了，抢在这个问题之前把它讲掉。

agg_hourly_zone_trips 在第 1 步之后返回 0 行，而一位搭档把它当成 bug 报上来。 它不是，见上面的讲解要点。在为 agg_hourly_zone_trips 花任何时间之前，先确认 dim_taxi_zones（265 行）和 fact_trips（约 5000 万行）都如预期地填充好了；如果这两个都正确，那么空的聚合表就是完全按设计工作的。这是本模块的头号故障，每次都要预期会有人问。
第 1 步中的 dbt run 失败或连不上。 本模块依赖模块 03 本应已经创建好的 ClickHouse dbt profile（~/.dbt/profiles.yml，nyc_taxi_ch）。如果那个 profile 缺失，见 03 开通与迁移中第 2 步的"配置 dbt profile"，第 1 步就会在这里失败，比根因晚了一个模块。
TODO：站点上的排障页面的 ## dbt on ClickHouse 小节里，没有专门针对只在这一步暴露的故障的条目。把演练中发现的相关情况记在这里。

可以放心地重跑 dbt run，它是增量的，重复执行是安全的；这里不需要任何销毁操作。
在 dbt 模型或 schema 变更之后，强制对增量模型做一次完整重建： dbt run --full-refresh（在 workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/dbt/nyc_taxi_dbt_ch 下执行）。
如果区域 dictionary 不正确或数据已过期，直接重新运行 scripts/04_create_dictionary.sql。该脚本使用 CREATE OR REPLACE DICTIONARY，可以安全地重复执行，无需先删除现有对象。
这里没有环境级别的重置，本模块的销毁脚本就是模块 03 下讲过的那个 workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/teardown.sh；不要在模块进行中运行它。