Belajar Data Engineer - Performance & Cost Optimization

#Pendahuluan

Setelah di episode 21 mengoptimasi Spark, kita perluas lensanya ke seluruh platform: query tuning di warehouse, keputusan arsitektur yang menentukan biaya bulanan, dan cara berpikir FinOps untuk data. Di era lakehouse cloud, biaya bukan sekadar tagihan — ia adalah output dari setiap keputusan teknis: schema, partisi, jenis compute, dan kebiasaan query.

Episode 22 menyatukan performa dan biaya menjadi satu disiplin. Kalian akan mempelajari teknik tuning query, memilih antara serverless dan provisioned, dan menerapkan FinOps — dengan praktik nyata memangkas biaya pipeline.

#Query Tuning: Scan Lebih Sedikit, Bayar Lebih Sedikit

Di warehouse, biaya query ≈ jumlah data yang di-scan. Prinsip pertama tuning: kurangi scan. Tiga teknik yang paling berdampak:

1. Predicate pushdown — filter di level engine/storage, bukan setelah data tiba di memori.
2. Column pruning — pilih kolom eksplisit, bukan SELECT *.
3. Pruning partisi — filter pada kolom partisi agar partisi lain tak tersentuh.

-- Boros: SELECT * tanpa filter partisi
SELECT * FROM analytics.orders;
 
-- Efisien: hanya kolom yang dibutuhkan, filter pada partisi
SELECT
    customer_id,
    SUM(amount) AS total
FROM analytics.orders
WHERE created_at >= '2026-08-01'
  AND created_at <  '2026-08-16'
GROUP BY customer_id;

Perhatikan: kalian sudah melihat pola ini di episode 9 — dan di episode 22 kita menjadikannya disiplin biaya, bukan sekadar teknik.

#Clustering dan Partitioning: Investasi Sekali, Hemat Setiap Hari

Partitioning & clustering (episode 9) adalah penghemat biaya terbesar di warehouse. Tapi bukan berarti "semakin banyak semakin baik" — ini masalah trade-off:

• Terlalu halus (partisi per jam, cluster 5 kolom) → overhead metadata dan banyak file kecil.
• Terlalu kasar (tanpa partisi) → setiap query memindai semuanya.

Pedoman praktis:

#Serverless vs Provisioned

Keputusan compute paling fundamental untuk biaya: serverless atau provisioned?

Beban tak terduga (analyst query acak)      → serverless
Beban stabil 24/7 (pipeline streaming)      → provisioned + auto-suspend saat idle
Mix (mayoritas ad-hoc)                       → serverless + budget alert

#FinOps untuk Data

FinOps adalah disiplin mengelola biaya cloud sebagai tim — bukan hanya tugas finance. Tiga pilar untuk data engineer:

1. Visibility — setiap pipeline tahu berapa biayanya. Tag resource (project, team, pipeline) sejak awal.
2. Ownership — tiap tim/pemilik dataset bertanggung jawab atas biayanya; bukan tagihan pusat yang tak jelas.
3. Optimization berkelanjutan — review bulanan: query apa yang paling mahal? tabel apa yang jarang dipakai?

SELECT
    job_id,
    user_email,
    total_bytes_processed,
    total_slot_ms,
    query
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE DATE(creation_time) >= CURRENT_DATE() - 7
ORDER BY total_bytes_processed DESC
LIMIT 20;

Tiga pertanyaan FinOps yang wajib dijawab setiap bulan:

• Query/table apa yang paling mahal? (temuan dari query di atas)
• Apakah biayanya sebanding dengan nilai yang dihasilkan?
• Bagaimana menguranginya? (materialisasi, partisi, throttle query ad-hoc)

#Praktik: Mengurangi Cost Pipeline

Studi kasus nyata: sebuah pipeline malam hari yang membengkak. Langkah pemangkasan:

1. Temukan biaya — tag pipeline, lihat breakdown: compute vs storage vs query.
2. Kurangi scan — tambahkan partisi per hari pada tabel fakta; ubah semua SELECT * menjadi kolom eksplisit.
3. Materialisasi query populer — dashboard yang memakai query sama 10 kali per hari di-ubah menjadi tabel materialized harian.
4. Turunkan compute idle — set auto-suspend 60 detik untuk warehouse yang sepi malam.
5. Terapkan budget alert — 50%, 90%, 100% dari anggaran, dengan notifikasi otomatis.

budget:
  amount: 2000000          # Rp 2 juta / bulan
  alerts:
    - percent: 50
      channels: [slack-data-team]
    - percent: 90
      channels: [slack-data-team, email-oncall]
    - percent: 100
      channels: [slack-data-team]

Hasil yang umum dicapai: biaya turun 30-50% tanpa mengubah SLA — hanya dengan disiplin scan, partisi yang tepat, dan menghilangkan idle.

#Kesalahan Umum (Common Pitfalls)

1. Mengoptimasi biaya di tempat yang salah. Tiga query raksasa biasanya menyumbang 80% biaya. Temukan itu dulu (FinOps visibility), jangan menyisir semua.

2. Serverless tanpa kontrol. Budget alert dan quota per tim adalah syarat mutlak untuk serverless.

3. Partisi berlebihan. Partisi per jam untuk tabel 1 juta baris justru lebih mahal. Ukur, jangan asal ikut tren.

4. Mengorbankan SLA demi biaya. Optimasi yang memutus SLO (episode 20) bukan optimasi. Ukur keduanya.

#Penutup

Di episode 22 ini kalian telah menyatukan performa dan biaya:

• Query tuning = kurangi scan: predicate pushdown, column pruning, pruning partisi.
• Partitioning/clustering adalah investasi sekali yang menghemat setiap hari — dengan trade-off yang dipahami.
• Serverless vs provisioned tergantung pola beban; serverless wajib disertai kontrol.
• FinOps data: visibility → ownership → optimasi berkelanjutan.
• Praktik: pemangkasan biaya 30-50% lewat partisi, materialisasi, dan budget alert.

Di episode 23 selanjutnya kita memasuki analitik kecepatan tinggi: real-time analytics (ClickHouse/Druid) — OLAP real-time, ClickHouse, dan streaming analytics, plus praktik membangun dashboard real-time. Sampai jumpa di episode 23!