Últimas do BLOG

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