ETL-komponenten i datalageret forbliver ofte i skyggen af selve lageret og får mindre opmærksomhed end den primære database eller frontend-komponenten, BI og rapportering. Set fra et mekanisk perspektiv i forhold til at fylde lageret med data, spiller ETL en nøglerolle og kræver ikke mindre opmærksomhed fra administratorerne end de øvrige komponenter. Jeg hedder Alexander, og jeg administrerer ETL i Rostelecom, og i denne artikel vil jeg forsøge at dele lidt af det, som en administrator for et af de mest kendte ETL-systemer i et stort datalager hos Rostelecom står overfor.
Hvis de ærede læsere allerede er bekendt med vores datalagerprojekt og produktet Informatica PowerCenter, kan de straks gå videre til næste afsnit.
For flere år siden modnedes idéen om et samlet virksomhedsdatalager i Rostelecom og blev realiseret. En række lagre, der løste forskellige opgaver, var allerede blevet oprettet, men antallet af scenarier voksede, omkostningerne til vedligeholdelse steg også, og det blev klart, at fremtiden lå i centralisering. Arkitektonisk set er dette selve lageret, der består af flere lag, implementeret på Hadoop og GreenPlum, hjælpe-databaser, ETL mekanismer og BI.
Som et resultat af det store antal territorielt distribuerede, heterogene datakilder blev der oprettet en speciel mekanisme til dataudtræk, hvis arbejde styres af Informatica. Som følge heraf havner datapaketterne i det grænsefladeområde, der tilhører Hadoop, hvorefter processerne til indlæsning af data gennem lagene i lageret begynder, i Hadoop og GreenPlum, og de styres af den såkaldte styringsmekanisme ETL, der er implementeret i Informatica. Således er Informatica-systemet en af de nøgleelementer, der sikrer driften af lageret.
Mere detaljeret om vores datalager vil blive fortalt i et af de følgende indlæg.
Informatica PowerCenter/Big Data Management betragtes i øjeblikket som den førende software inden for dataintegrationsværktøjer. Dette er et produkt fra det amerikanske firma Informatica, som er en af de stærkeste aktører inden for ETL (Extract Transform Load), datakvalitetsstyring, MDM (Master Data Management), ILM (Information Lifecycle Management) og mere.
Den PowerCenter, vi bruger, er en integreret applikationsserver Tomcat, hvor Informatica-applikationer kører og implementerer dens tjenester:
Domæne, dette er i bund og grund fundamentet for alt andet, tjenester, brugere og GRID-komponenter fungerer inden for domænet.
Administrator Console, et web-baseret administrations- og overvågningsværktøj, udover Informatica Developer-klienten, det primære værktøj til interaktion med produktet.
MRS, Model Repository Service, en metadata-lager, fungerer som et lag mellem databasen, hvor metadataene fysisk opbevares, og Informatica Developer-klienten, hvor udviklingen foregår. Repositories gemmer både data beskrivelser og anden information, herunder til en række andre Informatica-tjenester, for eksempel tidsplaner for jobplanlægning (Schedules) eller overvågningsdata, samt parametersæt for applikationerne, der tillader brug af den samme applikation til at arbejde med forskellige datakilder og -modtagere.
DIS, Data Integration Service, det er tjenesten, hvor de grundlæggende funktionelle processer finder sted, applikationer kører, og arbejdsteder (Workflows, beskrivelser af rækkefølgen af mappinger og deres interaktion) og mappinger (transformationer, blokke, hvor selve konverteringerne og databehandlingen finder sted) kører.
GRID-konfiguration – i bund og grund en mulighed for at opbygge et kompleks med flere servere, hvor belastningen, der genereres af DIS, fordeles på noder (dvs. servere, der indgår i domænet). I dette scenarie, udover belastningsfordelingen i DIS gennem et ekstra abstraktionslag GRID, der samler flere noder, hvor DIS fungerer i stedet for at arbejde på en enkelt node, kan der også oprettes ekstra backup-eksemplarer af MRS. Der kan endda implementeres høj tilgængelighed, når eksterne anmodninger kan foretages gennem backup-noder i tilfælde af fejl på den primære. Vi har dog indtil videre afvist denne opbygningsmulighed.
Informatica PowerCenter, illustrativt
I de tidlige faser af arbejdet i dataforsyningskæden opstod der regelmæssigt problemer, nogle på grund af den ustabile drift af Informatica på det tidspunkt. Jeg vil dele nogle af de mindeværdige øjeblikke fra denne saga – at lære Informatica 10.
Den tidligere logo for Informatica
Vores ansvarsområde omfatter også andre Informatica-miljøer, som har deres egen specifik, på grund af en anden belastning, men jeg vil huske på, hvordan Informatica udviklede sig som ETL-komponenten i datalageret.
Hvordan skete det?
I 2016, da vi begyndte at have ansvar for Informatica, var den allerede nået til version 10.0, og for kolleger med optimistiske synspunkter, der tog beslutningen om at anvende produktet i et seriøst projekt med en mindre version .0, syntes det alt sammen åbenlyst — vi skulle selvfølgelig bruge den nye version! På den hardwaremæssige side var alt på det tidspunkt i orden.
Fra foråret 2016 var det en underleverandør, der havde ansvaret for Informatica, og ifølge de få brugere af systemet 'arbejdede den et par gange om ugen'. Her skal det bemærkes, at datalageret de facto var på PoC-fasen, der var ingen administratorer i teamet, og systemet faldt konstant af forskellige årsager, hvorefter underleverandørens ingeniør genstartede det.
I efteråret kom der tre administratorer ind i teamet, som delte ansvarsområderne imellem sig, og der begyndte at blive etableret normal drift af systemerne i projektet, herunder Informatica. Det skal nævnes, at dette produkt ikke er særligt udbredt og har ikke et stort fællesskab, hvor man kan finde svar på spørgsmål eller løse problemer. Derfor var det meget vigtigt at få fuld teknisk support fra vores russiske Informatica-partner, som hjalp os med at rette alle vores fejl og også fejlene i det dengang stadig unge Informatica 10.
Det første, vi måtte gøre for udviklerne i vores team og underleverandøren — stabilisere selve Informatica, få webadministrationskonsollen (Informatica Administrator) til at fungere.
Således mødte vi ofte udviklerne af Informatica.
Uden at gå ind i selve processen med at finde årsagerne, var den primære årsag til nedbruddene interaktionen mellem Informatica-softwaren og databasen i depotet, som var placeret på en relativt fjern server, set i forhold til netværkslandskabet. Dette førte til forsinkelser og forstyrrede funktionerne, der sikrede kontrol over domænet Informatica. Efter en del tuning af databasen, ændringer i Informatica-parametrene, der gjorde den mere tolerant over for databaseforsinkelser, og til sidst opdatering af versionen af Informatica til 10.1 samt flytning af databasen fra den tidligere server til en server tættere på Informatica, mistede problemet sin relevans, og siden da har vi ikke observeret nedbrud af denne art.
Et af de forsøg, der blev gjort for at få Informatica Monitor til at fungere
Situationen med administrationskonsollen var også kritisk. Da der blev arbejdet aktivt på det betingede produktionsmiljø, var det konstant nødvendigt for kollegerne at analysere arbejdet med mappings og workflows "undervejs". I den nye Informatica, i Data Integration Service, er der ikke et særskilt værktøj til denne monitorering, men i webadministrationskonsollen er der kommet en overvågningssektion (Informatica Administrator Monitor), hvor man kan se applikationernes arbejde, workflows og mappings, kørsel, logfiler. Periodisk blev konsollen helt utilgængelig, eller oplysningerne om de aktuelle processer i DIS stoppede med at opdatere, eller der opstod fejl ved indlæsning af sider.
Justering af java-parametre for at stabilisere driften
Fejlretning skete på mange måder; der blev udført eksperimenter med ændring af parametre, logger blev indsamlet, jstack blev sendt til support, samtidig var der aktiv googling og simpelthen observation.
Først blev der oprettet et separat MRS til overvågning, som det senere viste sig, var en af de vigtigste forbrugere af ressourcer i vores miljøer, da kørsel af mappings skete meget intensivt. Der blev ændret parametre vedrørende java heap og en række andre.
Som følge heraf lykkedes det at stabilisere driften af konsollen og monitoren til den næste opdatering af Informatica 10.1.1, udviklerne blev mere effektive, og de regelmæssige processer blev mere og mere regelmæssige.
En interessant erfaring kan være interaktionen mellem udvikling og administration. Spørgsmålet om fælles forståelse af, hvordan alting fungerer, hvad man kan gøre, og hvad man ikke kan, er altid vigtigt, når man arbejder med komplekse systemer. Derfor kan det varmt anbefales først at træne administratorgruppen i, hvordan softwaren skal administreres, og udviklerne i, hvordan man skal skrive kode og designe processer i systemet, og først derefter lade de første og de sidste arbejde hen imod resultatet. Dette er virkelig vigtigt, når tiden ikke er en ubegribelig ressource. Mange problemer kan løses selv ved tilfældig afprøvning af muligheder, men nogle gange kræver visse problemer a priori viden — vores tilfælde bekræfter vigtigheden af denne akseoma.
For eksempel, da vi forsøgte at aktivere versionsstyring i MRS (som det til sidst viste sig, var vi nødt til at have en anden version af SVN), opdagede vi med bekymring, at systemets genstartstid var steget til flere titusinde minutter. Da vi fandt årsagen til forsinkelsen i opstarten og deaktiverede versionsstyring, gik det godt igen.
Blandt de mærkbare forhindringer forbundet med Informatica kan det episke slag med de voksende java-tråde nævnes. På et tidspunkt kom tiden til udbredelse, dvs. at udvide de etablerede processer til et stort antal kildesystemer. Det viste sig, at langt fra alle processer i 10.1.1 fungerede godt, og efter noget tid blev DIS uarbejdsdygtig. Der blev opdaget titusinder af tråde, og antallet voksede især mærkbart under applikationsudrulningsproceduren. Nogle gange måtte man genstarte flere gange om dagen for at genskabe funktionaliteten.
Her skal der ydes tak til supporten, da problemerne relativt hurtigt blev lokaliseret og løst ved hjælp af EBF (Emergency Bug Fix) – efter dette havde alle fornemmelsen af, at værktøjet faktisk fungerer.
Det virker trods alt!
Ved begyndelsen af arbejdet i måltilstand så Informatica således ud. Version Informatica 10.1.1HF1 (HF1 er HotFix1, en vendor-specifik version fra EBF-pakken) med yderligere installierede EBF'er, der løste vores skaleringsproblemer og nogle andre, på én server ud af tre, som var en del af GRID, 20 kerner x86_64 og lagring på en stor, langsom mængde lokale diske — det var serverkonfiguration for a Hadoop cluster. On another similar server — Oracle DB, which is used with the Informatica domain and the ETL management mechanism. All this is monitored by the standard monitoring tools used by the team (Zabbix + Grafana), from two sides — both Informatica itself with its services and the processes loading into it. Currently, both performance and stability, excluding external factors, depend on the settings that limit the load.
Separately, we can mention GRID. The environment was built on three nodes, with the ability to load balance. However, during testing, it was discovered that due to interaction problems between the running instances of our applications, this configuration did not work as expected, and we temporarily decided to abandon this construction scheme, removing two of the three nodes from the domain. The scheme itself remained the same, and it is now indeed a GRID service, but degenerated to one node.
Right now, there is still a difficulty related to performance drops during regular cleaning of the monitoring scheme — during simultaneous running processes in the ETL and the active cleaning, failures in the ETL management mechanism may occur. This is currently addressed in a "quick fix" manner — manual cleaning of the monitoring scheme, resulting in the loss of all its previous data. This is not too critical for production under normal operation, but the search for a proper solution is still ongoing.
From this situation arises another problem — there are times when multiple launches of our management mechanism occur.
Multiple application launches leading to the mechanism's failure
When scheduled tasks run during high system load, situations can arise that lead to the mechanism's failure. The problem is still resolved manually, and a permanent solution is being sought.
Generelt set kan man konkludere, at det ved stor belastning er meget vigtigt at levere passende ressourcer, hvilket gælder både hardware-ressourcerne til selve Informatica, og det samme for dens database-repositorium, samt at sikre optimale indstillinger for dem. Desuden forbliver spørgsmålet åbent om, hvilken databaseplacering der er bedst — på en separat host eller på den samme, hvor Informatica-software kører. På den ene side vil det være billigere at have det på én server, og ved at kombinere dem fjernes stort set den mulige problematik med netværksinteraktion, på den anden side tilføjes belastningen fra databasen til belastningen fra Informatica.
Som i ethvert seriøst produkt er der også kuriøse øjeblikke i Informatica.
En gang, da jeg analyserede en form for nedbrud, bemærkede jeg, at tiden for begivenhederne var mærket underligt i MRS-loggene.
Den tidslige dualisme i MRS-loggene 'by design'
Det viste sig, at tidsstemplerne skrives i 12-timersformat uden angivelse af AM/PM, så det er enten før eller efter middag. Der blev endda åbnet en sag om dette, og der blev givet et officielt svar — det var sådan, det var tænkt, i MRS-loggen skrives stempler netop i dette format. Det betyder, at der nogle gange er en vis spænding med hensyn til tidspunktet for opståen af en hvilken som helst ERROR…
Stræbe efter forbedring
I dag er Informatica et relativt stabilt værktøj, der er brugervenligt for administratorer og brugere, og meget kraftfuldt med hensyn til de nuværende muligheder og potentiale. Det overstiger funktionelt mange gange vores behov og bruges de facto i projektet på en ikke helt typisk måde. Udfordringerne er delvist forbundet med, hvordan mekanismerne fungerer — specifikationen er, at et stort antal tråde startes på kort tid, som intensivt opdaterer parameterset'ene og arbejder med databasen, samtidig med at serverens hardware-ressourcer næsten fuldt ud udnyttes af CPU'en.
Vi er nu tæt på overgangen til Informatica 10.2.1 eller 10.2.2, hvor nogle interne mekanismer er blevet omarbejdet, og supporten lover, at en række nuværende problemer med ydeevne og funktionalitet vil forsvinde. Desuden forventes der, ud fra et hardware-perspektiv, servere i en optimal konfiguration for os, i betragtning af den kapacitet, vi har brug for på kort sigt i forbindelse med væksten og udviklingen af lageret.
Selvfølgelig er der behov for testning, kompatibilitetskontrol, og muligvis arkitektoniske ændringer i forhold til HA GRID. Udviklingen inden for Informatica vil fortsætte, da vi i den kortsigtede fremtid ikke kan erstatte systemet.
Og dem, der i fremtiden skal stå for dette system, vil uden tvivl lykkes med at opnå de nødvendige pålideligheds- og ydeevnekrav, som kunderne stiller.
Artiklen er forberedt af datahåndteringsholdet hos «Ростелеком»
Det aktuelle Informatica-logo
Kilde: habr.com
