SAP Big Data – was ist Big Data?

Mit der direkten Übersetzung Massendaten trifft man nur einen Aspekt. Alle normalen Daten aus dem ERP-System und anderen Datenbanken sind auch Massendaten.

Bezüglich des Volumens an Daten muss von Mengen gesprochen werden, die zu groß für Datenbanken sind – zu groß im absoluten Sinn oder im Sinn von Kosten/Nutzen.

Der interessantere Aspekt ist der Grad an Struktur in den Daten. Das ERP-System beinhaltet zu 99 Prozent gut strukturierte Daten, etwa das Feld MATART (Material Typ) in der Tabelle MARA (Materialstamm).

Das eine Prozent sind Freitexte wie eine Liefernotiz. Bei Big Data ist es das andere Extrem und die spannenden Informationen stecken in den unstrukturierten Datenbereichen. Wann und wo ein Foto aufgenommen wurde, ist interessant, aber was das Bild zeigt ungleich wichtiger.

Damit einher geht auch die Art der Datenaufbereitung. Ist es bei Datenbanken eine Abfrage wie „Summe Umsatz pro Monat“, redet man bei obigem Beispiel plötzlich von Bildanalyse.

Selbst bei nicht so extremen Fällen, etwa Logfiles, werden nicht einfache Summierungen und Zählungen vorgenommen. Datenbanken sind somit die schlechteste Wahl für solche Daten.

Die wichtigste Definition von Big Data ist allerdings „alle Daten, die man heute nicht zur Steigerung des Unternehmensgewinnes heranzieht“. Hier ist Kreativität angesagt. Eines meiner letzten Projekte hat die Auslastung der Server im Rechenzentrum mitgeschrieben – mit dem Ziel, die Anzahl der Server zu reduzieren.

Ein Beispiel: Es sollen die Verkäufe mit der Information verknüpft werden, wie intensiv sich Kunden das jeweilige Produkt auf der Webseite angesehen haben. Beispielsweise wird ein Produkt in den Medien beworben.

Wird diese Werbung wahrgenommen? Wenn ja, müssten erhöhte Zugriffszahlen auf den zugehörigen Produktseiten zu sehen sein. Lesen Interessenten die Produktseite kurz, sind sofort überzeugt und kaufen danach?

Der Webserver schreibt schon alle Seitenzugriffe in Logfiles, aber nach einer Woche werden sie gelöscht. Die Daten dafür wären also vorhanden, sie werden nur noch nicht verwendet.

Das Ziele ist maximale Effektivität und Flexibilität. Vor ein paar Jahren war Map Reduce auf Hadoop das Nonplusultra, dann kam Apache Spark. Es konnte mehr, bei besserer Performance und größerer Mächtigkeit.

Lange Zeit war Apache Hive der Weg, heute sind es Parquet Files. In so einem dynamischen Umfeld möchte ich nicht viele Ressourcen für eine potenziell kurzfristig verwendete Lösung ausgeben und auch die Offenheit haben, jederzeit auf etwas Neues umschwenken zu können.

Aktuell ist Apache Spark so eine mächtige, aber gleichzeitig offene Lösung. Damit werden mit einer Code-Zeile die Logfiles des Webservers in Zeilen und Spalten zerlegt. Aufwändiger ist, die Logik zu entwickeln, wie aus dem Verlauf der Seitenaufrufe die Lesedauer pro Seite abgeleitet werden kann.

Füge ich diese und weitere Kennzahlen schlussendlich zum Data Warehouse hinzu, ermöglicht es kombinierte Analysen – etwa für ein Produkt die Kennzahlen Umsatz, Lesedauer und Seitenzugriffe über den zeitlichen Verlauf zu visualisieren.

Bis vor Kurzem war die Speicherung und die Verarbeitung von sekundären Daten preislich nicht attraktiv. Das Volumen der Daten war zu groß, die Informationsdichte zu gering und der einzige Weg, Daten effektiv zu verarbeiten, war mit datenbanknahen Werkzeugen.

Mit dem Apache Hadoop Filesystem (HDFS) können aus billigen PC-Komponenten große Filesysteme geformt werden, anstatt ein teures Disk-Array zu kaufen. Apache Spark kann diese großen Datenmengen verarbeiten, mit den zugehörigen komplexen Algorithmen inklusive statistischer Methoden und Machine Learning.

Die Werkzeuge aus dem Data-Warehouse-Bereich, inklusive die von SAP, haben sich an diese Situation angepasst und bieten direkten Zugriff auf Hadoop Files oder schicken Transformationsaufgaben an einen angeschlossenen Spark Cluster. Eine sehr einfache Möglichkeit, um von Hana aus Daten zu lesen, ist über den SAP Hana Spark Connector.