Od vsakodnevnih nesreč do stabilnosti: Informatica 10 skozi oči skrbnika

Od vsakodnevnih nesreč do stabilnosti: Informatica 10 skozi oči skrbnika

ETL komponenta podatkovnega skladišča je pogosto zasenčena s samim skladiščem in je deležna manj pozornosti kot glavna baza podatkov ali sprednja komponenta, BI in poročanje. Hkrati ima ETL ključno vlogo z vidika mehanike polnjenja skladišča s podatki in od skrbnikov ne zahteva nič manj pozornosti kot druge komponente. Moje ime je Alexander, zdaj upravljam ETL pri Rostelecomu in v tem članku bom poskušal deliti nekaj o tem, s čim se mora ukvarjati skrbnik enega najbolj znanih sistemov ETL v velikem podatkovnem skladišču pri Rostelecomu.

Če ste dragi bralci že na splošno seznanjeni z našim projektom podatkovnega skladišča in produktom Informatica PowerCenter, potem lahko takoj preidete na naslednji razdelek.

Pred nekaj leti je ideja o enotnem korporativnem skladišču podatkov dozorela in se začela izvajati v Rostelecomu. Izdelanih je bilo že nekaj repozitorijev, ki so reševali posamezne probleme, vendar je število scenarijev naraščalo, naraščali so tudi stroški podpore in postalo je jasno, da je prihodnost v centralizaciji. Arhitekturno je to sama shramba, sestavljena iz več plasti, implementirana na Hadoop in GreenPlum, pomožne baze podatkov, ETL mehanizmi in BI.

Hkrati je bil zaradi velikega števila geografsko razpršenih, heterogenih virov podatkov oblikovan poseben mehanizem za nalaganje podatkov, katerega delovanje nadzoruje Informatica. Posledično se podatkovni paketi znajdejo v območju vmesnika Hadoop, nato pa se začnejo procesi nalaganja podatkov skozi pomnilniške plasti, Hadoop in GreenPlum, upravlja pa jih tako imenovan nadzorni mehanizem ETL, implementiran v Informatici. Tako je sistem Informatica eden ključnih elementov, ki zagotavlja delovanje skladišča.

Naše skladišče bo podrobneje opisano v eni od naslednjih objav.

Informatica PowerCenter/Big Data Management trenutno velja za vodilno programsko opremo na področju orodij za integracijo podatkov. Gre za produkt ameriškega podjetja Informatica, ki je eden najmočnejših igralcev na področju ETL (Extract Transform Load), upravljanja kakovosti podatkov, MDM (Master Data Management), ILM (Information Lifecycle Management) idr.

PowerCenter, ki ga uporabljamo, je integriran aplikacijski strežnik Tomcat, v katerem tečejo same aplikacije Informatica, ki izvajajo njene storitve:

Domena, pravzaprav je to osnova za vse ostalo; storitve, uporabniki in komponente GRID delujejo znotraj domene.

Skrbniška konzola, spletno orodje za upravljanje in spremljanje, poleg odjemalca Informatica Developer glavno orodje za interakcijo z izdelkom

MRS, storitev repozitorija modelov, repozitorij metapodatkov, je plast med bazo podatkov, v kateri so metapodatki fizično shranjeni, in odjemalcem Informatica Developer, v katerem poteka razvoj. Repozitoriji shranjujejo opise podatkov in druge informacije, vključno s številnimi drugimi storitvami Infromatica, na primer urnike za izvajanje opravil (razporedi) ali podatke o spremljanju, kot tudi parametre aplikacij, zlasti kar omogoča uporabo iste aplikacije za delo z različnih podatkovnih virov in sprejemnikov.

DIS, storitev integracije podatkov, to je storitev, v kateri potekajo glavni funkcionalni procesi, v njej tečejo aplikacije in dejanski zagoni Workflows (opisi zaporedja preslikav in njihovih interakcij) in Mappings (transformacije, bloki, v katerih se same transformacije dogajajo, obdelava podatkov). ) odvijati se.

GRID konfiguracija – v bistvu možnost izgradnje kompleksa z uporabo več strežnikov, ko je obremenitev, ki jo sproži DIS, porazdeljena med vozlišča (to je strežnike, ki so del domene). V primeru te možnosti je poleg porazdelitve obremenitve v DIS prek dodatnega sloja abstrakcije GRID, ki združuje več vozlišč, na katerem teče DIS namesto dela na posameznem vozlišču, mogoče ustvariti tudi dodatne rezervne instance MRS. Lahko celo implementirate visoko razpoložljivost, kjer je mogoče zunanje klice opraviti prek rezervnih vozlišč, če glavno odpove. To možnost gradnje smo za zdaj opustili.

Od vsakodnevnih nesreč do stabilnosti: Informatica 10 skozi oči skrbnika
Informatica PowerCenter, shema

V zgodnjih fazah dela v okviru podatkovne verige so se redno pojavljale težave, nekatere tudi zaradi takratnega nestabilnega delovanja Informatike. Delil bom nekaj nepozabnih trenutkov te sage – obvladovanje Informatice 10.

Od vsakodnevnih nesreč do stabilnosti: Informatica 10 skozi oči skrbnika
Nekdanji logotip Informatica

V naše področje odgovornosti sodijo tudi druga okolja Informatica, ki imajo svoje specifike zaradi drugačne obremenjenosti, a zaenkrat se bom natančno spomnil, kako se je Informatica razvila kot ETL komponenta samega podatkovnega skladišča.

Kako se je to zgodilo

Leta 2016, ko smo postali odgovorni za delo Informatike, je le-ta že dosegla različico 10.0 in optimističnim kolegom, ki so se odločali za uporabo produkta z manjšo različico .0 v resni rešitvi, se je zdelo vse samoumevno – uporabiti moramo nova verzija! Z vidika strojnih virov je bilo takrat vse v redu.

Od pomladi 2016 je za delo Informatike odgovoren izvajalec, ki je po besedah ​​redkih uporabnikov sistema »deloval nekajkrat na teden«. Tukaj je treba pojasniti, da je bil repozitorij de facto v fazi PoC, v ekipi ni bilo skrbnikov in sistem se je nenehno sesuval zaradi različnih razlogov, nakar ga je izvajalčev inženir ponovno pobral.

Jeseni so se ekipi pridružili trije skrbniki, ki so si razdelili področja odgovornosti in začelo se je normalno delo pri organizaciji delovanja sistemov v projektu, vključno z Informatiko. Ločeno je treba povedati, da ta izdelek ni razširjen in ima veliko skupnost, v kateri lahko najdete odgovore na vsa vprašanja in rešite kakršno koli težavo. Zato je bila zelo pomembna popolna tehnična podpora ruskega partnerja Informatica, s pomočjo katere so bile odpravljene vse naše napake in napake takrat mlade Informatice 10.

Prva stvar, ki smo jo morali narediti za razvijalce naše ekipe in izvajalca, je bila stabilizacija delovanja same Informatike, zagotovitev funkcionalnosti spletne skrbniške konzole (Informatica Administrator).

Od vsakodnevnih nesreč do stabilnosti: Informatica 10 skozi oči skrbnika
Tako smo pogosto srečali razvijalce Informatice

Če odmislimo postopek ugotavljanja vzrokov, je bil glavni razlog za zrušitve vzorec interakcije programske opreme Informatica z bazo podatkov repozitorija, ki se je z vidika omrežne krajine nahajala na relativno oddaljenem strežniku. To je povzročilo zamude in motnje mehanizmov, ki spremljajo stanje domene Informatica. Po nekaj prilagoditvah baze podatkov, spremembi parametrov Informatice, zaradi česar je postala bolj tolerantna na zamude baze podatkov, in na koncu posodobitvi različice Informatice na 10.1 in prenosu baze podatkov s prejšnjega strežnika na strežnik, ki je bližje Informatici, je težava izgubila svojo veljavo. relevantnost in od takrat je prišlo do zrušitev te vrste, ki jih ne opažamo.

Od vsakodnevnih nesreč do stabilnosti: Informatica 10 skozi oči skrbnika
Eden od poskusov, da bi Informatica Monitor deloval

Kritično je bilo tudi stanje z administratorsko konzolo. Ker je aktiven razvoj potekal neposredno v razmeroma produktivnem okolju, so morali sodelavci nenehno analizirati delo preslikav in potek dela "na poti". V novi Informatici Data Integration Service nima posebnega orodja za tovrstno spremljanje, temveč se je v skrbniški spletni konzoli (Informatica Administrator Monitor) pojavil razdelek za spremljanje, v katerem lahko spremljate delovanje aplikacij, potek dela in preslikave, izstrelitve, dnevniki. Občasno je konzola postala popolnoma nedostopna ali pa so se informacije o trenutnih procesih v DIS prenehale posodabljati ali pa je prišlo do napak pri nalaganju strani.

Od vsakodnevnih nesreč do stabilnosti: Informatica 10 skozi oči skrbnika
Izbira parametrov java za stabilizacijo delovanja

Težava je bila odpravljena na več načinov, izvedeni so bili poskusi spreminjanja parametrov, zbrani so bili dnevniki in jstack, poslani podpori, hkrati pa je bilo aktivno guglanje in preprosto opazovanje.

Najprej je bil izdelan ločen MRS za monitoring, ki je, kot se je kasneje izkazalo, eden glavnih porabnikov virov v naših okoljih, saj se kartiranja izvajajo zelo intenzivno. Spremenjeni so bili parametri glede java heap in številni drugi.
Posledično se je do naslednje posodobitve Informatica 10.1.1 delovanje konzole in monitorja stabiliziralo, razvijalci so začeli delovati bolj učinkovito, redni procesi pa so postajali vse bolj redni.

Zanimiva je lahko izkušnja interakcije med razvojem in administracijo. Vprašanje splošnega razumevanja, kako stvari delujejo, kaj je mogoče narediti in česa ne, je vedno pomembno pri uporabi kompleksnih sistemov. Zato lahko mirno priporočamo, da administrativno ekipo najprej usposobite za administriranje programske opreme, razvojno ekipo pa za pisanje kode in risanje procesov v sistemu ter šele nato pošljete prvega in drugega delat na rezultat. To je zelo pomembno, ko čas ni neskončen vir. Številne težave je mogoče rešiti tudi z naključnim iskanjem možnosti, vendar včasih nekatere zahtevajo vnaprejšnje znanje - naš primer potrjuje pomembnost razumevanja tega aksioma.

Na primer, ko smo poskušali omogočiti različico v MRS (kot se je na koncu izkazalo, je bila potrebna drugačna različica SVN), smo čez nekaj časa zaskrbljeni ugotovili, da se je čas ponovnega zagona sistema povečal na nekaj deset minut. Po ugotovitvi vzroka za zakasnitev zagona in onemogočenju verziranja smo se spet dobro odrezali.

Pomembne ovire, povezane z Informatiko, vključujejo epsko bitko z rastočimi nitmi Java. Na neki točki je prišel čas za replikacijo, torej za razširitev uveljavljenih procesov na veliko število izvornih sistemov. Izkazalo se je, da vsi procesi v 10.1.1 niso dobro delovali in DIS je čez nekaj časa postal nedelujoč. Zaznanih je bilo na desettisoče niti, njihovo število je še posebej opazno naraslo med postopkom uvajanja aplikacije. Včasih sem moral znova zagnati večkrat na dan, da sem obnovil funkcionalnost.

Tukaj se je treba zahvaliti podpori, saj so bile težave relativno hitro lokalizirane in odpravljene z EBF (Emergency Bug Fix) – po tem so vsi dobili občutek, da orodje res deluje.

Še vedno deluje!

Ko smo začeli delati v ciljnem načinu, je Informatica izgledala takole. Verzija Informatice 10.1.1HF1 (HF1 je HotFix1, vendorski sestav iz kompleksa EBF-jev) z dodatno nameščenim EBF-jem, ki popravlja naše težave s skaliranjem in nekatere druge, na enem strežniku od treh, ki so bili del GRID-a, 20 x86_64 jeder in shranjevanje, na ogromnem počasnem nizu lokalnih diskov - to je konfiguracija strežnika za gručo Hadoop. Na drugem podobnem strežniku - Oracle DBMS, s katerim delujeta tako domena Informatica kot nadzorni mehanizem ETL. Vse to spremljajo standardna nadzorna orodja, ki jih uporablja ekipa (Zabbix + Grafana) na obeh straneh – sama Informatica s svojimi storitvami in procesi nalaganja, ki gredo vanjo. Zdaj sta zmogljivost in stabilnost, brez upoštevanja zunanjih dejavnikov, zdaj odvisni od nastavitev, ki omejujejo obremenitev.

Ločeno lahko rečemo o GRID. Okolje je bilo zgrajeno na treh vozliščih, z možnostjo izravnave obremenitve. Vendar pa je bilo med testiranjem ugotovljeno, da zaradi težav z interakcijo med delujočimi primerki naših aplikacij ta konfiguracija ne deluje po pričakovanjih, zato so se odločili začasno opustiti to konstrukcijsko shemo in odstraniti dve od treh vozlišč iz domene. Hkrati pa je sama shema ostala enaka in je zdaj ravno storitev GRID, vendar degenerirana na eno vozlišče.

Trenutno ostaja težava povezana s padcem zmogljivosti pri rednem čiščenju vezja monitorja - pri sočasnih procesih v CNN in tekočem čiščenju lahko pride do motenj v delovanju krmilnega mehanizma ETL. To se trenutno rešuje "kot bergla" - z ročnim čiščenjem vezja monitorja, pri čemer se izgubijo vsi njegovi prejšnji podatki. To ni preveč kritično za produktivnost med normalnim rutinskim delovanjem, vendar za zdaj poteka iskanje normalne rešitve.

Druga težava izhaja iz te iste situacije - včasih pride do večkratnih zagonov našega nadzornega mehanizma.

Od vsakodnevnih nesreč do stabilnosti: Informatica 10 skozi oči skrbnika
Večkratni zagoni aplikacij vodijo do okvare mehanizma

Pri delovanju po urniku, v času velike obremenitve sistema, včasih pride do situacij, ki vodijo do okvare mehanizma. Težavo še vedno ročno odpravljajo in iščejo trajno rešitev.

Na splošno lahko povzamemo, da je ob večjih obremenitvah zelo pomembno zagotoviti temu primerne vire, to velja tudi za strojne vire za samo Informatiko in enako za njen repozitorij baze podatkov ter zagotoviti optimalne nastavitve za njih. Poleg tega ostaja odprto vprašanje, katera shema postavitve baze podatkov je boljša - na ločenem gostitelju ali na istem, kjer teče programska oprema Informatica. Po eni strani bo ceneje na enem strežniku, v kombinaciji pa je morebitna težava z omrežno interakcijo praktično odpravljena, po drugi strani pa se obremenitev gostitelja iz baze dopolni z obremenitvijo iz Informatike.

Kot pri vsakem resnem izdelku ima tudi Informatica smešne trenutke.
Nekoč sem med reševanjem neke nesreče opazil, da je v dnevnikih MRS nenavadno naveden čas dogodkov.

Od vsakodnevnih nesreč do stabilnosti: Informatica 10 skozi oči skrbnika
Časovni dualizem v dnevnikih MRS "zasnovano"

Izkazalo se je, da so časovni žigi zapisani v 12-urnem formatu, brez navedbe AM/PM, torej pred poldnevom ali popoldne. V zvezi s tem je bila celo odprta prijava in prejet uradni odgovor - tako je bilo mišljeno, v dnevniku MRS so zapisane ocene v točno tej obliki. To pomeni, da včasih ostane nekaj spletk glede časa nastanka neke NAPAKE ...

Prizadevajte si za najboljše

Danes je Informatica dokaj stabilno orodje, priročno za administratorje in uporabnike, izjemno zmogljivo glede na trenutne zmožnosti in potencial. Večkrat presega naše funkcionalne potrebe in se de facto sedaj uporablja v projektu na način, ki ni najbolj tipičen in značilen. Težave so deloma povezane z načinom delovanja mehanizmov – specifično je, da se v kratkem času zažene veliko število niti, ki intenzivno posodabljajo parametre in delajo z bazo repozitorija, medtem ko so viri strežniške strojne opreme skoraj v celoti izkoriščeni. s strani procesorja.

Zdaj smo blizu prehoda na Informatico 10.2.1 ali 10.2.2, ki ima predelane nekatere notranje mehanizme in obljube podpore za odpravo nekaterih težav z zmogljivostjo in funkcionalnostjo, ki jih trenutno imamo. S strojnega vidika pa pričakujemo strežnike z za nas optimalno konfiguracijo, upoštevajoč rezervo za bližnjo prihodnost zaradi rasti in razvoja shranjevanja.

Seveda bodo testiranja, preverjanja združljivosti in morda arhitekturne spremembe v delu HA GRID. Razvoj znotraj Informatike se bo nadaljeval, saj kratkoročno ne moremo dobaviti ničesar, kar bi nadomestilo sistem.
In tisti, ki bodo v prihodnosti odgovorni za ta sistem, ga bodo zagotovo lahko pripeljali do zahtevanih kazalnikov zanesljivosti in učinkovitosti, ki jih bodo postavili kupci.

Članek je pripravila ekipa za upravljanje podatkov Rostelecom

Od vsakodnevnih nesreč do stabilnosti: Informatica 10 skozi oči skrbnika
Trenutni logotip Informatica

Vir: www.habr.com

Dodaj komentar