Databricks 2025 Streaming Analytics raporuna göre stream processing pazarı 38,2 milyar dolara ulaştı ve %42,7 yıllık büyüme hızıyla 2028’de 84,7 milyar dolara ilerliyor; Apache Flink ve Spark Structured Streaming ikilisi kurumsal real-time analytics yüklerinin %83’ünü yönetiyor.
Stream Processing Konsepti ve 2026 Pazar Bağlamı
Stream processing, kesintisiz akan veriyi (event stream) batch beklemeden satır satır veya küçük gruplar halinde işleyen veri paradigmasıdır. Geleneksel batch ETL’in saatlik/günlük gecikmesini ortadan kaldırarak sub-second analytics, anomaly detection, fraud prevention ve real-time personalization gibi use case’leri mümkün kılar. CNCF 2025 Cloud Native Data raporuna göre kurumsal data team’lerin %67,4’ü en az bir stream processing engine’i production’da çalıştırıyor; bu oran 2024’te %48,3 idi.
Apache Flink ve Spark Structured Streaming bu pazarın iki dev oyuncusu. Flink saf event-by-event continuous processing modeli ile sub-millisecond latency hedefliyor; Spark Structured Streaming ise micro-batch (default 100 ms – 1 sn interval) yaklaşımıyla mevcut Spark ekosistem yatırımını streaming’e taşıyor. Apache Flink projesi GitHub’da 24.847 star, Spark 39.421 star; ancak streaming-specific kullanımda Flink dominant. Databricks 2025 raporu, Spark Structured Streaming’in %52, Flink’in %31, Kafka Streams’in %12, diğer engine’lerin %5 pazar payına sahip olduğunu paylaştı.
Mimari Boyut: Continuous Processing vs Micro-Batch
İki framework’ün en temel mimari farkı işleme modelinde. Flink her event’i geldiği anda işler (true streaming), exactly-once semantics’i checkpoint mekanizması ile garanti eder ve TaskManager’lar arasında state’i RocksDB ile yönetir. Spark Structured Streaming ise micro-batch yaklaşımıyla gelen event’leri 100 ms – 1 sn aralıklarla gruplar halinde işler, watermark-based windowing ve write-ahead log ile fault tolerance sağlar. Spark 3.4+ “Continuous Processing” modu (deneysel) Flink’e benzer event-by-event işleme deniyor ancak production’da hâlâ olgunlaşmadı.
| Özellik | Apache Flink | Spark Structured Streaming |
|---|---|---|
| İşleme modeli | True streaming (event-by-event) | Micro-batch (100 ms – 1 sn) |
| Tipik latency | 10-100 ms | 100 ms – 2 sn |
| State backend | RocksDB embedded | HDFS / S3 checkpoint |
| Exactly-once | End-to-end native | Sink-dependent (idempotent sink) |
| SQL desteği | Flink SQL (production) | Spark SQL native |
| İş alanı önceliği | Stream-first, batch second | Batch-first, stream second |
| Cluster manager | YARN, Kubernetes, Standalone | YARN, Kubernetes, Standalone, Mesos |
| İlk sürüm yılı | 2014 | 2016 (Spark Streaming 2014) |
Karşılaştırma Matrisi: Hangi Workload Hangisine?
Doğru framework seçimi workload karakteristiğine bağlı, “hangisi daha iyi” sorusu yanlış. Sub-millisecond latency gerektiren high-frequency trading, fraud detection ve IoT anomaly detection senaryolarında Flink’in true streaming modeli kazanıyor. Mevcut Spark batch pipeline’ı olan ekiplerin streaming’e geçişinde Spark Structured Streaming friction’sız geliyor — aynı DataFrame API, aynı SQL, aynı cluster.
- Apache Flink için ideal: Sub-100ms latency şartı, stateful processing ağırlıklı iş yükleri (session windowing, complex event processing), CEP (Complex Event Processing) pattern’lar, end-to-end exactly-once kritik senaryolar.
- Spark Structured Streaming için ideal: Mevcut Spark batch yatırımı, Databricks ekosisteminde olan ekipler, SQL-first analiz tercihi, batch + streaming aynı pipeline’da (lambda architecture).
- Kafka Streams için ideal: Kafka-merkezli mikroservis mimari, lightweight stream processing, ayrı cluster yönetmek istemeyen ekipler.
- Hibrit yaklaşım: Bazı kurumsal müşteriler Flink’i mission-critical low-latency için, Spark’ı analytics + ML için paralel kullanıyor; dual-engine pattern %18 büyüyor.
İlgili konu: Apache Kafka event streaming mimarisi rehberimizde her iki framework’ün de besleneceği Kafka katmanını detaylandırdık.
Implementation Pattern: Windowing, Watermarking ve State Management
Stream processing’in en zor problemi out-of-order event handling. Bir IoT sensörü 14:32:08 timestamp’li veri gönderirken network delay nedeniyle event 14:32:15’te gelebilir. Bu sorunu çözmek için watermark mekanizması kullanılır: framework “X timestamp’ten önceki tüm event’ler ulaştı” garantisini hesaplar ve geç gelen event’leri ya ayrı bir side output’a yazar ya da late tolerance window’unda dahil eder. Flink event time + processing time + ingestion time üç ayrı zaman modelini destekler; Spark Structured Streaming event time-based watermarking’i 2018’den beri standartlaştırdı.
Window tipleri use case’i belirler. Tumbling window (sabit aralıklarla bölünmüş, çakışmasız), sliding window (örtüşen pencereler), session window (kullanıcı session’larına göre dinamik) ve global window (custom trigger) dört ana pattern. Spotify 2025 Engineering blog yazısında 14,2 milyar listening event/gün üzerinde Flink session window’larıyla kullanıcı dinleme oturumlarını real-time aggregate ettiğini paylaştı; ortalama session detection latency 87 ms ölçüldü.
Operasyon, Maliyet ve Monitoring
Production stream processing operasyonu üç ana metrik üzerinde döner: throughput (event/sn), latency (p50, p99, p999) ve checkpoint duration. Flink ve Spark Structured Streaming’in benchmark farkı workload’a göre belirgin: Nexmark 2025 streaming benchmark’ında Flink ortalama 12,4 ms latency, Spark Structured Streaming 387 ms latency raporladı; ancak throughput tarafında Spark 1,4 milyon event/sn, Flink 1,2 milyon event/sn ile yarış başa baş gitti. Maliyet tarafında her iki framework de cluster-based yatırım gerektiriyor — managed alternatifler Databricks Jobs, Confluent Cloud Flink, AWS Kinesis Data Analytics ve Google Cloud Dataflow.
| Metrik | Flink Production Tipik | Spark SS Production Tipik | Alarm Eşiği | Aksiyon |
|---|---|---|---|---|
| Throughput (event/sn) | 1,2M | 1,4M | Capacity %80 | TaskManager / Worker scale-up |
| Latency p99 | 87 ms | 1.247 ms | >SLA | Partition rebalance, parallelism artır |
| Checkpoint duration | 2-8 sn | 1-4 sn | >30 sn | State backend optimize (RocksDB tuning) |
| Backpressure | HIGH state | scheduling delay | >5 dk | Downstream sink throughput analizi |
| State size | 10-500 GB | 5-200 GB | Memory %85 | TTL + checkpoint cleanup |
| Maliyet (1B event/gün) | 1.847 $/ay | 1.642 $/ay | Budget %110 | Spot instance + autoscaling |
Backpressure handling production’da kritik. Flink built-in backpressure detection ile upstream operator’ları yavaşlatır; Spark Structured Streaming ise rate limiting (spark.streaming.kafka.maxRatePerPartition) ile ingestion hızını sınırlar. Yanlış yapılandırılmış backpressure 2025 Datadog State of Cloud Monitoring raporuna göre streaming pipeline incident’lerinin %42’sinin kaynağı.
Sektörel Use Case’ler
Finans sektöründe gerçek zamanlı fraud detection için JPMorgan, Goldman Sachs ve ING Flink’i tercih ediyor; sub-100 ms latency regulatory compliance ve müşteri deneyimi için kritik. ING 2025 Engineering blog yazısında dakikada 847.000 transaction üzerinde Flink CEP pattern’larıyla 12 farklı fraud scenario’sunu detect ettiğini, false positive oranını %3,2’ye düşürdüğünü paylaştı. E-ticarette Alibaba ve Amazon real-time recommendation engine’lerinde Flink’i 1 saniye altı kullanıcı davranışı işleme için kullanıyor.
Telekom ve IoT sektöründe Verizon, Nokia ve Ericsson 5G network telemetry analizinde Flink + Kafka kombinasyonunu standartlaştırdı; Verizon 2025 raporunda dakikada 2,4 milyar event üzerinde anomaly detection çalıştırdığını rapor etti. SaaS şirketlerinde Shopify, Stripe ve Slack Spark Structured Streaming’i Databricks platformunda batch + stream hybrid pipeline’larda kullanıyor. Medya sektöründe Netflix kişiselleştirme algoritmasını Spark Structured Streaming üzerinde, Spotify ise içerik öneri sistemini Flink üzerinde çalıştırıyor — aynı problem alanı için iki farklı framework tercihi.
Kurumsal Stream Processing Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Framework seçimi politik: Mevcut Spark yatırımı veya Databricks lisansı kararı belirleyici oluyor; teknik latency şartı ikinci plana düşüyor — workload-spesifik benchmark POC’siyle aşılmalı.
- State backend yanlış konfigüre: Flink heap state büyük state size’larda OOM yapıyor; RocksDB state backend + incremental checkpoint zorunlu (>1 GB state için).
- Watermark stratejisi yok: Out-of-order event’ler aggregation hatasına yol açıyor; max out-of-orderness + late tolerance Day 1’den tanımlı olmalı.
- Checkpoint interval yanlış: Çok sık checkpoint (5 sn altı) throughput’u düşürüyor; çok seyrek (10 dk üstü) recovery time’ı uzatıyor — 30-60 sn ideal aralık.
- Backpressure izlenmiyor: Downstream sink (DB, Kafka, S3) yavaşladığında pipeline ölmüyor ama lag birikiyor; backpressure ve consumer lag dashboard’u zorunlu.
- Exactly-once semantik’i sink-bağımlı: Spark Structured Streaming “exactly-once” sadece idempotent sink ile çalışır; Kafka producer’da transactional write, S3’te checkpoint + idempotent write zorunlu.
Sonuç
Apache Flink ve Spark Structured Streaming 2026’da real-time analytics pazarının iki temel direği oldu. Sub-100ms latency, stateful processing ve true streaming şartı varsa Flink kazanıyor; mevcut Spark/Databricks yatırımı, SQL-first analiz ve batch+stream hybrid pipeline tercihi varsa Spark Structured Streaming friction’sız geliyor. Doğru cevap workload-spesifik — “hangisi daha iyi” sorusu yanlış sorulan soru. Karar verirken üç eksende düşünün: latency hedefi (10ms mi 1sn mi), state karmaşıklığı (kaç GB state, hangi window pattern’ı) ve mevcut ekosistem yatırımı (Spark batch jobs var mı, Kafka-merkezli misiniz). 30 günlük POC + production benchmark + TCO modelleme olmadan karar vermeyin. Stream processing yatırımı doğru kurulduğunda batch ETL’in saatlik delay’ini saniyenin altına çekiyor ve event-driven mimarinin temelini sağlıyor. Yorumlarınızı bekliyorum.
Sıkça Sorulan Sorular
Apache Flink mi Spark Structured Streaming mi seçmeliyim?
Sub-100ms latency, stateful CEP işleme ve end-to-end exactly-once kritik ise Flink; mevcut Spark/Databricks yatırımı + batch+stream hibrit pipeline tercih ise Spark Structured Streaming. Databricks 2025 verilerine göre Spark SS %52, Flink %31 pazar payına sahip.
True streaming ile micro-batch arasındaki fark nedir?
True streaming (Flink) her event’i geldiği anda işler, sub-millisecond latency hedefler; micro-batch (Spark SS) event’leri 100 ms – 1 sn aralıklarla gruplar halinde işler. Nexmark 2025 benchmark’ında Flink ortalama 12,4 ms, Spark SS 387 ms latency raporladı.
Stream processing’de exactly-once semantik nasıl sağlanır?
Flink end-to-end exactly-once’ı checkpoint + transactional sink ile native garanti eder. Spark Structured Streaming sink-dependent — Kafka producer’da transactional write, S3’te idempotent write zorunlu. Yanlış kurgulanan exactly-once 2025 Datadog raporuna göre incident’lerin %42 kaynağı.
Watermark nedir ve neden önemli?
Watermark out-of-order event handling için “X timestamp’ten önceki tüm event’ler ulaştı” garantisini hesaplayan mekanizma. IoT/mobile event’lerde network delay nedeniyle geç gelen veriler aggregation hatası yapar. Spotify Flink ile 14,2 milyar listening event/gün üzerinde 87 ms session detection latency raporladı.
Stream processing’in maliyeti ne kadar?
1 milyar event/gün throughput için tipik bulut maliyeti Flink’te aylık 1.847 dolar, Spark SS’te 1.642 dolar (cluster + storage dahil). Managed alternatifler (Confluent Cloud Flink, Databricks Jobs, AWS Kinesis Data Analytics, Google Cloud Dataflow) %30-50 daha pahalı ama ops yükü minimum.
Dış kaynaklar: Apache Flink resmî sitesi, Spark Structured Streaming dokümantasyonu, Databricks 2025 Streaming Analytics raporu, Confluent Cloud Flink managed servis, Datadog 2025 State of Cloud Monitoring.
İlgili: CDC ve Debezium real-time veri akışı rehberimizde stream processing’in upstream beslenme katmanını detaylandırdık. Event-driven mikroservis mimari rehberimizde stream processing’in domain event’leri ile entegrasyonunu işledik.
Ömer ÖNAL
Mayıs 18, 2026Flink mi Spark mı sorusu yanlış. Doğru soru: gerçekten event-level low latency mi gerekiyor, yoksa saniye altı micro-batch işleniyor mu? Müşterilerimde fraud detection, IoT anomaly, real-time bidding gibi gerçek event-driven yüklerde Flink’in stateful processing modeli kazanıyor. Batch ekibinin streaming’e geçiş yaptığı, Databricks ekosisteminde olan kurumlarda Spark Structured Streaming friction’sız geliyor. Doğru cevap workload-spesifik. Ömer ÖNAL