02 Rencana dan desain

Titik awal

Modul 01 selesai: Snowflake terbangun penuh, stream CDC dan kedua task terjadwal berjalan, dan — yang paling penting — producer perjalanan masih menulis sekitar 60 perjalanan/menit ke TRIPS_RAW. Biarkan tetap berjalan; modul ini hanya membaca dari Snowflake. Siapkan sekitar 90 menit dan kurang lebih 0,5 kredit Snowflake.

Mengapa

Alasan paling umum migrasi ClickHouse berkinerja di bawah harapan bukanlah masalah tuning — melainkan masalah arsitektur. Tim memindahkan data lebih dulu dan memikirkan desain belakangan. Pada saat mereka menyadari bahwa engine MergeTree yang salah diam-diam menghasilkan hasil yang tidak benar, atau bahwa sort key yang dicontek dari skema sumber mengabaikan pola query yang sesungguhnya, migrasinya sudah "selesai". Modul ini memaksa urutan sebaliknya: profilkan apa yang benar-benar Anda punya, lalu buat setiap keputusan engine, sort key, pemetaan tipe, dan urutan pelaksanaan menjadi eksplisit — tertulis — sebelum modul 03 mengeksekusi apa pun.

Ini juga modul yang paling sering ingin dilewati partner. setup.sh di modul 03 memeriksa migration-plan.md dan memberi peringatan jika file itu tidak ada atau belum lengkap, tetapi ia tidak pernah memblokir — Anda bisa menerobos tanpanya. Kalau Anda melakukannya, Anda akan menjalankan modul 03 sambil mengeksekusi keputusan yang tidak pernah Anda ambil: Anda akan melihat fact_trips muncul sebagai ReplacingMergeTree tanpa tahu mengapa engine itu dan bukan MergeTree biasa, melihat kunci ORDER BY tanpa tahu bagaimana ia diturunkan dari workload query, melihat delete_insert dan FINAL di konfigurasi dbt tanpa tahu cara menurunkannya untuk workload berbeda, dan melihat percepatan benchmark di modul 04 yang tak bisa Anda jelaskan atau reproduksi untuk seorang pelanggan. Sembilan puluh menit di sini adalah yang mengubah sisa workshop dari menyalin perintah menjadi memahami sebuah migrasi.

Konsep — di balik layar

Setiap keputusan yang dihasilkan modul ini masuk ke salah satu dari lima kategori, masing-masing dengan sebuah worksheet:

• Keluarga engine — varian MergeTree mana yang cocok dengan pola tulis setiap tabel: MergeTree biasa untuk append-only, ReplacingMergeTree untuk tabel yang menerima update melalui CDC, AggregatingMergeTree untuk rollup pra-agregasi. Lihat Engine MergeTree.
• Kunci ORDER BY — ClickHouse tidak punya indeks yang bisa ditambahkan belakangan; sort key dipilih satu kali, dari workload query yang sesungguhnya, bukan dari primary key tabel sumber.
• Pemetaan tipe dan celah dialek — VARIANT, LATERAL FLATTEN, dan MERGE INTO milik Snowflake tidak punya padanan langsung di ClickHouse dan perlu bentuk terjemahan. QUALIFY adalah pengecualian: ClickHouse sudah punya klausa QUALIFY native sejak v24.5, tetapi lab ini tetap mengajarkan penulisan ulang sebagai subquery karena bentuk itu portabel ke versi ClickHouse dan engine SQL yang lebih tua atau tidak punya QUALIFY. Lihat Snowflake vs ClickHouse.
• Desain model dbt — materialisasi, konfigurasi engine, strategi inkremental, dan penempatan FINAL per model. Lihat dbt di ClickHouse.
• Urutan gelombang — objek mana yang bisa dipindahkan lebih dulu karena belum ada yang bergantung padanya di hilir, dan mana yang harus menunggu.

Langkah 1 — Profilkan lingkungan Snowflake

cd "$(git rev-parse --show-toplevel)/workshop_public/snowflake_migration_lab/02-plan-and-design"
source ../01-setup-snowflake/.env
./scripts/01_profile_snowflake.sh

Ini berjalan terhadap instance Snowflake modul 01 Anda yang masih hidup dan menulis profile_report.md dengan empat bagian: inventaris objek (setiap tabel, view, stream, dan task beserta jumlah baris dan nilai kompleksitas), 10 query teratas berdasarkan total waktu berjalan selama 7 hari terakhir, statistik tabel (jumlah baris, rentang tanggal, tingkat null, penggunaan VARIANT), dan celah kompatibilitas skema yang terdeteksi otomatis.

profile_report.md masuk gitignore — ia dihasilkan segar dari akun Snowflake Anda sendiri pada setiap eksekusi, jadi bersifat spesifik per mesin dan tidak pernah di-commit. Jangan berharap menemukannya di clone yang baru, dan jangan mencoba meng-commit-nya sendiri.

Jika ACCOUNT_USAGE belum tersedia (ia butuh jeda propagasi 1-3 jam atau role ACCOUNTADMIN), skrip akan jatuh kembali ke INFORMATION_SCHEMA dan mencatat apa yang tidak bisa diukurnya. Anda juga bisa menjalankan scripts/02_query_history.sql secara manual di UI Snowflake.

Langkah 2 — Kerjakan kelima worksheet

Kerjakan kelima worksheet secara berurutan. Masing-masing mengajarkan sebuah konsep, lalu menyajikan latihan pilihan ganda untuk workload NYC Taxi yang sesungguhnya. Setiap jawaban diperiksa begitu Anda memilihnya, dan setiap worksheet punya tombol "Copy as markdown" yang memberi Anda tabel terisi untuk ditempelkan ke rencana migrasi Anda.

• Worksheet 1: Pemilihan engine MergeTree — keluarga engine dan pilihan engine per tabel
• Worksheet 2: Desain sort key — ORDER BY yang diturunkan dari workload query
• Worksheet 3: Terjemahan skema — pemetaan tipe dan terjemahan fungsi
• Worksheet 4: Rencana gelombang migrasi — pengurutan dependensi dan penetapan gelombang
• Worksheet 5: Desain model dbt — materialisasi, engine, strategi inkremental, dan penempatan FINAL

Jawaban Anda disimpan di local storage browser, bukan di repo — jawaban itu tidak mengikuti Anda ke mesin lain dan tidak bertahan jika data situs dibersihkan. Jika Anda berganti laptop di tengah workshop, Anda perlu mengerjakan ulang worksheet-nya di sana.

Langkah 3 — Isi rencana migrasi

Buka workshop_public/snowflake_migration_lab/02-plan-and-design/migration-plan.md dan isi setiap bagian memakai jawaban worksheet Anda. Dokumen itu punya sepuluh bagian dan sebuah Completion Checklist dengan lima kotak centang di bagian atas:

- [ ] Engine selection: completed
- [ ] Sort key design: completed
- [ ] Schema translation: completed
- [ ] Migration wave plan: completed
- [ ] dbt model design: completed

setup.sh di modul 03 memeriksa checklist ini dan memberi peringatan jika belum lengkap, tetapi tidak menghalangi Anda melanjutkan. Menyelesaikannya tetap penting karena itulah yang membuat keputusan-keputusan modul 03 terasa bermakna alih-alih sewenang-wenang.

Cara memverifikasi bahwa Anda sudah selesai

Anda selesai ketika semua hal berikut terpenuhi:

• Kelima worksheet menunjukkan nilai penuh — baris skor di bagian bawah masing-masing berbunyi N/N correct.
• workshop_public/snowflake_migration_lab/02-plan-and-design/migration-plan.md punya setiap kotak di Completion Checklist-nya tercentang.
• profile_report.md ada di disk dari Langkah 1 (masuk gitignore, jadi tidak akan muncul di git status).

Setelah rencana Anda sendiri tertulis, bandingkan dengan Contoh terkerjakan: rencana yang sudah lengkap — sebuah rencana yang terisi penuh untuk workload yang sama. Gunakan itu untuk memeriksa kewajaran penalaran Anda dan untuk memahami setiap tempat di mana Anda memilih berbeda, bukan sebagai templat untuk diisi sebelum Anda memikirkannya sendiri.

Kondisi akhir

Sebuah migration-plan.md terisi di disk, setiap kotak tercentang, ditopang lima worksheet yang sudah diselesaikan. Producer Snowflake masih berjalan — modul 03 memigrasikan data dari sumber yang hidup dan bergerak, dan cutover di modul 05 mengukur jeda persis yang diciptakan producer antara Snowflake dan ClickHouse selama migrasi. Jangan hentikan sekarang.