Snowflake MigrationClickHouse Workshops

04 dbt パイプラインの再構築

ClickHouse 上で dbt パイプラインを再構築するためのファシリテーター向けガイド — 空の集計テーブルがバグではない理由。

学習者向けレッスン 04 dbt パイプラインの再構築 に対応するファシリテーター向けの手引きです。

所要時間

約 30 分。実質的な待ち時間がある区間は Step 1 の 2 回目の dbt run だけです(インクリメンタル モデルで 5,000 万行を処理するのにおおよそ 8〜12 分)。専用の休憩が必要になるほど長くはあり ませんが、黙って眺めるのではなく語る価値はある長さです。Step 2(ゾーンのディクショナリ)と 検証クエリは短時間で対話的に進みます。

トークトラック

  • このモジュールはデータではなくパイプラインを証明するものだと位置づけてください。モジュール 03 は ClickHouse が 5,000 万行を保持できることを証明しました。このモジュールは、モジュール 01 と同じ Medallion のパイプライン — ステージングのビュー、インクリメンタルなファクト テーブル、ディメンションのリロード、テスト — が、形を変えずに ClickHouse 上で動くことを 証明します。
  • 立ち止まる価値のある dbt のメカニズムが 1 つあります。delete_insert が MERGE INTO を 置き換え(ClickHouse に MERGE 文はありません)、ReplacingMergeTree はその下にある セーフティネットであって、代替ではありません。delete_insert が正常に完了すれば RMT が 片付けるものは何もなく、実行が途中で中断された場合にのみ意味を持ちます。
  • mv_live_trip_feed は名前を挙げて取り上げる価値があります。これには Snowflake 側の対応物が まったくありません。標準の materialized view は、自身をトリガーしたバッチに含まれる行しか 見ることができません。REFRESHABLE な materialized view はクエリ全体をスケジュールに従って 再実行するため、生涯にわたる集計を維持できます。これは単純な移植ではなく、移行によって 加わる新しい機能です。
  • 誰かが尋ねる前にこう伝えてください。Step 1 の dbt run の後、agg_hourly_zone_trips は 空になりますが、それはバグではなく正しい状態です。 そのインクリメンタルのフィルターは WHERE pickup_at >= now() - INTERVAL 2 HOUR で、ライブの producer が書き込んだ行にしか 一致しません。いま移行したばかりの行はすべて過去のデータです。モジュール 05 で カットオーバー時に ClickHouse の producer が起動するまで、空のままです。パートナーは決まって これをパイプラインの故障だと思い込みます。質問より先に手を打ってください。

よくある失敗

  • Step 1 の後に agg_hourly_zone_trips が 0 行を返し、パートナーがそれをバグとして報告する。 バグではありません。上記のトークトラックを参照してください。agg_hourly_zone_trips に時間を 費やす前に、dim_taxi_zones(265 行)と fact_trips(おおよそ 5,000 万行)が想定どおりに 埋まっていることを確認してください。その 2 つが正しければ、空の集計テーブルは設計どおりに ちょうど機能しています。これはこのモジュールの代表的な失敗で、毎回この質問が出ると 想定してください。
  • Step 1 の dbt run が失敗する、または接続できない。 このモジュールは、モジュール 03 で 既に作成されているはずの ClickHouse の dbt プロファイル(~/.dbt/profiles.yml、 nyc_taxi_ch)に依存します。そのプロファイルが欠けている場合 — 03 プロビジョニングと移行 の Step 2「Configure the dbt profile」を参照 — 根本原因より 1 モジュール遅れて、ここで Step 1 が失敗します。
  • TODO: サイトの トラブルシューティング ページの ## dbt on ClickHouse セクションには、この手順でのみ表面化する失敗についての専用の項目が ありません。リハーサル特有のことがあればここに記録してください。

リセット手順

  • dbt run は自由に再実行してください。インクリメンタルであり、繰り返しても安全です。ここでは ティアダウンは不要です。
  • dbt のモデルやスキーマを変更した後、インクリメンタルモデルの完全な再構築を強制する: dbt run --full-refresh( workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/dbt/nyc_taxi_dbt_ch から実行)。
  • ゾーンのディクショナリが誤っていたり古く見えたりする場合は、単に scripts/04_create_dictionary.sql を再実行してください。これは CREATE OR REPLACE DICTIONARY なので、先に何かを削除しなくても再実行して安全です。
  • ここに環境レベルのリセットは適用されません。このモジュールのティアダウンはモジュール 03 で 扱った同じ workshop_public/snowflake_migration_lab/03-migrate-to-clickhouse/teardown.sh です。 モジュールの途中で実行しないでください。

このページの内容

JA