Snowflake MigrationClickHouse Workshops
計画ワークシート

ワークシート1: MergeTree エンジンの選定

NYC タクシーの各テーブルに対して MergeTree エンジンを選びます。回答ごとに即時にフィードバックが返ります。

所要時間の目安: 15〜20分 参照: MergeTree エンジン

概念

Snowflake ではテーブルを作れば、どう保存するかは Snowflake が決めます。ClickHouse では ストレージエンジンを自分で選びます — そしてこの選択が決めるのは性能だけではなく、 正しさです。

このラボで必要になるエンジンは3つです。

MergeTree — 基本のエンジン。データはソートされた列指向ファイルとして保存されます。 重複排除はありません。テーブルが追記のみである場合、または更新をパイプライン側で外部から 管理している場合(例: dbt の実行ごとにフルリロードする)に使います。

ReplacingMergeTree(version_col) — MergeTree にバックグラウンドの重複排除を加えたものです。 同じ ORDER BY キーを持つ行が複数のパートに存在する場合、マージ後に残るのは version_col の値が最も大きい行だけです。行が更新されうるうえ、更新ごとに単調増加するカラム(例: updated_at タイムスタンプ)がある場合に使います。

重要な落とし穴: 重複排除は非同期です。ClickHouse がバックグラウンドマージを実行するまで、 行の古いバージョンと新しいバージョンは共存します。ReplacingMergeTree のテーブルでは常に SELECT ... FINAL を使い、クエリ時点で重複排除を強制してください。

AggregatingMergeTree — MergeTree に部分集計状態のマージを加えたものです。テーブルが 結合可能な集計状態(例: HyperLogLog スケッチ、分位点ダイジェスト)を保持し、バックグラウンドでの 集計が必要な場合に使います。NYC タクシーのラボでは不要です — 集計テーブルは累積されるのではなく、 dbt によって作り直されます。

デシジョンツリー

Does the table receive UPDATE or DELETE operations?
│
├── No (insert-only)
│   └─► MergeTree()
│
└── Yes
    ├── Is there a timestamp/version column that increases on every update?
    │   ├── Yes → ReplacingMergeTree(version_col)
    │   └── No (e.g., full-reload dimension tables)
    │       └─► MergeTree()  — dbt handles upsert via atomic table swap (full rebuild)
    │
    └── Does the table store partial aggregate states (AggregateFunction types)?
        └── Yes → AggregatingMergeTree()

ステージングモデルは常に view

dbt + ClickHouse では、ステージングモデルはテーブルではなく view としてマテリアライズすべきです。 view はストレージコストがゼロで、常に最新です — 物理的なオブジェクトではなく、保存された SQL に すぎません。

以下のエンジン選定演習が対象とするのは、分析レイヤーの dbt モデル(ファクトテーブル、 集計、ディメンション)と ClickHouse の materialized view です。trips_raw とステージング モデルは含みません。

  • trips_raw は、マイグレーションスクリプト(scripts/02_migrate_trips.py)が直接作成する ClickHouse のベーステーブルであり、dbt モデルではありません。ReplacingMergeTree(_synced_at) を使うのは、マイグレーションスクリプトがバッチをリトライして同じ trip_id を再挿入する 可能性があるからです。カットオーバー後は、稼働中のプロデューサーも一時的な障害でリトライし えます。_synced_at DateTime DEFAULT now() によって、最も新しい書き込みが勝つことが 保証されます。
  • stg_trips は trips_raw の上に立つ dbt の view です。SELECT ... FROM trips_raw FINAL を適用し、データが下流の分析モデルに届く前に、マージされていない重複を 解決します。重複排除の責務はここにあります — ReplacingMergeTree のステージングテーブルでは ありません。

演習: NYC タクシーのテーブルに対するエンジン選定

以下の各テーブルについて、更新パターンを見極め、バージョンカラム(あれば)を特定し、その テーブルを正しく保つエンジンを選んでください。すべての行を埋めたら、推論の問いに取り組みます。

Loading worksheet...

migration-plan.md への転記

このワークシートを記入し終えたら、エンジンの判断を migration-plan.md のセクション3に コピーし、次をチェックしてください。

- [ ] Engine selection: completed

このページの内容

Track your progress?

Optional. We email a link to confirm your address; progress records once you open it.

Please use your work email address, not a personal one.

Progress tracking also requires accepting the current Terms of Service in Privacy settings.

JA