Gerçek zamanlı veri analitiği: katmanlar, tasarım kararları ve sık hatalar

Gerçek zamanlı analitik ne demektir, ne zaman gerekir?

Gerçek zamanlı analitik, veriyi bir dosyada ya da tabloda birikmesini beklemeden, olay oluştuğu anda işleyip sonuca dönüştürmektir. Klasik toplu işlemede veri günün sonunda ya da belirli aralıklarla işlenir; akış işlemede ise her olay geldiği anda hesaba katılır. Aradaki fark teknik olduğu kadar iş kararıyla ilgilidir: sonucun gecikmesi bir şeyi değiştiriyor mu?

Örneğin bir ödeme sisteminde şüpheli işlemi işlem tamamlanmadan yakalamak, bir üretim hattında sensör değeri eşiği aştığında hattı durdurmak ya da bir e-ticaret sitesinde stok tükenirken ürünü vitrinden kaldırmak gecikmeye tahammül etmez. Aylık satış raporu ise toplu işlemle gayet iyi çalışır. Her şeyi gerçek zamanlı yapmak maliyeti ve karmaşıklığı artırır; bu nedenle ilk soru her zaman 'bu karar ne kadar çabuk verilmeli?' olmalıdır. Kabul edilen gecikme süresi, mimarinin geri kalanını belirleyen ölçüttür.

Altyapının katmanları

Gerçek zamanlı bir analitik sistemi genellikle şu katmanlardan oluşur: • Olay alım katmanı: uygulamalardan, cihazlardan ve veritabanı değişikliklerinden gelen olayları kalıcı ve sıralı bir kayda alır. Bu katmanda Apache Kafka gibi bir mesajlaşma platformu sık kullanılır. • Akış işleme katmanı: olayları filtreler, zenginleştirir, birleştirir ve pencereler üzerinde toplar. Kafka Streams, ksqlDB ya da benzer akış motorları bu işi yapar. • Durum saklama katmanı: işlem sırasında gereken ara sonuçları (örneğin bir müşterinin son dakikalardaki işlem toplamını) saklar. • Sunum katmanı: sonucu pano, uyarı, arayüz ya da başka bir sisteme ulaştırır; sıklıkla düşük gecikmeli bir sorgu deposu kullanılır.

Bu katmanları birbirinden ayırmak, her birinin bağımsız ölçeklenmesini ve değiştirilmesini sağlar. Örneğin sunum deposu değiştiğinde olay alım tarafı etkilenmez. Tasarımın başında hangi katmanın darboğaz olacağını tahmin etmek, maliyeti de belirler.

Zaman, pencere ve geç gelen veri

Akış işlemenin en kolay yanlış anlaşılan konusu zamandır. Bir olayın oluştuğu an (olay zamanı) ile sisteme ulaştığı an (işlenme zamanı) aynı değildir. Mobil bir uygulama çevrimdışıyken biriktirdiği olayları bağlantı geldiğinde gönderebilir; hesap işlenme zamanına göre yapılırsa sonuçlar yanıltıcı olur.

Pencereleme, sonsuz bir olay akışını anlamlı dilimlere bölmenin yoludur. Sabit aralıklı pencereler her dilimi ayrı sayar, kayan pencereler dilimleri üst üste bindirir, oturum pencereleri ise kullanıcı etkinliğindeki boşluklara göre kapanır. Hangisinin seçileceği iş sorusuna bağlıdır: dakikalık sipariş sayısı ile bir ziyaretçinin oturum süresi farklı pencereler ister.

Geç gelen veri için bir tolerans süresi tanımlanmalıdır. Pencere kapandıktan sonra gelen olay ya yok sayılır, ya düzeltme olarak sonuca eklenir ya da ayrı bir kuyruğa alınır. Bu karar açıkça verilmezse, sistem sessizce hatalı sayı üretir.

Güvenilirlik: tekrar, kayıp ve sıra

Dağıtık sistemlerde mesajlar kaybolabilir, tekrarlanabilir ya da sırası bozulabilir. Teslim semantiği üzerinden düşünmek gerekir: en fazla bir kez teslim kayıp riski taşır, en az bir kez teslim tekrar riski taşır, tam bir kez işleme ise ek mekanizmalar ve bedel gerektirir. Pratikte sıklıkla en az bir kez teslim seçilir ve işlemler tekrara dayanıklı (idempotent) yazılır: aynı olay yinelenerek işlendiğinde sonuç değişmez.

Hata yönetimi tasarımında şunlar planlanır: • Okunamayan ya da şemaya uymayan olaylar için bir ölü mektup kuyruğu. • İşleme motoru çökerse son kontrol noktasından devam etmek. • Şema değişikliklerinin tüketicileri bozmaması için sürümleme kuralları. • Geriye dönük yeniden işleme: hatalı bir mantık düzeltildiğinde geçmiş olayları yeniden oynatabilmek.

Geriye dönük yeniden işleme yeteneği, genellikle olay kaydının kalıcı tutulmasına bağlıdır; bu yüzden alım katmanındaki saklama süresi bir tasarım kararıdır, ayrıntı değildir.

Örnek senaryo: sipariş akışında anomali yakalama

Kurgusal bir örnek olarak bir çevrim içi perakendeciyi ele alalım. Sipariş, ödeme ve stok olayları ayrı konulara yazılıyor. Akış işleme katmanı ödeme olaylarını müşteri kimliğiyle zenginleştiriyor, kayan bir pencerede müşteri başına işlem toplamını tutuyor ve olağandışı yükselişi bir uyarı konusuna yazıyor. Durum deposunda her müşterinin güncel toplamı duruyor; sunum katmanı bu değeri hem operasyon panosuna hem de dolandırıcılık ekibinin uyarı sistemine veriyor.

Burada kritik tasarım kararları şunlardır: pencere ne kadar geniş olmalı, yanlış alarm ile kaçırılan olay arasındaki denge nerede kurulmalı, geç gelen ödeme bildirimi sayıyı nasıl düzeltmeli ve sistem durduğunda uyarılar nasıl kaybolmadan yeniden üretilmeli? Bu soruların yanıtı teknolojiden önce iş kuralından çıkar; araç seçimi sonra gelir.

Sık yapılan hatalar

Gerçek zamanlı analitik projelerinde tekrar eden sorunlar şunlardır: • Gerekmeyen yerde gerçek zamanlı çözüm kurmak. Karar günde bir kez veriliyorsa akış altyapısı yük getirir. • Zaman semantiğini düşünmemek: işlenme zamanına göre pencere kurmak ve geç gelen veriyi hesaba katmamak. • Durum boyutunu denetlemeden bırakmak. Sınırsız büyüyen ara durum, bellek ve disk sorununa yol açar. • Tekrara dayanıklı yazmamak. Yeniden başlatma sonrası aynı olay yinelenerek sayılır. • Gözlemlenebilirliği sona bırakmak: gecikme, tüketici ilerlemesi ve hata oranı baştan izlenmelidir. • Sunum katmanını unutmak. Hızlı işlenen veri, yavaş sorgulanan bir depoda anlamını yitirir. • Maliyeti ihmal etmek: sürekli çalışan altyapı, toplu işlemden farklı bir fatura ve nöbet yükü yaratır.

Bu hataların ortak noktası, mimariyi araç tercihiyle başlatmaktır. Gereksinimden başlayan tasarım bu tuzakların çoğunu baştan önler.

Öğrenme yolu

Başlangıçta mesajlaşma sistemlerinin temelini öğrenin: konu, bölüm, üretici, tüketici ve tüketici grubu kavramları. Sonra SQL benzeri bir akış sorgusu yazarak filtreleme, birleştirme ve pencere toplamalarını deneyin. Ardından durumlu işlemeyi, zaman semantiğini ve geç gelen veri yönetimini küçük bir uygulamada uygulayın.

İleri aşamada ölçekleme, bölümleme stratejisi, hata sonrası kurtarma, şema yönetimi ve maliyet konularına geçin. Her aşamada küçük bir uçtan uca proje kurmak en etkili yoldur: olay üretici bir betik, bir akış işleme adımı ve sonucu gösteren basit bir pano. Mimariyi yalnız şemada çizmek yerine bir kez gerçekten çalıştırmak, gecikme ve hata davranışını anlamanın tek güvenilir yoludur.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Gerçek Zamanlı Analitik Altyapısı Tasarımı programı modül başlıklarına göre gereksinimlerle başlar; olay alım, akış işleme, durum saklama ve sunum katmanlarını, güvenilirlik ve hata yönetimini, maliyet, ölçekleme ve referans mimariyi kapsar. Kafka Streams ve ksqlDB ile Akış İşleme programı ise Kafka Streams topolojisi, KStream ve KTable, birleştirme ve zenginleştirme, pencereleme ve durum yönetimi, ksqlDB ile bildirimsel akış işleme ve üretime alma konularını içerir.