Während Vorreiter Amazon in bestimmten Absatzgebieten heute bereits mit einer Wahrscheinlichkeit von 80% vorhersagen kann, welche Produkte ein Kunde morgen bestellen wird, sind vor allem deutsche Unternehmen nach wie vor skeptisch gegenüber der Kunst der modernen statistischen Datenanalyse. Obwohl die Erkenntnis wächst, schätzt ein Großteil der IT-Verantwortlichen der D‑A-CH Region, dass Predictive Analytics erst innerhalb der nächsten drei Jahre wirklich relevant wird, während Weltmarktführer ihre Marktmacht weiter ausbauen und der Konkurrenz davonlaufen.
Doch woher kommt die fehlende Innovationsfreude der eigentlich doch so innovativen Deutschen? Heinrich Vaske, Editorial Director der Fachzeitschriften „Computerwoche“ und „CIO“, sieht das Hauptproblem neben erschwerenden Faktoren wie dem Mangel an IT-Kräften auch bei den Entscheidern. In seinem Vorwort zur Studie „Predictive Analytics 2018“ von IDG Research Studies erklärt er: „Schwerer noch wiegt aber die kulturelle Überforderung von Entscheidern, die sich nun auf Daten statt auf ihren Bauch verlassen sollen.” Ziel dieses Beitrags ist es eine verständliche Einführung in das Thema zu geben, um so Verständnis für die kommenden Anforderungen zu schaffen.
Dies ist der erste Teil einer Blogserie, die sich um die Heraus- und Anforderungen an ein System zur Analyse von Clickstream Daten, zur Verbesserung des Internetauftritts eines Web Shops dreht. Der erste Teil behandelt dabei die grundlegende Hardware Architektur und verdeutlicht den Einsatz moderner Technologien in einer Lambda Architektur anhand eines Beispiels.
Anforderungen an Architektur
Ausgangspunkt unserer Überlegungen soll die Website eines Online-Reiseportals sein. Das Geschäftsmodell ist die Vermarktung von Urlaubsreisen rund um den Globus. In letzter Zeit sinkt die Zahl der Buchungen auf Grund von starker Konkurrenz und so genannten Einmalkäufern, also Kunden die maximal einmal über unsere Plattform buchen. Das Problem: Obwohl sich jeden Tag viele Nutzer auf der Website aufhalten, buchen sie doch bei anderen Anbietern. Wie schafft es der Betreiber also Besucher der Website auch als Kunden zu gewinnen? Die Antwort lautet Advanced Analytics.
Advanced Analytics gehen über die Erklärung der heutigen Zahlen, wie es in der traditionellen Datenanalyse üblich war, hinaus und ermöglichen Aussagen über zukünftige Ereignisse. Dieser Ansatz ermöglicht es z.B. Nutzer als Einmalkäufer zu identifizieren und über individuelle Marketing Maßnahmen als Kunden zu binden.
Möglich geworden ist diese Art der Analyse durch die Masse an verfügbaren Daten und den wirtschaftlichen Einsatz massiver Rechenleistung über Cloud-Dienste. Im oben genannten Beispiel wird davon ausgegangen, dass sich die historischen Daten bereits im System befinden. Um möglichst genaue Vorhersagen treffen zu können sollen tagesaktuelle Daten in Echtzeit mit einbezogen werden. Damit ergibt sich bereits die erste Anforderung an die Architektur. Benötigt wird ein System, um Informationen über das Nutzerverhalten auf unserer Website in Echtzeit und ohne Datenverlust in ein System zur Analyse der Daten aufzunehmen.
Die Durchführung der Algorithmen zur Datenanalyse (die in einem späteren Teil behandelt werden) benötigen in erster Linie Rechenleistung. Je nach Traffic auf unserer Website wird mehr oder weniger Leistung benötigt. Daraus werden zwei Szenarien abgeleitet.
- Zu Lastspitzen werden zusätzliche Rechenkapazitäten benötigt.
- Der Web Shop ist auf einen lokalen Markt fokussiert. Das bedeutet, dass zwischen 22 und 10 Uhr nicht genug Daten generiert werden, um sinnvolle Analysen durchzuführen. Dem entsprechend wird auch keine Rechenleistung benötigt.
Es muss also für die Skalierbarkeit unseres Systems gesorgt und gleichzeitig bedacht werden, dass die Rechenkapazität nicht rund um die Uhr benötigt wird. In vielen Fällen bietet sich dafür Cloud Computing an. Auch in diesem Beispiel werden wir die benötigte Rechenleistung aus der Cloud beziehen. Um trotzdem anbieterunabhängig agieren zu können wird Open-Source Software eingesetzt, statt Cloud-Services zu nutzen und damit an einen bestimmten Cloud-Service gebunden zu sein.
Abgesehen von der skalierbaren Rechenleistung muss das System noch anderen Anforderungen genügen. Was hätte man von in Echtzeit zur Verfügung stehenden Daten, wenn die Auswertung auf Grund von hohen Latenzzeiten verzögert wird. Um verwertbare Auswertungen zu erhalten, werden später mehrere Algorithmen zur Datenanalyse vorgestellt, die teilweise parallel ausgeführt werden. Damit ein Fehler in einem der Algorithmen nicht zum Absturz des Systems führt, muss die Architektur robust und fehlertolerant sein.
Echtzeit Datenübertragung mit Apache Kafka
An der Kommunikation für die erste Anforderung ist auf der einen Seite ein System zum tracken der Nutzeraktivität und auf der anderen Seite das von uns in der zweiten Anforderung zu erzeugende System beteiligt. Man könnte an dieser Stelle auf die Idee kommen beide Systeme direkt miteinander zu verbinden, z.B. über eine REST- Schnittstelle auf Nachrichtenempfängerseite. Dabei würden man allerdings auf ernstzunehmende Herausforderungen stoßen, wenn man sich überlegt, dass das Tracking-System zu Lastzeiten kontinuierlich große Datenmengen überträgt. Diese könnten das Empfangende System in die Knie zwingen oder zu Datenverlusten führen, weil die Daten nicht so schnell verarbeitet werden können wie sie gesendet werden.
Um sich keine Gedanken um die Datenübertragung machen zu müssen, werden Messaging-Systeme als Middleware zwischen Sender und Empfänger eingesetzt. Neben unzähligen Alternativen beschränkt sich das Beispiel auf das weitverbreitete, open source Projekt Apache Kafka. Im Kern basieren alle Massaging Systeme auf den gleichen Prinzipien. Dabei differenziert man zwei Arten von Nachrichtenkanälen.
Auf der einen Seite die Implementierung als Queue. Dabei wird der Sender üblicherweise als Producer und der Empfänger als Consumer bezeichnet. Entscheidend ist, dass jede Nachricht insgesamt nur einmal gelesen wird.
Das Topic-Modell auf der anderen Seite, basiert auf dem Publish-Subscribe-Modell. Dabei erhalten alle Consumer die Nachrichten eines von ihnen abonnierten Topics.
Die Leistungsfähigkeit von Kafka basiert in erster Linie auf Skalierbarkeit und Replikation. Vereinfacht gesagt besteht ein Kafka Cluster aus X Brokern, die Nachrichten unabhängig des Topics beziehen. Dabei gibt der Replication Factor an, auf wie vielen Brokern eine Nachricht abgelegt werden soll. Jeder Broker besteht aus mehreren Partitionen. Eine dieser Partitionen ist der Leader auf dem sämtliche Lese- und Schreibvorgänge stattfinden. Außerdem werden Nachrichten ausgehend vom Leader auf alle Follower (restliche Partitionen) repliziert.
Das gleiche Konzept nutzt Kafka in leicht abgewandelter Form für die Übermittlung der Nachrichten an die Consumer. Dafür werden Consumer desselben Topics zu einer Consumer Group zusammengefasst. Im Endeffekt erhält die Consumer Group jede Nachricht nur einmal. Umgesetzt wird dieses Prinzip indem jede Instanz einer Consumer Group exklusiver Consumer eines Anteils der Partitionen mit für ihn interessanten Topics ist. Grundlegend entspricht dieses Konzept dem Publish-Subscribe-Modell auf Grundlage von Clustern statt einzelner Prozesse als Consumer.
In unserem Fall wird die Nutzeraktivität unserer Website live über ein Drittanbieter Tool getrackt. Die erhobenen Daten werden über die Middleware an das System zur Datenanalyse übertragen. Dabei übernimmt Kafka die Datenübertragung in Echtzeit, ohne dass wir uns Gedanken um den Verlust von Daten machen müssen.
Streng genommen ist Kafka bzw. die spätere Kafka-Instanz ebenfalls Bestandteil der Lambda-Architektur (die im nächsten Abschnitt genauer erläutert wird). Sie ist den beiden Kernkomponenten als Data Ingestion Layer vorgeschaltet und bietet einen zentralen Eintrittspunkt in das Big-Data-System.
Aufbau einer Lambda Architektur
Die Lambda-Architektur ist eine Streaming Architektur zur Datenverarbeitung in Echtzeit, um schnellstmöglich Reaktionen durch Technik oder Management in die Wege zu leiten. Bezogen auf das vorliegende Beispiel haben die Operativen Daten ein gravierendes Merkmal. Ihr Wert nimmt sofort nach dem Ereigniszeitpunkt stark ab. Dies liegt darin begründet, dass ein maßgeschneidertes Angebot keinen wirtschaftlichen Nutzen hat, wenn der Kunde die Seite schon wieder verlassen hat bevor es für ihn sichtbar ist. Die notwendige Reaktionszeit auf neue Daten erkauft man sich auf Kosten der Genauigkeit. Um das Potenzial der operativen und der vorhandenen Daten zu nutzen, besteht die Architektur aus zwei Kernkomponenten: Speed oder auch Streaming Layer genannt und Batch Layer.
Streaming Layer
Ziel ist es nachgelagerten Systemen oder Endanwendern möglichst aktuelle Zahlen zu liefern. Die Aktualität dieser Zahlen geht zwangsläufig auf Kosten der Genauigkeit. Obwohl optimaler Weise komplett „In-Memory“ gearbeitet wird, kann in dieser Zeit nur eine Teilmenge der Daten ausgewertet werden.
Batch Layer
Der Batch Layer arbeitet in der Regel auf der gesamten Datenmenge. Er liefert exakte Ergebnisse und führt Analysen über lange Zeitfenster durch. Dabei arbeitet er zeitversetzt in bestimmten Intervallen. Damit ist er auch für das Trainieren von Machine Learning Algorithmen zuständig.
Als abschließende Komponente gibt es den Serving Layer, der die verarbeiteten Daten aus den Kernkomponenten in einem Real-Time- oder Management-Dashboard aufbereitet und bereitstellt.
Beispielhafte Umsetzung der Layer
An dieser Stelle konzentrieren wir uns auf die verfügbaren Software Lösungen, die zur Umsetzung unserer Problemstellung eingesetzt werden könnten. Die Hardware der Server betrachten wir an dieser Stelle nicht. Sie variiert je nach Anwendungsfall und ist in der Cloud relativ dynamisch anpassbar.
Starten wir mit den Kernkomponenten. Es gibt viele Technologieanbieter, die fertige Lösungen für Big Data Analytics bereitstellen. Allerdings ist nicht eine in der Lage, an die Mächtigkeit und den Umfang einiger Open Source Projekte heranzureichen. So auch nicht an Apache Spark. Das 2013 zum Incubator Projekt der Apache Spark Foundation gewordene Spark ist ein Allzweck-Tool zur Datenverarbeitung, eine sogenannte Data Processing Engine. Es nutzt das bekannte Hadoop Filesystem HDFS mit dem Unterschied, dass Spark laut Expertenmeinungen bis zu 100mal schneller, als die zuvor häufig genutzte Alternative MapReduce ist. Den Geschwindigkeitsvorteil verdankt Spark in erster Linie der „in-Memory“ Verarbeitung von Datenabfragen. Außerdem sind elementare Machine Learning Bibliotheken integraler Bestandteil von Spark. Dementsprechend lassen sich die für Predictive Analytics so wichtigen neuronalen Netze und darauf laufenden Machine Learning Algorithmen besonders elegant umsetzen.
Ein weiterer Vorteil geht fließend in unsere zweite Kernkomponente, den Speed/Streaming Layer, über. Dieser kann über die in Spark integrierte Bibliothek Spark Streaming ausgeführt werden. Dieser Umstand schafft einen besonderen Vorteil: Einmal geschriebener Code lässt sich sowohl auf Batch als auch im Streaming Layer ausführen. Gleichzeitig gibt es native APIs die beliebte Programmiersprechen wie Java, Python oder R unterstützen, was die Entwicklung vereinfacht.
Nachdem die Daten in den Kernkomponenten mithilfe von Spark analysiert wurden, müssen sie im Nachgang visualisiert werden. Die Software zur Umsetzung des Serving Layers wird an dieser Stelle nur skizziert. Eine genauere Ausführung erfolgt in einem späteren Beitrag. In unserem Beispiel nutzen wir mit Elastic´s Kibana, ein weiteres open source Tool. Kibana basiert auf Elasticsearch, einer ebenfalls open source Such- und Analysedatenbank mit REST-Schnittstelle. Elasticsearch ist zwar der defacto Standard zur Datenhaltung in unserem Anwendungsszenario, trotzdem ist der Einsatz nicht ganz unproblematisch. Aufgrund von Speicher und Konsistenz Problemen wird empfohlen eine hoch konsistente Datenbank als Backup Datenbank zu nutzen. Für präzise Vorhersagen sind konsistente Daten von elementarer Wichtigkeit. Abgesehen davon betreiben wir zu diesem Zeitpunkt bereits einen hohen Aufwand, damit die Daten in Echtzeit analysiert werden können. Auch hier haben wir uns mit Apache HBase wieder für ein weiteres open source Projekt entschieden. HBase ist eine column-family-oriented NoSQL Datenbank, die Lese- und Schreiboperationen in Echtzeit ermöglicht. Damit stellt HBase eine perfekte Ergänzung zu Elasticsearch dar.
Erläuterung der Funktionsweise anhand eines Beispiels
Die Veranschaulichung der Zusammenhänge lässt sich sehr gut Anhand eines Beispiels erklären. Dafür betrachten wir Herr Müller aus München, der für sich und seine Frau nach möglichen Zielen für ihren gemeinsamen Sommerurlaub sucht. Bereits mit dem Aufruf der Seite werden erste anonymisierte Informationen über Herrn Müller an den Streaming Layer übertragen. Die Erhebung der Daten mittels Tracking-Methoden lassen wir an dieser Stelle außenvor. Wir gehen der Einfachheitshalber davon aus, dass alle für unsere Analysen relevanten Daten erhoben werden.
Das getrackte Surfverhalten von Herrn Müller wird nun kontinuierlich mittels Kafka an den Streaming Layer übertragen. An dieser Stelle müssen wir ein wenig vorgreifen. Wie wir später sehen werden, müssen einige unserer Algorithmen erst trainiert bzw. kontinuierlich trainiert werden, um sie gewinnbringend anzuwenden. Dieses Training kann jedoch nicht in Echtzeit stattfinden, sondern wird wie bereits im vierten Abschnitt erwähnt, in festgeschriebenen Intervallen im Batch Layer ausgeführt. Betrachten wir beispielhaft einen Algorithmus der Nutzer auf Grund ihres Surfverhaltens in Kundengruppen kategorisiert. Der Batch Layer ermittelt Muster, auf dessen Grundlage eine Zuordnung zu bestimmten Kundengruppen stattfinden soll. Der Streaming Layer kategorisiert Nutzer fortan in Echtzeit basierend auf diesen Mustern. Im nächsten Intervall bezieht der Batch Layer auch das seit der letzten Iteration aufgetretene Nutzerverhalten in seine Berechnungen mit ein. Im Endeffekt erhalten wir also Muster, die den aktuellen Kundengruppen entsprechen.
Aber zurück zu unserem Beispiel. Das Surfverhalten von Herrn Müller wurde analysiert. Dadurch wissen auch wir jetzt, dass er nach einem Ziel für den Sommerurlaub sucht. Außerdem haben wir herausgefunden, dass er mit seiner Frau reist und ein ruhiges, eher gehobenes Hotel sucht. Wir haben ihn darüber hinaus als User identifiziert, der unsere Seite nur zur Informationsbeschaffung nutzt und nicht direkt bei uns buchen würde. (diese Annahmen sind plakativ gewählt, entsprechen aber durchaus dem heutigen Standard) Mit diesem Wissen sind wir in der Lage individuelle Angebote für Herrn Müller zu generieren und sie gut sichtbar zu platzieren. Im besten Fall sind unsere Angebote so gut, dass sich Herr Müller doch dazu entscheidet seine Reise bei uns zu buchen.
Während dessen werden uns die wichtigsten Erkenntnisse und Trends im Serving Layer per Dashboard nach Belieben visuell dargestellt. So haben auch wir als Betreiber jederzeit den vollen Überblick. Auf Grund dieser Trends wäre es uns möglich das Sortiment der Nachfrage entsprechend anzupassen.
Egal ob Herr Müller im Endeffekt bei uns bucht oder nicht. Ziel all unserer Anstrengungen ist es die User Experience zu verbessern. Herr Müller soll freiwillig und gerne zurückkommen. Im besten Fall empfiehlt er uns sogar noch seinen Freunden Manuel und Mats.
Fazit
In diesem Teil der Serie haben wir die Grundlagen geschaffen, um eine Website mithilfe von Advanced Analytics zu optimieren. An dieser Stelle nochmal eine kurze Zusammenfassung.
Alle Aktivitäten auf der Website werden durch ein Drittanbieter Tool getrackt. So erhobene Daten werden über unsere Middleware mittels Kafka in Echtzeit an Batch und Streaming Layer übertragen. Der Batch Layer trainiert bzw. optimiert die Algorithmen, die vom Streaming Layer in Echtzeit genutzt werden, um Nutzerverhalten zu prognostizieren. Die Ergebnisse der Analysen werden nicht nur zur Optimierung der Website genutzt, sondern auch im Serving Layer für den Betreiber visuell aufbereitet.
