Quero construir um data warehouse ou data lake
Resposta rápida
Centralizar dados não é decisão de tecnologia — é decisão sobre casos de uso e maturidade. Data warehouse (DW) serve dado estruturado e modelado para análise consistente, ideal para relatórios gerenciais e BI. Data lake serve dado bruto em qualquer formato, ideal para volumes grandes e casos de ciência de dados. Lakehouse combina os dois em arquitetura unificada, padrão crescente para empresa que faz análise e ciência. Comece pela pergunta do uso, não da tecnologia. Para a maioria das empresas hoje, lakehouse em cloud (Databricks, Snowflake, BigQuery, Synapse) cobre os dois mundos com custo razoável. Modelagem dimensional para dados de análise, ELT (não ETL) regular, governança desde o início e custo monitorado evitam que o investimento vire pântano de dado.
Na empresa pequena, "data warehouse" raramente é a resposta certa. Volume de dado e complexidade não justificam infraestrutura dedicada. O caminho típico é usar diretamente a base do ERP em SaaS, conectando ferramenta de BI (Power BI, Looker Studio) com extração via APIs ou exportações periódicas. Quando dados precisam ser combinados (vendas + financeiro + marketing), uma camada leve em BigQuery, Snowflake ou Azure SQL gratuito por consumo resolve. Não monte projeto de data warehouse formal nesse porte — custo de plataforma e operação é desproporcional ao retorno. Foco em algumas tabelas curadas para análise, mantidas com cuidado.
Na empresa média, projeto de data warehouse ou lakehouse formal começa a fazer sentido. Stack típica em cloud: Snowflake, BigQuery, Synapse ou Databricks como motor, Fivetran/Airbyte/Stitch para ingestão, dbt para transformações, Power BI ou Tableau para visualização, catálogo básico. Lakehouse já se justifica em vez de DW puro quando há casos de ciência de dados ou volume de dado não estruturado. Implantação em ondas, começando por área-piloto (vendas e financeiro são candidatos comuns), com modelagem dimensional clara, governança desde o início e custo monitorado (cloud bill cresce rápido). O risco maior é construir sem caso de uso prioritário — DW vira pântano de tabela que ninguém consulta.
Na empresa grande, lakehouse corporativo é a arquitetura dominante: Databricks ou Snowflake como plataforma, camadas bronze/silver/gold padronizadas, catálogo de dados maduro, lineage, qualidade automatizada, governança formal por domínio. Modelo de operação pode incluir data mesh quando faz sentido, com times de produto de dados em domínios de negócio responsáveis por seus dados. Investimento dedicado em plataforma de dados, ferramentas e capacitação. FinOps específico de dado é função crítica (custo de cloud pode explodir). O risco maior é arquitetura sobre-engenharia: plataforma elegante demais, lead time longo, time gastando mais com infraestrutura do que entregando análise. Equilíbrio entre rigor e velocidade é o desafio central.
- Cada análise importante envolve combinar dados de vários sistemas na mão
- Não há fonte única de verdade para métricas corporativas
- Análise de cliente exige extrair de ERP, CRM, e-commerce e juntar à mão
- Volume de dado cresce e Excel ou planilha não dá mais conta
- A área de dados quer escalar e está limitada pela infraestrutura
- Surgiu demanda por análise preditiva ou IA, e a base atual não sustenta
DW, data lake e lakehouse — o que cada um é
Três conceitos com função diferente. Data warehouse (DW): banco otimizado para análise, com dados estruturados, modelados em esquema dimensional, processados por ELT regular. Ideal para relatórios gerenciais e BI com performance previsível. Snowflake, BigQuery, Synapse, Redshift, Teradata. Data lake: repositório de dados brutos em qualquer formato (estruturado, semi-estruturado, não estruturado), normalmente em storage de objeto (S3, GCS, ADLS). Ideal para volumes grandes, ciência de dados, exploração. Lakehouse: arquitetura que combina as duas — armazenamento aberto como lake, com camadas de processamento que entregam consistência de DW. Databricks popularizou o termo; Snowflake, BigQuery e Synapse convergiram para algo similar.
Como escolher entre os três
Três perguntas orientam a decisão. Qual o principal caso de uso? Se é BI gerencial em dados estruturados, DW basta. Se inclui ciência de dados ou dado não estruturado, lakehouse cobre os dois. Data lake puro é cada vez menos escolhido por si só. Qual o volume? Volume pequeno cabe em DW tradicional; volume muito grande favorece lakehouse pelo custo de armazenamento. Qual o stack atual e ecossistema? Empresa em Microsoft tende a Synapse ou Fabric; Google tende a BigQuery; AWS tende a Redshift ou opções abertas; Databricks é multi-cloud. Para a maioria das empresas hoje, lakehouse em cloud é a escolha padrão.
ETL vs ELT — escolha moderna é ELT
ETL (Extract, Transform, Load) era padrão: dados eram transformados antes de carregar. ELT (Extract, Load, Transform) inverteu: dados são carregados brutos na plataforma e transformados lá, aproveitando o processamento elástico da cloud. ELT é mais simples, mais flexível, mais auditável e tornou-se padrão moderno. Ferramentas como Fivetran, Airbyte e Stitch para ingestão; dbt para transformação no destino. Equipes que ainda fazem ETL tradicional em escala estão pagando custo extra sem ganho proporcional.
- Casos de uso prioritários. Que análises e processos vão consumir esta plataforma nos primeiros 12 meses. Sem isso, o projeto vira "construir plataforma e esperar uso aparecer" — receita para pântano de dado.
- Escolha de stack. Lakehouse ou DW, plataforma específica (Databricks, Snowflake, BigQuery, Synapse), ferramentas de ingestão (Fivetran, Airbyte, Stitch), transformação (dbt), visualização (BI). Decisão coerente com ecossistema.
- Modelagem e camadas. Camadas bronze (raw), silver (limpo e modelado) e gold (agregado para análise). Modelagem dimensional para área de negócio prioritária.
- Governança e FinOps desde o início. Catálogo, qualidade, lineage, controle de acesso, monitoramento de custo. Adiar é receita para refazer.
Modelagem dimensional ainda importa
Em meio à modernização do stack, modelagem dimensional (esquema estrela, fato e dimensão) segue como melhor prática para dados de análise. Ela traduz processos de negócio em estrutura que ferramentas de BI consultam com performance e que usuários de negócio entendem. Pular modelagem ("dados estão crus no lake, qualquer um consulta") gera baixa performance, consulta inconsistente e dependência de quem entende a estrutura crua. Em camada silver/gold do lakehouse, modelagem dimensional continua sendo o padrão recomendado.
Construir sem caso de uso. Plataforma elegante sem demanda real vira pântano de dado: muitas tabelas, pouco uso, custo alto, valor baixo.
Pular modelagem. "Dados crus no lake" funciona para exploração; não funciona para análise consistente e performance. Modelagem dimensional segue importante.
ETL tradicional em escala. ELT moderno é mais simples e mais flexível. Ferramentas como Fivetran e dbt mudaram o padrão.
Sem FinOps. Custo de cloud cresce rápido em plataforma de dado. Monitoramento, tagging, otimização de query e revisão regular são parte do programa.
Governança como fase final. Catálogo, qualidade, lineage e controle de acesso precisam nascer com a plataforma. Adicionar depois multiplica trabalho.
- Casos de uso prioritários validados para os primeiros 12 meses
- Escolha entre DW, data lake ou lakehouse com justificativa
- Stack definido (plataforma, ingestão, transformação, visualização)
- Modelo de camadas (bronze, silver, gold) e modelagem dimensional planejada
- Governança mínima (catálogo, qualidade, controle de acesso) desde o início
- FinOps com responsável e processo de revisão de custo
- Onda piloto definida em área-âncora
- Equipe ou parceiro de implantação com expertise no stack escolhido