Belajar Data Architect - Cost & FinOps Data

#Pendahuluan

Setelah di episode 13 kita mendefinisikan data product, sekarang kita membahas sisi yang sering dihindari para arsitek: biaya. Di 2026, tagihan cloud menjadi sorotan utama — dan platform data adalah salah satu penyumbang biaya terbesar sekaligus paling sulit diprediksi. Arsitek yang tidak paham biaya akan kehilangan kredibilitas saat proposalnya ditolak karena "terlalu mahal" tanpa bisa membela diri dengan angka.

Mengapa episode ini penting? Karena arsitektur dan biaya tidak bisa dipisahkan. Keputusan platform, format file, pola query, dan retention policy semuanya berdampak langsung pada tagihan bulanan. FinOps data adalah kemampuan menjelaskan di mana biaya pergi dan mengapa, serta mengoptimasi tanpa mengorbankan nilai.

#Di Mana Biaya Data Mengalir

STORAGE    → object storage, format, kompresi, tiering, retention
COMPUTE    → warehouse (per query / per second), cluster, notebook
INGESTION  → tool sinkronisasi, CDC, API calls
TOOLING    → orchestrator, catalog, quality tools, BI licenses
PERSONEL   → engineer time (termahal dan paling sering diabaikan)

Arah aliran biaya sering mengejutkan: storage itu murah, compute yang mahal. Query yang boros atau cluster yang menyala 24/7 bisa mendominasi tagihan — bukan data yang disimpan.

#Model Biaya per Platform

Contoh: di BigQuery, query yang SELECT * memindai seluruh kolom; query yang memilih 3 kolom memindai jauh lebih sedikit. Perbedaan yang sama-sama "benar" bisa berbeda biaya 10x.

-- MAHAL: memindai semua kolom
SELECT * FROM silver.sales WHERE order_date >= '2026-01-01';
 
-- MURAH: hanya kolom yang dibutuhkan
SELECT order_date, revenue FROM silver.sales
WHERE order_date >= '2026-01-01';

#Tagging dan Chargeback

Tanpa tagging, biaya platform adalah "black box" — tagihan datang, tidak ada yang tahu milik siapa. Tagging adalah fondasi FinOps data:

kunci       contoh nilai
domain      sales | finance | product | platform
team        tim-sales-data
env         prod | dev | staging
workload    pipeline | dashboard | ml | adhoc
cost_center CC-42

Dengan tagging konsisten, biaya bisa dipulangkan (chargeback) ke tiap domain — dan tanggung jawab optimasi ikut menyebar. Tim yang tahu biaya query mereka sendiri akan mengoptimasi sendiri.

domain    storage   compute   total
sales      120       890      1010
finance     80       540       620
product     60       310       370
platform   200       420       620
→ total per bulan: USD 2620

#Optimasi Compute Data

Kebocoran biaya terbesar biasanya di compute. Teknik yang paling berdampak:

#1. Hidupkan Compute Hanya Saat Dipakai

- Warehouse/notebook dimatikan otomatis saat idle (auto-suspend)
- Cluster batch hanya menyala pada jendela schedule (misal 02:00-05:00)
- Query ad-hoc dialihkan ke warehouse/engine terpisah yang murah

#2. Partisi dan Clustering

Data dipartisi (misal per tanggal) sehingga query hanya membaca partisi yang dibutuhkan:

tanpa partisi:  query bulan Januari memindai 12 bulan data
dengan partisi: query bulan Januari memindai 1/12 data → biaya turun 12x

#3. Materialisasi yang Cerdas

Agregasi yang sering dipakai (misal revenue per hari) sebaiknya di-materialisasi sebagai tabel gold — bukan dihitung ulang setiap query. Biaya sekali di pipeline lebih murah daripada ribuan query berulang.

#4. Format dan Kompresi

Format kolom (Parquet) dengan kompresi (zstd) memangkas storage dan waktu scan secara bersamaan.

#Retention dan Tiering

Data tidak perlu disimpan selamanya di storage mahal. Arsitek menetapkan data lifecycle policy:

gold layer      → disimpan 2 tahun di platform (partisi per bulan)
silver/bronze   → 6 bulan; lalu dipindah ke object storage dingin
raw logs        → 30 hari; lalu kompresi + arsip dingin
backup          → rotasi otomatis, expired sesuai kebutuhan

Aturan emas: tanya dulu siapa yang butuh data ini dan untuk berapa lama sebelum memutuskan menyimpan. Retention yang terlalu lama = biaya storage yang tidak menghasilkan nilai.

#Praktik: Audit Biaya Data

#Step 1: Kumpulkan Data Biaya

Ekspor tagihan per platform, gabungkan dengan tag per resource, dan breakdown per domain/workload.

#Step 2: Identifikasi Anomali

- compute yang menyala 24/7 padahal workload batch
- query dengan bytes_processed raksasa berulang
- dataset yang jarang diakses tapi disimpan besar
- duplikasi storage antar env tanpa alasan

#Step 3: Hitung Dampak Optimasi

anomali                       dampak/bulan   aksi
cluster dev nyala 24/7        USD 350        auto-suspend after 30 min idle
3 query boros berulang        USD 420        rewrite + materialize
dataset X tak terpakai 2 th   USD 180        pindah ke cold storage
duplikasi test vs prod        USD 90         cleanup policy

#Step 4: Tetapkan Target dan Review

Tetapkan target penghematan kuartalan dan review bulanan. FinOps bukan proyek sekali jalan — biaya selalu merambat naik jika tidak dijaga.

#Penutup

Inti yang harus dibawa pulang:

• Biaya data mengalir di storage, compute, ingestion, tooling, dan personel — compute paling dominan.
• Tagging + chargeback menghadirkan biaya dan menyebarkan tanggung jawab optimasi.
• Optimasi compute: auto-suspend, partisi, materialisasi, format kolom.
• Data lifecycle policy mencegah penyimpanan tanpa nilai.
• Audit berkala dengan target penghematan kuartalan dan review bulanan.

Di episode 15 selanjutnya kita akan membahas Migration & Modernization — bagaimana memindahkan dan meremajakan platform data lama tanpa menghentikan operasional bisnis. Sampai jumpa di episode 15!