2026'da ETL ve ELT Karşılaştırması: Veri Pipeline Mimarisi Rehberi

Veri mühendisliği alanında son yıllarda yaşanan dönüşüm, organizasyonların veri işleme stratejilerini yeniden değerlendirmesini zorunlu kıldı. Geleneksel ETL (Extract-Transform-Load) yaklaşımı onlarca yıldır kurumsal veri entegrasyonunun temel taşı olarak kabul görürken, bulut tabanlı veri ambarları ve modern analitik platformlarının yükselişiyle birlikte ELT (Extract-Load-Transform) paradigması ön plana çıkmaya başladı. 2026 yılında veri mühendislerinin karşılaştığı en kritik mimari kararlardan biri, bu iki yaklaşım arasında doğru seçimi yapabilmek ve hangi senaryolarda hangisinin avantaj sağlayacağını anlamaktır. Bu makalede her iki yaklaşımın teknik detayları, mimari farklılıkları ve karar kriterleri derinlemesine incelenmektedir.

ETL Pipeline Yaklaşımında Veri İşleme Süreci

ETL mimarisinde veri işleme süreci üç ayrı aşamadan oluşur ve her aşama belirli bir sorumluluğu yerine getirir. Extraction (çıkarma) aşamasında veriler kaynak sistemlerden okunur; veritabanları, API endpointleri, dosya sistemleri veya mesaj kuyrukları kaynak olarak kullanılabilir. Transform (dönüşüm) aşaması, verilerin temizlenmesi, normalizasyonu, agregasyonu ve iş kurallarının uygulanmasını içerir. Load (yükleme) aşamasında ise dönüştürülmüş veriler hedef veri ambarına yazılır.

Bu yaklaşımdaki kritik nokta, dönüşüm işleminin bağımsız bir işlem ortamında gerçekleşiyor olmasıdır. Apache Spark kümeleri, özel ETL sunucuları veya serverless fonksiyonlar bu amaçla kullanılır. Kaynak sistemden alınan ham veriler, ara bir staging alanında işlenir ve yalnızca temizlenmiş, iş gereksinimlerine uygun hale getirilmiş veriler hedef sisteme aktarılır.

# etl_pipeline.py
import pandas as pd
from sqlalchemy import create_engine

def extract(source_url: str) -> pd.DataFrame:
    """Extract raw data from source system."""
    return pd.read_csv(source_url)

def transform(df: pd.DataFrame) -> pd.DataFrame:
    """Clean and reshape data before loading."""
    # Remove rows with missing revenue
    df = df.dropna(subset=["revenue"])
    # Normalize currency to USD
    df["revenue_usd"] = df.apply(
        lambda row: row["revenue"] * get_exchange_rate(row["currency"]),
        axis=1
    )
    # Aggregate to daily granularity
    return df.groupby("date").agg({"revenue_usd": "sum"}).reset_index()

def load(df: pd.DataFrame, engine) -> None:
    """Write transformed data to the warehouse."""
    df.to_sql("daily_revenue", engine, if_exists="append", index=False)

# Pipeline execution: Extract -> Transform -> Load
engine = create_engine("postgresql://warehouse:5432/analytics")
raw = extract("s3://data-lake/sales/2026-04-13.csv")
cleaned = transform(raw)
load(cleaned, engine)

Yukarıdaki örnekte görülebileceği üzere, ham satış verileri öncelikle kaynak sistemden çekilir, ardından eksik değerler temizlenir, para birimi normalizasyonu yapılır ve günlük agregasyona dönüştürülür. Yalnızca bu işlemler tamamlandıktan sonra veri, ambarına yazılır. Bu yaklaşım, hedef sistemde yalnızca temiz ve tutarlı verilerin bulunmasını garanti eder.

ELT Yaklaşımında Bulut Veri Ambarlarının Gücünden Yararlanma

ELT paradigması, modern bulut veri ambarlarının muazzam işlem kapasitesini kullanarak dönüşüm mantığı için ayrı bir altyapı gereksinimine son verir. Snowflake, Google BigQuery, Amazon Redshift ve Databricks gibi platformlar, petabyte ölçeğinde veriyi saniyeler içinde işleyebilecek elastik compute kaynakları sunar. Bu mimaride ham veriler minimum işlemle doğrudan ambarına yüklenir ve tüm dönüşüm mantığı SQL veya DataFrame API kullanılarak ambar içinde çalıştırılır.

dbt (data build tool), ELT yaklaşımının fiili standardı haline gelmiştir. dbt, SQL tabanlı dönüşümlerin version control altında yönetilebilmesini, test edilmesini ve dokümante edilmesini sağlar.

-- models/daily_revenue.sql (dbt model)
-- Transforms raw sales data inside the warehouse

WITH raw_sales AS (
    SELECT
        sale_date,
        revenue,
        currency,
        exchange_rate
    FROM {{ source('raw', 'sales_events') }}
    WHERE revenue IS NOT NULL
),

normalized AS (
    SELECT
        sale_date,
        revenue * exchange_rate AS revenue_usd
    FROM raw_sales
)

SELECT
    sale_date,
    SUM(revenue_usd) AS total_revenue_usd,
    COUNT(*) AS transaction_count
FROM normalized
GROUP BY sale_date

Bu model, ham satış verilerini okur, null değerleri filtreler, döviz kurunu uygular ve günlük toplamlar üretir. Tüm bu işlemler veri ambarının kendi query engine tarafından gerçekleştirilir. dbt, bu modeli çalıştırdığında arka planda CREATE TABLE AS SELECT veya MERGE ifadeleri oluşturur.

Mimari Karşılaştırma ve Temel Farklılıklar

ETL ve ELT arasındaki mimari farklılıklar, sistem tasarımını ve operasyonel süreçleri derinden etkiler. Aşağıdaki tablo, her iki yaklaşımın temel boyutlarda karşılaştırılmasını sunmaktadır.

| Boyut | ETL | ELT | |-------|-----|-----| | Dönüşüm konumu | Ayrı bir staging sunucusu | Hedef veri ambarının içinde | | Depolanan veri | Yalnızca dönüştürülmüş veriler | Ham ve dönüştürülmüş veriler birlikte | | Depolama maliyet modeli | Daha düşük ambar depolaması | Daha yüksek ambar depolaması, ancak bulut depolama ucuz | | İşlem maliyet modeli | Özel ETL sunucusu (her zaman açık) | İsteğe bağlı ambar işlem gücü (sorgu başına ödeme) | | Şema esnekliği | Yüklemeden önce tanımlanmış şema | Schema-on-read, esnek iterasyon | | Yeniden işleme | Kaynaktan tekrar çekim gerektirir | Ham veriler üzerinde dönüşümleri yeniden çalıştırma | | Gecikme | Yüksek (dönüşüm darboğazı) | Düşük (önce yükle, sonra dönüştür) | | Veri tazeliği | Pipeline hızıyla sınırlı | Neredeyse gerçek zamanlı mümkün | | Uyumluluk | Ham veri ambara ulaşmaz | Ham veri ambarda saklanır (şifreleme/maskeleme gerekir) | | Tipik araçlar | Informatica, Talend, SSIS, özel scriptler | Fivetran + dbt, Airbyte + dbt, Stitch + dbt |

Bu karşılaştırmadan görüleceği üzere, her iki yaklaşımın kendine özgü avantajları vardır. Seçim, organizasyonun teknik yetkinlikleri, veri hacmi, düzenleyici gereksinimleri ve mevcut altyapı yatırımlarına göre şekillenmelidir.

ETL Yaklaşımının Uygun Olduğu Senaryolar

ETL, belirli koşullar altında ELT yaklaşımına göre belirgin üstünlükler sağlar.

Düzenleyici uyumluluk gereksinimleri: GDPR, HIPAA veya PCI-DSS gibi düzenlemeler, hassas verilerin belirli sınırlar dışına çıkarılmamasını veya yalnızca maskelenmiş şekilde saklanmasını zorunlu kılabilir. ETL mimarisinde bu kurallar dönüşüm aşamasında uygulanır ve hassas veriler hedef sisteme hiç ulaşmaz.

Sabit ve nadiren değişen şemalar: Dönüşüm mantığı önceden tanımlandığında ve iş gereksinimleri kararlı olduğunda, ETL pipeline'ları önceden optimize edilebilir ve deterministik çıktılar üretir.

Küçük ve orta ölçekli veri setleri: Günlük birkaç gigabyte verinin işlendiği senaryolarda, basit bir Python scripti veya Apache Spark pipeline'ı yeterli olur ve ELT için gerekli altyapı yatırımı anlamsızlaşır.

Ağ bant genişliği kısıtlamaları: Ham verilerin tamamını uzak bir bulut ambarına transfer etmek pratik olmayabilir. ETL, verileri kaynak yakınında filtreleyerek ve aggregate ederek transfer edilmesi gereken veri miktarını azaltır.

ELT Yaklaşımının Üstün Olduğu Senaryolar

ELT, modern veri platformlarında iyi nedenlerle baskın konuma gelmiştir. Veri pipeline araçları pazarının 2030 yılına kadar 48,3 milyar dolara ulaşması öngörülmekte olup, bulut dağıtımı pazar gelirinin %71'inden fazlasını oluşturmaktadır.

İteratif analitik: İş gereksinimleri sürekli evrildiğinde, analistlerin ve veri bilimcilerin ham verilere erişebilmesi kritik önem taşır. Yeni bir metrik hesaplamak veya farklı bir agregasyon seviyesi oluşturmak için kaynak sistemlerden yeniden veri çekilmesi gerekmez; mevcut ham veriler üzerinde yeni bir dbt modeli tanımlamak yeterlidir.

Yüksek hacimli veri ortamları: Modern bulut veri ambarları, massively parallel processing (MPP) mimarisi sayesinde petabyte ölçeğinde veriyi dakikalar içinde işleyebilir.

Çapraz kaynak birleştirme: Farklı kaynaklardan gelen ham veriler aynı ambarda toplandıktan sonra, SQL ile kolayca birleştirilir. Veri mühendisliği ekipleri feature store'ları doğrudan ham tablolardan oluşturabilir.

Makine öğrenmesi ve gelişmiş analitik: Özellik mühendisliği süreci, farklı veri formatları ve granülarite seviyelerini denemeyi gerektirir. ELT, bu deneysellik için ideal ortamı sağlar.

Modern ELT Stack Yapılandırması

Günümüzde ELT mimarileri genellikle üç katmanlı bir model üzerinde yapılandırılır: staging, intermediate ve marts. dbt bu katmanları tutarlı bir şekilde yönetmek için standart bir yapılandırma sunar.

# dbt_project.yml - Modern ELT project configuration
name: analytics_pipeline
version: "1.0.0"

models:
  analytics_pipeline:
    staging:             # 1:1 mappings from raw sources
      +materialized: view
      +schema: staging
    intermediate:        # Business logic, joins, calculations
      +materialized: ephemeral
    marts:               # Final tables consumed by BI tools
      +materialized: table
      +schema: analytics

Staging katmanı, kaynak sistemlerden gelen ham verilerin birebir eşleştirmelerini içerir. Bu modeller genellikle view olarak materialize edilir ve minimal dönüşüm uygular. Intermediate katmanı, iş mantığı içeren dönüşümleri, joinleri ve hesaplamaları barındırır. Marts katmanı, son kullanıcıların ve BI araçlarının tüketeceği final tabloları içerir ve tablo olarak materialize edilir.

Hibrit Pipeline Tasarımı

Gerçek dünya uygulamalarında saf ETL veya saf ELT nadir görülür. Çoğu organizasyon, her iki yaklaşımın avantajlarını birleştiren hibrit pipeline'lar tasarlar. Tipik bir hibrit mimaride, extraction aşamasında minimal dönüşüm (PII maskeleme, format standardizasyonu) uygulanır ve ağır dönüşüm mantığı veri ambarına bırakılır.

# hybrid_pipeline.py
# Light ETL at extraction + heavy ELT in warehouse

def extract_and_mask(source: str) -> pd.DataFrame:
    """Extract with minimal transformation: PII masking only."""
    df = pd.read_json(source)
    # Mask email addresses before loading
    df["email"] = df["email"].apply(lambda e: hash_pii(e))
    # Remove raw IP addresses
    df.drop(columns=["ip_address"], inplace=True)
    return df

def load_raw(df: pd.DataFrame, warehouse) -> None:
    """Load masked but otherwise raw data to warehouse."""
    df.to_sql("raw_user_events", warehouse, if_exists="append", index=False)

# Heavy transformations happen in dbt inside the warehouse
# See: models/marts/user_engagement.sql

Bu yaklaşımda e-posta adresleri ve IP adresleri gibi hassas bilgiler daha ambara ulaşmadan maskelenir veya çıkarılır. Ancak verilerin geri kalanı ham haliyle yüklenir ve iş mantığı dbt modelleri içinde uygulanır. Bu denge, düzenleyici uyumluluğun sağlandığı ve analitik esnekliğin korunabildiği bir mimari oluşturur.

Performans ve Maliyet Dengeleri

ETL ve ELT seçimi doğrudan operasyonel maliyetleri etkiler. Her iki yaklaşımın maliyet yapısı temelden farklıdır ve doğru analiz edilmelidir.

| Metrik | ETL (EC2 + RDS) | ELT (Fivetran + Snowflake + dbt) | |--------|-----------------|----------------------------------| | Aylık ingestion (1TB/gün) | $2,400 (c5.4xlarge) | $1,800 (Fivetran kullanım bazlı) | | Dönüşüm işlem gücü | $2,400 (özel sunucu) | $600-1,200 (Snowflake isteğe bağlı) | | Depolama (ham + dönüştürülmüş) | $200 (EBS) | $460 (Snowflake depolama) | | Mühendislik bakımı | 40+ saat/ay | 5-10 saat/ay | | Toplam aylık maliyet | ~$5,000 + mühendislik zamanı | ~$3,000-3,500 + minimal mühendislik |

Mühendislik bakımı farkı en kritik faktördür. Özel ETL pipeline'ları kaynak şemaları değiştiğinde, API rate limitleri kaydığında veya veri hacimleri ani artış gösterdiğinde bozulur. Yönetilen ELT platformları bu değişiklikleri otomatik olarak ele alır.

Veri Kalitesi ve Test Stratejileri

Veri kalitesi, hem ETL hem de ELT pipeline'larında kritik öneme sahiptir. ELT yaklaşımında dbt, yerleşik test framework'ü ile veri kalitesini garantilemeyi kolaylaştırır.

# models/staging/stg_orders.yml
version: 2

models:
  - name: stg_orders
    description: "Cleaned orders from raw source"
    columns:
      - name: order_id
        tests:
          - unique           # No duplicate orders
          - not_null         # Every row has an ID
      - name: order_total
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: 0   # No negative totals
              max_value: 100000
      - name: customer_id
        tests:
          - not_null
          - relationships:   # Foreign key integrity
              to: ref('stg_customers')
              field: customer_id

Bu yapılandırmada order_id kolonunun benzersiz ve boş olmadığı, order_total değerinin 0 ile 100000 arasında olduğu ve customer_id değerinin müşteriler tablosunda mevcut olduğu test edilir. dbt run sonrasında dbt test komutu çalıştırılarak bu kuralların ihlal edilip edilmediği kontrol edilir.

Gerçek Zamanlı Veri İşleme Gereksinimleri

Batch işlem gereksinimlerinin ötesinde, gerçek zamanlı veya yakın gerçek zamanlı senaryolarda ETL ve ELT değerlendirmesi farklı dinamikler içerir. Streaming veri kaynaklarından (Kafka, Kinesis, Pub/Sub) gelen olaylar için genellikle stream processing framework'leri (Apache Flink, Spark Streaming, Kafka Streams) kullanılır.

Bu framework'ler teknik olarak ETL kategorisine girer: veriler alınır, stream üzerinde dönüşüm uygulanır ve hedefe yazılır. Ancak modern streaming veri ambarları (Snowflake Snowpipe, BigQuery streaming inserts, Databricks Delta Live Tables) ELT benzeri bir deneyim sunmaya başlamıştır.

Latency gereksinimleri saniye altındaysa, dedicated stream processing zorunludur. Dakika veya saat seviyesinde freshness yeterliyse, micro-batch ELT yaklaşımları daha basit ve ekonomik bir çözüm sunar.

Sonuç

ETL ve ELT arasındaki seçim, teknik bir karar olmanın ötesinde stratejik bir mimari tercihtir. Doğru kararı verebilmek için organizasyonun mevcut durumu ve gelecek hedefleri dikkate alınmalıdır.

• ETL, düzenleyici gereksinimler, sabit şemalar ve küçük veri hacimleri için uygundur
• ELT, bulut tabanlı ambarlar, iteratif analitik ve yüksek hacimli veriler için idealdir
• Hibrit yaklaşımlar, her iki paradigmanın avantajlarını birleştirerek esneklik sağlar
• dbt'nin test framework'ü, ELT'nin ham veri yükleme nedeniyle yarattığı kalite açığını kapatır
• Maliyet analizi, yalnızca altyapı değil işçilik ve bakım maliyetlerini de içermelidir
• Batch ELT çoğu analitik kullanım senaryosunu karşılar; streaming'i dolandırıcılık tespiti, operasyonel uyarılar ve saniye altı gecikme gereksinimleri için saklayın
• Modern ELT stack'leri (dbt, Fivetran, Snowflake) geliştirici verimliliğini önemli ölçüde artırır
• Karar, sektör trendlerine değil kısıtlamalara (uyumluluk, veri hacmi, ekip büyüklüğü, mevcut altyapı) dayanmalıdır