ETL e ELT: a história, os conceitos e as arquiteturas por trás da integração de dados

Sempre que você abre um dashboard de vendas, consulta um relatório financeiro ou recebe uma recomendação personalizada em um aplicativo, existe um processo invisível que reuniu informações de dezenas de sistemas diferentes. Esse trabalho de integração de dados é realizado por pipelines que seguem dois paradigmas principais: ETL e ELT. Embora a diferença entre eles pareça ser apenas a ordem de três letras, ela representa décadas de evolução na forma como armazenamos, processamos e analisamos dados.

Como e quando surgiu o ETL

O termo ETL remonta à década de 1970, quando as empresas passaram a precisar de uma forma padronizada de combinar dados de sistemas transacionais separados em um repositório central para análise. Nessa época, a IBM foi uma das pioneiras a aplicar o paradigma ETL para integrar dados de diferentes sistemas e bancos de dados, ainda em um contexto de processamento em lote e mainframes.

O ETL, porém, só ganhou seu propósito mais claro quando surgiu o conceito de data warehouse (armazém de dados), na década seguinte. William H. “Bill” Inmon, considerado o “pai do data warehousing”, foi decisivo na formulação dos conceitos e definições que abririam caminho para essa tecnologia, definindo o data warehouse como uma coleção de dados orientada por assunto, integrada, variável no tempo e não volátil — uma definição que se mantém atual até hoje. Segundo relatos sobre a origem do termo, Inmon já discutia os princípios do data warehouse e teria cunhado uma versão do termo ainda nos anos 1970, embora a prática como a conhecemos hoje tenha realmente se consolidado no final dos anos 1980, com um artigo da IBM Systems Journal de 1988 introduzindo o termo “business data warehouse”.

Foi justamente para alimentar esses data warehouses que o ETL se firmou como metodologia: o ETL surgiu como uma metodologia para viabilizar o movimento de dados dos bancos de dados operacionais para esses novos data warehouses. Bill Inmon também está entre os nomes associados à origem prática do processo: no início, os dados eram movidos manualmente para o warehouse por meio de programas escritos para acessar a fonte, localizar os dados necessários, transformá-los e carregá-los — um processo que Inmon percebeu ser extremamente demorado e trabalhoso, o que impulsionou a busca por automação.

Essa automação veio com a primeira geração de ferramentas de mercado: o final dos anos 1980 viu o surgimento de ferramentas automatizadas de ETL, como Informatica e IBM DataStage, que revolucionaram os fluxos de integração de dados, seguidas nos anos 1990 por soluções como Cognos e Microsoft SSIS. A própria IBM DataStage, uma das ferramentas mais tradicionais do mercado, tem origem na VMark Software Inc., empresa que também desenvolveu o banco de dados UniVerse.

Por que o ETL surgiu?

O ETL surgiu porque a infraestrutura da época impunha diversas limitações. Os sistemas operacionais, como ERPs e bancos de dados transacionais, eram desenvolvidos para registrar operações do dia a dia, não para responder consultas analíticas complexas. Além disso, os dados estavam espalhados entre departamentos diferentes, utilizando nomenclaturas e formatos incompatíveis. Como o armazenamento e o processamento eram extremamente caros, fazia muito mais sentido limpar e transformar os dados antes de enviá-los ao data warehouse, economizando recursos computacionais.

Como e quando surgiu o ELT

O ELT é um conceito mais recente e nasceu como resposta direta às limitações do ETL tradicional. Enquanto o ETL sempre existiu como ideia alternativa (transformar depois de carregar sempre foi tecnicamente possível), ele só se tornou prático e popular com a chegada da computação em nuvem e dos data warehouses de processamento massivamente paralelo (MPP). Como resume uma análise sobre o tema, o fator-chave que tornou o ELT viável foi o surgimento de data warehouses em nuvem com MPP, como Amazon Redshift, Google BigQuery e Snowflake, que passaram a oferecer armazenamento acessível para grandes volumes de dados e capacidade de processá-los sem necessidade de transformação prévia. Um segundo fator determinante foi o amadurecimento de frameworks de processamento: o desenvolvimento de estruturas de transformação e análise escaláveis, como Python, Apache Spark e R, tornou possível transformar grandes volumes de dados de forma rápida.

Isso quer dizer que o ELT, como prática difundida em larga escala, é essencialmente um fenômeno da década de 2010 em diante, acompanhando o crescimento de plataformas como Redshift (lançado em 2012), BigQuery (2010) e Snowflake (fundada em 2012). Diferentemente do ETL, o ELT não tem um “pai” único e reconhecido como Bill Inmon — ele surgiu de forma mais orgânica, como consequência natural da arquitetura de nuvem, sendo popularizado por fornecedores de data warehouse em nuvem e por ferramentas de transformação como o dbt (data build tool), lançado pela empresa que hoje se chama dbt Labs.

Por que o ELT surgiu?

O ELT surgiu quando essas limitações deixaram de existir. A computação em nuvem reduziu drasticamente o custo do armazenamento, enquanto plataformas como BigQuery, Snowflake e Redshift passaram a oferecer enorme capacidade de processamento. Dessa forma, tornou-se mais vantajoso armazenar todos os dados em seu estado original e realizar as transformações somente quando necessário. Ao mesmo tempo, ferramentas como o dbt popularizaram a ideia de tratar as transformações como código, facilitando testes, versionamento e manutenção dos pipelines.

Na arquitetura ELT, o processo seria diferente. Todas as vendas, cadastros de clientes, movimentações de estoque e demais informações seriam carregadas primeiro para um Data Lake ou Lakehouse exatamente como foram geradas pelos sistemas de origem. Somente depois equipes de BI, engenharia de dados ou ciência de dados criariam transformações específicas para cada necessidade, preservando os dados originais para futuras análises.

ETL vs. ELT: a diferença na prática

Embora os dois processos tenham o mesmo objetivo — integrar dados para análise — eles trabalham de maneiras diferentes.

No ETL, os dados são extraídos das fontes, passam por um processo completo de limpeza, padronização e transformação e somente depois são carregados no data warehouse. Isso significa que o ambiente de destino recebe apenas dados já preparados para consumo.

No ELT acontece exatamente o contrário. Os dados são carregados inicialmente em seu formato bruto para um data lake ou data warehouse moderno. Somente depois eles são transformados conforme a necessidade. Essa abordagem reduz o tempo de ingestão e permite que diferentes equipes reutilizem os mesmos dados para finalidades distintas.

Outra diferença importante está no local onde ocorre o processamento. Enquanto o ETL depende de um servidor ou ferramenta responsável pelas transformações, o ELT aproveita o próprio poder computacional do data warehouse em nuvem, executando transformações diretamente por meio de SQL, Spark ou outras tecnologias.

Essa mudança também trouxe maior flexibilidade. Como os dados originais permanecem armazenados, é possível criar novas regras de negócio sem precisar extrair novamente todas as informações da origem.

Imagine que a empresa descubra um erro na regra que calcula o faturamento líquido. Em um pipeline ETL tradicional, pode ser necessário executar novamente toda a extração e transformação dos dados para corrigir o histórico. Em uma arquitetura ELT, como os dados brutos continuam armazenados, basta alterar a regra de transformação e reprocessar as informações, sem precisar consultar novamente os sistemas de origem.

Onde ETL e ELT são utilizados

Os dois modelos aparecem em praticamente todas as áreas que trabalham com dados.

No Business Intelligence, pipelines alimentam dashboards de vendas, financeiro, logística e recursos humanos. Em ambientes corporativos, eles consolidam informações provenientes de ERPs, CRMs e outros sistemas em um único data warehouse.

Já em projetos de ciência de dados e machine learning, o ELT costuma ser a escolha preferida porque mantém os dados brutos disponíveis para experimentação e treinamento de modelos.

Em setores altamente regulados, como bancos, seguradoras e hospitais, o ETL ainda é muito utilizado, pois permite validar, mascarar e padronizar os dados antes que eles sejam armazenados.

Também é comum encontrar ELT em soluções de IoT, plataformas digitais e aplicações de streaming, onde milhares ou milhões de eventos precisam ser carregados rapidamente antes de serem processados.

Exemplo de uso:

Imagine uma rede de supermercados com centenas de lojas espalhadas pelo país. Cada loja registra milhares de vendas por dia em seu sistema de caixa (PDV), enquanto o estoque, o CRM e o sistema financeiro armazenam informações separadamente.

Em uma arquitetura ETL, todas essas informações seriam extraídas dos sistemas, passariam por um processo de limpeza e padronização — por exemplo, corrigindo nomes de produtos, removendo registros duplicados e convertendo moedas ou datas para um único formato — e somente depois seriam carregadas no Data Warehouse. Assim, os analistas acessariam apenas dados já tratados e prontos para criação de relatórios.

Na arquitetura ELT, o processo seria diferente. Todas as vendas, cadastros de clientes, movimentações de estoque e demais informações seriam carregadas primeiro para um Data Lake ou Lakehouse exatamente como foram geradas pelos sistemas de origem. Somente depois equipes de BI, engenharia de dados ou ciência de dados criariam transformações específicas para cada necessidade, preservando os dados originais para futuras análises.

Tecnologias e arquiteturas usadas

Ao longo das últimas décadas surgiram diversas ferramentas especializadas em ETL. Soluções tradicionais como Informatica PowerCenter, IBM DataStage, Microsoft SSIS, Talend e Pentaho dominaram o mercado corporativo durante muitos anos.

Com a popularização do ELT, um novo ecossistema apareceu. Ferramentas como Airbyte, Fivetran e Stitch passaram a simplificar a ingestão dos dados, enquanto o dbt se consolidou como uma das principais soluções para transformação dentro do próprio data warehouse. Plataformas como Snowflake, BigQuery, Redshift e Databricks assumiram o papel de motores de processamento, trabalhando em conjunto com data lakes baseados em Formato Delta.

Arquiteturas relacionadas:

A evolução do ETL e do ELT também trouxe diferentes arquiteturas de armazenamento. Durante muitos anos, o Data Warehouse clássico dominou o mercado, normalmente seguindo a abordagem proposta por Bill Inmon ou Ralph Kimball. Posteriormente surgiu o conceito de Data Lake, criado para armazenar grandes volumes de dados brutos com baixo custo. Mais recentemente apareceu o Lakehouse, que combina a flexibilidade do Data Lake com recursos tradicionalmente encontrados em Data Warehouses, como transações ACID, governança e otimização de consultas. Dentro desse contexto tornou-se bastante popular a arquitetura Medalhão, organizada nas camadas Bronze, Silver e Gold.

Conclusão

ETL e ELT não são “o antigo contra o novo” de forma simplista — são respostas de suas épocas às limitações de armazenamento e processamento disponíveis. O ETL nasceu nos anos 1970-80, ligado à consolidação dos data warehouses corporativos e a nomes como Bill Inmon; o ELT é filho da nuvem, viabilizado por data warehouses MPP como Snowflake, BigQuery e Redshift, e por ferramentas como o dbt, a partir dos anos 2010. Hoje, muitas empresas usam os dois modelos lado a lado, escolhendo ETL para dados sensíveis e regulados e ELT para grandes volumes e flexibilidade analítica.