Brokers de mensagens tradicionais e dados de streaming

De acordo com o site Kafka :

"O Kakfa é usado para criar pipelines de dados em tempo real e aplicativos de streaming " .

Pesquisando na Internet em toda parte, encontrei a seguinte definição geralmente aceita do que são " dados de fluxo ":

• Dados de fluxo são dados que fluem contiguamente de uma fonte para um destino em uma rede; e
• Os dados do fluxo não são de natureza atômica, o que significa que qualquer parte do fluxo de dados é significativa e processável, em oposição a um arquivo cujos bytes não significam nada, a menos que você tenha todos eles; e
• Os dados do fluxo podem ser iniciados / parados a qualquer momento; e
• Os consumidores podem anexar e desanexar de um fluxo de dados à vontade e processar apenas as partes desejadas

Agora, se algo que eu disse acima estiver incorreto, incompleto ou totalmente errado, comece me corrigindo! Supondo que estou mais ou menos no caminho certo, então ...

Agora que entendo o que são "dados em fluxo", entendo o que Kafka e Kinesis querem dizer quando se autodenominam como middleware de processamento / intermediação para aplicativos com dados em fluxo. Mas isso despertou meus interesses: o "fluxo de middleware" como Kafka ou Kinesis pode / deve ser usado para dados que não são de fluxo contínuo, como os intermediários de mensagens tradicionais? E vice-versa: os MQs tradicionais como RabbitMQ, ActiveMQ, Apollo etc. podem ser usados ​​para transmitir dados?

Vamos dar um exemplo em que um aplicativo enviará sua barragem constante de mensagens JSON que precisam ser processadas e o processamento é bastante complexo (validação, transformações nos dados, filtragem, agregações etc.):

• Caso nº 1: as mensagens são cada quadro de um filme; essa é uma bagagem JSON por quadro de vídeo que contém os dados do quadro e alguns metadados de suporte
• Caso 2: As mensagens são dados de séries temporais, talvez os batimentos cardíacos de alguém em função do tempo. Portanto, a mensagem nº 1 é enviada representando meu batimento cardíaco em t = 1, a mensagem nº 2 contém meu batimento cardíaco em t = 2, etc.
• Caso nº 3: os dados são completamente díspares e não relacionados ao tempo ou como parte de qualquer "fluxo de dados". Talvez os eventos de auditoria / segurança sejam disparados quando centenas de usuários navegam no aplicativo clicando nos botões e realizando ações

Com base em como o Kafka / Kinesis é cobrado e no meu entendimento sobre o que são "dados de streaming", eles parecem candidatos óbvios para os Casos 1 (dados de vídeo contíguos) e 2 (dados de séries temporais contíguas). No entanto, não vejo nenhuma razão para que um mediador de mensagens tradicional como o RabbitMQ não possa lidar com essas duas entradas com eficiência.

E no Caso # 3, somos fornecidos apenas a um evento que ocorreu e precisamos processar uma reação a esse evento. Então, para mim, isso diz respeito à necessidade de um corretor tradicional como o RabbitMQ. Mas também não há razão para que Kafka ou Kinesis não possam lidar com o processamento de dados de eventos.

Então, basicamente, estou procurando estabelecer uma rubrica que diz: Tenho X dados com características Y. Eu deveria usar um processador de fluxo como o Kafka / Kinesis para lidar com isso. Ou, inversamente, um que me ajude a determinar: eu tenho dados W com características Z. Eu devo usar um intermediário de mensagens tradicional para lidar com isso.

Por isso, pergunto: Quais fatores sobre os dados (ou não) ajudam a orientar a decisão entre o processador de fluxo ou o intermediário de mensagens, pois ambos podem lidar com dados de fluxo contínuo e ambos podem lidar com dados de mensagem (sem fluxo contínuo)?

Kafka lida com registros ordenados de mensagens atômicas. Você pode vê-lo como o pub/submodo de intermediários de mensagens, mas com uma ordem estrita e a capacidade de reproduzir ou procurar o fluxo de mensagens em qualquer ponto do passado que ainda esteja sendo mantido em disco (o que pode ser para sempre).

O sabor de streaming de Kafka se opõe à chamada de procedimento remoto, como Thrift ou HTTP, e ao processamento em lote, como no ecossistema Hadoop. Ao contrário do RPC, os componentes se comunicam de forma assíncrona: podem passar horas ou dias entre o envio de uma mensagem e o momento em que o destinatário acorda e age sobre ela. Pode haver muitos destinatários em diferentes momentos, ou talvez ninguém se dê ao trabalho de consumir uma mensagem. Vários produtores poderiam produzir o mesmo tópico sem o conhecimento dos consumidores. Kafka não sabe se você está inscrito ou se uma mensagem foi consumida. Uma mensagem é simplesmente confirmada no log, onde qualquer parte interessada pode lê-la.

Ao contrário do processamento em lote, você está interessado em mensagens únicas, não apenas em coleções gigantes de mensagens. (Embora não seja incomum arquivar mensagens Kafka em arquivos Parquet no HDFS e consultá-las como tabelas do Hive).

Caso 1 : Kafka não preserva nenhuma relação temporal específica entre produtor e consumidor. É um ajuste inadequado para a transmissão de vídeo porque o Kafka pode desacelerar, acelerar, entrar em ação e iniciar, etc. Para a mídia de streaming, queremos trocar a taxa de transferência geral em troca da latência baixa e, mais importante, estável (caso contrário, conhecido como jitter baixo). Kafka também se esforça ao máximo para nunca perder uma mensagem. Com o streaming de vídeo, normalmente usamos UDP e nos contentamos em soltar um quadro aqui e ali para manter o vídeo em execução. O SLA em um processo suportado por Kafka geralmente é de segundos a minutos, quando íntegro, horas ou dias, quando íntegro. O SLA da mídia de streaming está em dezenas de milissegundos.

A Netflix pode usar o Kafka para mover quadros em um sistema interno que transcodifica terabytes de vídeo por hora e os salva em disco, mas não para enviá-los para a tela.

Caso 2 : Absolutamente. Usamos Kafka dessa maneira no meu empregador.

Caso 3 : você pode usar o Kafka para esse tipo de coisa, e nós o fazemos, mas você está pagando uma sobrecarga desnecessária para preservar os pedidos. Como você não se importa com a ordem, provavelmente poderá extrair um pouco mais de desempenho de outro sistema. Porém, se sua empresa já mantém um cluster Kafka, é melhor reutilizá-lo, em vez de assumir a carga de manutenção de outro sistema de mensagens.

Kafka / Kinesis é modelado como um fluxo. Um fluxo tem propriedades diferentes das mensagens.

• Os fluxos têm contexto para eles. Eles têm ordem. Você pode aplicar funções de janela em fluxos. Embora cada item em um fluxo seja significativo, ele pode ser mais significativo com o contexto ao seu redor
• Como os fluxos têm ordem, você pode usá-lo para fazer determinadas declarações sobre a semântica do processamento. Por exemplo, o Apache Trident supostamente tem semântica exata ao consumir de um fluxo Kafka.
• Você pode aplicar funções aos fluxos. Você pode transformar um fluxo sem realmente consumi-lo. Você pode consumir preguiçosamente um fluxo. Você pode pular partes de um fluxo.
• É possível reproduzir inerentemente os fluxos no Kafka, mas não é possível (sem software adicional) reproduzir as filas de mensagens. Isso é útil quando você nem sabe o que deseja fazer com os dados ainda. Também é útil para treinar IA.

Geralmente, use Kafka para processamento de fluxo offline, use filas de mensagens para mensagens cliente-servidor em tempo real.

Exemplos de casos de uso do pivotal :

Kafka: rastreamento de atividades do site, métricas, agregação de logs, processamento de fluxo, fornecimento de eventos e logs de confirmação

RabbitMQ: sistema de mensagens de uso geral ..., geralmente usado para permitir que os servidores da Web respondam às solicitações rapidamente, em vez de serem forçados a executar procedimentos com muitos recursos, enquanto o usuário aguarda o resultado. Use quando você precisar usar protocolos existentes, como AMQP 0-9-1, STOMP, MQTT, AMQP 1.0

Às vezes, pode ser útil usar os dois! Por exemplo, no Caso de Uso 2, se esse fosse um fluxo de dados de um marcapasso, eu faria com que o marcapasso transmitisse dados de pulsação para uma fila de mensagens RabbitMQ (usando um protocolo legal como o MQTT), onde são processados ​​imediatamente para veja se o coração da fonte ainda está batendo. Isso poderia alimentar um painel e um sistema de resposta a emergências. A fila de mensagens também depositaria os dados da série temporal no Kafka, para que pudéssemos analisar os dados da pulsação ao longo do tempo. Por exemplo, podemos implementar um algoritmo para detectar doenças cardíacas observando tendências no fluxo de batimentos cardíacos.