Sıfırdan Bir ETL Akışı Tasarlamak

Veriyle çalışan herkesin er ya da geç karşılaştığı soru şu olur: "Bu veriyi oradan alıp buraya nasıl taşıyacağız?" İşte tam bu noktada ETL — Extract, Transform, Load — devreye girer. Kulağa basit gelir; ama kötü tasarlanmış bir ETL akışı, aylarca süren baş ağrısına dönüşebilir. Bu yazıda sıfırdan bir ETL akışı tasarlarken izlediğim adımları ve dikkat ettiğim noktaları paylaşıyorum.

ETL Nedir, Ne Değildir?

ETL, birden fazla kaynaktan veri çekip onu anlamlı bir formata dönüştürerek hedef sisteme yüklemek demektir. Bir ERP'den satış verisi, bir IoT cihazından sensör okumu, bir REST API'den kullanıcı davranışı — hepsini bir araya getirmek istiyorsanız ETL'e ihtiyacınız var.

Ama şunu baştan söyleyelim: ETL bir araç değil, bir mimari karardır. Hangi aracı kullandığınızdan çok, akışı nasıl kurguladığınız önemlidir.

1. Kaynakları ve Hedefi Netleştirin

Tasarıma başlamadan önce şu soruların cevabını kağıda dökün:

• Kaynak sistemler neler? Veritabanı mı, dosya mi, API mi?
• Veri ne sıklıkla güncelleniyor? Gerçek zamanlı mı, günlük batch mi?
• Hedef sistem ne? Veri ambarı, data lake, operasyonel bir tablo mu?
• Hacim ne kadar? Günde 10 bin satır mı, 10 milyon mu?

Bu soruların cevabı, hem araç seçiminizi hem de akış mimarinizi doğrudan etkiler.

2. Extract: Veriyi Kaynaktan Çekmek

Extract aşamasında en kritik karar şudur: tam yükleme mi (full load), yoksa artımlı yükleme mi (incremental load)?

• Tam yükleme her seferinde tüm veriyi çeker; basittir ama ölçeklenmez.
• Artımlı yükleme yalnızca değişen kayıtları çeker; daha verimlidir ama kaynak sistemde updated_at gibi bir sütun ya da CDC (Change Data Capture) mekanizması gerektirir.

Mümkün olduğunda artımlı yüklemeye yatırım yapın. Başta zahmetli görünür, ilerleyen dönemde size çok zaman kazandırır.

3. Transform: Veriyi Anlam Kazandırmak

Transform, ETL'in kalbidir ve en çok hata yapılan aşamadır. Dönüşüm katmanında şunlara dikkat edin:

• Veri tipi uyumsuzlukları: Kaynak string gönderiyorsa hedef integer bekleyemez.
• Null değerler: Her zaman varsayılan bir strateji belirleyin; boş bırakmak nadiren doğru cevaptır.
• Tekrarlayan kayıtlar (deduplication): İki kez çekilen veri iki kez yüklenmemeli.
• İş kuralları: "Negatif stok mümkün mü?" gibi domain bilgisi gerektiren kontroller bu aşamada yapılır.

Dönüşüm mantığını mümkün olduğunca saf fonksiyonlar olarak yazın — yan etkisiz, test edilebilir, tekrar kullanılabilir.

4. Load: Hedefe Yazmak

Yükleme aşamasında da birkaç strateji var:

• Append: Yeni kayıtları ekle, eskilere dokunma.
• Upsert (Merge): Varsa güncelle, yoksa ekle.
• Truncate & Load: Tabloyu temizle, yeniden yükle.

Hangi stratejiyi seçeceğiniz, hedef sistemin tolerans düzeyine ve iş gereksinimlerine göre değişir.

5. Hata Yönetimi ve İzleme

Bir ETL akışının ne kadar iyi çalıştığını, ancak bir şeyler ters gittiğinde anlarsınız. Bu yüzden şunları baştan kurun:

• Dead letter queue veya hata tablosu: Başarısız kayıtları kaybedin değil, saklayın.
• Loglama: Her çalışma için satır sayısı, süre ve hata mesajı kaydedin.
• Alerting: Akış sessizce çöküyorsa bunu siz değil, sistem size söylesin.

Araç Seçimi Üzerine Birkaç Söz

Apache Airflow, dbt, AWS Glue, Azure Data Factory, Airbyte... Seçenekler bol. Ama araç, mimariden önce gelirse projeyi araca göre şekillendirmeye başlarsınız — bu tehlikelidir.

Önce mimariyi tasarlayın, sonra o mimariye en uygun aracı seçin.

Sonuç

İyi bir ETL akışı; tekrarlanabilir, izlenebilir, test edilebilir ve bakımı kolay olmalıdır. Sıfırdan tasarlarken acele etmeyin. Kaynağı anlayın, dönüşüm mantığını belgeleyin, hataları sahiplenin. Veri güvenilir olduğunda, üstüne inşa edilen her şey de güvenilir olur.