Comments 9
Использование pl/sql в том же оракле - по факту это тоже ELT. Технология эта вообще не облачная, а используется она очень и очень давно, я бы даже не удивился, если дольше, чем ETL...
Кроме того, существуют вполне себе необлачные ELT решения типа Oracle Data Integrator (устарела уже даже), Stambia. То, что ELT чаще применяется теперь в облаках совершенно не означает, что подхода не было раньше. Идея старая, но её обоснование применения немного изменилось. Если раньше были распространены массово-параллельные БД, кластерные БД, которые лучше знали как быстрее обработать хранящиеся у них данные (иногда и нет, надо отметить), то сейчас это воркер-ноды различных систем, будь то Spark, BigQuery, Synapse и т.д.
И я уж не говорю о том, что на любом ETL решении можно построить ELT, если это поддерживает или источник или целевая система (или staging). Не всегда, правда, это будет соответствовать Best practices, но в теории можно.
ELT решения - это когда трансформация делается на уровне уже сохраненных данных, а Oracle DI - это ETL решение...
Нет, все таки ELT, у него нет своего движка трансформации. Например, чтоб совершить преобразования над данными из CRM или из другого любого не SQL источника, необходимо его загрузить. Поэтому ELT
Ну, и в Википедии, если достоверный для вас источник : https://en.m.wikipedia.org/wiki/Oracle_Data_Integrator
давайте вместо вики попробуем на официальном сайте оракла посмомтреть:
https://docs.oracle.com/cd/E28280_01/integrate.1111/e12643/intro.htm#ODIDG118
Oracle Data Integrator supports both ETL- and E-LT-Style data integration. See Section 11.5, "Designing Integration Interfaces: E-LT- and ETL-Style Interfaces" for more information.
Не хочу спорить с различными чтениями терминологии, но даже на сайте Oracle написано:
In an ETL-style interface, ODI processes the data in a staging area, which is different from the target. The data is first extracted from the source(s) and then loaded to the staging area. The data transformations take place in the staging area and the intermediate results...
По мне это ELT в чистом виде. Для того чтобы трансформировать нужно загрузить либо в целевую систему, либо в другую (но в случае ODI - только в СУБД), но которая умеет делать трансформации. Сам ODI ничего в этом плане не умеет, он только генерирует SQL скрипты. А уж целевая это система или нет - это не столь важно в подходе ELT. Строго говоря это ELTL подход.
"ETL .. не имеет поддержки озёр данных " что за чушь про не имеет поддержи?
"При ELT за преобразования отвечает целевая система. Благодаря разделению хранения и вычислений данные можно хранить в их исходном формате и преобразовывать по необходимости. Размер данных не влияет на скорость. "
А мужики то не знают, что размер не влияет на скорость. Facepalm
Если зрить в корень, то ETL отличается от ELT по сути только тем, где именно (в какой именно системе) происходит T: если уже в целевой системе, то это ELT, если нет — то ETL. Это и есть ключевое отличие, а все остальное — логическое следствие из этого.
А вообще, ИМХО, деление ELT/ETL было актуально лет 7 назад. Сейчас при проектировании высоконагруженных БигДата систем никто уже не задается вопросом, какой из этих подходов использовать — просто делают «как надо» и все. А как это называется — дело десятое. Вы же не задумываетесь, с какой ноги начинаете шагать?
Куча современных инструментов это всё-таки ETL. Тот же Спарк или трансформации данных через python pandas это вариации ETL подхода, хотя со спарком можно поспорить, так как зачастую он использует ресурсы hdfs. Но если поставим его в условном Standalone будет вполне себе ETL. Куча инструментов предлагает оба варианта обработки. Облачные движки так же могут давать ETL подход. Кроме того стримовые движки типа флинка это тоже по факту etl. В статье очень странно описаны плюсы/минусы каждого из подходов, статья очень похожа на продажу ЕLT подхода с которой лет 10 или 15 назад выходил оракл со своим odi, рассказывая что придумал новый вариант интеграции данных. Например "Вы работаете только со структурированными данными и/или с небольшими частями данных" почему etl не подходит для слабоструктурированные данных и как вы загрузите произвольный json в целевую базу и будете жечь проц на парсинг этого json в базе?
Огромные ресурсы для ETL тоже миф, используя подходы микробатчинга можно ограничится довольно скромными ресурсами, но правда теряются не некоторые возможности. Но иначе вам необходимо жечь ресурсы системы хранения в ELT, что при не удачной реализации ресурсных политик может поставить вас в неудобную ситуацию.
Идеально сочитать оба подхода, не сжигая ресурсы на операции трансформации и интеграции самих данных используя etl, и выполняя сложные трансформации сочетающие данные из разных источников для сбора сущностей и витрин в пушдаун/elt подходе.
ETL и ELT: ключевые различия, о которых должен знать каждый