Belajar Data Architect - Data Warehouse vs Data Lake vs Lakehouse

#Pendahuluan

Setelah di episode 3 kita menguasai modeling data — termasuk Data Vault untuk raw layer dan star schema untuk konsumsi — pertanyaan berikutnya yang harus dijawab seorang arsitek: di mana data itu hidup? Jawabannya membentuk fondasi platform: data warehouse, data lake, atau lakehouse.

Keputusan ini adalah salah satu keputusan paling strategis dan paling sulit diubah. Memindahkan platform data adalah proyek multi-bulan dengan risiko tinggi. Karena itu, arsitek harus memahami mengapa ketiga arsitektur ini lahir, apa yang mereka selesaikan, dan apa trade-off masing-masing — bukan sekadar mengikuti tren.

#Data Warehouse

Warehouse lahir di era BI (1990-an): penyimpanan terstruktur yang dioptimasi untuk query analitik cepat. Data di-ETL terlebih dahulu: dibersihkan, diubah, dan dimuat dalam skema yang sudah jadi (biasanya star schema).

100%

Kelebihan: query cepat, konsisten, aman, mudah dipakai BI. Kekurangan: mahal per-terabyte, skema kaku (schema-on-write — data harus dipahami sebelum disimpan), dan kurang cocok untuk data tidak terstruktur seperti log, gambar, atau dokumen.

#Data Lake

Lake lahir dari kebutuhan menyimpan data mentah dalam jumlah besar dengan murah — biasanya object storage (S3/GCS/ADLS) dengan format seperti Parquet/JSON. Prinsipnya: simpan dulu, pahami belakangan (schema-on-read).

Struktur data lake

s3://data-lake/
  raw/            -- data mentah apa adanya
  curated/        -- data yang sudah dirapikan
  analytics/      -- siap dipakai analisis

Kelebihan: murah, fleksibel untuk semua format data, ideal untuk machine learning dan pemrosesan besar. Kekurangan: mudah jadi data swamp (data tidak jelas isinya), kualitas dan konsistensi jelek tanpa governance, dan query langsung lambat tanpa tuning.

Warning

"Data lake" tanpa governance adalah resep data swamp: data menumpuk, tidak ada yang tahu isinya, tidak ada yang berani memakai. Arsitek yang membangun lake wajib membangun katalog, kualitas, dan zona yang jelas sejak hari pertama — bukan setelah kacau.

#Lakehouse

Lakehouse (dipopulerkan Databricks, 2020) mencoba menggabungkan yang terbaik keduanya: storage murah ala lake + keandalan dan performa ala warehouse. Kuncinya ada di open table format seperti Delta Lake, Apache Iceberg, atau Apache Hudi — yang menambahkan transactional layer di atas object storage.

Kemampuan	Warehouse	Lake	Lakehouse
Biaya storage	Mahal	Murah	Murah
Query cepat	✔	✘ (butuh tuning)	✔
Data tidak terstruktur	✘	✔	✔
ACID transactions	✔	✘	✔
Format open / tanpa lock-in	✘	✔	✔
Mendukung AI/ML	Terbatas	✔	✔
Kematangan tooling	Tinggi	Tinggi	Bertumbuh

Lakehouse menjawab masalah klasik: perusahaan tidak perlu lagi punya dua sistem terpisah — warehouse untuk BI dan lake untuk ML — yang saling menduplikasi data dan tidak pernah konsisten. Dengan lakehouse, satu storage bisa melayani keduanya.

100%

#Praktik: Memilih Arsitektur

Tidak ada arsitektur yang "paling benar" secara universal — ada yang paling cocok untuk kondisi organisasi. Gunakan langkah berikut:

#Step 1: Kategorikan Beban Kerja

Beban Kerja	Contoh	Arsitektur Paling Cocok
Laporan BI reguler	Revenue per hari, top product	Warehouse / lakehouse gold layer
Analytics mendalam	Cohort, funnel analysis	Lakehouse
Machine learning	Training dataset	Lake / lakehouse
Data tidak terstruktur	Log, dokumen, gambar	Lake
Data real-time	Streaming events	Lake (raw) + lakehouse (curated)
BI sederhana perusahaan kecil	Dashboard satu tim	Warehouse biasa cukup

#Step 2: Nilai Empat Faktor

Faktor penentu pilihan

1. Ukuran & jenis data       → besar + tidak terstruktur? → lake/lakehouse
2. Kebutuhan query BI        → berat & butuh latency rendah? → warehouse/lakehouse
3. Kebutuhan AI/ML           → training model? → lakehouse/lake
4. Budget & skill tim        → vendor terkelola? harga per query? platform mana

#Step 3: Skor dan Putuskan

Contoh skenario kecil

skenario: startup e-commerce, tim data 3 orang, data < 1 TB
  ukuran data      → 2   (kecil, terstruktur)
  beban BI         → 5   (banyak dashboard real-time)
  kebutuhan AI     → 2   (belum ada)
  budget           → 3   (sedang)
→ hasil: warehouse terkelola (BigQuery/Snowflake) paling masuk akal
 
skenario: korporasi besar, data multi-PB, ML aktif, log menumpuk
  ukuran data      → 5   (besar, campuran)
  beban BI         → 4   (banyak tapi bisa batch)
  kebutuhan AI     → 5   (ML & LLM aktif)
  budget           → 5   (besar, punya tim platform)
→ hasil: lakehouse (Databricks/EMR + Iceberg/Delta) paling masuk akal

Tip

Pola yang paling umum di industri besar 2026: lakehouse sebagai single source of truth, dengan model Data Vault di lapisan curated (episode 3), lalu star schema untuk konsumsi BI. Warehouse murni tetap dipakai untuk beban kecil yang butuh simplicity maksimum.

#Penutup

Inti yang harus dibawa pulang:

Warehouse: cepat, konsisten, mahal, untuk BI — schema-on-write.
Lake: murah, fleksibel, rawan jadi swamp — schema-on-read.
Lakehouse: storage murah + ACID + query cepat via open table format.
Pilih arsitektur berdasarkan beban kerja, ukuran data, kebutuhan AI, dan budget, bukan tren.

Di episode 5 selanjutnya kita akan membahas Cloud Data Platforms — perbandingan BigQuery, Snowflake, Databricks, dan Redshift, arsitektur masing-masing, dan cara mengevaluasi platform untuk organisasi kalian. Sampai jumpa di episode 5!