Komponenti ETL i magazinit të dhënash shpesh mbetet në hije të magazinit vetë dhe i jepet më pak vëmendje se sa bazës së të dhënave kryesore ose komponentëve të front-end, BI, përgatitjes së raporteve. Megjithatë, nga pikëpamja e mekanikës së mbushjes së magazinës me të dhëna, ETL luan një rol kyç dhe kërkon jo më pak vëmendje nga administratorët sesa komponentët e tjerë. Më quaj Alexander, tani unë administratoj ETL-në në Rostelecom, dhe në këtë artikull do të përpiqem të ndaj pak nga ajo që has një administrator i një prej sistemeve ETL më të njohura në një magazin të madhe të dhënash të kompanisë Rostelecom.
Nëse lexuesit e nderuar janë të njohur në përgjithësi me projektin tonë të magazinës së të dhënave dhe me produktin Informatica PowerCenter, atëherë mund të kaloni menjëherë në seksionin tjetër.
Disa vjet më parë, në Rostelecom u krijua dhe filloi të realizohet ideja e një magazinës së centralizuar të dhënash. Një sërë magazinash, që zgjidhnin detyra të veçanta, ishin krijuar tashmë, por numri i skenarëve po rritej, kostot për mbështetje gjithashtu po rriteshin, dhe bëhej e qartë se e ardhmja është në centralizim. Arkitektonikisht, kjo magazinë përbëhet nga disa nivele, të realizuara në Hadoop dhe GreenPlum, bazat ndihmëse të dhënash, mekanizmat ETL dhe BI.
Megjithatë, për shkak të numrit të madh të burimeve të dhënash që janë të shpërndara gjeografikisht dhe të ndryshme, u krijua një mekanizëm i veçantë për eksportimin e të dhënave, i cili drejtohet nga Informatica. Si rezultat, paketat me të dhëna përfundojnë në zonën ndërfaqësore të Hadoop, pas së cilës fillojnë proceset e ngarkesës së të dhënave nëpër nivelet e magazinës, në Hadoop dhe GreenPlum, të cilat menaxhohen nga mekanizmi i quajtur ETL, i realizuar në Informatica. Thënë kështu, sistemi Informatica është një nga elementët kryesorë që sigurojnë funksionimin e magazinës.
Më në detaje për magazinën tonë do të flitet në një nga postimet e ardhshme.
Informatica PowerCenter/Big Data Management në këtë moment konsiderohet si softueri lider në fushën e mjeteve për integrimin e të dhënave. Ky është një produkt i kompanisë amerikane Informatica, e cila është një nga lojtarët më të fortë në ETL (Extract Transform Load), menaxhimin e cilësisë së të dhënave, MDM (Master Data Management), ILM (Information Lifecycle Management) dhe të tjerë.
PowerCenter që përdorim është një server i integruar aplikacionesh Tomcat, në të cilin operojnë aplikacionet e Informatica, që realizojnë shërbimet e saj:
Domen, në thelb, është baza për gjithçka tjetër, brenda domainit funksionojnë shërbimet, përdoruesit, komponentët e GRID.
Administrator Console, mjeti web për menaxhim dhe monitorim, përveç klientit Informatica Developer, është mjeti kryesor për të ndërlidhur me produktin
MRS, Model Repository Service, magazina e metadatat, përfaqëson një shtresë midis bazës ku metadatat ruhen fizikisht dhe klientit Informatica Developer, ku zhvillohet. Repository-t ruajnë dhe përshkrimin e të dhënave, dhe informacionin tjetër, përfshirë për një sërë shërbimesh të tjera të Informatica, për shembull, orarin e ekzekutimeve të detyrave (Schedules) ose të dhënat e monitorimit, si dhe parametërset e aplikacioneve, që veçanërisht lejojnë përdorimin e një dhe të njëjtës aplikacion për të punuar me burime dhe marrës të ndryshëm të të dhënave.
DIS, Data Integration Service, ky është shërbimi ku ndodhin proceset funksionale kryesore, në të operojnë aplikacionet dhe ndodhin fillimet e Workflows (përshkrimi i sekuencave të mappings dhe ndërveprimi i tyre) dhe Mappings (transformime, blloqe ku ndodhin vetë transformimet, përpunimi i të dhënave).
Konfigurimi i GRID – në thelb, është një variant ndërtimi të një kompleksi me përdorimin e disa serverëve, kur ngarkesa e lançuar nga DIS shpërndahet në node (domethënë serverëve që bëjnë pjesë në domain). Në këtë rast, përveç shpërndarjes në DIS të ngarkesës përmes një shtrese shtesë abstrakte GRID, që bashkon disa node, në të cilin dhe punon DIS në vend të punuarit në një node të caktuar, gjithashtu mund të krijohen kopje rezervë shtesë të MRS. Madje mund të realizohet disponueshmëri e lartë, kur kërkesat e jashtme mund të përpunohen përmes node-ve rezervë në rast të dështimit të atij kryesor. Nga ky variant ndërtimi deri tani kemi hequr dorë.
Informatica PowerCenter, në mënyrë schematike
Në fillimet e punës brenda zinxhirit të furnizimit të të dhënave, rregullisht shfaqeshin probleme, disa prej të cilave për shkak të punës jo të qëndrueshme të Informatica në atë moment. Unë do të ndaj disa nga momentet e paharrueshme të kësaj saga — mastering Informatica 10.
Logotipas Informatica
Fusha e përgjegjësisë sonë përfshin gjithashtu mjedise të tjera të Informatica, që kanë specifikat e tyre për shkak të ngarkesave të ndryshme; për momentin, unë do të përmend veçanërisht si Informatica është zhvilluar si komponent ETL i vetë magazinës së të dhënave.
Si ndodhi kjo
Në vitin 2016, kur filluam të përgjigjeshim për funksionimin e Informatica, ajo kishte arritur tashmë versionin 10.0, dhe për kolegët me optimizëm që merrnin vendim për përdorimin e një produkti me versionin më të vogël .0, gjithçka dukej e qartë — duhej të përdorej versioni i ri! Sa i përket burimeve harduerike, gjithçka ishte në rregull në atë moment.
Që nga pranvera e vitit 2016, menaxhimin e Informatica e kishte një kontraktues, dhe sipas fjalëve të pakicës së përdoruesve të sistemit, “ajo punonte disa herë në javë”. Duhet të sqarojmë se të dhënat ishin de-fakto në fazën PoC, nuk kishte administratorë në ekip dhe sistemi vazhdimisht rrëzohej për arsye të ndryshme, pas së cilës inxhinieri i kontraktuesit e rihapte atë.
Në vjeshtë, në ekip u shfaqën tre administratorë, të cilët ndanë mes tyre fushat e përgjegjësisë, dhe filloi të ndërtohej një punë normale për administrimin e sistemeve në projekt, duke përfshirë Informatica. Duhet thënë veçmas se ky produkt nuk është shumë i përhapur dhe nuk ka një komunitet të gjerë, në të cilin mund të gjeni përgjigje për çdo pyetje dhe të zgjidhni çdo problem. Prandaj, mbështetje teknike e plotë nga partneri ynë rus i Informatica ishte shumë e rëndësishme, me ndihmën e të cilit u korrigjua çdo gabim ynë dhe ato të Informatica 10, e cila ishte akoma e re.
E para që duhej të bënim për zhvilluesit e ekipit tonë dhe kontraktuesin ishte stabilizimi i funksionimit të vetë Informatica, duke arritur funksionalitetin e konsolës së administrimit në rrjet (Informatica Administrator).
Ndonjëherë, zhvilluesit e Informatica na kanë pritur kështu
Duke lënë jashtë procesin e sqarimit të arsyeve, arsyeja kryesore e rrëzimeve ishte skema e ndërveprimit të softuerit Informatica me bazën e të dhënave të depozitës, e cila ndodhej në një server relativisht të largët, nga këndvështrimi i peizazhit rrjetor. Kjo shkaktonte vonesa dhe dëmtonte funksionimin e mekanizmave që siguronin kontrollin e gjendjes së domain-it të Informatica. Pas një optimizimi të caktuar të bazës së të dhënave, ndërrimit të parametrave të Informatica që e bënë atë më tolerant ndaj vonesave të bazës së të dhënave, dhe përfundimisht përditësimit të versionit të Informatica në 10.1 dhe transferimin e bazës së të dhënave nga serveri i mëparshëm në një server më të afërt me Informatica, problemi humbi rëndësinë, dhe që nga atëherë nuk kemi vërejtur rënie të këtij lloji.
Një nga përpjekjet për të arritur funksionalitetin e Informatica Monitor
Situata me konsolën e administrimit ishte gjithashtu kritike. Ndërsa zhvillimi po vazhdonte aktivisht direkt në një mjedis të ashtuquajtur produktiv, kolegët shpesh kishin nevojë të analizojnë funksionimin e mappings, workflow “në ecje”. Në Informatica të re, në Shërbimin e Integrimit të Të Dhënave, nuk ka një mjet të veçantë për monitorimin e tillë, por në konsolën web të administrimit ka lindur një seksion monitorimi (Informatica Administrator Monitor), ku mund të vërehet funksionimi i aplikacioneve, workflow dhe mappings, ekzekutimet, logjet. Herë pas here, konsola bëhej krejtësisht e paarritshme, ose informacionet për proceset aktuale në DIS ndalonin së përditësuari, ose ndodhnin gabime gjatë ngarkimit të faqeve.
Zgjedhja e parametrave java për stabilizimin e funksionimit
Rregullimi i problemit po përparonte në shumë mënyra, eksperimentet për ndryshimin e parametrave ishin duke u zhvilluar, logjet dhe jstack u mbledhën, dhe u dërguan në mbështetje, përveç kësaj, po zhvillohej kërkimi aktiv në Google dhe vetëm po vëzhgohej.
Fillimisht u krijua një MRS të veçantë për monitorim, siç u vërtetua më vonë, ky ishte një nga konsumatorët kryesorë të burimeve në mjediset tona, pasi ekzekutimet e mappings ishin shumë intensive. U ndërruan parametrat që kishin të bënin me java heap, dhe një sërë parametrash të tjerë.
Si rezultat, deri në përditësimin e ardhshëm të Informatica 10.1.1, funksionimi i konsolës dhe monitorit arriti të stabilizohet, zhvilluesit filluan të punonin më efektivisht dhe proceset e rregullta po bëheshin gjithnjë e më të shpeshta.
Një përvojë interesante mund të jetë bashkëpunimi ndërmjet zhvillimit dhe administratës. Pyetja e kuptimit të përbashkët, si funksionon gjithçka, çfarë është e mundur të bëhet dhe çfarë jo, gjithmonë është e rëndësishme kur përdoren sisteme të komplikuara. Prandaj, mund të rekomandohet me besim që së pari të trajnohet ekipi i administratorëve se si të administrojnë softuerin, dhe ekipi i zhvilluesve se si të shkruajnë kod dhe të përshkruajnë proceset në sistem, e më pas të dërgohen të parët dhe të dytë për të punuar për rezultat. Kjo është vërtet e rëndësishme kur koha nuk është një burim i pakufizuar. Shumë probleme mund të zgjidhen madje edhe me provë dhe gabim, por ndonjëherë disa kërkojnë njohuri a priori — rasti ynë konfirmon rëndësinë e kuptimit të kësaj aksiome.
Për shembull, kur u përpoqëm të aktivizonim versionimin në MRS (siç rezultoi, kishte nevojë për një version tjetër SVN), pas një kohe ne e zbuluam me shqetësim se koha e rillogaritjes së sistemit ishte rritur në disa dhjetëra minuta. Pas zbulimit të shkakut të vonesës së nisjes dhe çaktivizimit të versionimit, gjërat u bë përsëri mirë.
Një nga pengesat e dukshme që lidhen me Informatica është një luftë epike me rritjen e rrjedhave java. Në një moment, erdhi koha për të klonuar, që do të thoshte të shpërndanin proceset e krijuara më parë në një numër të madh sistemesh burimi. Ndërsa, rezultoi se jo të gjitha proceset në 10.1.1 funksiononin mirë, dhe pas një kohe DIS bëhej jo funksional. Zbuloheshin dhjetëra mijëra rrjedha, numri i të cilave rritej veçanërisht gjatë procedurës së shpërndarjes së aplikacioneve. Herë pas here duhej të bëhej një rillogaritje disa herë në ditë për të rikthyer funksionalitetin.
Këtu, duhet të falënderojmë mbështetjen, problemi u lokalizua dhe u riparua relativisht shpejt me ndihmën e EBF (Emergency Bug Fix) – pas kësaj, të gjithë patën ndjenjën se mjeti vërtet funksionon.
Vërtet funksionon!
Në momentin kur filluam punën në modin e destinuar, Informatica dukej në këtë mënyrë. Versioni Informatica 10.1.1HF1 (HF1 është HotFix1, grumbullimi vendor nga kompleksi EBF) me EBF të instaluara që riparonin problemet tona me shkallëzimin dhe disa të tjera, në një server nga tre, që ishin pjesë e GRID-it, 20 bërthama x86_64 dhe ruajtje në një masiv të madh dhe të ngadaltë diskesh lokalë — kjo konfigurimi i serverit për klasterin Hadoop. Në një server tjetër të tillë — DBMS Oracle me të cilin punon dhe domeni Informatica dhe mekanizmi menaxhues ETL. Të gjitha këto monitorohen me mjete të zakonshme monitorimi, të përdorura nga ekipi (Zabbix + Grafana), nga dy anë — si Informatica me shërbimet e saj, ashtu edhe proceset që po ngarkohen në të. Tani, dhe performanca dhe stabiliteti i punës, pa marrë parasysh faktorët e jashtëm, varen nga konfigurimet që kufizojnë ngarkesën.
Veçmas mund të flasim për GRID. Ambienti u ndërtua në tre node, me mundësi balancimi ngarkese. Megjithatë, gjatë testimit u zbulua se për shkak të problemeve të ndërveprimit ndërmjet instanceve të aplikuara të aplikacioneve tona, një konfigurim i tillë nuk punonte ashtu si pritej, dhe përkohësisht u vendos të hiqet nga kjo skemë ndërtimi, duke nxjerrë dy nga tre node nga domeni. Megjithatë, vetë skema mbeti e njëjtë, dhe tani është pikërisht shërbimi GRID, por i reduktuar në një node.
Pikërisht tani, mbetet një vështirësi që lidhet me rënien e performancës gjatë pastrimit të rregullt të skemës së monitorit — gjatë proceseve që ndodhin në mënyrë të përbashkët dhe me pastrimin e aktivizuar, mund të ndodhin dështime në funksionin e mekanizmit menaxhues ETL. Kjo aktualisht zgjidhet "me një zgjidhje të përkohshme" — pastrimi manual i skemës së monitorit, me humbjen e të gjitha të dhënave të saj të mëparshme. Kjo nuk është shumë kritike për produktivitetin, në punën e zakonshme, por për momentin po kërkohet një zgjidhje normale.
Nga kjo situatë del një tjetër problem — ndonjëherë ndodhin fillime të shumëfishta të mekanizmit tonë menaxhues.
Fillimet e shumëfishta të aplikacionit, që çojnë në dështimin e mekanizmit
Kur aktivizohet sipas një grafiku në momentet e ngarkesave të mëdha në sistem, ndonjëherë ndodhin situata të tilla që çojnë në dështimin e mekanizmit. Akoma problemi po riparohet manualisht, po kërkohet një zgjidhje të përhershme.
Në përgjithësi, mund të përfundojmë se kur ka ngarkesë të madhe, është shumë e rëndësishme të sigurohen burime adekuate, përfshirë burimet harduerike për vetë Informatica si dhe për depozitën e saj të DB-së, si dhe të sigurohen konfigurime optimale për to. Për më tepër, mbetet hapur çështja se cila skemë vendosjeje e DB-së është më e mirë - në një host të veçantë, ose në të njëjtin me softuerin Informatica. Nga njëra anë, është më e lirë ta mbash në një server, dhe kjo eliminon pothuajse mundësinë e problemeve me ndërveprimin rrjet, nga ana tjetër, ngarkesa nga DB-ja shtohet me ngarkesën nga Informatica.
Si në çdo produkt serioz, edhe në Informatica ka momente komike.
Një herë, duke analizuar një aksident, vura re se në logjet MRS, koha e ngjarjeve ishte shënuar çuditshëm.
Dualizmi temporal në logjet MRS "sipër dizajnit"
Doli se shenjat e kohës shënohen në formatin 12-orësh, pa treguar AM/PM, domethënë para mesditës ose pas saj. Madje ishte hapur një kërkesë për këtë çështje, dhe u mor një përgjigje zyrtare - ishte menduar ashtu, shenjat në logun MRS janë pikërisht në këtë format. Pra, ndonjëherë mbetet një mister i caktuar rreth kohës së ndodhisë së ndonjë ERROR-i...
Të dëshirosh më të mirën
Sot, Informatica është një mjet mjaft i qëndrueshëm, i përshtatshëm për administratorët dhe përdoruesit, jashtëzakonisht i fuqishëm për mundësitë aktuale dhe potencialin e tij. Ai shumëfish kalon nevojat tona dhe aktualisht përdoret në një projekt në mënyrë jo shumë karakteristike dhe tipike. Vështirësitë kanë të bëjnë pjesërisht me mënyrën se si funksionojnë mekanizmat - specifika është se në një periudhë të shkurtër kohore, një numër i madh procesesh aktivizohen që azhurnojnë intensivisht parameterët dhe punojnë me depozitën e DB-së, ndërkohë që burimet harduerike të serverit janë përdorur krejtësisht nga CPU.
Tani, ne jemi afër kalimit në Informatica 10.2.1 ose 10.2.2, të cilat kanë rishikuar disa mekanizma të brendshëm, dhe mbështetja premton eliminimin e disa problemeve që kemi aktualisht me performancën dhe funksionimin. Po ashtu, pritet që nga pikëpamja harduerike të kemi serverë të optimizuar për konfigurimin tonë, duke marrë parasysh rezervën për periudhën e ardhshme për shkak të rritjes dhe zhvillimit të depozitës.
Natyrisht, na pret testimi, verifikimi i pajtueshmërisë dhe ndoshta ndërrime arkitekturore në pjesën e HA GRID. Zhvillimi brenda Informatica do të vazhdojë, sepse në perspektivën afatshkurtër nuk mund të vendosim diçka në vend të sistemit.
Dhe ata që do të jenë përgjegjës për këtë sistem në të ardhmen, patjetër do të arrijnë ta sjellin atë në nivelet e nevojshme të besueshmërisë dhe performancës të kërkuara nga klientët.
Artikulli është përgatitur nga ekipi i menaxhimit të të dhënave të "Rostelecom"
Logotipi aktual i Informatica
Burimi: habr.com
