Gestern OWB, heute ODI

43
DOAG 2014 BI Christian Piasecki GESTERN OWB, HEUTE ODI Ein Erfahrungsbericht eines OWB - Entwicklers

description

Nach Oracle’s Ankündigung den OWB nicht weiter zu supporten stehen viele DWH-Architketen und Entwickler vor der Herausforderung sich mit dem Oracle Data Integrator auseinander zu setzen. Anhand eines Projekts, bei dem Daten von unterschiedlichen mobilen Zeiterfassungen verarbeitet und konsolidiert werden sollen, wird in einem Erfahrungsbericht näher gebracht, was man bei der Arbeit mit dem ODI als OWB-Umsteiger beachten muss. Wo gibt es zum Einstieg Herausforderungen und Probleme? Wo liegen die Vorteile des ODI? Anhand von konkreten Erfahrungen sollen diese Punkte dem Zuhörern aufgezeigt werden.

Transcript of Gestern OWB, heute ODI

DOAG 2014 BI

Christian Piasecki !

GESTERN OWB, HEUTE ODI

Ein Erfahrungsbericht eines OWB - Entwicklers

Christian Piasecki Consultant

ÜBER MICH

Beratung, Training, Entwicklung Oracle Technologie

Oracle BI Suite Oracle BI Publisher Oracle Warehouse Builder Oracle Apex Oracle Data Integrator

BlogTechnical http://enpit.blogspot.comSonstiges http://www.enpit.de/blog

Training DevelopmentConsultingOracle Business

IntelligenceOracle ADFADF Mobile

Oracle WebLogic

Oracle WebCenter

ENTERPRISE PRAGMATIC IT

Oracle Fusion Middleware

DOAG 2014 BI

AGENDA

Aufgabe

Erste Schritte

Umsetzung des Workflows

Unterschiede

Fazit

!

DOAG 2014 BI

ES WIRD ZEIT LOSZULEGEN

DOAG 2014 BI

AUFGABE‣ Projektmitarbeiter erfassen ihre Tätigkeiten mit

verschiedenen Systemen z.B. Mobile-Endgeräten

‣ Datenlieferung erfolgen immer Monatsweise mindestens einmal am Anfang des Folgemonats

‣ Aufwände sollen zentral in einer Datenbank konsolidiert werden

‣ Es wird nicht ein System zur Erfassung vorgeschrieben, sondern Datenanlieferungen werden integriert

DOAG 2014 BI

ARCHITEKTURZeiterfassung der Projektmitarbeiter

Datenbereitstellung durch Projektmitarbeiter

automatischeDatenverarbeitung

mit dem ODI

Konsolidierte Daten in der Oracle DB

Einwurf Share

DOAG 2014 BI

AGENDA

Aufgaben

Erste Schritte

Umsetzung des Workflows

Unterschiede

Fazit

NICHT IN DIE LUFT GEHEN

DOAG 2014 BI

AUFGABE: EINLESEN EINER TEXTDATEI‣ Strukturen schaffen: Quelle und Ziel

‣ Zugriff auf die Datei

‣ Prozess zur Verarbeitung der Datei erstellen

‣ Prozess ausführen

DOAG 2014 BI

OWB - EINLESEN EINER DATEI IN EINE TABELLE ‣ Anlegen eines Moduls mit Speicherort, das auf ein

Datenbank-Verzeichnis zeigt ‣ Anlegen eines Moduls mit Speicherort, das als

Target-Schema in der Datenbank dient ‣ Anlegen eines File-Objekts für die Text-Datei ‣ Erstellen eines Mappings mit dem File-Objekt als

Quelle und einer Tabelle als Ziel-Objekt ‣ optional erstellen und verwenden einer externen

Tabelle als Quelle

DOAG 2014 BI

OWB - EINLESEN EINER DATEI IN EINE TABELLE ‣ Mapping deployen ‣ Mapping ausführen

DOAG 2014 BI

ODI - QUELLE DEFINIEREN‣ In der „Topologie“ einen physikalischen

Speicherort für den Ordner mit den Quelldateien anlegen

DOAG 2014 BI

ODI - LOGISCHES SCHEMA‣ Ein logisches Schema erstellen und über den

Kontext das physikalische Schema mit dem logischen Schema verknüpfen

DOAG 2014 BI

ODI - MODEL ERZEUGEN‣ Im Designer ein Modell erstellen, welches auf den

logischen Speicherort verweist

DOAG 2014 BI

ODI - DATENSPEICHER UND FORMAT DEFINIEREN ‣ Einen Dateispeicher erstellen und den Dateinamen

angeben, auf den dieses Objekt verweisen soll

!

!

!

‣ Datei-Attribute, wie Format und Zeichensatz angeben

DOAG 2014 BI

ODI - REVERSE ENGINEERING DER DATENSTRUKTUR‣ Mit Hilfe des Reverse Engineering Dateiaufbau

einlesen, so dass das Objekt im Mapping verwendet werden kann

DOAG 2014 BI

ODI - BEWERTUNG DER QUELLEN INTEGRATION‣ gleicher Aufwand beim erstmaligen Erstellen von

Speicherorten in beiden Tools

‣ Mit Hilfe des Kontext können im ODI gleichen logischen Elemente auf unterschiedliche physikalische Elemente zeigen -> Im OWB gibt es eine ähnliche Möglichkeit mit den Dateispeicherorten an den einzelnen Modulen (Multi-Konfiguration, Control-Center)

‣ Beide Tools unterstützen einen beim Einlesen der Datei-Metadaten

DOAG 2014 BI

ODI - ZIEL-SCHEMA DEFINIEREN‣ Erstellen eines physikalischen und logischen

Schemas zur Abbildung der Datenspeicherung

DOAG 2014 BI

ODI - IMPORT DER ZIELDATENSTRUKTUR‣ Model erstellen, welches auf das logische

Zielschema zeigt

‣ Importieren der Metadaten der Zieltabelle aus der Datenbank (Selektives Reverse Engineering)

!

!

‣ ggf. Tabelle vorher in der DB anlegen

DOAG 2014 BI

ODI - MAPPING‣ Neues Projekt erstellen

‣ In dem Projekt ein Mapping erstellen und Quell- und Zielobjekt per Drag&Drop ins Mapping ziehen

DOAG 2014 BI

ODI - MAPPING ‣ Zuweisen von Quell-

zu Zielspalten

!

‣ Auswählen des passenden Integrationstyps (in diesem Fall „Control Append“) -> Datensätze werden nur hinzugefügt

DOAG 2014 BI

ODI - LKM‣ Zuordnen des LKM (Loading Knowledge Modul):

„LKM SQL to SQL “

‣ LKM: Wie werden dieDaten aus der Quelle extrahiert

DOAG 2014 BI

ODI - IKM‣ Zuordnen des IKM (Integration Knowledge Modul):

„IKM Oracle Insert“

‣ IKM: Wie werden dieDaten in das Ziel geladen

DOAG 2014 BI

ODI - MAPPING‣ Ausführen des Mappings

und Verarbeitung überprüfen

DOAG 2014 BI

ODI - BEWERTUNG‣ Mapping Designer in beiden Tools sehr ähnlich

‣ Wann wird welches Integration/Loading Knowledge Modul genommen und warum?

‣ Anlegen von Zieltabellen im ODI nicht sehr komfortabel

‣ Lassen sich nur aus dem Mapping mit Create Table erstellen (gibt beim 2ten Durchlauf eine Warnmeldung, falls nichts aus)

‣ Partionierung, Indexe in unterschiedlichen Tablespaces -> Objekte lieber selber direkt in der DB anlegen

-> OWB auf Oracle Datenbank zugeschnitten, ODI kommt aus der Middleware und ist heterogener aufgestellt

DOAG 2014 BI

!

!

!

!

!

-> Umsetzung in beiden Tools sehr ähnlich

ZUSAMMENFASSUNG / GEGENÜBERSTELLUNG

OWB ODI

Speicherorte einrichten x xQuelldatei einbinden x xMapping erstellen x xMapping deployen x xMapping

ausführen x x

Erstellung eines Szenarios

Code einfrieren

DOAG 2014 BI

AGENDA

Das Projekt

Erste Schritte

Umsetzung des Workflows

Unterschiede

Fazit/Ausblick

DOAG 2014 BI

SCHAUBILD / ARCHITEKTURZeiterfassung der Projektmitarbeiter

Datenbereitstellung durch Projektmitarbeiter

automatischeDatenverarbeitung

mit dem ODI

Konsolidierte Daten in der Oracle DB

Einwurf Share

DOAG 2014 BI

ODI - WORKFLOW‣ Dateien werden in einem zentralen Ordner als txt-/csv-Datei

(gleicher Aufbau) abgelegt

‣ Ein Prozess überwacht diesen Ordner und verarbeitet die abgelegten Dateien automatisch

‣ Löschen von Daten die für die Ressource und Monat schon da sind

‣ Daten laden

‣ Datei verschieben

DOAG 2014 BI

ODI - WORKFLOW (PACKAGE)

Auf Dateiwarten

Daten löschen Daten laden

Datei verschieben

DOAG 2014 BI

AGENDA

Das Projekt

Erste Schritte

Umsetzung des Workflows

Unterschiede

Fazit

DOAG 2014 BI

DB-FUNKTIONEN/PROZEDUREN‣ keine Möglichkeit diese zu importieren und direkt

einzubinden ‣ 2 Möglichkeiten:

1. In einer Expression aufrufen

2. ODI-Prozedur als Wrapper erstellen !

!

-> Nachteil: Kein Import der Objekte und Unterstützung in der IDE

DOAG 2014 BI

PRE-/POST-MAPPING‣ Im ODI gibt es kein Pre-/Post-Mapping Operatoren

‣ Im ODI muss diese Funktion mit anderen Mitteln umgesetzt werden

‣ Die einfachste Möglichkeit ist, die Prozeduren in einer Package vorher aufzurufen

!

-> Testen der Verarbeitung muss über eine Package durchgeführt werden

DOAG 2014 BI

WORKFLOW - PACKAGES / LOAD PLANS ‣ Im OWB wird die Ausführung mehrerer Mappings

durch Workflows gesteuert (seriell, parallel)

‣ Im ODI gibt es Packages und Load Plans

‣ Unterscheiden sich z.B. in der Transaktionssteuerung und bieten nicht die gleichen Funktion (z.B. Load Plans bei paralleler Ausführung verwenden, Packages bei Schleifen)

-> Einarbeitung nötig (es gibt auch keine Migration von Workflows)

DOAG 2014 BI

MEHRERE TABELLEN BEFÜLLEN‣ Es ist wie im OWB möglich mehrere Tabellen in

einem zu befüllen

‣ Ein Splitt-Operator steht zudem zur Verfügung

‣ Allerdings gibt es keine Target-Load-Order um die Tabellen in einer bestimmten Reihenfolge zu befüllen

-> Aufspaltung in mehrere Mappings nötig

DOAG 2014 BI

ODI - SZENARIEN‣ ODI-Objekte werden als Szenarien bereitgestellt

‣ Szenarien können von unterschiedlichen Objekten erstellt werden (Mappings, Prozeduren, Packages)

‣ Der Code des Objekts wird „eingefroren“ und bereitgestellt (Entwicklung -> Produktion)

‣ Bei Änderungen in den Objekten, muss ein neues Szenario erstellt und wiederum bereitgestellt werden

DOAG 2014 BI

AGENDA

Das Projekt

Erste Schritte

Umsetzung des Workflows

Unterschiede

Fazit

DOAG 2014 BI

BEWERTUNG DER PRODUKTIVITÄT‣ Durch Flowbased Mappings und Packages ist die

Konzeption mit dem OWB vergleichbar ‣ Produktivität leidet im Moment, da

‣ DB-Objekte (Packages, Prozeduren, Funktionen) extra gewrappt werden müssen

‣ Testen über Packages und nicht Mappings erfolgen muss

‣ Nützliche Komponenten in den ODI-Packages (filewait, Variablen deklarieren, erhöhen)

NICHT DEN KOPF IN DEN SAND STECKEN

DOAG 2014 BI

FAZIT‣ ODI ist kein Hexenwerk, allerdings muss man sich wie mit

jeder neuen Technologie intensiv damit auseinander setzen

‣ In heterogenen Projekten hat der ODI seine Vorteile

‣ In reinen Oracle-Umgebungen ist der OWB besser geeignet

!

‣ Selber loslegen und eigene Erfahrungen sammeln

VIELEN DANK FÜR IHRE AUFMERKSAMKEIT

HABEN SIE NOCH FRAGEN?