Oracle Data Warehouse Integrator Builder – Ein Selbstversuch

Dani Schnider Trivadis AG

Zürich/Glattbrugg, Schweiz Schlüsselworte: Data Warehouse, ETL, Oracle Data Integrator, Oracle Warehouse Builder Einleitung Oracle Data Integrator (ODI) ist ein umfassendes und vielseitiges Produkt für die Datenintegration in Data Warehouses. Doch wie einfach oder komplex ist die Entwicklung von Ladeprozessen mit ODI für einen ETL-Entwickler, der seit Jahren hauptsächlich mit Oracle Warehouse Builder (OWB) arbeitet? Wo liegen die Gemeinsamkeiten der beiden Oracle-Produkte, und wo gibt es konzeptuelle Unterschiede? Der Autor hatte die Gelegenheit, sich drei Wochen intensiv mit der Arbeitsweise von Oracle Data Integrator vertraut zu machen und anhand von konkreten Beispielen die Gemeinsamkeiten und Unterschiede zwischen OWB und ODI zu ergründen. Der vorliegende Artikel ist keine umfassende und vollständige Einführung in ODI, sondern eine Zusammenfassung der Erkenntnisse meines „Selbstversuchs“ mit ODI und beruht auf subjektiven Erfahrungen. Deshalb verwende ich für die folgenden Seiten – obwohl eher ungewöhnlich für eine technische Publikation – die Ich-Form. Da leider zum Zeitpunkt meines „Selbstversuchs“ ODI 12c noch nicht zur Verfügung stand, beziehen sich die nachfolgenden Erläuterungen auf die aktuell verfügbare ODI-Version 11.1.1.7. Falls bis zur DOAG-Konferenz Oracle Data Integrator 12c veröffentlicht werden sollte, werde ich im Vortrag auch auf die wichtigsten Neuerungen der neuen Version eingehen. Erster Eindruck: ODI im Überblick Ein erster Blick ins ODI Studio, der Entwicklungsoberfläche von Oracle Data Integrator, zeigt viele Ähnlichkeiten, aber auch einige wesentliche Unterschiede zum OWB. Die Oberfläche von ODI basiert auf der Fusion Client Platform (FCP) von Oracle – gleich wie bei OWB, SQL Developer und JDeveloper. Ich habe mich auf Anhieb im ODI Studio zurechtgefunden und brauchte weniger Eingewöhnungszeit als vor einigen Jahren bei der Umstellung von OWB 11.1 auf OWB 11.2, als die Benutzeroberfläche von Oracle Warehouse Builder auf FCP umgestellt wurde. Der Designer Navigator im ODI Studio zeigt aber schon einen ersten wesentlichen Unterschied. Während im OWB alle Objekte (Datenstrukturen und Datenflüsse) in Projekten abgelegt werden, enthalten die Projekte in ODI nur die Datenflüsse. Die Datenstrukturen werden in Models abgelegt und können von unterschiedlichen Projekten verwendet werden. Models werden üblicherweise nicht im ODI definiert (obwohl dies auch möglich ist), sondern mittels Reverse Engineering aus den Quell- und Zieldatenbanken importiert. Dies entspricht der üblichen Praxis, wie sie auch in vielen OWB-Projekten angewendet wird.

Abbildung 1: OWB und ODI – auf den ersten Blick ähnlich, aber unterschiedlich im Konzept Etwas verwirrend fand ich zu Beginn die Definitionen von Quell- und Zielsystemen im Topology Navigator. Hier unterscheidet ODI strikt zwischen logischer und physischer Architektur. Was im ersten Moment etwas umständlich erscheint, wird sich später bei der Implementierung der Interfaces (so heißen die Mappings in ODI 11.1) als wesentlicher Vorteil erweisen. Durch die Unterscheidung zwischen logischer Deklaration der Integrationsprozesse und deren physischer Implementierung mittels einer spezifischen Technologie (die Verbindung zwischen logischer und physischer Sicht wird in ODI als Context bezeichnet) lassen sich Ladeprozesse relativ einfach an unterschiedliche Quell- und Zieltechnologien anpassen. Dies ist eine der wichtigsten Eigenschaften von ODI. Im Gegensatz zu den meisten auf dem Markt verbreiteten ETL-Tools werden die Integrationsprozesse von ODI (bis auf wenige Ausnahmen) in der Datenbank ausgeführt. In der ODI-Dokumentation wird deshalb konsequent der Begriff E-LT (Extraction Loading Transformation) statt ETL verwendet. Einen OWB-Entwickler wie mich braucht man von diesem Ansatz nicht zu überzeugen, denn er entspricht genau der Vorgehensweise, wie sie auch vom OWB verwendet wird. Insbesondere bei den Transformationsprozessen zwischen den verschiedenen Schichten einer DWH-Architektur, die in der gleichen Datenbank gespeichert sind, macht es aus Performancesicht keinen Sinn, die Daten an einen separaten ETL-Server und wieder zurück an die Datenbank zu schicken. Beim ODI wird nur das generierte SQL-Statement vom ODI Java Agent an die Datenbank geschickt und dort ausgeführt. Genau so soll es sein! An die unterschiedlichen Begriffe, die ODI verwendet, musste ich mich zuerst gewöhnen. So gibt es – zumindest auf logischer Ebene – keine Tabellen, Views und Files, sondern nur Datastores. Dieser allgemeine Begriff wird für jede Datenstruktur verwendet, die als Quelle oder Ziel eines Integrationsprozesses verwendet werden kann. Teilweise werden in ODI andere Begriffe verwendet als beim OWB oder – schlimmer – die gleichen Begriffe für etwas anderes. Ein Package in ODI ist nicht etwa ein PL/SQL Package, sondern eine Abfolge von Interfaces (also Mappings), Procedures

oder anderer Packages. Somit ist ein Package vergleichbar mit einem Process Flow. Alles klar? Beim Lesen der ODI-Dokumentation und beim Implementieren meiner Testprojekte mit ODI habe ich mir eine kleine Auflistung (ich schreibe bewusst nicht „Mappingtabelle“, da sonst die Verwirrung noch grösser wird) zusammengestellt, die mir als Übersetzungshilfe dient: Oracle Warehouse Builder Oracle Data Integrator Project Project / Model Module Folder / Logical Schema Location Data Server / Physical Schema Configuration Context Table, View, Materialized View, External Table, File

Datastore

Primary Key, Unique Key Primary Key, Alternate Key Index Not Unique Index Sequence Sequence Mapping Interface Process Flow Package / Load Plan Transformation (Package, Procedure, Function) Procedure Das Fundament: Definieren der Topology Eine Stärke von Oracle Data Integrator ist die offene Architektur, die unterschiedliche Technologien unterstützt. Damit dies möglich ist, muss einige Vorbereitungsarbeit im Topology Navigator durchgeführt werden. Für jede verwendete Technologie werden Data Servers und Physical Schemas definiert. Technologien sind üblicherweise relationale Datenbanksysteme (Oracle, SQL Server, Netezza, Teradata, Informix, DB2, Sybase), Flat Files oder XML Files. Aber auch BI Tools wie OBIEE oder Hyperion Essbase können verwendet werden. Ich muss gestehen, dass ich mich in der zur Verfügung stehenden Zeit vor allem auf Oracle und Flat Files konzentriert habe. Für die Technologie Oracle ist ein Data Server eine Oracle-Datenbank, für die ein oder mehrere Schemas definiert werden können. Etwas erstaunt war ich, dass beim Schema kein Passwort angegeben wird, sondern nur beim Data Server. Das heißt im Falle von Oracle, dass pro Datenbank genau ein User definiert wird, über welchen der ODI Agent auf die Datenbank zugreift. Im Gegensatz zum OWB, wo die Mappings üblicherweise direkt im Zielschema mit dem zugehörigen User ausgeführt werden, wird bei ODI ein User auf der Datenbank angelegt, unter welchem alle Prozesse gestartet werden. Dieser User benötigt natürlich Lese- und Schreibberechtigungen auf alle verwendeten Schemas. Um verschiedene Datenbankumgebungen (z.B. Development, Test, Production) unterstützen zu können, wird im Topology Navigator für jede Umgebung ein sogenannter Context definiert. Schließlich werden Logical Schemas definiert, die als Platzhalter für alle Umgebungen dienen. Für jeden Context wird dem logischen ein physisches Schema zugeordnet. Nach dem gleichen Prinzip wird auch die Topologie für Files angelegt. Der Data Server ist in diesem Fall ein Filesystem, ein Physical Schema ein spezifisches Directory, welches für einen bestimmten Context einem Logical Schema zugeordnet werden kann. Die Definition der gesamten Topologie eines DWH-Systems mag etwas umständlich erscheinen, ist aber nicht komplexer als das Erstellen und Registrieren von Locations im OWB.

Einlesen der Struktur-Metadaten: Reverse Engineering Bevor Integrationsprozesse implementiert werden können, müssen die Quell- und Zielstrukturen definiert werden. Dazu wird pro Logical Schema ein Model erstellt, in welche die Struktur von Datastores (also Tables, Views, Queues, Files, etc.) mittels Reverse Engineering eingelesen werden. Auch die manuelle Definition von Datastores mit allen Attributen, Datentypen und Constraints ist möglich, aber nicht üblich. Sie wird höchstens für Output-Files verwendet, funktioniert aber auch für Tabellen. Hier hatte ich erstmals ein Problem mit dem ODI: Die vorhandenen Unique Key Constraints auf den Zieltabellen wurden nicht eingelesen. Zuerst dachte ich an einen Fehler im ODI, bis ich dann in der Dokumentation einen entsprechenden Hinweis fand. Mit dem Standard Reverse Engineering werden Unique Keys nicht erkannt. Stattdessen muss ein Customized Reverse Engineering mit einem technologiespezifischen RKM (Reverse Knowledge Modul), das für alle gängigen Technologien mitgeliefert wird, verwendet werden. Von der Quelle zum Ziel: Interfaces Nach den verschiedenen Vorbereitungsarbeiten kommen wir nun zur Kernaufgabe von Oracle Data Integrator – also zur Datenintegration. Daten sollen aus einem oder mehreren Datastores gelesen, transformiert und in einen weiteren Datastore geschrieben werden. Dazu werden im ODI sogenannte Interfaces definiert. Ein Interface entspricht vom Prinzip einem OWB-Mapping, ist aber immer auf eine Zieltabelle (bzw. einen Datastore) beschränkt. Sollen mehrere Datastores geladen werden, so ist normalerweise für jeden ein separates Interface zu implementieren. Beim OWB ist es technisch möglich, mehrere Tabellen in einem Mapping zu laden. Allerdings ist es auch da empfehlenswert, pro Zieltabelle ein Mapping zu verwenden. Als Basis habe ich ein bestehendes Beispielprojekt verwendet, das ursprünglich mit OWB entwickelt wurde und ein Oracle-DWH mit Staging Area, Cleansing Area, Core und einem Data Mart befüllt. Bevor die Daten ein einem Star Schema zur Verfügung stehen, werden sie in mehreren Schritten bereinigt, integriert und versioniert. Abbildung 2 zeigt ein OWB-Mapping aus diesem Projekt, welches den Deltaabgleich zwischen einer Quelltabelle in der Cleansing Area und einer versionierten Core-Tabelle durchführt.

Abbildung 2: Dieses OWB-Mapping diente als Basis (Versionierung einer Core-Tabelle)

Dieses Mapping möchte ich nun in ODI nachbauen – zumindest war dies meine ursprüngliche Idee. Bald wurde mir aber bewusst, dass dieser Ansatz nicht zum Ziel führt. Während ich im OWB die Logik des Deltaabgleichs mittels verschiedener Operatoren (Filter auf die aktuelle Version, Full Outer Join zwischen Cleanse-Tabelle und aktueller Version, etc.) implementieren muss, definiere ich im ODI für jedes Zielattribut eine Transformationsregel. Im einfachsten Fall ist dies ein Attribut aus einer der Quelltabellen. Es kann aber auch eine SQL-Expression, eine Konstante, Sequence oder Variable sein. Die Datastores, die als Quellen verwendet werden, können mittels Joins, Lookups und Filters verknüpft und eingeschränkt werden. Abbildung 3 zeigt das entsprechende ODI-Interface für die Versionierung der gleichen Zieltabelle im Core. Im Vergleich zum OWB-Mapping in Abbildung 2 wirkt es sehr „aufgeräumt“ und weniger komplex.

Abbildung 3: Die gleiche Logik implementiert als ODI-Interface Doch wo ist nun die ganze Komplexität des Deltaabgleichs? Bei der deklarativen Definition der Transformationsregeln, wie sie in ODI üblich ist, habe ich nirgends festgelegt, dass ein Deltaabgleich zwischen Quell- und Zieltabelle erfolgen soll. Und schon gar nicht, wie dieser implementiert wird. Was ein Interface genau machen soll und wie dies mit einer bestimmten Technologie implementiert werden soll, wird über Knowledge Module festgelegt. Knowledge Module gibt es seit Version 11.2 auch im OWB, dort heißen sie allerdings Code Templates (was meiner Meinung nach eine treffendere Bezeichnung ist). Um nun das Interface in Abbildung 3 dazu zu bringen, dass es die Daten in der Zieltabelle versioniert, muss einfach das entsprechende Knowledge Modul zugewiesen werden, in unserem Fall IKM Oracle Slowly Changing Dimension. Das Knowledge Modul enthält die einzelnen Verarbeitungsschritte, die für einen Deltaabgleich notwendig sind. Diese Schritte müssen somit nicht für jedes Interface definiert werden. Das klingt nun alles sehr schön und einfach – doch die Realität ist doch etwas komplexer. Die erste Hürde ist, dass für jedes Attribut das SCD-Verhalten definiert werden muss. Ist das Attribut ein Surrogate Key, ein Natural Key, soll es bei einer Änderung überschreiben werden (SCD Typ 1) oder soll eine neue Version erstellt werden (SCD Typ 2)? Auch Anfang und Ende des Gültigkeitsintervalls

sowie das Flag auf die aktuelle Version werden entsprechend markiert. All diese Einstellungen erfolgen nicht im Interface, sondern bei den Attributdefinitionen im entsprechenden Datastore – ähnlich wie beim SCD Wizard im OWB. Diese Fleißarbeit muss einmal durchgeführt werden, steht danach aber unabhängig vom verwendeten Knowledge Modul zur Verfügung. Als OWB-Entwickler wünscht man sich für solche Fleißaufgaben ein Scripting Interface à la OMB*Plus. Das gibt es auch in ODI: Mit Hilfe von Groovy, einer Java-basierten Skriptsprache, können solche Aktivitäten automatisiert werden. Leider hat das erwähnte Knowledge Modul IKM Oracle Slowly Changing Dimension einige konzeptionelle Mängel (z.B. dass es nicht funktioniert, wenn kein SCD1-Attribut existiert). Dies führt dazu, dass trotz vollständiger und korrekter Definition aller Attribute Fehler bei der Ausführung des Interfaces auftreten oder falsche Daten geladen werden. Die Fehlersuche ist in solchen Fällen relativ zeitaufwendig, hatte für mich aber immerhin den Vorteil, dass ich durch die Analyse der einzelnen Verarbeitungsschritte die Logik des Knowledge Moduls kennenlernen konnte. Als sehr nützlich ist in diesem Zusammenhang auch die Möglichkeit, dass ein Interface im Simulationsmodus ausgeführt werden kann. Die einzelnen Verarbeitungsschritte werden dann nicht ausgeführt, sondern es werden nur die generierten SQL-Befehle angezeigt. Der Simulationsmodus ist sehr ähnlich wie das Generieren von Intermediate Results im OWB und hat mir bei der Fehlersuche enorm geholfen. Die meisten Knowledge Module, die ich verwendet habe, konnten problemlos verwendet werden. Im hier erwähnten Fall bin ich aber nach Analyse der verwendeten Logik zum Schluss gekommen, dass ich wohl besser ein eigenes Knowledge Modul für Deltaabgleich und Versionierung schreibe. Das hatte nicht nur den Vorteil, dass ich so die Einschränkungen des vorhandenen Moduls umgehen konnte, sondern auch dass ich mich intensiv mit der Entwicklung und Arbeitsweise von Knowledge Modulen auseinandersetzen konnte. Jetzt geht’s ans Eingemachte: Knowledge Module Knowledge Module sind sozusagen der Motor der Lade- und Integrationsprozesse im ODI. Bevor ein Interface ausgeführt werden kann, muss ihm ein passendes Knowledge Modul (in heterogenen Umgebungen zwei) zugewiesen werden. Folgende Arten von Knowledge Modulen (KM) sind definiert: • LKM (Load KM): Wird in heterogenen Umgebungen verwendet, um Daten aus einem

Quellsystem in die Staging Area der Zieltechnologie zu laden. • JKM (Journalizing KM): Wird für Change Data Capture oder vergleichbare Technologien

verwendet, um lückenlose Deltaextraktionen aus Quellsystemen durchzuführen. • IKM (Integration KM): Wird für die Integrationslogik in die Zieltabelle (Target Datastore)

verwendet. Ein IKM wird für jedes Interface benötigt. • RKM (Reverse-engineering KM): Wird zum Einlesen der Strukturmetadaten aus einer

bestimmten Technologie verwendet. • CKM (Check KM): Wird für Konsistenzprüfungen und Constraints in der Zielumgebung

verwendet, falls für das Interface „Flow Control“ aktiviert ist. • SKM (Service KM): Wird zum Lesen und Schreiben von Web Services verwendet. Für die meisten Anwendungsbereiche und Technologien sind vorgefertigte Knowledge Module vorhanden, die weitgehend problemlos verwendet werden können. Für jedes Projekt werden die notwendigen KM vom Filesystem importiert. Zwar gibt es auch die Möglichkeit, globale Knowledge Module zu verwenden. Die projektspezifischen Knowledge Module haben aber den Vorteil, dass Anpassungen in einem KM eines Projekts keine Auswirkungen auf andere Projekte hat. Außerdem

bleibt die Liste übersichtlicher, wenn nicht alle über 150 von Oracle mitgelieferten KM angezeigt werden. Es ist übrigens nicht empfehlenswert, die mitgelieferten Knowledge Module zu verändern, aber möglich (und sinnvoll), sie als Basis für eigene KMs zu verwenden. In meinem Testprojekt habe ich relativ viele Knowledge Module verwendet, da ich teilweise die gleiche Funktionalität mit unterschiedlichen Technologien ausprobiert habe. So lässt sich zum Beispiel ein Flat File mittels dem technologieübergreifenden Knowledge Modul LKM File to SQL laden, oder mit dem Oracle-spezifischen LKM File to Oracle (EXTERNAL TABLE).

Abbildung 4: Im Beispielprojekt verwendete Knowledge Module Bei den hier aufgeführten Knowledge Modulen handelt es sich größtenteils um vorgefertigte und mitgelieferte Module. Die einzige Ausnahme ist IKM Oracle SCD Versioning (Triple-P), das ich im Rahmen des Beispielprojekts geschrieben habe. Selbstverständlich habe ich dabei nicht ein neues KM von Grund auf entwickelt, sondern ein ähnliches KM (in diesem Fall IKM Oracle Incremental Update) als Basis genommen und für die spezifischen Bedürfnisse angepasst. Bei dieser Gelegenheit konnte ich feststellen, wie mächtig und flexibel das Konzept der Knowledge Module ist. Das Prinzip besteht darin, dass man beliebige Statements (bei relationalen Datenbanken in der Regel SQL) schreibt, die man mit Platzhaltern der Form <%=odiRef. ... %> ergänzt und so generisch macht. Nachdem ich mich in die für mich etwas ungewohnte Syntax eingearbeitet hatte, konnte ich relativ rasch die erforderlichen Anpassungen durchführen und zusätzliche Schritte in mein eigenes Knowledge Modul einbauen. Eine gute Hilfe sind dabei – neben dem ODI Knowledge Module Developer’s Guide – die vorhandenen KMs, in denen man nach ähnlichen Codefragmenten suchen kann. Die Entwicklung der Knowledge Module erfolgt entweder direkt im ODI Studio, oder – was ich vorgezogen habe – mit einem komfortablen Editor, aus dem man dann die Codefragmente ins entsprechende Eingabefenster im ODI Studio kopiert. Das folgende Beispiel zeigt einen Teilschritt aus dem entwickelten Knowledge Modul. In einem vorher ausgeführten Schritt werden mittels Full Outer Join alle neuen, geänderten und gelöschten Datensätze ermittelt und in die für ODI typische Flow Table (I$-Tabelle) geladen. Hier wird nun mittels MERGE-Befehl das Enddatum und das SCD-Flag der aktuellen Version aller Datensätze

geändert, die durch eine neue Version ersetzt oder im Quellsystem gelöscht wurden. Dazu wird ein SQL-Statement mit verschiedenen Platzhaltern (zur besseren Lesbarkeit hier rot dargestellt) formuliert: merge into <%=odiRef.getTable("L","TARG_NAME","A")%> T using <%=odiRef.getTable("L","INT_NAME","A")%> S on (<%=odiRef.getColList("", "S.[COL_NAME] = T.[COL_NAME]", " and \n\t", "", "SCD_NK")%>) when matched then update set <%=odiRef.getColList("", "T.[COL_NAME] = 0", ",\n\t", ",", "SCD_FLAG")%> <%=odiRef.getColList("", "T.[COL_NAME] = S.[COL_NAME]", ",\n\t", "", "(SCD_END or UPD) and !SCD_FLAG and !SCD_UPD")%> where <%=odiRef.getColList("", "T.[COL_NAME]", "", "", "SCD_FLAG")%> = 1

Das daraus generierte SQL-Statement für einen konkreten Anwendungsfall – hier das Interface zum Laden der Versionstabelle COR_PRODUCT_VERS – sieht dann folgendermassen aus: merge into DWH_CORE.COR_PRODUCT_VERS T using DWH_CORE.I$_COR_PRODUCT_VERS S on (S.DWH_ID_HEAD = T.DWH_ID_HEAD) when matched then update set T.DWH_STATUS = 0, T.DWH_VALID_TO = S.DWH_VALID_TO where T.DWH_STATUS = 1

Das Entwickeln von eigenen Knowledge Modulen ist zwar aufwendig, zahlt sich aber aus, wenn das gleiche Knowledge Modul mehrfach eingesetzt werden kann. Damit dies der Fall ist, lohnt es sich, die Logik möglichst allgemeingültig zu implementieren und auch Spezialfälle zu berücksichtigen (hier zum Beispiel Target Datastores, die ausschließlich SCD1- oder SCD2-Attribute besitzen). Je generischer ein Knowledge Modul ist, desto flexibler kann es eingesetzt werden. Fazit Zu Beginn meines „Selbstversuchs“ hatte ich die Befürchtung, mit Oracle Data Integrator eine komplett andere Welt anzutreffen als mit Oracle Warehouse Builder. Der Einstieg in die für mich neue Technologie hat sich dann aber als recht einfach erwiesen, sodass ich mich relativ rasch der spannenden Aufgabe der Entwicklung von Knowledge Modulen widmen konnte. ODI ist meiner Meinung nach ein sehr flexibles und ausgereiftes ETL-Tool – Verzeihung, E-LT-Tool –, das praktisch alle Bedürfnisse für Lade- und Integrationsprozesse im DWH-Umfeld abdeckt. Und wenn mal etwas nicht geht, kann man ja sein eigenes Knowledge Modul dafür schreiben. OWB werde ich natürlich auch weiterhin einsetzen, aber ich freue mich auch auf den Einsatz von ODI in Kundenprojekten. Hier halte ich mich an den Grundsatz: Das eine tun und das andere nicht lassen. Kontaktadresse: Dani Schnider Telefon: +41(0)44-808 70 20 Trivadis AG Fax: +41(0)44-808 70 21 Europa-Strasse 5 E-Mail dani.schnider@trivadis.com CH-8152 Glattbrugg Internet: www.trivadis.com