ETL vs ELT и причём тут Data Lake

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

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

Рассмотрим простой пример ELT. Есть некая система-источник, например, система учёта продаж. Все её данные хранятся в реляционной БД. Хорошей практикой будет реплицировать необходимые таблицы с источника в Operational Data Store — специальный слой хранилища (сокр. ODS) для исходных данных.

Инструмент, с помощью которого выполнена репликация, уже извлёк (Extract) данные и загрузил их в хранилище (Load). Остаётся только из "сырья" собрать нужные бизнесу таблицы в детальном (Detailed Data Store) слое хранилища. Внутри хранилища все эти преобразования (Tranfsorm) как правило выполняются с помощью SQL.

Так и получился ELT-процесс, в котором вся бизнес-логика находится внутри SQL-скриптов, которые перегоняют данные из таблицы в таблицу в рамках единого DWH.

Но ведь все процессы обновления DWH могут быть устроены таким образом. Зачем же тогда выделять ELT, если все привыкли такие процессы называть ETL?

Я предполагаю, что подчёркивать различия между ETL и ELT стали в связи с популяризацией идеи озера данных — Data Lake. Это идея пришла с развитием экосистемы Hadoop и объектных хранилищ по стандарту S3.

Как было раньше: DWH работает на одной машине или в паре с репликой, место на диске ограниченно. Сначала анализируем источник, находим необходимое, по пути что-то преобразуем, собираем всё в рамках какой-то модели (например, "снежинки"). Часть преобразований между источником и хранилищем могла быть выполнена на отдельном ETL-сервере. Таким был классический ETL.

Что имеем сейчас: стоимость хранения данных упала, а с помощью Hadoop или связки Apache Spark + S3 стали возможны распределённые вычисления на большом количестве серверов. Стало возможным загружать сразу все доступные данные в распределённое хранилище, а уже затем собирать из них что-то полезное. Так мы получили Data Lake и ELT.

Теперь у нас не Data Warehouse, а Data Lake. Не ETL, а ELT. Всё это приправлялось технологиями, которые крепко ассоциируются с Бигдатой (Hadoop, Spark), чтобы выбить бюджет на разработку модного и прогрессивного озера данных. Да, я считаю Бигдату преимущественно маркетинговым ходом.

Это не отменяет того, что ELT-подход можно использовать и для классических DWH реализованных на том же Greenplum — место на дисках можно больше так не экономить.

Более того, сейчас набирает популярность гибридный концепт Data LakeHouse (DLH), когда мы храним сырые данные в S3-хранилище, а аналитическую модель данных реализуем в Clickhouse или Greenplum.

Ну что, теперь будем говорить о ELTLT-пайплайнах, когда данные преобразуются в разных слоях DLH? А можно не париться и продолжить всё называть ETL.