Akış

Akış Nedir

Akış, sonsuz olay dizilerine (işlem günlüğü, tıklamalar, ödemeler, telemetri), minimum gecikme ve durumların doğru olduğunun garantisi ile sürekli bir tepkidir. "Dönem boyunca biriken tüm verileri aldığımız" partinin aksine, akış verileri geldiği gibi işler, durumu korur ve olayın zamanını dikkate alır.

Anahtar kavramlar

Event, 'event _ time've benzersiz' event _ id'ile değişmez bir gerçektir.
Olay zamanı ve işlem süresi - birincisi kaynaktan gelir, ikincisi - operatör olayı gerçekten gördüğünde.

• Yuvarlanma, Sıçrama/Kayma, Oturum.
• Filigranlar - "T'den önceki olaylar zaten geldi", pencereleri kapatmanıza ve geç verilerin beklenmesini sınırlamanıza izin veren bir değerlendirme.
• Gecikme - geçerli filigrandan daha az 'event _ time' içeren olaylar; Bitirme kuralları sıklıkla uygulanır.
• Durum - toplama, birleştirme, veri tekilleştirme için yerel tablolar/anahtarlı durum.
• Geri basınç - aşağı akış verimi aşıldığında basınç; Protokol ve tamponlar tarafından kontrol edilir.

Mimari temel

1. Kaynak: olay komisyoncusu (Kafka/NATS/Pulsar), DB'den CDC, kuyruklar, dosyalar/günlük toplayıcıları.
2. Akış motoru: pencereleri, agregaları, joynları, desenleri (CEP) hesaplar, durumu ve kontrol noktalarını yönetir.
3. Lavabo: OLTP/OLAP veritabanı, arama motoru, önbellek, konular, vitrinler/raporlar için depolar.
4. Şema kaydı: yük evrimini ve uyumluluğunu kontrol eder.
5. Gözlemlenebilirlik: metrikler, izleme, günlükler, gecikme panoları ve filigranlar.

Zaman semantiği ve düzen

Her zaman olay zamanını tercih edin: bu, gecikmeler ve kesintiler için tek değişmezdir.
Olaylar düzenden çıkabilir; Sipariş sadece parti anahtarı içinde garanti edilir.

• Pencereleri kapatın ve sonuç verin;
• "Ne kadar beklediğimizi sınırla" gecikmeli olaylar ('allowed _ lateness').
• Geç olaylar için, retractions/upserts kullanın: agregaların ve düzeltici olayların yeniden hesaplanması.

Durum ve güvenilirlik

Anahtarlı durum: toplamların (toplamlar, sayaçlar, veri tekilleştirme yapıları) verileri anahtarlarla karıştırılır.
Checkpoint/Savepoint - kurtarma için periyodik durum anlık görüntüleri; savepoint - kod sürümü geçişleri için yönetilen anlık görüntü.

• İşlemsel "okuma-işlenmiş-yazma" (commit sink + okuma pozisyonu);
• Idempotent lavabolar (upsert/merge) + veri tekilleştirme tabloları;
• Toplamaları sürümleştirerek (iyimser eşzamanlılık).

Windows, toplama, katılma

• Yuvarlanma: basit periyodik raporlar (dakika, saat).
• Atlama/Kayma: "Kayma" metrikleri (1 dakikalık artışlarla 5 dakika içinde).
• Oturum: özel oturumlar ve anti-dolandırıcılık için doğal.
• Toplama: toplam/sayım/avg/yaklaşık-farklı (HyperLogLog), yüzdelik (TDiggest/CKMS).
• Stream-Stream birleşimi: her iki tarafın da anahtar ve zamana göre tamponlanmasını gerektirir, 'allowed _ skew'a saygı gösterin.
• Stream-Table join (KTable) - Bir dizin veya geçerli durum ekler (örneğin,'aktif kullanıcı sınırları ").

Gecikmeli ve yinelenen verilerle çalışma

Veri tekilleştirme: 'event _ id' veya '(producer_id, sıra)'ile; "Seen" tuşlarını TTL ile yineleme penceresinin ≥ saklayın.
Geç olaylar: Kapattıktan sonra 'X' için işlem sonrası pencereye izin verin (geri çekme/upserts).
Yanlış çoğaltmalar: agregaları idempotently olarak ayarlayın ve günlüklerdeki "ALREADY_APPLIED" düzeltin.

Ölçek ve performans

Anahtar sharding: paralellik sağlar; Sıcak tuşlara dikkat et.
Backpressure: paralelliği sınırlayın, yayınlarken toplu iş ve sıkıştırma kullanın.
Filigranlar: Çok agresif olmayın - sert filigranlar beklentiyi azaltır, ancak geç güncellemelerin oranını artırır.
Durum: Boyut ve erişim kalıplarını dikkate alarak formatı (RocksDB/state store/in memory) seçin; TTL'yi temizle.
Otomatik ölçekleme: gecikmeye göre, CPU, durum boyutu, GC süresi.

Güvenilirlik ve yeniden başlatmalar

Idempotent lavabo veya ofset sabitleme ile yapılan işlem, doğruluğun temelidir.
Yeniden başlattıktan sonra yeniden işleme izin verilir; Etki "tam olarak bir kez" kalmalıdır.
DLQ/otopark: sorunlu kayıtları nedenleri olan ayrı bir konuya gönderin; yeniden işleme sağlar.

Gözlemlenebilirlik (neyin ölçüleceği)

Kaynağa göre gecikme (zamana ve mesaja göre).
Filigran/geçerli olay zamanı ve geç olayların oranı.
Verim/gecikme operatörleri, p95/p99 uçtan uca.
Durum boyutu/rocksdb I/O, kontrol noktası hızı/süresi.
DLQ oranı, veri tekilleştirme/yeniden ödeme yüzdesi.
CPU/GC/yığın, duraklatma süresi.

Güvenlik ve uyumluluk

Veri sınıflandırması: PII/PCI'yı diyagramlarda işaretleyin, minimumu saklayın, durumu ve anlık görüntüleri şifreleyin.
Erişim denetimi: Konu/durum tabloları ve lavabolar için ayrı ACL'ler.
Retentions: Yasal gerekliliklerle uyumlu (GDPR/unutulma hakkı).
Denetim: log 'event _ id', 'trace _ id', sonuç: 'APPLIED/ALREADY _ APPLIED/RETRIEVED'.

Uygulama kalıpları

1. CDC - normalleştirme - etki alanı olayları: ham veritabanı değişikliklerini yayınlamaz, anlaşılabilir iş gerçeklerine göre haritalandırır.
2. Üreticiler için çıkış kutusu: işlem gerçeği + olay - bir veritabanı işleminde.
3. Core vs Zenginleştirilmiş: kritik akışta minimum yük, zenginleştirme - asenkron.
4. Yeniden oynatma dostu: Projeksiyonlar/vitrinler kütükten yeniden birleştirilmelidir.
5. Tasarım gereği idempotency: operation/event key, uppert şemaları, agrega versiyonları.

Test etme

Birim/Özellik tabanlı: kümelerin ve dönüşümlerin değişmezleri.
Akış testleri: sıra dışı ve kopyalarla sabit olay akışı - pencere ve veri tekilleştirme kontrolleri.
Altın pencereler: referans pencereler/kümeler ve izin verilen geç ayarlamalar.
Hata enjeksiyonu: "Kaydedilen etki've" taahhüt edilen ofset "arasında düşüş.
Yeniden oynatma testleri: log = current durumunun başlangıcından itibaren vitrinin yeniden birleştirilmesi.

Maliyet ve optimizasyon

Windows ve filigran gecikmeyi/kaynakları etkiler: pencere ne kadar uzun olursa ve 'izin verilen _ gecikme'ne kadar büyük olursa, durum o kadar büyük olur.
Codec ve sıkıştırma: CPU/ağ dengesi.
Toplu üretim çıktısı: daha az ağ çağrısı ve işlemi.
Erken filtreleme ("pushdown"): fazlalığı kaynağa mümkün olduğunca yakın atın.

Antipatterns

Olay zamanının gerekli olduğu işlem süresine bağlayın - yanlış analiz.
Lavaboda idempotency eksikliği - yeniden başlatmalarda çift etkiler.
Küresel "mega-anahtarlar": sıcak bir bölüm paralelliği kırar.
Halka açık olaylar olarak ham CDC'ler: sızdırılmış DB şemaları, evrimde kırılganlık.
DLQ yok: "Zehirli" mesajlar tüm boru hattını bloke eder.
Filigran yerine sabit sabit gecikme: ya sonsuz bekleme ya da veri kaybı.

Etki alanı örnekleri

Ödemeler/Finans

Akış 'ödeme. ', anti-dolandırıcılık için pencereler (oturum + CEP),' operation _ id'ile büyükbaba.
Muhasebe defterine gönderildiğinde tam bir kez etkisi (uppert + sürüm).

Pazarlama/Reklamcılık

TO/dönüşümlerin sürgülü pencereleri, '± Δ t' toleransı ile tıklama ve gösterimlere katılın, teklif için toplama.

iGaming/online hizmetler

Gerçek zamanlı denge/sınırlar, görevler/başarılar (oturum pencereleri), dolandırıcılıkla mücadele kalıpları ve uyarıları.

Mini şablonlar (sözde kod)

Filigranlı pencere ve geç güncellemeler

pseudo stream
.withEventTime(tsExtractor)
.withWatermark(maxAllowedLag=2m)
.window(TUMBLING, size=1m, allowedLateness=30s)
.keyBy(user_id)
.aggregate(sum, retractions=enable)
.sink (upsert_table )//idempotent upsert by (user_id, window_start)

Ofset fiksasyonlu işlemsel lavabo

pseudo begin tx upsert target_table using event, key=(k)
update consumer_offsets set pos=:pos where consumer=:c commit

Üretim kontrol listesi

• Olay zamanı ve filigran stratejisi tanımlanmış; Pencereler ve 'allowed _ lateness' seçilir.
• Idempotent lavabo veya işlem ofset ile taahhüt.
• Şema kayıt defteri ve uyumluluk modları etkinleştirildi; Katkı evrimi.
• Metrikler: gecikme, filigran, p95/p99, DLQ, durum boyutu, kontrol noktası süresi.
• Testler: sıra dışı, kopyalar, yeniden başlatılır, tekrar oynatılır.
• Devlet ve anlık görüntüler için PII/saklama politikaları.
• Ölçeklendirme planı ve geri basınç stratejileri.
• Pencere sözleşmelerinin ve düzeltmelerin belgelenmesi (geç güncellemeler).

SSS

Etkinlik süresi gerekli mi?
Metriklerin doğruluğu ve tutarlılık önemliyse, evet. İşlem süresi teknik hesaplamalar/izleme için uygundur, ancak analitiği bozar.

Tam olarak bir kez gerekli mi?
Nokta: kritik etkiler için. Daha sık, en az bir kez + idempotent lavabo yeterlidir.

Pencereler nasıl seçilir?
İş SLA'ları üzerine inşa edin: "Son 5 dakika -" atlama ", kullanıcı oturumları -" oturum ", dakika raporları -" yuvarlanma.

Geç verilerle ne yapmalı?
Sınırlı 'allowed _ lateness'e izin verin ve ayarlamalar yapın (upsert/retract). Müşteri vitrini güncellenebilmelidir.

Toplam

Düşük gecikmenin yanı sıra, akış zaman, koşul ve sözleşmelerin bir disiplinidir. Doğru etkinlik zamanı, pencere ve filigran seçimi, ayrıca idempotent efektler, gözlemlenebilirlik ve testler boru hattını güvenilir, tekrarlanabilir ve ekonomik hale getirir ve işletmelere her gece değil, burada ve şimdi çözümler sunar.