Conhecendo o
Analista de Sistemas Sênior
(1883 - 1924)
Kafka foi um importante escritor da língua alemã.
Integrando o movimento literário do modernismo e existencialismo, o autor foi considerado como pelos críticos como um dos escritores mais influentes do século XX.
O nome "Kafka" uma homenagem de Jay Kreeps (criador da ferramenta) ao Franz Kafka pelo fato de ser um sofware otimizado para escrita/leitura e também porque ele gostava do trabalho do autor.
O Apache Kafka é uma plataforma open source para processamento distribuído de streams em alta performance
Sistema
Origem
Sistema
Destino
A transferência de dados entre sistemas distintos é algo muito comum
Sistema
Origem
Sistema
Destino
Contudo, a situação se complica quando temos diferentes origens e destinos
Sistema
Origem
Sistema
Destino
Sistema
Origem
Sistema
Destino
Considerando múltiplos sistemas de origem e destino tem-se diversas dificuldades relacionadas a cada uma das integrações
Protocolo
Como esses dados são transportados?
Ex: TCP, HTTP, REST, FTP, JDBC, Oração?
Formato
Como esse dado é analisado/tratado?
Ex: Binários, CSV, JSON, XML.
Evolução
Como esse dado é tratado?
O que fazer em caso de mudanças?
Esse é um dos contextos em que o Kafka entra em ação
Sistema
Origem
Sistema
Destino
Sistema
Origem
Sistema
Destino
Sistema
Origem
Sistema
Destino
Originalmente criado pelo LinkedIn, mas agora é um projeto Open Source mantido majoritariamente pela Confluent através da Apache Foundation
Funciona de forma distribuída
Arquitetura resiliente e tolerância a falhas
Escalabilidade Horizontal
Alta performance (Latência menor que 10ms, real time)
Utilizado por mais de 2000 empresas, sendo 35% delas da Fortune 500 (lista das 500 maiores corporações do mundo)
Sistema de Mensageria
Rastreamento de Atividades
Internet das Coisas (IoT)
Agregador
de Logs
Processamento de Streams
Desacoplamento de Sistemas
Integração com tecnologias de Big Data
"O Apache Kafka e sistemas tradicionais de mensageria apesar de parecerem similares são essencialmente diferentes desde sua arquitetura"
Jay Kreeps no artigo "It's ok to Store Data in Apache Kafka".
Apesar do que foi dito por Kreeps, ele ainda ressalta em seu artigo que para utilizar o Kafka como um mecanismo de armazenamento é necessário um conhecimento aprofundado sobre a forma com que ele funciona, como mantê-lo e sobretudo suas limitações.
Os tópicos consistem de um fluxo específico de dados.
É conceitualmente similar a ideia de tabela em banco de dados (sem as constraints).
A grosso modo, podemos dizer que os tópicos são o "assunto" a que se referem os dados lá armazenados.
Times de Futebol
{
Vitória
Bahia
Chelsea
Juventus
Nome do Tópico
Mensagens
Os tópicos são divididos por partições (no mínimo uma), definidas no momento da criação do tópico de forma arbitrária (essa quantidade pode ser incrementada depois).
Times de Futebol
{
Vitória
Bahia
Chelsea
Juventus
Nome do Tópico
Partições
Cada partição irá armazenar as mensagens de forma ordenada, permanente (não podendo ser atualizada) e identificada por um sequenciador único e sequencial chamado offset.
Part. 0
Part. 1
Cruzeiro
Offset 0
Offset 1
Offset 2
- Viabilizar maior throughtput por conta do consumo paralelo;
- Demandam mais I/O por conta da escrita local do Kafka;
- Aumentar o risco de indisponibilidade (caso um broker falhe);
- Aumentar a latência fim-a-fim (por conta de mais I/O para sincronizações etc)
- Podem requerer mais memória do cliente (mais arquivos a serem escritos)
Um broker nada mais é do que um servidor que integra o cluster Kafka.
Broker 1
Broker 2
Broker 3
Cada broker é identificado por um ID (Inteiro).
Broker 1
Para tópicos multiparticionados, cada broker irá conter partições específicas.
Partição 1 | Partição 2 |
---|
Tópico A
Partição 1 |
---|
Tópico B
Broker 2
Partição 3 |
---|
Tópico A
Partição 1 | Partição 2 |
---|
Tópico C
Broker 3
Partição 2 | Tópico 3 |
---|---|
Partição 4 | Partição 5 |
Tópico B
Broker 1
Os tópicos devem, por segurança, ter um fator de replicação maior que 1 (o indicado são 3).
Partição 1 | Partição 2 |
---|
Tópico A
Broker 2
Broker 3
Partição 1 | Partição 2 |
---|
Partição 1 | Partição 2 |
---|
Tópico A
Tópico A
Desta forma, caso um broker caia, outro broker poderá continuar disponibilizando os dados.
Broker 1
Cada partição de um tópico terá um único broker lider, que irá efetivamente disponibilizar os dados.
Partição 1 |
---|
Tópico A
Broker 2
Broker 3
Partição 1 |
---|
Partição 1 |
---|
Tópico A
Tópico A
Os demais brokers serão apenas instâncias ISR (In-Sync Replica) para aquela partição. Porém, caso o lider caia, um dos brokers ISR se torna o novo lider. Todo esse processo é gerenciado pelo Zookeeper.
LÍDER
ISR
ISR
Os produtores escrevem dados nos tópicos.
O Kafka tem um mecanismo próprio para definir em qual partição ele deve realizar a escrita. Entretanto, é possível "definir" isso através de keys.
A escrita, por padrão, segue um balanceamento de carga através do escalonamento round robin.
Produtor
Partição 0 |
---|
Broker 1 (Tópico A)
Partição 0 |
---|
Broker 2 (Tópico A)
É possível produzir uma mensagem utilizando uma chave.
Mensagens produzidas utilizando chaves são sempre armazenadas na mesma partição.
Mensagens com chaves são normalmente utilizadas quando há necessidade de ordenar as mensagens.
Produtor
Partição 0 |
---|
Broker 1 (Tópico A)
Partição 0 quando
Key "p0"
Partição 1 quando
Key "p1"
Partição 1 |
---|
É possível receber a confirmação de escrita dos dados no broker (data acknowledgement).
Os níveis de confirmação é uma propriedade (acks) que pode assumir os valores:
acks=0: O produtor não aguarda a confirmação (pode acarretar perda de dados);
acks=1: O produtor aguarda a confirmação do líder da partição. Pode implicar em perda de dados em sincronização.
acks=all: O produtor aguarda a confirmação do líder e das réplicas daquela partição. Aconselhável quando não deve haver nenhuma perda de dados.
Partição 0 |
---|
Broker 1 (Tópico A)
Partição 1 |
---|
Broker 2 (Tópico A)
Produtor
Um consumer realiza uma conexão com o Kafka a fim de realizar a leitura dos dados de um determinado tópico.
A leitura acontece das mensagens mais antigas até as mais novas.
É possível definir tanto uma partição quanto um offset específico para a leitura.
Consumidor
Partição 0 |
---|
Broker 1 (Tópico A)
Caso dois consumers se conectem a um mesmo tópico eles irão ler duas vezes a mesma mensagem. Ou seja, haverá duplicidade.
Entretanto, é possível evitar isso através da utilização de group ids que representem um grupo de consumers. Desta forma, o Kafka realiza a distribuição das mensagens entre os consumidores conectados em um mesmo grupo.
Consumidor A
Consumidor B
Consumidor C
Consumer Group
Partição 0 |
---|
Broker 1 (Tópico A)
Kafka Cluster
Msg 1 - A
Msg 2 - B
Msg 3 - C
A, B
C
A, B, C
Existem outros aspectos importantes do Apache Kafka que podem ser encontrados na documentação da ferramenta!
A documentação do Apache Kafka possui um QuickStart muito didático. Portanto, nos guiaremos a partir dele.
Primeiramente, iremos
realizar o download e
descompactar o Apache Kafka
Executamos o Zookeeper
sh bin/zookeeper-server-start.sh config/zookeeper.properties
Em seguida o Kafka
sh bin/kafka-server-start.sh config/server.properties
Criamos um Tópico
sh bin/kafka-topics.sh --create --bootstrap-server localhost:9092 --replication-factor 1 --partitions 1 --topic test
Verificamos se o Tópico foi criado
sh bin/kafka-topics.sh --list --bootstrap-server localhost:9092
Agora podemos enviar algumas mensagens
sh bin/kafka-console-producer.sh --bootstrap-server localhost:9092 --topic test
Note que o terminal irá ficar aguardando por inputs. para encerrar, basta executar "Ctrl + C"
Caso queira ler desde o começo do tópico, é possível utilizar a flag "--from-begining" para realizar a leitura desde o começo do tópico. Entretanto, essa funcionalidade não é compatível com consumer groups.
Agora que temos tópico e mensagens, vamos ler?
sh bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test