Data warehouse para empresa média: por onde começar

Reunião de resultados do mês. O financeiro traz um faturamento, o comercial traz outro, e o e-commerce tem um terceiro número que ninguém consegue explicar. Os primeiros vinte minutos vão embora descobrindo qual planilha está certa, e a decisão que motivou a reunião fica para a semana que vem.

Esse é o problema que um data warehouse resolve. E não é projeto só de grande corporação, com equipe de dados dedicada e um ano de implantação. Com serviços gerenciados de nuvem, uma empresa média consegue ter uma base analítica enxuta e confiável, desde que comece pelo lugar certo e não copie a arquitetura de quem tem cem vezes o seu volume.

Quando relatórios direto do ERP deixam de bastar

Enquanto a empresa tem um sistema só e poucas perguntas, o relatório do ERP resolve. Os sinais de que esse tempo acabou:

As perguntas cruzam sistemas. Margem por canal exige o pedido do e-commerce, o custo do ERP e o frete da transportadora. Nenhum sistema tem as três coisas.

Alguém passa dias montando o fechamento. Exporta do ERP, exporta do CRM, cola na planilha, corrige os códigos que não batem. Todo mês, do zero, e o conhecimento de como fazer isso mora numa pessoa.

Consultas pesadas deixam o sistema lento. Um relatório de três anos de vendas no banco de produção compete com quem está faturando pedido agora.

O histórico se perde. O ERP guarda o estado atual. Se o vendedor mudou de região, as vendas antigas dele "mudam" junto, e comparar com o ano passado perde sentido.

Cada área tem sua versão da verdade. Não por má-fé, mas porque cada uma aplica um filtro diferente: com ou sem devolução, com ou sem frete, por data do pedido ou da nota.

Quando não vale: se a empresa tem um sistema principal, poucas fontes e as perguntas cabem nos relatórios dele, um data warehouse é infraestrutura antes da hora. O mesmo vale se os cadastros de origem estão tão bagunçados que qualquer cruzamento vai sair errado: aí o primeiro projeto é arrumar a origem. E, se a necessidade é só uma tela de indicadores em cima de uma fonte, vale ler antes quando usar dashboard sob medida ou Power BI.

Arquitetura enxuta: bruto, modelado e métricas

A arquitetura que funciona para empresa média tem poucas peças, cada uma com uma responsabilidade clara:

1. Extração. Rotinas que copiam os dados das fontes (ERP, CRM, e-commerce, gateway de pagamento, planilhas que ainda são oficiais) para dentro do warehouse, em horários definidos.
2. Camada bruta. Os dados chegam exatamente como vieram da origem, sem tratamento. Parece desperdício, mas é o que permite reprocessar tudo quando uma regra muda, sem precisar extrair de novo.
3. Camada modelada. Tabelas limpas, com códigos padronizados, clientes deduplicados e nomes que o negócio entende. É aqui que "pedido do e-commerce" e "pedido do ERP" viram uma coisa só.
4. Camada de métricas. As definições oficiais de faturamento, margem, ticket médio, churn, giro de estoque. Uma vez, num lugar só.

Em cima disso ficam os consumidores: BI, dashboards, planilhas conectadas e, mais adiante, modelos analíticos.

Um ponto importante: toda transformação é código versionado. A regra que tira devoluções do faturamento não fica escondida numa fórmula de planilha ou numa medida perdida dentro do BI. Fica num arquivo SQL, com histórico de quem mudou e por quê. Ferramentas como o dbt popularizaram esse jeito de trabalhar, mas o princípio vale com qualquer ferramenta.

Extração: conectores prontos ou pipelines próprios

Trazer os dados é a parte que mais consome esforço no começo, e existem dois caminhos, que normalmente convivem.

Conectores prontos. Serviços como Fivetran e Airbyte, ou os conectores nativos das nuvens, já sabem ler muitos sistemas conhecidos: CRMs de mercado, plataformas de e-commerce, bancos de dados. Você configura credenciais e frequência, e a cópia acontece. Faz sentido quando a fonte é um produto popular e o conector está maduro.

Pipelines próprios. Necessários quando a fonte é um ERP brasileiro com API específica, um sistema interno, um banco legado sem API ou um arquivo que chega por e-mail. Aqui entram os mesmos cuidados de qualquer integração: paginação, limites de requisição, reprocessamento, tratamento de falha. Se a origem é o ERP, os detalhes de como conversar com ele sem travar a operação estão em como integrar seu sistema com o ERP.

Decisões que valem para os dois caminhos:

• Carga incremental sempre que der. Trazer só o que mudou desde a última execução, por data de alteração ou por captura de mudanças no banco, em vez de copiar a base inteira toda noite.
• Frequência pelo uso, não pelo desejo. A maior parte das decisões gerenciais vive bem com dado de ontem. Atualização a cada poucos minutos custa mais e só se justifica quando alguém realmente age sobre ela no mesmo dia.
• Ler de réplica, não de produção. Quando a extração é direto do banco, uma réplica de leitura evita que a carga pese no sistema que está atendendo clientes.
• Credenciais só de leitura. O processo de extração nunca precisa gravar na origem.

Modelagem que o time de negócio consegue entender

A camada modelada é onde o projeto ganha ou perde a confiança das pessoas. O modelo clássico, e ainda o mais útil para empresa média, é o dimensional, com fatos e dimensões.

Fatos são os eventos que você mede: venda, item de pedido, pagamento, movimentação de estoque, chamado de suporte. Cada linha é uma ocorrência, com números (quantidade, valor, custo) e referências.

Dimensões são o contexto para cortar esses números: cliente, produto, vendedor, filial, canal, data.

Na prática, isso vira tabelas como "vendas por item", "clientes" e "produtos", com nomes do negócio. Quem abre o BI deve encontrar "data de faturamento", não um código de três letras.

Dois cuidados fazem diferença:

Histórico das dimensões. Se o cliente mudou de segmento ou o produto mudou de categoria, você precisa decidir se as vendas antigas acompanham a mudança ou ficam com a classificação da época. Guardar versões com data de início e fim (a chamada dimensão de mudança lenta) resolve, mas é decisão de negócio, não técnica.

Chaves de identidade entre sistemas. O mesmo cliente tem um código no ERP, outro no CRM e um e-mail no e-commerce. Definir como eles se casam (CNPJ, CPF, e-mail ou uma tabela de correspondência) aparece em todo projeto e costuma ser subestimado.

Uma definição única de cada métrica

Voltando à reunião do começo: os três números de faturamento provavelmente estavam todos "certos", cada um com uma regra diferente. O warehouse só resolve isso se as regras forem escritas e aceitas.

Para cada métrica importante, registre:

Esse glossário não é documento de gaveta: ele é implementado na camada de métricas, e o BI consome o resultado pronto. Quando o financeiro decide que frete sai da receita, muda um lugar e todos os relatórios acompanham.

O ganho político é tão grande quanto o técnico: a discussão sobre qual número está certo acontece uma vez, não em toda reunião.

Qualidade de dados e alertas de carga quebrada

O pior cenário não é a carga falhar. É falhar em silêncio e o dashboard continuar mostrando números com cara de normal, enquanto a diretoria decide sobre dado de três dias atrás.

O que precisa existir desde o primeiro mês:

• Monitor de atualização. Cada tabela sabe quando foi carregada pela última vez; se passou do horário esperado, alguém recebe um alerta, e o próprio dashboard exibe "dados atualizados até" de forma visível.
• Testes nos modelos. Chave primária sem duplicidade, campos obrigatórios preenchidos, códigos que existem na dimensão correspondente, valores dentro de uma faixa plausível.
• Reconciliação com a origem. Uma conferência periódica que compara totais do warehouse com o relatório oficial do ERP para o mesmo período. Se o faturamento do mês diverge, o problema aparece antes do fechamento.
• Detecção de volume anormal. Uma carga que trouxe metade das linhas de um dia comum provavelmente quebrou, mesmo que não tenha dado erro.

Governança também inclui acesso. O warehouse concentra dados de clientes, e a LGPD (Lei 13.709/2018) continua valendo ali: coletar só o que a análise precisa, restringir quem vê dados pessoais, mascarar ou pseudonimizar onde o nome não é necessário e registrar quem consultou o quê. Muitas análises funcionam perfeitamente sem CPF e telefone na mesma tabela.

Escolhendo o banco analítico e controlando o consumo

Três opções cobrem a maior parte dos casos de empresa média:

BigQuery (Google Cloud). Totalmente gerenciado, sem servidor para dimensionar. No modelo sob demanda, a cobrança acompanha o volume de dados lido pelas consultas, o que é ótimo para uso esporádico e perigoso quando alguém agenda uma consulta mal escrita a cada poucos minutos.

Amazon Redshift (AWS). Faz sentido quando o resto da infraestrutura já está na AWS. A versão serverless dispensa gerenciar cluster e cobra pela capacidade de processamento usada; a versão provisionada dá previsibilidade para uso constante.

PostgreSQL. Para volumes moderados, um PostgreSQL gerenciado bem modelado, com índices e tabelas agregadas, atende com folga e custo previsível. É ponto de partida legítimo, e migrar para um banco colunar depois é viável se os modelos estiverem em código.

Um resumo para orientar a escolha:

Independentemente do banco, o consumo se controla com hábitos:

• Particionar tabelas grandes por data e filtrar por partição, para a consulta ler só o período necessário.
• Evitar "selecionar todas as colunas" em bancos colunares, onde cada coluna lida conta.
• Materializar agregados que os dashboards consultam o tempo todo, em vez de recalcular a partir do detalhe a cada clique.
• Definir limites e alertas de gasto no próprio provedor, por projeto ou por usuário.

Esses cuidados são parte de uma disciplina maior de custo em nuvem, que detalhamos em como reduzir a conta de nuvem sem perder estabilidade. A infraestrutura como um todo (ambientes, permissões, pipelines de deploy dos modelos, monitoramento) é o tipo de trabalho que fazemos em cloud e DevOps.

Os erros mais comuns

Começar pela ferramenta. Escolher banco e BI antes de saber quais perguntas precisam de resposta gera uma infraestrutura bonita e vazia.

Trazer tudo de todos os sistemas. Cada fonte tem custo de manutenção. Comece pelas que respondem às perguntas prioritárias.

Deixar a regra de negócio no BI. Cada relatório recalculando margem do seu jeito recria o problema das planilhas, agora com gráficos.

Não ter dono. Sem alguém responsável por responder "esse número está certo?", a confiança se desfaz na primeira divergência.

Por onde começar, passo a passo

As fases são sempre as mesmas; a duração de cada uma é definida depois do diagnóstico.

1. Diagnóstico. Liste as cinco a dez perguntas que a diretoria mais faz e hoje demoram para ser respondidas. Mapeie de quais sistemas vêm os dados de cada uma e como eles se integram.
2. Glossário inicial. Escreva as definições das métricas envolvidas, com dono de cada uma. Resolva as divergências antes de escrever código.
3. Primeira entrega enxuta. Uma ou duas fontes, camada bruta, modelo de um assunto (vendas, normalmente) e um painel usado de verdade numa reunião real.
4. Qualidade e alertas. Testes, monitor de atualização e reconciliação com a origem antes de ampliar o escopo.
5. Evolução. Novas fontes e assuntos (estoque, financeiro, atendimento), sempre com o mesmo padrão. Com histórico limpo acumulado, abre-se espaço para análises mais avançadas, como a previsão de demanda com machine learning.

Para saber se deu certo, observe: o fechamento mensal ficou mais rápido? As reuniões pararam de discutir qual número está certo? As áreas consultam o painel sem pedir extração manual? Os alertas avisam antes de alguém notar dado desatualizado?

Como a Pervian Tech monta essa base

Construímos data warehouses sob medida para o tamanho real da empresa, começando pelas perguntas que o negócio precisa responder, não pela ferramenta da moda. Escolhemos entre BigQuery, Redshift ou PostgreSQL conforme as fontes, o volume e onde sua infraestrutura já está, e deixamos extração, modelos, métricas e alertas em código versionado, em contas que pertencem à sua empresa.

O investimento é definido sob consulta, depois de entender quantas fontes existem, como elas se integram e quais métricas precisam de acordo. Se os números da sua empresa ainda dependem de quem montou a planilha, conte quais perguntas você quer responder e mostramos por onde começaríamos.