Geleneksel Message Brokers ve Akış Verileri

Göre Kafka sitesine :

" Kakfa gerçek zamanlı veri boru hatları ve akış uygulamaları oluşturmak için kullanılır. "

İnterneti çok geniş bir alanda arayarak, " yayın verilerinin " ne olduğuna ilişkin genel kabul gören şu tanımı buldum :

• Akış verileri, bir ağ üzerinden bir kaynaktan hedefe bitişik olarak akan verilerdir; ve
• Akış verisi doğası gereği atomik değildir , yani akan bir veri akışının herhangi bir kısmı, hepsine sahip olmadığınız sürece baytları hiçbir şey ifade etmeyen bir dosyanın aksine anlamlı ve işlenebilir; ve
• Akış verileri herhangi bir zamanda başlatılabilir / durdurulabilir; ve
• Tüketiciler istedikleri zaman bir veri akışını ekleyip çıkarabilir ve yalnızca istedikleri bölümlerini işleyebilir

Şimdi, yukarıda söylediğim bir şey yanlış, eksik veya tamamen yanlışsa, lütfen beni düzelterek başlayın! Yolda az çok olduğumu varsayarsak, o zaman ...

Şimdi "veri akışı" nın ne olduğunu anladığımdan, Kafka ve Kinesis'in veri akışı olan uygulamalar için ara katman yazılımı işlemesi / aracısı olarak kendilerini faturalandırdıklarında ne anlama geldiğini anlıyorum. Ama bu benim ilgimi çekti: Kafka veya Kinesis gibi "akış orta katman yazılım" geleneksel mesaj aracıları gibi akış dışı veriler için kullanılabilir / gerekir mi? Tam tersi: RabbitMQ, ActiveMQ, Apollo vb. Gibi geleneksel MQ'lar veri akışı için kullanılabilir mi?

Bir uygulamanın işlenmesi gereken JSON mesajlarının arka uç sabit barajını göndereceği ve işlemenin oldukça karmaşık olduğu bir örnek alalım (doğrulama, veri üzerinde dönüşümler, filtreleme, toplamalar vb.):

• Durum # 1: Mesajlar bir filmin her karesidir; kare verilerini ve bazı destekleyici meta verileri içeren her video karesi için bir JSON iletisidir.
• Durum # 2: Mesajlar zaman serisi verileridir, belki de zamanın bir fonksiyonu olarak birinin kalp atışı. Bu yüzden # 1 numaralı mesaj, t = 1'deki kalp atışımı temsil eder, # 2 numaralı mesaj, t = 2'deki vb.
• Durum # 3: Veriler tamamen farklıdır ve zamana göre veya herhangi bir "veri akışının" bir parçası değildir. Belki de yüzlerce kullanıcı düğmelere tıklayarak ve işlem yaparken uygulamada gezinirken tetiklenen denetim / güvenlik olayları

Kafka / Kinesis'in nasıl faturalandırıldığına ve "veri akışı" nın ne olduğuyla ilgili anlayışım temelinde, Durum 1 # (bitişik video verileri) ve # 2 (bitişik zaman serisi verileri) için açık adaylar gibi görünüyorlar. Ancak RabbitMQ gibi geleneksel mesaj komisyoncu bir neden görmüyorum olamazdı verimli yanı her iki girdileri işlemek.

Durum 3 ile, yalnızca gerçekleşen bir olay bize sunulur ve bu olaya bir tepki vermemiz gerekir. Yani bana göre bu, RabbitMQ gibi geleneksel bir brokere ihtiyaç duyuyor. Ama aynı zamanda Kafka veya Kinesis'in olay verilerinin işlenmesini sağlayamamanız için hiçbir neden yok.

Yani temelde, şöyle bir değerlendirme listesi oluşturmak istiyorum : Y özellikli X verilerim var. Bunu işlemek için Kafka / Kinesis gibi bir akış işlemcisi kullanmalıyım. Ya da tam tersine, belirlememe yardımcı olan: Z özellikli W verilerim var. Bunu işlemek için geleneksel bir mesaj komisyoncusu kullanmalıyım.

Bu yüzden soruyorum: Veriler (veya başka türlü) ile ilgili hangi faktörler, her ikisi de akış verilerini işleyebildiğinden ve her ikisi de (akışsız) mesaj verilerini işleyebildiğinden, akış işlemcisi veya ileti aracısı arasındaki kararı yönlendirmeye yardımcı olur?

Kafka atomik mesajların sıralı günlüklerini ele alıyor. pub/subİleti aracıları gibi bir şekilde görüntüleyebilirsiniz , ancak sıkı sipariş ve geçmişte hala diskte tutulan (sonsuza kadar olabilir) herhangi bir noktada ileti akışını yeniden oynatma veya arama yeteneği ile.

Kafka'nın yayın aroması, Thrift veya HTTP gibi uzak prosedür çağrısına ve Hadoop ekosistemindeki gibi toplu işlemeye karşıdır . RPC'den farklı olarak, bileşenler eşzamansız olarak iletişim kurar: Bir mesajın gönderilmesi ile alıcının uyanması ve üzerinde işlem yapması arasında saatler veya günler geçebilir. Zaman içinde farklı noktalarda çok sayıda alıcı olabilir, ya da belki hiç kimse bir mesajı tüketmeye zahmet etmeyecektir. Birden fazla üretici, tüketicilerin bilgisi olmadan aynı konuyu üretebilir. Kafka abone olup olmadığınızı veya bir mesajın kullanılıp kullanılmadığını bilmiyor. Herhangi bir ilgilenen tarafın okuyabileceği günlüğe bir mesaj gönderilir.

Toplu işlemenin aksine, sadece dev mesaj koleksiyonlarıyla değil, tek mesajlarla ilgileniyorsunuz. (Kafka mesajlarını HDFS'deki Parquet dosyalarına arşivlemek ve bunları Hive tabloları olarak sorgulamak nadir değildir).

Durum 1 : Kafka, üretici ve tüketici arasında belirli bir geçici ilişkiyi korumamaktadır. O, biz, ve daha da önemlisi düşük karşılığında üretilen iş genel uzakta ticaret istediğiniz Kafka hızlandırmak, yavaşlatmak için izin verilir çünkü medya akışı için, vb düzensiz bir, içinde hareket video akışı için yetersiz bir uyum var stabil aksi (gecikme düşük titreşim olarak bilinir). Kafka ayrıca bir mesajı asla kaybetmemek için büyük özen gösteriyor. Video akışı ile, genellikle UDP kullanıyoruz ve videonun çalışmasını sağlamak için buraya bir çerçeve bırakmak için memnunuz. Kafka destekli bir süreçteki SLA genellikle sağlıklı olduğunda saniye ila dakika, sağlıklı olduğunda saatler ila günlerdir. Akış ortamındaki SLA onlarca milisaniye cinsindendir.

Netflix, Kafka'yı kullanarak saatte terabayt video kodunu dönüştüren ve diske kaydeden dahili bir sistemde kareleri hareket ettirebilir, ancak ekranınıza göndermez.

Durum 2 : Kesinlikle. Kafka'yı işverenimde bu şekilde kullanıyoruz.

Durum 3 : Kafka'yı bu tür şeyler için kullanabilirsiniz ve biz de yapıyoruz, ancak siparişi korumak için gereksiz ek yük ödüyorsunuz. Düzeni umursamadığınız için, muhtemelen başka bir sistemden biraz daha fazla performans çekebilirsiniz. Şirketiniz zaten bir Kafka kümesine sahipse, muhtemelen başka bir mesaj sisteminin bakım yükünü üstlenmek yerine yeniden kullanmak en iyisidir.

Kafka / Kinesis bir dere olarak modellenmiştir. Akış, iletilerden farklı özelliklere sahiptir.

• Akarsuların onlar için bağlamı vardır. Emirleri var. Akışlara pencere işlevleri uygulayabilirsiniz. Bir akıştaki her öğe anlamlı olsa da, çevresindeki bağlamla daha anlamlı olabilir
• Akışların düzeni olduğundan, bunu işleme anlambilimi hakkında belirli ifadeler yapmak için kullanabilirsiniz. Örneğin Apache Trident'in bir Kafka deresinden tüketirken tam olarak bir kez semantiği var.
• Akışlara işlevler uygulayabilirsiniz. Bir akışı gerçekte tüketmeden dönüştürebilirsiniz. Bir akışı tembel olarak tüketebilirsiniz. Bir akışın bölümlerini atlayabilirsiniz.
• Kafka'da akışları doğal olarak yeniden oynatabilirsiniz, ancak (ek yazılım olmadan) mesaj kuyruklarını yeniden oynatamazsınız. Bu, verilerle ne yapmak istediğinizi bile bilmiyorsanız yararlıdır. AI eğitimi için de yararlıdır.

Genellikle, Kafka'yı çevrimdışı akış işleme için kullanın, gerçek zamanlı istemci-sunucu mesajları için mesaj kuyrukları kullanın.

Önemli örnek kullanım örnekleri :

Kafka: Web Sitesi Etkinlik Takibi, Metrikler, Günlük Birleştirme, Akış İşleme, Etkinlik Kaynaklandırma ve İşlem günlükleri

RabbitMQ: genel amaçlı mesajlaşma ..., genellikle kullanıcı sonuç beklerken kaynak sunucuları zorlamak yerine web sunucularının isteklere hızlı yanıt vermesine izin vermek için kullanılır. AMQP 0-9-1, STOMP, MQTT, AMQP 1.0 gibi mevcut protokolleri kullanmanız gerektiğinde kullanın

Bazen her ikisini de kullanmak faydalı olabilir! Örneğin Kullanım Örneği 2'de, bu bir pace yapıcıdan gelen bir veri akışı olsaydı, pace yapıcısının kalp atışı verilerini hemen işlendiği bir RabbitMQ mesaj kuyruğuna (MQTT gibi serin bir protokol kullanarak) iletmesini isterdim Kaynağın kalbinin hala atıp atmadığını görün. Bu bir gösterge tablosuna ve acil durum müdahale sistemine güç verebilir. Mesaj kuyruğu, zaman serisi kalp atışı verilerini analiz edebilmemiz için zaman serisi verilerini Kafka'ya yatıracaktır. Örneğin, kalp atışı akışındaki eğilimleri fark ederek kalp hastalığını tespit etmek için bir algoritma uygulayabiliriz.