Hello again HANA!

SAP-HANA – In wenigen Schritten zur ersten Anwendung [Teil 2]
Kommentare

Im zweiten Teil der Artikelserie werden weitere Funktionen der SAP-HANA-Plattform zur Programmierung von Anwendungen vorgestellt. Ausprobieren lassen sich die Beispiele mit einem kostenfreien Entwickleraccount in der SAP HANA Cloud Platform.

Nach einer Einführung in die Funktionen der SAP-HANA-Plattform und dem grundlegenden Aufbau einer nativen SAP-HANA-Anwendung im ersten Teil der Artikelserie werden im Folgenden weitere Möglichkeiten zur funktionalen Erweiterung des Programmgerüsts vorgestellt. Dabei geht es um die Umsetzung einer Wertschöpfungskette, die aus Daten relevante Informationen für Entscheidungen oder Analysen gewinnt.

Mit der Möglichkeit einer kennzahlenbasierten Auswertung in Echtzeit, der Analyse unstrukturierter Daten per Text-Mining, der Nutzung integrierter Data-Mining- und Predictive-Analysis-Algorithmen sowie der Verarbeitung lokationsbasierter Daten, werden unterschiedliche Werkzeuge für die Umsetzung eines durchgängigen Wertschöpfungsprozesses von Daten bereitgestellt.

Abgerundet werden die Technologien zur Datenanalyse durch weitere Funktionen der In-Memory-Plattform, die eine durchgängige Implementierung einer kompletten Anwendung erlauben. Die extended application services von SAP HANA ermöglichen die Programmierung und das Deployment von Anwendungen direkt auf der Plattform. Alle notwendigen Komponenten zur Implementierung einer Lösung werden durch SAP HANA bereitgestellt.

Zur Steuerung des Wertschöpfungsprozesses wird Kontrollflusslogik in Form von nativen SAP-HANA-Anwendungen genutzt. Die Darstellung der Benutzeroberfläche erfolgt geräteunabhängig mit HTML5-basierten Oberflächen.

Ein Vorteil bei der Programmierung von Anwendungen mit SAP HANA ist die Möglichkeit, komplexe Datenanalysen direkt auf dem normalisierten Datenmodell auszuführen. Die übliche Kopie der transaktionalen Daten in ein spezielles analytisches Datenmodell (z. B. in ein Star-Schema oder Snow-Flake-Schema) entfällt. Spezielle Tabellen oder Aggregate zwecks Vorberechnung bestimmter Kennzahlen aus Laufzeitgründen sind bei der In-Memory-Plattform nicht erforderlich.

Stattdessen erlaubt SAP HANA die Modellierung von so genannten Information-Views, die eine kennzahlenbasierte Auswertung transaktionaler Daten in Echtzeit ermöglichen. Echtzeit bedeutet dabei, dass die zu analysierenden Daten nicht physisch kopiert oder transformiert werden müssen, bevor eine OLAP-basierte Auswertung möglich ist (Abb. 1). Durch den Verzicht von Lade- und Bereitstellungsprozessen vereinfacht sich nicht nur die Lösungsarchitektur, auch stehen die Daten für eine Analyse schneller zur Verfügung.

Darum ist eine Echtzeitverarbeitung mit SAP HANA möglich

Eine SAP-HANA-Kerntechnologie, die der Echtzeitanalyse zu Gute kommt, ist die spaltenbasierte Verarbeitung der relationalen Tabellen. Konzeptionell ist eine relationale Tabelle eine zweidimensionale Datenstruktur, unterteilt in Zeilen und Spalten. Speicher wird dahingegen als lineare Datenstruktur verarbeitet. Dies führt zu den beiden Möglichkeiten, die Daten der Tabellen entweder spaltenorientiert oder zeilenorientiert in den Speicher zur weiteren Verarbeitung zu legen. SAP HANA unterstützt beide Organisationsformen, ist aber speziell für die spaltenbasierte Verarbeitung optimiert.

Spaltenbasierte Tabellen lassen sich i. d. R. höher komprimieren als ihre zeilenbasierten Pendants. Dies liegt daran, dass die Daten einer Spalte immer vom gleichen Datentyp sind. Ist die Spalte auch noch sortiert, liegen wiederholende Datenmuster physisch nebeneinander im Speicher. Dadurch kommen effiziente Komprimierungsalgorithmen zum Einsatz, wie z. B. Run-Length-Encoding, Cluster-Encoding und Dictionary-Encoding. Da beim Dictionary-Encoding alle Daten einer Spalte als Bitsequenzen (Integer) gespeichert werden, ist es ebenfalls möglich, sehr schnelle Vergleichsoperationen (basierend auf Integervergleichen) während z. B. Table-Scan- oder Join-Operationen durchzuführen.

In vielen Fällen macht eine spaltenbasierte Speicherung auch die Definition von Sekundärindizes überflüssig, da durch die Spaltenorganisation funktional bereits ein Index vorliegt.
Die Geschwindigkeit mit der die In-Memory-Spalten einer SAP-HANA-Tabelle gescannt werden können und die Vorteile insbesondere des Dictionary-Encodings erlauben sehr hohe Lesegeschwindigkeiten und machen die Definition zusätzlicher Indizes oftmals überflüssig. Gerade bei der Datenanalyse gewinnt man dadurch an Flexibilität und reduziert gleichzeitig die Größe und Komplexität des Datenmodells.

Komprimierte Daten können darüber hinaus schneller in CPU-Caches geladen werden, was somit auch dem gesamten In-Memory-Konzept von SAP HANA zu Gute kommt. Dieser Geschwindigkeitsvorteil beim Befüllen der CPU-Caches ist deutlich höher als die Zeit, die für die Dekomprimierung der Daten benötigt wird.
Ein weiterer wichtiger Punkt ist, dass SAP HANA so programmiert ist, dass grundlegende Berechnungen wie analytische Joins, Scans oder Aggregationen parallel ausgeführt werden. Je nach Ausbau der Hardware-Appliance werden zahlreiche Cores gleichzeitig verwendet.

Mit einer spaltenbasierten Tabellenorganisation können Operationen auf einzelne Spalten (wie z. B. ein Scan oder eine Aggregation) als Schleifen über ein Array von zusammengehörenden Daten realisiert werden. Eine solche Operation hat dabei eine hohe so genannte „Spatial Locality“, d. h. alle nebeneinander liegenden Daten haben eine direkte Relevanz zur Beantwortung der SQL-Anfrage und können somit effizient im CPU-Cache abgearbeitet werden. Bei einer zeilenorientierten Tabellenorganisation würden relevante Daten nicht direkt nebeneinander im Speicher liegen, was zu „Cache Misses“ bei der Abarbeitung durch die CPU führt.

Darüber hinaus können spaltenbasierte Tabellen gut parallel von mehreren CPU-Cores bearbeitet werden, da die Daten ja bereits vertikal partitioniert vorliegen. Zum einen bedeutet dies, dass Operationen auf unterschiedlichen Spalten gut parallel abgearbeitet werden können; zum anderen bedeutet dies aber auch, dass Operationen auf einer einzigen Spalte ebenfalls über mehrere Cores parallelisiert werden können, indem die Spalte in mehrere Sektionen partitioniert wird.

Analyse von Daten mit Information Views

Die Zielsetzung der Modellierung von Information Views ist die Bereitstellung von Daten im Kontext fachlicher Fragestellungen. Um Daten näher an der Realität zu analysieren und damit relevantere Entscheidungen zu treffen, ermöglichen die Information Views eine direkte Auswertung transaktionaler Daten in voller Granularität. Die Daten aus dem normalisierten, relationalen Modell der In-Memory-Datenbank werden durch die Information Views kombiniert, gefiltert und angereichert. Auch eine parametrisierte Abfrage aus der Anwendung ist möglich.

Durch die parallelisierte In-Memory Engine rechnet SAP HANA die Information Views in Echtzeit. Auch entfallen Summenberechnungen im Datenmodell oder die Definition von Aggregaten.
SAP HANA bietet drei unterschiedliche Information Views zur Auswertung der operativen Daten: (1) Attribute Views (2) Analytic Views und (3) Calculation Views (Kasten: „Die drei SAP HANA Information Views zur Berechnung von KPIs“).

Die drei SAP HANA Information Views zur Berechnung von KPIs

Attribute Views werden zur Modellierung von Entitäten verwendet, die auf Beziehungen (d. h. JOINS) zwischen mehreren Tabellen des relationalen In-Memory-Datenmodells basieren. Ebenfalls wird die Modellierung von Hierarchien unterstützt (Level- und Parent-Child-Hierarchien).

Analytic Views werden verwendet, um Informationen zu modellieren, die auch Kennzahlen (Measures) beinhalten, so z. B. ein operativer Data Mart, der Bestellinformationen sowie eine Bestellhistorie beinhaltet und entsprechende Kennzahlen für Mengen, Preise usw. anbietet. Typischerweise wird bei der Modellierung von Analytic Views nicht nur auf Basistabellen des relationalen Datenmodells zurückgegriffen, sondern auch zuvor modellierte Attribute Views wiederverwendet.

Calculation Views werden bei der Modellierung komplexer und umfangreicher Auswertungen verwendet. Im Gegensatz zu Analytic Views können Calculation Views z. B. mehrere Faktentabellen verknüpfen sowie Berechnungen mithilfe von SQLScript-Prozeduren ausdrücken. Eine Calcuation View kann darüber hinaus eine beliebige Kombination aus Tabellen, Attribute, Analytic und anderen Calculation Views enthalten.
Die Information Views werden in der SAP-HANA-Modeler-Perspektive der Eclipse-basierten Entwicklungsumgebung erstellt (Abb. 2).

Abb. 2: In der SAP-HANA-Modeler-Perspektive werden die Information Views zur Echtzeitanalyse von transaktionalen Daten erstellt

Abb. 2: In der SAP-HANA-Modeler-Perspektive werden die Information Views zur Echtzeitanalyse von transaktionalen Daten erstellt

Im Systems-Tab der Modeler-Perspektive werden die verbundenen SAP-HANA-Systeme angezeigt, auf denen Information Views modelliert werden können. Darüber hinaus besteht über den Systems-Tab die Möglichkeit, mit allen In-Memory-Datenbankobjekten, wie z. B. Tabellen, zu arbeiten.

Zu erwähnen ist auch die Job-Log-View zur Darstellung von Status- und Laufzeitinformationen unterschiedlicher Arbeitsabläufe auf der SAP-HANA-Instanz. So wird z. B. der Status zur Validierung- oder auch Aktivierung einer Information View angezeigt. Im Falle eines Fehlers kann hierüber direkt das Fehlerprotokoll geöffnet werden.
Der Quick Launch Editor der Modeler-Perspektive beinhaltet eine Sammlung von Shortcuts zu den am häufigsten verwendeten Aufgaben im Kontext der Modellierung von Information Views.

Über den entsprechenden Quick-Launch-Shortcut wird eine neue Calculation View mit dem Namen SALESORDER erstellt. Die Information View wird dabei im Package hellohana der nativen SAP-HANA-Anwendung gespeichert, die im ersten Teil der Artikelserie programmiert wurde.

Der Editor zur Modellierung der Information Views unterteilt sich in ein Szenario-Panel und einen Details-Bereich. Im Szenario-Panel wird der Datenfluss modelliert. Gelesen wird der Datenfluss von unten nach oben. Abhängig von der Art der modellierten Information View ist der Datenfluss mit Standardknoten ausgerüstet. Bei einer Calculation View sind das ein Semantics- und ein Aggregation-Knoten.

Zusätzlich zu den Standardoperationen wird für die Calculation View SALESORDER ein Join-Knoten aus der Scenario-Palette vor den Aggregation-Knoten eingefügt. Da der Join-Knoten Verkaufsstatistiken der Geschäftspartner bereitstellt, enthält er den Namen BP_SALE. Dem Join-Knoten können entweder andere Information Views (z. B. Analytic und Attribute Views) oder auch Tabellen aus dem normalisierten Datenmodell hinzugefügt werden. Im folgenden Beispiel werden die beiden Tabellen SNWD_SO (Bestellinformationen) und SNWD_BPA (Geschäftspartnerinformationen) aus den SAP-HANA-Beispieldaten EPMSAMPLEDATA verknüpft. Der Join der Tabellen erfolgt über die Spalten BUYER_GUID (aus der Tabelle SNWD_SO) und NODE_KEY (aus der Tabelle SNWD_BPA) mit einem LEFT OUTER JOIN.

Um Informationen zum Umsatz der Unternehmen anzuzeigen, werden die Tabellenspalten GROSS_AMOUNT und NET_AMOUNT der Tabelle SNWD_SO und die Spalte COMPANY_NAME der Tabelle SNWD_BPA über das Kontextmenü der Ausgabe hinzugefügt (Abb. 3).

Der Join-Knoten wird im Scenario-Bereich des Information-View-Editors mit dem Aggregation-Knoten per Drag and Drop verbunden. Auch beim Aggregation-Knoten werden die Spalten GROSS_AMOUNT, NET_AMOUNT und COMPANY_NAME für die Ausgabe selektiert.

Neben Join-Knoten können in einer Calculation View auch Union-Knoten zur Verknüpfung des Datenflusses verbaut werden. Zusätzlich steht auch noch ein Projection-Knotentyp zur Verfügung. Auch eigene Logik in Form von SQLScript-Prozeduren kann eingebunden werden.

Ebenfalls besteht die Möglichkeit, zusätzlich zu den Spalten aus dem Datenmodell weitere berechnete Spalten zu modellieren oder Eingabeparameter zu definieren, bzw. auf bestimmte Zeilen oder Spalten zu filtern.

Als Abschluss der Wertschöpfungskette definiert der Semantics-Knoten weitere View-Eigenschaften, wie z. B. Kennzahlen mit entsprechendem Aggregationsverhalten (z. B. SUM, MAX, MIN oder COUNT).

Nach erfolgreicher Speicherung und Aktivierung der Calculation View setzt der Aufruf einer gespeicherten Prozedur der SAP HANA Cloud Platform (HCP) das notwendige Datenbankprivileg, um lesend auf die Calculation View zuzugreifen. Der Befehl wird aus einer SQL-Konsole im Eclipse ausgeführt:

CALL "HCP"."HCP_GRANT_SELECT_ON_ACTIVATED_OBJECTS"

Das aktivierte Laufzeitobjekt der Calculation View SALESORDER wird im Datenbankschema _SYS_BIC verwaltet und dort im Ordner Column Views angezeigt. Der Zugriff auf die Calculation View erfolgt über das Schema _SYS_BIC, so zum Beispiel bei folgendem SQL-Befehl:

SELECT * FROM "_SYS_BIC.p123trial.dev.hellohana/SALESORDER"

Der Accountname p123trial ist mit dem eigenen Account der SAP HANA Cloud Platform zu ersetzen. Der SELECT-Ausdruck gibt den Brutto- und Nettojahresumsatz unterschiedlicher Firmen aus.

Abb. 3: Definition einer Verknüpfung zwischen zwei Tabellen im Join-Knoten der Calculation View

Abb. 3: Definition einer Verknüpfung zwischen zwei Tabellen im Join-Knoten der Calculation View

Neben dem Zugriff auf Information Views per SQL stellen die extended application services von SAP HANA eine RESTful-Schnittstelle in Form von OData bereit.

RESTful-Service-Definition

Bei der Programmierung einer nativen SAP-HANA-Anwendung kann der Zugriff auf die Daten oder zuvor definierter Information Views über OData Services [3] erfolgen.
Die Definition und der Test von OData-Schnittstellen erfolgt in der SAP-HANA-Developer-Perspektive der Eclipse-basierten Entwicklungsumgebung. Im Kontextmenü des angelegten XS-Projekts hellohana wird über New → XS OData der Wizard zur Erstellung eines neuen XS-OData-Service geöffnet.
Die Servicedefinition soll einen lesenden Zugriff auf die zuvor definierte Calculation View SALESORDER ermöglichen. Die Definition des Service in der Datei salesorder.xsodata sieht wie folgt aus:

service {
"_SYS_BIC"."p123trial.dev.hellohana/SALESORDER" as "so" key("COMPANY_NAME");
}

Der OData-Service wird auf das Laufzeitobjekt der Calculation View im Datenbankschema _SYS_BIC definiert.

Damit der Zugriff auf die Daten der Calculation View über den OData-Service erfolgen kann, muss die bereits angelegte Rolle dataaccess.hdbrole um einem entsprechende Eintrag erweitert werden. Die komplette Rollendefinition lautet:

role p123trial.dev.hellohana.roles::dataaccess {
catalog sql object "EPMSAMPLEDATA"."SNWD_BPA_CONTACT":SELECT;
catalog sql object "_SYS_BIC"."p123trial.dev.hellohana/SALESORDER":SELECT;
}

Um die Rolle in der SAP HANA Cloud Platform zu aktivieren, wird folgender SQL-Befehl ausgeführt:

CALL
"HCP"."HCP_GRANT_ROLE_TO_USER"('p123trial.dev.hellohana.roles::dataaccess','p123')

Ist die Rolle dataaccess erfolgreich dem Nutzer der SAP HANA Cloud Platform zugewiesen (im Beispiel der Nutzer p123, der den HCP-Account p123trial verwendet), wird der XS-OData-Service über das Kontextmenü Run As → XS Service der Servicedefinition-Datei salesorder.xsodata aufgerufen. Nach Eingabe des SAP-HANA-Cloud-Platform-Nutzernamens und -Passworts zeigt der Browser die Daten des OData-Service an. Durch die Ergänzung des Service-URL mit /so/?$format=json erfolgt die Ausgabe der Daten im JSON-Format.

Weitere Informationen zur Nutzung und Parametrisierung der OData-Service-Definition sind im SAP HANA Developer Guide [5] oder auf der offiziellen OData-Seite zu finden.

Serverseitiges JavaScript

Zusätzlich zu OData wird per serverseitigem JavaScript auf Informationen der In-Memory-Datenbank zugegriffen. Dazu wird eine neue XS-JavaScript-Datei salesOrderService.xsjs über New | XS JavaScript File im XS-Projekt hellohana angelegt. Die Datei definiert den Zugriff auf die SALESORDER Calculation View über das JavaScript-Database-API. Die Ergebnisse werden im JSON-Format zurückgegeben (Listing 1).

Listing 1
var select_all_sales_orders_query =
"SELECT TOP 10 COMPANY_NAME, NET_AMOUNT, GROSS_AMOUNT " +
"FROM \"_SYS_BIC\".\"p123trial.dev.hellohana/SALESORDER\" " +
"ORDER BY GROSS_AMOUNT DESC";
function close(closables) {
var closable;
var i;
for (i = 0; i < closables.length; i++) {
closable = closables[i];
if(closable) {
closable.close();
}
}
}
function getSalesOrders(){
var salesOrdersList = [];
var connection = $.db.getConnection();
var statement = null;
var resultSet = null;
try{
statement = connection.prepareStatement(select_all_sales_orders_query);
resultSet = statement.executeQuery();
var salesOrder;
while (resultSet.next()) {
salesOrder = {};
salesOrder.company_name = resultSet.getString(1);
salesOrder.net_amount = resultSet.getDouble(2);
salesOrder.gross_amount = resultSet.getDouble(3);
salesOrdersList.push(salesOrder);
}
} finally {
close([resultSet, statement, connection]);
}
return salesOrdersList;
}
function doGet() {
try{
$.response.contentType = "application/json";
$.response.setBody(JSON.stringify(getSalesOrders()));
}
catch(err){
$.response.contentType = "text/plain";
$.response.setBody("Error while executing query: [" + err.message + "]");
$.response.returnCode = 200;
}
}
doGet();

Zur Visualisierung der Daten wird die mit der SAP-HANA-Plattform ausgelieferte SAPUI5-Bibliothek [4] verwendet.

UI-Entwicklung

Zur Darstellung der Rückgabewerte des salesOrderService.xsj– Service wird ein BarChart-Control aus der SAPUI5-Bibliothek verwendet. Die Bibliothek ist Teil der SAP HANA extended application services. Nach der Initialisierung des BarChart-Controls wird das JSON-Model durch Aufruf des zuvor definierten XS-JavaScript-Service gefüllt und dem Chart zugewiesen:
var topSalesCompanyBarChart = new sap.viz.ui5.Bar(...);
var salesModel = new sap.ui.model.json.JSONModel();
salesModel.loadData("salesOrderService.xsjs");
topSalesCompanyBarChart.setModel(salesModel);

Über die View werden so mittels einer HTML-Seite index.html die Top-10-Firmen mit dem meisten Umsatz angezeigt (Listing 2 und Abb. 4).

Listing 2
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<script src="/sap/ui5/1/resources/sap-ui-core.js?x33575" id="sap-ui-bootstrap"
data-sap-ui-libs="sap.ui.ux3,sap.ui.commons,sap.ui.table,sap.viz"
data-sap-ui-theme="sap_bluecrystal">
</script>
<script>
sap.ui.localResources("views");
var view = sap.ui.view({
id : "companies",
viewName : "views.Companies",
type : sap.ui.core.mvc.ViewType.JS
});
view.placeAt("content");
</script>
</head>
<body class="sapUiBody" role="application">
<div id="content"></div>
</body>
</html>

Die HTML-Seite kann aus dem Kontextmenü Run As | HTML ausgeführt werden. Auch im SAP-HANA-Cloud-Platform-Cockpit kann über die Kategorie HANA XS Applications die deployte Anwendung gestartet werden.

Abb. 5: Darstellung der JSON-Daten in einem SAPUI5-Barchart im Browser eines mobilen Endgeräts

Abb. 5: Darstellung der JSON-Daten in einem SAPUI5-Barchart im Browser eines mobilen Endgeräts

Fazit

Neben der Möglichkeit einer kennzahlenbasierten Analyse direkt auf transaktionalen Daten kann die Wertschöpfungskette der Daten durch weitere In-Memory-Funktionen wie z. B. Data-Mining, Predicitve-Analysis oder Text-Mining gestaltet werden. Durch die SAP HANA extended application services wird die Datenanalyse durch native SAP-HANA-Anwendungen gesteuert. Dazu wird JavaScript verwendet. Für einen Zugriff über RESTful-Services steht OData zur Verfügung. Zur Gestaltung geräteunabhängiger Oberflächen wird das HTML5-basierte SAPUI5-SDK verwendet.

Lesen Sie: Teil 1 von SAP-HANA – In wenigen Schritten zur ersten Anwendung

Aufmacherbild: step by step to a higher level Foto via Shutterstock / Urheberrecht: Camilo Torres

Abb. 1: Durch die Möglichkeit mit SAP HANA direkt die transaktionalen Daten analytisch auszuwerten, sind Anwendungen möglich, die analytische- und transaktionale Use Cases direkt kombinieren

Abb. 1: Durch die Möglichkeit mit SAP HANA direkt die transaktionalen Daten analytisch auszuwerten, sind Anwendungen möglich, die analytische- und transaktionale Use Cases direkt kombinieren

Abb. 1: Durch die Möglichkeit mit SAP HANA direkt die transaktionalen Daten analytisch auszuwerten, sind Anwendungen möglich, die analytische- und transaktionale Use Cases direkt kombinieren

Abb. 1: Durch die Möglichkeit mit SAP HANA direkt die transaktionalen Daten analytisch auszuwerten, sind Anwendungen möglich, die analytische- und transaktionale Use Cases direkt kombinieren

Abb. 1: Durch die Möglichkeit mit SAP HANA direkt die transaktionalen Daten analytisch auszuwerten, sind Anwendungen möglich, die analytische- und transaktionale Use Cases direkt kombinieren

Abb. 1: Durch die Möglichkeit mit SAP HANA direkt die transaktionalen Daten analytisch auszuwerten, sind Anwendungen möglich, die analytische- und transaktionale Use Cases direkt kombinieren

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -