Zum Jahreswechsel 2012/2013 steht die neue Oracle Datenbank Oracle 12c (so der voraussichtliche Name) in den Startlöchern. Oracle hat als wahrscheinlichen „Release Termin“ Dezember bis Januar genannt. Es ist jetzt also durchaus eine gute Zeit sich mit der zukünftigen Ausrichtung der Oracle ETL-Strategie zu befassen.
Für viele Anwender ist der Oracle Warehouse Builder (OWB) in der aktuellen Version das bevorzugte ETL-Produkt, um ein Oracle Data Warehouse mit Daten zu versorgen.
Die Gründe hierfür sind:
- Die Standard Edition ist kostenfrei in der Datenbanklizenz enthalten
- Das Produkt hat eine gewisse Reife erreicht und funktioniert sehr gut
- Es ist bestens in die Oracle Datenbank integriert.
Einziges Problem: Es stirbt!
Vor wenigen Jahren hat Oracle das Produkt „Oracle Data Integrator“ (ODI) auf den Markt gebracht, dass den „Oracle Warehouse Builder“ (OWB) zukünftig ablösen soll.
Dazu gibt es von Oracle eine Reihe von Aussagen:
- Den OWB gibt es nur noch in der Standard Edition, für die Enterprise Edition (mit erweiterter Funktionalität) kann man bereits heute keine Lizenzen mehr erwerben
- Der OWB wird seit Release 11g Rel. 2 nicht mehr weiterentwickelt, das heisst neue Datenbankfeatures werden durch den OWB zukünftig gegebenfalls nicht mehr unterstützt
- Im nächsten Datenbankrelease (12c) soll der OWB als Standard Edition noch vorhanden und unterstützt sein
- ODI ist offizieller Nachfolger vom OWB; es soll einen Migrationspfad geben
- Zusätzliche Optionen (z.B. Data Quality Option) werden nur noch für den ODI entwickelt und angeboten
- Der ODI ist kostenpflichtig und nicht mehr in der Datenbanklizenz enthalten
Wenn man sich diese Aussagen betrachtet, so liegt es für die Anwender nahe, in absehbarer Zeit vom OWB in Richtung ODI zu migrieren. Das wird natürlich von Oracle auch so propagiert. Doch ist das wirklich die richtige Strategie? Um dies zu entscheiden muss man den ODI etwas näher betrachten und vor allem die Unterschiede zum OWB berücksichtigen:
- Der ODI ist im Gegensatz zum OWB nicht in die Oracle Datenbank integriert, d.h. er kann prinzipiell auch ohne eine Oracle Datenbank betrieben werden. Sowohl die Quell- als auch Zieltechnologie kann dabei eine beliebige vom ODI unterstützte Datenbank sein. Ich kann also einen ETL-Prozess modellieren der aus einer DB2 ein DWH auf einer Sybase Datenbank lädt.
- Der ODI generiert nicht wie der OWB PL/SQL-Programme sondern reines SQL. Dies hat zur Folge, dass im OWB gewohnte Vorgehensweisen im ODI nicht mehr funktionieren und angepasst werden müssen.
- Oracle hat sich von dem Gedanken die Datenbank als alleinige ETL-Engine einzusetzen verabschiedet und propagiert nun eine Technologie, deren Leistungsfähigkeit nicht mehr direkt mit der Oracle-Datenbank gekoppelt ist.
- Die Anzahl der zu konfigurierenden Systemkomponenten hat im Vergleich zum OWB zugenommen. Während der OWB parallel zur Datenbank skaliert hat, muss ich mir bei ODI hierzu gesondert Gedanken machen.
- Die benötigten Skills zum Arbeiten mit dem ODI haben sich gegenüber dem OWB stark verändert. Beim Erlernen des ODI bieten OWB-Kenntnisse keine oder nur sehr geringe Vorteile.
- Der OWB in der Standard Edition hat keine zusätzlichen Kosten verursacht, der ODI ist extra zu lizensieren und bewegt sich mit seinen Preismodellen im Premiumsegment.
Legt man diese Betrachtungen zugrunde, so muss man feststellen: Zwar verspricht Oracle einen Migrationspfad vom OWB hin zum ODI, aber die rein datentechnische Migration ist nur ein kleiner Teil der Migrationsaufgaben. Gesamthaft betrachtet, kommt die Migration vom OWB zum ODI praktisch einer Migration hin zu jedem beliebigen anderen ETL-Werkzeug gleich. Weder kann ich mein Vorgehen 1:1 übernehmen, noch stimmen meine Designparadigmen. Meine „Mannschaft“ muss ebenfalls neu ausgebildet werden.
Folglich kann und muss ich auch andere Möglichkeiten in Betracht ziehen:
- Man bleibt auf absehbare Zeit beim OWB. D.h. man muss erst mal gar nichts tun und hat damit auch keine zusätzlichen Kosten oder Risiken. Die Einschränkung allerneuste Datenbank Features vielleicht nicht direkt nutzen zu können (eine indirekte Nutzung über eine selbst geschriebene Funktion oder View geht im Einzelfall ja schon) ist dabei sicher zu verschmerzen. Am schwersten wiegt die Unsicherheit, wie in Zukunft eine etwaige Migration aussehen könnte. Wenn man aber voraussetzt, dass Oracle 12c den OWB weiterhin unterstützt, so hat man bis zum Supportende von Oracle 12c noch einige Jahre Zeit.
- Man migriert auf ODI. Dadurch bekommt man eine zukunftsfähige ETL-Umgebung, die auch über Oracle 12c hinaus noch betriebsfähig ist und regelmäßig aktualisiert wird. Man hat damit aber ein klassisches Migrationsprojekt mit all seinen Risiken und Kosten.
- Man migriert auf ein „Nicht-Oracle-Produkt“. Lässt man sich auf eine groß angelegt Migration Richtung ODI ein, kann man auch noch weiter denken und das ETL-Werkzeug grundsätzlich neu bestimmen. Hier gibt es zum ODI sowohl in der kostenpflichtigen Variante, als auch im Open Source Bereich interessante Konkurrenzprodukte.
Wägt man das Für und Wider der oben aufgeführten Argumente ab, so kann man leider nicht zu einer einheitlichen Empfehlung kommen. Ob sich ein Anwender für eine Migration vom OWB hin zum ODI entscheidet, hängt von vielen Faktoren ab, die sorgfältig untersucht werden müssen. Eventuell ist beim OWB zu verbleiben, oder ein gänzlich anderes Werkzeug einzusetzen, die bessere Alternative.