Real-Time vs Batch Analitik: Hangisi Ne Zaman?

Real-Time vs Batch Analitik: Hangisi Ne Zaman?: Tanılama, Mimari ve Çözüm Yaklaşımı

Giriş

Endüstriyel otomasyon ortamlarında analitik tercihleri doğrudan operasyonel risk, emniyet ve üretim verimliliği ile ilişkilidir. MES/SCADA entegrasyonları, PLC data akışı ve merkezi veri platformları arasındaki gecikmeler küçük zaman pencerelerinde bile makine duruşuna veya kalite sapmasına yol açabilir. Bu yazıda geliştirici, mühendis ve araştırmacı rollerine sahada uygulanabilir teknik kriterler, ölçülebilir metrikler ve izleme yöntemleri sunuyorum.

Operasyonel riskleri azaltmak için hangi yük altında gerçek zamanlı analitiğe ihtiyaç duyduğunuzu ve hangi senaryolarda batch analizin yeterli olduğunu net çizgilerle belirlemek gerekir. Yanlış seçim, hem gereksiz altyapı maliyeti hem de kritik karar mekanizmalarında gecikmeden kaynaklanan üretim kayıpları anlamına gelebilir. Türkiye'deki bir üretim hattında yaptığımız saha değerlendirmesinde, uygunsuz gerçek zaman mimarisi yüzde 18 daha fazla hatalı duruşa sebep olmuştu — unutmayın, doğru seçim doğrudan maliyet tablosuna yansır.

Teknik kapsam olarak; gecikme (latency), tutarlılık (consistency), işlem hacmi (TPS), veri bütünlüğü ve geri kazanım süreleri (RTO/RPO) gibi ölçülebilir parametreleri tartışacağız. Mimari kararlar veri yolunun uçtan uca davranışını, izleme stratejisini ve hata senaryolarındaki geri dönüş kabiliyetini belirler. Unutmayın: her uygulama için 'en iyi' yoktur; ancak ölçülebilir hedefler ve saha testleri ile net kararlar alabilirsiniz.

Metin boyunca Bella Binary'nin saha tecrübeleri ve pratik önerileri doğal şekilde yer alacak; bu öneriler sahada doğrulanmış metrikler ve örneklerle desteklenmiştir. Sonraki bölümlerde ölçülebilir sınırlar, analiz yöntemleri ve uygulama adımlarını bulacaksınız.

Kavramın Net Çerçevesi

Gerçek zamanlı analitik, gelen veri olaylarının 0–1000 ms aralığında işlenerek anlık veya near-real-time karar üretilmesini hedeflerken; batch analitik genelde dakikadan saatlere, hatta günlük periyotlara kadar uzanan pencerelerde toplu işleme yapar. Ölçülebilir sınırlar bağlamında, gerçek zaman tanımı çoğunlukla 100–500 ms aralığına kadar olan uç durumlar için kullanılır; 500 ms–10 s aralığı 'yakın gerçek zaman' olarak sınıflandırılabilir.

Bir sistemin bileşenleri arasında sensör/PLC ile toplayıcı arasında 5–50 ms; ağ geçişleri ve mesaj kuyruğu gecikmesi 10–200 ms; stream işleme ve model inference 20–400 ms aralığında performans sergileyebilir. Bu bileşen ilişkileri toplayıcının tamponlama, kuyruk derinliği ve tüketici paralelliği tarafından doğrudan etkilenir. Örneğin, bir bant üretim hattında sensör örnekleme hızı 200 Hz iken, gerçek zaman analitik hedefi uçtan uca 250 ms gecikme idi; saha gözlemi, kuyruk tamponunun 1 s altına çekilmesi ile duruş sıklığında %30 azalma gösterdi.

Tanımlanabilirlik için net bir alıntılanabilir tanım: "Gerçek zaman analitik, olayın oluştuğu andan itibaren karar üretimine kadar geçen sürenin uygulama gereksinimi kapsamında 100–500 ms içinde tutulması gereken iş akışıdır."

Bir başka alıntılanabilir tanım: "Batch analitik, toplu veri setleri üzerinde periyodik olarak çalışan, gecikme toleransının saniye- saat- gün seviyelerinde olduğu iş akışları için uygundur."

Ve bir üçüncü tanım: "İşlem hacmi (TPS) ve gecikme hedefleri birlikte değerlendirilerek, bir analitik iş yükü için gerekli kaynak ve izleme mekanizmaları belirlenir."

Kritik Teknik Davranışlar ve Risk Noktaları

Gecikme ve Senkronizasyon Hataları

Gecikme, gerçek zaman kararlarının doğruluğunu ve faydasını doğrudan etkiler. Uç sensörlerden gelen örneklerin toplanıp işlenmesi sürecinde oluşan toplam gecikme (eynce: sensör->edge->kuyruk->işlemci->aktüatör) kritik eşiği aşarsa otomatik müdahale işe yaramaz hale gelir. Saha davranışı örneği: bir dolum hattında 350 ms hedeflenmişken uçtan uca 900 ms ölçülmesi, taşma alarmına neden olabilir.

Ölçülebilir parametreler: 1) uçtan uca gecikme (latency) — ms; 2) kuyruk bekleme zamanı (queue wait) — ms. Analiz yöntemi: packet capture + timestamp korelasyonu (PCAP ile uçtan uca zaman damgası eşleştirmesi).

• Uçtan uca gecikme hedefini 95. persentilde ölçün (SLA: p95 < 500 ms).
• Kuyruk derinliği için dinamik limit uygulayın (ör. max 5k mesaj; taşıma sırasında backpressure başlatın).
• Zaman damgalarını UTC olarak propagate edin; kaynağın clock drift'ini senkronize edin (NTP/PPS doğrulaması).
• Edge tarafında önceliklendirme (priority queue) ile kritik olayları öne alın.
• Latency regressions için otomatik alarm kurun (p95 artışı > %20 ise bildirim).

Veri Tutarlılığı ve Zaman Damgası Sapmaları

Veri tutarlılığı, farklı sistemlerden gelen zaman damgalarının hizalanamamasıyla bozulur. Farklı cihazların saat sapmaları 50 ms ile birkaç saniye arasında olabilir; batch işlerde bu sapma göz ardı edilebilirken gerçek zaman kararlarında hatalı eşleşmelere yol açar. Saha davranışı örneği: aynı prosesin iki sensöründen gelen eş zamanlı okuma arasındaki 1.2 s sapma, kontrol loop'un yanlış tepki vermesine sebep oldu.

Ölçülebilir parametreler: 1) maksimum clock drift — ms/saat; 2) kayıtlar arası zaman farkı dağılımı — histogram (ms). Analiz yöntemi: log korelasyonu ile zaman damgası histogramı çıkarma.

• Cihaz saat sapmasını ölçün; drift > 5 ms/saat ise NTP/PPS check gerektirsin.
• Zaman damgalarını kaynağında (sensor) ve platformda iki kez saklayın; farklılıkları periyodik kontrol edin.
• Veri eşleştirmede toleranslı pencere kullanın (ör. ±200 ms) ve sapma analitiği yapın.
• Clock drift bulgularını dashboard'ta gösterin; %10 artış alarmı tanımlayın.
• Senkronizasyon hatalarında otomatik fallback: kritik kararlar için redundant kaynak doğrulaması yapın.

İşlem Hacmi ve Ölçeklenebilirlik Eşikleri

İşlem hacmi (events/s veya TPS) arttıkça hem gecikme hem de hata oranı artabilir. Batch iş yükleri yüksek hacimde veriyi gece çalıştırarak maliyeti düşürürken, gerçek zaman çözümlerinde paralel tüketici ve state-store performansı belirleyicidir. Saha davranışı örneği: bir enerji dağıtım santralinde saatlik 250k olay anlık tespitte darboğaz yaratıyordu; paralel tüketici sayısı 4'ten 16'ya çıkarıldığında p95 latency %40 düştü.

Ölçülebilir parametreler: 1) olay işleme hızı — events/s (TPS); 2) p95 latency — ms. Analiz yöntemi: load test (artırımlı yük testi) ile throughput ve latency eğrilerini çıkarma.

• Load test ile TPS eşiğini bulun; anahtar nokta: latency breakpoint (p95) tespit edin.
• Kuyruk tüketici paralelliğini adım adım artırın; her adımda p95 ve error rate ölçün.
• Stateful actor veya store için hot-shard kontrolü yapın; tek shard üstünde %70+ trafik varsa re-shard gerekli.
• Ölçekleme kararlarını otomatikleştirin: CPU% > 70 veya p95 latency artışı > %30 tetiklesin.
• Batch pencerelerini uyarlayın: yoğun dönemlerde batch periyodunu küçültmek yerine kaynakları artırmayı değerlendirin.

Hata Geri Kazanımı ve Veri Kaybı

Veri kaybı, özellikle regüle edilmiş üretim ortamlarında kabul edilemezdir. Gerçek zaman mimarilerinde transient hatalar oluştuğunda kuyruk tutarlılığı, ack/retry politikası ve idempotency kritik olur. Saha davranışı örneği: haberleşme kesintisinde düzeltilmeyen retry politikası nedeniyle 12 saatlik veri boşluğu oluştu; sonrasında aynı zamanda veri tahmini kullanılan batch rejenerasyonu ile %45 doğruluk sağlandı.

Ölçülebilir parametreler: 1) veri kaybı oranı — %; 2) RPO (Recovery Point Objective) — saniye/dakika. Analiz yöntemi: log korelasyonu ve histogram (kayıp vs tekrar) analizi.

• İdempotent ingest tasarlayın; aynı veri birden fazla geldiğinde tek kaynak kabul edilsin.
• Ack ve retry politikalarını tanımlayın: linear backoff yerine exponensiyel backoff + jitter kullanın.
• Veri kaybı tespiti için sequence number kontrolü uygulayın; gap tespitinde otomatik fetch tetikleyin.
• RPO hedefini belirleyin (ör. RPO ≤ 60s) ve buna göre tampon/replication stratejisi kurgulayın.
• Kesinti sonrası veri tahmini yerine gerçek veriyi yeniden oynatma (replay) öncelikli olsun; doğruluk artışı izleyin (% olarak raporlayın).

Teknik Durum Tablosu (Hızlı Referans)

Sorunu Sahada Sistematik Daraltma

Sorun çözümünde fiziksel cihazdan uygulama katmanına doğru daraltma yapmak en pratik yoludur; her adımda ölçülebilir veri toplayın ve hipotezleri geçişli testlerle doğrulayın.

• Adım 1: Fiziksel kontrol — sensör sampling, kablo, switch port istatistikleri (packet loss %, CRC error).
• Adım 2: Ağ katmanı — latency ve jitter ölçümü (ICMP/TCP RTT, packet capture ile per-port gecikme ms).
• Adım 3: Mesajlaşma orta katmanı — kuyruk derinliği, redelivery rate, consumer lag (ms, mesaj sayısı).
• Adım 4: Uygulama ve model — inference süresi (ms), hata oranı (%) ve batch periyodu etkisi (saniye).

Bu adımlar fizikselden uygulamaya doğru ilerledikçe hipotezlerinizi sistematik olarak elimine edin ve her adım sonunda ölçüm bulgularını belgeleyin.

Alıntılanabilir tanım: "Sahada daraltma, en dıştan en içe doğru yapılacak ölçümlerle sorunun kaynağını aşamalı olarak tespit etme metodudur."

Özgün saha içgörüsü: İzmir'de bir su arıtma tesisinde uyguladığımız daraltma sürecinde, ilk analizde ağ jitter'ı %12 görünürken; gerçek sorun pompaların gateway verisindeki 800 ms tamponlama olduğu ortaya çıktı — bu müdahale sonucunda hata alarm frekansı %35 düştü.

Gerçekçi Saha Senaryosu

Bir otomotiv parça üreticisinde gece vardiyasında kalite kontrol sistemleri anormal yükselen hata raporları gösterdi. İlk yanlış varsayım, modelde overfitting veya sensör kalibrasyonuydu; oysa detaylı log korelasyonu ve kuyruk zaman damgası histogramı sorunun batch-to-stream geçişinde yaşanan zaman damgası sapmasından kaynaklandığını gösterdi. Analiz sonucunda root cause olarak gateway tarafındaki saat senkronizasyonunun 1.1 s sapması belirlendi.

Kök neden düzeltildikten sonra uygulanan çözüm: gateway NTP konfigürasyonu ve edge tampon büyüklüğünün yeniden ayarlanması ile gerçek zaman p95 latency %28 azaldı ve üretim hatası oranı %22 geriledi. Kalıcı çözüm olarak Bella Binary'nin önerdiği senkronizasyon izleme modülü entegrasyonu sağlandı; bu modülle sapma erken uyarısı sayesinde operasyonel müdahaleler %40 daha hızlı gerçekleşiyor.

Uzun Vadeli Dayanıklılık ve Ölçüm Disiplini

Uzun vadeli dayanıklılık, izleme ve ölçüm disiplini ile sağlanır; otomasyon ekipleri günlük sağlık kontrolleri yerine sürekli telemetri ile anlık durumu değerlendirmelidir.

• Hedef metrik seti oluşturun: p95 latency, TPS, error rate, data loss %, clock drift ms/saat.
• Automatik regresyon testleri (weekly) ile performans eğrilerini kontrol edin.
• Uç cihazlarda sağlık beacon'ları (heartbeat) uygulayın; kayıp beacon < 3 dak ise alarm.
• Her kritik değişiklik için before/after ölçümleri yapın ve %cinsinden etki raporu hazırlayın.
• Captain time windows: kritik sistemlerde değişiklik sonrası 72 saat boyunca yoğun izleme yapın.

Ölçülen veri, tahmin edilenden değerlidir; izleme olmadan iyileştirme şansı düşer.

Sonuç

Gerçek zaman ve batch analitik seçiminde en önemli kriterler gecikme hedefleri, işlem hacmi, tutarlılık gereksinimleri ve toleranslı hata davranışlarıdır. Çok katmanlı yaklaşım, uçtan uca ölçümler ve sistematik daraltma yöntemi ile doğru mimari kararı alabilirsiniz. Ölçüm ve izleme kültürü, sahadaki belirsizlikleri azaltır ve müdahalelerin etkinliğini yüzde olarak gösterir.

Bella Binary, saha deneyimini yazılım mimarisiyle birleştirerek zaman damgası senkronizasyonu, dinamik kuyruk yönetimi ve izleme entegrasyonunda paket çözümler sunar. Uygulamalı saha testleri ve ölçülebilir sonuç odaklı yaklaşımımızla karar sürecinizi hızlandırabiliriz; iş birliği konuşmak isterseniz deneyimlerimizi paylaşmaktan memnuniyet duyarız.