Aufbau eines Data Warehouses mit SAP HANA

Um den grundlegenden Unterschied zum klassischen Modell zu verdeutlichen, wird zunächst auf den Aufbau des modernen DWH-Ansatzes mit SAP HANA eingegangen.

Abb: Aufbau HANA Data Warehouse

1. Persistenzschicht: Es gibt nur eine einzige Schicht zur persistenten Datenhaltung. Das Datenmodell dieser Schicht ist relational und orientiert sich an den analytischen Auswertungsanforderungen. 
2. Virtuelle Datamart-Schicht: Alle Abnehmer des HANA Data Warehouses werden aus dieser Schicht versorgt. Der Zugriff erfolgt über Views auf die Persistenzschicht. 
3. Datenintegrationsschicht: Diese Schicht dient der Datenversorgung des HANA Data Warehouses. Hier erfolgt die Konsistenzprüfung, die Beladung und die Versionserzeugung der Daten.

Auswirkungen der redundanzfreien Datenhaltung

Sobald Daten in die Persistenzschicht geladen wurden, stehen sie durch den virtuellen Datamart unmittelbar allen Abnehmern zur Verfügung. Die neue Architektur ermöglicht es somit dem Fachbereich, schnellstmöglich auf die Daten zuzugreifen. Die entscheidende Frage aus Sicht der Fachbereiche ist dann: Sind die Daten vollständig und entsprechen sie meinen Vorgaben zur Datenqualität? Im Gegensatz zum klassischen Data Warehouse, in dem zunächst noch eine Beladung der Datamarts erfolgte, gibt es im HANA Data Warehouse keine internen Verarbeitungsprozesse mehr, in denen ermittelt werden könnte, zu welchem Zeitpunkt die Daten für einen bestimmten Abnehmer vollständig bereitstehen, und ob sie allen Datenqualitätsanforderungen entsprechen.

Im HANA Data Warehouse muss die Vollständigkeit und Richtigkeit daher mit anderen Methoden und an anderer Stelle bestimmt werden. Betrachtet man die drei Schichten, so wird klar, dass die Information über die Datenverfügbarkeit bereits während der Beladung der Persistenzschicht ermittelt werden muss, um sie dann im Rahmen eines Beladungsmonitorings allen Abnehmern zur Verfügung zu stellen.

Es gibt zwei grundlegend verschiedene Herangehensweisen, um das Beladungsmonitoring mit Daten zu versorgen. Eine Möglichkeit besteht darin, in jede ETL-Strecke Mechanismen einzubauen, die über entsprechende Schnittstellen ihre jeweiligen Protokollinformationen dem HANA Data Warehouse zur Verfügung stellen. Bei dieser Variante erhöhen sich die Implementierungskosten erheblich, wenn verschiedene ETL-Szenarien parallel zum Einsatz kommen sollen – wie zum Beispiel Batch-Lieferungen und Streaming-Technologien. Die andere Möglichkeit besteht darin, die Beladungsprotokollierung zentral durch die Datenintegrationsschicht durchführen zu lassen. Den eigentlichen Beladungsprozeduren vorgelagerte Methoden nehmen die Daten in Empfang und protokollieren den Beladungsstatus. Dieser zentrale Ansatz hat erhebliche Vorteile in Bezug auf Wartbarkeit und Erweiterbarkeit.

Auch für den zentralen Ansatz stellt sich die Frage, wie die Einführungs- und Betriebskosten der vorgelagerten Datenintegrationsschicht möglichst niedrig gehalten werden können. Immerhin müssen die vorgelagerten Methoden für dutzende Tabellen im HANA Data Warehouse angelegt werden. Wird das von Hand konzipiert und umgesetzt, dann bedeutet das einen erheblichen Aufwand – insbesondere auch bei späteren Erweiterungen des Data Warehouses.

Verlinkung von konzeptionellem zu physischem Datenmodell

Genau genommen stecken alle Informationen, die man für die Beladungssteuerung benötigt, bereits im Datenmodell des Data Warehouses. Somit ist es möglich, bereits in der Phase der Implementierung des HANA Data Warehouses (also zur Designzeit) Entwicklungsprozesse zu automatisieren, und beispielsweise die Datenintegrationsschicht zu generieren.

SAP HANA 2.0 beinhaltet als Komponente den SAP Enterprise Architecture Designer, der eine Integration des SAP PowerDesigners in die HANA-Entwicklungsumgebung darstellt. Dadurch entsteht die Möglichkeit, die konzeptionellen Eigenschaften des HANA Data Warehouses in einem zentralen Datenmodell zu modellieren, und die Generierungsmöglichkeiten des SAP Powerdesigners zu nutzen, um die eigentliche Implementierung der HANA-Artefakte zu automatisieren. Mit dieser Herangehensweise können Aufwände und Redundanzen sowohl für die Umsetzung als auch insbesondere für die Dokumentation vermieden werden.

SAP nutzt diese Herangehensweise für die Erzeugung der Persistenzschicht für die SAP HANA Financial Services Data Platform (FSDP). Der Kunde kann das Datenmodell erweitern (auch im Powerdesigner), und dieselben Generierungsmethoden werden verwendet, um diese Erweiterungen in der Persistenzschicht zu manifestieren. Dieses Prinzip lässt sich auch auf andere Datenmodelle außerhalb von Financial Services anwenden, sowohl bei branchenspezifischen Datenmodellen als auch bei einer kundenindividuellen Herangehensweise.

Weiter oben wurde bereits gezeigt, wie sich diese Herangehensweise auf die Generierung von Strukturen in der Datenintegrationsschicht nutzen lässt. Es stellt sich die Frage, inwieweit auch eine Verlinkung zur Datamart-Schicht möglich ist.

Die Aufgabe der Datamart-Schicht besteht darin, das Datenmodell des Data Warehouses für das Reporting zu transformieren, und abgeleitete Informationen, z.B. Kennzahlen, anzureichern. Hier stößt das Generierungsprinzip an seine Grenzen. Man kann aber umgekehrt die Implementierung der Datamart-Schicht auslesen und in einer gewissen „Flughöhe“ in einem konzeptionellen Datenmodell ablegen. Es handelt sich also um Reverse Engineering. Ziel ist es dabei, das Datenmodell als zentrale Referenz für die Data Lineage im Reporting nutzen zu können. Dabei ist zu beachten, dass Reverse Engineering nur dann umfassend funktionieren kann, wenn die relevanten Informationen bereits strukturiert in den implementierten Objekten vorliegen. Genaue Entwicklerrichtlinien und Namenskonventionen sind also Voraussetzung dafür, dass sich alle Informationen in das zentrale Datenmodell überführen lassen.

Zusammenfassung

Zusammengefasst lässt sich sagen, dass schon während der Vorüberlegungen zu einem modernen Data Warehouse mit SAP HANA darauf geachtet werden sollte, welche Herangehensweise der In-Memory-Datenhaltung am Besten gerecht wird. Mit den richtigen Methoden und dem richtigen Werkzeugkasten kann man die Implementierungsaufwände sowohl bei der Einführung als auch bei späteren Erweiterungen deutlich reduzieren, und gleichzeitig dafür sorgen, dass die Dokumentation im zentralen Datenmodell grundsätzlich aktuell ist. Dies ist die Grundlage für eine langfristig erfolgreiche Data Governance.