Broker di messaggi tradizionali e dati di streaming

Question

Broker di messaggi tradizionali e dati di streaming

#1 da (3 voti)
#2 da (3 voti)

7

"Kakfa is used for building real-time data pipelines and streaming apps."

Cercando in Internet in lungo e in largo, ho trovato la seguente definizione generalmente accettata di ciò che " stream data " è:

I dati di flusso sono dati che fluiscono in modo contiguo da un'origine a una destinazione su una rete; e
I dati del flusso sono non di natura atomica, ovvero qualsiasi parte di un flusso di dati che scorre è significativa e processabile, al contrario di un file i cui byte non significano nulla a meno che non li possiedi tutti ; e
I dati di streaming possono essere avviati / fermati in qualsiasi momento; e
I consumatori possono allegare e scollegare da un flusso di dati a piacere ed elaborare solo le parti di esso che desiderano

Ora, se qualcosa che ho detto sopra è errato, incompleto o totalmente sbagliato, per favore inizia correggendomi! Supponendo che io sia più o meno in pista, allora ...

Ora capisco cosa sono i "dati di streaming", quindi capisco cosa intendano Kafka e Kinesis quando si fatturano come middleware di elaborazione / intermediazione per le applicazioni con i dati di streaming. Ma ha suscitato i miei interessi: può / dovrebbe "streaming middleware" come Kafka o Kinesis essere utilizzato per i dati non in streaming, come i tradizionali broker di messaggi? E viceversa: possono / dovrebbero essere usati MQ tradizionali come RabbitMQ, ActiveMQ, Apollo, ecc. Per lo streaming dei dati?

Facciamo un esempio in cui un'applicazione invierà il suo bombardamento costante di messaggi JSON che devono essere elaborati e l'elaborazione è abbastanza complessa (convalida, trasformazione dei dati, filtraggio, aggregazione, ecc.):

Caso n. 1: i messaggi sono ciascuno dei fotogrammi di un film; questo è un messagio JSON per fotogramma video contenente i dati del fotogramma e alcuni metadati di supporto
Caso 2: i messaggi sono dati di serie temporali, forse il battito del cuore di qualcuno in funzione del tempo. Quindi il messaggio n. 1 viene inviato per rappresentare il mio battito cardiaco su t = 1, il messaggio n. 2 contiene il mio battito cardiaco su t = 2, ecc.
Caso n. 3: i dati sono completamente disparati e non correlati in base al tempo o come parte di qualsiasi "flusso di dati". Forse gli eventi di controllo / sicurezza che vengono generati quando centinaia di utenti navigano nell'applicazione facendo clic sui pulsanti e eseguendo azioni

Sulla base di come vengono fatturati Kafka / Kinesis e sulla mia comprensione di cosa siano i "flussi di dati", sembrano essere candidati ovvi per i casi n. 1 (dati video contigui) e n. 2 (dati di serie temporali contigue). Tuttavia non vedo alcun motivo per cui un tradizionale broker di messaggi come RabbitMQ non potrebbe gestire in modo efficiente entrambi questi input.

E con il caso n. 3, ci viene fornito solo un evento che si è verificato e dobbiamo elaborare una reazione a quell'evento. Quindi per me questo parla di aver bisogno di un broker tradizionale come RabbitMQ. Ma non c'è nemmeno motivo per cui Kafka o Kinesis non possano gestire l'elaborazione dei dati degli eventi.

Quindi, in sostanza, sto cercando di stabilire una rubrica che dice: Ho X dati con caratteristiche Y. Dovrei usare un processore di flusso come Kafka / Kinesis per gestirlo. Oppure, al contrario, uno che mi aiuta a determinare: Ho dati W con caratteristiche Z. Dovrei usare un tradizionale broker di messaggi per gestirlo.

Quindi chiedo: Quali fattori sui dati (o altro) aiutano a guidare la decisione tra lo stream processor o il broker dei messaggi, poiché entrambi possono gestire i dati di streaming ed entrambi possono gestire i dati dei messaggi (non in streaming)? / strong>

message-queue stream-processing apache-kafka

posta smeeb 07.06.2017 - 05:31
fonte

2 risposte

3

Kafka si occupa di registri ordinati di messaggi atomici. Puoi visualizzarlo in modo simile alla modalità pub/sub dei broker di messaggi, ma con un ordine rigoroso e la possibilità di riprodurre o cercare intorno al flusso di messaggi in qualsiasi punto del passato che è ancora conservato su disco (che potrebbe essere per sempre) .

Il sapore di streaming di Kafka è opposto alla chiamata di procedura remota come Thrift o HTTP e all'elaborazione batch come nell'ecosistema Hadoop. A differenza di RPC, i componenti comunicano in modo asincrono: possono passare ore o giorni tra un messaggio e l'altro quando il destinatario si sveglia e agisce su di esso. Potrebbero esserci molti destinatari in momenti diversi, o forse nessuno si prenderà mai il disturbo di consumare un messaggio. Più produttori potrebbero produrre sullo stesso argomento senza la conoscenza dei consumatori. Kafka non sa se sei iscritto o se è stato consumato un messaggio. Un messaggio è semplicemente impegnato nel log, dove ogni parte interessata può leggerlo.

A differenza dell'elaborazione batch, ti interessano singoli messaggi, non solo gigantesche raccolte di messaggi. (Anche se non è raro archiviare i messaggi di Kafka in file Parquet su HDFS e interrogarli come tabelle Hive).

Caso 1 : Kafka non conserva alcuna particolare relazione temporale tra produttore e consumatore. È inadeguato per lo streaming video perché Kafka è in grado di rallentare, accelerare, spostarsi in stallo, ecc. Per i media in streaming, vogliamo scambiare il throughput complessivo in cambio di uno stabile basso e, soprattutto, di stabile latenza (altrimenti nota come bassa jitter). Anche Kafka si impegna a non perdere mai un messaggio. Con lo streaming video, usiamo tipicamente UDP e siamo contenti di rilasciare un frame qua e là per mantenere attivo il video. Lo SLA su un processo sostenuto da Kafka è in genere da secondi a minuti quando è sano, da ore a giorni quando è in salute. Lo SLA su streaming media è in decine di millisecondi.

Netflix potrebbe usare Kafka per spostare fotogrammi in un sistema interno che transcodifica terabyte di video all'ora e li salva su disco, ma non per spedirli sullo schermo.

Caso 2 : assolutamente. Usiamo Kafka in questo modo al mio datore di lavoro.

Caso 3 : puoi usare Kafka per questo genere di cose, e lo facciamo, ma stai pagando un sovraccarico non necessario per preservare l'ordine. Dato che non ti interessa l'ordine, potresti probabilmente spremere un po 'più di prestazioni da un altro sistema. Se la tua azienda mantiene già un cluster Kafka, probabilmente è meglio riutilizzarlo invece di assumersi il carico di manutenzione di un altro sistema di messaggistica.

risposta data 07.06.2017 - 06:46
fonte

3

Kafka / Kinesis è modellato come uno stream. Un flusso ha proprietà diverse dai messaggi.

Gli stream hanno un contesto per loro. Hanno ordine È possibile applicare le funzioni della finestra sui flussi. Sebbene ogni elemento di uno stream sia significativo, potrebbe essere più significativo con il contesto attorno ad esso

Poiché gli stream hanno un ordine, puoi usarlo per fare alcune affermazioni sulla semantica dell'elaborazione. Per esempio. Si presume che Apache Trident abbia esattamente una sola semantica quando consuma da un flusso di Kafka.

È possibile applicare le funzioni agli stream. È possibile trasformare uno stream senza effettivamente consumarlo. Puoi pigramente consumare un flusso. Puoi saltare parti di un flusso.

È possibile riprodurre automaticamente i flussi in Kafka, ma non è possibile (senza software aggiuntivo) riprodurre le code dei messaggi. Questo è utile quando non sai ancora cosa vuoi fare con i dati. È anche utile per allenare AI.

In genere, utilizza Kafka per l'elaborazione del flusso offline, utilizza le code dei messaggi per i messaggi client-server in tempo reale.

Esempi di utilizzo da chiave :

Kafka: Website Activity Tracking, Metrics, Log Aggregation, Stream Processing, Event Sourcing and Commit logs

RabbitMQ: general purpose messaging..., often used to allow web servers to respond to requests quickly instead of being forced to perform resource-heavy procedures while the user waits for the result. Use when you need to use existing protocols like AMQP 0-9-1, STOMP, MQTT, AMQP 1.0

A volte può essere utile usare entrambi! Ad esempio in Use Case # 2, se questo fosse un flusso di dati da un pacemaker, direi che il pacemaker trasmetterà i dati heartbeat a una coda di messaggi RabbitMQ (usando un protocollo cool come MQTT) dove viene immediatamente elaborato per vedi se il cuore della fonte sta ancora battendo. Questo potrebbe alimentare un cruscotto e un sistema di risposta alle emergenze. La coda dei messaggi avrebbe anche depositato i dati delle serie temporali in Kafka in modo da poter analizzare i dati dell'heartbeat nel tempo. Ad esempio, potremmo implementare un algoritmo per rilevare le malattie cardiache osservando le tendenze nel flusso del battito cardiaco.

risposta data 07.06.2017 - 06:20
fonte

Leggi altre domande sui tag message-queue stream-processing apache-kafka

Gestione del rilascio mercuriale. Rifiutare le modifiche che non riescono a testare Perché nessuno parla di compilazione parallela per .Net?

score 3 · Accepted Answer

Kafka si occupa di registri ordinati di messaggi atomici. Puoi visualizzarlo in modo simile alla modalità pub/sub dei broker di messaggi, ma con un ordine rigoroso e la possibilità di riprodurre o cercare intorno al flusso di messaggi in qualsiasi punto del passato che è ancora conservato su disco (che potrebbe essere per sempre) .

Il sapore di streaming di Kafka è opposto alla chiamata di procedura remota come Thrift o HTTP e all'elaborazione batch come nell'ecosistema Hadoop. A differenza di RPC, i componenti comunicano in modo asincrono: possono passare ore o giorni tra un messaggio e l'altro quando il destinatario si sveglia e agisce su di esso. Potrebbero esserci molti destinatari in momenti diversi, o forse nessuno si prenderà mai il disturbo di consumare un messaggio. Più produttori potrebbero produrre sullo stesso argomento senza la conoscenza dei consumatori. Kafka non sa se sei iscritto o se è stato consumato un messaggio. Un messaggio è semplicemente impegnato nel log, dove ogni parte interessata può leggerlo.

A differenza dell'elaborazione batch, ti interessano singoli messaggi, non solo gigantesche raccolte di messaggi. (Anche se non è raro archiviare i messaggi di Kafka in file Parquet su HDFS e interrogarli come tabelle Hive).

Caso 1 : Kafka non conserva alcuna particolare relazione temporale tra produttore e consumatore. È inadeguato per lo streaming video perché Kafka è in grado di rallentare, accelerare, spostarsi in stallo, ecc. Per i media in streaming, vogliamo scambiare il throughput complessivo in cambio di uno stabile basso e, soprattutto, di stabile latenza (altrimenti nota come bassa jitter). Anche Kafka si impegna a non perdere mai un messaggio. Con lo streaming video, usiamo tipicamente UDP e siamo contenti di rilasciare un frame qua e là per mantenere attivo il video. Lo SLA su un processo sostenuto da Kafka è in genere da secondi a minuti quando è sano, da ore a giorni quando è in salute. Lo SLA su streaming media è in decine di millisecondi.

Netflix potrebbe usare Kafka per spostare fotogrammi in un sistema interno che transcodifica terabyte di video all'ora e li salva su disco, ma non per spedirli sullo schermo.

Caso 2 : assolutamente. Usiamo Kafka in questo modo al mio datore di lavoro.

Caso 3 : puoi usare Kafka per questo genere di cose, e lo facciamo, ma stai pagando un sovraccarico non necessario per preservare l'ordine. Dato che non ti interessa l'ordine, potresti probabilmente spremere un po 'più di prestazioni da un altro sistema. Se la tua azienda mantiene già un cluster Kafka, probabilmente è meglio riutilizzarlo invece di assumersi il carico di manutenzione di un altro sistema di messaggistica.