ETL & ELT. От перестановки «слагаемых» результат меняется

[strwolf]

Плюсы ETL не обозначены, как и минусы ELT. Просто по табличке кажется, что ELT выгоден всегда. Даже в конце есть сноска, да для 5 ГБ МОЖНО использовать ETL, но ведь так же можно использовать ELT. Насколько я знаю из минусов ELT подхода - намного большее потребление вычислительных ресурсов. Но у меня, конечно же, общие теоретические знания, но вроде так, насколько мне известно. Но с ростом вычислительных мощностей это стало меньшей проблемой чем скорость загрузки (то что всегда было узким местом для БД) и упорядочивания входящей информации, отсюда и появление подхода ELT, скачала загрузка, а трансформация в самом конце.

[Splitenok]

Плюсы и минусы не обозначены, так как в разных ситуациях плюс может стать минусом. Давай на примере - есть конкретный пул данных, которые весят 50Гб за день. Такой объем можно залить как ELT так и ETL. Для отчета нужен лишь кусок, занимающий всего 5 Гб. Но смотрим чуть шире - допустим мы небольшая компания с общим объемом хранилища на 1 Тб. И вот тут уже начинается разница: в ETL мы понесем в хранилище лишь 5 Гб (размер данных - плюс), данные загрузятся достаточно быстро даже с расчетами. Если мы берем ELT, то нам нужно загрузить 55 Гб данных (размер данных - минус)! И тут ELT уже не так хорош, как если бы мы были Яндексом с его размерами хранилищ, где эти 50Гб вообще не заметят, зато в случае необходимости напишут еще два отчета, используя сырые данные (размер этих данных не важен, сама возможность - плюс, не нужно будет команде писать новый ELT - плюс).

Надеюсь, ответила на вопрос.

[miksoft]

Наиболее классическая ситуация — забираем все изменения на Т -1, где Т — отчетная дата

Где как. У нас почти никогда не встречается. Чаще всего такие варианты - забираем всё, забираем инкремент с предыдущей загрузки, забираем данные за последние N дней (где N должно с запасом перекрыть как изменения задним числом, так и технические интервалы между расчетами).

[Splitenok]

Здесь все таки мой личный опыт.

Почему вы берете N дней ради изменений задним числом? Почему не забираете сами изменения?

[astentx]

Никогда не приходилось встречать чистые ETL или ELT: что-то можно посчитать прямо в источнике, что-то на транспорте подфильтровывается, где-то создаются универсальные API (например, Kafka-топик), под которые источник готовит данные, а что-то тянем 1 к 1. Деление весьма условное и только для терминологии скорее. После попадания в DWH данные так или иначе трансформируются, время использования DWH как ридонли хранилища готовых витрин давно прошло. Выходит, это уже ETL { -TL }. С коллегами всегда используем старый термин ETL, подразумевая обобщенный процесс преобразования данных от источников до витрин, который всегда имеет какое-то промежуточное хранение, но каждый раз свое и вполне определенное в рамках архитектурного решения для данной системы.

[Splitenok]

Про терминологию соглашусь, то же не слышала ни разу про ELT в рамках работы, но вот в моменте всплыл вопрос.

[Deesy]

Возможно здесь больше стоит рассмотреть проблему с другой стороны. Мы тоже обрабатывали карточные платежи - 25 млн транзакций в день проходили через AS400 и падали к нашим DBA в виде текстовых данных. Далее данные (практически*) сразу загружались в таблицы. И далее мне приходилось городить кучу костылей для перобразования кривых форматов с AS400 в удобоваримый. Как примеры цифры хранились как строки, даты как цифры. Знак хранился вообще как отдельное поле. Конечно минимальные (практически*) преобразования (знаки, касты и обфускация) были сделаны перед загрузкой и т.д. Дальше все это оборачивалось во вьюхи с преобразованием того, что не получилось преобразовать раньше. Это как раз было ELT. Такой "недо ETL".
Если бы хоть как-то чуть серьезнее подходили к процессу то много головной боли и преобразований на лету через вьюхи бы сняли для обработки.

А дальше все равно на основе этих транзакций, считалисть Scheme Fees, IC и строились таблицы для отчетов.

[Splitenok]

Не очень поняла с какой стороны стоит рассмотреть проблему? Карточные транзакции лишь пример. Они часто самые тяжелые, с этим не поспоришь ( по крайней мере в банковской среде). Может проблема с организации передачи данных? Просто сам подход "сначала записать в БД и потом сделать преобразования" выглядит разумно для такого объема. Больше смущает фраза про текстовые данные. Это ж не cvs, надеюсь, были?