Quella panoramica è un po 'in astratto, quindi mettiamola a terra in uno scenario del mondo reale, immagina di dover monitorare diversi server web. Ognuno che gestisce il proprio sito Web e nuovi registri vengono costantemente generati in ognuno di essi ogni secondo della giornata. Inoltre ci sono anche un certo numero di server di posta elettronica che devi monitorare.
Potrebbe essere necessario archiviare tali dati per scopi di conservazione e fatturazione dei registri, che è un lavoro batch che non richiede attenzione immediata. Potresti voler eseguire analisi sui dati per prendere decisioni in tempo reale, il che richiede un input accurato e immediato dei dati. Improvvisamente ti trovi nella necessità di razionalizzare i dati in modo ragionevole per tutte le varie esigenze. Kafka agisce come quel livello di astrazione a cui più fonti possono pubblicare diversi flussi di dati e un dato consumatore può iscriverti ai flussi che trova pertinente. Kafka si assicurerà che i dati siano ben ordinati. Sono gli interni di Kafka che dobbiamo capire prima di arrivare all'argomento del partizionamento e delle chiavi.
Kafka Temi sono come le tabelle di un database. Ogni argomento è costituito da dati di una particolare fonte di un tipo particolare. Ad esempio, la salute del cluster può essere un argomento costituito da CPU e informazioni sull'utilizzo della memoria. Allo stesso modo, il traffico in arrivo attraverso il cluster può essere un altro argomento.
Kafka è progettato per essere scalabile orizzontalmente. Vale a dire, una singola istanza di Kafka è costituita da più kafka broker Funzionando su più nodi, ciascuno può gestire flussi di dati paralleli all'altro. Anche se alcuni dei nodi guastano la pipeline di dati può continuare a funzionare. Un argomento particolare può quindi essere diviso in una serie di partizioni. Questo partizionamento è uno dei fattori cruciali alla base della scalabilità orizzontale di Kafka.
Multiplo produttori, Le fonti di dati per un determinato argomento, possono scrivere su quell'argomento contemporaneamente perché ciascuno scrive in una divisione diversa, in qualsiasi momento. Ora, di solito i dati vengono assegnati a una partizione in modo casuale, a meno che non gli forniamo una chiave.
Partizionamento e ordinamento
Giusto per ricapitolare, i produttori stanno scrivendo dati su un determinato argomento. Quell'argomento è effettivamente diviso in più partizioni. E ogni partizione vive indipendentemente dagli altri, anche per un determinato argomento. Ciò può portare a molta confusione quando l'ordinamento dei dati è importante. Forse hai bisogno dei tuoi dati in un ordine cronologico ma avere più partizioni per il tuo DataStream non garantisce un ordinamento perfetto.
Puoi usare una sola partizione per argomento, ma che sconfigge l'intero scopo dell'architettura distribuita di Kafka. Quindi abbiamo bisogno di un'altra soluzione.
Tasti per le partizioni
I dati di un produttore vengono inviati a partizioni in modo casuale, come abbiamo detto prima. Messaggi che sono i blocchi effettivi dei dati. Ciò che i produttori possono fare oltre a inviare solo messaggi è aggiungere una chiave che lo accompagna.
Tutti i messaggi forniti con la chiave specifica andranno alla stessa partizione. Quindi, ad esempio, l'attività di un utente può essere monitorata cronologicamente se i dati di quell'utente vengono contrassegnati con una chiave e quindi finiscono sempre in una partizione. Chiamiamo questa partizione P0 e l'utente U0.
La partizione P0 raccoglierà sempre i messaggi relativi agli U0 perché quella chiave li lega insieme. Ma ciò non significa che P0 sia legato solo a quello. Può anche occupare i messaggi da U1 e U2 se ha la capacità di farlo. Allo stesso modo, altre partizioni possono consumare dati da altri utenti.
Il punto che i dati di un determinato utente non sono distribuiti in diverse partizioni garantendo l'ordine cronologico per quell'utente. Tuttavia, l'argomento generale di dati utente, può ancora sfruttare l'architettura distribuita di Apache Kafka.
Mentre i sistemi distribuiti come Kafka risolvono alcuni problemi più anziani come la mancanza di scalabilità o con un solo punto di fallimento. Sono dotati di una serie di problemi che sono unici per il loro design. Anticipare questi problemi è un lavoro essenziale di qualsiasi architetto di sistema. Non solo, a volte devi davvero fare un'analisi costi-benefici per determinare se i nuovi problemi sono un degno compromesso per sbarazzarsi dei più grandi. L'ordinamento e la sincronizzazione sono solo la punta dell'iceberg.
Speriamo che articoli come questi e la documentazione ufficiale possano aiutarti lungo la strada.