Um data warehouse é um banco de dados construído para responder perguntas, e não para operar o negócio. Ele reúne, em um lugar só, informação que hoje vive espalhada entre o ERP, o CRM, a ferramenta de atendimento e as planilhas, organizada de um jeito que permite cruzar tudo sem travar nenhum sistema.

A pergunta que interessa não é o que ele é, e sim quando a empresa precisa de um. Este texto mostra os sinais que indicam a hora, as três alternativas mais baratas que resolvem antes, o que custa manter um, e como começar pequeno sem construir um projeto de dois anos que ninguém usa.

O que ele é, em linguagem de negócio

Todo sistema que a empresa usa guarda dados no formato que serve a ele. O ERP guarda de um jeito que torna rápido emitir uma nota; o CRM, de um jeito que torna rápido abrir a ficha de um cliente. Nenhum dos dois foi feito para responder “quanto o cliente que veio daquele canal comprou nos últimos dois anos, e qual foi a margem”.

O data warehouse é a cópia organizada para essa segunda pergunta. Ele recebe os dados dos sistemas de origem, padroniza nomes e formatos, guarda o histórico e fica disponível para relatórios e painéis. Três consequências práticas: o relatório pesado deixa de derrubar o sistema de produção, o histórico não se perde quando o sistema é trocado, e passa a existir uma versão única de cada número.

As três alternativas mais baratas

Antes do warehouse existem três caminhos que resolvem muita coisa e custam uma fração.

Caminho Resolve Onde para
Relatório dentro do próprio sistema Perguntas sobre uma única fonte No momento em que é preciso cruzar duas fontes
Painel conectado direto ao banco do sistema Visão em tempo quase real, sem projeto Quando a consulta pesada começa a atrapalhar a operação
Planilha consolidada com atualização automática Cruzamento simples, com pouco volume Quando o volume cresce ou a regra vira um emaranhado

Onde essa decisão se encaixa no caminho maior da empresa, da planilha à decisão instrumentada, está em business intelligence para empresas: o warehouse é a peça do terceiro estágio, e chegar nele cedo demais é a causa mais comum de projeto de dados que não entrega.

A segunda opção é subestimada e resolve a maior parte das empresas pequenas por bastante tempo. O caminho de sair da planilha sem partir para um projeto grande está em da planilha ao dashboard, e a comparação das ferramentas de visualização, em Looker Studio, Power BI e Metabase.

Os sinais de que chegou a hora

  • Toda pergunta interessante cruza dois ou mais sistemas. É o sinal mais forte de todos.
  • O relatório pesado atrapalha a operação. Quando o fechamento deixa o sistema lento, a consulta precisa sair de lá.
  • O mesmo número tem três versões. Cada área calcula do seu jeito, e a reunião discute o dado em vez do negócio.
  • Alguém monta o relatório à mão todo mês. Exportar, colar, ajustar e enviar é um processo que se paga rápido de eliminar.
  • Você quer olhar o histórico e ele não existe. Sistema de operação costuma sobrescrever o passado.
  • Trocar de sistema significaria perder o histórico. É o argumento que menos aparece e mais importa.

Um sinal isolado não justifica o projeto. Três ou mais indicam que o custo do improviso já superou o custo da estrutura. A leitura de fundo, sobre por que o dado existe e mesmo assim não vira decisão, está em por que empresas não usam os próprios dados.

Lago, warehouse e a sopa de nomes

Quatro palavras aparecem na mesma conversa e confundem a decisão. Vale separá-las em uma frase cada.

  • Data warehouse é o dado já organizado e padronizado para responder perguntas de negócio.
  • Data lake é o depósito do dado bruto, como ele veio, inclusive o que ainda não se sabe se será usado. Resolve volume e variedade, e não entrega resposta sozinho.
  • Data mart é um recorte do warehouse para uma área específica, como comercial ou financeiro.
  • ETL é o processo que move o dado de um lugar para outro, limpando e padronizando no caminho.

Para a maior parte das empresas brasileiras de porte médio, a resposta certa é warehouse, e a conversa sobre lago costuma ser prematura. Lago faz sentido quando existe volume muito grande de dado não estruturado, como texto, imagem ou registro de sensor, e alguém com capacidade de trabalhar com isso. Sem essas duas condições, o lago vira um depósito caro que ninguém consulta.

O que custa ter um

O custo de um data warehouse tem três partes, e a primeira é a menor.

A infraestrutura ficou barata: serviços de nuvem cobram por armazenamento e por consulta, e o volume de uma empresa média custa pouco por mês. A construção é o levantamento das fontes, a definição das regras de padronização e a montagem das cargas, e é aqui que mora a maior parte do investimento inicial. A manutenção é contínua: cada mudança em um sistema de origem exige ajuste na carga, e isso acontece algumas vezes por ano.

Existe ainda um custo que não aparece em proposta: o acordo sobre as definições. Decidir o que conta como cliente ativo, o que entra na receita e a partir de quando um pedido é considerado faturado é trabalho de negócio, não de tecnologia, e é o que mais atrasa esse tipo de projeto. É o mesmo problema de propriedade tratado em governança de dados.

Como começar pequeno

O caminho que funciona começa por uma pergunta de negócio, não pelo desenho do modelo de dados.

  • Escolha uma decisão recorrente. Algo que a empresa decide toda semana e hoje decide no escuro.
  • Traga só as fontes necessárias para ela. Duas costumam bastar. Trazer tudo é o começo do projeto de dois anos.
  • Defina os termos por escrito. Cliente ativo, receita, período. Uma página resolve e evita meses de discussão.
  • Entregue um painel em semanas, não em meses. Se ninguém usar, o problema estava na pergunta, e você descobriu barato.
  • Só então acrescente a segunda pergunta. A estrutura cresce por uso, e não por planejamento.

O passo técnico que costuma ser subestimado é a carga: trazer dado de sistema fechado depende do que ele permite, e isso é assunto de integração de sistemas. Quando a pergunta de negócio é comercial, o conjunto de indicadores que costuma vir primeiro está em dashboard de vendas.

Os erros que fazem o projeto morrer

  • Começar pelo modelo completo. Modelar a empresa inteira antes de entregar valor é a forma clássica de gastar um ano sem um painel no ar.
  • Tratar como projeto de tecnologia. Sem alguém do negócio dono das definições, o resultado é tecnicamente correto e inútil.
  • Copiar o dado sem limpar. Warehouse com dado sujo entrega erro mais rápido e com mais autoridade.
  • Não monitorar a carga. Quando ela falha em silêncio, o painel mostra número velho com cara de atual.
  • Esquecer quem vai usar. Estrutura sem painel e sem rotina de leitura é custo puro.

A leitura mais ampla sobre extrair decisão de dado em empresa pequena está em inteligência de dados para pequenas empresas, e a versão executiva do que olhar depois de pronto, em dashboard executivo. Se a origem da dor for relatório manual, o atalho mais barato continua sendo automatizar relatórios sem contratar ninguém. E se a estrutura de dados existir para sustentar um produto digital, o recorte de escopo está em como definir o escopo.

Perguntas frequentes

O que é um data warehouse?

É um banco de dados construído para responder perguntas, e não para operar o negócio. Ele reúne em um lugar só a informação que vive espalhada entre ERP, CRM, ferramenta de atendimento e planilhas, padroniza nomes e formatos e guarda o histórico. Isso permite cruzar informação de várias fontes sem travar nenhum dos sistemas de origem.

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

O warehouse guarda o dado já organizado e padronizado para responder perguntas de negócio. O lake guarda o dado bruto como ele veio, inclusive o que ainda não se sabe se será usado. O lake resolve volume e variedade e não entrega resposta sozinho, fazendo sentido quando existe muito dado não estruturado e gente capaz de trabalhar com ele.

Quando a empresa precisa de um data warehouse?

Quando aparecem três ou mais destes sinais: toda pergunta interessante cruza dois ou mais sistemas, o relatório pesado deixa a operação lenta, o mesmo número tem versões diferentes por área, alguém monta relatório à mão todo mês, o histórico não existe porque o sistema sobrescreve o passado, e trocar de sistema significaria perder o que já aconteceu.

O que dá para fazer antes de construir um data warehouse?

Três coisas mais baratas. Relatório dentro do próprio sistema, que resolve perguntas de uma fonte só. Painel conectado direto ao banco do sistema, que dá visão quase em tempo real sem projeto e para quando a consulta pesada atrapalha a operação. E planilha consolidada com atualização automática, que funciona com pouco volume e regra simples.

Quanto custa manter um data warehouse?

A infraestrutura em nuvem costuma custar pouco por mês para o volume de uma empresa média, cobrada por armazenamento e consulta. O peso está na construção, que é levantar fontes, definir padronização e montar as cargas, e na manutenção contínua, já que cada mudança em um sistema de origem exige ajustar a carga algumas vezes por ano.

Quanto tempo leva para ter o primeiro resultado?

Semanas, se o projeto começar por uma pergunta de negócio e trouxer só as fontes necessárias para respondê-la. Meses ou anos, se começar pelo desenho do modelo completo da empresa. A diferença não é técnica: é de sequência, e é a principal causa de projeto de dados que nunca entrega painel nenhum.

Data warehouse é a mesma coisa que ETL?

Não. O ETL é o processo que move o dado dos sistemas de origem para o warehouse, limpando e padronizando no caminho. O warehouse é o destino. Um depende do outro: sem carga confiável e monitorada, o warehouse mostra número velho com aparência de atual, o que é pior que não mostrar nada.

Preciso de um data warehouse para ter dashboards?

Não necessariamente. Dashboards de uma fonte só funcionam bem conectados diretamente ao sistema de origem. O warehouse passa a ser necessário quando as perguntas cruzam fontes, quando a consulta começa a pesar sobre a operação ou quando é preciso comparar períodos que o sistema de origem não guarda.

Qual o maior risco de um projeto de data warehouse?

Tratá-lo como projeto de tecnologia. Sem alguém do negócio responsável pelas definições, como o que conta como cliente ativo ou a partir de quando um pedido é receita, o resultado fica tecnicamente correto e inútil. Esse acordo sobre definições é o que mais atrasa esse tipo de trabalho, e não aparece em nenhuma proposta.

Empresa pequena precisa de data warehouse?

Em geral não, e é honesto dizer isso. Painel conectado ao sistema e planilha consolidada resolvem por bastante tempo. A estrutura passa a compensar quando o improviso já custa horas todo mês, quando o dado começa a ser assunto de discussão entre áreas ou quando o histórico vira ativo que a empresa não pode perder.