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