Percebi que minha empresa usa um processo ELT (extrair-carregar-transformar) em vez de usar um processo ETL (extrair-transformar-carregar).
Quais são as diferenças nas 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 acontece. O processamento de dados ETL acontece na ferramenta ETL (geralmente gravada por vez e na memória) O processamento de dados ELT ocorre no mecanismo de banco de dados
Os dados são iguais e os resultados finais dos dados podem ser alcançados nos dois métodos.
depende muito de você e do seu ambiente Se você possui um mecanismo de banco de dados forte e um bom hardware e pode fazer um processamento pesado, o ELT é bom para você. Se você possui um mecanismo de dataware ocupado e precisa liberá-lo do processamento para ETL.
observe que ter uma ferramenta ETL fornece 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 no ELT, você só tem a opção de transformação no mecanismo de banco de dados, mas deve saber que os bancos de dados são melhores em operações baseadas em conjunto do que as ferramentas ETL de registro por vez.
pergunta semelhante feita no 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 é liberado nas discussões sobre isso, mas não estou realmente convencido de que haja uma 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á-los, 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 simples e podem ser aplicadas a uma ampla variedade de arquiteturas técnicas, e existem muitos projetos possíveis que qualquer um dos termos poderia ser usado para descrever.
Sou fortemente a favor de uma arquitetura em que toda a lógica de transformação e de negócios possa ser incorporada a uma base de código mais ou menos homogênea, e já fiz vários sistemas em que a lógica de transformação era bastante complexa. Isso costumava usar apenas a ferramenta ETL para aterrar os dados e, em seguida, toda a transformação era feita nos procedimentos armazenados. Indiscutivelmente, isso poderia ser descrito como ETL ou ELT, com a diferença sendo apenas uma semântica.
Algumas ferramentas são muito centradas no banco de dados (no entanto, o Oracle Data Integrator, por exemplo, é frequentemente chamado de ferramenta ELT). Se você se inscrever nesta visualização, 'Extrair' e 'Carregar' ocorrerão antes que os dados sejam transformados, à medida que são aterrados em uma área intermediária e depois 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 por 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 transformação extensiva no lado do cliente de dados. Algumas ferramentas de ETL, como Ascential Datastage e Ab Initio, foram projetadas para trabalhar muito com arquivos simples e estruturas de dados na memória para maior 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.
Existem vantagens em várias ferramentas e abordagens arquiteturais, mas não se pode fazer uma declaração geral sobre os méritos das abordagens 'ETL' vs. '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 intenso de arquivos simples do Ab Initio oferece uma vantagem significativa de desempenho em grandes volumes de dados.
Na prática, fazer a distinção entre 'ETL' e 'ELT' é 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. Nos locais em que o volume de dados é alto, as soluções baseadas em arquivos simples como o Ab Initio e o 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 ELT) e a única maneira acessível que vi para lidar com o volume de transformação com a velocidade do sistema de arquivos, além de uma implementação complexa do Hadoop. Também acho que jogar o hardware no problema em geral (que os dispositivos ELT e os bancos de dados na memória também fazem), também não é escalável em termos de custo.