Data Warehouse

Toda empresa acumula dados em sistemas operacionais: o ERP registra pedidos e estoque, o CRM registra interações com clientes, a plataforma de e-commerce registra sessões e conversões, o sistema financeiro registra receitas e despesas. Cada sistema é otimizado para o que faz — transações rápidas, consistência, operação do dia a dia. Nenhum deles foi construído para responder perguntas como "qual foi a margem por categoria de produto nos últimos 18 meses, segmentada por região e comparada ao ano anterior?"

Data Warehouse (DW) é um repositório analítico centralizado, projetado especificamente para suportar consultas de business intelligence e análise histórica. Enquanto bancos de dados operacionais (OLTP — Online Transaction Processing) são otimizados para escrita rápida de muitas transações pequenas, o data warehouse é otimizado para leitura analítica de grandes volumes — agregações, filtros complexos, joins entre múltiplas dimensões, análise histórica que pode cobrir anos.

A distinção não é apenas técnica. É de propósito: sistemas operacionais guardam o estado atual do negócio; o data warehouse guarda o histórico analítico que permite entender como o negócio evoluiu e por quê.

Entender o data warehouse exige entender a diferença de otimização entre os dois paradigmas.

OLTP (Online Transaction Processing): banco de dados operacional. Escritas frequentes e concorrentes; transações atômicas (todo ou nada); schema normalizado (evita duplicação de dados, garante consistência); otimizado para encontrar e modificar registros individuais rapidamente. PostgreSQL, MySQL, SQL Server em modo transacional.

OLAP (Online Analytical Processing): banco de dados analítico. Leituras predominantemente; queries complexas em grandes volumes; schema desnormalizado (estrela ou floco de neve — prioriza velocidade de leitura sobre espaço); armazenamento colunar (agrupa valores da mesma coluna juntos no disco — permite ler apenas as colunas relevantes para uma query, dramática melhora para análises que não usam todas as colunas).

Um banco operacional com milhões de pedidos vai ser lento para calcular "total de receita por mês dos últimos 3 anos por categoria" porque precisaria varrer a tabela inteira. Um data warehouse com a mesma informação responde em segundos porque os dados estão organizados para isso — pré-agregados, particionados por data, armazenados em formato colunar.

Camadas de dados:

• Staging: área de entrada bruta. Dados extraídos dos sistemas de origem chegam aqui sem transformação — cópia fiel. Serve como buffer e permite reprojetar transformações sem re-extrair dados das origens.
• Raw/Core: dados limpos e estruturados, mas próximos da granularidade original. Mantém histórico completo. Fonte de verdade analítica.
• Marts (Data Marts): visões analíticas especializadas para domínios específicos (marketing, financeiro, logística). Schema em estrela — tabela fato central com dimensões desnormalizadas ao redor. Otimizadas para as queries frequentes de cada área.

Schema estrela (Star Schema): o padrão mais comum em data marts. Uma tabela de fatos no centro (vendas, pedidos, eventos) com colunas de métricas numéricas (valor, quantidade, duração) e chaves estrangeiras para tabelas de dimensão ao redor (produto, cliente, data, loja). Queries simples, performance de leitura alta, intuitivo para analistas de BI.

Schema floco de neve (Snowflake Schema): variação onde dimensões são normalizadas — dimensão Produto referencia tabela Categoria que referencia tabela Departamento. Reduz redundância, mas adiciona joins. Menos comum em produção por ser mais complexo para analistas.

Dados não chegam prontos no data warehouse. O processo de mover dados dos sistemas de origem para o DW envolve:

ETL (Extract, Transform, Load): extrair dados da origem, transformar (limpar, padronizar, consolidar, calcular campos derivados) e então carregar no destino. Transformação acontece antes de chegar ao DW. Abordagem clássica, necessária quando o volume de transformação é alto ou quando a origem não deve receber carga de processamento.

ELT (Extract, Load, Transform): extrair e carregar dados brutos no DW primeiro, transformar dentro do warehouse usando sua capacidade computacional. Abordagem moderna favorecida por cloud DWs que têm poder computacional elástico. Ferramentas como dbt (data build tool) gerenciam as transformações SQL como código versionado.

Ferramentas de integração: Fivetran, Airbyte, Stitch — conectores pré-construídos para extrair dados de centenas de sistemas (Salesforce, HubSpot, Shopify, bancos de dados, APIs) e carregá-los no DW. Reduzem dramaticamente o tempo de integração de novas fontes.

BigQuery (Google Cloud): serverless — sem clusters para gerenciar, cobrança por query. Escala automática, SQL padrão, integração nativa com ecossistema Google (Looker, Vertex AI). Excelente para workloads variáveis. Separação de storage (barato) e computação (pago por uso).

Snowflake: cloud-agnostic (AWS, GCP, Azure). Separação de storage e compute com múltiplos warehouses (clusters de computação) independentes — diferentes times podem ter seu próprio warehouse sem contender pelos mesmos recursos. Compartilhamento de dados entre organizações é diferencial único. Pricing por créditos de computação.

Amazon Redshift: DW da AWS. Cluster-based (precisa dimensionar), mas Redshift Serverless elimina isso. Integração profunda com ecossistema AWS (S3, Glue, SageMaker). Performance competitiva com uso de compressão e distribuição colunar.

Azure Synapse Analytics: DW da Microsoft, integrado com Power BI e Azure ML. Combina DW tradicional com Spark para Big Data. Favorecido por organizações Microsoft-first.

DuckDB: DW analítico embarcado — roda em processo local, sem servidor. Ideal para análise exploratória de arquivos Parquet, análise de datasets de tamanho médio em máquinas locais. Não substitui cloud DWs em produção, mas revolucionou análise ad hoc.

A qualidade do data warehouse depende tanto da modelagem quanto da tecnologia. Modelagem ruim produz DW que é lento, confuso para analistas e difícil de manter.

Tabelas fato: registros de eventos de negócio (vendas, cliques, chamadas, transações). Cada linha é uma ocorrência. Métricas numéricas (valor, quantidade, duração) e chaves para dimensões.

Tabelas dimensão: o contexto dos fatos. Quem, o quê, onde, quando, como. Cliente (nome, segmento, região, canal de aquisição), Produto (nome, categoria, fornecedor, preço de custo), Data (dia, semana, mês, trimestre, ano fiscal), Loja (nome, cidade, estado, formato).

Slowly Changing Dimensions (SCD): dimensões que mudam ao longo do tempo. Cliente muda de segmento; produto muda de categoria; funcionário muda de cargo. Como rastrear o histórico? SCD Tipo 1 (sobrescreve — sem histórico), Tipo 2 (nova linha com período de validade — histórico completo), Tipo 3 (coluna adicional para valor anterior — histórico limitado). A escolha afeta a capacidade de análise histórica.

Data Warehouse é o passo que separa empresas que tomam decisões baseadas em feeling ou em relatórios manuais de Excel das que tomam decisões baseadas em dado atualizado e confiável. É a fundação sobre a qual dashboards, análises e modelos de ML são construídos.

Para PMEs, o ponto de entrada hoje é mais acessível do que nunca. BigQuery tem tier gratuito generoso; Snowflake tem trial de 30 dias; ferramentas como dbt (open source), Fivetran ou Airbyte (com tier gratuito) e Metabase ou Google Looker Studio (gratuito) formam uma stack analítica completa com investimento em tempo, não em licenças de software.

O erro comum é adiar o data warehouse esperando "ter dados suficientes" ou "ter um time de dados". O valor emerge assim que as primeiras fontes estão conectadas e as primeiras perguntas de negócio têm resposta confiável sem depender de alguém extrair manualmente. Começar pequeno e crescer é melhor do que planejar a arquitetura perfeita indefinidamente.