Apache Airflow ile Dagster karşılaştırması: görev mi yönetilmeli, veri varlığı mı?

Aynı iş, farklı soru: "Ne çalışacak?" ile "Hangi veri üretilecek?"

Airflow ve Dagster, veri hatlarını Python ile kod olarak tanımlayan, zamanlayan, izleyen ve hata durumunda yeniden çalıştıran açık kaynak orkestrasyon araçlarıdır. İkisinde de bir web arayüzü, zamanlamalar, olaya bağlı tetikleyiciler ve yeniden denemeler bulunur.

Temel ayrım bakış açısındadır. Airflow'da birinci sınıf kavram görevdir: bir Dag, zamanlamayı, görevleri ve görevler arası bağımlılıkları bir araya getirir ve Airflow bu görevleri doğru sırayla çalıştırır. Dagster'da ise birinci sınıf kavram varlıktır (asset): bir tablo, veri seti ya da makine öğrenmesi modeli gibi mantıksal bir veri birimi. Varlıklar birbirine bağımlı tanımlanır ve bu bağımlılıklardan veri soy ağacı (lineage) kendiliğinden oluşur. Kısacası Airflow "hangi adım ne zaman çalışacak" sorusundan, Dagster "hangi veri varlığı güncel olmalı ve neye dayanıyor" sorusundan yola çıkar.

Kavram eşleştirmesi: Airflow terimlerinin Dagster karşılıkları

Ekipler genellikle birini bilerek diğerine bakar; bu yüzden kavramları yan yana koymak işe yarar. • Ölçüt, akış birimi: Airflow'da Dag / Dagster'da varlık grafiği ya da bir varlık seçimini veya op grafiğini çalıştıran job. • Ölçüt, iş birimi: Airflow'da görev (operatör ya da @task) / Dagster'da varlık; daha düşük seviyede op. Dagster belgelerine göre op'ların yerini büyük ölçüde varlıklar almıştır. • Ölçüt, dış bağlantılar: Airflow'da bağlantılar (connections) ve kancalar (hooks) / Dagster'da kaynaklar (resources); veritabanı ya da API bağlantısını varlıklara, zamanlamalara ve sensörlere sağlar. • Ölçüt, tetikleme: Airflow'da zamanlama, sensörler ve veri farkındalıklı tetikleme / Dagster'da zamanlamalar (schedules), sensörler ve varlıkların güncelliğine dayalı otomasyon. • Ölçüt, dilimleme: Airflow'da mantıksal tarih aralıkları ve geriye dönük doldurma (backfill) / Dagster'da bölümler (partitions) ve bölüm bazında backfill. • Ölçüt, kayıt noktası: Airflow'da Dag dosyalarının bulunduğu paket / Dagster'da tüm tanımları toplayan üst seviye Definitions nesnesi.

Aynı hat iki araçta nasıl yazılır?

Örneğin ham siparişleri okuyup günlük satış özet tablosu üreten basit bir hat düşünelim. Airflow'da TaskFlow yazımıyla görevler tanımlanır ve bağımlılık fonksiyon çağrısıyla kurulur:

@dag(schedule="@daily") def sales_pipeline(): @task def raw_orders(): ... @task def daily_summary(orders): ... daily_summary(raw_orders())

Dagster'da aynı iş varlıklarla yazılır; bağımlılık, fonksiyonun parametre adından çıkarılır:

@asset def raw_orders(): ...

@asset def daily_summary(raw_orders): ...

Fark kodun uzunluğunda değil, arayüzde görülen şeydedir. Airflow arayüzü görevlerin çalışma geçmişini gösterir. Dagster arayüzü ise daily_summary tablosunun raw_orders tablosundan türediğini, en son ne zaman üretildiğini ve bağlı kontrollerin sonucunu gösterir; zamanlama ayrıca bir schedule ya da otomasyon kuralıyla bağlanır.

Veri kalitesi, soy ağacı ve gözlemlenebilirlik

Dagster'ın varlık modeli, veri platformu sorularını orkestratörün içine taşır. Asset check'ler bir varlığın kalite, tazelik ya da bütünlük beklentilerini karşılayıp karşılamadığını varlık çalıştığında doğrular ve sonucu kaydeder. Arayüzde hangi tablonun hangi kaynaklardan beslendiği, en son ne zaman güncellendiği ve hangi kontrolden geçtiği tek yerde görülür. Bir kaynak tablo bozulduğunda etkilenecek aşağı akış varlıkları grafikte hemen izlenebilir.

Airflow'da görev başarı ya da başarısızlığı en temel sinyaldir; verinin kendisinin doğru olup olmadığı genellikle ayrı bir veri kalitesi aracı ya da görev içindeki kontrollerle sağlanır. Soy ağacı için OpenLineage gibi ek entegrasyonlar kullanılabilir. Bu, Airflow'un yetersiz olduğu anlamına gelmez; yalnızca veri odaklı gözlemlenebilirliğin mimariye sonradan eklendiğini gösterir.

Geliştirme ve test deneyimi

Dagster tasarımında yerel geliştirme ve test öne çıkar. Kaynaklar dışarıdan verildiği için bir varlık, testte gerçek veritabanı yerine sahte (mock) bir kaynakla çalıştırılabilir; ortam (geliştirme, test, üretim) farkı yapılandırmayla yönetilir. Varlıkların bağımsız Python fonksiyonları olması, birim testi yazmayı kolaylaştırır.

Airflow'da da Dag'ler test edilebilir ve yerel ortam Docker ile kurulabilir. Ancak operatörlerin bağlantıları Airflow meta veri veritabanından ya da ortam değişkenlerinden okuması, test ortamını kurmayı biraz daha zahmetli hale getirebilir. Pratikte iki araçta da önerilen yol aynıdır: iş mantığını orkestrasyon kodundan ayırmak, Dag ya da varlık tanımını ince tutmak.

Hangi durumda Airflow, hangi durumda Dagster?

Airflow'un ağır bastığı durumlar: • Orkestre edilen işler veri üretmekten öte; dosya taşıma, API çağrısı, rapor gönderme, dış sistem tetikleme gibi görev zincirleri. • Kurumda yerleşik Airflow altyapısı, yönetilen Airflow hizmeti ve büyük bir Dag kütüphanesi var. • Çok sayıda kurumsal sisteme hazır sağlayıcı paketi gerekiyor. • İşe alım tarafında geniş aday havuzu önemli.

Dagster'ın ağır bastığı durumlar: • Ekip kendini bir veri platformu ekibi olarak görüyor; tablolar, modeller ve raporlar ürün gibi yönetiliyor. • dbt modelleri, ambar tabloları ve makine öğrenmesi özellikleri arasında uçtan uca soy ağacı ve tazelik takibi isteniyor. • Bölüm bazında artımlı işleme ve hedefli backfill sık ihtiyaç. • Yeni bir platform sıfırdan kuruluyor ve devralınan Dag yükü yok.

Karar toplantısında şu soruyu sormak yol gösterir: ekip arızayı "hangi görev düştü" diye mi, "hangi tablo bayatladı" diye mi tarif ediyor?

Birlikte kullanım ve kademeli geçiş

Airflow'dan Dagster'a geçiş genellikle toptan değil kademeli yapılır. Yeni veri ürünleri Dagster'da varlık olarak açılırken mevcut Airflow Dag'leri bir süre çalışmaya devam eder. Geçişte ilk adım, Airflow görevlerinin ürettiği tabloları listelemek ve bunları Dagster'da varlık olarak modellemektir; böylece hangi görevin hangi veriyi ürettiği ortaya çıkar ve gereksiz ara adımlar ayıklanır.

İki aracı uzun süre birlikte işletmek bakım maliyeti doğurur: ayrı arayüzler, ayrı uyarı kanalları ve ayrı yetkinlikler. Bu yüzden geçişin hedef tarihi ve hangi Dag'lerin taşınmayacağı (örneğin yalnız operasyonel görev zincirleri) baştan kararlaştırılmalıdır.

Mindset programlarında Airflow ve Dagster

Airflow ile Veri Pipeline'ları eğitimi Airflow mimarisi, Dag tasarımı, operatör kütüphanesi ve üretim ortamında ölçeklendirme başlıklarıyla veri mühendislerinin mevcut kurulumları daha sağlam işletmesine odaklanır.

Dagster ile Veri Orkestrasyonu eğitimi varlık modeli, partition ve backfill ile artımlı işleme, veri kalitesi ve tazelik politikaları konularını ele alır. Analitik mühendisliği ve veri platformu ekipleri, tablolarını ürün gibi yöneten bir düzen kurmak için bu programı ekip olarak çalışabilir.