Confluent 2025 State of Data Streaming raporuna göre Apache Kafka kurumsal kullanımı son 24 ayda %78 büyürken şirketlerin %72’si artık üretimde en az bir gerçek zamanlı stream processing motoru işletiyor; Databricks Data + AI Summit 2025 sunumlarında ise Spark 4.0 ile Structured Streaming’in Connect Server üzerinden uzaktan istemci modelinin Genel Kullanıma (GA) hazırlandığı duyuruldu. Apache Flink 2.0 GA çıkışı (Mart 2025) Disaggregated State Storage ve PyFlink performans iyileştirmeleriyle gündemi belirlerken Kafka 4.0 KRaft mimarisini varsayılan yaparak ZooKeeper’a veda etti. Forrester 2025 verilerine göre stream processing devreye alan finans kuruluşları dolandırıcılık kayıplarında ortalama %38 azalma raporluyor, bu da 2026’da Flink-Kafka-Spark üçgenini yatırım kararının merkezine yerleştiriyor.
Bu rehberde üç motorun çekirdek mimarilerini, exactly-once garanti modellerini, state backend seçeneklerini (RocksDB, Memory, Filesystem, Disaggregated), pencereleme (windowing) tiplerini ve cloud managed servisler (AWS MSK, Confluent Cloud, Amazon Kinesis Data Analytics, Databricks DLT, Aiven) üzerinden maliyet–latency takasını karşılaştırıyor; üretim seçim çerçevesi ve 2026 yol haritasıyla kapatıyoruz. Daha derine inmek isteyenler için Big Data İşleme: Apache Spark Kafka ve Modern Veri Pipeline ve Event-Driven Architecture: Apache Kafka ile Modern Sistem Mimarisi rehberleri tamamlayıcıdır.
Stream Processing Nedir, Batch’ten Hangi Noktalarda Ayrılır?
Stream processing, verinin sınırsız (unbounded) bir olay akışı olarak ele alınması ve her olayın üretildiği anda işlenmesidir. Batch işleme verinin önce sınırlı bir kümeye toplanmasını, sonra periyodik bir job ile işlenmesini bekler; stream processing ise milisaniye–saniye seviyesinde sürekli sonuç üretir. Veriyi “akış” olarak görmek, “tabloyu sürekli güncellenen bir log’un materyalize görünümü” şeklinde modellemeyi gerektirir; bu yaklaşım Tyler Akidau, Slava Chernyak ve Reuven Lax’ın “Streaming Systems” kitabında sistematik biçimde anlatılır. Olay zamanı (event time) ve işleme zamanı (processing time) ayrımı, geç gelen (late arriving) olayların doğru pencerelere atanması için kritiktir; watermark mekanizması bu ayrımı yönetir ve “ne zaman pencere kapatılacak” sorusuna deterministik cevap verir.
- Olay zamanı (event time): Olayın gerçek dünyada üretildiği zaman damgası — log gecikmesinden bağımsızdır.
- İşleme zamanı (processing time): Motorun olayı gördüğü an — kolaydır ama doğru analitik vermez.
- Geliş zamanı (ingestion time): Olayın motor sınırından geçtiği an — orta yol.
- Watermark: “Bu zaman damgasından önceki tüm olayları gördüm” varsayımı; gecikmiş olaylar için tolerans (allowed lateness) eklenir.
- Triggers: Pencere içeriğinin ne zaman emitilmiş sayılacağını belirler (early, on-time, late firings).
Pencereleme (Windowing) Tipleri ve Kullanım Senaryoları
Akış sonsuz olduğu için toplama (aggregation) operasyonları zaman dilimine bölünür; bu dilimler “window” olarak adlandırılır. Pencere tipi seçimi hem doğruluk hem maliyet üzerinde belirleyici etkiye sahiptir. Aşağıdaki tabloda dört temel pencere tipi ve tipik kullanım alanları özetlenmektedir.
| Pencere Tipi | Tanım | Tipik Senaryo | Flink/Kafka/Spark Desteği |
|---|---|---|---|
| Tumbling | Sabit aralıklı, çakışmasız | Saatlik satış toplamı, dakikalık metrik | Üçü de native |
| Sliding | Sabit aralıklı, çakışan kayar pencere | 5 dk hareketli ortalama her 1 dk emit | Üçü de native |
| Session | İnaktivite gap’i ile dinamik kapanır | Kullanıcı oturumu, web clickstream | Flink + Kafka Streams native, Spark 3.2+ |
| Global | Tüm akışı tek pencerede tutar | Custom trigger ile tam tarama | Flink + Spark (Kafka Streams sınırlı) |
Apache Flink 2.0: Olay Bazlı İşleme ve Olgun State Yönetimi
Apache Flink, Berlin merkezli Data Artisans (sonradan Ververica) ekibinin Stratosphere projesini Apache Software Foundation üst projesine taşımasıyla doğdu. Flink’in temel ayırt edici özelliği gerçek event-at-a-time işleme modelidir; mikrobatch yerine her olay üretildiği anda hesaba katılır. Bu sayede P99 latency 50–200 ms aralığında kalır ve finansal ticaret, dolandırıcılık tespiti, gerçek zamanlı kişiselleştirme gibi sıkı SLA senaryolarında Flink fiilî lider olarak konumlanmıştır. Apache Flink 2.0 GA ile gelen Disaggregated State Storage mimarisi, RocksDB state’inin doğrudan S3/GCS gibi nesne depolama üzerinde tutulmasına olanak tanıyor; bu sayede 10 TB+ state boyutları artık kontrol düzlemi karmaşası yaratmadan ölçekleniyor. Alibaba’nın 2024 Singles Day’inde Flink saniyede 7,8 milyar olay işleyerek bu mimari sıçramanın canlı kanıtını sundu. Netflix, Uber ve Pinterest hâlâ en görünür kurumsal kullanıcılar.
Flink 2.0 ile birlikte PyFlink performansı %30–55 oranında iyileştirildi; Python kullanıcı tanımlı fonksiyonlar (UDF) artık JNI köprüsü yerine Arrow tabanlı vektörel batch yürütme ile çalışıyor. Ayrıca Materialized Tables yeni bir SQL primitive olarak duyuruldu; akış üzerinde tanımlı bir SQL view’ın motorca sürekli güncellenen tablo halinde tutulmasını sağlıyor. Apache Flink resmi dokümantasyonu tüm yeni özelliklerin migration guide’ını sunuyor. DataStream API’nin yanı sıra Table API ve Flink SQL, aynı job içinde harmanlanabiliyor; bu özellikle veri mühendisi ve analist ekiplerin paylaştığı pipeline’larda hızlı prototipleme avantajı sağlıyor.
Kafka Streams ve Kafka 4.0: Hafif, Kütüphane Tabanlı Yaklaşım
Kafka Streams, Confluent tarafından geliştirilen ve doğrudan Apache Kafka topic’leri üzerinde çalışan bir JVM kütüphanesidir; ayrı bir kümeyi yönetmek gerekmez, uygulama JAR’ının içine gömülür ve standart Kubernetes deployment ile ölçeklenir. Kafka Streams resmi dokümantasyonu Processor API ve yüksek seviye Streams DSL olmak üzere iki API katmanı sunar. Apache Kafka 4.0 (Mart 2025) ile ZooKeeper bağımlılığı tamamen kaldırıldı; KRaft varsayılan kontrol düzlemi haline geldi, bu da cluster ayağa kaldırmayı ve operasyonel yükü ciddi biçimde azalttı. Kafka Streams transactional API ile exactly-once garantisini Kafka broker tarafında sağlar (EOSv2). Tek sınırlama şudur: yalnızca Kafka topic’lerinden okuyup yazabilir; harici sistemlerle entegrasyon için Kafka Connect ek bileşen olarak gerekir. Bu mimarinin neden olay tabanlı sistem tasarımıyla iyi örtüştüğünü CQRS ve Event Sourcing rehberinde detaylandırdık.
Spark Structured Streaming 4.0: Batch Ekibi İçin Tanıdık DataFrame API
Spark Structured Streaming, Spark’ı batch için kullanan ekiplerin aynı DataFrame/Dataset API ile streaming yapabilmesini sağlar; “unified batch + streaming” sloganı buradan gelir. Varsayılan mikrobatch modu 200 ms–1 sn aralığında küçük batch’ler işler, Continuous Processing modu ise alt-1 ms latency hedefler (hâlâ deneysel ve sınırlı operatör desteklidir). Spark Structured Streaming Programming Guide resmi referans noktasıdır. Databricks Data + AI Summit 2025’te duyurulan Spark 4.0 ile Spark Connect Server üzerinden uzaktan istemci (thin client) modeli GA oldu; Python/Go/Rust uygulamalar artık Spark cluster’ına gRPC ile bağlanabiliyor. RocksDB state store ve Delta Live Tables (DLT) entegrasyonu, Databricks ortamında lakehouse batch-stream birlikteliğinin sürdürülebilir referans implementasyonu haline geldi. Data Lakehouse Mimarisi rehberi bu bağlamı tamamlar.
Spark 4.0’ın diğer kayda değer iyileştirmeleri arasında ANSI SQL varsayılan olması, VARIANT veri tipinin yarı yapılandırılmış JSON akışları için native desteklenmesi ve Python Data Source API’nin streaming source/sink yazımını saf Python’da mümkün kılması yer alıyor. State store async checkpointing özelliği sayesinde checkpoint operasyonu artık mikrobatch sürecini bloklamıyor; gerçek senaryolarda bu, P99 latency’de %20–35 düşüş anlamına geliyor. Databricks DLT ise streaming tabloları “expectations” (veri kalite kuralları) ile bezeyip Unity Catalog üzerinden lineage takibi sağlıyor; bu da regülasyona tabi sektörlerde (finans, sağlık) audit gereksinimleri için doğrudan değer üretiyor.
Üç Motorun Mimari ve Operasyonel Karşılaştırması
Aşağıdaki tablo üç motoru üretim kararını etkileyen sekiz boyutta yan yana koyar. Sayısal aralıklar Confluent State of Data Streaming 2025, Databricks 2025 benchmark notları ve Ververica üretim referanslarından derlenmiştir.
| Kriter | Apache Flink 2.0 | Kafka Streams 4.0 | Spark Structured Streaming 4.0 |
|---|---|---|---|
| İşleme modeli | Event-at-a-time | Event-at-a-time | Micro-batch (200 ms–1 sn) / Continuous |
| P99 latency | 50–200 ms | 20–150 ms | 500–2000 ms (Continuous: ~1 ms) |
| Throughput / çekirdek | 50–200K olay/sn | 30–100K olay/sn | 80–300K olay/sn |
| Exactly-once mekanizması | Chandy-Lamport checkpoint | Transactional API (EOSv2) | WAL + idempotent sink + offset commit |
| State backend | RocksDB / Heap / Disaggregated S3 | RocksDB lokal + changelog topic | HDFSBackedStateStore / RocksDB |
| Deployment modeli | Standalone / K8s / YARN / Managed | JVM lib (uygulamaya gömülü) | YARN / K8s / Databricks / EMR |
| SQL desteği | Flink SQL (olgun) | ksqlDB (Confluent ekosistemi) | Spark SQL (en olgun) |
| Operasyonel yük | Yüksek (orta — managed ile) | Düşük | Orta–Yüksek |
Exactly-Once vs At-Least-Once: Garanti Modelleri Detaylı
Bir stream processing pipeline’ında garanti, yalnızca tek bir aşamada değil kaynak + işleme + hedef zinciri boyunca korunduğunda anlamlıdır. Aşağıdaki tablo üç temel garantiyi davranış ve maliyet açısından karşılaştırır.
| Garanti | Anlamı | Yan Etki | Maliyet / Performans |
|---|---|---|---|
| At-most-once | Olay 0 veya 1 kez işlenir | Çöküntüde olay kaybı olası | En ucuz, en hızlı |
| At-least-once | Olay en az 1 kez işlenir | Tekrarlama (duplication) olası | Idempotent sink ile yönetilir |
| Exactly-once (effectively-once) | Her olay tam 1 kez “etki” eder | Yan etki yoktur | Throughput %15–25 düşer, latency +20 ms |
Flink, Chandy-Lamport algoritmasının asenkron bariyer ekleme varyantı ile periyodik checkpoint alır; çöküntü sonrası state son tutarlı snapshot’tan geri yüklenir ve Kafka source offset’i o noktaya rewind edilir. Kafka Streams ise EOSv2 ile transactional producer + isolation_level=read_committed kombinasyonu kullanır; bir transaction içinde hem state changelog topic’ine hem hedef topic’e yazılır, ya hepsi commit edilir ya hepsi abort. Spark, write-ahead log (WAL) + idempotent sink + atomic offset commit ile aynı semantiği “effectively-once” olarak sunar. Detaylı garantili mesaj iletim örüntüsü için Saga Pattern: Dağıtık Transaction Yönetimi rehberi tamamlayıcıdır.
State Backend Seçimi: RocksDB, Memory, Filesystem, Disaggregated
Stream processing motorunun kalbi state yönetimidir; pencere içerikleri, aggregation buffer’ları, join state’leri, deduplication tablolar hep state olarak yaşar. Yanlış state backend seçimi P99 latency’yi 10×, recovery süresini 100× kötüleştirebilir.
| State Backend | Storage | Latency | Maks. State | Tipik Senaryo |
|---|---|---|---|---|
| Memory / Heap | JVM heap | < 1 ms | < 1 GB / task | Geliştirme, küçük pencereler |
| Filesystem | Heap + checkpoint to S3/HDFS | 1–5 ms | < 5 GB / task | Orta boyutlu prod, basit operasyon |
| RocksDB (embedded) | Lokal disk + checkpoint | 5–20 ms | 100 GB+ / task | Büyük state, çoğu üretim |
| RocksDB Disaggregated (Flink 2.0) | Doğrudan S3/GCS | 10–50 ms (cached) | 10 TB+ | Mega state, elastik scale |
| Kafka Changelog (Kafka Streams) | Lokal RocksDB + topic backup | 5–20 ms | ~ TB | Kafka-yerleşik pipeline |
- RocksDB heap dışı çalıştığı için GC pause sorunu minimize olur — büyük state için varsayılan tercihtir.
- Memory backend yalnızca dev ortamında veya state’in < 100 MB olduğu özel jobs için anlamlıdır.
- Flink 2.0 Disaggregated State, savepoint alma süresini %80’e kadar düşürebilir (Ververica benchmark).
- Kafka Streams’in changelog topic stratejisi, recovery’yi otomatize eder; manuel snapshot yönetimi gerekmez.
- Spark RocksDBStateStore (3.2+), HDFSBacked’a göre %50–70 daha düşük P99 latency üretir.
Latency vs Throughput Takası: Hangi Motor Hangi Yük Profilinde Kazanır?
Stream processing tasarımında latency hedefi (P50/P95/P99) ile throughput (olay/sn) genellikle ters orantılıdır; biri için optimize etmek diğerinin maliyetiyle gelir. Aşağıdaki tablo dört iş yükü profilinde üç motorun gözlenen davranışını özetler.
| İş Yükü Profili | Hedef | Önerilen Motor | P99 Latency | Maks. Throughput |
|---|---|---|---|---|
| Dolandırıcılık tespiti (ödeme) | < 100 ms her olay | Flink | 50–150 ms | ~1M olay/sn |
| IoT telemetri toplulaştırma | 200 ms – 1 sn | Kafka Streams | 100–300 ms | ~500K olay/sn |
| Clickstream analitik (BI) | 1–5 sn | Spark Structured Streaming | 800–2000 ms | ~3M olay/sn |
| Lakehouse CDC + ML feature | 5–30 sn | Spark + Delta Live Tables | 3–10 sn | ~5M olay/sn |
Cloud Managed Servisler: AWS, Confluent, Databricks, Azure
Kendi kendine yönetilen (self-hosted) stream processing operasyonel olarak yüksek beceri talep eder; ilk 18 ay için yönetilen servisler hızlı pazara çıkış ve düşük operasyonel risk sunar. Confluent blog ve Databricks blog mimari rehberler ve maliyet karşılaştırmaları için canlı referans noktasıdır. Yönetilen servis tercihi yapılırken aşağıdaki kriterler ağırlıklandırılmalıdır.
- VPC ve ağ izolasyonu: Private link, peering ve transit gateway desteği regülasyona tabi yükler için zorunludur.
- SLA seviyesi: Standart 99.9 mı yoksa 99.99 mı; finansal dolandırıcılık tespiti için 99.99 minimumdur.
- Otomatik ölçekleme: Trafiğin 10× sıçradığı promosyon kampanyası senaryoları için elastik scale şart.
- Cross-region replication: Disaster recovery için multi-region topic mirroring (MirrorMaker 2, Cluster Linking).
- Egress maliyeti: Veri başka bir cloud’a veya on-prem’e akıyorsa, egress fiyatlandırması toplam TCO’yu domine edebilir.
Aşağıdaki tablo başlıca yönetilen seçenekleri özetler.
| Servis | Sağlayıcı | Çekirdek Motor | Tipik Aylık Maliyet | Güçlü Yön |
|---|---|---|---|---|
| Amazon MSK + MSK Connect | AWS | Kafka 3.x/4.x | 500–4.000 USD | VPC native, IAM auth |
| Amazon Kinesis Data Analytics | AWS | Flink 1.20 | 800–5.000 USD | Flink olgun, KPU bazlı fiyat |
| Confluent Cloud | Confluent | Kafka + Kafka Streams + ksqlDB + Flink | 1.000–10.000 USD | Tam ekosistem, SLA 99.99 |
| Databricks DLT + Structured Streaming | Databricks | Spark 4.0 | 3.000–25.000 USD | Lakehouse, MLflow, Unity |
| Aiven for Apache Flink | Aiven | Flink 2.0 | 800–4.000 USD | Multi-cloud, açık ekosistem |
| Azure Stream Analytics / HDInsight | Microsoft | Custom + Flink/Spark | 600–6.000 USD | Microsoft stack entegre |
Üretim Karar Çerçevesi: Adım Adım Motor Seçimi
Stream processing motoru seçimi tek başına teknik bir karar değil, organizasyonun ekip yetkinliği ve mevcut platform yatırımıyla iç içe geçmiş bir karardır. Aşağıdaki adımlar üretim seçimini yapılandırır.
- Latency hedefi tanımlayın: 100 ms altı için Flink, 200 ms–2 sn için Kafka Streams, 1 sn üstü için Spark.
- State boyutunu tahmin edin: 100 GB üzeri durumlar için Flink RocksDB / Disaggregated en olgun seçenek; küçük state için Kafka Streams ekonomiktir.
- Mevcut platform yatırımını değerlendirin: Databricks varsa Spark, Confluent varsa Kafka Streams, açık platform isteniyorsa Flink kazanır.
- Operasyonel olgunluğu ölçün: Flink ayrı cluster yönetimi gerektirir, bu yetkinlik yoksa Aiven/AWS Kinesis ile managed başlangıç önerilir.
- Geliştirici ergonomisini değerlendirin: SQL ağırlıklı ekipler için Flink SQL veya ksqlDB ya da Spark SQL iyi başlangıçtır.
- Pilot bir use case ile P95/P99 latency ve maliyet metriklerini doğrulayın: 2 hafta-süreli realistic load test minimum.
- Exit stratejisini tasarlayın: Apache açık standart kullanmak (Kafka, Flink, Spark) vendor lock-in’i en aza indirir.
Sık Sorulan Sorular
Exactly-once garanti gerçekten %100 olabiliyor mu?
Pratikte “effectively-once” semantiği elde edilir; kaynak (idempotent producer veya transactional source), işleme (checkpoint/transaction) ve hedef (idempotent sink veya transactional commit) zincirinin tamamı doğru kurulduğunda her olayın “etki”si tam olarak bir kez gerçekleşir. Mesaj fiziksel olarak hedef sisteme birden çok kez yazılabilir fakat aynı transaction içinde commit edilir ya da iptal edilir. Tek bir aşama eksik kurulduğunda zincir kırılır; örneğin idempotent olmayan bir REST API’ye exactly-once Flink job sink yapmak garantiyi geçersiz kılar.
Stream processing kapasitesi nasıl planlanır?
Kapasite üç boyutta planlanır: throughput (olay/sn), state boyutu (GB) ve latency hedefi (ms). Pilot fazda gerçekçi veri akışıyla prototip ölçümü en sağlıklı yöntemdir. Genel kural olarak Flink çekirdek başına 50–200K olay/sn, Kafka Streams 30–100K, Spark Structured Streaming 80–300K (mikrobatch boyutuna bağlı) işler. State boyutu RAM kapasitesinin %60’ını aştığında RocksDB veya disk spill devreye girer ve P99 latency belirgin artar; bu eşik mutlaka gözlemlenebilir olmalı, Prometheus + Grafana ile alarm tanımlanmalıdır.
Stream processing batch’in yerini alır mı?
Hayır; stream processing düşük gecikme ve sürekli güncellenen sonuçlar için kullanılır, tarihsel veri analizi, karmaşık ML feature engineering ve büyük tablo birleşimleri hâlâ batch’in güçlü olduğu alanlardır. Modern Lambda ve Kappa mimarileri stream’i ön plana koysa da batch katmanı geriye dönük yeniden işleme ve regülasyon raporları için kritik kalır. Apache Iceberg ve Delta Lake gibi açık tablo formatları stream-batch birlikteliği için tek depolama katmanı sunar; bu da Spark Structured Streaming + DLT veya Flink + Iceberg sink kombinasyonlarını mantıklı kılar.
Apache Flink 2.0’da Disaggregated State neyi değiştirdi?
Flink 2.0’ın getirdiği en büyük mimari sıçrama, RocksDB state’inin lokal SSD’lerden bağımsızlaştırılıp doğrudan S3/GCS gibi nesne depolama üzerinde tutulabilmesidir. Bu sayede TaskManager pod’ları stateless gibi davranır, yatay ölçekleme savepoint yapmadan yapılabilir ve recovery süresi 10 TB’lık state için saatlerden dakikalara iner. Trade-off, lokal SSD cache hit oranı düştüğünde P99 latency 10–50 ms aralığına çıkmasıdır; bu nedenle dolandırıcılık tespiti gibi ultra-low-latency yüklerde lokal RocksDB hâlâ tercih edilir.
Kafka 4.0 KRaft geçişi production için güvenli mi?
Evet, Apache Kafka 4.0 ile KRaft varsayılan ve “production ready” olarak işaretlendi; yeni cluster’lar artık ZooKeeper’sız ayağa kalkıyor. Mevcut ZooKeeper-tabanlı cluster’lar için iki aşamalı migration path (KIP-866 + KIP-919) belgelendi. Migration sırasında controller metadata’sının KRaft quorum’a aktarılması online yapılır; broker’lar restart edilse de topic verisi etkilenmez. 100+ broker’lı kurulumlar için staging ortamında 2–4 hafta paralel test önerilir, bu özellikle stream processing pipeline’larında consumer offset commit davranışı için kritiktir.
Sonuç: Use Case Bazlı Verdict
Stream processing 2026 yılında kurumsal veri mimarisinin standart bir katmanı olarak yerleşti. Use case bazlı verdict şöyle özetlenebilir: dolandırıcılık tespiti, gerçek zamanlı kişiselleştirme ve düşük-latency analitik için Apache Flink 2.0 Disaggregated State ve event-at-a-time modeliyle açık ara lider; küçük-orta ölçekli Kafka-yerleşik pipeline’lar için Kafka Streams 4.0 operasyonel basitliğiyle en ekonomik seçim; lakehouse mimarisinde batch-stream birlikteliği isteyen ekipler için Spark Structured Streaming 4.0 (Databricks DLT) en olgun seçenek. Apache Software Foundation şemsiyesi altındaki üç projenin de açık standart olması, vendor lock-in riskini minimize ederek seçimi geri dönülebilir kılar. Doğru kararı verdikten sonra Real-Time Analytics: ClickHouse, Apache Pinot ve Druid, RAG Altyapı Kurulum Rehberi ve Data Mesh Mimarisi rehberleriyle pipeline’ın downstream tarafını tamamlayın.
Ömer ÖNAL
Mayıs 16, 2026Yazılım danışmanlığı projelerinde sıkça karşılaştığım bir soru: “Hangi mimari hangi senaryoda öncelikli olmalı?” Cevap çoğunlukla iş hedefiyle teknik kısıtların kesiştiği noktada netleşiyor. Kurumsal AI projelerinde önce pilot çıktısının üretime taşınabilirliğini ölçen küçük bir validation framework kurmak, doğrudan büyük bütçeli implementation’a girmekten %3-4 kat daha düşük geri dönüşüm riski sağlıyor. Yorumlarınıza açığım.