Apache Kafka é uma plataforma de streaming de dados responsável por transmitir dados de vários fontes para muito alvos. As fontes também são chamadas produtores. Os dados produzidos são necessários para um grupo completamente diferente chamado consumidores para vários propósitos. Kafka é a camada que fica entre os produtores e consumidores e agrega os dados em um pipeline utilizável. Além disso, o próprio Kafka é uma plataforma distribuída, então a camada kafka é composta por vários servidores que executam um kafka, esses servidores ou nós são, portanto, conhecidos como kafka Corretores.

Essa visão geral é um pouco no resumo, então vamos aterrar em um cenário do mundo real, imagine que você precisa monitorar vários servidores da web. Cada um executando seu próprio site, e novos logs estão sendo gerados constantemente em cada um deles a cada segundo do dia. Além disso, existem vários servidores de email que você precisa monitorar também.

Pode ser necessário armazenar esses dados para fins de manutenção e cobrança, que é um trabalho em lote que não requer atenção imediata. Você pode querer executar análises nos dados para tomar decisões em tempo real, o que requer informações precisas e imediatas de dados. De repente, você se encontra na necessidade de simplificar os dados de maneira sensata para todas as várias necessidades. Kafka atua como a camada de abstração à qual várias fontes podem publicar diferentes fluxos de dados e um dado consumidor pode se inscrever nos fluxos que encontra relevantes. Kafka garantirá que os dados sejam bem ordenados. São os internos de Kafka que precisamos entender antes de chegarmos ao tópico de particionamento e chaves.

Tópicos, corretores e partições Kafka

Kafka Tópicos são como tabelas de um banco de dados. Cada tópico consiste em dados de uma fonte específica de um determinado tipo. Por exemplo, a saúde do seu cluster pode ser um tópico que consiste em CPU e informações de utilização de memória. Da mesma forma, o tráfego de entrada para o cluster pode ser outro tópico.

Kafka foi projetado para ser horizontalmente escalável. Ou seja, uma única instância de Kafka consiste em múltiplos kafka corretores Executando vários nós, cada um pode lidar com fluxos de dados paralelos ao outro. Mesmo que alguns dos nós falhem, seu pipeline de dados pode continuar funcionando. Um determinado tópico pode então ser dividido em vários partições. Este particionamento é um dos fatores cruciais por trás da escalabilidade horizontal de Kafka.

Múltiplo produtores, Fontes de dados para um determinado tópico, podem escrever para esse tópico simultaneamente porque cada um escreve em uma partição diferente, em qualquer ponto. Agora, geralmente os dados são atribuídos a uma partição aleatoriamente, a menos que forneçamos uma chave.

Particionamento e pedidos

Apenas para recapitular, os produtores estão escrevendo dados para um determinado tópico. Esse tópico é realmente dividido em várias partições. E cada partição vive independentemente dos outros, mesmo para um determinado tópico. Isso pode levar a muita confusão quando a ordem dos dados de dados. Talvez você precise dos seus dados em uma ordem cronológica, mas ter várias partições para o seu datastream não garante pedidos perfeitos.

Você pode usar apenas uma única partição por tópico, mas isso derrota todo o objetivo da arquitetura distribuída de Kafka. Então, precisamos de outra solução.

Chaves para partições

Os dados de um produtor são enviados para dividir aleatoriamente, como mencionamos antes. Mensagens são os pedaços reais de dados. O que os produtores podem fazer além de apenas enviar mensagens é adicionar uma chave que acompanha.

Todas as mensagens que acompanham a chave específica serão destinadas à mesma partição. Assim, por exemplo, a atividade de um usuário pode ser rastreada cronologicamente se os dados desse usuário forem marcados com uma chave e, portanto, sempre acabam em uma partição. Vamos chamar essa partição P0 e o usuário u0.

Partição P0 sempre pegará as mensagens relacionadas ao U0, porque essa chave as une. Mas isso não significa que P0 está apenas ligado a isso. Também pode levar mensagens de U1 e U2 se tiver capacidade para fazê -lo. Da mesma forma, outras partições podem consumir dados de outros usuários.

O ponto em que os dados de um determinado usuário não estão espalhados por diferentes partições, garantindo a ordem cronológica para esse usuário. No entanto, o tópico geral de dados do usuário, Ainda pode aproveitar a arquitetura distribuída de Apache Kafka.

Conclusão

Enquanto sistemas distribuídos como Kafka resolvem alguns problemas mais antigos, como falta de escalabilidade ou ter um único ponto de falha. Eles vêm com um conjunto de problemas exclusivos de seu próprio design. Antecipar esses problemas é um trabalho essencial de qualquer arquiteto do sistema. Além disso, às vezes você realmente precisa fazer uma análise de custo-benefício para determinar se os novos problemas são uma troca digna para se livrar dos mais velhos. Pedidos e sincronização são apenas a ponta do iceberg.

Felizmente, artigos como esses e a documentação oficial podem ajudá -lo ao longo do caminho.