02 Rencana dan desain

Pendamping fasilitator untuk pelajaran learner 02 Rencana dan desain.

Waktu

Sekitar 90 menit, dan hampir tidak ada bagiannya yang berjalan tanpa pengawasan. Ini satu-satunya modul yang dibangun di sekitar kerja worksheet individual atau berpasangan, bukan skrip yang berjalan di latar belakang. Step 1 (skrip profiling) adalah satu-satunya bagian otomatis dan selesai dalam beberapa menit; sisanya — lima worksheet di Step 2 dan migration-plan.md di Step 3 — adalah tempat 90 menit itu sebenarnya terpakai. Jangan rencanakan istirahat di dalam modul ini; jika ruangan butuh istirahat, ambil di perbatasan dengan modul 03, bukan di tengah-tengah worksheet.

Alur pembicaraan

• Awali dengan apa yang bukan modul ini: ini bukan penundaan sebelum migrasi "sungguhan" di modul 03. Alasan paling umum migrasi ClickHouse berkinerja di bawah harapan adalah masalah arsitektur, bukan masalah tuning — tim memindahkan data dulu dan mendesain kemudian.
• Sebut ini secara langsung, karena inilah argumen terkuat yang tersedia untuk menghabiskan 90 menit itu: ini modul yang paling ingin dilewati partner, karena setup.sh modul 03 hanya memberi peringatan atas migration-plan.md yang hilang atau tidak lengkap — ia tidak pernah memblokir.
• Telusuri apa yang terjadi jika partner tetap melewatinya: mereka masih akan berhasil secara mekanis di modul 03 — fact_trips tetap muncul sebagai ReplacingMergeTree, datanya tetap berpindah — tetapi mereka tidak akan tahu mengapa engine itu dan bukan MergeTree biasa, tidak akan tahu bagaimana key ORDER BY diturunkan dari beban kerja query, tidak akan mengenali delete_insert dan FINAL di konfigurasi dbt, dan tidak akan mampu menjelaskan atau mereproduksi peningkatan kecepatan pada benchmark modul 05 untuk pelanggan.
• Tunjuk halaman referensi Worked Example hanya setelah partner mencoba rencana mereka sendiri — itu pemeriksaan kewajaran, bukan template untuk disalin sebelum berpikir sampai tuntas.

Kegagalan umum

• ACCOUNT_USAGE tidak tersedia saat skrip profiling Step 1 berjalan. Ia membutuhkan entah jeda propagasi 1-3 jam setelah akun Snowflake dibuat, atau role ACCOUNTADMIN. Skrip beralih ke INFORMATION_SCHEMA secara otomatis dan mencatat apa yang tidak bisa diukurnya — ini degradasi yang mulus, bukan crash, tetapi partner mungkin tidak menyadari fallback itu terjadi. Tunjukkan mereka ke scripts/02_query_history.sql, yang bisa dijalankan manual di UI Snowflake, jika profil otomatisnya terlihat tipis.
• Partner menganggap Completion Checklist di migration-plan.md sebagai opsional. Bukan — setup.sh modul 03 membacanya, dan kotak yang belum dicentang adalah sinyal bahwa modul ini dilewati secara substansi meskipun filenya sendiri ada.
• TODO: tidak ada bagian Troubleshooting di README modul ini sendiri, berbeda dengan modul 01 dan 03. Isi ini dari gladi bersih setelah bagian worksheet dijalankan dengan ruangan sungguhan.

Langkah reset

• profile_report.md (output Step 1) di-gitignore dan diregenerasi segar dari akun Snowflake live milik partner sendiri pada setiap run — jika terlihat basi atau salah, cukup jalankan ulang ./scripts/01_profile_snowflake.sh. Tidak ada yang perlu dibongkar.
• Kelima worksheet diisi di situs, dengan jawaban dinilai langsung dan disimpan di browser peserta (localStorage), bukan di repo. migration-plan.md tetap diedit langsung di repo — modul ini tidak memprovisi apa pun di kedua cloud, jadi tidak ada teardown.sh dan tidak ada flag setup yang perlu dipakai.
• Jika peserta membuat sebuah worksheet masuk ke keadaan buruk, tunjukkan mereka ke kontrol "Clear answers" worksheet itu sendiri alih-alih git checkout — jawaban mereka tidak pernah menyentuh git, jadi checkout tidak akan membantu.