Belajar Apache Spark - Real-world Use Cases & Patterns

#Pendahuluan

Setelah 19 episode teori dan praktik, episode 20 ini menyatukan semuanya: bagaimana Spark dipakai untuk menyelesaikan masalah bisnis nyata. Tiga use case besar akan dibedah — ETL, real-time analytics, dan recommendation systems — ditambah pola arsitektur yang membuat pipeline tetap andal.

Ini adalah episode yang menghubungkan keterampilan teknis dengan nilai bisnis. Kode yang benar itu penting, tapi yang lebih penting adalah kode yang menyelesaikan masalah — dan masalah yang dipilih dengan baik akan menentukan kualitas seluruh data platform.

Episode ini membahas empat topik: pipeline ETL, real-time analytics, recommendation systems, design patterns untuk reliabilitas, dan arsitektur end-to-end batch plus streaming.

#Use Case: ETL Pipelines

#ETL Harian ke Data Lake

Contoh paling umum: tarik data dari database transaksional setiap malam, bersihkan, transformasi, dan tulis ke data lake untuk analitik:

ETL dari database ke Parquet

from pyspark.sql import functions as F
 
orders = spark.read \
    .format("jdbc") \
    .option("url", os.environ["DB_URL"]) \
    .option("dbtable", "orders") \
    .option("partitionColumn", "id") \
    .option("lowerBound", 0) \
    .option("upperBound", 1000000) \
    .option("numPartitions", 8) \
    .load()
 
bersih = orders.filter(F.col("amount").isNotNull()) \
    .withColumn("order_date", F.to_date("created_at")) \
    .repartition(4, "order_date")
 
bersih.write \
    .mode("overwrite") \
    .partitionBy("order_date") \
    .parquet("s3a://datalake/orders")

Pola di atas memakai partitioning di sisi pembacaan (partitionColumn) dan di sisi penulisan (partitionBy) — keduanya menjaga query database tidak overload dan file data lake tetap terorganisir.

#Idempotency dalam ETL

Untuk ETL batch, pastikan setiap run menghasilkan hasil yang sama tanpa bergantung pada run sebelumnya:

• Tulis ke lokasi temporary, lalu rename ke lokasi final secara atomik.
• Gunakan mode("overwrite") untuk partisi yang dihitung ulang penuh.
• Pertimbangkan Delta atau Iceberg untuk transaksi yang benar-benar aman.

#Use Case: Real-Time Analytics

#Dashboard Metrik Produk

Real-time analytics menjawab pertanyaan seperti "berapa klik dalam 5 menit terakhir" atau "konversi per channel sekarang". Arsitekturnya: event masuk ke Kafka, Spark mengagregasi dengan window, hasil masuk ke sink cepat:

Agregasi real-time per menit

from pyspark.sql import functions as F
 
events = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "localhost:9092") \
    .option("subscribe", "clicks") \
    .load() \
    .select(F.from_json(F.col("value").cast("string"),
            F.schema_of_json('{"halaman":"/","waktu":"2026-08-10T10:00:00Z"}')).alias("d")) \
    .select("d.*")
 
metrik = events \
    .withWatermark("waktu", "2 minutes") \
    .groupBy(F.window("waktu", "1 minute"), "halaman") \
    .count()
 
metrik.writeStream \
    .outputMode("update") \
    .format("console") \
    .start() \
    .awaitTermination()

Pipeline ini bisa diarahkan ke sink berkecepatan tinggi seperti Cassandra, Redis, atau Kafka lain yang memberi makan dashboard. Latensi total dari event sampai dashboard biasanya dalam hitungan detik.

#Pertimbangan Latensi

Pilih trigger dan sink sesuai kebutuhan: processingTime("5 seconds") cukup untuk dashboard; untuk kebutuhan near-real-time yang lebih ketat, pertimbangkan engine seperti Flink. Spark memenangkan kasus ini ketika tim butuh satu engine untuk batch dan stream sekaligus.

#Use Case: Recommendation Systems

#Rekomendasi Berbasis Kolaborasi

Sistem rekomendasi memakai data interaksi pengguna-produk untuk memprediksi preferensi. Dengan ALS dari episode 11, pipeline lengkapnya:

Pipeline rekomendasi lengkap

from pyspark.ml.recommendation import ALS
from pyspark.ml.evaluation import RegressionEvaluator
 
(train, test) = interaksi.randomSplit([0.8, 0.2], seed=42)
 
als = ALS(userCol="user_id", itemCol="produk_id", ratingCol="rating",
          coldStartStrategy="drop")
model = als.fit(train)
 
prediksi = model.transform(test)
evaluator = RegressionEvaluator(
    metricName="rmse", labelCol="rating", predictionCol="prediction")
print("RMSE:", evaluator.evaluate(prediksi))
 
rekomendasi = model.recommendForAllUsers(10)

recommendForAllUsers(10) menghasilkan 10 rekomendasi per pengguna. Hasilnya bisa ditulis ke cache untuk disajikan API rekomendasi, atau di-recompute setiap malam dengan ETL batch.

#Fitur Tambahan untuk Produksi

Rekomendasi produksi biasanya menggabungkan beberapa sinyal: popularitas, kategori, dan filter toksisitas. Spark memberi fleksibilitas untuk menggabungkan skor ALS dengan logika bisnis lain dalam satu pipeline sebelum menulis hasil akhir.

#Design Patterns untuk Reliabilitas Pipeline

#Pola yang Terbukti

Beberapa design pattern yang menjaga pipeline tetap andal:

• Checkpoint + sink transaksional: kombinasi untuk streaming yang tidak kehilangan data.
• Data quality gate: validasi sebelum dan sesudah transformasi; berhenti jika anomali.
• Idempotent write: overwrite atau merge, bukan append membabi buta.
• Retry dengan backoff dan dead-letter queue: job gagal diisolasi, bukan diblokir selamanya.
• Schema registry: perubahan skema terdeteksi sebelum merusak downstream.

ingest → validasi awal → transform → validasi akhir → publish → alert jika gagal

#Monitoring Business Metrics dan Data Quality

Reliabilitas tidak lengkap tanpa pengamatan:

• Business metrics: jumlah baris yang diproses, nilai agregat kunci, freshness data.
• Data quality: rasio null, distribusi nilai, duplikat, dan skema yang konsisten.
• Setiap pipeline menulis metrik ini ke tabel observasi, dan alert aktif saat angka menyimpang dari baseline.

#Arsitektur End-to-End untuk Batch + Streaming

#Satu Platform, Dua Kecepatan

Arsitektur yang menggabungkan batch dan streaming dengan satu engine:

Kafka/DB → ingestion → Spark (stream) → lakehouse (Delta/Iceberg)
                              ↓
               Spark (batch) → warehouse → BI & ML

Pola ini sering disebut lambda architecture dalam bentuk ringan: aliran real-time menyediakan data segar, batch menjaga akurasi dan data lengkap, dan lakehouse menjadi titik temu keduanya. Spark menjadi engine tunggal untuk keduanya.

#Pertimbangan Desain

• Medallion architecture: bronze (raw), silver (clean), gold (aggregated) — memisahkan lapisan data yang bisa diakses.
• One schema, one platform: hindari banyak salinan data dengan skema berbeda.
• Cost control: batch untuk data besar yang tidak mendesak, streaming untuk yang butuh kecepatan.

#Penutup

Episode 20 menunjukkan Spark dalam aksi nyata: ETL menghubungkan database dengan data lake, real-time analytics menyajikan metrik segar, recommendation systems memakai MLlib end-to-end, design patterns menjaga reliabilitas, dan arsitektur batch-plus-streaming memanfaatkan Spark sebagai satu platform.

Inti yang harus dibawa pulang:

• ETL yang baik bersifat idempotent dan memakai partitioning dua arah.
• Real-time analytics mengalir dari Kafka melalui window menuju sink cepat.
• ALS melengkapi pipeline rekomendasi dengan evaluasi RMSE dan persistensi.
• Quality gate dan data quality monitoring menjaga data tetap dapat dipercaya.
• Lakehouse memungkinkan batch dan streaming berbagi satu penyimpanan.

Di episode 21 selanjutnya kita akan membahas ekosistem dan resources — tooling seperti Delta Lake, Iceberg, Hudi, dan Spark SQL Gateway, managed Spark services seperti Databricks, AWS EMR, dan GCP Dataproc, library dan extensions seperti GraphX dan Pandas API on Spark, serta sumber belajar komunitas dan dokumentasi resmi.