ETL-komponenten av datalager hamnar ofta i skuggan av sjÀlva lagret och fÄr mindre uppmÀrksamhet Àn huvuddatabasen eller frontkomponenten, BI, rapportgenerering. Men sett ur perspektivet av hur lagret fylls med data, spelar ETL en nyckelroll och krÀver minst lika mycket uppmÀrksamhet frÄn administratörer som de andra komponenterna. Jag heter Alexander, jag administrerar ETL pÄ Rostelekom, och i den hÀr artikeln ska jag försöka dela med mig av det jag som administratör för ett av de mest kÀnda ETL-systemen i ett stort datalager pÄ Rostelekom stöter pÄ.
Om respektabla lÀsare redan Àr bekanta med vÄrt datalagerprojekt och produkten Informatica PowerCenter, kan vi gÄ direkt till nÀsta avsnitt.
För flera Är sedan vÀxte och började idén om ett enhetligt företagsdatalager realiseras pÄ Rostelekom. Ett antal datalager som löste separata uppgifter hade redan skapats, men antalet scenarier vÀxte, kostnaderna för support ökade ocksÄ, och det blev tydligt att framtiden lÄg i centralisering. Arkitektoniskt bestÄr detta datalager av flera lager, implementerat pÄ Hadoop och GreenPlum, med hjÀlp avdatabaser, ETL-mekanismer och BI.
Tack vare det stora antalet geografiskt spridda, heterogena datakÀllor skapades en sÀrskild mekanism för datalastning, vars arbete styrs av Informatica. Som ett resultat hamnar paket med data i det grÀnssnittsomrÄde som tillhör Hadoop, varefter dataöverföringsprocesserna genom lagren av lagret, i Hadoop och GreenPlum, börjar, och de styrs av den sÄ kallade ETL-hanteringsmekanismen, som Àr implementerad i Informatica. SÄledes Àr Informatica-systemet en av de centrala komponenterna som sÀkerstÀller lagrets funktion.
Mer information om vÄrt datalager kommer att ges i ett av de kommande inlÀggen.
Informatica PowerCenter/Big Data Management anses för nÀrvarande vara ledande programvara inom dataintegrationsverktyg. Det Àr en produkt frÄn det amerikanska företaget Informatica, som Àr en av de starkaste aktörerna inom ETL (Extract Transform Load), datakvalitetsstyrning, MDM (Master Data Management), ILM (Information Lifecycle Management) och mer.
Den PowerCenter vi anvÀnder Àr en integrerad Tomcat-applikationsserver dÀr Informatica-applikationerna körs och tillhandahÄller sina tjÀnster.
DomÀn, i grunden Àr detta basen för allt annat, tjÀnster, anvÀndare och GRID-komponenter arbetar inom domÀnen.
Administrator Console, ett webbaserat verktyg för hantering och övervakning, förutom Informatica Developer-klienten, det huvudsakliga verktyget för interaktion med produkten.
MRS, Model Repository Service, metadata-förrÄdet, fungerar som ett lager mellan databasen dÀr metadatan lagras fysiskt och Informatica Developer-klienten dÀr utvecklingen pÄgÄr. Repositories lagrar bÄde databeskrivningar och annan information, inklusive för ett antal andra Informatica-tjÀnster, till exempel scheman för körning av jobb (Schedules) eller övervakningsdata, samt parametersets för applikationer, sÀrskilt de som gör att samma applikation kan anvÀndas med olika datakÀllor och mottagare.
DIS, Data Integration Service, Àr tjÀnsten dÀr de huvudsakliga funktionella processerna Àger rum, dÀr applikationerna körs och actually workflows (beskrivningar av sekvenser av mapping och deras interaktion) och mappings (transformeringar, block dÀr sjÀlva konverteringarna och databehandlingarna Àger rum) startas.
GRID-konfiguration â Ă€r i grunden en variant av att bygga ett system med flera servrar, dĂ€r belastningen som DIS hanterar distribueras över noder (det vill sĂ€ga servrar som ingĂ„r i domĂ€nen). I detta fall, förutom belastningsfördelningen i DIS över ett ytterligare abstraktionslager GRID som sammanfogar flera noder, pĂ„ vilket DIS arbetar istĂ€llet för att bara arbeta pĂ„ en specifik nod, kan Ă€ven extra reservinstanser av MRS skapas. Hög tillgĂ€nglighet kan till och med implementeras, dĂ€r externa förfrĂ„gningar kan göras genom reservnoder vid fel av den primĂ€ra. Vi har dock för nĂ€rvarande avstĂ„tt frĂ„n denna byggnadsvariant.
Informatica PowerCenter, schematiskt
Under de första faserna av arbetet i dataleveranskedjan uppstod det regelbundet problem, en del berodde pĂ„ den instabila driften av Informatica vid den tidpunkten. Jag tĂ€nker dela med mig av nĂ„gra av de minnesvĂ€rda ögonblicken av denna saga â att bemĂ€stra Informatica 10.
Det tidigare Informatica-logotypen
VÄrt ansvarsomrÄde inkluderar ocksÄ andra miljöer för Informatica, dÀr det finns sina egna specifikationer pÄ grund av olika belastningar, men jag kommer att fokusera pÄ hur Informatica har utvecklats som en ETL-komponent i sjÀlva datalagringen.
Hur blev det sÄ hÀr?
Ă r 2016, nĂ€r vi började ansvara för Informatica, hade den redan nĂ„tt version 10.0, och för optimistiskt instĂ€llda kollegor som fattade beslutet att anvĂ€nda produkten med en mindre version .0, verkade det uppenbart â det var nödvĂ€ndigt att anvĂ€nda den nya versionen! NĂ€r det gĂ€llde hĂ„rdvaruresurser var allt utmĂ€rkt vid den tiden.
Sedan vÄren 2016 var det en entreprenör som ansvarade för Informatica, och enligt nÄgra fÄ anvÀndare av systemet "fungerade det nÄgra gÄnger i veckan". HÀr behöver jag klargöra att lagret de facto befann sig i ett PoC-lÀge, det fanns inga administratörer i teamet och systemet föll konstant av olika skÀl, efter vilket entreprenörens ingenjör fick starta det igen.
PÄ hösten anslöt tre administratörer till teamet, som delade pÄ ansvarsomrÄdena och började bygga upp en normal drift av systemen inom projektet, inklusive Informatica. Det bör ocksÄ noteras att denna produkt inte Àr allmÀnt förekommande och har en stor community dÀr man kan hitta svar pÄ frÄgor och lösa problem. DÀrför var det mycket viktigt att fÄ fullstÀndig teknisk support frÄn den ryska partnern till Informatica, som hjÀlpte oss att rÀtta till vÄra misstag och felen i den dÄ fortfarande unga Informatica 10.
Det första vi behövde göra för utvecklarna i vÄrt team och entreprenören var att stabilisera Informatica, och fÄ webbadministrationskonsolen (Informatica Administrator) att fungera.
SÄ hÀr stötte vi ofta pÄ utvecklarna av Informatica.
Vid sidan av sjÀlva processen för att faststÀlla orsakerna var den huvudsakliga orsaken till nedfallen interaktionen mellan Informatica-programvaran och databasen i lagret, som lÄg pÄ en relativt avlÀgsen server i nÀtverkslandskapet. Detta ledde till förseningar och störde funktionerna som sÀkerstÀller övervakningen av Informatica-domÀnens tillstÄnd. Efter en del justeringar av databasen, förÀndringar av Informatica-parametrarna som gjorde den mer tolerant mot databasen, samt en uppgradering av Informatica-versionen till 10.1 och förflyttning 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 vi inte observerat sÄdana typer av nedfall.
Ett av försöken att fÄ Informatica Monitor att fungera
Situation med administrationskonsolen var ocksÄ kritisk. Eftersom aktiv utveckling pÄgick direkt i den sÄ kallade produktionsmiljön, behövde kollegor stÀndigt analysera mappings och arbetsflöden "i farten". I den nya Informatica, i Data Integration Service, finns det inget separat verktyg för sÄdan övervakning, men i webbadministrationskonsolen har en övervakningssektion (Informatica Administrator Monitor) lagts till, dÀr man kan övervaka applikationers, arbetsflöden och mappings arbete, körningar och loggar. Periodvis blev konsolen helt otillgÀnglig, eller sÄ slutade informationen om aktuella processer i DIS att uppdateras, eller sÄ uppstod fel vid sidladdningar.
Justering av java-parametrarna för att stabilisera driften
Korrigeringen av problemet gjordes pÄ mÄnga olika sÀtt, experiment utfördes med att Àndra parametrar, loggar samlades, jstack skickades till supporten, samtidigt som aktiv googling pÄgick och observationer gjordes.
I första hand skapades en separat MRS för övervakning, vilket visade sig vara en av de största resurskonsumenterna i vÄra miljöer, eftersom körningar av mappings sker mycket intensivt. Parametrarna för java heap Àndrades, liksom en rad andra.
Som resultat av detta lyckades vi stabilisera driften av konsolen och monitorn till nÀsta uppdatering av Informatica 10.1.1, utvecklarna blev mer effektiva, och de regelbundna processerna blev allt mer regelbundna.
En intressant aspekt kan vara erfarenheten av interaktionen mellan utveckling och administration. FrĂ„gan om en gemensam förstĂ„else för hur allt 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 man med gott samvete rekommendera att först utbilda administratörsteamet om hur programvaran ska administreras och utvecklarteamet om hur man skriver kod och visualiserar processer i systemet, och först dĂ€refter lĂ„ta dem arbeta mot resultat. Det Ă€r verkligen viktigt nĂ€r tiden inte Ă€r en oĂ€ndlig resurs. MĂ„nga problem kan lösas Ă€ven genom slumpmĂ€ssig prövning av alternativ, men ibland krĂ€ver vissa förkunskaper â vĂ„rt fall bekrĂ€ftar vikten av att förstĂ„ denna axiom.
Till exempel, nÀr vi försökte aktivera versionshantering i MRS (som det visade sig, behövde en annan version av SVN), upptÀckte vi efter ett tag med oro att systemets omstartstid hade ökat till flera tiotals minuter. Efter att vi kommit fram till orsaken till förseningen och stÀngt av versionshanteringen gick det bra igen.
Bland de uppenbara hinder kopplade till Informatica kan vi nÀmna det episka slaget med vÀxande java-trÄdar. Vid en viss tidpunkt kom det till att replikera, det vill sÀga sprida de etablerade processerna till ett stort antal kÀllsystem. Det visade sig att lÄngt ifrÄn alla processer i 10.1.1 fungerade bra, och efter en tid blev DIS obrukbart. Tiotusentals trÄdar upptÀcktes, och deras antal ökade sÀrskilt mÀrkbart under proceduren för distribution av applikationer. Ibland behövde vi göra omstarter flera gÄnger om dagen för att ÄterfÄ funktionaliteten.
HĂ€r mĂ„ste vi tacka supporten, problemen lokaliserades och Ă„tgĂ€rdades ganska snabbt med hjĂ€lp av EBF (Emergency Bug Fix) â efter detta kĂ€nde alla att verktyget verkligen fungerar.
Det fungerar faktiskt!
Vid starten av arbetet i mĂ„lmode sĂ„g Informatica ut som följer. Version 10.1.1HF1 (HF1 stĂ„r för HotFix1, leverantörens version frĂ„n EBF-paketet) med ytterligare installerade EBF som Ă„tgĂ€rdade vĂ„ra skalningsproblem och nĂ„gra andra, pĂ„ en av tre servrar i GRID, 20 kĂ€rnor x86_64 och lagring pĂ„ en enorm, lĂ„ngsam uppsĂ€ttning lokala diskar â det Ă€r serverkonfiguration för Hadoop-kluster. PĂ„ en annan sĂ„dan server â Oracle DB som fungerar med bĂ„de Informatica-domen och ETL-hanteringsmekanismen. Allt detta övervakas av standardövervakningsverktyg som anvĂ€nds av teamet (Zabbix + Grafana), för bĂ„de Informatica och dess tjĂ€nster samt processerna för dataöverföring. Just nu beror bĂ„de prestanda och stabilitet, oavsett externa faktorer, pĂ„ instĂ€llningarna som begrĂ€nsar belastningen.
Speciellt kan man nÀmna GRID. Miljön byggdes pÄ tre noder med möjlighet till belastningsbalansering. Under testningen upptÀcktes dock att pÄ grund av problem med interaktionen mellan de körda instanserna av vÄra applikationer sÄ fungerade inte denna konfiguration som förvÀntat, och vi beslutade temporÀrt att överge denna byggschema genom att ta bort tvÄ av tre noder frÄn domen. SjÀlva schemat förblev dock detsamma och nu Àr det verkligen en GRID-tjÀnst, men reducerad till en nod.
För nĂ€rvarande kvarstĂ„r en svĂ„righet relaterad till prestandaförlust vid regelbunden radering av monitorens schema â nĂ€r processer körs i parallellt i NNN och rensningen Ă€r aktiverad kan det uppstĂ„ fel i ETL-hanteringsmekanismen. Detta löses för tillfĂ€llet "pĂ„ ett hackigt sĂ€tt" â manuellt rensande av monitorens schema, vilket resulterar i att alla tidigare data gĂ„r förlorade. Detta Ă€r inte alltför kritiskt för produktionen under normala driftsförhĂ„llanden, men man söker fortfarande en ordentlig lösning.
FrĂ„n samma situation uppstĂ„r Ă€nnu ett problem â ibland intrĂ€ffar flera körningar av vĂ„r hanteringsmekanism.
Flera körningar av applikationen, vilket leder till fel i mekanismen
Vid schemalagda körningar under perioder med hög belastning pÄ systemet intrÀffar ibland situationer som leder till att mekanismen gÄr sönder. Problemet hanteras fortfarande manuellt, och man söker en permanent lösning.
Sammanfattningsvis kan man sĂ€ga att det under hög belastning Ă€r mycket viktigt att tillhandahĂ„lla adekvata resurser. Detta gĂ€ller bĂ„de hĂ„rdvaruresurser för Informatica och Ă€ven för dess databasrepository, samt att sĂ€kerstĂ€lla optimala instĂ€llningar för dem. Dessutom kvarstĂ„r frĂ„gan om vilken databasplacering som Ă€r bĂ€st â pĂ„ en separat vĂ€rd eller pĂ„ samma dĂ€r Informatica-programvaran körs. Ă ena sidan blir det billigare att ha allt pĂ„ en server, och detta minskar potentiella problem med nĂ€tverksinteraktion, Ă„ andra sidan ökar belastningen pĂ„ vĂ€rden frĂ„n databasen samtidigt som belastningen frĂ„n Informatica tillkommer.
Som i alla seriösa produkter finns det Àven komiska ögonblick i Informatica.
En gÄng, nÀr jag granskade en incident, mÀrkte jag att tiden för hÀndelserna i MRS-loggarna var mÀrkligt angiven.
Tidsdualism i MRS-loggar "by design"
Det visade sig att tidsstĂ€mplarna skrivs i 12-timmarsformat, utan angivelse av AM/PM, det vill sĂ€ga före eller efter middag. En begĂ€ran kring detta öppnades och ett officiellt svar mottogs â sĂ„ var det tĂ€nkt, MRS-loggarna registreras just i det formatet. Detta innebĂ€r att det ibland förblir en viss intrig kring tidpunkten för uppkomsten av nĂ„got ERROR...
StrÀva efter det bÀsta
I dag Ă€r Informatica ett tillrĂ€ckligt stabilt verktyg, anvĂ€ndarvĂ€nligt för administratören och anvĂ€ndarna, och extremt kraftfullt utifrĂ„n nuvarande möjligheter och potential. Det överstiger vĂ„ra funktionella behov mĂ„nga gĂ„nger och anvĂ€nds de facto i projektet pĂ„ ett sĂ€tt som inte Ă€r det mest karaktĂ€ristiska och typiska. SvĂ„righeterna hĂ€nger delvis ihop med hur mekanismerna fungerar â specifikationen Ă€r att ett stort antal trĂ„dar körs pĂ„ kort tid, vilket intensivt uppdaterar parameterset och arbetar med databasrepositoryt, samtidigt som serverns hĂ„rdvaruresurser i stort sett utnyttjas fullt ut av CPU:n.
Vi har nu kommit nÀra att övergÄ till Informatica 10.2.1 eller 10.2.2, dÀr vissa interna mekanismer har omarbetats, och supporten lovar att en rad nuvarande problem med prestanda och funktionalitet kommer att vara frÄnvarande. Dessutom förvÀntas servrar med optimal konfiguration för oss, med tanke pÄ reserveringar för den nÀrmaste tiden pÄ grund av tillvÀxt och utveckling av lagret.
SjÀlvklart kommer det att krÀvas tester, kompatibilitetskontroller och eventuellt arkitekturÀndringar för HA GRID. Utvecklingen inom Informatica kommer att fortsÀtta, eftersom vi pÄ kort sikt inte kan ersÀtta systemet.
Och de som i framtiden kommer att ansvara för detta system kommer definitivt att kunna nÄ de krav pÄ tillförlitlighet och prestanda som kunderna stÀller.
Artikeln Àr förberedd av datahanteringsteamet pÄ "Rostelecom"
Aktuell logotyp för Informatica
KĂ€lla: habr.com
