Belajar Data Architect - Data Pipeline Architecture

#Pendahuluan

Setelah di episode 5 kita memilih platform cloud, sekarang kita membahas urat nadi arsitektur data: pipeline. Platform hanyalah wadah; pipeline-lah yang mengalirkan data dari sumber ke penyimpanan. Arsitektur pipeline menentukan seberapa cepat data tersedia, seberapa mudah debugging, dan seberapa besar biaya operasional harian.

Mengapa episode ini penting? Karena sebagian besar on-call data engineer dihabiskan untuk pipeline yang gagal di tengah malam. Arsitek yang merancang pipeline dengan pola yang benar — idempotent, observable, ter-orchestrasi — menyelamatkan timnya dari panggilan tengah malam dan laporan data yang salah.

#Batch vs Streaming

Dua mode dasar pengolahan data:

Aturan praktis yang sering dipakai: mulai dengan batch, tambahkan streaming hanya bila ada kebutuhan nyata. Streaming untuk kebutuhan "real-time" yang sebenarnya cukup harian adalah pemborosan yang sering terjadi.

butuh data hari ini untuk dashboard kemarin?   → batch harian
butuh deteksi fraud dalam hitungan detik?      → streaming
butuh keduanya?                                → kappa/lambda hybrid

#Arsitektur Pipeline Referensi

Pola yang paling umum di 2026 adalah ELT batch menuju lakehouse, dengan struktur berlapis:

Konsep medallion architecture (bronze → silver → gold) menciptakan pemisahan yang jelas: bronze menyimpan mentah (reproducibility), silver menyimpan bersih (consistency), gold menyimpan siap-pakai (performance). Kita bahas lebih dalam saat memilih skema di episode 16.

#Peran Orchestration: Apache Airflow

Batch pipeline tidak berjalan sendiri — butuh orchestrator. Apache Airflow adalah standar de facto: DAG (Directed Acyclic Graph) yang mendefinisikan alur tugas, dependencies, retry, dan alerting.

DAG Airflow sederhana

from airflow import DAG
from airflow.operators.bash import BashOperator
from airflow.operators.python import PythonOperator
from datetime import datetime, timedelta
 
default_args = {"retries": 3, "retry_delay": timedelta(minutes=5)}
 
with DAG(
    "elt_daily",
    default_args=default_args,
    schedule="0 2 * * *",
    catchup=False,
    start_date=datetime(2026, 1, 1),
) as dag:
    extract = BashOperator(task_id="extract", bash_command="bun run ingest")
    transform = BashOperator(task_id="transform", bash_command="dbt run")
    test = BashOperator(task_id="test", bash_command="dbt test")
    extract >> transform >> test

Poin penting untuk arsitek: orchestration ≠ transform. Airflow menjalankan kapan dan urutan; dbt/Spark mengerjakan apa yang dilakukan pada data. Memisahkan keduanya membuat pipeline mudah diuji dan dimodifikasi.

#Pola Pipeline yang Sehat

#1. Idempotent

Menjalankan pipeline dua kali harus menghasilkan hasil yang sama. Implementasi: tabel dengan partition yang bisa di-replace, dedup, atau merge bersyarat. Di dbt, pola incremental dengan is_incremental() menjaga pipeline bisa di-run ulang tanpa duplikasi.

#2. Immutable Raw Layer

Data mentah tidak pernah diupdate in-place — selalu tambahkan partisi baru. Ini memungkinkan re-proses penuh dan audit.

#3. Full Refresh Tersedia

Pipeline harus bisa di-backfill dari nol (misal re-proses 6 bulan) dengan satu command. Jika tidak, kalian tidak akan berani mengubah transformasi apa pun.

#4. Fail Loud dengan Alerting

Setiap kegagalan harus menghasilkan alert — bukan berakhir di log yang tidak dibaca. retries: 3 di Airflow harus disertai on_failure_callback yang mengirim ke Slack/email.

#5. Observability

Ukur durasi, row count, dan kualitas di setiap tahap. Kita bahas detail di episode 9 (data observability).

#Praktik: Desain Pipeline untuk Produksi

Kita desain pipeline untuk skenario: sinkronisasi order dari aplikasi (PostgreSQL) ke lakehouse, transformasi harian, dan notifikasi:

1. Ingestion (tiap 15 menit): baca baris baru dari PostgreSQL via CDC/log-based
   → tulis ke bronze di lakehouse (partition per tanggal)
2. Transformasi (setiap jam): dbt memproses bronze → silver
   → normalize, dedup, cast tipe data
3. Modeling (setiap jam): dbt silver → gold star schema
   → fact_sales, dim_customer, dim_product
4. Testing (setiap selesai): dbt test + data quality checks
   → warn jika row count menyimpang >5% dari rata-rata 30 hari
5. Alerting: gagal 3x → Slack #data-pipeline

Langkah evaluasi desain:

• Idempotent? Ya — semua stage bisa di-run ulang tanpa duplikasi.
• Backfill? Ya — partisi bronze immutble, semua transformasi full-refresh-able.
• Tertunda data? Orchestrator pakai sensor, bukan waktu asumsi.
• Terobservasi? Setiap DAG publish metrics ke monitoring.

#Penutup

Inti yang harus dibawa pulang:

• Batch untuk keterbaruan jam/hari, streaming untuk detik-menit — mulai dari batch.
• Medallion architecture (bronze/silver/gold) memisahkan mentah, bersih, dan siap-pakai.
• Airflow menjalankan kapan & urutan; dbt/Spark mengerjakan transformasi.
• Pipeline sehat: idempotent, raw immutable, backfill-able, fail loud, observable.

Di episode 7 selanjutnya kita akan membahas Streaming & Event-Driven Data — Apache Kafka, Change Data Capture (CDC), dan arsitektur real-time yang benar-benar dibutuhkan organisasi. Sampai jumpa di episode 7!