Whitepaper: DWautomatic - Assekuranz

Werbung
saracus-Software-Lösung für Data Warehouse Automation
DWautomatic
Architektur und Funktionalität einer Software-Lösung
für die generische automatisierte Verarbeitung von ETL-Prozessen
in einer Data-Warehouse-Umgebung
GENDEL
Generischevon
Delta-Verarbeitung
Ulrich Hebestreit
von
ETL-Experte der saracus
consulting GmbH
Ulrich Hebestreit
BI-Experte der saracus consulting GmbH
saracus consulting GmbH
saracus consulting veröffentlicht regelmäßig White Paper zum Themenbereich Big Data, Business Intelligence und
Data Warehousing. Diese White Paper vermitteln den BI-Praktikern umsetzbares Wissen, konkrete Anleitungen zur
Einführung von Best Practice-Methoden und filtert aus den (vermeintlichen) Innovationen die Praxisrelevanz für Anwendungsunternehmen. Die saracus White Paper sind keine Auftragsarbeiten für einen Sponsor (z.B. Hardware oder
Softwareanbieter aus dem BI-Markt) sondern basieren auf über 20 Jahre BI, DWH und neuerdings auch Big DataErfahrungen, die sich in über 300 BI-Projekten widerspiegeln.

saracus IBM Cognos TM1 Whitepaper (erschienen 2011)

saracus Big Data Whitepaper I (erschienen 07/2012)

saracus Big Data Whitepaper II (erschienen 01/2013)

saracus Datenmodellierung Whitepaper I (erschienen
04/2013)

saracus Big Data Whitepaper III (erschienen 06/2013)

saracus Datenmodellierung Whitepaper II (erschienen
01/2014)

saracus Social Media Whitepaper I (erschienen 04/2014)

saracus BI-Trends Whitepaper (erschienen 05/2014)

saracus ETL Whitepaper I (erschienen 07/2014)

saracus Datenmodellierung Whitepaper III (erschienen
09/2014)

saracus Whitepaper Core DWH Modellierung: Vergleich Data
Vault und konsolidierte Ankermodellierung (erschienen 3/2015)
Die Whitepaper stehen auf unserer Webseite unter http://www.saracus.com/saracus_240_white_paper.html als
PDF zum Download bereit.
www.saracus.com
saracus-Software-Lösung DWH Automation für generisches ETL-Processing
Seite 1
saracus consulting GmbH
Einführung
Agiles Data Warehousing, Data-Vault-Modellierung und DWH-Automation sind die aktuellen Buzzwords im BI/DWHUmfeld, die alle das Ziel verfolgen, die Entwicklung von DWH-Projekten durch einen möglichst hohen Automatisierungs-Grad zu beschleunigen und die Aufwendungen für den Betrieb zu reduzieren. Diese mehr oder weniger neuen
Konzepte sollen DWH-Projekte somit schneller, kostengünstiger und erfolgreicher machen. Ansatzpunkte für eine
Automatisierung und Projektbeschleunigung ergeben sich entlang der gesamten Data-Warehouse-Wertschöpfungskette.
Dazu gehören z.B.:
 ein übergreifendes DWH-Vorgehensmodell wie DWtec von saracus consulting
 analytische Branchendatenmodelle mit Datenmodellen für die Data-Mart-Schicht sowie das Core-DWH inkl.
Kennzahlen-Stammblätter und Reporting-Beispielen (vgl. hierzu DWinsurance von saracus consulting).
 Verwendung des Data-Vault-Modellierungsansatzes
 Generische ETL-Prozesse, die z.B. Struktur-Änderungen automatisch erkennen
 Automatische Testing-Tools
 Automatisierte Projekt-Versionskontrolle
Abbildung 1: Softwarelösungen und Utilities der saracus consulting zur DWH-Automatisierung und für Agiles Data Warehousing
Da der mit Abstand größte Aufwandstreiber bei DWH-Projekten die ETL-Prozesse sind, lassen sich hier durch eine
Automatisierung besondere Zeit- und Kostenvorteile realisieren.
Zu diesem Zweck hat die saracus consulting mit DWautomatic eine Software entwickelt, die sich wie folgt charakterisieren lässt:
 Metadaten-getriebene Umsetzung von Transformations- und Load-Funktionen
 Automatische Identifikation von Strukturänderungen / -erweiterungen
 Identifikation von neuen Dateninhalten mittels CDC und „eigener Kontrolle“
 Generische Umsetzung der Strukturänderungen / -erweiterungen
www.saracus.com
saracus-Software-Lösung DWH Automation für generisches ETL-Processing
Seite 2
saracus consulting GmbH





Automatisierte Historisierung / Versionierung von Daten
Schaffung eines „auditable“ Data Warehouse
Angepasst auf den Data-Vault-Modellierungsansatz
Optimiert für verschiedene RDBMS, um performante Parallelverarbeitung zu ermöglichen
Ein spezielles ETL-Tool ist für den Einsatz dieser Software nicht erforderlich
Die Software lässt sich für unterschiedliche Aufgabenstellungen einsetzen:
 Allgemeine Datenintegrationsaufgaben
 Einbindung eines neuen Quellsystems
 Transformation von der Stage ins Core
DWautomatic ist mit der Programmiersprache Java entwickelt worden und unterstützt alle gängigen Datenbanken
wie Oracle, DB2, SQL Server, Teradata oder MySQL. Für jede Datenbank wurde ein eigenes Software-Modul entwickelt, um die Besonderheiten der jeweiligen Datenbank zu berücksichtigen und z.B. die Datenbank-individuellen
Möglichkeiten zur Performance-Steigerung optimal zu nutzen.
Übersicht
Im Folgenden wird die Funktionsweise und Architektur von DWautomatic am Beispiel „Übernahme und Integration
der in der Stage-Schicht angelieferten Tabellen-Daten in die Core-Schicht innerhalb einer Data-Warehouse-Umgebung“ aus technischer Sicht dargestellt.
Die Daten werden dabei:
 zeitlich versioniert – Attribute 'dwa_validfrom/to'
 jede Version mit einer eindeutigen ID versehen – Attribut dwa_rowid'
 einfachen Transformationen unterworfen wie etwa
– Null-Wert-Ersetzung
– elementare Mapping-Regeln
Die Basis für die zeitliche Versionierung bildet der via Metadaten (Schema 'dwa_meta') definierte fachliche Schlüssel
je Tabelle. Die durch einen identischen fachlichen Schlüssel identifizierten STAGE- und CORE-Record-Paare werden
miteinander verglichen und der daraus abgeleiteten Aktion unterworfen:
neuer STAGE-Record
geänderter STAGE-Record
nicht gelieferter STAGE-Record
Einfügen einer 1. CORE-Version
Abschließen der alten Version, Einfügen der Folgeversion
Abschließen der alten Version, Einfügen der Folgeversion mit gesetztem
'deleted'-Indikator – Attribut 'dwa_deletedflag'
Die neueste Version eines Records hat dabei stets den 'aktiv'-Indikator gesetzt – Attribut 'dwa_activeflag'.
Der fachliche Schlüssel plus Versionierungsattribut 'dwa_validfrom' bilden den Primärschüssel jeder CORE-Tabelle.
DWautomatic unterstützt Full- und Delta-Lieferverfahren z. Z. in 2 verschiedenen CDC-Verfahren (CDC: changed data
capture):


CDC-Daten im IBM/DB2-Format
CDC-Daten im SAP-BW-Format
Neue CDC-Formate können leicht hinzugefügt werden.
www.saracus.com
saracus-Software-Lösung DWH Automation für generisches ETL-Processing
Seite 3
saracus consulting GmbH
Für DB2-artige Daten ist zusätzlich die Verarbeitung eines 'partial full' Lieferverfahrens implementiert, hier werden
nicht komplette Tabelleninhalte miteinander verglichen, sondern nur durch einen Teilschlüssel adressierte Teilmengen – als Regelfall sind hier Zeitscheiben zu nennen, wo etwa ein komplettes Jahr (nach)-geliefert und in die CORESchicht integriert werden soll.
In den Metadaten wird je CORE-Tabelle der Wiederaufsetzpunkt passend zur Liefermethode verwaltet:
DB2
SAP-BW
maximaler Zeitstempel der zuletzt erfolgreich verarbeiteten Lieferung
Request-Id des zuletzt erfolgreich verarbeiteten Pakets
Am Anfang der Verarbeitung wird zunächst anhand des Wiederaufsetzpunktes die Menge der zu verarbeitenden
Daten identifiziert und in 'Intervalle' zerlegt. Der Term 'Intervall' stammt dabei aus der DB2-Verarbeitung; hier muss
den angelieferten Daten zusätzlich erst noch eine Tagesstruktur aufgeprägt werden und daraus resultiert dann ein
tatsächliches Intervall der zu verarbeitenden Datensätze mit den Grenzen minimaler/maximaler Zeitstempel je Tag.
Für SAP-BW ist die Intervall-Ermittlung trivial, ein Intervall ist hier definiert als die zu einer Paket-Id/Request-Id gehörige Datenmenge.
Jedes Intervall wird 'ganz oder gar nicht' in der CORE-Zieltabelle persistiert. Im Delta-Fall wird je Intervall und fachlichem Schlüssel immer nur der zeitlich letzte Zustand ausgewählt und gespeichert.
Die Anzahl der Versionen wird dabei minimal gehalten, indem nicht nur auf die CDC-Aktion (insert/update/delete)
vertraut wird, sondern zusätzlich die Inhalte der Quelle-/Ziel-Record-Paare verglichen werden; nur wenn sich hier
eine tatsächliche Änderung ergeben hat, wird eine neue Version angelegt.
Bei einer Full-Datenlieferung kann manuell oder automatisch zwischen einem 'Full-New'-Verfahren oder einem 'FullUpdate'-Verfahren ausgewählt werden. Im 'Full-New'-Verfahren wird eine Schattentabelle komplett neu aufgebaut,
die dann am Ende des Verfahrens die Zieltabelle ersetzt. Im 'Full-Update'-Verfahren wird die Zieltabelle direkt via
'insert/update' mit der Quelltabelle abgeglichen.
Bei automatischer Auswahl versucht ein kleines 'Delta-Rule'-Modul anhand der Tabellengröße und einer Ähnlichkeitsanalyse das geeignete Verfahren auszuwählen. Die Ähnlichkeitsanalyse verursacht zwischen 10%-15% zusätzlicher Rechenzeit im Vergleich zur manuellen Auswahl. Die Erfahrung zeigt, dass ab einer Mutationsrate zwischen 8%10% das Full-New-Verfahren Performance-Vorteile bietet. Dies ist jedoch gerade bei großen Tabelle >= 108 Zeilen mit
dem zusätzlichen Platzbedarf abzugleichen.
Die Verarbeitung eines Intervalls wird durch eine Reihe vordefinierter Prozessschritte geleistet, Laufzeit-intensive
Schritte werden hierbei in einer Log-Tabelle protokolliert. Jeder Schritt kann eine oder mehrere fachliche/technische
Kennzahlen produzieren, die ebenfalls in der Log-Tabelle abgelegt werden. Neben dem knappen Logging schreibt
DWautomatic eine Log-Datei, in dem Zustände und Ereignisse festgehalten werden. Logging ist konfigurierbar:


der Level kann zwischen 0 (nichts) und 3 (furchtbar geschwätzig) gewählt werden
als Ziel kann eine Log-Tabelle und/oder eine Log-Datei gewählt werden
DWautomatic bietet zusätzlich folgende Services:





Generierung/Prüfung der Zielobjekte CORE-Tabelle und CORE-Delta-Views aus den Metadaten/STAGE-Tabelle
Automatisierte Strukturanpassung beim Ladevorgang – je nach gewählter Policy
Generierung von Sekundär-Indices, die während Beladung enabled/disabled/aktualisiert werden
Replikation einer Zieltabelle in die MART-Instanz
Steuerung der Parallelisierung der Datenbank via Metadaten
www.saracus.com
saracus-Software-Lösung DWH Automation für generisches ETL-Processing
Seite 4
saracus consulting GmbH
Modul-Architektur
Wie bereits erwähnt unterstützt DWautomatic alle gängigen relationalen Datenbanken. So werden z.B. bei Oracle
als zugrundeliegender Datenbank die ORACLE-Packages mit dem Namenspräfix 'dwa_' im Datenbankschema
'dwa_core' der CORE-Instanz implementiert.
Die folgende Abbildung zeigt die logische Modul-Architektur.
Abbildung 2: Software-Architektur
Jedes DWautomatic-Modul liest bei Bedarf 'seine' Metadaten aus dem Metadaten-Schema über ein spezielles Metadaten-Package. Zugriff über Metadaten-Views, die auf diesem Package basieren, ist ebenfalls möglich.
Innerhalb der CORE-Instanz bietet das Controller-Modul der Aufruf-Umgebung (Shell, Scheduler, ETL-Tool-Workflow,
etc.) die nötigen Schnittstellen, um eine einzelne Tabelle komplett zu verarbeiten. Der Controller ermittelt anhand
der Restart-Information die zu verarbeitenden Delta-Intervalle/-Pakete; für jedes gefundene Intervall wird das Processor-Modul mit den Intervalldaten parametrisiert aufgerufen.
Der Processor kreiert zunächst den Delta-Deskriptor mit Informationen über:





Quellsystem
Delta-Modus (Full- oder Delta-Load, etc.)
Struktur der Zieltabelle
Struktur der Quelltabelle
Sekundär-Indices
und führt den Abgleich zwischen Quell- und Zieltabellenstruktur durch. Im zweiten Schritt wird gemäß des Deskriptors die Step-Liste mit den durchzuführenden Prozessschritten ausgewählt. Jedem Step ist genau ein SQL-State-
www.saracus.com
saracus-Software-Lösung DWH Automation für generisches ETL-Processing
Seite 5
saracus consulting GmbH
ment oder Statement-Block zugewiesen; Statement oder Block werden dynamisch zum Step-Aufrufzeitpunkt generiert und ausgeführt. Die Ausführung erfolgt in der Regel in der CORE-Instanz.
Die Replikation einer CORE-Tabelle in eine MART- oder ODS-Umgebung bildet die Ausnahme dieser Regel; das generierte Step-Statement wird dem Processor-Proxy (Package auf der Mart-Instanz) zur Ausführung übermittelt.
In der Abbildung nicht gezeigt sind Utility-Module sowie das Modul zur Generierung der Zielobjekte:


CORE-Tabelle
CORE-Views
Diese Objekte werden aus der STAGE-Tabelle abgeleitet. Bei der Generierung wird zunächst ein 'abgespeckter'-DeltaDeskriptor erzeugt, mit dessen Hilfe dann die notwendige DDL für die Zielobjekte generiert und wahlweise ausgeführt wird.
Die Module jeder Ebene können separat aufgerufen und getestet werden. Controller und Processor persistieren zudem Kennzahlen zu Intervallen und ausgewählten Steps in den Metadaten (Schema dwa_meta).
www.saracus.com
saracus-Software-Lösung DWH Automation für generisches ETL-Processing
Seite 6
saracus consulting GmbH
Daten- und Kontrollfluss
Die folgende Abbildung zeigt den Daten- und Kontrollfluss.
Abbildung 3: Daten- und Kontrollfluss
Der zu einem Intervall gehörende relevante Datenausschnitt wird aus einer STAGE -Tabelle ausgelesen und in einer
ersten temporären Tabelle normiert persistiert (USS - Unique Source Slice). Abhängig von Deltatyp und -Modus werden sukzessive mehrere temporäre Tabellen erzeugt. Der Inhalt der USS-Tabelle wird i.W. durch das zu verarbeitende
Intervall definiert.
Die STAGE-Tabellen eines Liefersystems können lokal in der CORE-Instanz liegen oder via Database-Link in einer anderen Datenbank-Instanz angesprochen werden; die Lokation und STAGE-User werden pro Liefersystem in den Metadaten konfiguriert.
Falls entsprechend konfiguriert wird das Bild einer CORE-Tabelle (aktive und nicht-gelöschte Zeilen) in einen Data
Mart repliziert.
www.saracus.com
saracus-Software-Lösung DWH Automation für generisches ETL-Processing
Seite 7
saracus consulting GmbH
Parallelität am Beispiel der Oracle RDBMS
Aufgrund von Problemen bei der impliziten Allokation der parallelen Prozesse muss/kann z.B. bei Oracle mit der
aktuellen Version der Parallelitätsgrad explizit definiert werden, der Default-Wert hier ist 1 (noparallel). Ein Parallelitätsgrad kann in den Metadaten je CORE-Tabelle erfasst werden und wirkt innerhalb des DWautomatic-Pakets auf
die folgenden Objekte/Schritte:






Kreieren einer CORE-Tabelle, hier wird der Parallelitätsgrad entsprechend gesetzt
– parallel <n>
– noparallel
analog beim Kreieren des Primary Keys oder der Sekundär-Indices
analog beim Kreieren von temporären Tabellen sowie der 'New'-Tabelle Im Full-New-Prozess
'alter session enable parallel DML' im Full-New-Prozess nur noch, wenn der Parallelitätsgrad > 1 ausfällt
dito für Hint 'insert /*+ parallel */'
der Parallelitätsgrad wird bei der Replikation auf die MART-Tabelle vererbt
www.saracus.com
saracus-Software-Lösung DWH Automation für generisches ETL-Processing
Seite 8
Herunterladen