Worksheet 1: Pemilihan engine MergeTree

Perkiraan waktu: 15–20 menit Referensi: Engine MergeTree

Konsep

Di Snowflake, Anda membuat tabel dan Snowflake yang memutuskan cara menyimpannya. Di ClickHouse, Anda yang memilih storage engine — dan pilihan ini menentukan kebenaran hasil, bukan sekadar performa.

Tiga engine yang Anda butuhkan untuk lab ini:

MergeTree — Engine dasar. Data disimpan dalam file kolumnar terurut. Tanpa deduplikasi. Gunakan ini ketika tabel bersifat insert-only atau ketika pipeline Anda mengelola update di luar tabel (misalnya, reload penuh pada setiap eksekusi dbt).

ReplacingMergeTree(version_col) — Memperluas MergeTree dengan deduplikasi latar belakang. Ketika baris dengan kunci ORDER BY yang sama berada di beberapa part, hanya baris dengan nilai version_col tertinggi yang dipertahankan setelah merge. Gunakan ini ketika baris bisa diperbarui dan Anda punya kolom yang naik secara monoton pada setiap update (misalnya, timestamp updated_at).

Jebakan penting: Deduplikasi bersifat asinkron. Sampai ClickHouse menjalankan merge latar belakang, versi lama dan versi baru dari sebuah baris hidup bersama. Selalu gunakan SELECT ... FINAL pada tabel ReplacingMergeTree untuk memaksa deduplikasi saat query.

AggregatingMergeTree — Memperluas MergeTree dengan penggabungan state agregat parsial. Gunakan ini ketika tabel menyimpan state agregat yang bisa digabungkan (misalnya, sketch HyperLogLog, quantile digest) dan Anda butuh agregasi latar belakang. Tidak diperlukan untuk lab NYC Taxi — tabel agregasinya dibangun ulang oleh dbt, bukan diakumulasi.

Pohon keputusan

Does the table receive UPDATE or DELETE operations?
│
├── No (insert-only)
│   └─► MergeTree()
│
└── Yes
    ├── Is there a timestamp/version column that increases on every update?
    │   ├── Yes → ReplacingMergeTree(version_col)
    │   └── No (e.g., full-reload dimension tables)
    │       └─► MergeTree()  — dbt handles upsert via atomic table swap (full rebuild)
    │
    └── Does the table store partial aggregate states (AggregateFunction types)?
        └── Yes → AggregatingMergeTree()

Model staging selalu berupa view

Di dbt + ClickHouse, model staging sebaiknya dimaterialisasi sebagai view, bukan tabel. View tidak memakan biaya penyimpanan dan selalu segar — ia hanya SQL yang disimpan, bukan objek fisik.

Latihan pemilihan engine di bawah mencakup model dbt lapisan analitik (tabel fakta, agregat, dimensi) dan Materialized View ClickHouse. Latihan ini tidak mencakup trips_raw maupun model staging:

• trips_raw adalah tabel dasar ClickHouse yang dibuat langsung oleh skrip migrasi (scripts/02_migrate_trips.py) — bukan model dbt. Ia memakai ReplacingMergeTree(_synced_at) karena skrip migrasi bisa mengulang sebuah batch dan menyisipkan ulang trip_id yang sama. Setelah cutover, producer yang hidup juga bisa mengulang pada kegagalan sementara; _synced_at DateTime DEFAULT now() memastikan tulisan terbaru yang menang.
• stg_trips adalah view dbt di atas trips_raw. Ia menerapkan SELECT ... FROM trips_raw FINAL untuk menyelesaikan duplikat yang belum ter-merge sebelum data mencapai model analitik di hilir. Tanggung jawab deduplikasi ada di sini — bukan di tabel staging ReplacingMergeTree.

Latihan: pemilihan engine untuk tabel NYC Taxi

Untuk setiap tabel di bawah, tentukan pola update-nya, identifikasi kolom versinya (jika ada), dan pilih engine yang menjaga tabel tetap benar. Lalu kerjakan pertanyaan penalaran setelah setiap baris terisi.

Loading worksheet...

Pindahkan ke migration-plan.md

Setelah Anda mengisi worksheet ini, salin keputusan engine Anda ke Bagian 3 dari migration-plan.md dan centang:

- [ ] Engine selection: completed