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

Veri mühendisliğine ilk adım attığımda, "ETL yazmak" kulağa oldukça basit geliyordu: veriyi al, dönüştür, yükle. Ama işin içine girince fark ettim ki sağlam bir ETL akışı tasarlamak, bir binanın temelini atmak gibi — görünmez ama her şeyi taşıyor.

Bu yazıda sıfırdan bir ETL akışı tasarlarken izlediğim adımları ve öğrendiğim dersleri paylaşmak istiyorum.

ETL Nedir, Ne Değildir?

ETL, İngilizce Extract, Transform, Load kelimelerinin kısaltmasıdır. Türkçesiyle: veriyi kaynaktan çek, anlamlı hale getir, hedef sisteme yükle.

Pek çok kişi ETL'i sadece bir veri kopyalama işi olarak görüyor. Oysa iyi bir ETL;

• veri kalitesini garanti eder,
• iş kurallarını merkezi bir yerde uygular,
• hata durumlarında geri alınabilir (idempotent) olmak zorundadır.

1. Kaynağı Tanı

Her şeyden önce veri kaynağını iyi anlamak gerekiyor. Sormam gereken ilk sorular:

• Kaynak bir REST API mi, veritabanı mı, dosya sistemi mi?
• Veri ne sıklıkla değişiyor? (batch mi, streaming mi?)
• Şema sabit mi, yoksa sürprizlerle mi dolu?

Özellikle şema değişikliklerine karşı savunmacı bir yaklaşım benimsiyorum. Gelen alan yoksa akışın patlaması değil, uyarı üretmesi gerekiyor.

2. Dönüşüm Mantığını Belirle

Transform aşaması genellikle en karmaşık kısım. Burada yapılanlar:

• Veri temizleme: Null değerler, encoding sorunları, tarih formatları
• İş kuralları: "Sipariş tutarı 0'dan küçükse geçersiz say" gibi
• Zenginleştirme: Başka tablolardan JOIN ile bilgi ekleme
• Normalizasyon / Denormalizasyon: Hedef sisteme göre şekil verme

Bu mantığı SQL mi, Python mı yoksa dbt gibi bir araçla mı yazacağınız projeye göre değişiyor. Ben genellikle dbt + Python kombinasyonunu tercih ediyorum: iş kuralları dbt'de, karmaşık dönüşümler Python'da.

3. Hedef Sistemi Tanımla

Verinin nereye gideceği, nasıl taşınacağını doğrudan etkiliyor.

| Hedef | Dikkat Edilecek | |---|---| | PostgreSQL / MySQL | Upsert stratejisi, constraint'ler | | BigQuery / Redshift | Partition, cluster yapısı | | Data Lake (S3, GCS) | Dosya formatı (Parquet önerilir), dizin yapısı | | Elasticsearch | Mapping uyumu |

4. Hata Yönetimi ve İzlenebilirlik

Bir ETL akışında en çok zaman kaybettiğim konu bu. İyi bir akışta şunlar olmazsa olmaz:

• Dead letter queue veya hata tablosu: Başarısız kayıtlar kaybolmamalı
• Loglama: Her adımda kaç kayıt işlendi, kaç hata oluştu
• Alerting: Airflow, Prefect veya benzeri bir orkestratörden alarm

Monitoring olmayan ETL, motorun ışığı yanmayan bir araç gibi — bir süre çalışır, sonra aniden durur.

5. Idempotency: Tekrar Çalıştırabilirlik

Bu belki de en çok göz ardı edilen tasarım prensibi. Akışınız aynı zaman aralığı için iki kez çalışırsa ne olur? Veri çiftlendi mi?

Çözüm: Hedef tabloya yazmadan önce ilgili aralığı temizle (DELETE + INSERT), ya da MERGE / UPSERT kullan. Bu sayede akışı güvenle yeniden tetikleyebilirsiniz.

Araç Seçimi Üzerine

Popüler araçlar arasında Airflow, Prefect, Luigi ve modern alternatifler olan dbt Cloud, Dagster sayılabilir. Benim önerim: önce problemi çöz, sonra araca karar ver. Basit bir akış için Airflow kurmak bazen aşırıya kaçmak olabilir; bir Python scripti + cron da gayet iş görür.

Son Söz

Sıfırdan ETL tasarlamak; teknik bilgiden çok veri disiplini ve sistem düşüncesi gerektiriyor. Kaynağı tanı, dönüşümü belgele, hatayı sahiplen ve her zaman yeniden çalıştırılabilir yaz. Bu dört kural çoğu zaman kurtarıcı oluyor.

Sorularınız veya farklı deneyimleriniz varsa yorumlarda buluşalım.