ETL komponenta datového skladu je často zastíněna samotným skladem a dostává méně pozornosti než hlavní databáze nebo front-end komponenta, BI a reporting. Přitom z pohledu mechaniky plnění skladu daty hraje ETL klíčovou roli a vyžaduje neméně pozornosti administrátorů než ostatní komponenty. Jmenuji se Alexander, nyní spravuji ETL v Rostelecomu a v tomto článku se pokusím trochu podělit o to, s čím se musí potýkat správce jednoho z nejznámějších ETL systémů ve velkém datovém skladu v Rostelecomu.
Pokud milí čtenáři již obecně znáte náš projekt datového skladu a produkt Informatica PowerCenter, můžete okamžitě přejít k další sekci.
Před několika lety dozrála myšlenka jediného podnikového datového skladu a začala se implementovat v Rostelecomu. Již byla vytvořena řada úložišť, která řešila jednotlivé problémy, ale rostl počet scénářů, rostly i náklady na podporu a bylo jasné, že budoucnost je v centralizaci. Architektonicky se jedná o samotné úložiště, skládající se z několika vrstev, implementovaných na Hadoop a GreenPlum, pomocných databází, ETL mechanismů a BI.
Zároveň byl z důvodu velkého množství geograficky rozmístěných heterogenních datových zdrojů vytvořen speciální mechanismus nahrávání dat, jehož provoz řídí Informatica. Výsledkem je, že datové balíčky končí v oblasti rozhraní Hadoop, poté začínají procesy načítání dat přes vrstvy úložiště, Hadoop a GreenPlum a jsou řízeny tzv. řídicím mechanismem ETL implementovaným v Informatica. Systém Informatica je tedy jedním z klíčových prvků, který zajišťuje chod skladu.
Naše úložiště bude podrobněji popsáno v některém z následujících příspěvků.
Informatica PowerCenter/Big Data Management je v současnosti považován za vedoucí software v oblasti nástrojů pro integraci dat. Jedná se o produkt americké společnosti Informatica, která je jedním z nejsilnějších hráčů v ETL (Extract Transform Load), managementu kvality dat, MDM (Master Data Management), ILM (Information Lifecycle Management) a dalších.
PowerCenter, které používáme, je integrovaný aplikační server Tomcat, ve kterém běží samotné aplikace Informatica a implementují jeho služby:
Doména, ve skutečnosti je to základ všeho ostatního; služby, uživatelé a komponenty GRID fungují v rámci domény.
Administrátorská konzole, webový nástroj pro správu a monitorování, kromě klienta Informatica Developer, hlavního nástroje pro interakci s produktem
MRS, služba úložiště modelů, úložiště metadat, je vrstva mezi databází, ve které jsou fyzicky uložena metadata, a klientem Informatica Developer, ve kterém probíhá vývoj. V úložištích jsou uloženy popisy dat a další informace, včetně pro řadu dalších služeb Infromatica, například plány spouštění úloh (Schedules) nebo monitorování dat, a také parametry aplikace, zejména umožňující použití stejné aplikace pro práci s různé zdroje dat a přijímače.
DIS, služba integrace dat, jedná se o službu, ve které probíhají hlavní funkční procesy, běží v ní aplikace a samotné spouštění Workflows (popisy posloupnosti mapování a jejich interakcí) a Mappings (transformace, bloky, ve kterých dochází k samotným transformacím, zpracování dat ) konat.
Konfigurace GRID – v podstatě možnost vybudování komplexu pomocí několika serverů, kdy zátěž spouštěná DIS je rozdělena mezi uzly (tj. servery, které jsou součástí domény). V případě této možnosti lze kromě distribuce zátěže v DIS prostřednictvím další abstrakční vrstvy GRID, která sjednocuje několik uzlů, na kterých běží DIS místo práce na konkrétním jediném uzlu, vytvářet i další záložní instance MRS. Můžete dokonce implementovat vysokou dostupnost, kdy lze provádět externí hovory prostřednictvím záložních uzlů, pokud ten hlavní selže. Tuto možnost výstavby jsme prozatím opustili.
Informatica PowerCenter, schéma
V raných fázích práce v rámci dodavatelského řetězce dat se pravidelně objevovaly problémy, některé z nich kvůli nestabilnímu provozu Informatica v té době. Podělím se o některé z nezapomenutelných okamžiků této ságy - zvládnutí Informatica 10.
Bývalé logo Informatica
Do naší oblasti odpovědnosti patří i další prostředí Informatica, ta mají svá specifika z důvodu jiné zátěže, ale zatím si přesně vzpomenu, jak se Informatica vyvíjela jako ETL komponenta samotného datového skladu.
Jak se to stalo
V roce 2016, kdy jsme převzali odpovědnost za práci Informatica, již dosáhla verze 10.0 a optimistickým kolegům, kteří se rozhodovali použít produkt s vedlejší verzí .0 ve seriózním řešení, se vše zdálo samozřejmé - musíme použít nová verze! Z hlediska hardwarových prostředků bylo v té době vše v pořádku.
Od jara 2016 je za práci Informatica zodpovědný dodavatel a podle několika málo uživatelů systému to „fungovalo párkrát týdně“. Zde je potřeba upřesnit, že úložiště bylo de facto ve fázi PoC, v týmu nebyli žádní administrátoři a systém neustále z různých důvodů padal, načež to znovu vyzvedl inženýr dodavatele.
Na podzim se k týmu připojili tři administrátoři, kteří si mezi sebou rozdělili oblasti odpovědnosti, a začala běžná práce na organizaci provozu systémů v projektu včetně Informatica. Samostatně je třeba říci, že tento produkt není rozšířený a má velkou komunitu, ve které můžete najít odpovědi na jakékoli otázky a vyřešit jakýkoli problém. Proto byla velmi důležitá plná technická podpora od ruského partnera Informatica, s jejíž pomocí byly opraveny všechny naše chyby a chyby tehdy mladé Informaticy 10.
První, co jsme museli pro vývojáře našeho týmu a dodavatele udělat, bylo stabilizovat práci samotné Informatica, zajistit funkčnost webové administrační konzole (Informatica Administrator).
Takto jsme se často setkávali s vývojáři Informatica
Pomineme-li proces zjišťování příčin, hlavním důvodem pádů byl vzorec interakce softwaru Informatica s databází úložiště, která byla z pohledu síťového prostředí umístěna na relativně vzdáleném serveru. To způsobilo zpoždění a narušilo mechanismy, které sledují stav domény Informatica. Po určitém vyladění databáze, změně parametrů Informatica, která ji učinila tolerantnější vůči zpoždění databáze, a nakonec aktualizaci verze Informatica na 10.1 a přenesení databáze z předchozího serveru na server umístěný blíže Informatice, problém ztratil na svém a od té doby došlo k pádům tohoto druhu, které nepozorujeme.
Jeden z pokusů zprovoznit Informatica Monitor
Kritická byla také situace s administrační konzolí. Vzhledem k tomu, že aktivní vývoj probíhal přímo v relativně produktivním prostředí, kolegové neustále potřebovali analyzovat práci mapování a workflow „za pochodu“. Služba Data Integration Service v novém Informatice nemá samostatný nástroj pro takové sledování, ale v administrační webové konzoli (Informatica Administrator Monitor) se objevila monitorovací sekce, ve které můžete sledovat chod aplikací, workflow a mapování, spouští, logy. Pravidelně se konzole stávala zcela nedostupnou nebo se přestaly aktualizovat informace o aktuálních procesech v DIS nebo se vyskytly chyby při načítání stránek.
Výběr parametrů java pro stabilizaci provozu
Problém byl v mnoha ohledech opraven, experimentovalo se se změnou parametrů, sbíraly se protokoly a jstack, posílaly se na podporu, zároveň probíhalo aktivní googlování a pouhé pozorování.
Především byla vytvořena samostatná MRS pro monitorování, která je, jak se později ukázalo, jedním z hlavních konzumentů zdrojů v našem prostředí, protože mapování jsou spouštěna velmi intenzivně. Parametry týkající se java haldy a řady dalších byly změněny.
Díky tomu se do další aktualizace Informatica 10.1.1 stabilizoval provoz konzole a monitoru, vývojáři začali pracovat efektivněji a pravidelné procesy byly stále pravidelnější.
Zajímavá může být zkušenost s interakcí mezi vývojem a správou. Otázka obecného porozumění tomu, jak věci fungují, co lze a co nelze, je při používání složitých systémů vždy důležitá. Můžeme tedy s klidem doporučit, abyste nejprve proškolili administrativní tým, jak spravovat software, a vývojový tým, jak psát kód a kreslit procesy v systému, a teprve poté poslat prvního a druhého do práce na výsledku. To je opravdu důležité, když čas není nekonečný zdroj. Mnoho problémů lze vyřešit i náhodným hledáním možností, někdy však některé vyžadují apriorní znalosti – náš případ potvrzuje důležitost pochopení tohoto axiomu.
Když jsme se například pokoušeli povolit verzování v MRS (jak se nakonec ukázalo, byla potřeba jiná verze SVN), po nějaké době nás vyděsilo zjištění, že doba restartu systému se prodloužila na několik desítek minut. Když jsme našli důvod zpoždění při startu a deaktivovali verzování, udělali jsme opět dobře.
Mezi významné překážky spojené s Informatica patří epická bitva s rostoucími java vlákny. V určitém okamžiku nadešel čas replikace, tedy rozšíření zavedených procesů na velké množství zdrojových systémů. Ukázalo se, že ne všechny procesy v 10.1.1 fungovaly dobře a po nějaké době se stal DIS nefunkční. Byly detekovány desítky tisíc vláken, jejichž počet znatelně vzrostl zejména během procesu nasazování aplikace. Někdy jsem musel restartovat několikrát denně, abych obnovil funkčnost.
Zde je třeba poděkovat podpoře, problémy byly lokalizovány a opraveny poměrně rychle pomocí EBF (Emergency Bug Fix) - poté měli všichni pocit, že nástroj opravdu funguje.
Pořád to funguje!
V době, kdy jsme začali pracovat v cílovém režimu, vypadal Informatica takto. Verze Informatica 10.1.1HF1 (HF1 je HotFix1, sestava dodavatele z komplexu EBF) s dodatečně nainstalovaným EBF, který opravuje naše problémy se škálováním a některé další, na jednom serveru ze tří, které byly součástí GRID, 20 jader x86_64 a úložiště na obrovském pomalém poli místních disků – toto je konfigurace serveru pro cluster Hadoop. Na dalším podobném serveru - Oracle DBMS, se kterým pracuje jak doména Informatica, tak i kontrolní mechanismus ETL. To vše hlídají standardní monitorovací nástroje používané v týmu (Zabbix + Grafana) na obou stranách - samotná Informatica se svými službami a do ní nastupující procesy načítání. Nyní jak výkon, tak stabilita, bez zohlednění vnějších faktorů, nyní závisí na nastavení, které omezuje zátěž.
Samostatně můžeme říci o GRID. Prostředí bylo postaveno na třech uzlech, s možností load balancingu. Během testování však bylo zjištěno, že kvůli problémům s interakcí mezi spuštěnými instancemi našich aplikací tato konfigurace nefungovala podle očekávání a rozhodli se dočasně opustit toto konstrukční schéma a odstranit dva ze tří uzlů z domény. Současně samotné schéma zůstalo stejné a nyní je to přesně služba GRID, ale degenerovaná na jeden uzel.
Právě nyní přetrvává potíž spojená s poklesem výkonu při pravidelném čištění obvodu monitoru - při souběžných procesech v CNN a probíhajícím čištění může docházet k poruchám činnosti ovládacího mechanismu ETL. V současné době se to řeší „jako berlička“ – ručním vymazáním obvodu monitoru se ztrátou všech jeho předchozích dat. To není pro produktivitu při běžném rutinním provozu příliš kritické, ale zatím se hledá normální řešení.
Ze stejné situace vyplývá další problém - někdy dochází k vícenásobnému spuštění našeho kontrolního mechanismu.
Vícenásobné spuštění aplikací vedoucí k selhání mechanismu
Při běhu podle plánu v době velkého zatížení systému někdy dochází k situacím, které vedou k poruše mechanismu. Problém se stále řeší ručně a hledá se trvalé řešení.
Obecně lze shrnout, že při velké zátěži je velmi důležité zajistit jí adekvátní zdroje, to platí i pro hardwarové prostředky pro Informaticu samotnou a totéž pro její databázové úložiště, stejně jako pro zajištění optimálního nastavení pro ně. Kromě toho zůstává otevřená otázka, které schéma umístění databáze je lepší - na samostatném hostiteli nebo na stejném hostiteli, kde běží software Informatica. Jednak to na jednom serveru vyjde levněji a při kombinaci prakticky odpadá možný problém se síťovou interakcí, jednak se zátěž hostitele z databáze doplňuje o zátěž od Informatica.
Jako každý seriózní produkt má Informatica i vtipné momenty.
Jednou, když jsem řešil nějakou nehodu, jsem si všiml, že deníky MRS podivně ukazovaly čas událostí.
Časový dualismus v protokolech MRS „by design“
Ukázalo se, že časová razítka se píší ve 12hodinovém formátu, bez určení AM/PM, tedy před polednem nebo po něm. V této věci byla dokonce otevřena přihláška a přišla oficiální odpověď - tak to bylo myšleno, značky jsou v MRS logu zapsány přesně v tomto formátu. To znamená, že někdy zůstává nějaká intrika ohledně doby výskytu nějaké CHYBY...
Usilujte o to nejlepší
Dnes je Informatica poměrně stabilním nástrojem, pohodlným pro administrátory i uživatele, extrémně výkonným z hlediska svých současných možností a potenciálu. Mnohonásobně převyšuje naše funkční potřeby a de facto se nyní v projektu používá způsobem, který není nejtypičtější a nejtypičtější. Potíže částečně souvisejí se způsobem fungování mechanismů – specifikem je, že během krátké doby se spouští velké množství vláken, která intenzivně aktualizují parametry a pracují s databází úložiště, přičemž jsou hardwarové prostředky serveru téměř plně využity ze strany CPU.
Nyní jsme blízko přechodu na Informatica 10.2.1 nebo 10.2.2, které přepracovaly některé vnitřní mechanismy a slibují podporu, aby odstranily některé problémy s výkonem a funkčností, které v současnosti máme. A z hardwarového hlediska očekáváme servery s pro nás optimální konfigurací s přihlédnutím k rezervě na blízkou budoucnost vzhledem k růstu a rozvoji úložiště.
Samozřejmostí bude testování, kontrola kompatibility a případně architektonické změny v části HA GRID. Vývoj v rámci Informatica bude pokračovat, protože v krátkodobém horizontu nemůžeme dodat nic, co by systém nahradilo.
A ti, kteří budou za tento systém v budoucnu zodpovědní, jej určitě dokážou dovést k požadovaným ukazatelům spolehlivosti a výkonu, které předkládají zákazníci.
Článek připravil tým správy dat Rostelecom
Aktuální logo Informatica
Zdroj: www.habr.com