02 Query di tempat
Baca export GA4 langsung dari object storage tanpa ingestion sama sekali, dan rasakan sendiri mengapa ini bukan cara yang tepat untuk menjalankan dashboard.
Tidak ada apa pun di modul ini yang bergantung pada apa yang Anda kerjakan di modul 01. Jika Anda baru menyusul, atau akun atau service Anda masih dalam proses setup, modul ini hanya membutuhkan SQL console yang berfungsi -- jalankan query di bawah begitu Anda punya salah satunya.
Bucket-nya
Dataset event GA4 yang sama, diekspor ke Parquet dan digeser lima tahun ke depan (lebih lanjut soal pergeseran ini di bawah), tinggal di public Google Cloud Storage bucket yang menerima anonymous read -- tanpa kredensial apa pun:
https://storage.googleapis.com/ch-workshop-bq-migration/ga4-events/*.parquetGunakan gcs(), bukan url(), untuk membacanya. gcs() melist bucket itu sendiri, sehingga
bisa mengekspansi glob * di seluruh object; url() mengambil satu resource HTTP dan sama
sekali tidak bisa melakukan glob, sehingga wildcard yang sama diam-diam tidak melakukan
apa-apa yang berguna dengannya.
Soal pergeseran lima tahun itu
Tanggal pada export ini digeser lima tahun ke depan dari dataset publik yang Anda query di
modul 01 -- 2025-11-01 sampai 2026-01-31, bukan 2020-11-01 sampai 2021-01-31 -- sehingga
tanggal seperti 11.11 dan 12.12 jatuh di dalam window ini. user_pseudo_id tidak digeser,
sehingga probe user dari modul 01 tetap ada secara identik di sini. Kedua kopi sama-sama
benar; jika Anda membandingkan sebuah tanggal antara keduanya, Anda membandingkan kopi yang
sudah digeser dengan kopi yang belum digeser, bukan menemukan bug.
Baca schema yang diekspor BigQuery
DESCRIBE TABLE gcs('https://storage.googleapis.com/ch-workshop-bq-migration/ga4-events/*.parquet', NOSIGN, 'Parquet');ClickHouse menginfer daftar kolom langsung dari metadata Parquet: setiap kolom kembali
sebagai Nullable, event_date adalah String, event_timestamp adalah Int64 mentah
berisi microsecond, dan field bersarang (event_params, items, device, geo,
ecommerce, traffic_source) kembali sebagai array of tuples dan tuples of tuples. Tidak
ada apa pun di sini yang dibentuk ulang untuk lab -- inilah bentuk asli export BigQuery sendiri.
Modul 03 mengubah inferensi yang sama ini menjadi sebuah CREATE TABLE.
Hitung jumlahnya
SELECT count()
FROM gcs('https://storage.googleapis.com/ch-workshop-bq-migration/ga4-events/*.parquet', NOSIGN, 'Parquet');Harapkan 4,295,584 -- seluruh export, dibaca tanpa tabel, tanpa database, dan tanpa langkah ingestion apa pun.
Query funnel pertama
SELECT event_name, count() AS n
FROM gcs('https://storage.googleapis.com/ch-workshop-bq-migration/ga4-events/*.parquet', NOSIGN, 'Parquet')
WHERE event_name IN ('view_item', 'add_to_cart', 'begin_checkout', 'purchase')
GROUP BY event_name
ORDER BY n DESC;Harapkan hasil ini, dalam urutan yang sama seperti ORDER BY n DESC -- funnel konversi yang
sama yang terus muncul kembali di workshop ini:
event_name | n |
|---|---|
view_item | 386,068 |
add_to_cart | 58,543 |
begin_checkout | 38,757 |
purchase | 5,692 |
Waktunya akan bervariasi bergantung ukuran service Anda dan jalur network ke bucket, tapi sebagai referensi, satu kali run terhadap service yang cukup sederhana tetap menjawab dengan cepat meskipun membaca Parquet langsung lewat network:
Mengapa ini bukan cara menjalankan dashboard
Setiap query di atas membaca ulang dan mem-parsing ulang object Parquet yang sama melalui network, dari awal, setiap kali -- tidak ada kopi lokal, tidak ada cache, dan tidak ada index di baliknya. Jalankan query count dua kali berturut-turut dan kedua run membayar biaya itu lagi. Ini cara yang sangat berguna untuk mengeksplorasi data yang belum Anda komitmenkan untuk di-ingest, dan ini adalah ClickHouse SQL yang nyata dan berfungsi terhadap object storage. Namun ini bukan yang Anda ingin berdiri di belakang dashboard yang diakses berulang kali oleh user nyata. Modul berikutnya memberi ClickHouse kopi dari baris-baris yang sama untuk dikerjakan.
Selesai jika
DESCRIBE TABLE mengembalikan daftar kolom tanpa tabel di baliknya, count() mengembalikan
4,295,584, dan keempat hitungan query funnel cocok dengan angka-angka di atas. Lanjut ke
03 Migrasi yang malas.
01 Kenapa ini lambat?
Pertanyaan yang sama diajukan ke BigQuery dan, nanti, ke ClickHouse -- dua jawaban yang sudah diukur sebelumnya, belum ada penjelasan, dan pernyataan lugas soal di mana BigQuery memang menang.
03 Migrasi yang malas
Biarkan ClickHouse menginfer schema export BigQuery sendiri, ingest tanpa diubah, dan lihat migrasi yang berfungsi tapi biasa-biasa saja.