ETL-komponenten i datalagret överskuggas ofta av själva lagret och får mindre uppmärksamhet än huvuddatabasen eller front-end-komponenten, BI och rapportering. Samtidigt, ur synvinkeln av mekaniken att fylla lagret med data, spelar ETL en nyckelroll och kräver inte mindre uppmärksamhet från administratörer än andra komponenter. Jag heter Alexander, jag administrerar nu ETL på Rostelecom, och i den här artikeln ska jag försöka dela lite av vad administratören för ett av de mest kända ETL-systemen i ett stort datalager på Rostelecom har att göra med.
Om kära läsare redan är allmänt bekanta med vårt datalagerprojekt och med Informatica PowerCenter-produkten, kan du direkt gå vidare till nästa avsnitt.
För flera år sedan mognade idén om ett enda företagsdatalager och började implementeras i Rostelecom. Ett antal förvar som löste enskilda problem hade redan skapats, men antalet scenarier växte, supportkostnaderna ökade också och det blev tydligt att framtiden låg i centralisering. Arkitektoniskt är detta själva lagringen, bestående av flera lager, implementerad på Hadoop och GreenPlum, hjälpdatabaser, ETL-mekanismer och BI.
Samtidigt, på grund av det stora antalet geografiskt fördelade, heterogena datakällor, skapades en speciell datauppladdningsmekanism, vars funktion styrs av Informatica. Som ett resultat hamnar datapaket i Hadoop-gränssnittsområdet, varefter processerna med att ladda data genom lagringslager, Hadoop och GreenPlum, börjar, och de hanteras av den så kallade ETL-kontrollmekanismen implementerad i Informatica. Således är Informatica-systemet ett av nyckelelementen som säkerställer driften av lagret.
Vår förvaring kommer att beskrivas mer i detalj i något av följande inlägg.
Informatica PowerCenter/Big Data Management anses för närvarande vara den ledande programvaran inom området dataintegrationsverktyg. Detta är en produkt från det amerikanska företaget Informatica, som är en av de starkaste aktörerna inom ETL (Extract Transform Load), datakvalitetshantering, MDM (Master Data Management), ILM (Information Lifecycle Management) med mera.
PowerCenter vi använder är en integrerad Tomcat-applikationsserver där själva Informatica-applikationerna körs och implementerar dess tjänster:
Domän, i själva verket är detta grunden för allt annat; tjänster, användare och GRID-komponenter verkar inom domänen.
Administratörskonsol, ett webbaserat hanterings- och övervakningsverktyg, förutom Informatica Developer-klienten, huvudverktyget för att interagera med produkten
MRS, Model Repository Service, ett metadatalager, är ett lager mellan databasen där metadata lagras fysiskt och Informatica Developer-klienten där utvecklingen sker. Lagrar lagrar databeskrivningar och annan information, inklusive för ett antal andra Infromatica-tjänster, till exempel scheman för att köra uppgifter (Schedules) eller övervakningsdata, såväl som applikationsparametrar, i synnerhet, som tillåter användning av samma applikation för arbete med olika datakällor och mottagare.
DIS, Dataintegrationstjänst, detta är en tjänst där de huvudsakliga funktionella processerna äger rum, applikationer körs i den och de faktiska lanseringarna av Workflows (beskrivningar av sekvensen av mappningar och deras interaktioner) och Mappningar (transformationer, block där själva transformationerna sker, databehandling ) äger rum.
GRID-konfiguration – i huvudsak ett alternativ för att bygga ett komplex med hjälp av flera servrar, när belastningen som startas av DIS är fördelad mellan noderna (det vill säga servrar som är en del av domänen). I fallet med detta alternativ, förutom att fördela belastningen i DIS genom ett extra GRID-abstraktionslager som förenar flera noder, på vilka DIS körs istället för att arbeta på en specifik enskild nod, kan ytterligare backup-MRS-instanser också skapas. Du kan till och med implementera hög tillgänglighet, där externa samtal kan göras via backupnoder om den huvudsakliga misslyckas. Vi har övergett detta byggalternativ för tillfället.
Informatica PowerCenter, schematisk
I de tidiga stadierna av arbetet som en del av dataförsörjningskedjan uppstod regelbundet problem, några av dem på grund av den instabila driften av Informatica vid den tiden. Jag ska dela med mig av några av de minnesvärda ögonblicken i den här sagan - att bemästra Informatica 10.
Tidigare Informatica-logotyp
Vårt ansvarsområde omfattar även andra Informatica-miljöer, de har sina egna detaljer på grund av en annan belastning, men tills vidare kommer jag ihåg exakt hur Informatica utvecklades som en ETL-komponent i själva datalagret.
Hur hände det
2016, när vi blev ansvariga för Informaticas arbete, hade det redan nått version 10.0, och för optimistiska kollegor som bestämde sig för att använda en produkt med en mindre version .0 i en seriös lösning, verkade allt självklart - vi måste använda den nya versionen! Ur hårdvaruresursers synvinkel var allt bra på den tiden.
Sedan våren 2016 har en entreprenör ansvarat för Informaticas arbete och enligt de få användarna av systemet "fungerade det ett par gånger i veckan." Här är det nödvändigt att klargöra att förvaret de facto var på PoC-stadiet, det fanns inga administratörer i teamet och systemet kraschade hela tiden av olika anledningar, varefter entreprenörens ingenjör tog upp det igen.
Under hösten anslöt sig tre administratörer i teamet som delade upp sina ansvarsområden sinsemellan, och det normala arbetet började med att organisera driften av systemen i projektet, inklusive Informatica. Separat måste det sägas att denna produkt inte är utbredd och har en stor gemenskap där du kan hitta svar på alla frågor och lösa alla problem. Därför var fullständig teknisk support från den ryska partnern Informatica mycket viktig, med hjälp av vilken alla våra fel och fel av den då unga Informatica 10 korrigerades.
Det första vi var tvungna att göra för utvecklarna av vårt team och entreprenören var att stabilisera själva Informaticas arbete, för att säkerställa funktionaliteten hos webbadministrationskonsolen (Informatica Administrator).
Det var så vi ofta träffade Informatica-utvecklare
Om man bortser från processen att ta reda på orsakerna, var den främsta orsaken till krascharna interaktionsmönstret för Informatica-mjukvaran med arkivdatabasen, som låg på en relativt avlägsen server, ur nätverkslandskapets synvinkel. Detta orsakade förseningar och störde mekanismerna som övervakar tillståndet för Informatica-domänen. Efter en del justering av databasen, ändring av parametrarna för Informatica, vilket gjorde den mer tolerant mot databasförseningar, och så småningom uppdatering av Informatica-versionen till 10.1 och överföring av databasen från den tidigare servern till en server som låg närmare Informatica, förlorade problemet sin relevans, och sedan dess har det skett krascher av det här slaget som vi inte observerar.
Ett av försöken att få Informatica Monitor att fungera
Situationen med administrationskonsolen var också kritisk. Eftersom aktiv utveckling pågick direkt på den relativt produktiva miljön, behövde kollegor hela tiden analysera arbetet med kartläggningar och arbetsflöden "på språng". I nya Informatica har Dataintegrationstjänsten inget separat verktyg för sådan övervakning, men det har dykt upp en övervakningsdel i administrationens webbkonsol (Informatica Administrator Monitor), där man kan övervaka driften av applikationer, arbetsflöden och mappningar, lanseringar, loggar. Periodvis blev konsolen helt otillgänglig, eller information om aktuella processer i DIS slutade uppdateras, eller så uppstod fel när sidor laddades.
Val av java-parametrar för att stabilisera prestanda
Problemet åtgärdades på många sätt, experiment gjordes för att ändra parametrar, loggar och jstack samlades in, skickades till support, samtidigt var det aktiv googling och helt enkelt observation.
Först och främst skapades en separat MRS för övervakning, som det visade sig senare är detta en av huvudkonsumenterna av resurser i våra miljöer, eftersom kartläggningar lanseras mycket intensivt. Parametrar gällande java heap och ett antal andra har ändrats.
Som ett resultat av nästa uppdatering av Informatica 10.1.1 stabiliserades driften av konsolen och bildskärmen, utvecklare började arbeta mer effektivt och regelbundna processer blev mer och mer regelbundna.
Upplevelsen av samspel mellan utveckling och administration kan vara intressant. Frågan om en allmän förståelse för hur saker fungerar, vad som kan göras och vad som inte kan göras, är alltid viktig när man använder komplexa system. Därför kan vi lugnt rekommendera att du först utbildar det administrativa teamet i hur man administrerar mjukvaran, och utvecklingsteamet i hur man skriver kod och ritar processer i systemet, och först sedan skickar ettan och tvåan för att arbeta med resultatet. Detta är verkligen viktigt när tid inte är en oändlig resurs. Många problem kan lösas även genom en slumpmässig sökning av alternativ, men ibland kräver vissa a priori kunskap - vårt fall bekräftar vikten av att förstå detta axiom.
Till exempel, när vi försökte aktivera versionshantering i MRS (som det visade sig i slutändan behövdes en annan version av SVN), efter en tid blev vi oroliga när vi upptäckte att systemets omstartstid hade ökat till flera tiotals minuter. Efter att ha hittat orsaken till förseningen i starten och inaktiverat versionshantering gick vi bra igen.
Anmärkningsvärda hinder förknippade med Informatica inkluderar den episka striden med växande Java-trådar. Någon gång har tiden kommit för replikering, det vill säga att utöka de etablerade processerna till ett stort antal källsystem. Det visade sig att inte alla processer i 10.1.1 fungerade bra, och efter en tid blev DIS inoperabel. Tiotusentals trådar upptäcktes, deras antal ökade särskilt märkbart under applikationsdistributionen. Ibland var jag tvungen att starta om flera gånger om dagen för att återställa funktionaliteten.
Här måste vi tacka supporten, problemen lokaliserades och fixades relativt snabbt med EBF (Emergency Bug Fix) - efter det fick alla en känsla av att verktyget verkligen fungerar.
Det fungerar fortfarande!
När vi började arbeta i målläge såg Informatica ut så här. Version av Informatica 10.1.1HF1 (HF1 är HotFix1, en leverantörssammansättning från ett komplex av EBF) med ytterligare installerad EBF, som korrigerar våra problem med skalning och några andra, på en server av tre som ingick i GRID, 20 x86_64-kärnor och lagring, på en enorm långsam uppsättning lokala diskar - detta är serverkonfigurationen för ett Hadoop-kluster. På en annan liknande server - Oracle DBMS som både Informatica-domänen och ETL-kontrollmekanismen fungerar med. Allt detta övervakas av standardövervakningsverktyg som används i teamet (Zabbix + Grafana) på båda sidor - Informatica själv med sina tjänster och laddningsprocesserna som går in i det. Nu beror både prestanda och stabilitet, utan att ta hänsyn till yttre faktorer, på inställningarna som begränsar belastningen.
Separat kan vi säga om GRID. Miljön byggdes på tre noder, med möjlighet till lastbalansering. Men under testningen upptäcktes det att på grund av interaktionsproblem mellan de körande instanserna av våra applikationer, fungerade inte denna konfiguration som förväntat, och de beslutade att tillfälligt överge detta konstruktionsschema och ta bort två av de tre noderna från domänen. Samtidigt har själva schemat förblivit detsamma, och nu är det just en GRID-tjänst, men degenererat till en nod.
Just nu förblir svårigheten förknippad med en minskning av prestanda när man regelbundet rengör monitorkretsen - med samtidiga processer i CNN och pågående rengöring kan fel i driften av ETL-kontrollmekanismen uppstå. Detta löses för närvarande "som en krycka" - genom att manuellt rensa monitorkretsen, med förlust av alla tidigare data. Detta är inte alltför kritiskt för produktiviteten, under normal rutindrift, men för närvarande pågår ett sökande efter en normal lösning.
Ett annat problem uppstår från samma situation - ibland inträffar flera lanseringar av vår kontrollmekanism.
Flera programstarter leder till mekanismfel
När man kör enligt ett schema, vid tider med stor belastning på systemet, uppstår ibland situationer som leder till haveri av mekanismen. Problemet åtgärdas fortfarande manuellt och en permanent lösning söks.
Generellt kan vi sammanfatta att när det är en tung belastning är det mycket viktigt att tillhandahålla resurser som är tillräckliga för det, detta gäller även hårdvaruresurser för Informatica själv, och samma sak för dess databasförråd, samt att tillhandahålla optimala inställningar för dem. Dessutom förblir frågan öppen om vilket databasplaceringsschema som är bättre - på en separat värd, eller på samma där Informatica-mjukvaran körs. Å ena sidan blir det billigare på en server och i kombination är det möjliga problemet med nätverksinteraktion praktiskt taget eliminerat, å andra sidan kompletteras belastningen på värden från databasen med belastningen från Informatica.
Som med alla seriösa produkter har Informatica också roliga ögonblick.
En gång, när jag red ut någon sorts olycka, märkte jag att MRS-loggarna konstigt nog angav tidpunkten för händelserna.
Temporal dualism i MRS-loggar "by design"
Det visade sig att tidsstämplar skrivs i 12-timmarsformat, utan att specificera AM/PM, det vill säga före middagstid eller efter. En ansökan öppnades till och med angående denna fråga, och ett officiellt svar mottogs - så här var det tänkt, märken skrivs i MRS-loggen i exakt detta format. Det vill säga, ibland återstår det en del intriger angående tidpunkten för uppkomsten av något FEL...
Sträva efter det bästa
Idag är Informatica ett ganska stabilt verktyg, bekvämt för administratörer och användare, extremt kraftfullt vad gäller dess nuvarande möjligheter och potential. Det överträffar våra funktionella behov många gånger om och de facto används nu i projektet på ett sätt som inte är det mest typiska och typiska. Svårigheterna är delvis relaterade till hur mekanismerna fungerar - det specifika är att det på kort tid lanseras ett stort antal trådar som intensivt uppdaterar parametrar och arbetar med arkivdatabasen, samtidigt som serverns hårdvaruresurser utnyttjas nästan helt. av CPU:n.
Vi är nu nära att gå över till Informatica 10.2.1 eller 10.2.2, som har omarbetat några av de interna mekanismerna och supportlöften för att eliminera några av de prestanda- och funktionsproblem vi har för närvarande. Och ur hårdvarusynpunkt förväntar vi oss servrar med en optimal konfiguration för oss, med hänsyn till reserven för den närmaste framtiden på grund av tillväxten och utvecklingen av lagring.
Naturligtvis kommer det att finnas testning, kompatibilitetskontroll och eventuellt arkitektoniska förändringar i HA GRID-delen. Utvecklingen inom Informatica kommer att fortsätta eftersom vi på kort sikt inte kan leverera något som ersätter systemet.
Och de som kommer att ansvara för detta system i framtiden kommer definitivt att kunna föra det till de erforderliga tillförlitlighets- och prestandaindikatorer som lagts fram av kunderna.
Artikeln utarbetades av Rostelecoms datahanteringsteam
Aktuell Informatica-logotyp
Källa: will.com