Igapäevastest tõrgetest stabiilsuseni: Informatica 10 administraatori silmade läbi

Andmete lao ETL-komponent jääb sageli pealäbi lao enda varju ning sellele pööratakse vähem tähelepanu kui peamisele andmebaasile või esiosakomponendile, BI-le ja aruannete koostamisele. Sellest hoolimata mängib ETL andmelao täitmise mehhanika seisukohalt üliolulist rolli ja vajab administraatorite tähelepanu sama palju kui ülejäänud komponendid. Minu nimi on Aleksander, hetkel haldan ma ETL-i Rostelecomis, ja selles artiklis püüan natuke jagada, millega tuleb silmitsi seista tuntud ETL-süsteemi administraatoril suurte andmeladude juures Rostelecomis.

Kui austatud lugejad on juba meie andmeladude projektiga ja toote Informatica PowerCenteriga tutvunud, võivad nad otse järgmise osa juurde liikuda.

Mõni aasta tagasi küpses Rostelecomis ja hakkas ellu viima idee ühtsest ettevõtte andmeladust. Rida ladusid, mis lahendasid eraldi ülesandeid, oli juba loodud, kuid skriptide arv kasvas, toetuskulud suurenesid ning sai selgeks, et tulevik kuulub tsentraliseerimisele. Arhitektuuriliselt koosneb see lao mitmest kihist, mille on ellu viidud Hadoopi ja GreenPlumi baasil, ning sisaldab abitegevuse andmebaase, ETL mehhanisme ja BI-d.

Samas, tänu suures koguses territoriaalselt jaotunud, heterogeensetest andmeallikatest, loodi spetsiaalne andmete väljavõtme mehhanism, mille tööd juhib Informatica. Tulemuseks on see, et andmepakid jõuavad Hadoopi vaheala, mille järel algavad andmete laadimise protsessid jaotuste kihtide vahel, Hadoopis ja GreenPlumis, ja nendega juhib nii nimetatud ETL juhtimismehhanism, mis on ellu viidud Informatica kaudu. Seega on süsteem Informatica üks peamisi komponente, mis tagab lao toimimise.

Meie ladude kohta räägitakse üksikasjalikumalt ühes järgmistest postitustest.

Informatica PowerCenter / Big Data Management peetakse tänapäeval andmete integreerimise tööriistade seas juhtivaks tarkvaraks. See on Ameerika ettevõtte Informatica toode, mis on üks tugevamaid mängijaid ETL (Extract Transform Load), andmete kvaliteedi haldamise, MDM (Master Data Management), ILM (Information Lifecycle Management) ja muude valdkondade osas.

Meie kasutatav PowerCenter on integreeritud Tomcat rakendusserver, kus töötavad Informatica rakendused, mis pakuvad tema teenuseid:

Domeen, see on põhimõtteliselt alus kõikidele muudele teenustele, mille raames töötavad domeenis teenused, kasutajad, GRID komponendid.

Administrator Console, veebipõhine haldus- ja jälgimistööriist, lisaks Informatica Developer'i kliendile põhivahend toote kasutamiseks

MRS, Mudeli Repositooriumi Teenus, metaandmete salvestamine, toimib kihina füüsiliselt salvestatud metaandmete ja Informatica Developer'i kliendi vahel, kus arendamine toimub. Repositorid salvestavad nii andmete kirjeldusi kui ka muud teavet, sealhulgas mitmete teiste Informatica teenuste jaoks, näiteks tööde käivitamise ajakavad (Schedules) või jälgimisandmed, samuti rakenduste parameterset'id, mis võimaldavad kasutada ühte ja sama rakendust erinevate andmeallikate ja -sihtkohtadega töötamiseks.

DIS, Andmeintegreerimise Teenus, teenus, kus toimuvad peamised funktsionaalsed protsessid, kus töötavad rakendused ja toimub Workflows'i (mappingute ja nende koostöö järjestuse kirjeldused) ja Mappings'i (transformatsioonide, plokkide, kus toimuvad andmete tõstmised) käivitamine.

GRID konfiguratsioon – põhimõtteliselt on see mitme serveri kasutamise variant kompleksi ehitamisel, kus DIS'i koormus jaotatakse nodide (st domeeni kuuluvate serverite) vahel. Sel juhul, välja arvatud koormuse jaotamine DIS'is täiendava GRID abstraktsioonikihi kaudu, mis ühendab mitut noodi ja kus DIS töötab, selle asemel et töötada konkreetse noodi peal, võivad samuti luua täiendavad varukoopia MRS'exemplaarid. Saame isegi rakendada kõrge kättesaadavuse, kui välised päringud saavad toimuda varunoodide kaudu, kui peamine tõrkub. Sellisest lahendusse minekust oleme hetkel loobunud.

Informatica PowerCenter, skeemiliselt

Andmevõrgu tarneahela alguses esines regulaarseid probleeme, osa neist seoses Informatica tol hetkel ebastabiilse tööga. Jagame mõned meeldivad hetked sellest saagast – Informatica 10 omandamisest.

Endine Informatica logo

Meie valdkonna vastutusse kuuluvad ka teised Informatica keskkonnad, kus on oma spetsiifika erineva koormuse tõttu, aga ma tahan tänases arutelus meenutada eelkõige, kuidas Informatica on arenenud ETL-komponendina andmete ladustamise süsteemis.

Kuidas see juhtus

Aastal 2016, kui me hakkasime vastutama Informatica töö eest, oli see juba jõudnud versioonini 10.0. Optimistlikult meelestatud kolleegide seas, kes otsustasid kasutada toote väiksema versiooni .0, tundus kõik olevat ilmne — uus versioon peab olema kasutusele võetud! Riistvara ressursid olid tol hetkel väga head.

Kevadest 2016 oli Informatica töö eest vastutav alltöövõtja, ja natuke arvukate süsteemi kasutajate sõnul „töötas see paar korda nädalas“. Siinkohal on oluline märkida, et ladustamine oli de facto PoC etapis, meeskonnas ei olnud administraatoreid ja süsteem langes pidevalt eri põhjustel, pärast mida alltöövõtja insener taaskäivitas selle.

Sügiseks liitus meeskonnas kolm administraatorit, kes jagasid omavahel vastutusalasid ning normaalne süsteemide kasutamise töö hakati üles ehitama projektis, sealhulgas Informatica osas. Eraldi tasub mainida, et see toode ei ole laialdaselt levinud ning suurte kogukondadega, kus võiks leida vastuseid igasugustele küsimustele ja lahendada erinevaid probleeme. Seetõttu osutus Vene partneri Informatica poolt antud täiendav tehniline tugi äärmiselt oluliseks, mis aitas lahendada kõik meie vead ning ka noore Informatica 10 vigu.

Esimene asi, mida pidime tegema meie arendajatele ja alltöövõtjale, oli stabiliseerida Informatica töö ning tagada web-administratsiooni konsooli (Informatica Administrator) toimimine.

Nii kohtasime sageli arendajaid, kes töötasid Informatical.

Jätmata kõrvale protsess, millega selgitati välja põhjused, oli peamine põhjus informaatika tarkvara ja andmebaasi vahelise suhtluse skeem, mis asus võrgu maastiku seisukohalt suhteliselt kaugel serveris. See põhjustas viivitusi ja rikkus Informatica domeeni seisundi kontrollimise mehhanisme. Pärast andmebaasi teatud häälestamist, Informatica parameetrite muutmist, et muuta see andmebaasi viivituste suhtes tolerantsemaks, ning lõpuks Informatica versiooni värskendamist kuni 10.1 ja andmebaasi üleviimist eelmise serveri lähedal asuvasse serverisse, kaotas probleem oma olulisuse ning me ei ole sellest ajast saadik selliseid langusi täheldanud.

Üks katse saavutada Informatica Monitori töö

Adminsitratsioonikonsoliga oli olukord samuti kriitiline. Kuna aktiivne arendus toimus tingimuslikult tootmiskeskkonnas, oli kolleegidel pidevalt vajalik analüüsida mappings'e ja workflow'd „liikumise” ajal. Uues Informatica Data Integration Service'is ei ole selliseks jälgimiseks eraldi tööriista, kuid veebihalduskonsoolis on ilmunud jälgimise sektsioon (Informatica Administrator Monitor), kus saab jälgida rakenduste, workflow'de ja mappings'e tööd, korduste, logide seeriat. Aeg-ajalt muutus konsool täielikult kättesaamatuks, kas ei uuendatud DISi jooksvaid protsesside andmeid või ilmnesid vead lehtede laadimisel.

Java parameetrite valimine töö stabiliseerimiseks

Probleemi lahendamine käis mitmeti, tehti katsetusi parameetrite muutmiseks, koguti logisid, jstack'i, saadeti tugiisikutele, samal ajal toimus aktiivne Google'i otsimine ja lihtsalt jälgimine.

Esiteks loodi eraldi MRS jälgimiseks, nagu hiljem selgus, on see üks meie keskkondade peamisi ressursitarbijaid, kuna mappings'e jooksud toimuvad väga intensiivselt. Muudeti java heap'i parameetreid ja hulgaliselt teisi.
Tulemuseks suudeti järgmise Informatica 10.1.1 värskenduse käigus konsooli ja monitori töö stabiliseerida, arendajad hakkasid tõhusamalt töötama ning regulaarprotsessid muutusid üha regulaarsemaks.

Huvitav on arenduse ja haldamise vaheline koostöö. Üks peamisi aspekte on üldine arusaamine, kuidas kõik töötab, mida võib teha ja mida mitte, mis on keeruliste süsteemide kasutamisel alati oluline. Seetõttu on soovitatav kõigepealt koolitada haldajate meeskond selle kohta, kuidas tarkvara hallata, ning arendajate meeskond selle kohta, kuidas kirjutada koodi ja kujundada protsesse süsteemis, ning alles seejärel lasta neil ühiselt tulemusi saavutada. See on tõeliselt oluline, kui aega ei ole lõpmatult. Paljusid probleeme saab lahendada juhuslikult katsetades, kuid mõnel juhul on vajalikud eelnevad teadmised — meie juhtum kinnitab selle aksioomi mõistmise tähtsust.

Näiteks püüdes aktiveerida versiooni haldust MRS-is (mida lõpuks selgus, et oli vajalik teine SVN versioon), märkisime murelikult mõne aja pärast, et süsteemi taaskäivitamise aeg on tõusnud mitme kümne minutini. Põhjuse leidmisel viivituse alguses ning versiooni halduse keelamisel töötas kõik taas hästi.

Mõned märkimisväärsed takistused, mis on seotud Informatica'ga, hõlmavad epohhalist võitlust suurenevate Java voogudega. Ühel hetkel tuli aeg replikatsiooniks, et edastada väljakujunenud protsessid suure hulga allika süsteemide vahel. Selgus, et kaugelki kõik protsessid versioonis 10.1.1 ei töötanud hästi, ja mõne aja pärast muutus DIS kasutuskõlbmatuks. Leiti kümneid tuhandeid vooge, nende arv kasvas eriti märgatavalt rakenduste juurutamise protseduuri käigus. Mõnikord tuli töövõime taastamiseks mitu korda päevas taaskäivitada.

Siinkohal tuleb tänada tugiteenust, probleemid lokaliseeriti ja parandati suhteliselt kiiresti EBF (Emergency Bug Fix) abil – pärast seda oli kõigil tunne, et tööriist töötab tõeliselt.

See töötab ikkagi!

Siiski, kui Informatica sihitud režiimis tööle hakati, nägi see välja järgmiselt. Informatica versioon 10.1.1HF1 (HF1 tähendab HotFix1, tootja pakkumine EBF kogumikust) koos lisatud EBF-dega, mis parandasid meie mastaapsuse probleeme ja veel mõned, ühel kolmest GRID-i serverist, 20 x86_64 tuuma ja suur, aeglane kohalik ketaste massiiv — see serveri konfiguratsioon Hadoop klusteri jaoks. Teisel samasugusel serveril on Oracle DB, millega töötab nii Informatica domeen kui ka ETL juhtimismehhanism. Kõike seda jälgitakse meeskonnas kasutatavate standardsete jälgimistööriistade (Zabbix + Grafana) abil, nii Informatica teenuste kui ka selle kaudu toimuvate laadimisprotsesside osas. Praegu sõltub tootlikkus ja töö stabiilsus välistest teguritest, sõltuvalt seadistustest, mis piiravad koormust.

Erinevalt võib rääkida GRID-ist. Keskkond ehitati kolme nodiga, koormuse tasakaalustamise võimalusega. Kuid testimise käigus avastati, et meie rakenduste käivitatavate eksemplaride vahelise suhtluse probleemide tõttu ei töötanud see konfiguratsioon oodatud viisil ning otsustati ajutiselt loobuda sellest skeemist, välja arvatud kaks kolmest nodist domeenist. Samas jäi skeem muutumatuks ja praegu on see tõepoolest GRID-teenus, kuid ühe nodiga.

Praegu on endiselt probleem, mis on seotud tootlikkuse langusega monitori skeemi regulaarse puhastamise ajal — samaaegsete protsesside käimapaneku ja monitori puhastamise ajal võivad tekkida ETL juhtimismehhanismi töö häired. See lahendatakse praegu „taburetiga“ — manualne monitori skeemi puhastus, kaotades kõik varasemad andmed. See ei ole tootmises eriti kriitiline, normaalses töös, kuid otsitakse senini korralikku lahendust.

Sellest samast olukorrast tuleneb veel üks probleem — mõnikord toimub meie juhtimismehhanismi korduv käivitamine.

Rakenduse korduvad käivitamised, mis toovad kaasa mehhanismi rikke.

Kava alusel käivitades võivad süsteemi suure koormuse hetked mõnikord tuua kaasa olukordi, mis viivad mehhanismi rikkumiseni. Probleem on endiselt käsitsi lahendatav ning otsitakse püsivat lahendust.

Kokkuvõttes võib öelda, et suurt koormust arvestades on äärmiselt tähtis tagada piisavad ressursid, mis kehtib nii Informatica riistvararessursside kui ka selle andmebaasi jaoks, samuti tagada nende optimaalne seadistamine. Lisaks jääb lahtiseks küsimus, milline andmebaasi paigutusskeem on parem — kas eraldi hostis või samal, kus töötab Informatica tarkvara. Ühest küljest osutub ühe serveri kasutamine odavamaks ja koos töötades kaob praktiliselt probleem võrgus suhtlemisel, teisest küljest koormus andmebaasist lisandub Informatica koormusele.

Nagu igas tõsises tootes, on ka Informatica puhul naljakaid hetki.
Kord, uurides mõnda avariid, märkasin, et MRS logides on sündmuste ajad kummaliselt märgitud.

Ajatu dualism MRS logides "disaini tõttu"

Selgus, et ajatempleid kirjutatakse 12-tunnises vormingus, ilma AM/PM tähistamata, st kas enne või pärast keskpäeva. Selle kohta oli isegi avatud pilet ja saadi ametlik vastus — just nii oli plaanitud, MRS logides olevad ajatempli kirjeldused on tõepoolest selles formadis. See tekitab mõnikord teatud intriige seoses selle, millal mõni ERROR ilmneb...

Püüelda parema poole

Tänapäeval on Informatica piisavalt stabiilne tööriist, mugav administraatoritele ja kasutajatele, ülimalt võimas oma praeguste võimaluste ja potentsiaali poolest. See ületab meie funktsionaalsed vajadused kordades ja de facto kasutatakse seda projektis vähem iseloomulikus ja tüüpilises viisis. Raskused on osaliselt seotud sellega, kuidas mehhanismid töötavad — spetsiifika seisneb selles, et lühikese aja jooksul käivitatakse suur hulk vooge, mis intensiivselt uuendavad parameetrigruppide seadeid ja töötavad andmebaasiga, samas kui serveri riistvararessursid on protsessorite poolt praktiliselt täielikult ära kasutatud.

Praegu oleme jõudnud lähedale üleminekule Informatica 10.2.1 või 10.2.2 versioonile, kus on ümber töötatud mõned sisemised mehhanismid, ning toetusele lubatakse, et meil ei esine enam mitmeid praeguseid jõudlus- ja tööprobleeme. Samuti oodatakse riistvara osas ideaalseid servereid meie konfiguratsioonile, arvestades varu lähitulevikus laohalduse kasvu ja arendamise tõttu.

Loomulikult tuleb teha testimine, ühilduvuse kontroll ja võimalikud arhitektuurilised muudatused HA GRID osas. Informatica areng jätkub, kuna lühiajaliselt ei saa me süsteemi asendamiseks midagi paigaldada.
Ja need, kes hiljem vastutavad selle süsteemi eest, suudavad kindlasti viia selle nõutud usaldusväärsuse ja jõudluse tasemele, mille kliendid nõuavad.

Artikli on koostanud Andmete Halduse Meeskond „Rostelecom“

Kehtiv Informatica logo

Allikas: habr.com