ETL-komponenten i datavarehuset overskygges ofte af selve lageret og får mindre opmærksomhed end hoveddatabasen eller front-end-komponenten, BI og rapportering. Samtidig spiller ETL en nøglerolle, set ud fra mekanikken til at fylde lageret med data, og kræver ikke mindre opmærksomhed fra administratorer end andre komponenter. Mit navn er Alexander, jeg administrerer nu ETL hos Rostelecom, og i denne artikel vil jeg forsøge at dele lidt af, hvad administratoren af et af de mest kendte ETL-systemer i et stort datavarehus hos Rostelecom skal forholde sig til.
Hvis kære læsere allerede er bekendt generelt med vores data warehouse-projekt og med Informatica PowerCenter-produktet, så kan du straks gå videre til næste afsnit.
For flere år siden modnedes ideen om et enkelt virksomhedsdatavarehus og begyndte at blive implementeret i Rostelecom. Der var allerede oprettet en række repositories, der løste individuelle problemer, men antallet af scenarier voksede, supportomkostningerne steg også, og det blev klart, at fremtiden lå i centralisering. Arkitektonisk er dette selve lageret, bestående af flere lag, implementeret på Hadoop og GreenPlum, hjælpedatabaser, ETL-mekanismer og BI.
På samme tid blev der på grund af det store antal geografisk fordelte, heterogene datakilder skabt en særlig datauploadmekanisme, hvis drift styres af Informatica. Som følge heraf ender datapakker i Hadoop-grænsefladeområdet, hvorefter processerne med at indlæse data gennem lagerlag, Hadoop og GreenPlum begynder, og de styres af den såkaldte ETL-kontrolmekanisme implementeret i Informatica. Dermed er Informatica-systemet et af nøgleelementerne, der sikrer driften af lageret.
Vores opbevaring vil blive beskrevet mere detaljeret 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) med mere.
Det PowerCenter, vi bruger, er en integreret Tomcat-applikationsserver, hvori Informatica-applikationerne selv kører og implementerer dens tjenester:
Domæne, faktisk er dette grundlaget for alt andet; tjenester, brugere og GRID-komponenter opererer inden for domænet.
Administratorkonsol, et webbaseret administrations- og overvågningsværktøj, udover Informatica Developer-klienten, det vigtigste værktøj til at interagere med produktet
MRS, Model Repository Service, et metadatalager, er et lag mellem databasen, hvori metadata er fysisk lagret, og Informatica Developer-klienten, hvori udviklingen finder sted. Lagre gemmer databeskrivelser og anden information, herunder for en række andre Infromatica-tjenester, for eksempel tidsplaner for at køre opgaver (Schedules) eller overvågningsdata, samt applikationsparametre, som især tillader brugen af den samme applikation til arbejde med forskellige datakilder og modtagere.
DIS, Dataintegrationstjeneste, dette er en tjeneste, hvor de vigtigste funktionelle processer finder sted, applikationer kører i den og de faktiske lanceringer af Workflows (beskrivelser af sekvensen af kortlægninger og deres interaktioner) og Mappings (transformationer, blokke, hvori selve transformationerne forekommer, databehandling ) finde sted.
GRID-konfiguration – i det væsentlige en mulighed for at bygge et kompleks ved hjælp af flere servere, når belastningen lanceret af DIS er fordelt mellem noderne (det vil sige servere, der er en del af domænet). I tilfælde af denne mulighed, udover at fordele belastningen i DIS gennem et ekstra GRID-abstraktionslag, der forener flere noder, som DIS kører på i stedet for at arbejde på en specifik enkelt node, kan der også oprettes yderligere backup MRS-instanser. Du kan endda implementere høj tilgængelighed, hvor eksterne opkald kan foretages gennem backup noder, hvis den vigtigste fejler. Vi har opgivet denne byggemulighed for nu.
Informatica PowerCenter, skematisk
I de tidlige stadier af arbejdet som en del af dataforsyningskæden opstod der jævnligt problemer, nogle af dem på grund af den ustabile drift af Informatica på det tidspunkt. Jeg vil dele nogle af de mindeværdige øjeblikke i denne saga - at mestre Informatica 10.
Tidligere Informatica-logo
Vores ansvarsområde omfatter også andre Informatica-miljøer, de har deres egne detaljer på grund af en anden belastning, men indtil videre vil jeg huske præcis, hvordan Informatica udviklede sig som en ETL-komponent af selve datavarehuset.
Hvordan skete dette
I 2016, da vi blev ansvarlige for arbejdet i Informatica, var det allerede nået til version 10.0, og for optimistiske kolleger, der besluttede at bruge et produkt med en mindre version .0 i en seriøs løsning, virkede alt indlysende - vi skal bruge den nye version! Ud fra hardwareressourcernes synspunkt var alt fint på det tidspunkt.
Siden foråret 2016 har en entreprenør været ansvarlig for arbejdet i Informatica, og ifølge de få brugere af systemet "fungerede det et par gange om ugen." Her er det nødvendigt at præcisere, at depotet de facto var på PoC-stadiet, der var ingen administratorer på holdet, og systemet styrtede konstant ned af forskellige årsager, hvorefter entreprenørens ingeniør samlede det op igen.
I efteråret sluttede tre administratorer sig til teamet, som delte deres ansvarsområder indbyrdes, og det normale arbejde begyndte med at organisere driften af systemer i projektet, herunder Informatica. Separat skal det siges, at dette produkt ikke er udbredt og har et stort fællesskab, hvor du kan finde svar på eventuelle spørgsmål og løse ethvert problem. Derfor var fuld teknisk support fra den russiske partner Informatica meget vigtig, ved hjælp af hvilken alle vores fejl og fejl fra den dengang unge Informatica 10 blev rettet.
Det første, vi skulle gøre for udviklerne af vores team og entreprenøren, var at stabilisere selve Informaticas arbejde for at sikre funktionaliteten af webadministrationskonsollen (Informatica Administrator).
Sådan mødte vi ofte Informatica-udviklere
Ser man bort fra processen med at finde ud af årsagerne, var hovedårsagen til nedbruddene Informatica-softwarens interaktionsmønster med lagerdatabasen, som var placeret på en relativt fjern server set fra netværkslandskabets synspunkt. Dette forårsagede forsinkelser og forstyrrede mekanismerne, der overvåger Informatica-domænets tilstand. Efter lidt justering af databasen, ændring af parametrene for Informatica, hvilket gjorde den mere tolerant over for databaseforsinkelser, og til sidst opdatering af Informatica-versionen til 10.1 og overførsel af databasen fra den tidligere server til en server, der var placeret tættere på Informatica, mistede problemet sin relevans, og siden da har der været nedbrud af denne art, vi ikke observerer.
Et af forsøgene på at få Informatica Monitor til at virke
Situationen med administrationskonsollen var også kritisk. Da aktiv udvikling var i gang direkte på det relativt produktive miljø, havde kollegerne konstant brug for at analysere arbejdet med kortlægninger og arbejdsgange "på farten." I den nye Informatica har Data Integration Service ikke et separat værktøj til sådan overvågning, men der er dukket en overvågningssektion op i administrationens webkonsol (Informatica Administrator Monitor), hvori man kan overvåge driften af applikationer, workflow og kortlægninger, lanceringer, logger. Periodisk blev konsollen fuldstændig utilgængelig, eller information om aktuelle processer i DIS holdt op med at opdatere, eller der opstod fejl under indlæsning af sider.
Valg af java-parametre for at stabilisere ydeevnen
Problemet blev rettet på mange måder, eksperimenter blev udført for at ændre parametre, logs og jstack blev indsamlet, sendt til support, samtidig var der aktiv google og blot observation.
Først og fremmest blev der oprettet en separat MRS til overvågning; som det viste sig senere, er dette en af de vigtigste forbrugere af ressourcer i vores miljøer, da kortlægninger lanceres meget intensivt. Parametre vedrørende java heap og en række andre er blevet ændret.
Som et resultat, ved den næste opdatering af Informatica 10.1.1, blev driften af konsollen og skærmen stabiliseret, udviklere begyndte at arbejde mere effektivt, og regelmæssige processer blev mere og mere regelmæssige.
Oplevelsen af samspil mellem udvikling og administration kan være interessant. Spørgsmålet om en generel forståelse af, hvordan ting fungerer, hvad der kan gøres og hvad der ikke kan gøres, er altid vigtigt, når man bruger komplekse systemer. Derfor kan vi roligt anbefale, at du først træner det administrative team i, hvordan man administrerer softwaren, og udviklingsteamet i, hvordan man skriver kode og tegner processer i systemet, og først derefter sender den første og anden til at arbejde videre med resultatet. Dette er virkelig vigtigt, når tiden ikke er en uendelig ressource. Mange problemer kan løses selv ved en tilfældig søgning af muligheder, men nogle gange kræver nogle a priori viden - vores sag bekræfter vigtigheden af at forstå dette aksiom.
For eksempel, da vi forsøgte at aktivere versionering i MRS (som det viste sig i sidste ende, var der brug for en anden version af SVN), efter nogen tid blev vi alarmeret over at opdage, at systemets genstarts tid var steget til flere ti minutter. Efter at have fundet årsagen til forsinkelsen i starten og deaktivering af versionering, klarede vi os igen godt.
Bemærkelsesværdige forhindringer forbundet med Informatica inkluderer den episke kamp med voksende java-tråde. På et tidspunkt er tiden kommet til replikering, det vil sige at udvide de etablerede processer til et stort antal kildesystemer. Det viste sig, at ikke alle processer i 10.1.1 fungerede godt, og efter nogen tid blev DIS ubrugelig. Titusindvis af tråde blev opdaget, og deres antal voksede især mærkbart under applikationsimplementeringsproceduren. Nogle gange var jeg nødt til at genstarte flere gange om dagen for at genoprette funktionaliteten.
Her skal vi takke supporten, problemerne blev lokaliseret og løst relativt hurtigt ved hjælp af EBF (Emergency Bug Fix) - herefter fik alle en fornemmelse af, at værktøjet virkelig virker.
Det virker stadig!
Da vi begyndte at arbejde i måltilstand, så Informatica sådan ud. Version af Informatica 10.1.1HF1 (HF1 er HotFix1, en leverandørsamling fra et kompleks af EBF'er) med yderligere installeret EBF, som korrigerer vores problemer med skalering og nogle andre, på en server ud af tre, der var en del af GRID, 20 x86_64 kerner og lagring på en enorm langsom række lokale diske - dette er serverkonfigurationen for en Hadoop-klynge. På en anden lignende server - Oracle DBMS, som både Informatica-domænet og ETL-kontrolmekanismen arbejder med. Alt dette overvåges af standardovervågningsværktøjer, der bruges i teamet (Zabbix + Grafana) på begge sider - Informatica selv med dets tjenester og indlæsningsprocesserne, der går ind i det. Nu afhænger både ydeevne og stabilitet, uden at tage hensyn til eksterne faktorer, nu af de indstillinger, der begrænser belastningen.
Separat kan vi sige om GRID. Miljøet blev bygget på tre noder, med mulighed for belastningsbalancering. Men under test blev det opdaget, at på grund af interaktionsproblemer mellem de kørende forekomster af vores applikationer, fungerede denne konfiguration ikke som forventet, og de besluttede midlertidigt at opgive dette konstruktionsskema og fjerne to af de tre noder fra domænet. Samtidig er selve ordningen forblevet den samme, og nu er det netop en GRID-tjeneste, men degenereret til én node.
Lige nu er vanskeligheden fortsat forbundet med et fald i ydeevnen ved regelmæssig rengøring af monitorkredsløbet - med samtidige processer i CNN og kørende rengøring kan der opstå fejl i driften af ETL-kontrolmekanismen. Dette bliver i øjeblikket løst "som en krykke" - ved manuelt at rydde monitorkredsløbet med tab af alle dets tidligere data. Dette er ikke alt for kritisk for produktiviteten under normal rutinedrift, men indtil videre er en søgen efter en normal løsning i gang.
Et andet problem opstår fra den samme situation - nogle gange sker der flere lanceringer af vores kontrolmekanisme.
Flere applikationslanceringer fører til mekanismefejl
Når man kører i henhold til en tidsplan, i perioder med stor belastning af systemet, opstår der nogle gange situationer, der fører til nedbrud af mekanismen. Problemet løses stadig manuelt, og der søges en permanent løsning.
Generelt kan vi opsummere, at når der er en stor belastning, er det meget vigtigt at stille tilstrækkelige ressourcer til rådighed, dette gælder også hardwareressourcer til Informatica selv, og det samme for dets databaselager, samt at levere optimale indstillinger for dem. Derudover er spørgsmålet stadig åbent om, hvilken databaseplaceringsordning der er bedre - på en separat vært eller på den samme, hvor Informatica-softwaren kører. På den ene side vil det være billigere på én server, og kombineret er det mulige problem med netværksinteraktion praktisk talt elimineret, på den anden side er belastningen på værten fra databasen suppleret med belastningen fra Informatica.
Som med ethvert seriøst produkt har Informatica også sjove øjeblikke.
En gang, mens jeg ordnede en form for ulykke, lagde jeg mærke til, at MRS-loggene mærkeligt nok indikerede tidspunktet for begivenhederne.
Tidsmæssig dualisme i MRS-logfiler "by design"
Det viste sig, at tidsstempler er skrevet i 12 timers format, uden at angive AM/PM, det vil sige før middag eller efter. Der blev endda åbnet en ansøgning om denne sag, og der blev modtaget et officielt svar - sådan var det tænkt, mærker er skrevet i MRS-loggen i præcis dette format. Det vil sige, nogle gange er der stadig nogle intriger med hensyn til tidspunktet for forekomsten af en FEJL...
Stræb efter det bedste
I dag er Informatica et ret stabilt værktøj, praktisk for administratorer og brugere, ekstremt kraftfuldt i forhold til dets nuværende muligheder og potentiale. Det overstiger vores funktionelle behov mange gange, og de facto bliver nu brugt i projektet på en måde, der ikke er den mest typiske og typiske. Vanskelighederne hænger til dels sammen med måden mekanismerne fungerer på - det konkrete er, at der i løbet af kort tid lanceres en lang række tråde, der intensivt opdaterer parametre og arbejder med repository-databasen, mens serverhardwareressourcerne udnyttes næsten fuldstændigt. af CPU'en.
Vi er nu tæt på at flytte til Informatica 10.2.1 eller 10.2.2, som har omarbejdet nogle af de interne mekanismer og supportløfter for at eliminere nogle af de problemer med ydeevne og funktionalitet, vi har i øjeblikket. Og fra et hardwaresynspunkt forventer vi servere med en optimal konfiguration for os, under hensyntagen til reserven for den nærmeste fremtid på grund af vækst og udvikling af storage.
Selvfølgelig vil der være test, kompatibilitetskontrol og muligvis arkitektoniske ændringer i HA GRID delen. Udviklingen indenfor Informatica vil fortsætte, da vi på kort sigt ikke kan levere noget til erstatning for systemet.
Og dem, der vil være ansvarlige for dette system i fremtiden, vil helt sikkert være i stand til at bringe det til de krævede pålideligheds- og ydeevneindikatorer, som kunderne har fremlagt.
Artiklen er udarbejdet af Rostelecoms datastyringsteam
Nuværende Informatica-logo
Kilde: www.habr.com