4. Motivação
● Dados de atividades e dados operacionais
○ Requisito importante para aplicações Web
○ Resolvido normalmente com logging
○ Escalável para aplicações pequenas
5. Motivação
● Problema: tempo real
○ Fluxo de dados muito alto (vazão alta)
○ Logging tradicional:
■ Latência torna inviável a utilização
■ Pode prejudicar o comportamento do sistema
● Objetivo:
○ Baixa latência para grandes volumes de dados
6. Apache Kafka
● Desenvolvida no LinkedIn
● Sistema de mensagens persistentes
● Baseada no modelo Publish-Subscribe
● Linguagem Scala
● Quem utiliza?
7. Apache Kafka
● Características
○ Distribuído
■ Consumidores e produtores espalhados pela
rede
○ Escalável
■ Vazão alta
■ Baixa latência
○ Simples
■ Característica do modelo
■ Desacoplamento
9. Eficiência
● Don't fear the filesystem!
○ Sem cache em memória (a nível de processo)
■ Overhead mínimo com garbage collecting
■ Cache a nível de sistema de arquivos
○ Estruturas de dados eficientes para acesso
● Armazenamento simples
○ Cada partição de tópico é um "log" lógico
■ Conjuntos de arquivos de tamanho fixo
○ Espera um tempo por mais mensagens antes de
gravar no disco
■ Só ficam visíveis para consumo após gravadas
10. Eficiência
● Transferência eficiente
○ Mensagens podem ser enviadas em "lotes"
■ Leitura é "sequencial"
● Stateless
○ Estado de consumo (mensagens consumidas) é
mantido no consumidor e não nos brokers
○ Mensagens são removidas automaticamente após
certo período
■ Tipicamente, 7 dias
11. Coordenação distribuída
● Grupo de consumidores (um ou mais)
● Mensagens de uma partição são consumidas por um
único consumidor
○ Diminuir overhead de coordenação
● Consumidores coordenam entre eles próprios de forma
descentralizada
○ Consensus Zookeeper
12. Coordenação distribuída
● Uso do Zookeeper auxilia na coordenação
○ Armazenam informações em registros
■ Consumidores
■ Brokers
■ Partições
● Mudanças no conjunto de brokers ou no grupo de
consumidores são notificadas por watchers
13. Entrega e confiabilidade
● Garante "pelo menos" uma entrega
○ Entregas duplicadas devem ser tratadas na
aplicação
● Ordenação
○ Mensagens de mesma partição são entregues em
ordem
○ Não há garantia para partições diferentes
● Integridade
○ Mensagens entregues possuem CRC
○ Remove mensagens corrompidas
14. Tolerância a faltas
● O que acontece se um broker falhar?
○ Suas partições são removidas do registro
○ Mensagens não consumidas ficam indisponíveis
○ Se o sistema de armazenamento for permanentemente
danificado, suas mensagens estão perdidas
■ Não há replicação
● O que acontece se um consumidor falhar?
○ Sua entrada e suas partições de consumo são removidas
dos registros
● Após a falha, os consumidores são notificados e inicia um
balanceamento
16. LinkedIn: Resultados Experimentais
● Experimento comparativo
● Configurações do ambiente
○ 2 máquinas Linux, 8 cores de 2GHz, 16GB de
memória, 6 discos (RAID 10)
○ Link de 1GB
● Um produtor, um consumidor, 100 tópicos
17. LinkedIn: Resultados Experimentais
● Teste para produtor
○ 10 milhões de mensagens (200B) produzidas
● Muito menos overhead de armazenamento
○ ActiveQM - 70% mais de espaço (em 10 milhões mensagens)
● Vantagens
○ Não espera por confirmação dos brokers
■ Aumento da vazão do publisher
○ Formato de mensagem mais eficiente (batch size: 50)
● Desvantagens
○ Não existe garantia que o broker recebeu a mensagem
18. LinkedIn: Resultados Experimentais
● Teste para consumidor
○ Um consumidor para recuperar um total de 10
milhões de mensagens (200B)
● Consumiu quatro vezes mais que os demais
● Vantagens
○ Redução do overhead de transmissão
■ API Send File
○ Não há atividades de escrita no disco
21. Testes de Desempenho
● Usando simulador do Kafka
● Cenários remotos com mesmos nós
○ Broker em Virgínia/EUA
○ 2 consumidores em São Paulo/SP
○ 2 produtores em São Paulo/SP
● Variando parâmetros:
○ Tamanho do lote (produtor)
■ Em número de mensagens
○ Tamanho da mensagem (produtor)
■ Em KB
● N° de mensagens produzidas fixo
○ 20.000
25. Exemplo de Uso (Implementação)
● Consumidor / produtor simples
● Informações básicas de configuração:
○ Arquivos .properties ou diretamente no código
○ Dois modos de conexão
■ Zookeeper (recomendado)
■ Conexão direta ao(s) broker(s)
28. Considerações Finais
● Trabalhos futuros / em andamento
○ Replicação
○ Hierarquia de tópicos
○ Clientes em outras linguagens
● Dificuldade na configuração
○ Material da página só fornece exemplo 'local'
■ server.properties
● hostname => recomenda-se definir
29.
30. Referências
● Kafka: a Distributed Messaging System for Log
Processing. (Jay Kreps, Neha Narkhede, Jun Rao)
● Building LinkedIn’s Real-time Activity Data Pipeline.
(LinkedIn team)
● Disponível em: http://incubator.apache.
org/kafka/projects.html. Acesso em: 9 de novembro de
2012.
● Disponível em: https://cwiki.apache.
org/confluence/display/KAFKA/Index. Acesso em: 9 de
novembro de 2012.