ETL ELT farkı tek bir soruya dayanır: veri nerede dönüştürülür? ETL'de (çıkar, dönüştür, yükle) veri ambara girmeden önce ayrı bir sunucuda temizlenir ve yalnızca işlenmiş hali yüklenir. ELT'de (çıkar, yükle, dönüştür) ham veri önce ambara yüklenir, dönüşüm ambarın kendi işlem gücüyle yapılır. Seçimi altyapı, veri hacmi, kişisel veri kuralları ve ekip yetkinliği belirler.
Aynı veri, iki farklı boru hattı
Veri ambarı projelerinde bu soru çoğu zaman ilk teknik toplantıda gündeme gelir. Tedarikçilerden biri ETL aracı önerir, diğeri "artık herkes ELT yapıyor" der, iç ekip ise mevcut SQL betiklerini korumak ister. Karar çoğu zaman gerekçesiz verilir ve sonradan pahalıya düzeltilir.
Veri ambarının ne olduğunu, katmanlarını ve kurulum adımlarını veri ambarı ve ETL rehberimizde anlattık. Bu yazı tek bir karara odaklanıyor: veriyi yüklemeden önce mi, sonra mı dönüştürmelisiniz? Cevap, raporlama hızından KVKK uyumuna kadar birçok şeyi etkiler.
Sorunun özü şu: ERP, CRM, e-ticaret ve üretim sistemlerinden gelen veri ham haliyle rapora uygun değildir. Kodlar farklıdır, mükerrer kayıtlar vardır, tarih biçimleri uyuşmaz. Bu temizliğin bir yerde yapılması gerekir; ETL ile ELT, o yerin neresi olacağına verilen iki farklı cevaptır.
Yanlış seçimin maliyeti
Türkiye'de veri toplamak ile veriden karar üretmek arasında hâlâ büyük bir boşluk var:
TÜİK'e göre 2025'te 10 ve daha fazla çalışanı olan girişimlerin %28,3'ü ERP kullanırken iş zekası (BI) yazılımı kullananların oranı yalnızca %6,5 oldu. (TÜİK Girişimlerde Bilişim Teknolojileri Kullanım Araştırması 2025)
Bu boşluğu kapatmak için kurulan veri hattı yanlış tasarlanırsa, sorun yalnızca taşınmış olur. Kötü kurgulanmış bir ETL, kaynakta değişen bir alan adıyla sessizce durur; kötü yönetilen bir ELT ise ambarı kimsenin sahiplenmediği ham tablolarla doldurur. Her iki durumda da raporlar eski ya da hatalı veriyle beslenir.
Veri kalitesi uzmanı Thomas C. Redman, kötü verinin çoğu şirkete maliyetini gelirin %15-25'i olarak tahmin ediyor (MIT Sloan Management Review, "Seizing Opportunity in Data Quality", 2017).
Yetkinlik tarafı da seçimi doğrudan etkiler. TÜİK'e göre 2026'da girişimlerin yalnızca %15,2'si BİT uzmanı istihdam ediyor ve uzman arayanların %31,7'si işe alımda güçlük yaşadı (TÜİK Girişimlerde Bilişim Teknolojileri Kullanım Araştırması 2026). Bakımını yapacak kimsenin olmadığı bir mimari, kâğıt üzerinde ne kadar modern olursa olsun doğru seçim değildir.
ETL ELT farkı: adım adım karşılaştırma
İki yaklaşımda da aynı üç iş yapılır: veri kaynaktan çekilir, iş kurallarına göre dönüştürülür ve hedefe yüklenir. Fark, sıralamada ve dönüşümü yapan motordadır. ETL'de dönüşüm ayrı bir entegrasyon sunucusunda ya da araçta çalışır; ELT'de ambarın SQL motoru bu işi üstlenir.
| Ölçüt | ETL | ELT |
|---|---|---|
| Dönüşümün yapıldığı yer | Ambar dışında, entegrasyon sunucusunda | Ambarın içinde, SQL ile |
| Ambara giren veri | Temizlenmiş, modellenmiş veri | Önce ham veri, sonra işlenmiş katmanlar |
| Tipik altyapı | Şirket içi (on-premise) veritabanları | Bulut ya da ölçeklenebilir ambarlar |
| Yeni rapor ihtiyacı | Dönüşüm kuralı değişir, yeniden çekim gerekebilir | Ham veri zaten ambarda, yeniden işlenir |
| Kişisel veri | Maskeleme yükleme öncesinde yapılabilir | Ham veri ambara girer, erişim kontrolü şart |
| Maliyeti belirleyen etken | Entegrasyon sunucusu ve araç lisansı | Ambarın işlem gücü ve depolama kullanımı |
| Gereken yetkinlik | Araç bilgisi, akış tasarımı | Güçlü SQL, sürüm kontrolü, test disiplini |
| Hata ayıklama | Hata akışın içinde, araç günlüklerinde | Her adım ambarda tablo olarak izlenebilir |
Tablo bir kazanan ilan etmiyor. ELT'nin esnekliği ambarın işlem gücüne, ETL'nin kontrolü ise ek bir sunucuya ve araca bağlıdır. Bulut ambarlarında işlem gücü kullanıma göre faturalandığı için, ELT'de kötü yazılmış bir dönüşüm sorgusu doğrudan maliyete yansır; ambarın maliyet kalemlerini veri ambarı maliyeti yazımızda ayrıntılı ele aldık.
Hangi durumda ETL, hangi durumda ELT? Karar için 7 soru
Aşağıdaki soruları sırayla yanıtlamak, kararın gerekçesini yazılı hale getirir. Yanıtların çoğu bir tarafı işaret ediyorsa seçim nettir; dağınıksa karma mimari düşünülmelidir.
- Ambarınız nerede duracak? Şirket içi bir MSSQL ya da PostgreSQL sunucusunun işlem gücü sınırlıdır; ağır dönüşümleri ayrı bir katmanda yapmak (ETL) canlı raporları korur. Ölçeklenebilir bir bulut ambarında ise dönüşümü ambara bırakmak (ELT) doğaldır.
- Veri hacmi ve çeşitliliği ne kadar? Birkaç ERP tablosu ve günlük toplu aktarım için ETL yeterlidir. Sensör, log ve pazaryeri verisi gibi hacimli ve biçimi değişken kaynaklar ELT'nin "önce yükle, sonra karar ver" yaklaşımına daha uygundur; bu tür verinin ambara mı göle mi gideceğini veri gölü ve veri ambarı karşılaştırmamızda ele aldık.
- Ham veriye sonradan ihtiyaç duyacak mısınız? Yeni bir soru geldiğinde geçmiş veriyi farklı bir kuralla yeniden işlemek istiyorsanız, ham verinin ambarda durması büyük avantajdır. ETL'de bu, kaynaktan yeniden çekim anlamına gelir; kaynak geçmişi tutmuyorsa imkânsız olabilir.
- Kişisel veri ve yurt dışı aktarım kısıtı var mı? Ham müşteri ya da personel verisinin ambara hiç girmemesi gerekiyorsa, maskelemeyi yüklemeden önce yapan ETL daha güvenli bir başlangıçtır. Bu konuya aşağıda ayrıca değiniyoruz.
- Ekibiniz hangi dilde güçlü? SQL'e hâkim bir ekip ELT'de dönüşümleri okunur, test edilir ve sürümlenir biçimde yazabilir. Görsel araçlarla çalışmaya alışmış bir ekip için ETL aracı öğrenme yükünü azaltır.
- Veri ne kadar güncel olmalı? Dakikalık stok ya da sipariş verisi için asıl soru ETL/ELT'den çok, değişen kayıtların nasıl yakalandığıdır (CDC). Hangi kararın anlık veri istediğini gerçek zamanlı raporlama yazımızda tartıştık.
- Kaynaklara nasıl erişiyorsunuz? Doğrudan veritabanı bağlantısı mı, yoksa sayfalı ve hız sınırlı bir API mi? API kaynaklarında çekim katmanı her iki yaklaşımda da ayrı tasarlanır; API entegrasyonu yazımızda bu katmanın temel kurallarını anlattık.
Karma mimari: çoğu şirketin gerçek cevabı
Pratikte ETL ve ELT birbirini dışlamaz. Sık gördüğümüz düzen şöyledir: kişisel veri içeren alanlar yükleme öncesinde maskelenir ya da ayıklanır (hafif bir ETL adımı), geri kalan veri ham haliyle ambara alınır ve iş kuralları ambarın içinde katman katman uygulanır (ELT). Böylece hem kontrol hem esneklik korunur.
Ambarın içinde üç katman ayırmak işi kolaylaştırır. Ham katman kaynağın birebir kopyasıdır ve kimse ondan rapor almaz. Temiz katmanda kodlar eşlenir, mükerrer kayıtlar ayıklanır, tarih ve para birimi biçimleri birleştirilir; mükerrer cari ve ürün kayıtlarının nasıl yakalandığını veri kalitesi ve mükerrer kayıt yazımızda anlattık. İş katmanında ise yönetici panellerinin doğrudan okuduğu olgu ve boyut tabloları durur.
Hangi yaklaşım seçilirse seçilsin, iki kural değişmez. Birincisi, her dönüşüm kuralının bir sahibi olmalıdır; "net satış" tanımını kimin değiştirebileceği veri yönetişimi sorusudur, teknik değil. İkincisi, başarısız bir yükleme sessiz kalmamalıdır: izlenmeyen bir hat, yöneticiye dünkü değil geçen haftanın rakamını gösterir.
KVKK ve ham veri: ELT'nin gözden kaçan tarafı
ELT'nin esnekliği, ham verinin tamamını ambara taşımaktan gelir. Bu ham veride T.C. kimlik numarası, telefon, adres ya da maaş bilgisi varsa, ambar 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) kapsamında yeni bir işleme ortamı haline gelir. Erişim yetkileri, maskeleme ve saklama süreleri kaynak sistemdekinden daha dikkatli kurulmalıdır, çünkü ambar birçok sistemin verisini tek noktada birleştirir.
Ambar yurt dışındaki bir bulut bölgesinde çalışıyorsa, konu yurt dışına aktarım hükümlerine de girer. Haziran 2024'ten bu yana aktarım için yeterlilik kararı ya da standart sözleşme gibi uygun bir güvence gerekir; standart sözleşme imzadan itibaren beş iş günü içinde Kuruma bildirilmelidir. KVKK'ya 2025 yılında 2.497 standart sözleşme bildirildi ve Kurum bunlardan 70'i hakkında resen inceleme başlattı (Kişisel Verileri Koruma Kurumu 2025 Yılı Faaliyet Raporu). Sözleşme ve bildirim adımlarını KVKK yurt dışına veri aktarımı rehberimizde anlattık.
Pratik çözüm çoğu zaman yukarıdaki karma düzendir. Rapor için gerekmeyen kişisel alanlar hiç çekilmez, gerekenler yükleme öncesinde takma adla değiştirilir ve ham katmana erişim yalnızca veri ekibine açılır.
Digital Bridge'de bu işi nasıl yapıyoruz
ETL ya da ELT kararını araç tercihinden değil, sizin kaynaklarınızdan ve sorularınızdan başlatıyoruz. Veri ambarı ve ETL entegrasyonu projelerimizde izlediğimiz yol şöyledir:
- Keşif ve ihtiyaç analizi. Hangi raporların hangi sistemlerden beslendiğini, veri hacmini, güncellik ihtiyacını ve kişisel veri alanlarını birlikte haritalıyoruz. Yedi sorunun cevabı bu aşamada yazılı hale geliyor.
- Mimari kararı. Ambarın şirket içinde mi bulutta mı duracağını, maliyet ve veri yerleşimi boyutlarıyla bulut geçiş ve altyapı danışmanlığı kapsamında değerlendiriyoruz; ETL, ELT ya da karma düzen bu karardan doğuyor.
- Kaynak bağlantıları. ERP, CRM, e-ticaret ve pazaryeri kaynaklarından veriyi veritabanı bağlantısı, CDC ya da API entegrasyonu ile, canlı sistemleri yormadan çekiyoruz.
- Kalite kuralları ve sahiplik. Dönüşüm kurallarını, kontrol noktalarını ve tanımların sahiplerini veri yönetişimi ve kalite çalışmasıyla birlikte belirliyoruz; hatalı kayıt rapora girmeden ayrılıyor.
- KVKK tasarımı. Maskeleme, yetkilendirme ve saklama sürelerini KVKK uyum danışmanlığı ekibimizle birlikte hattın içine yerleştiriyoruz.
- Pilot ve genişleme. Önce satış ya da finans gibi tek bir alanı uçtan uca kuruyor, yükleme sürelerini ve rapor doğruluğunu ölçüyor, ardından diğer kaynaklara geçiyoruz.
Hazır paket satmıyoruz; ihtiyaç analizinden sonra kapsamı ve aşamaları içeren yazılı bir teklif hazırlıyoruz. Komşu başlıklar için Veri ve Analitik yazılarımızın tamamına göz atabilirsiniz.
Sonraki adım
Önce üç şeyi not edin: raporlarınızın beslendiği sistemlerin listesi, ambarın nerede duracağına dair ön tercihiniz ve ham veride bulunan kişisel veri alanları. Bu üç liste, ETL mi ELT mi sorusunun büyük kısmını kendiliğinden cevaplar. Bizimle iletişime geçin; listeleri birlikte gözden geçirip ilk veri alanı için uygun mimariyi çıkaralım.