ETL ve ELT: Pipeline Diyagramları, Ödünleşimler ve Hangisi Ne Zaman Kullanılır

Finans ekibi son iki yılın gelirini indirim koduna göre istiyor. Bir şirkette bu, küçük bir SQL değişikliği ve tabloların yeniden oluşturulmasından ibarettir, çünkü bugüne kadar yüklenmiş her sipariş satırı hâlâ ham bir tabloda durur. Bir başkasında ise gecelik iş indirim sütununu hiç saklamamıştır; bu yüzden biri işi değiştirir ve iki yıllık geçmişi üretim ortamından yeniden çeker.

Fark, dönüşümün nerede çalıştığındadır. ETL (extract, transform, load; yani çıkarma, dönüştürme, yükleme), veriyi veri ambarına ulaşmadan önce ayrı bir motorda şekillendirir. ELT (extract, load, transform) ise ham veriyi veri ambarına kopyalar ve orada SQL ile şekillendirir. Bu seçim hesaplama faturanızı, verinin ne kadar taze olduğunu, iş mantığının ne kadar kolay değiştiğini ve kişisel verinin nereye ulaştığını belirler.

Bu yazı iki pipeline'ı adım adım anlatıyor, karşılaştırıyor, ETL'nin hâlâ üstün geldiği durumları ve yaygın hibrit yaklaşımı gösteriyor, sonunda da ikisini yan yana koyan bir diyagram sunuyor.

ETL pipeline'ı nasıl çalışır

ETL'de kaynaklar ile veri ambarı arasında bir dönüşüm motoru bulunur. Gecelik bir çalıştırma şöyle ilerler:

1. Çıkarma. Yeni ve değişen satırlar, updated_at sütunu üzerinde bir sorguyla ya da bir change data capture akışından alınır.
2. Dönüştürme. Motor değerleri temizler, tekrarları ayıklar, referans verileriyle join yapar, kişisel veriyi maskeler ve sonucu olgu (fact) ve boyut (dimension) tablolarına dönüştürür.
3. Yükleme. Sonuç, insert ya da merge işlemleriyle veri ambarına yüklenir.

Motor; Informatica, SQL Server Integration Services (SSIS), bir Spark işi ya da bir Python betiği olabilir. Çıkarılan ham veriler çoğu zaman, işin başarılı bir çalıştırmadan sonra temizlediği bir staging alanında bekler; bu yüzden veri ambarı, işin öngörmediği bir soruyu yanıtlayamaz.

ELT pipeline'ı nasıl çalışır

ELT'de dönüşüm işini veri ambarı üstlenir:

1. Çıkarma ve yükleme. Fivetran ya da Airbyte gibi bir yükleyici, kaynak tabloları neredeyse hiç değiştirmeden bir raw şemasına kopyalar ve her satırın ne zaman senkronize edildiğini kaydeden _fivetran_synced ya da _airbyte_extracted_at gibi meta veri sütunları ekler.
2. Dönüştürme. Genellikle dbt ile yönetilen SQL modelleri ham tabloları okur ve başka şemalarda temizlenmiş ve birleştirilmiş tablolar oluşturur.
3. Sunma. BI araçları, genellikle mart (data mart) olarak adlandırılan son tabloları sorgular.

ELT, BigQuery ve Snowflake gibi depolamayı hesaplamadan ayıran bulut veri ambarlarıyla yaygınlaştı: Ham kopyaları saklamak ucuzdur ve dönüşüm kapasitesi ambarla birlikte ölçeklenir. Yüklenen her satır saklandığı için kaynağa dokunmadan bir modeli düzeltebilir, bir sütun ekleyebilir ya da yeni bir metrik tanımlayıp her şeyi geçmiş veriden yeniden oluşturabilirsiniz.

ETL ve ELT karşılaştırması

Takvimler kısaltmadan daha önemlidir: Fivetran'ın varsayılan senkronizasyonu altı saatte bir çalışır; bu, saatlik bir ETL işinden daha bayat veri demektir.

ETL'nin hâlâ öne çıktığı durumlar

• Kişisel veri ambara ham hâlde inmemeli. Düz metin e-posta adresleri ya da kart numaraları veri ambarına asla ulaşmamalıysa, bunları yüklemeden önce maskeleyin. Ambarın maskeleme politikaları saklanan veriyi değiştirmez: Snowflake'te bir Enterprise Edition özelliği olan Dynamic Data Masking, düz metin değerleri sorgu anında maskeler.
• Hedef dönüşüm yapamıyor. Sabit kapasiteli eski bir veri ambarı, bir arama indeksi ya da bir iş ortağının dosya bırakma alanı son hâline getirilmiş veri bekler.
• SQL'in iyi beceremediği zenginleştirmeler, örneğin satır başına API çağrıları, coğrafi kodlama, PDF ayrıştırma ya da model skorlama, çoğu zaman Python ya da Spark'ta daha iyi oturur.
• Düşük gecikme gerektiren akış işleme. Apache Flink ya da Kafka Streams olayları gerçekleştikten saniyeler sonra dönüştürür; Kafka mimari diyagramı bunların nereden okuduğunu gösteriyor.
• Saklamak istemediğiniz hacim. Saniyede bir ölçüm yapan 10.000 sensör günde 864 milyon satır üretir (10.000 × 86.400). Yüklemeden önce hesaplanan dakikalık ortalamalar bunu 14,4 milyona (10.000 × 1.440), yani 60 kat aşağıya indirir.

Yaygın hibrit yaklaşım

Pratikte pek çok ELT pipeline'ı, yüklemeden önce küçük bir dönüşüm içerir; bu bazen EtLT diye yazılır. Aktarım sırasında yalnızca asla ham hâlde ulaşmaması gereken veriyi dönüştürün; geri kalan her şeyi, sürümlendiği, test edildiği ve kolayca yeniden oluşturulabildiği veri ambarında yapın.

Kişisel veri için Fivetran'ın sütun hash'leme özelliği, bir sütunu senkronizasyon sırasında SHA-256 ve her hedefe özel bir salt ile hash'ler; böylece hash'lenmiş e-postalarla join yapmak hâlâ mümkündür. Veri engelleme (data blocking) ise bir sütunu tamamen dışarıda bırakır. Airbyte'ta mapping'ler alanları stream bazında hash'leyebilir ya da şifreleyebilir. Araç hangisi olursa olsun salt'lı bir hash tercih edin: Bir e-postanın düz SHA-256 hash'i, bilinen adreslerden oluşan bir listeyle eşleştirilebilir. İki uyarı daha: Hash'leme gelecekteki senkronizasyonları kapsar, dolayısıyla geçmiş veri yeniden senkronizasyon gerektirir; salt'lı bir hash de anonimleştirme değil, takma adlandırmadır (pseudonymization). GDPR kapsamında takma adlandırılmış veri hâlâ kişisel veridir (26. Gerekçe). Bu yazı hukuki tavsiye değildir; resmî metni gizlilik ekibinizle birlikte okuyun ve kişisel verinin nereye aktığını gösteren bir veri haritası tutun.

Katmanlı SQL modelleriyle ELT

dbt'nin proje yapısı rehberi, herhangi bir SQL aracıyla da işe yarayan üç katman tanımlar:

Lakehouse'lar aynı fikri bronz, gümüş ve altın adlarıyla kullanır; medallion mimari diyagramına bakın.

dbt dört genel (generic) veri testiyle gelir: unique, not_null, accepted_values ve relationships. Ayrıca hatalı satırları döndüren her sorgu bir teste dönüşebilir. Tazelik kontrolleri, sessizce durmuş bir yükleyiciyi yakalar. Tek bir kaynak tanımı ikisini birden bildirir:

sources:
  - name: shop
    schema: raw_shop
    config:
      loaded_at_field: _fivetran_synced
      freshness:
        warn_after: {count: 12, period: hour}
        error_after: {count: 24, period: hour}
    tables:
      - name: orders
        columns:
          - name: id
            data_tests:
              - unique
              - not_null

dbt source freshness (dbt v2'de dbt freshness), en yeni _fivetran_synced değeri 12 saatten eskiyse uyarı verir, 24 saati geçince de hata bildirir.

Orkestrasyon ve veri kalitesi

Bir orkestratör adımları sırayla çalıştırır. Airflow'da bir DAG (bağımlılıkları ve bir zamanlaması olan görevler) yükleyicinin senkronizasyonunu tetikler, bitmesini bekler, ardından dbt'yi çalıştırır. Dagster'ın dbt entegrasyonu her dbt modelini bir asset'e, yani var olması gereken bir tabloya dönüştürür; böylece bir mart, bir Fivetran senkronizasyonunun yazdığı tabloya doğrudan bağımlı olabilir.

Her iki durumda da dbt build hatalı veriyi panolardan uzak tutar: Modelleri, testleri, snapshot'ları ve seed'leri DAG sırasıyla çalıştırır ve başarısız bir test, aşağı akıştaki her şeyin atlanmasına yol açar. Tazelik kontrollerini ve sorumlu ekibe giden bir alarmı ekleyin; böylece hem yanlış hem de eski veri, bir paydaş fark etmeden önce ortaya çıkar.

Airbyte'ın data activation (veri aktivasyonu) dediği Reverse ETL ters yönde çalışır: Modellenmiş veriyi veri ambarından CRM ya da destek masası gibi araçlara kopyalar. Bu yazının yazıldığı tarihte (Kasım 2026) Hightouch bunu bağımsız bir ürün olarak sunuyor; Fivetran (Census'ı satın alan şirket) ve Airbyte ise veri alımıyla (ingestion) birlikte paketliyor.

ETL ve ELT diyagramı

Nasıl okunur:

• İki kulvar, aynı uçlar: Aynı Postgres sipariş veritabanı ve aynı BI panoları. Yalnızca orta kısım değişir.
• Kehribar rengi dönüşümü işaretler: ETL'de veri ambarından önceki ayrı motor, ELT'de ambarın içindeki dbt modelleri kutusu.
• Veri ambarı çerçeveleri neyin saklandığını gösterir. ETL'ninki yalnızca fct_orders tablosunu tutar; ELT'ninki yüklendiği hâliyle raw.orders tablosunu, modelleri ve marts.fct_orders tablosunu tutar.
• Mor bağlantı hibrit yaklaşımı gösterir: Yükleyici, satırlar ambara ulaşmadan önce kişisel veriyi hash'ler.
• Markdown bloğu ELT'nin çalışma sırasını, tazelik eşiklerini ve BI araçlarının hangi şemayı okuduğunu listeler.

ETL ve ELT diyagramlarını net çizmek

• Dönüşümü çalıştığı yere koyun. ELT'nin dönüşümünü veri ambarının dışında çizmek, asıl maliyetini ve riskini gizler.
• Veri ambarını bir sınır olarak çizin. Tek bir çerçevenin içindeki raw, staging ve marts, ayrı veritabanları değil, tek bir sistemdeki şemalardır.
• Bağlantıları taşınan şeyle etiketleyin (ham satırlar, hash'lenmiş satırlar, oluşturulmuş tablolar); önemliyse zamanlamayı da yazın.
• Kişisel verinin nerede maskelendiğini ve nerede hâlâ düz metin olarak bulunduğunu işaretleyin.
• Her modeli değil, katmanları gösterin. Katman başına bir örnek tablo yeterlidir; veri soyu (lineage) dbt'nin ürettiği dokümantasyonda yer almalıdır.
• Kontrol akışını ayrı tutun. Orkestratör tetiklemelerini kesikli bağlantılarla çizin ki kimse onları veri sanmasın.

Veri pipeline'ı mimari diyagramı, CDC, Kafka ve bir veri ambarı içeren eksiksiz bir pipeline gösteriyor.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. ETL ve ELT kulvarları için Temel paketinden, biri diğerinin üstünde olacak şekilde iki Çerçeve node'u ekleyin; her kulvara da veri ambarı için aynı yatay konumda iç içe bir Çerçeve yerleştirin.
3. ETL kulvarına Veri paketinden bir Postgres node'u, dönüşüm motoru için bir Temel Kutu, ambar çerçevesinin içine fct_orders için Veri paketinden bir Veri ambarı node'u ve BI için bir Temel Kutu ekleyin. Bağlantıları “raw rows”, “cleaned and conformed rows” ve “SQL queries” olarak etiketleyin.
4. ELT kulvarına bir Postgres node'u ve yükleyici için bir Temel Kutu ekleyin. Ambar çerçevesinin içine raw.orders ve marts.fct_orders için Veri ambarı node'ları, aralarına da dbt modelleri için bir Temel Kutu ekleyin. Son olarak BI için bir Temel Kutu ekleyin ve bağlantıları aynı şekilde etiketleyin.
5. İki dönüşüm kutusunu kehribar rengine, yükleyiciden çıkan bağlantıyı mora boyayın. Açıklama gerektiren node'ların altına Temel Metin notları, bir de kısa bir renk göstergesi ekleyin.
6. Çalışma sırası ve tazelik eşikleriyle Temel paketinden bir Markdown bloğu ekleyin.

Pipeline zaten bir Mermaid akış şeması olarak varsa, ilk taslak için onu Mermaid akış şemasından düzenlenebilir diyagrama aracına yapıştırın. Örnek 15 diagram node kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

ETL ile ELT arasındaki fark nedir? Dönüşümün çalıştığı yer. ETL veriyi ayrı bir motorda dönüştürür ve yalnızca sonucu yükler. ELT ise ham veriyi önce veri ambarına yükler ve orada SQL ile dönüştürür; böylece ham kopya yeniden oluşturmalar için elinizin altında kalır.

ETL'nin modası geçti mi? Hayır. Bulut veri ambarlarında olağan varsayılan ELT'dir; ancak kişisel verinin ambara ulaşmadan önce maskelenmesi gerektiğinde, hedef dönüşüm yapamadığında ve ağır zenginleştirme ya da düşük gecikmeli akış işleme için ETL hâlâ uygundur.

dbt bir ETL aracı mı? dbt, ELT'deki T'yi üstlenir. SQL modellerini ve testleri veri ambarınızın içinde çalıştırır ama veri çıkarmaz ya da yüklemez; bunu Fivetran ya da Airbyte gibi bir yükleyici yapar.

ELT, ETL'den daha ucuz mu? Hacme ve alışkanlıklara bağlıdır. ELT ayrı motoru ortadan kaldırır ama her model çalıştırmasını ambar hesaplaması olarak faturalandırır ve ham kopyaları saklar. Artımlı modeller maliyeti düşük tutar; büyük tabloları her saat baştan oluşturmak ise tutmaz.

Reverse ETL nedir? Modellenmiş verinin veri ambarından CRM gibi operasyonel araçlara kopyalanmasıdır. Veriyi mart'lardan okumalı, bir zamanlamaya göre çalışmalı ve diğer her pipeline gibi aynı testlere ve sahipliğe tabi olmalıdır.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.