Os pipelines de dados costumavam seguir uma sequência rígida: extrair dados dos sistemas de origem, transformá-los em um formato limpo e estruturado e, por fim, carregar o resultado em um banco de dados. Essa sequência — extração, transformação e carregamento ou ETL — fazia sentido quando o armazenamento era caro e os sistemas de destino não tinham capacidade para realizar processamento intensivo.

Mas os data warehouses em nuvem mudaram esse cenário, e o ELT (extração, carregamento e transformação) se tornou o padrão adotado por muitas equipes de análise. Embora o ETL tradicional ainda mantenha quase 40% de participação de mercado, ele vem perdendo espaço rapidamente para outros tipos de pipeline de dados, como o ELT.

A seguir, explicamos o que é ELT, como ele funciona e em quais situações é ou não adequado.

Destaques

• Um processo ELT (extração, carregamento e transformação) carrega primeiro os dados brutos em um data warehouse em nuvem e depois os transforma. Isso oferece aos analistas acesso mais rápido aos dados e maior flexibilidade para aprimorar modelos.

• Data warehouses em nuvem são especialmente adequados para ELT porque separam armazenamento de processamento computacional, escalam elasticamente e permitem que analistas escrevam a lógica de transformação usando SQL (Structured Query Language).

• Trabalhar com um provedor de pagamentos que sincroniza dados diretamente com o seu data warehouse, sem passar por infraestrutura de terceiros, reduz a complexidade do pipeline e a exposição a riscos de segurança.

O que é ELT e como ele funciona?

ELT (extração, carregamento e transformação) é um padrão de integração de dados baseado em três etapas: extrair dados dos sistemas de origem, carregá-los em formato bruto em um destino centralizado e transformá-los dentro desse destino para análises, relatórios ou Machine learning.

Veja como um fluxo de trabalho ELT normalmente funciona na prática:

• Extração: um conector ou processo de pipeline obtém registros de um sistema de origem, de forma incremental, programada ou acionada por eventos, e os grava no destino em sua estrutura original.

• Carregamento: as tabelas brutas são armazenadas no data warehouse, geralmente em um esquema dedicado, preservando nomes de campos, tipos de dados e relacionamentos exatamente como existiam na origem.

• Transformação: a lógica de transformação é executada dentro do próprio data warehouse. Ferramentas baseadas em SQL, como o data build tool (dbt), permitem que as equipes versionem esses modelos, realizem testes e construam conjuntos de dados sobre a camada bruta.

Como os dados brutos são carregados primeiro, os analistas podem consultá-los imediatamente, e diversas visualizações podem ser criadas a partir de uma única fonte sem necessidade de nova extração. Se um modelo de transformação estiver incorreto, basta reescrevê-lo e executá-lo novamente sobre dados já armazenados no data warehouse.

Como o ELT difere do ETL na prática?

A principal diferença arquitetural entre ETL e ELT está no local onde ocorre a transformação: fora do destino no ETL e dentro do destino no ELT.

Estas são as principais diferenças entre ETL e ELT:

• Disponibilidade dos dados: em um pipeline ETL, os dados não podem ser consultados até serem transformados e carregados. No ELT, os dados brutos são carregados primeiro, permitindo que analistas trabalhem com eles enquanto os processos de transformação são executados separadamente.

• Velocidade de aprimoramento: alterar uma transformação em um pipeline ETL frequentemente exige reconstruir o próprio pipeline. No ELT, basta atualizar um modelo SQL e executá-lo novamente sobre dados que já estão armazenados no data warehouse.

• Local de processamento: as transformações ETL são executadas na infraestrutura do pipeline, como um servidor ou serviço dedicado. Já as transformações ELT utilizam os recursos computacionais do data warehouse, que escalam elasticamente e já fazem parte da infraestrutura contratada.

• Preservação dos dados brutos: o ETL normalmente descarta estados intermediários após gerar o resultado transformado. O ELT preserva a camada bruta por padrão, permitindo reprocessar dados históricos quando os requisitos mudam.

Por que o ELT se adapta tão bem aos modernos data warehouses em nuvem?

As características a seguir tornam o ELT uma escolha natural para data warehouses em nuvem:

• Separação entre armazenamento e processamento: plataformas como Snowflake e BigQuery cobram separadamente pelo armazenamento e pelas consultas. Você pode armazenar grandes volumes de dados brutos e consumir recursos computacionais apenas quando os processos de transformação forem executados.

• Escalabilidade elástica: é possível provisionar a capacidade computacional necessária, executar o processamento e reduzi-la novamente. O próprio data warehouse gerencia a paralelização das tarefas.

• Armazenamento colunar: data warehouses em nuvem armazenam dados em formato colunar, tornando consultas analíticas, como agregações, filtros e junções entre grandes conjuntos de dados, muito mais rápidas do que em armazenamentos orientados a linhas.

• SQL nativo: a maioria dos analistas e engenheiros de análise já domina SQL. Executar transformações dentro do data warehouse permite que as pessoas que entendem a lógica de negócios escrevam e mantenham diretamente os modelos de transformação.

Quando o ELT é uma boa opção?

O ELT não é a solução ideal para todos os pipelines de dados, mas se adapta bem a um conjunto específico de condições.

Veja em quais situações o ELT costuma funcionar melhor:

• Conjuntos de dados grandes ou em rápido crescimento: se você sincroniza milhões de eventos por dia, executar transformações antes do carregamento exige uma infraestrutura robusta de pipeline. Carregar os dados brutos e transformá-los dentro do data warehouse é mais prático em grande escala.

• Lógica de transformação frequentemente alterada: quando as transformações ficam armazenadas no data warehouse como modelos SQL, mudanças nos requisitos analíticos não exigem a reimplantação da infraestrutura do pipeline.

• Múltiplos casos de uso posteriores: os dados brutos armazenados no data warehouse podem alimentar simultaneamente dashboards de business intelligence, repositórios de recursos para machine learning e relatórios operacionais. Você cria um único pipeline e modela os dados de forma diferente para cada usuário.

• Equipes com capacidade de engenharia analítica: o ELT transfere a responsabilidade pelas transformações para a camada analítica. Equipes que utilizam ferramentas como dbt tendem a se adaptar muito bem a esse modelo.

O ELT não é uma boa opção nas seguintes situações:

• Restrições regulatórias sobre dados brutos: alguns ambientes de saúde e dados financeiros proíbem o armazenamento de dados sensíveis antes de mascaramento ou filtragem. Nesses casos, as transformações precisam ocorrer antes do carregamento.

• Esquemas de destino rígidos: se o sistema de destino não consegue acomodar dados brutos ou semiestruturados, a abordagem de carregar primeiro adotada pelo ELT cria mais problemas do que resolve.

• Conjuntos de dados pequenos e estáveis: se um pipeline ETL simples já atende às necessidades, adicionar uma infraestrutura de transformação dentro do data warehouse representa um custo adicional com pouco benefício.

Quais desafios acompanham o ELT?

Carregar dados brutos em um data warehouse é uma abordagem poderosa, mas pode trazer desafios relacionados à governança e aos custos.

Considere os seguintes desafios potenciais do ELT.

Controle de acesso

Tabelas brutas frequentemente contêm dados que não devem estar amplamente acessíveis, como Informações pessoalmente identificáveis (PII), registros financeiros ou identificadores internos. Em ETL, campos sensíveis podem ser mascarados ou removidos antes mesmo que os dados cheguem ao destino. Já no ELT, os dados são carregados primeiro. Sem segurança em nível de linha, mascaramento de colunas ou funções de acesso ao data warehouse rigorosamente definidas, analistas podem consultar campos que não deveriam visualizar.

Qualidade dos dados

Dados incorretos provenientes de sistemas de origem são carregados no data warehouse antes da execução de qualquer validação. Campos nulos, registros duplicados, alterações de esquema e incompatibilidades de tipo podem se propagar para modelos subsequentes caso não sejam implementados testes de qualidade na camada de transformação, utilizando a estrutura de testes do dbt ou recursos nativos de qualidade de dados do próprio data warehouse.

Gestão de custos

Os trabalhos de transformação utilizam recursos computacionais do data warehouse, e consultas SQL mal escritas, como varreduras sem limite, ausência de filtros de partição ou atualizações completas redundantes de tabelas, podem gerar custos significativos. Definir limites de custos para consultas, utilizar modelos incrementais sempre que possível e monitorar o consumo computacional são práticas que valem a pena incorporar desde o início.

Como um fluxo de trabalho ELT lida com dados de pagamentos?

Muitas equipes criam uma integração personalizada com a API de seu provedor de pagamentos ou utilizam um conector de terceiros. Mas integrações personalizadas exigem manutenção contínua à medida que a API evolui, e conectores de terceiros significam encaminhar dados financeiros sensíveis pela infraestrutura de outro fornecedor.

O Stripe Data Pipeline é uma opção nativa integrada diretamente ao Stripe Dashboard. Ele sincroniza dados e relatórios da Stripe com Snowflake, Databricks, Amazon Redshift e outras plataformas em apenas alguns cliques. No-code, configuração de conectores nem credenciais adicionais para gerenciar. A sincronização é executada pela própria infraestrutura da Stripe, de modo que nenhum sistema de terceiros manipula seus dados financeiros durante a transferência.

Alguns detalhes importantes:

• Cobertura histórica: o Stripe Data Pipeline inclui dados históricos desde a criação da sua conta Stripe, e não apenas a partir da ativação da sincronização.

• Esquema: os dados são carregados em tabelas que refletem o modelo de dados da Stripe, como cobranças, clientes e assinaturas, facilitando a criação de modelos de transformação sem necessidade de extensa limpeza da camada bruta.

• Integridade dos dados: além dos dados brutos dos objetos, o Stripe Data Pipeline inclui acesso a relatórios financeiros pré-configurados e conjuntos de dados selecionados, o que acelera a geração de relatórios e reduz o trabalho de transformação em casos de uso comuns, como receita mensal recorrente (MRR) e análise de fraudes.