Arquitetura de Dados: Lakehouse e Data Mesh aplicados à governança e observabilidade

Revisão Crítica: Data Lake, Data Warehouse e Lakehouse - Apresentação

Apresentando o curso e audiodescrevendo o instrutor

Olá! Eu sou Leonardo Souza e vou te acompanhar neste curso de Engenharia de Dados, Arquitetura Lakehouse e Data Mesh.

Antes de falar sobre o curso, vou me apresentar para fins de acessibilidade.

Audiodescrição: Sou um homem branco, de estatura mediana, estou vestindo uma camiseta cinza chumbo e uso óculos. Estou nos estúdios da Alura; à minha esquerda há uma estante iluminada por luz azul e uma parede também iluminada em azul.

Apresentando a experiência profissional e contextualizando o lakehouse

Eu tenho mais de 20 anos na área de tecnologia, sendo os últimos 7 a 8 anos dedicados ao trabalho com dados, em plataformas de API (Interface de Programação de Aplicações), plataformas de dados, arquitetura e transformação digital. Sou atualmente gerente de engenharia de dados e vou acompanhar vocês nesta jornada para conhecer as características desse modelo de plataforma e de arquitetura que é o Lakehouse (arquitetura que combina data lake e data warehouse).

Nós vamos explorar quais capacidades essa abordagem oferece às empresas, em quais cenários seu uso é mais adequado e quando pode não fazer sentido adotá-la. Vamos entender o que é possível realizar, observar os benefícios que habilita para as organizações e discutir como implementar, a depender do contexto da empresa e do ambiente corporativo.

Vamos começar.

Revisão Crítica: Data Lake, Data Warehouse e Lakehouse - Evolução da Arquitetura de Dados

Apresentando a evolução e o contexto

Olá! Nesta aula, nós vamos avaliar e analisar como ocorreu a evolução das arquiteturas de dados ao longo do tempo. Partiremos do período em que a geração de dados tinha volume muito menor e formatos mais restritos até chegarmos aos dias atuais, nos quais praticamente tudo gera dado e informação nos mais diversos formatos.

Antes de qualquer coisa, é importante nós entendermos em que ambiente e qual é o contexto em que as arquiteturas de dados eram ou são pensadas.

Definindo o data warehouse e suas características

A primeira grande arquitetura para o uso de dados com propósito informacional surgiu no começo dos anos 1990: o Data Warehouse (Armazém de Dados). O Data Warehouse é uma estrutura, naquela época ainda on-premises (no local), cujo objetivo era coletar dados de sistemas transacionais, como CRM e ERP, estruturá-los em um modelo — normalmente de fatos e dimensões — pensado com visão de negócio e, a partir daí, disponibilizar esses dados por meio de ferramentas de visualização para as pessoas usuárias de negócio.

A principal característica de um Data Warehouse é exatamente essa que comentamos: alta confiabilidade. Os processos de extração e transformação que geram essas estruturas de consumo de dados são muito rigorosos. As estruturas são menos flexíveis para incorporar elementos muito distintos e, durante muito tempo, isso atendeu muito bem às equipes de negócio.

Introduzindo o data lake e seus desafios

A partir do momento em que tivemos uma expansão significativa da geração de dados — com Internet das Coisas, sistemas web, redes sociais —, os arquivos e documentos gerados nas empresas passaram a ser muito mais digitais do que físicos. O Data Warehouse começou a demonstrar certas limitações. Foi nesse contexto de muitos dados, crescimento exponencial e novos tipos de dados que surgiu o conceito de Data Lake (Lago de Dados).

O Data Lake é uma arquitetura que oferece muito mais flexibilidade, em grande medida viabilizada pela computação distribuída que se consolidou por volta dos anos 2000. O Data Lake proporciona maior flexibilidade, mais capacidade de processamento e é capaz de acomodar tipos de dados e informações muito mais diversos. Saímos daquele modelo mais restrito para um modelo em que conseguimos armazenar praticamente qualquer coisa.

Entretanto, essa flexibilidade também trouxe desafios. Muitas empresas começaram a carregar e utilizar grandes volumes de dados de maneira desordenada e esqueceram de catalogá-los, de pensar em controle de acesso, em governança, em qualidade desses dados e em realizar curadoria. Isso começou a gerar problemas de uso porque, embora houvesse muitas informações e dados disponíveis, as pessoas usuárias tinham dificuldade de saber onde esses dados estavam, o que significavam e se estavam atualizados ou não.

Apresentando o lakehouse e sua arquitetura

Como resposta às limitações do Data Warehouse (armazém de dados) e à necessidade de maior flexibilidade, surgiu o conceito de Lakehouse (arquitetura unificada de dados). O Lakehouse foi desenhado para trabalhar com dados estruturados, mantendo o processo de governança fortalecido do Data Warehouse, mas também para acomodar, dentro dessa arquitetura, formatos mais diversos, com maior flexibilidade e capacidade de processamento.

Outro aspecto importante do Lakehouse é a separação entre capacidade de processamento e capacidade de armazenamento. Isso habilita que trabalhemos, em uma única plataforma e em um único ambiente, com abordagens que vão desde business intelligence (inteligência de negócios), mais tradicionais, passando por ciência de dados e machine learning (aprendizado de máquina), chegando, mais recentemente, à IA generativa.

Resumindo a evolução e comparando capacidades

Neste slide, vemos um resumo de como as arquiteturas que discutimos até agora — Data Warehouse, Data Lake (lago de dados) e Lakehouse — evoluíram. Em resumo, os dados no Data Warehouse são essencialmente estruturados, enquanto, no Data Lake, acomodam todos os formatos, assim como no Lakehouse. Essa é uma característica que o Lakehouse herda do Data Lake.

A governança no Data Warehouse é alta, o que ajuda a pessoa usuária a entender onde está o dado, para que ele serve e qual é seu ciclo de vida. O Lakehouse aproveita esse benefício do Data Warehouse; portanto, a governança no Lakehouse é nativa. Veremos, mais à frente, quando aprofundarmos o conceito de Lakehouse, que a governança não é um acessório: ela nasce junto com a fundação da arquitetura.

O Data Warehouse estava mais limitado a business intelligence, isto é, a olhar o passado e o que aconteceu, em estruturas muito voltadas para o negócio. O Data Lake já entregava uma capacidade de ciência de dados, e o Lakehouse tem a capacidade de acomodar tudo isso dentro de uma única arquitetura e de uma única plataforma.

Avaliando custos e critérios de escolha

A questão do custo também é importante. Naturalmente, se não tomarmos cuidado com o uso de nuvem, esse custo pode disparar. Em contrapartida, essa abordagem nos proporciona capacidade de realizar um gerenciamento melhor e mais equilibrado do uso das ferramentas e dos custos.

Para finalizar este primeiro vídeo, trazemos uma reflexão. A evolução das plataformas não necessariamente substitui o passado; ela amplia as possibilidades, acomodando, dentro da arquitetura, as melhores práticas e os benefícios que cada abordagem traz. A mensagem para nós é: não existe uma arquitetura perfeita. Cada abordagem, cada arquitetura ou recorte de arquitetura dependerá do problema que precisa ser resolvido. Essa escolha dependerá do contexto de negócio, da capacidade de investimento e da maturidade da empresa no uso de dados.

Antecipando temas futuros e encerrando a aula

Veremos, mais à frente, neste curso, que existe uma questão cultural importante para adotar determinadas abordagens, especialmente as mais recentes e modernas, como o Data Mesh (malha de dados). O Lakehouse representa a convergência entre escalabilidade, confiabilidade e governança de dados, sem abrir mão de segurança e capacidade de processamento.

Vejo vocês no próximo vídeo.

Revisão Crítica: Data Lake, Data Warehouse e Lakehouse - Problemas Comuns

Aprofundando o tema e contextualizando escolhas arquiteturais

Olá, no vídeo anterior, vimos a evolução das arquiteturas de dados. Neste vídeo, vamos aprofundar o tema e avaliar os problemas mais comuns de algumas dessas abordagens.

Dificilmente uma arquitetura ou solução de tecnologia e dados é descontinuada por estar errada na concepção. O que acontece, como vimos, é que o cenário muda. Inicialmente, uma arquitetura é pensada para resolver um problema específico e, sempre que fazemos uma escolha, outros atributos acabam sendo deixados de lado.

Apresentando data warehouse e data lake no contexto histórico

O Data Warehouse (armazém de dados) foi muito forte para trabalhar com dados estruturados, com alta robustez e governança consistente, porque, tecnicamente, isso fazia sentido. Porém, à medida que a quantidade e a diversidade de dados aumentaram, tornou-se difícil para essa arquitetura acomodar as mudanças. Em resposta, surgiu a abordagem de Data Lake (lago de dados), que entrega escalabilidade quase ilimitada e maior eficiência de custo, mas traz desafios de governança e qualidade, como nós comentamos no vídeo anterior.

Durante muito tempo, a abordagem de Data Warehouse (armazém de dados) funcionou muito bem para as empresas. A capacidade de extrair, transformar e carregar os dados dos sistemas operacionais — que naquela época eram mais simples, com dados mais estruturados, menor quantidade e menor diversidade — atendeu às necessidades por um longo período. Isso gerou confiança: a governança era bem feita, e as empresas passaram a confiar fortemente nos dados disponibilizados por meio do Data Warehouse (armazém de dados).

Evidenciando limitações do data warehouse e desafios de governança no data lake

À medida que o uso de dados avança, a complexidade de negócio cresce e a diversidade de formatos gerados aumenta, evoluir uma plataforma de Data Warehouse (armazém de dados) torna-se mais difícil e custoso. Essa estrutura mais rígida cobra um preço. Há uma dependência dos processos de ETL (extração, transformação e carga) que impede a arquitetura de responder às necessidades de negócio em tempo adequado, pois incorporar novas informações e novos tipos de dados é custoso. Além disso, há limitações de escalabilidade, já que, normalmente, essas estruturas de ETL (extração, transformação e carga) estavam construídas em ambientes on-premises (em instalações próprias), mais caros de escalar.

A partir daí, ganhou força a flexibilidade e a capacidade de armazenamento e processamento do Data Lake (lago de dados). Contudo, quando os dados são armazenados de qualquer maneira em um ambiente como esse, torna-se muito mais difícil para as pessoas usuárias de negócio gerar valor a partir deles. Quando não se pensa em governança em um Data Lake (lago de dados), surge a dificuldade de uso efetivo dos ativos de dados disponíveis nesse ambiente.

Alertando para o data swamp e destacando trade-offs arquiteturais

Em muitos cenários, não se consegue saber o que significa cada conjunto de dados nem onde esses dados estão. Passa a ocorrer a situação em que cada unidade de negócio, cada time de negócio, consome dados — ainda que de um mesmo lugar — de maneira desordenada. É comum existirem dois números para o mesmo indicador, ou dois números diferentes para explicar um mesmo evento de negócio. Isso gera duplicidade e dados inconsistentes. O resultado dessa abordagem é o chamado Data Swamp (pântano de dados): há, de fato, muita informação disponível e uma variedade enorme de tipos de dados, mas é muito difícil acessar esses dados, identificar o que é bom, o que está sendo atualizado, o que responde a perguntas de negócio e o que pode ser utilizado com confiança para gerar, por exemplo, um modelo de Machine Learning (Aprendizado de Máquina).

Toda arquitetura envolve um compromisso, uma escolha baseada em trade-offs (compensações) de governança, custo, flexibilidade e qualidade.

Comparando data warehouse e data lake

Neste slide, comparamos alguns aspectos entre o Data Warehouse (armazém de dados) e o Data Lake (lago de dados). A escalabilidade do Data Warehouse é limitada, enquanto a do Data Lake é muito alta. A governança do Data Warehouse é alta, enquanto a do Data Lake é baixa — não por limitação nativa, mas pela tendência de não se dar a devida atenção a processos de governança, que não são necessariamente tecnológicos. A flexibilidade de armazenamento e de processamento no Data Warehouse é muito maior do que no Data Lake. O Data Lake consegue trabalhar com diversos tipos de dados, inclusive não estruturados, como documentos e vídeos, ou semiestruturados, como JSON, enquanto o Data Warehouse não consegue. Os custos do Data Warehouse, em uma escala mais avançada, são mais elevados, em função de infraestrutura e licenciamento que precisam crescer na mesma proporção em que os dados são processados. No Data Lake, não afirmamos que o custo seja reduzido; precisamos tomar muito cuidado com essa ideia. O custo não é necessariamente menor, mas existem formas e mecanismos para nós racionalizarmos esse custo e reduzi-lo de alguma forma.

Quanto aos riscos envolvidos, no Data Warehouse o risco é o de rigidez — dificuldade de adaptação a novas tecnologias e novas necessidades de negócio —, enquanto o Data Lake pode cair em uma zona de falta de controle. O grande desafio, ao comparar essas duas abordagens, é equilibrar as necessidades de negócio e as capacidades de investimento das empresas, de modo que o negócio seja atendido e a empresa possa evoluir.

Apresentando o lakehouse e antecipando os próximos tópicos

O Lakehouse surge exatamente para convergir e reduzir as limitações de cada uma dessas abordagens.

Nas próximas aulas, vamos ver melhor como funciona a estrutura de Lakehouse, aprofundar os conceitos e as principais estruturas envolvidas nesse modelo, cujo objetivo é resolver essas limitações e riscos das abordagens mais tradicionais. Há outro ponto que não podemos negligenciar: segurança, monitoramento e observabilidade. Vamos ver mais na próxima aula. Te vejo lá!

Sobre o curso Arquitetura de Dados: Lakehouse e Data Mesh aplicados à governança e observabilidade

O curso Arquitetura de Dados: Lakehouse e Data Mesh aplicados à governança e observabilidade possui 316 minutos de vídeos, em um total de 63 atividades. Gostou? Conheça nossos outros cursos de Engenharias e Arquiteturas de Dados em Dados, ou leia nossos artigos de Dados.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Revisão Crítica: Data Lake, Data Warehouse e Lakehouse
• Aprofundando arquitetura Lakehouse
• Fundamentos de Data Mesh
• Quando não usar Data Mesh
• Trade-offs: Centralização vs Descentralização
• Governança em Arquiteturas Distribuídas
• Coexistência Lakehouse e Data Mesh
• Arquitetura Enterprise Completa