Memilih Arsitektur Lakehouse

Section ini telah membekali kita dengan semua komponen: object storage, zona data, partitioning, tiga table format, schema enforcement, dan time travel. Pertanyaan penutupnya praktis: arsitektur mana yang harus dipilih untuk sebuah konteks nyata? Jawaban yang berbasis selera — misalnya membangun lakehouse karena sedang banyak dibicarakan — menghasilkan infrastruktur berat untuk data 5 GB per hari, atau sebaliknya: warehouse mahal untuk beban ML yang membaca berkas mentah. Bab ini merangkum pilihan menjadi satu kerangka keputusan yang bisa dihitung, lalu menutupnya dengan studi kasus dan pemilihan table format.

Tiga Opsi Arsitektur #

Aspek	Warehouse-only	Lake-only	Lakehouse
Lokasi penyimpanan utama	warehouse analitik (Snowflake, BigQuery, Redshift)	object storage berzona (raw, curated)	object storage + table format
Biaya storage per TB	paling mahal	paling murah	murah, setara lake
Query SQL analitik	tercepat, fitur terlengkap	tidak tersedia tanpa engine tambahan	baik lewat engine yang membaca table format
Akses data mentah untuk ML	terbatas, harus dimuat ulang	langsung dari berkas	langsung, namun terkelola schema
Transaksi dan time travel	bawaan warehouse	tidak ada	bawaan table format
Beban operasional	rendah, dikelola vendor	tinggi: tim mengelola zona dan berkas	sedang: tim mengelola kompaksi dan retensi

Baris terakhir itulah harga yang paling sering luput dari perhitungan: lakehouse bukan warehouse gratis, melainkan penukar beban — biaya storage turun, tanggung jawab operasional naik. Kerangka keputusan di bawah ini memasukkan faktor tersebut secara eksplisit.

Faktor Keputusan #

Lima pertanyaan berikut menentukan arah, dan setiap faktor bisa diukur sebelum arsitektur dibangun:

Volume — berapa gigabyte per hari yang masuk; di bawah puluhan GB, warehouse hampir selalu lebih murah dari mengoperasikan lake.
Beban ML pada data mentah — apakah pelatihan model membaca data mentah besar (telemetri, citra, log) yang tidak praktis dimuat ke warehouse.
Tim — tim analis kuat di SQL, atau tim engineering berorientasi berkas dan Python.
Biaya — seberapa sensitif anggaran terhadap harga storage dan kredit compute.
Investasi yang sudah ada — warehouse, lisensi, dan keahlian yang telah dibeli; migrasi total memiliki biaya tersendiri.

Diagram berikut merangkum alur keputusan menjadi bentuk yang bisa diskusikan bersama tim:

flowchart TD A[Mulai: rancang arsitektur data] --> B{Volume di atas 500 GB per hari?} B -- Tidak --> C{Warehouse analitik sudah tersedia?} C -- Ya --> D[Warehouse-only] C -- Tidak --> D2[Warehouse-only: mulai dari warehouse ringan] B -- Ya --> E{ML membutuhkan data mentah?} E -- Tidak --> F{Beban SQL analitik dominan?} F -- Ya --> G[Lakehouse: table format di object storage] F -- Tidak --> H[Lake: zona raw dan curated] E -- Ya --> I{Tim juga butuh query SQL?} I -- Ya --> G I -- Tidak --> H

Memilih Table Format #

Jika keputusan jatuh ke lakehouse, pertanyaan berikutnya adalah format tabelnya:

Format	Diciptakan di	Kekuatan khas	Dibaca baik oleh
Apache Iceberg	Netflix	metadata berlapis, partition evolution	Spark, Trino, Flink, DuckDB
Delta Lake	Databricks	log JSON sederhana, ekosistem matang	Spark, Trino, delta-rs
Apache Hudi	Uber	upsert tingkat record, latensi rendah	Spark, Flink

Tiga pertimbangan praktis mengurutkan pilihannya. Pertama, ekosistem engine: pilih format yang dibaca bawaan oleh engine yang sudah dipakai tim — ketiga format terbuka, tetapi kedalaman dukungannya berbeda antar-engine. Kedua, komunitas: ketiganya adalah project Apache dengan versi stabil (Iceberg 1.x, Delta 3.x, Hudi 1.x menurut catatan riset course ini). Ketiga, pendukung di belakangnya: Delta dimotori Databricks, Iceberg didukung luas lintas vendor warehouse, dan Hudi kuat di jalur streaming. Pola akses menjadi pemutus akhir: beban update baris yang frekuen condong ke Hudi, sedangkan beban batch besar nyaman di Delta atau Iceberg. Rujukan resminya ada di dokumentasi Iceberg , dokumentasi Delta Lake , dan dokumentasi Hudi .

Menerapkan Kerangka: Tiga Studi Kasus #

Fungsi berikut menerjemahkan lima faktor menjadi skor sederhana; opsi dengan skor tertinggi menang, dan seri tipis antara lake dan lakehouse dimenangkan lakehouse karena table format tetap menyimpan berkas mentah yang bisa dibaca langsung:

python
def rekomendasi_arsitektur(volume_gb_per_hari, beban_ml_mentah, tim_analisis_sql,
                           warehouse_ada, sensitif_biaya):
    """Kerangka keputusan warehouse / lake / lakehouse (ilustrasi)."""
    skor = {"warehouse": 0, "lake": 0, "lakehouse": 0}
    alasan = {"warehouse": [], "lake": [], "lakehouse": []}

    if volume_gb_per_hari >= 500:
        skor["lake"] += 2
        alasan["lake"].append("volume besar: object storage jauh lebih murah")
        skor["lakehouse"] += 1
        alasan["lakehouse"].append("volume besar masih butuh query SQL")
    elif volume_gb_per_hari <= 20 and warehouse_ada:
        skor["warehouse"] += 2
        alasan["warehouse"].append("volume kecil: warehouse yang ada sudah mencukupi")

    if beban_ml_mentah:
        skor["lakehouse"] += 2
        alasan["lakehouse"].append("ML membutuhkan akses data mentah")
        skor["lake"] += 1
        alasan["lake"].append("ML membutuhkan akses data mentah")
    elif warehouse_ada:
        skor["warehouse"] += 1
        alasan["warehouse"].append("beban analitik SQL terstruktur")

    if tim_analisis_sql:
        skor["warehouse"] += 1
        alasan["warehouse"].append("tim analis kuat di SQL")
        skor["lakehouse"] += 1
        alasan["lakehouse"].append("tim analis kuat di SQL")
    else:
        skor["lake"] += 1
        alasan["lake"].append("tim berorientasi rekayasa, bukan SQL")

    if warehouse_ada:
        skor["warehouse"] += 1
        alasan["warehouse"].append("investasi warehouse sudah ada")

    if sensitif_biaya and volume_gb_per_hari >= 500:
        skor["lake"] += 1
        alasan["lake"].append("biaya storage object storage paling rendah")

    # seri tipis antara lake dan lakehouse dimenangkan lakehouse:
    # tabel lakehouse tetap menyimpan berkas mentah yang bisa dibaca langsung
    pilihan = max(skor, key=lambda opsi: (skor[opsi], opsi == "lakehouse"))
    return pilihan, skor, alasan


studi_kasus = [
    ("startup SaaS internal", {
        "volume_gb_per_hari": 5,
        "beban_ml_mentah": False,
        "tim_analisis_sql": True,
        "warehouse_ada": True,
        "sensitif_biaya": True,
    }),
    ("logistik nasional telemetri", {
        "volume_gb_per_hari": 2000,
        "beban_ml_mentah": True,
        "tim_analisis_sql": True,
        "warehouse_ada": False,
        "sensitif_biaya": True,
    }),
    ("lembaga riset citra medis", {
        "volume_gb_per_hari": 800,
        "beban_ml_mentah": True,
        "tim_analisis_sql": False,
        "warehouse_ada": False,
        "sensitif_biaya": True,
    }),
]

for nama, faktor in studi_kasus:
    pilihan, skor, alasan = rekomendasi_arsitektur(**faktor)
    print(f"=== {nama} ===")
    print(f"  skor: warehouse {skor['warehouse']} | lake {skor['lake']} | lakehouse {skor['lakehouse']}")
    print(f"  rekomendasi: {pilihan.upper()}")
    for opsi in ("warehouse", "lake", "lakehouse"):
        for a in alasan[opsi]:
            print(f"    {opsi}: {a}")

Output yang Dihasilkan:

text
=== startup SaaS internal ===
  skor: warehouse 5 | lake 0 | lakehouse 1
  rekomendasi: WAREHOUSE
    warehouse: volume kecil: warehouse yang ada sudah mencukupi
    warehouse: beban analitik SQL terstruktur
    warehouse: tim analis kuat di SQL
    warehouse: investasi warehouse sudah ada
    lakehouse: tim analis kuat di SQL
=== logistik nasional telemetri ===
  skor: warehouse 1 | lake 4 | lakehouse 4
  rekomendasi: LAKEHOUSE
    warehouse: tim analis kuat di SQL
    lake: volume besar: object storage jauh lebih murah
    lake: ML membutuhkan akses data mentah
    lake: biaya storage object storage paling rendah
    lakehouse: volume besar masih butuh query SQL
    lakehouse: ML membutuhkan akses data mentah
    lakehouse: tim analis kuat di SQL
=== lembaga riset citra medis ===
  skor: warehouse 0 | lake 5 | lakehouse 3
  rekomendasi: LAKE
    lake: volume besar: object storage jauh lebih murah
    lake: ML membutuhkan akses data mentah
    lake: tim berorientasi rekayasa, bukan SQL
    lake: biaya storage object storage paling rendah
    lakehouse: volume besar masih butuh query SQL
    lakehouse: ML membutuhkan akses data mentah

Mari kita baca ketiga hasil tersebut. Startup dengan 5 GB per hari dan warehouse yang sudah dibayar memenangkan skor warehouse dengan telak: menambah object storage justru menambah beban operasional tanpa manfaat. Perusahaan logistik memperoleh seri 4-4 antara lake dan lakehouse — keputusan tie-break memilih lakehouse karena tim analis tetap butuh SQL di atas telemetri 2 TB per hari, sementara berkas mentah tetap bisa dibaca langsung oleh tim ML. Lembaga riset citra medis justru tidak butuh lapisan tabel: penelitinya bekerja dengan Python langsung di atas berkas, tidak ada analis SQL, sehingga zona raw dan curated pada object storage sudah memadai.

Dengan arsitektur dan format tabel terpilih, pekerjaan berikutnya bukan lagi memilih, melainkan menjalankan: memindahkan data antar-zone, menjaga urutan, dan memastikan setiap langkah berjalan tepat waktu. Itu pekerjaan orkestrasi — pintu masuk section Orkestrasi Workflow.