Se você estiver criando um data pipeline para alimentar uma ferramenta de inteligência de negócios ou treinar um modelo de machine learning, uma das primeiras decisões que você precisa tomar é onde a transformação ocorre: antes ou depois de os dados chegarem ao seu warehouse. Isso significa que você deve escolher entre pipelines de extrair, transformar e carregar (ETL) e extrair, carregar e transformar (ELT).

A escolha determina com que rapidez os analistas podem acessar dados brutos, quanto de poder de processamento você está utilizando em cada etapa e com que facilidade pode se adaptar quando seu modelo de dados muda. O mercado global de ferramentas de data pipeline está projetado para valer $ 48,33 bilhões até 2030, e o ETL está perdendo espaço para o ELT e outros tipos de pipelines.

Abaixo, abordaremos como cada modelo funciona, quando o ETL ou o ELT faz mais sentido e como os conectores criados para essa finalidade se encaixam nas duas abordagens de fontes de dados específicas.

Destaques

• O ETL transforma os dados antes que cheguem ao destino. O ELT carrega dados brutos e os transforma dentro do warehouse usando sua própria computação.

• O ELT é o padrão adotado pela maioria das equipes de dados modernas. O ETL continua popular para destinos restritos, requisitos de governança rigorosos e pipelines herdados.

• Os conectores criados para fins específicos para fontes de dados específicas podem reduzir o risco de problemas na qualidade dos dados que conectores genéricos costumam apresentar.

Pipelines ETL vs. ELT: qual é a diferença?

ETL significa "extrair, transformar, carregar". Em um modelo ETL, você puxa os dados de um sistema de origem, executa-os em uma camada de transformação que os limpa, remodela e filtra, e, em seguida, carrega o resultado processado em um destino, como um data warehouse ou data mart.

Com o ETL, um mecanismo de processamento separado faz o trabalho pesado antes que os dados cheguem ao destino. O warehouse recebe dados estruturados e prontos para serem consultados, em vez dos registros originais brutos. Reprocessar a partir da origem significa extrair novamente ou manter uma cópia bruta separada em outro lugar.

O ELT, que significa "extrair, carregar, transformar", inverte as duas últimas etapas. Os dados brutos chegam ao destino primeiro e, em seguida, as transformações são executadas dentro do warehouse usando sua própria computação.

Essa mudança tornou-se prática quando os cloud data warehouses tornaram barato e rápido executar transformações Structured Query Language (SQL) em grandes conjuntos de dados. Em vez de um mecanismo de transformação separado entre a origem e o destino, seu warehouse passa a ser o ambiente de transformação.

Como funciona o ETL?

Um pipeline ETL é executado em três estágios, cada um com uma responsabilidade distinta.

Veja como o ETL funciona:

• Extrair: um conector ou trabalho de processamento extrai dados da origem, como um banco de dados, uma interface de programação de aplicações (API) de pagamento, uma plataforma software-as-a-service (SaaS) ou um arquivo plano (flat file). Esta etapa processa autenticação, paginação, lógica de recarregar incremental x total e limites de taxa.

• Transformar: os dados extraídos movem-se para uma camada de processamento onde são limpos (por exemplo, valores nulos processados, tipos convertidos), remodelados (por exemplo, junções, agregações, renomeação de colunas), filtrados e, às vezes, enriquecidos com dados de referência de outras origens.

• Carregar: o conjunto de dados processado é carregado no destino como uma substituição total, um upsert ou um acréscimo, dependendo de como o pipeline está configurado.

Ainda faz sentido usar o ETL nestas situações específicas:

• Destinos restritos: data warehouses mais antigos ou sistemas no local com computação limitada não conseguem executar grandes transformações de forma eficiente no local, de modo que carregar dados pré-transformados é a única opção realista.

• Requisitos de governança rigorosos: algumas organizações precisam garantir que as informações pessoalmente identificáveis ou dados financeiros sensíveis nunca cheguem ao warehouse em formato bruto. Transformar e mascarar os dados na origem satisfaz esse requisito arquitetonicamente.

• Ambientes de borda: Internet of Things (IoT) e sistemas integrados que enviam dados para uma infraestrutura central frequentemente não conseguem enviar payloads brutos grandes, o que torna a transformação local antes da transmissão uma necessidade prática.

• Dívida de pipeline herdado: muitas organizações maduras têm pipelines ETL que funcionam de forma confiável há anos. Recriá-los como ELT envolve um risco que pode não valer a pena correr.

Como funciona o ELT?

Os pipelines ELT extraem e carregam dados de origem em estado bruto ou levemente formatados diretamente no destino. As transformações ocorrem depois, acionadas em um cronograma ou sob demanda, utilizando a própria capacidade de processamento do warehouse.

Por exemplo, um conector pode extrair dados de uma origem e gravá-los em um esquema bruto no seu warehouse. Um engenheiro de análise de dados cria modelos de ferramentas de criação de dados (dbt) que leem desse esquema bruto, aplicam a lógica de negócios e criam tabelas limpas que ferramentas de inteligência de negócios (BI) podem consultar. Quando a lógica precisa mudar, ele apenas atualiza o modelo e o executa novamente em dados que já estão lá.

O ELT é uma escolha inteligente por estes motivos:

• Acesso mais rápido aos dados brutos: os dados chegam ao warehouse rapidamente, de modo que as equipes podem começar a explorá-los e validá-los antes que a camada de transformação seja concluída.

• Melhorias mais baratas: mudar uma transformação no ETL frequentemente significa modificar um pipeline, reprocessar e recarregar. No ELT, você apenas atualiza um modelo SQL e o executa novamente em dados que já tem.

• Computação em escala do warehouse: cloud warehouses são criados para processar grandes conjuntos de dados rapidamente, o que significa que você está aplicando computação pesada à transformação em vez de aumentar uma camada de middleware de forma independente.

• Histórico bruto completo: como os dados brutos estão sempre no warehouse, você pode derivar qualquer tabela downstream do zero novamente, o que é importante quando as definições de negócios mudam ou quando você precisa depurar um problema de qualidade de dados.

Como escolher entre ETL e ELT?

Grandes organizações costumam executar ambos os modelos de processamento de dados em paralelo para fontes diferentes. As necessidades da sua organização ajudarão a decidir qual é o método mais adequado.

Veja o que você precisa considerar.

Volume e velocidade dos dados

Dados de alto volume e alta frequência geralmente favorecem um pipeline de dados ELT. Os cloud data warehouses lidam bem com isso, e o custo de executar um mecanismo de transformação pesado na origem cresce rapidamente. Em contrapartida, a conta de computação do seu data warehouse aumenta quando as transformações são pesadas, e armazenar dados brutos traz custos.

Pipelines de menor volume com lógica de transformação estável e bem definida podem continuar no ETL sem muitos problemas.

Propriedade da transformação

Se suas transformações forem baseadas em SQL e gerenciadas por engenheiros de análise que precisam se adaptar rapidamente, o ELT com dbt ou uma ferramenta semelhante provavelmente será a melhor opção.

Se suas transformações forem codificadas em Python ou Java e gerenciadas por uma equipe de engenharia de dados, o ETL pode se encaixar naturalmente em sua cadeia de ferramentas existente.

Acesso a dados brutos

Se os analistas precisarem de acesso aos dados brutos de origem (por exemplo, para exploração ad hoc, auditoria ou porque a lógica de transformação ainda está em desenvolvimento), o ELT é o padrão recomendado. Pipelines ETL que não preservam dados brutos dificultam a adaptação desse tipo de acesso.

Governança e conformidade

Se dados específicos precisarem ser mascarados ou anonimizados antes de chegarem a um destino compartilhado, o ETL oferece controle arquitetônico sobre esse requisito.

O ELT pode atender muitos dos mesmos requisitos por meio de segurança em nível de coluna e controles de acesso em nível de data warehouse, mas a implementação difere e vale a pena analisá-la em relação às suas obrigações de conformidade.

Fluxo de trabalho da equipe

Uma equipe com alta fluência em SQL e hábitos de controle de versão em torno do dbt extrairá mais valor de uma configuração ELT do que mantendo um pipeline ETL personalizado que não foi criado por ela. A compatibilidade com a forma como sua equipe trabalha é um fator legítimo.

Como os conectores de dados se encaixam em pipelines ETL e ELT?

Ferramentas ETL e ELT genéricas lidam com uma ampla variedade de origens por meio de conectores configuráveis. Essa abrangência é útil, mas envolve prós e contras.

Os dados de pagamentos são um bom exemplo. O modelo de dados da Stripe abrange eventos, cobranças, reembolsos, contestações, transações de saldo, clientes, assinaturas e faturas. Um conector genérico que não acompanha o controle de versão da API da Stripe ou que processa a lógica de sincronização incremental incorretamente pode produzir erros difíceis de detectar até que afetem um dashboard ou uma reconciliação financeira.

O Stripe Data Pipeline resolve isso diretamente:

• Criado e mantido pela Stripe: como a Stripe é proprietária do conector e reflete a infraestrutura interna da Stripe diretamente, você pode sincronizar dados de forma confiável e contínua, garantindo integridade e precisão, independentemente da quantidade de dados que tenha e sem limites de taxa da API.

• Sincronização direta com o warehouse: os dados são movidos para o Amazon Redshift, Snowflake, Databricks e muito mais, sem passar por um conector de terceiros, o que mantém dados financeiros sensíveis fora de infraestruturas de fornecedores adicionais.

• Conjunto de dados completo da Stripe: a sincronização abrange objetos da Stripe, relatórios financeiros pré-criados e conjuntos de dados curados para acelerar a análise e os relatórios.

• Configuração leve: a conexão é configurada no Dashboard da Stripe, sem precisar de código (no-code). Se você já executa pipelines ELT para outras origens, os dados da Stripe seguem o mesmo padrão.