http://www.opitz-consulting.com
"Automatisierung im DWH" war das Thema unserer Experten Marian Strüby und Dr. Jens Bleiholder zusammen mit Ulf Jeffke, Manager Voice & Data Anlalyst - Vodafone Kabel Deutschland, bei der DOAG 2015 Konferenz und Ausstellung.
Modularisierung, Standardisierung, Automatisierung. Mit diesen drei Stichworten kann man die Vorteile des ODI 12c als ETL-Tool im eigenen DWH-Projekt auf den Punkt bringen. Der ODI eröffnet hier eine ganze Reihe an Möglichkeiten, die Entwicklung eines DWH zu beschleunigen, dem Entwickler Arbeit abzunehmen und gleichzeitig die Entwicklung zuverlässiger und fehlerfreier zu machen. Dabei wird die Entwicklung noch wesentlich effizienter, wenn man auch bei Datenmodellierung und Architektur auf Modularisierung, Standardisierung und Automatisierung achtet und z.B. Data Vault verwendet. Anhand von Beispielen aus einem Kundenprojekt stellen wir unsere Erfahrungen auf diesem Gebiet vor und zeigen, wie der ODI 12c im Projekt dabei hilft und ein DWH größtmöglich automatisiert, aufzubauen: Generieren von Datenmodellen und zugehörigen Mappings, automatisches Deployment, Anpassung von Knowledge-Modulen etc. Den Kunden freut es, bekommt er nun mehr DWH für sein Geld. Den Entwickler freut es, muss er nun nicht mehr die langweiligen immer gleichen Arbeiten erledigen. Den Endanwender freut es, bleibt nun mehr Zeit übrig, um auf seine Probleme und Businesslogik einzugehen.
Warum ist Standardisierung wichtig?
Beispiel SCHUKO-Stecker, so dass man in jedem Land seine Geräte nutzen kann…
Findet man hier noch bessere, weitere Dinge? Warum sollte man Dinge standardisieren, was wird dadurch einfacher?
Welche Möglichkeiten hat man bei den Datenmodellen im DWH, Dinge zu Standardisieren?
Wie kann man im ETL Standardisieren?
Welche Regeln kann man aufstellen
Auch im ETL hat man Möglichkeiten Dinge zu standardisieren, bzw. überall gleich zu machen: Historisierung, Wiederanstartbarkeit, Reihenfolge, …
Im OWB z.B. durch Post-Skripte realisiert
Zentrale Komponente des ODIs sind die Knowledge Module (KM)
Für jede Phase des ETL-Prozesses gibt es verschiedene KMs, die für die unterschiedlichen Technologien entwickelt wurden.
Die Anpassung der KMs ist leicht zu erlernen, da man sich in der Sprache des dazugehörigen Systems bewegt (z.B. SQL + PL/SQL wenn mit einer Oracle-DB agiert wird)
Über die KMs werden Prozesse automatisch standardisiert und einzelne Funktionen (z.B. Historisierung/SCD2) als Modul ausgelagert.
Damit ist die Implementierung der eigentlichen Mappings deutlich weniger komplex deklaratives Design in Perfektion!
Reverse: Engineering Metadaten
Journalize: Über CDC Delta abgrenzen
Load: Aus Quellen in Staging
Check: Constraints vor dem Laden prüfen
Integrate: Transformieren und in Ziel integrieren
Service: Daten- oder Transformationsservice
Beispiel KMs (out-of-the-box):
Oracle GoldenGate
Oracle DB Link
Oracle Hyperion Essbase
Typ 2 SCD
SAP R/3
Oder aber auch: temporäre, pluggable Mappings. Komponenten, die Funktionalität beliebig wiederverwertbar machen
Mit der Java-API hat man quasi alle Möglichkeiten, eine Automatisierung zu implementieren.
Es können alle Funktionen des ODI gesteuert werden. Das ODI SDK ersetzt OMB*Plus im OWB, ist aber durch die Verwendung von Java statt tcl deutlich flexibler und besser einzusetzen.
Durch die Automatisierung lassen sich Entwicklungsvorgaben großflächig anwenden. Änderungen an den Standards werden einmalig im Java Code geändert und dann schnell auf die betroffenen Bereiche ausgerollt. Das ist ein entscheidender Faktor bei der Steigerung der Entwicklungsgeschwindigkeit.
In unseren Projekten setzen wir die Automatisierung z.B. bei der Generierung von Data Vault-Mappings und bei der Replikation von Daten aus den Quellen in die Stageebene ein.
OMB+ Skriptsprache im OWB
- T_SOURE_TABLE: Quelltabellen Weitere normalisierte Tabellen mit Informationen zu Schemas und Systemen werden nicht dargestellt
- T_SOURCE_COLUMN: Spalten der Quelltabellen. Markieren der Spalten, ob Business Key (Hub-Verknüpfung) bzw. Attribut (Satellite-Verknüpfung)
- T_HUB: Liste der Hubs
- T_LINK: Liste der Links
- T_SATELLITE: Liste der Satelliten
- T_HUB_LINK: Beziehungen zwischen Hubs und Links
- T_HUB_SATELLITE: Beziehungen zwischen Hubs und Satellites
- T_LINK_SATELLITE: Beziehungen zwischen Links und Satellites
- T_DV_META: Metadaten zu Data Vault Objekten, Namensschema, Name und Datentyp für die Spalten LOAD_DTS und RECORD_SOURCE
- Festlegen der grundlegenden Namensregeln und Definition globaler Spalten (Hash, BK, LOAD_DTS,…) und deren Datentypen
- Freiheit in Java: auch Schwächen des SDKs abfangen, um Entwicklungsstandardisierung über das SDK hinaus zu erweitern
Groovy_config.txt – 4 Spalten (Schema, Tabelle, Spalte, SCD Value)
RDV,SAT_HOTSPOT,*,ADD_ROW_ON_CHANGE
RDV,SAT_HOTSPOT,*_HASH,NATURAL_KEY
RDV,SAT_HOTSPOT,LOAD_DTS,START_TIMESTAMP
Der Algorithmus:
Alle Rows auf den Wert "ADD_ROW_ON_CHANGE" zusetzen
Das Attribut dass den Hash enthält wird auf "NATURAL_KEY" gesetzt (ACHTUNG: der * im Script ist keine echt Wildcard! Er wurde hardcoded in das Groovy Script geschrieben)
Das Attribut dass den Start Timestamp enthält muss auf "START_TIMESTAMP" gesetzt werden
Das Attribut dass den Ende Timestamp enthält muss auf "END_TIMESTAMP" gesetzt werden
Das Attribut LOAD_INS_SID wird immer auf "OVERWRITE_ON_CHANGE" gesetzt
Das Attribut LOAD_UPD_SID wird immer auf "OVERWRITE_ON_CHANGE" gesetzt
Das Attribut REC_SRC_ID wird immer auf "OVERWRITE_ON_CHANGE" gesetzt
Skillset +Java
Axel, ich bin…
Jens, ich bin… und wer sind sie? Fachbereich/Nutzer, IT/Umsetzer, Entscheider