Die ETL-Komponente des Data Warehouses steht oft im Schatten des eigentlichen Data Warehouses und erhĂ€lt weniger Aufmerksamkeit als die Hauptdatenbank oder die Front-Komponente, BI, bei der Erstellung von Berichten. Dabei spielt ETL aus mechanischer Sicht eine SchlĂŒsselrolle bei der BefĂŒllung des Data Warehouses und erfordert nicht weniger Aufmerksamkeit von den Administratoren als die anderen Komponenten. Mein Name ist Alexander, derzeit administriere ich ETL bei Rostelecom, und in diesem Artikel werde ich versuchen, ein wenig zu teilen, mit was ein Administrator eines der bekanntesten ETL-Systeme in einem groĂen Data Warehouse von Rostelecom konfrontiert ist.
Wenn die geschĂ€tzten Leser bereits allgemein 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 Unternehmens-Data Warehouses und wurde konkret umgesetzt. Eine Reihe von Data Warehouses, die einzelne Aufgaben lösen, war bereits geschaffen worden, doch die Anzahl der Szenarien wuchs, die Kosten fĂŒr die UnterstĂŒtzung nahmen ebenso zu, und es wurde klar, dass die Zukunft in der Zentralisierung liegt. Architektonisch besteht dieses Data Warehouse aus mehreren Schichten, die auf Hadoop und GreenPlum realisiert sind, einschlieĂlich unterstĂŒtzender Datenbanken, ETL-Mechanismen und BI.
Aufgrund der Vielzahl von geografisch verteilten, heterogenen Datenquellen wurde ein spezieller Mechanismus zur Datenextraktion geschaffen, dessen Arbeiten von Informatica gesteuert werden. Infolgedessen gelangen die Datenpakete in den Schnittstellenbereich von Hadoop, nach dem die Prozesse zur Beladung der Daten durch die Schichten des Data Warehouses, in Hadoop und GreenPlum, beginnen, die durch den sogenannten Steuermechanismus ETL, der in Informatica implementiert ist, verwaltet werden. Somit ist das System Informatica eines der SchlĂŒsselelemente, das den Betrieb des Data Warehouses sichert.
In einem der nĂ€chsten BeitrĂ€ge wird ausfĂŒhrlicher ĂŒber unser Data Warehouse berichtet.
Informatica PowerCenter/BIG Data Management gilt derzeit als die fĂŒhrende Software im Bereich der Datenintegrationswerkzeuge. Es handelt sich um ein Produkt des amerikanischen Unternehmens Informatica, das zu den stĂ€rksten Akteuren im Bereich ETL (Extract Transform Load), DatenqualitĂ€tsmanagement, MDM (Master Data Management), ILM (Information Lifecycle Management) und mehr gehört.
Der von uns verwendete PowerCenter ist ein integrierter Tomcat-Anwendungsserver, auf dem die Informatica-Anwendungen laufen, die deren Dienste bereitstellen:
Domain, im Grunde genommen ist dies die Grundlage fĂŒr alles Weitere: Innerhalb der DomĂ€ne arbeiten Dienste, Benutzer und GRID-Komponenten.
Administrator-Konsole, ein webbasiertes Management- und Ăberwachungstool, neben dem Informatica Developer Client das Hauptwerkzeug fĂŒr die Interaktion mit dem Produkt.
MRS, Modell-Repository-Dienst, ein Metadatenrepository, das eine Schicht zwischen der Datenbank, in der die Metadaten physisch gespeichert werden, und dem Informatica Developer Client, in dem die Entwicklung erfolgt, darstellt. Die Repositories speichern sowohl die Datenbeschreibung als auch andere Informationen, unter anderem fĂŒr verschiedene andere Informatica-Dienste, wie z. B. ZeitplĂ€ne fĂŒr die AusfĂŒhrung von Aufgaben (Schedules) oder Ăberwachungsdaten sowie Parametersets von Anwendungen, insbesondere solche, die es ermöglichen, dass dasselbe Anwendung fĂŒr verschiedene Datenquellen und -senken verwendet wird.
DIS, Datenintegrationsdienst, dies ist der Dienst, in dem die wesentlichen funktionalen Prozesse stattfinden, in dem Anwendungen laufen und tatsÀchlich Workflows (Beschreibungen der Sequenz von Mappings und deren Interaktion) und Mappings (Transformationen, Blöcke, in denen die tatsÀchlichen Umwandlungen und die Datenverarbeitung stattfinden) gestartet werden.
GRID-Konfiguration â im Grunde genommen eine Variante des Aufbaus eines komplexen Systems unter Verwendung mehrerer Server, bei der die Last, die vom DIS gestartet wird, auf Nodes (d.h. Server, die Teil der DomĂ€ne sind) verteilt wird. In einem solchen Szenario, neben der Lastenverteilung im DIS durch eine zusĂ€tzliche Abstraktionsschicht GRID, die mehrere Nodes vereint, auf der das DIS arbeitet, anstatt auf einem bestimmten Node, können auch zusĂ€tzliche Backup-Instanzen von MRS erstellt werden. Es kann sogar eine hohe VerfĂŒgbarkeit implementiert werden, bei der externe Anfragen ĂŒber Backup-Nodes bei Ausfall des Haupt-Nodes erfolgen können. Von dieser Art der Einrichtung haben wir jedoch vorerst Abstand genommen.
Informatica PowerCenter, schematisch
In den ersten Phasen der Arbeit innerhalb der Datenlieferkette traten regelmĂ€Ăig Probleme auf, teilweise aufgrund der damals instabilen Funktionsweise von Informatica. Ich beabsichtige, einige der einprĂ€gsamen Momente dieser Saga â der Einarbeitung in Informatica 10 â zu teilen.
Das frĂŒhere Logo von Informatica
Der Verantwortungsbereich unserer Abteilung umfasst auch andere Informatica-Umgebungen, die aufgrund anderer Anforderungen und Belastungen eine eigene Spezifik haben. Ich werde dabei zunÀchst darauf eingehen, wie sich Informatica als ETL-Komponente des Data Warehouses entwickelt hat.
Wie ist das passiert?
Im Jahr 2016, als wir fĂŒr die Arbeit mit Informatica verantwortlich wurden, hatte sie bereits die Version 10.0 erreicht. FĂŒr optimistisch eingestellte Kollegen, die ĂŒber den Einsatz des Produkts mit einer Minor-Version .0 entschieden, schien es klar zu sein: Wir mĂŒssen die neue Version verwenden! Was die Hardware-Ressourcen betrifft, war alles zu diesem Zeitpunkt hervorragend.
Seit dem FrĂŒhling 2016 war ein Auftragnehmer fĂŒr die Arbeit mit Informatica verantwortlich, und nach den Aussagen der wenigen Systembenutzer "lief es ein paar Mal in der Woche". Hier muss erklĂ€rt werden, dass das Warehouse de facto in einer PoC-Phase war, es gab keine Administratoren im Team und das System fiel aus verschiedenen GrĂŒnden stĂ€ndig aus, was dazu fĂŒhrte, dass der Ingenieur des Auftragnehmers es immer wieder neu hochfahren musste.
Im Herbst stieĂen drei Administratoren zum Team, die die Verantwortungsbereiche untereinander aufteilten, und begannen, den Betrieb der Systeme im Projekt, einschlieĂlich Informatica, zu stabilisieren. Es sollte erwĂ€hnt werden, dass dieses Produkt nicht weit verbreitet ist und keine groĂe Community hat, in der man Antworten auf Fragen finden und Probleme lösen kann. Daher war eine umfassende technische UnterstĂŒtzung durch den russischen Partner von Informatica von entscheidender Bedeutung, mit deren Hilfe wir all unsere Fehler sowie die der damals noch neuen Informatica 10 beheben konnten.
Das Erste, was wir fĂŒr unsere Entwickler und den Auftragnehmer tun mussten, war, die FunktionalitĂ€t von Informatica zu stabilisieren und die Web-Administrationskonsole (Informatica Administrator) betriebsbereit zu machen.
So trafen wir oft auf die Entwickler von Informatica.
Abgesehen vom Prozess der Ursachenforschung war der Hauptgrund fĂŒr die AbstĂŒrze das Zusammenspiel der Informatica-Software mit der Datenbank des Repositories, das sich auf einem vergleichsweise entfernten Server im Hinblick auf die Netzwerktopologie befand. Dies fĂŒhrte zu Verzögerungen und störte die Mechanismen, die fĂŒr die Ăberwachung des Status der Informatica-DomĂ€ne zustĂ€ndig waren. Nach einigen Anpassungen der Datenbank und Ănderungen der Einstellungen in Informatica, die sie toleranter gegenĂŒber Datenbankverzögerungen machten, sowie dem Upgrade auf die Version Informatica 10.1 und dem Umzug der Datenbank von dem vorherigen Server auf einen nĂ€her zur Informatica gelegenen Server verlor das Problem an Relevanz, und seitdem beobachten wir keine AbstĂŒrze Ă€hnlicher Art mehr.
Ein Versuch, den Informatica-Monitor zum Laufen zu bringen
Die Situation mit der Administrationskonsole war ebenfalls kritisch. Da aktiv auf einer bedingt produktiven Umgebung entwickelt wurde, mussten die Kollegen stĂ€ndig die AusfĂŒhrung von Mappings und Workflows "live" analysieren. In der neuen Informatica gibt es im Data Integration Service kein separates Werkzeug fĂŒr diese Art der Ăberwachung, aber in der Web-Administrationskonsole wurde ein Ăberwachungsbereich (Informatica Administrator Monitor) hinzugefĂŒgt, in dem man die AusfĂŒhrung von Anwendungen, Workflows und Mappings, Starts und Logs beobachten kann. Periodisch wurde die Konsole vollstĂ€ndig unerreichbar, oder die Informationen ĂŒber die aktuellen Prozesse im DIS wurden nicht aktualisiert, oder es traten Fehler beim Laden von Seiten auf.
Anpassung der Java-Parameter zur Stabilisierung des Betriebs
Die Problemlösung erfolgte auf vielen Wegen; es wurden Experimente zur Ănderung von Parametern durchgefĂŒhrt, Logs und Jstack wurden gesammelt und an den Support gesendet, wĂ€hrend parallel intensiv gegoogelt und einfach beobachtet wurde.
ZunĂ€chst wurde ein separates MRS zur Ăberwachung erstellt. Wie sich spĂ€ter herausstellte, ist das einer der Hauptressourcenverbraucher in unseren Umgebungen, da die AusfĂŒhrungen der Mappings sehr intensiv sind. Die Parameter bezĂŒglich des Java-Heaps und einige andere wurden angepasst.
Infolge dessen gelang es, bis zum nĂ€chsten Update von Informatica 10.1.1 die Konsole und den Monitor zu stabilisieren. Die Entwickler arbeiteten effizienter, und die regelmĂ€Ăigen Prozesse wurden zunehmend regelmĂ€Ăiger.
Eine interessante Erfahrung kann die Interaktion zwischen Entwicklung und Administration sein. Das VerstĂ€ndnis dafĂŒr, wie alles funktioniert, was man tun kann und was nicht, ist immer wichtig, wenn man komplexe Systeme verwendet. Daher sollte man zunĂ€chst das Team der Administratoren in der Softwareadministration und das Entwicklerteam im Schreiben von Code und der Modellierung von Prozessen schulen, bevor man sie zu einem konkreten Ergebnis arbeiten lĂ€sst. Dies ist besonders wichtig, wenn die Zeit kein unendlicher Ressource ist. Viele Probleme lassen sich sogar durch zufĂ€llige Variationen lösen, aber manchmal erfordern bestimmte Herausforderungen ein vorausgehendes Wissen â unser Fall bestĂ€tigt die Bedeutung dieses Axioms.
Beispielsweise haben wir bei dem Versuch, die Versionierung in MRS zu aktivieren (wie sich herausstellte, benötigten wir eine andere Version von SVN), nach einiger Zeit mit Besorgnis festgestellt, dass die Zeit fĂŒr den Systemneustart auf mehrere Minuten angestiegen war. Nachdem wir der Ursache fĂŒr die Verzögerung auf den Grund gegangen und die Versionierung abgeschaltet hatten, lief es wieder gut.
Zu den auffĂ€lligen Hindernissen im Zusammenhang mit Informatica kann man den epischen Kampf mit den wachsenden Java-Threads erwĂ€hnen. Irgendwann kam der Moment des Rollouts, also die Verbreitung der etablierten Prozesse auf eine groĂe Anzahl von Quellsystemen. Dabei stellte sich heraus, dass nicht alle Prozesse in 10.1.1 gut funktionierten und DIS nach einer gewissen Zeit nicht mehr funktionierte. Dutzende von Tausenden von Threads wurden entdeckt, deren Anzahl insbesondere wĂ€hrend des Anwendungsdeployments spĂŒrbar anstieg. Manchmal mussten wir mehrmals am Tag neu starten, um die FunktionsfĂ€higkeit wiederherzustellen.
Hier gilt es, der UnterstĂŒtzung zu danken, da die Probleme vergleichsweise schnell lokalisiert und mit Hilfe von EBF (Emergency Bug Fix) behoben wurden â danach hatten alle das GefĂŒhl, dass das Werkzeug tatsĂ€chlich funktioniert.
Es funktioniert tatsÀchlich!
Zum Zeitpunkt des Beginns der Arbeit im Zielmodus sah Informatica wie folgt aus. Version Informatica 10.1.1HF1 (HF1 ist HotFix1, von einem Anbieter aus dem EBF-Komplex) mit zusĂ€tzlich installierten EBF, die unsere Skalierungsprobleme und einige andere behoben haben, auf einem von drei Servern im GRID, 20 Kerne x86_64 und Speicher auf einem riesigen langsamen Array von lokalen Festplatten â das Serverkonfiguration fĂŒr das Hadoop-Cluster. Auf einem anderen, Ă€hnlichen Server lĂ€uft die Oracle-Datenbank, mit der sowohl die Informatica-Domain als auch der ETL-Managementmechanismus verbunden sind. All dies wird mit den ĂŒblichen Monitoring-Tools ĂŒberwacht, die im Team verwendet werden (Zabbix + Grafana), erwĂ€hnt werden hier beide Seiten â sowohl die Informatica selbst mit ihren Services als auch die laufenden Ladeprozesse. Momentan hĂ€ngen die Leistung und die StabilitĂ€t der Arbeit, ohne externe Faktoren zu berĂŒcksichtigen, von den Einstellungen ab, die die Last begrenzen.
Separat kann man ĂŒber das GRID sprechen. Die Umgebung wurde auf drei Knoten aufgebaut, mit der Möglichkeit, die Last zu verteilen. Bei Tests wurde jedoch festgestellt, dass aufgrund von Interaktionsproblemen zwischen den laufenden Instanzen unserer Anwendungen diese Konfiguration nicht wie erwartet funktionierte, und wir entschieden uns vorĂŒbergehend, von diesem Aufbauschema abzusehen, indem wir zwei von drei Knoten aus der Domain herausnahmen. Das Schema blieb jedoch unverĂ€ndert, und jetzt handelt es sich tatsĂ€chlich um einen GRID-Service, der jedoch auf einen Knoten degeneriert ist.
Aktuell bleibt die Schwierigkeit bestehen, die mit der Leistungsabnahme bei der regelmĂ€Ăigen Reinigung des Monitor-Schemas verbunden ist â wenn gleichzeitig Prozesse im CHNN laufen und die Reinigung lĂ€uft, kann es zu Störungen im ETL-Managementmechanismus kommen. Dies wird bisher "hacky" gelöst â durch manuelle Reinigung des Monitor-Schemas, wobei alle vorherigen Daten verloren gehen. Dies ist nicht allzu kritisch fĂŒr die Produktion, solange die regulĂ€re Arbeit gut funktioniert, aber wir suchen weiterhin nach einer soliden Lösung.
Aus dieser Situation ergibt sich ein weiteres Problem â es kommt manchmal zu mehrfachen Starts unseres Managementmechanismus.
Mehrfache Starts der Anwendung fĂŒhren zu Störungen des Mechanismus.
Beim geplanten Start zu Zeiten hoher Systemlast kommt es manchmal zu Situationen, die zu Störungen des Mechanismus fĂŒhren. Bisher wird das Problem manuell behoben, es wird eine dauerhafte Lösung gesucht.
Insgesamt lĂ€sst sich zusammenfassen, dass es bei hoher Belastung sehr wichtig ist, angemessene Ressourcen bereitzustellen, sowohl fĂŒr die Informatica-Software als auch fĂŒr ihr Datenbank-Repository, und dafĂŒr optimale Einstellungen zu gewĂ€hrleisten. DarĂŒber hinaus bleibt die Frage offen, welches Schema fĂŒr die Bereitstellung der Datenbank besser ist â auf einem separaten Host oder auf dem gleichen, auf dem die Informatica-Software lĂ€uft. Einerseits wird es gĂŒnstiger, auf einem Server zu arbeiten, und durch die Kombination wird das mögliche Problem der Netzwerkinteraktion praktisch beseitigt, andererseits wird die Belastung des Hosts durch die Datenbank zusĂ€tzlich durch die Informatica-Software verstĂ€rkt.
Wie bei jedem seriösen Produkt gibt es auch in Informatica kurvenreiche Momente.
Einmal, als ich einen Vorfall untersuchte, fiel mir auf, dass die Zeitstempel in den MRS-Logs merkwĂŒrdig vermerkt waren.
Zeitlicher Dualismus in den MRS-Logs âby designâ
Es stellte sich heraus, dass die Zeitstempel im 12-Stunden-Format ohne Angabe von AM/PM geschrieben werden, also vor oder nach Mittag. Es wurde sogar ein Ticket zu diesem Thema eröffnet, und die offizielle Antwort lautete: Es war so vorgesehen, die Zeitstempel in den MRS-Logs werden genau in diesem Format geschrieben. Das lĂ€sst manchmal ein wenig RĂ€tselraten darĂŒber ĂŒbrig, wann genau ein ERROR aufgetreten istâŠ
Streben nach Verbesserung
Heute ist Informatica ein ziemlich stabiles Werkzeug, das sowohl fĂŒr Administratoren als auch fĂŒr Benutzer bequem ist und Ă€uĂerst leistungsstark in seinen aktuellen Möglichkeiten und Potenzialen. Es ĂŒbersteigt funktional unsere BedĂŒrfnisse bei Weitem und wird de facto derzeit nicht in der typischen und charakteristischen Weise im Projekt eingesetzt. Die Schwierigkeiten hĂ€ngen teilweise damit zusammen, wie die Mechanismen arbeiten â die Besonderheit liegt darin, dass in kurzer Zeit eine groĂe Anzahl von Threads gestartet wird, die intensiv Parameter-Sets aktualisieren und mit dem Datenbank-Repository arbeiten, wĂ€hrend die Hardware-Ressourcen des Servers fast vollstĂ€ndig ausgelastet sind.
Jetzt stehen wir kurz vor dem Wechsel zu Informatica 10.2.1 oder 10.2.2, in denen einige interne Mechanismen ĂŒberarbeitet wurden, und der Support verspricht, dass eine Reihe der derzeit bei uns bestehenden Leistungs- und Funktionsprobleme behoben werden. Auch aus hardwaretechnischer Sicht werden Server unserer optimalen Konfiguration erwartet, wobei ein Puffer fĂŒr die nahe Zukunft aufgrund des Wachstums und der Entwicklung des Speichers berĂŒcksichtigt wird.
NatĂŒrlich stehen Tests, die ĂberprĂŒfung der KompatibilitĂ€t und möglicherweise architektonische Ănderungen im Bereich HA GRID an. Die Weiterentwicklung im Rahmen von Informatica wird fortgesetzt, da wir kurzfristig nichts als Ersatz fĂŒr das System bereitstellen können.
Diejenigen, die in Zukunft fĂŒr dieses System verantwortlich sein werden, werden es sicher schaffen, die geforderten ZuverlĂ€ssigkeits- und Leistungskennzahlen der Kunden zu erreichen.
Der Artikel wurde vom Datenmanagement-Team von "Rostelecom" vorbereitet
Das aktuelle Logo von Informatica
Quelle: habr.com
