ETL срещу ELT:Ние смятаме, вие преценете

Пълно разкриване:Тъй като авторът на тази статия е от ETL-центрирана компания със силната си страна в манипулирането на големи данни извън бази данни, това, което следва, няма да изглежда обективно за мнозина. Въпреки това той все още има за цел да даде повод за размисъл и отваря думата за дискусия.

От самото си начало архитектите на хранилища за данни (DWA) са били натоварени със задачата да създадат и попълват склад за данни с различни източници и форматирани данни. Поради драматичното нарастване на обема на данни, същите тези DWA са изправени пред предизвикателството да приложат по-ефективно своите операции за интегриране на данни и етапи. Въпросът дали трансформацията на данни ще се случи вътре или извън целевата база данни се превърна в критичен поради производителността, удобството и финансовите последици.

При операциите ETL (извличане, преобразуване, зареждане) данните се извличат от различни източници, трансформират се отделно и се зареждат в DW база данни и евентуално други цели. В ELT извлеченията се подават в единната етапна база данни, която също обработва трансформациите.

ETL остава преобладаващ, защото пазарът процъфтява с доказани играчи като Informatica, IBM, Oracle — и IRI с Voracity, който съчетава FACT (бързо извличане), CoSort или Hadoop трансформации и групово зареждане в същия графичен интерфейс на Eclipse — за извличане и трансформиране на данни. Този подход предотвратява натоварването на бази данни, предназначени за съхранение и извличане (оптимизация на заявки), с режийните разходи за мащабна трансформация на данни.

Въпреки това, с разработването на нова технология за бази данни и хардуерни устройства като Oracle Exadata, които могат да се справят с трансформациите „в кутия“, ELT може да бъде практично решение при определени обстоятелства. Има и специфични предимства за изолирането на етапа (зареждане) и семантичния (трансформиране) слоеве.

Цитирано предимство на ELT е изолирането на процеса на натоварване от процеса на трансформация, тъй като премахва присъщата зависимост между тези етапи.

Отбелязваме, че ETL подходът на IRI така или иначе ги изолира, тъй като Voracity прехвърля данните във файловата система (или HDFS). Всяка част от данни, свързана с базата данни, може да бъде придобита, почистена и трансформирана външно преди (предварително сортирано) натоварване. Това премахва тежестта на широкомащабните трансформации от базата данни (както и BI/аналитични инструменти и т.н.).

Обемите на данни и бюджетите често са това, което определя дали DWA трябва да разработи ETL или ELT решение. В статията си в блога на ITToolbox „И така, какво е по-добро, ETL или ELT?“, Винсент Макбърни посочва своите плюсове и минуси на всеки подход, които повторих тук по-долу и след това последвах всеки с типичен отговор, че IRI ETL ориентираните потребители правят на място (според моето първоначално предупреждение за субективност):

Професионалисти ETL

ETL може да балансира работното натоварване и да споделя натоварването с RDBMS – и всъщност да премахне това натоварване чрез трансформиране на данните чрез програма SortCL или Hadoop без кодиране в Voracity

ETL може да изпълнява по-сложни операции в единични диаграми на потоци от данни чрез карти на данни – като при картографирането на Voracity и диаграмите на работния поток, които също абстрахират кратки, отворени 4GL скриптове срещу SQL

ETL може да се мащабира с отделен хардуер – от кашони за стоки можете да се снабдите и поддържате сами на много по-ниски разходи в сравнение с уреди от един доставчик

ETL може да се справя с разделяне и паралелизъм независимо от модела на данните, оформлението на базата данни и архитектурата на модела на източника на данни – въпреки че задачите на Voracity CoSort SortCL изобщо не е необходимо да се разделя...

ETL може да обработва данни в поток, тъй като се прехвърля от източник към цел – или в пакет, ако това също има смисъл

ETL не изисква съвместно местоположение на набори от данни, за да върши своята работа – позволявайки ви да поддържате съществуващи платформи за източници на данни без притеснения за синхронизиране на данни

ETL улавя огромни количества метаданни днес - колко добре или интуитивно може да се направи това една DB на етапи?

ETL може да работи на хардуер SMP или MPP – който отново можете да управлявате и използвате по-изгодно и да не се притеснявате за спорове за производителност с DB

ETL обработва информация ред по ред и това изглежда работи добре с интегрирането на данни в продукти на трети страни – все пак е по-добре пълен блок, таблица или файл(и)-по-време, които Voracity изпълнява в обем.

Против ETL

Необходима е допълнителна хардуерна инвестиция за ETL двигатели – освен ако не го стартирате на сървъра(ите) на базата данни

Допълнителни разходи за изграждане на ETL система или лицензиране на ETL инструменти – които все още са по-евтини в сравнение с ELT уредите, но все още са по-евтини IRI инструменти като Voracity, които комбинират Fast Extract (FACT) и CoSort за ускоряване на ETL без такава сложност

Възможна намалена производителност на подхода, базиран на редове – правилно и защо способността на Voracity да профилира, придобива, трансформира и извежда данни в по-големи парчета е по-бърза

Необходими са специализирани умения и крива на обучение за внедряване на инструмента ETL – освен ако не използвате ергономичен GUI като Voracity, който предоставя множество опции за проектиране на задачи в една и съща IDE на Eclipse

Намалена гъвкавост поради зависимост от доставчика на ETL инструменти – Не съм сигурен как това е подобрено, като вместо това разчитам на един доставчик на ELT/устройство; не е ли независимостта на доставчика ключът към гъвкавостта и спестяването на разходи?

Данните трябва да преминат през още един слой, преди да попаднат в витрината с данни – освен ако не е просто още един изход на ETL процеса, типичен за многоцелеви операции Voracity .

Професионалисти ELT

ELT използва хардуера на двигателя на RDBMS за мащабируемост – но също така облага ресурсите на DB, предназначени за оптимизиране на заявките. Трансформациите на CoSort и Hadoop в Voracity използват алгоритми за линейно мащабиране и консолидиране на задачите, а не паметта или I/O ресурсите на DB

ELT запазва всички данни в RDBMS през цялото време – което е добре, стига изходните и целевите данни да са в една и съща DB

ELT се паралелизира според набора от данни и дисковият вход/изход обикновено се оптимизира на ниво машина за по-бърза пропускателна способност – да, но това е още по-вярно за външни трансформации, които не се борят с ресурсите на DB сървъра

ELT се мащабира, докато хардуерът и механизмът на RDBMS могат да продължат да се мащабират – кое колко струва спрямо алтернативата по-горе?

ELT може да постигне 3x до 4x скоростта на пропускателна способност на подходящо настроената MPP RDBMS платформа – което поставя уреда на нива на производителност на Voracity също спрямо ETL инструментите, но на 20 пъти по-висока цена.

Преобразуването на ELT се извършва на сървъра на RDBMS, след като базата данни е на целевата платформа и вече не натоварва мрежата – така че вместо това поставя стрес върху базата данни (потребителите)?

ELT има прости спецификации за трансформация чрез SQL – които не са толкова прости, гъвкави или богати на функции като синтаксиса на CoSort SortCL или картографирането на полета с плъзгане и пускане в графичния интерфейс на Eclipse на Voracity.

Против ELT

Налични са ограничени инструменти с пълна поддръжка за ELT – и на много високи цени за DB уреди, рекламиращи производителност с голям обем

Загуба на подробни статистически данни за наблюдение по време на изпълнение и произход от данни – особено анализи на въздействието на метаданните при промени в различни файлове, таблици или неструктурирани източници

Загуба на модулност поради базиран на набор дизайн за производителност – и загуба на функционалност/гъвкавост, произтичаща от това

Трансформациите биха използвали ресурси на базата данни, което потенциално ще повлияе на производителността на BI-отчитането – да не говорим за производителността на заявките и други операции с база данни

Впоследствие се появяват хибридни архитектури като ETLT, TELT и дори TETLT в опит да се засилят слабостите в двата подхода. Но изглежда, че те добавят допълнителни нива на сложност към процесите, които вече са изпълнени. Наистина няма сребърен куршум и много проекти за интегриране на данни се провалят под тежестта на SLA, превишаване на разходите и сложност.

Поради тези причини IRI изгради Voracity за интегриране на данни чрез програмата CoSort SortCL в съществуващи файлови системи или тъкани на Hadoop без повторно кодиране. Voracity е единствената ETL-ориентирана (макар и поддържаща ELT) платформа, която предлага и двете опции за външни трансформации на данни. В допълнение към превъзходната цена-производителност при движение и манипулиране на данни, Voracity включва:

разширено преобразуване на данни, качество на данните, MDM и отчитане
бавно променящи се измерения, промяна на събирането на данни, обединяване на данни
профилиране на данни, маскиране на данни, генериране на тестови данни и управление на метаданни
прости 4GL скриптове, които вие или съветниците, диаграми и диалози на Eclipse създавате и управлявате
безпроблемно изпълнение в Hadoop MR2, Spark, Spart Stream Storm и Tez
поддръжка за erwin Smart Connectors (преобразуване от други ETL инструменти)
родни драйвери на MongoDB и връзки към други NoSQL, Hadoop, облачни и наследени източници
вградено отчитане, статистически данни и функции за прогнозиране, връзки с KNIME и Splunk и емисии с данни за аналитични инструменти.

Вижте също:

http://www.iri.com/blog/data-transformation2/etl-elt-iri-in-between
http://www.iri.com/solutions/data-integration/etl
http://www.iri.com/solutions/data-integration/elt
http://www.iri.com/solutions/data-integration/implement