Apache Airflow, uzun yıllardır veri mühendislerinin en çok tercih ettiği orkestrasyon araçlarından biri. Özellikle farklı veri kaynaklarından veri çekme (extract), dönüştürme (transform) ve yükleme (load) süreçlerinde DAG (Directed Acyclic Graph) kavramıyla sunduğu esnek yapı, Airflow’u adeta endüstri standardı haline getirdi.

Ancak Airflow’un klasik kullanım biçimi olan task-oriented (görev odaklı) yaklaşım, her ne kadar güçlü olsa da bazı kısıtlar içeriyordu. Özellikle veri odaklı düşünen ekipler için “hangi verinin ne zaman güncellendiği, hangi tablonun hangi tabloya bağlı olduğu” gibi soruları yönetmek zordu.

İşte Airflow 3 ile gelen asset-oriented (varlık odaklı) yaklaşım bu noktada devreye giriyor. Artık yalnızca görevleri değil, bu görevlerin ürettiği veri varlıklarını (tables, files, ML modelleri, feature sets, vb.) merkeze alarak süreçleri tanımlayabiliyoruz.

Bu yazıda, Airflow 3’teki bu iki yaklaşımın farklarını, avantajlarını ve kullanım senaryolarını derinlemesine ele alacağız.

1. Task-Oriented Yaklaşım Nedir?

Airflow’un yıllardır alıştığımız klasik modeli, task-oriented yani görev odaklı bir modeldir. Burada asıl odak, yapılacak işler (tasks) ve bu işler arasındaki bağımlılıklardır.

Temel Özellikler

• Biriminiz görevdir (task): Yani PythonOperator, BashOperator, Sensor gibi operatörlerden türetilmiş işler.
• Çalıştırma zamanı zaman tabanlıdır: Cron ifadeleri, saatlik/günlük tetiklemeler ya da manuel trigger’lar.
• Bağımlılıklar manuel tanımlanır: task1 >> task2 şeklinde.
• Airflow veri hakkında bilgi sahibi değildir: Sadece hangi görevlerin çalıştırıldığına ve başarılı/başarısız olduğuna bakar.

Küçük Bir Örnek

from airflow.decorators import dag, task
from datetime import datetime

@dag(schedule="@daily", start_date=datetime(2024,1,1), catchup=False)
def etl_pipeline():
    @task
    def extract():
        print("Veri çekiliyor...")
    
    @task
    def transform():
        print("Veri dönüştürülüyor...")
    
    @task
    def load():
        print("Veri yükleniyor...")

    extract() >> transform() >> load()

etl_pipeline()

Burada üç basamaklı klasik bir ETL süreci var. Her şey görevler üzerinden tanımlı. Airflow için “hangi tablo güncellendi” ya da “hangi dosya üretildi” önemli değil; önemli olan görevlerin sırasıyla çalışması.

2. Asset-Oriented Yaklaşım Nedir?

Airflow 3 ile birlikte gelen en önemli yeniliklerden biri de asset-oriented (varlık odaklı) yaklaşımdır. Burada odak görevlerden ziyade veri varlıklarıdır.

Temel Özellikler

• Biriminiz asset’tir (varlık): Yani bir tablo, dosya, model veya başka bir veri nesnesi.
• Çalıştırma zamanı veri tabanlı olabilir: Bir asset güncellendiğinde, ona bağlı olan diğer asset’ler otomatik tetiklenebilir.
• Bağımlılıklar otomatik çıkarılır: Bir asset fonksiyonu başka bir asset’i parametre olarak alıyorsa bağımlılık otomatik oluşturulur.
• Lineage (soy ağacı) doğal olarak oluşur: Hangi asset’in hangisinden türediği, grafiksel olarak görülebilir.

Küçük Bir Örnek

from airflow.decorators import asset

@asset
def raw_data():
    return "ham veri"

@asset
def cleaned_data(raw_data):
    return raw_data + " -> temizlenmiş veri"

@asset
def analytics_table(cleaned_data):
    return cleaned_data + " -> analiz tablosu"

Burada üç asset tanımladık: raw_data, cleaned_data, analytics_table.

• Airflow, cleaned_data’nın raw_data’ya bağımlı olduğunu,
• analytics_table’ın da cleaned_data’ya bağlı olduğunu kendisi anlıyor.

Bir asset güncellendiğinde ona bağlı tüm asset’ler otomatik tetiklenebiliyor. Bu, veri odaklı ekipler için devrim niteliğinde bir kolaylık.

3. İki Yaklaşım Arasındaki Farklar

Şimdi gelin task-oriented ve asset-oriented yaklaşımları yan yana koyalım:

4. Hangi Durumda Hangisini Kullanmalı?

• Eğer işiniz daha çok API çağrıları, script çalıştırmaları, bildirimler gibi veri bağımsız görevlerden oluşuyorsa → Task-Oriented yaklaşım mantıklı.
• Eğer işiniz tablo üretmek, dosya işlemek, ML modeli eğitmek gibi veri odaklı süreçlerden oluşuyorsa → Asset-Oriented yaklaşım daha uygun.
• Gerçek hayatta çoğu zaman ikisini bir arada kullanmak gerekiyor. Bazı adımlar görev odaklı, bazıları varlık odaklı olabilir.

5. Gerçek Hayattan Senaryolar

Senaryo 1: Klasik ETL

Bir finans şirketi her gün müşteri işlemlerini alıyor, temizliyor ve bir veri ambarına yüklüyor.

• Task-oriented yaklaşımda: extract >> transform >> load.
• Asset-oriented yaklaşımda: transactions_raw → transactions_clean → transactions_dw.

Senaryo 2: Machine Learning Pipeline

Bir e-ticaret şirketi ürün öneri sistemi geliştiriyor.

• Asset’ler: user_features, product_features, training_data, recommendation_model.
• Model güncellendiğinde otomatik olarak recommendations_table asset’i de güncelleniyor.

Senaryo 3: RAG (Retrieval-Augmented Generation)

Bir yapay zeka uygulaması için belgeler vektör veritabanına yükleniyor.

• Asset’ler: pdf_raw, pdf_chunks, vector_embeddings, retrieval_index.
• Yeni PDF eklendiğinde zincirleme tüm downstream asset’ler tetikleniyor.

6. Avantajlar ve Zorluklar

Task-Oriented’in Avantajları

• Çok esnek, her tür iş için kullanılabilir.
• Zaten Airflow kullanıcılarının alışık olduğu yapı.
• Debugging ve log takibi net.

Asset-Oriented’in Avantajları

• Veri soy ağacı (lineage) doğal olarak çıkıyor.
• Veri odaklı ekipler için daha anlamlı.
• Bağımlılıklar otomatik çıkarıldığı için hata yapma riski azalıyor.
• Data freshness (veri güncelliği) daha iyi yönetilebiliyor.

Zorluklar

• Task-oriented: Veri odaklı işlerde karmaşık hale geliyor.
• Asset-oriented: Henüz yeni bir özellik, toplulukta kullanım örnekleri sınırlı. Ayrıca bazı “non-data” görevler asset mantığına tam oturmuyor.

7. İleride Ne olur?

Airflow’un bu iki yaklaşımı yan yana desteklemesi aslında hibrit bir gelecek öngörüyor. Yani tek tip “ya bu ya şu” yaklaşım yerine:

• Veri varlıkları asset olarak tanımlanacak.
• Veri dışı işler task olarak kalmaya devam edecek.

Böylece hem veri mühendisleri hem de genel iş süreçlerini yöneten ekipler için Airflow tek platform olmaya devam edecek.

Sonuç

Airflow 3 ile birlikte task-oriented ve asset-oriented yaklaşımlar yan yana kullanılabilir hale geldi.

• Task-oriented: Görev odaklı, zaman tabanlı, klasik yaklaşım.
• Asset-oriented: Varlık odaklı, veri tabanlı, lineage dostu modern yaklaşım.

Hangisini kullanmanız gerektiği tamamen projenizin yapısına bağlı. Ancak büyük resmi görmek gerekirse:

• Task-oriented yaklaşımdan asset-oriented yaklaşıma doğru bir kayış yaşanıyor.
• Veri odaklı ekipler için asset yaklaşımı gelecekte standart haline gelecek gibi görünüyor.

Airflow 3 Veri Bilimi Okulu Data Engineering Bootcamp‘te. Eğer veri mühendisliğini kapsamlı ve uygulama öğrenmek istiyorsanız Türkiye’nin en kapsamlı ve uygulamalı veri mühendisliği eğitimini tavsiye ederim.

Kaynaklar

• Kapak Görseli: Photo by Agence Olloweb on Unsplash