Kafka ile Veri Modelleme? Konular ve Bölümler

Yeni bir hizmet (RDBMS olmayan bir veri deposu veya ileti kuyruğu gibi) kullanırken ilk düşündüğüm şeylerden biri: "Verilerimi nasıl yapılandırmalıyım?".

Bazı tanıtım materyallerini okudum ve izledim. Özellikle, örneğin Kafka: Günlük İşleme için Dağıtılmış Mesajlaşma Sistemi'ni şöyle ele alalım :

• "Konu, mesajların ilişkilendirildiği kapsayıcıdır"
• "Paralelliğin en küçük birimi bir konunun bölümüdür. Bu, bir konunun belirli bir bölümüne ait olan tüm iletilerin bir tüketici grubundaki bir tüketici tarafından tüketileceğini gösterir."

Bunu bilerek, konuların ve bölümlerin nasıl kullanılacağını gösteren iyi bir örnek ne olurdu? Bir şey ne zaman konu olmalı? Bir şey ne zaman bölüm olmalı?

Örnek olarak, (Clojure) verilerimin şöyle göründüğünü varsayalım:

{:user-id 101 :viewed "/page1.html" :at #inst "2013-04-12T23:20:50.22Z"}
{:user-id 102 :viewed "/page2.html" :at #inst "2013-04-12T23:20:55.50Z"}

Konu esas alınmalı user-idmı? viewed? at? Bölüm ne olacak?

Nasıl karar veririm?

Verilerinizi Kafka için yapılandırırken gerçekten nasıl tüketilmesi gerektiğine bağlıdır.

Zihnimde, bir konu, aynı tür tüketici tarafından tüketilecek benzer türde bir mesajlar grubudur, bu nedenle yukarıdaki örnekte, sadece tek bir konuya sahip olacaktım ve başka bir tür Kafka üzerinden veri, daha sonra bunun için yeni bir konu ekleyebilirsiniz.

Konular ZooKeeper'da kayıtlıdır, yani çok fazla sayıda ekleme yapmaya çalışırsanız, örneğin bir milyon kullanıcınız olduğu ve kullanıcı başına bir konu oluşturmaya karar verdiğiniz durumlarda sorun yaşayabileceğiniz anlamına gelir.

Öte yandan bölümler, mesajların tüketimini paralel hale getirmenin bir yoludur ve bir küme kümesindeki toplam bölüm sayısının bölümleme özelliğini anlamak için bir tüketici grubundaki tüketici sayısıyla en az aynı olması gerekir. Bir tüketici grubundaki tüketiciler, konuyu bölümlere göre işleme koyma yükünü bölerler, böylece bir tüketici yalnızca bölümün kendisinde "atanmış" iletilerle ilgilenir.

Bölümleme, üretici tarafında bir bölüm anahtarı kullanılarak açıkça ayarlanabilir veya sağlanmazsa, her mesaj için rastgele bir bölüm seçilir.

Etkinlik akışınızı nasıl bölümleyeceğinizi öğrendikten sonra, konu adı kolay olacaktır, bu yüzden önce bu soruyu cevaplayalım.

@Ludd doğrudur - seçtiğiniz bölüm yapısı büyük ölçüde olay akışını nasıl işlemek istediğinize bağlı olacaktır. İdeal olarak bir bölüm anahtarı istiyorsunuz, bu da olay işlemenizin bölüm yerel olduğu anlamına gelir .

Örneğin:

1. Kullanıcıların sitede geçirdiği ortalama süreyi önemsiyorsanız, bölümlemeniz gerekir :user-id. Bu şekilde, tek bir kullanıcının site etkinliğiyle ilgili tüm etkinlikler aynı bölümde kullanılabilir. Bu, Apache Samza gibi bir akış işleme motorunun , yalnızca tek bir bölümdeki olaylara bakarak belirli bir kullanıcı için ortalama sitede geçirilen zamanı hesaplayabileceği anlamına gelir . Bu, herhangi bir tür pahalı bölüm küresel işlem gerçekleştirmekten kaçınır
2. Web sitenizdeki en popüler sayfaları önemsiyorsanız, :viewedsayfaya göre bölümleme yapmanız gerekir . Yine, Samza sadece tek bir bölümdeki olaylara bakarak belirli bir sayfanın görüşlerini tutabilecektir.

Genel olarak, küresel duruma güvenmekten (sayımları DynamoDB veya Cassandra gibi uzak bir veritabanında tutmak gibi) kaçınmaya çalışıyoruz ve bunun yerine bölüm yerel durumunu kullanarak çalışabiliyoruz. Çünkü yerel durum, akış işlemede temel bir ilkedir .

Yukarıdaki kullanım senaryoları her iki gerekiyorsa, o zaman Kafka ile ortak bir desen söz hakkından ilk bölümü olan :user-idve daha sonra yeniden bölme ile :viewedişleme bir sonraki aşaması için hazır.

Konu adlarında - burada bariz olan eventsveya olacaktır user-events. Daha spesifik olmak için events-by-user-idve / veya ile gidebilirsiniz events-by-viewed.

Bu tam olarak soru ile ilgili değildir, ancak konulara göre kayıtların mantıksal olarak ayrılmasına karar verdiyseniz ve Kafka'daki konu / bölüm sayısını optimize etmek istiyorsanız, bu blog kullanışlı olabilir.

Özetle temel çıkarımlar:

• Genel olarak, bir Kafka kümesinde ne kadar çok bölüm varsa, o kadar yüksek verim elde edilebilir. Üretim için tek bir bölümde elde edilebilecek maksimum değer p olsun ve tüketim c olsun . Diyelim ki hedef veriminiz t . O zaman en az maksimum ( t / p , t / c ) bölümünüz olmalıdır.

• Şu anda Kafka'da her broker, her günlük segmentinin hem indeksinin hem de veri dosyasının bir dosya tanıtıcısını açıyor. Bu nedenle, ne kadar çok bölüm olursa, temel işletim sistemindeki açık dosya tanıtıcı sınırını yapılandırmanız o kadar yüksek olur. Örneğin, üretim sistemimizde, bir keresinde too many files are open3600 konu bölümümüz varken bir hata gördük .

• Bir aracı temiz bir şekilde kapatıldığında (ör. -9'u öldürün), gözlenemeyen kullanılabilirlik bölüm sayısı ile orantılı olabilir.

• Kafka'da uçtan uca gecikme süresi, bir mesajın üretici tarafından yayınlanmasından, mesajın tüketici tarafından okunmasına kadar geçen süre ile tanımlanır. Genel bir kural olarak, gecikmeyi önemsiyorsanız, broker başına bölüm sayısını 100 x b x r ile sınırlamak iyi bir fikirdir ; burada b , bir Kafka kümesindeki aracıların sayısıdır ve r , çoğaltma faktörüdür.

Sanırım konu adı bir tür mesajın sonucudur ve üretici konuya mesaj yayınlar ve tüketici abone mesajı yoluyla mesaj abone olur.

Bir konunun birçok bölümü olabilir. bölümleme paralellik için iyidir. bölme aynı zamanda çoğaltma birimidir, bu yüzden Kafka'da lider ve takipçi de bölme düzeyinde söylenir. Aslında bir bölüm, siparişin mesaj geldi sırası olan sıralı bir kuyruktur. Ve konu basit bir kelimeyle bir veya daha fazla kuyruktan oluşur. Bu, yapımızı modellememiz için faydalıdır.

Kafka, günlük toplama ve dağıtımı için LinkedIn tarafından geliştirilmiştir. bu sahne örnek olarak çok iyi.

Kullanıcının web veya uygulamanızdaki etkinlikleri Web sunucunuz tarafından günlüğe kaydedilebilir ve daha sonra yapımcı aracılığıyla Kafka brokerine gönderilebilir. Yapımcıda, bölümleme yöntemini belirtebilirsiniz, örneğin: olay türü (farklı bölüme farklı olay kaydedilir) veya olay zamanı (bir gün, uygulama mantığınıza göre farklı bir döneme bölümleme) veya kullanıcı türü veya sadece mantık yok ve tüm günlükleri dengeleme birçok bölüme.

Söz konusu davanız hakkında, "page-view-event" adlı bir konu oluşturabilir ve günlükleri tüm bölümlere eşit olarak dağıtmak için karma tuşlarıyla N bölümleri oluşturabilirsiniz. Ya da ruhunuz tarafından günlük dağıtımı yapmak için bir bölüm mantığı seçebilirsiniz.