Komponenta ETL datového skladu se často ocitá ve stínu samotného skladu a je jí věnována méně pozornosti než hlavní databázi nebo frontovým komponentům, BI a reporting. Přitom z pohledu mechaniky plnění skladu daty hraje ETL klíčovou roli a vyžaduje od administrátorů stejnou pozornost jako ostatní komponenty. Jmenuji se Alexander, momentálně spravuji ETL v Rostelecom a v tomto článku se pokusím sdílet některé z výzev, kterým musí čelit administrátor jednoho z nejznámějších ETL systémů ve velkém datovém skladu společnosti Rostelecom.
Pokud jsou milí čtenáři již obeznámeni s naším projektem datového skladu a s produktem Informatica PowerCenter, mohou přejít rovnou k dalšímu oddílu.
Před několika lety se v Rostelecomu zrodila a začala se realizovat myšlenka jednotného firemního datového skladu. Řada skladů, které řešily jednotlivé úkoly, už byla vytvořena, ale počet scénářů rostl, náklady na údržbu také stoupaly a bylo jasné, že budoucnost patří centralizaci. Architektonicky se jedná o samotný sklad, který se skládá z několika vrstev, realizovaných na Hadoopu a GreenPlum, s pomocnými databázemi, ETL mechanismy a BI.
Přitom kvůli velkému množství teritorálně rozptýlených, různorodých zdrojů dat byl vytvořen speciální mechanismus pro export dat, jehož činnost je řízena Informatica. V důsledku toho se balíčky s daty dostávají do rozhraní Hadoopu, po čemž začínají procesy načítání dat přes vrstvy skladu do Hadoopu a GreenPlum, které řídí takzvaný řídící mechanismus ETL, realizovaný v Informatica. Tímto způsobem je systém Informatica jedním z klíčových prvků, které zajišťují fungování skladu.
O našem skladu bude podrobněji řečeno v jednom 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. Je to produkt americké společnosti Informatica, která patří mezi nejsilnější hráče v ETL (Extract Transform Load), správě kvality dat, MDM (Master Data Management), ILM (Information Lifecycle Management) a další.
Námi používaný PowerCenter je integrovaný aplikační server Tomcat, na kterém běží aplikace Informatica, vykonávající její služby:
Doména, a v podstatě je to základ pro všechno ostatní, v rámci domény fungují služby, uživatelé a komponenty GRID.
Administrator Console, webový nástroj pro správu a monitoring, kromě klienta Informatica Developer, je to hlavní nástroj pro interakci s produktem
MRS, Model Repository Service, úložiště metadat, představuje mezivrstvu mezi databází, ve které jsou metadata fyzicky uložena, a klientem Informatica Developer, ve kterém probíhá vývoj. Repozitáře ukládají jak popis dat, tak další informace, včetně pro řadu dalších služeb Informatica, například rozvrhy spuštění úloh (Schedules) nebo monitorovací data, stejně jako parametrové sady aplikací, které umožňují používat stejnou aplikaci pro práci s různými zdroji a příjemci dat.
DIS, Data Integration Service, to je služba, ve které probíhají hlavní funkční procesy, v níž běží aplikace a probíhá vlastní spuštění Workflow (popisy sekvence mappings a jejich interakce) a Mappings (transformace, bloky, ve kterých dochází k samotným převodům a zpracování dat).
Konfigurace GRID – v podstatě varianta vybudování komplexu s využitím několika serverů, kdy je zátěž, spouštěná DIS, rozložena mezi nody (tedy servery, které jsou součástí domény). V případě této varianty, kromě rozložení zátěže DIS přes dodatečnou vrstvu abstrakce GRID, která spojuje několik nodů, na kterých DIS pracuje místo na konkrétní jedné nodě, mohou být také vytvořeny dodatečné záložní instance MRS. Můžete dokonce implementovat vysokou dostupnost, kdy mohou být externí žádosti prováděny prostřednictvím záložních nodů v případě selhání hlavního. Tento typ konstrukce jsme zatím odmítli.
Informatica PowerCenter, schematicky
Na počátku práce v rámci dodavatelského řetězce dat se pravidelně objevovaly problémy, část z nich díky v té době nestabilní práci Informatica. Chci se podělit o některé z nezapomenutelných okamžiků této ságy – osvojení Informatica 10.
Původní logo Informatica
Do odpovědnosti našeho oddělení patří také další prostředí Informatica, kde existuje specifika kvůli jiné zátěži. Prozatím si však vzpomenu především na to, jak se Informatica vyvíjela jako ETL komponenta samotného datového skladu.
Jak k tomu došlo
V roce 2016, kdy jsme začali odpovídat za práci s Informatica, již dosáhla verze 10.0, a pro optimisticky naladěné kolegy, kteří se rozhodovali o nasazení produktu s minoritní verzí .0, se vše zdálo jasné — měla se použít nová verze! Z pohledu hardwarových zdrojů bylo vše v té době skvělé.
Od jara 2016 zajišťoval provoz Informatica dodavatel, a podle slov několika uživatelů systému 'fungovala párkrát týdně'. Je třeba vysvětlit, že datové skladiště bylo de facto v fázi PoC, v týmu nebyli administrátoři a systém neustále padal z různých důvodů, přičemž inženýr dodavatele ho musel opakovaně restartovat.
Na podzim se v týmu objevili tři administrátoři, kteří si rozdělili oblasti odpovědnosti a začala se vytvářet normální práce na zajištění provozu systémů v projektu, včetně Informatica. Je potřeba zmínit, že tento produkt není široce rozšířený a nemá velkou komunitu, kde by bylo možné najít odpovědi na jakékoli otázky či vyřešit jakýkoli problém. Proto byla velmi důležitá plnohodnotná technická podpora od ruského partnera Informatica, díky které jsme opravovali všechny naše chyby a chyby mladé tehdy Informatica 10.
První, co jsme museli udělat pro vývojáře našeho týmu a dodavatele, bylo stabilizovat samotnou Informatica a dosáhnout funkčnosti webové konzole pro správu (Informatica Administrator).
Tak se mnohdy setkávali vývojáři Informatica
Opustil proces zjišťování příčin a hlavní příčinou výpadků byla schéma interakce softwaru Informatica s databází repozitáře, která se nacházela na relativně vzdáleném serveru z hlediska síťového prostředí. To vedlo k zpožděním a narušovalo to fungování mechanismů zajišťujících kontrolu stavu domény Informatica. Po určitém ladění databáze a změnách parametrů Informatica, které ji učinily tolerantnější k zpožděním databáze, a nakonec aktualizaci verze Informatica na 10.1 a přenos databáze z předchozího serveru na server blíže k Informatica, problém přestal být aktuální, a od té doby jsme nezaznamenali podobné výpadky.
Jedním z pokusů o zajištění funkce Informatica Monitor
Situace s administrační konzolí byla také kritická. Jelikož probíhala aktivní vývoj na podmíněně produktivním prostředí, kolegové často museli analyzovat fungování mappings a workflow "za chodu". V nové Informatice, v Data Integration Service není samostatný nástroj pro takové sledování, ale v webové administrativní konzoli se objevila sekce monitorování (Informatica Administrator Monitor), kde lze sledovat fungování aplikací, workflow a mappings, spuštění, logy. Občas se konzole stala zcela nedostupnou, nebo se přestaly aktualizovat informace o aktuálních procesech v DIS, nebo se objevily chyby při načítání stránek.
Nastavení parametrů java pro stabilizaci práce
Řešení problému probíhalo mnoha způsoby, prováděly se experimenty se změnou parametrů, shromažďovaly se logy, jstack, posílaly se do podpory, současně probíhalo aktivní googlení a prostě se to sledovalo.
Na první místě byla vytvořena samostatná MRS pro monitorování, jak se později ukázalo, že to je jeden z hlavních spotřebitelů zdrojů v našich prostředích, protože spuštění mappings se děje velmi intenzivně. Byly změněny parametry týkající se java heap a řada dalších.
V důsledku toho se k dalšímu upgradu Informatica 10.1.1 podařilo stabilizovat práci konzole a monitoru, vývojáři začali pracovat efektivněji a pravidelné procesy se stávaly stále pravidelnějšími.
Zajímavým může být prožitek interakce mezi vývojem a administrací. Otázka společného porozumění, jak všechno funguje, co lze dělat a co nelze, je vždy důležitá při používání složitých systémů. Proto lze směle doporučit nejprve vyškolit tým administrátorů, jak by mělo být software spravováno, a tým vývojářů, jak by měl psát kód a navrhovat procesy v systému, a teprve poté poslat první a druhé pracovat na výsledku. To je skutečně důležité, když čas není neomezeným zdrojem. Mnoho problémů lze vyřešit i náhodným zkoušením variant, ale někdy některé vyžadují apriorní znalosti — náš případ potvrzuje důležitost pochopení této axiomy.
Například při pokusu o zapnutí verzování v MRS (jak se nakonec ukázalo, potřebovali jsme jinou verzi SVN), jsme po nějaké době s obavami objevili, že doba restartu systému se prodloužila na několik desítek minut. Po nalezení příčiny zpoždění při startu a vypnutí verzování jsme to opět postavili do pořádku.
Mezi znatelnými překážkami spojenými s Informatica si můžeme vzpomenout na epickou bitvu s rostoucími java vlákny. V určitém okamžiku nastal čas na replikaci, tedy rozšíření nastavených procesů na velké množství systémů zdrojů. Přitom se ukázalo, že ne všechny procesy v 10.1.1 fungovaly dobře a po nějaké době DIS se stal nefunkčním. Byly nalezeny desítky tisíc vláken, jejich počet zvlášť výrazně rostl při procesu nasazení aplikací. Někdy bylo nutné restartovat několikrát denně pro obnovení funkčnosti.
Tady je třeba poděkovat podpoře, relativně rychle byly problémy lokalizovány a opraveny pomocí EBF (Emergency Bug Fix) – po tom všem všichni měli pocit, že nástroj skutečně funguje.
Ono to přece jen funguje!
K začátku práce v cílovém režimu vypadala Informatica následovně. Verze Informatica 10.1.1HF1 (HF1 to je HotFix1, dodavatelská sestava z komplexu EBF) s dodatečně nainstalovanými EBF, které opravovaly naše problémy se škálováním a některé další na jednom serveru ze tří, které tvořily GRID, 20 jader x86_64 a úložiště, na obrovském pomalém poli lokálních disků — to konfigurace serveru pro Hadoop cluster. On another similar server — Oracle DB, which is used by both the Informatica domain and the ETL management mechanism. All of this is monitored by standard monitoring tools used by the team (Zabbix + Grafana), from two sides — Informatica itself with its services, and the loading processes going into it. Currently, both performance and stability, excluding external factors, depend on settings that limit the load.
Separately, we can talk about GRID. The environment was built on three nodes with the possibility of load balancing. However, during testing, it was discovered that due to interaction problems between the instances of our applications, such a configuration did not work as expected, and we temporarily decided to abandon this construction scheme by removing two out of three nodes from the domain. The scheme itself remained the same, and now it is indeed a GRID service, but degenerated to a single node.
Right now, there is a complexity related to performance drops during the regular clearing of the monitoring scheme — during simultaneously running processes in the CHNN and the running cleanup, failures in the ETL management mechanism may occur. This is currently resolved in a "quick fix" manner — by manually clearing the monitoring scheme, losing all its previous data. This is not too critical for production during normal operational activity, but we are still searching for a proper solution.
From this situation arises another problem — sometimes multiple launches of our management mechanism occur.
Multiple launches of the application lead to the breakdown of the mechanism.
When launched on a schedule during peak load times, such situations may occur that lead to the mechanism breaking. The problem continues to be resolved manually, and we are searching for a permanent solution.
Celkově lze shrnout, že při vysoké zátěži je velmi důležité poskytnout adekvátní zdroje, což se týká jak hardwarových zdrojů pro samotnou Informatica, tak i pro její databázový repozitář, a také zajistit pro ně optimální nastavení. 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 tom samém, kde běží software Informatica. Na jedné straně na jednom serveru to vyjde levněji a při kombinaci se téměř eliminuje možný problém se síťovou interakcí, na druhé straně — zátěž na hostitele z databáze se doplňuje zátěží od Informatica.
Jako v každém vážném produktu, v Informatica se také objevují kuriózní momenty.
Jednou, když jsem analyzoval nějakou havarii, jsem si všiml, že v logách MRS je podivně zaznamenán čas událostí.
Časový dualismus v logách MRS "by design"
Ukázalo se, že časové značky jsou zapisovány ve formátu 12 hodin, bez označení AM/PM, tedy před polednem nebo po něm. Dokonce byla podána žádost ohledně tohoto a bylo získáno oficiální odpověď — takto to bylo navrženo, v logu MRS jsou značky zapisovány právě v tomto formátu. To znamená, že občas zůstává jistá intrika ohledně času vzniku nějaké chyby ERROR…
Usilovat o lepší
Dnes je Informatica dostatečně stabilní nástroj, který je pohodlný pro administrátora a uživatele, a neobyčejně silný co do současných možností a potenciálu. Funkčně mnohonásobně překračuje naše potřeby a de facto je nyní používán v projektu poněkud netypickým způsobem. Obtíže jsou částečně spojené s tím, jak fungují mechanismy — specifikou je, že za krátké období je spuštěno velké množství vláken, která intenzivně aktualizují parametersety a pracují s databází repozitáře, přičemž hardwarové zdroje serveru jsou téměř plně využity na CPU.
Nyní jsme se dostali blízko k přechodu na Informatica 10.2.1 nebo 10.2.2, ve kterých byly přepracovány některé vnitřní mechanismy, a podpora slibuje absenci řady aktuálně existujících problémů s výkonem a fungováním. A z pohledu hardwaru se očekávají servery optimální konfigurace pro nás, s ohledem na rezervu na nejbližší čas vzhledem k růstu a rozvoji úložiště.
Samozřejmě, bude třeba testování, kontrola kompatibility a možná i architektonické změny v oblasti HA GRID. Rozvoj v rámci Informatica bude pokračovat, protože v krátkodobém horizontu nemůžeme nahradit stávající systém.
A ti, kdo budou později zodpovědní za tento systém, určitě budou schopní dosáhnout požadovaných ukazatelů spolehlivosti a výkonu předložených zákazníky.
Článek připravila data management tým "Rostelecomu"
Aktuální logo Informatica
Zdroj: habr.com
