Offloading představuje extract, load, transform (ETL) process přenosu obrovského množství dat z Enterprise Data Warehouse (EDW) do platforem velkých dat. Znamená jeden z klíčových kroků, které společnosti, jež chtějí začít využívat Big Data a rozšířenou analytiku, musejí překonat.

S rostoucím množstvím dat stoupá i potřeba velká data zpracovávat či ukládat. Tradiční datové sklady mohou být pro některé typy dat neefektivní, a tak se pro ně nabízí využít specifické platformy velkých dat. Typicky jde o logová, senzorová či signální data, jež se generují ve velkém objemu a která získávají na hodnotě až zpracováním a propojením s dalšími daty, např. s profilem zařízení či zákazníka. Jak ale zajistit, aby propojení velkých dat a (tradičních) profilových dat bylo vždy aktuální a úplné?

Jednou z variant je pravidelně přesouvat klíčová data z tradičních datových skladů (EDW) na Big Data platformu. O aspektech zajištění pravidelného přenosu dat z EDW pojednávají následující řádky.

Datové přenosy do EDW

Integrace mnoha datových zdrojů do jednoho firemního prostředí (Enterprise Data Warehouse čili EDW) obecně zajišťují tzv. ETL procesy. Ty představují nejen získání dat z datových zdrojů (extrakce dat), ale i transformaci (normalizace, denormalizace, změny struktury) a nahrání dat (loading) do EDW, kde se dále zpracovávají, analyzují a reportují.

Cílem ETL procesů je zajistit uživateli vhodný pohled na data, která generují různé systémy, a poskytnout mu potřebné informační podklady pro podporu rozhodování. 

Datové přenosy do BD platformy

S pořízením platformy Big Data (BD) nebo někdy též Big Data Warehouse (BDW) se IT architektura a princip datových přenosů stávají mírně složitějšími. Nová platforma se musí propojit jak se systémy, které generují velké objemy dat, tak i s EDW, kde jsou zpravidla kvalitní a spolehlivé informace z podnikání společnosti.

A právě v souvislosti s plněním BDW se v rámci ETL procesů objevuje nový pojem – „offloading“. Ten označuje ETL proces, který má za úkol plnit BDW. Offloading představuje přenos obrovského množství dat z ERW do BDW. Někdy se tato úloha také označuje jako zrcadlení (mirroring) dat.

Výhody EDW

Data pocházející z enterprise data warehouse mají obecně vysokou cenu a kvalitu, neboť pro jejich získání investovaly společnosti často nemalé prostředky a úsilí. Benefity, které EDW přináší, nejsou zanedbatelné, a proto je účelné je plně využít i v rámci propojení s BDW. Jde především o:

  • Ukládání dat: umožňuje ukládat data, upravovat a historizovat.
  • Přístup k datům: umožňuje uživatelům přistupovat k datům, která byla dostupná pouze ve zdrojových systémech.
  • Analyzování dat: umožňuje analyzování dat, tvorbu reportovacích nástrojů a přípravu podkladů pro rozhodování Enterprise data warehouse dovoluje určitou škálovatelnost těchto benefitů podle potřeb společnosti, potom už jen záleží na typu organizace a jejích datových zdrojích, zda je tato škálovatelnost dostatečná.

Výhody BDW

Společnosti, jako jsou banky, finanční instituce, retail nebo telekomunikace, často narážejí na to, že jejich EDW nestačí v jednomz předchozích benefitů, a pořídí si BDW. Ten nejenže poskytuje všechny předchozí výhody, ale přináší i nové: má mnohem větší škálovatelnost (levnější storage, paralelní zpracování dat nebo podporuje ce- lou škálu analytických nástrojů než jen SQL).

Současné trendy vedou velké podniky k tomu, aby si pořídily BDW, nicméně interní IT často neví, k čemu jim přesně taková platforma může být a jak ji architektonicky zasadit do infrastruktury.

Jednou z motivací může být potřeba „odlehčit“ rostoucím nárokům na EDW. V tomto případě přichází na řadu klíčové architektonické rozhodnutí, zda uskutečnit „migraci“ EDW na BDW nebo jestli firma rozšiřuje existující EDW o prostředí BDW. V prvním případě čeká společnost velmi radikální a náročný proces migrace, ve druhém případě, tedy při rozšíření EDW o prostředí BDW, bude potřebovat vyřešit „offloading“ dat.

Obr. 1: Integrace dat z různých systémů do EDW

Offloading dat

Offloading představuje způsob, jak data dostupná v EDW nabídnout rovněž v prostředí BDW. Jeho cílem je zajistit, aby data z EDW byla k dispozici na BDW pro jejich propojení a umožnila tvorbu nových nebo bohatších pohledů na klíčové podnikání společnosti.

Co tedy offloading musí zajišťovat:

  • Přenos dat mezi EDW a BDW, tedy musí být schopný přenést data (jednosměrně/o­bousměrně).
  • Konzistenci dat mezi EDW a BDW, tedy struktury na EDW a BDW musejí být identické (tak, jak to povolují prostředí).
  • Přenos práv, tedy uživatelé, kteří mají práva na EDW, musejí mít práva i na BDW (jednosměrně/ obousměrně).
  • Škálovatelnost a šetrnost, tedy nesmí způsobovat nestabilitu EDW a BDW.
  • Auditovatelnost výsledků, tedy musí poskytovat reporting a informace o přenosech.

Způsoby přenosu dat

V rámci přenosu dat mezi EDW a BDW je nutné především vyřešit, jak bude přenos probíhat. V tomto ohledu lze identifikovat dva způsoby přenosu.

Prvním je nepřímý způsob přenosu, kdy EDW připravuje pravidelně extrakty (batche) na vybraný server, odkud se potom přes STFP nebo jiný způsob přenosu přenášejí na BDW. BDW tyto extrakty zpracuje a připraví je pro finální uložení. Nepřímý způsob se preferuje, pokud objem dat není příliš velký, anebo když není možné z hlediska bezpečnosti učinit druhý způsob přenosu.

Druhý způsob přenosu lze označit jako přímý, kdy se mezi EDW a BDW udělá přímé propojení a vybere se technologie, která je schopna navázat spojení a dokáže data přenést napřímo bez nutnosti vytvářet „extrakt“. V tomto případě se nejčastěji volí technologie nativní pro BDW, jako jsou Apache Sqoop, Apache Spark či Apache Kafka, nebo se volí technologie vhodná pro vybrané prostředí EDW.

Režim přenosu

Další architektonickou výzvou je určit, kdy a jaká data přenášet, aby byla zachována jejich aktuálnost.
Z hlediska plánování přenosu je důležité, aby se aktualizace dat ze zdrojových ETL do EDW nepřekrývala s offloadem.

Tabulky se mohou přenášet ve dvou základních režimech. První režim je full, který představuje přenos celé tabulky (využívá se pro malé tabulky do 100 000 řádků), zatímco druhý typ přenosu lze označovat jako inkrementální, zde jde pouze o přenos vybraných dat (ideální pro velké tabulky nad 100 000 řádků).

Pro inkrementální přenos je důležité si uvědomit, že se nejčastěji dělá v režimu forward (tedy pouze nová data) nebo recent (nová data a aktualizace posledních přenosů), ale měl by podporovat možnost aktualizace historických dat.

Obr. 2: Přenos dat z EDW na BDW

Připravenost dat ve vrstvách

Při přenosu dat je nutné zajištění jejich konzistence, tzn. je třeba věnovat pozornost datovým typům a vyvarovat se nebezpečí ztráty přesnosti. Proto se na straně EDW vytváří output vrstva, kde se data před přenosem upravují do struktury, která je přívětivá pro přenos.

Na straně BDW se naopak vytváří landing vrstva, kde data přistávají a ukládají se v kompatibilní struktuře. Data z landing vrstvy se v BDW následně přenášejí do cílové vrstvy, kde už jsou přístupná běžnému uživateli.

Transformační příkazy

Přenos mezi zdrojem a output vrstvou se zajišťuje na straně EDW. V EDW se tento přenos řeší s pomocí přeuložení existujících dat nebo s pomocí pohledů na zdrojová data. V obou případech je nutné dělat převod datových typů (na kompatibilní datové typy). Na EDW output vrstvu potom navážou tzv. offload joby, které zajistí přesun dat do BDW landing vrstvy.

Přenos mezi landing vrstvou a cílovou vrstvou zajišťují tzv. transformační příkazy. Ty slouží k odstranění nevalidních znaků (některé EDW často generují ve výstupech znaky, které nejsou kompatibilní) a převodu datových typů (z kompatibilních na cílové).

Pro exekuci těchto kroků se mohou využívat Apache Hive, Apache Impala, Apache Kafka, Apache Spark nebo jiná technologie nativní pro BDW.

Metadata

Významnou roli pro udržení konzistence dat hrají způsob a úroveň synchronizace metadat. Jejich struktury na BDW lze:

  • vytvářet přímo pro BDW (nezávislé na EDW),
  • odvozovat ze struktur v EDW,
  • generovat z externího zdroje (pro EDW a pro BDW).

Metadatová kontrola se může uskutečnit jednou denně (pokud jsou změny v EDW pravidelně plánované) anebo před každým přenosem (pokud EDW povoluje ad hoc změny struktur). V každém případě změna struktury v EDW by se měla projevit jak na output vrstvě (v EDW), tak i v landing a cílové vrstvě (v BDW).

Output vrstva může být tvořena pevně (znovu ukládá upravená data) nebo ve formě pohledů (kdy se data pouze přetransformují v kompatibilní datové typy, popřípadě v redukovaná data, která jsou určena k přenosu). Finální varianta pak záleží pouze na možnostech EDW.

Řízení přenosu dat

Pro řízení přenosu dat se může použít scheduler, který společnost už má a používá pro řízení přenosu dat a zpracování v EDW. Na něj naváže offloading, jenž začne přenášet už zpracovaná data. Pokud tento postup není možný, lze pro offloading vytvořit vlastní scheduler, nebo vlastní API, které bude přijímat požadavky na přenos dat. Nakonec je nutné myslet na dohledatelnost všech učiněných úkonů, proto je potřeba zajistit místo, kam se budou metadata z offloadingu ukládat a odkud budou k dispozici auditu.

Metadata zahrnují informace jak o strukturách přenášených tabulek, tak o vlastních datových přenosech a přehled nastavení parametrů přenosu. K tomuto účelu může sloužit tradiční relační databáze (MariaDB nebo Postgre). Nad ní je možné tvořit sestavu dashboardů, které poskytují IT infrastruktuře informace o probíhajících a dokončených přenosech.

Obousměrnost

Offloading jako ETL proces není pouze jednosměrný, ale měl by podporovat i možnost vracet data (např. zajímavé výsledky z analýz dat) z BDW do EDW. Pak je nutné reverzně vytvořit output vrstvu na BDW a landing vrstvu na EDW.

Uživatelský přístup

Zajištění kvalitních a včasných dat na obou platformách vede k tomu, že koncoví uživatelé mají možnost volby, zda k práci s daty využijí EDW, nebo BDW. Důležité je, že „tradiční“ data EDW budou na obou místech stejná.

Aby se koncoví uživatelé mohli svobodně rozhodovat, je nutné adekvátně vyřešit přenos práv uživatelů. V rámci EDW se práva často řeší pomocí systému správy práv uživatelů (LDAP, AD atd.), odkud se generují práva uživatelů pro EDW.

Pro BDW je třeba zajistit totéž. Ale protože BDW podporuje větší počet technologií, je tato úloha poněkud složitější, než je tomu v případě EDW.

Soubor více rozhodnutí

Vytvořit ve firmách s velkými daty kvalitní datové zázemí je skutečně výzvou. Většinou musí IT najít odpovědi na celou řadu koncepčních otázek. Často je nutné vzít v potaz strategická rozhodnutí společnosti o jejím směřování a potřebě inovací.

Propojení tradičních EDW (nebo i několika EDW) s BDW se může opírat o koncept offloadingu, i pokud jde o přesuny dat mimo firmu do cloudových technologií. Komplexnost datových služeb nicméně klade i zvýšené nároky na provoz interního IT. Proto promyšlená automatizace přenosů dat z jednotlivých platforem formou propracovaného offloadingu může IT oddělení leccos ulehčit. A zároveň přinést vyšší komfort, kvalitu a rozsah dat pro využití v byznysu. Data musejí firmám přinášet klíčové informace a podpořit konkurenceschop­nost, akceschopnost či inovace. 

Reálný příklad využití offloadingu na závěr

Enterprise Data Warehouse (EDW), který obsahuje 10 000 tabulek (celkem 200–500 GB), je potřeba každý den aktualizovat. Neexistuje externí zdroj metadat k tabulkám a jediným zdrojem je právě EDW.

Z hlediska rozložení dat je poměr malých a velkých tabulek 9 : 1. EDW povoluje uskutečnit přenos po dobu osmi hodin každý den. Na přenos lze použít přímé spojení.

V rámci tohoto spojení se vytvářejí jak tzv. robustní spojení, která dokážou přenést jakoukoliv tabulku, tak rychlá spojení, která umějí přenést pouze malé tabulky. Společnost má k dispozici scheduler a chce s jeho pomocí řídit všechny přenosy.

Alternativy řešení

Zvolí-li se pro přenos na BDW přímý způsob, vytvoří se v rámci povolených osmi hodin jedno spojení, které je velmi robustní a dokáže přenést libovolnou tabulku v rozmezí jedné až deseti minut. Výhodou tohoto přenosu je, že je velmi šetrný, neboť jen velmi málo zatěžuje EDW.

Nicméně se ukazuje, že za předpokladu, že by průměrný přenos jedné tabulky trval dvě minuty, zabral by celkový přenos přibližně 13 dní. Nevýhoda tohoto řešení je tedy zřejmá.

Alternativně lze úlohu řešit tak, že se k přenosu tabulek vytvoří 100 paralelních vláken, které zajistí větší rychlost. Celý přenos by se stihl za tři a půl hodiny, tudíž časovou podmínku plní. Nevýhodou však je, že by takový přenos vedl k nestabilitě EDW systému, protože EDW musí na všechny tyto prostředky dedikovat své zdroje, nejčastěji RAM a CPU, které ale nemusejí být k dispozici (musejí ještě zajistit/uložit data ze svých zdrojo- vých systémů).

Kombinace obou způsobů

Pro vyřešení tohoto případu je nutné nejprve si ujasnit, jak se přenos uskuteční. Protože má společnost k dispozici scheduler, dojde poté, co budou data k přenosu připravena (naplněna output vrstva), k zapnutí přenosu.

Z hlediska přenosu se často hledá alternativa mezi počtem spojení a nároky na RAM a CPU v EDW. V tomto případě lze například zvolit 1–2 robustní přenosy pro velké tabulky a 10–20 rychlých připojení, která zajistí přenos všech malých tabulek.

Jakmile jsou data k dispozici na landing vrstvě, dojde k finálnímu zpracování. Protože se pracuje s obrovským počtem tabulek, lze z hlediska kontroly přenosu spojovat tabulky do tzv. stahovacích procesů, tyto procesy jsou potom konfigurovatel­né v schedule­ru.

Aby bylo možné tento přenos vykonávat automaticky, je nutné zajistit synchronizaci metadat mezi EDW a BDW. Pro synchronizaci metadat se volí varianta synchronizace EDW struktur s BDW, tzn., že se pro každou tabulku z EDW vygeneruje její struktura a použije se v BDW jak pro landing vrstvu, tak pro cílovou vrstvu.

Nakonec je nutné zajistit, aby se veškerý přenos detailně zdokumentoval, protože offloading generuje obrovské množství logů. Pro tyto účely je vhodné využít nějakou relační databázi.

Vytvoří se tabulky, které budou logovat metadata z přenosu, metadata tabulek (ukládat struktury tabulek v čase pro auditní účely), ukládat nastavení přenosu.

Tato databáze se musí synchronizovat se schedulerem a na základě jejího nastavení budou probíhat všechny přenosy. Ve finále lze potom nad touto databází vytvořit sadu dashboardů pro zajištění monitoringu a auditu přenosu.

 

Autor článku: Marcel Vrobel, specialista na Big Data, Adastra

Zdroj: Computer World 1/19