Akışlı Veri Hatları (Streaming Pipelines): Geri Basınç Tuzağı

Veri Platformu streaming, kafka

Akışlı veri hatları tüketici üreticinin gerisinde kalana kadar sorunsuz çalışır. Veri kaybetmeden veya kaynağı kilitlemeden geri basıncı yöneten desenler.

  • Yazar: Orzed Team
  • 1 dk okuma
Önemli çıkarımlar
  • Tüketici gecikmesi (consumer lag) en kritik metriktir; toplam olarak değil bölüm (partition) bazında takip edin.
  • Düşürme (drop) politikaları, yük altında hangi veriden vazgeçileceğine dair önceden verilmiş açık kararlar gerektirir.
  • Deterministik örnekleme (sampling), veri hacmini azaltırken istatistiksel doğruluğu korur.
  • Kaynağı yavaşlatma deseni yalnızca üretici sizin kontrolünüzdeyse çalışır; dış webhook'lar yavaşlatılamaz.

Uygulamalarından analitik veri ambarına saniyede 80.000 olay aktaran Kafka tabanlı bir veri hattı altı ay boyunca sorunsuz çalışmıştı. Trafik %30 arttığında Spark Streaming tüketicisi geride kalmaya başladı ve Kafka gecikmesi (lag) sessizce tırmandı. Birisi fark ettiğinde gecikme 14 saate ulaşmıştı; analitik ekibi üzerinde “canlı” yazan panellerde aslında yarım gün önceki verilere bakıyordu.

Çözüm Kafka kümesini büyütmek veya tampon boyutunu artırmak değildir; tüketici sürekli olarak üreticiden yavaşsa her boyuttaki tampon er ya da geç taşar. Çözüm, bölüm (partition) bazında tüketici gecikmesini izlemek ve yük altında devreye girecek üç geri basınç (back-pressure) deseninden birini baştan seçmektir:

Üç Geri Basınç Deseni: Düşür, Örnekle ve Yavaşlat

  1. Düşük değerli olayları düşür (Drop): Tüm olaylar eşit değerde değildir. Üretici tarafında olayları önceliklendirip yüksek öncelikli denetim ve finans olaylarını ayrı bir konuya (topic), hata ayıklama (debug) ve tıklama olaylarını ayrı bir konuya yönlendirin. Yük altında düşük öncelikli akış geride kalsa bile kritik veriler etkilenmez.
  2. Deterministik örnekleme yap (Sample): Analitik ve izleme toplamları için her olayı işlemek şart değildir. Saniyede 80.000 olayı hash(event.id) % 100 < 10 kuralıyla %10 oranında deterministik örneklediğinizde, tüketici saniyede 8.000 olayla rahatça başa çıkar ve istatistiksel doğruluk korunur.
  3. Kaynağı yavaşlat (Slow): Üretici kendi kontrolünüzdeki bir iç servisse, Reactive Streams veya Kafka max.in.flight.requests mekanizmalarıyla tampon dolduğunda üreticiyi yavaşlatın. Ancak bu yaklaşım yavaş bir analitik tüketicisinin kullanıcıya dönük web uygulamasını da yavaşlatacağı anlamına gelir; yalnızca veri kaybının yavaşlamadan daha tehlikeli olduğu senaryolarda kullanılmalıdır.

Bölümleme (partitioning) yaparken “sıcak bölüm” (hot partition; tek bir büyük müşterinin tüm trafiği tek bölüme yığması) oluşmadığından ve alt veri ambarının paralel yazmaları kaldırabildiğinden emin olun.

Sıkça sorulanlar

Sıkça sorulan sorular

Kabul edilebilir bir tüketici gecikmesi (consumer lag) ne kadardır?

Kullanım senaryosuna bağlıdır. Gerçek zamanlı paneller için 30 saniyenin altı, analitik ETL hatları için 30 dakikanın altı, denetim logları için birkaç saat makuldür. Tüketici bazında açık bir SLA belirleyin.

Paralellik için her zaman bölümleme (partitioning) yapmalı mıyız?

Her zaman değil. Bölümleme tüketici yatay ölçeklenebildiğinde faydalıdır; ancak olayların küresel sırası kritikse veya tek bir veritabanı darboğazı varsa bölüm sayısını artırmak sorunu çözmez.

Ne zaman olay kaynaklı (event sourcing) mimariye geçmeliyiz?

Durum değişikliklerinin denetim izi mevcut durumun kendisinden daha değerli olduğunda. Event sourcing bir veri hattı dar boğaz çözümü değil, ağır sonuçları olan bir veri modelleme tercihidir.