Belajar Data Engineer - Data Warehouse (Snowflake/BigQuery/Redshift)

#Pendahuluan

Di episode 8 kalian telah mengorkestrasi pipeline batch dengan Airflow. Tapi ke mana data itu dimuat? Di episode 6 kita memakai PostgreSQL sebagai "warehouse" — itu cukup untuk belajar, tapi warehouse produksi adalah kelas yang berbeda. Episode ini membuka pintu ke data warehouse cloud: mengapa ia dibuat terpisah, bagaimana Snowflake/BigQuery/Redshift bekerja, dan bagaimana kalian membuat query serta tagihan tetap sehat.

Mengapa topik ini penting? Karena warehouse adalah jantung serving layer dari seluruh arsitektur data. Keputusan di sini — partitioning, clustering, pemilihan teknologi — berdampak langsung pada performa dashboard dan biaya bulanan. Data engineer yang menguasai warehouse adalah aset langka.

#Mengapa Warehouse Cloud Menang

Warehouse modern (Snowflake, BigQuery) dibangun di atas satu ide revolusioner: memisahkan storage dari compute.

• Storage: data disimpan di object storage (S3/GCS) dalam format kolumnar — murah, elastis, tak terbatas.
• Compute: engine query (cluster/warehouse) di-hidupkan hanya saat ada query — bayar sesuai pemakaian, bisa diskalakan terpisah.

Dampaknya luar biasa: storage bisa berisi terabyte dengan biaya rendah, sementara compute bisa "tidur" saat tidak ada pekerjaan. Inilah yang membuat ELT dengan data mentah di warehouse menjadi praktis (episode 6).

#Perbandingan Tiga Warehouse Utama

Ketiganya sama-sama kolumnar dan memakai SQL. Pilihan biasanya ditentukan oleh ekosistem cloud yang sudah dipakai organisasi — bukan murni teknis.

#Partitioning dan Clustering

Di dunia warehouse kolumnar, dua mekanisme menentukan kecepatan query: partitioning dan clustering/sorting. Keduanya bekerja dengan prinsip yang sama: hindari memindai data yang tidak dibutuhkan.

#Partitioning

Membagi tabel secara fisik berdasarkan kolom (biasanya tanggal), sehingga query yang memfilter satu partisi hanya membaca sebagian kecil data.

CREATE TABLE analytics.orders
PARTITION BY DATE(created_at)
AS SELECT * FROM staging.orders;

CREATE TABLE analytics.orders
CLUSTER BY (created_at);

Partisi harian adalah default yang tepat untuk sebagian besar tabel fakta. Tapi hati-hati: terlalu banyak partisi kecil (misalnya per jam untuk tabel kecil) justru memperlambat query karena overhead metadata.

#Clustering

Mengurutkan baris dalam partisi berdasarkan kolom tertentu, sehingga filter pada kolom itu bisa melompati blok yang tidak relevan:

CREATE TABLE analytics.orders
PARTITION BY DATE(created_at)
CLUSTER BY customer_id
AS SELECT * FROM staging.orders;

Aturan praktis: partisi untuk kolom waktu (paling sering difilter), cluster untuk kolom kardinalitas sedang yang sering difilter bersamaan (customer_id, store_id, region).

#Cost Management: Membaca Tagihan dengan Benar

Biaya warehouse bukan misteri — ia mengikuti data yang di-scan dan compute yang dipakai. Empat prinsip pengendalian biaya:

1. Ukur bytes processed — di BigQuery, setiap query menagih data yang di-scan. Biasakan SELECT hanya kolom yang dibutuhkan, bukan SELECT *.
2. Pakai partitioning/clustering dengan benar — memotong scan adalah penghemat terbesar.
3. Batasi query ad-hoc — SELECT * FROM table oleh analyst bisa menghabiskan kuota harian. Sediakan data mart yang sudah teragregasi.
4. Suspend idle compute — di Snowflake, set auto-suspend 60 detik agar warehouse tidak berbayar saat menganggur.

-- Dry run menghitung bytes yang akan di-scan tanpa menjalankan query
bq query --dry_run --use_legacy_sql=false "SELECT * FROM analytics.orders"

Perintah di atas adalah cara paling cepat tahu apakah query kalian boros — sebelum benar-benar menjalankannya. Topik optimasi biaya menyeluruh kita bahas di episode 22.

#Praktik: Optimasi Query di Warehouse

Mari optimasi satu query dari "boros" menjadi "efisien":

SELECT
    customer_id,
    DATE(created_at) AS order_date,
    SUM(amount) AS total
FROM analytics.orders
WHERE amount > 100
GROUP BY customer_id, DATE(created_at);

Masalahnya: filter amount > 100 tidak memanfaatkan partisi maupun clustering, sehingga database memindai semua partisi. Versi optimasi:

SELECT
    customer_id,
    DATE(created_at) AS order_date,
    SUM(amount) AS total
FROM analytics.orders
WHERE created_at >= TIMESTAMP('2026-08-01')
  AND created_at <  TIMESTAMP('2026-09-01')
  AND customer_id IN (101, 202, 303)
GROUP BY customer_id, DATE(created_at);

Perbedaan prinsipnya: pindahkan filter ke kolom partisi/cluster. Alih-alih memindai 30 hari penuh (atau seluruh tabel), query kini hanya membaca partisi Agustus dan blok-blok customer yang relevan — scan berkurang drastis, biaya ikut turun.

#Kesalahan Umum (Common Pitfalls)

1. SELECT * di warehouse. Setiap kolom yang di-scan berbayar. Pilih kolom secara eksplisit.

2. Partisi tanpa kebutuhan filter. Mempartisi kolom yang tidak pernah difilter hanya menambah overhead metadata.

3. Mengabaikan perbedaan antara warehouse. Sintaks partitioning di BigQuery vs Snowflake vs Redshift berbeda — jangan copy-paste antar platform tanpa adaptasi.

4. Tidak membaca query plan/biaya. Warehouse menyediakan tools (BigQuery dry run, Snowflake query profile) untuk melihat boros/tidaknya query. Biasakan memakainya.

#Penutup

Di episode 9 ini kalian telah menguasai warehouse cloud:

• Pemisahan storage & compute adalah fondasi warehouse modern — storage murah, compute elastis.
• Snowflake/BigQuery/Redshift berbeda di model compute dan pricing; pilih berdasarkan ekosistem organisasi.
• Partitioning memotong data berdasarkan waktu; clustering mengurutkan dalam partisi untuk filter cepat.
• Cost management: scan lebih sedikit = bayar lebih sedikit. SELECT eksplisit, partisi tepat, suspend idle compute.
• Praktik optimasi: pindahkan filter ke kolom partisi/cluster.

Di episode 10 selanjutnya kita membangun untuk volume yang lebih besar: data lake & lakehouse (Spark/Databricks) — format file Parquet/Avro, tabel Iceberg & Delta Lake, serta batch processing dengan PySpark. Sampai jumpa di episode 10!