Este é um artigo traduzido originalmente publicado dia 15/7/2022 no blog do Kai Waehner: "Data Warehouse and Data Lake Modernization: From Legacy On-Premise to Cloud-Native Infrastructure". 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 3: Modernização do Data Warehouse: Do Legado On-Premise à Infraestrutura Nativa da Nuvem.
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 3: Modernização do Data Warehouse: Do Legado On-Premise à Infraestrutura Nativa da Nuvem.
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 data warehouse, data lake e streaming de dados juntos:
Data Warehouse vs. Data Lake vs. Data Streaming – Amigos, Inimigos, um pouco dos dois? (post original: Data Warehouse vs. Data Lake vs. Data Streaming – Friends, Enemies, Frenemies?)
Streaming de dados para ingestão de dados no Data Warehouse e Data Lake (post original: Data Streaming for Data Ingestion into the Data Warehouse and Data Lake)
ESTE POST: Modernização do Data Warehouse: do Legado On-Premise à 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).
Modernização do data warehouse: do legado local à infraestrutura nativa da nuvem
Muitas pessoas falam sobre a modernização do data warehouse quando migram para um data warehouse nativo da nuvem. No entanto, o que significa modernização do data warehouse? Por que as pessoas se afastam de seu data warehouse local? Quais são os benefícios?
Muitos projetos que vi na natureza passaram pelas seguintes etapas:
Selecione um data warehouse nativo da nuvem
Obtenha dados no novo data warehouse
[Opcional] Migre do antigo para o novo data warehouse
Vamos explorar essas etapas com mais detalhes e entender as opções de tecnologia e arquitetura.
1. Seleção de um data warehouse nativo da nuvem
Muitos anos atrás, a computação em nuvem foi um divisor de águas para a infraestrutura operacional. A AWS inovou ao fornecer não apenas máquinas virtuais EC2, mas também armazenamento, como o AWS S3 como serviço.
As ofertas de data warehouse nativas da nuvem são criadas com base na mesma mudança fundamental. Os provedores de nuvem trouxeram seus serviços de análise de nuvem, como AWS Redshift, Azure Synapse ou GCP BigQuery. Fornecedores independentes lançaram um data warehouse nativo da nuvem ou SaaS de data lake , como Snowflake, Databricks e muito mais. Embora cada solução tenha seus trade-offs, algumas características gerais são verdadeiras para a maioria delas:
Nativo da nuvem : um data warehouse moderno é elástico, dimensionado para cargas de trabalho pequenas a extremas e automatiza a maioria dos processos de negócios relacionados ao desenvolvimento, operações e monitoramento.
Totalmente gerenciado : O fornecedor assume o ônus das operações. Isso inclui dimensionamento, tratamento de failover, atualizações e ajuste de desempenho. Algumas ofertas são realmente sem servidor, enquanto muitos serviços exigem planejamento de capacidade e dimensionamento manual ou automatizado.
Preços baseados no consumo : o pagamento conforme o uso permite começar em minutos e dimensionar os custos com o uso mais amplo do software. A maioria das implantações corporativas permite o compromisso de obter descontos nos preços.
Compartilhamento de dados : replicar conjuntos de dados entre regiões e ambientes é um recurso comum para oferecer localização de dados, privacidade, latência mais baixa e conformidade regulatória.
Implantações multinuvem e híbridas : enquanto os provedores de nuvem geralmente oferecem apenas o serviço de primeira parte em sua infraestrutura de nuvem, os fornecedores de terceiros fornecem uma estratégia de várias nuvens. Alguns fornecedores até oferecem ambientes híbridos, incluindo implantações no local e na borda.
Existem muitas comparações na comunidade, além de pesquisas de analistas do Gartner, Forrester et al. Observar as informações do fornecedor e experimentar os vários produtos em nuvem usando créditos gratuitos também é crucial. Encontrar o data warehouse nativo da nuvem certo é seu próprio desafio e não nesta postagem do blog.
2. Streaming de dados como (quase) em tempo real e camada de integração híbrida
A ingestão de dados em data warehouses e data lakes já foi abordada na segunda parte desta série de blogs. Quanto mais tempo real, melhor para a maioria dos aplicativos de negócios. A ingestão quase em tempo real é possível com ferramentas específicas (como AWS Kinesis ou Kafka) ou como parte da malha de dados (o hub de dados de streaming em que uma ferramenta como Kafka desempenha um papel maior do que apenas a ingestão de dados).
A parte geralmente mais desafiadora é a integração de dados . A maioria dos pipelines de data warehouse e data lake exige que o ETL ingira dados. Como a plataforma de análise de próxima geração é crucial para tomar as decisões de negócios corretas, a plataforma de ingestão e integração de dados também deve ser nativa da nuvem! Ferramentas como o Kafka fornecem a camada de integração confiável e escalável para colocar todos os dados necessários no data warehouse.
Integração de dados legados no local no data warehouse nativo da nuvem
Em um projeto greenfield, a equipe do projeto tem sorte . As fontes de dados são executadas na mesma nuvem, usando APIs abertas e modernas, e dimensionadas, assim como o data warehouse nativo da nuvem.
Infelizmente, a realidade é quase sempre brownfield, mesmo que todos os aplicativos sejam executados em infraestrutura de nuvem pública . Portanto, a integração e replicação de dados de aplicativos legados e locais é um requisito geral.
Os dados normalmente são consumidos de bancos de dados legados, data warehouses, aplicativos e outras plataformas proprietárias. A replicação no data warehouse na nuvem geralmente precisa ser quase em tempo real e confiável .
Uma plataforma de streaming de dados como o Kafka é perfeita para replicar dados em data centers, regiões e ambientes devido à sua escalabilidade elástica e recursos de desacoplamento reais. O Kafka permite conectividade com sistemas legados e modernos por meio de conectores, APIs proprietárias, linguagens de programação ou interfaces REST abertas:
Um cenário comum em um projeto brownfield é a separação clara de preocupações e a verdadeira dissociação entre cargas de trabalho de nuvem legadas no local e modernas . Aqui, o Kafka é implantado no local para se conectar a aplicativos legados.
Ferramentas como MirrorMaker, Replicator ou Confluent Cluster Linking replicam eventos em tempo real no cluster Kafka na nuvem . Os corretores Kafka fornecem acesso aos eventos de entrada. Os consumidores downstream leem os dados nos coletores de dados em seu próprio ritmo; em tempo real, quase em tempo real, em lote ou solicitação-resposta via API. O streaming de ETL é possível em qualquer local – onde faz mais sentido do ponto de vista comercial ou de segurança e é o mais econômico.
Exemplo: nuvem confluente + floco de neve = modernização de data warehouse nativo da nuvem
Aqui está um exemplo concreto de modernização de data warehouse usando streaming de dados nativos da nuvem e data warehousing com Confluent Cloud e Snowflake:
Para modernizar o data warehouse, os dados são ingeridos de várias fontes de dados legadas e modernas usando diferentes paradigmas de comunicação, APIs e estratégias de integração. Os dados são transmitidos em movimento de fontes de dados via Kafka (e pré-processamento opcional) para o data warehouse Snowflake. Todo o pipeline de ponta a ponta é escalável, confiável e totalmente gerenciado , incluindo a conectividade e a ingestão entre os clusters Kafka e Snowflake.
No entanto, há mais na camada de integração e ingestão: a plataforma de streaming de dados armazena os dados para desacoplamento verdadeiro e aplicativos de downstream lentos; nem todo consumidor é ou pode ser em tempo real. A maioria das arquiteturas corporativas não ingere dados em um único data warehouse, data lake ou lakehouse. A realidade é que diferentes aplicativos downstream precisam acessar as mesmas informações; embora os fornecedores de data warehouses e data lakes digam a você de forma diferente, é claro
Ao consumir eventos do hub de dados de streaming, cada domínio de aplicativo decide por si mesmo se
processa eventos dentro do Kafka com ferramentas de processamento de fluxo como Kafka Streams ou ksqlDB
cria aplicativos downstream próprios com seu código e tecnologias (como Java, .NET, Golang, Python)
integra-se a aplicativos de negócios de terceiros, como Salesforce ou SAP
ingere os dados brutos ou pré-processados e curados do Kafka no sistema coletor (como um data warehouse ou data lake)
3. Modernização e migração do data warehouse do legado para o nativo da nuvem
Um conceito muitas vezes incompreendido é o burburinho em torno da modernização do data warehouse: as empresas raramente pegam os dados do data warehouse ou data lake existente no local, escrevem alguns trabalhos de ETL e colocam os dados em um data warehouse nativo da nuvem para Fazendo.
Se você pensar em um lift-and-shift único de um data warehouse local para a nuvem, uma ferramenta de ETL tradicional ou um serviço de replicação em nuvem pode ser o mais fácil . No entanto, geralmente, a modernização do data warehouse é mais do que isso!
O que é a modernização do data warehouse?
Uma modernização de data warehouse pode significar muitas coisas , incluindo substituir e migrar o data warehouse existente, construir um novo data warehouse nativo da nuvem do zero ou otimizar um pipeline ETL legado de um data warehouse nativo da nuvem.
Em todos esses casos, a modernização do data warehouse requer justificativa comercial , por exemplo:
Problemas de aplicativos no data warehouse legado, como processamento de dados muito lento com cargas de trabalho em lote legadas, resultam em informações erradas ou conflitantes para o pessoal de negócios.
Problemas de escalabilidade no data warehouse local à medida que o volume de dados cresce demais.
Problemas de custo porque o data warehouse legado não oferece preços razoáveis com modelos de pagamento conforme o uso.
Problemas de conectividade, pois os data warehouses legados não foram criados com uma API aberta e compartilhamento de dados em mente. Os data warehouses nativos da nuvem são executados em armazenamento de objetos escalável e econômico, separam o armazenamento da computação e permitem o consumo e o compartilhamento de dados. (mas lembre-se de que o ETL reverso geralmente é um antipadrão! )
Uma mudança estratégica para a nuvem com toda a infraestrutura. A plataforma de análise não é exceção se todos os aplicativos antigos e novos forem para a nuvem.
Os aplicativos nativos da nuvem geralmente vêm com inovação, ou seja, novos processos de negócios, formatos de dados e tomada de decisão orientada por dados. Do ponto de vista do data warehouse, a melhor modernização é começar do zero. Consuma dados diretamente das fontes de dados existentes, faça ETL e faça business intelligence sobre as novas estruturas de dados.
Tenho visto muitos outros projetos em que os clientes usam a captura de dados de alteração (CDC) de bancos de dados Oracle (ou seja, o sistema principal líder) em vez de tentar replicar dados do data warehouse legado (ou seja, a plataforma de análise) como escalabilidade, custo e o desligamento posterior da infraestrutura herdada se beneficia dessa abordagem.
Migração de data warehouse: contínua vs. cut-over
O projeto geralmente é um cut-over quando você precisa fazer uma modernização real (ou seja, migração) de um data warehouse legado para um nativo da nuvem. Dessa forma, a primeira fase do projeto integra as fontes de dados legadas com o novo data warehouse. As plataformas de data warehouse antigas e novas operam em paralelo, para que os processos de negócios antigos e novos continuem. Após algum tempo (meses ou anos depois), quando a empresa estiver pronta para ser movida, o data warehouse antigo será encerrado após a migração dos aplicativos legados para o novo data warehouse ou a substituição por novos aplicativos:
Meu artigo “ Mainframe Integration, Offloading and Replacement with Apache Kafka ” ilustra esse processo de offloading e migração de longo prazo. Basta rolar até a seção “Descarregamento e substituição de mainframe nos próximos 5 anos” nesse post e substituir o termo 'mainframe' por 'armazém de dados legado' em sua mente.
Uma migração e cut-over é seu projeto e pode incluir o data warehouse legado; ou não. A modernização do data lake (por exemplo, de um cluster Cloudera autogerenciado ou parcialmente gerenciado em execução no local no data center para uma infraestrutura de nuvem Databricks ou Snowflake totalmente gerenciada) segue os mesmos princípios. E misturar o data warehouse (relatórios) e o data lake (big data analytics) em uma única infraestrutura também não muda isso.
A modernização do data warehouse NÃO é um big bang e NÃO é uma abordagem de ferramenta única!
A maioria dos projetos de modernização de data warehouse são esforços contínuos por um longo período . Você deve selecionar um data warehouse nativo da nuvem, obter dados no novo data warehouse de várias fontes e, opcionalmente, migrar para fora da infraestrutura local legada.
O streaming de dados para ingestão de dados, aplicativos de negócios ou compartilhamento de dados em tempo real deve sempre ser um componente separado na arquitetura corporativa . Ele tem requisitos muito diferentes em relação a SLAs, tempo de atividade, passagem, latência etc. Colocar todas as cargas de trabalho analíticas e em tempo real no mesmo cluster faz pouco sentido do ponto de vista de custo, risco ou valor comercial. A ideia de um fluxo de dados moderno e a construção de uma malha de dados é a separação das preocupações com o design orientado a domínio e o foco em produtos de dados (usando APIs, tecnologias e serviços em nuvem diferentes e independentes).
Para mais detalhes, navegue em outros posts desta série de blogs:
Data Warehouse vs. Data Lake vs. Data Streaming – Amigos, Inimigos, um pouco dos dois? (post original: Data Warehouse vs. Data Lake vs. Data Streaming – Friends, Enemies, Frenemies?)
Streaming de dados para ingestão de dados no Data Warehouse e Data Lake (post original: Data Streaming for Data Ingestion into the Data Warehouse and Data Lake)
ESTE POST: Modernização do Data Warehouse: do Legado On-Premise à 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
Quais data warehouses nativos da nuvem você usa? Como o streaming de dados se encaixa em sua jornada? Você integrou ou substituiu seu(s) data warehouse(s) no local legado(s); ou começar do greenfield na nuvem? 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