Streaming vs batch: musluk vs kova

İki Farklı Zaman Modeli

Veri mühendisliğinde iş yükünün zaman modeli, tüm mimariyi şekillendirir. İki uç nokta:

• Batch processing: veri birikir, zamanı gelince toplu işlenir.
• Stream processing: veri geldiği anda işlenir, ara durum sürekli güncellenir.

Arada micro-batch var (Spark Streaming, Kafka Streams KTable): sabit zaman pencerelerinde küçük batch’ler çalıştırır. Pratikte çoğu “gerçek zamanlı” ihtiyaç 1-5 dakikalık micro-batch ile çözülür.

Latency: Dağılım Önemli

Latency tek bir sayı değildir, bir dağılımdır. SLA (hizmet seviyesi anlaşması) yazarken percentile kullanılır:

• p50 (medyan): kullanıcıların yarısı bundan hızlı cevap alıyor.
• p95: en yavaş %5’in eşiği.
• p99: en kötü %1. Genelde asıl SLA buraya bağlanır.

Batch raporunun latency’si saatler mertebesinde (p99 ≈ 4 saat). Streaming sisteminin p99’u 200 ms olabilir. Bu fark 300.000 kat.

Throughput ile latency takas edilir (trade-off):

• Daha düşük latency istiyorsan daha fazla kaynak (CPU, RAM, network) ayırman gerekir.
• Daha yüksek throughput istiyorsan batch’in büyük boyutunu artırırsın, ama latency artar.

Ne Zaman Streaming?

Şu sorular gerçek zamanlı ihtiyacı işaret eder:

1. Olay anında bir karar tetikliyor mu? (Dolandırıcılık tespiti, alarm)
2. Kullanıcı bir değerin şu anki halini mi görüyor? (Stok adedi, canlı skor)
3. Veri zamana duyarlı mı? (5 dakika geç kalırsan değeri düşüyor)
4. Toplam hacim çok yüksek ve tek seferde işlenemiyor mu?

Bunların hiçbiri yoksa batch yeter. Yıllık rapor, aylık fatura, haftalık segmentasyon = batch. Çoğu kurumsal veri yükü hâlâ batch’tir.

State: Akan Hesapların Hafızası

Streaming’in en zor kısmı state yönetimi. Akan veride “şu ana kadar kaç sipariş geldi” gibi soruları cevaplamak için motorun bir state store tutması gerekir. Flink bunu RocksDB üzerinde tutar (yerel disk + incremental checkpoint).

State iki soru çıkar:

1. Checkpoint: motor çökerse state’i nasıl kurtarır? Periyodik olarak state’in anlık görüntüsü alınır (örn. her 10 saniye) ve HDFS / S3’e yazılır.
2. Exactly-once: bir olay işlenip motor çökerse, kurtarma sonrası aynı olayı tekrar işlemesin mi? Çoğu stream motoru (Flink, Kafka Streams) exactly-once garantisini checkpoint + transactional sink ile sağlar.

Hibrit Mimari: Lambda / Kappa

İki yaygın hibrit desen:

Lambda mimarisi (Nathan Marz):

                Tüm olaylar
                    │
        ┌───────────┴───────────┐
        ▼                       ▼
  [Batch layer]           [Speed layer]
  tüm veri, doğru,        son veri, hızlı,
  yavaş (günlük)          yaklaşık (anlık)
        │                       │
        └───────────┬───────────┘
                    ▼
              [Serving layer]
              sorgu servisi

• Batch layer: tüm geçmişi doğru işler (HDFS, Spark).
• Speed layer: sadece son veriyi hızlı işler (Storm, Flink).
• Serving layer: iki katmanın sonucunu birleştirip sunar.

Kappa mimarisi (Jay Kreps, Kafka’nın yazarı):

   Tüm olaylar → Kafka (tek günlük)
                     │
                     ▼
             Stream processor
              (Flink / Kafka Streams)
                     │
                     ▼
             Serving (kafka-backed)

Tek katman: akan veri. İhtiyaç halinde aynı olayları baştan tekrar işletirsin (replay). Lambda’nın çift kod tabakası yok.

Pratik ipucu: Çoğu ekip Lambda ile başlar, olgunlaşınca Kappa’ya geçer. İlk projede micro-batch ile Lambda yapısı kurmak yeterli.

Gecikme ve Throughput Kodla

Python’da aynı işi batch ve streaming olarak yazıp farkı görmek:

import time
from collections import Counter

# --- BATCH ---
def batch_isle(olaylar):
    return Counter(olaylar)             # tüm liste elimizde, say

# --- STREAMING (state tutarak) ---
def stream_isle(initial_state=None):
    state = Counter(initial_state or {})
    def ilerlet(olay):
        state[olay] += 1                 # her olayda güncelle
        return dict(state)
    return ilerlet

# Demo
counter = stream_isle()
for olay in ["a", "b", "a", "c", "a", "b"]:
    print(f"olay={olay} → state={counter(olay)}")

Çıktı:

olay=a → state={'a': 1}
olay=b → state={'a': 1, 'b': 1}
olay=a → state={'a': 2, 'b': 1}
olay=c → state={'a': 2, 'b': 1, 'c': 1}
olay=a → state={'a': 3, 'b': 1, 'c': 1}
olay=b → state={'a': 3, 'b': 2, 'c': 1}

Batch fonksiyonu tüm listeyi ister; streaming fonksiyonu tek tek olay alır, state’i kendi taşır. Gerçek projede state bir veritabanında veya RocksDB’de yaşar, motor çökerse kurtarılır.

Özet

Bugün öğrendik:

• Latency bir dağılımdır; SLA yazarken p95 / p99 kullanılır.
• Batch: biriktir, zamanı gelince işle. Çoğu iş yükü için yeterli.
• Streaming: olay geldiği anda işle. State ve checkpoint ile exactly-once sağlanır.
• Lambda: iki katman (batch + speed). Kappa: tek katman (akan).
• Micro-batch: çoğu “gerçek zamanlı” ihtiyaç için yeterli, karmaşık motor gerekmez.

Alıştırma

1. Yukarıdaki batch_isle ve stream_isle kodunu 100 rastgele olayla çalıştır, sonuçları karşılaştır.
2. Bir senaryo seç (e-ticaret, IoT sensör, finansal işlem). Hangi yöntemi seçerdin, neden?
3. Lambda ve Kappa arasında seçim yapman gereken bir karar ağacı yaz (3+ soru).

Sıradaki

Zaman modelini seçtik. Şimdi akan veriyi nerede tutacağız: Kafka, Redpanda ve Avro geliyor →