Büyük Veri Hattı (ETL ve ELT) Nedir?

Kurumsal bir organizasyonda her saniye onlarca farklı kaynaktan veri üretilir: e-ticaret siparişlerinin tutulduğu PostgreSQL veritabanları, mobil uygulama tıklama olayları (clickstream), CRM sistemleri (Salesforce, HubSpot), ödeme geçitleri (Stripe, iyzico), ERP yazılımları ve IoT sensörleri. Ancak bu verilerin üretildiği operasyonel sistemler üzerinde doğrudan ağır analitik raporlar veya yapay zeka modelleri çalıştırmaya kalktığınızda, üretim veritabanınızın kilitlendiğini ve müşterilerinizin sipariş veremediğini görürsünüz. İşte farklı formatlardaki bu dağınık, ham ve gürültülü verileri kaynak sistemlerden yormadan çekip, temizleyip, birleştirerek karar destek sistemlerine ve makine öğrenmesi modellerine hazır hale getiren otoyollara Büyük Veri Hattı (Data Pipeline); bu mimariyi inşa eden disipline ise Veri Mühendisliği (Data Engineering) adı verilir.

Son on yılda bulut bilişim maliyetlerinin düşmesi ve depolama ile işlem gücünün (storage & compute) birbirinden ayrılmasıyla birlikte, veri mühendisliği dünyası geleneksel ETL (Extract, Transform, Load) mimarisinden bulut-yerel ELT (Extract, Load, Transform) ve Data Lakehouse (Veri Gölü Ambarı) paradigmasına doğru devasa bir dönüşüm geçirmiştir. Modern uygulama ve yazılım ekosistemlerinde bir veri hattının nasıl tasarlandığını anlamak; yazılım mimarları, veri bilimciler ve teknoloji yöneticileri için kritik bir yetkinliktir. Bu kapsamlı rehberde; OLTP ve OLAP ayrımından başlayarak ETL ve ELT farklarını, Debezium ve Kafka ile Gerçek Zamanlı Değişiklik Yakalama (CDC) mimarisini, Apache Airflow ve dbt (data build tool) kullanımını ve Apache Iceberg tabanlı Lakehouse devrimini tüm teknik detaylarıyla inceliyoruz.

1. Neden Ayrı Bir Veri Hattına İhtiyaç Duyulur? OLTP ve OLAP Ayrımı

Birçok yazılım geliştiricinin aklına ilk etapta şu soru gelir: "Zaten tüm verilerimiz üretimdeki PostgreSQL veya MySQL veritabanında duruyor; neden BI (İş Zekası) aracını doğrudan üretim veritabanına bağlamıyoruz?" Bu sorunun yanıtı, veritabanı motorlarının disk üzerindeki veri diziliminde, yani OLTP (Online Transaction Processing) ile OLAP (Online Analytical Processing) arasındaki temel mimari farkta yatar:

• OLTP (Çevrimiçi İşlem İşleme - Satır Tabanlı / Row-Oriented): PostgreSQL, MySQL, Oracle ve SQL Server gibi operasyonel veritabanlarıdır. Disk üzerinde bir satırın tüm sütunlarını (id, ad, soyad, adres, bakiye, tarih) yan yana yazarlar. Bir kullanıcının profilini getirmek (SELECT * FROM users WHERE id = 42) veya yeni bir sipariş eklemek (INSERT) için mükemmeldirler; milisaniyeler içinde yanıt verirler. Ancak "Son 3 yıldaki 500 milyon siparişin toplam ciro ortalamasını hesapla" dediğinizde, sadece tutar sütununu okumak için 500 milyon satırın tüm sütunlarını diskten belleğe okumak zorunda kalırlar ve I/O darboğazına girerler.
• OLAP (Çevrimiçi Analitik İşleme - Sütun Tabanlı / Columnar Storage): Snowflake, Google BigQuery, Amazon Redshift, ClickHouse ve Apache Parquet/Iceberg gibi analitik veri ambarlarıdır. Disk üzerinde satırları değil, aynı sütundaki tüm değerleri yan yana bloklar halinde saklarlar. 500 milyon satırlık bir tabloda sadece tutar ve bolge sütunlarını toplayacaksanız, motor diğer 48 sütuna hiç dokunmaz. Ayrıca aynı veri tipindeki değerler yan yana durduğu için (Run-Length Encoding ve Dictionary Encoding ile) %80-90 oranında sıkıştırılır ve SIMD vektörel işlemci komutlarıyla saniyeler içinde taranır.

İşte Büyük Veri Hattı (ETL/ELT), veriyi satır tabanlı OLTP dünyasından alıp sütun tabanlı OLAP dünyasına güvenli, tutarlı ve kesintisiz bir şekilde taşıyan köprüdür.

2. ETL ve ELT Arasındaki Mimari Fark Nedir?

Veri mühendisliğinin temelini oluşturan üç harf vardır: E (Extract - Çıkarma), T (Transform - Dönüştürme) ve L (Load - Yükleme). Bu üç adımın hangi sırayla ve hangi sunucu üzerinde çalıştırıldığı, mimarinizin esnekliğini ve maliyetini doğrudan belirler:

A. Geleneksel ETL (Extract → Transform → Load) Mimarisi

1990'lardan 2010'ların ortasına kadar (Informatica, IBM DataStage, SSIS, Talend dönemleri) disk depolama alanı ve veri ambarı işlemcileri son derece pahalıydı. Bu nedenle veri kaynaktan çekilir çekilmez (Extract), veri ambarına girmeden önce ara bir Hazırlık/Dönüştürme Sunucusunda (Staging / ETL Engine) temizlenir, filtrelenir, hassas verileri maskelenir, birleştirilir (Transform) ve yalnızca son halini almış özet tablolar veri ambarına yüklenirdi (Load).

• ETL'in Dezavantajı (Katılık): Dönüştürme kuralları veri ambarına yüklemeden önce uygulandığı için, ham veri (raw data) kaybolurdu. 6 ay sonra iş birimi "Geçmiş siparişlerde iptal nedenlerini de analiz etmek istiyoruz" dediğinde, o sütun ETL aşamasında filtrelenip atıldığı için tüm boru hattını baştan yazmak ve veriyi kaynaktan yeniden çekmek gerekirdi.

B. Modern ELT (Extract → Load → Transform) Mimarisi

Bulut veri ambarlarının (BigQuery, Snowflake, Databricks) depolama maliyetlerini gigabayt başına birkaç sente düşürmesi ve devasa paralel işleme (MPP - Massively Parallel Processing) gücü sunmasıyla paradigma tersine döndü. ELT mimarisinde veri kaynaklardan çekilir (Extract) ve hiçbir karmaşık dönüşüme uğramadan ham haliyle (Raw / Bronze Layer) doğrudan bulut veri ambarına veya veri gölüne yüklenir (Load). Ardından tüm temizleme, birleştirme ve iş mantığı dönüşümleri (Transform), doğrudan veri ambarının kendi yüksek hızlı motoru içinde SQL veya Spark kullanılarak yapılır.

• ELT'nin Avantajı (Çeviklik ve Yeniden İşlenebilirlik): Ham veri her zaman veri ambarında saklandığı için, iş kuralları değiştiğinde veya bir dönüşüm kodunda hata bulunduğunda kaynak sistemlere tekrar bağlanmaya gerek kalmaz; sadece SQL dönüşüm modeli (dbt) yeniden çalıştırılarak tüm geçmiş veri dakikalar içinde yeniden hesaplanır.

Karşılaştırma Kriteri	ETL (Extract - Transform - Load)	ELT (Extract - Load - Transform)
Dönüşümün (Transform) Yapıldığı Yer	Veri ambarı dışındaki özel bir ara sunucuda (Staging Server / Spark Kümesi)	Doğrudan bulut veri ambarının / Lakehouse motorunun kendi içinde
Ham Verinin (Raw Data) Saklanması	Saklanmaz; yalnızca dönüştürülmüş ve filtrelenmiş veri ambar에 yazılır	Ham veri (Bronze katmanı) her zaman saklanır; istenildiği an yeniden işlenebilir
Yükleme Hızı (Ingestion Latency)	Yavaştır (Veri önce ağır dönüşüm adımlarını bekler)	Çok hızlıdır (Veri kaynaktan alındığı gibi doğrudan hedefe yazılır)
Şema Yaklaşımı	Yazma Anında Şema (Schema-on-Write) - Katı yapı	Okuma/Dönüşüm Anında Şema (Schema-on-Read) - Esnek yapı (JSON/Parquet)
Bakım ve Geliştirme Dili	Özel GUI araçları, Java/Scala veya Python betikleri	Standart SQL ve modüler veri modelleme (dbt - data build tool)
En Uygun Kullanım Senaryosu	Sıkı KVKK/GDPR gereği verinin buluta çıkmadan önce maskelenmesi/anonimleştirilmesi gereken durumlar ve çok yoğun akış içi (in-flight) zenginleştirmeler	Modern bulut analitiği, iş zekası (BI), makine öğrenmesi özellik depoları (Feature Stores) ve hızlı değişen iş gereksinimleri

3. Veri Çıkarma (Ingestion): Toplu İşleme (Batch) vs. Gerçek Zamanlı CDC (Change Data Capture)

Bir veri hattının ilk adımı olan Extract (Veri Çıkarma) aşamasında geçmişte en yaygın yöntem, her gece saat 02:00'de çalışan bir Cron işi ile üretim veritabanına SELECT * FROM orders WHERE updated_at > DÜN sorgusu atmaktı. Ancak bu geleneksel sorgu tabanlı (query-based polling) yaklaşımın üç büyük kusuru vardır:

1. Üretim veritabanına ağır yük bindirir.
2. Veritabanından fiziksel olarak silinen kayıtları (HARD DELETE) yakalayamaz.
3. Veri yalnızca günde bir kez güncellendiği için iş birimleri her zaman 24 saat bayat veriye bakar.

Log Tabanlı Change Data Capture (CDC) Mimarisi

Modern veri mühendisliğinde bu sorun Log Tabanlı CDC (Değişiklik Verisi Yakalama) ile çözülür. PostgreSQL (WAL - Write-Ahead Log), MySQL (Binlog) veya SQL Server (Transaction Log) gibi tüm ilişkisel veritabanları, zaten kendi veri bütünlüklerini korumak için her INSERT, UPDATE ve DELETE işlemini milisaniyesi milisaniyesine sıralı bir ikili günlük dosyasına (transaction log) yazar.

Açık kaynaklı Debezium ve Apache Kafka (veya Fivetran, Airbyte gibi modern ELT konektörleri) veritabanına hiçbir SELECT sorgusu atmaz; doğrudan bu WAL/Binlog dosyasını bir akış (stream) olarak dinler. Üretim veritabanına sıfır yük bindirerek, yapılan her değişikliği (silinen satırlar dahil) milisaniyeler içinde yakalar ve hedef veri ambarına aktarır.

4. Modern Data Stack: dbt, Madalyon Mimarisi (Bronze-Silver-Gold) ve Apache Airflow

Güvenli kurumsal bulut çözümleri üzerinde kurulan "Modern Data Stack" (Modern Veri Yığını) mimarisinde veri, ambara girdikten sonra Madalyon Mimarisi (Medallion Architecture) adı verilen üç katmanlı bir kalite süzgecinden geçer ve bu süreç dbt (data build tool) ile yönetilir:

• Bronz Katman (Bronze / Raw / Staging): Kaynak sistemlerden gelen verinin birebir, değiştirilmemiş ham kopyasıdır. Hatalı kayıtlar veya mükerrer (duplicate) satırlar içerebilir.
• Gümüş Katman (Silver / Cleansed & Conformed): Verinin tekilleştirildiği (deduplication), veri tiplerinin standartlaştırıldığı, boş (null) değerlerin temizlendiği ve temel iş varlıklarının (Müşteriler, Siparişler, Ürünler) oluşturulduğu tek doğruluk kaynağıdır.
• Altın Katman (Gold / Marts & Business Level): Finans, Pazarlama, Ürün veya Üst Yönetim için özel olarak modellenmiş (Kimball Yıldız Şeması / Star Schema: Fact ve Dimension tabloları), iş zekası araçlarının (Power BI, Tableau, Looker, Metabase) doğrudan bağlandığı yüksek performanslı özet katmandır.

Apache Airflow ve Dagster ile DAG Orkestrasyonu

Bir veri hattında "Önce Airbyte ile veriyi çek, çekme biterse dbt Silver modellerini çalıştır, veri kalitesi testleri (Great Expectations / dbt tests) başarılı olursa Gold tablosunu güncelle ve Slack'e bildirim gönder" şeklindeki bağımlılık zincirini yöneten katmana Orkestratör denir. Sektör standardı olan Apache Airflow (ve yeni nesil varlık odaklı alternatifleri Dagster ve Prefect), bu iş akışlarını Yönlü Çevrimsiz Çizge (Directed Acyclic Graph - DAG) olarak Python koduyla tanımlar:

# Apache Airflow 2.x TaskFlow API ile Modern ELT Boru Hattı (DAG Örneği)
from airflow.decorators import dag, task
from datetime import datetime, timedelta

@dag(
    dag_id="eticaret_gunluk_elt_hatti",
    schedule="0 * * * *", # Her saat başı çalışır
    start_date=datetime(2026, 1, 1),
    catchup=False,
    default_args={"retries": 2, "retry_delay": timedelta(minutes=5)}
)
def eticaret_elt_pipeline():

    @task
    def kaynaklardan_ham_veriyi_yukle():
        # Airbyte / CDC ile PostgreSQL'den Bronze katmanına yükleme tetiklenir
        return {"status": "success", "rows_loaded": 145200}

    @task
    def dbt_gumus_ve_altin_modelleri_calistir(yukleme_sonucu: dict):
        if yukleme_sonucu["rows_loaded"] > 0:
            # dbt build komutu hem SQL dönüşümlerini hem de veri kalite testlerini çalıştırır
            print("dbt run && dbt test başarıyla tamamlandı.")
        return True

    ham_veri = kaynaklardan_ham_veriyi_yukle()
    dbt_gumus_ve_altin_modelleri_calistir(ham_veri)

eticaret_elt_pipeline()

5. Veri Ambarı (Data Warehouse) vs. Veri Gölü (Data Lake) vs. Data Lakehouse

Veri mühendisliğinde son yılların en büyük mimari birleşmesi Data Lakehouse kavramıyla gerçekleşmiştir:

1. Data Warehouse (Veri Ambarı): Yapısal (structured) tablo verileri için mükemmeldir, ACID işlemleri (atomiklik, tutarlılık) ve yüksek hızlı SQL performansı sunar. Ancak depolama maliyeti yüksektir ve yapısal olmayan verileri (ses, görüntü, PDF, ham loglar) veya doğrudan Python/PyTorch tabanlı makine öğrenmesi eğitimlerini desteklemekte zorlanır.
2. Data Lake (Veri Gölü - S3, ADLS, GCS): Her türlü veriyi ucuz nesne depolama (Object Storage) üzerinde Parquet veya ORC dosyaları olarak tutar. Çok ucuzdur ancak işlem bütünlüğü (ACID transactions) olmadığı için yarıda kalan bir yazma işlemi veriyi bozar, bir satırı güncellemek/silmek (KVKK unutulma hakkı) çok zordur ve zamanla "Veri Bataklığına" (Data Swamp) dönüşür.
3. Data Lakehouse (Apache Iceberg, Delta Lake, Apache Hudi): Veri gölünün ucuz nesne depolaması (S3 + Parquet) üzerine açık kaynaklı bir Açık Tablo Formatı (Open Table Format - özellikle Apache Iceberg ve Delta Lake) üst veri (metadata) katmanı ekler. Böylece S3 üzerindeki ucuz Parquet dosyalarınız; tıpkı pahalı bir veri ambarı gibi ACID işlemlerini, Zaman Yolculuğu (Time Travel - tablonun 3 gün önceki halini sorgulama) özelliğini, şema evrimini (Schema Evolution) ve satır bazlı silme/güncelleme işlemlerini destekler hale gelir.

Ayrıca kurumsal veri hatlarında akan verinin bütünlüğünü korumak ve veri zehirlenmesi (data poisoning) saldırılarını önlemek için yapay zeka destekli siber güvenlik ve anomali tespit araçları doğrudan veri kalitesi katmanına entegre edilmektedir. Benzer biçimde, Web3 ve blokzincir ağlarındaki zincir üstü (on-chain) işlem verilerinin indekslenip analitik sorgulara açılması da modern ELT ve Lakehouse boru hatları üzerinden yürütülür; kapalı kaynaklı eski ikili veri formatlarının çözülmesinde ise yapay zeka tersine mühendislik yöntemlerinden faydalanılır.

Sıkça Sorulan Sorular (SSS)

1. Küçük ve orta ölçekli bir şirket için en pratik başlangıç veri hattı (Data Stack) nasıl olmalıdır?

Devasa Kubernetes kümeleri veya karmaşık Spark altyapıları kurmadan; veri çıkarma için Airbyte (veya Fivetran), bulut veri ambarı olarak kullandığınız buluta göre Google BigQuery veya Snowflake (ya da tek sunucuda inanılmaz hız sunan gömülü DuckDB / ClickHouse), veri dönüşümü için dbt Core ve görselleştirme için Metabase veya Power BI kullanarak birkaç gün içinde kurumsal standartta bir ELT hattı kurabilirsiniz.

2. Veri mühendisliğinde "İdempotent" (Eşgüçlü) boru hattı ne demektir ve neden hayati önem taşır?

Bir veri hattı görevinin (task) aynı zaman aralığı (örneğin 2026-10-20 tarihi) için 1 kez çalıştırılması ile 5 kez üst üste yeniden çalıştırılması (retry/backfill) sonucunda hedef tabloda birebir aynı veri durumunun oluşmasına İdempotensi (Idempotency) denir. Eğer boru hattınız idempotent değilse (örneğin hedef tabloyu temizlemeden veya MERGE/UPSERT kullanmadan körü körüne INSERT yapıyorsa), ağ hatası yüzünden tekrar çalışan bir görev tüm ciro raporlarınızın ikiye katlanmasına yol açar.

3. Gerçek zamanlı akış (Streaming - Kafka/Flink) her proje için zorunlu mudur?

Hayır. Kredi kartı dolandırıcılık tespiti (fraud detection), dinamik fiyatlandırma veya anlık kurye takibi gibi milisaniyelik karar gerektiren senaryolarda Apache Kafka ve Apache Flink ile gerçek zamanlı akış işleme şarttır. Ancak kurumsal raporlama, finansal analiz ve müşteri segmentasyonu ihtiyaçlarının %85'inde 15 dakikalık veya 1 saatlik mikro-toplu (micro-batch) ELT boru hatları hem çok daha ucuz hem de bakımı çok daha kolaydır.

4. Reverse ETL (Ters ETL) nedir ve ne işe yarar?

Klasik ETL/ELT, veriyi operasyonel araçlardan (CRM, ödeme sistemi, uygulama veritabanı) alıp veri ambarına taşır. Reverse ETL ise veri ambarının Gold katmanında hesaplanan değerli metrikleri (örneğin "Terk Etme Riski Yüksek Müşteri Skoru" veya "Yaşam Boyu Değer - LTV") veri ambarından çıkarıp tekrar satış ve pazarlama ekiplerinin günlük kullandığı Salesforce, HubSpot, Zendesk veya reklam platformlarına geri yazar; böylece analitik veriyi doğrudan operasyonel aksiyona dönüştürür.

5. "Data Contract" (Veri Sözleşmesi) kavramı veri hatlarındaki kırılmaları nasıl önler?

Veri hatlarının en sık çökme nedeni, yazılım ekibinin üretim veritabanındaki bir sütunun adını veya tipini veri mühendisliği ekibine haber vermeden değiştirmesidir. Veri Sözleşmesi (Data Contract), tıpkı mikroservisler arasındaki OpenAPI/Protobuf sözleşmeleri gibi, veri üreticisi (yazılım ekibi) ile veri tüketicisi (veri ekibi) arasında şema yapısını, veri tiplerini ve anlamsal kuralları CI/CD aşamasında zorunlu kılan resmi bir protokol katmanıdır.