Я понял, что моя компания использует процесс ELT (extract-load-transform) вместо использования процесса ETL (extract-transform-load).
Каковы различия в этих двух подходах и в каких ситуациях один будет «лучше», чем другой? Было бы здорово, если бы вы могли привести несколько примеров.
Ответы:
Много дискуссий о ETL против ELT там.
Основное различие между ETL и ELT заключается в том, где происходит обработка ETL. Обработка данных происходит в инструменте ETL (обычно по записи и в памяти). ELT обработка данных происходит в ядре базы данных.
Данные одинаковы, и конечные результаты могут быть получены обоими методами.
это очень сильно зависит от вас и вашей среды. Если у вас есть мощное ядро базы данных и хорошее аппаратное обеспечение, и вы можете выполнять на нем тяжелую обработку, ELT вам подойдет, если у вас загруженный механизм хранилища данных и вам нужно освободить его от обработки, переходите для ETL.
обратите внимание, что наличие инструмента ETL дает вам обе опции, например, ETL (T), вы можете выполнять Преобразование в инструменте ETL, а также выполнять преобразование в движке базы данных.
но ELT у вас есть только возможность преобразования в ядре базы данных, но вы должны знать, что базы данных лучше выполняют операции на основе множеств, чем инструменты ETL для записи за один раз.
аналогичный вопрос, заданный для SO, но поддерживающий ETL, а также хорошая статья, сравнивающая ETL с ELT, но поддерживающая ELT
Это почти вопрос семантики. В дискуссиях по этому поводу выпускается много горячего воздуха, но я не совсем уверен, что есть какая-то реальная философская глубина для различия между ними.
На некотором уровне вы можете рассматривать 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» довольно бессмысленно, если не вдаваться в более глубокое обсуждение системных требований, платформы и технической архитектуры.
Это также вопрос денег. Там, где, как вы указали, объемы данных высоки, решения на основе плоских файлов, такие как Ab Initio и DataStage Parallel Extender, действительно быстрее, но могут предлагать средние и высокие цифры из шести цифр. IRI CoSort очень ориентирован на ETL (в сравнении с ELT) и является единственным доступным способом, который я видел, для решения проблемы объема преобразования со скоростью файловой системы, кроме сложной реализации Hadoop. Я также думаю, что использование аппаратного обеспечения для решения проблемы в целом (что делают устройства ELT и БД в памяти) также не масштабируется с точки зрения затрат.