Apache Airflow 3 Hakkında Mutlaka Bilmeniz Gereken 10 Kritik Değişiklik

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ş

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

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:

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:

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ı:

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:

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:

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:

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:

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

Şimdi Airflow 3 ile:

Bu özellik iki AIP ile tanımlandı:

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:

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

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

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

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’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:

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:

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)

Bundle TürüSürümleme DesteğiDavranış
GitDagBundle✅ Tam destekDAG run başladığındaki commit ile tamamlanır
LocalDagBundle❌ YokHer zaman en son kod kullanılır
S3DagBundle❌ YokHer zaman en son kod kullanılır

Ö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]:

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:

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:

Çö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:

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:

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]:

Öne Çıkan UI Özellikleri

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]:

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:

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ı

Airflow 3’te Backfill

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

# 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)

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ü:

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

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

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

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:

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]:

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

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

Ayar (Setting)Airflow 2 Varsayılanı (Default)Airflow 3 Varsayılanı (Default)
catchup_by_defaultTrueFalse
create_cron_data_intervalsTrueFalse
Varsayılan zamanlama (Default schedule)@onceNone
Varsayılan auth_managerFABSimpleAuthManager

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)

Eski Yol (Deprecated)Yeni Yol (airflow.sdk)
airflow.decorators.dagairflow.sdk.dag
airflow.decorators.taskairflow.sdk.task
airflow.decorators.task_groupairflow.sdk.task_group
airflow.decorators.setupairflow.sdk.setup
airflow.decorators.teardownairflow.sdk.teardown
airflow.models.dag.DAGairflow.sdk.DAG
airflow.models.baseoperator.BaseOperatorairflow.sdk.BaseOperator
airflow.models.param.Paramairflow.sdk.Param
airflow.sensors.base.BaseSensorOperatorairflow.sdk.BaseSensorOperator
airflow.hooks.base.BaseHookairflow.sdk.BaseHook
airflow.datasets.Datasetairflow.sdk.Asset
airflow.models.connection.Connectionairflow.sdk.Connection
airflow.models.variable.Variableairflow.sdk.Variable

Zaman Çizelgesi (Timeline)

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

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)

Bileşen (Component)Airflow 2 KomutuAirflow 3 Komutu
Web Sunucusu (Webserver)airflow webserverairflow api-server
Zamanlayıcı (Scheduler)airflow schedulerairflow scheduler
DAG İşlemcisi (DAG Processor)(Scheduler içinde)airflow dag-processor
Celery İşçisi (Celery Worker)airflow celery workerairflow celery worker
Uç Nokta İşçisi (Edge Worker)–airflow edge worker

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:

“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

Özellik (Feature)Airflow 2Airflow 3
Mimari (Architecture)Tüm bileşenler DB’ye doğrudan erişir (direct DB access)API tabanlı hizmet odaklı mimari (API-based SOA)
UIFlask tabanlıReact + FastAPI
DAG Sürümleme (DAG Versioning)YokTam destek (Full support)
Veri Farkındalığı (Data Awareness)DatasetsAssets (genişletilmiş/extended)
Geriye Dönük Doldurma (Backfill)CLI tabanlı, senkronScheduler yönetimli, UI desteği
Olay Güdümlü (Event-Driven)Sınırlı (Limited)Asset Watchers ile tam destek
Çoklu Dil (Multi-Language)Yalnızca PythonTaskSDK ile çoklu dil (yakında)
SubDAGDestekleniyor (deprecated)Kaldırıldı → TaskGroups
SLADestekleniyorKaldırıldı → Deadline Alerts
REST APIv1v2 (FastAPI)
Kimlik Doğrulama Yöneticisi (Auth Manager)FABSimpleAuthManager (varsayılan/default)
DAG İşlemcisi (DAG Processor)Scheduler içinde (within Scheduler)Bağımsız süreç (Standalone process)

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)

Dikkat Edilmesi Gerekenler (Things to Watch Out For)

Ö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

Etiketlendi , , ,

Bir yanıt yazın