1) O documento discute o uso do Kafka no LinkedIn para suportar o processamento de 1,4 trilhões de mensagens por dia e 175 terabytes de dados.
2) O Kafka foi projetado para mover dados de alta performance de forma distribuída e escalável, servindo como uma única fonte de verdade para o LinkedIn.
3) O documento explica os principais conceitos do Kafka como tópicos, partições, produção e consumo de dados.
3. Volume
● 1.4 trilhões de mensagens por dia
● 175 terabytes trafegados por dia
● picos de 13 milhões de msg/s
● aproximadamente 2,75 GB/s
4. Sem o Kafka o LinkedIn não seria capaz de
suportar o próprio crescimento
5.
6. 1. Kafka foi desenhado para mover
dados em alta performance
2. Distribuído nativamente e por padrão,
garantindo recuperação de falhas
3. Tem sido utilizado como
“single source of truth”
7. 1. Flexível para publish/subscribe
2. Baixo acoplamento
3. Escalável horizontalmente
4. Alta vazão de dados (throughput)
5. Reliable & Durable
6. Usa tópicos ao invés de filas
10. API Producer permite que aplicações
possam enviar streams para os tópicos
do Kafka.
Já as aplicações que lêem dados do
Kafka usam a API Consumer.
11. Para realizar operações com input e output
de dados sem tirar as mensagens do Kafka
usa-se a API de Streams.
A extração de dados de sistemas ou banco
de dados existentes pode ser feita usando
API Connectors.
12.
13. Um topic é um stream que atua como
um banco de dados;
Possui armazenamento persistente;
Um tópico tem diversas partições, cada
uma definida por um número;
A quantidade de partições é definida na
criação do tópico.
14. As partições são independentes;
Ordenadas e a sequência dos registros
são imutáveis;
O offset é posição de um registro na
partição, ID sequencial e único do dado.
15.
16. Os producers adicionam registros ao
stream sempre na cauda da partição;
Os consumers controlam o offset que
desejam ler;
Os consumers podem ler e reler as
mensagens sem “perdê-las”;
É possível criar consumer groups.
17. Se todos os consumers estiverem dentro
do mesmo consumer group, as mensagens
são entregues separadamente como um
load balancer.
18. Mas se os consumers estiverem em
consumer groups diferentes, as mensagens
são entregues para todos como um
broadcast.
19.
20. Cada partição é replicada em diversos
brokers, de acordo o replication-factor;
Isto garante que um dado nunca seja
perdido;
Cluster possui a estratégia de
controllers, leaders e followers.