Я зрозумів, що моя компанія використовує процес ELT (витяг-завантаження-перетворення) замість використання процесу ETL (витяг-перетворення-завантаження).
У чому полягають відмінності двох підходів і в яких ситуаціях один був би "кращим", ніж інший? Було б чудово, якби ви могли навести кілька прикладів.
Відповіді:
багато дискусій про ETL проти ELT там.
Основна відмінність ETL від ELT полягає в тому, що обробка відбувається ETL обробка даних відбувається в інструменті ETL (зазвичай записується за часом і в пам'яті). ELT обробка даних відбувається в двигуні бази даних
Дані однакові, а кінцеві результати даних можна досягти в обох методах.
це дуже залежить від вас та вашого оточення. Якщо у вас є потужний механізм баз даних та гарне обладнання, і ви можете на ньому важко обробляти, ELT корисний для вас, якщо у вас зайнятий двигун сховища даних і вам потрібно звільнити його від обробки. для ETL.
зауважте, що наявність інструменту ETL надає вам обидва варіанти, як, наприклад, ETL (T), ви можете виконати перетворення в інструменті ETL, а також перетворення в двигуні бази даних.
але ELT у вас є лише можливість трансформації в двигуні баз даних, але ви повинні знати, що Бази даних краще в заданих операціях, ніж інструменти ETL за часом.
подібний запитання задається щодо SO, але підтримує ETL, а також приємну статтю, що порівнює ETL проти ELT, але надає перевагу ELT
Це майже питання семантики. Дуже багато гарячого повітря виходить в дискусії з цього приводу, але я не дуже впевнений, що існує якась реальна філософська глибина, яка може відрізняти між собою.
На якомусь рівні ви можете розглядати ETL як перетворення даних у клієнтському інструменті, перш ніж остаточно завантажувати його, при цьому ELT означає, що дані переносяться на якусь область постановки з відносно невеликою зміною формату. «Трансформація» відбувається згодом.
Це дуже пухнасті визначення та можуть бути застосовані до найрізноманітніших технічних архітектур, і існує безліч можливих конструкцій, які можна було б використати для опису будь-якого терміна.
Я дуже висловлююся за архітектуру, де всю логіку перетворення та ділової логіки можна вбудувати в більш-менш однорідну базу коду, і я зробив багато систем, де логіка перетворення була досить складною. Це, як правило, просто використовувало інструмент ETL для землекористування даних, а потім все перетворення здійснювалося в збережених процедурах. Можливо, це можна було б охарактеризувати як ETL або ELT з різницею, що є лише однією з семантичних.
Однак деякі інструменти дуже орієнтовані на бази даних (наприклад, Oracle Data Integrator часто називають інструментом ELT). Якщо ви підписалися на це представлення даних, то "Витягнути" та "Завантажити" відбуваються до того, як дані трансформуються, коли вони висаджуються в місце постановки, а потім стискаються кодом SQL або PL / SQL (який може бути створений інструментом або рукописний). Кілька людей, з якими я спілкувався, здається, вважають головну заслугу ODI тим, що це не OWB.
Якщо ви використовуєте такий клієнтський інструмент, як Informatica Powercentre або MS SQL Server Integration Services, то інструмент може здійснити велику трансформацію на сторону клієнта даних. Деякі інструменти ETL, такі як Ascential Datastage та Ab Initio, розроблені для того, щоб зробити роботу з плоскими файлами та структурами даних в пам'яті для швидкості. У такій архітектурі трансформація вже зроблена до її завантаження. Можливо, цей тип архітектури можна було б точно класифікувати як "ETL", хоча я бачив багато проектів, орієнтованих на інструменти, де вся реальна робота виконується купою збереженого коду процедури.
У різних інструментах та архітектурних підходах є переваги, але не можна складати загальну заяву про переваги підходів «ETL» та «ELT», оскільки терміни такі широкі, що різниця майже безглузда. Деякі інструменти та архітектури можуть мати конкретні переваги - наприклад, велике використання плоских файлів Ab Initio дає їй значну перевагу у виконанні великих об’ємів даних.
На практиці робити розрізнення між ETL та ELT досить безглуздо, не заглиблюючись у більш глибокі обговорення системних вимог, платформи та технічної архітектури.
Це також питання грошей. Якщо об'єм даних великий, як ви зазначаєте, рішення на базі плоских файлів, такі як Ab Initio і DataStage Parallel Extender, дійсно швидші, але можуть бути середніми до високих шестизначних пропозицій. IRI CoSort дуже орієнтований на ETL (за їх порівнянням ELT), і єдиний доступний спосіб, який я бачив, щоб вирішити обсяг трансформації зі швидкістю файлової системи, крім складної реалізації Hadoop. Я також думаю, що накидання обладнання на вирішення проблеми (як і пристрої ELT та БД в пам'яті) також не так масштабне.