O dilema dos dados
Toda empresa gera dados. Poucas sabem o que fazer com eles. A escolha entre Data Lake e Data Warehouse é uma das primeiras decisões estratégicas de uma iniciativa de dados — e escolher errado custa caro.
O que é um Data Warehouse
Um Data Warehouse é um repositório centralizado de dados estruturados, otimizado para consultas analíticas e geração de relatórios. Os dados chegam limpos, transformados e modelados (tipicamente em Star Schema ou Snowflake Schema).
Características principais: schema-on-write (estrutura definida antes da carga), dados altamente curados, performance otimizada para SQL, ideal para BI e relatórios.
O que é um Data Lake
Um Data Lake é um repositório que armazena dados em seu formato nativo — estruturados, semi-estruturados e não-estruturados. A transformação acontece no momento da leitura (schema-on-read).
Características principais: armazena qualquer tipo de dado, custo de armazenamento muito baixo, flexível para diferentes casos de uso, ideal para data science e machine learning.
Comparativo direto
Estrutura de dados
- Warehouse: Dados estruturados e modelados (tabelas relacionais)
- Lake: Qualquer formato (JSON, CSV, Parquet, imagens, logs, áudio)
Performance
- Warehouse: Otimizado para queries SQL complexas, respostas em segundos
- Lake: Performance variável, depende do engine de query (Spark, Presto, Athena)
Custo
- Warehouse: Armazenamento mais caro, compute otimizado
- Lake: Armazenamento barato (object storage), compute pode ser caro sem otimização
Casos de uso
- Warehouse: BI, relatórios executivos, dashboards, KPIs
- Lake: Machine learning, data science, exploração de dados, processamento de logs
O melhor dos dois mundos: Lakehouse
A tendência atual é o Lakehouse, que combina a flexibilidade do Data Lake com a performance e governança do Data Warehouse. Plataformas como Databricks (Delta Lake), Apache Iceberg e Apache Hudi permitem rodar queries SQL performantes diretamente sobre dados no Data Lake.
O Lakehouse resolve o problema histórico de ter dados duplicados: uma cópia no Lake e outra no Warehouse. Com formatos abertos como Iceberg e Delta, os mesmos dados servem tanto data scientists (Python, Spark) quanto analistas de negócio (SQL, BI).
Quando o Lakehouse faz sentido
- Você precisa de analytics e machine learning sobre os mesmos dados
- Quer evitar a complexidade de manter duas infraestruturas separadas
- Precisa de governança unificada (um catálogo, um controle de acesso)
- Volume de dados justifica a complexidade (tipicamente acima de 1 TB)
Arquitetura Medallion: Bronze, Silver, Gold
Uma abordagem comprovada para organizar dados em qualquer arquitetura (Lake, Warehouse ou Lakehouse) é a arquitetura Medallion:
Bronze (Raw)
Dados brutos exatamente como chegaram da fonte. Nenhuma transformação, nenhuma limpeza. É a "fonte de verdade histórica" que permite reprocessar tudo se necessário.
Armazene em formatos eficientes como Parquet ou Delta, particionado por data de ingestão. Mantenha indefinidamente (storage é barato) ou defina retenção baseada em requisitos legais.
Silver (Curated)
Dados limpos, deduplicados, tipados e com schema consistente. Joins entre fontes diferentes já estão feitos. Regras de qualidade validadas. É a camada que a maioria dos consumidores deveria usar.
Aqui entram transformações como: remover duplicatas, preencher valores nulos, padronizar formatos de data, unificar códigos de cliente entre sistemas diferentes.
Gold (Business)
Dados agregados e modelados para casos de uso específicos: dashboards executivos, KPIs, features para modelos de ML, reports regulatórios. Cada tabela Gold responde uma pergunta de negócio clara.
A vantagem dessa organização é que cada camada tem um propósito e um público claro. Data engineers trabalham na Bronze e Silver. Analistas e data scientists consomem Silver e Gold. Executivos veem Gold em dashboards.
ETL vs ELT: qual abordagem escolher
ETL (Extract, Transform, Load)
O modelo clássico: dados são extraídos da fonte, transformados em um servidor intermediário e carregados no destino já prontos para uso. Faz sentido quando o destino tem capacidade de processamento limitada (data warehouses tradicionais).
ELT (Extract, Load, Transform)
O modelo moderno: dados são extraídos e carregados brutos no destino. A transformação acontece dentro do próprio destino, aproveitando seu poder de processamento. Ideal para cloud data warehouses (Snowflake, BigQuery, Redshift) e lakehouses que têm compute elástico.
ELT está dominando porque: cloud compute é barato e elástico, manter dados brutos permite reprocessar, e ferramentas como dbt tornaram transformação in-database simples e testável.
dbt: o padrão para transformações
dbt (data build tool) se tornou o padrão da indústria para transformação de dados em ELT. Ele permite escrever transformações como SELECT SQL, com versionamento, testes automatizados, documentação e linhagem de dados.
Se você está começando uma iniciativa de dados em 2026, dbt provavelmente deveria fazer parte da stack.
Governança de dados
Sem governança, qualquer repositório de dados vira caos. Os pilares essenciais:
Catalogação
Um catálogo centralizado que responde: quais dados existem, onde estão, quem é o dono, quando foram atualizados e o que significam. AWS Glue Catalog, Unity Catalog (Databricks) e Apache Atlas são opções.
Linhagem (Lineage)
Saber de onde um dado veio, quais transformações sofreu e onde é usado. Quando um dashboard mostra um número errado, linhagem permite rastrear a causa raiz até a fonte original.
Qualidade de dados
Regras automatizadas que validam dados na ingestão e após transformações: campos obrigatórios preenchidos, valores dentro de ranges esperados, unicidade de chaves, referential integrity. Great Expectations, Soda e dbt tests são ferramentas para isso.
Controle de acesso
Nem todo mundo deve ver todos os dados. Implemente controle de acesso granular: por dataset, por coluna, por linha. Dados de PII (Personally Identifiable Information) devem ter acesso restrito e auditado.
Ferramentas por cenário
Startup ou empresa pequena
- Warehouse: BigQuery (serverless, pague por query) ou Snowflake
- ETL: Fivetran ou Airbyte para ingestão, dbt para transformação
- BI: Metabase (open source) ou Looker
Média empresa
- Lake + Warehouse: S3 + Snowflake ou Databricks
- ETL: Airbyte + dbt + Airflow para orquestração
- BI: Power BI ou Tableau
Grande empresa
- Lakehouse: Databricks com Unity Catalog ou plataforma on-premise com Iceberg
- ETL: Spark + dbt + Airflow/Dagster
- BI: Tableau, Power BI, Looker
- Governança: Unity Catalog, Apache Atlas, Collibra
Como montar sua estratégia de dados
Passo 1: Defina os casos de uso
Antes de escolher tecnologia, entenda o que precisa responder. Relatórios mensais para diretoria? Modelos preditivos? Análise de comportamento do usuário? Monitoramento em tempo real? Cada caso de uso tem requisitos diferentes de latência, volume e complexidade.
Passo 2: Mapeie suas fontes de dados
Identifique todas as fontes: bancos de dados transacionais, APIs externas, arquivos, logs, IoT, redes sociais. Classifique por volume, velocidade e variabilidade. Entenda a qualidade atual de cada fonte.
Passo 3: Escolha a arquitetura
Para a maioria das empresas, a resposta é "ambos" ou "lakehouse":
- Data Lake para ingestão e armazenamento bruto
- Data Warehouse para dados curados e analytics
- Lakehouse para unificar ambos em uma plataforma
Passo 4: Implemente governança desde o dia 1
Catalogação, linhagem de dados, controle de acesso, qualidade e retenção não são "nice to have" — são requisitos para que sua estratégia de dados funcione a longo prazo. Ignorar governança no início cria débito técnico que é exponencialmente mais caro de resolver depois.
Passo 5: Comece com quick wins
Identifique 2-3 dashboards ou relatórios que o negócio precisa urgentemente e que podem ser construídos com dados disponíveis. Entregue valor rápido para construir credibilidade e justificar investimento contínuo.
Não espere ter dados perfeitos para começar
O erro mais comum é esperar ter todos os dados limpos e integrados antes de começar a gerar valor. Comece com um caso de uso concreto, dados disponíveis e entregue insights reais. Itere e melhore continuamente.
Dados imperfeitos que geram decisões melhores são infinitamente mais valiosos que dados perfeitos que nunca são usados. A estratégia de dados é uma jornada, não um destino.