saracus-software-lösung für Data Warehouse Automation

Transkript

1 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 Generische von Delta-Verarbeitung Ulrich Hebestreit von ETL-Experte der saracus Ulrich Hebestreit consulting GmbH BI-Experte der saracus consulting GmbH

2 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 Data- Erfahrungen, 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 als PDF zum Download bereit. saracus-software-lösung DWH Automation für generisches ETL-Processing Seite 1

3 Einführung Agiles Data Warehousing, Data-Vault-Modellierung und DWH-Automation sind die aktuellen Buzzwords im BI/DWH- Umfeld, 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 saracus-software-lösung DWH Automation für generisches ETL-Processing Seite 2

4 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. saracus-software-lösung DWH Automation für generisches ETL-Processing Seite 3

5 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 CORE- Schicht 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 'Full- Update'-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 >= 10 8 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 saracus-software-lösung DWH Automation für generisches ETL-Processing Seite 4

6 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- saracus-software-lösung DWH Automation für generisches ETL-Processing Seite 5

7 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'-delta- Deskriptor 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). saracus-software-lösung DWH Automation für generisches ETL-Processing Seite 6

8 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. saracus-software-lösung DWH Automation für generisches ETL-Processing Seite 7

9 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 saracus-software-lösung DWH Automation für generisches ETL-Processing Seite 8