Este é um artigo traduzido originalmente publicado dia 09/3/2022 no blog do Kai Waehner: "Analytics vs. Transactions in Data Streaming with Apache Kafka". Assine a newsletter do Kai para se manter atualizado com novas publicações.
As cargas de trabalho para analytics e transactions têm características e requisitos muito diferentes. Muitas pessoas pensam que o Apache Kafka não foi desenvolvido para transações e deve ser usado apenas para análise de big data. Esta postagem explora quando e como usar o Kafka em arquiteturas resilientes e de missão crítica e quando usar a API de transação integrada.
As cargas de trabalho para análises e transações têm características e requisitos muito diferentes. Os casos de uso diferem significativamente . Os SLAs também são muito diferentes. Muitas pessoas pensam que o Apache Kafka não foi desenvolvido para transações e deve ser usado apenas para análise de big data. Esta postagem de blog explora quando e como usar o Kafka em arquiteturas resilientes e de missão crítica e quando usar a API de transação integrada.
Cargas de trabalho analíticas e transacionais
Vamos começar definindo os termos. O canal do YouTube 'Databases Demystified' tem um ótimo episódio: Analítico vs. Transacional . Eu uso e aprimoro sua explicação nas subseções seguintes.
Algumas pessoas se referem a isso como uma discussão “OLTP vs. OLAP”:
No OLTP (processamento de transações online) , os sistemas de informação normalmente facilitam e gerenciam aplicativos orientados a transações.
No OLAP (processamento analítico online) , os sistemas de informação geralmente executam consultas muito mais complexas, em um volume menor, para fins de inteligência de negócios ou relatórios, em vez de processar transações.
Existem algumas sobreposições em alguns casos de uso e produtos. Por isso, uso os termos mais genéricos “transações” e “análises” neste post do blog.
Cargas de trabalho analíticas
As cargas de trabalho analíticas têm as seguintes características:
Processando grandes quantidades de informações para criar agregados
Consultas somente leitura e (geralmente) carregamentos de dados de gravação em lote
Suporte a consultas complexas com várias etapas de processamento de dados, condições de junção e filtragem
Consultas ad hoc altamente variáveis , muitas das quais podem ser executadas apenas uma vez, sempre
Não é de missão crítica , o que significa que o tempo de inatividade ou a perda de dados não é bom, mas na maioria dos casos não é um desastre para o negócio principal
Soluções de análise
As soluções de análise existem no local e em todas as principais nuvens. As ferramentas diferem em relação às suas capacidades e pontos doces. Exemplos incluem:
Redshift (Serviços da Web da Amazon)
BigQuery (Google Cloud)
Floco de neve
Hive / HDFS / Spark
E muitos mais!
Cargas de trabalho transacionais
As cargas de trabalho transacionais têm características e SLAs exclusivos em comparação com as cargas de trabalho analíticas:
Manipulando um objeto por vez (geralmente em diferentes sistemas)
Criar operações de leitura, atualização e exclusão (CRUD) inserindo dados um objeto por vez ou atualizando dados existentes (geralmente em diferentes sistemas)
Gerenciando precisamente o estado com garantias sobre o que foi ou não gravado no disco
Suportando muitas operações por segundo em tempo real com alto rendimento
SLAs de missão crítica para tempo de atividade, disponibilidade e latência da comunicação de dados de ponta a ponta
Soluções transacionais
As soluções transacionais incluem aplicativos, bancos de dados, sistemas de mensagens e middleware de integração:
Mainframe IBM (incluindo CICS, IMS, DB2)
TIBCO EMS
PostgreSQL
Banco de Dados Oracle
MongoDB
E muitos mais!
Muitas vezes, uma carga de trabalho transacional precisa garantir os princípios ACID (ou seja, tudo ou nada grava em diferentes aplicativos e tecnologias).
Uma combinação de cargas de trabalho transacionais e analíticas
Muitas soluções oferecem suporte a uma combinação de cargas de trabalho transacionais e analíticas.
Por exemplo, muitas empresas armazenam dados transacionais no MongoDB, mas também processam consultas complexas para casos de uso de análise no mesmo banco de dados. MongoDB começou como banco de dados NoSQL baseado em documentos. Enquanto isso, é uma plataforma de banco de dados de uso geral que também suporta outras formas de consultas de banco de dados, como o MongoDB, que fornece recursos de travessia de gráficos e árvores:
Portanto, concentre-se primeiro no problema do negócio. Em seguida, você pode decidir se sua infraestrutura existente pode resolver o problema ou se você precisa de mais uma. Mas não existe bala de prata. Uma melhor abordagem independente de fornecedor funciona melhor na maioria das arquiteturas corporativas que vejo nas histórias de sucesso do campo.
Dados em repouso versus dados em movimento
O processamento de dados em lote versus em tempo real é uma discussão importante que você deve ter em todos os projetos. Declarações como “processamento em lote é para análise, processamento em tempo real é para transações” nem sempre estão corretas. O tempo real supera os dados lentos em quase todos os casos de uso de uma perspectiva de valor comercial . No entanto, o processamento em lote é a melhor abordagem para alguns casos de uso específicos.
Plataformas de análise para processamento em lote
Dados em repouso significa armazenar dados em um banco de dados, data warehouse ou data lake . Isso significa que os dados são processados tarde demais em muitos casos de uso – mesmo se um componente de streaming em tempo real (como Kafka) ingerir os dados. O processamento de dados ainda é uma chamada de serviço da Web, consulta SQL ou processo em lote de redução de mapa, longe de fornecer um resultado para seu problema.
Não me entenda mal. Dados em repouso não são uma coisa ruim . Vários casos de uso, como relatórios (inteligência de negócios), análises (processamento em lote) e treinamento de modelos (aprendizado de máquina) exigem essa abordagem... Se você fizer certo! Os dados em repouso também podem ser usados para cargas de trabalho transacionais!
Apache Kafka para streaming de dados em tempo real
A API Kafka é a API padrão de fato para dados em movimento, como o Amazon S3 para armazenamento de objetos. Por que Kafka é tão bem sucedido? O tempo real supera os dados lentos na maioria dos casos de uso em todos os setores.
A mesma abordagem nativa da nuvem é necessária para o streaming de eventos e para o data lake moderno. Construir uma infraestrutura escalável e econômica é crucial para o sucesso de um projeto. As tecnologias de streaming de eventos e data lake são complementares , não competitivas.
Não explorarei as razões e casos de uso para o sucesso de Kafka neste post. Em vez disso, confira minha visão geral sobre os casos de uso do Kafka em todos os setores para obter mais detalhes. Ou leia alguns dos meus posts de blog específicos de verticais.
Em suma, o maior valor agregado vem do processamento de Dados em Movimento enquanto é relevante, em vez de armazenar Dados em Repouso e processá-los mais tarde (ou tarde demais) . Muitas cargas de trabalho analíticas e transacionais usam o Kafka por esse motivo.
Apache Kafka para análise
Mesmo em 2022, muitas pessoas pensam no Kafka como uma camada de ingestão de dados em armazenamentos de dados. Este ainda é um caso de uso crítico. As empresas usam o Kafka como a camada de ingestão para diferentes plataformas de análise:
Relatórios e painéis em lote
Consultas interativas (usando Tableau, Qlik e ferramentas semelhantes)
Preparação de dados para cálculos em lote, treinamento de modelos e outras análises
Conectividade em diferentes data warehouses, data lakes e outros coletores de dados usando a melhor abordagem da categoria
Mas Kafka é muito mais do que uma camada de mensagens e ingestão . Aqui estão alguns exemplos de análise usando o Kafka para análise (geralmente com outras ferramentas de análise para resolver um problema específico em conjunto):
Integração de dados para vários sistemas de origem usando o Kafka Connect e conectores pré-criados (incluindo interfaces em tempo real, quase em tempo real, batch, web service, arquivo e proprietárias)
Desacoplamento e manuseio de contrapressão, pois os sistemas de dreno geralmente não estão prontos para grandes volumes de dados em tempo real. O design orientado a domínio (DDD) para desacoplamento verdadeiro é um diferencial crucial do Kafka em comparação com outros middleware e filas de mensagens.
O processamento de dados em escala em tempo real filtra, transforma, generaliza ou agrega conjuntos de dados recebidos antes de ingeri-los em sistemas coletores.
Análise em tempo real aplicada no aplicativo Kafka. Muitas plataformas de análise foram projetadas para cargas de trabalho em lote ou quase em tempo real, mas não para pontuação de modelo resiliente com baixa latência – especialmente em escala). Um exemplo pode ser um modelo analítico treinado com algoritmos de aprendizado de máquina em lote em um data lake com Spark MLlib ou TensorFlow e, em seguida, implantado em um aplicativo Kafka Streams ou ksqlDB .
Reproduza eventos históricos em casos como integração de um novo aplicativo de consumidor, tratamento de erros, conformidade ou processamento regulatório, alterações de esquema em uma plataforma de análise. Isso se torna especialmente relevante se o armazenamento em camadas for usado sob o capô do Kafka para armazenamento de longo prazo econômico e escalável.
Exemplo de análise com serviços Confluent Cloud e AWS
Aqui está uma ilustração de uma arquitetura da AWS que combina o Confluent e seu ecossistema, incluindo conectores, recursos de processamento de fluxo e gerenciamento de esquema junto com vários serviços de nuvem AWS de terceiros:
Como você pode ver, o Kafka é uma excelente ferramenta para cargas de trabalho analíticas . Não é uma bala de prata , mas usada para partes apropriadas da arquitetura geral de gerenciamento de dados. Eu tenho outra postagem no blog que explora a relação entre o Kafka e outras plataformas de análise sem servidor .
No entanto, Kafka NÃO é usado apenas para cargas de trabalho analíticas !
Apache Kafka para transações
Cerca de 60 a 70% dos casos de uso e implantações que vejo em clientes em todo o mundo aproveitam o ecossistema Kafka para cargas de trabalho transacionais . As empresas usam o Kafka para:
principais plataformas bancárias
detecção de fraude
replicação global de informações de pedidos e estoque
integração com plataformas críticas de negócios como CRM, ERP, MES e muitos outros sistemas transacionais
gestão da cadeia de abastecimento
comunicação com o cliente, como integração no ponto de venda ou upselling específico do contexto
e muitos outros casos de uso em que cada evento conta.
Kafka é um sistema distribuído e tolerante a falhas que é resiliente por natureza (se você o implantar e operar corretamente). Nenhum tempo de inatividade e perda de dados pode ser garantido, como em seu banco de dados favorito, mainframe ou outras plataformas principais.
A escalabilidade elástica e as atualizações contínuas permitem construir uma infraestrutura de streaming de dados flexível e confiável para cargas de trabalho transacionais para garantir a continuidade dos negócios . O arquiteto pode até estender um cluster entre regiões para garantir zero perda de dados e zero tempo de inatividade , mesmo em caso de desastre em que um data center esteja completamente inativo. O post “ Global Kafka Deployments ” explora as diferentes opções de implantação e suas compensações com mais detalhes.
Exemplo de API de transações do Kafka
E ainda melhor: a API de Transação do Kafka, ou seja, Exactly-Once Semantics (EOS) , está disponível desde o Kafka 0.11 (que foi usado no GA há muito tempo). O EOS torna a criação de cargas de trabalho transacionais ainda mais fácil, pois você não precisa mais lidar com duplicatas.
O Kafka agora suporta gravações atômicas em várias partições por meio da API de transações . Isso permite que um produtor envie um lote de mensagens para várias partições. Todas as mensagens no lote são eventualmente visíveis para qualquer consumidor ou nenhuma delas é visível para os consumidores. Aqui está um exemplo:
Kafka fornece uma API de transações integrada . E o impacto no desempenho (com o qual muitas pessoas estão preocupadas) é mínimo. Aqui está uma regra simples: se você se importa com a semântica exatamente uma vez, basta ativá-la! Se problemas de desempenho forçarem você a desativá-lo, você ainda poderá ajustar seu aplicativo ou desativá-lo. Mas a maioria dos projetos está bem com as compensações mínimas de desempenho versus o enorme benefício de lidar com o comportamento transacional pronto para uso.
No entanto, para ser claro: você não precisa usar a API de transações do Kafka para criar cargas de trabalho transacionais de missão crítica.
Design Pattern SAGA para dados transacionais em Kafka sem transações
A API Kafka Transactions é opcional . Conforme discutido acima, o Kafka é resiliente sem transações. Embora eliminar duplicatas seja sua tarefa então. A semântica exatamente uma vez resolve esse problema imediatamente em todos os componentes do Kafka. Kafka Connect, Kafka Streams, ksqlDB e diferentes clientes como Java, C++, .NET, Go suportam EOS.
No entanto, também não estou dizendo que você deve sempre usar a API de transação Kafka ou que ela resolve todos os problemas transacionais. Lembre-se de que os sistemas distribuídos escaláveis exigem outros padrões de design além de uma “transação Oracle para IBM MQ” tradicional .
Algumas transações comerciais abrangem vários serviços . Portanto, você precisa de um mecanismo para implementar transações que abrangem serviços. Um padrão de design e implementação familiares para essa carga de trabalho transacional é o padrão SAGA com um aplicativo de orquestração com estado .
Custodigit da Swisscom é um excelente exemplo de tal implementação alavancando Kafka Streams. É umaplataforma bancária moderna para ativos digitais e criptomoedasque fornece recursos e garantias cruciais para investimentos em criptomoedas seriamente regulamentados – mais detalhes em minha postagem no blog sobreBlockchain, Crypto, NFTs e Kafka.
E sim, sempre há compensações entre a API de transação do Kafka e a semântica exatamente uma vez, a orquestração com estado em um aplicativo separado e as transações de confirmação de duas fases, como Oracle DB e IBM MQ, a usam. Escolha a ferramenta certa para definir sua arquitetura corporativa apropriada!
Kafka com outros armazenamentos de dados e mecanismos de streaming
A maioria das empresas usa o Kafka como o hub de dados em tempo real escalável central . Portanto, os casos de uso incluem cargas de trabalho analíticas e transacionais.
A maioria dos projetos Kafka que vejo hoje também aproveita o Kafka Connect para integração de dados, Kafka Streams/ksqlDB para processamento contínuo de dados e Schema Registry para governança de dados .
Assim, com o Kafka, uma infraestrutura (distribuída e escalável) permite mensagens, armazenamento, integração e processamento de dados . Mas é claro que a maioria dos clusters Kafka se conecta a outros aplicativos (como SAP ou Salesforce) e sistemas de gerenciamento de dados (como MongoDB, Snowflake, Databricks etc.) para análise:
Explorei em detalhes por que o Kafka é um banco de dados para alguns casos de uso específicos, mas NÃO substituirá outros bancos de dados e data lakes em sua própria postagem no blog.
Além dos mecanismos de processamento de fluxo nativos do Kafka, como Kafka Streams ou ksqlDB, outras estruturas de análise de streaming, como Apache Flink ou Spark Streaming, podem ser facilmente conectadas para cargas de trabalho transacionais ou analíticas. Lembre-se de que cargas de trabalho especialmente transacionais ficam mais difíceis de ponta a ponta com cada sistema e infraestrutura adicionais que você adiciona à arquitetura corporativa.
Arquitetura Kappa para análises E transações com Kafka como hub de dados
Dados em tempo real superam dados lentos . Isso é verdade para quase todos os casos de uso. No entanto, os arquitetos corporativos criam novas infraestruturas com a arquitetura Lambda que inclui uma camada de lote separada para análise e uma camada em tempo real para cargas de trabalho transacionais.
Um único pipeline em tempo real, chamado arquitetura Kappa , é o mais adequado. Exemplos do mundo real de empresas como Disney, Shopify, Uber e Twitter exploram os benefícios do Kappa, mas também mostram como o processamento em lote se encaixa positivamente nessa discussão sem Lambda. Em seu post dedicado, saiba como uma arquitetura Kappa pode revolucionar a forma como você cria cargas de trabalho analíticas e transacionais com o mesmo hub de dados escalável em tempo real desenvolvido pelo Kafka .
Como você aproveita o streaming de dados para cargas de trabalho analíticas ou transacionais? Você usa a semântica exatamente uma vez para facilitar a implementação de transações? Conecte comigo e com o Kai no LinkedIn e vamos discutir isso! Mantenha-se informado sobre as novas postagens do blog assinando a newsletter.
Komentar