Belajar Data Engineer - Arsitektur Data Modern

#Pendahuluan

Setelah di episode 1 kita memetakan peran dan ekosistem data, sekarang saatnya menyusun arsitektur: bagaimana data mengalir dari sumber mentah sampai siap dianalisis. Arsitektur adalah keputusan paling mahal yang akan kalian buat — salah memilih arsitektur berarti membangun ulang pipeline yang sudah terlanjur dipakai ratusan orang.

Mengapa arsitektur data modern penting? Karena pipeline data tidak lagi hanya "copy dari database ke warehouse". Ada data real-time dari event stream, data mentah yang harus di-query, dan kebutuhan berbagi data antar tim. Episode ini memberikan kalian bahasa bersama untuk mendeskripsikan dan mendesain sistem data: medallion, Lambda/Kappa, dan keputusan batch vs streaming.

#Medallion Architecture

Pola paling populer di industri saat ini (dipopulerkan Databricks) adalah medallion architecture: data mengalir melalui tiga lapisan penyimpanan yang semakin bersih dan terstruktur.

100%

Kenapa pola ini efektif? Karena bronze mempertahankan data mentah selamanya — jika logika transformasi berubah, kalian tidak perlu kembali ke sumber asli, cukup re-process dari silver. Bronze adalah jaring pengaman, silver adalah fondasi pemrosesan, dan gold adalah produk yang dikonsumsi.

#Batch vs Streaming

Sebelum memilih arsitektur pipeline, kalian harus memutuskan satu pertanyaan fundamental: apakah data perlu hadir seketika?

#Batch Processing

Data diproses dalam interval terjadwal — tiap jam, tiap malam, atau tiap minggu. Karakteristiknya:

• Latency: menit sampai jam setelah data tersedia.
• Simpler: mudah di-debug, mudah di-backfill, tooling matang (Airflow, dbt).
• Biaya rendah: bisa memproses dalam volume besar secara efisien dengan Spark batch.

#Streaming Processing

Data diproses terus-menerus begitu muncul di event stream. Karakteristiknya:

• Latency: detik sampai milidetik.
• Kompleks: butuh penanganan exactly-once, watermark, dan stateful processing.
• Biaya tinggi: infrastruktur real-time lebih mahal untuk dijalankan 24/7.

#Lambda vs Kappa Architecture

Dua arsitektur klasik untuk menggabungkan data historis dan real-time.

#Lambda Architecture

Menjalankan dua jalur paralel: batch layer (memproses data historis lengkap, hasilnya akurat) dan speed layer (memproses data real-time, hasilnya cepat tapi bisa tidak lengkap), lalu menggabungkan keduanya di serving layer.

• Kelebihan: akurasi data historis + kefreshan data real-time.
• Kekurangan: dua codebase yang harus dijaga — aturan bisnis diimplementasi dua kali, mudah tidak konsisten.

#Kappa Architecture

Menjalankan satu jalur streaming untuk semuanya: data historis dianggap sebagai stream yang diputar ulang dari awal, dan semua data melewati pipeline streaming yang sama.

• Kelebihan: satu codebase, satu logika transformasi.
• Kekurangan: perlu event broker yang kuat (Kafka) dan kemampuan replay tanpa batas.

Di tahun 2026, kecenderungan industri adalah Kappa yang dipragmatiskan: data diingest lewat streaming (Kafka) lalu diproses dengan model micro-batch, atau streaming dipakai hanya di lapisan ingesti sementara transformasi berat tetap batch. Yang penting: kalian memahami trade-off, bukan menghafal dogma.

#Reference Architecture Data Platform

Mari rangkai semua konsep menjadi satu reference architecture yang realistis:

100%

Komponen utamanya:

1. Sumber — database transaksional, API, dan event stream.
2. Ingestion — CDC (Debezium) untuk database, connector (Airbyte) untuk API, broker (Kafka) untuk event.
3. Storage lapisan raw — data lake/bronze di object storage.
4. Transformasi — batch (Spark/dbt) dan/atau streaming (Flink), menghasilkan silver.
5. Serving — warehouse/lakehouse untuk gold, dikonsumsi dashboard dan ML.
6. Orkestrasi — Airflow/Dagster menjadwalkan dan memantau seluruh alur.

#Praktik: Mendesain Arsitektur Sederhana

Sekarang praktikkan: bayangkan sebuah e-commerce ingin menganalisis pesanan secara harian dan mendeteksi anomali pembayaran secara real-time. Desainlah arsitekturnya:

1. Pesanan harian (batch): database orders diekstrak tiap malam ke bronze, dibersihkan ke silver (dedupe, standardisasi mata uang), lalu diagregasi ke gold daily_sales untuk dashboard.
2. Anomali pembayaran (streaming): event pembayaran dikirim ke Kafka, dikonsumsi pipeline streaming yang menghitung skor anomali, hasilnya ditulis ke tabel gold untuk dikonsumsi aplikasi deteksi fraud.

Ini menggambarkan keputusan arsitektur nyata: data yang butuh analisis historis memakai jalur batch + medallion, sedangkan data yang butuh respons seketika memakai jalur streaming — sering kali dalam satu platform yang sama.

#Kesalahan Umum (Common Pitfalls)

1. Langsung streaming tanpa kebutuhan. Pipeline streaming menambah kompleksitas operasional besar; pastikan kebutuhan latency benar-benar ada.

2. Melewatkan lapisan bronze. Menyimpan hanya hasil transformasi (tanpa raw) membuat kalian tidak bisa merekonstruksi data saat logika berubah. Bronze adalah asuransi.

3. Lambda tanpa disiplin. Dua codebase yang tidak sinkron akan menghasilkan angka yang berbeda antar jalur — pertanyaan paling umum analyst: "kenapa angka batch dan real-time beda?"

4. Desain tanpa mempertimbangkan konsumen. Arsitektur yang tidak menyertakan kebutuhan dashboard dan ML akan menghasilkan platform yang jarang dipakai.

#Penutup

Di episode 2 ini kalian telah menguasai fondasi arsitektur data modern:

• Medallion architecture: bronze (raw) → silver (cleansed) → gold (curated), dengan bronze sebagai jaring pengaman.
• Batch vs streaming: mulai dari batch, tambahkan streaming hanya jika kebutuhan latency nyata.
• Lambda vs Kappa: dua codebase vs satu codebase — Kappa lebih modern, Lambda masih relevan.
• Reference architecture: sumber → ingestion → lake/bronze → transformasi → warehouse/lakehouse → konsumen, dengan orkestrasi di tengahnya.

Di episode 3 selanjutnya kita masuk ke fase operasional: SQL & database fundamental untuk data engineering — perbedaan OLTP vs OLAP, query lanjutan dengan CTE dan window functions, serta modeling query untuk kebutuhan analytics. Sampai jumpa di episode 3!