Seit vielen Jahren setzen Unternehmen SAP Business Warehouse (BW) erfolgreich für ihr Reporting ein. Durch aktuelle Trends wie Big Data und Industrie 4.0 steigt jedoch die Notwendigkeit, Massendaten flexibel und in Echtzeit auszuwerten. Da SAP Hana die dafür benötigte Technologie zur Verfügung stellt, empfiehlt sich den Unternehmen eine BW-on-Hana-Migration, die Verbesserungen im Bereich der Datenhaltung, Datenmodellierung und Architektur möglich macht.
Foto: Melpomene-shutterstock.com
SAP Hana als Innovationsmotor
Die Plattform macht viele bisherige Maßnahmen zur Performance-Steigerung in BW-Systemen obsolet, ist aber die Voraussetzung für neue Funktionen, die daher ausschließlich für BW-on-Hana-Systeme verfügbar sind.
Die Leistung von SAP Hana basiert im Wesentlichen auf vier Prinzipien:
In-Memory steht für das Vorhalten aller Daten im Arbeitsspeicher, das - im Gegensatz zum Business Warehouse Accelerator (BWA) - das Reporting für alle BW-Daten beschleunigt. Damit kann auf die aufwendige Cache-Verwaltung verzichtet und eine konstant geringe Zugriffszeit für Lese- und Schreibvorgänge garantiert werden. Der Arbeitsspeicher wird nicht wie üblich vom Betriebssystem, sondern von SAP Hana direkt verwaltet.
Spaltenorientierte Datenhaltung bedeutet, dass die Daten einer Tabelle spaltenweise gespeichert werden. Gegenüber der immer noch üblichen zeilenbasierten Datenhaltung ist damit eine erheblich bessere Datenkomprimierung möglich, da Inhalt und Datentyp in einer Spalte sehr ähnlich sind. Auch Berechnungen innerhalb einer Spalte sind performanter, wodurch auf das Voraggregieren von Daten im BW verzichtet werden kann. Bei allen Vorteilen beherrscht SAP Hana dennoch auch die zeilenorientierte Datenhaltung.
Insert-Only ist ein Konzept, das Schreiboperationen an Datensätzen für spaltenbasierte Tabellen performanter durchführt. Neue oder geänderte Datensätze werden zunächst in eine zeilenbasierte Delta-Tabelle geschrieben. Die entsprechend aufwendigen Änderungen der spaltenbasierten Tabellen ("Delta Merge") werden in regelmäßigen Abständen gesammelt durchgeführt.
Appliance ist die Bezeichnung dafür, dass die Software gemeinsam mit einem zertifizierten Server und optimierten Betriebssystem ausgeliefert wird. Es stehen mehrere Konfigurationsvarianten zur Auswahl, um die optimale Unterstützung von Hardware und Software zu garantieren.
Hana bietet für BW-Systeme jedoch nicht nur eine hohe Performance, sondern umfasst zahlreiche zusätzliche Funktionen, man spricht daher von der SAP-Hana-Plattform. Dazu gehören unter anderem die Advanced Function Libraries (AFL), die komplexe Algorithmen unter direkter Nutzung der internen Hana-Komponenten ausführen. Sie werden unter anderem für Vorhersagemodelle verwendet. Eine Auswahl können BW-on-Hana- Kunden als SAP Hana Analysis Process direkt im BW verwenden. Die Ausführung erfolgt direkt auf Datenbankebene.
Die In-Memory-Plattform verfügt zudem über einen eigenen Anwendungsserver, der die Entwicklung und den Betrieb von Anwendungen direkt auf Datenbankebene erlaubt. SAP nutzt diese Möglichkeit selbst und bietet zahlreiche dieser sogenannten XS-Anwendungen an. Sie können oft parallel zu BW-on-Hana betrieben werden. Eine weitere zentrale Funktion ist die Erstellung von SAP Hana Views, das sind BW-ähnliche Objekte, die aus Datenbanktabellen entwickelt werden. Sie können zum Beispiel über SAP-Reporting-Tools, wie Lumira, ausgewertet werden und ergänzen das SAP BW um eine weitere Modellierungsmöglichkeit.
Besonderheiten in der Datenmodellierung für BW-on-Hana
Während es bisher im SAP BW meist erforderlich war, zur Beschleunigung von Analysen und Berichten Daten in einem InfoCube vorzuhalten, entfällt unter BW-on-Hana diese Notwendigkeit. Queries, die auf einem DataStore-Object (DSO) basieren, können nun genauso schnell ausgeführt werden. Daher ist der Einsatz von InfoCubes unter BW-on-Hana häufig sogar komplett überflüssig.
Soll allerdings ein bestehendes BW-System auf SAP Hana migriert werden, können bestehende Datenmodelle meist nicht alle angepasst werden, nur um InfoCubes zu eliminieren. In diesem Fall lohnt es sich, deren Konvertierung in SAP-Hana-optimierte InfoCubes durchzuführen. Dadurch werden die Tabellen der InfoCubes für die Plattform optimiert, was die Ladevorgänge deutlich beschleunigt.
Bei der Entwicklung von Datenflüssen in BW galt bisher das Prinzip, BEx-Queries nicht direkt auf InfoProvidern, sondern auf MultiProvidern aufzusetzen. Ausschlaggebend dafür war, dass sich auf diese Weise Datenmodelle im Zeitverlauf flexibel an neue Anforderungen anpassen lassen, etwa wenn neue InfoProvider in ein bestehendes Datenmodell integriert werden sollen. Mit dem Einsatz von BW-on-Hana empfiehlt es sich jedoch, anstelle eines MultiProviders dafür den neuen, SAP-Hana-spezifischen CompositeProvider zu verwenden. Dieser macht sowohl die Modellierung flexibler als auch die Zusammenführung der Daten zur Laufzeit schneller.
BW-Prozesse mit längeren Laufzeiten, wie das Aktivieren von DSO-Requests, werden auf die SAP-Hana-Datenbank verlagert. Zum einen beschleunigt dies die Ausführung der Prozesse, und zum anderen müssen weniger Daten zwischen BW-Server und Datenbank ausgetauscht werden. Dieser Ansatz wird auch als "Code Push-Down"-Prinzip bezeichnet. Analog werden in neueren BW-on-Hana-Versionen auch bestimmte BW-Transformationen direkt in der SAP-Hana-Datenbank ausgeführt. Weil die Daten dann ausschließlich SAP-Hana-intern verarbeitet werden, können so nicht nur hohe Geschwindigkeitssteigerungen erzielt, sondern es kann auch der BW-Server entlastet werden.
Die Datenmodellierung im BW war bislang häufig recht zeitaufwendig und umfangreich. Um eine verlässliche Datenbasis zu schaffen, war die Erstellung von zahlreichen BW-Objekten wie InfoObjekte, Transformationen und InfoProvidern notwendig. Unter BW-on-Hana stehen nun besonders "schlanke" InfoProvider, sogenannte "Open ODS Views", zur Verfügung. Diese können direkt auf Datenbanktabellen zugreifen, setzen keine InfoObjekte voraus und führen notwendige Berechnungen zur Laufzeit direkt in SAP-Hana durch.
Auch der Umgang mit Prozessketten wird verbessert. Nicht länger benötigt werden beispielsweise die Prozessschritte zum Aufbau und Löschen von Indizes für InfoCubes, zum Aktualisieren von Datenbankstatistiken oder zum Hochrollen gefüllter Aggregate. Enthalten bestehende Prozessketten noch diese obsoleten Prozessschritte, werden diese bei der Ausführung unter BW-on-Hana einfach übersprungen.
Layered Scalable Architecture ++ (LSA++)
2007 entwickelte SAP die Layered Scalable Architecture (LSA) mit dem vorrangigen Ziel, konsistente Daten in einem Enterprise Data Warehouse (EDW) und somit auch eine konsistente Business-Intelligence- und Reporting-Lösung zur Verfügung zu stellen. Um den klaren Aufbau eines EDW zu unterstützen, werden die Daten durch die LSA in verschiedenen Ebenen strukturiert. Diese Ebenen legen die Daten auf unterschiedlichen Aggregationsniveaus ab.
Motiviert durch die neuen Möglichkeiten des Szenarios SAP BW powered by SAP Hana stellte SAP 2012 die Weiterentwicklung der LSA zur LSA++ vor. Diese hatte die Verschlankung des "klassischen" LSA-Ansatzes zu einem konsistenten Kern zum Ziel. Dieser Kern besteht aus den verschiedenen Ebenen der LSA und enthält konsistente Daten, die durch die LSA sichergestellt werden. Daneben gibt es Erweiterungen, den Virtual Data Mart Layer und den Open Operational Data Store Layer (Open ODS Layer) (siehe Abbildung 1).
Foto: Camelot ITLab
Um eine Verbindung zwischen einem EDW und dem operativen BI-Ansatz zu ermöglichen, wird der Open ODS Layer eingeführt. Dieser ermöglicht es, neben Daten, die im SAP BW gemanagt werden, auch Daten aus anderen Datenquellen in das Reporting einzubeziehen, ohne dass die Daten in SAP BW geladen werden müssen. Trotzdem kann damit ein direktes Reporting aufgebaut werden. Die flexible Einbeziehung von zusätzlichen Daten macht es möglich, neue Berichtsanforderungen schnell und einfach abzudecken.
Der konsistente Kern der LSA++ umfasst die ursprünglichen Layer der LSA, die den Aufbau eines EDW ermöglichen. Er wird durch die folgenden Layer gebildet:
EDW Transformation Layer - erste Transformation der Daten
Corporate Memory - Historisierung der Quelldaten.
EDW Propagation Layer - Persistierung der Quelldaten
Business Transformations - zweite Transformation der Daten
Architected DatA Mart Layer - Persistierung der Daten
Der Virtual Data Mart Layer sorgt zudem dafür, dass die Daten aus den anderen Layern für das Reporting mit BEx Queries zur Verfügung stehen.
Insgesamt wird damit der Anwendungsbereich der LSA++ gegenüber der LSA deutlich erweitert, und zwar durch den Einsatz neuer InfoProvider, die für das Szenario BW-on-Hana zur Verfügung stehen. Durch die Verwendung der LSA++-Architektur ergeben sich folgende Vorteile und Möglichkeiten:
Iterative / inkrementelle Verwendung eines multi-dimensionalen Modellierungsansatzes auf Basis eines EDW-Ansatzes
Die LSA++ bietet zudem Stabilität durch das verwendete Rahmenwerk, definiert durch die LSA++ Layer und die EDW-Dimensionen, die durch die Kern-InfoObjekte festgelegt werden.
Auch haben Anwender die Möglichkeit, feldbasierte InfoProvider zu verwenden, was wiederum eine Offenheit für andere Datenquellen als SAP bedingt.
Fazit
Die Vorteile von SAP-BW-on-Hana gegenüber dem klassischen BW-Ansatz beruhen aus technologischer Sicht vor allem auf der In-Memory- und spaltenbasierten Datenbankhaltung. Im Bereich der Datenmodellierung sind vor allem die neuen InfoProvider, wie SAP-Hana-optimierte InfoCubes, der neue CompositeProvider und Open ODS Views, zu nennen. Darüber hinaus trägt auch die schlankere LSA++-Architektur, die zugleich neue Einsatzszenarien für SAP BW eröffnet, erheblich zur Verbesserung der Datenhaltung und damit zur breiten Akzeptanz von BW-on-Hana bei. (bw)