Wenn in einem Data Warehouse mehrere Quellsysteme fachlich bedingt mit identischen Datenmodellen arbeiten, dann werden die Daten auch in den Cleansing, Core und Mart Areas in gemeinsamen Tabellen abgelegt. Für die Datenbeladung kann es von Vorteil sein, nicht alle Quellen gemeinsam zu verarbeiten, sondern unabhängige Prozesse zu etablieren, um zeitliche und fachliche Unabhängigkeit zu erlauben. Als technische Voraussetzung müssen alle Tabellen nach Quellsystem partitioniert sein:
CREATE TABLE mytab ( dwh_opco_id NUMBER, <columns>)
PARTITION BY LIST (dwh_opco_id)
(
PARTITION opco_1 VALUES(1),
PARTITION opco_2 VALUES(2),
…
) …
Welche Möglichkeiten gibt es aber nun im ODI 12c, um partitionsweises ELT zu implementieren?
Parametrisierte Variablen
Mit Hilfe der globalen bzw. der Projektvariablen lässt sich die Verarbeitung im ODI sehr flexibel gestalten. Ich definiere eine zentrale Projektvariable g_opco_shortname, die den fachlichen Bezeichner für die Quelle (Operational Company) enthalten wird. Die anderen Variablen, wie z.B. die technische g_opco_id (Partitionsspalte) oder g_opco_partition (Partitionsname) verwenden diese in ihrer Refreshing-Definition. Eine globale Variable würde man mit #GLOBAL.variablenname ansprechen, eine Projektvariable (in unserem Fall heißt das Projekt „DWH“) mit #PROJEKTNAME.variablenname. Damit sind sie von g_opco_shortname abhängig und können zur Laufzeit den entsprechenden Wert annehmen.
Knowledge Module
Die Standard Knowledge Module von Oracle arbeiten mit Tabellen bzw. Views, aber nicht mit Partitionen. Also muss ich die entsprechenden Stellen in den Knowledge Modulen anpassen, damit bei der Selektion Daten gefiltert werden und beim Insert direkt die gewünschte Partition verwendet wird. Um flexibel zu bleiben, definiere ich erst Optionen, die den Wert der Variablen annehmen können. Diese Optionen werden dann im Code der Knowledge Module verwendet.
Mappings
Bei den Mappings ist nicht viel zu beachten. Diese werden wie gewohnt entworfen ohne Rücksicht auf zukünftiges partitionsweises Laden. Nur zwei Sachen sind wichtig:
-
Einbinden des neuen Knowledge Modules, welches die Verarbeitung auf eine Partition einschränken wird.
Generiertes Statement vor der Änderung Generiertes Statement nach der Änderung INSERT INTO target_tab
(<columns>)
SELECT <columns>
FROM(<source_tabs>)INSERT INTO target_tab PARTITION (OPCO_1)
(<columns>)
SELECT <columns>
FROM(<source_tabs>)
WHERE dwh_opco_id = 1 -
Setzen der Unique-Option für I$-Tabellen, falls diese bei der Verarbeitung verwendet werden. Diese Option stellt sicher, dass der Name für die automatisch erzeugte Zwischentabelle nicht von dem Zieltabellennamen hergeleitet wird, sondern eine interne Sequence verwendet, um immer eindeutige Namen zu erzeugen. Damit ist es möglich, dasselbe Mapping für unterschiedliche Partitionen gleichzeitig laufen zu lassen.
Ladeplan
Nun habe ich meine Knowledge Module und die Mappings vorbereitet. Jetzt möchte ich einen Ladeplan haben, den ich für jedes Quellsystem verwenden kann. Und das geht auch sehr einfach. Der Ladeplan wird wie gewohnt definiert und beinhaltet alle notwendigen Mappings. Für alle Variablen, die von v_opco_shortname abhängig sind, wird am Anfang die Refresh-Option gesetzt. Die Variable v_opco_shortname wird hier nicht gesetzt, da der Ladeplan ja allgemein bleiben soll.
Jetzt kann ich für jede Quellgesellschaft einen eigenen Scheduler anlegen. Erst im Scheduler setzte ich die Variable v_opco_shortname auf den jeweiligen Wert. Bei einem manuellen Start des Ladeplans wird man vom ODI aufgefordert die gewünschten Variablen zu setzten – an dieser Stelle muss die v_opco_shortname ebenfalls gefüllt werden.
Damit ist es jetzt möglich, Daten aus einzelnen Quellsystemen unabhängig voneinander bis in den Mart zu laden. Selbstverständlich können Sie auch alle Quellsysteme gleichzeitig verarbeiten – Voraussetzungen dafür sind da. Viel Spaß beim Ausprobieren!