Data warehouse, data lake ou lakehouse: qual a sua empresa precisa?

Para a maioria das empresas de médio porte, o ponto de partida certo é um data warehouse: um banco organizado para análise, que recebe os dados do ERP, do CRM e das planilhas já tratados e entrega ao Power BI números que batem em qualquer relatório. O data lake passa a fazer sentido quando entram dados que não cabem bem em tabelas, como arquivos JSON de integrações, logs, leituras de sensores, imagens e PDFs, ou quando o volume bruto fica grande demais para guardar em banco. O lakehouse junta os dois: guarda tudo em arquivos baratos, como um data lake, mas com tabelas confiáveis e consultáveis por SQL, como um warehouse. Ele compensa quando a empresa já tem os dois tipos de dado e uma equipe para operar a plataforma. A escolha depende menos do que está na moda e mais de três perguntas: que tipo de dado você tem, quem vai consumir e quem vai manter.

Qual a diferença entre data warehouse e data lake?

A diferença principal está no momento em que os dados ganham estrutura. No data warehouse, a estrutura vem antes: cada carga passa por limpeza e regras de negócio e entra em tabelas com colunas definidas, por isso a consulta é rápida e o indicador é calculado do mesmo jeito para todo mundo. No data lake, a estrutura vem depois: o arquivo é guardado como chegou e só é interpretado quando alguém vai usá-lo. Isso dá flexibilidade e armazenamento barato, mas passa o trabalho e o risco para quem consulta. Um lago sem catálogo, sem dono e sem regra de qualidade vira em pouco tempo um depósito de arquivos que ninguém sabe se pode usar, o que o mercado apelidou de data swamp (pântano de dados).

• Tipo de dado: o warehouse trabalha com tabelas, como pedidos, notas, estoque e títulos. O lake aceita qualquer formato: CSV, JSON, Parquet, logs, imagens, áudio e documentos.
• Quem consome: o warehouse atende analistas de negócio e painéis do Power BI. O lake atende engenheiros e cientistas de dados, que sabem tratar o dado bruto.
• Confiança no número: no warehouse, a regra do indicador é escrita uma vez e vale para todos. No lake, sem governança, cada consulta pode aplicar uma regra diferente.
• Custo: guardar arquivos em armazenamento de objetos costuma custar bem menos por GB do que guardar em banco, mas o processamento e as pessoas necessárias para organizar o lake pesam mais na conta.
• Histórico: o lake guarda anos de dado bruto sem pressão de espaço. O warehouse guarda o histórico que interessa à análise, já resumido quando faz sentido.

O que o lakehouse muda?

Durante muitos anos, empresas com os dois tipos de dado mantinham duas camadas: o lake para o bruto e o warehouse para os relatórios, com cargas copiando dados de um para o outro. O lakehouse surgiu para reduzir essa duplicação. Os formatos de tabela abertos permitem atualizar e apagar registros, impedir que uma carga interrompida apareça pela metade na consulta e voltar a uma versão anterior da tabela, tudo sobre arquivos em armazenamento de objetos. Plataformas como Microsoft Fabric, Databricks e Snowflake trabalham com esse modelo, cada uma à sua maneira. O ganho é manter uma cópia só do dado e várias formas de consultá-la. O preço é a complexidade: um lakehouse pede organização em camadas (bruto, tratado e pronto para o negócio), rotinas de manutenção das tabelas e alguém que conheça a plataforma a fundo.

Qual arquitetura a sua empresa precisa?

• Só data warehouse: os dados vêm de sistemas transacionais (ERP, CRM, WMS, financeiro) e de planilhas, o volume cabe em um banco, o consumo é de relatórios e painéis e a equipe de dados é pequena. É o caso da maioria das empresas de médio porte, e um SQL Server, um PostgreSQL ou um warehouse em nuvem resolve.
• Warehouse com um lake de apoio: além dos sistemas, chegam arquivos de integrações, telemetria, logs de e-commerce ou documentos que precisam ficar guardados em estado bruto, mas o uso principal continua sendo BI.
• Lakehouse: há volume grande de dados semiestruturados ou de máquina, projetos de ciência de dados ou IA que leem o dado bruto, várias áreas consumindo a mesma base e uma equipe, interna ou parceira, para operar a plataforma.
• Nenhum dos três, por enquanto: se os relatórios saem de exportações do ERP e o problema é que ninguém confia nos números, a prioridade é organizar regras e cadastros. Nesse estágio, o passo seguinte está em como sair das planilhas para uma base de dados confiável.

Como isso fica em um exemplo?

Tome como referência uma distribuidora inventada para ilustrar a escolha, sem ligação com clientes ou projetos da Insight Pro. Ela tem ERP, WMS e um sistema de roteirização, oito anos de histórico e dois analistas que mantêm 30 painéis no Power BI. Os dados do ERP e do WMS somam algumas dezenas de GB, em tabelas bem definidas. Para esse conjunto, um data warehouse com cargas diárias, ou de hora em hora no caso do estoque, resolve com folga.

O cenário muda quando a empresa decide acompanhar a frota. São 80 caminhões enviando a posição a cada 30 segundos: 2.880 leituras por caminhão por dia, cerca de 230 mil por dia na frota e 84 milhões por ano. Os dados chegam do fornecedor de rastreamento em arquivos JSON, e o formato muda quando ele atualiza o sistema. Carregar tudo direto no warehouse obriga a definir as colunas antes de saber o que será analisado, e cada mudança de formato quebra a carga. A saída mais sensata é guardar os arquivos brutos em armazenamento de objetos e levar ao warehouse só o que o negócio usa, como tempo parado por cliente, quilômetros por rota e atrasos por janela de entrega. Se mais adiante a empresa quiser treinar um modelo de previsão de tempo de entrega com o histórico completo, o lakehouse passa a fazer sentido, porque o mesmo dado bruto atende o BI e o modelo sem cópias paralelas.

Esse é o padrão mais comum: a arquitetura cresce quando aparece a necessidade. Começar pelo lakehouse sem dado semiestruturado e sem equipe para operar costuma gerar uma plataforma cara fazendo o trabalho de um banco de dados.

Como decidir sem errar a arquitetura?

1. 1.Liste as fontes e o formato de cada uma: sistemas com banco de dados, APIs, arquivos, planilhas e sensores, com volume e frequência de atualização.
2. 2.Liste as perguntas de negócio dos próximos 12 meses: quais painéis, quais análises e se existe de fato um projeto de IA ou ciência de dados planejado, com dono e orçamento.
3. 3.Veja quem vai manter: quantas pessoas de dados a empresa tem, se dominam SQL, Python ou Spark e se haverá um parceiro. Plataforma sem dono se degrada rápido.
4. 4.Comece pela menor arquitetura que atende: quase sempre um warehouse bem modelado, com a regra de cada indicador escrita uma vez.
5. 5.Prepare o próximo passo sem construí-lo: se já existem arquivos brutos, guarde-os desde já em armazenamento de objetos e prefira ferramentas que leiam formatos abertos, para que uma futura migração não exija refazer tudo.
6. 6.Revise a decisão quando os dados mudarem: entrada de telemetria, e-commerce com volume alto ou um projeto de IA aprovado são os eventos que justificam subir de patamar.

Quais erros encarecem o projeto?

• Escolher pela ferramenta: contratar a plataforma mais comentada e depois procurar um problema para ela resolver.
• Lake sem governança: jogar tudo no armazenamento "para o caso de precisar", sem catálogo, dono e regra de retenção. Guardar sai barato, mas encontrar e confiar no dado depois sai caro.
• Levar o problema de origem junto: cadastros duplicados e regras divergentes continuam errados em qualquer arquitetura. Se os números já não fecham hoje, vale entender antes por que os números do Power BI não batem com o ERP.
• Duplicar regras de negócio: calcular a margem de um jeito no lake, de outro no warehouse e de um terceiro no Power BI. A regra precisa morar em um lugar só.
• Subestimar as pessoas: licença e nuvem costumam ser a menor parte da conta. A engenharia que mantém cargas, qualidade e custos é o que decide se a plataforma ainda funciona no segundo ano.

Para quem está no ambiente Microsoft e avalia uma plataforma única, os critérios de custo e de tamanho de capacidade estão em Microsoft Fabric para indústrias: quando centralizar os dados.

Se a sua empresa está decidindo onde guardar e organizar os dados, ou recebeu propostas de plataformas diferentes e não sabe como compará-las, agende uma conversa sobre arquitetura de dados com a Insight Pro. No diagnóstico gratuito, dentro do serviço de Engenharia de Dados, mapeamos as suas fontes, o formato e o volume de cada uma, as perguntas que o negócio precisa responder e quem vai manter o ambiente, e indicamos a menor arquitetura que atende hoje, com o caminho de crescimento definido para quando os dados mudarem.