Konsep Workflow Orchestration

Pukul dua pagi, pipeline penjualan harian berjalan keliru: langkah agregasi dieksekusi sebelum data pesanan selesai dimuat, dan laporan pagi menampilkan angka yang salah. Seminggu kemudian kejadian serupa berulang karena API sumber data mengalami gangguan singkat dan tidak ada mekanisme yang mencoba ulang. Cron, penjadwal berbasis waktu yang andal selama puluhan tahun, tetap menjalankan perintah tepat waktu — tetapi cron tidak memahami urutan langkah, tidak menangani kegagalan, dan tidak bisa menjawab pertanyaan sederhana: job mana yang gagal semalam? Workflow orchestration adalah disiplin yang mengambil alih persoalan tersebut: mendefinisikan pipeline sebagai kumpulan task yang saling bergantung, lalu menjalankan, mengawasi, dan memperbaikinya secara otomatis.

Mengapa Cron Tidak Lagi Cukup #

Cron menjalankan satu perintah pada waktu tertentu dan berhenti di situ. Model sederhana tersebut cukup selama pipeline terdiri dari satu-dua job mandiri. Tiga keterbatasan muncul begitu pipeline bertambah banyak dan saling bergantung:

• Dependency: cron tidak mengenal konsep “job B harus menunggu job A selesai”. Solusi yang sering dijumpai adalah memberi jeda waktu — job B dijadwalkan 30 menit setelah job A — dan pendekatan tersebut rapuh ketika job A berjalan lambat.
• Retry: cron hanya mencatat kode keluar gagal, lalu berhenti. Gangguan jaringan singkat yang seharusnya cukup diselesaikan dengan mencoba ulang justru menuntut campur tangan manual.
• Visibilitas: log tersebar di berkas yang berbeda untuk setiap job, sehingga tidak ada satu tempat untuk melihat status seluruh pipeline — apakah run kemarin sukses, berapa lama durasinya, dan langkah mana yang lambat.

Kombinasi skrip shell dan cron sebenarnya adalah orchestrator buatan sendiri, hanya saja logika dependency, retry, dan pencatatan status harus ditulis serta dirawat manual. Workflow orchestrator memindahkan seluruh pekerjaan tersebut ke platform yang sudah teruji, dan tim data tinggal fokus pada logika pipeline.

Apa yang Dikerjakan Orchestrator #

Orchestrator menjalankan pipeline sebagai sistem yang mengenal struktur dan riwayatnya sendiri. Kemampuan inti yang ditawarkan:

• menjalankan task sesuai urutan dependency, otomatis dan berulang;
• penjadwalan berbasis waktu dengan cron expression atau interval;
• retry dan timeout per task tanpa menulis ulang logika;
• pencatatan status, durasi, dan log setiap run di satu tempat;
• notifikasi ketika workflow gagal atau melewati batas waktu yang diharapkan;
• backfill untuk menjalankan ulang periode lampau;
• antarmuka visual untuk melihat seluruh pipeline beserta statusnya.

Inti dari daftar tersebut: pipeline berubah dari sekadar “perintah berjadwal” menjadi sistem yang bisa diinterogasi — run mana yang gagal dan di task mana.

Komponen Inti: DAG, Task, Scheduler, dan Executor #

Empat istilah ini menjadi kosakata bersama hampir semua orchestrator. DAG (directed acyclic graph) adalah definisi pipeline: task sebagai simpul dan dependency sebagai garis berarah, dengan syarat tidak boleh ada siklus — siklus membuat task saling menunggu tanpa akhir. Task adalah satu unit kerja: baca tabel sumber, validasi schema, agregasi, atau tulis partisi ke warehouse. Scheduler membaca definisi DAG, menentukan run yang jatuh tempo, dan memilih task yang seluruh upstream-nya telah sukses. Executor adalah mekanisme yang benar-benar menjalankan task — dari proses lokal sederhana sampai pod Kubernetes per task.

Tiga Orchestrator Populer #

Airflow lahir di Airbnb pada 2014 lalu menjadi proyek Apache, dan kini menjadi standar de facto orkestrasi batch. Sejak Airflow 3 (rilis April 2025), penulisan DAG berpindah ke import from airflow.sdk import dag, task — detail yang akan kita pakai di chapter Airflow nanti. Dagster memandang pipeline dari sisi aset data: tabel dan berkas adalah warga kelas satu, lengkap dengan lineage serta pemeriksaan kualitas bawaan. Prefect menonjolkan pengalaman pengembang Python dengan flow yang bisa dibangun dinamis saat runtime. Sebagai fakta industri: pada Juli 2026 Prefect mengakuisisi Dagster Labs, dan keduanya tetap berjalan sebagai produk terpisah. Rujukan resmi ketiganya: dokumentasi Apache Airflow , dokumentasi Dagster , dan dokumentasi Prefect .

Apapun orchestrator yang kelak dipilih, konsep paling fundamental tetap sama: task sebagai satuan kerja dan dependency sebagai pengikat urutannya. Chapter Dependency dan Task membedah konsep tersebut sampai ke implementasi task graph mini dengan Python murni.