Vor einiger Zeit standen wir vor der Frage, welches ETL-Tool wir für die Arbeit mit Big Data wählen sollten. Die zuvor verwendete Lösung Informatica BDM entsprach nicht unseren Erwartungen aufgrund ihrer eingeschränkten Funktionalität. Ihr Einsatz beschränkte sich auf das Framework zum Ausführen von spark-submit-Befehlen. Auf dem Markt gab es nicht viele Alternativen, die grundsätzlich in der Lage sind, mit dem Datenvolumen umzugehen, das wir täglich bewältigen. Letztendlich entschieden wir uns für Ab Initio. Während der Pilotvorführungen zeigte das Produkt eine sehr hohe Geschwindigkeit bei der Datenverarbeitung. Informationen über Ab Initio in russischer Sprache sind nahezu nicht vorhanden, daher haben wir uns entschieden, unsere Erfahrungen auf Хабре zu teilen.
Ab Initio bietet viele klassische und ungewöhnliche Transformationen, deren Code durch eine eigene Sprache PDL erweitert werden kann. Für kleine Unternehmen könnte ein so leistungsstarkes Werkzeug überdimensioniert sein, und die meisten seiner Möglichkeiten können sich als teuer und ungenutzt herausstellen. Wenn Ihr Maßstab jedoch dem von Sberbank nähert, könnte Ab Initio für Sie von Interesse sein.
Es hilft Unternehmen, global Wissen anzusammeln und ein Ökosystem zu entwickeln, während es Entwicklern ermöglicht, ihre ETL-Fähigkeiten zu verbessern, ihr Wissen in Shell anzuwenden, die Möglichkeit bietet, die Sprache PDL zu erlernen, einen visuellen Überblick über die Ladeprozesse zu erhalten und die Entwicklung durch die Fülle funktionaler Komponenten zu erleichtern.
In diesem Beitrag werde ich die Möglichkeiten von Ab Initio vorstellen und vergleichende Merkmale seiner Nutzung mit Hive und GreenPlum anführen.
- Beschreibung des MDW-Frameworks und Arbeiten zur Anpassung an GreenPlum
- Vergleichende Leistungsmerkmale von Ab Initio mit Hive und GreenPlum
- Einsatz von Ab Initio mit GreenPlum im Near Real Time-Modus
Die Funktionalität dieses Produkts ist sehr umfangreich und erfordert eine gewisse Einarbeitungszeit. Mit den richtigen Fähigkeiten und der richtigen Leistungsanpassung erzielt man jedoch beeindruckende Ergebnisse bei der Datenverarbeitung. Die Nutzung von Ab Initio kann Entwicklern eine interessante Erfahrung bieten. Es bietet einen neuen Blick auf die ETL-Entwicklung, eine Hybridform zwischen einer visuellen Umgebung und der Entwicklung von Ladeprozessen in einer skriptähnlichen Sprache.
Die Unternehmen entwickeln ihre Ökosysteme und dieses Werkzeug kommt ihnen wie nie zuvor gelegen. Mit Ab Initio kann Wissen über das aktuelle Geschäft angesammelt und dieses Wissen zur Erweiterung bestehender und zur Eröffnung neuer Geschäfte genutzt werden. Alternativen zu Ab Initio sind die visuellen Entwicklungsumgebungen Informatica BDM und die nicht-visuellen Umgebungen wie Apache Spark.
Beschreibung von Ab Initio
Ab Initio, wie auch andere ETL-Tools, ist eine Produktreihe.
Ab Initio GDE (Graphical Development Environment) ist eine Umgebung für Entwickler, in der sie Datenumwandlungen einstellen und diese mit Datenströmen in Form von Pfeilen verbinden. Dabei wird eine solche Ansammlung von Umwandlungen als Graph bezeichnet:
Die Eingangs- und Ausgangsverbindungen der funktionalen Komponenten sind Ports und enthalten Felder, die innerhalb der Umwandlungen berechnet werden. Mehrere Graphen, die durch Pfeilströme in der Ausführungsreihenfolge verbunden sind, werden als Plan bezeichnet.
Es gibt mehrere Hundert funktionale Komponenten, was sehr viel ist. Viele davon sind stark spezialisiert. Die Möglichkeiten der klassischen Umwandlungen in Ab Initio sind umfangreicher als in anderen ETL-Tools. Zum Beispiel hat Join mehrere Ausgänge. Neben dem Ergebnis der Zusammenführung von Datensätzen können auch die Aufzeichnungen der Eingangsdatensätze ausgegeben werden, bei denen die Verbindung nicht erfolgreich war. Außerdem können auch Rejected, Errors und ein Protokoll der Umwandlungsarbeit ausgegeben werden, das in demselben Graphen als Textdatei gelesen und von anderen Umwandlungen verarbeitet werden kann:
Oder man kann beispielsweise den Datenempfänger in Form einer Tabelle materialisieren und in demselben Graphen Daten daraus lesen.
Es gibt originale Umwandlungen. Zum Beispiel hat die Umwandlung Scan eine Funktionalität ähnlich wie analytische Funktionen. Es gibt Umwandlungen mit sprechenden Namen: Create Data, Read Excel, Normalize, Sort within Groups, Run Program, Run SQL, Join with DB und andere. Graphen können Parameter zur Laufzeit verwenden, einschließlich der Möglichkeit, Parameter vom Betriebssystem zu übergeben oder ins Betriebssystem zu übergeben. Dateien mit einer vordefinierten Menge von Parametern, die dem Graphen übergeben werden, werden als parameter sets (psets) bezeichnet.
Wie es sich gehört, verfügt Ab Initio GDE über ein Repository, das als EME (Enterprise Meta Environment) bezeichnet wird. Entwickler haben die Möglichkeit, mit lokalen Versionen des Codes zu arbeiten und ihre Entwicklungen im zentralen Repository einzuchecken.
Es ist möglich, während oder nach der Ausführung des Graphen auf jeden Verbindungstransformationsfluss zu klicken und die Daten zu überprüfen, die zwischen diesen Transformationen übertragen wurden.
Es besteht auch die Möglichkeit, auf jeden Fluss zu klicken und die Tracking-Details einzusehen – wie viele parallele Prozesse die Transformation bearbeitet hat, wie viele Zeilen und Bytes in welchen dieser Parallelprozesse geladen wurden.
Es ist möglich, die Ausführung des Graphen in Phasen aufzuteilen und zu kennzeichnen, welche Transformationen zuerst ausgeführt werden müssen (in Phase null), die nächsten in Phase eins, die nächsten in Phase zwei usw.
Für jede Transformation kann ein sogenanntes Layout gewählt werden (wo sie ausgeführt wird): ohne Parallelität oder in parallelen Strömen, deren Anzahl festgelegt werden kann. Dabei können Temporäre Dateien, die Ab Initio bei der Ausführung von Transformationen erstellt, sowohl im Dateisystem Serverals auch im HDFS abgelegt werden.
In jeder Transformation kann auf Basis des Standardtemplates ein eigenes Skript in der PDL-Sprache erstellt werden, das ein wenig an Shell erinnert.
Mit der PDL-Sprache können Sie die Funktionalität der Transformationen erweitern und insbesondere zur Laufzeit beliebige Codefragmente dynamisch generieren, abhängig von den Laufzeitparametern.
Auch in Ab Initio ist die Integration mit dem Betriebssystem über Shell gut entwickelt. Konkret wird in Sberbank Linux ksh verwendet. Es ist möglich, Variablen mit Shell auszutauschen und sie als Parameter für Graphen zu verwenden. Aus Shell heraus können Sie die Ausführung von Ab Initio-Graphen aufrufen und Ab Initio verwalten.
Neben Ab Initio GDE umfasst die Lieferung viele andere Produkte. Es gibt ein eigenes Co>Operation System, das den Anspruch erhebt, ein Betriebssystem zu sein. Es gibt Control>Center, in dem Sie Ladeprozesse planen und überwachen können. Es gibt Produkte für die Entwicklung auf einer einfacheren Ebene, als es Ab Initio GDE ermöglicht.
Beschreibung des MDW-Frameworks und Arbeiten zur Anpassung an GreenPlum
Zusammen mit seinen Produkten bietet der Anbieter das Produkt MDW (Metadata Driven Warehouse) an, das einen Konfigurator für Graphen darstellt, der zur Unterstützung bei typischen Aufgaben zur Befüllung von Data Warehouses oder Data Vaults dient.
Es enthält benutzerdefinierte (projektbezogene) Metadaten-Parser und standardmäßige Codegeneratoren "out of the box".
MDW erhält beim Eingang ein Datenmodell, eine Konfigurationsdatei für die Verbindung zur Datenbank (Oracle, Teradata oder Hive) und einige andere Einstellungen. Der projektspezifische Teil beispielsweise entwickelt das Modell in der Datenbank. Der standardisierte Teil des Produkts erzeugt Graphen und die zugehörigen Konfigurationsdateien beim Laden von Daten in die Modelltabellen. Dabei werden Graphen (und psets) für mehrere Modi der initialen und inkrementellen Verarbeitung zur Aktualisierung von Entitäten erstellt.
Bei Hive und RDBMS werden unterschiedliche Graphen für die initiale und inkrementelle Datenaktualisierung generiert.
Im Fall von Hive werden die eingehenden Delta-Daten über einen Ab Initio Join mit den Daten verbunden, die vor der Aktualisierung in der Tabelle vorhanden waren. Die Datenladeprozesse in MDW (sowohl in Hive als auch in RDBMS) fügen nicht nur neue Daten aus dem Delta ein, sondern schließen auch die Gültigkeitszeiträume der Daten, für die das Delta eingegangen ist, anhand der Primärschlüssel. Außerdem muss der unveränderte Teil der Daten neu geschrieben werden. Das ist notwendig, da es in Hive keine Lösch- oder Aktualisierungsoperationen gibt.
Bei RDBMS hingegen erscheinen die Graphen für die inkrementelle Datenaktualisierung optimierter, da RDBMS echte Aktualisierungsmöglichkeiten bieten.
Das eingehende Delta wird in einer Zwischentabelle der Datenbank geladen. Danach erfolgt die Verbindung des Deltas mit den Daten, die vor der Aktualisierung in der Tabelle waren. Dies geschieht mithilfe von SQL durch eine generierte SQL-Abfrage. Anschließend erfolgt die Einfügung neuer Daten aus dem Delta in die Zieltabelle sowie das Schließen der Gültigkeitszeiträume anhand der Primärschlüssel der eingegangenen Delta-Daten mithilfe der SQL-Befehle delete+insert.
Unveränderte Daten müssen nicht neu geschrieben werden.
Somit sind wir zu dem Schluss gekommen, dass MDW im Falle von Hive die gesamte Tabelle neu schreiben muss, da Hive keine Aktualisierungsfunktion hat. Besser als die vollständige Neuschreibung von Daten bei einer Aktualisierung wurde nichts gefunden. Im Fall von RDBMS hingegen hielten die Produktentwickler es für notwendig, das Verbinden und Aktualisieren der Tabellen SQL zu überlassen.
Für ein Projekt bei Sberbank haben wir eine neue mehrmals verwendbare Implementierung eines Datenbank-Loaders für GreenPlum erstellt. Dies wurde auf der Grundlage einer Version entwickelt, die MDW für Teradata generiert. Teradata, und nicht Oracle, war dafür besser geeignet, da es ebenfalls ein MPP-System ist. Die Arbeitsweisen sowie die Syntax von Teradata und GreenPlum erwiesen sich als ähnlich.
Beispiele kritischer Unterschiede zwischen verschiedenen RDBMS sind wie folgt. In GreenPlum muss im Gegensatz zu Teradata beim Erstellen von Tabellen die Klausel
distributed byin Teradata wird geschrieben
delete <table> all, während in GreenPlum geschrieben wird
löschen von <table>In Oracle wird zur Optimierung geschrieben
delete from t where rowid in (), während in Teradata und GreenPlum geschrieben wird
delete from t where exists (select * from delta where delta.pk=t.pk)Darüber hinaus stellen wir fest, dass für die Arbeit von Ab Initio mit GreenPlum der GreenPlum-Client auf allen Knoten des Ab-Initio-Clusters installiert werden musste. Dies liegt daran, dass wir uns gleichzeitig von allen Knoten unseres Clusters mit GreenPlum verbunden haben. Damit das Lesen aus GreenPlum parallel erfolgte und jeder parallele Ab-Initio-Thread seine Datenportion aus GreenPlum las, musste in den 'where'-Abschnitt der SQL-Abfragen eine von Ab Initio verstandene Konstruktion eingefügt werden.
where ABLOCAL()und der Wert dieser Konstruktion musste angegeben werden, indem der lesenden Transformation aus der Datenbank der Parameter
ablocal_expr=„string_concat("mod(t.", string_filter_out("{$TABLE_KEY}","{}"), ",", (decimal(3))(number_of_partitions()),")=", (decimal(3))(this_partition()))“, der in etwas wie
mod(sk,10)=3, das heißt, GreenPlum muss für jede Partition einen expliziten Filter kennen. Für andere Datenbanken (Teradata, Oracle) kann Ab Initio diese Parallelisierung automatisch durchführen.
Vergleichende Leistungsmerkmale von Ab Initio mit Hive und GreenPlum
Bei Sberbank wurde ein Experiment zur Leistungsbewertung der von MDW generierten Graphen sowohl für Hive als auch für GreenPlum durchgeführt. Im Rahmen des Experiments hatten wir im Fall von Hive 5 Knoten im selben Cluster wie Ab Initio, während im Fall von GreenPlum 4 Knoten in einem separaten Cluster vorhanden waren. Das heißt, Hive hatte einen gewissen Vorteil gegenüber GreenPlum hinsichtlich der Hardware.
Es wurden zwei Paare von Graphen betrachtet, die dieselbe Aufgabe der Datenaktualisierung in Hive und GreenPlum erfüllen. Dabei wurden die von dem MDW-Konfigurator generierten Graphen gestartet:
- Initiale Ladeoperation + inkrementelles Laden zufällig generierter Daten in die Hive-Tabelle
- Initiale Ladeoperation + inkrementelles Laden zufällig generierter Daten in dieselbe GreenPlum-Tabelle
In beiden Fällen (Hive und GreenPlum) wurden Uploads mit 10 parallelen Streams auf demselben Ab Initio-Cluster gestartet. Die Zwischendaten für die Berechnungen wurden von Ab Initio im HDFS gespeichert (in Ab Initio-Begriffen wurde das MFS-Layout unter Verwendung von HDFS verwendet). Eine Zeile zufällig generierter Daten belegte in beiden Fällen 200 Byte.
Das Ergebnis war folgendes:
Hive:
Initialer Upload in Hive
Eingefügte Zeilen
6 000 000
60 000 000
600 000 000
Dauer des initialen
Uploads in Sekunden
41
203
1 601
Inkrementeller Upload in Hive
Anzahl der Zeilen, die in der
Zieltabelle zu Beginn des Experiments vorhanden waren
6 000 000
60 000 000
600 000 000
Anzahl der Delta-Zeilen, die in der
Zieltabelle während des Experiments angewendet wurden
6 000 000
6 000 000
6 000 000
Dauer des inkrementellen
Uploads in Sekunden
88
299
2 541
GreenPlum:
Initialer Upload in GreenPlum
Eingefügte Zeilen
6 000 000
60 000 000
600 000 000
Dauer des initialen
Uploads in Sekunden
72
360
3 631
Inkrementeller Upload in GreenPlum
Anzahl der Zeilen, die in der
Zieltabelle zu Beginn des Experiments vorhanden waren
6 000 000
60 000 000
600 000 000
Anzahl der Delta-Zeilen, die in der
Zieltabelle während des Experiments angewendet wurden
6 000 000
6 000 000
6 000 000
Dauer des inkrementellen
Uploads in Sekunden
159
199
321
Wir sehen, dass die Geschwindigkeit des initialen Uploads sowohl in Hive als auch in GreenPlum linear vom Datenvolumen abhängt. Aufgrund besserer Hardware ist es in Hive etwas schneller als in GreenPlum.
Der inkrementelle Upload in Hive hängt ebenfalls linear von dem Volumen der zuvor in der Zieltabelle geladenen Daten ab und erfolgt relativ langsam mit wachsendem Volumen, da die gesamte Zieltabelle neu geschrieben werden muss. Dies bedeutet, dass kleine Änderungen an großen Tabellen – keine gute Option für Hive sind.
Der inkrementelle Upload in GreenPlum hingegen hängt nur schwach von dem Volumen der zuvor in der Zieltabelle geladenen Daten ab und erfolgt relativ schnell. Dies wurde durch SQL Joins und die Architektur von GreenPlum ermöglicht, die Operationen wie delete zulässt.
Somit fügt GreenPlum die Delta durch delete+insert hinzu, während es in Hive keine delete- oder update-Operationen gibt, weshalb der gesamte Datensatz beim inkrementellen Update vollständig neu geschrieben werden musste. Besonders aufschlussreich ist der Vergleich der fettgedruckten Zellen, da dies dem häufigsten Einsatz ressourcenintensiver Uploads entspricht. Wir sehen, dass GreenPlum in diesem Test 8 Mal besser abgeschnitten hat als Hive.
Einsatz von Ab Initio mit GreenPlum im Near Real Time-Modus
In diesem Experiment werden wir die Möglichkeit von Ab Initio überprüfen, die Tabelle GreenPlum mit zufällig generierten Datenmengen in einem nahezu Echtzeitszenario zu aktualisieren. Wir betrachten die GreenPlum-Tabelle dev42_1_db_usl.TESTING_SUBJ_org_finval, mit der wir arbeiten werden.
Wir werden drei Ab Initio-Grafiken verwenden, um mit ihr zu arbeiten:
1) Graf Create_test_data.mp – erstellt in 10 parallelen Streams Dateien mit Daten in HDFS mit 6.000.000 Zeilen. Die Daten sind zufällig, ihre Struktur ist für die Einspeisung in unsere Tabelle organisiert.
2) Graf mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset – generierter MDW-Graf zur initialen Einspeisung von Daten in unsere Tabelle in 10 parallelen Streams (es werden Testdaten verwendet, die durch Graf (1) generiert wurden).
3) Graf mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset – generierter MDW-Graf zum inkrementellen Update unserer Tabelle in 10 parallelen Streams unter Verwendung einer Charge neu eingegangener Daten (Deltas), die durch Graf (1) generiert wurden.
Wir werden das folgende Szenario im NRT-Modus durchführen:
- 6.000.000 Testzeilen generieren.
- Die initiale Einspeisung durchführen: 6.000.000 Testzeilen in eine leere Tabelle einfügen.
- Die inkrementelle Einspeisung 5 Mal wiederholen.
- 6.000.000 Testzeilen generieren.
- Die inkrementelle Einspeisung von 6.000.000 Testzeilen in die Tabelle vornehmen (dabei wird den alten Daten die Gültigkeitsdauer valid_to_ts zugewiesen, und es werden neuere Daten mit demselben Primärschlüssel eingefügt).
Ein solches Szenario emuliert den Betrieb eines tatsächlichen Geschäftssystems – in Echtzeit erscheinen eine relativ umfangreiche Charge neuer Daten und werden sofort in GreenPlum eingespeist.
Lassen Sie uns nun das Protokoll der Szenarioausführung betrachten:
Start Create_test_data.input.pset am 2020-06-04 11:49:11
Fertigstellen Create_test_data.input.pset am 2020-06-04 11:49:37
Start mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset am 2020-06-04 11:49:37
Fertigstellen mdw_load.day_one.current.dev42_1_db_usl_testing_subj_org_finval.pset am 2020-06-04 11:50:42
Start Create_test_data.input.pset am 2020-06-04 11:50:42
Fertigstellen Create_test_data.input.pset am 2020-06-04 11:51:06
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset am 2020-06-04 11:51:06
Fertigstellen mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset am 2020-06-04 11:53:41
Start Create_test_data.input.pset am 2020-06-04 11:53:41
Fertigstellen Create_test_data.input.pset am 2020-06-04 11:54:04
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset am 2020-06-04 11:54:04
Fertigstellen mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset am 2020-06-04 11:56:51
Start Create_test_data.input.pset am 2020-06-04 11:56:51
Fertigstellen Create_test_data.input.pset am 2020-06-04 11:57:14
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset am 2020-06-04 11:57:14
Fertigstellen mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset am 2020-06-04 11:59:55
Start Create_test_data.input.pset am 2020-06-04 11:59:55
Fertigstellen Create_test_data.input.pset am 2020-06-04 12:00:23
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset am 2020-06-04 12:00:23
Fertigstellen mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset am 2020-06-04 12:03:23
Start Create_test_data.input.pset am 2020-06-04 12:03:23
Fertigstellen Create_test_data.input.pset am 2020-06-04 12:03:49
Start mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset am 2020-06-04 12:03:49
Beende mdw_load.regular.current.dev42_1_db_usl_testing_subj_org_finval.pset am 2020-06-04 12:06:46
So ergibt sich folgendes Bild:
Graf
Startzeit
Endzeit
Dauer
Create_test_data.input.pset
04.06.2020 11:49:11
04.06.2020 11:49:37
00:00:26
mdw_load.day_one.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11:49:37
04.06.2020 11:50:42
00:01:05
Create_test_data.input.pset
04.06.2020 11:50:42
04.06.2020 11:51:06
00:00:24
mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11:51:06
04.06.2020 11:53:41
00:02:35
Create_test_data.input.pset
04.06.2020 11:53:41
04.06.2020 11:54:04
00:00:23
mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11:54:04
04.06.2020 11:56:51
00:02:47
Create_test_data.input.pset
04.06.2020 11:56:51
04.06.2020 11:57:14
00:00:23
mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 11:57:14
04.06.2020 11:59:55
00:02:41
Create_test_data.input.pset
04.06.2020 11:59:55
04.06.2020 12:00:23
00:00:28
mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 12:00:23
04.06.2020 12:03:23
00:03:00
Create_test_data.input.pset
04.06.2020 12:03:23
04.06.2020 12:03:49
00:00:26
mdw_load.regular.current.
dev42_1_db_usl_testing_subj_org_finval.pset
04.06.2020 12:03:49
04.06.2020 12:06:46
00:02:57
Wir sehen, dass 6.000.000 Zeilen Inkremente in 3 Minuten bearbeitet werden, was ziemlich schnell ist.
Die Daten in der Zieltabelle wurden folgendermaßen verteilt:
select valid_from_ts, valid_to_ts, count(1), min(sk), max(sk) from dev42_1_db_usl.TESTING_SUBJ_org_finval group by valid_from_ts, valid_to_ts order by 1,2; 
Man kann die Übereinstimmung der eingefügten Daten mit den Startzeitpunkten der Grafiken erkennen.
Das heißt, man kann in Ab Initio eine inkrementelle Datenladung in GreenPlum mit sehr hoher Frequenz starten und die hohe Geschwindigkeit der Dateninsertierung in GreenPlum beobachten. Natürlich wird es nicht möglich sein, jede Sekunde einen Start durchzuführen, da Ab Initio, wie jedes ETL-Tool, beim Start Zeit für das 'Hochfahren' benötigt.
Fazit
Derzeit wird Ab Initio bei der Sberbank für den Aufbau einer einheitlichen semantischen Datenschicht (ESS) verwendet. Dieses Projekt sieht den Aufbau einer einheitlichen Version des Zustands verschiedener bankgeschäftlicher Entitäten vor. Informationen kommen aus verschiedenen Quellen, deren Replikate auf Hadoop vorbereitet werden. Je nach den Anforderungen des Unternehmens wird ein Datenmodell erstellt und Datenumwandlungen beschrieben. Ab Initio lädt Informationen in die ESS und die geladenen Daten sind nicht nur für das Unternehmen von Interesse, sondern dienen auch als Quelle für die Erstellung von Datensichten. Die Funktionalität des Produkts ermöglicht es zudem, verschiedene Systeme (Hive, Greenplum, Teradata, Oracle) als Empfänger zu nutzen, was es dem Unternehmen erleichtert, Daten in den benötigten Formaten bereitzustellen.
Die Möglichkeiten von Ab Initio sind breit gefächert, zum Beispiel ermöglicht das mitgelieferte MDW-Framework den Aufbau der technischen und geschäftlichen Historie der Daten 'out of the box'. Für Entwickler bietet Ab Initio die Möglichkeit, 'das Rad nicht neu zu erfinden' und auf eine Vielzahl vorhandener funktionaler Komponenten zurückzugreifen, die im Grunde Bibliotheken sind, die bei der Arbeit mit Daten benötigt werden.
Autor — Experte der professionellen Gemeinschaft der Sberbank SberProfi DWH/BIGDATA. Die professionelle Gemeinschaft SberProfi DWH/BIGDATA ist verantwortlich für die Entwicklung von Kompetenzen in Bereichen wie Hadoop-Ökosystem, Teradata, Oracle DB, GreenPlum sowie BI-Tools wie Qlik, SAP BO, Tableau usw.
Quelle: habr.com
