O Desafio
Os dados estão no centro de qualquer sistema de decisão empresarial de qualquer organização. Você provavelmente ouviu a expressão: “Dados é o novo Petróleo”.
No entanto, nem sempre (na verdade, é raramente) que todos os dados necessários estão localizados em apenas um lugar, como um RDBMS de remos e baunilha. Normalmente está espalhado por diferentes RDBMS e outros silos de dados.
Portanto, não é incomum encontrar situações em que os dados estão em todos os tipos de fontes diferentes e o DBA ou O Engenheiro de Dados precisa implementar um solution que puxa todos os dados relevantes para um local centralizado para análises posteriores.
Imagem 1: As muitas fontes de dados possíveis
Recentemente nos deparamos com um caso em que um cliente tinha dados de vendas em uma instância rds AWS Postgres e precisava que os dados (um conjunto de tables para ser mais preciso) fossem replicados (quase em tempo real) em algumas tabelas em seu Azure VM com MS SQL SERVER. Infelizmente, a replicação heterogênea é marcada como depreciada e só funciona entre SQL SERVER e ORACLE. Não é permitido postgres no lote. Além disso, não há replicação heterogênea nativa no lado dos Postgres. Isso pode ser alcançado on-only com o uso de ferramentas de terceiros ou manualmente no modo de esforço ALTO – criando um MECHANISM CDC (Change Data Capture) usando gatilhos e, em seguida, puxando dados de tabelas de controle. Isso parece certo para implementar, mas o tempo é essencial. Desenvolver tal solução levaria algum tempo.
Portanto, outra solução tinha que ser usada para alcançar o movimento de dados necessário .
Uma possível solução (por que Kafka)
A imagem 1 mostra um cenário possível, mas não mostra a solução como em qual ferramenta poderia ser usada como pipeline. O cenário do Big Data tem muitas ferramentas que talvez pudessem conseguir isso, mas nenhuma delas tinha as vantagens que Kafka oferecia.
Originalmente, o Apache Kafka foi projetado para ser uma fila de mensagens como o aplicativo (lembra-se da IBM MQ Series ou mesmo do SQL SERVER Service Broker?). A melhor definição do que é pode ser citada da Confluent: “Apache Kafka é uma tecnologia de streaming de eventos distribuídos pela comunidade capaz de lidar com trilhões de eventos por dia”. Da mente de um DBA: Bem, o streaming deve ser como uma replicação, mas enorme! Isso é preciso, mas um Sistema de Streaming precisa ter a capacidade de ingerir dados de muitas fontes de dados diferentes e deve ser capaz de entregar suas mensagens em uma variedade de pontos finais de dados também. Poderíamos escolher entre muitas ferramentas para conseguir isso, Azure Event Hubs ou AWS Kinesis ou até mesmo o Kafka gerenciado em Nuvem Confluente. However, para aprender como as coisas funcionam sob o capô e já que todas elas vêm de origens semelhantes (que é o código de código aberto Apache Kafka) ou têm o mesmo objetivo decidimos mostrar ao cliente como configurar o ambiente a partir do zero do solo sem quaisquer Serviços Gerenciados para o processamento do Stream. Então, a imagem anterior seria mais ou menos assim:
Imagem 2: Usando Kafka para lidar com muitas fontes e entregar a mensagem para um (ou muitos) destinos
Como uma breve introdução, os componentes básicos do Apache Kafka são:
- Mensagem:A menor unidade de dados em Kafka, do ponto de vista da DBA, uma mensagem é uma linha em uma tabela db. No que diz respeito a Kafka, uma mensagem é uma série de bytes.
- Esquema: Uma estrutura que acompanha mensagens, para que elas possam ser desarmadas pelos aplicativos que consomem ;
- Tópicos: As mensagens são categorizadas em Tópicos. No Mundo DBA, isso seria o equivalente a uma “mesa”. As mensagens são lidas de acordo em troca de conteúdo;
- Produtores e Consumidores: Lembra-se de Editores e Assinantes de Replicação do SQL SERVER? A ideia é muito semelhante aqui, no entanto, Kafka tem a capacidade de lidar com vários produtores e consumidores ao mesmo tempo.
- Corretores e Clusters: Um único servidor Kafka é um “corretor”. Recebe mensagens dos produtores, escreve um deslocamento para eles e persiste em disco. Também servirá aos consumidores como eles pedem mensagens. De um modo geral, em um ambiente de produção, os Corretores fazem parte de um Cluster
- Conectores: Apache Kafka tem muitos conectores para lidar com consumidores e produtores (que poderiam ser do tipo pia). Uma grande variedade de conectores está disponível gratuitamente ou para compra. Você encontrará a maioria deles na página web confluente (https://www.confluent.io/product/confluent-connectors).
Em conclusão, kafka é a ferramenta de escolha para essa tarefa e vamos criar todo o ambiente para a movimentação de dados do zero. Para mais informações, acesse aqui: https://kafka.apache.org/documentation.
A arquitetura
Para alcançar a funcionalidade de Streaming e ver o fluxo de dados em ação, usaremos um conjunto de tabelas do Postgresql DB como fonte, um conjunto de tabelas do SQL SERVER como destino e Apache Kafka agirá como o “mecanismo de replicação”. Para se conectar aos Postgres e detectar suas alterações de dados (CDC), também é necessário um plugin conector. Neste caso, vamos usar o Debezium, pois ele também é de código aberto e construído do zero para trabalhar com Kafka o mais facilmente possível.
Imagem 3: Movendo dados de Postgres para MS SQL em poucas palavras
Mergulhando um pouco mais em detalhes, no final desta série de postagem do Blog devemos ter:
- um VM Linux que tem uma instância pós-ano e os binários Kafka idealmente com conectividade à Internet (usaremos o Cli Confluente para tornar a implantação um pouco menos complicada). O Debezium para Pós-Grau também será instalado neste VM;
- Um Windows VM (ou um local) com uma instância de SERVIDOR SQL MS.
Então nossa arquitetura deve parecer um pouco mais com a Imagem 4.
Imagem 4: Detalhando a arquitetura
Também tenha em mente que, para alcançar o objetivo necessário (replicar dados do Postgres para o SQL SERVER usando Kafka), poderíamos simplesmente usar um produto Kafka-as-a-service em qualquer um dos principais Provedores de Nuvem. No entanto, para entender completamente como a arquitetura funciona e simplesmente como uma vitrine decidimos não usar nenhum produto relacionado ao SaaS, nem Docker nesta série. Você pode encontrar uma nova série no blog this em um futuro próximo que contempla os Serviços de Nuvem. Com as expectativas estabelecidas, estamos prontos para prosseguir…
Sujando as mãos
Vamos começar instalando nosso primeiro VM. Estou usando um PC Windows para fazer todos os meus testes, então estou criando o VM em Hyper-V. Feel livre para usar qualquer hipervisor que você preferir. Minha escolha para OS é Red Hat Developer edição 8.5. Você precisará assinar o Portal do Chapéu Vermelho: https://developers.redhat.com/prod ucts/rhel/visão geral.
Passo 1: Criando a Máquina Virtual
- No meu caso, criarei um VM chamado Júpiter para agir como nosso servidor Postgres e Kafka.
- Será uma Geração 2 no que diz respeito ao Hyper-V. Certifique-se de alocar memória suficiente para que você possa testar properly. Estou definindo o meu para cerca de 6 GB – dinâmico, o que significa que Hyper-V não vai dedicar essa memória inteiramente ao VM.
- Para rede, estou adicionando um adaptador ethernet virtual que está conectado à nic física do host, o que significa que o roteador wi-fi atribuirá um endereço IP diretamente ao VM.