Data Lake vs. Data Warehouse na Nuvem: Um Guia Prático para Cientistas de Dados

Um data lake é um repositório centralizado que armazena dados brutos em seu formato nativo — estruturados, semiestruturados e não estruturados — usando armazenamento de objetos em nuvem de baixo custo. Diferente de um cloud data warehouse, que exige um esquema predefinido antes que os dados possam ser carregados, um data lake aplica a estrutura apenas no momento da leitura, oferecendo a cientistas e engenheiros de dados o máximo de flexibilidade para trabalhar com diversos tipos de dados sem a necessidade de transformação prévia. Ambas as arquiteturas rodam em infraestrutura de nuvem, mas respondem a perguntas fundamentalmente diferentes sobre como coletar, processar e recuperar dados em escala.

Este guia foi escrito para cientistas de dados, engenheiros de dados e líderes de analytics que precisam de um framework de decisão prático — e não de um discurso de vendas de um fornecedor. Ao final, você entenderá as principais diferenças entre um data lake e um cloud data warehouse, quando um data lakehouse preenche essa lacuna e como escolher a arquitetura de armazenamento de dados certa para suas cargas de trabalho específicas.

Resumo rápido de recomendações

Antes de nos aprofundarmos nos detalhes técnicos, aqui está a orientação prática que a maioria das equipes precisa logo de início.

Escolha um data lake quando sua principal necessidade for armazenar dados brutos e multiformato em escala de petabytes para machine learning, ciência de dados ou casos de uso futuros de analytics que ainda não foram definidos. Os data lakes oferecem escalabilidade a um custo por gigabyte menor do que os cloud data warehouses e suportam todos os tipos de dados sem exigir um esquema antes da ingestão.

Escolha um cloud data warehouse quando sua carga de trabalho estiver focada em consultas SQL rápidas e concorrentes em dados de negócios estruturados — como dashboards, relatórios financeiros, extratos de contas de clientes e analytics operacional, onde a baixa latência de consulta e a alta concorrência importam mais do que a flexibilidade de armazenamento.

Escolha um data lakehouse quando sua organização executar cargas de trabalho de machine learning e business intelligence e precisar de uma plataforma unificada que elimine a duplicação de dados entre um lake e um warehouse. Os lakehouses oferecem suporte a transações ACID diretamente no armazenamento do lake, tornando-os a escolha padrão prática para a maioria das plataformas de dados modernas.

O que é um data lake?

Um data lake é um repositório centralizado projetado para armazenar todos os seus dados — estruturados, semiestruturados e não estruturados — em seu formato original e bruto até que sejam necessários para análise. Os data lakes surgiram especificamente para lidar com a explosão das necessidades de armazenamento de dados não estruturados que os bancos de dados relacionais tradicionais e os data warehouses não conseguiam acomodar de forma econômica.

A característica definidora de um data lake é que ele aceita dados imediatamente usando a metodologia de Extração, Carga e Transformação (ELT), aplicando o esquema na leitura (schema-on-read) em vez do esquema na escrita (schema-on-write). Isso significa que os engenheiros de dados podem ingerir arquivos de log, eventos JSON, imagens, vídeos, fluxos de sensores e tabelas de banco de dados no mesmo sistema sem primeiro definir como esses dados serão consultados. Os cientistas de dados ganham acesso direto a dados brutos e não processados em qualquer formato em que tenham chegado, o que é essencial para a engenharia de recursos e o desenvolvimento de modelos de machine learning.

Os cloud data lakes geralmente rodam em serviços de armazenamento de objetos — como Amazon S3, Azure Data Lake Storage (ADLS) e Google Cloud Storage —, que oferecem capacidade virtualmente ilimitada. Os data lakes podem armazenar petabytes de informações sem limitações fixas, e o custo por gigabyte é substancialmente menor do que o armazenamento proprietário usado por data warehouses legados. Essa escalabilidade a um custo por gigabyte mais baixo torna os data lakes a escolha prática para o armazenamento de big data onde o volume é a principal preocupação.

Os data lakes suportam todos os tipos de dados — exportações de bancos de dados estruturados, formatos semiestruturados como JSON e Parquet, e conteúdos totalmente não estruturados como corpora de texto, áudio e imagens. Essa abrangência os torna a zona de destino de dados natural para qualquer organização que precise reter dados brutos para analytics futuro, incluindo casos de uso que ainda não foram definidos no momento da ingestão.

Contexto de Cloud Data Warehouses e Bancos de Dados Relacionais

Um cloud data warehouse é um banco de dados de analytics gerenciado, otimizado para consultas SQL de alta concorrência em dados estruturados e prontos para os negócios. Ao contrário de um banco de dados relacional projetado para cargas de trabalho transacionais — inserindo e atualizando linhas individuais em tempo real —, um cloud data warehouse é construído para cargas de trabalho analíticas que varrem grandes volumes de dados históricos para produzir agregações, relatórios e dashboards.

Os cloud data warehouses impõem um modelo de esquema na escrita (schema-on-write): os dados devem ser limpos, tipados e adaptados a um esquema predefinido antes de serem carregados. Essa restrição é a origem tanto da maior força do warehouse quanto de sua limitação mais significativa. Como cada linha em cada tabela segue uma estrutura conhecida, o armazenamento colunar e as técnicas de aceleração de consulta (como pushdown de predicados, zone maps e cache de resultados) podem ser aplicados de forma agressiva — oferecendo o desempenho de consulta de subsegundo que os usuários de negócios e analistas de dados esperam dos dashboards.

Os principais fornecedores de cloud data warehouse — incluindo Amazon Redshift, Google BigQuery, Snowflake e Databricks Lakehouse — desacoplaram a computação do armazenamento, o que significa que a capacidade de consulta pode ser dimensionada independentemente dos dados armazenados. Essa arquitetura suporta cargas de trabalho de alta concorrência, onde centenas de usuários executam consultas simultâneas sem disputa por recursos. Para casos de uso de business intelligence — relatórios de receita, extratos de contas de clientes, analytics de inventário —, o cloud data warehouse continua sendo a escolha dominante porque o desempenho da consulta e a consistência dos dados são inegociáveis.

Onde os cloud data warehouses encontram dificuldades é com tipos de dados que não se ajustam a um modelo relacional: texto não estruturado, fluxos de sensores brutos, embeddings de imagem e logs de eventos semiestruturados. Carregar esses dados em um warehouse exige um trabalho substancial de transformação e, muitas vezes, resulta no descarte ou na aproximação de dados para se ajustarem a um esquema, o que compromete a integridade exigida pelas cargas de trabalho de machine learning.

Arquitetura de Data Lake e Soluções de Armazenamento

A arquitetura de data lake geralmente é organizada em três zonas, cada uma representando um nível progressivamente mais alto de qualidade de dados e prontidão para os negócios.

Zona Raw (Camada Bronze)

A zona raw é a área de destino inicial para os dados ingeridos de sistemas de origem externos. Os dados chegam em seu formato nativo — exportações de banco de dados, respostas de API, eventos de streaming, arquivos planos — e são gravados no armazenamento de objetos com transformação mínima. O objetivo é a fidelidade: preservar o registro original para que todo o pipeline possa ser executado novamente desde o início se a lógica downstream for alterada. Metadados, carimbos de data/hora de carregamento (timestamps) e identificadores de origem são adicionados, mas os dados em si não são modificados.

Zona Cleansed (Camada Prata)

Na zona cleansed, os dados brutos são combinados, mesclados e adaptados em uma visão empresarial unificada. Verificações de qualidade de dados são aplicadas, registros duplicados são resolvidos e dados de várias origens são unidos em entidades coerentes — como clientes, transações e produtos. Essa camada suporta análises exploratórias, relatórios ad-hoc e experimentação de ciência de dados sem expor dados brutos e não processados aos consumidores downstream.

Zona Curated (Camada Ouro)

A zona curated contém agregações em nível de negócios e prontas para produção, disponíveis para consumo por dashboards, analytics operacional e modelos de machine learning. Os dados nesta camada passaram por todas as etapas de qualidade e estão organizados em estruturas prontas para consumo — como esquemas estrela, tabelas largas (wide tables) e métricas pré-agregadas — que suportam consultas de alto desempenho. A arquitetura de medalhão, que formaliza as camadas Bronze, Silver e Gold como estágios distintos de pipeline, é o padrão mais amplamente adotado para organizar a arquitetura de data lake.

O armazenamento de objetos é a base de todas as três zonas. Formatos como Apache Parquet e Apache ORC oferecem codificação colunar que reduz o espaço de armazenamento e acelera as varreduras analíticas. Formatos abertos desacoplam os dados do mecanismo de processamento de qualquer fornecedor específico, permitindo que os mesmos arquivos sejam consultados por várias ferramentas sem a necessidade de cópia.

Custos de Armazenamento de Dados e Escalabilidade

As comparações de custos entre data lakes e cloud data warehouses devem considerar o armazenamento e o processamento (compute) separadamente, já que as arquiteturas modernas desacoplam os dois.

O armazenamento de data lake em camadas de armazenamento de objetos em nuvem é significativamente mais barato do que o armazenamento proprietário de data warehouses — muitas vezes por uma ordem de magnitude no preço bruto por gigabyte. Para organizações que armazenam grandes volumes de dados brutos ou históricos que são consultados com pouca frequência, as camadas de armazenamento frio (como Amazon S3 Glacier e Azure Archive) reduzem ainda mais os custos, embora com maior latência de recuperação. Os data lakes são mais econômicos do que os data warehouses precisamente porque o armazenamento de objetos foi projetado para durabilidade e escala, e não para desempenho de consulta.

Os cloud data warehouses aplicam preços por consulta ou por unidade de computação, o que os torna econômicos para cargas de trabalho regulares e de alto valor, mas caros para consultas ad-hoc ou exploratórias em grandes conjuntos de dados. Os modelos de preço de pagamento por uso (pay-as-you-go) em cloud data warehouses modernos ajudam — você paga pelas consultas executadas em vez de um tamanho de cluster fixo —, mas o custo por terabyte de dados processados permanece substancialmente mais alto do que o armazenamento em lake.

A implicação prática é que as decisões de arquitetura de armazenamento de dados raramente são escolhas simples de exclusão mútua. Muitas organizações depositam todos os dados em um lake por eficiência de custo e, em seguida, movem seletivamente conjuntos de dados tratados para um warehouse para BI de alta simultaneidade. O custo de duplicação para manter duas cópias — uma no lake e outra no warehouse — é o principal fator que impulsiona a adoção do lakehouse.

Machine Learning e análises avançadas para cientistas de dados

Os data lakes foram criados para machine learning. A capacidade de armazenar dados brutos em seu formato nativo significa que os cientistas de dados podem acessar a fidelidade total dos dados históricos — e não um subconjunto pré-agregado ou limitado por esquemas —, o que é essencial para treinar modelos de alta qualidade.

Engenharia de features para machine learning exige transformações iterativas e exploratórias em diversos tipos de dados. Um cientista de dados que treina um modelo de detecção de fraudes precisa de logs de transações brutos, dados de impressão digital do dispositivo (device fingerprint), sequências comportamentais e histórico de contas — a maior parte dos quais não se ajusta perfeitamente a um esquema relacional. Os data lakes oferecem consistência de dados essencial em várias aplicações, preservando o formato bruto que os pipelines de ML exigem.

Os data lakes se integram nativamente com ferramentas de ciência de dados e análises avançadas. Apache Spark, o padrão de fato para ML distribuído em escala, lê diretamente do armazenamento de objetos usando formatos abertos. As bibliotecas Python usadas para treinamento de modelos — PyTorch, TensorFlow, scikit-learn — acessam o armazenamento do lake por meio das mesmas APIs compatíveis com S3. Os engenheiros de dados podem executar pipelines de dados em streaming que alimentam recursos em tempo real nos modelos sem mover os dados para um sistema separado.

Os cloud data warehouses contribuem para os fluxos de trabalho de ML principalmente na fase de inferência e scoring. Depois que um modelo é treinado, o scoring operacional em tabelas estruturadas do warehouse — como executar uma previsão de churn em uma tabela de clientes ou pontuar leads em uma exportação de CRM — se beneficia da indexação e da otimização de consultas do warehouse. Uma arquitetura de ML madura posiciona a feature store no limite: a computação de features brutas acontece no lake, enquanto as tabelas de features prontas para consumo são materializadas em um formato acessível tanto para o warehouse quanto para a camada de serviço do modelo.

Cargas de trabalho de análise de dados e BI

As cargas de trabalho de business intelligence — dashboards, relatórios agendados, consultas ad-hoc de analistas de negócios — têm requisitos que diferem fundamentalmente do machine learning. Os usuários de BI precisam de respostas de baixa latência (menos de um segundo para carregamento de dashboards), resultados consistentes entre usuários simultâneos e dados que reflitam definições de negócios acordadas, e não valores de origem brutos.

Os cloud data warehouses são projetados especificamente para esses requisitos. O armazenamento colunar, o cache de resultados e as exibições materializadas garantem que as consultas comuns de dashboard retornem em milissegundos, mesmo com o crescimento dos dados. O controle de acesso granular permite que os analistas de dados consultem os dados de seus departamentos sem expor registros confidenciais de outras unidades de negócios. Os usuários de negócios podem executar SQL diretamente em tabelas estruturadas sem precisar entender as opções de armazenamento de dados subjacentes ou os formatos de arquivo.

Os data lakes podem atender a cargas de trabalho de BI por meio de mecanismos de consulta SQL — Apache Hive, Presto, Trino, Spark SQL —, mas tradicionalmente ofereciam um desempenho de consulta inferior em comparação com warehouses projetados especificamente para isso. A flexibilidade do schema-on-read traz uma sobrecarga de planejamento de consulta que se torna evidente sob alta simultaneidade. Para dashboards em tempo real e business intelligence de alta simultaneidade, um cloud data warehouse ou um lakehouse com uma camada SQL de alto desempenho é a escolha adequada.

O streaming de dados para dashboards em tempo real é cada vez mais comum: leituras de sensores, clickstreams de sites, eventos de pagamento. Tanto os data lakes os cloud data warehouses oferecem suporte à ingestão por streaming por meio de conectores para Kafka, Kinesis e sistemas semelhantes, mas o suporte do lake para pipelines de dados em streaming sem restrições de esquema o torna a zona de destino mais natural para fluxos de eventos de alta velocidade e esquema variável.

Principais diferenças: Lake vs. Cloud Data Warehouses

A comparação a seguir abrange as dimensões mais importantes nas decisões de arquitetura.

Modelo de esquema

Os data lakes usam schema-on-read: a estrutura é aplicada quando os dados são consultados, não quando são gravados. Qualquer tipo de dados pode ser ingerido imediatamente, sem a necessidade de um design prévio. Os cloud data warehouses exigem schema-on-write: os dados devem estar em conformidade com uma estrutura predefinida antes do carregamento, o que garante a qualidade dos dados, mas retarda a ingestão e limita a flexibilidade. Essa distinção impulsiona a maioria das outras diferenças abaixo.

Desempenho de consulta

Os cloud data warehouses oferecem um desempenho de consulta superior para cargas de trabalho estruturadas baseadas em SQL, especialmente sob alta simultaneidade. Mecanismos colunares projetados especificamente, cache inteligente e otimizações de compilação de consultas geram respostas em menos de um segundo para padrões comuns de BI. Os mecanismos de consulta de data lakes tradicionais são mais lentos para SQL simultâneo, mas melhoraram substancialmente com os mecanismos vetorizados modernos. Os data lakes continuam sendo mais rápidos para processamento em lote de grande escala e cargas de trabalho de treinamento de ML, onde a computação do warehouse seria proibitivamente cara.

Maturidade de governança e curadoria de dados

Os cloud data warehouses têm uma governança integrada mais madura: controles de acesso em nível de tabela e coluna, logs de auditoria, rastreamento de linhagem de dados e tipos de dados obrigatórios são recursos padrão. Os data lakes tradicionais exigem ferramentas adicionais — catálogos de dados, camadas de gerenciamento de metadados, sistemas externos de controle de acesso — para atingir uma maturidade de governança equivalente. Essa lacuna diminuiu significativamente com serviços de catálogo como o Unity Catalog, mas os warehouses ainda levam vantagem para organizações com requisitos de conformidade rigorosos.

Custo por terabyte

Os data lakes armazenam dados a um custo por terabyte substancialmente menor do que os cloud data warehouses — geralmente de 10 a 100 vezes mais barato, dependendo da camada de armazenamento e da frequência de consulta. Para grandes volumes de dados, dados históricos e ingestão bruta, a vantagem de custo do lake é decisiva. Para dados de negócios tratados e consultados com frequência, o desempenho do warehouse justifica seu custo mais elevado.

Formatos e tipos de dados suportados

Os data lakes suportam todos os tipos de dados: exportações relacionais estruturadas, JSON e XML semiestruturados, texto não estruturado, imagens, áudio e arquivos binários. Os warehouses são otimizados para dados estruturados armazenados em tabelas de banco de dados e oferecem suporte nativo limitado ou nulo para dados não estruturados e semiestruturados. O armazenamento de dados diversos — arquivos de log junto com transações financeiras e metadados de imagem — é um caso de uso típico de lake.

Principais perfis de usuário

Os engenheiros de dados e cientistas de dados são os principais usuários dos ambientes de data lake: eles precisam de acesso bruto a todos os dados em seu formato nativo para desenvolvimento de pipelines e treinamento de modelos. Os analistas de dados e usuários de negócios são os principais consumidores dos cloud data warehouses: eles precisam de dados limpos, confiáveis e de resposta rápida para consultas SQL e relatórios. Os data lakehouses atendem a ambos os perfis a partir de uma única plataforma, o que é o principal motivo de sua rápida adoção.

Data Lakehouses: unindo lakes e warehouses

Um data lakehouse é uma arquitetura de plataforma de dados que combina o armazenamento flexível e de baixo custo de um data lake com os recursos de gerenciamento de dados e o desempenho de consulta de um data warehouse — em um único sistema unificado. O lakehouse elimina o custo operacional mais caro da arquitetura de dois sistemas: manter uma cópia separada dos dados tratados no warehouse.

A camada de armazenamento transacional é a principal inovação. Os formatos de tabela abertos — Delta Lake, Apache Iceberg e Apache Hudi — adicionam suporte a transações ACID diretamente ao armazenamento de objetos. As transações ACID garantem que cada operação de gravação seja totalmente bem-sucedida ou totalmente revertida, evitando a corrupção de dados por gravações simultâneas. Essa garantia, que os data warehouses oferecem há décadas, historicamente não estava disponível nos data lakes. Os lakehouses oferecem suporte a transações ACID para confiabilidade dos dados, mantendo o formato aberto e a estrutura de custos do lake.

O Delta Lake é o formato de tabela de lakehouse mais amplamente adotado. Ele armazena dados em arquivos Parquet no armazenamento de objetos em nuvem e mantém um log de transações que registra cada alteração de esquema, inserção, atualização e exclusão. O recurso de Time Travel — que pode ser consultado via SQL — permite que cientistas de dados e auditores leiam qualquer snapshot histórico de uma tabela. A compactação automática de arquivos e os índices de salto de dados (data skipping) aceleram o desempenho das consultas sem a necessidade de ajuste manual. Delta Lake é uma tecnologia comum usada em arquiteturas de lakehouse porque é de código aberto, agnóstico em relação à nuvem e se integra nativamente com o Apache Spark e mecanismos SQL.

O Apache Iceberg e o Apache Hudi oferecem recursos semelhantes com diferentes compensações de design. O Iceberg oferece uma evolução de esquema mais robusta e particionamento oculto para cargas de trabalho analíticas complexas. O Hudi é especializado em upserts em nível de registro e padrões de ingestão por streaming. Todos os três formatos são cada vez mais interoperáveis por meio de padrões abertos como o Apache XTable.

Até 2025, os lakehouses representarão mais da metade das cargas de trabalho de análise corporativa — impulsionados pela simplicidade operacional de gerenciar uma única plataforma em vez de sincronizar um lake e um warehouse. Para organizações que estão criando uma nova plataforma de dados, o lakehouse é o padrão prático.

Padrões de integração com bancos de dados relacionais e data marts

Compreender onde o data lake e o cloud data warehouse se posicionam em relação a outros sistemas esclarece quando usar cada um deles.

Os bancos de dados relacionais de Online Transaction Processing (OLTP) — MySQL, PostgreSQL, Oracle — continuam sendo o sistema de registro para aplicações operacionais. Eles são otimizados para cargas de trabalho transacionais com uso intenso de gravação: gerenciamento de pedidos, rastreamento de inventário, autenticação de usuários. As cargas de trabalho analíticas não devem ser executadas diretamente nos bancos de dados OLTP porque a carga de consulta compete com as transações da aplicação. O padrão comum é replicar os dados OLTP no lake ou warehouse por meio de Change Data Capture (CDC), uma técnica que transmite alterações em nível de linha do banco de dados de origem como eventos, sem impactar o desempenho operacional.

Os data marts são subconjuntos específicos de um data warehouse ou lake maior, organizados para uma função de negócios específica — finanças, marketing, cadeia de suprimentos. Eles fornecem conjuntos de dados curados e pré-combinados que os analistas de negócios podem consultar sem precisar entender todo o modelo de dados da empresa. Os data marts continuam sendo relevantes em organizações onde diferentes departamentos têm requisitos de governança divergentes ou onde o isolamento de consultas é necessário para o desempenho. Em uma arquitetura lakehouse, as tabelas da camada Gold atendem perfeitamente à função de data mart sem a necessidade de um sistema físico separado.

ETL (Extract, Transform, Load) é o padrão adequado para carregamento em sistemas de gravação com esquema (schema-on-write): as transformações são aplicadas antes que os dados entrem no warehouse, garantindo a conformidade com o esquema de destino. ELT (Extract, Load, Transform) é o padrão adequado para sistemas de leitura com esquema (schema-on-read): os dados brutos chegam primeiro ao lake e, em seguida, as transformações são aplicadas no momento da consulta ou nas etapas do pipeline. A maioria das plataformas de dados modernas usa ELT para ingestão no lake e, depois, aplica a curadoria no estilo ETL para produzir tabelas da camada Gold.

Segurança, governança e conformidade

A governança de dados em um data lake em nuvem exige um investimento explícito que os sistemas de warehouse oferecem por padrão.

O controle de acesso em nível de arquivo — impedindo que usuários não autorizados leiam dados brutos no armazenamento de objetos — é o requisito fundamental. Os provedores de nuvem oferecem políticas de acesso em nível de bucket e de prefixo, mas os controles detalhados em nível de coluna e de linha exigem uma camada de governança adicional. Unity Catalog, a plataforma de governança unificada da Databricks, oferece políticas de segurança em nível de tabela, coluna e linha em tabelas de lake e warehouse a partir de uma única interface, usando a sintaxe SQL DCL padrão que os administradores de banco de dados já conhecem.

O catálogo de dados e o gerenciamento de metadados são a segunda camada de governança. Um catálogo rastreia quais tabelas existem, quais são seus esquemas, quem é o proprietário delas e como foram produzidas — a linhagem de dados desde a origem até o consumo. Sem um catálogo, os data lakes se tornam pântanos de dados (data swamps): repositórios onde os dados se acumulam sem documentação e os engenheiros passam mais tempo procurando dados do que analisando-os. A linhagem automatizada — rastreando o caminho de transformação desde a ingestão Bronze, passando por junções Silver até agregações Gold — é essencial para depurar pipelines, validar a conformidade e entender o impacto das alterações de esquema.

A criptografia é necessária para todos os dados em repouso e em trânsito. O armazenamento de objetos em nuvem criptografa os dados em repouso por padrão usando criptografia no lado do servidor, e o transporte é sempre criptografado via TLS. Organizações com requisitos mais rígidos gerenciam suas próprias chaves de criptografia usando chaves gerenciadas pelo cliente (CMK) por meio de serviços de gerenciamento de chaves na nuvem, garantindo que nem mesmo o provedor de nuvem possa descriptografar os dados sem autorização explícita.

Estrutura de decisão de migração e arquitetura

A escolha entre um data lake, um cloud data warehouse e um data lakehouse exige a correspondência das capacidades arquitetônicas com os requisitos de carga de trabalho.

Comece com uma avaliação de adequação da carga de trabalho. Catalogue suas cargas de trabalho de análise por consumidor principal (cientistas de dados, analistas, usuários de negócios), tipos de dados necessários (estruturados, semiestruturados, não estruturados), padrões de consulta (lote, interativo, streaming) e requisitos de latência (segundos, minutos, horas). Cargas de trabalho dominadas por relatórios SQL estruturados são mapeadas para warehouses. Cargas de trabalho que exigem diversos tipos de dados, treinamento de modelo de ML ou flexibilidade futura são mapeadas para lakes. Cargas de trabalho mistas são mapeadas para lakehouses.

Avalie o custo juntamente com o desempenho. Um data warehouse existente pode ter um desempenho aceitável para as cargas de trabalho atuais, mas calcule o custo total, incluindo o armazenamento de dados brutos localizados em outro lugar, os custos de duplicação de dados e a sobrecarga de engenharia para manter os pipelines de sincronização. Para maioria das organizações que armazenam mais do que alguns terabytes de dados brutos, a vantagem de custo de armazenamento do lake aumenta significativamente ao longo do tempo.

Avalie as habilidades da sua equipe de forma honesta. Os cloud data warehouses têm ferramentas mais acessíveis para equipes de análise focadas em SQL. Os data lakes exigem um investimento de engenharia mais profundo no desenvolvimento de pipelines, gerenciamento de catálogos e ferramentas de governança. Os lakehouses reduzem essa lacuna, mas ainda exigem conhecimento em Spark ou processamento distribuído equivalente para cargas de trabalho em grande escala.

Para organizações que estão migrando de um data warehouse tradicional, uma abordagem em fases é mais eficaz. Na etapa piloto, identifique uma única carga de trabalho de alto valor — um caso de uso de ML específico ou um tipo de dados que o warehouse existente não manipula bem — e envie-a para o lake ou lakehouse. Meça o custo real, o desempenho e os resultados de governança em relação ao sistema existente antes de expandir. Isso evita o modo de falha comum de uma migração em massa ("big-bang") que interrompe as análises de produção antes que a nova arquitetura seja validada.

Escolhendo entre data lake, warehouse e lakehouse

A estrutura de decisão se simplifica em três caminhos com base no tipo de carga de trabalho principal.

Se a sua carga de trabalho for dominada por machine learning, experimentação de ciência de dados ou armazenamento de grandes volumes de dados brutos ou não estruturados, comece com um data lake. A eficiência de custos e a flexibilidade de formato são vantagens decisivas, e você pode adicionar uma camada de consulta SQL mais tarde, conforme as necessidades de relatórios amadurecerem.

Se a sua carga de trabalho for dominada por análises SQL estruturadas, painéis de alta simultaneidade e relatórios de negócios com requisitos rígidos de latência, e seus dados já estiverem estruturados na origem, um cloud data warehouse oferece o melhor desempenho por dólar para esse caso de uso específico.

Se a sua organização executa ambos os tipos de cargas de trabalho — ou prevê executar ambos dentro de 12 a 18 meses —, crie uma arquitetura lakehouse desde o início. O custo de migrar uma arquitetura madura de dois sistemas para um lakehouse unificado mais tarde é substancialmente maior do que construir sobre bases unificadas inicialmente.

Em todos os casos, valide as suposições com um projeto piloto antes de se comprometer com uma migração completa. Defina métricas de sucesso mensuráveis antes do início do piloto: latência de consulta em P95, custo por terabyte por mês, tempo desde a ingestão bruta até os dados prontos para análise e a proporção de manutenção de pipeline em relação ao desenvolvimento de novos recursos. Essas métricas fornecem uma base objetiva para decisões de arquitetura que, de outra forma, se tornariam debates organizacionais.

FAQs e conceitos errôneos comuns

Um data lake substitui um cloud data warehouse em todos os casos?

Um data lake não substitui um cloud data warehouse em todos os casos. Os data lakes são excelentes para armazenar dados brutos e multiformato a baixo custo e dar suporte a cargas de trabalho de machine learning, mas os data lakes tradicionais oferecem um desempenho de consulta mais lento para cargas de trabalho SQL de alta simultaneidade do que os warehouses criados especificamente para essa finalidade. Organizações com requisitos maduros de business intelligence se beneficiam de um cloud data warehouse ou de um lakehouse — uma arquitetura unificada que oferece desempenho de consulta de nível de warehouse diretamente no armazenamento do lake.

Qual é a diferença entre um data lake e um banco de dados relacional tradicional?

Um data lake armazena dados brutos em seu formato nativo no armazenamento de objetos sem um esquema predefinido, enquanto um banco de dados relacional impõe um esquema fixo, armazena dados estruturados em tabelas de banco de dados e é otimizado para cargas de trabalho transacionais — inserindo e atualizando registros individuais. Os data lakes são projetados para cargas de trabalho analíticas e de machine learning em escala de petabytes; os bancos de dados relacionais são projetados para aplicações operacionais que exigem transações ACID com baixa latência em linhas individuais.

Qual é a diferença entre um data lake e um data lakehouse?

Um data lake armazena dados brutos no armazenamento de objetos sem garantias transacionais, tornando complexas as gravações simultâneas e a evolução do esquema. Um data lakehouse adiciona uma camada de formato de tabela aberta — como Delta Lake, Apache Iceberg ou Apache Hudi — que fornece suporte a transações ACID, aplicação de esquema e monitoramento de qualidade de dados diretamente no armazenamento do lake. Os lakehouses oferecem a flexibilidade e a eficiência de custo de um lake e a confiabilidade e o desempenho de consulta de um warehouse sem exigir a duplicação de dados.

Quando devo usar um data mart em vez de um data lake ou warehouse?

Use um data mart quando uma função de negócios específica — finanças, marketing, operações de vendas — exigir um conjunto de dados curado e pré-combinado, otimizado para os padrões de consulta dessa função, e quando o isolamento desse conjunto de dados da plataforma de dados empresarial mais ampla for necessário por motivos de governança ou desempenho. Em uma arquitetura lakehouse, as tabelas da camada Gold atendem perfeitamente à função de data mart, reduzindo a necessidade de data marts físicos separados e sua complexidade de sincronização associada.

O que torna um data lake um "pântano de dados" (data swamp) e como posso evitar isso?

Um data lake se torna um data swamp quando os dados se acumulam sem um gerenciamento adequado de metadados, controles de qualidade de dados ou governança de acesso — dificultando para os usuários encontrar, confiar ou acessar os dados de que precisam. A prevenção exige três controles: um catálogo de dados que documenta os esquemas das tabelas, a propriedade e a linhagem; verificações de qualidade de dados aplicadas em cada estágio do pipeline (Bronze, Silver, Gold); e controles de acesso que evitam que gravações não autorizadas poluam os conjuntos de dados curados. A arquitetura de medalhão impõe uma progressão de qualidade que mantém os dados brutos isolados das tabelas de nível de produção.

Apêndice: Padrões Técnicos e Ferramentas

Exemplos de arquiteturas em lote e streaming. Um padrão de ingestão em lote padrão carrega exportações do sistema de origem no armazenamento do lake Bronze diariamente, aplica transformações de limpeza no Silver e materializa agregações Gold para consumo de BI. Um padrão de streaming usa o Apache Kafka ou serviços de streaming de eventos em nuvem para entregar eventos ao Bronze quase em tempo real, com atualizações incrementais no Silver e Gold orientadas por frameworks de tabelas de streaming. Ambos os padrões são executados no mesmo armazenamento de lake, com o Delta Lake lidando com o isolamento de transações entre os dois modos de ingestão.

Ferramentas populares por camada. Para ingestão: Lakeflow, Apache Kafka, serviços de CDC nativos da nuvem. Para transformação: Apache Spark (PySpark, Spark SQL), dbt (para equipes focadas em SQL). Para orquestração: Apache Airflow, serviços de fluxo de trabalho nativos da nuvem. Para análise de SQL: Databricks Lakehouse, BigQuery, Snowflake, Amazon Redshift. Para governança: Unity Catalog, Apache Atlas, serviços de catálogo nativos da nuvem. Para ML: MLflow, Apache Spark MLlib, serviços de treinamento de modelo nativos da nuvem.

Modelos de design de esquema. Para tabelas de BI da camada Gold, os esquemas em estrela no estilo Kimball — uma tabela de fatos central cercada por tabelas de dimensões — continuam sendo o padrão para o desempenho de dashboards. As tabelas de fatos contêm eventos (transações, sessões, conversões); as tabelas de dimensões contêm atributos de entidade (cliente, produto, loja). Para tabelas de features de ML, tabelas desnormalizadas amplas com uma linha por entidade e todas as features como colunas minimizam a complexidade de junção durante o treinamento. Para análise de streaming, tabelas de eventos do tipo append-only com particionamento no timestamp do evento permitem varreduras eficientes de intervalo de tempo para dashboards em tempo real.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original