08 Migrasi nyata Anda

Hasil akhir

Semua yang sejauh ini memindahkan satu export yang fixed, sekali, ke satu tabel. Migrasi nyata berjalan terus-menerus, berevolusi, dan harus mengambil keputusan yang tidak pernah dipaksakan dataset workshop ini. Modul ini dibuka dengan kenapa migrasi itu layak dilakukan sama sekali, lalu menyebutkan keputusan-keputusan itu, lalu membuat argumen yang sudah dibangun seluruh workshop ini: BigQuery tidak hilang, dan memang tidak seharusnya.

Kenapa harus migrasi sama sekali?

Benchmark cost-performance yang dipublikasikan ClickHouse sendiri (Desember 2025) adalah jawaban yang lebih baik untuk ini dibanding apa pun yang bisa didukung sample 4,3 juta baris workshop ini sendiri -- dataset itu sengaja terlalu kecil untuk menunjukkan gap biaya, dan workshop ini sudah mengatakannya dengan jelas alih-alih memaksakannya. Benchmark di bawah menjalankan 43 query ClickBench yang tidak diubah, tanpa tuning tangan di kedua sisi, terhadap billing compute nyata pada tarif nyata masing-masing vendor, bukan harga list:

Akui dengan cara yang sama seperti workshop ini lakukan sepanjang jalan: pada 1 miliar baris, ClickHouse Cloud dan BigQuery Enterprise benar-benar dekat -- 38 detik dan 80 sen melawan 23 detik dan 67 sen. Gap yang memotivasi migrasi muncul begitu data bertambah, bukan pada skala ini. Pada 10 miliar baris, BigQuery Enterprise membutuhkan waktu 5,2x lebih lama dan biaya 2,7x lebih mahal untuk 43 query yang identik. Pada 100 miliar baris, waktunya 14x lebih lama dan biayanya 7,2x lebih mahal. BigQuery on-demand, yang menagih per byte yang discan bukan per node yang di-provision, tertinggal lebih jauh lagi -- bill-nya tumbuh berdasarkan seberapa sering query dijalankan, bukan berapa banyak compute yang di-reserve sebelumnya, yang justru adalah bentuk per-request, customer-facing yang dimodelkan setiap challenge di workshop ini.

Ingestion berkelanjutan, bukan load sekali-jadi

ClickPipe yang Anda setup di modul 03 membaca sekumpulan fixed object Parquet sekali dan berhenti. Pipeline produksi membaca terus-menerus -- file export baru yang mendarat sesuai jadwal, atau streaming source, datang selama bisnisnya berjalan. Mekanismenya adalah konsep ClickPipes yang sama, diarahkan ke source yang terus memproduksi alih-alih bucket yang berhenti berubah sejak hari Anda membacanya. Yang berbeda di produksi adalah semua hal di hilir pipe itu harus mengasumsikan baris akan terus datang tanpa batas: materialized view yang dibangun sekali dan dibiarkan, seperti cara kerja dashboard MV modul 06, alih-alih tabel yang Anda load, tuning, dan tinggalkan.

Evolusi schema

Schema export workshop ini tidak pernah berubah di bawah Anda. Schema export GA4 yang nyata berubah -- BigQuery dan format export-nya menambahkan field seiring waktu, dan tabel berbentuk event yang dibangun untuk export 2026 workshop ini tidak akan identik byte demi byte dengan export tahun depan. Rencanakan untuk itu: Map residual event_params menyerap key baru yang genuine tanpa migrasi schema, dengan biaya key itu tidak mendapat tipe atau codec-nya sendiri sampai Anda menyadari itu layak diekstrak. Kolom top-level baru yang ditambahkan BigQuery ke export-nya, sebaliknya, memang butuh ALTER TABLE yang nyata di sisi ClickHouse -- tidak ada apa pun soal Map yang menyerap sibling baru dari device_category atau traffic_source. Tentukan perubahan jenis mana yang bisa Anda serap secara diam-diam dan jenis mana yang butuh seseorang untuk menyadari dan bertindak.

event_params sebagai Map, atau diratakan: kapan masing-masing menang

Pelajaran nyata challenge kompresi bukan "terapkan sebuah codec" -- itu adalah ekstrak apa yang benar-benar Anda query ke kolom yang ditipekan dan dinamai, dan simpan sisanya di Map residual alih-alih menyimpan byte yang sama dua kali. Pelajaran itu berlaku umum di luar satu dataset ini.

Ratakan sebuah key menjadi kolomnya sendiri ketika Anda sudah tahu hari ini bahwa query akan memfilter atau mengelompokkan berdasarkannya -- page_location, ga_session_id, engagement_time_msec dalam kasus workshop ini. Kolom yang ditipekan mendapat codec-nya sendiri, bisa memimpin sort key, dan query planner bisa melakukan pruning langsung padanya. Biayanya adalah berkomitmen pada bentuk key itu sejak awal, dan kehilangan perbedaan antara "key ini absen" dan "key ini menyimpan value kosong atau nol" begitu ia ditarik ke kolom yang ditipekan non-nullable -- value selalu bisa direcover dari kolom khususnya, tapi kehadiran atau ketidakhadirannya umumnya tidak, begitu digabung ke default yang ditipekan.

Biarkan key tinggal di Map ketika Anda belum tahu apakah itu layak punya kolom khusus, atau ketika event_params memang schema-on-read untuk workload Anda -- seorang analyst yang mengeksplorasi key apa saja yang ada, atau key yang begitu jarang diquery sehingga kolom yang ditipekan menjadi overhead murni. Map berbiaya lebih per byte saat disimpan dan tidak bisa memimpin sort key atau di-pruning secara langsung, tapi tidak membuat Anda berkomitmen apa-apa. Kebanyakan schema event nyata berakhir dengan keduanya: sejumlah kolom yang ditipekan untuk apa yang disentuh setiap query dashboard, dan Map residual untuk long tail yang belum pernah diquery siapa pun.

Retention

Tidak ada apa pun di workshop ini yang menghapus satu baris pun. Pipeline produksi biasanya perlu: detail event mentah sering hanya berguna untuk window yang terbatas -- minggu hingga beberapa bulan, bergantung pada bisnisnya -- setelah itu biaya storage lebih besar dari nilai menyimpan detail row-level. Klausa TTL ClickHouse menyatakan itu langsung pada sebuah tabel (buang baris yang melewati usia tertentu) atau menggulungnya menjadi agregat yang lebih kasar alih-alih membuangnya sama sekali, yang adalah ide yang sama yang sudah diterapkan materialized view modul 06 pada sebuah dashboard: simpan granularitas yang dibutuhkan query live dekat dengannya, dan biarkan apa pun yang lebih kasar menyerap baris yang kalau tidak akan duduk di sana selamanya dengan detail penuh.

Koeksistensi, bukan penggantian

Ini adalah poin yang ditujukan seluruh workshop ini, dan ini bukan "pindahkan semuanya dari BigQuery."

BigQuery dibangun untuk pertanyaan yang tidak diantisipasi siapa pun, di atas data yang belum dimodelkan siapa pun, pada skala di mana provisioning cluster di awal tidak masuk akal. Modul 01 sudah mengakui ini dan memaksudkannya: zero operational surface, tanpa komitmen schema, arahkan ke petabyte dan tanyakan. Itu keunggulan nyata untuk analitik ad-hoc, eksploratif, schema-on-read, dan tidak ada apa pun di workshop ini yang mengubah itu.

ClickHouse dibangun untuk pertanyaan yang diajukan user nyata dengan memuat sebuah halaman: bentuk query yang sama, berulang-ulang, dari banyak orang sekaligus, di mana jawabannya harus kembali dalam milidetik dan pricing-nya harus bertahan ditanya sesering itu. Itulah bentuk yang dimodelkan setiap challenge di workshop ini -- profile lookup, live funnel dashboard -- dan itu bentuk yang tidak pernah dibangun untuk dilayani murah oleh pricing per-byte, per-job, dan latency dispatch job BigQuery pada request rate itu, seperti yang baru ditunjukkan benchmark di atas pada skala produksi nyata.

Arsitektur yang tepat menyimpan keduanya, masing-masing melakukan pekerjaan yang memang bagus dikerjakannya: BigQuery menyimpan eksplorasi ad-hoc, schema-on-read, skala petabyte; ClickHouse menyimpan serving layer yang customer-facing, konkuren, dan latency-bound di depannya. Tidak satu pun mengganti yang lain, dan migrasi yang mencoba membuat ClickHouse melakukan pekerjaan BigQuery -- atau sebaliknya -- menyelesaikan masalah yang salah.

Kirimkan schema Anda sendiri

Jika apa yang Anda lihat di workshop ini terlihat seperti workload Anda sendiri -- sebuah tabel event, dashboard yang diakses berulang kali user Anda, bill BigQuery yang skalanya mengikuti seberapa sering orang melihat sesuatu -- kirimkan schema dan volume data Anda ke kontak ClickHouse Anda. Yang kembali adalah sizing dan perbandingan biaya yang nyata terhadap angka Anda sendiri, bukan ekstrapolasi dari sample dataset publik. Itu langkah selanjutnya yang genuinely berguna, bukan gestur sales: benchmark yang dipublikasikan di atas tetap workload orang lain, dijalankan pada data orang lain. Tawaran yang sama, dilakukan dengan benar, menggantinya dengan schema produksi dan angka Anda sendiri.

Query paling lambat Anda sendiri

Kembali ke modul 01 dan teka-teki yang dibukanya -- BigQuery mem-prune scan-nya menjadi 4,455,256 byte dan tetap butuh 0.98 detik, sementara pertanyaan yang sama terhadap ClickHouse menjawab dalam 52 milidetik tanpa pruning sama sekali, dan 14 dengan materialized view. Sekarang sebutkan query di environment Anda sendiri yang berbentuk sama: yang sudah diketahui tim Anda lambat, yang ditunggu seorang customer atau kolega, yang diajukan dengan cara yang sama berulang-ulang oleh orang yang berbeda-beda. Query itu, bukan dataset ini, adalah yang layak untuk percakapan sizing di atas.

Selesai jika

Anda bisa menyebutkan, dalam satu kalimat masing-masing, apa yang berubah soal ingestion, schema, dan retention antara workshop ini dan pipeline nyata; Anda bisa mengatakan workload mana yang seharusnya dipertahankan BigQuery dan mana yang berpindah ke ClickHouse, dan mengapa; dan Anda punya query lambat spesifik dari environment Anda sendiri di kepala, bukan cuma dataset workshop ini. Lanjut ke Troubleshooting jika ada sesuatu di sepanjang jalan yang tidak berperilaku seperti yang dikatakan workshop ini.