Apache Airflow 2’den 3’e Geçiş Rehberi | Son güncelleme: Aralık 2025

Merhaba değerli veri mühendisleri (data engineers)!

Bugün sizlerle veri dünyasındaki en heyecan verici gelişmelerden birini konuşacağız: Apache Airflow 3. Nisan 2025’te yayınlanan bu sürüm (release), Airflow tarihindeki en büyük güncelleme olarak kayıtlara geçti [1]. 2020’den bu yana ilk büyük sürüm (major release) olan Airflow 3, yalnızca birkaç yeni özellik (feature) eklemekle kalmıyor; aynı zamanda mimariyi (architecture) kökten değiştiriyor, güvenliği (security) artırıyor ve modern veri iş akışlarının (data workflows) ihtiyaçlarına yanıt veriyor.

Bu yazıda, Airflow 2 kullanan ve geçiş (migration) yapmayı planlayan deneyimli kullanıcılar olarak 10 kritik değişikliği detaylıca inceleyeceğiz. Eğer Airflow başta olmak üzere en güncel data engineering konularını uygulamalı olarak öğrenmek isterseniz VBO Data Engineering Bootcamp‘e göz atmanızı tavsiye ederim.

İçindekiler (Table of Contents)

Giriş

• Neden Airflow 3?

10 Kritik Değişiklik

1. Hizmet Odaklı Mimari (Service-Oriented Architecture)
2. Görev SDK’sı ve Görev Yürütme Arayüzü (Task SDK & Task Execution Interface)
3. DAG Sürümleme (DAG Versioning)
4. Varlıklar ve Olay Güdümlü Zamanlama (Assets & Event-Driven Scheduling)
5. ML/AI İş Akışları İçin Yeni Yetenekler (ML/AI Workflow Capabilities)
6. Yeni React Tabanlı Kullanıcı Arayüzü (React-Based UI)
7. Zamanlayıcı Yönetimli Geriye Dönük Doldurma (Scheduler-Managed Backfill)
8. Uç Nokta Yürütücüsü (Edge Executor)
9. Kaldırılan Özellikler ve Kırılma Değişiklikleri (Breaking Changes)
10. İçe Aktarma Yolu Değişiklikleri (Import Path Changes)

Geçiş ve Kaynaklar

• Geçiş Stratejisi ve Araçları (Migration Strategy)
• Sık Sorulan Sorular (FAQ)
• Karşılaştırma Tablosu (Comparison Table)
• Sonuç ve Öneriler (Conclusion)

Neden Airflow 3?

Airflow 2.0, 2020 yılında yayınlandığından bu yana, her çeyrekte (quarterly) artımlı güncellemeler (incremental updates) aldı. 2024’ün son çeyreğinde 2.10 sürümüne ulaşan Airflow, artık aylık 30 milyonun üzerinde indirme (downloads) sayısına ve 80.000’den fazla kuruluş (organizations) tarafından kullanıma sahip [1]. Bu büyüme, ETL/ELT işlerinin ötesine geçerek MLOps (%30) ve GenAI iş akışlarına (workflows) (%10) kadar uzanıyor.

Peki Airflow 3 neden bu kadar önemli? İşte ana nedenler:

• Güvenlik endişeleri (Security concerns): Airflow 2’de görevler (tasks) doğrudan meta veri tabanına (metadata database) erişebiliyordu. Bu, kötü niyetli kodların (malicious code) sistem üzerinde zararlı işlemler yapmasına olanak tanıyordu [2].
• Ölçeklenebilirlik sorunları (Scalability issues): Veritabanına (database) olan aşırı bağlantı sayısı (connection count), büyük dağıtımlarda (large deployments) ölçekleme zorluklarına yol açıyordu [2].
• Modern ihtiyaçlar (Modern requirements): ML/AI iş akışları (workflows), olay güdümlü (event-driven) zamanlama (scheduling) ve çoklu dil desteği (multi-language support) gibi modern gereksinimler karşılanmalıydı.

10 KRİTİK DEĞİŞİKLİK

1. Hizmet Odaklı Mimari (Service-Oriented Architecture)

Airflow 3’ün en temel değişikliği hizmet odaklı mimari (Service-Oriented Architecture / SOA) geçişidir [3]. Bu, Airflow’un nasıl çalıştığını kökten değiştiriyor.

Airflow 2.x Mimarisi

Airflow 2’de tüm bileşenler (components) doğrudan meta veri tabanıyla (metadata database) iletişim kuruyordu:

• Zamanlayıcı (Scheduler), İşçiler (Workers), Web Sunucusu (Webserver) – hepsi aynı veritabanına bağlanıyordu
• Görev kodu (task code) ve görev yürütme kodu (task execution code) aynı süreçte (process) çalışıyordu
• İşçiler (Workers) doğrudan Airflow veritabanıyla iletişim kuruyordu
• Kullanıcı kodu (user code), oturumları (sessions) içe aktarabilir (import) ve meta veri tabanı üzerinde işlemler yapabilirdi [2]

Bu mimari, güvenlik açıkları (security vulnerabilities) ve ölçekleme sorunları (scaling issues) yaratıyordu.

Airflow 3.x Mimarisi

Airflow 3’te işler çok farklı:

• API Sunucusu (API Server) artık görevler (tasks) ve işçiler (workers) için meta veri tabanına tek erişim noktası (single access point) [2]
• İşçiler (Workers) artık doğrudan veritabanıyla değil, API Sunucusuyla (API Server) iletişim kuruyor
• DAG İşlemcisi (DAG Processor) ve Tetikleyici (Triggerer), değişkenler (variables) veya bağlantılar (connections) gerektirdiğinde görev yürütme mekanizmasını (task execution mechanism) kullanıyor [2]

Bu mimari değişikliğin pratik sonuçları:

Airflow 2.x:
Worker → Direct → Metadata Database

Airflow 3.x:
Worker → API Server → Metadata Database

Veritabanı Erişim Kısıtlamaları (Database Access Restrictions)

Bu belki de en kritik değişiklik: Görev kodundan (task code) doğrudan meta veri tabanı erişimi artık yasak [2].

Airflow 3’te:

• Görev kodu (task code) artık Airflow veritabanı oturumlarını (database sessions) veya modellerini (models) doğrudan içe aktaramaz (import) ve kullanamaz
• Tüm çalışma zamanı etkileşimleri (runtime interactions) – durum geçişleri (state transitions), kalp atışları (heartbeats), XCom’lar, kaynak getirme (resource fetching) – özel bir Görev Yürütme API’si (Task Execution API) üzerinden gerçekleştirilir [2]
• Görev SDK’sı (Task SDK), veritabanı bağımlılıkları (database dependencies) olmadan Airflow kaynaklarına erişim için kararlı, ileriye uyumlu (forward-compatible) bir arayüz (interface) sağlar

Bu değişiklik, özel operatörleriniz (custom operators) varsa ciddi şekilde etkileyebilir. Doğrudan veritabanı erişimi yapan kodlarınızı gözden geçirmeniz gerekecek [2].

Pratik Örnek: Eski vs Yeni Yaklaşım

Diyelim ki eski kodunuzda şöyle bir şey vardı:

# ❌ ESKİ YAKLAŞIM (Airflow 2.x) - Airflow 3'te ÇALIŞMAZ!
from airflow.models import DagRun
from airflow import settings

def get_dag_run_count(**context):
    session = settings.Session()
    count = session.query(DagRun).filter(
        DagRun.dag_id == "my_dag"
    ).count()
    session.close()
    return count

Airflow 3’te bu kodu şöyle yazmalısınız:

# ✅ YENİ YAKLAŞIM (Airflow 3.x)
from airflow.sdk import dag, task, get_current_context

@task
def check_state():
    context = get_current_context()
    ti = context["ti"]
    
    # Görev Bağlamı metodlarını kullan
    dr_count = ti.get_dr_count(dag_id="my_dag")
    return f"DAG çalıştırma sayısı: {dr_count}"

Bu yeni yaklaşım, veritabanına doğrudan erişim yerine Görev Bağlamı (Task Context) metodlarını kullanıyor [7].

2. Görev SDK’sı (Task SDK) ve Görev Yürütme Arayüzü (Task Execution Interface)

AIP-72 ile tanıtılan Görev Yürütme Arayüzü (Task Execution Interface) ve Görev SDK’sı (Task SDK), Airflow 3’ün temel taşlarından birini oluşturuyor [4][5].

Görev SDK’sı (Task SDK) Nedir?

Görev SDK’sı (Task SDK), görevlerin (tasks) çağırabileceği kod için büyük ölçüde azaltılmış ve yalın bir arayüz/API sağlar [5]. Bu SDK:

• Bağlantılara (Connections), Değişkenlere (Variables) ve XCom değerlerine erişim
• Kalp atışı raporlama (Heartbeat reporting)
• Günlük kaydetme (Log recording)
• Metrik raporlama (Metric reporting)

gibi işlevleri içerir.

Çoklu Dil Desteği (Multi-Language Support)

Airflow 3’ün temel hedeflerinden biri, herhangi bir ortamda (any environment), herhangi bir dilde (any language) yürütme (execution) sağlamaktır [1]. Görev Yürütme Arayüzü (Task Execution Interface) sayesinde:

• Python TaskSDK hemen kullanıma hazır
• Golang için TaskSDK yakında gelecek [1]
• Diğer diller için de SDK’lar planlanıyor

Bu, Python dışında dillerde görev (task) yazabilmenizi sağlayacak – BashOperator‘dan daha güzel bir kullanıcı deneyimi (user experience) sunacak [6].

Yeni İçe Aktarma Yolları (New Import Paths)

Artık DAG yazarları (DAG authors) airflow.sdk ad alanını (namespace) kullanmalı [3]:

# Eski yol (Airflow 2.x) - Kullanımdan kaldırılıyor
from airflow.decorators import dag, task
from airflow.models.dag import DAG
from airflow.models.baseoperator import BaseOperator

# Yeni yol (Airflow 3.x) - Önerilen
from airflow.sdk import dag, task, DAG, BaseOperator

Bu değişiklik, DAG yazımını Airflow iç yapılarından ayırarak, Airflow sürümleri arasında kararlı bir arayüz sağlıyor [7].

3. DAG Sürümleme (DAG Versioning)

DAG Sürümleme (DAG Versioning), Airflow kullanıcılarının yıllık anketlerine göre en çok talep edilen özellikti (most requested feature) [1][8]. Airflow 3 ile bu nihayet gerçek oldu!

Sorun Neydi?

Airflow 2’de, bir DAG çalışırken DAG kodunu güncellerseniz:

• Çalışmakta olan DAG, yeni kodu kullanmaya başlardı
• Bir görev (task) yeniden denendiğinde (retried) bile en son kod kullanılırdı
• UI’da eski DAG çalıştırmalarının (DAG runs) yapısını görmek zordu [9]

Airflow 3’te DAG Sürümleme (DAG Versioning)

Şimdi Airflow 3 ile:

• Sürüm takibi (Version tracking): DAG yapısı değişiklikleri (structure changes) – yeniden adlandırılan görevler (renamed tasks), bağımlılık değişiklikleri (dependency changes) – artık doğrudan meta veri tabanında izleniyor [3]
• Tutarlı yürütme (Consistent execution): Bir DAG çalıştırması (DAG run) başladığında, o sürümle tamamlanır – çalışma sırasında yeni sürüm yüklense bile [1]
• Geçmiş görüntüleme (History viewing): UI ve API üzerinden geçmiş DAG yapılarını inceleyebilirsiniz [3]
• İlişkilendirme (Association): Tüm DAG çalıştırmaları (DAG runs), görev yapısı (task structure), kod, günlükler (logs) dahil olmak üzere çalıştırıldığı DAG sürümüyle ilişkilendirilir [1]

Bu özellik iki AIP ile tanımlandı:

• AIP-65: UI’da DAG geçmişini iyileştirme (Improve DAG history in UI) [8]
• AIP-66: DAG Paketleri ve Ayrıştırma (DAG Bundles & Parsing) [8]

DAG Sürümleme (DAG Versioning) Nasıl Çalışır?

DAG sürümü hesaplamak için Airflow, serileştirilmiş DAG JSON’ını (serialized DAG JSON) hashliyor [9]. Bu yaklaşım:

• Zamanlayıcı (scheduler) ve web sunucusu (webserver) tarafından kullanılan şeyleri zaten kapsıyor
• Hesaplaması kolay
• PythonOperator içindeki python_callable değişikliklerini de tespit edebilir

Kullanıcılar ayrıca DAG’ları için kendi sürüm dizelerini (version strings) sağlayabilir. Bu, kullanıcı için anlamlı olabilir ve Airflow’un hesapladığı sürümle birlikte UI’da gösterilebilir.

Senaryolar ve UI Davranışı

Senaryo 1: DAG değişmeden çalışıyor

• Her şey normal, tek bir DAG sürümü gösterilir

Senaryo 2: DAG, DAG çalıştırmaları (DAG runs) arasında değişiyor

• 2 görevden (tasks) 3 göreve geçtiniz diyelim
• Eski DAG çalıştırmalarında “welcome” görevi (task) yoktu – Airflow 2’de bu kafa karıştırıcıydı
• Airflow 3’te her DAG çalıştırması (DAG run), o sırada hangi yapıya sahip olduğunu gösterir [9]

Senaryo 3: DAG, bir DAG çalıştırması (DAG run) SÜRESİNCE değişiyor

• En karmaşık senaryo!
• AIP-66 ile Airflow, belirli DAG kodu sürümlerini yürütebilir (execute specific DAG code versions) [10]

DAG Paketleri (DAG Bundles)

DAG Paketleri (DAG Bundles) konsepti, DAG’ları ve ilgili dosyaları bir arada sürümleyebilmenizi sağlar [10]. Paketler şu kaynaklardan alınabilir:

• Git depoları (Git repositories): GitHub, GitLab, Bitbucket veya self-hosted Git sunucuları
• Bulut depolama (Cloud storage): AWS S3
• Yerel dosya sistemi (Local filesystem): NFS, yerel klasörler
• Özel kaynaklar (Custom sources): Kendi DAG bundle sınıfınızı yazabilirsiniz

Git’ten DAG Yükleme (Loading DAGs from Git)

GitDagBundle, herhangi bir Git deposundan (GitHub, GitLab, Bitbucket vb.) DAG’larınızı çekmenizi sağlar. Bu yöntem sürümlemeyi (versioning) tam destekler – commit hash veya tag kullanarak belirli sürümleri çalıştırabilirsiniz.

Adım 1: Git Provider’ı kurun

pip install apache-airflow-providers-git

Adım 2: Airflow’da Git bağlantısı (connection) oluşturun

UI’dan veya CLI ile bir connection oluşturun:

# SSH key ile bağlantı
airflow connections add my_git_conn \
    --conn-type git \
    --conn-host github.com/kullanici/repo.git \
    --conn-extra '{"key_file": "/path/to/ssh_key"}'

# Token ile bağlantı (GitHub Personal Access Token)
airflow connections add my_git_conn \
    --conn-type git \
    --conn-host github.com/kullanici/repo.git \
    --conn-password ghp_xxxxxxxxxxxx

Adım 3: airflow.cfg’yi yapılandırın

[dag_processor]
dag_bundle_config_list = [
    {
        "name": "my_git_repo",
        "classpath": "airflow.providers.git.bundles.git.GitDagBundle",
        "kwargs": {
            "tracking_ref": "main",
            "git_conn_id": "my_git_conn",
            "subdir": "dags"
        }
    }
]

Parametreler:

• tracking_ref: İzlenecek branch (main, develop) veya tag
• git_conn_id: Airflow connection ID’si
• subdir: Repo içindeki DAG klasörü (opsiyonel)
• repo_url: Doğrudan URL (connection yerine kullanılabilir)

S3’ten DAG Yükleme (Loading DAGs from S3)

S3DagBundle, AWS S3 bucket’tan DAG’larınızı çekmenizi sağlar. Dikkat: S3 bundle’ı şu an sürümlemeyi (versioning) desteklemiyor – görevler her zaman en son kodu kullanır.

Adım 1: Amazon Provider’ı kurun

pip install apache-airflow-providers-amazon

Adım 2: AWS bağlantısı (connection) oluşturun

airflow connections add aws_default \
    --conn-type aws \
    --conn-extra '{"region_name": "eu-west-1"}'

Adım 3: airflow.cfg’yi yapılandırın

[dag_processor]
dag_bundle_config_list = [
    {
        "name": "dags-s3",
        "classpath": "airflow.providers.amazon.aws.bundles.s3.S3DagBundle",
        "kwargs": {
            "bucket_name": "my-airflow-dags-bucket",
            "prefix": "dags/",
            "aws_conn_id": "aws_default"
        }
    }
]

Parametreler:

• bucket_name: S3 bucket adı
• prefix: Bucket içindeki klasör yolu (opsiyonel)
• aws_conn_id: Airflow AWS connection ID’si

Birden Fazla Bundle Kullanma (Using Multiple Bundles)

Farklı kaynaklardan DAG’ları birlikte kullanabilirsiniz:

[dag_processor]
dag_bundle_config_list = [
    {
        "name": "production-dags",
        "classpath": "airflow.providers.git.bundles.git.GitDagBundle",
        "kwargs": {"tracking_ref": "main", "git_conn_id": "prod_git"}
    },
    {
        "name": "dev-dags",
        "classpath": "airflow.providers.git.bundles.git.GitDagBundle",
        "kwargs": {"tracking_ref": "develop", "git_conn_id": "dev_git"}
    },
    {
        "name": "local-dags",
        "classpath": "airflow.dag_processing.bundles.local.LocalDagBundle",
        "kwargs": {"path": "/opt/airflow/dags"}
    }
]

Sürümleme Farkları (Versioning Differences)

Önemli: Tam DAG sürümleme (versioning) avantajlarından yararlanmak için GitDagBundle kullanmanızı öneririz.

4. Varlıklar (Assets) ve Olay Güdümlü Zamanlama (Event-Driven Scheduling)

Airflow 2.4’te tanıtılan Veri Kümeleri (Datasets) konsepti, Airflow 3’te Varlıklar (Assets) olarak yeniden adlandırıldı ve genişletildi [3][11].

Neden Bu Değişiklik?

“Asset” terimi daha genellenebilir ve şu türleri temsil edebilir [11]:

• Veri kümeleri (Datasets) – tablolar, dosyalar
• Serileştirilmiş ML modelleri (Serialized ML models)
• Gömülü panolar (Embedded dashboards)
• Raporlar (Reports)

ML uygulayıcıları (ML practitioners) hem veri kümelerini (datasets) hem de modelleri (models) kullanır. “Dataset” yerine “Asset” kullanmak, bu çeşitliliği daha iyi yansıtıyor.

Yeni @asset Dekoratörü (Decorator)

AIP-75 ile tanıtılan yeni varlık merkezli söz dizimi (Asset-Centric Syntax), varlıkları (assets) tanımlamayı çok daha kolay hale getiriyor [12]:

from airflow.sdk import asset

# Varlık tanımlama (Asset definition)
@asset(uri="s3://aws_conn_id@bucket/raw_bus_trips.parquet")
def raw_bus_trips():
    # Varlığa veri yaz... (Write data to asset...)
    pass

Varlık İzleyicileri (Asset Watchers) ve Olay Güdümlü Zamanlama (Event-Driven Scheduling)

Varlık İzleyicileri (Asset Watchers), Airflow’un dış sistemleri (external systems) sürekli izlemesini ve belirli olaylar (events) gerçekleştiğinde DAG’ları tetiklemesini (trigger) sağlar [13].

Airflow 3 ile:

• AWS SQS entegrasyonu kutudan çıkar çıkmaz kullanılabilir (out-of-the-box) [1]
• Bir mesaj kuyruğuna (message queue) mesaj geldiğinde DAG tetiklenebilir
• Yoklama tabanlı (poll-based) ve itme tabanlı (push-based) yaklaşımlar destekleniyor [14]

Bu, geleneksel sensör tabanlı (sensor-based) yoklama mekanizmalarının (polling mechanisms) yükü olmadan iş akışlarının (workflows) olaylara yanıt vermesini sağlar.

Varlık (Asset) Tanımlama Örneği

İşte Airflow 3’te varlıkların (assets) nasıl tanımlandığına dair kapsamlı bir örnek:

from airflow.sdk import Asset, dag, task

# Basit varlık tanımlama
my_dataset = Asset(
    name="processed_sales",
    uri="s3://bucket/processed_sales.parquet"
)

# @asset dekoratörü ile varlık tanımlama
@asset(uri="s3://aws_conn_id@bucket/aggregated_sales.parquet")
def aggregated_sales():
    # Satış verilerini işle ve varlığa yaz
    pass

# Varlığa bağımlı DAG
@dag(schedule=[my_dataset])
def downstream_dag():
    @task
    def process_sales():
        # my_dataset güncellendiğinde bu görev tetiklenir
        pass
    
    process_sales()

Varlık Grupları ve Alt Türler

Varlıklar group özniteliğiyle kategorize edilebilir [11]:

# Aynı türdeki varlıkları grupla
sales_q1 = Asset(name="sales_q1", uri="...", group="quarterly_sales")
sales_q2 = Asset(name="sales_q2", uri="...", group="quarterly_sales")

Gelecekte ML veri kümeleri için tablo şeklinde bilgi de eklenebilir:

# Gelecek sürümlerde planlanan
aggregated_sales = Dataset(
    "aggregated_sales", 
    columns=["sales", "region", "date"]
)

Asset Watchers ile AWS SQS Entegrasyonu

Airflow 3 ile AWS SQS entegrasyonu kutudan çıkar çıkmaz geliyor [13]:

from airflow.providers.amazon.aws.assets.sqs import SQSAssetWatcher

# SQS kuyruğunu izle ve mesaj geldiğinde DAG'ı tetikle
sqs_watcher = SQSAssetWatcher(
    queue_url="https://sqs.region.amazonaws.com/account/queue"
)

Bu, “mesaj kuyruğuna mesaj geldiğinde pipeline’ı başlat” senaryosunu çok basitleştiriyor.

İçe Aktarma Değişiklikleri

# Eski (Airflow 2.x)
from airflow.datasets import Dataset, DatasetAlias, DatasetAll, DatasetAny

# Yeni (Airflow 3.x)
from airflow.sdk import Asset, AssetAlias, AssetAll, AssetAny

5. ML/AI İş Akışları (ML/AI Workflows) İçin Yeni Yetenekler

Airflow 3, makine öğrenimi (machine learning) ve yapay zeka (artificial intelligence) iş akışları için özel olarak tasarlanmış önemli iyileştirmeler getiriyor.

execution_date Benzersizlik Kısıtlamasının Kaldırılması (Removal of execution_date Uniqueness Constraint)

Airflow’un mimarisi başlangıçta “execution_date” (yürütme tarihi) konseptine bağlıydı. Bu tarih, bir DAG çalıştırmasının (DAG run) veri işlediği mantıksal noktayı (logical point) temsil ediyordu ve DAG çalıştırmaları için birincil tanımlayıcı (primary identifier) olarak kullanılıyordu [29].

Sorun: Bu yaklaşım, zaman bağımsız (time-independent) iş akışları için sorunluydu – özellikle ML/AI senaryolarında:

• Model eğitimi (Model training)
• Hiperparametre ayarlaması (Hyperparameter tuning)
• Çıkarım görevleri (Inference tasks)

Çözüm (AIP-83): Airflow 3, her DAG çalıştırmasının (DAG run) benzersiz bir veri aralığına (data interval) karşılık gelmesi zorunluluğunu kaldırıyor [3]:

# Artık logical_date=None ile birden fazla DAG çalıştırması (DAG run) mümkün
@dag(schedule=None)  # schedule artık varsayılan olarak None
def ml_training_dag():
    @task
    def train_model(params):
        # Her tetiklemede (trigger) farklı parametrelerle çalıştırılabilir
        pass

Bu sayede:

• Ad hoc çalışan iş akışları (ad-hoc workflows)
• Harici sistemler (external systems) tarafından tetiklenen iş akışları
• Aynı veri kümesi (dataset) üzerinde farklı parametrelerle birden çok kez yürütülmesi gereken iş akışları

artık yerel olarak (natively) destekleniyor – geçici çözümler (workarounds) gerektirmeden.

İnsan Döngüsünde (Human-in-the-Loop / HITL) Operatörleri

Airflow 3.1 ile Human-in-the-Loop (İnsan Döngüsünde / HITL) işlevselliği tanıtıldı [26]:

from airflow.providers.standard.operators.hitl import HITLOperator

# İş akışını (workflow) duraklatıp insan kararı (human decision) bekle
approval_task = HITLOperator(
    task_id="manager_approval",
    question="Bu model dağıtıma hazır mı?",
    options=["Evet", "Hayır", "Gözden geçir"]
)

HITL görevleri (tasks) şunlar için özellikle değerli:

• AI/ML iş akışları (workflows)
• İçerik moderasyonu (content moderation)
• Onay süreçleri (approval processes)

Görevler (tasks), insan girdisi (human input) beklerken ertelenmiş durumda (deferred state) kalır ve kullanıcılar Airflow UI üzerinden bekleyen görevleri (pending tasks) görebilir, bağlamı (context) inceleyebilir ve eylemleri tamamlayabilir.

Son Tarih Uyarıları (Deadline Alerts)

Airflow 3.1’de tanıtılan Son Tarih Uyarıları (Deadline Alerts), DAG çalıştırmaları (DAG runs) zaman eşiklerini (time thresholds) aştığında proaktif izleme sağlar [16]:

@dag(
    deadline=timedelta(hours=2),
    on_deadline_callback=my_alert_function
)
def time_sensitive_dag():
    # 2 saatten uzun sürerse uyarı (alert) tetiklenir
    pass

Bu, SLA uyumluluğunu (SLA compliance) sağlamaya ve kritik iş akışlarının (critical workflows) zamanında tamamlanmasını garantilemeye yardımcı olur.

6. Yeni React Tabanlı Kullanıcı Arayüzü (React-Based User Interface)

Airflow 3, tamamen yeniden tasarlanmış bir kullanıcı arayüzü (UI) ile geliyor. Flask tabanlı eski arayüz, React ve FastAPI üzerine inşa edilmiş modern bir arayüzle değiştirildi [3][15].

AIP-38: Modern Web Uygulaması (Modern Web Application)

Bu değişikliğin arkasındaki nedenler [15]:

• Bakım kolaylığı (Maintainability): FAB’ın (Flask-AppBuilder) CRUD görünüm şablonlarını (view templates) kaldırmak, uçtan uca deneyim (end-to-end experience) üzerinde daha fazla kontrol sağlıyor
• Gerçek zamanlı UI (Real-time UI): Artık manuel yenileme yok – veriler dinamik olarak güncelleniyor (dynamic updates)
• Test edilebilirlik (Testability): JavaScript’te her şeyin olması, uygulama genelinde geliştirilmiş hata ayıklama (debugging) ve test imkanı sağlıyor
• Topluluk desteği (Community support): React, en yaygın kullanılan UI çerçevesi (framework) – katkıda bulunmak daha kolay

Öne Çıkan UI Özellikleri

• Sürüm farkındalıklı görünümler (Version-aware views): DAG çalıştırmaları (DAG runs) ilgili DAG sürümüyle ilişkilendiriliyor
• Geriye dönük doldurma yönetimi (Backfill management): Backfill’ler doğrudan UI’dan başlatılabilir ve izlenebilir [1]
• Varlık merkezli DAG tanımları (Asset-centric DAG definitions): Varlıklar (assets), DAG detay sayfasından görüntülenebilir
• Geliştirilmiş filtreleme ve arama (Improved filtering and search): Daha sezgisel navigasyon
• Favori DAG’lar (Favorite DAGs): DAG’ları üste sabitleyebilir (pin) veya kolayca filtreleyebilirsiniz [16]

Airflow 3.1’de Geri Dönen Görünümler (Returning Views)

Airflow 2.x’teki sevilen Takvim (Calendar) ve Gantt grafik görünümleri (graph views), Airflow 3.0’da yoktu ancak 3.1’de modern React UI için yeniden inşa edildi [16]:

• Yeni Takvim görünümü (Calendar view) interaktif ve filtreleme yeteneklerine sahip
• Gantt grafiği artık doğrudan grid görünümüne (grid view) entegre ve çok daha hızlı

Flask-AppBuilder’ın Kaldırılması (Removal of Flask-AppBuilder)

Flask-AppBuilder (FAB) artık çekirdek (core) Airflow paketinin bir parçası değil [1]. Bunun yerine:

• FAB, ayrı bir sağlayıcı paketine (provider package) taşındı
• Geriye dönük uyumluluk (backward compatibility) için FAB sağlayıcısı kurulabilir
• Yeni eklentiler (plugins) FastAPI uygulamaları, React uygulamaları ve FastAPI ara yazılımları (middleware) kullanmalı [17]

7. Zamanlayıcı Yönetimli Geriye Dönük Doldurma (Scheduler-Managed Backfill)

Geriye dönük doldurma (Backfill) işlemleri, Airflow 3’te köklü bir değişime uğradı [18][19].

Airflow 2’de Backfill Sorunları

• Backfill yalnızca CLI üzerinden çağrılabiliyordu
• Kullanıcıların her zaman CLI erişimi yoktu
• CLI süreci (process) öldüğünde, backfill işi de ölüyordu
• Backfill aslında “ikinci bir zamanlayıcı (scheduler)” gibi çalışıyordu [18]
• Web UI’da backfill işlerinin görünürlüğü (visibility) yoktu

Airflow 3’te Backfill

Artık backfill’ler zamanlayıcı (scheduler) tarafından yönetiliyor (AIP-78):

• CLI backfill komutu artık görevleri (tasks) çalıştırmıyor; bir backfill işi (job) oluşturuyor ve zamanlayıcı (scheduler) bu işi yönetiyor [18]
• Backfill işleri API üzerinden asenkron olarak (asynchronously) tetiklenebiliyor
• Web sunucusunda (webserver) backfill işlerini görüntüleyebilir, ilerlemeyi (progress) ve durumu (status) izleyebilir, iptal edebilir (cancel) veya duraklatabilirsiniz (pause) [19]
• Backfill DAG çalıştırmaları (DAG runs), normal DAG yürütmesiyle aynı zamanlama (scheduling), sürümleme (versioning) ve gözlemlenebilirlik (observability) modellerini takip ediyor [3]

# Artık backfill CLI'dan başlatıldığında, zamanlayıcı (scheduler) işi devralır
airflow dags backfill -s 2024-01-01 -e 2024-01-31 my_dag

Önemli Davranış Değişiklikleri (Important Behavior Changes)

• Yerel mod kaldırıldı (Local mode removed): Eskiden backfill’i yerel modda (local mode) çalıştırıp tüm görevleri yerelde yürütebilirdiniz. Bu artık yok [18].
• Havuzlara saygı (Pool compliance): Backfill artık görevlerinizde (tasks) ayarlanan havuzlara (pools) saygı duyuyor; havuz geçersiz kılma (pool override) mevcut değil [18].
• Kendi max_active_runs ayarı: Backfill’ler, DAG’ın max_active_runs ayarından bağımsız kendi ayarlarına sahip [18].

8. Uç Nokta Yürütücüsü (Edge Executor)

Uç Nokta Yürütücüsü (Edge Executor), AIP-69 ile tanıtılan ve Airflow 3’te genel kullanıma (GA – Generally Available) sunulan yeni bir yürütücüdür (executor) [1][20].

Uç Nokta Yürütücüsü (Edge Executor) Nedir?

Uç Nokta Yürütücüsü (Edge Executor), görevlerin (tasks) merkezi veri merkezleri (data centers) ve bulutların (clouds) dışında, uç cihazlarda (edge devices) çalıştırılmasını sağlar [1]. Bu yürütücü:

• Görev Yürütme Arayüzü (Task Execution Interface) üzerine inşa edilmiştir
• Celery, Kubernetes ve Local Executor’ların yanı sıra yeni yetenekler sunar
• Dağıtık (distributed) veya uzak hesaplama ortamlarında (remote compute environments) görev yürütmeyi destekler [3]

Neden Uç Nokta Yürütücüsü (Edge Executor)?

Geleneksel dağıtık işçi (distributed worker) kurulumlarının zorlukları [20]:

• Uzak mesafelerde Celery işçilerini (workers) bağlamak karmaşık
• İşçilerin (workers) meta veri tabanına (metadata database) bağlanması gerekiyor – gecikme (latency) performansı etkiliyor
• Redis, Airflow Meta DB ve en azından iyi bir Git Sync bağlamak gerekiyor
• VPN veya bağlantı şifrelemesi (connection encryption) gerekiyor

Uç Nokta Yürütücüsü (Edge Executor) bu sorunları çözüyor:

• İşçiler (workers) yalnızca HTTPS üzerinden API sunucusuna (API server) bağlanıyor [21]
• Doğrudan veritabanı erişimi (direct database access) gerekmiyor
• Birkaç MB Python bağımlılığıyla (dependencies) uzak makine kuruluma eklenebilir
• Windows desteği bile mümkün [20]

Kurulum (Setup)

# airflow.cfg'de

[core]

executor = airflow.providers.edge.executors.EdgeExecutor # Edge Worker (Uç Nokta İşçisi) başlatma airflow edge worker -q remote,wisconsin_site

Uç Nokta İşçileri (Edge Workers) birden fazla kuyruğu (queues) dinleyebilir ve görevler (tasks) queue özniteliğiyle belirli işçilere (workers) yönlendirilebilir [21].

9. Kaldırılan Özellikler (Removed Features) ve Kırılma Değişiklikleri (Breaking Changes)

Airflow 3, bazı eski özellikleri tamamen kaldırıyor. Bu bölümde nelerin gittiğini ve alternatiflerini inceleyeceğiz [2][22].

SubDAG’lar → Görev Grupları (TaskGroups)

SubDAG’lar tamamen kaldırıldı. SubDagOperator, ilgili CLI ve API arayüzleri dahil [22].

# Eski (Airflow 2.x) - Artık çalışmıyor!
from airflow.operators.subdag import SubDagOperator

# Yeni (Airflow 3.x) - Görev Grubu (TaskGroup) kullanın
from airflow.sdk import TaskGroup

with TaskGroup("grubum") as tg:
    task1 = ...
    task2 = ...

Görev Grupları (TaskGroups), SubDAG’ların aksine:

• Ayrı bir DAG oluşturmaz
• Daha hafif (lightweight) ve performanslıdır
• UI’da görsel gruplama (visual grouping) sağlar

SLA’lar → Son Tarih Uyarıları (Deadline Alerts)

SLA özelliği kaldırıldı. SLA geri çağırmaları (callbacks) ve metrikleri (metrics) dahil [22].

Alternatif olarak Son Tarih Uyarıları (Deadline Alerts) planlanıyor ve Airflow 3.1’de kullanıma sunuldu [16]:

# Son Tarih Uyarıları (Deadline Alerts) DAG çalıştırmalarının (DAG runs)
# zaman eşiklerini (time thresholds) aştığında
# otomatik olarak bildirim (notification) tetikler

SequentialExecutor → LocalExecutor

SequentialExecutor kaldırıldı [2]. Yerel geliştirme (local development) için artık LocalExecutor kullanılmalı – SQLite ile de çalışır.

CeleryKubernetesExecutor ve LocalKubernetesExecutor

Bu karma yürütücüler (hybrid executors) kaldırıldı. Yerine Çoklu Yürütücü Yapılandırması (Multiple Executor Configuration) kullanılmalı [2].

REST API v1 → v2

Eski /api/v1 kaldırıldı. Modern FastAPI tabanlı kararlı (stable) /api/v2 kullanılmalı [2].

Kaldırılan Bağlam Değişkenleri (Removed Context Variables)

Aşağıdaki şablon değişkenleri (template variables) artık görev bağlamında (task context) mevcut değil [2]:

• tomorrow_ds, tomorrow_ds_nodash
• yesterday_ds, yesterday_ds_nodash
• prev_ds, prev_ds_nodash
• prev_execution_date, prev_execution_date_success
• next_execution_date, next_ds_nodash, next_ds
• execution_date

Bu değişkenleri kullanıyorsanız, DAG’larınız hata verecektir!

Varsayılan Değer Değişiklikleri (Default Value Changes)

XCom Pickling

Güvenlik nedeniyle (for security reasons), varsayılan XCom arka ucunu (backend) kullanırken XCom pickling artık izin verilmiyor [22].

Gelecek Mantıksal Tarih Desteği Kaldırıldı (Future Logical Date Support Removed)

Airflow artık gelecekte mantıksal tarihle (logical_date) DAG çalıştırmalarını (DAG runs) tetiklemeyi desteklemiyor [3].

10. İçe Aktarma Yolu Değişiklikleri (Import Path Changes)

Airflow 3, içe aktarma yollarında (import paths) önemli değişiklikler getiriyor. Eski yollar kullanımdan kaldırılıyor (deprecated) ve gelecek sürümlerde kaldırılacak [2].

Ana İçe Aktarma Değişiklikleri Tablosu (Main Import Changes Table)

Zaman Çizelgesi (Timeline)

• Airflow 3.1: Eski içe aktarmalar (old imports) kullanımdan kaldırma uyarıları (deprecation warnings) gösteriyor ancak çalışmaya devam ediyor
• Gelecek sürüm (Future release): Eski içe aktarmalar kaldırılacak [2]

Standard Provider Paketi (Standard Provider Package)

BashOperator ve PythonOperator gibi yaygın kullanılan operatörler (commonly used operators) artık çekirdek paketten (core package) ayrıldı [2]:

pip install apache-airflow-providers-standard

Bu paket Airflow 2.x sürümlerine de kurulabilir, böylece DAG’larınızı geçiş öncesinde güncelleyebilirsiniz.

Geçiş Stratejisi ve Araçları (Migration Strategy and Tools)

Airflow 3’e geçiş dikkatli planlama gerektirir. Neyse ki, Airflow ekibi bu süreci kolaylaştırmak için araçlar sağlıyor [2][23].

Ön Koşullar (Prerequisites)

1. En az Airflow 2.7 sürümünde olmalısınız. En son 2.x sürümüne yükseltmeniz önerilir [2].
2. Python sürümünüz desteklenen listede olmalı (Python 3.9-3.12) [3].
3. Kaldırılan özellikleri (removed features) veya işlevleri (functions) kullanmadığınızdan emin olun.

Adım 1: DAG Uyumluluğunu Kontrol Edin (Check DAG Compatibility)

Ruff aracı ve AIR kuralları (rules) kullanarak DAG’larınızı kontrol edin [2]:

# Kırılma değişikliklerini (breaking changes) kontrol et
ruff check dags/ --select AIR301

# Önerilen düzeltmeleri (suggested fixes) önizle
ruff check dags/ --select AIR301 --show-fixes

# Otomatik düzeltmeleri (auto-fixes) uygula
ruff check dags/ --select AIR301 --fix

# Güvensiz düzeltmeleri (unsafe fixes) de uygula (dikkatli kullanın!)
ruff check dags/ --select AIR301 --fix --unsafe-fixes

• AIR301 ve AIR302: Airflow 3’teki kırılma değişikliklerini (breaking changes) gösterir
• AIR311 ve AIR312: Şu an kırmayan (non-breaking) ancak güncellenmesi şiddetle önerilen değişiklikler

Adım 2: Yapılandırmayı Kontrol Edin (Check Configuration)

# Yapılandırma uyumluluğunu (configuration compatibility) kontrol et
airflow config update

# Otomatik düzeltmeleri (auto-fixes) uygula
airflow config update --fix

Adım 3: Veritabanını Yedekleyin ve Temizleyin (Backup and Clean Database)

# Veritabanını temizle (eski XCom verileri vb.)
airflow db clean

# Yedek (backup) almayı unutmayın!

Önemli: Airflow örneklerinizi (instances) kapatmadan yedek (backup) alırsanız, yedek tutarlı olmayabilir [2].

Adım 4: DAG İşleme Hatalarını Düzeltin (Fix DAG Processing Errors)

# Hatasız çalışmalı
airflow dags reserialize

AirflowDagDuplicatedIdException gibi hatalar varsa, yükseltmeden önce düzeltin.

Adım 5: Standard Provider’ı Kurun (Install Standard Provider)

pip install apache-airflow-providers-standard

Adım 6: Özel Operatörleri Gözden Geçirin (Review Custom Operators)

Doğrudan veritabanı erişimi (direct database access) yapan özel operatörleriniz (custom operators) varsa, bunları güncellemeniz gerekiyor. Örnekler için GitHub issue #49187’ye bakın [2].

Adım 7: Veritabanını Yükseltin (Upgrade Database)

airflow db migrate

Adım 8: Başlangıç Komutlarını Güncelleyin (Update Startup Commands)

Airflow 3’te Web Sunucusu (Webserver), genel bir API sunucusu (API server) haline geldi:

# Eski (Airflow 2.x)
airflow webserver

# Yeni (Airflow 3.x)
airflow api-server

DAG işlemcisi (DAG processor) artık bağımsız olarak başlatılmalı [2]:

airflow dag-processor

Adım 9: Helm Chart Kullanıcıları İçin (For Helm Chart Users)

webserver altındaki tüm yapılandırma seçeneklerini (configuration options) apiServer olarak değiştirmeniz gerekiyor [2].

Adım 10: SSO/OAuth Kontrolü (SSO/OAuth Check)

Özel (custom) webserver_config.py kullanıyorsanız:

# Eski
from airflow.www.security import AirflowSecurityManager

# Yeni
from airflow.providers.fab.auth_manager.security_manager.override import FabAirflowSecurityManagerOverride

Ayrıca OAuth yönlendirme URL’leri değişti – artık /auth ön ekini içermeleri gerekiyor [2]:

Airflow 2.x: https://<url>/oauth-authorized/google
Airflow 3.x: https://<url>/auth/oauth-authorized/google

CLI Değişiklikleri (CLI Changes)

Airflow 3, CLI’yi de yeniden düzenledi. AIP-81 ile CLI, airflow ve airflowctl olarak ikiye ayrıldı [3]:

airflow komutu: Yerel geliştirme (local development) ve geriye dönük uyumluluk (backward compatibility) için

airflow dags list
airflow tasks test my_dag my_task 2024-01-01

airflowctl komutu: API üzerinden uzak erişim (remote access) için

# Airflow 3 ile tanıtılan yeni araç
airflowctl dags trigger my_dag
airflowctl connections list

Bu değişiklik, CLI güvenliğini artırıyor – artık CLI komutları doğrudan veritabanı (database) yerine API’yi kullanıyor [1].

Bileşen Başlatma Değişiklikleri Özeti (Component Startup Changes Summary)

Sık Sorulan Sorular (Frequently Asked Questions / FAQ)

“DAG’larım hiç değişiklik yapmadan çalışacak mı?”

Büyük olasılıkla evet! Airflow ekibi geriye dönük uyumluluğa (backward compatibility) çok özen gösterdi. Ancak şu durumlarda değişiklik gerekecek:

• Doğrudan veritabanı erişimi (direct database access) yapıyorsanız
• SubDAG kullanıyorsanız
• Kaldırılan bağlam değişkenlerini (removed context variables) kullanıyorsanız
• SLA özelliğini kullanıyorsanız

“Ne zaman geçmeliyim?”

Hemen üretim ortamına (production environment) geçmenizi önermiyoruz. İdeal strateji:

1. Test ortamında (test environment) Airflow 3’ü deneyin
2. Ruff araçlarıyla DAG’larınızı kontrol edin
3. Sorunlu kodları Airflow 2’de düzeltin (standard provider zaten Airflow 2’de çalışır)
4. Kademeli olarak geçiş yapın (gradual migration)

“Hangi Python sürümlerini destekliyor?”

Airflow 3, Python 3.9 ile 3.12 arasını destekliyor [3]. Python 3.8 desteği kaldırıldı.

“CeleryExecutor hâlâ çalışıyor mu?”

Evet! CeleryExecutor, KubernetesExecutor ve LocalExecutor hâlâ destekleniyor [1]. Sadece CeleryKubernetesExecutor ve LocalKubernetesExecutor karma yürütücüleri (hybrid executors) kaldırıldı – yerine Çoklu Yürütücü Yapılandırması (Multiple Executor Configuration) kullanılmalı.

“FAB tabanlı eklentilerim (plugins) ne olacak?”

FAB provider paketini kurarak FAB tabanlı eklentilerinizi (plugins) kullanmaya devam edebilirsiniz. Ancak uzun vadede FastAPI tabanlı eklentilere geçmenizi öneririz [17].

“Veritabanı geçişi (database migration) ne kadar sürer?”

Bu, veritabanınızın boyutuna bağlı. Uzun süredir çalışan bir Airflow örneği (instance), artık gerekli olmayan önemli miktarda veri biriktirebilir. Geçiş öncesi airflow db clean komutunu çalıştırmanızı şiddetle öneriyoruz [2].

“Helm Chart kullanıyorum, ne yapmalıyım?”

Helm Chart’taki webserver altındaki yapılandırmaları (configurations) apiServer olarak değiştirmeniz gerekiyor. Ayrıca birçok parametrenin yeniden adlandırıldığını (renamed) veya kaldırıldığını (removed) unutmayın [2].

Karşılaştırma Tablosu (Comparison Table): Airflow 2 vs Airflow 3

Sonuç ve Öneriler (Conclusion and Recommendations)

Airflow 3, projenin tarihindeki en önemli sürüm (most significant release). 300’den fazla geliştirici (developer) tarafından aylarca süren çalışmaların ürünü [1]. İşte özetimiz:

Kazanımlar (Benefits)

• ✅ Gelişmiş güvenlik (Improved security): Görevlerden (tasks) doğrudan veritabanı erişimi kaldırıldı
• ✅ Daha iyi ölçeklenebilirlik (Better scalability): API tabanlı mimari, veritabanı bağlantı sorunlarını çözüyor
• ✅ DAG sürümleme (DAG versioning): En çok talep edilen özellik (most requested feature) nihayet burada
• ✅ Modern UI: React tabanlı, hızlı ve duyarlı (responsive)
• ✅ Olay güdümlü (Event-driven): Asset Watchers ile gerçek olay tabanlı tetikleme (event-based triggering)
• ✅ Çoklu dil (Multi-language): Gelecekte Python dışında dillerde görev (task) yazabilme
• ✅ Uç hesaplama (Edge computing): Uç noktalarda (edge) görev yürütme (task execution) desteği

Dikkat Edilmesi Gerekenler (Things to Watch Out For)

• ⚠️ İçe aktarma yollarını (import paths) güncellemeniz gerekiyor
• ⚠️ Doğrudan veritabanı erişimi (direct database access) yapan kodlar çalışmayacak
• ⚠️ SubDAG, SLA gibi eski özellikler (legacy features) kaldırıldı
• ⚠️ Varsayılan değerler (default values) değişti (catchup, schedule vb.)
• ⚠️ API v1 yerine v2 kullanılmalı

Önerilerimiz (Our Recommendations)

1. Hemen başlamayın – Önce test ortamında (test environment) deneyin
2. Ruff araçlarını kullanın – Otomatik kontrol (automatic checking) ve düzeltme (fixing)
3. Eski sürümde kalırken içe aktarmaları (imports) güncelleyin – Standard provider Airflow 2’de de çalışır
4. Veritabanı yedeği (database backup) alın – Mutlaka!
5. Kademeli geçiş yapın (Gradual migration) – Tüm DAG’ları birden geçirmeye çalışmayın

Airflow 3, veri mühendisliğinin (data engineering) geleceğini şekillendiriyor. ML/AI iş akışları (workflows), olay güdümlü mimariler (event-driven architectures) ve dağıtık sistemler (distributed systems) için mükemmel bir platform sunuyor. Geçiş biraz çaba gerektirse de, sunduğu avantajlar buna değer!

Bir sonraki yazıda görüşmek üzere! Hoşçakalın…

Kaynaklar

[1] Apache Software Foundation. “Apache Airflow® 3 is Generally Available!” Apache Airflow Blog, April 22, 2025. https://airflow.apache.org/blog/airflow-three-point-oh-is-here/

[2] Apache Software Foundation. “Upgrading to Airflow 3.” Apache Airflow Documentation. https://airflow.apache.org/docs/apache-airflow/stable/installation/upgrading_to_airflow3.html

[3] Apache Software Foundation. “Release Notes – Airflow 3.0.0.” Apache Airflow Documentation. https://airflow.apache.org/docs/apache-airflow/3.0.0/release_notes.html

[4] Apache Software Foundation. “AIP-72 Task Execution Interface aka Task SDK.” Apache Airflow Wiki. https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-72+Task+Execution+Interface+aka+Task+SDK

[5] Airflow Mailing List. “[VOTE] AIP-72: Task Execution Interface aka Task SDK.” https://www.mail-archive.com/dev@airflow.apache.org/msg13364.html

[6] Airflow Mailing List. “Re: [DISCUSS] AIP-72 Task Execution Interface (aka Task SDK).” https://www.mail-archive.com/dev@airflow.apache.org/msg13289.html

[7] Apache Software Foundation. “Public Interface for Airflow 3.0+.” Apache Airflow Documentation. https://airflow.apache.org/docs/apache-airflow/stable/public-airflow-interface.html

[8] Airflow Mailing List. “[DISCUSS] AIP-63, AIP-64, and AIP-65: DAG Versioning.” https://www.mail-archive.com/dev@airflow.apache.org/msg12419.html

[9] Apache Software Foundation. “AIP-65: Improve DAG history in UI.” Apache Airflow Wiki. https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-65:+Improve+DAG+history+in+UI

[10] Apache Software Foundation. “AIP-66: DAG Bundles & Parsing.” Apache Airflow Wiki. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=294816356

[11] Apache Software Foundation. “AIP-74 Introducing Data Assets.” Apache Airflow Wiki. https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-74+Introducing+Data+Assets

[12] Apache Software Foundation. “AIP-75 New Asset-Centric Syntax.” Apache Airflow Wiki. https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-75+New+Asset-Centric+Syntax

[13] Amazon Web Services. “Introducing Apache Airflow 3 on Amazon MWAA: New features and capabilities.” AWS Blog, October 8, 2025. https://aws.amazon.com/blogs/big-data/introducing-apache-airflow-3-on-amazon-mwaa-new-features-and-capabilities/

[14] Apache Software Foundation. “AIP-82 External event driven scheduling in Airflow.” Apache Airflow Wiki. https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-82+External+event+driven+scheduling+in+Airflow

[15] Apache Software Foundation. “AIP-38 Modern Web Application.” Apache Airflow Wiki. https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-38+Modern+Web+Application

[16] Apache Software Foundation. “Apache Airflow 3.1.0: Human-Centered Workflows.” Apache Airflow Blog, September 25, 2025. https://airflow.apache.org/blog/airflow-3.1.0/

[17] Apache Software Foundation. “Plugins.” Apache Airflow Documentation. https://airflow.apache.org/docs/apache-airflow/stable/administration-and-deployment/plugins.html

[18] Apache Software Foundation. “AIP-78 Scheduler-managed backfill.” Apache Airflow Wiki. https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-78+Scheduler-managed+backfill

[19] Airflow Mailing List. “[DISCUSS] AIP-78 scheduler-managed backfill.” https://www.mail-archive.com/dev@airflow.apache.org/msg13330.html

[20] Apache Software Foundation. “AIP-69 Edge Executor (Initial Name: Remote Executor).” Apache Airflow Wiki. https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=301795932

[21] Apache Software Foundation. “Edge Executor.” Apache Airflow Providers Edge Documentation. https://airflow.apache.org/docs/apache-airflow-providers-edge3/stable/edge_executor.html

[22] Astronomer. “Upgrade from Apache Airflow® 2 to 3.” Astronomer Docs. https://www.astronomer.io/docs/learn/airflow-upgrade-2-3

[23] Amazon Web Services. “Best practices for migrating from Apache Airflow 2.x to Apache Airflow 3.x on Amazon MWAA.” AWS Blog, October 7, 2025. https://aws.amazon.com/blogs/big-data/best-practices-for-migrating-from-apache-airflow-2-x-to-apache-airflow-3-x-on-amazon-mwaa/

[24] Astronomer. “Airflow 3 Development Update.” Astronomer Blog, February 28, 2025. https://www.astronomer.io/blog/apache-airflow-3-development-update/

[25] GitHub. “Release Airflow 3.0 – Issue #39593.” Apache Airflow Repository. https://github.com/apache/airflow/issues/39593

[26] Apache Software Foundation. “Release Notes – Airflow 3.1.3.” Apache Airflow Documentation. https://airflow.apache.org/docs/apache-airflow/stable/release_notes.html

[27] Apache Software Foundation. “AIP-84 UI REST API.” Apache Airflow Wiki. https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-84+UI+REST+API

[28] Apache Software Foundation. “Edge Worker Deployment.” Apache Airflow Providers Edge Documentation. https://airflow.apache.org/docs/apache-airflow-providers-edge3/stable/deployment.html

[29] The Data Canal. “Airflow 3.0: DAG versioning, multi-language support and native AI/ML workflows.” Substack, March 5, 2025. https://thedatacanal.substack.com/p/airflow-30-dag-versioning-multi-language

[30] Airflow Summit 2025. “Seamless Migration: Leveraging Ruff for a Smooth Transition from Airflow 2 to Airflow 3.” https://airflowsummit.org/sessions/2025/seamless-migration-leveraging-ruff-for-a-smooth-transition-from-airflow-2-to-airflow-3/

Kapak Görseli: Photo by Florian Schmid on Unsplash