ETL ve ELT
- ETL (Extract, Transform, Load): Veri kaynakta çekilir, ayrı bir sunucuda dönüştürülür, sonra ambara yüklenir. Klasik yaklaşım (Informatica, SSIS).
- ELT: Ham veri önce ambara yüklenir, dönüşüm ambarın içinde SQL ile yapılır. Bulut ambarlarının ucuz depolama ve güçlü hesaplama gücüyle standart hale geldi (Fivetran/Airbyte + dbt).
Katmanlı mimari
| Katman | İçerik | Örnek |
|---|---|---|
| Raw / bronze | Kaynaktan olduğu gibi, değiştirilmeden | raw_signups |
| Staging / silver | Temizlenmiş, tipleri düzeltilmiş, tekilleştirilmiş, adlar standart | stg_signups |
| Mart / gold | İş mantığı uygulanmış, analize hazır fact/dimension | fct_sales, dim_customer |
İyi bir pipeline'ın özellikleri
- Idempotent: Aynı adımı iki kez çalıştırmak aynı sonucu verir (çift kayıt üretmez).
DELETE + INSERTveyaMERGEkalıpları. - Artımlı: Her seferinde tüm tabloyu değil, sadece yeni/değişen veriyi işler.
- Test edilmiş: Benzersizlik, NULL olmama, referans bütünlüğü kontrolleri.
- Orkestre edilmiş: Airflow, Dagster, Prefect gibi araçlarla bağımlılık sırasına göre çalışır.
Derinleş: ETL mi ELT mi, ve tekrar çalıştırılabilir yükleme
ETL ile ELT arasındaki fark yalnızca harflerin sırası değil; dönüşümün nerede ve hangi araçla yapıldığıdır. Bu, ekip yapısını, maliyeti ve hata ayıklamayı doğrudan etkiler.
| ETL | ELT | |
|---|---|---|
| Dönüşüm yeri | Ayrı bir sunucu / araç | Hedef ambarın içinde, SQL ile |
| Ham veri | Çoğu zaman saklanmaz | Bronze katmanda olduğu gibi durur |
| Hata sonrası | Kaynaktan yeniden çekmek gerekir | Ham veriden yeniden dönüştürülür |
| Kim yazar? | Entegrasyon uzmanı | SQL bilen analist / analitik mühendis |
| Uygun olduğu yer | Hassas verinin ambara girmeden maskelenmesi, eski sistemler | Bulut ambarları (BigQuery, Snowflake), dbt projeleri |
Staging katmanında tipik temizlik
Ham raw_signups tablosunda tarihler iki biçimde geliyor: 2024-02-10 ve 29.07.2024. Staging adımı adları standartlaştırır, e-postayı normalize eder ve tarihi tek biçime çevirir:
SELECT DISTINCT
id,
LOWER(TRIM(email)) AS email,
TRIM(full_name) AS full_name,
CASE WHEN signup_date LIKE '__.__.____'
THEN substr(signup_date, 7, 4) || '-' || substr(signup_date, 4, 2) || '-' || substr(signup_date, 1, 2)
ELSE signup_date END AS signup_date
FROM raw_signups
ORDER BY id;
İdempotent yükleme
Bir iş gece yarısı yarıda kesildi ve yeniden başlatıldı. Yükleme INSERT ile yapılıyorsa aynı ayın satırları iki kez eklenir ve ciro iki katına çıkar. İdempotent bir adım, kaç kez çalışırsa çalışsın aynı sonucu bırakır. En basit kalıp, yüklenecek dilimi önce silip sonra eklemektir:
CREATE TABLE aylik_ciro (ay VARCHAR(7), ciro DECIMAL(12, 2)); -- Aynı adımı iki kez çalıştırıyoruz: DELETE FROM aylik_ciro WHERE ay = '2024-12'; INSERT INTO aylik_ciro (ay, ciro) SELECT '2024-12', ROUND(SUM(oi.quantity * oi.unit_price * (1 - oi.discount)), 2) FROM orders o JOIN order_items oi ON oi.order_id = o.order_id WHERE o.status = 'delivered' AND o.order_date >= '2024-12-01' AND o.order_date < '2025-01-01'; DELETE FROM aylik_ciro WHERE ay = '2024-12'; INSERT INTO aylik_ciro (ay, ciro) SELECT '2024-12', ROUND(SUM(oi.quantity * oi.unit_price * (1 - oi.discount)), 2) FROM orders o JOIN order_items oi ON oi.order_id = o.order_id WHERE o.status = 'delivered' AND o.order_date >= '2024-12-01' AND o.order_date < '2025-01-01'; SELECT ay, ciro, (SELECT COUNT(*) FROM aylik_ciro) AS satir FROM aylik_ciro;
İki çalıştırmadan sonra da tabloda tek satır var. Gerçek sistemlerde DELETE ile INSERT aynı işlem (transaction) içinde yapılır; böylece arada okuyan bir rapor boş tablo görmez. Diğer idempotent kalıplar: MERGE (upsert), CREATE OR REPLACE TABLE ve bölüm üzerine yazma (BigQuery'de WRITE_TRUNCATE).
loaded_at / batch_id ekleniyor mu? Kaynak ve hedef satır sayıları karşılaştırılıyor mu? Hata olursa kim, nasıl haberdar oluyor?