Belajar Database Administrator - Ops untuk Data Warehouse

#Pendahuluan

Sejauh ini kita mengelola database transaksional (OLTP): aplikasi menulis dan membaca baris per baris. Di episode 25 kita memasuki dunia berbeda — data warehouse: tempat data dari banyak sistem berkumpul untuk dianalisis. Peran DBA di sini berbeda: bukan menjaga transaksi lancar, tapi memastikan query analitik raksasa cepat dan biayanya terkendali.

Warehouse bukan sekadar "database besar". Cara kerjanya, model biayanya, dan alat optimasinya hampir semuanya berbeda. Episode ini membangun fondasi operasi warehouse dengan Snowflake dan BigQuery sebagai contoh utama.

#OLTP vs OLAP: Dua Dunia Berbeda

Warehouse mengoptimalkan scan dan agregasi. Karenanya ia memakai penyimpanan columnar: nilai per kolom disimpan berdekatan, sehingga agregasi SUM(harga) hanya membaca kolom itu — bukan seluruh baris.

#Arsitektur Warehouse: Storage dan Compute Terpisah

Kunci arsitektur warehouse modern (Snowflake, BigQuery, Redshift Spectrum) adalah pemisahan storage dan compute. Data disimpan di object storage (S3/GCS) dengan format columnar (Parquet/Avro), dan klaster komputasi "menyala" hanya saat query berjalan. Inilah yang membuat warehouse bisa autoscale dan bayar per pemakaian.

Imbasnya untuk DBA:

• Scaling tanpa migrasi data: tambah node compute kapan saja, data tetap di tempatnya.
• Biaya = compute saat query + storage: query mahal = biaya mahal. Kontrolnya bukan storage, tapi kebiasaan query.
• Keamanan dan metadata terpusat: access control (episode 9) diterapkan di layer metadata warehouse, bukan di file.

#Snowflake: Virtual Warehouse dan Auto Suspend

Snowflake memperkenalkan konsep Virtual Warehouse — kumpulan node compute yang dihidupkan per query session:

CREATE WAREHOUSE analytics_wh
    WITH WAREHOUSE_SIZE = 'X-SMALL'
         AUTO_SUSPEND = 60
         AUTO_RESUME = TRUE;

• AUTO_SUSPEND = 60: warehouse mati otomatis setelah 60 detik idle — penghematan biaya terbesar.
• AUTO_RESUME = TRUE: menyala otomatis saat query datang — dengan konsekuensi latensi "cold start".
• Ukuran warehouse menaikkan paralelisme, bukan kecepatan per query tunggal — query lambat lebih baik diperbaiki daripada sekadar membesarkan warehouse.

#BigQuery: Slot dan Query Cache

BigQuery memakai slot (unit komputasi) yang dialokasikan per project. Prinsip operasinya:

• On-demand: bayar per byte yang di-scan — query murah adalah query yang tidak membaca data yang tidak perlu.
• Flat-rate: bayar slot tetap untuk beban stabil — setara commitment discount (episode 23).
• Query cache: hasil query yang sama dengan data yang sama dilayani dari cache selama 24 jam — gratis.

Optimasi paling berdampak: prune data sebelum query. BigQuery menghitung biaya dari data yang di-scan, jadi partition dan clustering (di bawah) adalah alat penghemat biaya sekaligus kecepatan.

#Partition dan Clustering: Pruning untuk Analitik

Di warehouse, dua mekanisme memangkas data yang dibaca:

• Partition: membagi tabel berdasarkan kolom (biasanya tanggal). Query WHERE date = '2026-08-01' hanya membaca partisi itu.
• Clustering key: mengurutkan baris dalam partisi berdasarkan kolom tertentu, sehingga filter pada kolom itu membaca blok lebih sedikit.

CREATE TABLE app.events (
    event_time TIMESTAMP,
    event_type STRING,
    payload JSON
)
PARTITION BY DATE(event_time)
CLUSTER BY event_type;

Aturan praktis: partition pada kolom yang di-filter luas (hari/bulan), cluster pada kolom yang di-filter di dalam partisi (tipe event, tenant). Kebalikannya — cluster di kolom tanggal — hampir tidak memberi manfaat.

#Metadata dan Data Quality: Tanggung Jawab yang Bergeser

Warehouse hidup mati dari metadata: deskripsi tabel, kolom, owner, dan lineage (darimana data berasal). Tanpa metadata, warehouse berubah jadi "data swamp" — data ada tapi tidak ada yang percaya. Praktiknya:

• Catalog dan lineage: dokumentasikan tabel dan asal-usulnya (misal OpenMetadata, DataHub).
• Data quality checks: bukan sekadar "query jalan", tapi data benar — cek NULL rate, kardinalitas, dan anomali pada data penting.
• Transformasi terkelola: alat seperti dbt membuat transformasi SQL menjadi kode yang versioned (pola episode 17) — model didefinisikan sebagai SQL, diuji, lalu di-deploy.

version: 2
models:
  - name: daily_sales
    tests:
      - not_null:
          column_name: order_date
      - unique:
          column_name: order_id

#Praktik: Administrasi Warehouse Mini

Rancang warehouse mini dengan prinsip yang sama:

1. Pilih tabel analitik inti (misal transaksi) dan buat partition + clustering yang sesuai.
2. Susun model transformasi (dbt atau SQL biasa) yang clean, testable, dan versioned.
3. Terapkan access control: analis hanya bisa baca model yang dibutuhkan (least privilege, episode 9).
4. Aktifkan fitur hemat biaya: auto suspend (Snowflake), query cache (BigQuery), batasi scan data.
5. Buat monitor penggunaan: siapa yang menjalankan query mahal, berapa slot/jam per tim — lalu alokasikan ke pemilik biaya (episode 23).

#Penutup

Inti yang harus dibawa pulang:

• OLTP mengoptimalkan transaksi; warehouse mengoptimalkan scan dan agregasi.
• Storage dan compute terpisah → scaling tanpa migrasi, biaya per pemakaian.
• Snowflake: virtual warehouse dengan auto suspend; BigQuery: slot dan query cache.
• Partition + clustering = pruning data yang dibaca = cepat dan murah sekaligus.
• Metadata, data quality (dbt), dan monitoring penggunaan menjadikan warehouse yang sehat.

Di episode 26 selanjutnya kita menutup fase teknis dan melihat peta besar: ekosistem & tren modern 2026 — managed database, serverless, AI/vector, dan bagaimana peran DBA bergeser menjadi cloud database manager. Sampai jumpa di episode 26!