Was ist Big Data?
Die größte Hürde zu Beginn ist der Begriff Big Data selbst. Die direkte Übersetzung Massendaten trifft leider nur einen Aspekt. Alle normalen Daten aus dem ERP-System und anderen Datenbanken sind auch Massendaten.
Bezüglich des Volumens muss also von Mengen gesprochen werden, die zu groß für Datenbanken sind – zu groß im absoluten Sinn oder im Sinn von Kosten und Nutzen. Ein anderer Aspekt ist der Grad an Struktur in den Daten.
Das ERP-System beinhaltet zu 99 Prozent gut strukturierte Daten. Die ein 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 obigen Beispielen plötzlich von Bildanalyse und Textanalyse.
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 vergangenen Projekte hat die Auslastung der Server im Rechenzentrum mitgeschrieben – mit dem Ziel, die Anzahl der Server zu reduzieren. Um das zu verdeutlichen, möchte ich ein Beispiel bringen.
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? Oder lesen sie die technischen Daten sehr genau und kaufen dann doch nicht?
Hat man eine Idee, welche Daten mit Big Data analysiert werden sollen, stellt sich die Frage nach einer zukunftsträchtigen Architektur. Gerade im Big-Data-Bereich werden ständig neue Produkte entwickelt, die Altes ersetzen. Vor ein paar Jahren war Map Reduce auf Hadoop das Nonplusultra, dann kam Apache Spark, das bessere Performance und größere Mächtigkeit hat.
Lange Zeit war Apache Hive der Weg, heute sind es Parquet Files. In so einem dynamischen Umfeld möchte ich nicht viel Geld für eine potenziell kurzfristig verwendete Lösung ausgeben und auch die Offenheit haben, jederzeit auf etwas Neues umschwenken zu können.
Apache Spark passt zu diesem Wunsch nach einer mächtigen, aber gleichzeitig offenen Lösung und wird deswegen in fast jedem Projekt weltweit eingesetzt.
Die Installation ist einfach, komplexe Transformationen sind mit weniger Codezeilen möglich und die Software kostet nichts. Die großen Kosten würden beim Aufbau eines BI-Systems dafür entstehen.
Daher füge ich die mit Spark berechneten Kennzahlen stattdessen zum existierenden Data Warehouse hinzu und ermögliche den Benutzern, mit den altbekannten Werkzeugen neue Analysen durchzuführen – etwa für ein Produkt jetzt den Umsatz zusätzlich mit Lesedauer und Seitenzugriffen zu korrelieren.
Fazit und Zukunft: Bis vor Kurzem waren die Speicherung und die Verarbeitung von so 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 DB-nahen Werkzeugen.
Diese Argumente gelten heute nicht mehr. 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.
Und die Lösung: 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 dieser verkannten Perlen ist der SAP Hana Spark Connector.
