it-swarm-eu.dev

Jaké jsou argumenty pro použití procesu ELT oproti ETL?

Uvědomil jsem si, že moje společnost používá proces ELT (extrakt-zatížení-transformace) místo použití procesu ETL (extrakt-transformace-zatížení).
Jaké jsou rozdíly ve dvou přístupech a ve kterých situacích by byl jeden „lepší“ než druhý? Bylo by skvělé, kdybyste mohli uvést některé příklady.

19
What'sUP

spousta diskusí o ETL vs ELT venku.

Hlavní rozdíl mezi ETL vs ELT je , kde probíhá zpracování , ETL zpracování dat se děje v nástroji ETL (obvykle záznam v čase a obvykle v paměti) Zpracování dat ELT probíhá v databázovém stroji

Data jsou stejná a konečných výsledků dat lze dosáhnout oběma metodami.

velmi záleží na vás a vašem prostředí Pokud máte silný databázový stroj a dobrý hardware a můžete na něm provádět těžké zpracování, ELT je pro vás dobré, pokud máte zaneprázdněný modul datawarehouse a potřebujete jej osvobodit od zpracování pro ETL.

všimněte si, že nástroj ETL vám dává obě možnosti, jako ETL (T), můžete provést transformaci v nástroji ETL a můžete také provést transformaci v databázovém stroji

ale ELT máte pouze možnost transformace v databázovém stroji, ale měli byste vědět, že databáze jsou v operacích založených na sadách lepší než nástroje ETL pro záznam v čase.

podobná otázka položená TAK ale podporující ETL a také pěkné článek porovnání ETL vs ELT, ale upřednostňování ELT

13
AmmarR

Je to téměř otázka sémantiky. Při debatách o tom dojde k uvolnění velkého množství horkého vzduchu, ale nejsem přesvědčen, že existuje skutečná filozofická hloubka pro rozlišení mezi nimi.

Na určité úrovni si můžete ETL prohlížet jako transformující data v nástroji na straně klienta před jeho konečným načtením, s ELT, což znamená, že data jsou přenesena do nějakého druhu pracovní oblasti s relativně malou změnou formátu. Poté následuje „transformace“.

Jedná se o velmi nadýchané definice a lze je použít na širokou škálu technických architektur a existuje mnoho možných návrhů, které by bylo možné použít pro označení obou termínů.

Velmi podporuji architekturu, ve které lze veškerou transformační a obchodní logiku zabudovat do víceméně homogenní kódové základny, a udělal jsem mnoho systémů, kde byla transformační logika docela složitá. To inklinovalo k použití dat pouze nástroj ETL a poté byla veškerá transformace provedena v uložených procedurách. Pravděpodobně by to mohlo být popsáno jako ETL nebo ELT s tím rozdílem, že jde pouze o sémantiku.

Některé nástroje se však velmi zaměřují na databáze (například Oracle Data Integrator je často označován jako nástroj ELT). Pokud se přihlásíte k odběru tohoto zobrazení, děje se „Rozbalit“ a „Načíst“ před tím, než se data transformují, když jsou vyložena do pracovní oblasti, a poté je rozdrtí kódem SQL nebo PL/SQL (který může být vygenerován nástrojem nebo ručně psané). Zdá se, že několik lidí, se kterými jsem mluvil, považuje hlavní přínos ODI za to, že to není OWB.

Pokud používáte nástroj na straně klienta, jako je například Informatica Powercentre nebo MS SQL Server Integration Services, může tento nástroj provést rozsáhlou transformaci na straně datového klienta. Některé nástroje ETL, jako jsou Ascential Datastage a Ab Initio, jsou navrženy tak, aby pro rychlou práci s plochými soubory a datovými strukturami v paměti pracovaly hodně práce. V tomto druhu architektury již byla transformace provedena před jejím načtením. Možná by tento typ architektury mohl být definitivně klasifikován jako „ETL“, ačkoli jsem viděl mnoho projektů zaměřených na nástroje, kde veškerou skutečnou práci provádí hromada kódu uložené procedury.

Existují výhody různých nástrojů a architektonických přístupů, ale nelze vyložit obecné prohlášení o výhodnosti přístupů „ETL“ vs. „ELT“, protože podmínky jsou tak široké, že rozdíl je téměř bezvýznamný. Některé nástroje a architektury mohou mít specifické výhody - například velké množství plochých souborů Ab Initio mu poskytuje významnou výhodu výkonu na velkých objemech dat.

V praxi je rozlišení mezi „ETL“ a „ELT“ zcela bezvýznamné, aniž by bylo nutné projít mnohem hlubší diskusi o systémových požadavcích, platformě a technické architektuře.

Je to také otázka peněz. Pokud poukazujete na objemy dat vysoké, řešení založená na plochých souborech, jako je Ab Initio a DataStage Parallel Extender, jsou sice rychlejší, ale mohou to být středně vysoké až šestimístné návrhy. IRI CoSort je velmi ETL-centric (na základě jejich ELT srovnání), a jediný dostupný způsob, jak jsem viděl, jak řešit objem transformace rychlostí systému souborů, kromě složité implementace Hadoop. Také si myslím, že házení hardwaru obecně na problém (které spotřebiče ELT a DB v paměti také dělají), neměří měřítko také z hlediska nákladů.

1
Suraj Singh