ETL mi, ELT mi? Production kararı

Aşçı Analojisi: ETL vs ELT

Veriyi hedef sisteme taşırken iki strateji var:

ETL (Extract → Transform → Load): Veri kaynaktan çekilir, taşıma sırasında dönüştürülür, hedefe yazılır. Aşçı mutfakta yemeği pişirip servise öyle gönderir. Örnek: Spark batch job, dbt-clean-then-load.

ELT (Extract → Load → Transform): Veri ham haliyle hedefe yazılır, dönüşüm hedef sistemde yapılır. Aşçı malzemeyi büyük kaba koyar, müşteri istediğinde pişirir. Örnek: dlt ile ham JSON → BigQuery → dbt ile dönüşüm.

Production’da Hangisi?

Kriter	ETL	ELT
Veri ambarı maliyeti	Düşük (temizlenmiş saklanır)	Yüksek (ham + temizlenmiş birlikte)
Geliştirme hızı	Yavaş (her yeni sütun için pipeline değişir)	Hızlı (warehouse içinde model ekle)
Veri keşfi	Zor (transform kaybeder)	Kolay (ham veri duruyor)
Hesaplama nereye gider	Spark kümesi (senin masrafın)	BigQuery (kullanım başına)
Tipik araçlar	Airflow + Spark + dbt	dlt + BigQuery + dbt
Tipik müşteri	Düzenleyiciye tabi sektör (banka, sağlık)	SaaS startup, e-ticaret

2010 öncesi ETL her şeydi (Informatica, Talend). 2015 sonrası Snowflake/BigQuery ile ELT patladı. 2026’da greenfield projelerin %80’i ELT.

Production Pattern: GCS → BigQuery ELT

Senaryo: Partner API’si her gece 02:00’de JSON dosyalarını GCS’e bırakıyor. Sen bu dosyaları ham olarak BigQuery’ye yazıyorsun. dbt bir sonraki adımda temizliyor (modül 4).

id: gcs_to_bigquery_elt
namespace: prod
schedule:
  cron: "0 3 * * *"
tasks:
  - id: load_raw_orders
    type: io.kestra.plugin.gcp.bigquery.Load
    from: gs://lemonade-raw/orders/{{ trigger.date }}.json
    destinationTable: lemonade.raw.orders_{{ trigger.date | date('yyyyMMdd') }}
    writeDisposition: WRITE_TRUNCATE
    format: JSON
    jsonExtension: GEOJSON

  - id: count_rows
    type: io.kestra.plugin.jdbc.bigquery.Query
    sql: |
      SELECT COUNT(*) AS satir_sayisi,
             MIN(_PARTITIONTIME) AS en_eski
      FROM `lemonade.raw.orders_*`
    fetch: true

İlk task ham veriyi partition’lı tabloya yazar (gün bazlı). İkinci task kalite kontrolü yapar. Backfill yaparsan 90 gün × 2 task = 180 execution paralel çalışır.

Maliyet Hesabı (Basit)

100 GB/gün ham veri, 30 gün tutuyorsun → 3 TB. BigQuery aktif depolama $20/TB/ay → ~$60/ay. Aynı veriyi ETL ile temizleyip yazsaydın ~%40 sıkıştırma ile 1.8 TB → $36/ay. Fark $24/ay. ELT pahalı görünüyor.

Ama: ham veriyle 3 yeni soru cevapladın (analitik ekibi kendi dbt modelini yazdı). ETL’de o sorular için 2 hafta pipeline geliştirme gerekirdi (mühendis maliyeti $5K+). Tradeoff net.

Bugün Yaptık

• ETL/ELT farkını production açısından karşılaştırdık
• GCS → BigQuery ELT pattern öğrendik (partition’lı ham tablo)
• Maliyet/hız tradeoff’unu somut sayılarla gördük

Ellerini Kirlet

1. gcs_to_bigquery_elt flow’unu Kestra’ya ekle.
2. Henüz GCS bucket’ın yoksa bir örnek CSV oluştur, io.kestra.plugin.jdbc.postgresql.Query ile Postgres’e yaz (BigQuery adımını skip et).
3. Execution log’unda count_rows task’ının çıktısını gör.
4. README’de: “Bu akışın maliyeti ne?” sorusunu cevapla — ayda kaç GB yazıyorsun, BigQuery fiyatıyla hesapla.

Sıradaki

Bir sonraki ders: Zamanlayıcılar, backfill ve orkestrasyon araçları →