De ETL-komponint fan it datapakhús wurdt faak oerskaad troch it pakhús sels en krijt minder omtinken as de haaddatabase as front-end-komponint, BI en rapportaazje. Tagelyk, út it eachpunt fan 'e meganika fan it foljen fan it pakhús mei gegevens, spilet ETL in wichtige rol en fereasket net minder omtinken fan behearders as oare komponinten. Myn namme is Alexander, ik administrearje no ETL by Rostelecom, en yn dit artikel sil ik besykje in bytsje te dielen fan wat de behearder fan ien fan 'e meast ferneamde ETL-systemen yn in grut datapakhús by Rostelecom te krijen hat.
As bêste lêzers yn 't algemien al bekend binne mei ús datawarehouse-projekt en mei it Informatica PowerCenter-produkt, dan kinne jo fuortendaliks nei de folgjende seksje gean.
Ferskate jierren lyn, it idee fan ien bedriuw data warehouse matured en begûn te wurde ymplementearre yn Rostelecom. Der wiene al in oantal repositories makke dy't yndividuele problemen oplosten, mar it tal senario's groeide, de stipekosten namen ek ta, en it waard dúdlik dat de takomst yn sintralisaasje lei. Arsjitektoanysk is dit de opslach sels, besteande út ferskate lagen, ymplementearre op Hadoop en GreenPlum, helpdatabases, ETL-meganismen en BI.
Tagelyk, fanwege it grutte oantal geografysk ferspraat, heterogene gegevens boarnen, waard makke in spesjale data upload meganisme, de wurking fan dat wurdt regele troch Informatica. As gefolch, gegevens pakketten einigje yn de Hadoop ynterface gebiet, wêrnei't de prosessen fan it laden fan gegevens troch opslach lagen, Hadoop en GreenPlum begjinne, en se wurde beheard troch de saneamde ETL kontrôle meganisme útfierd yn Informatica. Sa is it Informatica-systeem ien fan 'e wichtige eleminten dy't de wurking fan it pakhús soarget.
Us opslach sil yn mear detail wurde beskreaun yn ien fan 'e folgjende berjochten.
Informatica PowerCenter/Big Data Management wurdt op it stuit beskôge as de liedende software op it mêd fan ark foar gegevensyntegraasje. Dit is in produkt fan it Amerikaanske bedriuw Informatica, dat is ien fan de sterkste spilers yn ETL (Extract Transform Load), data kwaliteit behear, MDM (Master Data Management), ILM (Information Lifecycle Management) en mear.
It PowerCenter dat wy brûke is in yntegreare Tomcat-applikaasjetsjinner wêryn de Informatica-applikaasjes sels rinne, en har tsjinsten ymplementearje:
domein, yn feite, dit is de basis foar al it oare; tsjinsten, brûkers en GRID-komponinten wurkje binnen it domein.
Behearderskonsole, in web-basearre ark foar behear en tafersjoch, neist de Informatica Developer-kliïnt, it wichtichste ark foar ynteraksje mei it produkt
MRS, Model Repository Service, in metadata-repository, is in laach tusken de databank wêryn metadata fysyk opslein wurde en de Informatica Developer-kliïnt wêryn ûntwikkeling plakfynt. Repositories bewarje gegevensbeskriuwings en oare ynformaasje, ynklusyf foar in oantal oare Infromatica-tsjinsten, bygelyks skema's foar it útfieren fan taken (skema's) of tafersjoch op gegevens, lykas ek applikaasjeparameters, benammen, wêrtroch it gebrûk fan deselde applikaasje foar wurk mei ferskate gegevens boarnen en ûntfangers.
DIS, Data Yntegraasje Service, dit is in tsjinst wêryn de wichtichste funksjonele prosessen plakfine, applikaasjes dêryn rinne en de eigentlike lansearringen fan Workflows (beskriuwings fan 'e folchoarder fan mappings en har ynteraksjes) en Mappings (transformaasjes, blokken wêryn't de transformaasjes sels foarkomme, gegevensferwurking ) plakfine.
GRID konfiguraasje - yn wêzen, in opsje foar it bouwen fan in kompleks mei help fan ferskate tsjinners, as de lading lansearre troch DIS wurdt ferdield ûnder de knopen (dat is, tsjinners dy't diel útmeitsje fan it domein). Yn it gefal fan dizze opsje, neist it fersprieden fan de lading yn DIS troch in ekstra GRID abstraksje laach dy't ferieniget ferskate knopen, dêr't DIS rint ynstee fan wurkjen op in spesifike inkele node, ekstra reservekopy MRS eksimplaren kinne ek makke wurde. Jo kinne sels hege beskikberens ymplementearje, wêr't eksterne petearen kinne wurde makke fia reservekopyknooppunten as de wichtichste mislearret. Wy hawwe dizze bou-opsje foar no ferlitten.
Informatica PowerCenter, skematysk
Yn 'e iere stadia fan wurk as ûnderdiel fan' e gegevens supply chain, problemen regelmjittich ûntstien, guon fan harren fanwege de ynstabile wurking fan Informatica op dat stuit. Ik sil guon fan 'e memorabele mominten fan dizze saga diele - mastering Informatica 10.
Eardere Informatica logo
Us ferantwurdlikensgebiet omfettet ek oare Informatica-omjouwings, se hawwe har eigen spesifikaasjes fanwege in oare lading, mar foar no sil ik my krekt ûnthâlde hoe't Informatica ûntwikkele as in ETL-komponint fan it datapakhús sels.
Hoe is dit bard
Yn 2016, doe't wy ferantwurdlik waarden foar it wurk fan Informatica, hie it al ferzje 10.0 berikt, en foar optimistyske kollega's dy't besluten om in produkt te brûken mei in lytse ferzje .0 yn in serieuze oplossing, like alles fanselssprekkend - wy moatte brûke de nije ferzje! Fanút it eachpunt fan hardware-boarnen wie alles yn dy tiid goed.
Sûnt de maitiid fan 2016 is in oannimmer ferantwurdlik foar it wurk fan Informatica, en neffens de pear brûkers fan it systeem, "wurke it in pear kear yn 'e wike." Hjir is it nedich om te ferdúdlikjen dat de repository de facto wie yn 'e PoC-stadium, d'r wiene gjin behearders op it team en it systeem ferûngelokke konstant om ferskate redenen, wêrnei't de yngenieur fan' e oannimmer it wer ophelle.
Yn 'e hjerst kamen trije behearders by it team, ferdield harren gebieten fan ferantwurdlikens ûnder harsels, en normaal wurk begûn te organisearjen de wurking fan systemen yn it projekt, ynklusyf Informatica. Apart moat sein wurde dat dit produkt net wiidferspraat is en in grutte mienskip hat wêryn jo antwurden kinne fine op alle fragen en elk probleem kinne oplosse. Dêrom wie folsleine technyske stipe fan 'e Russyske partner Informatica tige wichtich, mei help fan al ús flaters en flaters fan' e doe jonge Informatica 10 waarden korrizjearre.
It earste ding dat wy moasten dwaan foar de ûntwikkelders fan ús team en de oannimmer wie om it wurk fan Informatica sels te stabilisearjen, om de funksjonaliteit fan 'e webadministraasjekonsole (Informatica Administrator) te garandearjen.
Dit is hoe't wy faaks Informatica-ûntwikkelders moete
Troch it proses fan it finen fan 'e redenen ôf te litten, wie de wichtichste reden foar de crashes it ynteraksjepatroan fan' e Informatica-software mei de repository-database, dy't op in relatyf ôfstân tsjinner lei, út it eachpunt fan it netwurklânskip. Dit soarge foar fertragingen en fersteurde de meganismen dy't de steat fan it Informatica-domein kontrolearje. Nei wat tuning fan 'e databank, it feroarjen fan de parameters fan Informatica, wat it tolerant makke foar databankfertragingen, en úteinlik it bywurkjen fan de Informatica-ferzje nei 10.1 en it oerbringen fan de databank fan 'e foarige tsjinner nei in tsjinner tichter by Informatica, it probleem ferlear syn relevânsje, en sûnt dy tiid hawwe der crashes fan dit soarte wy net observearje.
Ien fan 'e besykjen om Informatica Monitor te wurkjen
De situaasje mei de administraasjekonsole wie ek kritysk. Sûnt aktive ûntwikkeling direkt op 'e relatyf produktive omjouwing wie, moasten kollega's konstant it wurk fan mappings en workflow "ûnderweis" analysearje. Yn de nije Informatica hat de Data Integration Service gjin apart ark foar sa'n tafersjoch, mar in tafersjochseksje is ferskynd yn 'e administraasjewebkonsole (Informatica Administrator Monitor), wêryn jo de wurking fan applikaasjes, workflow en mappings kinne kontrolearje, lansearret, logs. Periodyk waard de konsole folslein net beskikber, of ynformaasje oer aktuele prosessen yn DIS stoppe mei it bywurkjen, of flaters binne bard by it laden fan siden.
Seleksje fan Java-parameters om operaasje te stabilisearjen
It probleem waard op in protte manieren korrizjearre, eksperiminten waarden útfierd om parameters te feroarjen, logs en jstack waarden sammele, stjoerd nei stipe, tagelyk wie d'r aktyf googling en gewoan observaasje.
Alderearst waard in aparte MRS makke foar tafersjoch; sa't letter bliken die, is dit ien fan 'e wichtichste konsuminten fan boarnen yn ús omjouwing, om't kaarten tige yntinsyf wurde lansearre. Parameters oangeande java heap en in oantal oaren binne feroare.
As gefolch, troch de folgjende update Informatica 10.1.1, de wurking fan 'e konsole en monitor waard stabilisearre, ûntwikkelers begûn te wurkjen effisjinter, en reguliere prosessen wurden mear en mear reguliere.
De ûnderfining fan ynteraksje tusken ûntwikkeling en administraasje kin ynteressant wêze. De kwestje fan in algemien begryp fan hoe't dingen wurkje, wat kin dien wurde en wat kin net dien wurde, is altyd wichtich by it brûken fan komplekse systemen. Dêrom kinne wy feilich oanbefelje dat jo earst it bestjoerlike team opliede oer hoe't jo de software beheare, en it ûntwikkelteam oer hoe't jo koade skriuwe en prosessen yn it systeem tekenje, en allinich dan de earste en twadde stjoere om oan it resultaat te wurkjen. Dit is echt wichtich as tiid gjin ûneinige boarne is. In protte problemen kinne wurde oplost sels troch in willekeurige sykjen fan opsjes, mar soms fereaskje guon a priori kennis - ús gefal befêstiget it belang fan it begripen fan dit axioma.
Bygelyks, doe't wy besochten ferzjeferzje yn MRS yn te skeakeljen (sa't it úteinlik die bliken, wie in oare ferzje fan SVN nedich), nei in skoft wiene wy alarm om te ûntdekken dat de systeem opnij starte tiid ta ferskate tsientallen minuten tanommen. Nei't wy de reden fûn hawwe foar de fertraging yn 'e start en it útskeakeljen fan ferzjeferzje, diene wy it wer goed.
Opmerklike obstakels ferbûn mei Informatica omfetsje de epyske striid mei groeiende java-threads. Op in stuit is de tiid kommen foar replikaasje, dat is, om de fêststelde prosessen út te wreidzjen nei in grut oantal boarnesystemen. It die bliken dat net alle prosessen yn 10.1.1 goed wurke, en nei ferrin fan tiid waard DIS net te wurkjen. Tsientûzenen triedden waarden ûntdutsen, har oantal groeide foaral merkber tidens de applikaasje-ynsetproseduere. Soms moast ik ferskate kearen deis opnij starte om funksjonaliteit te herstellen.
Hjir moatte wy de stipe betankje; de problemen waarden lokalisearre en relatyf fluch repareare mei EBF (Emergency Bug Fix) - dêrnei krige elkenien it gefoel dat it ark echt wurket.
It wurket noch!
Tsjin de tiid dat wy yn doelmodus begon te wurkjen, seach Informatica der sa út. Ferzje fan Informatica 10.1.1HF1 (HF1 is HotFix1, in ferkeaper-assemblage út in kompleks fan EBF's) mei ekstra ynstalleare EBF, dy't ús problemen mei skaalfergrutting en guon oaren korrigearret, op ien tsjinner fan trije dy't diel útmakken fan GRID, 20 x86_64-kearnen en opslach, op in enoarme trage array fan lokale skiven - dit is de serverkonfiguraasje foar in Hadoop-kluster. Op in oare ferlykbere server - de Oracle DBMS wêrmei sawol it Informatica-domein as it ETL-kontrôlemeganisme wurkje. Dit alles wurdt kontrolearre troch standert tafersjoch ark brûkt yn it team (Zabbix + Grafana) oan beide kanten - Informatica sels mei har tsjinsten, en de laden prosessen dy't deryn geane. No binne sawol prestaasjes as stabiliteit, sûnder rekken hâlden mei eksterne faktoaren, no ôfhinklik fan 'e ynstellingen dy't de lading beheine.
Apart kinne wy sizze oer GRID. De omjouwing waard boud op trije knopen, mei de mooglikheid fan load balancing. Tidens testen waard it lykwols ûntdutsen dat troch ynteraksjeproblemen tusken de rinnende eksimplaren fan ús applikaasjes, dizze konfiguraasje net wurke lykas ferwachte, en se besleaten dit konstruksjeskema tydlik te ferlitten, twa fan 'e trije knopen fan it domein te ferwiderjen. Tagelyk is it skema sels itselde bleaun, en no is it krekt in GRID-tsjinst, mar degenerearre ta ien knooppunt.
Op it stuit bliuwt de swierrichheid ferbûn mei in drop yn prestaasjes by it regelmjittich skjinmeitsjen fan it monitorsirkwy - mei simultane prosessen yn 'e CNN en rinnende skjinmeitsjen kinne storingen yn' e wurking fan it ETL-kontrôlemeganisme foarkomme. Dit wurdt op it stuit oplost "as in kruk" - troch it manuell wiskjen fan it monitorsirkwy, mei it ferlies fan al syn foarige gegevens. Dit is net te kritysk foar produktiviteit, by normale routine operaasje, mar foar no is in syktocht nei in normale oplossing oan 'e gong.
In oar probleem ûntstiet út deselde situaasje - soms komme meardere lansearringen fan ús kontrôlemeganisme foar.
Meardere applikaasje lanseart dy't liedt ta meganismefout
By it rinnen neffens in skema, yn tiden fan swiere lêst op it systeem, komme soms situaasjes foar dy't liede ta ôfbraak fan it meganisme. It probleem wurdt noch mei de hân reparearre, en in permaninte oplossing wurdt socht.
Yn 't algemien kinne wy gearfetsje dat as d'r in swiere lading is, it heul wichtich is om middels dy't adekwaat binne te leverjen, dit jildt ek foar hardware-boarnen foar Informatica sels, en itselde foar har databankrepository, en ek om optimale ynstellings te leverjen foar harren. Derneist bliuwt de fraach iepen hokker databank pleatsingskema better is - op in aparte host, of op deselde wêr't de Informatica-software rint. Oan 'e iene kant sil it goedkeaper wêze op ien server, en yn kombinaasje wurdt it mooglike probleem mei netwurkynteraksje praktysk elimineare; oan' e oare kant wurdt de lading op 'e host fan' e database oanfolle troch de lading fan Informatica.
Lykas by elk serieus produkt hat Informatica ek grappige mominten.
Ienris, by it sortearjen fan in soarte fan ûngelok, fernaam ik dat de MRS-logboeken de tiid fan 'e barrens nuver oanjûn.
Tydlik dualisme yn MRS-logboeken "by design"
It die bliken dat tiid stimpels wurde skreaun yn 12 oeren opmaak, sûnder oantsjutte AM / PM, dat is, foar de middei of nei. Oangeande dizze saak waard sels in applikaasje iepene, en in offisjele antwurd waard ûntfongen - dit is hoe't it wie bedoeld, markearrings wurde skreaun yn it MRS-logboek yn krekt dit formaat. Dat is, soms bliuwt d'r wat yntriges oer de tiid fan it foarkommen fan wat FOUT ...
Stribje foar it bêste
Tsjintwurdich is Informatica in frij stabyl ark, handich foar behearders en brûkers, ekstreem krêftich yn termen fan har hjoeddeistige mooglikheden en potensjeel. It grutter ús funksjonele behoeften in protte kearen en de facto wurdt no brûkt yn it projekt op in manier dy't net de meast typyske en typyske is. De swierrichheden binne foar in part te krijen mei de manier wêrop de meganismen wurkje - it spesifike ding is dat yn in koarte perioade fan tiid in grut oantal triedden wurde lansearre dy't parameters yntinsyf bywurkje en wurkje mei de repository-database, wylst de tsjinner hardware-boarnen hast folslein brûkt wurde troch de CPU.
Wy binne no ticht by it ferpleatsen nei Informatica 10.2.1 of 10.2.2, dy't guon fan 'e ynterne meganismen en stipebeloften hawwe omwurke om guon fan' e prestaasjes en funksjonaliteitproblemen te eliminearjen dy't wy no hawwe. En út in hardware eachpunt ferwachtsje wy servers mei in optimale konfiguraasje foar ús, rekken hâldend mei de reserve foar de heine takomst troch de groei en ûntwikkeling fan opslach.
Fansels sille d'r testen, kompatibiliteitskontrôle, en mooglik arsjitektoanyske feroarings wêze yn it HA GRID-diel. De ûntwikkeling binnen Informatica sil trochgean, om't wy op koarte termyn neat kinne leverje om it systeem te ferfangen.
En dejingen dy't ferantwurdlik wêze sille foar dit systeem yn 'e takomst, sille perfoarst by steat wêze om te bringen it nei de fereaske betrouberens en prestaasjes yndikatoaren foarsteld troch klanten.
It artikel waard taret troch it Rostelecom data management team
Aktuele Informatica logo
Boarne: www.habr.com