Это почти вопрос семантики. В дискуссиях по этому поводу выпускается много горячего воздуха, но я не совсем уверен, что есть какая-то реальная философская глубина для различия между ними.
На некотором уровне вы можете рассматривать ETL как преобразование данных в инструменте на стороне клиента перед окончательной загрузкой, при этом ELT подразумевает, что данные переносятся в какую-то промежуточную область с относительно небольшим изменением формата. «Преобразование» происходит потом.
Это очень пушистые определения, и они могут быть применены к широкому кругу технических архитектур, и существует множество возможных конструкций, которые можно использовать для описания любого термина.
Я очень сильно поддерживаю архитектуру, в которой все преобразования и бизнес-логика могут быть встроены в более или менее однородную кодовую базу, и я создал много систем, где логика преобразования была довольно сложной. Как правило, для сбора данных использовался инструмент ETL, а затем все преобразования выполнялись в хранимых процедурах. Возможно, это можно описать как ETL или ELT, с той лишь разницей, что это просто семантика.
Однако некоторые инструменты ориентированы на базу данных (например, Oracle Data Integrator часто называют инструментом ELT). Если вы подпишитесь на это представление, то «Извлечение» и «Загрузка» будут происходить до того, как данные будут преобразованы, поскольку они помещаются в промежуточную область и затем обрабатываются кодом SQL или PL / SQL (который может быть сгенерирован инструментом или написано от руки). Некоторые люди, с которыми я разговаривал, похоже, считают основную заслугу ODI в том, что это не OWB.
Если вы используете инструмент на стороне клиента, такой как Informatica Powercentre или MS SQL Server Integration Services, тогда этот инструмент может выполнить обширное преобразование на стороне клиента данных. Некоторые инструменты ETL, такие как Ascential Datastage и Ab Initio, предназначены для быстрой работы с плоскими файлами и структурами данных в памяти. В такой архитектуре преобразование уже выполнено до загрузки. Возможно, этот тип архитектуры может быть определенно классифицирован как «ETL», хотя я видел много ориентированных на инструменты проектов, в которых вся настоящая работа выполняется кучей кода хранимых процедур.
Существуют преимущества для различных инструментов и архитектурных подходов, но нельзя сделать общее заявление о достоинствах подходов «ETL» и «ELT», потому что термины настолько широки, что различие почти бессмысленно. Некоторые инструменты и архитектуры могут иметь определенные преимущества - например, интенсивное использование плоских файлов в Ab Initio дает ему значительное преимущество в производительности на больших объемах данных.
На практике проводить различие между «ETL» и «ELT» довольно бессмысленно, если не вдаваться в более глубокое обсуждение системных требований, платформы и технической архитектуры.
