Streaming ETL 2026: CDC, Kafka ve Iceberg ile Real-Time Lakehouse Pattern

Confluent 2025 State of Data in Motion raporu, batch ETL’den streaming ETL’ye geçen kurumlarda veri freshness’ın ortalama 2 saatten 5 dakikaya düştüğünü, decision latency’nin %78 azaldığını gösteriyor. CDC + Kafka + Iceberg üçlüsünü kullanan ekiplerin ortalama event throughput’u 1.8 milyon olay/saniyeye ulaşıyor. Konuyla ilişkili olarak Change Data Capture (CDC): Debezium ile Real-Time Veri Akışı rehberimiz detaylı incelemeyi içerir.

Streaming ETL 2026: Real-Time Lakehouse Paradigması

Batch ETL geleneksel olarak veri ambarına saatte bir veya günde bir veri yüklerken modern streaming ETL bu süreyi saniyelere indiriyor. Change Data Capture (CDC) + Apache Kafka + Apache Iceberg üçlüsü 2025’te kurumsal real-time lakehouse’un standardı haline geldi. Forrester 2025 Streaming Data Integration Wave değerlendirmesinde Debezium, Confluent ve Estuary CDC connector’ları liderler olarak konumlandı; Iceberg merge-on-read pattern’i streaming upsert için en olgun çözüm.

Müşterilerimde gördüğüm en yanlış uygulanan pattern: ‘real-time’ diye başlanan proje ‘micro-batch 5 dk’ olarak doğuyor çünkü Iceberg compaction maliyeti hesaba katılmıyor. Doğru pattern: CDC + Kafka + Iceberg + saatte 1 compaction job. Bu üçlü doğru kalibre edildiğinde freshness 30 saniyenin altına iniyor, maliyet batch pipeline’ın 1.4 katı civarında kalıyor.

CDC Connector Seçimi: Debezium, Fivetran HVR, AWS DMS

CDC operasyonel veri tabanından (PostgreSQL, MySQL, Oracle, SQL Server) değişiklik event’lerini stream halinde çıkaran teknoloji. Üç ana yaklaşım var: open-source Debezium (en yaygın, Kafka Connect üzerinden), Fivetran HVR (managed CDC + transformation), AWS DMS (AWS-native, RDS uyumlu). Seçim deployment kısıtı, kaynak veri tabanı çeşitliliği ve maliyete bağlı.

Kafka Topic Tasarımı: CDC için Best Practice

CDC event’leri Kafka topic’lere yayılırken topic naming ve partition strategy kritik. Convention: cdc.{database}.{schema}.{table}; bu sayede consumer’lar topic pattern subscription ile çoklu tablo dinleyebiliyor. Partition key olarak primary key kullanılmalı; aynı row’un tüm event’leri aynı partition’a düşsün ki order garantili olsun. Partition sayısı throughput hedefine göre 3-50 arasında ayarlanır.

• Topic naming: cdc.{db}.{schema}.{table} (Debezium default)
• Partition key: primary key (single PK için doğal; composite PK için concatenate)
• Partition count: hedef throughput / (consumer max throughput) + buffer
• Retention: minimum 7 gün (consumer outage recovery için)
• Compaction: tombstone (DELETE event) için log compaction enable

Stream processing entegrasyonu için stream processing rehberimize bakabilirsiniz.

Iceberg Merge-on-Read ve Streaming Upsert

Apache Iceberg 1.4+ ile merge-on-read pattern streaming upsert için olgun. Yeni gelen CDC event’ler delete file + data file olarak yazılıyor; read query bunları birleştirip current state’i veriyor. Bu pattern write latency’yi düşürüyor (saniyeler) ama read latency’yi artırıyor. Compaction job periyodik olarak delete + data file’ları base file’a merge ediyor, read latency’yi geri optimize ediyor.

Compaction Stratejisi: Maliyet ve Freshness Dengesi

Streaming ETL’nin gizli maliyeti compaction. Sık compaction (saatte 1) read latency’yi düşük tutar ama compute maliyeti yüksek; seyrek compaction (günde 1) maliyeti düşürür ama small file problem ve read amplification yaratır. Doğru pattern: critical tier tablolar için saatlik, non-critical için günlük. Apache Iceberg resmi maintenance rehberinde bu pattern detaylı.

Exactly-Once Garantisi: Source-to-Sink

Streaming ETL’de en kritik konu exactly-once garantisi. CDC source’tan başlayarak Kafka producer (idempotent + transactional), Kafka consumer (read-committed isolation), Iceberg sink (atomic commit) zinciri exactly-once sağlıyor. Bir noktada at-least-once’a düşersek (örn. consumer offset commit hatası) downstream’de duplicate row’lar ortaya çıkıyor. Iceberg’in idempotent merge-on-read özelliği bu pattern’i tamamlıyor.

Kurumsal Streaming ETL Dönüşümünde Karşılaşılan Tipik Sorunlar

Danışmanlık projelerinde gözlemlenen tipik darboğazlar:

• “Real-time” iddiası ile başlayan proje aslında micro-batch 5dk; Iceberg compaction hesaba katılmamış
• CDC partition key yanlış seçiliyor (timestamp gibi); row ordering bozuluyor, duplicate processing
• Kafka topic retention 24 saat; consumer outage’da event kaybediliyor
• Iceberg compaction job kurulmuyor; small file problem 6 ay sonra query latency’yi 10x artırıyor
• Schema evolution stratejisi yok; production’da CDC connector hata veriyor
• Exactly-once zinciri parçalı; bir node at-least-once, duplicate row’lar downstream’e ulaşıyor

Sonuç

Streaming ETL 2026’da artık “experimental” değil, kurumsal real-time lakehouse’un standart pattern’i. CDC + Kafka + Iceberg üçlüsü doğru kalibre edildiğinde freshness 30 saniyenin altına iniyor, decision latency %78 düşüyor. Karar öncesi mutlaka şu üç soruyu cevaplayın: Source DB’lerin CDC kapasitesi var mı (WAL, binlog enable mı)? Iceberg compaction stratejisi tablo-tier bazlı tanımlandı mı? Exactly-once zinciri uçtan uca planlandı mı? Bu üç hazırlık olmadan streaming ETL “yarım batch” haline geliyor ve hem maliyet hem incident artıyor.

Sıkça Sorulan Sorular