Kafka: API de consumidor vs API de streams

Recentemente, comecei a aprender Kafka e acabei com essas perguntas.

1. Qual é a diferença entre Consumer e Stream? Para mim, se alguma ferramenta / aplicativo consome mensagens do Kafka é um consumidor do mundo Kafka.

2. Como o Stream é diferente, pois também consome ou produz mensagens para o Kafka? e por que isso é necessário, pois podemos escrever nosso próprio aplicativo de consumidor usando a API do consumidor e processá-los conforme necessário ou enviá-los ao Spark a partir do aplicativo de consumidor?

Eu pesquisei no Google sobre isso, mas não obtive boas respostas para isso. Desculpe se esta pergunta é muito trivial.

Atualização em 09 de abril de 2018 : hoje em dia você também pode usar o ksqlDB , o banco de dados de streaming de eventos do Kafka, para processar seus dados no Kafka. O ksqlDB é construído sobre a API Streams de Kafka e também vem com suporte de primeira classe para "fluxos" e "tabelas".

qual é a diferença entre API de consumidor e API de streams?

A biblioteca Streams do Kafka ( https://kafka.apache.org/documentation/streams/ ) é construída sobre os clientes produtores e consumidores do Kafka. O Kafka Streams é significativamente mais poderoso e também mais expressivo do que os clientes simples.

É muito mais simples e rápido escrever um aplicativo do mundo real do início ao fim com o Kafka Streams do que com o consumidor comum.

Aqui estão alguns dos recursos da API Kafka Streams, muitos dos quais não são suportados pelo cliente consumidor (exigiria que você mesmo implemente os recursos ausentes, essencialmente reimplementando Kafka Streams).

• Oferece suporte à semântica de processamento exatamente uma vez por meio de transações Kafka (o que significa EOS )
• Suporta processamento com estado tolerante a falhas (bem como sem estado, é claro), incluindo junções de streaming , agregações e janelas . Em outras palavras, ele oferece suporte ao gerenciamento do estado de processamento do seu aplicativo pronto para uso.
• Suportes de processamento em tempo evento assim como o processamento baseado em processamento em tempo e ingestão de tempo . Ele também processa perfeitamente dados fora de ordem .
• Possui suporte de primeira classe para fluxos e tabelas , que é onde o processamento de fluxo encontra os bancos de dados; na prática, a maioria dos aplicativos de processamento de fluxo precisam de ambos os fluxos E tabelas para implementar seus respectivos casos de uso, portanto, se uma tecnologia de processamento de fluxo não tiver nenhuma das duas abstrações (digamos, nenhum suporte para tabelas), você ficará preso ou deverá implementar manualmente essa funcionalidade sozinho (boa sorte com isso...)
• Oferece suporte a consultas interativas (também chamadas de 'estado consultável') para expor os resultados de processamento mais recentes a outros aplicativos e serviços
• É mais expressiva: ele vem com (1) um estilo de programação funcional DSL com operações tais como map, filter, reducebem como (2) um estilo imperativo API processador para, por exemplo fazendo processamento de eventos complexos (CEP), e (3) você pode até combinar o DSL e a API do processador.
• Possui seu próprio kit de teste para teste de unidade e integração.

Consulte http://docs.confluent.io/current/streams/introduction.html para uma introdução mais detalhada, mas ainda de alto nível, da API Kafka Streams, que também deve ajudá-lo a compreender as diferenças para o consumidor Kafka de nível inferior cliente.

Além do Kafka Streams, você também pode usar o banco de dados de streaming de eventos ksqlDB para processar seus dados no Kafka. O ksqlDB foi desenvolvido com base no Kafka Streams. Ele oferece suporte essencialmente aos mesmos recursos do Kafka Streams, mas você escreve streaming de SQL em vez de Java ou Scala. Programaticamente, você pode interagir com ksqlDB por meio de uma CLI ou API REST; ele também tem um cliente Java nativo caso você não queira usar REST.

Então, como a API do Kafka Streams é diferente, já que também consome ou produz mensagens para o Kafka?

Sim, a API do Kafka Streams pode tanto ler dados quanto gravar dados no Kafka. Ele suporta transações Kafka, então você pode, por exemplo, ler uma ou mais mensagens de um ou mais tópicos, opcionalmente atualizar o estado de processamento se você precisar e, em seguida, escrever uma ou mais mensagens de saída para um ou mais tópicos - todos como um operação atômica.

e por que isso é necessário, pois podemos escrever nosso próprio aplicativo de consumidor usando a API do consumidor e processá-los conforme necessário ou enviá-los ao Spark a partir do aplicativo de consumidor?

Sim, você poderia escrever seu próprio aplicativo de consumidor - como mencionei, a API Kafka Streams usa o próprio cliente consumidor Kafka (mais o cliente produtor) - mas você teria que implementar manualmente todos os recursos exclusivos que a API Streams fornece . Veja a lista acima para tudo o que você ganha "de graça". Portanto, é uma circunstância bastante rara que um usuário escolha o cliente consumidor simples em vez da biblioteca mais poderosa do Kafka Streams.

O componente Kafka Stream desenvolvido para suportar o tipo ETL de transformação de mensagem. Significa o fluxo de entrada do tópico, transformação e saída para outros tópicos. Ele suporta processamento em tempo real e ao mesmo tempo oferece suporte a recursos analíticos avançados, como agregação, janelamento, junção, etc.

"O Kafka Streams simplifica o desenvolvimento de aplicativos ao construir sobre as bibliotecas de produtor e consumidor Kafka e aproveitar os recursos nativos do Kafka para oferecer paralelismo de dados, coordenação distribuída, tolerância a falhas e simplicidade operacional."

Abaixo estão os principais recursos arquitetônicos do Kafka Stream. Consulte aqui

1. Partições e tarefas de fluxo : Kafka Streams usa os conceitos de partições e tarefas como unidades lógicas de seu modelo de paralelismo com base nas partições de tópico Kafka.
2. Modelo de encadeamento: o Kafka Streams permite que o usuário configure o número de encadeamentos que a biblioteca pode usar para paralelizar o processamento em uma instância do aplicativo.
3. Armazenamento de estado local : Kafka Streams fornece os chamados armazenamentos de estado, que podem ser usados ​​por aplicativos de processamento de fluxo para armazenar e consultar dados, o que é um recurso importante ao implementar operações com estado
4. Tolerância a falhas: o Kafka Streams se baseia em recursos de tolerância a falhas integrados nativamente ao Kafka. As partições Kafka são altamente disponíveis e replicadas, portanto, quando os dados de fluxo são persistidos no Kafka, eles ficam disponíveis mesmo se o aplicativo falhar e precisar reprocessá-los.

Com base no meu entendimento, abaixo estão as principais diferenças que estou aberto a atualizar se algum ponto estiver faltando ou enganando

Onde usar Consumidor - Produtor:

1. Se houver consumidores únicos, consuma o processo de mensagem, mas não divulgue para outros tópicos.
2. Como ponto 1, se apenas o produtor produziu a mensagem, não precisamos do Kafka Stream.
3. Se a mensagem do consumidor for de um cluster Kafka, mas publicar em diferentes tópicos de cluster Kafka. Nesse caso, até você pode usar o Kafka Stream, mas precisa usar um Produtor separado para publicar mensagens em clusters diferentes. Ou simplesmente use o mecanismo Kafka Consumidor - Produtor.
4. Processamento em lote - se houver um requisito para coletar uma mensagem ou tipo de processamento em lote, é bom usar a forma tradicional normal.

Onde usar o Kafka Stream:

1. Se você consumir mensagens de um tópico, transformar e publicar em outros tópicos, o Kafka Stream é mais adequado.
2. Processamento em tempo real, análise em tempo real e aprendizado de máquina.
3. Transformação com estado, como agregação, janela de junção, etc.
4. Planejando usar armazenamentos estaduais locais ou armazenamentos estaduais montados, como Portworx etc.
5. Obtenha exatamente uma semântica de processamento e tolerância a falhas definida automaticamente.