1. GİRİŞ

Apache Airflow, veri mühendisliği ve veri platformları dünyasında workflow orkestrasyonu için en yaygın kullanılan araçlardan biridir. Zamanlanmış batch job'lar, veri entegrasyon pipeline'ları, ETL/ELT iş akışları ve ML eğitim boru hattı adımlarını yönetmek için geniş çapta benimsenmiştir. Airflow'un popülaritesi, açık kaynak olması, esnek DAG (Directed Acyclic Graph) modeli, Python tabanlı görev tanımları ve zengin ekosistemi sayesinde hızla arttı. Ancak üretim ölçeğinde Airflow'u doğru mimariyle dağıtmak ve işletmek, hata toleransı, ölçeklenebilirlik ve güvenlik gereksinimlerini karşılamak için dikkatli tasarım gerektirir.

Bu teknoloji neden konuşuluyor?

Veri odaklı organizasyonlar artan sayıda otomatikleştirilmiş iş akışı çalıştırıyor; bu iş akışlarının güvenilir, izlenebilir ve kolayca değiştirilebilir olması gerekiyor. Airflow, operasyondan geliştiriciye kadar geniş bir kullanıcı kitlesine hitap eden bir orkestratördür. Bulut‑yerel çözümler ve managed Airflow servisleri yaygınlaşıyor, ama birçok ekip esneklik yüzünden kendi Airflow altyapısını işletmeye devam ediyor.

Kimler için önemli?

Veri mühendisleri, platform mühendisleri, SRE'ler ve makine öğrenimi mühendisleri için iş akışlarının güvenilir şekilde planlanması ve işletilmesi kritik. Ayrıca veri operasyonları, ETL/ELT, raporlama ve denetim süreçlerinde Airflow geniş kullanım alanı bulur.

Hangi problemleri çözüyor?

• Zamanlanmış ve bağımlı görevlerin yönetimi.
• Fail/retry politikaları, görevlere ait metadata'nın merkezi yönetimi.
• Task bağımlılıklarının declarative şekilde tanımlanması ve görselleştirilmesi.

2. KAVRAMSAL TEMELLER

2.1 Airflow’un Temel Kavramları

DAG (Directed Acyclic Graph)

DAG, görevlerin (tasks) ve bu görevler arasındaki bağımlılıkların tanımlandığı yapıdır. Her DAG bir workflow'u temsil eder.

Task

DAG içindeki en küçük yürütülebilir birimdir. PythonOperator, BashOperator, SparkSubmitOperator gibi çeşitleri vardır.

Operator

Task'ların tipini belirleyen sınıflardır. Operator, belirli bir eylemi temsil eder (ör. bir SQL çalıştırma, bir Spark job submit).

Scheduler

DAG'ları zamanlar ve hangi task'ların çalıştırılacağına karar verir.

Executor

Task'ları paralel olarak çalıştıran bileşendir. LocalExecutor, CeleryExecutor, KubernetesExecutor gibi çeşitleri vardır.

Worker

Gerçek task yürütmesini yapan işlemler veya pod'lar.

Web UI

DAG'ları görselleştirme, iş geçmişine bakma ve manuel tetikleme için sunduğu arayüz.

Metastore

Airflow meta verilerini (DAG durumları, task instance durumları, bağlantılar) saklayan veritabanıdır (genellikle PostgreSQL veya MySQL).

2.2 Mimari Bileşenler

Airflow mimarisi, birkaç temel bileşeni içerir: Scheduler, Executor (ve dolayısıyla Worker), Webserver, Metastore, Message Broker (seçilen executor tipine göre), ve Artifact/Log storage. Hangi executor kullanıldığı mimarinin dağıtım şeklini belirler.

3. NASIL ÇALIŞIR?

Sistem Mimarisi (Yüksek seviyede)

Kullanıcı DAG dosyasını yazar; DAG, Airflow DAG folder'ına konulur veya GitOps ile deploy edilir. Scheduler, DAG'ları parse edip planlama kararları üretir; bu kararlar metastore'a kaydedilir. Executor, task'ları çalıştırmak üzere worker'lara dağıtır. Worker'lar task'ı çalıştırır, logları merkezi bir depoya yazıp sonuçları metastore'a bildirir. Webserver kullanıcıya DAG durumunu ve geçmişini sunar.

Executor türleri ve etkileri

• SequentialExecutor: Tek proses, seri çalışma; geliştirme için uygundur, üretimde ölçeklenmez.
• LocalExecutor: Aynı host üzerinde çoklu process ile paralel çalıştırma; küçük ölçekli üretim için kullanılabilir.
• CeleryExecutor: Mesaj kuyruğu (RabbitMQ/Redis) ile dağıtık worker'lara task gönderir; ölçeklenebilir ve yaygın kullanılır.
• KubernetesExecutor: Her task için dinamik pod oluşturur; kubernetes native, izolasyon sağlar ve cloud‑native kullanım için önerilir.

Veri Akışı ve Task Çalışma Mantığı

Scheduler, belirlenen zamanlarda veya harici tetiklerle DAG'ı çalıştırır. Task'lar ready durumuna geldikçe executor tarafından worker'lara atanır. Task çalıştırma context'inde bağlantılar (connections), değişkenler (variables) ve XCom (tasklar arası küçük veri transferi) kullanılır. Task başarısız olursa retry stratejileri, backoff politikaları ve failure callback'ler devreye girebilir.

Operator ve Sensor kullanımı

Sensor'lar belirli bir koşul sağlanana kadar DAG yürütmesini bekletebilir (ör. dosya var mı, SQL sonucu beklenen duruma geldi mi). Ancak sensor'ların yanlış kullanımı kaynak tüketimini artırabilir; poke interval ve timeout ayarlarına dikkat edilmelidir.

Dag Parsing ve Performance

Scheduler sürekli olarak DAG dosyalarını parse eder; DAG dosyaları içinde ağır işlemler (ağ çağrısı, büyük obje oluşturma) yapılmamalıdır. Parse maliyeti yüksek DAG'lar scheduler performansını düşürür. DAG'larda yalnızca deklaratif yapı ve operator örneklemeleri bulunmalı, ağır kodlar task runtime içinde çalıştırılmalıdır.

4. GERÇEK DÜNYA KULLANIMLARI

Netflix

Netflix gibi büyük ölçekli organizasyonlarda workflow orkestrasyonu hem batch hem de near‑real‑time iş akışları içerir. Airflow, ETL job'ları ve veri pipeline'larının schedule edilmesinde kullanılır; operasyonda retry, backfill ve owner routing ile ölçeklenebilirlik sağlanır.

Uber

Uber büyük veri iş yüklerinde güçlü scheduling ve bağımlılık yönetimine ihtiyaç duyar. Orkestrasyon katmanı, çeşitli sistemlerle (Spark, Hive, Flink) entegrasyon sağlamak için kullanılır; otomasyon ve monitoring ile işlerin sürekliliği korunur.

Amazon

Amazon ve AWS müşterileri, hem managed Airflow hizmetlerini hem de kendi kurumsal Airflow dağıtımlarını kullanır. Entegrasyonlar ve güvenlik politikaları (IAM, VPC) kritik önemdedir.

OpenAI (ML pipeline orkestrasyonu)

ML farkındalığı yüksek organizasyonlarda Airflow, model eğitim pipeline'larını düzenlemek, veri hazırlama ve değerlendirme adımlarını koordine etmek için kullanılır. Ancak model serving ve düşük gecikme gereksinimi olan inferans işlemleri için genellikle farklı çözümler tercih edilir.

Stripe

Finansal sistemlerde workflow'ların deterministik olması ve hata durumlarında audit izlerinin bulunması gerekir. Airflow'un DAG tabanlı declarative yapısı bu ihtiyaçlara cevap verebilir; ancak idempotency ve reconciliation süreçleri ayrıca ele alınmalıdır.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

• Python tabanlı DAG tanımları ile esneklik ve geniş operator ekosistemi.
• Görselleştirme, lineage ve task geçmişi ile iyi operasyonal şeffaflık.
• Birçok executor seçeneği sayesinde farklı ölçek ve izolasyon gereksinimlerine uyum.
• Topluluk ve eklenti zenginliği (Providers, Hooks, Operators).

Sınırlandırmalar

• DAG parsing performansı ve scheduler ölçeklenebilirliği büyük kurulumlarda zorluk çıkarabilir.
• Sensors ve long‑running task'ların yanlış kullanımı kaynak tüketimini arttırır.
• Gerçek‑zamanlı low‑latency iş yükleri için uygun değildir; daha çok batch/near‑real‑time odaklıdır.
• Config ve secret yönetimi, multi‑tenant ortamlarda dikkatli planlama gerektirir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Aşağıdaki tablo, Airflow ile çeşitli orkestrasyon yaklaşımlarını karşılaştırır.

7. EN İYİ PRATİKLER

Production kullanımı

• DAG'ları küçük, tek sorumluluk prensibiyle yazın; tek bir DAG çok fazla sorumluluk üstlenmemeli.
• DAG dosyalarında network çağrıları veya ağır hesaplamalar yapmayın; bunlar task runtime içinde olmalı.
• Scheduler ve metastore için HA (high availability) konfigürasyonu uygulayın; metastore yedeğini ve bakım prosedürlerini planlayın.
• Secrets yönetimi için Vault veya benzeri güvenli çözümler kullanın; connection'ları UI üzerinden düz metin saklamayın.

Performans optimizasyonu

• DAG parsing maliyetini azaltmak için DAGs folder'ını segmentlere ayırın ve parse edilen dosya sayısını sınırlandırın.
• KubernetesExecutor veya CeleryExecutor kullanarak worker'ları yatay ölçekleyin.
• Sensor yerine deferrable operators veya triggerer kullanın (Airflow 2.x ile gelen özellikler) — kaynak verimliliği artar.

Güvenlik

• Role‑based access control (RBAC) ile Web UI erişimini yönetin.
• Network segmentation ve VPC peering ile metastore ve worker erişimlerini sınırlandırın.

Ölçeklenebilirlik

• Executor seçimini iş yüküne göre yapın: dinamik görev sayısı için KubernetesExecutor, geniş worker havuzu için CeleryExecutor.
• Log ve artifacts için merkezi storage (S3/MinIO) kullanın; worker node'ların disk bağımlılığını azaltın.

8. SIK YAPILAN HATALAR

• DAG'ları tek bir büyük dosyada toplamak — bu scheduler performansını bozar.
• Sensors'ları sık aralıklarla poke edecek şekilde ayarlamak — kaynak israfı.
• Secrets ve credentials'ı kod içinde bırakmak.
• Idempotency düşünmeden replay/backfill yapmak — duplicate etkiler.
• Monitoring eksikliği: scheduler, executor ve worker metriklerini takip etmemek.

9. GELECEK TRENDLER

AI ve Otomasyonun Rolü

AI destekli otomasyon, DAG optimizasyonu, failure pattern detection ve önerilen remediation ile workflow yönetimini kolaylaştıracak. Otomatik root cause analysis ve anomaly detection, operatör yükünü azaltacak.

Cloud‑native orkestrasyon ve serverless entegrasyonları

Kubernetes tabanlı executor'ların ve managed Airflow servislerinin yaygınlaşmasıyla birlikte, orkestrasyon daha sıkı biçimde cloud‑native paradigmalara entegre olacak. Serverless task execution, cold start ve kaynak yönetimi problemlerini beraberinde getirse de operasyonel overhead azaltacak.

SLA / SLO Odaklı Orkestrasyon

İş odaklı SLO'ların DAG seviyesinde tanımlanması ve otomatik uyarı/rollback mekanizmalarının orkestrasyon mantığına dahil edilmesi, veri ürünlerinin güvenilirliğini artıracak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. Airflow mu, Prefect mi tercih etmeliyim?

   İhtiyaca göre: Airflow geniş operatör ekosistemi ve olgun yapısı ile tercih edilir; Prefect daha modern state management ve developer deneyimi sunar. Karar iş yükü, ekip yetkinliği ve operasyon modeline bağlıdır.

2. Airflow ile gerçek zamanlı veri işlemeyi yapabilir miyim?

   Airflow daha çok batch/near‑real‑time işler için uygundur. Low latency gerektiren gerçek zamanlı işlerde stream processing platformları tercih edilmelidir.

3. DAG'larda en iyi hata yönetim yaklaşımı nedir?

   Retry politikaları, failure callback'ler ve idempotent task tasarımı; ayrıca DLQ ve manuel müdahale runbook'ları kombinasyonu en iyi sonuç verir.

4. Scheduler performansını nasıl iyileştiririm?

   DAG parsing maliyetini azaltın, metadata DB'yi optimize edin, gerekirse scheduler'ı HA modunda çalıştırın ve DAG file sayısını düşürün.

5. Secrets yönetimi için öneriler?

   Vault, AWS Secrets Manager veya GCP Secret Manager gibi çözümlerle entegrasyon; connections ve variables içinde hassas veri saklamayın.

6. KubernetesExecutor mu CeleryExecutor mu?

   KubernetesExecutor, isolation ve dinamik pod yaratma avantajı sunar; CeleryExecutor ise olgun ve geniş destekli bir seçenektir. Kubernetes ortamınız varsa genelde KubernetesExecutor tercih edilir.

7. Airflow loglarını nasıl merkezi hale getiririm?

   Log shipping ile S3/MinIO gibi merkezi object storage kullanın; Web UI'da remote log viewer entegrasyonunu aktif edin.

8. Backfill güvenliği nasıl sağlanır?

   Backfill planı, idempotency, throttling ve canary replay ile kontrol altında tutulmalıdır; runbook ile rollback adımları belirlenmelidir.

Anahtar Kavramlar

DAG

Yönlendirilmiş döngüsüz grafik; workflow tanımının temelidir.

Operator

Task tipini belirleyen sınıf.

Executor

Task yürütme stratejisini belirleyen bileşen.

Scheduler

DAG'ların planlanmasından sorumlu süreç.

XCom

Task'lar arası küçük veri transfer mekanizması.

Öğrenme Yol Haritası

1. 0–1 ay: Airflow temel kavramları, DAG yazımı, Operators ve temel scheduler davranışı.
2. 1–3 ay: Executor türleri, metastore, logging, basic HA ve secrets yönetimi.
3. 3–6 ay: Production deployment (Kubernetes/Celery), monitoring, observability ve runbook yazımı.
4. 6–12 ay: Advanced optimisation: DAG refactor, sensor/triggerer, auto‑scaling, security hardening ve disaster recovery planları.