Percebi que minha empresa usa um processo ELT (extract-load-transform) em vez de usar um processo ETL (extract-transform-load).
Quais são as diferenças entre as duas abordagens e em quais situações uma seria "melhor" que a outra? Seria ótimo se você pudesse fornecer alguns exemplos.
muitas discussões sobre ETL vs ELT por aí.
A principal diferença entre ETL e ELT é onde o processamento ocorre O processamento ETL dos dados ocorre na ferramenta ETL (geralmente registro por vez e na memória) O processamento ELT dos dados ocorre no mecanismo de banco de dados
Os dados são os mesmos e os resultados finais dos dados podem ser alcançados em ambos os métodos.
depende muito de você e do seu ambiente Se você tem um mecanismo de banco de dados forte e um bom hardware e pode fazer processamento pesado nele, o ELT é bom para você, Se você tem um mecanismo de datawarehouse ocupado e precisa liberá-lo do processamento vá para ETL.
observe que ter uma ferramenta ETL oferece as duas opções, como ETL(T), você pode fazer a transformação na ferramenta ETL e também pode fazer a transformação no mecanismo de banco de dados
mas ELT você só tem a opção de transformação no mecanismo de banco de dados, mas você deve saber que os bancos de dados são melhores em operações baseadas em conjunto do que ferramentas ETL de registro por vez.
pergunta semelhante feita em SO , mas apoiando ETL e também um bom artigo comparando ETL vs ELT, mas favorecendo ELT
É quase uma questão de semântica. Muito ar quente é lançado nas discussões sobre isso, mas não estou realmente convencido de que haja alguma profundidade filosófica real para uma distinção entre os dois.
Em algum nível, você pode visualizar o ETL como a transformação de dados em uma ferramenta do lado do cliente antes de finalmente carregá-lo, com o ELT implicando que os dados são transferidos para algum tipo de área de preparação com relativamente pouca alteração no formato. 'Transformação' ocorre depois.
Essas são definições muito confusas e podem ser aplicadas a uma ampla variedade de arquiteturas técnicas, e há muitos designs possíveis que qualquer um dos termos poderia ser usado para descrever.
Sou totalmente a favor de uma arquitetura em que toda a transformação e lógica de negócios podem ser construídas em uma base de código mais ou menos homogênea, e já fiz muitos sistemas em que a lógica de transformação era bastante complexa. Isso tendia a usar apenas a ferramenta ETL para obter os dados e, em seguida, toda a transformação era feita em procedimentos armazenados. Indiscutivelmente, isso poderia ser descrito como ETL ou ELT com a diferença sendo apenas uma das semânticas.
Algumas ferramentas são muito centradas no banco de dados, no entanto (Oracle Data Integrator, por exemplo, é frequentemente referido como uma ferramenta ELT). Se você assinar esta visualização, 'Extrair' e 'Carregar' estarão acontecendo antes que os dados sejam transformados, pois eles estão sendo colocados em uma área de preparação e, em seguida, processados por código SQL ou PL/SQL (que pode ser gerado pela ferramenta ou escrito a mão). Várias pessoas com quem conversei parecem considerar o principal mérito do ODI o fato de não ser OWB.
Se você usar uma ferramenta do lado do cliente, como o Informatica Powercentre ou o MS SQL Server Integration Services, a ferramenta poderá fazer uma ampla transformação nos dados do lado do cliente. Algumas ferramentas ETL, como Ascential Datastage e Ab Initio, são projetadas para fazer muito trabalho com arquivos simples e estruturas de dados na memória para obter velocidade. Nesse tipo de arquitetura, a transformação já foi feita antes de ser carregada. Talvez esse tipo de arquitetura possa ser definitivamente classificado como 'ETL', embora eu tenha visto muitos projetos centrados em ferramentas em que todo o trabalho real é feito por um monte de código de procedimento armazenado.
Há vantagens em várias ferramentas e abordagens arquitetônicas, mas não se pode fazer uma declaração geral sobre os méritos das abordagens 'ETL' versus 'ELT' porque os termos são tão amplos que a diferença é quase sem sentido. Algumas ferramentas e arquiteturas podem ter vantagens específicas - por exemplo, o uso pesado de arquivos simples do Ab Initio oferece uma vantagem de desempenho significativa em grandes volumes de dados.
Na prática, fazer a distinção entre 'ETL' e 'ELT' é bastante sem sentido sem entrar em uma discussão muito mais profunda dos requisitos do sistema, plataforma e arquitetura técnica.
Também é uma questão de dinheiro. Onde os volumes de dados são altos, como você aponta, soluções baseadas em arquivos simples como Ab Initio e DataStage Parallel Extender são realmente mais rápidas, mas podem ser proposições de seis dígitos de médio a alto. O IRI CoSort é muito centrado em ETL (de acordo com a comparação de ELT) e a única maneira acessível que vi de abordar o volume de transformação com a velocidade do sistema de arquivos, além de uma implementação complexa do Hadoop. Eu também acho que jogar hardware no problema geralmente (o que dispositivos ELT e bancos de dados na memória também fazem), também não escala tão bem em termos de custo.