Belajar Data Engineer - Data Lakehouse di Cloud

#Pendahuluan

Di episode 10 kalian memahami konsep lakehouse — sekarang waktunya mewujudkannya di cloud. Di episode 9 kalian punya warehouse cloud, dan di episode 10 konsep lakehouse. Episode 17 menyatukan semuanya: bagaimana organisasi nyata membangun lakehouse di AWS, GCP, dan Azure, layanan managed apa yang tersedia, dan bagaimana kalian membangun lakehouse mini sendiri.

Mengapa topik ini penting? Karena di 2026 lakehouse adalah standar de facto penyimpanan data — dan hampir semua lowongan data engineer menuntut kemampuan mengoperasikan Delta Lake/Iceberg di salah satu cloud. Episode ini memberikan peta lengkapnya.

#Blok Penyusun Lakehouse di Cloud

Lakehouse tersusun dari tiga lapisan yang harus kalian kenali satu per satu:

Object storage — S3 (AWS), GCS (GCP), Azure Blob/ADLS. Murah, elastis, dan menjadi "rumah" data.
Table format — Delta Lake, Iceberg, Hudi (episode 10). Memberi transaksi, snapshot, dan time travel.
Query/processing engine — Spark, Trino, DuckDB, atau engine warehouse. Memberi kemampuan query SQL.

100%

Poin penting arsitekturnya: setiap lapisan bisa diganti. Storage tetap, table format bisa dipilih ulang, dan query engine bisa berbeda per beban — tanpa memindahkan data. Inilah fleksibilitas yang tidak dimiliki warehouse tertutup.

#Memilih Table Format

Tiga format utama (dari episode 10) dengan nuansa pemilihan di cloud:

Aspek	Delta Lake	Iceberg	Hudi
Penggerak	Databricks	Netflix (open ecosystem)	Uber
Kekuatan	Integrasi Databricks mulus, time travel	Paling netral: didukung BigQuery, Snowflake, Trino, Flink	Incremental upsert di skala raksasa
Dukungan cloud	Semua	Semua	Semua
Kapan dipilih	Tim memakai Databricks	Butuh interop maksimum antar engine	Beban high-frequency upsert

Note

Jangan terjebak perang format. Ketiganya menyelesaikan masalah yang sama. Pilih berdasarkan engine yang sudah dipakai organisasi (Databricks → Delta; multi-engine/Trino + BigQuery → Iceberg) — bukan berdasarkan tren.

#Layanan Managed di Tiap Cloud

Alih-alih mengoperasikan Spark sendiri, kebanyakan tim memakai layanan managed. Perbandingan singkat:

Cloud	Layanan	Fungsi
AWS	AWS Glue	ETL serverless + data catalog
AWS	Amazon Athena	Query SQL langsung di S3 (Iceberg/Delta)
GCP	Dataproc	Managed Spark (bisa Hadoop)
GCP	BigLake	Query data lake dengan BigQuery engine
Azure	Azure Synapse / Fabric	Analitik terpadu + lakehouse
Multi-cloud	Databricks	Managed Spark + Delta, dipakai di semua cloud

Pola umum penggunaannya: Spark managed untuk transformasi (medallion), Trino/Athena/BigLake untuk query ad-hoc, dan engine warehouse untuk serving — semuanya di atas satu storage dan table format.

#Praktik: Lakehouse Mini dengan Iceberg + Trino + MinIO

Mari bangun lakehouse mini lokal yang mereplikasi pola cloud — tanpa biaya. Komponen: MinIO (S3-compatible), Iceberg sebagai table format, dan Trino sebagai query engine. Jalankan dengan Docker Compose:

docker-compose.yml (lakehouse mini)

services:
  minio:
    image: minio/minio:latest
    command: server /data --console-address ":9001"
    environment:
      MINIO_ROOT_USER: minioadmin
      MINIO_ROOT_PASSWORD: minioadmin
    ports: ["9000:9000", "9001:9001"]
 
  trino:
    image: trinodb/trino:463
    ports: ["8080:8080"]
    depends_on: [minio]

Buat bucket, lalu query dengan Trino (Iceberg catalog menunjuk ke MinIO):

Setup bucket dan jalankan Trino

docker exec -it minio mc alias set local http://localhost:9000 minioadmin minioadmin
docker exec -it minio mc mb local/lakehouse

Buat tabel Iceberg di Trino

CREATE SCHEMA lakehouse.bronze;
 
CREATE TABLE lakehouse.bronze.orders (
    order_id BIGINT,
    amount DECIMAL(12,2),
    status VARCHAR,
    created_at TIMESTAMP
) WITH (
    format = 'PARQUET',
    partitioning = ARRAY['day(created_at)']
);

Insert dan cek snapshot

INSERT INTO lakehouse.bronze.orders
VALUES (1, 25000.00, 'completed', TIMESTAMP '2026-08-16 10:00:00');
 
SELECT * FROM "lakehouse.bronze"."orders$snapshots";

Perhatikan orders$snapshots — tabel sistem Iceberg yang menunjukkan versi snapshot. Inilah time travel: setiap insert menciptakan snapshot baru, dan kalian bisa query versi mana pun. Lakehouse mini kalian sudah memiliki fitur warehouse sungguhan.

#Kapan Pakai Managed vs Self-Hosted

Keputusan klasik yang harus dipikirkan:

Managed (Databricks/Glue/Dataproc) — jika tim kecil, butuh kestabilan, dan mau membayar untuk tidak mengelola infra. Ini pilihan default 2026.
Self-hosted (Spark + Trino di K8s) — jika biaya tinggi tidak bisa diterima, atau kebutuhan sangat spesifik; tapi kalian menanggung operasional penuh.
Hybrid — sebagian managed untuk transformasi, query engine ringan (DuckDB/Trino) untuk eksplorasi.

#Kesalahan Umum (Common Pitfalls)

Mengabaikan object storage lifecycle. Tanpa kebijakan lifecycle (pindah ke kelas storage dingin, hapus snapshot lama), biaya lakehouse membengkak diam-diam.
Format file acak-acakan. Tabel yang ditulis dalam beberapa format (Parquet, ORC, Avro) di satu lake = performa tidak konsisten. Standarkan ke Parquet.
Menambah table format tanpa kebutuhan transaksi. Tabel yang hanya ditulis sekali tidak butuh Iceberg. Format menambah manfaat seiring kebutuhan concurrent writes & time travel.
Memindahkan data antar layanan. Esensi lakehouse: query dari berbagai engine di atas satu penyimpanan. Menyalin data antar sistem menghancurkan tujuannya.

#Penutup

Di episode 17 ini kalian telah mewujudkan lakehouse di cloud:

Lakehouse = object storage + table format + query engine, tiap lapisan bisa diganti bebas.
Pilih format berdasarkan engine organisasi: Delta (Databricks), Iceberg (multi-engine), Hudi (high-frequency upsert).
Layanan managed: AWS Glue/Athena, GCP Dataproc/BigLake, Databricks multi-cloud.
Praktik: lakehouse mini MinIO + Iceberg + Trino dengan snapshot & time travel.

Di episode 18 selanjutnya kita memasuki fase keamanan: security & access control — row/column-level security, encryption, secrets management, least privilege, dan praktik mengamankan pipeline dengan IAM. Sampai jumpa di episode 18!