Mimari, çevrimiçi sunumu çevrimdışı eğitim endişelerinden kesin bir şekilde ayıran çift deposu modelini kullanıyor. Çevrimiçi katman, her bölgede NVMe destekli örnekler üzerinde dağıtılmış Redis Cluster kullanırken, yerel yük dengelemesi ve TLS sonlandırması için Envoy Proxy ile önceden yapılandırılmıştır. Özellik güncellemeleri, operasyonel veritabanlarından değişiklik yakalama (CDC) bağlantılarıyla Apache Kafka aracılığıyla akar ve bunlar bölgesel Redis tüketicilerine akıtılır.
Çevrimdışı depolama için, geçmiş özellikler S3 üzerinde Apache Iceberg tablolarına sıkıştırılır ve zaman yolculuğu sorguları ile verimli toplu işlem için Apache Spark aracılığıyla işlem yapılır. Geri besleme sırasında tutarlılık, her özellik değerinin bir mantıksal zaman damgası taşıdığı vektör saat versiyonlaması ile sağlanır ve Redis Lua betikleri, sıralı yazımları reddedecek şekilde atomik karşılaştırma ve değiştirme işlemleri gerçekleştirir, böylece sunum yolu asla kısmi geri besleme durumlarını gözlemlemez.
Kayma tespiti, özellik dağılımları üzerinde gerçek zamanlı istatistiksel analiz yapan bir Apache Flink işinde kazanç ile çekilen Prometheus histogramlarını kullanır. KL-erişimi veya nüfus stabilite endeksi belirli eşikleri aştığında, Flink bölgeler arası model yeniden eğitilmesi ve canary dağıtımları düzenlemek için Argo Workflows tetikler.
Uluslararası bir fintech şirketinin, AWS, Azure ve yerinde veri merkezlerinde gerçek zamanlı dolandırıcılık tespiti yeteneklerine ihtiyacı vardı. Kritik zorluk, gerçekleme noktalarına son 1 saat içindeki kullanıcı işlem hızı gibi kayan toplama özellikleri sunurken 5 ms'den az bir gecikme ile hizmet sunmaktı. Mevcut PostgreSQL okuma çoğaltıcıları, zirve yükler sırasında 200 ms'yi aşan çoğaltma gecikmesi yaşadı, bu da dolandırıcılık puanlama modellerinin eski verilerle çalışmasına neden oldu ve koordine saldırıları yakalayamadı.
Çözüm 1: Küresel Aktif-Aktif Veritabanı CockroachDB veya Google Spanner kullanımı, serileştirilebilir yalıtım ve otomatik küresel çoğaltma vadetti. Bu yaklaşım tutarlılık endişelerini ortadan kaldırdı ancak Paxos uzlaşması nedeniyle bölgeler arası yazma gecikmesi 100 ms'yi aştı. Hızlı özelliklerin yeni işlemlerin görünürlüğünü hemen gerektirmesi durumunda, bu gecikme kabul edilemez hale geldi. Ayrıca, işletme maliyetleri okuma verimliliği ile kararlı bir şekilde arttı, bu da milisaniye düzeyinde hizmet gereksinimleri için ekonomik olarak sürdürülemez hale geldi.
Çözüm 2: Bölgesel Önbelleklerle Nihai Tutarlılık Her bölge için bağımsız Redis kümeleri uygulamaları ve Kafka MirrorMaker aracılığıyla asenkron çoğaltma, mükemmel okuma performansı ve doğrusal ölçeklenebilirlik sağladı. Ancak, bu, veri bilimcilerin veri kalitesi sorunlarını düzeltmek için geçmiş özellikleri yeniden hesapladığı geri besleme işlemleri sırasında kritik tutarlılık açıkları yarattı. Sıkı versiyonlama garantileri olmadan, sistem bayat topluları taze olanlarla birlikte sundu ve model çıkarımında kayma ve yanlış risk puanlama ile dolandırıcılık olarak işaretlenen meşru işlemleri kaçırdı.
Çözüm 3: Vektör Saatlerle Katmanlı Önbellek (Seçilen) Redis'i sıcak katman olarak ve Kafka'yı değişmez gerçeklerin kaynağı olarak kullanan katmanlı bir sistem tasarladık. Her özellik değeri, alma hattından türetilmiş bir vektör saat zaman damgasını taşır. Geri besleme sırasında, Spark işleri S3'e yazdı ve Kafka'ya versiyonlu olaylar yaydı. Bölgesel tüketiciler güncellemeleri, sunucu tarafında vektör saat karşılaştırması yapan Redis Lua betikleri ile uygulayarak, sıralı yazımlarını atomik olarak reddetti ve daha yeni versiyonları kabul etti. Kayma tespiti için, özellik dağılımlarını Prometheus histogramları aracılığıyla izleyerek, Flink'i eğitim tabanlarına karşı gerçek zamanlı istatistiksel karşılaştırma yapacak şekilde besledik.
Sonuç, küresel ortalama P99 hizmet gecikmesini 1.2 ms'ye düşürdü, geri besleme sırasında tutarlılık ihlallerini ortadan kaldırdı ve otomatik kayma tetiklemeli yeniden eğitim hatlarında model bozulma olaylarını %94 oranında azalttı.
Çevrimiçi hizmet katmanının kullanılabilirliğini korurken büyük ölçekli tarihi özellik geri beslemeleri sırasında önbellek zehirlenmesini nasıl önlersiniz?
Birçok aday genellikle geri beslemeler sırasında hizmeti duraklatmayı veya önbellek ve veritabanını kapsayan dağıtılmış işlemler kullanmayı önerir. Doğru yaklaşım, mantıksal zaman damgaları ve gölge anahtar alanları uygulamaktır. Geri besleme veri akışları, monoton olarak artan versiyon kimlikleriyle ayrı bir Kafka konusundan geçer. Çevrimiçi hizmet kümeleri, "mevcut" ve "staging" adı verilen iki Redis anahtar alanı tutar. Geri besleme, staging'i doldururken, hizmet mevcut olanı okur. Tamamlandıktan sonra, atomik bir Redis RENAME işlemi, mikro saniyeler içinde anahtar alanlarını değiştirir veya uygulama katmanı her iki anahtar alanını sorgular ve daha yüksek versiyonlu değeri seçer. Bu, sıfır duraklama sağlar ve karmaşık koordinasyon protokolleri olmadan kısmi geri besleme durumlarının sunulmasını engeller.
Çevrimiçi ve çevrimdışı özellik depoları arasındaki ilişkiyi yöneten tutarlılık modeli nedir ve neden güçlü tutarlılık ölçeklendiğinde başarısız olur?
Adaylar genellikle iki fazlı onay protokolleri kullanarak hem Redis hem de S3 üzerinden ACID işlemleri için öneride bulunur. Çevrimdışı depo, verimlilik ve toplu değişmezlik için optimize edilirken, çevrimiçi depo düşük gecikmeli nokta okumaları için optimize edilmiştir. Güçlü tutarlılık, sunum yolunda kabul edilemez gecikmelere neden olan uzlaşma yükünü gerektirir. Bunun yerine, sınırlı bozulma garantileri ile nihai tutarlılığı benimseyin. Çevrimiçi deponun durumunun belirli bir zaman sınırı içinde çevrimdışı deponun durumuna ulaşmasını sağlamak için bir tutulma tabanlı uzlaşma penceresi kullanın. Daha sıkı garantiler gerektiren özellikler için, çevrimiçi yazma onayını Kafka onayını bekleyen yazma üzerinden önbelleğe alma uygulayın ve kritik özellikler için biraz daha yüksek gecikmeye kabul edin, diğerlerinin yüksek verim aldıktan sonra asenkron çoğaltma ile yüksek verimliliği koruyun.
A/B testlerinde aynı ham verinin birbirine uyumlu olmayan dönüşümlerini gerektiren model versiyonlamasını nasıl ele alırsınız?
Yaygın bir hata, yalnızca model artefaktını versiyonlamak, özellik şeması evrimini göz ardı etmektir ve bu, eğitim-hizmet kaymasına yol açar. Çözüm, DataHub veya Apache Atlas kullanarak özellik ad alanları ve soy ağacı takibi uygulamaktır. Her özellik dönüşümü bir anlamsal versiyon alır. Özellik deposu, rekabetçi anahtarlar kullanarak Redis’te birden fazla versiyonu aynı anda tutar. Model sunum yapılandırmaları, gerekli özellik versiyonlarını Consul veya etcd aracılığıyla belirtir. Bir modeli gölgeden üretime geçirirken, orkestrasyon katmanı, trafik kayması olmadan önce yeni özellik versiyonu için tarihsel oynatma kullanarak önbellekleri önceden ısıtır. Bu, deney kolları arasında veri sızıntısını veya soğuk başlatma gecikmesi artışını önleyerek uyumsuz özellik hesaplamalarıyla aynı anda rekabetçi A/B testleri yapılmasını sağlar.