ETL vs ELT:Nós postulamos, você julga

Divulgação completa:Como este artigo é de autoria de uma empresa centrada em ETL com seu ponto forte na manipulação de big data fora dos bancos de dados, o que se segue não parecerá objetivo para muitos. No entanto, ainda pretende apresentar o que pensar e abrir o espaço para discussão.

Desde o início, os arquitetos de data warehouse (DWA) foram encarregados de criar e preencher um data warehouse com dados de origem e formatação diferentes. Devido ao crescimento dramático nos volumes de dados, esses mesmos DWAs são desafiados a implementar suas operações de integração e preparação de dados com mais eficiência. A questão de saber se a transformação de dados ocorrerá dentro ou fora do banco de dados de destino tornou-se crítica devido ao desempenho, conveniência e consequências financeiras envolvidas.

Nas operações ETL (extrair, transformar, carregar), os dados são extraídos de diferentes fontes, transformados separadamente e carregados em um banco de dados DW e possivelmente em outros destinos. No ELT, as extrações são alimentadas no banco de dados de teste único que também trata das transformações.

O ETL continua predominante porque o mercado floresce com players comprovados como Informatica, IBM, Oracle — e IRI com Voracity, que combina FACT (Fast Extract), transformações CoSort ou Hadoop e carregamento em massa na mesma GUI do Eclipse — para extrair e transformar dados. Essa abordagem evita sobrecarregar os bancos de dados projetados para armazenamento e recuperação (otimização de consulta) com a sobrecarga da transformação de dados em grande escala.

No entanto, com o desenvolvimento de novas tecnologias de banco de dados e dispositivos de hardware como o Oracle Exadata, que podem lidar com transformações 'em uma caixa', o ELT pode ser uma solução prática em determinadas circunstâncias. E há benefícios específicos para isolar as camadas de teste (carga) e semântica (transformar).

Uma vantagem citada do ELT é o isolamento do processo de carga do processo de transformação, pois remove uma dependência inerente entre esses estágios.

Observamos que a abordagem ETL do IRI os isola de qualquer maneira porque o Voracity organiza os dados no sistema de arquivos (ou HDFS). Qualquer fragmento de dados vinculado ao banco de dados pode ser adquirido, limpo e transformado externamente antes de um carregamento (pré-ordenado). Isso tira o fardo das transformações em grande escala do banco de dados (assim como ferramentas de BI/analíticas, etc.).

Volumes de dados e orçamentos geralmente determinam se um DWA deve desenvolver uma solução ETL ou ELT. Em seu artigo do blog do ITToolbox "Então, o que é melhor, ETL ou ELT?", Vincent McBurney apresenta seus prós e contras para qualquer uma das abordagens, que repeti aqui abaixo e, em seguida, segui cada uma com uma resposta típica de que IRI ETL usuários orientados fazem questão (de acordo com minha ressalva inicial de subjetividade):

Pros ETL

O ETL pode equilibrar a carga de trabalho e compartilhar a carga de trabalho com o RDBMS - e, de fato, remover essa carga de trabalho transformando dados por meio do programa SortCL ou Hadoop sem codificação no Voracity

O ETL pode realizar operações mais complexas em diagramas de fluxo de dados únicos por meio de mapas de dados, como o mapeamento Voracity e diagramas de fluxo de trabalho que também abstraem curtos e abertos Scripts 4GL x SQL

O ETL pode ser dimensionado com hardware separado - em caixas de commodities, você pode adquirir e manter-se a custos muito mais baixos do que os dispositivos de um único fornecedor

O ETL pode lidar com particionamento e paralelismo independentemente do modelo de dados, layout do banco de dados e arquitetura do modelo de dados de origem – por meio dos trabalhos CoSort SortCL da Voracity não precisa ser particionado…

O ETL pode processar dados in-stream, pois transfere da origem para o destino - ou em lote, se isso também fizer sentido

A ETL não exige a colocação de conjuntos de dados para fazer seu trabalho - permitindo que você mantenha plataformas de fonte de dados existentes sem preocupações de sincronização de dados

ETL captura grandes quantidades de linhagem de metadados hoje - quão bem ou intuitivamente um banco de dados de teste pode fazer isso?

ETL pode ser executado em hardware SMP ou MPP - que novamente você pode gerenciar e explorar de forma mais econômica, sem se preocupar com contenção de desempenho com o banco de dados

A ETL processa as informações linha por linha e isso parece funcionar bem com a integração de dados em produtos de terceiros. melhor ainda bloco completo, tabela ou arquivo(s) por vez, que o Voracity executa em volume.

Contras ETL

É necessário investimento adicional em hardware para mecanismos ETL - a menos que você o execute no(s) servidor(es) de banco de dados

Custo extra de construção de sistema ETL ou licenciamento de ferramentas ETL – que ainda são mais baratas em relação aos dispositivos ELT, mas ainda mais baratas são ferramentas IRI como Voracity que combinam Fast Extract (FACT) e CoSort para acelerar ETL sem tanta complexidade

Possível redução de desempenho da abordagem baseada em linhas - certo, e por que a capacidade da Voracity de perfilar, adquirir, transformar e gerar dados em partes maiores é mais rápida

Habilidades especializadas e curva de aprendizado necessárias para implementar a ferramenta ETL - a menos que você esteja usando uma GUI ergonômica como a Voracity, que oferece várias opções de design de trabalho no mesmo Eclipse IDE

Flexibilidade reduzida devido à dependência do fornecedor da ferramenta ETL - Não sei como isso pode ser melhorado confiando em um único fornecedor de ELT/dispositivo; a independência do fornecedor não é a chave para a flexibilidade e economia de custos?

Os dados precisam passar por mais uma camada antes de chegar ao data mart, a menos que o mart seja apenas outra saída do processo ETL, típico de operações Voracity de vários destinos.

ELT profissionais

O ELT aproveita o hardware do mecanismo RDBMS para escalabilidade, mas também tributa os recursos de banco de dados destinados à otimização de consultas. As transformações CoSort e Hadoop no Voracity aproveitam algoritmos de dimensionamento linear e consolidação de tarefas, não a memória ou recursos de E/S do DB

O ELT mantém todos os dados no RDBMS o tempo todo - o que é bom, desde que os dados de origem e destino estejam no mesmo banco de dados

A ELT é paralelizada de acordo com o conjunto de dados, e a E/S do disco geralmente é otimizada no nível do mecanismo para uma taxa de transferência mais rápida - sim, mas isso é ainda mais verdadeiro para transformações externas que não competem com os recursos do servidor de banco de dados

O ELT é dimensionado enquanto o hardware e o mecanismo RDBMS podem continuar a ser dimensionados - qual custa quanto em relação à alternativa acima?

O ELT pode atingir de 3x a 4x as taxas de transferência na plataforma MPP RDBMS adequadamente ajustada - o que coloca o dispositivo nos níveis de desempenho Voracity em relação às ferramentas ETL também, mas a um custo 20 vezes maior.

A transformação ELT é feita no servidor RDBMS quando o banco de dados está na plataforma de destino e não causa mais estresse na rede – então, ele coloca o estresse no banco de dados (usuários)?

ELT tem especificações de transformação simples via SQL - que não são tão simples, flexíveis ou tão ricas em recursos quanto a sintaxe CoSort SortCL ou mapeamento de campo de arrastar e soltar na GUI do Eclipse da Voracity.

Contra ELT

Ferramentas limitadas disponíveis com suporte total para ELT – e a preços muito altos para dispositivos de banco de dados que promovem desempenho de alto volume

Perda de estatísticas detalhadas de monitoramento em tempo de execução e linhagem de dados - especialmente análises de impacto de metadados em alterações em arquivos, tabelas ou fontes não estruturadas diferentes

Perda de modularidade devido ao design baseado em conjunto para desempenho - e a perda de funcionalidade/flexibilidade que flui dele

As transformações utilizariam recursos de banco de dados, impactando potencialmente o desempenho de relatórios de BI - sem mencionar o desempenho de consulta e outras operações de banco de dados

Arquiteturas híbridas como ETLT, TELT e até mesmo TETLT estão surgindo posteriormente em uma tentativa de reforçar as fraquezas em qualquer uma das abordagens. Mas estes parecem adicionar níveis adicionais de complexidade aos processos já tão carregados. Realmente não existe uma bala de prata, e muitos projetos de integração de dados falham sob o peso de SLAs, custos excessivos e complexidade.

É por esses motivos que a IRI criou o Voracity para integrar dados por meio do programa CoSort SortCL em sistemas de arquivos existentes ou malhas Hadoop sem recodificação. Voracity é a única plataforma orientada a ETL (embora também compatível com ELT) que oferece as duas opções para transformações de dados externos. Além do preço-desempenho superior na movimentação e manipulação de dados, o Voracity inclui:

transformação avançada de dados, qualidade de dados, MDM e relatórios
dimensões de alteração lenta, captura de dados de alteração, federação de dados
perfil de dados, mascaramento de dados, geração de dados de teste e gerenciamento de metadados
scripts 4GL simples que você ou assistentes, diagramas e caixas de diálogo do Eclipse criam e gerenciam
execução perfeita no Hadoop MR2, Spark, Spart Stream Storm e Tez
suporte para erwin Smart Connectors (conversão de outras ferramentas ETL)
drivers nativos do MongoDB e conexões com outras fontes NoSQL, Hadoop, nuvem e legadas
relatórios, estatísticas e funções preditivas incorporados, tie-ins KNIME e Splunk e feeds de dados de ferramentas analíticas.

Veja também:

http://www.iri.com/blog/data-transformation2/etl-elt-iri-in-between
http://www.iri.com/solutions/data-integration/etl
http://www.iri.com/solutions/data-integration/elt
http://www.iri.com/solutions/data-integration/implement