Reklam Ölçümlemesi Tepe Yükte Olay Kaybediyor: Ek Yerleri, Mükerrer Anahtarlar ve Bidder Join'i

Tepe trafikte olay kaybeden ve bidder loglarıyla hiç mutabakata gelmeyen bir olay pipeline'ı, tek bir belirtinin arkasında iki arıza olabilir. Biri taşımadır: oluşturulan ama hiç ulaşmayan olaylar, kimsenin saymadığı bir ek yerinde. Diğeri tanımsaldır: ulaşan ama açık artırma kaydından farklı bir kurala göre sayılan olaylar.

Alışılmış çerçeve - pipeline olay düşürüyor, öyleyse pipeline'ı yeniden kuralım - bu ikisinden en fazla birini çözer. Aşağıdakiler ikisini birbirinden ayırır ve bir mutabakatın ne ürettiğini söyler; ürettiği şey eşitlik değildir. Aşağıda alıntılanan varsayılanlar taşıma tarafında Kafka'ya, depolama tarafında ClickHouse'a aittir.

Tek bir sorgu, kayıp olayı geç olandan ayırır

İlk arıza kayıptır: olay oluşturuldu ve belirli bir hop'ta, belirli bir nedenle hiç ulaşmadı. Sayfadan hiç çıkmayan bir beacon, deploy ortasında yeniden başlatılan bir edge, dolan bir producer buffer'ı, işlemeden önce offset'ini commit eden bir consumer.

İkincisi hiç arıza değildir. Ölçüm tarafı istemcinin başlattığı bir olayı sayar; bidder ise sunucu tarafındaki bir açık artırma sonucunu kaydeder. Biri bir tahsis, diğeri o tahsise ne olduğunun gözlemidir. MRC ölçümleme rehberi pre-fetch, pre-render ve otomatik yenilemeyi tespit edilip açıklanması gereken ayrı şeyler olarak ele alır: bir taşıma arızası değil, bir sayma kuralı. İkisini birbirinden ayırmanın bedeli tek bir sorgu ve biraz sabırdır.

• Aynı olay zamanı penceresini, kapsadığı zamandan bir saat, altı saat ve tam bir gün sonra yeniden çalıştırın
• Her koşuda küçülen bir açık, olayların kaybolmadığı, yalnızca geç kaldığı ve taşımanın sorunsuz olduğu anlamına gelir
• Satırları değil, farklı tekilleştirme anahtarlarını sayın: at-least-once taşıma yeniden teslimi garanti eder ve satır tabanlı bir eğri fazla sayımı gizler
• Sabit kalan bir açık, olayların kaybolduğu anlamına gelir; soru hangi ek yeri olduğudur
• Test, bir olay zamanı damgasına, yeniden denemelerden sağ çıkan bir kimliğe ve pencereyi yeniden çalıştırmaya yetecek kadar uzun bir saklama süresine ihtiyaç duyar
• Oturma eğrisini olay türü bazında bir grafik olarak, açıkladığı sayının yanında yayımlayın

O eğri var olana kadar tartışmanın iki tarafı da görüşten ibarettir. Sonrasında eğrinin şekli, bu yazının hangi yarısının geçerli olduğuna karar verir ve iki yarı birbirini dışlamaz.

Olaylar adı konmuş ek yerlerinde kaybolur ve sayılmayan bir ek yeri suçlanamaz

Bir reklam olayının oluşturulup sonra sessizce var olmayı bıraktığı yedi yer var, üstüne garanti gibi görünen ama garanti olmayan bir ayar.

• İstemci tarafı toplama: beacon tetiklenir ama belge ondan önce boşaltılır, ya da kreatif önbelleğe alınmış, önceden getirilmiş veya otomatik yenilenmiştir ve açık artırma kaydının saymadığını sayar
• Edge alımı: bağlantı limitleri, keep-alive tükenmesi, deploy sırasındaki yeniden başlatmalar ve tehlikeli olan varyantı - olay kalıcı hâle gelmeden başarı yanıtı dönmek
• Producer buffer'ı: istemci sınırlı bir süre bloklanır, sonra hata fırlatır; hatayı yakalayıp hiçbir şey saymayan kod, verinin öldüğü yerdir
• Broker kalıcılığı: hiç onay istenmediğinde kaydın ulaştığını hiçbir şey garanti etmez; yalnızca leader ile yetinildiğinde, follower'lar kopyalamadan önce o leader düşerse kayıt gider
• Tüm replikalardan onay almak kalıcılık değildir: mevcut in-sync kümesini bekler, o kümenin asgari boyutu ise varsayılan olarak birdir; dolayısıyla follower'ları geride bırakan bir tepe yük, yalnızca leader üzerinde commit eder
• Consumer: offset'i işlemeden önce commit etmek at-most-once demektir ve bu bir karar değil bir varsayılandır - kapatılmadıysa istemci zamanlayıcıyla commit eder
• Saklama süresinin aşılması: saklama penceresinin ötesine düşen bir consumer, bir sonraki offset'inin silinmiş olduğunu bulur ve varsayılan reset politikası onu log'un ucuna atlatır
• Sütun tabanlı depoya yükleme: fire-and-forget insert'ler buffer'a alınır alınmaz onay döner ve bağımlı materialized view'lar ayrı bir ayar üzerinden tekilleştirir - ham tablo ile raporun yollarının ayrıldığı yer

Kural bir raporlama kuralıdır, mühendislik kuralı değil: bir kayıp ya adı konmuş bir ek yerine yazılır ya da hiç yazılmaz. İki alarm sessiz ek yerlerini görünür tutar - saklama süresine karşı zaman cinsinden ölçülen consumer lag ve atlamak yerine hata veren bir reset politikası.

Tekilleştirme, ilk yeniden denemeden önce var olan bir anahtar ister

Tekilleştirme anahtarı, hedefte seçilen kullanışlı bir birincil anahtar değildir. Her yeniden denemenin yukarısında, açık artırma anında ya da olay oluşturulurken atanır; alıcı taraf asla kendisi bir anahtar uydurmaz. Varış zaman damgaları dışarıda kalır: yeniden deneme yeni bir varış zamanı ve yeni bir anahtar taşır.

• Idempotent producer, tek bir oturum içindeki producer yeniden denemelerinden doğan mükerrerleri kaldırır ve Kafka bunu 3.0'dan beri tüm replikalardan onayla birlikte varsayılan olarak açar
• Bu varsayılan koşulludur: eski bir yapılandırmadan gelen çelişkili bir ayar, idempotency'yi sessizce kapatır; bu yüzden çalışan sürece neye sahip olduğunu sorun
• Uygulama düzeyindeki bir mükerreri göremez: çöküp yeniden gönderen bir süreç, iki kez tetiklenen bir beacon, bir alım işini yeniden çalıştıran bir operatör
• ClickHouse insert tekilleştirmesi blok içeriğinin hash'ini alır; bu yüzden rebalance sonrası yeniden batch'leyen bir consumer aynı satırları yeni bir biçimde gönderir ve hash tutmaz
• Pencere hem blok hem zaman olarak sınırlıdır ve replikasız tablolarda varsayılanı sıfırdır, yani kapalıdır; bir insert token'ı bu bağımlılığı ortadan kaldırır
• Log içindeki exactly-once, consume-transform-produce zincirini kapsar; analitik veritabanına yapılan hop ise taşıma ne söz verirse versin bu sınırın dışında kalır

Yani çalışan biçim, idempotent anahtarlarla at-least-once taşımadır. Yazma anındaki tekilleştirme depolama faturasını makul tutar; sayıyı doğru yapan ise okuma anındaki tekilleştirmedir. Merge'ler farklı partition'lardaki part'ları asla birleştirmez; bu yüzden bir sonraki partition'a düşen bir mükerrer, ancak bir sorgu sorduğunda çözülür.

Bir kaybın sayı mı yoksa söylenti mi olduğuna back pressure karar verir

Aşırı yük altında bir sistemin üç seçeneği vardır: producer'ı yavaşlatmak, sayaçla yük atmak ya da sessizce kaybetmek. Yalnızca üçüncüsü kabul edilemez ve bu, kendisine bu soru hiç sorulmamış kodun varsayılan davranışıdır. Tepe yükteki kayıp, bellek tükenene kadar büyüyen bir kuyruk ya da kalıcılıktan önce verilmiş bir onaydır.

• Her hop'ta sınırlı kuyruklar ve büyüme yerine açık reddetme. Sınırsız bir kuyruk, kaybı bellek baskısına ve bir yeniden başlatmaya taşır
• Producer'ın bloklanma süresi ve buffer boyutu kapasite kararlarıdır: ikisini de ölçtüğünüz tepe yüke göre boyutlandırın ve bloklanmada geçen süreye alarm kurun
• Rastgele değil sınıfa göre yük atın: gösterim ve faturalanabilir olaylar hayatta kalır, önce teşhis olayları gider ve atılan her olay etiketli bir sayacı artırır
• Consumer lag, back pressure'ın görünür hâlidir. İşlenmemiş en eski olayın yaşına ve lag'in ne kadar hızlı değiştiğine alarm kurun

Etiketli sayacı olan bir düşürme, sonradan mutabakata getirilebilen bilinen bir büyüklüktür. Sayacı olmayan bir düşürme kayıp veri değil, kayıp sayıdır.

Geç varış yapısaldır ve uyuşmazlığın yarısı bir takvim meselesidir

OpenRTB uygulama rehberi bunu doğrudan söyler: reklam isteğinden açık artırmaya, oradan render ve faturalamaya uzanan zincir temelde işlemsel değildir. İki sayımın arasında fazla sayıda taraf oturuyor.

Gecikme istisna değil, beklenen durumdur. Bid request bir gösterim sona erme süresi taşıyabilir, teklif ise bidder'ın tolere ettiği gecikmeyi; aynı rehber, web için dakika mertebesinden önbelleğe alınmış uygulama içi formatlar ve stitched video için çok daha uzun sürelere uzanan pratik kurallar verir.

İki alan da bir sözleşme değildir. Rehber açıkça şunu söyler: bidder'ın bildirdiği sona erme süresinden daha geç gelen bir faturalama bildirimi yine de faturalanabilir olabilir - bu, protokolün dayattığı bir şey değil, bidder ile exchange arasında bir politika tartışmasıdır.

• Olay başına üç zaman damgası vardır ve pencereyi tam olarak biri belirler: cihaz saati, güvenilmez; edge'de alınma zamanı, geç; açık artırma zamanı, esas alınan
• Exchange'in sağladığı yerde bir dördüncüsü vardır: gösterimin gerçekleştiği anı taşıyan makro; bulunmadığı yerde spesifikasyon, bildirimin saniyeler içinde ardından geldiğini varsayar
• Bir watermark, olay zamanının bir noktaya ulaştığını ve daha erken öğe beklenmediğini beyan eder; dolayısıyla izin verilen gecikme sizin seçtiğiniz bir parametredir
• Geç varış penceresini olay türü bazında, yeniden düzenleme politikasıyla birlikte yayımlayın: pencere açıkken sayılar hareket eder, sonra donar ve hareketler loglanır
• Geç gelen olayı sayın ve geç olarak işaretleyin; onu düşürmek, faturası size kesilmiş harcamayı düşürmektir

Pencere kapandıktan sonra gelen bir olay, pipeline'daki bir kusur değil, mecranın bir özelliğidir. Tek gerçek seçim, sayının pencere açıkken herkesin gözü önünde mi yoksa kapandıktan sonra sessizce mi hareket edeceğidir.

Mutabakat, protokolün zaten taşıdığı kimlikler üzerinden join yapar

Exchange'in bildirim ve takip URL'lerine yerleştirdiği kimlikler şunlardır: bid request'teki açık artırma kimliği, gösterim kimliği ve bidder bir tane ürettiyse teklif kimliği. Üçünün hiçbiri tek başına anahtar değildir.

Spesifikasyon açık artırma kimliğini küresel olarak benzersiz değil, exchange içinde benzersiz olarak tanımlar: iki exchange aynı gün size aynı dizgiyi verebilir. Gösterim kimliği yalnızca kendi bid request'inin içinde benzersizdir ve çoğu zaman düpedüz 1'dir. Teklif kimliği isteğe bağlıdır.

Tutan anahtar bileşik olandır: işlemi yaptığınız exchange ya da seat, artı açık artırma kimliği, artı gösterim kimliği. Bunu bidder tarafında, açık artırma anında üretin ve daha kısa olan her şeye anahtar değil önek muamelesi yapın.

Bu makrolar beacon'larda yoksa olay düzeyinde mutabakat imkânsızdır; geriye zaman, yerleşim ve kreatif üzerinden eşleştirme kalır. Bunun yerine kurabileceğiniz şey, her biri bir üst adımdan neden farklılaştığını söyleyen altı sayımdan oluşan bir köprüdür.

• Bidder logundan kazanılan açık artırmalar - tamamen size ait olan tek sayım
• Exchange'in aldığı kazanma bildirimleri - aradaki fark bildirim kaybı ve zaman aşımlarıdır ve spesifikasyona göre bir kazanma bildirimi zorunlu olarak teslimat anlamına gelmez
• Edge'inizde alınan beacon'lar - aradaki fark, istemci tarafı toplama ve onun üzerindeki her ek yeridir
• Tekilleştirme sonrası olaylar - aradaki fark yeniden denemelerdir ve haftadan haftaya sabit kalmalıdır
• Geçersiz trafik filtrelemesi sonrası olaylar - aradaki fark, sonradan keşfettiğiniz değil yayımladığınız bir filtreleme oranıdır
• Faturalanabilir olaylar - aradaki fark faturalama kuralıdır ve bildirim, exchange'in gelir yazdığı sunucu tarafına aittir

Amaç, adımlar arasında istikrarlı bir orandır; alarm ise açıklanamayan bir kaymadır. Tek bir sistemin içinde hop oranları bir olmalıdır ve her sapma sinyaldir. Açık artırma ile ölçüm arasındaki sınırda ise şüpheli okuma birdir.

Yeniden kurulan bir pipeline'ın vermedikleri

Köprünün yanıtlamadığı, bir sözleşmenin ise yanıtladığı tek bir soru var: bu sayıların hangisi üzerinden ödeme yapıyorsunuz. Satıcı geliri kendi faturalanabilir olayına göre yazar, alıcı kendi olayına göre hızını ayarlar ve rehber, kalıcı bir farkı taraflar arasında bir destek görüşmesi olarak ele alır.

Harcama için hangi sayımın esas kayıt olduğuna ve hangi fark seviyesinde bir rapor notunun exchange'e açılan bir talebe dönüşeceğine önceden karar verin. Yukarıdaki iş size kaybın nereye yazılacağını, dürüst mükerrerleri ve satır satır açıklanmış bir mutabakatı kazandırır. Şunları kazandırmaz.

• İki sayımı eşitlemez: iki taraf da bilerek farklı olaylar sayar ve fark açıklanır, asla ortadan kaldırılmaz
• Ölçümleme var olmadan önce düşen olayları geri getirmez - oturma eğrisi, sayaçların başladığı gün başlar
• Yeniden düzenlemeyi ortadan kaldırmaz: geç varış penceresi açıkken dün hareket eder ve buna tahammülü olmayan bir işletmenin daha geç bir kapanışa ihtiyacı vardır
• Eksik makrolarla baş edemez: beacon'larda açık artırma kimlikleri yoksa hiçbir depolama tasarımı olay düzeyinde bir join üretmez
• Örneklenmiş veriyi sonradan join edilebilir hâle getirmez; çünkü örnekleme, hangi soruların yanıtlanabilir kalacağına satır yazılmadan önce karar verir
• MRC tarzı bir denetimin beklediği açıklama listesinin yerini tutmaz: yakalama noktası, loglama sıklığı, latency tahminleri, tutarsızlık kuralları

Bu açıklama sorularını yanıtlayabilen bir pipeline'ın bütünlük anlatısı vardır. Yanıtlayamayanın elinde yalnızca bir görüş vardır ve çeyrek sonunda tartışılan şey görüştür.

Tasarımda karşı önlem almaya değer arıza, soruşturma başlatan eksik saat değildir. Sessiz olanıdır: sayaç tutmadan yük atan bir ek yeri, kalıcı olmadan onaylanmış bir insert ve hâlâ açık bir pencere üzerinde yapılan bir mutabakat.

amBrain'in kamuya kanıtlayabildikleri: amBrain, Erivan (Ermenistan) merkezli bir yazılım mühendisliği şirketidir; Rust ile low latency trading platformları, matching engine'ler ve real-time bidding sistemleri geliştirir. amBrain 2019'dan beri yazılım geliştiriyor. Bir ölçümleme pipeline'ını yeniden kurmak burada anlatılan iş değildir. Sayılar bidder ve exchange tarafında - teklif, kazanım ve gösterim kayıtlarının kendisinde - mutabakata gelmeyi bırakıyorsa, konuşmaya değer konu budur ve bu konuşma yeniden kurmakla değil, oturma eğrisiyle başlar.