Este é um artigo traduzido originalmente publicado dia 23/01/2023 no blog do Kai Waehner: "Apache Kafka (including Kafka Streams) + Apache Flink = Match Made in Heaven". Assine a newsletter do Kai para se manter atualizado com novas publicações.
O Apache Kafka e o Apache Flink estão cada vez mais unindo forças para criar aplicativos inovadores de processamento de fluxo em tempo real. Esta postagem explora os benefícios de combinar as duas estruturas de código aberto, mostra os diferenciais exclusivos do Flink versus Kafka e discute quando usar um mecanismo de streaming nativo do Kafka como o Kafka Streams em vez do Flink.
O Apache Kafka e o Apache Flink estão cada vez mais unindo forças para criar aplicativos inovadores de processamento de fluxo em tempo real. Esta postagem de blog explora os benefícios de combinar as duas estruturas de código aberto, mostra os diferenciais exclusivos do Flink versus Kafka e discute quando usar um mecanismo de streaming nativo do Kafka como o Kafka Streams em vez do Flink.
A tremenda adoção do Apache Kafka e do Apache Flink
O Apache Kafka tornou-se o padrão de fato para streaming de dados . O núcleo do Kafka é o envio de mensagens em qualquer escala em combinação com um armazenamento distribuído (= log de confirmação) para durabilidade confiável, desacoplamento de aplicativos e reprodutibilidade de dados históricos.
O Kafka também inclui um mecanismo de processamento de fluxo com o Kafka Streams. E o KSQL é outro mecanismo SQL de streaming nativo do Kafka bem-sucedido, construído sobre o Kafka Streams. Ambas são ferramentas fantásticas. Paralelamente, o Apache Flink tornou-se um mecanismo de processamento de fluxo muito bem-sucedido .
O primeiro estudo de caso Kafka + Flink proeminente de que me lembro é o caso de uso de detecção de fraude do ING Bank. As primeiras publicações surgiram em 2017, ou seja, há mais de cinco anos: “ StreamING Machine Learning Models: How ING Adds Fraud Detection Models at Runtime with Apache Kafka and Apache Flink ”. Este é apenas um dos muitos estudos de caso de detecção de fraude Kafka .
Um dos últimos estudos de caso sobre os quais escrevi no blog vai na mesma direção: “ Por que o DoorDash migrou do Amazon SQS e Kinesis nativos da nuvem para Apache Kafka e Flink ”.
A adoção de Kafka já é notável. E o Flink entra cada vez mais nas empresas, muitas vezes em combinação com Kafka . Este artigo não é uma introdução ao Apache Kafka ou Apache Flink. Em vez disso, exploro por que essas duas tecnologias são uma combinação perfeita para muitos casos de uso e quando outras ferramentas nativas do Kafka são a escolha apropriada em vez do Flink.
Principais razões pelas quais o Apache Flink é uma tecnologia complementar perfeita para o Kafka
O processamento de fluxo é um paradigma que correlaciona continuamente eventos de uma ou mais fontes de dados. Os dados são processados em movimento , em contraste com o processamento tradicional em repouso com um banco de dados e uma API de solicitação-resposta (por exemplo, um serviço da Web ou uma consulta SQL). O processamento de fluxo pode ser sem estado (por exemplo, filtrar ou transformar uma única mensagem) ou com estado (por exemplo, uma agregação ou janela deslizante). Especialmente o gerenciamento de estado é muito desafiador em um aplicativo de processamento de fluxo distribuído.
Uma vantagem vital do mecanismo Apache Flink é sua eficiência em aplicativos com estado. O Flink possui APIs expressivas, operadores avançados e controle de baixo nível. Mas o Flink também é escalável em aplicativos stateful, mesmo para consultas JOIN de streaming relativamente complexas.
O mecanismo escalável e flexível do Flink é fundamental para fornecer uma tremenda estrutura de processamento de fluxo para cargas de trabalho de big data . Mas há mais. Os seguintes aspectos são meus recursos favoritos e princípios de design do Apache Flink:
APIs unificadas de streaming e lote
Conectividade com um ou vários clusters Kafka
Transações entre Kafka e Flink
Processamento de eventos complexos
Suporte a SQL padrão
Aprendizado de máquina com Kafka, Flink e Python
Mas lembre-se de que toda abordagem de design tem prós e contras. Embora existam muitas vantagens, às vezes também é uma desvantagem.
APIs unificadas de streaming e lote
A API DataStream do Apache Flink unifica APIs de lote e streaming. Ele oferece suporte a diferentes modos de execução de tempo de execução para processamento de fluxo e processamento em lote , dos quais você pode escolher o correto para seu caso de uso e as características de seu trabalho. No caso da API SQL/Tabela, a troca ocorre automaticamente com base nas características das fontes: Todos os eventos limitados entram em modo de execução em lote; pelo menos um evento ilimitado significa modo de execução STREAMING.
A unificação de streaming e lote traz muitas vantagens :
Reutilização de lógica/código para processamento histórico e em tempo real
Semântica consistente em fluxo e processamento em lote
Um único sistema para operar
Aplicativos que misturam processamento de dados históricos e em tempo real
Isso soa semelhante ao Apache Spark. Mas há uma diferença significativa: ao contrário do Spark, a base do Flink é o streaming de dados, não o processamento em lote . Portanto, o streaming é o modo de tempo de execução padrão no Apache Flink.
O processamento contínuo sem estado ou com estado permite a análise de streaming em tempo real usando um fluxo ilimitado de eventos. A execução em lote é mais eficiente para trabalhos limitados (ou seja, um subconjunto limitado de um fluxo) para o qual você tem uma entrada fixa conhecida e que não é executada continuamente. Isso executa trabalhos de uma maneira que lembra mais as estruturas de processamento em lote, como MapReduce nos ecossistemas Hadoop e Spark.
O Apache Flink facilita a mudança de uma arquitetura empresarial Lambda para Kappa . A base da arquitetura é em tempo real, com Kafka como seu coração. Mas o processamento em lote ainda é possível pronto para uso com Kafka e Flink usando semântica consistente. No entanto, essa combinação provavelmente não (tentará) substituir as ferramentas de lote ETL tradicionais, por exemplo, para uma migração única de levantamento e deslocamento de grandes cargas de trabalho.
Conectividade com um ou vários clusters Kafka
O Apache Flink é uma infraestrutura separada do cluster Kafka. Isso tem vários prós e contras. Em primeiro lugar, costumo enfatizar o grande benefício dos aplicativos nativos do Kafka: você só precisa operar, dimensionar e oferecer suporte a uma infraestrutura para processamento de dados de ponta a ponta. Uma segunda infraestrutura adiciona complexidade, custo e risco adicionais . No entanto, imagine um fornecedor de nuvem assumindo esse fardo, para que você consuma o pipeline de ponta a ponta como um único serviço de nuvem.
Com isso em mente, vejamos alguns benefícios de clusters separados para o hub de dados (Kafka) e o mecanismo de processamento de fluxo (Flink) :
Concentre-se no processamento de dados em uma infraestrutura separada com APIs dedicadas e recursos independentes da plataforma de streaming de dados.
Pipelines de streaming mais eficientes antes de atingir os Tópicos Kafka novamente; a troca de dados acontece diretamente entre os trabalhadores do Flink.
Processamento de dados em diferentes tópicos Kafka de clusters Kafka independentes de diferentes unidades de negócios. Se fizer sentido do ponto de vista técnico e organizacional, você pode se conectar diretamente a fontes e coletores não Kafka. Mas tenha cuidado, isso pode rapidamente se tornar um antipadrão na arquitetura corporativa e criar “integrações espaguete” complexas e incontroláveis.
Implemente novas estratégias de failover para aplicativos.
Enfatizo que o Flink geralmente NÃO é a escolha recomendada para implementar seu cenário de agregação, migração ou integração híbrida . Vários clusters Kafka para arquiteturas híbridas e globais são a norma, não uma exceção . O Flink não altera essas arquiteturas.
As ferramentas de replicação nativas do Kafka, como MirrorMaker 2 ou Confluent Cluster Linking, ainda são a escolha certa para recuperação de desastres . Ainda é mais fácil fazer tal cenário com apenas uma tecnologia. Ferramentas como Cluster Linking resolvem desafios como gerenciamento de compensação pronto para uso.
Transações entre Kafka e Flink
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 streaming de dados não é construído para transações e deve ser usado apenas para análise de big data.
No entanto, o Apache Kafka e o Apache Flink são implantados em muitas arquiteturas resilientes de missão crítica . O conceito de semântica exatamente uma vez (EOS) permite que aplicativos de processamento de fluxo processem dados por meio do Kafka sem perda ou duplicação. Isso garante que os resultados calculados sejam sempre precisos.
As transações são possíveis em Kafka e Flink . O recurso é maduro e testado em batalha na produção. Operar clusters separados ainda é um desafio para cargas de trabalho transacionais. No entanto, um serviço de nuvem pode assumir esse risco e carga.
Muitas empresas já usam EOS em produção com Kafka Streams. Mas o EOS pode até ser usado se você combinar Kafka e Flink. Esse é um grande benefício se você escolher o Flink para cargas de trabalho transacionais. Portanto, para deixar claro: o EOS não é um diferencial no Flink (vs. Kafka Streams), mas é uma excelente opção para usar o EOS no Kafka e no Flink também.
Processamento de eventos complexos com FlinkCEP
O objetivo do processamento de eventos complexos (CEP) é identificar eventos significativos em situações de tempo real e responder a eles o mais rápido possível. O CEP geralmente não envia eventos contínuos para outros sistemas, mas detecta quando algo significativo ocorre. Um caso de uso comum para o CEP é o tratamento de eventos atrasados ou a não ocorrência de eventos .
A grande diferença entre o CEP e o processamento de fluxo de eventos (ESP) é que o CEP gera novos eventos para acionar a ação com base em situações que ele detecta em vários fluxos de eventos com eventos de diferentes tipos (situações que se acumulam ao longo do tempo e do espaço). O ESP detecta padrões em fluxos de eventos com eventos homogêneos (ou seja, padrões ao longo do tempo). A correspondência de padrões é uma técnica para implementar qualquer padrão, mas os recursos parecem diferentes.
O FlinkCEP é um add-on para o Flink fazer o processamento de eventos complexos . A poderosa API de padrões do FlinkCEP permite definir sequências de padrões complexos que você deseja extrair de seu fluxo de entrada. Depois de especificar a sequência padrão, você os aplica ao fluxo de entrada para detectar possíveis correspondências. Isso também é possível com SQL por meio da cláusula MATCH_RECOGNIZE.
Suporte a SQL padrão
Structured Query Language (SQL) é uma linguagem específica de domínio usada em programação e projetada para gerenciar dados mantidos em um sistema de gerenciamento de banco de dados relacional (RDBMS). No entanto, é tão predominante que outras tecnologias, como bancos de dados não relacionais (NoSQL) e plataformas de streaming, também o adotam.
O SQL tornou-se um padrão do American National Standards Institute (ANSI) em 1986 e da International Organization for Standardization (ISO) em 1987 . Portanto, se uma ferramenta oferece suporte a ANSI SQL, ela garante que qualquer ferramenta de terceiros possa se integrar facilmente usando consultas SQL padrão (pelo menos em teoria).
Apache Flink suporta ANSI SQL , incluindo a Linguagem de Definição de Dados (DDL), Linguagem de Manipulação de Dados (DML) e Linguagem de Consulta. O suporte SQL do Flink é baseado no Apache Calcite, que implementa o padrão SQL. Isso é ótimo porque muitas pessoas, incluindo desenvolvedores, arquitetos e analistas de negócios, já usam o SQL em seu trabalho diário.
A integração SQL é baseada no chamado Flink SQL Gateway, que faz parte da estrutura Flink permitindo que outros aplicativos interajam facilmente com um cluster Flink por meio de uma API REST. Aplicações de usuário (por exemplo, programa Java/Python/Shell, Postman) podem usar a API REST para enviar consultas, cancelar trabalhos, recuperar resultados, etc. Isso permite uma possível integração do Flink SQL com ferramentas tradicionais de business intelligence como Tableau, Microsoft Power BI ou Qlik .
No entanto, para ser claro, ANSI SQL não foi criado para processamento de fluxo . A incorporação da funcionalidade Streaming SQL no padrão SQL oficial ainda está em andamento . O grupo de trabalho Streaming SQL inclui fornecedores de banco de dados como Microsoft, Oracle e IBM, fornecedores de nuvem como Google e Alibaba e fornecedores de streaming de dados como Confluent. Mais detalhes: “ The History and Future of SQL: Databases Meet Stream Processing ”.
Dito isto, o Flink suporta janelas deslizantes contínuas e várias junções de streaming via ANSI SQL . Há coisas que exigem palavras-chave SQL não padrão adicionais, mas janelas deslizantes contínuas ou junções de streaming, em geral, são possíveis.
Aprendizado de máquina com Kafka, Flink e Python
Em conjunto com o streaming de dados, o aprendizado de máquina resolve a incompatibilidade de impedância de trazer modelos analíticos de forma confiável para a produção para pontuação em tempo real em qualquer escala . Eu explorei implantações de ML em aplicativos Kafka em várias postagens de blog, por exemplo, modelos incorporados em aplicativos Kafka Streams ou usando um servidor de modelo de aprendizado de máquina com recursos de streaming como Seldon .
PyFlink é uma API Python para Apache Flink que permite criar cargas de trabalho escalonáveis em lote e streaming, como pipelines de processamento de dados em tempo real, análise exploratória de dados em larga escala, pipelines de aprendizado de máquina (ML) e processos ETL. Se você já está familiarizado com Python e bibliotecas como Pandas, o PyFlink torna mais simples aproveitar todos os recursos do ecossistema Flink.
PyFlink é a peça que faltava para uma infraestrutura de streaming de dados baseada em ML, já que quase todos os engenheiros de dados usam Python. A combinação de armazenamento em camadas em Kafka e streaming de dados com Flink em Python é excelente para treinamento de modelo sem a necessidade de um data lake separado.
Quando usar o Kafka Streams em vez do Apache Flink?
Não subestime o poder e os casos de uso do processamento de fluxo nativo do Kafka com o Kafka Streams. A taxa de adoção é enorme, pois o Kafka Streams é fácil de usar. E faz parte do Apache Kafka. Para ser claro: o Kafka Streams já está incluído se você baixar o Kafka do site Apache .
Kafka Streams é uma biblioteca, Apache Flink é um cluster
A diferença mais significativa entre o Kafka Streams e o Apache Flink é que o Kafka Streams é uma biblioteca Java, enquanto o Flink é uma infraestrutura de cluster separada . Os desenvolvedores podem implantar a infraestrutura Flink no modo de sessão para cargas de trabalho maiores (por exemplo, muitas cargas de trabalho pequenas e homogêneas, como consultas SQL) ou no modo de aplicativo para menos tarefas de processamento de dados heterogêneas (por exemplo, aplicativos isolados em execução em um cluster Kubernetes).
Não importa sua opção de implantação, você ainda precisa operar uma infraestrutura de cluster complexa para Flink (incluindo gerenciamento de metadados separado em um cluster ZooKeeper ou um cluster etcd em um ambiente Kubernetes).
TL;DR: Apache Flink é uma fantástica estrutura de processamento de fluxo e um dos 5 principais projetos de código aberto Apache. Mas também é complexo de implantar e difícil de gerenciar.
Benefícios de usar a biblioteca leve do Kafka Streams
Kafka Streams é uma única biblioteca Java. Isso adiciona alguns benefícios:
A integração nativa do Kafka oferece suporte a SLAs críticos e baixa latência para pipelines de dados de ponta a ponta e aplicativos com uma única infraestrutura de cluster em vez de operar mecanismos separados de mensagens e processamento com Kafka e Flink. Os aplicativos Kafka Streams ainda são executados em suas VMs ou contêineres Kubernetes, mas a alta disponibilidade e persistência são garantidas por meio dos Kafka Topics.
Muito leve, sem outras dependências (o Flink precisa de S3 ou armazenamento similar como back-end de estado)
Fácil integração em pipelines de teste/CI/DevOps
Processamento de fluxo integrado em qualquer aplicativo JVM existente , como um aplicativo Spring Boot leve ou um monólito legado criado com tecnologias Java EE antigas, como EJB.
Consultas interativas permitem alavancar o estado de seu aplicativo de fora de seu aplicativo. A API do Kafka Streams permite que seus aplicativos sejam consultáveis. O recurso similar do Flink, “estado consultável”, está chegando ao fim de sua vida útil devido à falta de mantenedores .
O Kafka Streams é conhecido por criar microsserviços independentes, desacoplados e leves. Isso é diferente de enviar um trabalho de processamento para o cluster Flink (ou Spark); cada equipe de produto de dados controla seu destino (por exemplo, não dependa da equipe central do Flink para atualizações ou seja forçado a atualizar). O modo de aplicativo do Flink permite um estilo de implantação semelhante para microsserviços. Mas:
Kafka Streams e Apache Flink vivem em diferentes partes de uma empresa
Hoje, Kafka Streams e Flink são geralmente usados para diferentes aplicações. Embora o Flink forneça um modo de aplicativo para criar microsserviços, a maioria das pessoas usa o Kafka Streams para isso hoje. As consultas interativas estão disponíveis no Kafka Streams e no Flink, mas foram descontinuadas no Flink, pois não há muita demanda da comunidade. Estes são dois exemplos que mostram que não há um vencedor claro. Às vezes, o Flink é a melhor escolha e, às vezes, o Kafka Streams faz mais sentido .
“Em resumo, embora certamente haja uma sobreposição entre a API Streams no Kafka e no Flink, eles vivem em partes diferentes de uma empresa, em grande parte devido a diferenças em sua arquitetura e, portanto, os vemos como sistemas complementares.” Essa é a citação de um artigo “ Comparação Kafka Streams vs. Flink ” escrito em 2016 (!) Por Stephan Ewen, ex-CTO da Data Artisans, e Neha Narkhede, ex-CTO da Confluent. Embora alguns detalhes tenham mudado com o tempo, esta postagem antiga do blog ainda é bastante precisa hoje e uma boa leitura para um público mais técnico.
A linguagem específica de domínio (DSL) do Kafka Streams difere do Flink, mas também é muito semelhante. Como ambas as características são possíveis? Depende de quem você perguntar. Este assunto (legítimo) para debate muitas vezes separa as comunidades Kafka Streams e Flink . O Kafka Streams possui APIs de fluxo e tabela. Flink tem DataStream, Tabela e API SQL. Acho que 95% dos casos de uso podem ser construídos com ambas as tecnologias. APIs, infraestrutura, experiência, histórico e muitos outros fatores são relevantes para escolher a estrutura de processamento de fluxo adequada.
Alguns aspectos arquitetônicos são muito diferentes no Kafka Streams e no Flink . Eles precisam ser entendidos e podem ser um pró ou um contra para o seu caso de uso. Por exemplo, o ponto de verificação do Flink tem a vantagem de obter um instantâneo consistente, mas a desvantagem é que cada erro local sempre interrompe todo o trabalho e tudo precisa ser revertido para o último ponto de verificação. Kafka Streams não tem esse conceito. Erros locais podem ser recuperados localmente (mova as tarefas correspondentes para outro lugar; as tarefas/threads sem erros continuam normalmente). Outro exemplo é o hot standby do Kafka Streams para alta disponibilidade versus o sistema de checkpoint tolerante a falhas do Flink.
Kafka + Flink = Uma combinação poderosa para processamento de streams
Apache Kafka é o padrão de fato para streaming de dados . Ele inclui Kafka Streams, uma biblioteca Java amplamente usada para processamento de fluxo. O Apache Flink é um projeto de código aberto independente e bem-sucedido que oferece um mecanismo de processamento de fluxo para cargas de trabalho em lote e em tempo real. A combinação de Kafka (incluindo Kafka Streams) e Flink já é difundida em empresas de todos os setores .
Tanto o Kafka Streams quanto o Flink têm vantagens e desvantagens para processamento de stream . A liberdade de escolha dessas duas principais tecnologias de código aberto e a forte integração do Kafka com o Flink permitem qualquer tipo de caso de uso de processamento de fluxo. Isso inclui implantações híbridas, globais e multinuvem, cargas de trabalho transacionais de missão crítica e análises poderosas com aprendizado de máquina incorporado. Como sempre, entenda as diferentes opções e escolha a ferramenta certa para seu caso de uso e requisitos .
Qual é o seu favorito para processamento de streaming, Kafka Streams, Apache Flink ou outro mecanismo proprietário ou de código aberto? Em quais casos de uso você aproveita o processamento de stream? Conecte comigo e com o Kai no LinkedIn e vamos discutir isso! Mantenha-se informado sobre as novas postagens do blog assinando a newsletter.