Parameterisasi Workflow

Workflow yang sama hampir selalu dibutuhkan dalam beberapa varian: dijalankan untuk hari ini atau untuk tanggal historis saat backfill, menargetkan environment dev atau produksi, membaca dari API atau dari berkas yang diunggah partner. Menulis setiap varian sebagai kode terpisah adalah sumber bug klasik — dua salinan kode perlahan berbeda dan tidak ada yang yakin salinan mana yang benar. Parameterisasi menyelesaikan persoalan tersebut: satu definisi workflow, banyak run, dan setiap run membawa parameternya sendiri.

Parameter Run: Tanggal, Environment, dan Sumber #

Segala nilai yang berubah antar run adalah parameter, bukan konstanta. Empat kelompok yang paling sering dijumpai:

• tanggal proses: periode data yang diproses — hari ini, kemarin, atau rentang backfill;
• environment: dev, staging, atau produksi, yang menentukan sumber data serta tujuan output;
• sumber data: pilih antar API, berkas, atau replika database;
• opsi teknis: format output, ambang batas validasi, atau jumlah batch.

Template: Konsep {{ ds }} #

Orchestrator menyediakan template string yang nilainya diganti pada saat run. Di Airflow, {{ ds }} diganti menjadi data interval start berformat YYYY-MM-DD, {{ ds_nodash }} menjadi format tanpa tanda hubung, dan {{ params.nama }} untuk parameter kustom yang dideklarasikan pada DAG.

Dalam gaya Airflow 3, parameter kustom dideklarasikan lewat argumen params pada decorator @dag — misalnya params={"env": "dev"} — dan nilai bawaannya bisa ditimpa per run dari UI maupun command line. Cara menyusun template dan konteksnya dijelaskan dalam dokumentasi Apache Airflow , sementara detail Task SDK tersedia di dokumentasi Airflow Task SDK .

Config File vs Argumen Command Line #

Pola yang umum dipakai: nilai bawaan hidup di config file yang ikut di-review bersama kode, sementara argumen command line berperan sebagai penimpa untuk eksperimen dan run satu kali. Dengan begitu, perilaku produksi selalu bisa ditelusuri ke satu berkas di repositori.

Default dan Override #

Setiap parameter sebaiknya memiliki nilai bawaan yang membuat workflow tetap bisa dijalankan tanpa argumen apa pun — biasanya mode paling aman untuk pengembangan. Run produksi kemudian menimpa sebagian nilai saja. Validasi nilai, misalnya membatasi environment ke daftar yang sah, mencegah salah ketik lolos ke sistem hilir.

Workflow Parameterized dengan argparse dan Template #

Contoh berikut menggabungkan seluruh konsep di atas dalam satu skrip: fungsi render_template menjadi versi mini dari templating Airflow, jalankan_pipeline menerima parameter eksplisit dengan nilai bawaan, dan argparse mengubah argumen command line menjadi parameter run.

"""Workflow parameterized: default + override via argparse, plus template mini."""
import argparse
from datetime import date


def render_template(teks, konteks):
    for kunci, nilai in konteks.items():
        teks = teks.replace("{{ " + kunci + " }}", str(nilai))
    return teks


def jalankan_pipeline(tanggal, environment, sumber, format_output="parquet"):
    konteks = {
        "ds": tanggal.isoformat(),
        "ds_nodash": tanggal.strftime("%Y%m%d"),
        "env": environment,
    }
    path = render_template("s3://data-{{ env }}/pesanan/tanggal={{ ds }}/part-{{ ds_nodash }}", konteks)
    print(f"[{environment}] {sumber} -> {path} (format: {format_output})")
    return path


parser = argparse.ArgumentParser(description="Pipeline pesanan harian")
parser.add_argument("--tanggal", type=date.fromisoformat, default=date(2026, 1, 15))
parser.add_argument("--env", choices=["dev", "staging", "prod"], default="dev")
parser.add_argument("--sumber", default="api")
parser.add_argument("--format", dest="format_output", default="parquet")
args = parser.parse_args()

jalankan_pipeline(args.tanggal, args.env, args.sumber, args.format_output)

Tanpa argumen apa pun, seluruh nilai bawaan terpakai:

python3 parameterisasi.py

Output yang Dihasilkan:

[dev] api -> s3://data-dev/pesanan/tanggal=2026-01-15/part-20260115 (format: parquet)

Run produksi menimpa tanggal, environment, sumber, dan format sekaligus:

python3 parameterisasi.py --tanggal 2026-01-20 --env prod --sumber warehouse --format csv

Output yang Dihasilkan:

[prod] warehouse -> s3://data-prod/pesanan/tanggal=2026-01-20/part-20260120 (format: csv)

Mari kita telaah baris-baris kode di atas:

1. Baris 6-9 (render_template): mengganti setiap pola {{ kunci }} dengan nilainya — versi mini dari mekanisme templating yang dijalankan orchestrator sebelum task dieksekusi.
2. Baris 12 (jalankan_pipeline): seluruh parameter menjadi argumen eksplisit; hanya format_output yang memiliki nilai bawaan parquet di tingkat fungsi.
3. Baris 13-18 (konteks run): pemetaan nama template ke nilai run — ds, ds_nodash, dan env — lalu path output dibangun dari satu template string, sama seperti pola penulisan path partisi di Airflow.
4. Baris 23-27 (argparse): setiap argumen dideklarasikan dengan tipe dan nilai bawaan; choices membatasi --env ke tiga nilai sah sehingga salah ketik langsung ditolak; dest memetakan flag --format ke parameter format_output.
5. Baris 30: nilai hasil parsing diteruskan ke fungsi workflow — batas antara antarmuka command line dan logika pipeline tetap bersih.

Dengan parameterisasi, satu definisi workflow melayani hari ini, historis backfill, dan berbagai environment sekaligus. Perjalanan kita melalui blok bangunan orkestrasi — dependency, scheduling, retry, backfill, parameter — kini lengkap; pertanyaan berikutnya adalah memastikan semuanya tetap sehat saat berjalan, pokok bahasan Chapter Monitoring Workflow.