Tanggal Berita: 9 Desember 2025
Guna Chandra Durgapu membagikan studi kasus teknis tentang bagaimana timnya merekayasa ulang pipeline data 7TB untuk mencapai target "1-day planning", memangkas waktu eksekusi job terberat dari 35 jam menjadi jauh lebih singkat.
🚧 Problem Statement: Mimpi Buruk Partisi 1.9 GB
Tantangan utamanya adalah mengejar tenggat waktu eksekusi total di bawah 24 jam untuk 19 rencana pemrosesan data. Namun, satu job ETL kritis saja memakan waktu 35 jam.
🐌 Inefisiensi Partisi & Disk Spills Akar masalah ditemukan di Spark UI: job tersebut membaca 400 part-files yang masing-masing berukuran 1.9 GB. Dalam Spark, 1 partisi dipetakan ke 1 core. Memaksa satu core memproses 1.9 GB data menyebabkan memori eksekutor jebol, memicu disk spill (data tumpah ke disk yang lambat), dan akhirnya crash OOM (Out Of Memory).
🛑 Straggler Tasks & Idle Executors Selain itu, terjadi fenomena "Straggler Task" di mana 4.799 task selesai dalam 2 menit, tapi 1 task lambat (akibat data skew) berjalan selama 45 menit, menahan seluruh kluster. Konfigurasi alokasi statis juga membuat ribuan core menganggur (idle) saat tidak dipakai, membuang biaya komputasi.
🛠️ Solusi: Bedah Jantung Arsitektur Spark
Tim melakukan rekayasa ulang holistik yang menyentuh level data, kode, dan konfigurasi kluster.
✂️ Repartitioning Strategis Alih-alih membiarkan partisi raksasa, mereka melakukan repartition data menjadi 3.200 file kecil (300-500 MB). Ini memungkinkan ribuan task berjalan paralel tanpa membebani memori per core.
💾 Manajemen DAG & Caching Masalah komputasi ulang (re-computation) diatasi dengan persist() dan checkpoint(). Ini memutus garis keturunan (lineage) DAG yang terlalu panjang—yang sering menyebabkan driver meledak—dan menyimpan hasil komputasi mahal ke disk agar tidak perlu diulang.
🧠 Adaptive Query Execution (AQE) Mengaktifkan fitur "autopilot" Spark: spark.sql.adaptive.enabled. AQE secara otomatis mendeteksi data skew saat runtime dan memecah partisi yang miring menjadi sub-partisi kecil, secara efektif membunuh straggler tasks.
🚀 Optimasi Shuffle & Memori Mengganti serializer default Java dengan Kryo (lebih cepat & ringkas) serta kompresi Snappy. Mereka juga mengaktifkan Off-Heap Memory (Project Tungsten) untuk memindahkan data shuffle keluar dari JVM, mengurangi drastis kejadian Stop-the-World GC pauses.
⚡ Findings: Mencapai Target 24 Jam
Hasil dari serangkaian operasi bedah ini sangat signifikan.
📉 Runtime Terpangkas Waktu eksekusi keseluruhan berkurang sebesar 36%. Target jendela waktu pemrosesan 20-22 jam berhasil dicapai, jauh di bawah batas 24 jam.
💎 Efisiensi Sumber Daya Dengan beralih ke Dynamic Allocation, kluster hanya menggunakan sumber daya saat dibutuhkan. Stabilitas job meningkat drastis karena disk spills dan GC pauses berhasil dihilangkan.
⚙️ How to Use: Panduan Tuning Anda
Jangan biarkan Spark berjalan dengan konfigurasi default untuk data besar. Ikuti langkah teknis berikut:
🧮 Hitung Partisi Optimal Gunakan rumus: Max(Total_Input_MB / 128, Total_Cores * 3). Pastikan ukuran partisi Anda berkisar di 128MB (untuk HDD) agar seimbang antara parallelism dan overhead.
⚡ Aktifkan Konfigurasi Kunci Pastikan setelan ini ada di spark-submit Anda:
1️⃣spark.sql.adaptive.enabled=true (Wajib untuk Spark 3.x)
2️⃣spark.serializer=org.apache.spark.serializer.KryoSerializer
3️⃣spark.memory.offHeap.enabled=true
🏗️ Gunakan Kolumnar Selalu gunakan format penyimpanan kolumnar seperti Parquet atau ORC daripada JSON/CSV. Ini memungkinkan fitur column pruning dan predicate pushdown bekerja maksimal.
🗝️ Key Takeaways
🧱 Partisi adalah Raja Performa Spark sangat bergantung pada bagaimana Anda membagi data. File input yang terlalu besar (1GB+) adalah pembunuh performa nomor satu.
🤖 Percayakan pada AQE Fitur Adaptive Query Execution bukan sekadar hiasan. Ia adalah solusi paling ampuh untuk menangani ketidakpastian data dan skew di lingkungan produksi.
🗑️ Hindari JVM untuk Data Besar Memanfaatkan Off-Heap memory menjauhkan data besar dari Garbage Collector Java, membuat aplikasi berjalan jauh lebih mulus tanpa jeda pembekuan.
💬 Interaksi Pembaca
Coba cek Spark UI pada job terberat Anda. Apakah Anda melihat batang hijau panjang (task sukses) yang tertahan oleh satu batang yang tak kunjung selesai (straggler)? Itu tanda Anda butuh AQE dan repartitioning.
Sumber:
https://blog.flipkart.tech/apache-spark-optimisations-c3464f71bd38
#ApacheSpark #BigData #DataEngineering #PerformanceTuning #ETL #Scala #Python #DataPipeline #TechCaseStudy #SoftwareArchitecture
