Autor/in: Kok Yew Lim

Annahme für den Use Case

Für den fachlichen Use Case unterstellen wir, dass man auf Basis der Twitter-Daten der letzten Stunde – mit dem Hashtag #Bitcoin – eine Vorhersage auf den Bitcoinkurs der nächsten 24h machen kann. Aus Zeit- und Kostengründen haben wir diese Annahme nicht weitergehend validiert, d.h. wir haben keine Studien durchgeführt, die belegen, ob dies auch tatsächlich so ist bzw. welche Begriffe, Tweets, etc. in der Vergangenheit am ehesten einen Einfluss auf die Kursentwicklung hatten¹ .

Wir nehmen also an, dass wiederkehrende Muster an Wörtern in den Tweets zu einer ähnlichen Kursveränderung des Bitcoins führen. Wenn beispielsweise die Begriffe Trump, Geld und bezahlen in einer bestimmten Verteilung – d.h. Anzahl, in der Vergangenheit zu steigenden Kursen geführt haben – dann nehmen wir an, dass das zukünftig bei einer ähnlichen Verteilung wieder so passieren wird.

Datenvorverarbeitung und Modelltraining

Zum Verständnis dieses Abschnitts ist es zunächst wichtig im Hinterkopf zu haben, dass wir bei der Datenvorverarbeitung und dem Modelltraining immer mit historischen Daten arbeiten.

Für die Modellbildung ist es zunächst wichtig, die jeweils wichtigsten Wörter in den gesammelten Tweets zu identifizieren. Hierzu haben wir einfache Datenvorverarbeitungsmethoden aus dem NLP (Natural Language Processing) Bereich genutzt, wie z.B. Part-of-speech tagging (POS), Entfernung von Stoppwörtern oder Tokenization. Im Wesentlichen werden jeweils die drei häufigsten Substantive, Verben und Named Entities (Eigennamen wie Unternehmen, Personen oder Städte) gezählt.

Im nächsten Schritt müssen nun die identifizierten Wörter mit den Bitcoin-Daten bzw. der Entwicklung des Bitcoin-Kurses in Verbindung gebracht werden.

Hierzu wird zunächst zu jeder vollen Stunde die relative Kursentwicklung für den nächsten Tag berechnet. In einem zweiten Schritt werden diese Werte gruppiert, z.B. in steigende Kurse (alles >+1% Kursentwicklung), fallende Kurse (alles <-1% Kursentwicklung) und gleichbleibende Kurse (alles zwischen >=-1% und <=+1% Kursentwicklung)² . Dieses Vorgehen soll in Abbildung 3 etwas besser veranschaulicht werden.

Dann werden diese Kategorien (steigende Kurse, sinkende Kurse, etc.) mit den gezählten Wörtern assoziiert. Abbildung 4 zeigt dies etwas anschaulicher. Am 12.02., um 12:00 Uhr wurde innerhalb von 24h ein fallender Kurs gemessen. Gleichzeitig kamen die Begriffe Trump, Geld und bezahlen am 12.02. in dem Zeitraum von 11-12 Uhr besonders häufig vor. Entsprechend unserer Annahme (siehe hierzu auch im Abschnitt Annahme für den Use Case) gehen wir nun davon aus, dass bei einer ähnlichen Verteilung dieser Begriffe zukünftig auch eine ähnliche (stark fallende) Kursentwicklung zu erwarten ist.

In diesem Verfahren bilden wir nun viele gleichmäßige Zeitscheiben, jeweils im Stundentakt. Jede dieser Zeitscheiben besteht nun aus 9 Features (3 Substantive, 3 Verben, 3 Named Entities) und einem Label (der Kategorie welche die Kursentwicklung beschreibt).

Dieses Datenkonstrukt wird nun mit einer Supervised Learning Methode (Multinomiale Logistische Regression) trainiert.

Vorhersage und Fazit

Auf Basis des trainierten Modells (siehe vorheriger Abschnitt) sind wir nun in der Lage einmal pro Stunde eine Vorhersage, jeweils für den nächsten Tag zu berechnen. Die Vorhersage gibt immer jeweils eine Range an, z.B. der Kursveränderung wird zwischen +3% und +5% liegen. Abbildung 5 zeigt einen Auszug aus der Datenvisualisierung, die mit Tableau umgesetzt wurde (basierend auf echten Daten/Prognosen).

Wie man recht schnell erkennen kann, sind wir unserem Ziel, steinreich zu werden, leider nicht sehr viel nähergekommen. Die berechnete Prognose ist nur selten in der Lage, die Kursentwicklung richtig vorherzusagen.

Dafür war das Projekt in Bezug auf die technische Implementierung ein voller Erfolg. Es ist uns gelungen, die komplette fachliche Logik des Projekts auf AWS zu migrieren. Darüber hinaus konnten wir auch relativ große Datenmengen effizient verarbeiten. So werden beispielsweise beim täglichen Training des Modells mehr als 2.500.000 Tweets auf einer relativ bescheidenen EC2-Instanz verarbeitet.

Lessons Learned und Ausblick

Für die Implementierung des Projekts mussten zahlreiche AWS-Komponenten aufgesetzt werden, die miteinander interagieren und die in Summe eine gewisse Komplexität mit sich bringen. Trotzdem war unsere Erfahrung, dass die Umsetzung im Vergleich zu der selbstgebauten On-Premise Lösung deutlich schneller, effizienter und in Summe auch einfacher umzusetzen war.

Wesentliche Lessons Learned, die wir aus diesem und auch aus anderen Cloud-Projekten mitgenommen haben:

• Implementation to Costs
  In der Softwareentwicklung kümmert man sich üblicherweise um die Effizienz seines Programms, um eine möglichst geringe Zeit- und Speicherkomplexität zu erhalten. Auch auf Cloud-Computing Plattformen bleibt dies relevant, allerdings kommt aufgrund der Kostenpflicht zusätzlich noch die Optimierung im Hinblick auf Kosten. Bei der Nutzung der Services können häufig zahlreiche Kosten für Features anfallen, die eventuell gar nicht verwendet werden. Des Weiteren kann die Verwendung der einzelnen Services so optimiert werden, dass diese so wenig wie möglich aufgerufen werden, da auch hier der Kostenfaktor hoch sein kann.
• Geringere Komplexität und effizientere Teams
  In Summe war – im Vergleich zur On-Premise Lösung – der Gesamtpersonalaufwand für das Projekt erheblich niedriger. Bei der Implementierung der ersten Leistungsstufe waren in Spitzenzeiten bis zu sechs Experten mit ganz unterschiedlichen Skills notwendig (z.B. Spark-, Hive-, Docker-Experten usw.). Die Cloud-Lösung hingegen konnte im Wesentlichen von nur einer einzelnen Person umgesetzt werden. Wir sehen den Hauptgrund hierfür in einer geringeren Gesamtkomplexität: das Management zahlreicher kleiner Teilprobleme kann quasi an die Cloud ausgelagert werden. Damit hat sich auch der Kommunikations- und Abstimmungsaufwand innerhalb des Teams erheblich reduziert.
• Stabiler Betrieb bei guter Erweiterbarkeit und Skalierbarkeit
  Seitdem die fachliche Logik auf AWS migriert wurde, hatten wir keinen einzigen Ausfall einer AWS Komponente zu verzeichnen. Das System läuft seit der Aufsetzung auf AWS, ohne dass wir uns größere Gedanken über Stabilitäts- oder Backupthemen machen mussten. Gleichzeitig ist das implementierte System deutlich leichter skalier- und erweiterbar. Möchte man beispielsweise eine weitere Datenquelle anbinden, so müsste man hierzu lediglich eine neue Elastic Beanstalk-Instanz erstellen, die die Daten von der gewünschten API abruft.
• Ein gutes Explorationskonzept lohnt sich
  Ein wesentlicher Grund dafür, dass die Implementierung schnell verlief, war die Entwicklung eines detaillierten Explorationskonzepts, in dem die wichtigsten Anforderungen an das System exploriert wurden. Durch das Explorationskonzept wurden bereits von Anfang an für das Projekt geeigneten Services identifiziert, sodass nicht erst während der Implementierung auffällt, dass eine Technologie für das Projekt eher ungeeignet ist. Ebenso wurden die einzelnen Datenverarbeitungsschritte definiert, wodurch die Umsetzung dieser Verarbeitungen in einem Skript wesentlich einfacher wurde.

Trotz der Fertigstellung des Projekts gibt es noch zahlreiche weitere Aspekte, mit denen das Projekt weitergeführt werden kann:

• Anbindung weiterer Datenquellen
  Es ist durchaus denkbar, weitere Datenquellen anzubinden. So könnte man z.B. unterschiedliche Nachrichtendienste anbinden und den Inhalt der Artikel detailliert analysieren.
• Ausbau der Algorithmen
  Der implementierte Algorithmus stellt ein sehr einfaches Verfahren dar, da im Wesentlichen nur die häufigsten Begriffe betrachtet werden. Hier gibt es noch sehr viel besser geeignete, komplexere Ansätze. So könnte man die Beziehungsnetzwerke der Twitter-Nutzer mitberücksichtigen und z.B. die Anzahl der Follower oder die Anzahl der Retweets analysieren. Man könnte auch Sentimentanalysen durchführen und deutlich ausgereiftere NLP Methoden (z.B. Long-Short-Term-Memory Networks) oder Frameworks wie BERT einsetzen.
• Evaluierung weiterer Services
  Das Hauptziel des Projekt war vor allem das Gewinnen von Know-how in AWS. Daher wäre die Evaluation von weiteren Services ebenfalls ein weiterer Punkt, an dem am Projekt weitergearbeitet könnte. Geeignet wären zum Beispiel der Natural Language Processing Service Amazon Comprehend oder der Service zur Visualisierung von Daten, Amazon QuickSight.
• Weitere Automatisierung
  Nicht nur das Training und die Vorhersage können automatisiert werden, sondern auch die Erstellung der gesamten Projektinfrastruktur auf AWS. Dafür eignet sich die Infrastructure-as-Code Software Terraform, die das automatische Erstellen der benötigten Ressourcen ermöglicht. Auch hier könnte es interessant sein, weitere Teile des Projekts zu automatisieren.

Zusammenfassend birgt das Projekt ein sehr weites Feld an Möglichkeiten, das System weiterzuentwickeln. Vom Ausbau der Algorithmen, über die Anzahl der Datenquellen, bis hin zu weiterer Automatisierung besteht umfangreiches Potential zum Ausbau und der Verbesserung des Systems.

Co-Autor: Danny Claus

Zu Teil 1 der Bitcoinkursvorhersage mit AWS

1 In einem echten Kundenprojekt hätte man hier vorab eine entsprechende Validierung vornehmen müssen. Da für uns aber die technischen Aspekte im Vordergrund standen, haben wir davon im Rahmen dieses internen Projekts abgesehen.

2 Dies ist lediglich ein vereinfachtes Beispiel. In unserem echten Modell verwenden wir in Summe 11 Kategorien.

Ein zweites Ziel im Rahmen dieses Projekts war die Entwicklung eines technischen Prototyps, der die komplexen Aspekte eines typischen Big Data Projekts (Datenintegration, Datenanalyse und Datenvisualisierung) umsetzt. Hierzu wurde in einer ersten Leistungsstufe eine entsprechende Umgebung komplett selbst aufgebaut und On-Premise betrieben.

Beim Aufbau und Betrieb dieser Plattform mussten wir eine Vielzahl an Herausforderungen meistern, angefangen vom Monitoring der Anwendung, über Backupstrategien bis hin zur Sicherstellung einer Skalierbarkeit. Hierzu wurde eine Vielzahl an Technologien eingesetzt: Spark, Hive, PostgreSQL, Docker, HDFS, REST, Java und Tableau – um nur ein paar zu nennen. Und wie man sich denken kann, ist das Zusammenspiel dieser verschiedenen Technologien durchaus komplex und auch aufwendig, unter anderem weil man eine Vielzahl von Experten benötigt, die sich regelmäßig miteinander abstimmen und synchronisieren.

Für uns war das der Anlass, unseren fachlichen Use Case mit einem neuen Technologiestack und auf Basis von Cloud Computing Technologien zu erproben.

Die Ergebnisse dieses Projekts wollen wir im Rahmen einer zweiteiligen Blogserie kurz vorstellen. Im Rahmen dieses ersten Beitrags stellen wir die technische Umsetzung vor. In einem zweiten Teil beschreiben wir die implementierte Business Logik und gehen auf die wesentlichen Lessons Learned ein, die wir im Rahmen des Projekts für uns mitgenommen haben.

Technische Umsetzung

Für die technische Umsetzung wurde ein Platform-as-a-Service (PaaS) Ansatz auf Basis von AWS Technologien genutzt, d.h. sämtliche Hardware wurde von der Cloud zur Verfügung gestellt. Lediglich die Software, d.h. die fachliche Logik, musste selbst implementiert werden.

Die Architektur lässt sich dabei in folgende Abschnitte aufteilen:

• Datensammlung
• Datenverarbeitung
• Modelltraining und -vorhersage

Datensammlung

Auf Abbildung 3 ist dargestellt, wie die Komponenten für die Datensammlung miteinander arbeiten. Für die Sammlung der Twitter- und Bitcoin Daten wurde die Twitter API bzw. Coindesk API verwendet. Die Twitter API stellt Tweets mithilfe von Streaming in Echtzeit bereit, während die Coindesk API eine REST API darstellt und somit durch das Stellen von HTTP Requests den aktuellen Kurswert zurückgibt. Beide APIs werden jeweils durch ein Python-Skript angesprochen, welche dauerhaft im Hintergrund laufen und die dabei abgerufenen Daten speichern. Für die Ausführung dieser Skripte auf AWS wurde Elastic Beanstalk verwendet – ein Service, der sich automatisch um die Bereitstellung von Code auf EC2-Instanzen kümmert.

Um die Twitter- und Bitcoin-Daten von Elastic Beanstalk auf einem AWS Storage Service zu übertragen, wird der Service Kinesis Firehose verwendet, welcher Daten entgegennimmt und diese im gewählten Storage Service abspeichert. Kinesis Firehose ermöglicht es zudem, eingehende Daten zu komprimieren oder zu verarbeiten, bevor diese gespeichert werden.

Als zentraler Storage Service für alle im Projekt verwendeten Daten wird S3 benutzt, womit Objekte gespeichert und abgerufen werden können.

Datenverarbeitung, Modelltraining und -vorhersage

Wie zuvor bei der Datensammlung stellt Abbildung 4 sämtliche Komponenten dar, die für die Datenverarbeitung, das Modelltraining und die -vorhersage verantwortlich sind. Da das Training täglich und die Vorhersage stündlich laufen sollen, müssen die dazugehörigen Services in AWS selbst angesteuert werden. Für diesen Zweck wird CloudWatch benutzt – ein Service, der hauptsächlich für das Logging der AWS Services zuständig ist, aber zusätzlich weitere Funktionen anbietet, wie z.B. das Auslösen von Services in einem festlegbaren Intervall.

Durch CloudWatch soll ein Training / eine Vorhersage gestartet werden. Allerdings kann der dafür verantwortliche Service (SageMaker => siehe hierzu auch den nächsten Absatz) nicht direkt durch einen CloudWatch Auslöser angesteuert werden. Daher wird der Service Lambda verwendet, welcher das Ausführen von Skripten auf der Cloud ermöglicht. Die Ausführung einer Lambda Funktionen kann durch Events ausgelöst werden, wie z.B. die vorher genannte CloudWatch Auslöser, wodurch ein regelmäßiges Training / Vorhersage gewährleistet werden kann. In der Lambda Funktion wird die AWS SDK Boto3 verwendet, um SageMaker aufrufen zu können.

Bei SageMaker handelt es sich um einen Machine Learning Service, auf dem jegliche Operationen zum Erstellen, Trainieren und Bereitstellen von Machine Learning Modellen möglich sind. Auf SageMaker werden sowohl das Training als auch die Vorhersage ausgeführt. Um auf die Daten in S3 zugreifen zu können, wird der Service Athena verwendet, mit welchem SQL-ähnliche Abfragen in S3 ausgeführt werden können. Das aus dem Training entstehende Modell wird sodann auf S3 gespeichert.

Mit dem Zusammenfügen der Architekturen für die Datensammlung bzw. Modelltraining und Vorhersage ergibt sich nun die Gesamtarchitektur wie in Abbildung 5 dargestellt.

Jetzt haben wir euch die technische Implementierung im Wesentlichen vorgestellt, im zweiten Teil unserer Sapphire-Reihe geht es dann ums Eingemachte: Wie sieht die implementierte Business Logik genau aus und welche Lessons Learned ziehen wir aus dem Projekt?

Co-Autor: Danny Claus

Zu Teil 2 der Bitcoinkursvorhersage mit AWS