Saniyede 500.000 işlemi izleyen bir ödeme sistemi hayal edin. Batch işleme ile bu verinin anlamlı hale gelmesi için saatlerce beklemek zorunda kalırsınız. Ama gerçek zamanlı veri akışı mimarisinde, dolandırıcılık tespiti 200 milisaniyenin altında gerçekleşiyor — işlem onaylanmadan önce. Fark, salt teknik değil: bu, iş kararlarının hangi hızda alınabildiğini belirliyor.
Batch’ten Stream’e: Farkı Anlamak
Geleneksel ETL (Extract-Transform-Load) boru hatları veriyi biriktirir, periyodik olarak işler. Hadoop MapReduce bu modelin sembolüdür. Gerçek zamanlı akış ise veriyi olay-olay (event-by-event) işler; gecikme saniyelerin, hatta milisaniyelerin altına iner. İkisi birden aynı sistemde çalışabilir — bu hibrit yaklaşıma Lambda Mimarisi denir.
Lambda Mimarisi’nde batch katmanı tarihsel veriyi yeniden işleyerek referans değerleri üretir; hız katmanı (speed layer) son birkaç saatin verisini gerçek zamanlı işler; servis katmanı ikisini birleştirip sorguları karşılar. Netflix bu mimariyle öneri sistemini çalıştırdı; ancak karmaşıklığı sebebiyle 2015’te Kappa Mimarisine geçti.
Kappa Mimarisi: Sadeleşme
Kappa Mimarisinde tek bir akış işleme motoru var. Tarihsel veri de bir akış gibi tekrar oynatılır (replay). LinkedIn’in Jay Kreps’in önerdiği bu yaklaşım, iki ayrı kod tabanı tutma karmaşıklığını ortadan kaldırır. Apache Kafka’nın log saklama özelliği sayesinde — varsayılan 7 gün, yapılandırılabilir — tarihsel yeniden işleme mümkün hale gelir.
Hangi mimariyi seçeceğiniz büyük ölçüde gecikme gereksinimlerine ve tarihsel yeniden işleme sıklığına bağlı. Saatlik raporlama yeterliyse Lambda daha az risklidir. Milisaniye gecikmesi kritikse ve mantık zamanla değişmiyorsa Kappa daha temiz.
Temel Bileşenler ve Araç Seçimleri
Gerçek zamanlı bir akış mimarisinin katmanları şöyle sıralanır:
- Mesaj aracısı (message broker): Apache Kafka endüstri standardı. Saniyede milyonlarca mesaj, partisyon başına sıralı teslim, consumer group desteği. Alternatif: Amazon Kinesis (yönetilen servis, AWS ekosistemi içinde). Kafka’nın güçlü yanı: bir konuya (topic) birden fazla consumer bağlanabilir, veri kaybolmaz.
- Akış işleme motoru: Apache Flink, tam durum yönetimi (stateful processing) ve tam-tam-bir-kez (exactly-once) semantiği sunar. Apache Spark Structured Streaming micro-batch tabanlı; gerçek anlamda stream değil ama ekosistemi zengin. Küçük ölçekte Apache Storm veya Kafka Streams yeterli.
- Depolama: İşlenmiş veri için Apache Druid veya ClickHouse (OLAP sorgular, alt-saniye yanıt). Ham akış logları için nesne depolama (S3, GCS) + Parquet formatı.
Durum Yönetimi: Akış İşlemenin En Zorlu Kısmı
Stateless işleme basittir: her olay bağımsız. Ama çoğu gerçek senaryo durum gerektirir: kullanıcı son 5 dakikada kaç işlem yaptı? Ortalama sipariş tutarı nedir? Bu sorular, motorun önceki olayları hatırlamasını zorunlu kılar.
Apache Flink, durumu RocksDB’de yerel olarak saklar ve checkpoint mekanizmasıyla dağıtılmış dosya sistemine (HDFS, S3) periyodik yazar. Bir düğüm çökerse, son checkpoint’ten kaldığı yerden devam eder. Bu kurtarma süresi — RTO (Recovery Time Objective) — Flink’te genellikle birkaç saniyeyle ölçülür.
Zaman Pencereleri ve Geç Gelen Veri
Akış işlemede iki farklı zaman var: event time (olayın gerçekte ne zaman yaşandığı) ve processing time (sistemin olayı ne zaman işlediği). Mobil uygulamalar çevrimdışı dönemde veri üretir; ağa bağlandığında bu olaylar gecikmeli gelir. Event time pencereleri kullanıyorsanız bu geç gelen olayları bir tolerans süresi boyunca (watermark) beklemeniz gerekir.
Flink’in watermark mekanizması şunu sorar: “Bu olayın event time’ından X saniye geçti mi?” Geçtiyse pencereyi kapatır; geç gelen olayları ya reddeder ya da ayrı bir yan çıktıya (side output) yönlendirir. X değerini doğru ayarlamak deneyim ister — çok kısa tutarsanız veri kaybı, çok uzun tutarsanız gecikme artar.
İzleme ve Gözlemlenebilirlik
Gerçek zamanlı sistemlerde izleme, batch sistemlerine kıyasla çok daha kritik. Consumer lag — Kafka’daki mesaj sayısı ile consumer’ın işlediği mesaj sayısı arasındaki fark — gecikmenin en doğru göstergesidir. Bu metriği Prometheus + Grafana ile izlemek standarttır; lag belirli bir eşiği aştığında otomatik uyarı tetiklenmeli.
Bunların dışında throughput (saniyedeki mesaj sayısı), işleme gecikmesi (processing latency) ve checkpoint süresi düzenli olarak ölçülmeli. Bir Flink checkpoint’i normalde 30 saniyenin altında tamamlanıyorsa sorun yoktur; süre dakikalara uzarsa durum boyutu veya disk I/O araştırılmalıdır.
Ne Zaman Gerçek Zamanlı Mimari Kurmaya Değer?
Her sistem gerçek zamanlı veri akışını hak etmiyor. Kurulum maliyeti, operasyonel karmaşıklık ve ekibin öğrenme eğrisi göz önüne alındığında, saniyelik veya dakikalık gecikmenin iş süreçleri üzerinde anlamlı bir etkisi olmayacaksa batch işleme tercih edilmelidir. Gerçek zamanlı mimari şu senaryolarda kendini haklı kılar: anlık dolandırıcılık tespiti, dinamik fiyatlandırma, canlı kullanıcı davranışı analizi ve operasyonel izleme. Diğer durumlar için Spark batch veya dbt + veri ambarı çoğunlukla daha az riskli ve daha az maliyetlidir.
