Jak přistupovat k misi ETL?

Některé obecné tipy ETL

1. Zvažte jeho uspořádání podle cíle (například veškerý kód pro vytvoření Customerdimension žije ve stejném modulu, bez ohledu na zdroj). To je někdy známé jako předmětově orientované ETL. Díky tomu je hledání věcí mnohem jednodušší a zvýší se udržovatelnost vašeho kódu.

2. Pokud je databáze SQL2000 nepořádek, pravděpodobně zjistíte, že toky dat SSIS jsou neohrabaný způsob, jak s daty nakládat. Nástroje ETL se zpravidla špatně škálují se složitostí; něco jako polovina všech projektů datových skladů ve finančních společnostech se provádí s kódem uložených procedur jako explicitním architektonickým rozhodnutím – přesně z tohoto důvodu. Pokud musíte vložit velké množství kódu insprocs, zvažte umístění všech kódu v sprocs.
   
   Pro systém, který zahrnuje mnoho složitých čištění nebo transformací, je 100% sproc přístup mnohem lépe udržovatelný, protože je to jediný proveditelný způsob, jak umístit všechny transformace a obchodní logiku na jedno místo. U smíšených systémů ETL/sproc se musíte dívat na více místech, abyste mohli sledovat, odstraňovat problémy, ladit nebo měnit celou transformaci.

3. Sladké místo nástrojů ETL je na systémech, kde máte větší počet zdrojů dat s relativně jednoduchými transformacemi.

4. Udělejte kód testovatelný, takže si můžete oddělit komponenty a izolaci testinů. Kód, který lze spustit pouze uprostřed komplexního datového toku v nástroji ETL, je mnohem těžší testovat.

5. Udělejte extrahování dat hloupé pomocí nepodnikatelské logiky a zkopírujte je do předváděcí oblasti. Máte-li obchodní logiku rozprostřenou napříč vrstvami extraktu a transformace, budete mít transformace, které nelze testovat izolovaně a znesnadňují sledování chyb. Pokud je transformace spuštěna z přípravné oblasti, snížíte silnou závislost na zdrojovém systému, což opět zvýší testovatelnost. Toto je zvláštní vítězství na architekturách založených na sproc, protože umožňuje téměř zcela homogenní kódovou základnu.

6. Sestavte generický obslužný program pomalu se měnících rozměrů nebo použijte jeden z poličky, pokud je k dispozici. Testování této funkčnosti je proto snazší. Pokud to lze unittestovat, testování systému nemusí testovat všechny rohové skříně, pouze to, zda jsou prezentovaná data správná. Není to tak složité, jak to zní - Poslední, který jsem napsal, byl asi 600 nebo 700 řádků kódu T-SQL. Totéž platí pro všechny obecné funkce čištění.

7. Pokud je to možné, nabíjejte postupně.

8. Použijte svůj kód – nechte jej provést záznamy do protokolu, případně zaznamenat diagnostiku, jako je kontrola součtů nebo počtů. Bez toho je odstraňování problémů téměř nemožné. Kontrola asercí je také dobrý způsob, jak uvažovat o zpracování chyb (počítají se řádky ve stejném počtu řádků v b, je vztah A:B skutečně 1:1).

9. Používejte syntetické klíče. Použití přirozených klíčů ze zdrojových systémů spojuje váš systém se zdroji dat a ztěžuje přidávání dalších zdrojů. Klíče a vztahy v systému by měly být vždy zarovnány - žádné nuly. V případě chyb „nezaznamenáno“ zadejte v tabulce dimenzí konkrétní položky „chyba“ nebo „nezaznamenáno“ a přiřaďte je.

10. Pokud vytvoříte úložiště provozních dat (předmět mnoha náboženských válek), nerecyklujte klíče ODS ve hvězdných schématech. V každém případě spojte klíče ODS a vytvořte rozměry, ale shodujte se s přirozeným klíčem. To vám umožňuje libovolně vypustit a znovu vytvořit ODS - případně změnit jeho strukturu - bez narušení hvězdných schémat. Mít tuto schopnost je skutečnou výhrou v údržbě, protože kdykoli můžete změnit strukturu ODS nebo provést přemístění ODS hrubou silou.

Body 1-2 a 4-5 znamenají, že můžete vytvořit systém, kde je vše kódu pro jakýkoli daný subsystém (např. jedna dimenze nebo tabulka faktů) žije na jednom a pouze jednom místě v systému. Tento typ architektury je také lepší pro větší počet zdrojů dat.

Bod 3 je protipólem bodu 2. Volba mezi nástroji SQL a ETL je v zásadě funkcí složitosti transformace a počtu zdrojových systémů. Čím jednodušší data a větší počet zdrojů dat, tím silnější je argument pro přístup založený na nástrojích. Čím složitější jsou data, tím silnější je důvod pro přechod na architekturu založenou na uložených procedurách. Obecně je lepší používat výhradně nebo téměř výhradně jedno nebo druhé, ale ne obojí.

Bod 6 usnadňuje testování vašeho systému. Testování SCD nebo jakékoli funkce založené na změnách je nešikovné, protože musíte být schopni prezentovat systému více než jednu verzi zdrojových dat. Pokud funkci správy změn přesunete do kódu infrastruktury, můžete ji otestovat izolovaně s testovacími datovými sadami. Toto je vítězství v testování, protože to snižuje složitost požadavků na testování vašeho systému.

Bod 7 je obecný tip na výkon, který budete muset dodržovat u velkých objemů dat. Všimněte si, že můžete potřebovat pouze přírůstkové načítání pro některé části systému; pro menší referenční tabulky a rozměry jej možná nebudete potřebovat.

Bod 8 je relevantní pro jakýkoli bezhlavý proces. Pokud se to během noci zvedne, budete chtít další den bojovat, abyste viděli, co se pokazilo. Pokud kód správně nezaznamená, co se děje, a nezachytí chyby, budete mít mnohem těžší práci s jeho odstraňováním.

Bod 9 dává datovému skladu vlastní život. Zdrojové systémy můžete snadno přidávat a rušit, když má sklad vlastní klíče. Klíče skladu jsou také nezbytné k implementaci pomalu se měnících rozměrů.

Bod 10 je vítězstvím v oblasti údržby a nasazení, protože ODS lze restrukturalizovat, pokud potřebujete přidat nové systémy nebo změnit mohutnost záznamu. Znamená to také, že dimenzi lze načíst z více než jednoho místa v ODS (myslím:přidání ručních účetních úprav) bez závislosti na klávesách ODS.