Apache Airflow 2026: Pipeline Orkestrasyonu, DAG Mimarisi ve Mülakat Soruları

Apache Airflow 3.2, açık kaynak orkestrasyon platformunun 3.0 sürümündeki köklü mimari yenilemeden bu yana gerçekleştirilen en kapsamlı güncellemeyi temsil etmektedir. PyPI üzerinden aylık 10 milyonu aşan indirme sayısı ve Airbnb'den Spotify'a kadar uzanan geniş bir benimseme yelpazesiyle Airflow, veri hatlarının oluşturulması, zamanlanması ve izlenmesi alanında sektörün baskın aracı olmayı sürdürmektedir. Bu rehber, yeni Task SDK ile DAG geliştirme sürecini, pipeline orkestrasyon kalıplarını ve veri mühendisliği pozisyonlarına yönelik mülakat sorularını uygulamalı kod örnekleriyle ele almaktadır.

Task SDK ile DAG Geliştirme

Airflow 3.0 ile birlikte sunulan Task SDK, DAG tanımlarını Airflow'un iç mekanizmalarından bağımsızlaştıran ayrı bir paket olarak tasarlanmıştır. Temel hedef, Airflow sürüm güncellemelerinde kod değişikliği gerektirmeden sorunsuz çalışmaya devam eden, taşınabilir ve sürüm uyumlu DAG'lar oluşturmaktır. DAG, dag, task, BaseOperator, Connection ve Variable gibi tüm temel nesneler artık airflow.sdk altında konumlandırılmıştır.

Eski import yolları (airflow.decorators.task, airflow.models.dag.DAG) 3.2 sürümünde hala işlevsel olmakla birlikte kullanım dışı (deprecated) olarak etiketlenmiştir ve ilerleyen sürümlerde tamamen kaldırılacaktır.

# etl_daily_revenue.py
import pendulum
from airflow.sdk import dag, task

@dag(
    schedule="@daily",
    start_date=pendulum.datetime(2026, 1, 1, tz="UTC"),
    catchup=False,
    tags=["finance", "etl"],
)
def etl_daily_revenue():
    @task()
    def extract_transactions() -> list[dict]:
        # Pulls raw transactions from the payments API
        import requests
        response = requests.get("https://api.internal/payments/daily")
        return response.json()["transactions"]

    @task(multiple_outputs=True)
    def transform(transactions: list[dict]) -> dict:
        # Aggregates by currency and computes totals
        totals = {}
        for tx in transactions:
            currency = tx["currency"]
            totals[currency] = totals.get(currency, 0) + tx["amount"]
        return {"totals": totals, "count": len(transactions)}

    @task()
    def load(totals: dict, count: int):
        # Inserts aggregated row into the warehouse
        from warehouse import insert_revenue_summary
        insert_revenue_summary(totals=totals, transaction_count=count)

    raw = extract_transactions()
    result = transform(raw)
    load(result["totals"], result["count"])

etl_daily_revenue()

@dag dekoratoru, geleneksel with DAG(...) bağlam yöneticisinin (context manager) yerini almaktadır. @task dekoratoru ise standart Python fonksiyonlarını Airflow görevlerine donuştürür ve XCom serileştirme işlemi otomatik olarak gerçekleştirilir. Kodda yer alan transform(raw) çağrısı bir bağımlılık ilişkisi tanımlar; Airflow bu fonksiyon çağrı grafiğinden DAG kenarlarını otomatik olarak oluşturur.

Değişken İş Yükleri İçin Dinamik Görev Eşlemesi

Statik DAG yapıları, işlenecek öğe sayısının çalıştırmalar arasında değişkenlik gösterdiği durumlarda yetersiz kalmaktadır. Airflow 2.4'ten itibaren kararlı hale getirilen ve 3.x serisinde daha da olgunlaştırılan dinamik görev eşlemesi (dynamic task mapping), .expand() yöntemini kullanarak görevlerin çalışma zamanında genişletilmesine olanak tanır.

# etl_multi_region.py
import pendulum
from airflow.sdk import dag, task

@dag(
    schedule="@hourly",
    start_date=pendulum.datetime(2026, 1, 1, tz="UTC"),
    catchup=False,
    tags=["regional", "etl"],
)
def etl_multi_region():
    @task()
    def get_regions() -> list[str]:
        # Returns the active regions from config
        return ["us-east-1", "eu-west-1", "ap-southeast-1"]

    @task()
    def process_region(region: str) -> dict:
        # Processes events for a single region
        from data_processor import aggregate_events
        return aggregate_events(region)

    @task()
    def merge_results(results: list[dict]):
        # Combines all regional outputs into a single report
        from reporter import publish_global_report
        publish_global_report(results)

    regions = get_regions()
    # .expand() creates one mapped task instance per region
    processed = process_region.expand(region=regions)
    merge_results(processed)

etl_multi_region()

Çalışma zamanında Airflow, her bölge için bir tane olmak üzere üç paralel process_region örneği oluşturur. Ertesi gün dördüncü bir bölge eklenirse DAG kodunda herhangi bir düzenleme yapılmasına gerek kalmaz. merge_results görevi, tüm eşlenmiş örneklerin tamamlanmasını bekledikten sonra yürütülür.

Airflow 3.2'de Asset Partition'ları ile Veriye Duyarlı Zamanlama

Airflow 3.2 öncesinde veriye duyarlı zamanlama yalnızca asset düzeyinde çalışıyordu: bir üretici DAG herhangi bir asset'i güncellediğinde, hangi veri diliminin değiştiğinden bağımsız olarak tüm tüketici DAG'lar tetikleniyordu. Asset partition'ları, bölüm düzeyinde ayrıntı sunarak bu sorunun üstesinden gelmektedir.

Üç farklı yukarı akış DAG'ının farklı spor ligleri için saatlik oyuncu istatistikleri ürettiği bir senaryoyu ele alalım. Aşağı akış analitik DAG'ının yalnızca üç ligin de aynı saat dilimi için veri yayımladığı durumda tetiklenmesi gerekmektedir.

# downstream_analytics.py
import pendulum
from airflow.sdk import dag, task
from airflow.timetables.assets import CronPartitionTimetable

# Define partitioned assets with hourly granularity
nba_stats = Asset("s3://datalake/nba/hourly/", partitions=CronPartitionTimetable("0 * * * *"))
epl_stats = Asset("s3://datalake/epl/hourly/", partitions=CronPartitionTimetable("0 * * * *"))
nfl_stats = Asset("s3://datalake/nfl/hourly/", partitions=CronPartitionTimetable("0 * * * *"))

@dag(
    # Triggers only when all three assets have matching partition
    schedule=(nba_stats & epl_stats & nfl_stats),
    start_date=pendulum.datetime(2026, 1, 1, tz="UTC"),
    catchup=False,
)
def unified_sports_analytics():
    @task()
    def aggregate_all_leagues(**context):
        partition = context["partition"]
        # Process only the specific hourly slice across all leagues
        from analytics import build_cross_league_report
        build_cross_league_report(partition=partition)

    aggregate_all_leagues()

unified_sports_analytics()

Partition tabanlı zamanlama, gereksiz pipeline çalıştırmalarını ortadan kaldırmaktadır. Aşağı akış DAG'ı yalnızca ihtiyaç duyduğu belirli partition tüm yukarı akış kaynaklarında hazır olduğunda tetiklenir; eksik veya kısmi veri durumunda çalıştırma başlatılmaz.

I/O Yoğun İş Yüklerinde Yerleşik Async Görev Desteği

Airflow 3.2, PythonOperator'e yerleşik async desteği getirmektedir. Önceki sürümlerde, eş zamanlı I/O işlemlerinin (binlerce API çağrısı, toplu dosya indirmeleri gibi) yürütülmesi özel deferrable operatörlerin yazılmasını gerektiriyordu. Yeni sürümde doğrudan bir async fonksiyon tanımlamak yeterli olmaktadır.

# async_file_download.py
import asyncio
import aiohttp
from airflow.sdk import dag, task
import pendulum

@dag(
    schedule="@daily",
    start_date=pendulum.datetime(2026, 1, 1, tz="UTC"),
    catchup=False,
    tags=["async", "download"],
)
def async_file_download():
    @task()
    async def download_files():
        urls = [f"https://data.source/files/{i}.csv" for i in range(500)]
        async with aiohttp.ClientSession() as session:
            # Downloads 500 files concurrently instead of sequentially
            tasks = [fetch_and_save(session, url) for url in urls]
            results = await asyncio.gather(*tasks)
        return {"downloaded": len(results)}

    download_files()

async def fetch_and_save(session: aiohttp.ClientSession, url: str):
    async with session.get(url) as resp:
        content = await resp.read()
        filename = url.split("/")[-1]
        with open(f"/data/downloads/{filename}", "wb") as f:
            f.write(content)
        return filename

async_file_download()

Async yaklaşım, tek bir worker slot'u kullanarak 500 dosyayı eş zamanlı olarak indirmeyi mümkün kılar; senkron sürümde ise aynı işlem 500 ardışık HTTP isteği gerektirir. I/O bağımlı iş yüklerinde bu yöntem, ek worker kaynağı tahsis etmeye gerek kalmadan büyüklük mertebesi düzeyinde hız kazancı sağlamaktadır.

Airflow Mimarisi: Temel Bileşenler ve Yürütme Akışı

Airflow mimarisini kavramak, hem üretim ortamında platformu işletmek hem de teknik mülakatlarda başarılı olmak açısından kritik öneme sahiptir. Her DAG çalıştırmasında beş temel bileşen birbirleriyle etkileşim halindedir:

• Scheduler -- DAG dosyalarını ayrıştırır, bağımlılıkları çözer ve görevleri yürütme kuyruğuna ekler. Airflow 3.x serisinde scheduler, metadata veritabanına karşı durumsuz (stateless) bir şekilde çalışmaktadır.
• Executor -- Görevlerin hangi ortamda yürütüleceğini belirler. LocalExecutor tek sunucu kurulumlarına uygundur. CeleryExecutor görevleri birden fazla worker düğümü arasında dağıtır. KubernetesExecutor ise her görev için bağımsız bir pod oluşturur.
• Worker'lar -- Görev kodunun fiili yürütülmesini gerçekleştirir. Airflow 3.0'da sunulan Task Execution API ile worker'lar kararlı bir arayüz üzerinden iletişim kurar; bu sayede görevler konteyner ortamlarında, uç noktalarda veya harici çalışma zamanlarında yürütülebilir.
• Metadata veritabanı -- PostgreSQL (önerilen) veya MySQL. DAG tanımlarını, görev durumlarını, XCom değerlerini, bağlantı kimlik bilgilerini ve denetim kayıtlarını depolar.
• Web sunucusu -- DAG çalıştırmalarını izlemek, günlük kayıtlarını incelemek, manuel çalıştırmaları başlatmak ve bağlantıları yönetmek için kullanılan Airflow kullanıcı arayüzüdür.

2026'da Airflow, Prefect ve Dagster Karşılaştırması

Airflow, veri hattı orkestrasyonu alanında iki güçlü alternatifle rekabet etmektedir. En uygun aracın seçimi; ekip büyüklüğü, mevcut altyapı ve oluşturulan pipeline türlerine göre şekillenmektedir.

| Özellik | Airflow 3.2 | Prefect 3.x | Dagster 1.9 | |---|---|---|---| | DAG tanımlama | Python dekoratörleri (airflow.sdk) | Python dekoratörleri (@flow, @task) | Python dekoratörleri (@asset, @op) | | Zamanlama | Cron, asset-aware, partition-aware | Cron, olay tabanlı | Cron, sensor tabanlı, asset-aware | | Yürütme modeli | Merkezi scheduler + dağıtık worker'lar | Hibrit (sunucu + iş havuzları) | Merkezi dagster-daemon | | Dinamik görevler | .expand() ile eşlenmiş görevler | Yerel Python döngüleri | Dinamik partition'lar | | Async desteği | 3.2'de yerleşik | 2.0'dan beri yerleşik | Async I/O işlemleri | | Çok ekipli izolasyon | Yerleşik (3.2 deneysel) | Workspace tabanlı (Cloud) | Branch dağıtımları | | Topluluk büyüklüğü | En büyük (35.000+ GitHub yıldızı) | Büyüyen (18.000+ yıldız) | Büyüyen (12.000+ yıldız) | | En uygun senaryo | Yerleşik altyapıya sahip karmaşık, çok ekipli hatlar | Hızlı iterasyon isteyen küçük ekipler | Veri varlığı odaklı organizasyonlar |

Airflow'un temel avantajı ekosisteminin genişliğinde yatmaktadır: tüm büyük bulut hizmetlerini, veritabanlarını ve API'leri kapsayan 80'den fazla provider paketi sunmaktadır. Prefect, daha az boilerplate koduyla geliştirici deneyiminde öne çıkmaktadır. Dagster'ın varlık merkezli (asset-centric) modeli ise iş akışlarını görev sıraları yerine veri ürünleri perspektifinden değerlendiren ekipler için daha uygundur.

Veri Mühendisleri İçin Apache Airflow Mülakat Soruları

Aşağıdaki sorular, Airflow'u üretim ortamında kullanan şirketlerin işe alım süreçlerinde karşılaşılan gerçek mülakat sorularını yansıtmaktadır.

DAG nedir ve Airflow bunu nasıl kullanır?

DAG (Directed Acyclic Graph - Yönlü Döngüsüz Çizge), bir iş akışını bağımlılık ilişkileri olan görevler bütünü olarak tanımlar ve yapı gereği döngüsel referanslar barındıramaz. Airflow, dags/ dizinindeki Python dosyalarını ayrıştırır, bağımlılık grafiğini oluşturur ve scheduler yürütme sırasını belirler. Her DAG çalıştırması, mantıksal bir tarihle ilişkilendirilmiş bir DagRun nesnesi oluşturur. "Döngüsüz" kısıtlaması, scheduler'ın her zaman geçerli bir yürütme sırası bulabilmesini garanti altına alır: görev A, görev B'den önce tamamlanır ve bu sıralama eş zamanlı olarak tersine çevrilemez.

XCom nasıl çalışır ve hangi durumlarda kullanılmamalıdır?

XCom (cross-communication), görevler arasında küçük boyutlu veri parçalarının aktarılmasını sağlayan bir mekanizmadır. Bir görev, dönüş değerini XCom'a yazar; aşağı akıştaki görevler bu değeri okur. Task SDK, dekoratörlü görevler arasında fonksiyon dönüş değerlerinin aktarımını otomatik olarak yönetir. XCom verileri varsayılan olarak metadata veritabanında saklandığından, büyük veri kümeleri (birkaç kilobaytı aşan veriler) için uygun değildir. Hacimli veri aktarımlarında harici depolama çözümleri (S3, GCS) kullanılmalı ve XCom üzerinden yalnızca referans yolu iletilmelidir.

schedule, start_date ve catchup parametreleri arasındaki farklar nelerdir?

schedule parametresi (Airflow 3.x'te schedule_interval yerine geçmiştir), DAG'ın çalışma sıklığını tanımlar: bir cron ifadesi, timedelta nesnesi, timetable nesnesi veya asset tetikleyicisi biçiminde olabilir. start_date, DAG çalıştırmasının oluşturulabileceği en erken mantıksal tarihi belirler. catchup=True (varsayılan değer), start_date ile mevcut zaman arasında kaçırılmış tüm aralıklar için geriye dönük DAG çalıştırmaları oluşturur. catchup=False olarak ayarlandığında scheduler geçmiş aralıkları atlayarak yalnızca güncel zamandan itibaren zamanlama gerçekleştirir. Yaygın bir üretim uygulaması olarak operasyonel DAG'larda catchup=False, tarihsel veri yeniden işleme süreçlerinde ise catchup=True tercih edilmektedir.

KubernetesExecutor ile CeleryExecutor arasındaki temel farklar nelerdir?

CeleryExecutor, bir mesaj aracısı (Redis veya RabbitMQ) aracılığıyla bağlanan uzun ömürlü worker süreçlerinden oluşan bir havuz yönetir. Görevler kuyruğa alınır ve uygun worker'larda yürütülür. KubernetesExecutor ise her görev için, görevin Docker imajını ve kaynak gereksinimlerini temel alan yeni bir Kubernetes pod'u başlatır. Celery, pod başlatma gecikmesi olmadığından daha düşük gecikme sunar ve homojen iş yüklerinde verimli çalışır. KubernetesExecutor; daha güçlü izolasyon, görev bazında kaynak kontrolü sağlar ve sabit bir worker havuzu yönetme zorunluluğunu ortadan kaldırır. Bu özellikler, farklı bağımlılık ve bellek gereksinimlerine sahip heterojen iş yükleri için KubernetesExecutor'u ideal bir tercih haline getirir.

Görev başarısızlıklarını yönetmek için hangi stratejiler uygulanabilir?

Airflow, çok katmanlı bir başarısızlık yönetim mekanizması sunmaktadır. retries ve retry_delay parametreleri, üstel geri çekilme (exponential backoff) ile otomatik yeniden denemeleri yapılandırır. on_failure_callback, bir görev başarısız olduğunda özel mantık tetikler (Slack bildirimleri, PagerDuty olayları gibi). trigger_rule parametresi, aşağı akış görevlerinin hangi koşullarda çalışacağını belirler: all_success (varsayılan), one_success, all_failed veya none_failed_min_one_success seçenekleri mevcuttur. Geçici altyapı sorunlarına karşı retry_exponential_backoff=True parametresi, ardışık yeniden denemeler arasındaki bekleme süresini kademeli olarak artırır. SLA mekanizması (3.x sürümünde Deadline Alerts olarak yeniden adlandırılmıştır) yürütme süresini izler ve görevler öngörülen çalışma süresini aştığında uyarı geri çağrımlarını tetikler.

Üretim Ortamı İçin Airflow En İyi Uygulamaları

Airflow'u ölçeklenebilir ve güvenilir bir şekilde işletmek, doğru DAG yazmaktan çok daha fazlasını gerektirmektedir. Aşağıdaki operasyonel kalıplar, üretim ortamlarında karşılaşılan yaygın sorunları önlemeye yardımcı olur.

Idempotent görevler. Her görev, aynı girdilerle tekrar tekrar çalıştırıldığında aynı sonucu üretmelidir. Düz INSERT ifadeleri yerine INSERT ... ON CONFLICT veya MERGE kullanılmalıdır. Çıktı verileri mantıksal tarihe göre partition'lanmalıdır. Bu yaklaşım, veri çoğaltması riski olmadan güvenli yeniden denemeler ve geriye dönük toplu işlemler gerçekleştirmeyi mümkün kılar.

Küçük ve odaklı DAG yapıları. Onlarca görevi barındıran monolitik DAG'lar oluşturmaktan kaçınılmalıdır. Karmaşık pipeline'lar, asset'ler (eski adıyla dataset) aracılığıyla birbirine bağlanan birden fazla küçük DAG'a bölünmelidir. Daha küçük DAG'lar daha hızlı ayrıştırılır, hata ayıklama süreci kolaylaşır ve kısmi pipeline yeniden başlatmalarına olanak tanır.

Bağlantı yönetimi. Tüm kimlik bilgileri, Airflow'un yerleşik bağlantı yöneticisi veya harici bir gizli bilgi deposu (AWS Secrets Manager, HashiCorp Vault) aracılığıyla saklanmalıdır. Kimlik bilgilerinin DAG dosyalarına doğrudan yazılması kesinlikle yapılmamalıdır. Airflow 3.x, metadata veritabanındaki bağlantı alanlarını durağan halde (at rest) şifrelemektedir.

İzleme ve uyarı altyapısı. Airflow metrikleri Prometheus veya StatsD sistemlerine aktarılmalıdır. scheduler_heartbeat, dag_processing.total_parse_time ve executor.queued_tasks gibi kritik metrikler sürekli takip edilmelidir. Airflow 3.2, uçtan uca pipeline gözlemlenebilirliği sağlamak amacıyla OpenTelemetry izleme desteği de sunmaktadır.

Pipeline orkestrasyonu konularını kapsayan bir veri mühendisliği mülakatına hazırlanan adaylar, SharpSkill platformunun sunduğu Airflow mülakat soruları ve üretim ortamlarından alınan gerçek senaryoları yansıtan pratik modüllerinden yararlanabilir.

Sonuç

• Airflow 3.2, DAG geliştirme için kararlı API olarak Task SDK'yi (airflow.sdk) sunmaktadır; gelecekteki uyumsuzlukları önlemek adına import ifadelerinin şimdiden taşınması gerekmektedir
• Asset partition'ları, bölüm düzeyinde veriye duyarlı zamanlama sağlayarak kısmi veri güncellemelerinde gereksiz pipeline tetiklemelerini ortadan kaldırmaktadır
• PythonOperator'deki yerleşik async desteği, özel deferrable operatörlere gerek kalmadan I/O yoğun iş yüklerini (toplu indirmeler, API fan-out işlemleri) verimli bir şekilde yönetmektedir
• .expand() ile dinamik görev eşlemesi, DAG kodunda değişiklik yapılmasına gerek kalmadan değişken iş yükü boyutlarına çalışma zamanında uyum sağlamaktadır
• Mülakat hazırlığında DAG mekanikleri, executor karşılaştırmaları (Celery vs. Kubernetes), XCom sınırlılıkları ve idempotency kalıpları mutlaka ele alınmalıdır
• Üretim dağıtımları; küçük idempotent DAG'lar, harici gizli bilgi yönetimi ve gözlemlenebilirlik platformlarına metrik aktarımı ile güçlendirilmelidir