ClickHouse 移行シリーズ

ワークロードを移す。
効果を証明する。

50M 行、Medallion 構成の dbt パイプライン一式、7 つの分析クエリ、ライブなデータプロデューサー、そして Superset のダッシュボード — 本番相当の Snowflake ワークロードを ClickHouse Cloud へエンドツーエンドで移行し、計測して説明できるようにします。

6 時間 · 7 モジュール50M 行を移行7 クエリを計測~$2-4 トライアルクレジット

単なる持ち上げて移すだけの話ではありません。 判断の記録です。

5,000 万行を別のウェアハウスへコピーするスクリプトは誰でも書けます。移行の難所はそこではなく、顧客がソリューションアーキテクトに期待しているのもそこではありません。

難しいのはコピーの手前です。どのテーブルにどの MergeTree エンジンファミリーが合うのか、ORDER BY キーは実際に何の役に立っているのか、そして QUALIFY、VARIANT、スケジュール実行の TASK のように ClickHouse に直接の対応物がなく、本当の翻訳が必要な Snowflake のイディオムはどれか。

このラボでは、実行する前にその判断を書き出させます。モジュール 02 ではすべての選択に理由を添えた migration-plan.md を作り、モジュール 03 のセットアップスクリプトは ClickHouse に触れる前にその存在を確認します。

モジュール 06 では、その計画をオープンブックで、20 問のアセスメントと 4 つの記述問題に対して弁護します — 実際の顧客との会話で問われる判断力と、同じ試験です。

持ち帰るもの

終わりに動いているもの、すべて。

自分の Snowflake トライアルと自分の ClickHouse Cloud トライアル上で — どちらもクレジットカード不要。

01

プロファイリング済みの Snowflake ワークロード

テーブルの棚卸し、クエリパターンの特定、SQL 方言のギャップの洗い出し、そして移行工数の見積もり — 計画を立てる前に済ませます。

02

正しいエンジンとスキーマの判断

各テーブルに合った MergeTree エンジンファミリー、働きに見合う ORDER BY キー、そして Snowflake の型とイディオムを ClickHouse の対応物へ翻訳。

03

本番仕様の移行、実行済み

50M 行 を再開可能な Python スクリプトで移し、整合性を検証し、プロデューサーの切り替えもスクリプトで実施。

04

ClickHouse 上に作り直した dbt パイプライン

delete_insert を設定した dbt-clickhouse、ReplacingMergeTree のモデル、そして refreshable materialized view。

05

定量化したビジネスケース

7 クエリのベンチマークから、顧客の前で説明できる 6-9x の性能数値へ。

06

説明できる判断

モジュール 06 のアセスメントに合格 — 同じ型を新しい顧客のワークロードに適用できる証明です。

実際に翻訳することになる方言のギャップ

QUALIFYROW_NUMBER を使うサブクエリ
LATERAL FLATTENJSONExtract / arrayJoin
VARIANTJSON / String と抽出関数
MERGEReplacingMergeTree と delete_insert
スケジュール実行の TASKrefreshable materialized view
STREAMライブなプロデューサーのフィード

行程 · ハンズオン 6 時間

7 モジュールを、順番に。

ひと続きの流れ: ソースをプロファイリングし、ターゲットを計画し、データを移し、パイプラインを作り直して、効果を証明します。

  1. 00

    ツールチェーンをインストールし、両方のクラウドトライアルアカウントを作成し、リポジトリをクローンして、dbt の仮想環境を両方構築 — データに触れる前に移行が必要とするものすべて。

  2. 01

    実際の顧客環境を模した Snowflake 環境を用意します: 50M 行、dbt の Medallion パイプライン、ライブな乗車プロデューサー、そして 3 つの Superset ダッシュボード。

  3. 02

    Snowflake のワークロードをプロファイリングし、移行で実行するアーキテクチャの判断を下します: エンジン選定、sort key、スキーマ変換、展開のウェーブ、そして dbt モデル設計。

  4. 03

    Terraform で ClickHouse Cloud をプロビジョニングし、計画どおりにターゲットテーブルを作成して、再開可能なスクリプトで 50M 行を移します。全体で 60 分を見込んでください — そのうち 40〜50 分ほどは放置できるデータ転送で、バックグラウンドで走らせたままにできます。

  5. 04

    Medallion パイプラインを dbt-clickhouse で ClickHouse 上に再構築します — delete_insert の増分モデル、ReplacingMergeTree、refreshable materialized view — そして zone dictionary を作成します。

  6. 05

    ダッシュボードを ClickHouse 上に作り直し、7 つのクエリを両エンジンで計測し、プロデューサーを切り替え、整合性を確認して、環境を破棄します。

  7. 06

    評価

    60 分

    20 問の選択式と 4 問の記述式アセスメントをオープンブックで完了し、ClickHouse Migration Proficiency Badge を獲得します。

既定は自習形式です。 どのモジュールにも開始チェックポイントがあるので、会場のペースに取り残される人は出ません。モジュール 01 で起動した Snowflake のプロデューサーはモジュール 05 まで動かし続ける必要があります — 休憩はその流れを止めずに、合間で取ってください。

参加する前に

対象者と、持ち物。

こんな方に 対象者

  • Snowflake 移行の案件を担当する ClickHouse ソリューションアーキテクトとパートナー
  • 「なぜこのエンジンで、なぜこの sort key なのか」 と聞かれて、根拠を示したい方
  • 本番相当の分析ワークロードを Snowflake から移そうとしているチーム
  • SQL とターミナルに慣れていれば十分 — データエンジニアリングの経験は不要です

持ち物 前提条件

  • モジュール 00 のツールチェーン: Terraform、Docker、Python 3.11-3.13、dbt Core、そして SnowSQL CLI
  • Snowflake のトライアルアカウント — クレジットカード不要
  • ClickHouse Cloud のトライアルアカウント — クレジットカード不要
  • セッション全体で消費する ClickHouse Cloud のトライアルクレジットは約 $2-4 です

進め方 形式

  • 7 モジュールすべて 100% ハンズオン — コマンドとクエリはすべてコピー&ペースト
  • 自習でも講師ありでも。各モジュールに対応した講師トラックがあります
  • Snowflake のプロデューサーは通しでライブに動くので、タイミングはシミュレーションではなく本物です
  • モジュール 06 のアセスメントはオープンブックで、自分で実施します

このラボが扱わないこと 範囲

  • リアルタイムのストリーミング取り込み — Kafka、Kinesis、ClickPipes の代わりに Docker ベースの乗車プロデューサーを使います
  • ClickHouse のマルチノードクラスター — 作業はすべて単一サービスの ClickHouse Cloud 上です
  • データガバナンスとアクセス制御 — ロールベースのアクセス、行レベルセキュリティ、マスキングは実装しません
  • 段階的なスキーマ進化、Snowflake 以外のソース、本番の SLA と監視 — それぞれが独立したテーマです

ワークロードを移す準備はできましたか?

Snowflake のトライアルと ClickHouse Cloud のトライアルを持って参加してください。50M 行の移行、作り直した dbt パイプライン、そして顧客に説明できる 7 つのベンチマーク結果を持ち帰れます。

50M再開可能な Python スクリプトで移行する行数。
6-9x7 つのベンチマーククエリすべてで計測された高速化 — モジュール 05 で自分で測るまでは参考値です。
バッジモジュール 06 で自分の移行計画を弁護して獲得。
JA