Streaming Veri İşleme: Kafka Streams ve Apache Flink Rehberi [2026]

Stream Processing Neden Kritik?

Geleneksel batch processing, verileri belirli periyotlarla toplu olarak işlerken; stream processing, verileri oluştukları anda sürekli bir akış olarak işler. Gerçek zamanlı karar verme ihtiyacı arttıkça, batch yaklaşımının dakikalar veya saatler süren gecikmeleri kabul edilemez hale gelmiştir.

Dolandırıcılık tespiti milisaniyeler içinde yapılmalıdır. IoT sensörlerinden gelen anomaliler anında işaretlenmelidir. E-ticaret platformlarında fiyat güncellemeleri ve stok değişiklikleri gerçek zamanlı yansımalıdır. Log analizi ve sistem izleme kesintisiz çalışmalıdır. Bu rehberde, stream processing mimarisinin temellerini, Kafka Streams ve Apache Flink ekseninde derinlemesine inceliyoruz.

Batch vs Stream Processing

Batch Processing

Batch processing, sınırlı (bounded) veri kümeleri üzerinde çalışır. Veriler toplanır, belirli bir zaman diliminde biriktirilir ve toplu olarak işlenir. MapReduce, Apache Spark batch mode ve geleneksel ETL süreçleri bu modelin örnekleridir. Yüksek throughput sağlar ancak gecikme (latency) dakikalardan saatlere kadar uzayabilir.

Stream Processing

Stream processing, sınırsız (unbounded) veri akışları üzerinde çalışır. Her olay geldiğinde veya mikro-batch'ler halinde işlenir. Gecikme milisaniyelerden saniyelere kadar düşer. Durum yönetimi (state management) ve hata toleransı (fault tolerance) daha karmaşıktır. Kafka Streams, Apache Flink ve Spark Structured Streaming bu alanın öncü teknolojileridir.

Lambda ve Kappa Mimarileri

Lambda mimarisi, batch ve stream katmanlarını paralel çalıştırarak sonuçları birleştirir. Bu yaklaşım doğruluk ve düşük gecikmeyi aynı anda sağlar ancak iki ayrı pipeline'ın bakımı karmaşıklık yaratır. Kappa mimarisi ise yalnızca stream katmanını kullanır ve gerektiğinde geçmiş verileri stream olarak yeniden oynatır. Kafka'nın log compaction ve retention özellikleri sayesinde Kappa mimarisi pratik hale gelmiştir.

Zaman Kavramları ve Windowing

Stream processing'de zaman yönetimi en kritik tasarım kararlarından biridir.

Event Time vs Processing Time

Event time, olayın gerçekleştiği zamandır ve veri kaynağı tarafından damgalanır. Processing time ise olayın işlendiği zamandır. Ağ gecikmeleri, sistem yükleri ve yeniden işleme senaryoları nedeniyle bu iki zaman arasında fark oluşur. Doğru sonuçlar için event time tercih edilmelidir; ancak bu, watermark mekanizması gerektirir.

Watermark Mekanizması

Watermark, "bu zamana kadar olan tüm olayların geldiğini varsayıyorum" anlamına gelen bir sinyal mekanizmasıdır. Watermark, event time ilerlemesini takip eder ve pencere hesaplamalarının ne zaman tetikleneceğini belirler. Çok erken watermark, eksik sonuçlara; çok geç watermark ise gereksiz gecikmeye neden olur. Heuristic watermark stratejileri, veri kaynağının gecikmesine göre dinamik olarak ayarlanabilir.

Geç Gelen Veriler

Watermark'tan sonra gelen veriler "geç veri" olarak sınıflandırılır. Allowed lateness parametresi, geç verilerin ne kadar süre kabul edileceğini belirler. Geç veriler mevcut pencere sonuçlarını güncelleyebilir (update mode) veya ayrı bir yan çıktıya (side output) yönlendirilebilir. Kritik iş senaryolarında geç veri kaybını önlemek için uygun strateji seçilmelidir.

Windowing Stratejileri

Pencere (window) kavramı, sınırsız veri akışını sınırlı gruplar halinde işlemeyi mümkün kılar.

Tumbling Window

Sabit boyutlu, örtüşmeyen pencerelerdir. Örneğin, her 5 dakikalık dilim ayrı bir pencere oluşturur. Her olay yalnızca bir pencereye ait olur. Periyodik raporlama ve toplama (aggregation) işlemleri için idealdir. Saatlik satış toplamları, dakikalık istek sayıları gibi metrikler bu pencere tipi ile hesaplanır.

Sliding Window

Sabit boyutlu ancak örtüşen pencerelerdir. Pencere boyutu ve kayma miktarı (slide) ayrı ayrı belirlenir. Bir olay birden fazla pencereye dahil olabilir. Hareketli ortalamalar ve trend analizi için uygundur. Örneğin, 10 dakikalık pencere ve 1 dakikalık kayma ile her dakika son 10 dakikanın ortalaması hesaplanabilir.

Session Window

Aktivite boşluklarına göre dinamik olarak oluşan pencerelerdir. Belirli bir süre (gap duration) boyunca olay gelmezse pencere kapanır. Kullanıcı oturumu analizi, tıklama akışı (clickstream) analizi için idealdir. Pencere boyutu önceden bilinmez; kullanıcı davranışına göre değişir.

Global Window

Tüm olayları tek bir pencerede toplayan, trigger mekanizması ile sonuç üreten pencere tipidir. Özel tetikleme mantığı tanımlanarak esnek işleme sağlanır. Karmaşık iş kuralları gerektiren senaryolarda tercih edilir.

Kafka Streams Derinlemesine

Kafka Streams, Apache Kafka üzerine inşa edilmiş, ayrı bir küme gerektirmeyen bir stream processing kütüphanesidir.

KStream ve KTable

KStream, sınırsız bir olay akışını temsil eder. Her kayıt bağımsız bir olay olarak ele alınır ve INSERT semantiğine sahiptir. KTable ise bir changelog akışını temsil eder ve her anahtar için en güncel değeri tutar; UPSERT semantiğine sahiptir. Bu iki soyutlama, stream-table duality ilkesinin uygulamasıdır. KStream'ler filtreleme, dönüştürme ve zenginleştirme için; KTable'lar referans veri ve anlık durum sorguları için kullanılır.

Join Operasyonları

KStream-KStream join, iki olay akışını belirli bir zaman penceresi içinde birleştirir. KStream-KTable join, olay akışını güncel referans verisi ile zenginleştirir. KTable-KTable join, iki durum tablosunu birleştirir. Inner, left, outer join tipleri desteklenir. Join işlemlerinde co-partitioning gereksinimi kritiktir: birleştirilecek topic'ler aynı sayıda partition'a sahip olmalı ve aynı anahtarla bölümlenmelidir.

Exactly-Once Semantics

Kafka Streams, Kafka'nın transactional API'sini kullanarak exactly-once semantik sağlar. processing.guarantee parametresi exactly_once_v2 olarak ayarlandığında, okuma-işleme-yazma döngüsü atomik bir transaction olarak gerçekleşir. Bu sayede, hata durumlarında veri kaybı veya tekrarlı işleme önlenir. Exactly-once semantik, performans maliyeti getirir; bu nedenle iş gereksinimlerine göre at-least-once ile karşılaştırılmalıdır.

State Store ve Interactive Queries

Kafka Streams, stateful işlemler için RocksDB tabanlı yerel state store kullanır. Aggregation, join ve windowed hesaplamalar state store'a yazılır. State store, changelog topic'i aracılığıyla Kafka'ya yedeklenir ve hata durumunda bu topic'ten yeniden oluşturulur. Interactive Queries özelliği, state store'a doğrudan REST API üzerinden sorgu yapılmasını sağlar; bu sayede ayrı bir veritabanına gerek kalmadan gerçek zamanlı sorgular çalıştırılabilir.

Apache Flink Derinlemesine

Apache Flink, dağıtık stream processing için tasarlanmış, yüksek performanslı ve esnek bir framework'tür.

DataStream API

Flink'in DataStream API'si, düşük seviyeli ve esnek bir programlama modeli sunar. map, flatMap, filter, keyBy, window, reduce, aggregate gibi operatörler zinciri oluşturularak veri akışları işlenir. keyBy operatörü verileri mantıksal partitionlara ayırır ve paralel işlemeyi mümkün kılar. Process function, event time erişimi, state yönetimi ve timer'lar ile en esnek işleme mantığını sunar.

State Management

Flink, keyed state ve operator state olmak üzere iki state tipi destekler. ValueState tekil bir değer, ListState bir liste, MapState bir harita, ReducingState ve AggregatingState ise sürekli güncellenen toplama değerlerini tutar. State backend olarak HashMapStateBackend bellek tabanlı hızlı erişim sağlarken, EmbeddedRocksDBStateBackend disk tabanlı olarak büyük state'leri yönetebilir.

Checkpointing ve Savepoint

Checkpoint, Flink'in hata toleransı mekanizmasıdır. Chandy-Lamport algoritmasına dayalı asenkron barrier snapshotting kullanılır. Her checkpoint'te tüm operatörlerin state'i ve kaynak offsetleri tutarlı bir şekilde kaydedilir. Checkpoint aralığı, kurtarma süresi ile performans arasındaki dengeyi belirler. Savepoint ise kullanıcı tarafından tetiklenen, uygulamanın tam bir anlık görüntüsüdür. Versiyon yükseltme, yapılandırma değişikliği ve A/B testi senaryolarında savepoint kullanılır.

Flink SQL ve Table API

Flink SQL, SQL bilen analistlerin stream processing yapmasını sağlar. Temporal join, pattern recognition (MATCH_RECOGNIZE) ve windowed aggregation gibi gelişmiş özellikler SQL söz dizimi ile kullanılabilir. Dynamic tables kavramı, sürekli güncellenen sorgu sonuçlarını temsil eder. Catalog entegrasyonu ile Hive, Iceberg ve Delta Lake tablolarına doğrudan erişim mümkündür.

Spark Structured Streaming Karşılaştırması

Spark Structured Streaming, mikro-batch ve continuous processing modlarını destekler. Spark ekosistemi ile tam entegrasyon sağlar; DataFrame API ve SQL desteği mevcuttur. Mikro-batch modu 100ms-saniye düzeyinde gecikme sunarken, continuous mode milisaniye düzeyine iner ancak sınırlı operatör desteği vardır. Flink, event time processing, state management ve düşük gecikme konularında daha olgun iken; Spark, mevcut Spark altyapısı olan ekipler için düşük giriş bariyeri sunar. Büyük ölçekli batch ve stream birleşik iş yükleri için Spark, düşük gecikme ve karmaşık event processing için Flink tercih edilmelidir.

Complex Event Processing (CEP)

CEP, olay akışlarında karmaşık kalıpları tespit etmek için kullanılan bir paradigmadır.

Pattern Tanımlama

Flink CEP kütüphanesi, olaylar arasında sıralama, zaman kısıtları ve koşullar tanımlamaya olanak tanır. "A olayını takip eden 5 dakika içinde B olayı ve ardından C olayı" gibi karmaşık kalıplar ifade edilebilir. Quantifier'lar (oneOrMore, timesOrMore, optional) kalıp esnekliğini artırır. Timeout mekanizması, beklenen kalıbın tamamlanmadığı durumları yakalar.

CEP Kullanım Alanları

Dolandırıcılık tespitinde, kısa sürede farklı lokasyonlardan yapılan işlemler veya olağandışı harcama kalıpları tespit edilir. IoT'de, sensör değerlerinin belirli bir eşiği aşması ve ardından normale dönmemesi gibi kalıplar izlenir. E-ticarette, sepet oluşturma sonrası satın alma yapılmadan terk etme kalıpları analiz edilir.

Stream-Table Duality

Stream-table duality, stream processing'in temel kavramlarından biridir. Bir tablo, bir stream'in belirli bir andaki anlık görüntüsüdür. Bir stream, bir tablodaki değişikliklerin zaman sıralı kaydıdır. Kafka'da bu dualite, topic (stream) ve compacted topic (table) ile somutlaşır. Change Data Capture (CDC) araçları, veritabanı tablolarını stream'e dönüştürerek bu dualiteyi etkinleştirir. Debezium gibi CDC araçları, veritabanı değişikliklerini Kafka topic'lerine aktararak gerçek zamanlı veri entegrasyonu sağlar.

Stateful Processing Kalıpları

Enrichment Pattern

Olay akışı, harici bir veri kaynağından alınan referans verisi ile zenginleştirilir. Referans verisi KTable, state store veya async I/O ile erişilebilir. Async I/O, harici servislere non-blocking çağrılar yaparak throughput'u artırır.

Deduplication Pattern

Aynı olayın birden fazla işlenmesini önlemek için bloom filter veya state store tabanlı deduplikasyon uygulanır. Zaman penceresi ile sınırlandırılmış deduplikasyon, state boyutunu kontrol altında tutar.

Temporal Join Pattern

Bir olay akışını, belirli bir zamandaki referans verisi ile birleştirme ihtiyacı temporal join ile karşılanır. Flink'in temporal table join özelliği, event time'a göre doğru referans versiyonunu seçer.

Ölçeklendirme ve Paralellik

Kafka Streams Ölçeklendirme

Kafka Streams, topic partition sayısına göre parallellik sağlar. Her partition en fazla bir stream thread tarafından işlenir. Ölçeklendirme için partition sayısı artırılabilir veya uygulama instance'ları eklenebilir. num.stream.threads parametresi ile instance başına thread sayısı ayarlanır.

Flink Paralellik Modeli

Flink'te her operatör bağımsız paralellik derecesine sahip olabilir. Kaynak paralelliği Kafka partition sayısı ile, işleme paralelliği iş yoğunluğuna göre ayarlanır. TaskManager ve slot yapılandırması kaynak kullanımını belirler. Reactive mode ile Flink, mevcut kaynaklara göre otomatik ölçeklenir.

Stream Uygulamalarının İzlenmesi

Stream uygulamalarının izlenmesi, batch uygulamalarından farklı metrikler gerektirir.

Temel Metrikler

Consumer lag, işlenmeyi bekleyen olay sayısını gösterir ve en kritik metriktir. Event time lag, watermark ile mevcut zaman arasındaki farkı ölçer. Throughput (events/second), sistemin işleme kapasitesini gösterir. Checkpoint süresi ve boyutu, Flink uygulamalarında state sağlığını yansıtır. Back pressure, downstream operatörlerin yetiştirememesi durumunu işaret eder.

Kubernetes Üzerinde Dağıtım

Flink, Kubernetes üzerinde native mode veya standalone mode ile çalıştırılabilir. Flink Kubernetes Operator, uygulama yaşam döngüsünü otomatik yönetir. Kafka Streams uygulamaları standart Kubernetes deployment olarak dağıtılabilir. Stateful set ve persistent volume kullanımı, state kurtarma süresini kısaltır. Smart Maple olarak, stream processing uygulamalarını Kubernetes üzerinde operasyonel hale getirirken, otomatik ölçeklendirme ve self-healing mekanizmalarının doğru yapılandırılmasının kritik olduğunu vurguluyoruz.

Gerçek Dünya Kullanım Senaryoları

Gerçek Zamanlı Analitik

Olay akışlarından anlık dashboard'lar ve metrikler oluşturulur. Windowed aggregation ile saniye veya dakika bazlı toplama yapılır. Materialized view olarak sunulan sonuçlar, REST API üzerinden sorgulanabilir.

Dolandırıcılık Tespiti

Kural tabanlı ve ML tabanlı yaklaşımlar stream üzerinde birleştirilir. CEP ile karmaşık dolandırıcılık kalıpları gerçek zamanlı tespit edilir. Model güncellemeleri, stream uygulamasına kesintisiz olarak uygulanır.

IoT Sensör İşleme

Milyonlarca sensörden gelen veri akışı paralel olarak işlenir. Anomali tespiti, eşik kontrolü ve pattern detection uygulanır. Edge computing ile ön filtreleme yapılarak merkezi sisteme yalnızca anlamlı olaylar iletilir.

Log İşleme ve Gözlemlenebilirlik

Uygulama logları, sistem metrikleri ve trace verileri stream olarak işlenir. Gerçek zamanlı anomali tespiti ve alerting sağlanır. Event-driven mimari ile entegre çalışan log pipeline'ları oluşturulabilir. Gerçek zamanlı veri işleme konusunda daha geniş bir perspektif için ilgili rehberimize de bakabilirsiniz.

Sonuç

Stream processing, modern veri mimarisinin temel yapı taşlarından biridir. Kafka Streams, Kafka ekosistemi ile sıkı entegrasyon ve operasyonel basitlik sunarken; Apache Flink, gelişmiş state management, event time processing ve CEP yetenekleri ile karmaşık senaryoları karşılar.

Doğru teknoloji seçimi, gecikme gereksinimleri, state boyutu, ekip yetkinliği ve mevcut altyapıya bağlıdır. Her iki teknoloji de olgunlaşmış ekosistemler sunmaktadır; kritik olan, iş gereksinimlerine uygun mimari kararların alınmasıdır.

Stream processing yolculuğuna başlarken, basit bir kullanım senaryosu ile proof of concept oluşturmak, windowing ve state management kavramlarını pratikte deneyimlemek ve ardından üretime geçiş planını oluşturmak en sağlıklı yaklaşımdır.