ODI 12c - Flexible Datenintegration in komplexen DWH/ BI

Werbung
ODI 12c - Flexible Datenintegration in komplexen DWH/
BI-Umgebungen
Dr.-Ing. Holger Friedrich
sumIT AG
!
Schlüsselworte
Datenintegration, Oracle Data Integrator, Heterogene Umgebungen, Flexibilität, Performance, Data
Warehouse, Business Intelligence
!Einleitung
Oracle Data Integrator (ODI) 12c Release ist eine hervorragende Kombination der Konzepte der alten
ODI- und OWB-Produktlinien. Aber warum ist das ein Vorteil für komplexe Data-Warehouse- und
Business-Intelligence-Implementierungen? Nun, DWH- & BI-Projekte beinhalten in der Regel nicht
nur mehrere Datenquellen, sondern nutzen auch oftmals verschiedene Ziele und Zieltechnologien zur
Speicherung dimensionaler Daten und von Aggregationen. Beispiele hierfür sind Essbase, TimesTen
und die Oracle Datenbank.
Insbesondere in komplexen Umgebungen und zur Vereinfachung von Wartung und Auditierung ist die
Nutzung von DI-Werkzeugen ohne ernsthafte Alternative. Hier machen einige Produkteigenschaften
von ODI 12c den Unterschied zur Konkurrenz aus. Am wichtigsten ist in diesem Kontext die Trennung des logischen Designs von DI-Verarbeitungen von deren jeweiliger technischen Implementierung. Dieses, nur in ODI 12c vorhandene Feature vereinfacht DI-Implementierungen in technisch heterogenen, sich im stetigem Wandel befindlichen Systemlandschaften
Dieser Artikel beleuchtet das allgemeine Szenario sowie die Produktfeature von ODI12c und die daraus resultierenden Vorteile für DWH- und BI-Projekte. Es wird gezeigt, dass und warum ODI 12c das
beste DI-Produkt für agile DWH- und BI-Projekte ist und wie seine Eigenschaften in typischen, sich
fortentwickelnden Umgebungen eingesetzt werden können. In der zugehörigen Präsentation auf der
DOAG-2014-Konferenz werden die angesprochenen Produkteigenschaften live vorgestellt und auf
verschiedene Technologien angewendet werden.
!Die wichtigsten Unterscheidungsmerkmale des ODI bis Release 11g
Betrachtet man Oracles Produktmarketing der letzten Jahre für Oracle Data Integrator, fällt auf, dass
drei Produkteigenschaften als Hauptunterscheidungsmerkmale zum Wettbewerb intensiv beworben
wurden. Es sind dies:
!
1. E-LT-Architektur,
2. hervorragende Eignung für heterogene Umgebungen und
3. einzigartiges Modellierungsverfahren mit deklarativem Design.
!Zunächst ein Blick auf diese drei Produkteigenschaften des Oracle Data Integrator, bevor andere Eigenschaften betrachtet werden, die ODI12c sogar noch besser und weiter von der Konkurrenz in der
Datenintegrationswelt absetzen.
!E-LT-Architektur
Oracle Data Integrator ermöglicht und fördert die Verwendung einer E-LT-Architektur, also einer Verarbeitungsweise bei der Daten aus einem System extrahiert werden, dann ins Zielsystem, zum Beispiel
ein DWH, geladen werden, um schliesslich dort unter Nutzung der sich im System befindlichen Engine notwendige Transformationen auszuführen. Wahlweise kann auch eine TE-L-Strategie verfolgt
werden, bei der die Daten vor oder während der Extraktion aus dem Quellsystem bereits transformiert
werden, um dann bereits in der gewünschten Form und Struktur vorliegend, ins Zielsystem geladen zu
werden. Dies ist des öfteren ein vorliegendes Anwendungsszenario im Falle des beladens entfernter
Data Marts aus einem Data Warehouse. Abbildung 1 illustriert das Verfahren.
!
!
!
!Entgegen klassischer ETL-Tools, wie Informatica Power Center (ohne Push-Down-Option) oder IBM
Abb. 1: E-LT-Architektur des Oracle Data Integrator
Datastage, spart die ELT-Architektur eine Menge Aufwand, I/O und Kosten und glänzt mit stark verminderter Komplexität bei Entwicklung und Infrastruktur. Dies ist ein grosses Plus von ODI. Allerdings ist ODI nicht das erste Werkzeug, welches den ELT-Ansatz verfolgt. Oracle Warehouse Builder
implementierte eine ELT-Architektur bereits vor ca. 15 Jahren, allerdings begrenzt auf Oracle Datenbanken als Zielsysteme. Zudem stellen Wettbewerber mittlerweile auch Erweiterungen zur Verfügung,
welche eine ELT-Architektur in bestimmten Grenzen umsetzen (z.B. Informaticas Push-DownOption).
!Heterogene Umgebungen
Oracle Data Integrator stellt Entwicklern das Konzept der Knowledge-Module zur Verfügung. Dies
bedeutet de facto, dass ODI ein offenes Framework zur Verwaltung und Ausführung von Code Templates hat, wobei der individuelle Programmcode innerhalb der Knowledge-Module durch ODI-APIAufrufe mit Metadaten instantiiert werden kann. Dieses Framework, dessen typische Anwendungsgebiete in Abbildung 2 dargestellt sind, erlaubt es Entwicklern DI-Code für beliebige Technologien und
Anwendungsfälle selbst zu erstellen, den Funktionsumfang des ODI derart selbstständig zu erweitern
und so DI-Aufgaben in hetereogenen Umgebungen optimal zu lösen.
!
!
!
!Oracle liefert eine grosse Zahl von Knowledge-Modulen (KMs) mit ODI aus. Diese erlauben es ODI
Abb. 2: Anwendungsgebiete des ODI- Knowedge-Module-Frameworks
mit einer Vielzahl von Standardapplikationen (OBS, Siebel, SAP,...) und Technologien (HADOOP,
Files, XML, ...) zu verbinden. Standardkonnektoren zu diversen Applikationen und Technologien gibt
es selbstverständlich auch von Wettbewerbern, aber Oracle bietet mit ODI hier sicherlich das überlegene Produkt an.
!Deklaratives Design
Was meint Oracle Marketing mit dem Begriff ‚deklaratives Design’? Damit wird darauf hingewiesen,
dass man bei Verwendung von Knowledge-Modulen eine saubere Trennung des ‚was ist zu tun’,
sprich dem logischen Design eines Datenintegrationsschrittes von der physischen Implementierung,
dem ‚wie ist es zu tun’ erreicht wird. Man muss nur simplifiziert den logischen Ablauf definieren und
dann das passende KM dazu wählen. Abbildung 3 verdeutlicht den Ablauf im Vergleich zu klassischen
ETL-Werkzeugen.
!
!
!
Abb. 3: Deklaratives Design des Oracle Data Integrator
Leider hatte dieses Vorgehen bis und mit ODI 11g einen grossen Nachteil. Man musste entweder mit
den vorhandenen Knowledge-Modulen leben. Dann reduzierte sich die Entwicklungsarbeit wirklich
auf einfaches anbinden der Metadatenobjekte und konfigurieren von Bedingungen, Expressions und
Ablaufparametern des KM. Oder aber, wenn die KMs nicht hundertprozentig zur vorliegenden Aufgabe passten, musste man eigene schreiben bzw. die vorhandenen anpassen. Man war daher schon bei
recht einfachen Aufgaben zurück in der klassischen Softwareentwicklung angelangt und hatte alle üblichen Herausforderungen des Software Engineering, wie Releasefähigkeit, Versionenvielfalt etc. zu
bewältigen. Andere Werkzeuge, wie zum Beispiel Oracle Warehouse Builder hatten zur gleichen Zeit
zwar nicht Funktionalität für komplexe Aufgaben wie sie manche KMs zur Verfügung stellen (ab
OWB11gR2 konnten allerdings ODI-KMs ausgeführt werden), dafür aber brachten sie bereits leistungsfähige Engines zur Codeerzeugung mit, die das manuelle schreiben von Programmcode weitgehend überflüssig machten.
!Release 12c – Entscheidende Produktmerkmale
Die von Oracle angeführten Hauptunterscheidungsmerkmale streichen echte Vorteile gegenüber den
Wettbewerbern heraus. Es gibt seit Release 12c neue bzw. erweiterte Produkteigenschaften, die Oracle
Data Integrator noch einen wesentlich grösseren Vorsprung vor den Mitbewerbern sichern. Diese geben ODI12c-Nutzern verbesserte Leistung auf den Gebieten
!
•
•
•
!Effizienz
Effizienz,
Flexibilität, sowie
Wartbarkeit und Übertragbarkeit.
Wie kann gemessen bzw. beurteilt werden, ob mit einem DI-Werkzeug effizient gearbeitet oder effizienter als mit vergleichbaren Werkzeugen gearbeitet werden kann? Beim Thema Effizienz geht es in
der industrialisierten Welt immer darum, welche Menge eines Gutes in hoher Qualität, während einer
bestimmten Zeitspanne, mit möglichst geringem Ressourceneinsatz produziert oder gewartet werden
kann. Die Lösung für die Steigerung qualitativ hochwertigen Outputs ist in der Regel die Automatisierung von Prozessen und Herstellungsschritten, wobei Grad und Flexibilität der Automatisierung in der
Regel mit fortschreitender Entwicklungszeit immer weiter zunehmen.
Was heisst dies für das Feld der Datenintegration mit dem Einsatz von meta-daten-basierten Werkzeugen, wie dem Oracle Date Integrator? Für die Anwendung von DI-Tools heisst Automatisierung,
schneller zu werden, als Entwickler mit der Maus zeigen, klicken, tippen und damit entwickeln können. Oracle Data Integrator bringt hierfür den ODI Software Development Kit mit. Es handelt sich
dabei um ein vollständiges Java API, welches die programmatische Ausführung aller Design-, Deployment- und Ausführungsaktionen, die von den graphischen Benutzeroberflächen ausführbar sind,
per API-Aufruf erlaubt. Mittels des SDK, dessen APIs durch Scriptingerweiterungen, wie beispielsweise Groovy nutzbar sind, können komplexe ETL-Design-Aufgaben, aber auch Releaseaufgaben und
anderes automatisiert werden. So wird die Produktivität eines Entwicklerteams massiv gesteigert. Nebenbei werden auch Wissensvermittlung, Codequalität und Fluktuation im Team wesentlich besser
gemanagt. Vorraussetzung für den effektiven Einsatz des ODI SDKs ist allerdings eine hohe Standardisierung des Data-Warehosue-Designs in den Bereichen Modellierung und Verarbeitungslogik.
!Flexibilität
Die Flexibilität eines Tools offenbart sich unter anderem in den Freiheitsgraden, die es gewährt.
Schaut man sich Problemstellungen der Datenintegration an, so ist die grösste Flexibilität der Lösungserstellung sicher beim manuellen kodieren von Verarbeitungslogik gegeben. Andererseits aber
sind beim manuellen kodieren andere wichtige Aspekte einer DI-Lösung, wie Auditierbarkeit, Ausführungsablauf, Anpassungen an Änderungen in Quell- und Zielsystemen etc. ebenfalls manuell zu handhaben, was die Flexibilität solcher Lösungsimplementierungen massiv einschränkt.
Ein anderer Aspekt der Flexibilität im Rahmen der Datenintegration besteht darin, dass ein DI-Werkzeug Entwickler von den genannten administrativen Aspekten entlastet. Dennoch sollte es mittels der
Fähigkeit zur sehr leistungsfähiger, automatischer Codeerzeugung aus logischen Verarbeitungsdesigns
die Freiheit manueller Kodierung fast erreichen.
Während ODI bis und mit Release 11g durch das KM-Framework, die Freiheitsgrade der manuellen
Kodierung effektiv mit der Instantiierung durch Metadatenmodelle verband, fehlte es an der Unterstützung der Entwickler durch eine leistungsfähige echte Codeerzeugungs-Engine. Eine solche war im
Oracle Warehouse Builder seit jeher vorhanden. Diese war jedoch auf verschiedene Releases von Oracle-Datenbanken beschränkt. So wie früher mit ODI und OWB geht es mit praktisch allen DI-Werkzeugen am Markt. Sie bieten entweder grösstmögliche Programmierflexibilität, insbesondere im
Open-Source-Bereich, ohne jedoch Unterstützung bei der Codeerzeugung für Standardfälle viel zu
helfen, oder sie bieten reichhaltige Funktionalität, lassen aber die Flexibilität für Sonderfälle vermissen.
Oracle Data Integrator 12c bietet nun das beste beider Welten, der freien Programmierung und Instatiierung mittels Knowledge-Modulen und der automatischen Codegenerierung auf der Basis eines logischen Designs. Erreicht wird dies mittels der Erweiterung des klassischen Knowledge-Modul-Frameworks. Seit Release 12c gibt es in ODI12c zwei Arten von Knowldge-Modulen.
!
•
•
Component-Knowledge-Module. Component-KMs sind de facto instantiierbare Code-Fragmente, die einzelne Operatoren eines logischen ETL-Modells für eine gewählte Technologie
repräsentieren, also zum Beispiel ein Code-Fragment für eine Lookup-Operation als OuterJoin, einmal in Oracle-SQL-, einmal in ANSI-SQL- und einmal in Hive-Syntax.
De facto sind Component-KMs eine neue, fortschrittlichere Implementierung eines OperatorFrameworks, wie es schon in Oracle Warehouse Builder zum Einsatz gekommen ist. Nur ist es
nun erweitert und flexibilisiert worden, damit Component-KMs für beliebige Technologien,
Releases und Operationen darstellbar sind. ODI12c enthält bereits heute Component-KMs, die
fast die gesamte Reichhaltigkeit von SQL abdecken, inklusive fortgeschrittener Funktionen
wie Pivot/Unpivot, analytischem SQL und anderen. Zugleich stehen diese Funktionen sowohl
zur Erzeugung von ANSI-SQL, Oracle-SQL und, seit Release 12.1.0.3 auch für Hive-SQL zur
Verfügung. So können Entwickler heute schon hochkomplexen Code fur Oracle-Datenbanken,
für alle Systeme, die ANSI-SQL ausführen können und zur Ausführung auf HADOOP-Clustern erzeugen lassen.
Template-Knowledge-Module. Diese entsprechen den klassischen ODI-Knowledge-Modulen,
wie sie auch in den vorigen Releases bereits zum Einsatz kamen. Es sind also Code-Templates, die an logische Designs der Verarbeitungslogik angeflanscht werden, mit deren Metadaten
instantiiert und daraufhin deployt und ausgeführt werden können.
Template-Knowledge-Module sind für zwei Anwendungsfälle besonders geeignet.
o Mittels Template-KMs können spezielle Technologien, für die noch keine automatische Codeerzeugung in ODI zur Verfügung steht angesprochen werden.
o Unterstützt die in ODI verfügbare, automatische Code-Erzeugung eine bestimmte
Zieltechnologie, aber noch nicht alle deren Möglichkeiten, so kann mit Template-KMs
diese Beschränkung überbrückt werden, bis in einem folgenden ODI-Release die
Codeerzeugung eventuell entsprechend erweitert worden ist. Ein Beispiel hierfür ist zum Beispiel die Nutzung und Konfiguration von Error-DMLLogging in Oracle Datenbanken. Diese wird von ODIs Component-KMs noch nicht
unterstützt, kann aber einfach durch ein Template-KM nachgerüstet werden.
!Spannend ist hierbei, dass im Gegensatz zu ODI11g
beliebig komplexe Queries in Template-KMs
erzeugt und verwendet werden können. Man kann also zum Beispiel hochkomplexes SQL von den
Oracle-SQL-Component-KMs erzeugen lassen und den resultierenden Select-Query in einem Template-KM mit DML-Error-Logging-Insert-Query nutzen.
!
Auf diese Weise gibt ODI12c den Entwicklern das beste zweier Welten, die Vorteile reichhaltiger
Codeerzeugung gepaart mit den Freiheitsgraden der manuellen Programmierung. Das ist in dieser
Form zur Zeit einzigartig auf dem Markt der DI-Werkzeuge.
!Wartbarkeit und Übertragbarkeit
Wie gezeigt wurde enthält ODI12c Produkteigenschaften, die hohe Effizienz und Flexibilität ermöglichen. Die meiste Zeit des Lebenszyklus einer Data-Warehouse- oder Business-Intelligence-Lösung
besteht aber nicht aus der initialen Entwicklung, sondern aus Weiterentwicklung, Wartung und immer
wieder einmal aus der Portierung der Lösung oder von Teilen der Lösung auf andere Infrastrukturen
und/oder Technologien. Um ODIs Fähigkeiten bezüglich hoher Wartbarkeit und einfacher Übertragbarkeit von DI-Lösungen zu bewerten, muss erst definiert werden, was im Kontext dieses Artikels
darunter zu verstanden wird.
!
•
•
Hohe Wartbarkeit. Hiermit ist im Kontext dieses Artikels die Möglichkeit zum einfachen Test,
Vergleich und der einfachen Inbetriebnahme von
o Änderungen an einer bestehenden Implementierung oder
o alternativen Implementierungen
gemeint.
Einfache Übertragbarkeit. Eine DI-Lösung ist dann einfach übertragbar bzw. einfache Übertragbarkeit wird von DI-Werkzeugen und –Infrastrukturen dann gut unterstützt, wenn
o abweichend konfigurierte Instanziierungen der gleichen Technologie oder
o alternative Instanzen unterschiedlicher Technologien
mit geringem Aufwand getestet, verglichen bzw. Portierungen mit geringem Aufwand durchgeführt werden können.
!
ODI12c bietet im Rahmen der oben definierten Wartbarkeit und Übertragbarkeit eine Unterstützung,
wie sie von anderen Werkzeugen nicht geboten wird. Es ist ein Zusammenspiel verschiedener Produkteigenschaften, die dies ermöglicht. Dazu gehört auch das schon besprochene KM-Framework mit
Component- und Template-KMs, und weiterhin die flexible Verknüpfung physischer Server und Technologieinstanzen mit von der Technologie abstrahierten logischen Schemata. Der Schlüssel ist aber
insbesondere die Trennung der logischen Modellierung der Verarbeitungslogik von ihrer physischen
Implementierung durch sogenannte Deployment-Spezifikationen. Dieses so nur im ODI vorzufindende Feature gestattet es für eine Verarbeitungslogik
!
•
•
•
mehrere alternative physische Implementierungen,
mehrere alternative Konfigurationen derselben physischen Implementierung und
mehrere physische Implementierungen für mehrere verschiedene Technologien gleichzeitig zu
halten.
!In allen obigen Anwendungsfällen können Component-KMs und Template-KMs getrennt oder gemischt verwendet werden. Welche Deployment-Spezifikation in welchem technologischen Kontext
zum Einsatz kommen soll, kann bei jeder Ausführung dynamisch gewählt werden. Abbildung 4 zeigt
den Screenshot einer Deployment-Spezifikation, die es erlaubt das logische Design einer Verarbeitungslogik in eine TimesTen-Datenbank zu deployen und die Implementierung dort auszuführen. Ausserdem sind die Laschen mehrerer anderer Deployment-Spezifikationen für andere Technologien desselben logischen Designs zu sehen.
!
!
!
!Fazit
Abb. 4: Mehrere Deplyment-Spezifikationen zu einem logischen ELT-Design in ODI12c
Oracle Data Integrator bietet, neben E-LT-Archtitektur, Unterstützung heterogener Systemlandschaften
und deklarativem Design, die traditionell von Oracle beworben werden, gegenüber den Mitbewerbern
im DI-markt gravierende Vorteile auf den Gebieten der Effizienz, der Flexibilität und der Wartbarkeit
und Übertragbarkeit damit erstellter DI-Lösungen. Schlüssel zu dieser Überlegenheit sind der ODI
Software Development Kit, die Kombination aus Component- und Template-Knowledge-ModulFramework und die Entkopplung logischen Verarbeitungsdesigns von physischer Implementierung
durch Deployment-Spezifikationen.
!Kontaktadresse:
Dr.-Ing. Holger Friedrich
sumIT AG
Täfernstrasse 28
CH-5405 Baden-Dättwill
!Telefon:
Fax:
E-Mail
Internet:
+41 (0) 56 – 470 2500
+41 (0) 79 – 320 8179
[email protected]
www.sumit.ch
Herunterladen