ETL vs ELT: desmistificando as transformações de dados

Você ouviu seu colega falar sobre "pipeline de ETL" e ficou na dúvida se era um processo, uma ferramenta ou alguma sigla de linguagem de programação? Ou já viu o termo "ELT" aparecer em uma vaga de emprego e se perguntou se era erro de digitação?

Não é. ETL e ELT são dois termos distintos de movimentação e transformação de dados e entender a diferença entre eles é essencial para qualquer profissional que trabalha com dados.

Mais do que decorar a sigla, você vai entender por que a ordem das letras importa, em qual abordagem o Power Query se encaixa, quando cada paradigma faz sentido e o que isso significa para a forma como você estrutura seus projetos de dados no dia a dia.

1. O problema que os dois paradigmas resolvem

Antes de entender ETL e ELT, é preciso entender o problema que eles resolvem:

Dados corporativos raramente nascem prontos para análise. Eles estão espalhados em sistemas diferentes: um ERP, um CRM, planilhas enviadas por e-mail, arquivos de texto gerados por sistemas legados, APIs de parceiros. Cada fonte fala uma língua diferente: formatos de data distintos, codificações incompatíveis, chaves de identificação que não coincidem entre sistemas.

Para que esses dados possam ser analisados juntos em um único relatório, eles precisam passar por um processo de movimentação e transformação. É exatamente aí que entram ETL e ELT, dois caminhos para resolver o mesmo problema, mas com lógicas opostas sobre onde e quando a transformação acontece.

2. ETL: Extrair, Transformar e depois Carregar

ETL é a sigla para Extract, Transform, Load (Extrair, Transformar e Carregar). É o paradigma mais antigo e mais consolidado na história da engenharia de dados.

O fluxo funciona em três etapas sequenciais e obrigatórias:

2.1 Extract (Extrair)

Os dados são coletados das fontes de origem: bancos de dados relacionais, arquivos .csv, APIs, sistemas ERP e movidos para uma área temporária de processamento, geralmente chamada de staging area. Nessa etapa, os dados chegam no seu estado bruto, sem nenhuma modificação.

Leia também: Dado bruto x Dado tratado x Informação: entenda as diferenças

2.2 Transform (Transformar)

Ainda fora do destino final, os dados passam por todo o processo de limpeza, padronização, enriquecimento e estruturação:

• Colunas são renomeadas,
• Tipos de dados são corrigidos,
• Registros duplicados são removidos,
• Tabelas de diferentes origens são cruzadas e unificadas por chaves comuns,
• Dentre outras diversas trasnformações possíveis.

Apenas após essas etapas, podemos dizer que os dados estão "prontos".

2.3 Load (Carregar)

Somente os dados já transformados são carregados no destino final, como em um Data Warehouse, um modelo de dados do Power BI, ou qualquer outro repositório analítico.

Como o Power Query implementa o ETL

O Power Query é, por design, uma ferramenta de ETL. Quando você clica em Obter Dados e depois em Transformar Dados no Power BI Desktop, está iniciando exatamente esse fluxo:

1. Extract: o Power Query conecta à fonte (Excel, SQL Server, API, etc.) e traz os dados em estado bruto para o editor.
2. Transform: você aplica etapas de transformação como remover colunas, alterar tipos, mesclar tabelas, filtrar linhas usando a interface visual ou a linguagem M diretamente.
3. Load: ao clicar em Fechar e Aplicar, os dados transformados são carregados no modelo de dados do Power BI, onde o DAX poderá trabalhar sobre eles.

💡 Ponto importante: O Power Query não altera a fonte original. Ele registra uma sequência de etapas de transformação (visível no painel Etapas Aplicadas) que é executada a cada atualização, sempre partindo do dado bruto. Isso garante rastreabilidade e reversibilidade, o que significa se uma etapa estiver errada, você a remove sem perder o dado original.

Leia também: Decifrando o Power Query #1: Entendendo a interface e o fluxo de trabalho

3. ELT: Extrair, Carregar e só depois Transformar

ELT é a sigla para Extract, Load, Transform (Extrair, Carregar e Transformar). A diferença em relação ao ETL parece pequena na sigla, mas representa uma mudança fundamental de arquitetura.

No ELT, a ordem de operação é outra:

1. Extract: os dados são extraídos das fontes de origem, igualmente em estado bruto.
2. Load: os dados brutos são carregados diretamente no destino final, geralmente um Data Lake ou um Data Warehouse em nuvem, sem transformação prévia.
3. Transform: a transformação acontece dentro do destino, aproveitando o poder de processamento da plataforma de nuvem para manipular os dados já armazenados.

Por que essa inversão existe?

O ELT surgiu como resposta a um novo contexto tecnológico: o advento de plataformas de dados em nuvem com capacidade de processamento massivo e custo de armazenamento cada vez mais baixo como o Microsoft Azure Synapse Analytics, o Google BigQuery e o Amazon Redshift.

No paradigma ETL tradicional, a transformação acontecia antes da carga porque armazenar dados brutos era caro e lento. Manter um grande volume de dados não transformados em um Data Warehouse on-premises custava muito em hardware e licenciamento.

Com a nuvem, esse cálculo mudou. Armazenar terabytes de dados brutos em um Data Lake passou a ser viável. E processar transformações complexas diretamente em plataformas distribuídas passou a ser mais eficiente do que pré-processar tudo em um servidor intermediário.

4. As diferenças técnicas e práticas entre ETL e ELT

Entender as diferenças na teoria é importante. Mas saber quando cada abordagem faz sentido na prática é o que realmente agrega valor ao projeto.

Quando o ETL faz mais sentido

• Projetos de médio porte com fontes de dados estáveis e bem definidas
• Ambientes onde os dados brutos não precisam ser preservados após o tratamento
• Times com maior familiaridade com ferramentas visuais como o Power Query
• Empresas que ainda não migraram sua infraestrutura para a nuvem
• Casos em que a privacidade e o mascaramento de dados sensíveis precisam ocorrer antes da carga (o dado bruto nunca chega ao destino)

Quando o ELT faz mais sentido

• Projetos com grande volume de dados que se beneficiam do poder de processamento distribuído da nuvem
• Ambientes onde a reutilização do dado bruto é estratégica: diferentes times podem aplicar diferentes transformações sobre a mesma base
• Empresas com infraestrutura em nuvem consolidada (Azure, AWS, GCP)
• Times com engenheiros de dados capazes de escrever SQL avançado e gerenciar pipelines em plataformas como dbt (data build tool) ou Azure Data Factory

⚠️ Atenção: ELT não é uma versão "mais moderna" ou "melhor" do ETL. São paradigmas diferentes para contextos diferentes. Escolher ELT para um projeto de pequeno porte sem infraestrutura de nuvem é como usar um caminhão para fazer compras no mercado: tecnicamente funciona, mas não faz sentido.

5. Onde o Microsoft Fabric se posiciona nesse cenário

O Microsoft Fabric foi projetado para suportar ambos os paradigmas, dependendo do componente utilizado. Uma plataforma unificada de dados da Microsoft lançada em 2023.

Dentro do Fabric, o fluxo pode ser configurado de diferentes formas:

Pipeline ETL tradicional com Power Query / Dataflows Gen2

Para times que já conhecem o Power Query, o Dataflows Gen2 dentro do Fabric permite aplicar transformações visuais (no estilo ETL) antes de carregar os dados no modelo ou no Lakehouse. É a porta de entrada mais natural para analistas que vêm do Power BI Desktop.

Pipeline ELT com Data Factory + Lakehouse

Para volumes maiores, o Data Factory no Fabric extrai e carrega dados brutos em um Lakehouse (armazenamento de dados em formato aberto Delta Lake). As transformações são então aplicadas diretamente sobre esses dados usando Spark notebooks, SQL Analytics Endpoint ou pipelines automatizados.

Warehouse SQL com semântica ELT

O Synapse Data Warehouse dentro do Fabric permite que engenheiros de dados escrevam transformações em T-SQL diretamente sobre os dados armazenados: ELT puro, com a familiaridade do SQL.

💡 Disponibilidade: Os recursos do Microsoft Fabric estão disponíveis a partir da licença Power BI Premium Per User (PPU) ou em workspaces com capacidade Fabric (F SKU). O Power BI Desktop e a licença Free não dão acesso ao Fabric.

Leia também: Licenças do Power BI: tipos, custos e diferenças entre Free, Pro e Premium

6. Dica de Ouro / Performance: transforme o mais cedo possível e no lugar certo

Um dos princípios mais importantes da engenharia de dados moderna é conhecido como a Máxima de Roche, formulada por Matthew Roche, do time de Customer Advisory do Microsoft Fabric:

"Os dados devem ser transformados o mais longe possível da análise (upstream) e o mais próximo possível de onde serão utilizados."

Na prática, isso significa:

Hierarquia ideal de transformação:

Fonte de dados (SQL, API, ERP)
    ↓  → Transformações pesadas aqui (filtragem de volume, joins complexos)
Staging / Data Lake
    ↓  → Limpeza, padronização, tipagem aqui (Power Query / dbt)
Modelo de dados (Power BI / Fabric)
    ↓  → Cálculos analíticos dinâmicos aqui (Medidas DAX)
Visualização (Relatório / Dashboard)

O que NÃO fazer:

• ❌ Usar Colunas Calculadas em DAX para concatenar ou tratar texto: isso infla o modelo e degrada a performance. Faça isso no Power Query.
• ❌ Carregar tabelas inteiras com centenas de colunas quando você usa apenas 10. Filtre na origem ou no Power Query antes de carregar.
• ❌ Aplicar transformações pesadas em Medidas DAX que poderiam ser resolvidas durante o ETL: cada clique no relatório recalcula a Medida.

O que fazer:

• ✅ Filtre linhas desnecessárias na etapa de conexão com a fonte (via consulta SQL ou parâmetros de API), antes mesmo de chegar ao Power Query
• ✅ Use o Power Query para limpeza, tipagem e padronização: é para isso que ele foi projetado
• ✅ Reserve o DAX exclusivamente para cálculos que precisam responder dinamicamente ao contexto de filtros do relatório

7. Um exemplo completo: o mesmo projeto nos dois paradigmas

Para tornar a diferença concreta, considere o seguinte cenário. Uma empresa de varejo quer analisar vendas por produto, filial e período, combinando dados de três fontes: ERP (SQL Server), planilhas de metas (Excel) e cadastro de fornecedores (API REST).

Abordagem ETL (com Power Query)

1. Extract: Power Query conecta ao SQL Server, ao Excel e à API
2. Transform (no Power Query, antes de carregar):

• Remove colunas irrelevantes das três fontes
• Padroniza nomes de filiais (a API usa "loja_03", o SQL usa "FL003", o Excel usa "Filial 3")
• Cruza cadastro de fornecedores com produtos via chave ID_PRODUTO
• Converte datas para o tipo correto
• Filtra apenas registros do último ano

3. Load: modelo do Power BI recebe apenas tabelas limpas, tipadas e relacionadas
4. DAX: medidas calculam variações percentuais, comparativos com metas e rankings

Resultado: arquivo .pbix leve, modelo limpo, relatório rápido. Solução adequada para um time de analistas de dados sem infraestrutura de nuvem dedicada.

Abordagem ELT (com Microsoft Fabric)

1. Extract + Load: Data Factory extrai os dados brutos das três fontes e deposita tudo no Lakehouse em formato Delta, sem nenhuma transformação
2. Transform (dentro do Fabric, após a carga):

• Engenheiro de dados aplica transformações em Spark notebooks ou dbt diretamente no Lakehouse
• Cria tabelas dimensionais e fatos já prontas
• As transformações são versionadas e documentadas como código

3. Semantic Model: o Power BI conecta ao Lakehouse já transformado e monta o modelo analítico
4. DAX: medidas calculam os KPIs sobre uma base já estruturada e escalável

Resultado: infraestrutura robusta e escalável, dado bruto sempre preservado para auditoria, múltiplos times podem usar a mesma base com transformações diferentes. Solução adequada para organizações com engenharia de dados dedicada e infraestrutura Fabric.

8. ETL e ELT não são excludentes

Uma confusão comum é tratar ETL e ELT como opostos absolutos, como se uma empresa precisasse escolher um e abandonar o outro para sempre.

Na prática, organizações maduras em dados frequentemente usam os dois paradigmas em camadas diferentes do mesmo pipeline:

• O Data Factory (ELT) traz dados brutos de dezenas de fontes para o Lakehouse
• O Power Query / Dataflows (ETL) aplica transformações visuais sobre uma seleção desses dados para construir modelos específicos de departamentos
• O DAX no Power BI gera os cálculos analíticos dinâmicos sobre esses modelos

Cada camada usa a ferramenta e o paradigma mais adequado ao que precisa fazer. Isso é o que separa uma arquitetura de dados improvisada de uma arquitetura de dados pensada para crescer.

Qual o próximo passo?

Agora que você entende a diferença entre ETL e ELT, e onde cada abordagem faz sentido, o próximo passo natural é aprofundar o conhecimento na ferramenta que implementa o ETL no ecossistema Microsoft: o Power Query.

É no Power Query que você vai colocar em prática os conceitos de extração, transformação e carga de forma visual, sem precisar escrever código na maior parte do tempo e com total rastreabilidade de cada etapa aplicada.

Leia também: Decifrando o Power Query #2: Guia Arquivos - Configurações Locais x Configurações Gerais

Leia também: Como destravar o verdadeiro poder do Power BI - Integrando dados de fontes distintas

📌 Nota sobre versões: Os componentes do Microsoft Fabric descritos neste artigo referem-se à plataforma lançada em disponibilidade geral em Abril de 2026. Funcionalidades específicas podem variar conforme atualizações mensais da Microsoft. Consulte sempre a documentação oficial do Microsoft Fabric para verificar o estado atual de cada recurso.