Business Intelligence Automatisierung durch Data Vault: Umsetzungen mit Microsoft SQL Server Integration Services und SAS Base

Textprobe:

Kapitel 3, Automatisierungsmöglichkeiten von Data Vault:

Bei dem DV-Modell bietet es sich an, eine Befüllung des Schemas zu automatisieren. Ermöglicht wird dies vor allem dadurch, dass das Modell immer aus den drei Entitätstypen Hub, Link und Satellit besteht und diese vom Grundsatz her immer gleich aufgebaut sind. Ein Ansatz für eine Automatisierung ist die metadatengesteuerte Generierung von Ladeprozessen. Bei diesem Vorgehen werden auf Grundlage von Metadaten komplette ETL-Strecken, wie beispielsweise die Befüllung eines Hubs von dem Quellsystem bis in das DV, generiert. Ein weiterer Ansatz ist die Erstellung eines einzelnen metadatengesteuerten Ladeprozesses. Dieser Prozess kann durch Metadatensteuerung alle Tabellen mit gleicher Verarbeitungslogik befüllen. Dies bietet sich besonders durch die einfache Verarbeitungslogik eines DV an. Beide Vorgehensweisen werden später näher erläutert. Der Vorteil der Metadatensteuerung beider Ansätze besteht darin, dass der Umgang mit der Automatisierung für einen Nutzer relativ einfach ist. Grund dafür ist, dass dieser nicht in irgendeiner Art und Weise in die Automatisierung eingreifen muss, sondern alle Änderungen, wie beispielsweise im DV, in den Metadaten erfolgen können. Sollten zum Beispiel neue Teile in das DV aufgenommen werden müssen diese nur dort definiert werden.
Der Ansatz des metadatengesteuerten Ladeprozesses wird allerdings von den wenigsten ETL-Tools unterstützt. Beispielsweise ist es laut Dörffler + Partner mit Informatica PowerCenter nicht ohne weiteres möglich. Microsoft SSIS unterstützt dieses Vorgehen ebenfalls nicht, wobei es von Drittanbietern, beispielsweise cozyrock, zusätzliche Pakete gibt, durch welche diese dynamische Prozesssteuerung wiederum möglich ist. Das einzige ETL-Tool, welches in Vorbereitung auf dieses Buch untersucht wurde und die Möglichkeit für einen metadatengesteuerten Ladeprozess bietet, ist Pentaho Kettle. Weiterhin denkbar ist eine solche Umsetzung mittels einer herkömmlichen Programmiersprache. Daraus entstand die Motivation im Rahmen dieser Untersuchung eine Umsetzung mit der Sprache SAS Base zu entwickeln. Diese Sprache ist auf die Verarbeitung großer Datenmengen ausgelegt und bringt viele bereits integrierte Möglichkeiten für die Verarbeitung von Daten mit sich. Im Folgenden werden beide Varianten der Metadatensteuerung näher erläutert.
3.1, Bestehende Automatisierungssoftware für Data Vault:

Es sind bereits einige Anwendungen mit diversen Automatisierungsfunktionen hinsichtlich des DV verfügbar. Die laut Dörffler + Partner bekanntesten werden in den folgenden vier Unterkapiteln betrachtet, wobei der Fokus auf den Möglichkeiten der automatisierten Befüllung eines DWH liegt. Alle Lösungen sind entweder speziell für DV entwickelt worden oder unterstützen es als Option neben anderen Modellierungsvarianten. Bis auf das PDI DV Framework stellen alle Lösungen umfassende DWH-Verwaltungssoftware dar. Sie können zum Beispiel eigenständig Metadaten erzeugen und pflegen, nötige Datenbankschemata aufbauen und befüllen sowie Änderungen daran verwalten.
Aufgrund des vorhandenen Angebots stellt sich die Frage, weshalb für dieses Buch zwei Eigenentwicklungen realisiert wurden. Der Hauptgrund ist, einen möglichst gerechten Vergleich der methodisch unterschiedlichen Ansätze zu ermöglichen. Von der bereits erhältlichen Software wäre das PDI DV Framework die einzige Umsetzung eines dynamischen Ladeprozesses. Es hat aber einen wesentlich geringeren Funktionsumfang als die anderen vorgestellten Anwendungen. Würde man diese Software als Vertreter für einen dynamischen Ladeprozess verwenden, wäre die Frage, welche Software zur Generierung der Prozesse als Vergleich herangezogen werden könnte. Die beiden für diese Untersuchung entwickelten Anwendungen hingegen sind von Anfang an darauf ausgelegt, sich möglichst gut miteinander vergleichen zu lassen. Sie werden beide auf identischen virtuellen Maschinen installiert und nutzen dasselbe Betriebssystem. Weiterhin sind die Datenbanken für die Testquelldaten identisch, beide Entwicklungen bieten denselben Funktionsumfang und verwenden dieselben Metadaten. Zusätzlich ermöglicht diese Vorgehensweise einen Vergleich des Entwicklungsaufwands beider Methoden.
3.1.1, WhereScape RED:

Das Produkt RED der US-amerikanischen BI-Beratungsfirma WhereScape stellt eine integrierte Entwicklungsumgebung zum Aufbau und der Befüllung eines DWH dar. Das Programm ist in der Lage standardisiere Datenbank-Objekte und entsprechenden SQL-Code zur Befüllung zu generieren; weiterhin erzeugt es beispielsweise zugehörige Dokumentationen oder Diagramme. RED unterstützt vier Datenbanken: Microsoft SQL Server, Teradata, Oracle Database und DB2. Als grundlegendes Datenmodell nutzt es die dritte Normalform, das Sternschema oder DV. Letzteres passt gut zu der Philosophie der Software nicht ETL-, sondern 'ELT'-Prozesse zu verwenden. Damit ist gemeint, dass alle Daten unbedingt erst einmal in das EDW-System kopiert werden sollten, bevor beliebige Transformationen vorgenommen werden. Wie bereits in zuvor beschrieben, folgt das DV-Konzept einem ähnlichen. Beim Anlegen des DWH erzeugt RED Metadaten; zum Beispiel über alle Quellsysteme und das DWH selbst, aber auch über von diesem abhängige Objekte wie DMs. Diese gesammelten Informationen speichert RED innerhalb des erstellten DWH im sogenannten 'WhereScape RED Repository' ab. Der RED-Client greift auf diese Daten zu und nutzt sie zum Generieren und Verändern aller Ladeprozesse. Neben 'RED Desktop' als Client und Entwicklungsumgebung sowie dem RED Repository für Metadaten, enthält RED noch eine dritte Hauptkomponente: den RED Scheduler als Steuerungsprogramm für alle erzeugten Prozesse. Der Client benötigt ein Windows-System, das Steuerprogramm gibt es neben Windows- ebenfalls für Linux- und Unix-Systeme. Da RED alle erforderlichen Metadaten im DWH speichert und ausschließlich standardisierte Datenbankobjekte und Befüllungsprozesse erzeugt, ist es weitestgehend systemunabhängig. So ist es möglich, nach der Erstellung aller Datenbankobjekte und Prozesse RED vollständig zu deinstallieren. Das DWH ließe sich dann trotzdem mit einem dritten Datenbanktool und den bisherigen Prozessen weiter betreiben.
3.1.2, Quipu:

Quipu ist ein Open-Source-Werkzeug zur Entwicklung und Verwaltung von DV-basierten DWH. Es ist ein Produkt der niederländischen BI-Beratungsfirma QOSQO, welche bereits seit Jahren in BI-Projekten mit internationalen Unternehmen auf das DV-Modell zurückgreift. Dabei haben die Mitarbeiter erkannt, dass sich das Modell zur automatischen Erstellung und Befüllung eignet. Immer wieder schrieben sie entsprechende Skripte für einzelne Kunden. Im Rahmen eines Projektes bei einer niederländischen Großbank entwickelte sich auf diese Weise schließlich eine umfassende DWH-Management-Lösung. Diese verwaltete unter anderem die verwendeten Datenmodelle, ETL-Prozesse und die zugehörige Dokumentation. Aus diesem Projekt entwickelte sich 2010 schließlich Quipu. Die Software generiert metadatengesteuert eine Stage-Datenbank, ein DV-Modell und die zugehörigen ETL-Prozesse zur Befüllung. Es analysiert dabei die Struktur aller Quelldaten und macht einen Vorschlag für den Aufbau eines DV-Modells. Dieses kann und soll nachbearbeitet werden. So muss der Nutzer unbedingt entscheiden, was wirkliche Geschäftsschlüssel sind und als Hub abgebildet werden soll. Ebenfalls ist es sinnvoll, dass die Benennung der einzelnen Tabellen angepasst wird, damit das DV-Modell übersichtlich bleibt. Quipu ist Java-basiert und damit plattformunabhängig. Die Bedienung ist in jedem Fall über ein Web-Interface möglich. Für Windows-Betriebssysteme gibt es zusätzlich noch eine grafische Oberfläche.