Data warehouse: o que é e quando você precisa de um

Metade das empresas que pergunta sobre data warehouse tem, somando tudo, umas 40 mil linhas de dados. Isso cabe numa planilha. Cabe até num Google Sheets, com folga.

A outra metade tem informação espalhada em sete sistemas, fecha o mês com três números diferentes de faturamento e acha que o problema está no relatório. Essa metade precisa mesmo, só que quase nunca entende o que está comprando.

Vale separar as duas conversas, porque o erro acontece nos dois sentidos. Quem monta cedo demais queima seis meses em infraestrutura que ninguém consulta. Quem adia demais toma decisão com número errado durante anos e só descobre quando o prejuízo já virou rotina.

O que é um data warehouse?

Um data warehouse é um banco de dados central, organizado para análise, que reúne informações de vários sistemas — ERP, CRM, plataformas de anúncio, planilhas — em um modelo único e com histórico preservado. Ele não roda a operação da empresa: existe para consultar, comparar períodos e gerar relatórios sem travar os sistemas de origem.

Essa última parte é a que costuma passar batido. Um data warehouse não é "um banco de dados maior". É um banco de dados com outro propósito, e a diferença de propósito muda tudo: a modelagem, a frequência de escrita, o tipo de consulta que ele aguenta.

Por que o seu banco de dados atual não resolve?

O sistema que emite nota fiscal foi desenhado para gravar uma transação por vez, rápido, sem perder nada. É o que a literatura chama de OLTP. Ele é ótimo em responder "qual o saldo do cliente 4.812 agora" e péssimo em responder "qual foi a margem por linha de produto, por região, mês a mês, nos últimos três anos".

Quando alguém tenta fazer a segunda pergunta direto na base de produção, duas coisas acontecem. A consulta demora, porque a estrutura não foi feita para varrer milhões de registros. E o sistema fica lento para quem está trabalhando, porque a consulta pesada disputa recurso com a operação. Por isso, na prática, o TI acaba proibindo, e a área de negócio volta para o export em CSV.

Tem ainda um problema mais silencioso: o sistema operacional sobrescreve o passado. Se o cliente mudou de categoria em março, a base mostra a categoria de hoje. Você perde a capacidade de responder "como estávamos naquele momento". O data warehouse guarda essas fotografias. É um dos motivos reais de existir, e raramente aparece nas listas de benefícios.

Quando a empresa realmente precisa de um?

Não existe número mágico de linhas. O que costuma decidir é a combinação de três coisas: quantas fontes precisam conversar, quanto histórico você precisa olhar para trás e quantas pessoas consultam sem pedir ajuda para alguém.

Sinais concretos de que chegou a hora:

• Duas áreas apresentam números diferentes para a mesma pergunta, e ninguém consegue dizer qual está certo.
• O relatório mensal depende de uma pessoa específica juntar cinco exportações à mão.
• Você não consegue cruzar custo de mídia com venda efetivada porque cada número mora num lugar.
• Já bateu no limite da planilha: ela trava, corrompe ou demora minutos para recalcular.
• Precisa comparar com o ano passado e a base de origem já sobrescreveu aquele estado.

Sinais de que ainda não é hora: você tem duas fontes, a operação inteira cabe numa exportação semanal e a dor real é falta de disciplina no preenchimento, não falta de tecnologia. Data warehouse não conserta cadastro mal preenchido; ele só distribui o erro mais rápido, para mais gente, com mais autoridade. Antes de investir, vale endereçar a qualidade dos dados na origem.

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

Os três guardam dados, mas partem de premissas diferentes sobre quando você organiza a informação.

Característica	Data warehouse	Data lake	Lakehouse
Formato	Estruturado, modelado antes da carga	Bruto, como veio da origem	Bruto com camada estruturada por cima
Quem usa no dia a dia	Analistas e áreas de negócio	Engenharia e ciência de dados	Os dois perfis
Custo de armazenamento	Maior por GB	Menor por GB	Intermediário
Risco típico	Rigidez: mudar o modelo dá trabalho	Virar depósito sem catálogo	Complexidade operacional
Faz sentido para	Maioria das empresas médias	Volume alto e dado não estruturado	Times com engenharia dedicada

Opinião de quem já viu isso dar errado: se a sua empresa não tem uma pessoa dedicada a engenharia de dados, data lake vira pasta compartilhada com nome bonito. Comece pelo warehouse, que impõe organização, e só migre se o volume ou o tipo de dado exigir.

Quanto custa um data warehouse na prática?

A conta de infraestrutura assusta menos do que a maioria imagina. No BigQuery, por exemplo, o Google cobra US$ 6,25 por tebibyte consultado, com o primeiro 1 TiB de consultas e os primeiros 10 GiB de armazenamento gratuitos todo mês, segundo a tabela oficial de preços.

Um exemplo calculado. Uma distribuidora com 3 milhões de linhas de vendas, 800 mil registros de CRM e dois anos de dados de mídia ocupa algo perto de 8 GB, dentro da faixa gratuita de armazenamento. Se a equipe rodar consultas que varrem 200 GB por mês, ainda fica abaixo do 1 TiB gratuito. Custo de infraestrutura: zero ou perto disso.

O custo real está em outro lugar: quem constrói e quem mantém. A rotina de ETL precisa de alguém. A API da plataforma de anúncios muda, o campo de categoria ganha um valor novo, o ERP é atualizado e a carga quebra numa sexta-feira. Orçar o warehouse sem orçar a manutenção é o jeito mais comum de ter um projeto morto em doze meses, com a tabela lá, desatualizada, e todo mundo de volta ao CSV.

Vale lembrar o tamanho do prejuízo do lado oposto. A Gartner estima que dados de má qualidade custam, em média, pelo menos US$ 12,9 milhões por ano às organizações, conforme publicado no próprio site da consultoria. Não é o seu número — é o de grandes organizações —, mas a proporção costuma se manter: o erro de decisão custa mais caro que a estrutura.

Como sair da planilha sem travar o projeto

A ordem importa mais que a ferramenta. Um caminho que funciona:

1. Escolha uma pergunta de negócio, não um conjunto de tabelas. "Qual o CAC por canal, por mês" é um escopo. "Centralizar os dados da empresa" não é.
2. Traga só as fontes que respondem aquela pergunta. Duas, três no máximo. Resista à tentação de plugar tudo.
3. Modele com nomes que a área de negócio usa. Se o comercial fala "oportunidade ganha", a tabela não deveria chamar stage_id_7.
4. Automatize a carga antes de fazer o dashboard bonito. Dashboard com dado velho é pior que planilha, porque parece confiável.
5. Só depois abra para outras áreas. Cada área nova traz regra nova de negócio, e é melhor descobrir isso com a estrutura já estável.

Esse recorte resolve o sintoma mais caro dos dados em silos (números que não fecham entre áreas) sem exigir um projeto de doze meses para começar a entregar valor.

Os erros que matam o projeto no meio

O primeiro é começar pela ferramenta. A reunião vira comparação entre Snowflake, BigQuery e Redshift antes de alguém definir qual decisão o warehouse vai apoiar. Para a maioria das empresas médias, as três resolvem; a escolha muda pouco o resultado e atrasa muito o começo.

O segundo é replicar a bagunça. Se você joga as tabelas do ERP dentro do warehouse sem modelar, ganhou uma cópia mais cara da mesma confusão. O trabalho de tradução, de estrutura de sistema para estrutura de negócio, é o que gera o valor.

O terceiro é subestimar a rotina. Pesquisa da Anaconda com profissionais de dados apontou que, em média, 45% do tempo é gasto preparando dados (carregando e limpando) antes de qualquer análise, segundo o State of Data Science 2020. O warehouse reduz esse percentual, mas transfere parte do esforço para a manutenção da carga. Quem não planeja isso vive a ilusão de que terminou no dia em que o primeiro dashboard ficou pronto.

Perguntas frequentes

Data warehouse é um banco de dados?

Tecnicamente sim, mas com finalidade diferente. Um banco de dados operacional é otimizado para gravar transações rápido; o data warehouse é otimizado para ler grandes volumes e cruzar dimensões. A tecnologia pode até ser parecida, a modelagem e o padrão de uso não são.

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

O warehouse organiza o dado antes de guardar, o lake guarda primeiro e organiza depois. Na prática, o warehouse entrega resposta mais rápido para quem é de negócio, e o lake oferece flexibilidade maior para quem é de engenharia. Empresas médias costumam se dar melhor começando pelo warehouse.

Pequena empresa precisa de data warehouse?

Na maioria dos casos, não de imediato. Enquanto a operação cabe em duas ou três fontes e uma pessoa consegue consolidar em um dia, a planilha ou um banco simples com BI dão conta. O ponto de virada costuma ser quando o tempo gasto consolidando passa a ser recorrente e as versões começam a divergir.

Quanto tempo leva para implementar um data warehouse?

Com escopo enxuto (duas fontes e uma pergunta de negócio clara), de quatro a oito semanas até o primeiro resultado utilizável. Projetos que prometem centralizar tudo de uma vez costumam passar de seis meses e perder o patrocínio antes de entregar.

Preciso de um profissional de dados para manter o data warehouse?

Alguém precisa ser responsável pela carga, nem que seja em tempo parcial. Ferramentas gerenciadas reduzem bastante o trabalho de infraestrutura, mas mudanças nas fontes continuam quebrando rotinas. Sem responsável definido, a base envelhece e perde a confiança do time.

A decisão que importa não é técnica

A pergunta que vale fazer não é "qual data warehouse escolher", e sim "qual decisão a gente vem tomando no escuro e quanto isso está custando". Se a resposta for uma reunião mensal em que cada área traz um número diferente, a estrutura se paga rápido. Se for uma curiosidade de dashboard, é caro demais para o retorno.

Centralizar dado só entrega valor quando as pessoas conseguem perguntar a ele. É exatamente essa a lacuna que o Sherlok cobre: conectar as fontes que você já tem (anúncios, CRM, planilhas, banco SQL) e deixar qualquer pessoa da equipe perguntar em português, recebendo a análise pronta em vez de uma fila de pedidos para o time técnico. Vale como primeiro passo, inclusive para descobrir quais perguntas justificam um warehouse depois.