Merancang Data Pipeline

Toko online TokoKita tumbuh dari 30 menjadi lebih dari 500 pesanan per hari, dan datanya kini tersebar di beberapa tempat: tabel pesanan di database operasional, berkas CSV dari sistem logistik, serta laporan manual yang dirakit tim bisnis tiap pagi. Menggabungkan data tersebut secara manual masih mungkin selama volumenya kecil, tetapi pendekatan tersebut mulai gagal ketika satu kesalahan salin-tempel membuat laporan harian salah hitung. Data pipeline menyelesaikan masalah ini dengan mengotomatiskan alur data dari sumber sampai laporan secara terjadwal. Sebelum menulis satu baris kode, kita perlu merancang pipeline secara sadar agar setiap keputusan teknis tidak diambil setengah jalan.

Enam Langkah Merancang Pipeline #

Setiap desain pipeline yang sehat mengikuti urutan pertanyaan yang sama. Kita mulai dari kebutuhan, bukan dari tools, karena tools hanyalah konsekuensi dari keputusan sebelumnya.

Kebutuhan: siapa pemakai output pipeline dan pertanyaan bisnis apa yang dijawab? Laporan penjualan harian untuk tim bisnis berbeda kebutuhannya dengan feed fitur untuk model machine learning.
Sumber: dari mana data berasal, dalam format apa, dan seberapa terpercaya kualitasnya? Tabel orders di PostgreSQL, berkas CSV dari logistik, atau topic Kafka memiliki karakter ingestion yang berbeda.
Transformasi: pembersihan apa yang wajib dilakukan sebelum data layak dianalisis? Contohnya membuang pesanan batal, menyeragamkan status, dan mengagregasi per tanggal.
Tujuan: ke mana hasil disimpan dan siapa yang membacanya? Data warehouse untuk analitik, tabel aplikasi untuk operasional, atau object storage untuk arsip.
Orkestrasi: kapan dan dalam urutan apa tiap tahap dijalankan? Jadwal harian pukul 01:30 dengan dependency antartahap harus dinyatakan eksplisit, bukan diasumsikan.
Monitoring: bagaimana kita tahu pipeline sehat? Metrik jumlah baris, durasi eksekusi, dan notifikasi ketika pipeline gagal wajib dirancang sejak awal, bukan ditambahkan setelah insiden pertama.

Urutan enam langkah tersebut berjalan maju, tetapi hasil monitoring mengalir kembali ke kebutuhan: metrik yang memburuk adalah masukan untuk revisi desain di siklus berikutnya.

flowchart LR A[Kebutuhan] --> B[Sumber] B --> C[Transformasi] C --> D[Tujuan] D --> E[Orkestrasi] E --> F[Monitoring] F -.-> A

Pertanyaan Desain Sebelum Menulis Kode #

Empat pertanyaan berikut menentukan hampir seluruh keputusan turunan. Kita mengisinya dengan jawaban nyata untuk kasus TokoKita sebagai patokan.

Aspek	Pertanyaan kunci	Jawaban untuk TokoKita
Frekuensi	Seberapa sering pipeline harus berjalan?	Batch harian, selesai sebelum pukul 06:00
Volume	Berapa banyak data per eksekusi?	Sekitar 12 ribu baris pesanan per hari, sekitar 1,8 MB
SLA	Kapan hasil wajib tersedia?	Pukul 06:00, sebelum rapat pagi tim bisnis
Konsumen	Siapa yang membaca hasilnya?	Tim bisnis lewat dashboard, bukan engineer
Kegagalan	Apa yang terjadi saat pipeline gagal?	Coba ulang otomatis, jalankan ulang tanpa duplikat
Latensi	Berapa lama data boleh tertunda?	Maksimal satu hari, bukan menit

Angka pada tabel sengaja dibuat biasa dan terukur. Volume 12 ribu baris per hari terasa kecil, tetapi justru pada skala inilah kebiasaan desain yang benar dibangun sebelum data tumbuh menjadi jutaan baris per bulan.

Studi Kasus: Pipeline Order Analytics Harian #

Kita terapkan enam langkah di atas pada satu pipeline konkret, yaitu laporan penjualan harian TokoKita. Diagram berikut memetakan alur data beserta dua komponen pendukungnya: scheduler dan monitoring.

flowchart TD A[Scheduler: batch harian 01:30] --> B[Extract: baca tabel orders] B --> C[Staging: tabel orders_staging] C --> D[Transform: buang batal, agregasi per tanggal] D --> E[Load: tabel penjualan_harian] E --> F[Dashboard: laporan untuk tim bisnis] D -.-> G[Monitoring: jumlah baris dan durasi]

Dari kerangka tersebut, setiap titik penting dijatuhkan menjadi keputusan desain yang dapat diuji. Tabel berikut merangkum keputusan beserta alasannya agar keputusan tidak berubah diam-diam di tengah pengerjaan.

Aspek	Keputusan	Alasan
Pola eksekusi	Batch harian	Laporan harian tidak membutuhkan data detik-per-detik
Jendela eksekusi	01:30 sampai 02:30	Di luar jam sibuk transaksi, durasi aman di bawah 45 menit
Model data	Partisi per tanggal	Kegagalan di satu partisi tidak menular ke partisi lain
Penanganan kegagalan	Coba ulang 3x, lalu jalankan ulang manual	Eksekusi ulang tidak menimbulkan duplikat
Alat orkestrasi	cron + runner Python	Dua pipeline saja; orkestrator penuh belum diperlukan
Retensi data	Partisi dipertahankan 90 hari	Kebutuhan analitik belum menjangkau lebih jauh
Monitoring	Jumlah baris, durasi, selisih vs 7 hari terakhir	Selisih besar menjadi indikasi galat data paling awal
Pemilik	Engineer data yang berpiket	Insiden punya orang yang bisa dihubungi

Satu angka pada tabel perlu dihitung, bukan ditebak: SLA pukul 06:00 dikurangi jendela selesai pukul 02:30 menyisakan anggaran pulih 3,5 jam untuk kegagalan. Anggaran tersebut yang menentukan berapa kali coba ulang layak dicoba sebelum eskalasi ke engineer, dan angka itulah yang kita tulis ke design doc.

Desain ini juga menetapkan batasnya sendiri: kebutuhan latensi di bawah satu hari menutup jalan menuju streaming, dan perubahan skema sumber belum dibahas. Kedua topik tersebut memiliki pembahasan khusus di Course Streaming Data dan Chapter Pipeline Versioning.

Kerangka Design Doc Mini #

Hasil rancangan di atas dituangkan ke satu berkas pendek yang hidup di repositori yang sama dengan kode pipeline. Kerangka berikut cukup untuk pipeline seukuran TokoKita dan dapat ditumbuhkan seiring kebutuhan.

text
Design Doc: pipeline penjualan harian TokoKita
Tujuan        : laporan penjualan harian, siap pukul 06:00
Sumber        : tabel orders di database operasional (PostgreSQL)
Target        : tabel penjualan_harian di warehouse, partisi per tanggal
Transformasi  : buang status batal, normalisasi status dan email, agregasi per tanggal
Jadwal        : setiap hari 01:30, jendela maksimal 45 menit
Kegagalan     : coba ulang 3x, eksekusi ulang aman (idempotent), eskalasi ke engineer
Monitoring    : jumlah baris, durasi, selisih vs rata-rata 7 hari terakhir

Setiap langkah desain meninggalkan artefak yang bisa diperiksa orang lain. Pemetaan berikut menjaga agar design doc tidak berhenti di niat baik.

Langkah	Artefak keluaran
Kebutuhan	Satu paragraf tujuan beserta SLA
Sumber	Daftar koneksi, skema, dan catatan kualitas data
Transformasi	Spesifikasi aturan pembersihan dan agregasi
Tujuan	Skema tabel target dan aturan partisi
Orkestrasi	Definisi jadwal dan dependency
Monitoring	Daftar metrik beserta ambang notifikasi

Konsep orkestrasi jadwal dan dependency didokumentasikan resmi di Apache Airflow , sementara pola transformasi berlapis staging-ke-warehouse dibahas luas di dokumentasi dbt . Dengan desain di tangan, langkah berikutnya adalah memilih pola eksekusi pertama. Pola paling sederhana sekaligus paling banyak dipakai adalah batch, yang akan kita bangun secara utuh pada Chapter Pipeline Batch.