Come decidere le dimensioni di Kafka Cluster

Question

Sto pensando di stabilire quanti nodi devono essere presenti su Kafka Cluster. Non sono sicuro dei parametri da tenere in considerazione. Sono sicuro che deve essere> = 3 (con fattore di replicazione di 2 e tolleranza di errore di 1 nodo).

Qualcuno può dirmi quali parametri devono essere tenuti in considerazione al momento di decidere le dimensioni del cluster e il loro effetto sulla dimensione.

Conosco i seguenti fattori ma non conosco il modo in cui effettua l'effetto quantitativo delle dimensioni del cluster. So come influisce qualitativamente sulla dimensione del cluster. C'è qualche altro parametro che influenza la dimensione del cluster? 1. Replication factor (cluster size >= replication factor) 2. Node failure tolerance. (cluster size >= node-failure + 1)

quello che dovrebbe essere la dimensione dei cluster per scenario descritto di seguito, mentre considerazione di tutti i parametri 1. There are 3 topics. 2. Each topic has messages of different size. Message size range is 10 to 500kb. Average message size being 50kb. 3. Each topic has different partitions. Partitions are 10, 100, 500 4. Retention period is 7 days 5. There are 100 million messages which gets posted every day for each topic.

Qualcuno può per favore punto me documento o qualsiasi altro blog che può discutere di questo. Ho cercato su google ma inutilmente

Answer 1

Come ho capito, ottenere un buon throughput da Kafka non dipende solo dalla dimensione del cluster; ci sono altre configurazioni che devono essere considerate pure. Cercherò di condividere il più possibile.

Il throughput di Kafka dovrebbe essere scalabile in modo lineare con il numero di dischi che hai. La nuova funzionalità di più directory di dati introdotta in Kafka 0.8 consente agli argomenti di Kafka di avere partizioni diverse su macchine diverse. Con l'aumentare del numero di partizioni, aumentano anche le possibilità che il processo di elezione dei leader sia più lento, con il conseguente riequilibrio dei consumi. Questo è qualcosa da considerare e potrebbe essere un collo di bottiglia.

Un'altra cosa fondamentale potrebbe essere la velocità di risciacquo del disco. Dato che Kafka scrive sempre immediatamente tutti i dati nel filesystem, più spesso i dati vengono scaricati su disco, più Kafka "seek-bound" sarà, e minore sarà il throughput. Anche in questo caso una frequenza di lavaggio molto bassa potrebbe portare a problemi diversi, poiché in tal caso la quantità di dati da svuotare sarà grande. Quindi fornire una figura esatta non è molto pratico e penso che sia la ragione per cui non è possibile trovare una risposta così diretta nella documentazione di Kafka.

Ci saranno anche altri fattori. Ad esempio la dimensione fetch del consumatore, le compressioni, la dimensione del batch per i produttori asincroni, le dimensioni del buffer del socket ecc.

Hardware & Anche il sistema operativo ha un ruolo chiave in questo poiché è consigliabile utilizzare Kafka in un ambiente basato su Linux grazie al meccanismo di pageCache per la scrittura dei dati sul disco. Maggiori informazioni su questo here

Si potrebbe anche voler dare un'occhiata a how OS flush behavior play a key role into consideration prima di sintonizzarsi in realtà per soddisfare le vostre esigenze. Credo che sia fondamentale comprendere la filosofia del design, che la rende così efficace in termini di throughput e tolleranza ai guasti.

Alcuni ulteriori risorse trovo utile a scavare in
https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines
http://blog.liveramp.com/2013/04/08/kafka-0-8-producer-performance-2/
https://grey-boundary.io/load-testing-apache-kafka-on-aws/
https://cwiki.apache.org/confluence/display/KAFKA/Performance+testing

Answer 2

Ho lavorato di recente con Kafka e queste sono le mie osservazioni.

Ogni argomento è suddiviso in partizioni e tutte le partizioni di un argomento sono distribuite tra i broker di kafka; prima di tutto questi aiutano a salvare argomenti la cui dimensione è maggiore della capacità di un singolo broker kafka e aumentano anche il parallelismo dei consumatori.

Per aumentare l'affidabilità e la tolleranza ai guasti, le repliche delle partizioni vengono eseguite e non aumentano il parallelismo dei consumatori. La regola del pollice è un singolo broker in grado di ospitare solo una singola replica per partizione. Quindi Numero di broker deve essere> = No di repliche

Tutte le partizioni sono distribuite tra tutti i broker disponibili, il numero di partizioni può essere indipendente dal numero di broker ma il numero di partizioni deve essere uguale al numero di thread di consumo in un gruppo di consumatori (per ottenere il miglior rendimento)

La dimensione del cluster deve essere decisa tenendo presente il throughput che si desidera raggiungere al consumatore.