Este é um artigo traduzido originalmente publicado dia 5/7/2022 no blog do Kai Waehner: "Data Streaming for Data Ingestion into the Data Warehouse and Data Lake". Assine a newsletter do Kai para se manter atualizado com novas publicações.
Os conceitos e arquiteturas de um data warehouse, um data lake e streaming de dados são complementares para resolver problemas de negócios. Infelizmente, as tecnologias subjacentes são muitas vezes incompreendidas, usadas em excesso para arquiteturas monolíticas e inflexíveis e apresentadas para casos de uso errados pelos fornecedores. Vamos explorar esse dilema em uma série de blogs. Esta é a parte 2: Streaming de Dados para Ingestão de Dados no Data Warehouse e Data Lake.
Os conceitos e arquiteturas de data warehouse, data lake e streaming de dados são complementares para resolver problemas de negócios . Armazenar dados em repouso para relatórios e análises requer recursos e SLAs diferentes do processamento contínuo de dados em movimento para cargas de trabalho em tempo real. Existem muitas estruturas de código aberto, produtos comerciais e serviços de nuvem SaaS. Infelizmente, as tecnologias subjacentes são muitas vezes incompreendidas, usadas em excesso para arquiteturas monolíticas e inflexíveis e apresentadas para casos de uso errados pelos fornecedores. Vamos explorar esse dilema em uma série de blogs. Saiba como criar uma pilha de dados moderna com tecnologias nativas da nuvem. Esta é a parte 2: Streaming de Dados para Ingestão de Dados no Data Warehouse e Data Lake.
Série do Blog: Data Warehouse vs. Data Lake vs. Data Streaming
Esta série de blogs explora conceitos, recursos e compensações de uma stack de dados moderna usando um data warehouse, data lake e streaming de dados juntos:
Data Warehouse vs. Data Lake vs. Data Streaming – Amigos, Inimigos, Frenemies? (post original: Data Warehouse vs. Data Lake vs. Data Streaming – Friends, Enemies, Frenemies?)
ESTE POST: Streaming de dados para ingestão de dados no Data Warehouse e Data Lake
Modernização do Data Warehouse: De Legado On-Premise a Infraestrutura Nativa em Nuvem
Estudos de caso: streaming de dados nativo da nuvem para modernização do data warehouse
Lições aprendidas com a criação de um data warehouse nativo da nuvem
Fique atento para uma postagem de blog dedicada para cada tópico como parte desta série de blogs. Vou linkar os blogs aqui assim que estiverem disponíveis (nas próximas semanas). Assine minha newsletter para receber um e-mail após cada publicação (sem spam ou anúncios).
Ingestão de dados confiável e escalável com streaming de dados
A ingestão de dados confiável e escalável é crucial para qualquer plataforma de análise , seja para construir um data warehouse, data lake ou lakehouse.
Quase um dos principais players no espaço de análise reprojetou a plataforma existente para permitir a ingestão de dados em tempo (quase) real, em vez de apenas integração em lote .
Ingestão de dados = integração de dados
Apenas obter dados de A para B geralmente não é suficiente. A integração de dados com fluxos de trabalho de extração, transformação, carregamento (ETL) conecta-se a vários sistemas de origem e processa eventos de entrada antes de ingeri-los em um ou mais coletores de dados . No entanto, a maioria das pessoas pensa em uma fila de mensagens ao discutir a ingestão de dados. Em vez disso, uma boa tecnologia de ingestão de dados fornece recursos adicionais:
Conectividade : Os conectores permitem uma integração rápida, mas confiável, com qualquer fonte de dados e coletor de dados. Não construa seu próprio conector se um conector estiver disponível!
Processamento de dados : a lógica de integração filtra, enriquece ou agrega dados de uma ou mais fontes de dados.
Compartilhamento de dados : replique dados entre regiões, data centers e várias nuvens.
Armazenamento econômico : separe verdadeiramente as fontes de dados de vários consumidores downstream (plataformas analíticas, aplicativos de negócios, SaaS, etc.)
Kafka é mais do que apenas ingestão de dados ou uma fila de mensagens . Kafka é um middleware nativo da nuvem :
Uma opção comum é executar cargas de trabalho ETL no data warehouse ou data lake . Uma fila de mensagens é suficiente para ingestão de dados. Mesmo nesse caso, a maioria dos projetos usa a plataforma de streaming de dados Apache Kafka como camada de ingestão de dados, embora muitos recursos excelentes do Kafka sejam desconsiderados dessa maneira.
Em vez disso, executar cargas de trabalho ETL no pipeline de ingestão de dados tem várias vantagens :
O verdadeiro desacoplamento entre a camada de processamento e armazenamento permite uma infraestrutura escalável e econômica .
As cargas de trabalho de ETL são processadas em tempo real , independentemente do ritmo que cada aplicativo de downstream oferece.
Cada consumidor (data warehouse, data lake, banco de dados NoSQL, fila de mensagens) tem a liberdade de escolha para a tecnologia/API/linguagem de programação/paradigma de comunicação para decidir como e quando ler, processar e armazenar dados.
Os consumidores downstream escolhem entre dados brutos e conjuntos de dados relevantes selecionados .
Integração de dados em repouso ou em movimento?
ETL não é nenhuma novidade. As ferramentas da Informatica, TIBCO e outros fornecedores fornecem ótima codificação visual para a construção de pipelines de dados. A evolução na nuvem nos trouxe alternativas nativas da nuvem como SnapLogic ou Boomi. Ferramentas de gerenciamento de API como o MuleSoft são outra opção comum para construir uma camada de integração baseada em APIs e integração ponto a ponto.
O enorme benefício dessas ferramentas é um time-to-market muito melhor para construir e manter pipelines. Existem algumas desvantagens , no entanto:
Infraestrutura separada para operar e pagar
Escalabilidade e/ou latência geralmente limitadas usando um middleware dedicado em comparação com uma camada de ingestão de fluxo nativa (como Kafka ou Kinesis)
Dados armazenados em repouso em sistemas de armazenamento separados
Forte acoplamento com serviços da web e conexões ponto a ponto
A lógica de integração está na plataforma de middleware; experiência e ferramentas proprietárias sem liberdade de escolha para implementar a integração de dados
A grande notícia é que você tem a liberdade de escolha. Se o coração da infraestrutura for em tempo real e escalável, você pode adicionar não apenas aplicativos escaláveis em tempo real, mas qualquer lote ou middleware baseado em API :
A integração ponto a ponto via API Management é complementar ao streaming de dados , não competitiva.
Malha de dados para ingestão de dados em várias nuvens
Data Mesh é a última palavra da moda na indústria de software. Ele combina design orientado a domínio, data marts, microsserviços, streaming de dados e outros conceitos. Assim como o Lakehouse, o Data Mesh é um conceito lógico, NÃO uma infraestrutura física construída com uma única tecnologia! Explorei o papel que o streaming de dados com o Apache Kafka desempenha em uma arquitetura de malha de dados .
Em resumo, as características do Kafka, como desacoplamento verdadeiro, manipulação de contrapressão, processamento de dados e conectividade com sistemas de tempo real e não real, permitem a construção de uma arquitetura de dados global distribuída.
Aqui está um exemplo de uma malha de dados criada com Confluent Cloud e Databricks em provedores de nuvem e regiões :
O streaming de dados como camada de ingestão de dados desempenha muitas funções em um ambiente multinuvem e/ou multirregional :
Replicação de dados entre nuvens e/ou regiões
Integração de dados com vários aplicativos de origem (diretamente ou por meio de middleware ETL/iPaaS de terceiros)
Pré-processamento na região local para reduzir os custos de transferência de dados e melhorar a latência entre as regiões
Ingestão de dados em um ou mais data warehouses e/ou data lakes
Tratamento de contrapressão para consumidores lentos ou entre regiões em caso de internet desconectada
O poder do streaming de dados fica mais aparente neste exemplo: a ingestão de dados ou uma fila de mensagens sozinha NÃO é boa o suficiente para a maioria dos “projetos de ingestão de dados ”!
Apache Kafka – O padrão de fato para ingestão de dados na casa do lago
O Apache Kafka é o padrão de fato para streaming de dados e um caso de uso crítico é a ingestão de dados . O Kafka Connect permite uma integração confiável em tempo real em qualquer escala . Ele lida automaticamente com falhas, problemas de rede, tempo de inatividade e outros problemas operacionais. Procure sua plataforma de análise favorita e verifique a disponibilidade de um conector Kafka Connect. As chances são altas que você vai encontrar um.
As vantagens críticas do Apache Kafka em comparação com outros mecanismos de ingestão de dados, como o AWS Kinesis, incluem:
Desacoplamento verdadeiro : a ingestão de dados em um data warehouse geralmente é apenas um dos coletores de dados. A maioria das empresas ingere dados em vários sistemas e cria novos aplicativos em tempo real com a mesma infraestrutura e APIs Kafka.
API aberta em ambientes multinuvem e híbridos : o Kafka pode ser implantado em qualquer lugar, incluindo qualquer provedor de nuvem, data center ou infraestrutura de borda.
Eficiência de custo : quanto mais você dimensiona, mais econômicas as cargas de trabalho Kafka se tornam em comparação com o Kinesis e ferramentas semelhantes.
Armazenamento de longo prazo na plataforma de streaming : a capacidade de reprodução de dados históricos e o tratamento de backpressure para consumidores lentos são incorporados ao Kafka (e econômicos se você aproveitar o armazenamento em camadas).
Pré-processamento e ETL em uma única infraestrutura : em vez de ingerir grandes volumes de dados brutos em vários sistemas em repouso, os dados recebidos podem ser processados em movimento com ferramentas como Kafka Streams ou ksqlDB uma vez. Cada consumidor escolhe os dados curados ou brutos de que precisa para análises adicionais – em tempo real, lote quase em tempo real ou solicitação-resposta.
Kafka como ingestão de dados e middleware ETL com Kafka Connect e ksqlDB
O Kafka fornece dois recursos que muitas pessoas geralmente subestimam no início (porque pensam no Kafka apenas como uma fila de mensagens):
Integração de dados : Kafka Connect é uma ferramenta para transmitir dados de forma escalável e confiável entre o Apache Kafka e outros sistemas de dados. O Kafka Connect simplifica a definição rápida de conectores que movem grandes conjuntos de dados para dentro e para fora do Kafka.
Processamento de fluxo : Kafka Streams é uma biblioteca cliente para criar aplicativos e microsserviços sem estado ou com estado, onde os dados de entrada e saída são armazenados em clusters Kafka. O ksqlDB foi desenvolvido com base no Kafka Streams para criar aplicativos de streaming de dados, aproveitando sua familiaridade com bancos de dados relacionais e SQL.
A principal diferença de outras ferramentas ETL é que Kafka come sua própria comida de cachorro :
Observe que o Kafka Connect é mais do que um conjunto de conectores . A estrutura subjacente fornece muitos recursos de middleware adicionais . Veja as transformações de mensagem única (SMT), fila de mensagens mortas, validação de esquema e outros recursos do Kafka Connect.
Kafka como middleware nativo da nuvem; NÃO iPaaS
O streaming de dados com o Kafka geralmente substitui as ferramentas ETL e ESBs . Aqui estão os principais motivos:
Alguns consideram o streaming de dados uma plataforma de integração como serviço (iPaaS). Não posso concordar inteiramente com isso. Os argumentos são muito semelhantes a dizer que o Kafka é uma ferramenta ETL. Estas são tecnologias muito diferentes que brilham com outras características (e trade-offs). Confira minha postagem no blog explicando por que o streaming de dados é uma nova categoria de software e por que o Kafka NÃO é um iPaaS .
Arquiteturas de referência para ingestão de dados com Apache Kafka
Vamos explorar duas arquiteturas de exemplo para ingestão de dados com Apache Kafka e Kafka Connect: Elasticsearch Data Streams e Databricks Delta Lake . Ambos os produtos atendem a casos de uso muito diferentes e exigem uma estratégia de ingestão de dados diferente .
O desenvolvedor pode usar as mesmas APIs do Kafka Connect para conectores diferentes. Sob o capô, a implementação parece muito diferente para atender a diferentes necessidades e SLAs.
Ambos estão usando o conector Kafka Connect dedicado no diagrama de arquitetura de alto nível. Nos bastidores, a velocidade de ingestão, a estratégia de indexação, as garantias de entrega e muitos outros fatores devem ser configurados dependendo dos requisitos do projeto e dos recursos do coletor de dados.
Exemplo de ingestão de dados: indexação em tempo real com Kafka e Elasticsearch Data Streams
Um dos meus exemplos favoritos é o Elasticsearch . Naturalmente, o mecanismo de pesquisa construiu índices no modo de lote. Portanto, o primeiro conector Kafka Connect ingeriu eventos no modo em lote. No entanto, a Elastic criou uma nova estratégia de indexação em tempo real chamada Elasticsearch Data Streams para oferecer aos usuários finais tempos de consulta e resposta mais rápidos .
Um Elastic Data Stream permite armazenar dados de séries temporais somente de acréscimo em vários índices, ao mesmo tempo em que fornece um único recurso nomeado para solicitações. Os fluxos de dados são adequados para logs, eventos, métricas e outros dados gerados continuamente . Você pode enviar solicitações de indexação e pesquisa diretamente para um fluxo de dados. O stream roteia automaticamente a solicitação para índices de apoio que armazenam os dados do stream. Um fluxo de dados Kafka é a fonte de dados ideal para Elastic Data Streams .
Exemplo de ingestão de dados: Confluent e Databricks
Confluent em conjunto com Databricks é outro excelente exemplo. Muitas pessoas lutam para explicar as diferenças de ambos os fornecedores e pontos de venda exclusivos . Por quê? Porque o marketing é muito semelhante para ambos: processar big data, armazená-lo para sempre, analisá-lo em tempo real, implantar em várias nuvens e várias regiões e assim por diante. A realidade é que Confluent e Databricks se sobrepõem apenas ~ 10%. Ambos se complementam muito bem .
O foco da Confluent é processar dados em movimento. O principal negócio da Databricks é armazenar dados em repouso para análises e relatórios. Sim, você pode armazenar dados a longo prazo no Kafka (especialmente com armazenamento em camadas). Sim, você pode processar dados com Databricks (quase) em tempo real com o Spark Streaming. Isso é bom para alguns casos de uso, mas na maioria dos cenários, você (deve) escolher e combinar a melhor tecnologia para um problema.
Aqui está uma arquitetura de referência para streaming e análise de dados com Confluent e Databricks :
Confluent e Databricks são uma combinação perfeita de uma arquitetura moderna de aprendizado de máquina :
Ingestão de dados com streaming de dados
Treinamento de modelo no data lake
(streaming ou batch) ETL onde melhor se adapta ao caso de uso
Implantação de modelo no data lake próximo ao ambiente de ciência de dados ou um aplicativo de streaming de dados para SLAs de missão crítica e baixa latência
Monitoramento do pipeline de ponta a ponta (ETL, pontuação de modelo etc.) em tempo real com streaming de dados
Espero que esteja claro que fornecedores de streaming de dados como o Confluent têm recursos, pontos fortes e fracos muito diferentes dos fornecedores de data warehouse como Databricks ou Snowflake.
Como construir uma casa do lago nativa da nuvem com Kafka e Spark?
Databricks cunhou Lakehouse para falar sobre dados em tempo real em movimento e cargas de trabalho em lote em repouso em uma única plataforma . Do meu ponto de vista, o Lakehouse é uma ótima visão lógica . Mas não existe bala de prata! A implementação técnica de um Lakehouse requer ferramentas diferentes em uma pilha de dados moderna.
Em junho de 2022, apresentei minha perspectiva detalhada sobre essa discussão no Databricks' Data + AI Summit em San Francisco. Confira minha apresentação de slides " Serverless Kafka and Spark in a Multi-Cloud Lakehouse Architecture ":
O streaming de dados é muito mais do que a ingestão de dados em um lakehouse
Tecnologias de streaming de dados como Apache Kafka são perfeitas para ingestão de dados em um ou mais data warehouses e/ou data lakes. MAS o streaming de dados é muito mais : Integração com várias fontes de dados, processamento de dados, replicação entre regiões ou nuvens e, finalmente, ingestão de dados nos coletores de dados.
Exemplos com fornecedores como Confluent, Databricks e Elasticsearch mostraram como o streaming de dados ajuda a resolver muitos desafios de integração de dados com uma única tecnologia.
No entanto, não há bala de prata. Uma casa do lago moderna aproveita as melhores tecnologias da categoria. Nenhuma tecnologia pode ser a melhor para lidar com todos os tipos de conjuntos de dados e paradigmas de comunicação (como tempo real, lote, solicitação-resposta).
Para mais detalhes, navegue em outros posts desta série de blogs:
Data Warehouse vs. Data Lake vs. Data Streaming – Amigos, Inimigos, Frenemies? (post original: Data Warehouse vs. Data Lake vs. Data Streaming – Friends, Enemies, Frenemies?)
ESTE POST: Streaming de dados para ingestão de dados no Data Warehouse e Data Lake
Modernização do Data Warehouse: De Legado On-Premise a Infraestrutura Nativa em Nuvem
Estudos de caso: streaming de dados nativo da nuvem para modernização do data warehouse
Lições aprendidas com a criação de um data warehouse nativo da nuvem
Como você combina data warehouse e streaming de dados hoje? O Kafka é apenas sua camada de ingestão no data lake? Você já aproveita o streaming de dados para casos de uso adicionais em tempo real? Ou o Kafka já é o componente estratégico na arquitetura corporativa para microsserviços desacoplados e uma malha de dados? Conecte comigo e com o Kai no LinkedIn e vamos discutir isso! Mantenha-se informado sobre as novas postagens do blog assinando a newsletter.
Comments