Big-Data-Technologien im Preismanagement – Technologischer Hintergrund

Im vorangehenden Abschnitt werden die Grunde erlautert, wieso sich herkommliche relationale Datenbanken meist nicht dazu eignen, Analysen mit groen Datenmengen durchzufuhren. Dementsprechend wird mit SAP HANA fur nachfolgende Analysen eine Technologien ausgewahlt, die auch mit Datenmengen in Big Data Dimensionen umgehen kann, und im nachfolgenden Abschnitt vorgestellt wird. Daruber hinaus wird die Google Places API, die als Datenquelle fur Standortinformationen verwendet wird, vorgestellt und Grunde fur diese Auswahl erlautert.

SAP HANA als zugrundeliegendes Datenbanksystem

SAP HANA ist ein weit verbreitetes4, kommerzielles Datenbanksystem auf SQL-Basis, welches auerdem Unterstutzung fur einen Einsatz im Big Data Kontext bietet. Es basiert auf In-Memory-Technologie, somit ermoglicht SAP HANA performante Analysen sehr groer Datenmengen, deren Verarbeitung in dieser Form mit herkommlichen relationalen Datenbanken kaum moglich ist. Grund hierfur ist, dass gangiges SQL nicht mehr alle Anforderungen moderner Anwendungen erfullen kann, da diese eine enge Interaktion mit der Datenmanagementschicht erfordern (vgl. [Farber et al., 2011]). Dies wird durch die Architektur von SAP HANA ermoglicht, wahrend weiterhin SQL fur traditionelle Anwendungen unterstutzt wird (vgl. [Farber et al., 2012]). Auerdem nutzt SAP HANA neue Hardwaremoglichkeiten, wie etwa sehr groe Mengen an Hauptspeicher, um die Performance von transaktionalen und analytischen Anwendungen zu verbessern (vgl. [Farber et al., 2011]). SAP HANA wurde nach einigen Grundsatzen designt (vgl. zu allen Grundsatzen [Farber et al., 2011]). (1) Es existiert eine Multi- Engine Abfrageverarbeitungsumgebung, die beispielsweise eine Textsuch-Engine oder eine Graph-Engine mit sich bringt, wodurch die Abfrageverarbeitung unterstutzt wird. (2) Die Reprasentation von anwendungsspezifischen Business-Objekten wird ermoglicht, es besteht in SAP HANA namlich die Moglichkeit, semantische Modelle zu registrieren, die fur mehr Semantik auf Datenmangementebene sorgen und somit das Verstandnis dieser Businessobjekte prazisieren. (3) Aktuelle Hardwareentwicklungen werden ausgeschopft, denn SAP HANA wurde von Grund auf fur parallele und hauptspeicherorientierte Umgebungen konzipiert. (4) Die effiziente Kommunikation mit der Anwendungsebene wird ermoglicht, dies geschieht durch eine Kommunikation zwischen proprietaren Anwendungsservern uber gemeinsam genutzten Speicher, sowie durch eine Angleichung der Datentypen innerhalb dieser Anwendungsserver. Das grundlegende Ziel der SAP HANA Datenbank ist die Integration analytischer und transaktionaler Aufgaben im selben Datenbankmanagementsystem (vgl. [Farber et al., 2012]).

SQLScript

Zusatzlich zu technologischen und architekturalen Verbesserungen wird SAP HANA um SQLScript erweitert, einer deklarativen Programmiersprache, die sich zwischen Datenbankebene und Applikationsebene befindet und die Implementierung von Anwendungslogik ermoglicht (vgl. [SAP SE, 2017b] und [Binnig et al., 2013]). SQLScript erweitert den HANA-eigenen Dialekt der Abfragesprache SQL (Structured Query Language), um komplexe, skalierbare Analysefunktionen in SAP HANA zu integrieren. Diese Erweiterung umfasst einerseits funktionale, sowie prozedurale Aspekte. Die funktionale Erweiterung erlaubt die Definition von deklarativen und optimierbaren Funktionen, um Big Data Analysen im Unternehmenskontext zu erlauben (vgl. [Binnig et al., 2013]). Im Gegensatz hierzu stellt die prozedurale Erweiterung imperative Konstrukte zur Verfugung, die es erlauben, eine Orchestrationslogik zu implementieren, etwa zur Vor- oder Nachverarbeitung einer analytischen Aufgabe (vgl. [Binnig et al., 2013]) und in dem Kontext angegangen wird. Ein Nachteil von klassischen SQL-Dialekten ist die Tatsache, dass eine SQL-Abfrage nur ein Ergebnis haben kann, zusammenhangende Ergebnisse mussen also in eigenstandige, fur die Datenbank unabhangige Abfragen aufgespalten werden, was das Potential fur Optimierung verringern kann (vgl. [SAP SE, 2017b]). Ein Beispiel fur die Erweiterung durch SQLScript sind die vordefinierten Funktionen, die ein optimiertes Data Mining auf Tabellen der HANA-Umgebung, wie beispielsweise ein Clustering von Daten mit Hilfe verschiedener clusteranalytischer Verfahren, ermoglichen und im nachsten Abschnitt angesprochen werden.

SAP HANAs Predictive Analysis Library

Die Predictive Analysis Library (PAL) ist eine SAP HANA Bibliothek, die SQLScript- Funktionen zum Durchfuhren von analytischen Algorithmen zwecks Data Mining umfasst (vgl. [SAP SE, 2017a]). Durch die Nutzung der Funktionen der Predictive Analysis Library uber SQLScript ist es moglich, Daten innerhalb einer SAP HANA Umgebung mit vergleichsweise wenig Aufwand zu analysieren, da die Funktionen direkt auf Datenbankebene, statt auf Applikationsebene ausgefuhrt werden konnen. Obwohl die Predictive Analysis Library viele unterschiedliche Moglichkeiten der Datenanalyse, wie beispielsweise Zeitreihenanalyse oder Regressionsanalyse bietet, sind fur den weiteren Verlauf nur die Funktionen relevant, die ein Clustering von Daten ermoglichen

Google Places API als Datenquelle

Im Rahmen dieser Arbeit sollen fur jede Filiale eines Supermarktes die umliegenden Konkurrenten und Points-of-Interest (zusammengenommen: Lokalitaten) ermittelt werden, um auf Basis der Kombination der umliegenden Lokalitaten zu bestimmen, wie Supermarktfilialen in Gruppen eingeteilt werden konnen, um eine standortspezifische Preisdifierenzierung zu unterstutzen, mehr dazu in Abschnitt 3.4. Daher wird eine umfassende Datenbasis fur in Frage kommender, naheliegender Konkurrenten oder nachfragebeein ussender Points-of-Interest benotigt, die das Kaufverhalten, und damit verbunden die Zahlungsbereitschaft, von Konsumenten beein ussen. Die Google Places API (Application Programming Interface) ist eine – mittlerweile kommerzielle – Geodaten-Schnittstelle, die diverse Umgebungsdaten zu angefragten Standorten zuruckliefert. Es ist nicht anzunehmen, dass die Schnittstelle vollstandige beziehungsweise ausschlielich richtige Daten liefert, allerdings kann angenommen werden, dass die Qualitat der Daten hinreichende Ausmae annimmt. Es gibt selbstverstandlich andere Anbieter von Geodaten-Schnittstellen, die Standortdaten liefern, allerdings bietet sich die Google Places API aufgrund des Verbreitungsgrad und der technischen Einfachheit des Zugriffs fur diese Untersuchung an. Weitere Aussagen uber die Eignung lassen sich nach der Untersuchung – durch reale Nutzung der Schnittstelle fur diesen Anwendungszweck – treffen. Die Schnittstelle bietet uber RESTful Webservices verschiedene Moglichkeiten zum Abruf von Standorten. Uber einen REST (Representational State Transfer) API-Aufruf wird eine Anfrage an einen Endpunkt gestellt, welcher dann die angefragten Daten in einer Antwortnachricht, der API-Antwort, zuruckliefert. Die Antwortnachricht beinhaltet die Daten im weit verbreiteten JSON-Format (JavaScript Object Notation) und ist somit mit vielerlei Programmiersprachen einfach zu verarbeiten. Da REST auf bereits existierenden Standards wie HTTP (Hypertext Transfer Protocol) aufbaut, existieren in vielen Programmiersprachen bereits Strukturen, die eine Nutzung einer solchen Schnittstelle vereinfachen. Daruber hinaus ist bei dieser Implementierung des Webservices keine  

Abb. 1: Kennzeichen der Lokalitatstypen der Google Places API

komplexe Authentifizierung notwendig, sondern lediglich die Ubergabe eines APISchl ussels via Parameter.

Ein im Kontext der Untersuchung wichtiger Aspekt zum Aufbau der via der Google Places API ruckgemeldeten Daten ist die Tatsache, dass allen Lokalitaten ein oder mehrere Kennzeichen zugeordnet sind, die diese Lokalitaten in eine eine oder mehrere Lokalitatstypen klassifizieren. Somit ist es einfach, Lokalitaten wie Supermarkte oder Flughafen anhand eines bestimmten Kennzeichens zu filtern, ohne eine solche Klassifizierung manuell durchfuhren zu mussen. Abbildung 1 zeigt alle verschiedenen Kennzeichen, die zur Verfugung stehen und von denen jede Lokalitat eine beliebige Anzahl aufweisen kann (vgl. die Dokumentation der Schnittstelle [Google LLC, 2019]).

Die Bedeutung der einzelnen Kennzeichen ist in der Dokumentation nicht eindeutig aufgeschlusselt, allerdings kann anhand der Grundidee eines Kennzeichens davon ausgegangen werden, dass die jeweiligen Kennzeichen ohne semantische Erweiterung direkt ins Deutsche ubersetzt werden konnen, unter Berucksichtigung der Ziele einer Geodaten-Schnittstelle. Somit ware das Kennzeichen supermarket etwa ein Kennzeichen fur Supermarkte, airport fur Flughafen, analog dazu konnen die restlichen Kennzeichen ubersetzt werden. Es gibt noch eine Reihe weiterer, informativer Kennzeichen, allerdings kann nicht explizit nach diesen Kennzeichen per API-Aufruf gesucht werden, vielmehr bieten sie eine Reihe von zusatzlicher, optionalen Informationen fur die ruckgemeldeten Lokalitaten einer Antwortnachricht.

Die Schnittstelle bietet verschiedene Moglichkeiten an, nach Lokalitaten zu suchen. Einerseits kann uber die hier behandelte Schnittstelle anhand eines Textes nach Lokalitaten gesucht werden, die ebenjenen Text im Namen tragen. Die Ergebnisse werden entweder mit einem sogenannten locationbias oder einem ipbias gezielt in eine Richtung verzerrt, sodass die fur einen Nutzer tatsachlich relevantesten Ergebnisse priorisiert werden. Diese Verzerrung bezieht zusatzlich zum gesuchten Text entweder die IP-Adresse des Nutzers oder den Standort in die Bewertung der Suchergebnisse mit ein (vgl. [Google LLC, 2019]). Eine Suche nach einem ‘Hauptbahnhof’ wurde somit durch die gezielte Verzerrung den Hauptbahnhof als erstes zuruckmeldet, der auf Basis der IP-Adresse oder des Standorts das wahrscheinlichste Suchergebnis ist, wahrend ohne eine solche Verzerrung keine semantische Sortierung stattfindet und vermutlich eine weitere Spezifikation des Suchtextes notwendig ware, um den gewunschten Bahnhof zu finden.

Daruber hinaus gibt es die Moglichkeit, basierend auf einem Suchtext nach Lokalit aten zu suchen, der nicht zwangslaufig dem Namen der gesuchten Lokalitaten entspricht, sondern semantisch jene Orte beschreibt. Es ist somit moglich, etwa einen Suchbegriff  wie ‘Restaurants in Berlin’ an die Schnittstelle zu ubergeben, wodurch seitens des Anbieters der Schnittstelle der Text semantisch auf die Bedeutung untersucht wird. Da die Interpretation seitens des Anbieters stattfindet, hat der Anwender keinen Ein uss hierauf, auer erneut durch einen locationbias. Die ruckgemeldeten Ergebnisse beinhalten dann eine Menge von Lokalitaten in Berlin, die als Restaurants gekennzeichnet sind. Eine andere Moglichkeit der Interaktion mit der Schnittstelle, die im Kontext dieser Untersuchung besonderen Fokus erlangt, ist die Moglichkeit der Umgebungssuche. Basierend auf geografischen Koordinaten und einem Kennzeichen wird innerhalb eines spezifizierten Radius nach allen6 Lokalitaten gesucht, die das jeweilige Kennzeichen in ihrer Menge von Kennzeichen aufweisen. Diese Art der Abfrage wird im Folgenden an einem Beispiel naher betrachtet.

Wie in Abbildung 2 an einem exemplarischen API-Aufruf zu sehen ist, konnen in den jeweiligen Parametern der URL des API-Aufrufs die geografischen Koordinaten, der Suchradius und das Kennzeichen der gesuchten Lokalitaten festgelegt werden. In diesem Fall wird die Schnittstelle testweise angesprochen, um in einem Umkreis von funf Kilometern um die Universitatsbibliothek des Campus Essen alle Bahnhofe zu ermitteln. Ferner zu den Parametern der eigentlichen Abfrage ist ein APISchl ussel zur Authentifizierung gegen den Endpunkt notwendig. Dies dient dazu, Abfragen einem Abrechnungskonto zuzuordnen und somit die einzelnen Abfragen in Rechnung zu stellen, bzw. zu verhindern, falls fur den Nutzer keine Anfragen mehr entgegengenommen werden. Nutzer, die nicht an der Google-Plattform registriert sind und somit keinen API-Schlussel besitzen, haben keine Moglichkeit, sich gegen den Endpunkt zu authentifizieren, und somit keine Moglichkeit, Geodaten abzurufen. Fur eine korrekte Abfrage sind keine HTTP-Header notwendig.

Falls die Anfrage semantisch und syntaktisch korrekt ist, gibt die Schnittstelle auf eine solche Anfrage eine Antwort im JSON-Format zuruck, die die angefragten Daten beinhaltet. Die Antwort auf die eingangs vorgestellte, exemplarische Anfrage ist in Abbildung 3 zu sehen. Die Abbildung wurde gekurzt, sodass nur das erste zuruckgelieferte Umgebungselement, der Essener Hauptbahnhof, zu sehen ist. Es werden zusatzlich zu der eigentlichen Lokalitat noch weitere Nutz- und Metadaten mitgeschickt, die in dem JSON ersichtlich sind und die fur andere Anwendungsfalle relevant sein konnen, wie etwa die durchschnittliche Nutzerbewertung der Lokalitat oder eine Referenz zu einem Foto der Lokalitat. Diese Art der Lokalitatssuche ist fur den folgenden Verlauf der Untersuchung relevant und wird im Verlauf dazu verwendet, um fur Supermarktfilialen umliegende Lokalitaten bestimmter Typen zu ermitteln. Die Screenshots aus Abbildung 2 und Abbildung 3 stammen aus dem Programm Postman, mit dem sich RESTful Webservices uber eine grafische Benutzerober ache manuell abrufen und somit testen lassen.