Die ETL-Komponente des Data Warehouse steht oft im Schatten des Warehouse selbst und erhält weniger Aufmerksamkeit als die Hauptdatenbank oder Front-End-Komponente, BI und Reporting. Gleichzeitig spielt ETL aus Sicht der Mechanismen zum Füllen des Lagers mit Daten eine Schlüsselrolle und erfordert von Administratoren nicht weniger Aufmerksamkeit als andere Komponenten. Mein Name ist Alexander, ich verwalte jetzt ETL bei Rostelecom und in diesem Artikel werde ich versuchen, ein wenig davon zu erzählen, womit der Administrator eines der bekanntesten ETL-Systeme in einem großen Data Warehouse bei Rostelecom zu kämpfen hat.
Wenn Sie, liebe Leserinnen und Leser, bereits allgemein mit unserem Data-Warehouse-Projekt und dem Produkt Informatica PowerCenter vertraut sind, dann können Sie gleich zum nächsten Abschnitt übergehen.
Vor einigen Jahren reifte die Idee eines einzigen Unternehmens-Data-Warehouses und begann mit der Umsetzung bei Rostelecom. Es waren bereits mehrere Repositories entstanden, die einzelne Probleme lösten, doch die Anzahl der Szenarien wuchs, auch die Supportkosten stiegen und es wurde klar, dass die Zukunft in der Zentralisierung lag. Architektonisch gesehen ist dies der Speicher selbst, bestehend aus mehreren Schichten, implementiert auf Hadoop und GreenPlum, Hilfsdatenbanken, ETL-Mechanismen und BI.
Gleichzeitig wurde aufgrund der Vielzahl geografisch verteilter, heterogener Datenquellen ein spezieller Daten-Upload-Mechanismus geschaffen, dessen Betrieb von Informatica gesteuert wird. Infolgedessen landen Datenpakete im Hadoop-Schnittstellenbereich, woraufhin die Prozesse des Ladens von Daten über Speicherschichten, Hadoop und GreenPlum beginnen und durch den sogenannten ETL-Kontrollmechanismus verwaltet werden, der in Informatica implementiert ist. Somit ist das Informatica-System eines der Schlüsselelemente, die den Betrieb des Lagers sicherstellen.
Unsere Speicherung wird in einem der folgenden Beiträge genauer beschrieben.
Informatica PowerCenter/Big Data Management gilt derzeit als die führende Software im Bereich Datenintegrationstools. Dabei handelt es sich um ein Produkt des amerikanischen Unternehmens Informatica, das zu den stärksten Playern in den Bereichen ETL (Extract Transform Load), Datenqualitätsmanagement, MDM (Master Data Management), ILM (Information Lifecycle Management) und mehr zählt.
Das von uns verwendete PowerCenter ist ein integrierter Tomcat-Anwendungsserver, auf dem die Informatica-Anwendungen selbst ausgeführt werden und dessen Dienste implementiert:
DomainTatsächlich ist dies die Grundlage für alles andere: Dienste, Benutzer und GRID-Komponenten arbeiten innerhalb der Domäne.
Administratorkonsole, ein webbasiertes Verwaltungs- und Überwachungstool, zusätzlich zum Informatica Developer-Client, dem Haupttool für die Interaktion mit dem Produkt
MRS, Model Repository Service, ein Metadaten-Repository, ist eine Schicht zwischen der Datenbank, in der Metadaten physisch gespeichert werden, und dem Informatica Developer-Client, in dem die Entwicklung stattfindet. In Repositorys werden Datenbeschreibungen und andere Informationen gespeichert, darunter auch für eine Reihe anderer Infromatica-Dienste, beispielsweise Zeitpläne für die Ausführung von Aufgaben (Schedules) oder Überwachungsdaten sowie insbesondere Anwendungsparameter, die die Verwendung derselben Anwendung für die Arbeit ermöglichen verschiedene Datenquellen und Empfänger.
DIS, DatenintegrationsdienstHierbei handelt es sich um einen Dienst, in dem die wichtigsten Funktionsprozesse ablaufen, Anwendungen darin ausgeführt werden und die eigentlichen Starts von Workflows (Beschreibungen der Abfolge von Mappings und ihrer Interaktionen) und Mappings (Transformationen, Blöcke, in denen die Transformationen selbst stattfinden, Datenverarbeitung) erfolgen ) stattfinden.
GRID-Konfiguration – im Wesentlichen eine Option zum Aufbau eines Komplexes mit mehreren Servern, bei der die von DIS gestartete Last auf die Knoten (d. h. Server, die Teil der Domäne sind) verteilt wird. Bei dieser Option können neben der Lastverteilung im DIS durch eine zusätzliche GRID-Abstraktionsschicht, die mehrere Knoten vereint, auf der DIS läuft, anstatt auf einem bestimmten einzelnen Knoten zu arbeiten, auch zusätzliche Backup-MRS-Instanzen erstellt werden. Sie können sogar Hochverfügbarkeit implementieren, bei der externe Anrufe über Backup-Knoten getätigt werden können, wenn der Hauptknoten ausfällt. Auf diese Bauvariante haben wir vorerst verzichtet.
Informatica PowerCenter, schematisch
In den frühen Phasen der Arbeit als Teil der Datenlieferkette kam es regelmäßig zu Problemen, teilweise aufgrund des zu diesem Zeitpunkt instabilen Betriebs von Informatica. Ich werde einige der denkwürdigsten Momente dieser Saga teilen – das Beherrschen von Informatica 10.
Ehemaliges Informatica-Logo
Unser Verantwortungsbereich umfasst auch andere Informatica-Umgebungen, diese haben aufgrund einer anderen Auslastung ihre eigenen Besonderheiten, aber ich werde mich vorerst genau daran erinnern, wie sich Informatica als ETL-Komponente des Data Warehouse selbst entwickelt hat.
Wie ist es passiert
Als wir 2016 die Verantwortung für die Arbeit von Informatica übernahmen, hatte es bereits Version 10.0 erreicht, und für optimistische Kollegen, die sich entschieden, ein Produkt mit einer Nebenversion .0 in einer ernsthaften Lösung zu verwenden, schien alles klar – wir müssen es verwenden die neue Version! Aus Sicht der Hardware-Ressourcen war damals alles in Ordnung.
Seit Frühjahr 2016 ist ein Auftragnehmer für die Arbeit von Informatica verantwortlich und laut den wenigen Nutzern des Systems „funktionierte es ein paar Mal pro Woche“. Hier muss klargestellt werden, dass sich das Repository de facto im PoC-Stadium befand, es keine Administratoren im Team gab und das System aus verschiedenen Gründen ständig abstürzte, woraufhin der Ingenieur des Auftragnehmers es wieder in Betrieb nahm.
Im Herbst schlossen sich dem Team drei Administratoren an, die ihre Verantwortungsbereiche untereinander aufteilten, und die normale Arbeit begann, den Betrieb der Systeme im Projekt, einschließlich Informatica, zu organisieren. Unabhängig davon muss gesagt werden, dass dieses Produkt nicht weit verbreitet ist und über eine große Community verfügt, in der Sie Antworten auf alle Fragen finden und jedes Problem lösen können. Daher war die volle technische Unterstützung durch den russischen Partner Informatica sehr wichtig, mit deren Hilfe alle unsere Fehler und Fehler der damals jungen Informatica 10 korrigiert wurden.
Das erste, was wir für die Entwickler unseres Teams und den Auftragnehmer tun mussten, bestand darin, die Arbeit von Informatica selbst zu stabilisieren, um die Funktionalität der Webverwaltungskonsole (Informatica Administrator) sicherzustellen.
So haben wir oft Informatica-Entwickler getroffen
Abgesehen von der Ursachenforschung war der Hauptgrund für die Abstürze das Interaktionsmuster der Informatica-Software mit der Repository-Datenbank, die sich aus Sicht der Netzwerklandschaft auf einem relativ entfernten Server befand. Dies führte zu Verzögerungen und störte die Mechanismen, die den Status der Informatica-Domäne überwachen. Nach einer gewissen Optimierung der Datenbank, einer Änderung der Parameter von Informatica, wodurch Datenbankverzögerungen toleranter wurden, und schließlich einer Aktualisierung der Informatica-Version auf 10.1 und der Übertragung der Datenbank vom vorherigen Server auf einen Server, der näher an Informatica liegt, verschwand das Problem Relevanz, und seitdem gab es Abstürze dieser Art, die wir nicht beobachten.
Einer der Versuche, Informatica Monitor zum Laufen zu bringen
Kritisch war auch die Situation mit der Administrationskonsole. Da die aktive Entwicklung direkt in der relativ produktiven Umgebung stattfand, mussten die Kollegen ständig die Arbeit von Mappings und Workflows „unterwegs“ analysieren. Im neuen Informatica verfügt der Data Integration Service nicht über ein separates Tool für eine solche Überwachung, aber in der Administrations-Webkonsole ist ein Überwachungsbereich (Informatica Administrator Monitor) erschienen, in dem Sie den Betrieb von Anwendungen, Arbeitsabläufen und Zuordnungen überwachen können. Starts, Protokolle. In regelmäßigen Abständen war die Konsole vollständig nicht verfügbar, Informationen zu aktuellen Prozessen in DIS wurden nicht mehr aktualisiert oder es traten Fehler beim Laden von Seiten auf.
Auswahl von Java-Parametern zur Stabilisierung des Betriebs
Das Problem wurde in vielerlei Hinsicht behoben, es wurden Experimente zur Änderung von Parametern durchgeführt, Protokolle und Jstack wurden gesammelt, an den Support gesendet, gleichzeitig wurde aktiv gegoogelt und einfach beobachtet.
Zunächst wurde ein separates MRS für die Überwachung erstellt; wie sich später herausstellte, ist dies einer der Hauptressourcenverbraucher in unseren Umgebungen, da Mappings sehr intensiv gestartet werden. Parameter bezüglich Java-Heap und einer Reihe anderer wurden geändert.
Infolgedessen wurde mit dem nächsten Update Informatica 10.1.1 der Betrieb der Konsole und des Monitors stabilisiert, die Entwickler begannen effizienter zu arbeiten und regelmäßige Prozesse wurden immer regelmäßiger.
Die Erfahrung der Interaktion zwischen Entwicklung und Verwaltung kann interessant sein. Beim Umgang mit komplexen Systemen ist immer die Frage nach einem allgemeinen Verständnis darüber wichtig, wie Dinge funktionieren, was getan werden kann und was nicht. Daher können wir mit Sicherheit empfehlen, dass Sie zunächst das Verwaltungsteam in der Verwaltung der Software und das Entwicklungsteam darin schulen, wie man Code schreibt und Prozesse im System zeichnet, und erst dann das erste und zweite Team mit der Arbeit am Ergebnis beauftragen. Dies ist wirklich wichtig, wenn Zeit keine unendliche Ressource ist. Viele Probleme können sogar durch eine zufällige Suche nach Optionen gelöst werden, aber manchmal erfordern einige A-priori-Kenntnisse – unser Fall bestätigt, wie wichtig es ist, dieses Axiom zu verstehen.
Als wir beispielsweise versuchten, die Versionierung in MRS zu aktivieren (wie sich am Ende herausstellte, war eine andere Version von SVN erforderlich), stellten wir nach einiger Zeit alarmiert fest, dass sich die Systemneustartzeit auf mehrere zehn Minuten erhöht hatte. Nachdem wir den Grund für die Verzögerung beim Start und die Deaktivierung der Versionierung gefunden hatten, haben wir es wieder gut gemacht.
Zu den bemerkenswerten Hindernissen im Zusammenhang mit Informatica gehört der epische Kampf mit wachsenden Java-Threads. Irgendwann ist die Zeit gekommen für die Replikation, also die Ausweitung der etablierten Prozesse auf eine Vielzahl von Quellsystemen. Es stellte sich heraus, dass nicht alle Prozesse in 10.1.1 gut funktionierten und DIS nach einiger Zeit nicht mehr funktionsfähig war. Es wurden Zehntausende Threads entdeckt, deren Zahl insbesondere während der Anwendungsbereitstellung deutlich zunahm. Manchmal musste ich mehrmals am Tag neu starten, um die Funktionalität wiederherzustellen.
An dieser Stelle ist dem Support zu danken, die Probleme wurden mittels EBF (Emergency Bug Fix) relativ schnell lokalisiert und behoben – danach hatte jeder das Gefühl, dass das Tool wirklich funktioniert.
Es funktioniert noch!
Als wir begannen, im Zielmodus zu arbeiten, sah Informatica so aus. Version von Informatica 10.1.1HF1 (HF1 ist HotFix1, eine Herstellerbaugruppe aus einem Komplex von EBFs) mit zusätzlich installiertem EBF, das unsere Probleme mit der Skalierung und einigen anderen behebt, auf einem von drei Servern, die Teil von GRID waren, 20 x86_64-Kerne und Speicherung auf einem riesigen, langsamen Array lokaler Festplatten – das ist die Serverkonfiguration für einen Hadoop-Cluster. Auf einem anderen ähnlichen Server – dem Oracle DBMS, mit dem sowohl die Informatica-Domäne als auch der ETL-Kontrollmechanismus funktionieren. All dies wird durch Standard-Überwachungstools überwacht, die im Team (Zabbix + Grafana) auf beiden Seiten verwendet werden – Informatica selbst mit seinen Diensten und den darin ablaufenden Ladevorgängen. Jetzt hängen sowohl Leistung als auch Stabilität, ohne Berücksichtigung externer Faktoren, von den Einstellungen ab, die die Last begrenzen.
Unabhängig davon können wir etwas über GRID sagen. Die Umgebung wurde auf drei Knoten aufgebaut, mit der Möglichkeit des Lastausgleichs. Beim Testen wurde jedoch festgestellt, dass diese Konfiguration aufgrund von Interaktionsproblemen zwischen den laufenden Instanzen unserer Anwendungen nicht wie erwartet funktionierte, und man entschied sich, dieses Konstruktionsschema vorübergehend aufzugeben und zwei der drei Knoten aus der Domäne zu entfernen. Gleichzeitig ist das Schema selbst gleich geblieben, und jetzt handelt es sich genau um einen GRID-Dienst, der jedoch zu einem Knoten degeneriert ist.
Derzeit ist die Schwierigkeit weiterhin mit einem Leistungsabfall bei regelmäßiger Reinigung des Monitorschaltkreises verbunden – bei gleichzeitigen Prozessen im CNN und laufender Reinigung kann es zu Fehlfunktionen im Betrieb des ETL-Steuerungsmechanismus kommen. Dies wird derzeit „als Krücke“ gelöst – durch manuelles Löschen des Überwachungsschaltkreises, wobei alle vorherigen Daten verloren gehen. Dies ist für die Produktivität im normalen Routinebetrieb nicht allzu kritisch, aber derzeit wird nach einer normalen Lösung gesucht.
Ein weiteres Problem ergibt sich aus derselben Situation: Manchmal kommt es zu mehreren Starts unseres Kontrollmechanismus.
Mehrere Anwendungsstarts führen zu einem Mechanismusfehler
Bei einem planmäßigen Betrieb kommt es in Zeiten hoher Systembelastung manchmal zu Situationen, die zum Ausfall des Mechanismus führen. Das Problem wird noch manuell behoben und es wird nach einer dauerhaften Lösung gesucht.
Generell lässt sich zusammenfassen, dass es bei hoher Auslastung sehr wichtig ist, entsprechende Ressourcen bereitzustellen, dies gilt auch für Hardware-Ressourcen für Informatica selbst und das Gleiche für das Datenbank-Repository sowie für optimale Einstellungen für Sie. Darüber hinaus bleibt die Frage offen, welches Datenbankplatzierungsschema besser ist – auf einem separaten Host oder auf demselben Host, auf dem die Informatica-Software ausgeführt wird. Einerseits ist es auf einem Server günstiger und in der Kombination wird das mögliche Problem der Netzwerkinteraktion praktisch eliminiert; andererseits wird die Belastung des Hosts durch die Datenbank durch die Belastung durch Informatica ergänzt.
Wie bei jedem seriösen Produkt gibt es auch bei Informatica lustige Momente.
Als ich einmal einen Unfall aufklärte, bemerkte ich, dass in den MRS-Protokollen seltsamerweise der Zeitpunkt der Ereignisse angegeben war.
Zeitlicher Dualismus in MRS-Protokollen „beabsichtigt“
Es stellte sich heraus, dass Zeitstempel im 12-Stunden-Format geschrieben werden, ohne Angabe von AM/PM, also vor Mittag oder danach. Es wurde sogar ein Antrag zu dieser Angelegenheit gestellt und eine offizielle Antwort erhalten – so war es beabsichtigt, Noten werden in genau diesem Format in das MRS-Protokoll geschrieben. Das heißt, manchmal bleibt die Frage nach dem Zeitpunkt des Auftretens eines FEHLERs unklar ...
Streben Sie nach dem Besten
Heutzutage ist Informatica ein ziemlich stabiles Tool, praktisch für Administratoren und Benutzer, äußerst leistungsstark im Hinblick auf seine aktuellen Fähigkeiten und sein Potenzial. Es übertrifft unsere funktionalen Anforderungen um ein Vielfaches und wird im Projekt nun de facto auf eine Art und Weise eingesetzt, die nicht die typischste und typischste ist. Die Schwierigkeiten hängen teilweise mit der Funktionsweise der Mechanismen zusammen – das Besondere ist, dass in kurzer Zeit eine große Anzahl von Threads gestartet wird, die intensiv Parameter aktualisieren und mit der Repository-Datenbank arbeiten, während die Hardwareressourcen des Servers fast vollständig ausgelastet sind durch die CPU.
Wir stehen nun kurz vor der Umstellung auf Informatica 10.2.1 oder 10.2.2, bei denen einige der internen Mechanismen und Supportversprechen überarbeitet wurden, um einige unserer aktuellen Leistungs- und Funktionsprobleme zu beseitigen. Und aus Hardware-Sicht erwarten wir für uns Server mit einer optimalen Konfiguration, unter Berücksichtigung der Reserve für die nahe Zukunft aufgrund des Speicherwachstums und der Speicherentwicklung.
Natürlich wird es im HA GRID-Teil Tests, Kompatibilitätsprüfungen und möglicherweise Architekturänderungen geben. Die Entwicklung innerhalb von Informatica wird fortgesetzt, da wir kurzfristig keinen Ersatz für das System liefern können.
Und diejenigen, die in Zukunft für dieses System verantwortlich sein werden, werden es auf jeden Fall auf die von den Kunden geforderten Zuverlässigkeits- und Leistungsindikatoren bringen können.
Der Artikel wurde vom Datenmanagementteam von Rostelecom erstellt
Aktuelles Informatica-Logo
Source: habr.com