ワークシート4: マイグレーションのウェーブ計画

所要時間の目安: 15〜20分 参照: 実行順序については モジュール03 — プロビジョニングと移行 → モジュール04 — dbt パイプラインの再構築 → モジュール05 — ベンチマークとカットオーバー

概念

データベースのオブジェクトには依存関係があります。fact_trips を参照する view は fact_trips が存在する前には作成できません。trips_raw から読む materialized view は trips_raw にデータが入る前には投入できません。誤った順序で移行すると、テーブル作成の失敗、 空の結果、あるいは原因の突き止めにくい不完全なデータを招きます。

解決策はウェーブ計画です。 すべてのオブジェクトを番号付きのウェーブに整理し、各ウェーブには 依存関係が先行するウェーブで満たされているオブジェクトだけを含めます。

複雑度の格付け は、マイグレーションの労力に優先順位を付けるのに役立ちます。B と C の境目は、 ステートメント を作り直す必要があるのか、型を書き換えるだけで済むのかです。

• グレード A — 自明: 標準的なテーブル、あるいは素通しの view。特別なロジックはなく、 型マッピングも素直
• グレード B — 中程度: 学んでテストすべき ClickHouse 固有の構文が1つあるが、変換そのものは 置き換えで済む — ClickHouse のエンジンと増分設定、CREATE DICTIONARY、リフレッシュ可能な MV の REFRESH EVERY、あるいは VARIANT の読み取りの代わりに立つ JSONExtract* のパス
• グレード C — 複雑: 型を書き換えるだけでなくステートメントを作り直す必要があり （QUALIFY をサブクエリで包む、MERGE INTO を増分戦略で置き換える）、その書き換えは エンジンの選択と、下流のすべてにおける FINAL の置き場所とも整合していなければならない。 慎重にテストすること
• グレード D — 再設計が必要: 直接の同等物がない Snowflake 固有の機能 （Streams → プロデューサーを ClickHouse へカットオーバー、Tasks → リフレッシュ可能な MV か スケジュールされた dbt 実行）

以下の演習3では、上記の4段階の代わりに圧縮した3段階の尺度 — Low（グレード A）、 Medium（グレード B）、High（グレード C または D）— で格付けしてもらいます。作業量の 順序付けにおいて最も重要な区別は、自明か / テストが必要か / 再設計が必要か であって、 4分割ではないからです。各回答の解説にはどのグレード（A〜D）が当てはまるかが書かれているので、 文字グレードに戻して対応付けることもできます。

演習1: 依存関係の DAG

以下の各オブジェクトについて、何に依存しているかを選んでください。10のうち3つは依存関係を まったく持たない静的な参照データです — それは実際の答えであり、後で埋めるべき空白では ありません。

演習2: マイグレーションのウェーブ割り当て

ウェーブ0と1は文脈として記入済みです。ウェーブ2から4については、そのウェーブに属する オブジェクトを選び、そのうえでそのウェーブで実際に何が起きるのかに答えてください。

演習3: 複雑度の格付け

各オブジェクトを格付けし、そのうえで表の下にある主要な課題の問いに答えてください。

振り返りの問い

最後の2問は、解答例のリスクレジスターにある3つの項目を扱います — fact_trips（グレード C）と agg_hourly_zone_trips が到着したあとの検証、そして TRIPS_CDC_STREAM と CDC_CONSUME_TASK を置き換えるプロデューサーのカットオーバーの検証（グレード D）です。 このレジスターは、単にグレード C/D の集合ではありません。agg_hourly_zone_trips は Medium と 格付けされますが、そのローリング再計算ウィンドウは、このパイプラインの中で最も微妙に間違え やすいものです。

Loading worksheet...

migration-plan.md への転記

ウェーブ計画と複雑度のグレードを migration-plan.md のセクション6にコピーし、次を チェックしてください。

- [ ] Migration wave plan: completed