Úplné zveřejnění:Jelikož je tento článek napsán společností zaměřenou na ETL s její silnou stránkou při manipulaci s velkými daty mimo databáze, nebude se to, co následuje, mnohým zdát objektivní. Přesto má stále představovat podnět k zamyšlení a otevírá prostor pro diskusi.
Od svých počátků mají architekti datových skladů (DWA) za úkol vytvořit a naplnit datový sklad daty z různých zdrojů a formátů. Kvůli dramatickému nárůstu objemů dat jsou tito DWA vystaveni výzvě k efektivnější implementaci integrace dat a přípravných operací. Otázka, zda k transformaci dat dojde uvnitř nebo vně cílové databáze, se stala kritickou kvůli výkonu, pohodlí a finančním důsledkům.
V operacích ETL (extract, transform, load) jsou data extrahována z různých zdrojů, transformována samostatně a načtena do DW databáze a případně dalších cílů. V ELT jsou extrakty vkládány do jediné pracovní databáze, která také zpracovává transformace.
ETL zůstává převládající, protože trh vzkvétá s osvědčenými hráči, jako jsou Informatica, IBM, Oracle – a IRI s Voracity, který kombinuje transformace FACT (Fast Extract), CoSort nebo Hadoop a hromadné načítání ve stejném GUI Eclipse – k extrakce a transformaci dat. Tento přístup zabraňuje zatěžování databází určených pro ukládání a vyhledávání (optimalizace dotazů) režií rozsáhlé transformace dat.
S vývojem nové databázové technologie a hardwarových zařízení, jako je Oracle Exadata, která zvládnou transformace „v krabici“, však může být ELT za určitých okolností praktickým řešením. A izolace fází (zatížení) a sémantické (transformace) vrstvy má specifické výhody.
Citovanou výhodou ELT je izolace procesu zatížení od procesu transformace, protože odstraňuje vlastní závislost mezi těmito fázemi.
Všimli jsme si, že přístup IRI ETL je stejně izoluje, protože Voracity uvádí data do systému souborů (nebo HDFS). Jakýkoli datový blok vázaný pro databázi lze získat, vyčistit a transformovat externě před (předem seřazeným) načtením. To odstraňuje zátěž velkých transformací z databáze (stejně jako BI/analytické nástroje atd.).
Objemy dat a rozpočty jsou často tím, co určuje, zda by měl DWA vyvinout řešení ETL nebo ELT. Vincent McBurney ve svém článku na blogu ITToolbox „So What Is Better, ETL or ELT?“ (Takže co je lepší, ETL nebo ELT? uživatelé s orientací na věc (podle mého počátečního výhrady k subjektivitě):
Pros ETLNevýhody ETL
- ETL dokáže vyvážit pracovní zátěž a sdílet pracovní zátěž s RDBMS – a ve skutečnosti tuto zátěž odstranit transformací dat pomocí programu SortCL nebo Hadoop bez kódování ve Voracity
- ETL může provádět složitější operace v jednotlivých diagramech toku dat prostřednictvím datových map – jako u mapování Voracity a diagramů pracovních toků, které také abstrahují krátké, otevřené 4GL skripty vs. SQL
- ETL lze škálovat pomocí samostatného hardwaru – na krabicích s komoditami můžete nakupovat a udržovat sami za mnohem nižší náklady než zařízení od jednoho dodavatele
- ETL zvládne dělení a paralelismus nezávisle na datovém modelu, rozložení databáze a architektuře zdrojového datového modelu – přestože úlohy CoSort SortCL Voracity nemusí být vůbec rozděleny…
- ETL dokáže zpracovávat data in-stream při přenosu ze zdroje do cíle – nebo dávkově, pokud to dává smysl
- ETL ke své práci nevyžaduje společné umístění souborů dat – umožňuje vám udržovat stávající platformy zdrojů dat bez starostí se synchronizací dat
- ETL dnes zachycuje obrovské množství linie metadat – jak dobře nebo intuitivně to dokáže jeden staging DB?
- ETL může běžet na hardwaru SMP nebo MPP – který opět můžete spravovat a využívat efektivněji a nemusíte se obávat sporů o výkon s DB
- ETL zpracovává informace řádek po řádku a zdá se, že to funguje dobře s integrací dat do produktů třetích stran – ještě lepší je úplný blok, tabulka nebo soubor(y) najednou, které Voracity spouští ve svazku.
Pros ELT
- Pro motory ETL jsou zapotřebí další investice do hardwaru – pokud je nespustíte na databázových serverech
- Dodatečné náklady na budování systému ETL nebo licencování nástrojů ETL – které jsou stále levnější ve srovnání se zařízeními ELT, ale stále levnější jsou nástroje IRI jako Voracity, které kombinují Fast Extract (FACT) a CoSort pro urychlení ETL bez takové složitosti
- Možná snížená výkonnost přístupu založeného na řádcích – správně a proč je schopnost Voracity profilovat, získávat, transformovat a vydávat data ve větších blocích rychlejší
- Pro implementaci nástroje ETL jsou vyžadovány speciální dovednosti a křivka učení – pokud nepoužíváte ergonomické grafické uživatelské rozhraní, jako je Voracity, které poskytuje více možností návrhu úlohy ve stejném IDE Eclipse
- Snížená flexibilita kvůli závislosti na dodavateli nástrojů ETL – Nejsem si jistý, jak by se to zlepšilo tím, že se místo toho spoléhám na jediného dodavatele ELT/zařízení; není nezávislost na prodejci klíčem k flexibilitě a úsporám nákladů?
- Data musí projít ještě jednou vrstvou, než se dostanou do datového tržiště – pokud tento tržiště nebyl jen dalším výstupem procesu ETL, typického pro operace Voracity s více cíli.
Nevýhody ELT
- ELT využívá hardware motoru RDBMS pro škálovatelnost – ale také zdaňuje zdroje DB určené pro optimalizaci dotazů. Transformace CoSort a Hadoop ve Voracity využívají algoritmy lineárního škálování a konsolidaci úkolů, nikoli paměť nebo I/O zdroje DB
- ELT neustále uchovává všechna data v RDBMS – což je v pořádku, pokud jsou zdrojová a cílová data ve stejné databázi
- ELT je paralelizován podle datové sady a diskové I/O jsou obvykle optimalizovány na úrovni enginu pro rychlejší propustnost – ano, ale to platí ještě více o externích transformacích, které se nepotýkají s prostředky DB serveru
- ELT se škáluje, dokud se může hardwarový a RDBMS modul dále škálovat – co stojí v porovnání s výše uvedenou alternativou?
- ELT může dosáhnout 3x až 4x vyšší propustnosti na vhodně vyladěné platformě MPP RDBMS – což staví zařízení na výkonnostní úrovně Voracity ve srovnání s nástroji ETL také, ale s 20násobnou cenou.
- Transformace ELT se provádí na serveru RDBMS, jakmile je databáze na cílové platformě a již nezatěžuje síť – takže místo toho zatěžuje databázi (uživatele)?
- ELT má jednoduché specifikace transformace prostřednictvím SQL – které nejsou tak jednoduché, flexibilní nebo tak bohaté na funkce jako syntaxe CoSort SortCL nebo mapování polí přetažením v grafickém uživatelském rozhraní Voracity’s Eclipse.
- K dispozici jsou omezené nástroje s plnou podporou ELT – a za velmi vysoké ceny pro zařízení DB nabízející velkoobjemový výkon
- Ztráta podrobných statistik sledování za běhu a datové řady – zejména analýzy dopadu metadat na změny v různých souborech, tabulkách nebo nestrukturovaných zdrojích
- Ztráta modularity díky designu založenému na množinách pro výkon – a z toho plynoucí ztráta funkčnosti/flexibility
- Transformace by využívaly databázové zdroje, což by potenciálně ovlivnilo výkon BI reportů – nemluvě o výkonu dotazů a dalších DB operací
Hybridní architektury jako ETLT, TELT a dokonce i TETLT se následně objevují ve snaze podpořit slabiny obou přístupů. Zdá se však, že přidávají další úrovně složitosti procesům, které jsou již tak zatížené. Ve skutečnosti to není nic platné a mnoho projektů datové integrace selhává pod tíhou dohod SLA, překračování nákladů a složitosti.
Z těchto důvodů IRI vytvořilo Voracity pro integraci dat prostřednictvím programu CoSort SortCL do stávajících souborových systémů nebo hadoopových tkanin bez překódování. Voracity je jediná platforma orientovaná na ETL (i když také podporující ELT), která nabízí obě možnosti externí transformace dat. Kromě vynikající ceny a výkonu v oblasti pohybu a manipulace s daty zahrnuje Voracity:
- pokročilá transformace dat, kvalita dat, MDM a vytváření přehledů
- pomalu se měnící dimenze, sběr dat změn, federace dat
- profilování dat, maskování dat, generování testovacích dat a správa metadat
- jednoduché 4GL skripty, které vytváříte a spravujete vy nebo průvodci Eclipse, diagramy a dialogy
- bezproblémové provádění v Hadoop MR2, Spark, Spart Stream Storm a Tez
- podpora erwin Smart Connectors (konverze z jiných nástrojů ETL)
- nativní ovladače MongoDB a připojení k dalším zdrojům NoSQL, Hadoop, cloud a starším zdrojům
- vestavěné hlášení, statistiky a prediktivní funkce, propojení KNIME a Splunk a zdroje dat z analytických nástrojů.
Viz také:
- 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