Modellazione dei dati con Kafka? Argomenti e partizioni

Una delle prime cose a cui penso quando utilizzo un nuovo servizio (come un archivio dati non RDBMS o una coda di messaggi) è: "Come devo strutturare i miei dati?".

Ho letto e visto alcuni materiali introduttivi. In particolare, prendiamo ad esempio Kafka: un sistema di messaggistica distribuita per l'elaborazione dei log , che scrive:

• "un argomento è il contenitore a cui sono associati i messaggi"
• "la più piccola unità di parallelismo è la partizione di un argomento. Ciò implica che tutti i messaggi che ... appartengono a una particolare partizione di un argomento saranno consumati da un consumatore in un gruppo di consumatori."

Sapendo questo, quale sarebbe un buon esempio che illustra come usare argomenti e partizioni? Quando qualcosa dovrebbe essere un argomento? Quando qualcosa dovrebbe essere una partizione?

Ad esempio, supponiamo che i miei dati (Clojure) siano:

{: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"}

L'argomento dovrebbe essere basato user-id?viewed? at? E la partizione?

Come decido?

Quando strutturi i tuoi dati per Kafka, dipende davvero da come devono essere consumati.

Nella mia mente, un argomento è un raggruppamento di messaggi di un tipo simile che saranno consumati dallo stesso tipo di consumatore, quindi nell'esempio sopra, avrei solo un singolo argomento e se deciderai di spingere qualche altro tipo di dati tramite Kafka, è possibile aggiungere un nuovo argomento per quello in seguito.

Gli argomenti sono registrati in ZooKeeper, il che significa che potresti riscontrare problemi se provi ad aggiungerne troppi, ad esempio il caso in cui hai un milione di utenti e hai deciso di creare un argomento per utente.

D'altra parte, le partizioni sono un modo per parallelizzare il consumo dei messaggi e il numero totale di partizioni in un cluster broker deve essere almeno uguale al numero di consumatori in un gruppo di consumatori per dare un senso alla funzione di partizionamento. I consumatori di un gruppo di consumatori divideranno l'onere di elaborare l'argomento tra di loro in base al partizionamento in modo che un consumatore si occupi solo dei messaggi nella partizione stessa a cui è "assegnato".

Il partizionamento può essere impostato esplicitamente utilizzando una chiave di partizione sul lato produttore o, se non fornito, verrà selezionata una partizione casuale per ogni messaggio.

Una volta che sai come partizionare il tuo flusso di eventi, il nome dell'argomento sarà facile, quindi rispondiamo prima a questa domanda.

@Ludd è corretto: la struttura della partizione scelta dipenderà in gran parte da come si desidera elaborare il flusso di eventi. Idealmente, si desidera una chiave di partizione, il che significa che l'elaborazione degli eventi è partizione locale .

Per esempio:

1. Se ti interessa il tempo medio sul sito degli utenti, devi partizionare per :user-id. In questo modo, tutti gli eventi relativi all'attività del sito di un singolo utente saranno disponibili all'interno della stessa partizione. Ciò significa che un motore di elaborazione di flussi come Apache Samza può calcolare il tempo medio sul sito per un determinato utente semplicemente osservando gli eventi in una singola partizione. Questo evita di dover eseguire qualsiasi tipo di costoso partizione globale elaborazione
2. Se ti interessano le pagine più popolari sul tuo sito Web, dovresti partizionare per :viewedpagina. Ancora una volta, Samza sarà in grado di tenere il conto delle visualizzazioni di una determinata pagina semplicemente guardando gli eventi in una singola partizione

In generale, stiamo cercando di evitare di dover fare affidamento sullo stato globale (come mantenere i conteggi in un database remoto come DynamoDB o Cassandra), e invece essere in grado di lavorare usando lo stato partizione-locale. Questo perché lo stato locale è una primitiva fondamentale nell'elaborazione dei flussi .

Se hai bisogno di entrambi i casi d'uso sopra menzionati, allora un modello comune con Kafka è di prima partizionare per dire :user-id, e poi di ripartizionare per:viewed pronto per la prossima fase di lavorazione.

Sui nomi degli argomenti - uno ovvio qui sarebbe eventso user-events. Per essere più specifici, potresti andare con events-by-user-ide / o events-by-viewed.

Questo non è esattamente correlato alla domanda, ma nel caso in cui tu abbia già deciso la segregazione logica dei record in base agli argomenti e desideri ottimizzare il conteggio argomento / partizione in Kafka, questo blog potrebbe tornare utile.

Key takeaway in breve:

• In generale, più partizioni ci sono in un cluster Kafka, maggiore è il rendimento che si può ottenere. Lascia che il massimo ottenibile su una singola partizione per la produzione sia p e che il consumo sia c . Supponiamo che il throughput target sia t . Quindi devi avere almeno il massimo ( t / p , t / c ) partizioni.

• Attualmente, in Kafka, ogni broker apre un handle di file sia dell'indice che del file di dati di ogni segmento di registro. Quindi, maggiore è il numero di partizioni, maggiore è la necessità di configurare il limite di gestione dei file aperti nel sistema operativo sottostante. Ad esempio nel nostro sistema di produzione, una volta abbiamo visto un errore dire too many files are open, mentre avevamo circa 3600 partizioni di argomenti.

• Quando un broker viene chiuso in modo impuro (es. Kill -9), l'indisponibilità osservata potrebbe essere proporzionale al numero di partizioni.

• La latenza end-to-end in Kafka è definita dal momento in cui un messaggio viene pubblicato dal produttore a quando il messaggio viene letto dal consumatore. Come regola generale, se ti interessa la latenza, è probabilmente una buona idea limitare il numero di partizioni per broker a 100 x b x r , dove b è il numero di broker in un cluster Kafka e r è il fattore di replica.

Penso che il nome dell'argomento sia una conclusione di un tipo di messaggi e che il produttore pubblichi un messaggio sull'argomento e che il consumatore sottoscriva un messaggio tramite l'argomento sottoscrizione.

Un argomento potrebbe avere molte partizioni. la partizione è buona per il parallelismo. la partizione è anche l'unità di replica, quindi in Kafka, leader e follower sono detti anche a livello di partizione. In realtà una partizione è una coda ordinata in cui l'ordine è l'ordine del messaggio arrivato. E l'argomento è composto da una o più code in una semplice parola. Questo è utile per noi per modellare la nostra struttura.

Kafka è sviluppato da LinkedIn per l'aggregazione e la consegna dei registri. questa scena è molto buona come esempio.

Gli eventi dell'utente sul Web o sull'app possono essere registrati dal server Web e quindi inviati al broker Kafka tramite il produttore. Nel produttore, è possibile specificare il metodo di partizione, ad esempio: tipo di evento (evento diverso viene salvato in partizione diversa) o ora dell'evento (partizione al giorno in un periodo diverso in base alla logica dell'app) o tipo di utente o semplicemente nessuna logica e bilanciamento di tutti i registri in molte partizioni.

A proposito del tuo caso in questione, puoi creare un argomento chiamato "page-view-event" e creare N partizioni tramite le chiavi hash per distribuire uniformemente i log in tutte le partizioni. Oppure potresti scegliere una logica di partizione per rendere il log il tuo spirito di distribuzione.