De ETL-component van het datalager ligt vaak in de schaduw van het datalager zelf en krijgt minder aandacht dan de hoofd-database of front-end componenten, BI, en rapportage. Echter, vanuit het perspectief van het vullen van het datalager met gegevens speelt ETL een sleutelrol en vereist het net zoveel aandacht van beheerders als de andere componenten. Mijn naam is Alexander, ik beheer momenteel de ETL bij Rostelecom, en in dit artikel zal ik proberen een beetje te delen wat een beheerder van een van de meest bekende ETL-systemen in een groot datalager van Rostelecom tegenkomt.
Als gewaardeerde lezers al bekend zijn met ons project voor het datalager en met het product Informatica PowerCenter, kunnen ze direct naar de volgende sectie gaan.
Enkele jaren geleden is bij Rostelecom het idee van een centrale corporatieve datalager rijp geworden en in de praktijk gerealiseerd. Een aantal datalagers dat afzonderlijke taken afhandelde was al gecreƫerd, maar het aantal scenario's nam toe, de kosten voor ondersteuning stegen ook, en het werd duidelijk dat de toekomst ligt in centralisatie. Architectonisch bestaat dit datalager uit verschillende lagen, gerealiseerd op Hadoop en GreenPlum, ondersteunende databases, ETL-mechanismen en BI.
Vanwege het grote aantal territoriaal verspreide, heterogene gegevensbronnen werd echter een speciaal mechanisme voor het extraheren van gegevens gecreƫerd, waarvan de werking wordt beheerd door Informatica. Als gevolg hiervan komen datapakketten in de interfacezone van Hadoop terecht, waarna de dataverwerkingsprocessen door de lagen van het datalager in Hadoop en GreenPlum beginnen, die worden beheerd door het zogenaamde ETL-beheersmechanisme, dat in Informatica is gerealiseerd. Op deze manier is het Informatica-systeem een van de sleutelelementen die de werking van het datalager waarborgen.
Meer informatie over ons datalager zal worden gegeven in een van de volgende berichten.
Informatica PowerCenter/Big Data Management wordt op dit moment beschouwd als de toonaangevende software op het gebied van data-integratietools. Dit is een product van het Amerikaanse bedrijf Informatica, dat een van de sterkste spelers is in ETL (Extract Transform Load), gegevenskwaliteitsbeheer, MDM (Master Data Management), ILM (Information Lifecycle Management) en meer.
De PowerCenter die wij gebruiken, is een geĆÆntegreerde Tomcat-applicatieserver waarop de Informatica-applicaties draaien die haar diensten implementeren:
Domein, dit is in wezen de basis voor alles, binnen het domein opereren services, gebruikers en GRID-componenten.
Administrator Console, een webbeheer- en monitoringtool, naast de Informatica Developer-client, het belangrijkste hulpmiddel voor interactie met het product.
MRS, Model Repository Service, een metadata-opslag die een tussenlaag vormt tussen de database waarin de metadata fysiek is opgeslagen en de Informatica Developer-client waarin ontwikkeling plaatsvindt. De repositories bevatten zowel gegevensbeschrijvingen als andere informatie, inclusief voor verschillende andere Informatica-services, zoals taakplanning (Schedules) of monitoringsdata, evenals parametersets van applicaties die het mogelijk maken om dezelfde applicatie te gebruiken voor verschillende gegevensbronnen en -doelen.
DIS, Data Integration Service, dit is de service waarin de belangrijkste functionele processen plaatsvinden, waar applicaties draaien en waar de eigelijke Workflows (de beschrijving van de volgorde van mappings en hun interactie) en Mappings (transformaties, blokken waarin de daadwerkelijke gegevensverwerking plaatsvindt) worden gestart.
GRID-configuratie ā in wezen een variant van het bouwen van een cluster met meerdere servers, waarbij de belasting die door de DIS wordt gestart, wordt verdeeld over nodes (dat wil zeggen servers die deel uitmaken van het domein). In dit geval, naast de verdeling van de belasting in de DIS via een extra abstract laag GRID die meerdere nodes combineert waarop de DIS draait in plaats van op een specifieke node, kunnen ook extra back-up instanties van MRS worden gemaakt. Het is zelfs mogelijk om hoge beschikbaarheid te realiseren, waarbij externe aanvragen via reserve nodes kunnen worden verwerkt bij uitval van de hoofdnode. We hebben momenteel besloten om van deze opstelling af te zien.
Informatica PowerCenter, schematisch
In de vroege stadia van de dataleveringsketen kwamen voortdurend problemen voor, deels door de onbetrouwbare werking van Informatica op dat moment. Ik ben van plan om enkele van de memorabele momenten van deze saga ā het leren van Informatica 10 ā te delen.
Oude logo van Informatica
De verantwoordelijkheden van onze afdeling omvatten ook andere Informatica-omgevingen, die hun eigen specificiteit hebben vanwege de andere belasting. Voorlopig zal ik me concentreren op de ontwikkeling van Informatica als ETL-component van het datawarehouse.
Hoe is dit gebeurd?
In 2016, toen we verantwoordelijk werden voor de werking van Informatica, had het al versie 10.0 bereikt. Voor de optimistisch ingestelde collega's die besloten een serieuze oplossing met een minor versie .0 toe te passen, leek alles duidelijk ā je moest de nieuwe versie gebruiken! Wat betreft hardwarebronnen was alles op dat moment uitstekend.
Vanaf de lente van 2016 was een aannemer verantwoordelijk voor de werking van Informatica, en volgens de weinige gebruikers werkte het 'paar keer per week'. Hier moet ik uitleggen dat het dat warehouse de facto zich in de PoC-fase bevond, er waren geen systeembeheerders in het team en het systeem viel om verschillende redenen constant uit, waarna de ingenieur van de aannemer het opnieuw moest opstarten.
In de herfst verschenen er drie systeembeheerders in het team, die de verantwoordelijkheden onderling verdeelden, en er begon een normale werking van de systemen in het project op te bouwen, inclusief Informatica. Het is vermeldenswaard dat dit product niet wijdverbreid is en geen grote community heeft waar je antwoorden op vragen kunt vinden of problemen kunt oplossen. Daarom was een volledige technische ondersteuning van de Russische partner van Informatica zeer belangrijk, waarmee we al onze fouten en die van het inmiddels nog jonge Informatica 10 corrigeerden.
Het eerste wat we moesten doen voor de ontwikkelaars van ons team en de aannemer, was het stabiliseren van de werking van Informatica zelf en zorgen voor de functionaliteit van de webbeheersconsole (Informatica Administrator).
Zo kwamen we vaak in contact met Informatica-ontwikkelaars.
De hoofdreden voor de uitval was de interactieschema van de Informatica-software met de repository-database, die zich op een relatief afgelegen server bevond vanuit het perspectief van het netwerklandschap. Dit leidde tot vertragingen en verstoorde de mechanismen die de status van het Informatica-domein controleerden. Na enige optimalisatie van de database, het aanpassen van de Informatica-parameters om deze toleranter te maken voor databasevertragingen, en uiteindelijk de upgrade van Informatica naar versie 10.1 en de verhuizing van de database naar een server dichter bij Informatica, is het probleem opgelost, en sindsdien hebben we dergelijke uitval niet meer waargenomen.
Een van de pogingen om de Informatica Monitor aan de praat te krijgen
De situatie met de administratieconsole was ook kritiek. Aangezien er actief werd ontwikkeld op een voorwaardelijk productieve omgeving, moesten de collega's voortdurend de werking van mappings en workflows āon-the-flyā analyseren. In de nieuwe Informatica, in de Data Integration Service, is er geen afzonderlijk instrument voor dergelijke monitoring, maar in de webadministratieconsole is er een monitoringsectie (Informatica Administrator Monitor) verschenen, waar men de werking van applicaties, workflows en mappings, opstarts, logs kan observeren. Af en toe werd de console volledig onbereikbaar, of stopten de actuele procesinformatie in DIS met updaten, of waren er fouten bij het laden van pagina's.
Afstemming van de java-parameters voor stabilisatie van de werking
Het oplossen van het probleem gebeurde op verschillende manieren, er werden experimenten uitgevoerd met parameterwijzigingen, logs werden verzameld, jstack's werden naar de support gestuurd, terwijl er uitvoerig gegoogeld werd en simpelweg werd waargenomen.
In de eerste plaats werd er een aparte MRS voor monitoring gecreƫerd, wat later bleek een van de belangrijkste middelen van onze omgevingen te zijn, aangezien de opstarts van mappings zeer intensief plaatsvinden. De parameters met betrekking tot de java heap werden gewijzigd, evenals een aantal andere.
Als resultaat kon de werking van de console en monitoring tegen de volgende update van Informatica 10.1.1 worden gestabiliseerd, waardoor de ontwikkelaars efficiƫnter konden werken en de reguliere processen steeds regelmatiger werden.
De interactie tussen ontwikkeling en administratie kan interessant zijn. Het is altijd belangrijk om een algemeen begrip te hebben van hoe alles werkt, wat mogelijk is en wat niet, vooral bij het gebruik van complexe systemen. Daarom kan het met vertrouwen worden aanbevolen om eerst het team van beheerders op te leiden in hoe de software moet worden beheerd, en het ontwikkelingsteam in hoe code geschreven en processen in het systeem ontworpen moeten worden, om daarna beiden aan de slag te laten gaan met het behalen van resultaten. Dit is echt belangrijk wanneer tijd geen onbeperkte hulpbron is. Veel problemen kunnen zelfs door middel van trial-and-error worden opgelost, maar soms zijn er bepaalde vereisten voor kennis ā ons geval bevestigt het belang van het begrijpen van deze axioma.
Bijvoorbeeld, toen we probeerden versiebeheer in MRS in te voeren (zoals uiteindelijk bleek, was een andere versie van SVN nodig), ontdekten we na enige tijd met bezorgdheid dat de herstarttijd van het systeem was toegenomen tot enkele tientallen minuten. Toen we de oorzaak van de vertraging bij de opstart hebben achterhaald en versiebeheer hebben uitgeschakeld, werkte het weer goed.
Een van de opvallende obstakels met betrekking tot Informatica was de epische strijd met toenemende java-threads. Op een gegeven moment kwam het tijd om te repliceren, dat wil zeggen om de gestroomlijnde processen naar een groot aantal bronsystemen uit te breiden. Hierbij bleek dat niet alle processen in 10.1.1 goed werkten, en na verloop van tijd werd DIS niet meer operationeel. Tienduizenden threads werden ontdekt, waarbij het aantal vooral toenam tijdens de procedure voor de implementatie van applicaties. Soms moesten we meerdere keren per dag herstarten om de functionaliteit te herstellen.
Hier moeten we de ondersteuning bedanken, die de problemen relatief snel heeft gelokaliseerd en verholpen met behulp van EBF (Emergency Bug Fix) - daarna had iedereen het gevoel dat de tool echt werkte.
Het werkt toch!
Bij de start van het operationele regime zag Informatica er als volgt uit. Versie Informatica 10.1.1HF1 (HF1 is HotFix1, de vendorversie uit de EBF-reeks) met extra geĆÆnstalleerde EBF's die onze schaalbaarheidsproblemen en enkele andere problemen oplosten, op Ć©Ć©n van de drie servers die deel uitmaakten van de GRID, 20 cores x86_64 en opslag op een enorme, trage array van lokale schijven. serverconfiguratie voor een Hadoop-cluster. Op een andere identieke server draait de Oracle-database, die samenwerkt met het Informatica-domein en de ETL-beheermachine. Al deze systemen worden gemonitord met de standaard monitoringtools die in het team worden gebruikt (Zabbix + Grafana), van beide kanten ā zowel Informatica zelf met zijn diensten, als de processen van data-uploads die hierbij lopen. Momenteel hangt de prestaties en stabiliteit, los van externe factoren, af van de instellingen die de belasting beperken.
Er valt ook wat te zeggen over GRID. De omgeving was opgebouwd uit drie nodes, met de mogelijkheid van load balancing. Tijdens het testen werd echter ontdekt dat door problemen met de interactie tussen de draaiende exemplaren van onze applicaties, deze configuratie niet naar verwachting werkte, en tijdelijk hebben we besloten deze opzet te verlaten door twee van de drie nodes uit het domein te halen. De configuratie zelf is echter ongewijzigd gebleven, en momenteel is het nog steeds een GRID-service, maar gedegradeerd tot Ć©Ć©n node.
Op dit moment blijft er een probleem bestaan met het verval van prestaties tijdens de regelmatige opruiming van het monitor-schema ā wanneer er gelijktijdig processen in het CHN lopen en de opruiming wordt uitgevoerd, kunnen er storingen optreden in de werking van de ETL-beheermachine. Dit wordt voorlopig āhackyā opgelost ā door handmatig het monitor-schema op te schonen, met verlies van alle eerdere gegevens. Dit is niet al te kritisch voor productie, bij normaal operationeel werk, maar er wordt nog gezocht naar een solide oplossing.
Hieruit vloeit ook een ander probleem voort ā soms worden er meerdere exemplaren van onze beheermachine gestart.
Meerdere exemplaren van de applicatie, wat leidt tot een storing in de machine.
Bij het starten volgens schema tijdens piekbelasting op het systeem komen er soms situaties voor die leiden tot een storing in de machine. Tot nu toe wordt het probleem handmatig opgelost, en er wordt gezocht naar een permanente oplossing.
Over het algemeen kan worden samengevat dat het bij grote belasting zeer belangrijk is om adequate middelen te bieden. Dit geldt zowel voor de hardware van Informatica als voor de database-repository, en ook voor het optimaliseren van hun instellingen. Bovendien blijft de vraag open welke configuratie van de database beter is ā op een aparte host of op dezelfde als waarop de Informatica-software draait. Aan de ene kant is het goedkoper om alles op Ć©Ć©n server te hebben, en door de combinatie wordt vrijwel de mogelijk opkomende probleem met netwerkinteractie weggenomen, maar aan de andere kant wordt de belasting op de host door de database aangevuld met de belasting van Informatica.
Zoals bij elk serieus product zijn er ook in Informatica komische momenten.
Een keer, terwijl ik een storing aan het onderzoeken was, merkte ik op dat de tijden van gebeurtenissen in de MRS-logs vreemd waren opgemerkt.
Tijddualiteit in de MRS-logs āopzettelijkā
Het bleek dat de tijdstempels in een 12-uurs formaat worden geschreven, zonder AM/PM-aanduiding, dus voor of na de middag. Er was zelfs een verzoek hierover ingediend, en een officiĆ«le reactie gekregen ā het was zo ontworpen, tijdstempels in de MRS-logboeken worden juist in dat formaat genoteerd. Dit betekent dat er soms een zekere intrige blijft bestaan over het tijdstip waarop een ERROR zich voordoet ā¦
Streven naar beter
Vandaag de dag is Informatica een behoorlijk stabiel hulpmiddel, handig voor zowel de beheerder als de gebruikers, en extreem krachtig in termen van huidige mogelijkheden en potentieel. Het overstijgt functioneel meerdere malen onze behoeften en wordt de facto op een niet typische manier in ons project gebruikt. De complicaties zijn gedeeltelijk gerelateerd aan de werking van de mechanismen ā de specificiteit is dat in een korte tijd veel threads worden gestart die intensief parametersets bijwerken en met de database van de repository werken, terwijl de hardwarebronnen van de server vrijwel volledig worden benut qua CPU.
We zijn nu dicht bij de overgang naar Informatica 10.2.1 of 10.2.2, waarin enkele interne mechanismen zijn herzien, en de ondersteuning belooft dat een aantal van de problemen die we momenteel ondervinden met de prestaties en functionaliteit zullen ontbreken. Ook vanuit hardware-oogpunt worden servers van een optimale configuratie voor ons verwacht, met inachtneming van de reserve voor de nabije toekomst gezien de groei en ontwikkeling van de opslag.
Natuurlijk volgen testprocedures, compatibiliteitscontroles en mogelijk architectonische aanpassingen met betrekking tot HA GRID. De ontwikkeling binnen Informatica zal doorgaan, aangezien we op korte termijn niets ter vervanging van het systeem kunnen implementeren.
En degenen die in de toekomst verantwoordelijk zullen zijn voor dit systeem, zullen zeker in staat zijn om het te brengen naar de vereiste niveaus van betrouwbaarheid en prestaties die door de klanten worden gepresenteerd.
Dit artikel is voorbereid door het data management team van "Rostelecom"
Actueel logo van Informatica
Bron: habr.com
