Um data warehouse é um repositório central que reúne dados de vários sistemas da empresa, já limpos e padronizados, para responder perguntas analíticas sobre vendas, clientes, custos e histórico. A tradução literal é “armazém de dados”: o galpão organizado atrás do balcão, com tudo etiquetado e guardado por anos. Neste guia você vê como ele funciona etapa por etapa, o que o separa de data lake e banco transacional, quanto custa manter um, quais plataformas dominam as avaliações em 2026 e quando o projeto não vale a pena. Em 3 de setembro de 2026, o conceito completa 38 anos e ainda define onde a IA corporativa busca dado limpo.
- 77,2% das indústrias brasileiras com 100 ou mais empregados usavam computação em nuvem em 2024, segundo a PINTEC Semestral do IBGE, com 10.167 empresas ouvidas
- 41,9% dessas indústrias usavam inteligência artificial em 2024, contra 16,9% em 2022, no mesmo levantamento do IBGE
- 17% das empresas brasileiras, sem recorte setorial, usavam IA em 2025, conforme a TIC Empresas 2025 do Cetic.br, com 4.174 empresas entrevistadas
- 1988 é o ano da primeira arquitetura de data warehouse publicada, por Barry Devlin e Paul Murphy, na IBM Systems Journal
- Nenhuma das três metodologias de projeto (Inmon, Kimball e Data Vault) é universalmente ideal, conclui a análise comparativa publicada no arXiv em junho de 2026
O que é um data warehouse e para que serve
Um data warehouse é um repositório central que reúne dados de vários sistemas de uma empresa, já limpos e padronizados, para responder perguntas analíticas: o que vendemos, para quem, a que custo e como isso mudou ao longo dos anos. A tradução literal é “armazém de dados”. Warehouse, em inglês, significa armazém ou depósito, o galpão em que se guarda estoque. A analogia ajuda: o sistema de vendas é o balcão da loja, e o data warehouse é o galpão organizado atrás dele, com tudo etiquetado e guardado por anos.
A definição clássica é de Bill Inmon, tido como o pai do conceito. Para ele, um data warehouse é uma coleção de dados com quatro propriedades, e vale decorar as quatro, porque elas explicam quase toda decisão de projeto que vem depois:
- Orientado por assunto: os dados se organizam em torno de temas do negócio (cliente, produto, pedido), em vez de seguir a estrutura das aplicações que os geraram.
- Integrado: informação vinda de sistemas diferentes chega com nomes, formatos e unidades uniformizados. O mesmo cliente aparece uma vez só, com um único código.
- Não volátil: nada é sobrescrito nem apagado. O dado entra, fica e é somente para leitura.
- Variável no tempo: cada registro carrega a data a que se refere, então dá para comparar o estoque de março de 2024 com o de março de 2026.
Um data warehouse é uma coleção de dados “orientada por assunto, integrada, não volátil e variável no tempo”, organizada para dar suporte às decisões da gerência, segundo a definição de Inmon sistematizada pela Universität Hildesheim.
Ralph Kimball, o outro nome que você vai encontrar em qualquer discussão séria sobre o tema, prefere definir pelo que o sistema faz: extrai, limpa, uniformiza e entrega dados de origem em um repositório dimensional, pronto para consulta. As duas visões partem de pontos diferentes e chegam ao mesmo destino, que é apoiar quem decide. A divergência entre elas está na ordem de construção, e ela rende metodologias de projeto distintas até hoje.
O conceito é mais velho do que parece. Em 1988, os pesquisadores Barry Devlin e Paul Murphy, da IBM Europa, publicaram a primeira arquitetura de data warehouse descrita em texto, no volume 27 da IBM Systems Journal: um repositório integrado de dados corporativos sobre banco relacional, com um conjunto consistente de ferramentas para o usuário final. Trinta e oito anos depois, a ideia central continua a mesma.
Para que serve, então? Quatro usos concentram quase tudo:
- Business intelligence: dashboards e painéis que a diretoria abre na segunda-feira de manhã.
- Relatórios recorrentes: fechamento mensal, DRE, indicadores por filial, tudo saindo de uma fonte só.
- Histórico: responder como estava a carteira de clientes há três anos, coisa que o sistema transacional já não sabe, porque sobrescreveu o registro.
- Apoio à decisão: cruzar vendas, estoque e custo de aquisição para decidir onde abrir a próxima loja.
Quem já tentou fechar o DRE juntando extrato do ERP com planilha do comercial sabe exatamente qual dor a característica “integrado” resolve. Os números não batem porque cada sistema conta de um jeito. O warehouse existe para que exista uma versão só.
Como funciona um data warehouse na prática
Na prática, um data warehouse funciona em cinco etapas encadeadas: coleta dados dos sistemas operacionais, transforma esses dados num formato uniforme, guarda tudo num repositório de leitura, separa recortes por área e entrega o resultado em dashboards e relatórios. Cada etapa tem dono, ferramenta e ponto de falha próprios.
Pense numa rede de farmácias. Ela tem o sistema de caixa (PDV) registrando cada cupom, o ERP cuidando de estoque e nota fiscal eletrônica, uma loja virtual com outro cadastro de produtos e um programa de fidelidade com o CPF dos clientes. Quatro fontes, quatro formatos, quatro relógios. O fluxo até o dashboard segue esta ordem:
- Fontes operacionais: PDV, ERP, e-commerce e fidelidade continuam funcionando como sempre, sem saber que existe um warehouse.
- Extração e carga: um processo periódico copia os dados novos. No padrão ETL, ele transforma antes de carregar; no padrão ELT, carrega bruto e transforma dentro do warehouse.
- Warehouse: o repositório central recebe tabelas já integradas, com um único código por produto e por cliente.
- Data marts: recortes menores por assunto, como vendas, compras ou financeiro, para cada área consultar só o que lhe interessa.
- Ferramentas analíticas: dashboards, relatórios agendados e consultas OLAP, que permitem girar a mesma informação por região, categoria e trimestre.
O que ninguém descobre até tentar é que a etapa 2 consome a maior parte do esforço. O mesmo produto tem código diferente no ERP e na loja virtual, o CNPJ vem com máscara num sistema e sem máscara no outro, e a data de venda do PDV está no fuso da loja enquanto a do e-commerce está em UTC. Nada disso é difícil. É só muito, e aparece todo dia.
Por que não consultar direto o banco do PDV? Porque ele é um sistema OLTP (processamento de transações online): feito para milhares de escritas pequenas e rápidas, uma por cupom. Já a pergunta da diretoria (“quanto vendemos de analgésicos por região, por trimestre, nos últimos três anos?”) é uma carga OLAP (processamento analítico online): poucas consultas, cada uma lendo milhões de linhas agregadas. Rodar a segunda em cima do primeiro trava o caixa da loja. Separar os dois ambientes é o motivo de existir do warehouse.
Os exemplos de uso vão bem além do varejo:
- Na saúde, há warehouses montados para apoio à decisão clínica e para acompanhar doenças oncológicas.
- Na agricultura, a arquitetura serve para prever safras a partir de dados estruturados de clima e solo.
- Na indústria brasileira, um estudo de caso publicado na Revista Contabilidade & Finanças mostra business intelligence apoiando a controladoria, e outros trabalhos na SciELO descrevem warehouse com OLAP no chão de fábrica e no controle da produção.
- No setor público, o Banco Central mantém o Sistema Gerenciador de Séries Temporais (SGS), que consolida séries econômico-financeiras de forma uniforme e alimenta parte do Portal de Dados Abertos do BCB.
Qual a diferença entre data warehouse, data lake e banco de dados transacional
A diferença entre data warehouse, data lake e banco de dados transacional está em três eixos: o que cada um guarda, quando o esquema é aplicado e qual carga de trabalho ele atende. O banco transacional registra a operação do momento. O warehouse guarda dados estruturados e históricos, com esquema definido antes da escrita. O data lake guarda dados brutos de qualquer formato, e o esquema só é aplicado na hora da leitura.
| Critério | Banco transacional (OLTP) | Data warehouse | Data lake |
|---|---|---|---|
| Tipo de dado | Estruturado, estado atual | Estruturado, histórico | Bruto: estruturado, semiestruturado e não estruturado |
| Esquema | Definido na escrita, normalizado | Definido na escrita (schema-on-write), dimensional | Aplicado na leitura (schema-on-read) |
| Carga de trabalho | Muitas escritas pequenas | Consultas de leitura pesadas e agregadas | Exploração, ciência de dados, treinamento de IA |
| Governança | Alta, mas presa a cada sistema | Alta e centralizada | Frágil se ninguém cuidar |
| Custo relativo de armazenamento | Embutido no sistema que o usa | Mais alto, por pipelines e processamento | Mais baixo por volume |
| Uso típico | Registrar pedido, baixar estoque | BI, relatórios, apoio à decisão | Análise exploratória, IA, arquivo de dados brutos |
A coluna do esquema é a que mais importa. Com schema-on-write, você decide a estrutura antes de carregar: toda linha que entra no warehouse já passou por validação, e uma consulta SQL devolve resposta consistente em segundos. Com schema-on-read, o data lake aceita tudo (logs, imagens, JSON de API, planilhas) e empurra a responsabilidade para quem lê. Isso dá flexibilidade a cientistas de dados e a projetos que precisam de dado bruto, como os modelos de IA que uma empresa coloca em produção, mas cobra o preço na governança.
E o preço é conhecido. Um lake sem catálogo, sem dono e sem regra de qualidade vira um data swamp, o pântano de dados: terabytes armazenados barato que ninguém consegue usar, porque ninguém sabe o que significa cada coluna nem de onde ela veio. Já o warehouse tem o problema inverso: forte em consistência e em SQL de alto desempenho, ele oferece menos flexibilidade para análise exploratória e para workloads de IA que precisam de texto livre ou imagem.
O lakehouse surgiu para juntar as duas coisas: armazenamento barato e formatos abertos do lake, com camada de governança, transações e consultas SQL no estilo do warehouse. As fontes de maior autoridade tratam o modelo de forma qualitativa até aqui, como arquitetura híbrida em consolidação, sem métrica consolidada de adoção.
Na minha leitura, o erro mais comum é tratar os três como escolha excludente. Não são. O banco transacional continua existindo de qualquer jeito, porque a operação precisa dele. A pergunta real é se a camada analítica nasce como warehouse, como lake ou como os dois costurados, e a resposta depende de quantos dos seus dados são tabelas limpas e de quantos são documentos, áudio e log.
Arquitetura de um data warehouse: camadas, ETL e modelagem dimensional
A arquitetura de um data warehouse tem três camadas (staging, integração e apresentação), alimentadas por um processo de carga que pode ser ETL ou ELT, e modeladas em esquemas dimensionais do tipo estrela ou floco de neve. Cada camada faz uma coisa só. Misturar as três é a origem de boa parte dos warehouses em que ninguém confia.
- Staging: a área de pouso. Os dados chegam das fontes como estão, sem tratamento, carimbados com a hora de chegada. Se algo der errado no meio do caminho, você reprocessa a partir daqui, sem bater de novo no sistema de origem.
- Integração: onde dados de sistemas diferentes viram um conjunto só, com chaves, nomes e unidades padronizados. É a camada que entrega a propriedade “integrado” de Inmon.
- Apresentação: tabelas desenhadas para consulta, quase sempre divididas em data marts por assunto. É tudo o que o analista e a ferramenta de BI enxergam.
O NIST, o instituto de padrões dos EUA, adota um desenho parecido no seu modelo de referência para big data, o NBDRA: o warehouse aparece como componente do ciclo de vida dos dados, com uma camada de staging e uma de acesso que combinam a visão operacional com a histórica.
ETL ou ELT: onde a transformação acontece
Em ETL, a transformação roda numa ferramenta à parte, antes da carga. O dado só entra no warehouse depois de limpo. Esse foi o padrão por décadas por uma razão econômica simples: o warehouse era o recurso caro e escasso, e gastar o processador dele com limpeza de dados não fazia sentido. O ELT inverte a ordem: o dado bruto entra primeiro, e a transformação acontece dentro do warehouse, em SQL.
A nuvem mudou essa conta. Warehouses nativos em nuvem escalam armazenamento e processamento de forma independente, então transformar dentro deles deixou de ser desperdício. O efeito prático é que o analista escreve a transformação na mesma linguagem em que consulta, e o time de dados para de depender de uma ferramenta separada para cada ajuste. É isso que sustenta o modelo de autosserviço.
Estrela ou floco de neve
Na camada de apresentação, a modelagem dimensional separa fatos (a venda, com valor e quantidade) de dimensões (produto, loja, data, cliente). No esquema estrela, cada dimensão é uma tabela única e desnormalizada: a tabela de produto traz categoria, subcategoria e fabricante nas próprias colunas. No esquema floco de neve, essas dimensões são normalizadas em subtabelas ligadas entre si, o que reduz redundância e cobra em complexidade, com mais junções por pergunta. Na dúvida, estrela. O espaço em disco que o floco economiza custa menos que as horas de analista escrevendo joins.
Três metodologias de projeto
| Metodologia | Ordem de construção | Ponto forte |
|---|---|---|
| Inmon (top-down) | Primeiro o warehouse corporativo normalizado, depois os data marts derivados dele | Consistência entre áreas |
| Kimball (bottom-up) | Primeiro os data marts dimensionais por área, depois a costura entre eles | Entrega rápida de valor |
| Data Vault | Modelo voltado a rastreabilidade, guardando o histórico de cada origem | Auditoria em setores regulados |
Qual escolher? Uma análise comparativa das três metodologias publicada em junho de 2026 conclui que nenhuma é universalmente ideal, e que a decisão depende de escala da organização, ambiente regulatório, maturidade analítica e disposição para investir na arquitetura antes de ver o primeiro dashboard. Um banco sob supervisão pesada tende ao Data Vault ou a Inmon. Uma empresa de SaaS que precisa de relatório de churn na próxima sprint começa por Kimball.
Principais plataformas de data warehouse em nuvem em 2026
Em 2026, as plataformas de data warehouse em nuvem que aparecem em praticamente toda avaliação no Brasil são cinco: Google BigQuery, Snowflake, Amazon Redshift, Microsoft Fabric (que absorveu o Azure Synapse) e Databricks. Todas separam armazenamento de computação em algum grau, e todas cobram por uso. A diferença está em como medem esse uso e em qual ecossistema te puxam.
| Plataforma | Fornecedor | Armazenamento e computação | Modelo de cobrança | Ecossistema natural |
|---|---|---|---|---|
| BigQuery | Google Cloud | Separados, sem cluster para administrar | Por volume lido em cada consulta ou por capacidade reservada | Google Cloud, Looker, Vertex AI |
| Snowflake | Snowflake | Separados, com “virtual warehouses” de computação por equipe | Créditos de computação por tempo de uso, armazenamento à parte | Roda sobre AWS, Azure e Google Cloud |
| Redshift | AWS | Clusters provisionados ou modo serverless | Por nó-hora ou por capacidade serverless consumida | S3, Glue, SageMaker |
| Fabric | Microsoft | Capacidade compartilhada entre warehouse, lake e BI | Unidades de capacidade reservadas ou sob demanda | Power BI, Azure, Microsoft 365 |
| Databricks | Databricks | Lakehouse sobre formatos abertos, computação em clusters ou serverless | Unidades de processamento (DBU) mais a infraestrutura da nuvem escolhida | Spark, MLflow, workloads de IA |
Separar armazenamento de computação significa pagar duas contas diferentes: uma pelo que você guarda, outra pelo que você consulta. Isso é o que permite manter dez anos de histórico barato e só pagar caro no dia em que a diretoria roda a análise pesada. O reverso é que a fatura fica sensível ao comportamento dos usuários. Uma consulta mal escrita que varre a tabela inteira aparece no fim do mês.
Valores mudam com frequência, e qualquer tabela de preço envelhece em meses. Confira a página oficial do fornecedor na data da decisão e simule com o seu volume real de dados e de consultas.
O ecossistema pesa mais do que a planilha de comparação sugere. Quem já roda a operação em Azure e monta relatório em Power BI vai sentir menos atrito com Fabric. Quem tem o time de ciência de dados em Spark tende ao Databricks. BigQuery e Snowflake atraem quem quer o mínimo de administração de infraestrutura.
O contexto de adoção ajuda a calibrar a escolha. Na indústria brasileira, a PINTEC Semestral 2024 do IBGE ouviu 10.167 empresas com 100 ou mais empregados e encontrou computação em nuvem em 77,2% delas, a tecnologia digital mais adotada, com 89,1% usando ao menos uma das tecnologias avançadas investigadas. No mesmo levantamento, o uso de inteligência artificial (IA) na indústria subiu de 16,9% em 2022 para 41,9% em 2024. Para o conjunto das empresas brasileiras, sem recorte setorial, o uso de IA chegou a 17% em 2025 segundo a TIC Empresas do Cetic.br, pesquisa com 4.174 empresas coletada entre fevereiro de 2025 e janeiro de 2026.
A leitura é direta: a infraestrutura de nuvem já está instalada na maioria das indústrias médias e grandes, e a IA corporativa cresce em cima de dado estruturado e integrado. Quem escolhe a plataforma de warehouse hoje está escolhendo, na prática, onde os projetos de IA dos próximos anos vão buscar dado limpo.
Quanto custa manter um data warehouse
Manter um data warehouse custa a soma de seis parcelas: armazenamento, computação das consultas, ingestão, ferramentas de ETL e BI, equipe e governança, o que inclui a conformidade com a LGPD. Nenhuma parcela é a maior em todas as empresas. É por isso que uma faixa de preço confiável por porte não existe, e qualquer número redondo que você encontrar por aí é chute.
O que dá para fazer é entender o que move cada parcela:
- Armazenamento: cresce com o volume e com o histórico guardado. É a linha mais barata na nuvem e a mais previsível, porque só sobe quando você carrega mais dado.
- Computação: cresce com o número de consultas e com o peso de cada uma. Na cobrança sob demanda, uma consulta que varre a tabela inteira custa mais que cem consultas bem filtradas. Na capacidade reservada, você paga por ociosidade em troca de previsibilidade.
- Ingestão: cresce com o número de fontes e com a frequência de carga. Carregar de hora em hora custa mais que carregar uma vez por noite, e cada sistema novo é um conector para manter.
- Ferramentas de ETL e BI: licenças cobradas por usuário ou por volume. Aqui entra o efeito do ELT: quando a transformação roda dentro do warehouse, parte do que era licença de ferramenta vira conta de computação.
- Equipe: engenheiro de dados, analista e alguém que responda pela qualidade. Em warehouse pequeno, a folha do time costuma passar a fatura da nuvem.
- Governança e LGPD: controle de acesso, registro de quem consultou o quê, anonimização de campos sensíveis e a documentação das bases legais de cada uso.
A parcela da LGPD é a que mais surpreende quem orça pela primeira vez. Um warehouse que consolida CPF, endereço e histórico de compra é um “conjunto estruturado de dados pessoais” nos termos do art. 5º da Lei 13.709/2018 (LGPD), e cada etapa do pipeline (coleta, transformação, armazenamento, cruzamento) é tratamento de dados pessoais. Isso obriga a arquitetura a respeitar base legal, finalidade e necessidade, e a manter segurança sob fiscalização da Agência Nacional de Proteção de Dados (ANPD). Nada disso é gratuito. Mascarar CPF na camada de apresentação, separar quem pode ver dado nominal de quem só vê agregado e registrar cada consulta a campo sensível são trabalho de engenharia que precisa entrar no orçamento desde o primeiro data mart.
Como estimar, então? Três perguntas resolvem a maior parte da incerteza:
- Quantos gigabytes entram por mês e quantos anos de histórico você precisa manter online?
- Quantas pessoas vão consultar, com que frequência, e quantas dessas consultas são pesadas?
- Quantas fontes precisam ser conectadas e quantas delas carregam dado pessoal?
Com essas respostas em mãos, o simulador de preço de qualquer fornecedor devolve um número útil, e uma avaliação de prontidão antes de contratar evita descobrir a parcela da equipe depois que a licença já foi assinada. O que não dá é orçar pelo tamanho da empresa. Uma indústria com 800 funcionários e três fontes de dados pode gastar menos que uma startup de 40 pessoas que carrega eventos de aplicativo a cada minuto.
Quando um data warehouse não é a melhor escolha
Um data warehouse não é a melhor escolha quando a empresa tem uma ou duas fontes de dados, quando o que ela precisa é dado bruto para treinar modelos, quando a resposta tem de sair segundos depois do evento, ou quando ainda não existe ninguém fazendo perguntas ao dado. Em cada um desses casos há uma saída mais barata. Montar o warehouse antes da hora costuma produzir um repositório caro que ninguém consulta.
Os quatro cenários, com a alternativa para cada um:
- Uma ou duas fontes de dados: se tudo mora no ERP e o volume cabe numa réplica de leitura, gere os relatórios direto do banco, numa cópia que não trava a operação. O warehouse resolve integração, e sem fontes para integrar ele só adiciona uma camada e uma fatura.
- Dado bruto e não estruturado para IA: texto de atendimento, imagem, áudio e log não cabem bem num esquema dimensional. Um data lake com governança mínima desde o primeiro dia (catálogo e um dono por conjunto de dados) atende melhor e custa menos por terabyte.
- Latência de segundos: o warehouse clássico carrega em lotes, uma vez por noite ou de hora em hora. Bloquear uma fraude no momento da transação ou disparar alerta de sensor na linha de produção exige streaming, com o processamento acontecendo no fluxo do evento. Existe a variante do warehouse em tempo real, que encurta o intervalo entre a geração do dado operacional e a hora em que ele fica disponível para análise, mas é uma arquitetura à parte, com custo próprio.
- Equipe sem maturidade analítica: se ninguém na empresa abre um relatório hoje, o problema não é infraestrutura. Comece com dois ou três indicadores num painel simples ligado à fonte e observe quem usa. O warehouse entra quando as perguntas passarem a exigir cruzamento e histórico.
O sinal mais claro de projeto prematuro aparece na primeira reunião. Alguém pergunta “que relatório vocês querem?” e a sala fica em silêncio. Quando ninguém sabe dizer qual pergunta o dado precisa responder, o projeto entrega tabelas, e tabela sem pergunta é só custo de armazenamento com nome bonito.
Há ainda um caso intermediário que quase nenhum guia menciona: a empresa que precisa das duas coisas ao mesmo tempo, dado estruturado para o fechamento e dado bruto para um modelo. Aí a resposta raramente é escolher. É montar o warehouse para o financeiro e deixar o lake receber o resto, com um catálogo comum entre os dois.
Data warehouse vale a pena para empresas pequenas?
Para uma empresa pequena, o data warehouse vale a pena a partir do momento em que as decisões dependem de cruzar dois ou mais sistemas e de olhar o histórico, e deixa de valer enquanto a resposta cabe numa consulta ao banco do ERP. O porte, sozinho, não decide nada. O que decide é o número de fontes e o número de perguntas que ficam sem resposta na reunião mensal.
Três sinais de que chegou a hora:
- As planilhas não fecham: o comercial diz que vendeu um valor, o financeiro fechou outro, e a reunião vira debate sobre qual número é o certo.
- Três ou mais sistemas com o mesmo cadastro: ERP, loja virtual e plataforma de atendimento, cada um com um código de cliente e uma grafia de endereço.
- Decisão que depende de histórico que o sistema já apagou: margem por produto de dois anos atrás, cliente que sumiu e voltou, sazonalidade por região.
O caminho enxuto existe, e não se parece com o projeto corporativo em fases. Contrate uma plataforma em nuvem com cobrança sob demanda, que custa perto de zero nos dias em que ninguém consulta. Ligue um conector de ELT gerenciado às três ou quatro fontes que doem. Escreva a transformação em SQL dentro do próprio warehouse, monte um único data mart de vendas em esquema estrela e ligue um painel em cima. Uma pessoa que saiba SQL e conheça o negócio toca isso sozinha, e a ordem é a de Kimball: primeiro o recorte que resolve a briga da reunião, depois o resto.
As armadilhas são conhecidas de quem já passou por elas:
- Contratar a plataforma antes de listar as perguntas.
- Carregar todas as tabelas de todos os sistemas “para ter”, o que multiplica a ingestão e recria o pântano de dados em escala de PME.
- Tratar a LGPD como assunto de empresa grande. A Lei 13.709/2018 se aplica ao tratamento de dado pessoal e não pergunta o faturamento de quem trata. O CPF do cliente da loja de bairro tem a mesma proteção do CPF do correntista de banco.
- Deixar a fatura de consulta sem alarme de gasto. Uma consulta mal escrita num sábado aparece na segunda.
Quem faz isso direito costuma ter o primeiro data mart em uso em semanas, com um custo mensal de nuvem menor que o de uma licença de software de gestão. O custo real, como sempre, é a hora de quem conhece o dado.
Perguntas frequentes sobre data warehouse
O que significa warehouse e qual a tradução de data warehouse?
Warehouse significa armazém ou depósito em inglês, o galpão em que uma empresa guarda mercadoria. A tradução literal de data warehouse é “armazém de dados”, mas ninguém no mercado brasileiro usa a forma traduzida: vagas, documentação e contratos falam em data warehouse. Em texto técnico, escreva data warehouse, ou apenas warehouse quando o contexto já deixa claro que é de dados.
Qual a diferença entre data warehouse e data mart?
O data mart é um recorte do data warehouse dedicado a um único assunto ou área, como vendas, compras ou RH. O warehouse cobre a empresa inteira e integra todas as fontes. Um data mart pode nascer antes do warehouse, na ordem de Kimball, ou derivar dele, na ordem de Inmon. Na prática, quem abre um painel de BI quase sempre está consultando um data mart, mesmo sem saber.
Data warehouse é a mesma coisa que big data?
Não. Big data nomeia um conjunto de técnicas e arquiteturas para lidar com dados em volume e variedade além do que um banco relacional comum aguenta. Data warehouse é uma arquitetura específica, voltada a dado estruturado e consulta analítica. No modelo de referência de big data do NIST, o NBDRA, o warehouse aparece como um componente do ciclo de vida dos dados, com camadas de staging e de acesso. Ou seja, um warehouse pode fazer parte de uma arquitetura de big data sem substituí-la, e a maioria dos warehouses no Brasil roda com volumes que big data nem chamaria de grandes.
Quais são as características de um data warehouse?
As quatro características clássicas, definidas por Bill Inmon, são: orientado por assunto, integrado, não volátil e variável no tempo. Na prática isso se traduz em quatro comportamentos: os dados se organizam por tema do negócio em vez de seguir a estrutura dos sistemas de origem, chegam com códigos e formatos uniformizados, nunca são sobrescritos e carregam a data a que se referem. Duas características operacionais completam a lista: o repositório é somente leitura para o usuário e fica separado do banco que sustenta a operação.
Quais são exemplos de data warehouse?
Os exemplos vão de produtos a aplicações. Como produto, os mais usados são Google BigQuery, Snowflake, Amazon Redshift, Microsoft Fabric e Databricks. Como aplicação documentada, há warehouses para apoio à decisão clínica e para acompanhamento de doenças oncológicas na saúde, um projeto de previsão de safra na agricultura e, no Brasil, estudos de caso de business intelligence sobre warehouse na controladoria e no chão de fábrica industrial. No setor público, o Sistema Gerenciador de Séries Temporais (SGS) do Banco Central consolida séries econômico-financeiras de forma uniforme e cumpre o papel de repositório analítico.
O que é ETL em data warehouse?
ETL é a sigla de extract, transform, load: extrair dados dos sistemas de origem, transformá-los num formato uniforme e carregá-los no warehouse. É o processo que entrega a característica “integrado”, padronizando códigos, unidades e datas antes que o dado fique disponível para consulta. A variante ELT inverte as duas últimas etapas: carrega o dado bruto primeiro e transforma dentro do próprio warehouse, em SQL, aproveitando o processamento elástico das plataformas em nuvem.
Data warehouse precisa seguir a LGPD?
Sim, sempre que guardar dado pessoal. O art. 5º da Lei 13.709/2018 (LGPD) define banco de dados como “conjunto estruturado de dados pessoais, estabelecido em um ou em vários locais, em suporte eletrônico ou físico”, e um warehouse com CPF, endereço ou histórico de compra se encaixa nessa definição. Coletar, transformar, armazenar e cruzar esses dados é tratamento, sujeito a base legal, finalidade, necessidade e deveres de segurança, sob fiscalização da Agência Nacional de Proteção de Dados (ANPD). Um warehouse que só guarda vendas agregadas por loja ou séries de preço, sem identificar pessoas, fica fora desse enquadramento.
Por onde começar a montar seu data warehouse
Comece o seu data warehouse pelas perguntas de negócio, e só depois pelos sistemas, pela plataforma e pelo modelo. A ordem parece óbvia e quase ninguém segue: a maioria dos projetos abre com a contratação da ferramenta e passa meses carregando tabelas que nenhuma reunião pediu.
O roteiro cabe em cinco etapas:
- Mapeie as perguntas: liste as dez decisões que a diretoria toma por mês e anote qual número cada uma exige. Se a lista não passa de três, você ainda não precisa de warehouse.
- Inventarie as fontes: para cada pergunta, escreva de qual sistema sai cada dado, quem é o dono e se há CPF ou outro dado pessoal no meio.
- Escolha a plataforma: com volume mensal, número de consultas e ecossistema já em uso em mãos, simule no site do fornecedor e confirme o alarme de gasto antes de assinar.
- Defina modelo e governança: esquema estrela para o primeiro recorte, base legal documentada para cada campo pessoal e controle de acesso separando dado nominal de agregado.
- Entregue um data mart: vendas ou financeiro, o que resolver a briga da reunião mensal, com um painel em cima e uma pessoa responsável pela qualidade.
O primeiro data mart em uso vale mais que a arquitetura completa no papel, porque é ele que revela quais perguntas eram reais. Se o time interno não tem quem conheça ETL, modelagem dimensional e LGPD ao mesmo tempo, fale com o time da AlphaCorp AI antes de contratar a plataforma. Marque na agenda: a lista de perguntas pronta até o fim deste mês.
