ETL komponent dátového skladu je často zatienený samotným skladom a dostáva menej pozornosti ako hlavná databáza alebo front-end komponent, BI a reporting. Zároveň z pohľadu mechaniky napĺňania skladu dátami hrá ETL kľúčovú úlohu a vyžaduje si od administrátorov nemenej pozornosti ako ostatné komponenty. Volám sa Alexander, teraz administrujem ETL v Rostelecome a v tomto článku sa pokúsim trochu podeliť o to, s čím sa musí popasovať správca jedného z najznámejších ETL systémov vo veľkom dátovom sklade v Rostelecome.
Ak milí čitatelia už vo všeobecnosti poznajú náš projekt dátového skladu a produkt Informatica PowerCenter, môžete okamžite prejsť na ďalšiu časť.
Pred niekoľkými rokmi dozrela myšlienka jednotného podnikového dátového skladu a začala sa implementovať v Rostelecome. Už bolo vytvorených niekoľko úložísk, ktoré riešili jednotlivé problémy, ale rástol počet scenárov, zvyšovali sa aj náklady na podporu a bolo jasné, že budúcnosť je v centralizácii. Architektonicky ide o samotné úložisko pozostávajúce z niekoľkých vrstiev, implementovaných na Hadoop a GreenPlum, pomocných databáz, ETL mechanizmov a BI.
Zároveň z dôvodu veľkého množstva geograficky distribuovaných, heterogénnych dátových zdrojov vznikol špeciálny mechanizmus nahrávania dát, ktorého fungovanie riadi Informatica. Výsledkom je, že dátové balíky končia v oblasti rozhrania Hadoop, po ktorých nastupujú procesy načítania dát cez úložné vrstvy, Hadoop a GreenPlum a sú riadené takzvaným kontrolným mechanizmom ETL implementovaným v Informatica. Systém Informatica je teda jedným z kľúčových prvkov, ktorý zabezpečuje chod skladu.
Naše úložisko bude podrobnejšie popísané v jednom z nasledujúcich príspevkov.
Informatica PowerCenter/Big Data Management je v súčasnosti považovaný za popredný softvér v oblasti nástrojov na integráciu dát. Ide o produkt americkej spoločnosti Informatica, ktorá je jedným z najsilnejších hráčov v ETL (Extract Transform Load), manažmente kvality dát, MDM (Master Data Management), ILM (Information Lifecycle Management) a ďalších.
PowerCenter, ktoré používame, je integrovaný aplikačný server Tomcat, v ktorom bežia samotné aplikácie Informatica, ktoré implementujú jej služby:
Doména, v skutočnosti je to základ pre všetko ostatné; služby, používatelia a komponenty GRID fungujú v rámci domény.
Administrátorská konzola, webový nástroj na správu a monitorovanie, okrem klienta Informatica Developer, hlavného nástroja na interakciu s produktom
MRS, služba úložiska modelov, úložisko metadát, je vrstva medzi databázou, v ktorej sú fyzicky uložené metadáta, a klientom Informatica Developer, v ktorom prebieha vývoj. Repozitáre uchovávajú popisy údajov a ďalšie informácie, a to aj pre množstvo ďalších služieb Infromatica, napríklad plány spustených úloh (Schedules) alebo monitorovacie údaje, ako aj parametre aplikácie, najmä umožňujúce použitie rovnakej aplikácie na prácu s rôzne zdroje údajov a prijímače.
DIS, služba integrácie údajov, ide o službu, v ktorej prebiehajú hlavné funkčné procesy, bežia v nej aplikácie a samotné spúšťania Workflows (popis postupnosti mapovaní a ich interakcií) a Mappings (premeny, bloky, v ktorých dochádza k samotným transformáciám, spracovanie dát ) konať.
konfigurácia GRID – v podstate možnosť vybudovania komplexu pomocou niekoľkých serverov, keď záťaž spúšťaná DIS je rozdelená medzi uzly (t. j. servery, ktoré sú súčasťou domény). V prípade tejto možnosti je možné okrem rozloženia záťaže v DIS prostredníctvom dodatočnej abstrakcie GRID vrstvy, ktorá združuje niekoľko uzlov, na ktorých beží DIS namiesto práce na konkrétnom jedinom uzle, vytvárať aj ďalšie záložné inštancie MRS. Môžete dokonca implementovať vysokú dostupnosť, kde je možné uskutočniť externé hovory cez záložné uzly, ak hlavný zlyhá. Od tejto možnosti výstavby sme nateraz upustili.
Informatica PowerCenter, schéma
V počiatočných fázach práce v rámci dátového dodávateľského reťazca sa pravidelne objavovali problémy, niektoré z nich kvôli nestabilnej prevádzke Informatica v tom čase. Podelím sa o niektoré z nezabudnuteľných momentov tejto ságy - zvládnutie Informatica 10.
Bývalé logo Informatica
Naša oblasť zodpovednosti zahŕňa aj ďalšie prostredia Informatica, tie majú svoje špecifiká z dôvodu inej záťaže, no zatiaľ si presne spomeniem, ako sa Informatica vyvíjala ako ETL komponent samotného dátového skladu.
Ako sa to stalo
V roku 2016, keď sme sa stali zodpovednými za prácu Informatica, už dosiahla verziu 10.0 a optimistickým kolegom, ktorí sa rozhodovali použiť produkt s menšou verziou .0 vo serióznom riešení, sa všetko zdalo samozrejmé – musíme použiť nová verzia! Z pohľadu hardvérových prostriedkov bolo vtedy všetko v poriadku.
Od jari 2016 je za prácu Informatica zodpovedný dodávateľ a podľa niekoľkých používateľov systému to „fungovalo párkrát do týždňa“. Tu je potrebné objasniť, že úložisko bolo de facto v štádiu PoC, v tíme neboli žiadni správcovia a systém neustále z rôznych príčin padal, po čom ho inžinier dodávateľa opäť zdvihol.
Na jeseň sa k tímu pridali traja administrátori, ktorí si medzi sebou rozdelili oblasti zodpovednosti a začala sa bežná práca na organizácii chodu systémov v projekte vrátane Informatica. Samostatne je potrebné povedať, že tento produkt nie je rozšírený a má veľkú komunitu, v ktorej môžete nájsť odpovede na akékoľvek otázky a vyriešiť akýkoľvek problém. Preto bola veľmi dôležitá plná technická podpora od ruského partnera Informatica, pomocou ktorej boli opravené všetky naše chyby a omyly vtedy mladej Informaticy 10.
Prvá vec, ktorú sme museli pre vývojárov nášho tímu a dodávateľa urobiť, bolo stabilizovať prácu samotnej Informaticy, zabezpečiť funkčnosť webovej administračnej konzoly (Informatica Administrator).
Takto sme sa často stretávali s vývojármi Informatica
Odhliadnuc od procesu zisťovania príčin, hlavnou príčinou pádov bol spôsob interakcie softvéru Informatica s databázou úložiska, ktorá bola z pohľadu sieťového prostredia umiestnená na relatívne vzdialenom serveri. To spôsobilo oneskorenia a narušili mechanizmy monitorujúce stav domény Informatica. Po určitom ladení databázy, zmene parametrov Informatica, vďaka ktorej bola tolerantnejšia voči oneskoreniam databázy a prípadnej aktualizácii verzie Informatica na 10.1 a prenose databázy z predchádzajúceho servera na server umiestnený bližšie k Informatice, sa problém stratil. a odvtedy sa vyskytli pády tohto druhu, ktoré nepozorujeme.
Jeden z pokusov sfunkčniť Informatica Monitor
Kritická bola aj situácia s administračnou konzolou. Keďže aktívny vývoj prebiehal priamo v relatívne produktívnom prostredí, kolegovia neustále potrebovali analyzovať prácu mapovania a workflow „za pochodu“. Služba Data Integration Service v novom Informatice nemá samostatný nástroj na takéto monitorovanie, ale v administračnej webovej konzole (Informatica Administrator Monitor) sa objavila sekcia monitoringu, v ktorej môžete sledovať chod aplikácií, workflow a mapovania, štarty, protokoly. Pravidelne sa stávala konzola úplne nedostupná alebo sa prestali aktualizovať informácie o aktuálnych procesoch v DIS alebo sa vyskytli chyby pri načítavaní stránok.
Výber parametrov java na stabilizáciu výkonu
Problém bol opravený mnohými spôsobmi, robili sa experimenty na zmenu parametrov, zbierali sa protokoly a jstack, posielali sa na podporu, zároveň prebiehalo aktívne googlovanie a jednoduché pozorovanie.
V prvom rade bola vytvorená samostatná MRS na monitorovanie, ako sa neskôr ukázalo, ide o jedného z hlavných spotrebiteľov zdrojov v našich prostrediach, keďže mapovania sa spúšťajú veľmi intenzívne. Parametre týkajúce sa haldy java a mnohých ďalších boli zmenené.
V dôsledku toho sa ďalšou aktualizáciou Informatica 10.1.1 stabilizovala prevádzka konzoly a monitora, vývojári začali pracovať efektívnejšie a pravidelné procesy boli čoraz pravidelnejšie.
Zaujímavá môže byť skúsenosť interakcie medzi vývojom a správou. Otázka všeobecného chápania toho, ako veci fungujú, čo sa dá a čo nie, je pri používaní zložitých systémov vždy dôležitá. Preto môžeme pokojne odporučiť, aby ste najskôr zaškolili administratívny tím, ako spravovať softvér, a vývojársky tím, ako písať kód a kresliť procesy v systéme, a až potom poslať prvého a druhého pracovať na výsledku. To je naozaj dôležité, keď čas nie je nekonečný zdroj. Mnohé problémy sa dajú vyriešiť aj náhodným hľadaním možností, no niekedy si niektoré vyžadujú apriórne znalosti – náš prípad potvrdzuje dôležitosť pochopenia tejto axiómy.
Keď sme sa napríklad pokúšali povoliť verzovanie v MRS (ako sa nakoniec ukázalo, bola potrebná iná verzia SVN), po určitom čase nás vystrašilo zistenie, že čas reštartu systému sa predĺžil na niekoľko desiatok minút. Po zistení dôvodu oneskorenia spustenia a deaktivácie verzií sme opäť urobili dobre.
Pozoruhodné prekážky spojené s Informatica zahŕňajú epický boj s rastúcimi java vláknami. V istom momente nastal čas replikácie, teda rozšírenia zabehnutých procesov na veľké množstvo zdrojových systémov. Ukázalo sa, že nie všetky procesy v 10.1.1 fungovali dobre a po určitom čase sa DIS stalo nefunkčným. Boli odhalené desiatky tisíc vlákien, ktorých počet sa výrazne zvýšil najmä počas procesu nasadzovania aplikácie. Niekedy som musel reštartovať niekoľkokrát za deň, aby sa obnovila funkčnosť.
Tu treba poďakovať podpore, problémy boli lokalizované a opravené pomerne rýchlo pomocou EBF (Emergency Bug Fix) - potom už každý nadobudol pocit, že nástroj naozaj funguje.
Stále to funguje!
V čase, keď sme začali pracovať v cieľovom režime, Informatica vyzerala takto. Verzia Informatica 10.1.1HF1 (HF1 je HotFix1, zostava dodávateľa z komplexu EBF) s dodatočne nainštalovaným EBF, ktorý opravuje naše problémy so škálovaním a niektoré ďalšie, na jednom serveri z troch, ktoré boli súčasťou GRID, 20 jadier x86_64 a úložisko na obrovskom pomalom poli lokálnych diskov – toto je konfigurácia servera pre klaster Hadoop. Na inom podobnom serveri - Oracle DBMS, s ktorým funguje doména Informatica aj riadiaci mechanizmus ETL. Toto všetko monitorujú štandardné monitorovacie nástroje používané v tíme (Zabbix + Grafana) na oboch stranách – samotná Informatica so svojimi službami a do nej idúce procesy načítania. Teraz výkon aj stabilita, bez zohľadnenia vonkajších faktorov, teraz závisia od nastavení, ktoré obmedzujú zaťaženie.
Samostatne môžeme povedať o GRID. Prostredie bolo postavené na troch uzloch, s možnosťou load balancingu. Počas testovania sa však zistilo, že kvôli problémom s interakciou medzi spustenými inštanciami našich aplikácií táto konfigurácia nefungovala podľa očakávania a rozhodli sa dočasne opustiť túto konštrukčnú schému a odstrániť dva z troch uzlov z domény. Zároveň samotná schéma zostala rovnaká a teraz je to presne služba GRID, ale degenerovaná do jedného uzla.
Práve teraz zostáva problém spojený s poklesom výkonu pri pravidelnom čistení okruhu monitora - pri súčasných procesoch v CNN a prebiehajúcom čistení môže dôjsť k poruchám v činnosti ovládacieho mechanizmu ETL. V súčasnosti sa to rieši „ako barlička“ – ručným vymazaním obvodu monitora so stratou všetkých jeho predchádzajúcich údajov. Pri bežnej rutinnej prevádzke to nie je príliš dôležité pre produktivitu, ale zatiaľ sa hľadá normálne riešenie.
Z rovnakej situácie vyplýva aj ďalší problém – niekedy dochádza k viacnásobnému spusteniu nášho kontrolného mechanizmu.
Viacnásobné spustenie aplikácií vedie k zlyhaniu mechanizmu
Pri behu podľa plánu, v časoch veľkého zaťaženia systému, niekedy nastanú situácie, ktoré vedú k poruche mechanizmu. Problém sa stále rieši ručne a hľadá sa trvalé riešenie.
Vo všeobecnosti môžeme zhrnúť, že pri veľkej záťaži je veľmi dôležité zabezpečiť jej adekvátne zdroje, to platí aj pre hardvérové prostriedky pre Informaticu samotnú a to isté pre jej databázové úložisko, ako aj zabezpečenie optimálneho nastavenia pre nich. Okrem toho zostáva otvorená otázka, ktorá schéma umiestnenia databázy je lepšia - na samostatnom hostiteľovi alebo na tom istom, kde beží softvér Informatica. Na jednej strane to bude lacnejšie na jednom serveri a pri kombinácii prakticky odpadá možný problém so sieťovou interakciou, na druhej strane zaťaženie hostiteľa z databázy je doplnené o záťaž z Informatica.
Ako každý seriózny produkt, aj Informatica má vtipné momenty.
Raz, keď som riešil nejakú nehodu, všimol som si, že denníky MRS čudne ukazovali čas udalostí.
Časový dualizmus v denníkoch MRS „podľa návrhu“
Ukázalo sa, že časové pečiatky sa píšu v 12-hodinovom formáte bez uvedenia AM/PM, teda pred poludním alebo po ňom. V tejto veci bola dokonca otvorená žiadosť a prišla oficiálna odpoveď - tak to bolo myslené, značky sú v denníku MRS zapísané presne v tomto formáte. To znamená, že niekedy zostáva nejaká intriga týkajúca sa času výskytu nejakej CHYBY...
Usilujte sa o to najlepšie
Dnes je Informatica pomerne stabilný nástroj, vhodný pre správcov a používateľov, mimoriadne výkonný z hľadiska svojich súčasných možností a potenciálu. Mnohonásobne presahuje naše funkčné potreby a de facto sa teraz v projekte používa spôsobom, ktorý nie je najtypickejší a najtypickejší. Ťažkosti čiastočne súvisia so spôsobom fungovania mechanizmov – špecifikom je, že v krátkom čase sa spustí veľké množstvo vlákien, ktoré intenzívne aktualizujú parametre a pracujú s databázou úložiska, pričom hardvérové zdroje servera sú takmer úplne vyťažené zo strany CPU.
Teraz sme blízko prechodu na Informatica 10.2.1 alebo 10.2.2, ktoré prepracovali niektoré interné mechanizmy a sľubujú podporu na odstránenie niektorých problémov s výkonom a funkčnosťou, ktoré v súčasnosti máme. A z hardvérového hľadiska očakávame servery s pre nás optimálnou konfiguráciou, berúc do úvahy rezervu na blízku budúcnosť z dôvodu rastu a rozvoja úložiska.
Samozrejmosťou bude testovanie, kontrola kompatibility a možno aj architektonické zmeny v časti HA GRID. Vývoj v rámci Informatica bude pokračovať, keďže v krátkodobom horizonte nevieme dodať nič, čo by systém nahradilo.
A tí, ktorí budú za tento systém v budúcnosti zodpovední, ho určite dokážu doviesť k požadovaným ukazovateľom spoľahlivosti a výkonu, ktoré predkladajú zákazníci.
Článok pripravil tím správy údajov Rostelecom
Aktuálne logo Informatica
Zdroj: hab.com