Die ETL-Komponente eines Data Warehouses steht oft im Schatten des eigentlichen Lagers und erhĂ€lt weniger Aufmerksamkeit als die Hauptdatenbank oder die Frontkomponenten, BI und Berichterstattung. Dabei spielt ETL aus mechanischer Sicht eine SchlĂŒsselrolle bei der BefĂŒllung des Lagers mit Daten und verdient genauso viel Aufmerksamkeit von den Administratoren wie die anderen Komponenten. Mein Name ist Alexander, ich verwalte aktuell ETL bei Rostelecom, und in diesem Artikel möchte ich einige Herausforderungen teilen, mit denen ein Administrator eines bekannten ETL-Systems in einem groĂen Data Warehouse von Rostelecom konfrontiert ist.
Wenn unsere geschĂ€tzten Leser bereits insgesamt mit unserem Data Warehouse-Projekt und dem Produkt Informatica PowerCenter vertraut sind, können sie direkt zum nĂ€chsten Abschnitt ĂŒbergehen.
Vor einigen Jahren reifte bei Rostelecom die Idee eines einheitlichen Unternehmensdatenlagers und wurde schlieĂlich umgesetzt. Eine Reihe von Speichersystemen, die spezifische Aufgaben erfĂŒllten, war bereits geschaffen worden; jedoch stieg die Anzahl an Szenarien und die Kosten fĂŒr die Wartung wuchsen ebenfalls. Es wurde klar, dass die Zukunft in der Zentralisierung liegt. Architektonisch besteht dieses Speicherlager aus mehreren Schichten, realisiert auf Hadoop und GreenPlum, einschlieĂlich unterstĂŒtzender Datenbanken, ETL-Mechanismen und BI.
Angesichts der Vielzahl geografisch verteilter, heterogener Datenquellen wurde ein spezieller Mechanismus zur Datenextraktion geschaffen, dessen Betrieb durch Informatica gesteuert wird. Infolgedessen gelangen die Datenpakete in den Interface-Bereich von Hadoop, danach beginnen die Prozesse zum Laden der Daten in die Schichten des Speichers, sowohl in Hadoop als auch in GreenPlum. Diese Prozesse werden durch den sogenannten ETL-Verwaltungsmechanismus, der in Informatica implementiert ist, gesteuert. Somit ist das System Informatica eines der SchlĂŒsselelemente, die den Betrieb des Speichers gewĂ€hrleisten.
In einem der folgenden BeitrĂ€ge werden wir ausfĂŒhrlicher ĂŒber unser Speicherlager berichten.
Informatica PowerCenter und Big Data Management gelten derzeit als fĂŒhrende Softwarelösung im Bereich der Datenintegrationswerkzeuge. Dieses Produkt stammt von der amerikanischen Firma Informatica, einem der stĂ€rksten Akteure im Bereich ETL (Extract, Transform, Load), DatenqualitĂ€tsmanagement, MDM (Master Data Management), ILM (Information Lifecycle Management) und mehr.
Das von uns verwendete PowerCenter ist ein integrierter Anwendungsserver auf Basis von Tomcat, auf dem die Informatica-Anwendungen betrieben werden, die ihre Dienste bereitstellen:
Domain, im Grunde ist es die Grundlage fĂŒr alles Weitere, innerhalb der DomĂ€ne arbeiten die Dienste, die Benutzer und die GRID-Komponenten.
Administrator Console, ein webbasiertes Management- und Ăberwachungstool, neben dem Informatica Developer Client, das Hauptwerkzeug fĂŒr die Interaktion mit dem Produkt.
MRS, Model Repository Service, ein Metadaten-Repository, dient als Schnittstelle zwischen der physischen Datenbank, in der die Metadaten gespeichert sind, und dem Informatica Developer-Client, in dem die Entwicklung erfolgt. Repositories speichern sowohl die Datenbeschreibung als auch andere Informationen, einschlieĂlich Daten fĂŒr verschiedene andere Informatica-Dienste, beispielsweise AusfĂŒhrungsplĂ€ne (Schedules) oder Ăberwachungsdaten sowie Parametersets von Anwendungen, die es ermöglichen, dass dieselbe Anwendung mit verschiedenen Datenquellen und -senken arbeitet.
DIS, Data Integration Service, ist der Dienst, in dem die wesentlichen Funktionsprozesse stattfinden, in dem Anwendungen ausgefĂŒhrt werden und in dem die eigentlichen Workflows (Beschreibungen der Reihenfolge von Mappings und deren Interaktion) und Mappings (Transformationen, Blöcke, in denen die Transformationen und Datenverarbeitung stattfinden) gestartet werden.
GRID-Konfiguration â im Wesentlichen handelt es sich um eine Bauweise eines Komplexes, bei der mehrere Server verwendet werden, um die von DIS erzeugte Last auf Knoten (d. h. Server innerhalb der DomĂ€ne) zu verteilen. In dieser Variante kann, neben der Lastverteilung in DIS ĂŒber eine zusĂ€tzliche Abstraktionsschicht GRID, die mehrere Knoten miteinander verbindet und auf der DIS anstelle eines einzelnen Knoten arbeitet, auch die Erstellung zusĂ€tzlicher Backup-Instanzen von MRS erfolgen. Man kann sogar HochverfĂŒgbarkeit implementieren, bei der externe Anfragen ĂŒber Backup-Knoten bei einem Ausfall des Hauptknotens abgewickelt werden. Von dieser Bauweise haben wir vorerst Abstand genommen.
Informatica PowerCenter, schematisch
In den frĂŒhen Phasen der Arbeit in der Datenlieferkette gab es regelmĂ€Ăig Probleme, von denen einige auf die damals instabile Leistung von Informatica zurĂŒckzufĂŒhren waren. Ich möchte einige der denkwĂŒrdigen Momente dieser Saga â der Einarbeitung in Informatica 10 â teilen.
Das frĂŒhere Logo von Informatica
Unser Bereich umfasst auch andere Informatica-Umgebungen, die aufgrund unterschiedlicher Lasten ihre eigenen Besonderheiten aufweisen. Momentan möchte ich jedoch darauf eingehen, wie sich Informatica als ETL-Komponente des Data Warehouses entwickelt hat.
Wie kam es dazu
Im Jahr 2016, als wir die Verantwortung fĂŒr Informatica ĂŒbernahmen, war sie bereits in der Version 10.0. FĂŒr optimistisch eingestellte Kollegen, die die Entscheidung ĂŒber den Einsatz des Produkts mit einer Minor-Version .0 getroffen hatten, war es offensichtlich: Wir mĂŒssen die neue Version nutzen! Was die Hardware-Ressourcen angeht, war zu diesem Zeitpunkt alles prima.
Seit dem FrĂŒhjahr 2016 war ein Auftragnehmer fĂŒr den Betrieb von Informatica verantwortlich, und aus den Worten der wenigen Nutzer des Systems âlief es ein paar Mal in der Wocheâ. Hier ist anzumerken, dass das Data Warehouse de facto im PoC-Stadium war, es gab keine Administratoren im Team und das System fiel aus verschiedenen GrĂŒnden stĂ€ndig aus, wobei der Ingenieur des Auftragnehmers es dann wieder hochfahren musste.
Im Herbst stieĂen drei Administratoren zu unserem Team, die die Verantwortungsbereiche aufteilten und so eine reibungslose BetriebsfĂŒhrung der Systeme im Projekt, einschlieĂlich Informatica, ermöglichten. Hierbei ist zu erwĂ€hnen, dass dieses Produkt nicht weit verbreitet und nicht von einer groĂen Community unterstĂŒtzt wird, in der man Antworten auf Fragen finden oder Probleme lösen kann. Daher war eine vollumfĂ€ngliche technische UnterstĂŒtzung durch unseren russischen Partner Informatica entscheidend, um all unsere Fehler sowie die Fehler des damals noch jungen Informatica 10 zu korrigieren.
Das erste, was wir fĂŒr die Entwickler unseres Teams und den Auftragnehmer tun mussten, war die Stabilisierung des Betriebs von Informatica und die Wiederherstellung der FunktionalitĂ€t der Web-Verwaltungskonsole (Informatica Administrator).
So trafen wir hÀufig auf die Entwickler von Informatica.
UnabhĂ€ngig von dem Prozess, der zur KlĂ€rung der Ursachen fĂŒhrte, war der Hauptgrund fĂŒr die AusfĂ€lle die Interaktion zwischen der Informatica-Software und der Datenbank des Repositories, die sich auf einem im Netzwerkvergleich relativ entfernten Server befand. Dies fĂŒhrte zu Verzögerungen und beeintrĂ€chtigte die Funktion der Mechanismen zur Ăberwachung des Zustands der Informatica-DomĂ€ne. Nach einigen Anpassungen der Datenbank und Ănderungen der Informatica-Parameter, die die Software toleranter gegenĂŒber Datenbank-Verzögerungen machten, sowie nach dem Upgrade auf die Version 10.1 und dem Umzug der Datenbank auf einen nĂ€her gelegenen Server, ist das Problem an Bedeutung verloren, und seitdem beobachten wir keine Ă€hnlichen AusfĂ€lle mehr.
Ein Versuch, den Informatica Monitor zum Laufen zu bringen
Die Situation mit der Administrationskonsole war ebenfalls kritisch. Da aktiv an der sogenannten produktiven Umgebung gearbeitet wurde, mussten die Kollegen stĂ€ndig die FunktionalitĂ€t der Mappings und Workflows 'live' ĂŒberprĂŒfen. In der neuen Informatica gibt es im Data Integration Service zwar kein separates Werkzeug fĂŒr diese Ăberwachung, jedoch wurde in der Web-Administrationskonsole ein Ăberwachungsbereich (Informatica Administrator Monitor) eingefĂŒhrt, in dem die Leistung von Anwendungen, Workflows und Mappings, sowie Starts und Protokolle verfolgt werden können. Gelegentlich war die Konsole vollstĂ€ndig nicht erreichbar, oder die Informationen ĂŒber die aktuellen Prozesse im DIS wurden nicht mehr aktualisiert, oder es traten Fehler beim Laden der Seiten auf.
Einstellungen fĂŒr Java zur Stabilisierung des Betriebs
Die Problemlösung verlief auf mehreren Wegen: Es wurden Tests zur Ănderung der Parameter durchgefĂŒhrt, Protokolle und JStacks gesammelt und an den Support gesendet, wĂ€hrend parallel aktiv gegoogelt und einfach beobachtet wurde.
ZunĂ€chst wurde ein separater MRS zur Ăberwachung eingerichtet, der sich spĂ€ter als einer der Hauptressourcenverbraucher in unseren Umgebungen herausstellte, da die Mappings sehr intensiv ausgefĂŒhrt werden. Die Einstellungen bezĂŒglich des Java-Heap und eine Reihe weiterer Parameter wurden angepasst.
Infolge dessen gelang es, mit dem nĂ€chsten Update von Informatica 10.1.1 die FunktionalitĂ€t von Konsole und Monitor zu stabilisieren. Die Entwickler arbeiteten effizienter, und die regelmĂ€Ăigen Prozesse wurden zunehmend konstanter.
Die Interaktion zwischen Entwicklung und Administration kann sehr interessant sein. Das gemeinsame VerstĂ€ndnis dafĂŒr, wie alles funktioniert, was möglich ist und was nicht, ist besonders wichtig bei der Nutzung komplexer Systeme. Daher ist es ratsam, zunĂ€chst das Administrator-Team im Umgang mit der Software zu schulen, wĂ€hrend das Entwicklungsteam lernt, wie man Code schreibt und Prozesse im System entwirft. Erst danach sollte man beide Teams auf ihre Aufgaben ansetzen. Dies ist besonders wichtig, wenn die Zeit ein begrenzter Faktor ist. Viele Probleme lassen sich durch Ausprobieren lösen, doch einige erfordern tiefere Kenntnisse â unser Fall bestĂ€tigt die Bedeutung dieses Grundsatzes.
Zum Beispiel, als wir versuchten, die Versionsverwaltung in MRS zu aktivieren (wie sich spÀter herausstellte, benötigten wir eine andere SVN-Version), bemerkten wir mit Besorgnis, dass die Neustartzeit des Systems auf mehrere Dutzend Minuten angestiegen war. Nachdem wir die Ursache der Verzögerung identifiziert und die Versionsverwaltung deaktiviert hatten, lief es wieder optimal.
Unter den bemerkenswerten Herausforderungen, die mit Informatica verbunden sind, kann man den epischen Kampf gegen steigende Java-Threads erwĂ€hnen. Irgendwann kam der Zeitpunkt fĂŒr die Skalierung, also um etablierte Prozesse auf eine groĂe Anzahl von Quellsystemen auszudehnen. Dabei stellte sich heraus, dass lĂ€ngst nicht alle Prozesse in 10.1.1 reibungslos liefen, und nach einer Weile wurde das DIS unbrauchbar. Es wurden zehntausende Threads entdeckt, deren Zahl besonders auffĂ€llig wĂ€hrend des Deployments von Anwendungen anstieg. Manchmal mussten mehrere Neustarts pro Tag durchgefĂŒhrt werden, um die FunktionstĂŒchtigkeit wiederherzustellen.
Hier gilt es, dem Support zu danken; die Probleme wurden relativ schnell lokalisiert und mithilfe von EBF (Emergency Bug Fix) behoben â danach hatte jeder das GefĂŒhl, dass das Tool wirklich funktioniert.
Es funktioniert tatsÀchlich!
Zum Zeitpunkt der Inbetriebnahme im Zielmodus sah Informatica wie folgt aus: Version Informatica 10.1.1HF1 (HF1 ist HotFix1, ein vendor-spezifischer Build aus einer Sammlung von EBFs) mit zusĂ€tzlich installierten EBFs, die unsere Skalierungsprobleme und einige andere behoben, auf einem von drei Servern im GRID, 20 Kerne x86_64 und Speicherung auf einem riesigen, langsamen Array lokaler Festplatten â das ist die Serverkonfiguration fĂŒr den Hadoop-Cluster. Auf einem anderen, identischen Server â die Oracle-Datenbank, mit der sowohl das Informatica-Domain als auch der ETL-Management-Mechanismus arbeiten. All dies wird mit den StandardĂŒberwachungswerkzeugen ĂŒberwacht, die im Team verwendet werden (Zabbix + Grafana), von zwei Seiten â sowohl das Informatica-System mit seinen Diensten als auch die darin laufenden Ladeprozesse. Derzeit hĂ€ngt sowohl die Leistung als auch die StabilitĂ€t der Arbeit, unabhĂ€ngig von externen Faktoren, von den Einstellungen ab, die die Last begrenzen.
Eine besondere ErwĂ€hnung verdient das GRID. Die Umgebung wurde auf drei Knoten aufgebaut, mit der Möglichkeit zur Lastenverteilung. Bei den Tests stellte sich jedoch heraus, dass aufgrund von Interaktionsproblemen zwischen den laufenden Instanzen unserer Anwendungen diese Konfiguration nicht wie erwartet funktionierte. Daher haben wir vorĂŒbergehend entschieden, von diesem Aufbau abzusehen und zwei der drei Knoten aus der DomĂ€ne herauszunehmen. Die Struktur selbst blieb jedoch unverĂ€ndert, und es handelt sich nach wie vor um einen GRID-Dienst, der jedoch auf einen Knoten reduziert wurde.
Derzeit besteht eine Herausforderung im Zusammenhang mit der Leistungsverschlechterung wĂ€hrend der regelmĂ€Ăigen Reinigung der Monitorstruktur. Bei gleichzeitig ablaufenden Prozessen im ETL-Management und laufender Reinigung können Störungen im Betrieb des Steuerungsmechanismus auftreten. Momentan wird dieses Problem »mit einem Workaround« gelöst â durch manuelle Reinigung der Monitorstruktur, wobei alle vorherigen Daten verloren gehen. Dies ist fĂŒr den Produktionsbereich nicht zu kritisch unter normalen Betriebsbedingungen, aber es wird weiterhin nach einer ordentlichen Lösung gesucht.
Aus dieser Situation ergibt sich ein weiteres Problem â gelegentlich kommt es zu mehrfachen AusfĂŒhrungen unseres Steuerungsmechanismus.
Mehrfache Anwendungsstarts, die zu einem Mechanikfehler fĂŒhren
Bei zeitlich geplanten Starts in Zeiten hoher Systembelastung kommt es gelegentlich zu Situationen, die zu einem Mechanikfehler fĂŒhren. Bislang wird das Problem manuell behoben, wĂ€hrend nach einer dauerhaften Lösung gesucht wird.
Insgesamt lĂ€sst sich zusammenfassen, dass es bei hoher Belastung wichtig ist, angemessene Ressourcen zur VerfĂŒgung zu stellen. Dazu gehören sowohl die Hardware-Ressourcen fĂŒr Informatica selbst als auch die fĂŒr das Datenbank-Repository und deren optimale Konfiguration. Zudem bleibt die Frage offen, welches Datenbank-Setup besser ist â auf einem separaten Host oder auf demselben, auf dem die Informatica-Software lĂ€uft. Einerseits wĂ€re es gĂŒnstiger, alles auf einem Server zu betreiben, und bei einer gemeinsamen Nutzung entfĂ€llt praktisch das mögliche Problem der Netzwerkinteraktion. Andererseits bedeutet die Belastung des Hosts durch die Datenbank eine zusĂ€tzliche Last fĂŒr Informatica.
Wie bei jedem ernsthaften Produkt gibt es auch in Informatica kuriose Momente.
Einst, als ich einen Vorfall analysierte, fiel mir auf, dass in den MRS-Protokollen die Zeitstempel der Ereignisse merkwĂŒrdig vermerkt waren.
Der zeitliche Dualismus in den MRS-Protokollen ist âby designâ.
Es stellte sich heraus, dass die Zeitstempel im 12-Stunden-Format ohne AM/PM angegeben werden, also vor oder nach Mittag. Es wurde sogar ein entsprechendes Ticket eröffnet, und die offizielle Antwort lautete â genau so war es geplant, die MRS-Logs werden tatsĂ€chlich in diesem Format aufgezeichnet. Das bedeutet, dass manchmal eine gewisse Spannung hinsichtlich des Zeitpunkts eines ERRORs verbleibtâŠ
Streben nach Besserem
Heute ist Informatica ein ausreichend stabiles Tool, das sowohl fĂŒr Administratoren als auch fĂŒr Anwender bequem ist und ĂŒber aktuelle Möglichkeiten und Potenziale Ă€uĂerst leistungsstark ist. Es ĂŒbertrifft unsere funktionalen BedĂŒrfnisse bei weitem und wird in diesem Projekt nicht auf die typischen und gewohnten Weise genutzt. Die Schwierigkeiten hĂ€ngen teilweise mit der Funktionsweise der Mechanismen zusammen â die Besonderheit ist, dass in kurzer Zeit eine groĂe Anzahl von Threads gestartet wird, die intensiv Parameter-Sets aktualisieren und mit der Datenbank des Repositories arbeiten, wĂ€hrend die Hardware-Ressourcen des Servers nahezu vollstĂ€ndig durch die CPU ausgelastet sind.
Wir stehen kurz vor dem Umstieg auf Informatica 10.2.1 oder 10.2.2, in denen einige internen Mechanismen ĂŒberarbeitet wurden. Der Support verspricht, dass eine Reihe von aktuell bestehenden Leistungs- und Funktionsproblemen nicht mehr auftreten werden. Auch aus hardwaretechnischer Sicht erwarten wir Server in einer fĂŒr uns optimalen Konfiguration, die genĂŒgend Spielraum fĂŒr das zukĂŒnftige Wachstum und die Entwicklung des Speichers bieten.
NatĂŒrlich stehen Tests, KompatibilitĂ€tsprĂŒfungen und möglicherweise architektonische VerĂ€nderungen im Bereich HA GRID an. Die Entwicklung innerhalb von Informatica wird fortschreiten, da wir kurzfristig nichts als Ersatz fĂŒr das bestehende System implementieren können.
Und diejenigen, die in Zukunft fĂŒr dieses System verantwortlich sein werden, werden es sicherlich schaffen, die erforderlichen Standards in Bezug auf ZuverlĂ€ssigkeit und Leistung, die von den Kunden gefordert werden, zu erreichen.
Dieser Artikel wurde vom Datenmanagement-Team von "Rostelecom" erstellt.
Aktuelles Informatica-Logo
Quelle: habr.com
