Komponenta ETL e magazinit të dhënash shpesh mbetet në hije të vetë magazinës dhe i kushtohet më pak vëmendje se sa bazës kryesore të të dhënave ose komponentit të përparëm, BI, përgatitjes së raporteve. Megjithatë, nga pikëpamja mekanike të mbushjes së magazinës me të dhëna, ETL luan një rol kyç dhe kërkon ashtu siç është administratori më shumë vëmendje se komponentët e tjerë. Unë quhem Aleksandër, tani administroj ETL në Rostelecom, dhe në këtë artikull do të përpiqem të ndaj pak nga ajo që ndodhet përballë një administratori të një prej sistemeve ETL më të njohura në një magazinë të madhe të dhënash të kompanisë Rostelecom.
Nëse të nderuar lexues janë tashmë 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.
Para disa vjetësh në Rostelecom, lindi dhe u realizua ideja për një magazinë të vetme korporative të të dhënave. Një seri magazinash, që zgjidhin detyra të veçanta, ishin krijuar tashmë, por numri i skenarëve po rritej, shpenzimet për mbështetje gjithashtu po rriteshin, dhe ishte e qartë se e ardhmja është centralizimi. Arkitektonikisht, kjo magazinë përbëhet nga disa nivele, e realizuar në Hadoop dhe GreenPlum, databaza ndihmëse, mekanizmat ETL dhe BI.
Megjithatë, për shkak të numrit të madh të burimeve të dhënash, të shpërndara gjeografikisht dhe heterogjene, u krijua një mekanizëm i veçantë për shkarkimin e të dhënave, puna e të cilit menaxhohet nga Informatica. Si rezultat, paketat me të dhëna ndodhen në zonën ndërfyese të Hadoop, pasi fillojnë proceset e ngarkimit të të dhënave nëpër nivelet e magazinës, në Hadoop dhe GreenPlum, dhe ato menaxhohen nga mekanizmi i quajtur mekanizmi i administratës ETL, i realizuar në Informatica. Kështu, sistemi Informatica është një nga elementet kyçe 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 konsiderohet aktualisht 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ë tjera.
PowerCenter që përdorim është një server i integruar i aplikacioneve Tomcat, në të cilin funksionojnë aplikacionet Informatica që realizojnë shërbimet e saj:
Domain, në thelb, kjo është baza për të gjitha gjërat e tjera, brenda domenit funksionojnë shërbime, përdorues, komponente GRID.
Administrator Console, një mjet web për menaxhim dhe monitorim, përveç klientit Informatica Developer, është mjeti kryesor për bashkëveprimin me produktin
MRS, Model Repository Service, një depo e metadatat, është një shtresë ndërmjet bazës ku metadatat ruhen fizikisht dhe klientit Informatica Developer, ku zhvillohet. Repository-t ruajnë si përshkrimin e të dhënave ashtu edhe informacione të tjera, përfshirë për disa shërbime të tjera të Informatica, për shembull, orarin e ekzekutimit të detyrave (Schedules) ose të dhënat për monitorim, si dhe setet e parametrave të aplikacioneve, të cilat përfundojnë duke lejuar përdorimin e njëjtit aplikacion për punë me burime dhe destinacione të ndryshme të të dhënave.
DIS, Data Integration Service, ky është shërbimi ku ndodhin proceset funksionale kryesore, ku aplikacionet punojnë dhe ndodhin ekzekutimet e Workflows (përshkrimet e sekuencave të mappings dhe ndërveprimin e tyre) dhe Mappings (transformimet, blloqet ku ndodhin vetë transformimet, përpunimi i të dhënave).
Konfigurimi i GRID – në thelb, një variant i ndërtimit të një kompleksi duke përdorur disa serverë, kur ngarkesa e nisur nga DIS shpërndahet në node (dmth serverë që bëjnë pjesë në domen). Në rastin e këtij varianti, përveç shpërndarjes së ngarkesës në DIS përmes një shtrese të mëtejshme abstraksioni GRID, që bashkon disa node, ku punon DIS në vend të punës për një nod të caktuar, gjithashtu mund të krijohen kopje rezervë shtesë të MRS. Madje mund të realizohet një disponueshmëri e lartë, kur kërkesat e jashtme mund të realizohen përmes nodded rezervë në rast të dështimit të nodit kryesor. Prej këtij varianti të ndërtimit ne për momentin jemi të anuluar.
Informatica PowerCenter, në mënyrë skematike
Në fazat e para të punës në zinxhirin e furnizimit të të dhënave, rregullisht shfaqeshin probleme, disa prej tyre falë punës jo të qëndrueshme të Informatica në atë kohë. Unë kam për qëllim të ndajem disa nga momentet më të paharrueshme të kësaj saga - mësimi i Informatica 10.
Logotip i mëparshëm i Informatica
Fusha e përgjegjësive tona përfshin gjithashtu mjedise të tjera të Informatica, ku ka specifika të veta për shkak të ngarkesës tjetër, por deri tani do të përmend një mënyrë se si Informatica është zhvilluar si komponent ETL i vetë depozitës së të dhënave.
Si ndodhi kjo
Në vitin 2016, kur ne filluam të ishim përgjegjës për funksionimin e Informatica, ajo tashmë kishte arritur versionin 10.0, dhe për kolegët me mendime optimiste, që morën vendimin për të përdorur një zgjidhje serioze të produktit me një version minor .0, gjithçka dukej e qartë - duhet të përdoret versioni i ri! Nga pikëpamja e burimeve harduerike, gjithçka ishte shkëlqyer në atë moment.
Që nga pranvera e vitit 2016, funksionimin e Informatica e kishte një kontraktues, dhe sipas fjalëve të pak përdoruesve të sistemit, "ajo punonte disa herë në javë". Këtu duhet të sqaroj se depozita ishte de facto në fazën e PoC, nuk kishte administratorë në ekip dhe sistemi binte vazhdimisht për arsye të ndryshme, pas së cilës inxhinieri i kontraktuesit e ringjallte atë përsëri.
Në vjeshtë në ekip u shfaqën tre administratorë, të cilët ndanë përgjegjësitë midis tyre dhe filloi të ndërtohej një punë normale për operimin e sistemeve në projekt, duke përfshirë Informatica. Është e rëndësishme të përmendet se ky produkt nuk është i përhapur gjerësisht dhe nuk ka një komunitet të madh, ku mund të gjejmë përgjigje për çfarëdo pyetje dhe të zgjidhim çfarëdo problemi. Prandaj, mbështetje teknike e plotë nga partneri rus i Informatica ishte shumë e rëndësishme, me ndihmën e të cilit u korrigjuan të gjitha gabimet tona dhe ato të Informatica 10, që ishte ende e re.
Gjëja e parë që na duhej të bënim për zhvilluesit e ekipit tonë dhe kontraktuesin - të stabilizojmë funksionimin e vetë Informatica, për të arritur funksionalitetin e web-konsolës së administratës (Informatica Administrator).
Kështu, shpesh takonim zhvilluesit e Informatica.
Duke lënë anash vetë procesin e zbardhjes së arsyeve, arsyeja kryesore e rënieve ishte skema e bashkëpunimit të softuerit Informatica me bazën e të dhënave të depozitës, e cila ndodhej në një server relativisht të largët, në lidhje me peizazhin rrjetor. Kjo shkaktonte vonesa dhe dëmtonte funksionimin e mekanizmave që siguronin kontrollin e gjendjes së domain-it Informatica. Pas disa optimizimeve të bazës së të dhënave, ndryshimeve të parametrave të Informatica, që e bënë atë më tolerant ndaj vonesave të bazës së të dhënave, si dhe përditësimit të versionit të Informatica në 10.1 dhe zhvendosjes së bazës së të dhënave nga serveri i mëparshëm në një server më të afërt me Informatica, problemi humbi aktualitetin dhe qysh atëherë nuk kemi vërejtur rënie të këtij lloji.
Një nga përpjekjet për të arritur funksionimin e Informatica Monitor
Situata me konsolën e administratës gjithashtu ishte kritike. Pasi po zhvillohej aktivisht në një mjedis që supozohej se ishte produktiv, kolegët kishin nevojë të analizojnë punën e mappings, workflow 'në lëvizje'. Në Informatica të re, në Shërbimin e Integrimit të Të Dhënave nuk ka një mjet të veçantë për të tillë monitorim, por në web-konsolën e administratës është shfaqur një seksion monitorimi (Informatica Administrator Monitor), ku mund të vëreni punën e aplikacioneve, workflow dhe mappings, nisjet, logjet. Periodikisht konsola bëhej krejtësisht e pa akses, ose informatat për proceset aktuale në DIS nuk rifreshoheshin, ose shfaqeshin gabime gjatë ngarkimit të faqeve.
Përzgjedhja e parametrave java për stabilizimin e punës
Korrigjimi i problemit po bëhej në shumë mënyra, eksperimentet për ndryshimin e parametrave u zhvilluan, logjet u mblodhën, jstack u dërgua në mbështetje, në të njëjtën kohë po bëhej kërkimi aktiv në Google dhe thjesht u bë vëzhgim.
Së pari, u krijua një MRS e veçantë për monitorim, siç doli më vonë, kjo ishte një nga konsumatorët kryesorë të burimeve në mjediset tona, pasi nisjet e mappings ndodhin shumë intensivisht. U ndryshuan parametrat që lidhen me java heap, si dhe një sërë të tjerave.
Si rezultat, në përditësimin e ardhshëm të Informatica 10.1.1, arritëm të stabilizojmë funksionimin e konsolës dhe monitorit, zhvilluesit filluan të punojnë më efikasht, dhe proceset e rregullta bëheshin gjithnjë e më të rregullta.
Eksperienca e bashkëveprimit mes zhvillimit dhe administrimit mund të jetë interesante. Pyetja e kuptimit të përbashkët, se si funksionon gjithçka, çfarë mund të bëhet dhe çfarë nuk mund të bëhet, përherë është e rëndësishme kur përdoren sisteme komplekse. Prandaj, mund të rekomandohet që së pari të trajnohet ekipi i administruesve se si duhet të administrohet softueri, dhe ekipi i zhvilluesve se si duhet të shkruhet kodi dhe të vizatohen proceset në sistem, dhe vetëm pastaj t’i dërgoni ata të punojnë për rezultate. Kjo është me të vërtetë e rëndësishme kur koha nuk është një burim i pafund. Shumë probleme mund të zgjidhen madje edhe me një përzgjedhje rastësore të mundësive, por herë pas here disa kërkojnë njohuri a priori - rasti ynë konfirmon rëndësinë e kuptimit të kësaj aksiome.
Për shembull, gjatë përpjekjes për të aktivizuar versionimin në MRS (siç doli, ishte e nevojshme një version tjetër të SVN), pas një kohe ne e zbuluam me shqetësim se koha e rinisjes së sistemit ishte rritur në disa dhjetëra minuta. Duke dalë në shkakun e vonesës në fillim dhe duke çaktivizuar versionimin, e bëmë sërish mirë.
Nga pengesat e dukshme që lidhen me Informatica, mund të përmendim luftën epike me rritjen e rrjedhave java. Në një moment, erdhi koha për replikimin, pra për të përhapur proceset e vendosura në një numër të madh sistemesh burimore. Gjatë kësaj, doli 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ëjmë rinisje disa herë në ditë për të rikthyer funksionalitetin.
Këtu duhet falënderuar mbështetjen, gjithçka u lokalizua dhe u rregullua relativisht shpejt me ndihmën e EBF (Rregullimi i Jashtëzakonshëm të Gabimeve) - pas kësaj të gjithëve iu ndie se instrumenti me të vërtetë funksionon.
Përfundimisht funksionon!
Në momentin e fillimit të punës në modin e synuar, Informatica dukej si më poshtë. Versioni Informatica 10.1.1HF1 (HF1 është HotFix1, ndërtimi i furnizuesit nga kompleksi i EBF-ve) me EBF shtesë të instaluara, që rregullojnë 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ë sasi të madhe të ngadaltë të disqeve lokale - kjo konfigurimi i serverit për klasterin Hadoop. Në një server tjetër të ngjashëm — Baza e të Dhënave Oracle me të cilën punon dhe domeni Informatica dhe mekanizmi menaxhues ETL. Të gjitha këto monitorohen me mjete standarde monitorimi, të përdorura nga ekipi (Zabbix + Grafana), nga dy anë — si Informatica me shërbimet e saj, ashtu edhe proceset e ngarkesës që i drejtohen asaj. Tani për tani, si performanca ashtu edhe 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-in. Mjedisi u ndërtua mbi tre node, me mundësi për balancimin e ngarkesës. Megjithatë, gjatë testimit u zbulua se për shkak të problemeve në ndërveprimin mes instanceve të aplikacioneve tona, një konfigurim i tillë nuk funksiononte siç pritej, dhe përkohësisht u vendos të hiqet dorë nga ky skemë ndërtimi, duke çuar jashtë domenit dy nga tre node. Sidoqoftë, skema mbeti e njëjta, dhe tani është pikërisht një shërbim GRID, por i shndërruar në një node.
Aktualisht mbetet një vështirësi e lidhur me rënien e performancës gjatë pastrimit të rregullt të skemës së monitorit — kur proceset po ndodhin në mënyrë të sinkronizuar dhe pastrimi është në zhvillim, mund të ndodhin dështime në punën e mekanizmit menaxhues ETL. Kjo aktualisht zgjidhet në mënyrë "të përkohshme" — me pastrimin manual të skemës së monitorit, me humbjen e të dhënave të mëparshme. Kjo nuk është shumë kritike për produktivitetin, gjatë funksionimit normal, por akoma po kërkohet një zgjidhje të duhur.
Nga kjo situatë rrjedh edhe një problem tjetër — herë pas here ndodhin njësitë e shumta të mekanizmit tonë menaxhues.
Njësitë e shumta të aplikacionit, që çojnë në prishjen e mekanizmit
Gjatë nisjes sipas orarit në momentet me ngarkesë të madhe në sistem, nganjëherë ndodhin situata të tilla që çojnë në prishjen e mekanizmit. Deri tani problemi zgjidhet manualisht, dhe po kërkohet një zgjidhje të përhershme.
Në përgjithësi, mund të përmblidhet se, në kushte të ngarkesës së madhe, është shumë e rëndësishme të ofrosh burime të përshtatshme për të, kjo përfshin burimet harduerike për vetë Informatica, si dhe për depozitën e saj DB, si dhe sigurimin e konfigurimeve optimale për to. Për më tepër, ngeli i hapur pyetja se cila skemë vendosjeje të DB është më e mirë - në një host të veçantë, apo në të njëjtin ku punon programi Informatica. Nga njëra anë, në një server do të ishte më lirë dhe duke u kombinuar, praktiikisht zgjidhet problemi i mundshëm me ndërveprimin rrjetor, nga ana tjetër — ngarkesa në host nga DB shtohet me ngarkesën nga Informatica.
Si në çdo produkt të rëndësishëm, në Informatica ka dhe momente komike.
Një herë, duke analizuar ndonjë aksident, vura re se në logot MRS ishte shënuar pazakonisht koha e ngjarjeve.
Dualizmi temporal në logot MRS 'sipër dizajnit'
Doli se kohët shënohen në formatin 12-orësh, pa shënimin AM/PM, pra para ose pas mesditës. Madje ishte hapur një kërkesë për këtë çështje dhe u mor një përgjigje zyrtare - kështu ishte menduar, në logun MRS shënohen pikërisht në këtë format. Domethënë, ndonjëherë ka mbetur një mister në lidhje me orën e shfaqjes së ndonjë ERROR-i...
Të synosh për të mirën
Sot Informatica është një mjet mjaft i qëndrueshëm, i përshtatshëm për administratorin dhe përdoruesit, jashtëzakonisht i fuqishëm për mundësitë dhe potencialin aktual. Ai tejkalon disa herë funksionalisht nevojat tona dhe de facto përdoret tani në projekt në një mënyrë jo të zakonshme dhe tipike. Vështirësitë lidhen pjesërisht me mënyrën si funksionojnë mekanizmat - specifikisht është se për një periudhë të shkurtër kohore aktivizohen një numër i madh kanalesh që përditësojnë intensivisht parametrat e setit dhe punojnë me DB-në e depozitës, ndërkohë që burimet harduerike të serverit shfrytëzohen praktikisht plotësisht në CPU.
Tani jemi afër kalimit në Informatica 10.2.1 ose 10.2.2, në të cilat janë rishikuar disa mekanizma të brendshëm, dhe mbështetja premton se do të mungojnë disa nga problemet e tanishme që kemi me performancën dhe funksionimin. Po ashtu, nga pikëpamja harduerike pritet të kemi serverë me konfigurimin optimal për ne, duke marrë parasysh rezervat për periudhën në vijim për shkak të rritjes dhe zhvillimit të depozitave.
Natyrisht, do të ketë testime, verifikime të përputhshmërisë, dhe ndoshta, ndryshime arkitekturore në lidhje me HA GRID. Zhvillimi brenda Informatica do të vazhdojë, pasi në një perspektivë afatshkurtër nuk mund të vendosim diçka për të zëvendësuar sistemin.
Dhe ata që në të ardhmen do të jenë përgjegjës për këtë sistem, patjetër që do të arrijnë ta çojnë atë në nivelet e kërkuara të besueshmërisë dhe performancës që kërkojnë klientët.
Artikulli është përgatitur nga ekipi i menaxhimit të të dhënave të "Rostelecom".
Logoja aktuale e Informatica
Burimi: habr.com
