Oracle Warehouse Builder 10g im Einsatz

Transkript

1 Mittwoch, 9. November h00, Stamitzsaal Oracle Warehouse Builder 10g im Einsatz Dr. Susanne Palm Deutsche Post IT Solutions, Darmstadt Schlüsselworte: Oracle Warehouse Builder 10g, ETL, Data Warehouse, Metadaten Einleitung Von seiner Natur her ist ein Data Warehouse (DWH) statisch. Eingebettet ist das DWH in eine Umgebung, die stetig dynamischer wird. Die Änderungen kommen schneller und häufiger und liegen meist nicht im Einflussbereich der IT Abteilungen. Wenn die Geschäftsprozesse der Unternehmen häufigen Änderungen unterworfen sind, hat dies direkte Auswirkungen auf die OLTP Systeme, welche die Analysedaten erzeugen. Die Lebenszyklen einzelner Releases in OLTP Systemen nehmen kontinuierlich ab. Da die Änderungen in den OLTP Systemen meist direkten Einfluss auf die Struktur/Aufbau eines DWHs haben, muss auch das DWH immer häufiger an neuen Gegebenheiten angepasst werden. Die Betreiber von DWHs stehen also vor der Herausforderung mit immer geringeren Mitteln auf zunehmend häufigere Änderungen zu reagieren. In dem gleichen Maße, wie Budgets der IT Abteilungen gekürzt werden, wachsen andererseits die Anforderungen der Benutzer an die Verfügbarkeit, den Komfort und die Flexibilität im Umsetzen von Änderungswünschen in einem Informationssystem. Ein Metadaten gesteuertes ETL (Extract, Transform, Load) Tool, wie der Oracle Warehouse Builder (OWB), kann den Betreiber eines DWHs dabei unterstützen, dieser Herausforderung zu begegnen. Ziel des Vortrags Anliegen des Vortrags ist es aufzuzeigen, dass sich das Redesign eines laufenden Projektes durchaus lohnen kann. Anhand von Praxisbeispielen wird erläutert, welche technischen Aspekte einer historisch gewachsenen Umgebung durch eine Umstrukturierung effizienter gestaltet werden können. Der Fokus liegt dabei nicht auf den technischen Details, sondern auf den Projektsituationen, den Erfahrungen und den daraus gewonnenen Erkenntnissen. Herausforderung Selten hat man die Situation, dass ein System auf der grünen Wiese neu geplant werden kann. Meist sieht man sich einer DWH Lösung gegenüber, die schon eine Weile im Einsatz ist. Die zugrunde liegende Technik ist oft veraltet, auch wurden i.d.r. auch keine ETL Werkzeuge eingesetzt. Damit steht man vor handgeschriebenen Ladeprogrammen, die im besten Fall mit gelegentlicher Inline-Dokumentation versehen wurden. Nicht selten stehen auch die Entwickler nicht mehr zur Verfügung, da sie inzwischen das Unternehmen verlassen haben. Einen rechten Überblick über die Gesamtsituation zu bekommen ist schwierig. Aufgrund unterschiedlicher Informationsstände herrschen durchaus unterschiedliche Ansichten zur aktuellen Lage. Das kann dazu führen, dass der Aufwand für die notwendigen Anpassungen unterschätzt wird. Warum der OWB? Der OWB ist ein Tool, mit dem man ein DWH definieren, modellieren und verwalten kann. Die Quelldaten werden mit dem OWB transformiert und aufbereitet. Das System wird mit dem OWB verwaltet und weiterentwickelt. Für die Realisierung von Data Warehouse Lösungen auf Oracle Datenbanken ist der OWB eine sehr gut integriertes Entwicklungs- und Wartungswerkzeug.

2 18. Deutsche ORACLE-Anwenderkonferenz Die Angaben in diesem Artikel beziehen sich auf den Oracle Warehouse Builder 10g Release 1. Die folgende Version, Release 2, ist zurzeit im Beta Test und soll voraussichtlich Ende des Jahres zur Verfügung stehen. Technischer Hintergrund Der OWB umfasst zwei Hauptkomponenten. Das ist zum einen die Design Komponente, der Client, mit dessen grafischer Oberfläche alle benötigten Datenbankobjekte und Ladeszenarien auf Metadatenebene modelliert werden können. Zum anderen gibt es eine Runtime Umgebung, den so genannten Deployment Manager, über den das definierte ETL System und alle seine Objekte und Prozeduren in der Datenbank physisch erzeugt (generiert) werden. Der OWB generiert PL/SQL-Prozeduren für den ETL Prozess und DDL-Statements für die Datenbank Objekte. Mit dem Design Client (Abbildung 1) verbindet man sich an die Datenbank. Die Design Komponente besteht aus einem Design Repository, das sich in der Oracle Datenbank befindet, sowie Design und Reporting Tools, mit denen die Metadaten dargestellt und manipuliert werden können. In der Datenbank sind wenigstens drei User erforderlich, der Runtime Access User, das Runtime Repository Schema und das Target Schema. Da das Runtime Repository einige Systemprivilegien (z.b. die Rolle DBA) benötigt, ist der Runtime Access User als Sicherheitsebene implementiert. Der Runtime Access User ermöglicht es Usern, auf das Runtime Repository zuzugreifen. Das Runtime Repository Schema beinhaltet die Audit und Service Tabellen und Packages. Der Besitzer des Runtime Repositories ist der zentrale User in dem System, der die Verbindungen zum Target Schema verwaltet. In das Target Schema werden letztendlich die Daten geladen. Dieses Schema enthält die Datenbankobjekte und Prozeduren, die den ETL Prozess ausführen. Sämtliche Informationen in Bezug auf die Generierung der Objekte und Ausführung der Prozesse sind im Runtime Repository abgespeichert. Der Runtime Audit Browser kommuniziert ebenfalls mit dem Runtime Repository und ermöglicht es dem User, Berichte über die Audit und Fehlerprotokollierung einzusehen. IT Experience bb. 1: Vereinfachte Architekturskizze vom Aufbau des Oracle Warehouse Builders und seinen wichtigsten Komponenten Metadaten Unter Metadaten ("Daten über Daten") versteht man allgemein Daten, die Informationen über andere Daten enthalten. Oder anders gesagt, strukturierte Daten, mit deren Hilfe eine Informationsressource beschrieben und dadurch besser auffindbar gemacht wird. Tim Berners-Lee, der Erfinder des World Wide Web und Direktor des World Wide Web Consortiums (W3C), definiert es folgendermaßen: "Metadaten sind maschinenlesbare Informationen über elektronische Ressourcen oder andere Dinge." Bemühungen der Object Management Group (OMG), einen Standard für die Behandlung von im Data- Warehouse-Prozess anfallenden Metadaten zu schaffen, führte zu der Entwicklung des Common Warehouse Metamodel (CWM). Durch die Vereinheitlichung von Zugriff, Austausch und Beschreibung von Metadaten soll die Zusammenarbeit zwischen verschiedenen DWH Lösungen und Tools ermöglicht werden.

3 Das Arbeiten mit Metadaten hat den großen Vorteil, dass die Daten zentral in einem Repository abgelegt sind. Sie verlassen also nicht ggf. mit dem Mitarbeiter das Unternehmen. Jeder Berechtigte hat Zugang zu den Daten. Man muss die Informationen nicht an verschiedenen Stellen aktualisieren, wenn sie zentral abgelegt sind. Auch bieten die grafischen Oberflächen eine sehr gute Möglichkeit zur Visualisierung. Man kann sowohl die Ladeprozeduren (Mappings) als auch die Ladeszenarien (Workflows) modellieren und visualisieren. Mit der Nachvollziehbarkeit des Datenflusses und der Informationsgewinnung steigt auch die Akzeptanz. Der gesamte ETL Prozess wird auf diese Weise besser verständlich. Die grafischen Darstellungsmöglichkeiten kommen den zunehmenden Forderungen der Benutzer nach mehr Transparenz entgegen. So können sich auch Endanwender komplexe Zusammenhänge zugänglich machen. Die Projekte Grundlage für den Praxisbericht sind zwei Projekte, in denen der OWB 10g zum Einsatz kam, um eine vorhandene Lösung zu ersetzen. Der Fokus lag Projektsituationen und Aspekten, die wahrscheinlich auf andere Unternehmen, Bereiche und Projekte übertragbar sind. Aus diesem Grund erfolgt hier auch keine detaillierte Projektbeschreibung oder eine Konzentration auf technische Spezialitäten. Projekt 1 Bei dem ersten Projekt handelt es sich um ein Tracking System für Projekte und zugehörige Lizenzen, das basierend auf Excel Mappen begonnen wurde. Die Datengrundlage des Projekts bildeten 5 komplexe Excel Mappen mit mehreren Blättern, sowie diverse Textdateien. Alle Kalkulationen und die gesamte Logik steckte in den Excel Mappen, das fachliche Know-how des Systems in den Köpfen zweier Mitarbeiter. In dieser Situation war es schwierig, diese Mitarbeiter zu vertreten oder zu unterstützen. Mit einer steigenden Anzahl der Projekte und zunehmender Komplexität der Projektmerkmale wurde die Excel Lösung unhandlich und unübersichtlicht. Auch konnte man Wünschen nach zusätzlichen Auswertungen nicht immer nachkommen. Immer wieder kam es vor, dass man nicht ganz aktuelle oder teilweise unkorrekte Daten vorliegen hatte. Was teils an Fehlern in den Quelldaten lag, teils auch daran, dass sich durch manuelle Bearbeitung Fehler in die Excel Mappen eingeschlichen hatten. Projekt 2 In einem zweiten Projekt war eine DWH Lösung schon seit längerem im Einsatz. Hier wurden keine ETL Tools verwendet, die Ladeszenarien waren manuell programmiert. Die Datenbasis beruhte in diesem Projekt auf ca. 40 Tabellen eines Quellsystems, auf die über Views zugegriffen wurde. Zusätzlich gab es einige Textdateien und Excel Mappen, die Daten bereitstellten. Der Datenbewirtschaftungsprozess selbst wurde von etwa 60 manuell kodierten PL/SQL-Prozeduren und Funktionen abgebildet. Zur Steuerung des Ladeszenarios gab es mehrere PL/SQL-Packages, die einen Workflow nachbildeten. Problematisch an den Zugriffen über die Views war die Fehlersuche, da man keine Fehlermeldung hatte, anhand derer man nach Lösungen suchen könnte. Bei den nächtlichen Ladeläufen traten in dem selbst geschriebenen Workflow häufig Fehler auf. Die Fehlersuche nahm viel Zeit und Mühe in Anspruch, da man wenig Anhaltspunkte hatte. Auch waren Änderungen und Erweiterungen des manuell kodierten Systems schwierig und zeitaufwendig. Es lag nur unzureichende Dokumentation vor, und ein Teil der Entwickler hatte das Unternehmen inzwischen verlassen. Den Status Quo erhalten und Wartungsarbeiten ohne größere Neuentwicklungen durchführen, das funktioniert mit solchen Systemen nach wie vor. Neuen Herausforderungen und Weiterentwicklungen aber kann man damit auf effiziente Weise nicht begegnen. Lösungsansatz Für beide Projekte wurde die Anbindung der auf Excel Mappen oder Textdateien basierenden Quelldaten, über so genannte External Tables realisiert. Diese External Tables können bequem im OWB definiert und in die Modellierung des ETL Prozesses eingebunden werden können. Um der langatmigen und mühseligen Fehlersuche bei Fehlschlägen in Views im zweiten Projekt zu begegnen, wurden die Quelldaten direkt aus den Quelltabellen in so genannte Stage Tabellen extrahiert. Die teilweise in den Views enthaltenen Transformationen werden künftig in separaten Schritten vorgenommen. So hat man bei auftretenden Fehlern gute Chancen, die Ursachen ausfindig zu machen.

4 18. Deutsche ORACLE-Anwenderkonferenz Zentrales Anliegen des ersten Projekts war es, das Know-how in den Köpfen der Mitarbeiter und die Logik des Systems mit dem OWB umzusetzen. Der Modellierung im OWB ging eine intensive Arbeitsphase zum identifizieren und konsolidieren von Informationen zur Beurteilung der Datenqualität, zur logischen Auswertung der Daten sowie zu Plausibilitäten voraus. Die so erarbeiteten Grundlagen wurden mit der Design Komponente des OWB umgesetzt. Alle benötigten Datenbankobjekte wurden ebenfalls im OWB definiert und dort ausführlich dokumentiert. Das Gleiche gilt für die dem ETL Prozesse zugrunde liegenden Mappings (Prozeduren), die ebenfalls im OWB modelliert wurden (Abbildung 2). Zahlreiche Operatoren bieten vielfältige Möglichkeiten, die Daten entsprechend der zuvor formulierten Bedingungen zu transformieren und anhand der Plausibilitäten zu validieren, so dass am Ende des Vorgangs konsistente Daten vorliegen. Mit dem Operator Expressions kann man entweder vorformulierte SQL Ausdrücke verwenden, oder aber selbst welche formulieren. Arbeitet man auf einer Oracle 10g Datenbank, so kann man sogar Regular Expressions nutzen, auch wenn der OWB das von sich aus noch nicht anbietet. Die Regular Expression eröffnen ganz neue Möglichkeiten, Texte in der Datenbank zu durchsuchen und zu ändern. IT Experience Abb. 2: Grafische Oberfläche zum Modellieren von Mappings (Ladeprozeduren). Anhand verschiedener Operatoren kann man definieren, wie genau die Daten transformiert und validiert werden sollen. Kernstück des zweiten Projekts war ein Redesign des manuell programmierten ETL Prozesses. Zunächst wurden die relevanten Datenbankobjekte und Mappings im OWB definiert. Innerhalb der Mappings kann man verschiedene Varianten auswählen, wie man die Zieltabelle eines Mappings füllen möchte. Sehr praktisch ist, dass die seit Oracle 9i verfügbare MERGE Funktion nun auch im OWB angeboten wird. Gerade wenn kontinuierlich neue Daten eingespielt werden, zum Teil aber auch bereits vorhandene Datensätze geändert werden müssen, so kann dies mit MERGE in einem Schritt erfolgen. Über die Modellierung der einzelnen Mappings hinaus können die einzelnen ETL Prozessschritte in einen Workflow (Abbildung 3) eingebunden werden. Für den regelmäßigen Ablauf der ETL Prozesse wurde ebenfalls im OWB die Reihenfolge festgelegt, in der die Prozesse später ablaufen. Auch die Fehlertoleranz des Prozesses und der Detailgrad in der Anzeige sind konfigurierbar. Am Ende des Prozesses können s mit Informationen über den Verlauf des Workflows, an einen definierten Verteilerkreis verschickt werden. Abb. 3: Der Ablauf der Ladeszenarien lässt sich im OWB modellieren. An dieser Stelle können auch detaillierte Anweisungen zu deren Abarbeitung, wie z.b. Fehlertoleranz, mitgegeben werden.

5 Für die Überwachung der regelmäßigen ETL Ladeläufe kommt der Runtime Audit Browser (Abbildung 4) zum Einsatz. Über eine HTML Oberfläche kann auf Berichte mit Laufzeitinformationen aus dem Runtime Repository zugegriffen werden. Mit wenigen Clicks können diese Berichte sortiert und durchsucht werden, aufgetretene Fehler sind sehr schnell identifiziert. Man bekommt nicht nur den Hinweis, dass ein Fehler aufgetreten ist, sondern auch konkrete Information zu z.b. Key Constraint Verletzungen oder unerlaubt Null Werte. Abb.4: Über die HTML Oberfläche des Runtime Audit Browsers kann der User ohne die Installation weiterer Komponenten auf Laufzeitinformationen des ETL Prozesses zugreifen. Technische Helferlein Bevor man die auf Metadatenebene definierten Objekte in die Datenbank generiert, empfiehlt es sich, von der Validierungsfunktion für Objekte und Mappings Gebrauch zu machen. So können Inkonsistenzen in den erstellten Objekten oder spätere Laufzeitfehler der Mappings oftmals vermieden werden. Detaillierte Meldungen helfen die Unstimmigkeiten rasch zu identifizieren. Um den Überblick zu behalten, welche Objekte z.b. geändert, aber noch nicht erneut generiert wurden, bietet der Deployment Manager eine Übersicht und schlägt einen Default Modus für die Objekte vor. So können geänderte Metadaten gezielt mit einem Click neu in der Datenbank generiert werden. Die Option Ad Hoc generieren bietet die Möglichkeit, sich den SQL Code anzeigen zu lassen, den der OWB generiert. So können erfahrene SQL Programmierer schnell einen Überblick bekommen, ob der generierte Code in Ordnung ist. Um Zwischenergebnisse zu prüfen, bietet sich die Option Generate Intermediate Result an. Gerade bei komplexen Mappings bietet es klare Vorteile, sich Zwischenergebnisse anzeigen lassen zu können, wenn man sich gezielt mit einzelnen Joins oder sonstigen Operatoren beschäftigen möchte. Nutzen Metadaten. Ein großer Vorteil ist die zentrale Verwaltung und Pflege der Metadaten. Informationen liegen in einem zentralen Repository und jeder kann gemäß seiner Berechtigung darauf zugreifen. Die Daten werden nur an einer Stelle aktualisiert. Es existiert nur ein Version der Wahrheit. Visualisierung. Die grafischen Oberflächen des OWB ermöglichen eine Visualisierung der Prozesse. Gerade bei dem für den Endanwender nicht sichtbaren Herzstück eines DWHs, dem ETL Prozess, ist das sehr hilfreich. Hier kann man dem Anspruch der Anwender nach mehr Transparenz entgegen kommen. Langfristig führt mehr Verständnis auch zu mehr Akzeptanz eines Systems. Datenqualität. Mangelnde Datenqualität ist bei den ETL Prozessen oft ein großes Thema. Um zuverlässige Aussagen machen zu können, muss ein gewisser Qualitätsstandard eingehalten werden. Durch die schnelle und sichere (feldgenaue) Identifizierung fehlerhafter Quelldaten anhand des Runtime Audit Browsers hat sich die Datenqualität innerhalb kurzer Zeit deutlich verbessert.

6 18. Deutsche ORACLE-Anwenderkonferenz Tägliche Arbeit. Die täglichen Wartungsarbeiten, Änderungen und Weiterentwicklungen lassen sich mit der grafischen Entwicklungsoberfläche einfacher und schneller realisieren als mit manuell programmierten Systemen. Vor allem bei der Fehlersuche in den nächtlichen Ladeläufen hat sich der zeitliche Aufwand drastisch reduziert, awber auch die Einarbeitung neuer Mitarbeiter wird deutlich vereinfacht. Kommentare Was in der aktuellen Version nicht so gut funktioniert Nicht skalare Datentypen werden vom OWB nicht unterstützt. Neben RAWs, CLOBs und BLOBs kann der OWB auch mit VARRARAYS nicht umgehen. Die Modellierungen im OWB werden in Projekten gruppiert. Eine projektübergreifende Nutzung von Dimensionen ist nicht möglich. Wird dies gewünscht, so muss die Dimension in dem neuen Projekt zusätzlich angelegt werden. Während man mit dem Deployment Manager arbeitet, um die Objekte in der Datenbank zu generieren, ist der Client zum Modellieren der Objekte gesperrt und kann nicht zur Weiterentwicklung genutzt werden. Man kann sich damit behelfen, während längerer Deploymentvorgänge auf einen anderen Client auszuweichen. Die Installation des Runtime Repositories hat sich teilweise als etwas hakelig erwiesen. Während die Installation auf Windows oder auch Sun Solaris keinerlei Probleme macht, so kann der Vorgang auf HP teilweise recht aufwendig gestalten. Einzelne Teile des im OWB modellierten Workflows kann man nicht einfach so separat laufen lassen, z.b. wenn man beim Auftreten von Fehlern Daten nachladen will. Hier muss der Teil, der separat laufen soll, extra als Prozess definiert werden. Nur so kann der Workflow die Komponenten als Prozess erkennen und ansprechen. IT Experience Worauf man achten sollte Will man in einer gewachsenen Umgebung ein metadatengesteuertes ETL Tool zum Einsatz bringen, so darf man den Aufwand hierfür nicht unterschätzen. Die Vorarbeit sollte auch den Bereich der Konzeptionierung, Systemarchitektur, Datenmodellierung etc. umfassen, so dass man die Ergebnisse mit dem ETL Tool nur noch umsetzen muss. Großes Augenmerk sollte auf der Datenqualität der Quellsysteme liegen, die ist leider oft schlechter als man denkt. Möglicherweise macht es Sinn, einen Daten Audit in Erwägung zu ziehen. Im Rahmen eines Redesigns bietet es sich an, die Arbeits- und Entwicklungsprozesse der Mitarbeiter zu beleuchten und gegebenenfalls an die neuen Prozesse anzupassen. Die ständige Aktualisierung der Metadaten muss in die Corporate Prozesse eingebunden sein. Die Prozesse zum Erhalt des Systems müssen funktionieren. Schulung der betroffenen Mitarbeiter und Anwender. Bindet man die Fachseite frühzeitig in den Prozess ein, so hat man die Chance Skeptikern zu begegnen, Zweifel auszuräumen und über Nutzen und Vorteile zu informieren. Anderenfalls verspielt man möglicherweise die Akzeptanz der Mitarbeiter und damit eine effiziente Nutzung des neuen Systems. Uneinigkeit und mangelnde Einsicht sind Punkte, denen man auch mit dem besten Tool nicht begegnen kann. Ein Tool kann unterstützen, aber die Arbeit abnehmen wird es einem nicht. Es bleibt die Konsequenz aufzubringen, Metadaten aktuell zu halten, zentral zu pflegen und auch die Dokumentation nicht zu vergessen.

7 Fazit Der OWB stellt ein umfassendes, metadatengesteuertes Entwicklungs- und Betriebswerkzeug für eine DWH-Lösung dar. Die offenen Schnittstellen ermöglichen die Integration vielfältiger Produkte weiterer Anbieter. Das starke Metadatenmanagement erfüllt alle Anforderungen, die an eine moderne und effiziente DWH-Entwicklung gestellt werden. Ein gezielter Umbau kann sich durchaus lohnen. Da künftige Änderungen entsprechend schneller und einfacher durchgeführt werden können, amortisieren sich Ausgaben schnell. Zudem kann man beim Redesign einen evolutionären Ansatz verfolgen, d.h. man muss nicht alle Änderungen revolutionär zu einem Zeitpunkt vornehmen, sondern kann sie in mehreren inkrementellen Schritten vornehmen. Auch in Etappen lässt sich mit vereinfachter Weiterentwicklung und Wartbarkeit der Systeme eine Kostenersparnis beobachten. Manuelles Programmieren entfällt, da der Code für den Ablauf der Laderoutinen von dem ETL Tool generiert wird. Die schnelle und sichere Identifikation fehlerhafter Daten führt neben einer drastischen Zeitersparnis bei der Suche nach den Fehlern auf Dauer zu einer Verbesserung der Datenqualität. Mit einem stetig verbesserten Datenqualitätsprozess können auf Dauer auch Kostensenkungen erreicht werden. Anhand der grafischen Oberfläche lassen sich Änderungen leichter nachvollziehen und Zusammenhänge visualisieren. Damit steigt die Transparenz und Nachvollziehbarkeit, grundlegende Voraussetzung um Vertrauen zu schaffen und die Akzeptanz des Gesamtsystems zu verbessern. Endanwender sollen das System intuitiv erfassen können. Kontaktadresse: Dr. Susanne Palm Hilpertstrasse 31 D Darmstadt Telefon: +49(0) Fax: +49(0) Internet: