OLAP vs OLTP, ETL vs ELT, Data Lake vs Data Warehouse vs Lakehouse: o guia definitivo da arquitetura de dados

Se você está entrando em engenharia de dados ou já atua na área, provavelmente já se deparou com esses três pares de conceitos que parecem simples, mas definem a base de toda arquitetura de dados moderna. Entender para que cada um serve, quando usar e como eles se relacionam é o que separa quem apenas “roda pipelines” de quem projeta soluções de dados escaláveis.

Neste artigo, vamos destrinchar cada comparação com profundidade técnica, exemplos práticos e critérios objetivos de decisão.

Parte 1 — OLAP vs OLTP: dois mundos, um mesmo dado

A primeira distinção que todo engenheiro de dados precisa dominar é entre processamento transacional e processamento analítico. São filosofias opostas de como armazenar e acessar dados.

OLTP (Online Transaction Processing)

O OLTP é o sistema que sustenta as operações do dia a dia. Cada venda, cada login, cada atualização de cadastro — tudo isso passa por um banco OLTP. Suas características definidoras:

• Alta concorrência: milhares de usuários acessando simultaneamente
• Operações curtas: inserts, updates e deletes rápidos e frequentes
• Integridade transacional: usa ACID (Atomicidade, Consistência, Isolamento, Durabilidade) para garantir que nenhuma operação fique pela metade
• Modelagem normalizada: dados organizados para evitar redundância (3ª forma normal)
• Latência em milissegundos: cada consulta retorna em tempo real

Exemplos: sistemas de ERP (SAP), bancos, e-commerce (carrinho de compras), sistemas de pedidos, CRM.

OLAP (Online Analytical Processing)

O OLAP é o sistema voltado para análise e tomada de decisão. Ele consome os dados gerados pelos sistemas OLTP e os reorganiza para que consultas complexas sejam rápidas. Suas características:

• Baixa concorrência: poucos usuários (analistas, cientistas de dados)
• Consultas pesadas: agregações, drill-down, slice-and-dice sobre milhões de registros
• Leitura intensiva: praticamente não há escrita no OLAP
• Modelagem desnormalizada: dados organizados em fatos e dimensões (esquema estrela ou floco de neve)
• Latência em segundos: respostas para análises, não para operações

Exemplos: SAP BW, Oracle OLAP, cubos multidimensionais, dashboards de BI.

A relação entre eles

O OLAP não substitui o OLTP — ele o complementa. O dado nasce no OLTP (transação) e é movido para o OLAP (análise) através de um pipeline de dados. Essa é a ponte que conecta a Parte 1 à Parte 2 deste artigo.

Vou gerar o infográfico dessa comparação agora.

Resumo rápido da Parte 1

Parte 2 — ETL vs ELT: a ordem importa (e muito)

Agora que temos a origem (OLTP) e o destino (OLAP), surge a pergunta central: como mover os dados? Aqui entram ETL e ELT — dois padrões de pipeline que diferem em um ponto crítico: onde e quando a transformação acontece.

ETL (Extract, Transform, Load)

O ETL é o padrão clássico, consolidado há décadas. O fluxo é sequencial:

1. Extract: extrai os dados da fonte (OLTP, APIs, arquivos)
2. Transform: processa, limpa, valida e modela os dados em um servidor intermediário (staging)
3. Load: carrega os dados já transformados no destino (Data Warehouse)

Vantagens:

• Dados chegam ao destino prontos para consumo
• Controle total sobre a qualidade antes da carga
• Ideal quando o destino é caro ou tem capacidade limitada de processamento

Desvantagens:

• Processamento lento em grandes volumes (tudo passa pelo servidor de transformação)
• Infraestrutura extra (servidor de staging)
• Menos flexível: se a regra de negócio muda, o pipeline inteiro precisa ser reprocessado

ELT (Extract, Load, Transform)

O ELT inverte a ordem — uma mudança que só foi possível com o barateamento do armazenamento e o poder de processamento dos data lakes e warehouses modernos:

1. Extract: extrai os dados da fonte
2. Load: carrega os dados brutos diretamente no destino
3. Transform: transforma dentro do próprio destino, sob demanda

Vantagens:

• Escalabilidade: o destino (ex.: Snowflake, BigQuery, Databricks) processa em paralelo
• Velocidade de ingestão: dados brutos ficam disponíveis quase imediatamente
• Flexibilidade: o mesmo dado bruto pode ser transformado de várias formas para diferentes análises
• Menos infraestrutura intermediária

Desvantagens:

• Dados brutos no destino podem gerar custos de armazenamento e riscos de governança
• Exige que o destino tenha capacidade de processamento (nem todo warehouse aguenta)
• Qualidade de dados precisa ser garantida no consumo, não na carga

Qual escolher?

A decisão depende do volume, do destino e da necessidade de governança:

• ETL → quando você precisa de dados já modelados, com forte controle de qualidade, e o destino é um warehouse tradicional com capacidade limitada.
• ELT → quando o volume é grande, o destino é um lakehouse/warehouse moderno com processamento elástico, e você precisa de flexibilidade analítica.

Vou gerar o infográfico dessa comparação.

Resumo rápido da Parte 2

Parte 3 — Data Lake vs Data Warehouse vs Lakehouse: a evolução do destino

Agora chegamos ao coração da arquitetura moderna: onde os dados vivem. Essa é a evolução de três gerações de armazenamento analítico.

Data Warehouse (DW)

O Data Warehouse é a solução clássica, madura há mais de 30 anos. Ele armazena dados estruturados, limpos e modelados para análise.

• Dados: apenas estruturados, já transformados e modelados (fatos e dimensões)
• Objetivo: BI e relatórios de alta performance
• Modelagem: esquema estrela/floco de neve, normalizado para análise
• Tecnologias: Teradata, Oracle Exadata, SAP BW, Snowflake, BigQuery, Redshift
• Pontos fortes: performance de consulta, governança, qualidade de dados
• Limitações: caro, rígido, não lida bem com dados não estruturados (imagens, vídeos, logs, JSON)

Data Lake

O Data Lake surgiu para resolver a rigidez do warehouse: armazenar tudo, em qualquer formato, sem modelagem prévia.

• Dados: estruturados, semiestruturados e não estruturados (qualquer formato)
• Objetivo: armazenamento massivo e barato para data science e ML
• Modelagem: schema-on-read (o schema é aplicado na leitura, não na escrita)
• Tecnologias: Hadoop HDFS, Amazon S3, Azure Data Lake Storage, Google Cloud Storage
• Pontos fortes: baixo custo, flexibilidade total, escala massiva
• Limitações: pode virar um “data swamp” (pântano de dados) sem governança; performance de consulta inferior; sem transações ACID

Lakehouse

O Lakehouse é a convergência: combina o baixo custo e flexibilidade do data lake com a performance, governança e transações ACID do data warehouse.

• Dados: todos os formatos (estruturados e não estruturados)
• Objetivo: unificar BI, data science e ML em uma única plataforma
• Modelagem: schema-on-read com camadas de governança (medallion architecture: bronze → prata → ouro)
• Tecnologias: Databricks (Delta Lake), Apache Iceberg, Apache Hudi, Snowflake (com suporte a dados não estruturados)
• Pontos fortes: melhor dos dois mundos — custo de lake, performance e ACID de warehouse
• Limitações: maturidade ainda em evolução, curva de aprendizado

A comparação decisiva

A escolha entre os três depende do tipo de dado, do uso e do orçamento. A tendência atual do mercado é clara: o lakehouse está se tornando o padrão de facto, pois elimina a necessidade de manter dois sistemas separados.

Vou gerar o infográfico dessa comparação.

Resumo rápido da Parte 3

Parte 4 — Como tudo se conecta: o pipeline completo

Agora que dominamos os três pares, vamos juntar tudo em um fluxo real. Uma arquitetura de dados moderna conecta esses conceitos assim:

1. OLTP (origem) gera os dados transacionais do negócio.
2. O pipeline ETL ou ELT extrai esses dados.
3. Os dados são carregados em um Data Lake (brutos) ou Data Warehouse (modelados).
4. No Lakehouse, os dados brutos (bronze) são progressivamente limpos e enriquecidos (prata) até virarem modelos analíticos prontos (ouro).
5. O OLAP consome esses dados modelados para alimentar dashboards e análises.

A escolha de cada componente depende de um trade-off constante entre custo, performance, flexibilidade e governança.

Parte 5 — Guia de decisão para engenheiros de dados

Para fechar com objetividade, aqui está o raciocínio prático que você deve aplicar em cada projeto:

Sobre OLTP vs OLAP

• Se o sistema precisa de transações em tempo real com integridade → OLTP
• Se o sistema precisa responder perguntas analíticas sobre histórico → OLAP

Sobre ETL vs ELT

• Volume pequeno/médio + destino tradicional + governança rígida → ETL
• Volume grande + destino cloud moderno + flexibilidade → ELT

Sobre Lake vs Warehouse vs Lakehouse

• Apenas BI estruturado, orçamento alto → Data Warehouse
• Exploração de dados não estruturados, data science → Data Lake
• Unificar tudo, tendência moderna → Lakehouse

Conclusão

Dominar essas distinções não é sobre decorar definições — é sobre tomar decisões de arquitetura com fundamento. Um engenheiro de dados sênior não pergunta “ETL ou ELT?”, mas sim “qual abordagem entrega valor mais rápido com o menor custo de manutenção para este cenário específico?”.

A tendência do mercado é inequívoca: o lakehouse com pipelines ELT está se consolidando como o padrão dominante, impulsionado por plataformas como Databricks, Snowflake e o ecossistema Apache Iceberg. Mas o conhecimento de ETL e Data Warehouse clássicos continua essencial — a maioria das empresas ainda opera sistemas legados que precisam ser integrados e modernizados.

Para quem está em transição de carreira, meu conselho: domine o pipeline completo, do OLTP ao OLAP, passando por ETL/ELT e pela arquitetura de destino. É essa visão de ponta a ponta que diferencia um engenheiro de dados de um simples executor de tarefas.

Resumindo

• OLTP executa transações; OLAP suporta análises. São complementares, conectados por pipelines.
• ETL transforma antes de carregar (servidor intermediário); ELT carrega bruto e transforma no destino (mais escalável).
• Data Lake armazena tudo barato; Data Warehouse entrega BI performático; Lakehouse une os dois com ACID e governança.
• A tendência do mercado é lakehouse + ELT, mas ETL e DW clássicos seguem essenciais para sistemas legados.