Memilih Workflow Orchestrator

Kita kini memegang tiga orchestrator dengan kekuatan nyata: Airflow yang matang dan berekosistem luas, Dagster dengan paradigma aset dan lineage bawaan, serta Prefect yang pythonic dan dinamis. Di forum, pembahasan pemilihan orchestrator sering turun menjadi pertarungan selera — padahal tim, beban, dan infrastruktur yang berbeda menghasilkan pilihan yang berbeda, dan ketiganya bisa sama-sama benar. Bab penutup ini menyusun kerangka keputusan: faktor penentunya, perbandingan menyeluruh, dan tiga studi kasus nyata.

Faktor Keputusan #

Empat faktor berikut menentukan arah — urutannya menempatkan faktor sosial sejajar dengan faktor teknis.

Ekosistem Tim #

Orchestrator yang sudah dikuasai tim — lengkap dengan runbook, kebiasaan on-call, dan ratusan workflow yang terbukti — adalah aset nyata. Migrasi menuntut penulisan ulang workflow, pelatihan tim, dan masa transisi ketika dua sistem berjalan bersamaan.

Model Mental #

Apakah tim memikirkan pipeline sebagai urutan task yang harus selesai, atau sebagai kumpulan aset data yang harus segar? Airflow mewadahi model pertama, Dagster mewadahi model kedua, dan Prefect membiarkan struktur mengikuti logika Python. Ketidakcocokan model mental menimbulkan gesekan harian — pertanyaan “tabel ini berasal dari mana” lebih mudah dijawab di orchestrator yang berpikir sebagai aset.

Infrastruktur #

Berapa banyak komponen yang sanggup dioperasikan tim? Airflow meminta metadata database plus sekelompok service sejak awal. Dagster dan Prefect sama-sama menyediakan jalur lokal ringan — dagster dev dan python berkas.py — sebelum naik ke mode produksi dengan komponen terpisah.

Biaya #

Biaya total mencakup compute, biaya operasional tim (on-call, upgrade, penanganan insiden), dan opsi layanan terkelola — Astronomer untuk Airflow, Prefect Cloud, atau penawaran terkelola Dagster — yang menukar beban operasional dengan langganan. Bandingkan biaya per tahun, bukan biaya memulai.

Perbandingan Menyeluruh #

Tidak ada kolom yang menang mutlak. Baris lineage condong ke Dagster, baris ekosistem integrasi condong ke Airflow, dan baris titik mulai lokal condong ke Prefect — persis alasan kerangka faktor harus diterapkan sebelum membaca tabel.

Tiga Studi Kasus #

Kasus 1: Jaringan Ritel Nasional #

Tim data lima belas orang telah lima tahun di Airflow dengan lebih dari empat ratus DAG; tim analytics terbiasa dengan UI run, dan runbook on-call tersusun per DAG. Migrasi total berarti proyek berbulan-bulan tanpa fitur baru. Keputusan yang sehat: bertahan di Airflow dan menambal kelemahan lewat disiplin monitoring serta backfill. Faktor penentu: ekosistem tim.

Kasus 2: Startup Marketplace #

Tim analytics engineering empat orang membangun tabel warehouse dan dashboard sebagai produk utama; pertanyaan stakeholder yang paling sering adalah “angka ini dihasilkan dari mana”, dan pengujian data adalah prioritas mingguan. Asset graph Dagster menjawab kedua hal tersebut secara bawaan: lineage tampil di katalog, dan aset diuji sebagai fungsi Python. Keputusan: Dagster. Faktor penentu: model mental aset.

Kasus 3: Perusahaan Logistik #

Tim machine learning enam orang menulis Python setiap hari; jumlah task per run berubah mengikuti rute aktif, dan tidak ada tim infrastruktur khusus. Prefect membiarkan struktur workflow mengikuti logika Python, dimulai dari python berkas.py hingga work pool di satu virtual machine. Keputusan: Prefect. Faktor penentu: dinamisme workflow dan infrastruktur ringan.

Fakta Industri 2026 #

Satu fakta industri perlu dicatat secara netral: pada Juli 2026, Prefect mengakuisisi Dagster Labs, namun keduanya tetap berjalan sebagai produk terpisah. Bagi tim yang sedang mengevaluasi, implikasi praktisnya sederhana: kedua produk tetap layak dinilai terpisah berdasarkan faktor di atas, tanpa bersandar pada spekulasi masa depan produk. Dokumentasi ketiganya tetap menjadi rujukan utama: dokumentasi Apache Airflow , dokumentasi Dagster , dan dokumentasi Prefect .

Alur Keputusan #

Diagram berikut merangkum bab ini menjadi alur untuk diskusi tim:

Tiga cabang keputusannya membaca tabel dan studi kasus di atas secara langsung:

• Cabang pertama berhenti di konsistensi tim — persis jalan studi kasus ritel.
• Cabang aset data berakhir di Dagster, terpicu kebutuhan lineage — jalan studi kasus marketplace.
• Cabang urutan task bertanya soal dinamisme: jawaban ya berakhir di Prefect (studi kasus logistik), jawaban tidak di Airflow.

Ringkasan Keputusan #

Dengan orchestrator terpilih dan workflow berjalan terjadwal, fokus kita bergeser dari kerangka pipeline ke isinya: pola batch dan incremental, idempotency, checkpointing, hingga recovery. Section berikutnya, Data Pipeline Engineering, membahasnya tuntas.