Gerçek Zamanlı Veri İşleme: Kafka, Spark Streaming ve Event-Driven Mimari [2026]

Gerçek Zamanlı Veri İşleme: Tarihsel Veriden Canlı Akışlara

Geleneksel veri analizi, geçmişe bakar. Dün ne satış yaptık, geçen ay müşteri kaybı ne kadar—bunlar önemli sorulardır. Ancak, bugünün işletmeleri için yeterli değildir.

Bir dolandırıcılık tespit sistemi, işlem gerçekleşirken (saniyeler içinde) karar vermelidir. Bir e-ticaret sitesi, müşteri sayfada gezinirken (anlık olarak) kişiselleştirilmiş ürün önermeleri göstermelidir. Bir IoT ağı, sensörlerden gelen anomaliyi hemen farkettikten bir saniye sonra uyarı vermelidir.

Bunlar, batch (toplu) veri işlemesiyle yapılamaz. Gerçek zamanlı (streaming) veri işleme gerekir. Bu rehber, stream processing'in ne olduğunu, ne zaman gerekli olduğunu ve nasıl kurulacağını açıklıyor.

Batch vs. Streaming: Zaman Boyutunun Üzerinden Karar

İlk olarak, temel farkı anlamalıyız: batch ve streaming işleme, zaman yönetiminin farklı yollarıdır.

Batch İşleme

Tanım: Veriler, belirli bir zaman intervalinde toplanır ve bir kerede işlenir.

Örnek: Her gece saat 02:00'de, günün tüm satış işlemleri (1 milyon kayıt) alınır, tutarlılık kontrolleri yapılır, raporlar oluşturulur, dashboard güncellenir.

Avantajları:

• Basit ve güvenilir (batch işlemleri, tekrar çalıştırılabilir)
• Ucuz (yazılım ve altyapı maliyeti düşük)
• Büyük hacimli veri işlemeye uygun (1 TB veriyi bir kerede işlemek kolay)
• Çoğu kuruluş başarılı bir şekilde batch kullanıyor

Dezavantajları:

• Gecikmeli sonuçlar (işlemlerin sonuçları, birkaç saat sonra bilinir)
• İş gereksinimleri değişirse, pipeline'ı yeniden yazmalısınız

Streaming İşleme

Tanım: Veriler, oluşur oluşmaz (gerçek zamanlı) işlenir.

Örnek: Bir müşteri satın alma yaptığında, o saniye, işlem dolandırıcılık sistemine gider, başında riski değerlendirilir. Risk yüksekse, işlem bloke edilir. Aynı zamanda, müşteri profili güncellenir, kişiselleştirilmiş ürün önerileri hazırlanır.

Avantajları:

• Anlık sonuçlar (kararlar, milisaniye içinde verilir)
• Dinamik ve esnek (yeni kuralları anında başlayabilirsiniz)
• Gerçek zamanlı analitik ve öngörüler

Dezavantajları:

• Daha karmaşık (distributed systems, konsistensi sorunları)
• Maliyetli (24/7 kaynaklara ihtiyaç)
• Düşük letency gereksinimleri (milisaniye), mimariye ek sorunlar getirir

Streaming Gerekli midir? Kullanım Örnekleri

Streaming işleme, tüm işletmeler için gerekli değildir. Doğru soruyu sormak önemlidir: Bu iş için gerçek zamanlı veri karar veriyor mu?

Streaming Gerekli Olan Senaryolar

1. Dolandırıcılık Tespiti (Fraud Detection)

Kredi kartı işleminde, dolandırıcılık denemesi tespit edilmesi, milisaniye içinde olmalıdır. Işlem halihazırda gerçekleştikten sonra tespit edilirse, para çalınmışıdır. Streaming, burada zorunludur.

Finans kuruluşları, bu tür sistemler için milyonlar yatırır.

2. Gerçek Zamanlı Kişiselleştirme

Bir e-ticaret sitesinde, müşteri "ayakkabı" kategorisine bakıyor. O anda, ürün önerileri güncellenmesi, müşteri deneyimini iyileştirir. Batch'te, öneriler saatler sonra güncellenir, müşteri sayfadan ayrılmış olur.

3. IoT Sensörleri ve Anomali Tespiti

Üretim tesisindeki makine, şu anda 100 derece sıcaklıkta çalışıyor. Normal sıcaklık 75 derece. Sıcaklık yükselişi, makine hasarı veya yangın riskini gösterebilir. Sistem, derhal uyarı vermelidir. Günlük batch raporunda, makine patlamış olacak.

4. Hisse Senedi Ticaret Sistemleri

Borsa, hisse senedi fiyatı her saniye değişir. Otomatik ticaret (algo trading), fiyat değişim anında (milisaniye) alım/satım kararı vermelidir.

5. Oyun İçi Etkinlikleri

Çok oyunculu oyunlarda, her oyuncu hareketi diğer oyunculara anında görülmelidir. Streaming, bu senkronizasyonu sağlar.

Streaming Gerekli Olmayan Senaryolar

Finansal Raporlama: Aylık veya yıllık mali tablolar, gerçek zamanlı olmak zorunda değildir. Batch yeterlidir.

İnsan Kaynakları Analitiği: Çalışan turnover oranı, günde bir kez raporlanabilir.

Müşteri Segmentasyonu: Müşteri grupları, periyodik olarak (aylık) yeniden hesaplanabilir.

Hükümetin kurala göre: Eğer veri bir dakika içinde işlenmeyecekse, streaming'i göz ardı edebilirsiniz.

Streaming Mimarisi: Apache Kafka

Streaming veri işlemesi, genellikle event broker aracılığıyla başlar. En popüler event broker, Apache Kafka'dır.

Kafka Nedir?

Kafka, yüksek aktarım hızında veri akışını yönetmek için tasarlanmış, dağıtılmış bir pub-sub messaging sistemidir.

Temel Konseptler:

• Topic: Veri akışının kategorisi. "satış-işlemleri" bir topic, "müşteri-giriş-çıkışları" başka bir topic.
• Producer: Topic'e veri yazan uygulama. Örneğin, e-ticaret sitesi, her işlemi "satış-işlemleri" topic'ine yazıyor.
• Consumer: Topic'ten veri okuyan uygulama. Örneğin, dolandırıcılık tespit sistemi, "satış-işlemleri"ni okuyor.
• Partition: Topic, birden fazla partition'a bölünür. Her partition, ayrı sunucuda olabilir. Bu, skalabiliteyi sağlar.

Örnek Akış:

Müşteri satın alma işlemi gerçekleştiğinde, e-ticaret uygulaması, işlemi Kafka Topic'ine ("satış-işlemleri") yazıyor. Bu topic, birden fazla partition'a (İşlem 1-1000, İşlem 1001-2000 gibi) bölünmüştür. Farklı consumer'lar, bu işlemleri okuyup kendi görevlerini yapıyor. Dolandırıcılık tespit sistemi, işlemleri kontrol ediyor, risk değerlendirmesi yapıyor. Aynı zamanda, müşteri profili güncelleyici, müşteri hakkındaki bilgileri tazeleştiriyor.

Kafka'nın avantajları:

• Yüksek Aktarım Hızı: Saniye başına milyonlarca işlem
• Dayanıklılık: Veriler kalıcı olarak saklanır, hiçbir işlem kaybı yok
• Ölçeklenebilirlik: Cluster'a sunucu ekleyerek ölçeklenebilir
• Yeniden İşleme: Eski veriler tekrar işlenebilir (gerekirse)

Dezavantajları:

• Operasyonel Komplekslik: Kafka'yı çalıştırmak zordur. Cluster yönetimi, failover, disk yönetimi
• Maliyeti: Kafka kümesi, ciddi donanım gereksinimidir

Kafka Alternatifleri

• AWS Kinesis: Yönetilen hizmet, Kafka kadar güçlü değil ama işletmesi kolay
• Google Pub/Sub: Google Cloud üzerinde yönetilen, ölçeklenebilir
• Azure Event Hubs: Microsoft Azure üzerinde
• RabbitMQ: Eski ama hala güçlü, ancak streaming için optimize değil

Stream Processing: Apache Spark Streaming

Kafka sadece veriyi taşır. Bu veriyi işlemek için, stream processing engine gerekir. Spark Streaming, bu işlemler için kullanılan en popüler araçtır.

Spark Streaming Nedir?

Spark Streaming, Kafka'dan (veya başka kaynaklardan) gelen veriyi, micro-batch adı verilen küçük toplu parçalar halinde işler. Her 1-2 saniye, bir batch oluşturulur ve işlenir.

Örnek:

Kafka'dan gelen müşteri işlemleri, Spark Streaming tarafından micro-batch halinde işlenir. Her saniye, bir batch oluşturulur ve işleme tabi tutulur. Örneğin, 0:00:00-0:00:01 arasında 10.000 işlem, 0:00:01-0:00:02 arasında 12.000 işlem, 0:00:02-0:00:03 arasında 9.000 işlem. Spark Processing Engine, bu veriler üzerinde transformasyon yaparak, dolandırıcı işlem tespiti, müşteri güncelleme, dashboard güncellemesi gibi görevleri yerine getiriyor.

Avantajları:

• Scala: Batch ve streaming aynı Spark kodu ile yazılabilir
• Güç: Kompleks veri dönüştürmeler kolay yapılabilir
• Integration: Spark ML, Spark SQL gibi kütüphaneler integre
• Yapılandırma: Birkaç satır Python/Scala kodu

Dezavantajları:

• Latency: Micro-batch yaklaşımı, gerçek true-streaming'ten daha az hızlı
• Operasyon: Spark kümesinin yönetilmesi, Kafka gibi zor

Spark Streaming Alternatifleri

• Apache Flink: True streaming (micro-batch değil), daha düşük latency
• ksqlDB: Kafka üzerinde SQL; stream processing işlemlerinin basitleştirilmiş versiyonu
• Kafka Streams: Kafka'nın kendi stream processing kütüphanesi, lightweight
• AWS Kinesis Analytics: Yönetilen, SQL-based stream processing

Event-Driven Mimari

Modern uygulamalar, event-driven mimarisine doğru gelişiyor. Her şey event'tir. Kullanıcı giriş yaptı—event. Ürün satıldı—event. Hata oluştu—event.

Event-Driven Mimarisinin Faydaları

1. Bağımlılıkları Azaltır: Sistemler, doğrudan birbirine bağlı değildir. Event broker aracılığıyla iletişim kurur. Bir sistemi değiştirmek, diğerlerini etkilemez.

2. Ölçeklenebilirlik: Yeni işlemler eklemek kolay. Satış event'ini okumak isteyen yeni bir sistem, consumer olarak eklenir. Mevcut sistem değiştirilmez.

3. Gerçek Zamanlı Veri: Tüm sistemler, en güncel veriyi alır.

Örnek Event-Driven Mimarisi:

Sipariş sistemi, bir sipariş oluşturulduğunda, "order-created" adında bir event oluşturur. Bu event, Event Broker'a (Kafka) gönderilir. Event broker, bu event'i tüm ilgili sistemlere dağıtıyor. Inventory sistemi, envanter güncelleme işlemini yapıyor. Billing sistemi, ödeme işlemini yönetiyor. Shipping sistemi, kargo gönderimi işlemini başlatıyor. Analytics sistemi, satış verilerini kaydediyor.

Her sistem, doğrudan birbiriyle konuşmaz. Event broker aracılığıyla iletişim kurulu. Bu şekilde, sistemler bağımsız ve ölçeklenebilir kalır.

Consistency ve Exactly-Once Processing

Stream processing'de, iki önemli sorun vardır:

1. Consistency (Tutarlılık): Sistemi yeniden başlatırsam, aynı event iki kez mı işlenir?

2. Latency (Gecikme): Sonuçlar, ne kadar hızlı görülebilir?

Kafka ve Spark Streaming, "exactly-once" semantiği sağlar. Her event, tam olarak bir kez işlenecektir. Sistem çöktüğünde yeniden başlatılsa bile, veriler kaybolmaz veya çoğalmaz.

Bu, maliyete neden olabilir (checkpoint'ler, state yönetimi), ama veri bütünlüğü sağlar.

Maliyet ve Karmaşıklık Analizi

Streaming mimarisi kurmanın maliyeti, önemli bir karar faktörüdür.

Kafka + Spark Clustering:

• Kafka Cluster: 3 node, her node 8 CPU, 32 GB RAM = 50.000 $/yıl
• Spark Cluster: 5 node, her node 4 CPU, 16 GB RAM = 30.000 $/yıl
• Operasyon ve Bakım: 1 DevOps Engineer = 100.000 $/yıl
• Toplam: 180.000 $/yıl

Bulut Alternatifleri:

• AWS Kinesis + Lambda: 20.000 - 50.000 $/yıl
• Google Dataflow: 15.000 - 40.000 $/yıl
• Kafka Cloud (Confluent): 30.000 - 100.000 $/yıl

Bulut, başlangıç için 3-6 kat daha ucuzdur. Ölçek arttıkça, kendi Kafka cluster'ı daha ekonomik hale gelebilir.

Streaming Maturity Nivolar

Hemen streaming'e gitmeyin. Maturity bir seviyeden diğerine geçmelidir:

Seviye 1 - Batch: Günlük raporlar, batch işlemesi. Çoğu kuruluş burada.

Seviye 2 - Scheduled Batch: Hourly batch'ler. Veri daha güncel hale geliyor.

Seviye 3 - Micro-Streaming: Spark Streaming gibi, 1-5 saniyelik latency.

Seviye 4 - True Real-Time: Kafka + Flink, milisaniye latency.

Seviye 5 - Complex Stream Processing: Stateful operations, advanced windowing.

Çoğu işletme, Seviye 2 - 3'te sabit kalmalıdır. Seviye 4-5, sadece gerçekten ihtiyaç duyulduğunda.

Gerçek Zamanlı Veri ile Makine Öğrenmesi

Stream processing, ML modellerine gerçek zamanlı veri besler. Örneğin, dolandırıcılık tespit modeli, milyonlarca işlemi saniye başına taraması gerekir.

Bu senaryolarda, feature engineering de streaming olmalıdır. Veri mühendisliğinin ML entegrasyonu hakkında daha fazla bilgi için, Veri Mühendisliğinden MLOps'a Geçiş: AI-Ready Veri Altyapısı rehberimizde, ML ve streaming'in nasıl entegre olacağını bulabilirsiniz.

Streaming mimarisi, temel veri mühendisliği disiplini kapsamında yer alır. Daha kapsamlı bilgi için, Veri Mühendisliğini Kapsamlı Rehberimiz adresini inceleyebilirsiniz.

Smart Maple ile Streaming Mimarisi

Streaming mimarisi kurmanız gerekiyorsa, Smart Maple, danışmanlık ve uygulama hizmetleri sunmaktadır.

Hizmetlerimiz:

• Streaming gereksinimlerini tanımlama (batch mi, streaming mi?)
• Kafka cluster'ı mimarisi tasarımı
• Spark Streaming pipeline'ları yazılması
• Monitoring ve alerting kurulması
• Takım eğitimi
• Operasyonel destek ve bakım

Streaming mimarisi konusunda danışmanlık almak için, Smart Maple ile iletişime geçebilirsiniz.