Big-Data-Architektur
Als Software-Architekt habe ich das Ziel, komplizierte Aufgaben über einfache Lösungen zu erreichen. Die einzelnen Bestandteile einer Lösung haben jeweils Vor- und Nachteile, die Kunst ist, sie so zu kombinieren, dass in Summe die Vorteile erhalten bleiben und die Nachteile sich gegenseitig aufheben.
Für viele SAP-Anwender wird es im ersten Schritt darum gehen, Analytics mit Big Data zu ermöglichen, also in diesen riesigen Datenmengen interessante Informationen zu finden.
Anstatt aber eine komplett neue Infrastruktur für die Anwender zu bauen, kombiniere ich das Big-Data-System mit dem bestehenden Data Warehouse.
Der Data Scientist bekommt das Data Lake, einen Datenbereich, in dem alle Rohdaten vorliegen, und dazu passend ein mächtiges Werkzeug, mit dem er diese Rohdaten auch aufbereiten kann. Das Ergebnis seiner Tätigkeit sind neue Kennzahlen, die ich im Data Warehouse hinzufüge. Das hat mehrere Vorteile:
- Der Business User verwendet weiter seine gewohnten Werkzeuge zur Analyse, nur hat er jetzt mehr Kennzahlen.
- Der Data Scientist hat Zugriff auf alle Daten, Big Data und ERP-Daten.
- Für die IT ist der Aufwand überschaubar.
Auch im Spannungsbogen aus Kosten vs. Nutzen vs. Erfolgswahrscheinlichkeiten ist diese Lösung attraktiv: Indem ich an Bestehendes andocke, habe ich einen reduzierten Projektumfang, damit ein minimiertes Projektrisiko und eine billigere Umsetzung, aber schöpfe dennoch den potenziellen Nutzen voll aus.
Somit besteht eine Big-Data-Lösung nur noch aus zwei Komponenten: dem Data Lake mit den Rohdaten und einem Server-Cluster, in dem die Datenaufbereitung geschieht.
Data Lake oder SAP Vora
SAP hat in der Vergangenheit SAP Vora als Data Lake angeboten und vertreibt unter dem Namen Big Data Services die Altiscale-Lösung. Im Grunde genommen ist das Data Lake aber nur ein großes Filesystem. Wird trotzdem vom SAP-Vertrieb Vora, Altiscale oder DataHub vorgeschlagen, sollte man Preis und Leistung sehr kritisch hinterfragen.
Warum nicht einfach in der ersten Projektphase mit einer lokalen Festplatte oder dem zentralen Fileserver anfangen? Solange genug Platz da ist und die Kosten für den Speicherplatz nicht zu hoch werden, ist das durchwegs valide. Die Files zu kopieren geht jederzeit und problemlos, daher verbaue ich nichts für die Zukunft.
Aufbereitung mit Apache Spark
Für die Verarbeitung dieser Daten wird heute bei den meisten Projekten das Open Source Framework Apache Spark verwendet. Es erlaubt mit wenigen Zeilen Code Programme für die Datenaufbereitung zu schreiben und in einem Server-Cluster parallelisiert auszuführen.
Es gibt für mich keinen Grund, hier das Rad neu zu erfinden, noch dazu, wo so eine Installation denkbar einfach geht und in zehn Minuten erledigt ist: Das Paket auf einem kleinen Linux-Rechner herunterladen, extrahieren und über den Befehl start-all einen Master sowie einen ersten Worker starten.
Herausforderung: Algorithmus
Die Technik ist mit obigem Ansatz handhabbar. Das Entwickeln der Algorithmen für die neuen Kennzahlen ist der schwierige Teil: Wie können aus den Massendaten Informationen gewonnen werden, die sich schlussendlich im Gewinn der Firma niederschlagen?
Genau hier entscheidet sich der Erfolg eines Big-Data-Projekts. Genau hier finde ich daher auch Investition sinnvoll, etwa in die Ausbildung eines Data Scientist.
In den folgenden Kolumnen werde ich unter anderem folgende Fragen beantworten: Warum Apache Spark verwenden und nicht ein ETL Tool? Wozu benötigt man das Data Lake, wenn die Daten doch schon im Data Warehouse liegen? Etc.
