Data warehouse e pipelines de dados: do banco transacional ao analytics
Todo SaaS chega ao dia em que alguém pergunta: "quanto crescemos por segmento no último trimestre, cruzando plano, região e canal de aquisição?". E a engenharia descobre, com desconforto, que responder isso rodando queries direto no banco de produção é uma péssima ideia. A consulta analítica varre milhões de linhas, pesa sobre o banco que atende os usuários e ainda por cima é lenta, porque aquele banco foi desenhado para outra coisa. O banco que registra as transações do dia a dia não é o banco certo para analisar o negócio. Essa separação é o ponto de partida de toda a engenharia de dados.
Este guia percorre o caminho do dado transacional até o analítico: por que OLTP e OLAP são mundos diferentes, o que é um data warehouse, como os dados chegam lá por pipelines, e como garantir que o que sai dali seja confiável. O foco é analytics, um território distinto da busca textual e da otimização do banco transacional.
OLTP e OLAP: dois mundos, dois bancos
A raiz de tudo é entender que existem dois perfis de uso de dados, com necessidades opostas.
O OLTP (Online Transaction Processing) é o mundo do banco de produção. Ele lida com muitas transações pequenas e rápidas: criar um pedido, atualizar um cadastro, registrar um pagamento. É otimizado para escrever e ler poucos registros por vez, com integridade e baixa latência. É o coração operacional do sistema.
O OLAP (Online Analytical Processing) é o mundo da análise. Ele lida com poucas consultas, porém enormes, que varrem milhões de linhas para agregar, agrupar e cruzar dados. Responder "faturamento por mês por região nos últimos dois anos" é OLAP. Esse perfil exige uma estrutura de dados completamente diferente, otimizada para leitura em massa e agregação, não para escrita transacional.
| Característica | OLTP (transacional) | OLAP (analítico) |
|---|---|---|
| Propósito | Operar o negócio | Analisar o negócio |
| Operações | Muitas, pequenas, rápidas | Poucas, grandes, pesadas |
| Otimizado para | Escrita e leitura pontual | Leitura e agregação em massa |
| Modelagem | Normalizada | Dimensional (fatos e dimensões) |
| Exemplo | Registrar um pedido | Faturamento por região por trimestre |
Forçar cargas OLAP no banco OLTP é o erro que degrada a produção. A solução é levar os dados para um lugar próprio.
O data warehouse: a casa do analytics
O data warehouse é um banco de dados desenhado para análise, separado do banco de produção. Para lá vão cópias dos dados de todas as fontes do negócio (o banco transacional, ferramentas de terceiros, logs, planilhas), consolidadas em um único lugar otimizado para consultas analíticas pesadas.
O warehouse traz três ganhos essenciais:
- Não pesa sobre a produção. As consultas analíticas rodam nele, deixando o banco operacional livre para atender usuários.
- Consolida fontes. Dados de vários sistemas se juntam em um lugar só, permitindo cruzamentos que nenhuma fonte isolada faria.
- É rápido para agregar. Sua estrutura interna (frequentemente colunar) é feita para somar e agrupar milhões de linhas com eficiência.
Warehouses modernos, na nuvem, escalam o armazenamento e o processamento de forma elástica, cobrando pelo que se consulta. Mas o warehouse é só o destino; o desafio é levar os dados até ele.
Como os dados chegam lá: ETL e ELT
Mover dados das fontes para o warehouse é trabalho de um pipeline de dados, e há duas filosofias para isso, distintas pela ordem das etapas.
O ETL (Extract, Transform, Load) é a abordagem clássica: você extrai os dados da fonte, transforma (limpa, formata, agrega) em um passo intermediário, e só então carrega o resultado já pronto no warehouse. A transformação acontece antes de chegar ao destino.
O ELT (Extract, Load, Transform) inverte a ordem, aproveitando o poder dos warehouses modernos: você extrai e carrega os dados brutos primeiro, e faz a transformação depois, dentro do próprio warehouse, usando a potência dele para processar. É a abordagem que ganhou força na nuvem, porque separa a ingestão da transformação e permite reprocessar os dados brutos quantas vezes quiser.
- ETL brilha quando a transformação é pesada e você quer só o dado limpo no destino, ou quando há restrições de conformidade sobre o que pode ser armazenado.
- ELT brilha na nuvem, com warehouses potentes e baratos, onde guardar o bruto e transformar sob demanda dá flexibilidade e reprocessamento fácil.
Modelagem dimensional: fatos e dimensões
Dentro do warehouse, os dados não ficam na estrutura normalizada do banco transacional. Usa-se a modelagem dimensional, desenhada para análise, organizada em torno de dois tipos de tabela.
As tabelas fato guardam os eventos mensuráveis do negócio, os números que você quer somar: uma venda, com seu valor e quantidade. Cada linha é um fato ocorrido. As tabelas dimensão guardam o contexto que descreve esses fatos: quem, o quê, quando, onde. A dimensão de cliente, de produto, de tempo, de região.
O padrão clássico é o esquema estrela (star schema): uma tabela fato no centro, cercada pelas dimensões. Para responder "vendas por região por mês", você cruza a fato de vendas com as dimensões de região e de tempo. Essa organização torna as consultas analíticas simples de escrever e rápidas de executar, exatamente o oposto do que seria cruzar dezenas de tabelas normalizadas.
Orquestração: pipelines que rodam sozinhos
Um pipeline de dados não é uma tarefa única; é um fluxo de passos que roda de forma recorrente (a cada hora, todo dia de madrugada) e no qual cada passo depende do anterior. Extrair antes de transformar, transformar antes de carregar. Coordenar isso é papel de um orquestrador de pipelines, que agenda a execução, respeita as dependências entre passos, repete o que falha e alerta quando algo quebra.
Sem orquestração, os pipelines viram scripts soltos que alguém roda na mão e que falham silenciosamente. Com ela, o fluxo de dados é confiável, observável e recuperável, com visibilidade de qual passo rodou, qual falhou e onde retomar.
Qualidade de dados: lixo entra, lixo sai
De nada adianta um warehouse elegante se os dados que chegam nele estão errados. Qualidade de dados é o cuidado que separa um analytics em que o negócio confia de um que ninguém acredita. Decisões tomadas sobre dados ruins são piores que decisões tomadas sem dado nenhum, porque vêm com falsa confiança.
Pilares de qualidade em um pipeline sério:
- Validação na entrada: checar que os dados extraídos têm o formato, o tipo e as faixas esperadas antes de processá-los.
- Testes de dados: afirmações automáticas de que uma coluna não é nula, de que um total bate, de que não há duplicatas onde não deveria.
- Detecção de anomalias: alertar quando um número foge do padrão histórico, como um volume que despenca ou explode sem explicação.
- Rastreabilidade (lineage): saber de onde cada número veio, por quais transformações passou, para investigar quando algo parece errado.
Do dado bruto à decisão confiável
Transformar o banco transacional em analytics é uma jornada de engenharia: separar OLTP de OLAP, montar um data warehouse, construir pipelines de ETL ou ELT, modelar em fatos e dimensões, orquestrar a execução e garantir a qualidade em cada etapa. Cada peça existe para que uma pergunta de negócio receba uma resposta rápida, correta e confiável, sem pesar sobre a produção nem depender de alguém rodando consultas na mão. Dados são um dos ativos mais valiosos de um SaaS, e é a disciplina desse caminho que os transforma de um subproduto da operação em uma vantagem real para decidir.
Suas análises rodam no banco de produção e ninguém confia nos números? Na ConstructorTI, desenhamos a jornada de dados do transacional ao analytics, com data warehouse, pipelines de ETL ou ELT, modelagem dimensional e testes de qualidade. Se responder uma pergunta de negócio hoje é lento, arriscado ou pouco confiável, fale com a nossa engenharia e receba um diagnóstico da sua arquitetura de dados.