Belajar Data Engineer - Data Lake & Lakehouse (Spark/Databricks)

#Pendahuluan

Di episode 9 kalian mempelajari warehouse cloud — dan mungkin bertanya: apa yang terjadi jika datanya jauh lebih besar dari yang bisa ditampung warehouse? Jawabannya adalah data lake dan turunannya: lakehouse. Inilah lapisan penyimpanan yang menangani volume terabyte sampai petabyte dengan biaya rendah.

Episode ini menjelaskan fondasi teknis yang wajib dipahami setiap data engineer modern: format file (Parquet, Avro), table formats (Iceberg, Delta Lake), dan engine pemrosesan (Spark/PySpark). Di akhir, kalian menjalankan batch processing PySpark pertama.

#Dari File Biasa ke Format Kolumnar

Data lake menyimpan data sebagai file di object storage. Tapi format file menentukan segalanya. Dua format yang paling penting:

Parquet — format kolumnar (data disimpan per kolom, bukan per baris). Keunggulannya: kompresi lebih baik dan query yang mengambil beberapa kolom bisa melewatkan kolom lain — sangat cocok untuk analitik. Ini format default di hampir semua ekosistem data 2026.

Avro — format row-based dengan schema tersemat. Keunggulannya: cepat untuk menulis dan membaca seluruh baris, ideal untuk streaming dan message queue.

Aturan praktis: Parquet untuk penyimpanan analitik, Avro untuk transport/streaming.

#Table Format: Iceberg, Delta Lake, Hudi

File Parquet saja tidak cukup — kalian butuh cara mengelola ribuan file sebagai satu tabel dengan transaksi. Di sinilah table format bekerja. Tiga pemain utama:

• Apache Iceberg — open-source, netral vendor, snapshot isolation, didukung banyak engine (Spark, Trino, Flink, BigQuery).
• Delta Lake — dikembangkan Databricks, transaction log berbasis JSON, time travel, default di Databricks.
• Apache Hudi — dikembangkan Uber, kuat untuk incremental upsert di skala besar.

Ketiganya menyelesaikan masalah yang sama: ACID di atas data lake — beberapa proses bisa menulis bersamaan tanpa saling merusak, dan kalian bisa time travel ke versi tabel sebelumnya.

MERGE INTO silver.orders AS t
USING bronze.orders_raw AS s
ON t.order_id = s.order_id
WHEN MATCHED THEN UPDATE SET
    t.amount = s.amount,
    t.status = s.status,
    t.updated_at = s.updated_at
WHEN NOT MATCHED THEN INSERT (order_id, amount, status, created_at)
    VALUES (s.order_id, s.amount, s.status, s.created_at);

MERGE adalah cara kanonik melakukan incremental update di lakehouse — dasar dari topik CDC di episode 12.

#Lakehouse: Menggabungkan Lake dan Warehouse

Lakehouse adalah arsitektur yang menyimpan data di lake (object storage, format terbuka, murah) tapi menghadirkan fitur warehouse: transaksi ACID, schema enforcement, indeks, dan query cepat.

Inilah alasan lakehouse menjadi standar de facto 2026: satu penyimpanan untuk raw (bronze), cleansed (silver), dan curated (gold) — tanpa perpindahan data antar sistem (episode 2). Databricks (Delta), Iceberg ecosystem, dan layanan cloud (episode 17) semua bergerak ke arah ini.

#Batch Processing dengan PySpark

Apache Spark adalah engine pemrosesan terdistribusi: pekerjaan dipecah ke banyak executor yang memproses data secara paralel. PySpark adalah API Python-nya. Konsep dasarnya: DataFrame yang terdistribusi — API-nya mirip pandas/polars, tapi bekerja di atas cluster.

from pyspark.sql import SparkSession
from pyspark.sql import functions as F
 
spark = SparkSession.builder \
    .appName("orders_batch") \
    .getOrCreate()
 
# Baca data lake (bronze) dan filter hanya yang valid
raw = spark.read.parquet("s3://data-lake/bronze/orders/")
 
silver = raw.filter(F.col("status") != "cancelled") \
    .withColumn("amount", F.col("amount").cast("decimal(12,2)")) \
    .withColumn("order_date", F.to_date("created_at"))
 
# Agregasi per hari (gold)
daily = silver.groupBy("order_date") \
    .agg(F.count("order_id").alias("total_orders"),
         F.sum("amount").alias("total_revenue"))
 
daily.write.mode("overwrite").format("parquet") \
    .save("s3://data-lake/gold/daily_orders/")

Perhatikan polanya: bronze dibaca, dibersihkan jadi silver, diagregasi jadi gold — medallion architecture dalam aksi. Spark menangani volume yang terlalu besar untuk pandas dengan memecah pekerjaan lintas executor.

#Menjalankan PySpark Lokal

Untuk belajar, Spark bisa dijalankan di satu mesin (local mode). Jalankan di Docker agar Java & dependency bersih:

docker run -it --rm \
  -v $(pwd):/work -w /work \
  apache/spark:3.5 \
  ./bin/spark-submit pyspark_batch.py

spark-submit adalah cara menjalankan aplikasi Spark. Untuk series ini, mode local sudah cukup memahami konsep; detail tuning dan optimasi cluster kita bedah di episode 21.

#Kesalahan Umum (Common Pitfalls)

1. Menganggap pandas dan PySpark identik. Transformasi yang valid di pandas (misalnya mutate baris per baris) bisa menjadi bencana performa di Spark. Pikirkan dalam operasi kolom yang didistribusikan.

2. Menyimpan semuanya sebagai CSV di lake. CSV tidak punya metadata, kompresi buruk, dan lambat di-scan. Parquet adalah standar.

3. File lake tanpa table format. Ribuan file Parquet tanpa Iceberg/Delta = data swamp tanpa transaksi dan tanpa lineage.

4. Menulis kembali semua data tiap hari. Overwrite penuh tabel besar itu mahal dan lambat. Gunakan incremental (MERGE, partitioning) sedini mungkin.

#Penutup

Di episode 10 ini kalian telah membangun pemahaman lake & lakehouse:

• Parquet (kolumnar, analitik) vs Avro (row-based, streaming) — pilih berdasarkan beban.
• Iceberg/Delta/Hudi menghadirkan transaksi ACID, snapshot, dan time travel di atas data lake.
• Lakehouse = object storage + table format + query engine — standar de facto 2026.
• PySpark memproses data terdistribusi dengan pola medallion: bronze → silver → gold.

Di episode 11 selanjutnya kita beralih dari batch ke real-time: streaming (Kafka/Flink) — konsep topics, producers, consumers, arsitektur Kappa, dan praktik membangun pipeline streaming sederhana. Sampai jumpa di episode 11!