Este é um artigo traduzido originalmente publicado no blog do Kai Waehner: “When NOT to use Apache Kafka?”. Assine a newsletter do Kai para se manter atualizado com novas publicações.
O Apache Kafka é o padrão de fato para streaming de eventos para processar dados em movimento. Esta postagem do blog explora quando NÃO usar o Apache Kafka. Quais casos de uso não são adequados para o Kafka? Que limitações tem Kafka? Como qualificar Kafka, pois não é a ferramenta certa para o trabalho?
O Apache Kafka é o padrão de fato para streaming de eventos para processar dados em movimento. Com seu significativo crescimento de adoção em todos os setores, recebo uma pergunta muito válida toda semana: Quando NÃO usar o Apache Kafka? Quais são as limitações da plataforma de streaming de eventos? Quando Kafka simplesmente não fornece os recursos necessários? Como qualificar Kafka, pois não é a ferramenta certa para o trabalho? Esta postagem de blog explora os DOs e DONTs. Seções separadas explicam quando usar o Kafka, quando NÃO usar o Kafka e quando TALVEZ usar o Kafka.
Tendências de Mercado – Um Mundo Conectado
Vamos começar entendendo por que Kafka aparece em todos os lugares nesse meio tempo. Isso esclarece a enorme demanda do mercado por streaming de eventos, mas também mostra que não há bala de prata para resolver todos os problemas. Kafka NÃO é a bala de prata para um mundo conectado, mas um componente crucial!
O mundo está cada vez mais conectado. Grandes volumes de dados são gerados e precisam ser correlacionados em tempo real para aumentar a receita, reduzir custos e reduzir riscos . Eu poderia escolher quase qualquer indústria. Alguns são mais rápidos. Outros são mais lentos. Mas o mundo conectado está chegando em todos os lugares. Pense em manufatura, cidades inteligentes, jogos, varejo, bancos, seguros e assim por diante. Se você olhar meus blogs anteriores, poderá encontrar casos de uso relevantes do Kafka para qualquer setor.
Escolhi duas tendências de mercado que mostram esse crescimento insano de dados e a criação de inovação e novos casos de uso de ponta (e por que a adoção de Kafka também é insana em todos os setores).
Carros Conectados – Volume insano de dados de telemetria e pós-venda
Aqui está a “ Análise de Oportunidade Global e Previsão da Indústria, 2020–2027 ” pela Allied Market Research:
O mercado de carros conectados inclui uma variedade muito maior de casos de uso e indústrias do que a maioria das pessoas pensa . Alguns exemplos: infraestrutura de rede e conectividade, segurança, entretenimento, varejo, pós-venda, seguro de veículos, uso de dados de terceiros (por exemplo, cidade inteligente) e muito mais.
Games – Bilhões de jogadores e receitas massivas
A indústria de jogos já é maior do que todas as outras categorias de mídia combinadas , e isso ainda é apenas o começo de uma nova era – como o Bitkraft descreve:
Milhões de novos jogadores se juntam à comunidade de jogos todos os meses em todo o mundo. Conectividade e smartphones baratos são vendidos em países menos ricos. Novos modelos de negócios como “jogar para ganhar” mudam a forma como a próxima geração de jogadores joga um jogo. Tecnologias mais escaláveis e de baixa latência, como 5G, permitem novos casos de uso. Blockchain e NFT (Non-Fungible Token) estão mudando o mercado de monetização e cobrança para sempre.
Essas tendências de mercado em todos os setores esclarecem por que a necessidade de processamento de dados em tempo real aumenta significativamente a cada trimestre. O Apache Kafka se estabeleceu como o padrão de fato para o processamento de fluxos de dados analíticos e transacionais em escala . No entanto, é crucial entender quando (não) usar o Apache Kafka e seu ecossistema em seus projetos.
O que é Apache Kafka e o que NÃO é?
Kafka é muitas vezes incompreendido . Por exemplo, ainda ouço com muita frequência que Kafka é uma fila de mensagens. Parte do motivo é que alguns fornecedores apenas o lançam para um problema específico (como ingestão de dados em um data lake ou data warehouse) para vender seus produtos. Então, resumindo:
Kafka é…
uma plataforma de mensagens em tempo real escalável para processar milhões de mensagens por segundo.
uma plataforma de streaming de eventos para grandes volumes de análise de big data e pequenos volumes de processamento de dados transacionais .
um armazenamento distribuído fornece desacoplamento real para tratamento de contrapressão, suporte a vários protocolos de comunicação e reprodutibilidade de eventos com pedido garantido.
uma estrutura de integração de dados para streaming de ETL.
uma estrutura de processamento de dados para processamento contínuo de fluxo sem estado ou com estado.
Essa combinação de características em uma única plataforma torna o Kafka único (e bem-sucedido).
Kafka NÃO é...
um proxy para milhões de clientes (como aplicativos móveis) – mas existem proxies nativos do Kafka (como REST ou MQTT) para alguns casos de uso.
uma plataforma de gerenciamento de APIs – mas essas ferramentas geralmente são complementares e usadas para a criação, gerenciamento do ciclo de vida ou a monetização de APIs Kafka.
um banco de dados para consultas complexas e cargas de trabalho de análise em lote – mas bom o suficiente para consultas transacionais e agregações relativamente simples (especialmente com ksqlDB).
uma plataforma IoT com recursos como gerenciamento de dispositivos - mas a integração direta nativo do Kafka com (alguns) protocolos IoT, como MQTT ou OPC-UA, é possível e a abordagem apropriada para (alguns) casos de uso.
uma tecnologia para aplicações difíceis em tempo real , como sistemas determinísticos ou de segurança crítica – mas isso também vale para qualquer outra estrutura de TI. Sistemas embarcados são um software diferente!
Por esses motivos, o Kafka é complementar, não competitivo, a essas outras tecnologias . Escolha a ferramenta certa para o trabalho e combine-as!
Estudos de caso para Apache Kafka em um mundo conectado
Esta seção mostra alguns exemplos de histórias de sucesso fantásticas em que o Kafka é combinado com outras tecnologias porque faz sentido e resolve o problema de negócios. O foco aqui são estudos de caso que precisam de mais do que apenas Kafka para o fluxo de dados de ponta a ponta .
Não importa se você segue meu blog, conferências do Kafka Summit, plataformas online como Medium ou Dzone ou qualquer outra notícia relacionada à tecnologia. Você encontra muitas histórias de sucesso em torno do streaming de dados em tempo real com o Apache Kafka para grandes volumes de análises e dados transacionais de carros conectados, dispositivos de borda IoT ou aplicativos de jogos em smartphones.
Alguns exemplos em todos os setores e casos de uso:
Audi : plataforma de carros conectados lançada em regiões e provedores de nuvem
BMW : Fábricas inteligentes para a otimização da cadeia de suprimentos e logística
SolarPower : Soluções e serviços completos de energia solar em todo o mundo
Royal Caribbean : Entretenimento em navios de cruzeiro com serviços de borda desconectados e agregação de nuvem híbrida
Disney+ Hotstar : conteúdo de mídia interativo e jogos/apostas para milhões de fãs em seus smartphones
A lista continua e continua.
Então, qual é o problema com todas essas grandes histórias de sucesso da IoT? Bem, não há problema. Mas alguns esclarecimentos são necessários para explicar quando usar streaming de eventos com o ecossistema Apache Kafka e onde outras soluções complementares geralmente o complementam .
Quando usar o Apache Kafka?
Antes de discutirmos quando NÃO usar o Kafka, vamos entender onde usá-lo para ficar mais claro como e quando complementá-lo com outras tecnologias, se necessário.
Vou adicionar exemplos do mundo real para cada seção. Na minha experiência, isso torna muito mais fácil entender o valor agregado.
Kafka consome e processa grandes volumes de IoT e dados móveis em tempo real
Processar grandes volumes de dados em tempo real é um dos recursos críticos do Kafka.
A Tesla não é apenas uma fabricante de automóveis. A Tesla é uma empresa de tecnologia que escreve muitos softwares inovadores e de ponta . Eles fornecem uma infraestrutura de energia para carros com seus Superchargers Tesla, produção de energia solar em suas Gigafactories e muito mais. Processar e analisar os dados de seus veículos, redes inteligentes e fábricas e a integração com o restante dos serviços de back-end de TI em tempo real é uma parte crucial do sucesso.
A Tesla construiu uma infraestrutura de plataforma de dados baseada em Kafka “para suportar milhões de dispositivos e trilhões de pontos de dados por dia”. A Tesla mostrou uma emocionante história e evolução do uso do Kafka em um Kafka Summit em 2019:
Tenha em mente que Kafka é muito mais do que apenas mensagens . Repito isso em quase todos os posts do blog, pois muitas pessoas ainda não entendem. Kafka é uma camada de armazenamento distribuído que realmente separa produtores e consumidores. Além disso, ferramentas de processamento nativas do Kafka, como Kafka Streams e ksqlDB, permitem o processamento em tempo real .
Kafka correlaciona dados de IoT com dados transacionais dos sistemas MES e ERP
A integração de dados em tempo real em escala é relevante para análises e o uso de sistemas transacionais como um sistema ERP ou MES. O middleware Kafka Connect e não-Kafka complementam o núcleo do streaming de eventos para essa tarefa.
A BMW opera cargas de trabalho Kafka de missão crítica na borda (ou seja, nas fábricas inteligentes) e na nuvem pública . Kafka permite desacoplamento, transparência e inovação. Os produtos e a experiência da Confluent adicionam estabilidade. Este último é vital para o sucesso na fabricação. Cada minuto de inatividade custa uma fortuna. Leia meu artigo relacionado “ Apache Kafka as Data Historian – an IIoT / Industry 4.0 Real-Time Data Lake ” para entender como o Kafka melhora a eficácia geral do equipamento (OEE) na fabricação.
A BMW otimiza sua gestão da cadeia de suprimentos em tempo real. A solução fornece informações sobre o estoque certo no local, tanto fisicamente quanto em sistemas transacionais como o ERP da BMW com tecnologia SAP. “Just in time, just in sequence” é crucial para muitas aplicações críticas. A integração entre Kafka e SAP é necessária para quase 50% dos clientes com quem converso neste espaço. Além da integração, muitas plataformas transacionais de ERP e MES de última geração também são alimentadas pelo Kafka.
O Kafka integra-se a toda a TI não IoT da empresa na borda e híbrida ou multinuvem
As implantações de vários clusters e centros de dados cruzados do Apache Kafka tornaram-se a norma e não uma exceção. Conheça vários cenários que podem exigir soluções de vários clusters e veja exemplos do mundo real com seus requisitos e compensações específicos, incluindo recuperação de desastres, agregação para análise, migração para a nuvem, implantações estendidas de missão crítica e Kafka global .
O verdadeiro desacoplamento entre diferentes interfaces é uma vantagem exclusiva do Kafka em relação a outras plataformas de mensagens , como IBM MQ, RabbitMQ ou brokers MQTT. Também explorei isso em detalhes em meu artigo sobre Domain-driven Design (DDD) com Kafka .
Modernização de infraestrutura e arquiteturas de nuvem híbrida com Apache Kafka são comuns em todos os setores.
Um dos meus exemplos favoritos é a história de sucesso da Unity . A empresa fornece uma plataforma de desenvolvimento 3D em tempo real com foco em jogos e em outros setores, como manufatura, com seus recursos de Realidade Aumentada (AR) / Realidade Virtual (VR).
A empresa orientada a dados já teve conteúdo instalado 33 bilhões de vezes em 2019, chegando a 3 bilhões de dispositivos em todo o mundo . A Unity opera em uma das maiores redes de monetização do mundo. Eles migraram essa plataforma do Kafka autogerenciado para o Confluent Cloud totalmente gerenciado. O cutover foi executado pela equipe do projeto sem tempo de inatividade ou perda de dados. Leia a postagem do Unity no Blog do Confluent: “ Como o Unity usa o Confluent para transmissão de eventos em tempo real em escala ”.
Kafka é o back-end escalável em tempo real para serviços de mobilidade e plataformas de jogos/apostas
Muitos serviços de jogos e mobilidade aproveitam o streaming de eventos como a espinha dorsal de sua infraestrutura. Os casos de uso incluem o processamento de dados de telemetria, serviços baseados em localização, pagamentos, detecção de fraudes, retenção de usuários/jogadores, plataforma de fidelidade e muito mais . Quase todas as aplicações inovadoras neste setor requerem streaming de dados em tempo real em escala.
Alguns exemplos:
Serviços de mobilidade : Uber, Lyft, FREE NOW, Grab, Otonomo, Here Technologies, …
Serviços de jogos : Disney+ Hotstar, Sony Playstation, Tencent, Big Fish Games, …
Serviços de apostas : William Hill, Sky Betting, …
Basta olhar para os portais de emprego de qualquer serviço de mobilidade ou jogos. Nem todo mundo está falando sobre o uso de Kafka em público. Mas quase todo mundo está procurando especialistas em Kafka para desenvolver e operar sua plataforma.
Esses casos de uso são tão críticos quanto um processo de pagamento em uma plataforma bancária principal. Conformidade regulatória e perda zero de dados são cruciais . Clusters de várias regiões (ou seja, um cluster Kafka estendido por regiões como Leste, Centro e Oeste dos EUA) permitem alta disponibilidade com tempo de inatividade zero e sem perda de dados, mesmo em caso de desastre .
Veículos, máquinas ou dispositivos IoT incorporam um único agente Kafka
A borda está aqui para ficar e crescer. Alguns casos de uso exigem a implantação de um cluster Kafka ou agente único fora de um data center . Os motivos para operar uma infraestrutura Kafka na borda incluem baixa latência, eficiência de custos, segurança cibernética ou ausência de conectividade com a Internet .
Exemplos de Kafka na borda:
Borda desconectada na logística para armazenar logs, dados de sensores e imagens enquanto estiver offline (por exemplo, um caminhão na rua ou um drone voando em torno de um navio) até que uma boa conexão de internet esteja disponível no centro de distribuição
Comunicação Vehicle-to-Everything (V2X) em um pequeno data center local como AWS Outposts (por meio de um gateway como MQTT se área grande, um número considerável de veículos ou rede ruim) ou via conexão direta do cliente Kafka para algumas centenas de máquinas, por exemplo, em uma fábrica inteligente)
Serviços de mobilidade offline, como a integração de uma infraestrutura de carro com jogos, mapas ou um mecanismo de recomendação com serviços de parceiros processados localmente (por exemplo, o próximo Mc Donalds chega em 10 milhas, aqui está um cupom).
A linha de cruzeiros Royal Caribbean é um grande caso de sucesso para este cenário. Opera os quatro maiores navios de passageiros do mundo. Em janeiro de 2021, a linha opera vinte e quatro navios e tem seis navios adicionais encomendados.
A Royal Caribbean implementou um dos casos de uso mais famosos de Kafka na borda . Cada navio de cruzeiro tem um cluster Kafka rodando localmente para casos de uso como processamento de pagamentos, informações de fidelidade, recomendações de clientes, etc .:
Cobri este exemplo e outras implantações de borda do Kafka em vários blogs. Falei sobre casos de uso para Kafka na borda , mostrei arquiteturas para Kafka na borda e explorei implantações 5G de baixa latência alimentadas por Kafka .
Quando NÃO usar o Apache Kafka?
Finalmente, estamos chegando à seção que todos estavam procurando, certo? No entanto, é crucial primeiro entender quando usar o Kafka. Agora, é fácil explicar quando NÃO usar o Kafka.
Para esta seção , vamos supor que falamos sobre cenários de produção , não algumas soluções feias (?) para conectar o Kafka a algo diretamente para uma prova de conceito; há sempre uma opção rápida e suja para testar algo – e isso é bom para esse objetivo. Mas as coisas mudam quando você precisa dimensionar e implantar sua infraestrutura globalmente, estar em conformidade com a lei e garantir que não haja perda de dados para cargas de trabalho transacionais.
Com isso em mente, é relativamente fácil qualificar o Kafka como uma opção para alguns casos de uso e problemas:
Kafka NÃO é exatamente em tempo real
A definição do termo “tempo real” é difícil. Muitas vezes é um termo de marketing. Os programas em tempo real devem garantir uma resposta dentro das restrições de tempo especificadas.
Kafka – e todos os outros frameworks, produtos e serviços em nuvem usados neste contexto – é apenas soft real time e construído para o mundo de TI . Muitos aplicativos de OT e IoT exigem tempo real duro com picos de latência zero.
O tempo real suave é usado para aplicações como
Mensagens ponto a ponto entre aplicativos de TI
Ingestão de dados de várias fontes de dados em um ou mais coletores de dados
Processamento de dados e correlação de dados (geralmente chamado de fluxo de eventos ou processamento de fluxo de eventos)
Se seu aplicativo requer latência abaixo de milissegundos, Kafka não é a tecnologia certa . Por exemplo, a negociação de alta frequência geralmente é implementada com soluções comerciais proprietárias específicas.
Tenha sempre em mente: a latência mais baixa seria não usar um sistema de mensagens e apenas usar a memória compartilhada . Em uma corrida para a latência mais baixa, Kafka perderá todas as vezes. No entanto, para o log de auditoria e o log de transações ou partes do mecanismo de persistência da troca, não é a perda de dados que se torna mais importante do que a latência e o Kafka vence.
A maioria dos casos de uso em tempo real “somente” requer processamento de dados em milissegundos até o segundo intervalo . Nesse caso, Kafka é uma solução perfeita. Muitas FinTechs, como Robinhood, confiam no Kafka para cargas de trabalho transacionais de missão crítica, até mesmo negociações financeiras. A computação de borda de acesso múltiplo (MEC) é outro excelente exemplo de streaming de dados de baixa latência com Apache Kafka e infraestrutura 5G nativa da nuvem .
Kafka NÃO é determinístico para sistemas embarcados e de segurança crítica
Este é bastante simples e relacionado à seção acima. Kafka não é um sistema determinista. Aplicações críticas de segurança não podem usá-lo para um sistema de controle de motor de carro, um sistema médico como um marca-passo cardíaco ou um controlador de processo industrial.
Alguns exemplos onde Kafka NÃO PODE ser usado para:
Processamento de dados de segurança crítica no carro ou veículo . Isso é Autosar/MINRA C/Assembler e tecnologias similares.
Comunicação CAN Bus entre ECUs.
Robótica . Isso é C/C++ ou linguagens de baixo nível semelhantes combinadas com frameworks como Industrial ROS (Robot Operating System).
Aprendizado de máquina crítico de segurança / aprendizado profundo (por exemplo, para direção autônoma)
Comunicação veículo-veículo (V2V) . Isso é sidelink 5G sem intermediário como Kafka.
Meu post “ Apache Kafka NÃO é difícil em tempo real, MAS é usado em todos os lugares na IoT automotiva e industrial ” explora essa discussão com mais detalhes.
TL;DR: O processamento de dados relacionado à segurança deve ser implementado com linguagens e soluções de programação de baixo nível dedicadas. Isso não é Kafka! O mesmo vale para qualquer outro software de TI . Portanto, não substitua Kafka por IBM MQ, Flink, Spark, Snowflake ou qualquer outro software de TI semelhante.
Kafka NÃO é construído para redes ruins
Kafka requer uma boa conectividade de rede estável entre os clientes Kafka e os corretores Kafka . Portanto, se a rede for instável e os clientes precisarem se reconectar aos brokers o tempo todo, as operações serão desafiadoras e os SLAs serão difíceis de alcançar.
Existem algumas exceções, mas a regra básica é que outras tecnologias são construídas especificamente para resolver o problema de redes ruins . MQTT é o exemplo mais proeminente. Portanto, Kafka e MQTT são amigos, não inimigos. A combinação é super poderosa e muito usada em todos os setores. Por esse motivo, escrevi uma série inteira de blogs sobre Kafka e MQTT .
Construímos uma infraestrutura de carro conectada que processa 100.000 fluxos de dados para previsões em tempo real usando MQTT, Kafka e TensorFlow em uma arquitetura Kappa .
Kafka NÃO fornece conectividade para dezenas de milhares de aplicativos clientes
Outro ponto específico para qualificar o Kafka como uma solução de integração é que o Kafka não pode se conectar a dezenas de milhares de clientes . Se você precisar construir uma infraestrutura de carro conectada ou plataforma de jogos para jogadores móveis, os clientes (ou seja, carros ou smartphones) não se conectarão diretamente ao Kafka.
Um proxy dedicado, como um gateway HTTP ou corretor MQTT, é o intermediário certo entre milhares de clientes e o Kafka para processamento de back-end em tempo real e integração com outros coletores de dados, como data lake, data warehouse ou aplicativos personalizados em tempo real.
Onde estão os limites das conexões do cliente Kafka? Como tantas vezes, isso é difícil de dizer. Tenho visto clientes se conectarem diretamente de seu chão de fábrica na planta via .NET e clientes Java Kafka por meio de uma conexão direta com a nuvem onde o cluster Kafka está sendo executado . As conexões híbridas diretas geralmente funcionam bem se o número de máquinas, PLCs, gateways IoT e dispositivos IoT estiver na casa das centenas. Para um número maior de aplicativos cliente, você precisa avaliar se a) precisa de um proxy no meio ou b) implantar “computação de borda” com ou sem Kafka na borda para menor latência e cargas de trabalho econômicas.
Quando TALVEZ usar o Apache Kafka?
A última seção cobriu cenários em que é relativamente fácil tirar a qualidade do Kafka, pois ele simplesmente não pode fornecer os recursos necessários. Quero explorar alguns tópicos menos aparentes , e depende de várias coisas se Kafka é uma boa escolha ou não.
Kafka (geralmente) NÃO substitui outro banco de dados
Apache Kafka é um banco de dados. Ele fornece garantias ACID e é usado em centenas de empresas para implantações de missão crítica. No entanto, na maioria das vezes, o Kafka não é competitivo com outros bancos de dados . Kafka é uma plataforma de streaming de eventos para mensagens, armazenamento, processamento e integração em escala em tempo real com zero tempo de inatividade ou perda de dados.
O Kafka é frequentemente usado como uma camada central de integração de streaming com essas características. Outros bancos de dados podem criar visualizações materializadas para seus casos de uso específicos, como análises de séries temporais em tempo real, ingestão quase em tempo real em uma infraestrutura de pesquisa de texto ou armazenamento de longo prazo em um data lake.
Em resumo, quando você é perguntado se o Kafka pode substituir um banco de dados, há várias respostas a serem consideradas :
Kafka pode armazenar dados para sempre de maneira durável e de alta disponibilidade, fornecendo garantias de ACID
Outras opções para consultar dados históricos estão disponíveis no Kafka
Complementos nativos do Kafka, como ksqlDB ou armazenamento em camadas, tornam o Kafka mais potente do que nunca para processamento de dados e armazenamento de longo prazo baseado em eventos
Aplicativos com estado podem ser criados aproveitando os clientes Kafka (microsserviços, aplicativos de negócios) sem nenhum outro banco de dados externo
Não é um substituto para bancos de dados existentes, data warehouses ou data lakes como MySQL, MongoDB, Elasticsearch, Hadoop, Snowflake, Google BigQuery, etc.
Outros bancos de dados e Kafka se complementam ; a solução certa deve ser selecionada para um problema; muitas vezes, visualizações materializadas específicas são criadas e atualizadas em tempo real a partir da infraestrutura central baseada em eventos
Diferentes opções estão disponíveis para integração baseada em push e pull bidirecional entre o Kafka e os bancos de dados para complementar um ao outro
Minha postagem no blog “ O Apache Kafka pode substituir um banco de dados, data warehouse ou data lake? ” discute o uso do Kafka como banco de dados com muito mais detalhes.
Kafka (geralmente) NÃO processa mensagens grandes
Kafka não foi construído para mensagens grandes. Período.
No entanto, mais e mais projetos enviam e processam arquivos de 1Mb, 10Mb e até mesmo muito maiores e outras grandes cargas via Kafka. Uma razão é que o Kafka foi projetado para grande volume/taxa de transferência – o que é necessário para mensagens grandes. Um exemplo muito comum que surge regularmente é a ingestão e processamento de grandes arquivos de sistemas legados com Kafka antes de ingerir os dados processados em um Data Warehouse.
No entanto, nem todas as mensagens grandes devem ser processadas com o Kafka. Frequentemente, você deve usar o sistema de armazenamento correto e apenas aproveitar o Kafka para a orquestração . As mensagens baseadas em referência (ou seja, armazenar o arquivo em outro sistema de armazenamento e enviar o link e os metadados) geralmente são o melhor padrão de design:
Conheça os diferentes padrões de projeto e escolha a tecnologia certa para o seu problema.
Para obter mais detalhes e casos de uso sobre como lidar com arquivos grandes com o Kafka, confira esta postagem no blog: " Manipulando mensagens grandes com o Apache Kafka (CSV, XML, imagem, vídeo, áudio, arquivos) ".
Kafka (geralmente) NÃO é o gateway de IoT para a integração de última milha de protocolos industriais…
A integração de última milha com interfaces de IoT e aplicativos móveis é um espaço complicado. Conforme discutido acima, o Kafka não pode se conectar a milhares de clientes Kafka. No entanto, muitos aplicativos móveis e de IoT exigem apenas dezenas ou centenas de conexões . Nesse caso, uma conexão nativa do Kafka é direta usando um dos vários clientes Kafka disponíveis para quase todas as linguagens de programação do planeta.
Suponha que uma conexão no nível TCP com um cliente Kafka faça pouco sentido ou não seja possível. Nesse caso, uma solução muito comum é o REST Proxy como intermediário entre os clientes e o cluster Kafka . Os clientes se comunicam via HTTP(S) síncrono com a plataforma de streaming.
Os casos de uso para APIs HTTP e REST com Apache Kafka incluem o plano de controle (= gerenciamento), o plano de dados (= produzir e consumir mensagens) e automação, respectivamente, tarefas de DevOps.
Infelizmente, muitos projetos de IoT exigem integrações muito mais complexas . Não estou falando apenas de uma integração relativamente direta por meio de um conector MQTT ou OPC-UA. Os desafios em projetos de IoT industrial incluem:
O setor de automação geralmente não usa padrões abertos, mas é lento, inseguro, não escalável e proprietário.
Os ciclos de vida do produto são muito longos (dezenas de anos), sem alterações ou atualizações simples.
A IIoT geralmente usa protocolos incompatíveis, normalmente proprietários e criados para um fornecedor específico .
Monólitos proprietários e caros que não são escaláveis e não extensíveis .
Portanto, muitos projetos de IoT complementam o Kafka com uma plataforma de IoT desenvolvida especificamente . A maioria dos produtos de IoT e serviços em nuvem são proprietários, mas fornecem interfaces e arquiteturas abertas. O espaço de código aberto é pequeno nesta indústria. Uma ótima alternativa (para alguns casos de uso) é o Apache PLC4X . A estrutura se integra a muitos protocolos legados proprietários, como Siemens S7, Modbus, Allen Bradley, Beckhoff ADS, etc. O PLC4X também fornece um conector Kafka Connect para integração Kafka nativa e escalável.
Um historiador de dados moderno é aberto e flexível . A base de muitos projetos estratégicos de modernização de IoT no chão de fábrica e na nuvem híbrida é alimentada pelo streaming de eventos:
Kafka NÃO é uma blockchain (mas relevante para web3, negociação de criptomoedas, NFT, off-chain, sidechain, oráculos)
Kafka é um log de commit distribuído. Os conceitos e fundamentos são muito semelhantes a um blockchain. Eu explorei isso com mais detalhes no meu post “ Apache Kafka and Blockchain – Comparison and a Kafka-native Implementation “.
Um blockchain deve ser usado SOMENTE se diferentes partes não confiáveis precisarem colaborar. Para a maioria dos projetos corporativos, um blockchain é uma complexidade desnecessária . Um log de confirmação distribuído (= Kafka) ou um livro-razão distribuído à prova de adulteração (= Kafka aprimorado) é suficiente.
Dito isso, o mais interessante é que vejo cada vez mais empresas usando o Kafka em suas plataformas de negociação de criptomoedas, trocas de mercado e mercados de negociação de tokens NFT .
Para ser claro: Kafka NÃO é o blockchain nessas plataformas . O blockchain é uma criptomoeda como o Bitcoin ou uma plataforma que fornece contratos inteligentes como o Ethereum, onde as pessoas criam novos aplicativos distribuídos (dApps) como NFTs para a indústria de jogos ou arte. Kafka é a plataforma de streaming para conectar esses blockchains com outros Oracles (= os aplicativos não blockchain) como CRM, data lake, data warehouse e assim por diante:
O TokenAnalyst é um excelente exemplo que aproveita o Kafka para integrar dados de blockchain do Bitcoin e Ethereum com suas ferramentas de análise. O Kafka Streams fornece um aplicativo de streaming com estado para evitar o uso de blocos inválidos em cálculos agregados downstream . Por exemplo, a TokenAnalyst desenvolveu um componente de confirmação de bloco que resolve cenários de reorganização mantendo blocos temporariamente e só os propaga quando um limite de um número de confirmações (os filhos desse bloco são extraídos) é atingido.
Em alguns casos de uso avançados, o Kafka é usado para implementar uma plataforma sidechain ou off-chain, pois o blockchain original não é dimensionado bem o suficiente (blockchain é conhecido como dados on-chain). Não apenas o Bitcoin tem o problema de processar apenas transações de um dígito (!) por segundo. A maioria das soluções de blockchain modernas não pode ser dimensionada nem perto das cargas de trabalho que o Kafka processa em tempo real.
De DAOs a empresas blue chip, medir a integridade da infraestrutura blockchain e componentes IOT ainda é necessário mesmo em uma rede distribuída para evitar tempo de inatividade, proteger a infraestrutura e tornar os dados blockchain acessíveis. O Kafka fornece uma maneira escalável e sem agente de apresentar esses dados às partes envolvidas e garantir que os dados relevantes sejam expostos às equipes certas antes que um nó seja perdido. Isso é relevante para projetos de IoT Web3 de ponta, como o Helium, ou ledgers distribuídos fechados (DLT) mais simples, como o R3 Corda.
Meu post recente sobre comércio ao vivo alimentado por streaming de eventos e Kafka transformando o metaverso do varejo mostra como a indústria de varejo e jogos conecta coisas virtuais e físicas. O processo de negócio do varejo e a comunicação com o cliente acontecem em tempo real ; não importa se você deseja vender roupas, um smartphone ou um token NFT baseado em blockchain para seu colecionável ou videogame.
TL;DR: Kafka NÃO é…
… um substituto para seu banco de dados ou data warehouse favorito.
… duro em tempo real para cargas de trabalho incorporadas de segurança crítica.
… um proxy para milhares de clientes em redes ruins.
… uma solução de gerenciamento de API.
… um gateway de IoT.
… uma cadeia de blocos.
É fácil qualificar o Kafka para alguns casos de uso e requisitos .
No entanto, cargas de trabalho analíticas e transacionais em todos os setores usam Kafka . É o padrão de fato para transmissão de eventos em todos os lugares. Assim, o Kafka é frequentemente combinado com outras tecnologias e plataformas.
Onde você (não) usa o Apache Kafka? Com quais outras tecnologias você combina o Kafka? Conecte comigo e com o Kai no LinkedIn e vamos discutir isso! Mantenha-se informado sobre as novas postagens do blog assinando a newsletter.
Comentarios