Wie und warum wir Greenplum in QCD / Sudo Null IT News implementiert haben

Hey Habr! Mein Name ist Maxim Solopin, ich arbeite bei Rosbank als Corporate Data Warehouse Architect. In diesem Beitrag werde ich darüber sprechen, wie wir vom Data Lake, in dem täglich alle Rohdaten abgelegt wurden, zu einem praktischen System auf Basis von Greenplum übergegangen sind. Und nebenbei werde ich ein wenig auf die Entwicklung von Corporate-Data-Warehouse-Modellen eingehen.

Zu Beginn des Projekts verfügte die Bank über 3 QCD, 5 Sandboxes, 7 BI-Server und 0 Golden Source, auf deren Basis sich der Data Lake seit mehreren Jahren entwickelt. Downloads wurden dort dupliziert, und um dies zu vermeiden, haben wir uns entschieden, Rohdaten von Hadoop zu nehmen.

Aber das brachte nur neue Probleme. Die Daten wurden langsam geladen, nicht aus allen Quellen in der Bank (jetzt gibt es mehr als 50 davon). Das selbst geschriebene Lade-Framework war roh, es brauchte für all das und auch für die Entwicklung Überwachung, Support und dementsprechend eine Menge Ressourcen.

Dann haben wir Anfang 2021 beschlossen, unsere erste Golden Source auf Basis von Greenplum zu kreieren. Unser Kernteam, das die Retail-Sandbox der Bank entwickelt, arbeitete an der Migration. Wir haben uns aus mehreren Gründen für Greenplum entschieden: Skalierbarkeit, Geschwindigkeit, moderate Kosten, Kompatibilität mit Hadoop, die Möglichkeit, verschiedenste Quellen im Rahmen eines universellen Datenmodells anzubinden.

Mit Datenmodellen werde ich eine ausführliche Geschichte beginnen.

Wie Corporate Data Warehouses aufgebaut sind

Der klassische Ansatz zur Datenspeicherung in einem Unternehmen ist das Konzept des Data Warehouse (DWH), dessen Geschichte bereits 1990 begann, als der amerikanische Wissenschaftler Bill Inmon das Buch „Building the Data Warehouse“ veröffentlichte. Inmon identifizierte vier Schlüsseleigenschaften von DWH:

  • themenorientiert – alle Datenelemente in der Datenbank, die sich auf dasselbe reale Ereignis oder Objekt beziehen, stehen in Beziehung zueinander; wobei der Datenspeicher Informationen zu einem bestimmten Thema enthält, wie z Produkt, Klient, Verkauf usw.

  • Zeitvariant – Datenänderungen in der Datenbank werden nachverfolgt und aufgezeichnet, sodass Änderungen im Laufe der Zeit gemeldet werden können.

  • Nichtflüchtig – Daten in der Datenbank werden niemals überschrieben oder gelöscht; nach der Korrektur werden sie statisch, schreibgeschützt und in dieser Form für zukünftige Berichte gespeichert;

  • Integriert – Die Datenbank enthält Daten aus den meisten oder allen betrieblichen Anwendungen der Organisation, und die Daten sind konsistent.

Einen etwas anderen Ansatz verfolgten Inmons Gegenspieler Ralph Kimball und die Microsoft Corporation. Sie konzentrierten sich auf Data Marts, d. h. Teile des Data Warehouse, bei denen es sich um eine Reihe thematischer, eng fokussierter Informationen handelt. Für Einkäufer war dieser Ansatz attraktiver – es war einfacher, Vitrinen mit schnellen und effektiven Berichten zu verkaufen, als sie in komplexe Lagererstellungsprozesse einzutauchen.

Die Erstellung von DWH war länger und kostspieliger, und nach Inmons Ansatz erschienen Schaufenster erst in der Endphase. Aber der Ansatz der Kimball-Gruppe hat sich im Laufe der Zeit geändert.

DWH arbeiten nach der ETL-Methode – Extract, Transform and Load. Das bedeutet, dass die Daten regelmäßig aufbereitet und in den Speicher hochgeladen werden, beispielsweise einmal im Monat. Das Laden dauert lange, und oft muss der Speicher während dieser Zeit für die Nutzung geschlossen werden, was schlecht ist.

Unternehmensspeicher hat sich im Laufe der Zeit weiterentwickelt und zum Data Lake-Konzept geführt. Data Lakes verwenden den ELT-Ansatz (Extract, Load and Transform). Rohdaten werden sofort in den Speicher geladen und dann im Hintergrund transformiert und von Schicht zu Schicht bis zur letzten Schicht von Data Marts hochgestuft.

Die Vorteile von Data Lake bestehen darin, dass es keine aufwendige Datenvorbereitungsphase gibt und der Speicher während des Upgrades nicht geschlossen werden muss. Für Fintech ist kontinuierliche Verfügbarkeit entscheidend. Darüber hinaus können Daten- und Machine-Learning-Wissenschaftler die Daten sofort nach ihrem Eintreffen nutzen.

Datenmodell in Rosbank

Unser Datenmodell, basierend auf der Methodik von Bill Inmon, wurde bereits getestet. Wir haben die wichtigsten Einheiten wie Kunden, Konten, Verträge, Transaktionen, Salden usw. hervorgehoben.

Jeder Tisch kann einen Erweiterungstisch haben. Beispielsweise könnte die Erweiterung für eine Vereinbarungstabelle die Erweiterungstabelle ihres Darlehensvertrags sein. Es enthält bereits Attribute, die nicht in die Vertragstabelle gepasst haben. Außerdem kann jede Tabelle eine %_property-Tabelle haben. Darin werden Attribute herausgenommen, für die zB Historizität benötigt wird oder man keine Erweiterungstabelle erstellen möchte, da es wenige solcher Attribute gibt.

So sind die Datenflüsse in unserem Speicher organisiert. Lassen Sie mich einige Dinge erklären:

  • STG ist eine Schicht, die Roh-Ext-Tabellen enthält. Es gibt keinen separaten ELT-Stream in GP, ​​Tabellen sind nur mit Hadoop verbunden.

  • ODS – eine Schicht zum Sammeln der Historie aus der STG-Schicht für die erforderlichen Attribute. Es wird selten verwendet, da wir die Historie der Rohdaten nicht speichern.

  • DDS – enthält detaillierte Daten zu den wichtigsten Entitäten.

  • EM – enthält Vitrinen mit aggregierten Indikatoren grundlegender Einheiten: Kundenportfolio, HR-Portfolio, Kredit- und Einlagenportfolios usw.

  • DM – Vitrinen mit berechneten Aggregaten, komplexen Attributberechnungen. Diese Ebene enthält gemeinsame Schaufenster für alle Abteilungen. Erst auf dessen Basis werden weitere Reports generiert. Es gibt auch separate DM-Ebenen für bestimmte Geschäftsbereiche.

  • DICT ist eine Ebene von Verzeichnissen.

Verzeichnisse können manuell geladen werden, können aus Dateien gefüllt werden, können aus Quellsystemen gezogen werden: aus MDS, über API usw.

Ich werde Ihnen ein wenig über die parallele Arbeit an zwei Repositories erzählen. Um am neuen Repository zu arbeiten, haben wir das Team des alten eingebunden, und die Jungs mussten beide gleichzeitig warten. Das Geschäft steht immer an erster Stelle, daher änderten sich die Prioritäten oft, und manchmal gab es nicht genug Hände für neuen Speicher. Wir haben die Entwicklung auf dem alten Repository nicht eingefroren, und infolgedessen stand unsere Logik etwas im Widerspruch zu der neuen; musste eine Menge Ressourcen aufwenden, um es fertigzustellen.

Es hat uns geholfen, dass wir allen anderen Entwicklungsteams erlaubt haben, das Repository aktiv weiterzuentwickeln. Dazu müssen sie sich alle an unser etabliertes Datenmodell und unsere Designstandards halten. Und das Team muss mindestens einen Leiter haben, der diese Standards validiert, Mitarbeiter schult und Fragen zur Architektur des Modells beantwortet. Mehrmals in der Woche treffen sich diese Führungskräfte zu Architekturtreffen, bei denen sie aufkommende Probleme und Probleme diskutieren, neue Regeln und Standards festlegen usw.

So haben wir Probleme mit einem großen Rückstand auf ein Team beseitigt.

Orchestrierung herunterladen

Die Stream-Orchestrierung geht in den Luftstrom über und es war ein neues Tool für uns. Alle Hadoop-Downloads, die früher in Cron gingen, wurden in Airflow verschoben. Dafür wurde ein Dag-Generator erstellt, der automatisch Aufgaben zum Laden von Tabellen aus Quellen generiert.

Dann haben wir denselben Generator erstellt, um SQL-Funktionen auf dem GP auszuführen. Dort sind die Abhängigkeiten nicht so linear, und es sieht im Luftstrom nicht so schön aus:

Derzeit läuft ein Pilotprojekt zur Umstellung auf Gitlab + Gitlab CI, und in naher Zukunft werden wir auf die Automatisierung des Prozesses der Bereitstellung von Code umstellen. In der Zwischenzeit wird der gesamte Code in der Datenbank nur durch Bitbucket geleitet, im manuellen Modus, nachdem die Pull-Anforderung genehmigt wurde.

Ladeprogramm für Datenbankreplikate

Am Anfang des Artikels habe ich unser Datenlade-Framework erwähnt. Ich werde darüber gesondert berichten. Der Universal Loader erstellt Repliken von Tabellen aus Datenbanken von Quellsystemen (DB2, Oracle, MSSQL, PostgeSQL, Pervasive) und aktualisiert die Repliken auch zu einem bestimmten Datum. Der Loader sorgt für die Akkumulation der Historie von Tabellenänderungen in Hadoop in der Struktur Slow Changing Dimension Typ 2 (Markierung von Datensatzversionen mit DT_FROM, DT_TO-Feldern) und in unbegrenzter Tiefe.

Die Loader-Eingabeliste sieht folgendermaßen aus:

  • Batch-Version – schreibgeschützte Tabellen in Quellsystemen, Anbindung über JDBC);

  • CDC-Version – Changelog-Datendateien, die als Ergebnis der CDC-Arbeit erhalten wurden (im JSON-, Parquet- oder ORC-Format);

  • Konfigurationsdateien und Metadaten (Tabellenbeschreibung).

Und das ist die Ausgabe:

  • Replikattabelle in Hive mit der Möglichkeit, den Änderungsverlauf zu speichern;

  • Arbeitsprotokolle in YARN und in der Metadatenbank.

Der Loader unterstützt die automatische DDL-Replikation – Ändern der Tabellenstruktur in Hive nach dem Ändern der DDL auf der Quelle. Für das Stapelladen steht eine Dublettenprüfung nach Schlüssel mit Dublettenablehnung in der Reject-Tabelle zur Verfügung. Beim CDC-Laden ist es möglich, vollständige Duplikate in den Eingabedaten zu ignorieren (wenn die CDC-Aktualisierung durchgeführt wurde, ohne alte Dateien zu löschen), sowie Aktualisierungs- / Löschvorgänge auf nicht vorhandenen Schlüsseln.

Der Loader hat derzeit einige Einschränkungen in Bezug auf das Laden von Tabellenspalten, Kompatibilität und Funktionalität für die DDL-Replikation.

Ergebnisse

Die Migration der ersten Sandbox war erfolgreich. Jetzt senden wir basierend auf neuen Daten täglich Motivation an die Mitarbeiter. Bis Mitte des Jahres wird die vollständige Migration abgeschlossen sein, und parallel dazu werden andere Teams mit der Migration der restlichen Tresore der Bank beginnen.

Die wichtigste Lektion, die wir während des Projekts gelernt haben, ist, dass wir selbst verstehen müssen, was wir wollen, die notwendige Architektur bauen und selbst modellieren und uns nicht auf Anbieter verlassen müssen. Und wir müssen die Ressourcen haben, die all dies unterstützen.

Similar Posts

Leave a Reply

Your email address will not be published.