ODI 12c - Flexible Datenintegration in komplexen DWH/ BI-Umgebungen Dr.-Ing. Holger Friedrich sumit AG

Transkript

1 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.

2 Abb. 1: E-LT-Architektur des Oracle Data Integrator Entgegen klassischer ETL-Tools, wie Informatica Power Center (ohne Push-Down-Option) oder IBM 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-Down- Option). 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-API- Aufrufe 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.

3 Abb. 2: Anwendungsgebiete des ODI- Knowedge-Module-Frameworks Oracle liefert eine grosse Zahl von Knowledge-Modulen (KMs) mit ODI aus. Diese erlauben es ODI 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.

4 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, Flexibilität, sowie Wartbarkeit und Übertragbarkeit. Effizienz 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.

5 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 Outer- Join, einmal in Oracle-SQL-, einmal in ANSI-SQL- und einmal in Hive-Syntax. De facto sind Component-KMs eine neue, fortschrittlichere Implementierung eines Operator- Frameworks, 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 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-DML- Logging 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.

6 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 o abweichend konfigurierte Instanziierungen der gleichen Technologie oder 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.

7 Abb. 4: Mehrere Deplyment-Spezifikationen zu einem logischen ELT-Design in ODI12c Fazit 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-Modul- Framework 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: +41 (0) Fax: +41 (0) Internet: