ETL vs ELT: mudanças modernas na engenharia de dados

1. Fundamentos: O que são ETL e ELT?

A engenharia de dados moderna se apoia em dois paradigmas fundamentais para movimentar e transformar informações: ETL (Extract, Transform, Load) e ELT (Extract, Load, Transform). O modelo clássico de ETL surgiu nos anos 1990, quando os data warehouses eram o centro das arquiteturas corporativas. Nesse fluxo, os dados são extraídos de fontes diversas (bancos relacionais, APIs, arquivos), transformados em um ambiente intermediário — geralmente um servidor de staging — e só então carregados no destino final.

O ELT inverte essa ordem: primeiro extrai-se e carrega-se os dados brutos no sistema de destino (um data lake ou data warehouse moderno), e as transformações ocorrem posteriormente, dentro do próprio ambiente de armazenamento. Essa inversão não é meramente técnica; ela reflete uma mudança filosófica sobre onde e quando o processamento deve acontecer.

A principal diferença arquitetural reside no local da transformação. No ETL, a transformação ocorre em motores dedicados fora do data warehouse, consumindo recursos de servidores ETL. No ELT, o data warehouse ou data lake assume a responsabilidade pelo processamento, aproveitando sua capacidade de computação distribuída.

Fluxo ETL:
[Fonte] -> Extract -> Transform (servidor ETL) -> Load -> [Data Warehouse]

Fluxo ELT:
[Fonte] -> Extract -> Load -> [Data Lake/Warehouse] -> Transform (no destino)

2. A Evolução do Cenário de Dados: Por que o ELT surgiu?

O surgimento do ELT não foi acidental. Três forças principais impulsionaram essa mudança. Primeiro, o volume exponencial de dados gerados por aplicações web, IoT e redes sociais tornou inviável processar tudo em servidores ETL tradicionais. Segundo, a ascensão de data warehouses em nuvem como Snowflake, Google BigQuery e Amazon Redshift ofereceu poder computacional elástico e praticamente ilimitado. Terceiro, o custo de armazenamento caiu drasticamente — armazenar petabytes em um data lake como Amazon S3 ou Azure Data Lake Storage custa uma fração do que custava manter storages locais.

Antes, cada transformação custava caro em termos de hardware e licenciamento. Hoje, o modelo "pague pelo que usar" permite armazenar dados brutos e transformá-los sob demanda. O ELT também se beneficia da separação entre computação e armazenamento, característica dos principais data warehouses modernos.

Cenário em 2005:
- Volume médio: gigabytes
- Custo de armazenamento: US$ 10/GB/mês
- Transformação: servidores dedicados caros

Cenário em 2025:
- Volume médio: terabytes/petabytes
- Custo de armazenamento: US$ 0.02/GB/mês
- Transformação: computação elástica na nuvem

3. Comparação Técnica e de Performance

A escolha entre ETL e ELT impacta diretamente latência, throughput e custos. No ETL, a transformação antecipada reduz o volume de dados carregados, mas aumenta o tempo até o dado estar disponível para consumo. Cada nova requisição de negócio exige reprojetar o pipeline de transformação. No ELT, os dados brutos ficam disponíveis imediatamente após a carga, permitindo transformações sob demanda.

O gerenciamento de esquemas também difere. O ETL adota schema-on-write: define-se o esquema antes de carregar os dados. O ELT usa schema-on-read: os dados são armazenados em formato bruto (JSON, Parquet, Avro) e o esquema é aplicado no momento da leitura. Isso oferece flexibilidade para análises exploratórias, mas exige cuidado com qualidade de dados.

Exemplo de transformação ETL (antes da carga):
1. Extrair vendas de 10 lojas
2. Agregar por mês no servidor ETL
3. Carregar apenas 12 linhas (uma por mês)

Exemplo de transformação ELT (após a carga):
1. Extrair vendas de 10 lojas
2. Carregar 1 milhão de linhas brutas
3. Transformar via SQL no warehouse:
   SELECT loja, mes, SUM(vendas)
   FROM vendas_brutas
   GROUP BY loja, mes

4. Casos de Uso: Quando Escolher ETL vs. ELT

O ETL permanece relevante para sistemas legados que não suportam processamento pesado, ambientes com dados sensíveis onde a transformação deve ocorrer antes do armazenamento para garantir conformidade (GDPR, HIPAA), e cenários com largura de banda limitada onde enviar dados brutos é inviável.

O ELT brilha em big data analytics, ciência de dados e ambientes onde a agilidade é prioridade. Empresas que precisam explorar dados sem schema pré-definido, como startups de tecnologia ou departamentos de pesquisa, se beneficiam do ELT. Cenários híbridos são cada vez mais comuns: usa-se ELT para ingestão rápida de grandes volumes e ETL para dados críticos que exigem transformações complexas antes da carga.

Cenário híbrido:
- Pipeline diário: ELT para logs de servidor (10 TB/dia)
- Pipeline horário: ETL para transações financeiras (dados sensíveis)
- Orquestração: Apache Airflow coordenando ambos os fluxos

5. Ferramentas e Ecossistema Atual

O ecossistema de ferramentas reflete essa dualidade. Ferramentas clássicas de ETL como Informatica PowerCenter, Talend e Microsoft SSIS ainda dominam ambientes corporativos tradicionais, oferecendo conectores maduros e governança robusta. Para ELT moderno, plataformas como dbt (data build tool) permitem transformações baseadas em SQL dentro do warehouse. Ferramentas de ingestão como Fivetran, Airbyte e Stitch automatizam a extração e carga, deixando a transformação para o dbt.

A orquestração é unificada: Apache Airflow, Prefect e Dagster gerenciam pipelines independentemente do paradigma escolhido. O Airflow, por exemplo, permite criar DAGs que misturam tarefas ETL e ELT no mesmo fluxo.

Exemplo de pipeline com Airflow + dbt:
1. Tarefa extract_load: Airbyte carrega dados brutos no BigQuery
2. Tarefa transform: dbt executa modelos SQL no BigQuery
3. Tarefa validate: Great Expectations verifica qualidade
4. Tarefa notify: Slack notifica conclusão

6. Desafios e Boas Práticas na Implementação

Implementar ELT traz desafios específicos. A qualidade dos dados precisa ser verificada após a transformação, não antes — o que exige ferramentas como Great Expectations ou dbt tests. A linhagem dos dados (data lineage) torna-se crucial: saber de onde veio cada coluna e quais transformações sofreu. Estratégias de transformação incremental evitam reprocessar todo o dataset a cada execução, usando técnicas como incremental models no dbt ou partitions no Spark.

A segurança em ambientes ELT exige atenção: dados brutos podem conter informações sensíveis que precisam ser mascaradas antes de qualquer transformação. Boas práticas incluem aplicar criptografia em repouso, usar views com filtros de segurança e implementar row-level security no warehouse.

Transformação incremental com dbt:
{{ config(materialized='incremental') }}

SELECT
    id,
    data,
    valor
FROM {{ source('raw', 'vendas') }}
{% if is_incremental() %}
WHERE data > (SELECT MAX(data) FROM {{ this }})
{% endif %}

7. Tendências Futuras e o Papel da Engenharia de Dados

O futuro aponta para convergência. Arquiteturas lakehouse (Databricks, Apache Iceberg, Delta Lake) combinam a flexibilidade dos data lakes com o desempenho dos warehouses, tornando a distinção entre ETL e ELT menos relevante. O streaming ganha espaço: ferramentas como Kafka e Flink permitem transformações em tempo real, borrando ainda mais as fronteiras.

A automação via machine learning começa a otimizar pipelines: algoritmos sugerem particionamento, índices e estratégias de materialização. A inteligência artificial generativa promete revolucionar a modelagem — assistentes de código como GitHub Copilot já ajudam engenheiros a escrever transformações SQL e configurar pipelines.

O engenheiro de dados moderno precisa dominar ambos os paradigmas, entendendo quando cada um se aplica. A escolha não é binária: o melhor pipeline frequentemente combina elementos de ETL e ELT, adaptando-se às necessidades específicas de cada fonte de dados e caso de uso.

Referências