Proyek Proyek: Data Warehouse Penjualan menutup pekerjaan dengan satu pertanyaan terbuka: pipeline pemuatan warehouse baru berjalan sempurna bila dijalankan sekali, tetapi siapa yang menjalankannya setiap malam selama berbulan-bulan? Cron pada Proyek: Pipeline ETL Terjadwal sudah menjawab sebagian, tetapi cron hanya tahu waktu, tidak tahu urutan antar tahap, tidak mencoba ulang kegagalan dengan kebijakan yang sadar konten, dan tidak punya catatan eksekusi yang bisa dibaca dari satu layar. Bagian ini memetakan masalah tersebut menjadi kosakata orchestration sebelum kita menulis satu baris DAG.
Dari Pipeline ke Orkestrasi #
Setiap keterbatasan cron berubah menjadi fitur inti sebuah orchestrator. Tabel berikut merangkum persoalan operasional TokoKita dan mekanisme yang menjawabnya di Apache Airflow:
| Persoalan operasional | Dengan cron saja | Yang disediakan orchestrator |
|---|---|---|
| Tahap extract berhasil tetapi load gagal | Exit code tercatat, urutan tidak dipahami | Task dan dependency: setiap tahap adalah unit yang terlihat |
| Partisi pukul 02:30 belum selesai diunggah | Run gagal, selesai | Retry otomatis dengan jeda per task |
| Scheduler mati tiga hari | Hari tersebut hilang, perlu skrip manual | catchup: run yang terlewat dibuat ulang dari start_date |
| “Sudah sampai tanggal berapa pipeline ini?” | Baca manifest tiap run satu per satu | UI eksekusi plus watermark pada state kita |
| Query: berapa lama tahap transform kemarin? | Hitung selisih log manual | Durasi tiap task tercatat pada DAG run |
| Task lambat menggantung worker | Berjalan sampai selesai sendiri | execution_timeout memutus task yang melampaui batas |
Perbedaan mendasarnya: cron menjalankan perintah, sedangkan orchestrator menjalankan workflow — graf berarah (DAG) dari task-task berdependensi yang memiliki jadwal, riwayat, dan kebijakan kegagalan. Cron tetap punya tempatnya untuk pekerjaan satu perintah; tetapi begitu pekerjaan punya tahapan, riwayat, dan kebijakan ulang, deklarasi workflow menjadi alat yang tepat. Konsep umumnya dibahas pada chapter Konsep Workflow Orchestration.
Istilah Inti Airflow #
Lima istilah berikut dipakai di seluruh proyek ini, jadi kita kunci dulu maknanya:
| Istilah | Makna | Padanan di proyek ini |
|---|---|---|
| DAG | Definisi workflow: task, dependency, dan jadwal dalam satu berkas Python | dags/etl_pesanan.py |
| Task | Satu unit kerja di dalam DAG | ekstrak, transform, muat, laporan, alarm_kegagalan |
| DAG run | Satu eksekusi DAG untuk satu periode data | Run untuk partisi 2026-11-02 |
| Logical date | Penanda periode data yang diolah, bukan jam dinding run | ds = 2026-11-02 |
| Data interval | Rentang waktu data yang menjadi tanggung jawab satu run | [02:30, 02:30) sehari |
Perbedaan logical date dan jam dinding adalah sumber kebingungan paling umum saat belajar Airflow. Run untuk partisi 2026-11-02 pada jadwal malam berjalan pada dini hari 2026-11-03; keduanya dicatat terpisah sehingga eksekusi ulang periode lama tetap jelas periode datanya. Chapter Apache Airflow membahas arsitektur di baliknya — scheduler, executor, dan metadata database — yang tidak kita bangun ulang di sini.
Dalam satu siklus hidup run, ketiga istilah itu bertemu: scheduler membuat DAG run untuk satu data interval, logical date run menjadi ds yang disuntikkan ke setiap task, dan lima task mengeksekusi pekerjaan bergantian sesuai dependency:
Bagian 5 membedah hubungan interval dan ds sampai ke tabel runnya; saat ini cukup pegang bentuk besarnya: jadwal menentukan interval, interval menentukan run, dan run menentukan partisi mana yang diolah.
Data dan Aturan yang Diwariskan #
Pipeline yang diorkestrasi adalah versi sederhana dari pipeline ETL terjadwal sebelumnya. Masukannya partisi CSV harian dengan empat kolom, dan pengujian kita menumbuhkan partisi persis seperti ini:
# Partisi contoh: spasi berlebih, rupiah berformat, status huruf besar,
# satu pesanan_id ganda (kemunculan terakhir menang), dan baris rusak.
BARIS_11_02 = [
{"pesanan_id": "ORD-101", "kota": "Jakarta", "status": "selesai", "total": "Rp355.000"},
{"pesanan_id": "ORD-102", "kota": " Bandung ", "status": "Selesai", "total": "175.000"},
{"pesanan_id": "ORD-103", "kota": "Surabaya", "status": "DIPROSES", "total": "98000"},
{"pesanan_id": "ORD-104", "kota": "Jakarta", "status": "selesai", "total": "Rp 210.000"},
{"pesanan_id": "ORD-105", "kota": "", "status": "selesai", "total": "50000"},
{"pesanan_id": "ORD-106", "kota": "Bandung", "status": "batal", "total": "30000"},
{"pesanan_id": "ORD-104", "kota": "Jakarta", "status": "selesai", "total": "Rp 215.000"},
]Aturan pembersihannya kita bawa dari proyek sebelumnya dalam bentuk ringkas:
| Aturan | Perilaku |
|---|---|
| Spasi berlebih dipangkas dari seluruh kolom | " Bandung " menjadi "Bandung" |
| Status dibaca huruf kecil dan harus dikenal | DIPROSES sah; batal ditolak dengan alasan |
| Total dibaca sebagai rupiah | "Rp 215.000", "175.000", dan "98000" menjadi int |
| Baris rusak ditolak, bukan dibuang diam-diam | Dicatat dengan nomor baris dan alasan |
pesanan_id ganda | Kemunculan terakhir menang, sisanya dihitung duplikat |
Hasil akhirnya dua keluaran per tanggal: data/gold/summary_harian_YYYY-MM-DD.csv (jumlah pesanan dan omzet per kota) serta data/state/state.json (watermark dan catatan per tanggal). Dibanding proyek ETL terjadwal, zona karantina dan manifest per run tidak dibawa — fokus proyek ini adalah orchestration, bukan panjangnya kode ETL.
Yang diwariskan dari dua proyek sebelumnya tetap banyak, dan itu disengaja agar kosakata kita tidak berubah di tengah jalan:
| Warisan | Asal | Perannya di proyek ini |
|---|---|---|
Zona data/raw → data/gold | Pipeline ETL terjadwal | Pemisahan data mentah dan hasil siap baca |
Watermark di data/state | Pipeline ETL terjadwal | Gerbang idempotensi dan sumber pemantauan |
| Kebiasaan jadwal 02:30 malam | Pipeline ETL terjadwal | Cron 30 2 * * * pada berkas DAG |
| Data pesanan TokoKita | Data warehouse penjualan | Domain dan aturan bisnis yang sama |
Lingkup dan Batasan yang Kita Pegang #
Yang dibangun pada proyek ini:
| Deliverable | Berkas | Diverifikasi lewat |
|---|---|---|
| Definisi workflow | dags/etl_pesanan.py | py_compile + pengujian ast |
| Logika ETL dan watermark | src/tasks.py, src/state.py | pytest |
| Pengujian | tests/ (4 berkas + fixture) | pytest |
| Konfigurasi environment | config/requirements.txt, config/connections.example.yaml | Dibaca manusia, dipakai saat deploy |
Prasyaratnya pun ringkas: selesaikan Proyek: Pipeline ETL Terjadwal agar pola zona data dan watermark terasa familier, dan baca chapter Konsep Workflow Orchestration untuk peta besar orchestrator. Pengalaman memakai Airflow tidak disyaratkan — seluruh konsep yang dipakai diperkenalkan di tempatnya.
Yang dipegang jujur sebagai batasan:
Dengan batasan itu, setiap bagian tetap menghasilkan sesuatu yang berjalan: pengujian hijau, keluaran demonstrasi nyata, atau verifikasi sintaks. Saat lingkungan Airflow tersedia, seluruh berkas proyek bisa langsung dipakai tanpa perubahan.
Mengapa Airflow dan bukan orchestrator lain? Ekosistemnya paling luas, konsepnya (DAG, run, catchup) menjadi kosakata bersama industri, dan chapter Dagster serta Prefect menunjukkan alternatif dengan kekuatan berbeda — Dagster berorientasi aset data, Prefect ringan untuk orkestrasi Python. Perbandingan cara memilihnya dibahas pada chapter Memilih Workflow Orchestrator; untuk pipeline batch harian seperti TokoKita, Airflow adalah pilihan yang aman dipelajari.
Peta Sembilan Bagian #
Bagian 2 menyiapkan struktur direktori dan konfigurasi; Bagian 3 sampai 6 membangun berkas DAG bertahap (anatomi, dependency, scheduling, retry dan timeout); Bagian 7 dan 8 mengurus backfill serta pemantauan; Bagian 9 menutup dengan strategi pengujian.
Setiap bagian diakhiri kode atau keluaran yang benar-benar berjalan, jadi proyek ini bisa dikerjakan sambil memverifikasi setiap langkah.
Bacaan pendamping terbaik saat mengerjakan proyek ini adalah dokumentasi resmi Apache Airflow , dan istilah scheduling serta backfill akan banyak merujuk chapter Scheduling dan Backfill.