ETL против ELT: в чем разница?

Сравнение ETL и ELT в контексте Data Engineering

ETL (извлечение-преобразование-загрузка) и ELT (извлечение-загрузка-преобразование) — это два термина, обычно используемые в области инженерии данных и, более конкретно, в контексте приема и преобразования данных.

Хотя эти термины часто используются как взаимозаменяемые, они относятся к несколько разным концепциям и имеют разные последствия для проектирования конвейера данных.

В этой статье мы уточним определения процессов ETL и ELT, обрисуем различия между ними и обсудим преимущества и недостатки, которые оба могут предложить инженерам и группам обработки данных в целом.

И самое главное, я собираюсь описать, как недавние изменения в формировании современных команд обработки данных повлияли на ситуацию вокруг битвы ETL и ELT.

Понимание извлечения, загрузки и преобразования независимо друг от друга

Основная ставка, когда речь идет о сравнении ETL и ELT, очевидно, заключается в последовательности шагов извлечения, загрузки и преобразования, выполняемых в конвейере данных.

На данный момент давайте проигнорируем эту последовательность выполнения и сосредоточимся на фактической терминологии и обсудим, что должен делать каждый отдельный шаг.

Извлечение. Этот шаг относится к процессу извлечения данных из постоянного источника. Этим источником данных может быть база данных, конечная точка API, файл или что угодно, что содержит любую форму данных, включая как структурированные, так и неструктурированные.

Преобразование. На этом этапе ожидается, что конвейер внесет некоторые изменения в структуру или формат данных для достижения определенной цели. Преобразованием может быть выбор атрибута, модификация записей (например, преобразование 'United Kingdom' в 'UK'), проверка данных, присоединение к другому источнику или что-то еще, что изменяет формат входных необработанных данных.

Загрузка. Этап загрузки относится к процессу копирования данных (необработанных или преобразованных версий) в целевую систему. Обычно целевой системой является хранилище данных (т. е. система OLAP, используемая для целей аналитики) или база данных приложения (т. е. система OLTP).

Безусловно, последовательность, в которой мы выполняем эти три шага, имеет значение. А с увеличением объемов данных, которые необходимо обрабатывать, порядок выполнения имеет большое значение. Давайте обсудим, почему!

Извлечение нагрузки преобразования (ETL)

ETL расшифровывается как Extract-Transform-Load, а сам термин относится к процессу, в котором за этапом извлечения данных следует этап преобразования, который заканчивается этапом загрузки.

Этап преобразования данных в процессах ETL происходит в промежуточной среде за пределами целевой системы, где данные преобразуются непосредственно перед их загрузкой в ​​место назначения.

Преобразование извлечения нагрузки (ELT)

С другой стороны, ELT, что означает «извлечение-загрузка-преобразование», относится к процессу, в котором за шагом извлечения следует шаг загрузки, а окончательный шаг преобразования данных происходит в самом конце.

В отличие от ETL, в ELT не требуется промежуточная среда/сервер, поскольку преобразование данных выполняется в целевой системе, которой обычно является хранилище данных или озеро данных, размещенное в облаке.

Как выбрать между ETL и ELT

ETL и ELT имеют свои плюсы и минусы, и есть вероятность, что вы столкнетесь с обоими в своей повседневной работе, учитывая, что они обычно используются для разных вариантов использования.

ETL лучше всего подходит для случаев, когда данные хранятся локально и их необходимо структурировать перед загрузкой в ​​целевую базу данных или хранилище. Следовательно, процесс ETL обычно предпочтительнее, когда в процесс вовлечены меньшие объемы данных и/или когда предстоит выполнить сложные преобразования.

Кроме того, поскольку ETL преобразовывает данные перед этапом загрузки, конфиденциальные данные могут быть замаскированы, зашифрованы или полностью удалены до загрузки. Этот аспект ETL может помочь компаниям и командам более легко обеспечивать соблюдение различных нормативных требований (например, GDPR).

Поскольку преобразование происходит на промежуточном (промежуточном) сервере, перенос преобразованных данных в целевую систему сопряжен с дополнительными затратами. Кроме того, целевая система не будет содержать необработанных данных (то есть данных в форме до преобразования). Это означает, что всякий раз, когда требуются дополнительные преобразования, нам придется снова извлекать необработанные данные.

С другой стороны, ELT обеспечивает большую гибкость по сравнению с ETL, учитывая, что последний исторически предназначался для структурированных (реляционных) данных. Современные облачные архитектуры и хранилища позволяют использовать ELT как для структурированных, так и для неструктурированных данных.

Как упоминалось ранее, ETL следует использовать для небольших объемов данных. ELT предлагает более быстрое преобразование, поскольку оно не зависит от размера данных и обычно выполняется по мере необходимости.

Кроме того, когда данные загружаются перед преобразованием в рамках процесса ELT, это означает, что пользователи и системы по-прежнему имеют доступ к необработанным данным. Это означает, что если на более позднем этапе потребуются дополнительные преобразования, у нас уже есть необработанные данные в хранилище данных, к которым можно получить доступ в любое время. Единственным недостатком было бы дополнительное хранилище, необходимое для хранения этих необработанных данных, но, учитывая постоянно снижающуюся стоимость хранения, я не думаю, что это серьезная проблема.

Теперь, когда мы все хорошо понимаем технические аспекты процессов ETL и ELT, позвольте мне кое-что задать. Когда дело доходит до выбора одного над другим, это просто вопрос технической реализации?

Дело не только в том, когда нужно выполнить трансформацию

Кроме того, область данных постоянно развивается и движется вперед, и роли данных не являются исключением в этой быстро меняющейся среде. Разница между ETL и ELT заключается не только в том, где происходит этап преобразования, но и в том, кто должен его выполнять.

Шаг преобразования обычно включает некоторую бизнес-логику. Традиционные процессы ETL раньше выполнялись инженерами хранилища данных (не уверен, что это все еще актуально, если честно), что означает, что эти люди также отвечали за создание бизнес-логики.

С другой стороны, процессы ELT развивались в зависимости от характера и ландшафта современных групп данных и их формирования. Шаги EL (извлечение-загрузка) обычно выполняются инженерами данных, тогда как шаг преобразования выполняется так называемыми инженерами-аналитиками.

И это имеет для меня большой смысл. Data Engineer — это чисто технический парень, который заботится об эффективности, масштабируемости, готовности и доступности (среди миллиона других вещей). С другой стороны, инженер-аналитик по-прежнему является техническим специалистом с гораздо лучшим пониманием бизнеса. И поэтому имеет больше смысла для инженера-аналитика нести ответственность за преобразование данных, учитывая, что (обычно) преобразование соответствует ценности для бизнеса.

Современные облачные архитектуры, стеки данных (включая облачные системы OLAP) и формирование команд сделали процессы ELT более актуальными и эффективными. Исходя из моего личного опыта, я бы сказал, что происходит переход от ETL к ELT, несмотря на то, что ETL по-прежнему актуален и полезен.

Современные стеки данных и команды отдают предпочтение процессам ELT

Хотя ETL не умер, на мой взгляд, современные стеки данных и технологии благоприятствуют процессам ELT. В качестве примера рассмотрим dbt (инструмент построения данных), который является одним из самых горячих дополнений в области данных и фактически стал инструментом трансформации для аналитиков и инженеров.

Обычно мы хотели бы принести в хранилище данных необработанные данные (т. е. без применения какого-либо преобразования) из внешних или внутренних источников данных. Затем поверх этих моделей данных (в dbt мы обычно называем их промежуточными моделями) мы строим дополнительные модели (промежуточные и рыночные), которые являются результатом некоторых трансформационных процессов, происходящих в хранилище данных.

Поэтому в таких рабочих процессах имеет смысл загружать данные в хранилище перед их преобразованием. Это также обеспечивает доступ к необработанным данным в любой момент времени, чтобы можно было поддерживать будущие варианты использования.

Если вы заинтересованы в более глубоком понимании того, как работает dbt и как различные компоненты объединяются для преобразования необработанных данных и создания значимых моделей данных для поддержки принятия решений, я бы порекомендовал следующую статью.

Последние мысли

Проектирование конвейеров данных — сложная задача, и при ее выполнении необходимо тщательно учитывать множество факторов. Когда дело доходит до приема данных из источников данных в хранилище данных, обычно можно использовать два подхода.

В этой статье мы обсудили, как ETL и ELT выполняют последовательность шагов для преобразования и загрузки (или загрузки и преобразования) данных в целевую систему.

В зависимости от ландшафта организации и конкретного варианта использования вы можете выбрать один из них. Я надеюсь, что это руководство предоставило вам все детали, необходимые для выбора наилучшего и наиболее эффективного подхода к приему и преобразованию данных.

Стать участником и читать все истории на Medium. Ваш членский взнос напрямую поддерживает меня и других писателей, которых вы читаете. Вы также получите полный доступ ко всем историям на Medium.

Статьи по теме, которые вам также могут понравиться