Die ETL-komponent van die datapakhuis word dikwels deur die pakhuis self oorskadu en kry minder aandag as die hoofdatabasis of voorkomponent, BI, verslagdoening. Terselfdertyd, vanuit die oogpunt van die meganika om die pakhuis met data te vul, speel ETL 'n sleutelrol en vereis nie minder aandag van administrateurs as ander komponente nie. My naam is Alexander, nou administreer ek ETL in Rostelecom, en in hierdie artikel sal ek probeer om 'n bietjie te deel wat die administrateur van een van die bekendste ETL-stelsels in 'n groot datapakhuis van Rostelecom moet trotseer.
As liewe lesers reeds in die algemeen vertroud is met ons datapakhuisprojek en met die Informatica PowerCenter-produk, dan kan jy dadelik na die volgende afdeling gaan.
'N Paar jaar gelede het Rostelecom volwasse geword en die idee van 'n enkele korporatiewe datapakhuis begin implementeer. 'n Aantal bewaarplekke wat individuele take opgelos het, is reeds geskep, maar die aantal scenario's het gegroei, ondersteuningskoste het ook toegeneem, en dit het duidelik geword dat die toekoms in sentralisering lê. Argitektonies is dit die berging self, bestaande uit verskeie lae, geïmplementeer op Hadoop en GreenPlum, hulpdatabasisse, ETL-meganismes en BI.
Terselfdertyd, as gevolg van die groot aantal geografies verspreide, heterogene databronne, is 'n spesiale data-oplaaimeganisme geskep, waarvan die werking deur Informatica beheer word. Gevolglik beland datapakkette in die Hadoop-koppelvlak-area, waarna die prosesse van die laai van data oor stoorlae, in Hadoop en GreenPlum, begin, en dit word beheer deur die sogenaamde ETL-beheermeganisme wat in Informatica geïmplementeer is. Die Informatica-stelsel is dus een van die sleutelelemente wat die werking van die bewaarplek verseker.
Meer besonderhede oor ons bewaarplek sal in een van die volgende plasings bespreek word.
Informatica PowerCenter/Big Data Management word tans beskou as die toonaangewende sagteware op die gebied van data-integrasie-instrumente. Dit is 'n produk van die Amerikaanse maatskappy Informatica, wat een van die sterkste spelers in ETL (Extract Transform Load), datakwaliteitbestuur, MDM (Master Data Management), ILM (Information Lifecycle Management) en meer is.
Die PowerCenter wat ons gebruik is 'n geïntegreerde Tomcat-toepassingsbediener wat die Informatica-toepassings self laat loop wat sy dienste implementeer:
Domain, in werklikheid is dit die basis vir alles anders, dienste, gebruikers, GRID-komponente werk binne die domein.
Administrateurskonsole, 'n webgebaseerde bestuurs- en moniteringsinstrument, benewens die Informatica-ontwikkelaarkliënt, die hoofinstrument vir interaksie met die produk
MRS, Modelbewaardiens, die metadata-stoor, is 'n laag tussen die basis, waarin metadata fisies gestoor word, en die Informatica-ontwikkelaarkliënt, waarin ontwikkeling aan die gang is. Bewaarplekke stoor beide databeskrywing en ander inligting, insluitend vir 'n aantal ander Informatica-dienste, byvoorbeeld die skedule van werkbekendstellings (skedules) of moniteringsdata, sowel as toepassingsparameterstelle, in die besonder, wat jou toelaat om dieselfde toepassing vir werk met verskillende bronne en ontvangers van data.
DIS, Data-integrasiediens, dit is 'n diens waarin die hoof funksionele prosesse plaasvind, toepassings daarin werk en die werklike bekendstellings van Workflows (beskrywings van die volgorde van kartering en hul interaksie) en Mappings (transformasies, blokke waarin die transformasies self plaasvind, data verwerking) plaasvind.
GRID-konfigurasie - trouens, 'n variant van die bou van 'n kompleks met behulp van verskeie bedieners, wanneer die las wat deur DIS geloods word, tussen die nodusse versprei word (dit wil sê die bedieners wat deel is van die domein). In die geval van hierdie opsie, benewens die verspreiding van die las in DIS deur 'n bykomende GRID-abstraksielaag wat verskeie nodusse kombineer, waarop DIS werk in plaas van om op 'n spesifieke enkele nodus te werk, kan addisionele rugsteun-MRS-instansies ook geskep word. Jy kan selfs hoë beskikbaarheid implementeer, wanneer eksterne oproepe deur rugsteunnodusse gemaak kan word wanneer die hoof een misluk. Ons het tot dusver hierdie opsie verwerp.
Informatica PowerCenter, skematies
In die eerste fases van werk as deel van die dataverskaffingsketting het probleme gereeld ontstaan, sommige van hulle weens die onstabiele werk van Informatica op daardie tydstip. Ek gaan 'n paar van die hoogtepunte van hierdie sage van die bemeestering van Informatica 10 deel.
Voormalige Informatica-logo
Ons verantwoordelikheidsgebied sluit ook ander Informatica-omgewings in, hulle het hul eie besonderhede as gevolg van 'n ander lading, maar vir eers sal ek presies onthou hoe Informatica ontwikkel het as 'n ETL-komponent van die datapakhuis self.
Hoe het dit gebeur
In 2016, toe ons verantwoordelik geword het vir die werk van Informatica, het dit reeds weergawe 10.0 bereik, en vir optimistiese kollegas wat die besluit geneem het om 'n produk met 'n minderjarige weergawe van .0 in 'n ernstige oplossing te gebruik, het alles voor die hand liggend gelyk - jy het nodig om 'n nuwe weergawe te gebruik! Wat hardewarebronne betref, was alles uitstekend op daardie tydstip.
Sedert die lente van 2016 is 'n kontrakteur verantwoordelik vir die werk van Informatica, en volgens die min gebruikers van die stelsel het dit ''n paar keer per week gewerk. Hier is dit nodig om duidelik te maak dat die berging de facto op die PoC-stadium was, daar was geen administrateurs in die span nie, en die stelsel het voortdurend om verskeie redes gedaal, waarna die kontrakteur se ingenieur dit weer geopper het.
In die herfs het drie administrateurs in die span verskyn, wat die verantwoordelikheidsareas onder mekaar verdeel het, en normale werk het begin in lyn met die werking van stelsels in die projek, insluitend Informatica. Afsonderlik moet gesê word dat hierdie produk nie wydverspreid is nie en 'n groot gemeenskap het waarin u die antwoord op enige vrae kan vind en enige probleem kan oplos. Daarom was volwaardige tegniese ondersteuning van die Russiese vennoot Informatica baie belangrik, met behulp waarvan al ons foute en die foute van die destydse jong Informatca 10 reggestel is.
Die eerste ding wat ons vir die ontwikkelaars van ons span en die kontrakteur moes doen, was om die werk van Informatica self te stabiliseer, om die administrasie-webkonsole (Informatica Administrator) operasioneel te maak.
Dit is hoe ons dikwels Informatica-ontwikkelaars ontmoet het
As die proses om die redes uit te vind, uitgelaat word, was die hoofrede vir die ineenstortings die skema van interaksie tussen die Informatica-sagteware en die repository-databasis, wat vanuit die oogpunt van die netwerklandskap op 'n relatief afgeleë bediener geleë was. Dit het tot vertragings gelei en die meganismes wat beheer oor die toestand van die Informatica-domein verseker, ontwrig. Na 'n bietjie aanpassing van die databasis, die verandering van die parameters van Informatica, wat dit meer verdraagsaam gemaak het vir databasisvertragings, en as gevolg van die opdatering van die weergawe van Informatica na 10.1 en die verskuiwing van die databasis van die vorige bediener na 'n bediener wat nader aan Informatica geleë is, die probleem het sy relevansie verloor, en sedertdien was daar ineenstortings van hierdie soort wat ons nie dophou nie.
Een van die pogings om Informatica Monitor te laat werk
Die situasie met die administrasiekonsole was ook kritiek. Aangesien daar 'n aktiewe ontwikkeling reg op 'n voorwaardelik produktiewe omgewing was, moes kollegas voortdurend die werk van kartering, werkvloei "onderweg" ontleed. In die nuwe Informatica het Data Integration Service nie 'n aparte hulpmiddel vir sulke monitering nie, maar die monitering-afdeling (Informatica Administrator Monitor) het in die administrasie-webkonsole verskyn, waarin jy die werking van toepassings, werkvloei en kartering kan monitor, bekendstellings , logs. Van tyd tot tyd het die konsole heeltemal ontoeganklik geword, of inligting oor huidige prosesse in DIS het nie meer opgedateer nie, of foute het voorgekom met die laai van bladsye.
Seleksie van Java-parameters om werk te stabiliseer
Die probleem is op baie maniere opgelos, eksperimente is uitgevoer om die parameters te verander, logs is versamel, jstack, gestuur na ondersteuning, aktiewe google was parallel aan die gang en net waarneming is uitgevoer.
Eerstens is 'n aparte MRS geskep vir monitering, soos later geblyk het, dit is een van die hoofverbruikers van hulpbronne in ons omgewings, aangesien kartering baie intensief van stapel gestuur word. Parameters wat verband hou met java heap en 'n aantal ander is verander.
As gevolg hiervan, met die volgende Informatica 10.1.1-opdatering, kon die konsole en monitor stabiliseer, ontwikkelaars het meer doeltreffend begin werk en gereelde prosesse het al hoe meer gereeld geword.
Die ervaring van interaksie tussen ontwikkeling en administrasie kan interessant wees. Die vraag na 'n gemeenskaplike begrip van hoe alles werk, wat gedoen kan word en nie gedoen kan word nie, is altyd belangrik wanneer komplekse stelsels gebruik word. Daarom kan ons veilig aanbeveel om eers die administrateurspan te leer hoe om sagteware te administreer, en die ontwikkelingspan hoe om kode te skryf en prosesse in die stelsel te teken, en dan eers die eerste en tweede stuur om aan die resultaat te werk. Dit is regtig belangrik wanneer tyd nie 'n oneindige hulpbron is nie. Baie probleme kan selfs opgelos word deur ewekansige opsomming van opsies, maar soms vereis sommige a priori kennis - ons saak bevestig die belangrikheid om hierdie aksioma te verstaan.
Byvoorbeeld, toe ons probeer om weergawes in MRS te aktiveer (soos dit geblyk het, 'n ander weergawe van SVN was nodig), was ons na 'n rukkie geskrik om te vind dat die stelsel herbegin tyd tot 'n paar tien minute toegeneem het. Nadat hulle die rede gevind het vir die beginvertraging en weergawes gedeaktiveer het, het hulle weer goed gevaar.
Van die noemenswaardige struikelblokke wat met Informatica geassosieer word, kan 'n mens die epiese stryd met groeiende java-drade onthou. Op 'n stadium het die tyd aangebreek vir replikasie, dit wil sê om gevestigde prosesse na 'n groot aantal bronstelsels te versprei. Terselfdertyd het dit geblyk dat nie alle prosesse in 10.1.1 goed gewerk het nie, en na 'n ruk het DIS onwerkbaar geword. Tienduisende drade is opgespoor, hul getal het veral merkbaar gegroei tydens die toepassing-ontplooiingsprosedure. Soms moes ek 'n paar keer per dag herbegin om prestasie te herstel.
Hier moet u die ondersteuning bedank, relatief vinnig is die probleme gelokaliseer en reggestel met behulp van EBF (Emergency Bug Fix) - daarna het almal die gevoel gekry dat die instrument regtig werk.
Dit werk steeds!
Teen die tyd dat ons in die teikenmodus begin werk het, het Informatica so gelyk. Informatica-weergawe 10.1.1HF1 (HF1 is HotFix1, 'n verskaffer wat vanaf die EBF-kompleks gebou is) met bykomende EBF geïnstalleer, wat ons probleme met skaal en 'n paar ander oplos, op een bediener uit drie wat deel was van GRID, 20 x86_64-kerne en berging , op 'n groot stadige reeks plaaslike skywe is 'n bedienerkonfigurasie vir 'n Hadoop-groepering. Op 'n ander soortgelyke bediener is daar 'n Oracle DBMS waarmee beide die Informatica-domein en die ETL-beheermeganisme werk. Dit alles word gemonitor deur standaard moniteringsinstrumente wat in die span (Zabbix + Grafana) gebruik word, beide kante - beide Informatica self met sy dienste, en die laaiprosesse wat daarin gaan. Nou is beide die werkverrigting en stabiliteit van werk, sonder om eksterne faktore in ag te neem, nou afhanklik van die instellings wat die las beperk.
Afsonderlik kan ons sê oor GRID. Die omgewing is op drie nodusse gebou, met die moontlikheid van lasbalansering. Daar is egter tydens toetsing gevind dat as gevolg van interaksieprobleme tussen die geloodsde gevalle van ons toepassings, hierdie konfigurasie nie soos verwag gewerk het nie, en daar is besluit om hierdie konstruksieskema tydelik te laat vaar en twee van die drie nodusse uit die domein te verwyder. Terselfdertyd het die skema self dieselfde gebly, en nou is dit 'n GRID-diens, maar ontaard tot een nodus.
Op die oomblik bly die moeilikheid geassosieer met 'n daling in werkverrigting tydens gereelde skoonmaak van die monitorskema - met gelyktydige prosesse wat in die CNN loop en skoonmaak, kan foute in die ETL-beheermeganisme voorkom. Dit word tot dusver opgelos met 'n "kruk" - handmatige skoonmaak van die monitorkring, met die verlies van al sy vorige data. Dit is nie te krities vir produktiwiteit tydens normale gereelde werk nie, maar vir nou is die soektog na 'n normale oplossing aan die gang.
Nog 'n probleem spruit uit dieselfde situasie - soms is daar verskeie bekendstellings van ons beheermeganisme.
Veelvuldige bekendstellings van die toepassing, wat lei tot 'n ineenstorting van die meganisme
Wanneer op 'n skedule begin word in tye van swaar las op die stelsel, kom situasies soms voor wat lei tot 'n ineenstorting van die meganisme. Tot nou toe word die probleem met die hand reggestel, 'n permanente oplossing word gesoek.
Oor die algemeen kan dit opgesom word dat dit onder swaar vrag baie belangrik is om hulpbronne voldoende daarvoor te verskaf, dit geld ook vir hardewarehulpbronne vir Informatica self, en dieselfde vir sy databasisbewaarplek, en ook om optimale instellings daarvoor te verskaf. Daarbenewens bly die vraag oor watter databasisuitleg beter is - op 'n aparte gasheer, of op dieselfde gasheer waar die Informatica-sagteware loop. Aan die een kant sal dit goedkoper wees op een bediener, en wanneer dit gekombineer word, word 'n moontlike probleem met netwerkinteraksie feitlik verwyder, aan die ander kant word die las op die gasheer vanaf die databasis aangevul deur die las van Informatica.
Soos in enige ernstige produk, het Informatica ook 'n paar snaakse oomblikke.
Eenkeer, terwyl ek 'n soort ongeluk ontleed het, het ek opgemerk dat die tyd van gebeure vreemd in die MRS-logboeke aangeteken is.
Temporele dualisme in MRS “by design” logs
Dit het geblyk dat tydstempels in 12-uur-formaat geskryf word, sonder AM / PM, dit wil sê voor middag of daarna. 'n Aansoek is selfs hieroor geopen, en 'n amptelike reaksie is ontvang - dit was bedoel, punte word in die MRS-log in hierdie formaat geskryf. Dit wil sê, soms is daar 'n intrige oor die tyd van die voorkoms van 'n soort FOUT ...
Streef na die beste
Vandag is Informatica 'n redelik stabiele hulpmiddel, gerieflik vir die administrateur en gebruikers, en uiters kragtig in terme van huidige vermoëns en potensiaal. Dit oortref funksioneel ons behoeftes baie keer en word de facto nou in die projek gebruik, nie op die mees kenmerkende en tipiese manier nie. Die probleme hou deels verband met hoe die meganismes werk - die besonderhede is dat in 'n kort tydperk 'n groot aantal drade geloods word wat die parameterstelle intensief opdateer en met die repository databasis werk, terwyl die bediener hardeware hulpbronne byna heeltemal benut word deur die SVE.
Nou is ons naby aan skuif na Informatica 10.2.1 of 10.2.2, waarin sommige interne meganismes herontwerp is, en ondersteuning beloof die afwesigheid van 'n aantal werkverrigting- en funksioneringsprobleme wat ons tans het. En vanuit 'n hardeware-oogpunt word bedieners met die optimale konfigurasie vir ons verwag, gegewe die voorraad vir die nabye toekoms as gevolg van die groei en ontwikkeling van berging.
Natuurlik sal daar toetsing, versoenbaarheidstoetsing en moontlik argitektoniese veranderinge in die HA GRID-deel wees. Ontwikkeling binne Informatica sal voortgaan, want op kort termyn kan ons nie iets lewer om die stelsel te vervang nie.
En diegene wat in die toekoms vir hierdie stelsel verantwoordelik sal wees, sal dit beslis tot die vereiste betroubaarheids- en prestasie-aanwysers wat deur kliënte voorgehou word, kan bring.
Die artikel is voorberei deur die databestuurspan van Rostelecom
Huidige Informatica-logo
Bron: will.com