Belajar Data Analyst - SQL untuk Warehouse (BigQuery/Snowflake)

#Pendahuluan

Hingga episode 15 kalian berlatih di database kecil (PostgreSQL lokal). Di dunia nyata, data analis hidup di data warehouse cloud: BigQuery, Snowflake, atau Redshift, tempat miliaran baris disimpan dan dianalisis. Perbedaannya bukan sekadar "lebih besar" — arsitektur, dialect SQL, dan cara berpikir tentang biaya semuanya berubah.

Episode ini menjembatani SQL yang sudah kalian kuasai ke skala warehouse. Fokusnya tiga hal: memahami mengapa warehouse berbeda dari OLTP, menulis query untuk data raksasa (dengan dialect modern), dan mengendalikan biaya — karena di cloud, query yang ceroboh adalah tagihan yang menyakitkan.

#Warehouse vs OLTP: Beda Arsitektur, Beda Pola Query

Database operasional (OLTP) dan data warehouse dirancang untuk pekerjaan yang berlawanan:

Kunci teknisnya: warehouse menyimpan data kolumnar, sehingga membaca satu kolom dari miliaran baris itu murah — asalkan kalian hanya memilih kolom yang dibutuhkan. Ini mengubah kebiasaan SQL kalian: SELECT * yang tidak berbahaya di OLTP bisa jadi mahal di warehouse.

#Dialect Warehouse: BigQuery dan Snowflake

Semua warehouse memakai SQL, tetapi dengan dialect yang sedikit berbeda. Contoh memakai BigQuery:

SELECT
    FORMAT_DATE('%Y-%m', order_date) AS bulan,
    COUNT(DISTINCT customer_id) AS customers,
    SUM(amount) AS revenue
FROM `project.dataset.orders`
WHERE order_date >= '2026-01-01'
GROUP BY bulan
ORDER BY bulan;

Perhatikan FORMAT_DATE (pengganti to_char), dan nama tabel berformat project.dataset.tabel dengan backtick. Di Snowflake tabel berbentuk database.schema.table:

SELECT
    DATE_TRUNC('month', order_date) AS bulan,
    COUNT(DISTINCT customer_id) AS customers,
    SUM(amount) AS revenue
FROM analytics.dbt_orders
WHERE order_date >= '2026-01-01'
GROUP BY bulan
ORDER BY bulan;

Jangan panik dengan perbedaan kecil — kalian belajar sekali, dialect tinggal disesuaikan. Sebagian besar konsep episode 3-4 (JOIN, window, CTE) berlaku persis sama.

#Query untuk Data Raksasa: Kebiasaan Baru

Di dataset miliaran baris, tiga kebiasaan ini menjadi wajib:

#1. Select Hanya yang Dibutuhkan

SELECT customer_id, amount, order_date
FROM `project.dataset.orders`
WHERE order_date >= '2026-06-01';

#2. Partisi dan Filter Sejak Dini

Warehouse besar hampir selalu dipartisi (misal per tanggal). Filter pada kolom partisi membuat query hanya membaca bagian yang relevan:

SELECT SUM(amount) AS revenue
FROM `project.dataset.orders`
WHERE order_date BETWEEN '2026-06-01' AND '2026-06-30';  -- baca 1 bulan, bukan 3 tahun

#3. Minimalkan JOIN yang Boros

Join di warehouse adalah operasi mahal. Kurangi dengan memfilter dan meng-agregasi sebelum join, serta memahami kardinalitas tabel (mana fakt, mana dimensi).

#Mengendalikan Biaya Query

Di cloud, biaya sebanding dengan volume data yang dipindai (BigQuery) atau waktu komputasi (Snowflake). Tiga senjata pengendali biaya:

Di BigQuery kalian bisa melihat estimasi data yang dipindai sebelum eksekusi:

-- Klik "Query settings" → centang "Dry run" (BigQuery console)
SELECT COUNT(*) FROM `project.dataset.events`;  -- tampil "This query will process ~2.1 TB"

Estimasi dry run ini menjadi kebiasaan defensif terbaik: kalian tahu biaya sebelum data dipindai. Di Snowflake, ekuivalennya adalah memeriksa CREDITS_USED per query dan QUERY_PROFILE untuk menemukan langkah yang boros.

#Warehouse dan Pola Analis

Sebagian besar analis tidak menulis SELECT di warehouse langsung setiap hari — mereka memakai lapisan di atasnya:

• BI tool (episode 11) menerjemahkan klik ke query warehouse.
• dbt (episode 17) membangun tabel transformasi di dalam warehouse.
• Semantic layer (episode 23) menyediakan metrik terstandar.

Posisi kalian sebagai analis adalah pengguna cerdas lapisan-lapisan ini: memahami apa yang terjadi di balik layar, mampu menulis query manual saat perlu, dan tahu kapan harus berkolaborasi dengan data engineer.

#Kesalahan Umum

• SELECT * di tabel raksasa. Pilih kolom; warehouse kolumnar menghargai selektivitas.
• Filter pada kolom non-partisi. Query membaca seluruh tabel secara diam-diam.
• Join sebelum filter. Kurangi data dulu, baru gabungkan.
• Mengabaikan biaya. Di warehouse, "menjalankan saja" bukan tanpa konsekuensi.

#Penutup

Inti yang harus dibawa pulang:

• Warehouse dirancang untuk analisis kolumnar skala besar; OLTP untuk transaksi.
• Dialect berbeda (BigQuery vs Snowflake), konsep tetap sama.
• Query efisien: select terbatas, filter partisi, minimalkan join boros.
• Biaya dikendalikan dengan dry run, tabel ringkas, dan kesadaran data yang dipindai.

Di episode 17 selanjutnya kalian memasuki skill paling dicari untuk analis tahun 2026: dbt & Analytics Engineering — transformasi SQL sebagai kode dengan model, test, dan version control, plus membangun pipeline transformasi pertama. Warehouse sudah kalian pahami; sekarang saatnya memproduksi data dengan benar!