Bitcoinkursvorhersage mit AWS – Teil 2

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 hatten1 .

Zusammenhang zwischen Bitcoin Kurs und Tweets
Abbildung 1. Zusammenhang zwischen Bitcoin Kurs und Tweets – Annahme für die Vorhersage – eigene Darstellung

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.

Beispiel für Filterung und Zählen wichtiger Begriffe in den Tweets – eigene Darstellung
Abbildung 2. Beispiel für Filterung und Zählen wichtiger Begriffe in den Tweets – eigene Darstellung

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)2 . Dieses Vorgehen soll in Abbildung 3 etwas besser veranschaulicht werden.

Vereinfachtes Beispiel für die Gruppierung von Kursentwicklungen – eigene Darstellung
Abbildung 3. Vereinfachtes Beispiel für die Gruppierung von Kursentwicklungen – eigene Darstellung

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.

Gezählte Wörter und Kategorien – eigene Darstellung
Abbildung 4. Gezählte Wörter und Kategorien – eigene Darstellung

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).

Visualisierung der Ergebnisse – eigene Darstellung
Abbildung 5. Visualisierung der Ergebnisse – eigene Darstellung

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

 

Advanced Analytics Projekte mit Machine Learning erfolgreich umsetzen

 


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.

ECM goes CSP – Alles neu oder alter Wein aus neuen Schläuchen?

weg vom zentralistischen Ansatz – hin zu einer Anpassung mit Blick auf die neuen Anforderungen der Arbeitswelt. Aber was genau sind Content Services Plattformen und wie unterscheiden sie sich von ECM Systemen? Wir geben einen Überblick.

Was ist ein ECM und eine CSP genau?

Enterprise Content Management ist ein Teilgebiet des Informationsmanagements und beschäftigt sich insbesondere mit den Methoden und Werkzeugen zur Erfassung, Verwaltung, Speicherung, Bewahrung und Bereitstellung von Content und Dokumenten in Unternehmen. Die Anwendungsfelder, in welchen sich ein ECM bewegt, sind laut Definition der AIIM International (The Association for Intelligent Information Management): Dokumentenmanagement, Collaboration, Web-Content-Management, Records Management und Business Process Management. Damit ist ECM einerseits eine Überkategorie, die CMS, DMS und viele weitere zusammenfasst. ECM hat aber auch den Anspruch diese konkreten Systeme zu einem zusammen zu fassen mit den wesentlichen Ziele:

  1. Regulatory compliance and risk management
  2. Retention and dissemination of business knowledge
  3. Cost and process efficiencies
  4. Innovation and new ways of working

In der Praxis hat sich gezeigt, dass sich – mit Ausnahmen von Ziel 1 – diese nicht umsetzen lassen. (Siehe hierzu auch: https://www.project-consult.de/in_der_diskussion/gartner-ersetzt-ecm-durch-content-services/)

Content Services Plattformen (CSPs) sind Plattformen, welche verschiedene Services, Repositories und APIs bereitstellt, um Unternehmen in der Digitalisierung ihrer Geschäftsprozesse zu unterstützen. Klassische Anwendungsfälle von CSPs sind neben Datei- und Dokumentenmanagement außerdem Kollaboration und die nachvollziehbare Verwaltung geschäftsrelevanter Transaktionen (Records Management).

Durch standardisierte APIs und Konnektoren lassen sich externe Anwendungen optimal in eine CSP integrieren. Web-, Desktop- und mobile Interfaces ermöglichen Benutzern wiederum den Zugriff von zentraler Stelle auf verschiedene Services der Plattform.

Was ist nun der Unterschied?

Ein ECM System, gemäß unserer Definition, versucht alle Unternehmensinhalte in ein einziges, zentrales Verzeichnis zu bringen. Dieses Konzept ist jedoch in der Praxis oft nur schwer zu realisieren. Gartner versucht daher den Begriff ECM durch ein Bündel von Bausteinen zu ersetzen und Rückt damit von dem Ansatz der Datenzentralisierung bei CSPs weg. Grund dafür, die Zahl der Datensilos in Unternehmen sind aufgrund der Einführung neuer SaaS-Lösungen und zusätzlichen Anforderungen aus den Fachbereichen gestiegen. Zudem werden Compliance und Datenkontrolle zwar bis zu einem gewissen Grad erfüllt, jedoch wurde an manchen Stellen versäumt, den Endbenutzern die gewünschte Benutzererfahrung zu bieten. Also der Zugriff von überall und von jedem Gerät. Darüber hinaus sind Funktionen der modernen Arbeitswelt wie unternehmensweite Dateifreigaben, Synchronisierung und kollaboratives Arbeiten über Unternehmensgrenzen hinweg bisher kaum Bestandteil dieser Lösungen. Grund dafür ist unter anderem, dass ECM-Systeme meist nur für einen ausgewählten Key-User-Kreis und nicht das ganze Unternehmen bereitgestellt werden.

ECM und CSP im Vergleich

Enterprise Content ManagementContent Service Plattform
Ein zentrales RepositoryMehrere Repositories nutzbar
Für einen kleineren Kreis an Key-Usern entwickeltFür das gesamte Unternehmen entwickelt, auf jedem Endgerät nutzbar
Geschlossenes System eines AnbietersOffenes System mit unterschiedlichen Services

CSP als Weiterentwicklungsmöglichkeit

Die CSPs können als Weiterentwicklung der Vernetzung angesehen werden. Aufgrund standardisierter APIs und der damit einhergehenden Flexibilität lassen sich weitere externe Datenspeicher oder Drittanwendungen optimal integrieren. Dies ermöglicht es, verteilte Inhalte, welche in unterschiedlichen Repositories liegen direkt in der führenden Anwendung dem Benutzer zur Verfügung zu stellen. Inhalte sollen somit kontextbezogen geliefert und um Metadaten angereichert werden. Für den Benutzer wird es daher zweitrangig, woher der Inhalt stammt oder wie er verwaltet wird.

Welche Funktionalitäten haben Content Services Plattformen?

  1. Zusätzlich zu ihrem primären Repository unterstützen CSPs auch externe Repositories
  2. Content Service Plattformen sind API-zentriert. Es werden gemeinsame, offene APIs für den Zugriff genutzt
  3. Es wird großen Wert auf intuitive Benutzeroberflächen und eine gute User Experience gelegt
  4. Flexibler Zugriff auf die verwalteten Inhalte über mehrere Endpunkte und Oberflächen (z.B. Laufwerk, Client, Synchronisierung, Weboberfläche, mobile Anwendungen, Add-On, usw.)
  5. CSPs bieten Integrationen mit gängigen Anwendungen wie Salesforce, SAP und weiteren
  6. Eine ideale CSP ist cloud-unabhängig und unterstützt öffentliche, private und hybride Cloud-Speicher
  7. Die Verwaltung der Inhalte geschieht nach gesetzlichen und organisatorischen Vorgaben und Vorschriften
  8. Flexible Architekturen und Funktionen zur Verhinderung von Datenlecks zur Sicherung von Unternehmensinhalten
  9. Zugriffsberechtigungen für Benutzer, Ordner und Dateien
  10. Verwaltung von Metadaten und Klassifizierung von Inhalten zur besseren Organisation und Sicherung von Inhalten

Fazit 

Content Services Plattformen (CSP) und Enterprise Content Management (ECM) verfolgen ähnliche Ziele, schlagen aber unterschiedliche Wege ein. Die Anforderungen und Strukturen der Arbeitswelt verändern sich, daher brauchen wir flexible Systeme, die sich weiterentwickeln können und von überall aus zugänglich sind. Aus diesem Grund hat Gartner den Begriff neu geprägt. Die Weiterentwicklung zu CSPs und die damit verbundenen Möglichkeiten, z.B. Zugriffe auf Inhalte über diverse Endpunkte intuitive Oberflächen sowie Integrationen mit Anwendungen (SAP etc.) orientieren sich an den neuen Ansprüchen. Der Trend geht also auch hier dazu, komplexe Systeme gegen schlanke und spezifische Services zu ersetzen.

Bitcoinkursvorhersage mit AWS – Teil 1

Social mediA Price PREdiction – SAPPhiRE
Abbildung 1. Social mediA Price PREdiction – SAPPhiRE – eigene Darstellung

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.

Architektur der ersten Leistungsstufe
Abbildung 2. Architektur der ersten Leistungsstufe – eigene Darstellung

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

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.

Architektur für die Datensammlung
Abbildung 3. Architektur für die Datensammlung – eigene Darstellung

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.

Architektur für das Modelltraining und die Vorhersage
Abbildung 4. Architektur für das Modelltraining und die Vorhersage – eigene Darstellung

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.

Gesamte Architektur
Abbildung 5. Gesamte Architektur – eigene Darstellung

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

 

Advanced Analytics Projekte mit Machine Learning erfolgreich umsetzen

 

 

Challenge accepted! Endlich eine Hex Tile Map, die aussieht wie Europa

Hex Tile Maps gehören mittlerweile zum Standardrepertoire bei der Visualisierung von Daten mit Tableau. Im Vergleich zu normalen Kartendarstellungen bietet ein Raster aus Sechsecken in der Karstendarstellung den großen Vorteil, dass die Größe der geografischen Region keine Rolle spielt und somit der optische Vergleich der Regionen wesentlich einfacher fällt. Des Weiteren gewährleistet die Hex Tile Map eine höhere Performance beim Rendering im Vergleich zu normalen Landkartendarstellungen. Das ist vor allen Dingen dann hilfreich, wenn eine große Region oder auch große, komplexe Berechnungen bzw. Datenmenge geografisch dargestellt werden sollen.

Obwohl die Hex Tile Map einige Vorteile im Vergleich zu einer normalen Kartendarstellung bietet, ist es gerade für die Region Europa relativ schwierig solch eine Map zu erstellen. Europa hat einerseits sehr viele Länder und zudem viele kleine Länder oder Stadtstaaten, was die gleichmäßige Anordnung mit gleichzeitigem Wiedererkennungswert im Vergleich zur normalen Europakartendarstellung erschwert. Länder wie die USA sind hier wesentlich leichter auf eine Hex Tile Map zu übertragen, sodass auch ein Wiedererkennungswert des Umrisses der USA gegeben ist.

Manche haben sich schon daran versucht, die Europakarte auf eine Hex Tile Map zu übertragen, wie einige Beispiele auf Tableau Public zeigen:

Hex Tile Map Europa
Quelle: https://public.tableau.com/views/EuropeHexagonTileMap/EuropeHexmap?:embed=y&:showVizHome=no&:display_count=y&:display_static_image=y&:bootstrapWhenNotified=true

 

Eurovision Song Contest nach Länder sortiert
Quelle: https://questionsindataviz.com/2017/06/04/which-shapes-work-well-with-tile-maps/

Da uns bei den obigen Beispielen aber zum einen der Wiedererkennungswert der Europakarte nicht hoch genug war und auch nicht alle Staaten aus Europa vertreten waren, haben wir uns in unserem Datenvisualisierungsteam selbst der Herausforderung gestellt und den Versuch gewagt, Europa auf eine Hex Tile Map zu übertragen.

Wie sind wir bei der Erstellung einer Hex Tile Map vorgegangen?

Auf Basis der Anleitung von Matt Chambers hört sich das Erstellen einer eigenen Hex Tile Map eigentlich ganz simpel an:

  1. Ein Excel-File erstellen mit Zahlenwerten für X- und Y-Achsen Position und dieses als Quelle in Tableau anlegen
  2. X-Achsenwerte in Spalten, Y-Achsenwerte in Zeilen ziehen
  3. Passende Darstellung wählen
  4. Punkte durch die Hex Tile Formen austauschen
  5. Ggf. Ansicht anpassen…und fertig!

Die Crux an der Geschichte: Schritt 1.

Allein die passenden Zahlenwerte für die Positionen der Tiles auf der X- und Y-Achse zu finden, hört sich jetzt nicht so kompliziert an. Es stellte sich aber, aufgrund der vielen kleinen Länder und Stadtstaaten, als ungeahnte Challenge heraus.

Zunächst wagten wir den Versuch einfach nur die Tiles auf einem Raster immer wieder hin- und her zu schieben. Was aber leider nie zum gewünschten Ergebnis führte. Dann aber kam uns die zündende Idee: die Europakarte als Hintergrund zu nehmen (1), ein Raster drüber zu legen (2) und dann die Tiles entsprechend auf der Karte zu positionieren (3), um die Hintergrundkarte dann wieder zu entfernen (4).

(1)Europakarte(2)Europakarte mit Raster versehen
(3)Europakarte mit Raster und Tiles versehen(4)Tiles und Karte

Quelle: Eigene Darstellung – unser Vorgehen bei der Erstellung einer Hex Tile Map

Um für die X- und Y-Werte des Rasters nachvollziehbare Werte zu setzen, nutzten wir dann statt den Zahlen von 0 – 20 in etwa die Werte der Längen- und Breitengrade der Länder. Der Hintergedanke dabei: mit dieser Vorgehensweise kann das Gebiet eventuell auch auf größere Flächen ausgedehnt werden. Da uns das Ergebnis immer noch nicht vollends zufrieden stellte, schoben wir dann doch noch ein bisschen hin und her, um eine kompaktere Form der Hex Tile Map zu bekommen.

Unsere Hex Tile Map von Europa

Die Hex Tile Map mit der Europakarte im Hintergrund fanden wir auch sehr ansprechend, daher wurden in unserem finalen Dashboard einfach kurzerhand beide Varianten vereint:

Quelle: https://public.tableau.com/profile/anja.pengl#!/vizhome/HexTileMapEurope/HexMapEuropa

In unserem Beispiel haben wir einen Datensatz der Eurostat (New registration of passenger cars by type of motor energy) verwendet, der die Registrierungen von Fahrzeugen nach Antriebstechnologie enthält.

Workbook to go

Mit dem Button „Freigeben“ in unsererem Workbook kannst Du dieses direkt herunterladen – oder wenn dir unser Raster nicht gefällt einfach Deine eigene Challenge draus machen. Binde mit diesem Link gleich alles in deiner Homepage ein:

https://public.tableau.com/views/HexTileMapEurope/HexMapEuropa?:display_count=y&:origin=viz_share_link

So oder so wünschen wir Dir viel Spaß beim Visualisieren und freuen uns, wenn Du deine Ergebnisse kommentierst.

 

Diese Beiträge könnten Dich auch interessieren:

Best Practices: Welches ist das richtige Werkzeug für die Datenaufbereitung mit Tableau

Die Top 3 Business Intelligence Tools – eine Kurzgeschichte

Best Practices: Welches ist das richtige Werkzeug für die Datenaufbereitung mit Tableau

Im Bereich Datenaufbereitung gibt es eine ständige Herausforderung: Wie werden die Daten am besten für Tableau aufbereitet? Und sind hierfür Tools wie Knime oder Tableau Prep oder gleich eine eigene Programmierung sinnvoller? Mit Glück haben die Unternehmen sich für einen Toolweg entschieden und der IT-Dienstleister kann diesem folgen. Wie aber vorgehen, wenn es keinerlei Vorgaben gibt? Anhand von folgenden fünf Fällen haben wir uns drei „Werkzeuge“ genauer angeschaut und beleuchten die Vor- und Nachteile der einzelnen Lösungen:

  1. Sehr große Datensätze (Dateien mit mind. 3 Mio. Datensätzen werden getestet)
  2. Komplexe Logik (werden bestimmte Logiken z.B. Loops unterstützt)
  3. Fehleranalyse (wie und wann werden Fehler vom Tool angezeigt)
  4. Verbindung zu verschiedenen Datenquellen (welche Verbindungen zu unterschiedlichen Datenquellen sind möglich)
  5. Automatisierung (Aktualisierung)

Unser Supporter für diesen Zweck ist ein HP Elitebook (RAM 16GB; Intel® Core™ i5-8250U CPU 1.60 GHz).

In der Übersicht: Wann ist welches Werkzeug sinnvoll

Für eine übersichtliche Empfehlung, in welchem Fall die getesteten Werkzeuge sinnvoll sind, haben wir in drei Kategorien eingeteilt (grün=für diesen Fall empfehlenswert, gelb=für diesen Fall mit Einschränkungen empfehlenswert, rot=für diesen Fall nicht empfehlenswert).

Übersicht und Einordnung Werkzeuge zur Datenaufbereitung mit Tableau
Abbildung 1: Übersicht Einordnung Werkzeuge Datenaufbereitung mit Tableau nach Kategorie, Eigene Darstellung

Tableau Prep – Nix für komplexe Logik

Fall 1: Sehr große Datensätze
Bei sehr großen Datensätzen kann es zu Einschränkungen der PC-Performance (CPU und Arbeitsspeicher) und von Tableau Prep kommen – bis hin zum kompletten PC-Absturz. Dabei geht der Arbeitsstand verloren und es muss von vorne begonnen werden.
Unser Testergebnis: nicht empfehlenswert.

Fall 2: Komplexe Logik
Es lässt sich keinerlei komplexe Logik abbilden.
Unser Testergebnis: nicht empfehlenswert.

Fall 3: Fehleranalyse
Fehler werden zwar sofort entweder im Bearbeitungsfenster oder im Bereich Benachrichtigungen angezeigt, jedoch können diese sehr kryptisch und knapp ausfallen.
Unser Testergebnis: mit Einschränkungen empfehlenswert.

Fall 4: Verbindungen zu verschiedenen Datenquellen
Dateien können von MS Access, CSV, PDF, XLS, Statistikdaten oder Tableau-Extrakte importiert werden. Es werden nicht so viele Verbindungen wie bei Tableau Desktop geboten.
Unser Testergebnis: mit Einschränkungen empfehlenswert.

Fall 5: Automatisierung
Wäre der Tableau Prep Conductor nicht lizenziert, wäre im Test eine automatisierte Ausführung auf Tableau Server mit Tableau Prep Conductor möglich. Eine lokale Automatisierung ist lokal durchführbar (Batch, JSON), der PC muss aber durchgehend angeschaltet sein.
Unser Testergebnis: mit Einschränkungen empfehlenswert.

Knime: komplexe Logik und große Datensätze

Fall 1: Sehr große Datensätze
Im Bereich großer Datensätze muss bei Knime am Ende geprüft werden, ob alle Berechnungen und Änderungen funktionieren. Das Ergebnis: es führt zu Performance-Einschränkungen, jedoch nicht zum Absturz. Wie bei Tableau Prep gibt es den Bonus, dass die Daten in der Stichprobe auf eine bestimmte Anzahl eingeschränkt sind (bis zu 1 Mio. frei wählbar). Ein weiterer Vorteil ist, dass bei Knime die Daten erst durchlaufen werden, wenn es vom User angestoßen wird.
Unser Testergebnis: mit Einschränkungen empfehlenswert.

Fall 2: Komplexe Logik
Mit über 2.000 Knotenpunkten und der Möglichkeit, eine komplexe Logik abzubilden ist Knime für diesen Fall empfehlenswert. Und gibt es mal keinen Node, um eine Logik abzubilden, kann sie in einem Node mit Java oder Python abgebildet und ausgeführt werden. Das Große Online-Register für Knoten sowie die hilfreiche Online-Community wiegen auch den Nachteil aus, dass Know-how aufgrund der vielen Funktionen dringend notwendig ist.
Unser Testergebnis: empfehlenswert.

Fall 3: Fehleranalyse
Warnungen und Fehler werden in Form von Symbolen oder Ampelfarben sofort im Knoten angezeigt, wobei eine Überprüfung von Knoten zu Knoten möglich ist. Meldungen können außerdem auch auf einer Konsole angezeigt werden. Einziges Manko: Fehlermeldungen sind teilweise nicht leicht nachvollziehbar, da das Error-Handling eines Knoten dem Creator unterliegt.
Unser Testergebnis: empfehlenswert.

Fall 4: Verbindungen zu verschiedenen Datenquellen
Es können Verbindungen zu einer großen Bandbreite an Datenquellen hergestellt werden – Textformate (CSV, PDF, XLS etc.), Unstrukturierte Datentypen (Bilder, Dokumente, Netzwerke etc.) oder Datenbanken und Data Warehouse Lösungen (Oracle, ApacheHive, Azure etc,), Twitter und Google usw.
Unser Testergebnis: empfehlenswert.

Fall 5: Automatisierung
Die Vorteile im Falle der Automatisierung heben sich bei Knime meist wieder auf. So ist zwar eine automatische Ausführung auf dem Knime-Server möglich, der ist aber wiederum lizenziert. Ebenfalls ist auf der einen Seite ein automatisierter Durchlauf (z.B. Batch) realisierbar, auf der anderen Seite jedoch keiner für Workflowketten umsetzbar.
Unser Testergebnis: mit Einschränkungen empfehlenswert.

Python: Mit Geduld zu maximaler Flexibilität und Aufbereitung großer Datensätze

Fall 1: Sehr große Datensätze
Im Falle sehr großer Datensätze ist es möglich, den gesamten Code zu schreiben, ohne die Daten anzufassen und es gibt kaum Performance-Einschränkungen. Ein Aber gibt es: die Fehleranalyse nimmt viel Zeit in Anspruch.
Unser Testergebnis: mit Einschränkungen empfehlenswert.

Fall 2: Komplexe Logik
Python ist im Kontext der komplexen Logik sehr frei in der Entwicklung. Funktionen wie z.B. FOR– oder While Schleifen stehen zur Verfügung. Um die komplexen Logiken umfänglich nutzen zu können, ist Know-how in der Sprache daher zwingend notwendig.
Unser Testergebnis: empfehlenswert.

Fall 3: Fehleranalyse
Durch einen Debugger ist eine direkte Dateneinsicht und bessere Fehlerverständlichkeit gegeben – und die Verwendung von Python Console ist auch während dem debuggen möglich. Jedoch werden Fehler bei Python erst angezeigt, wenn sie auftreten. Bei einem sehr großen Datensatz kann das schon mal eine halbe Stunde dauern.
Unser Testergebnis: mit Einschränkungen empfehlenswert.

Fall 4: Verbindungen zu verschiedenen Datenquellen
Eine Verbindung zu Dateiformaten (z.B. CSV, XLS, TSV, Datei etc.) ist möglich. Datenbanken und Data Warehouse Lösungen sind teilweise direkt integriert.
Unser Testergebnis: empfehlenswert.

Fall 5: Automatisierung
Eine Automatisierte Ausführung ist direkt auf den Servern möglich und eine lokale Automatisierung (z.B. Batch) wird ebenfalls geboten. Datenbanken und Data Warehouse Lösungen müssen jedoch Python Skripte unterstützen und der PC muss angeschaltet sein.
Unser Testergebnis: mit Einschränkungen empfehlenswert.

Fazit

Alle drei „Werkzeuge“ bzw. Lösungen bieten die Möglichkeit Daten auf verschiedene Art und Weise aufzubereiten. Nachdem wir die Lösungen in fünf Fällen untersucht haben, wird schnell ein Muster deutlich. Tableau Prep ist für eine schnelle und einfache Datenaufbereitung von kleineren Datensätzen sinnvoll. Da der Workflow auf den Tableau Server eingebunden werden kann, ist der Zugriff und die Bearbeitung des Workflows von überall möglich. Sollen komplexe Logiken und größere Datensätze aufbereitet werden, empfiehlt sich Knime oder Python.

 

Mehr über unsere Data Driven Services erfahren

 

Diese Blogbeiträge könnten dich auch interessieren:

Automatisierte Qualitätssicherung im Kontext von Data Analytics

Die Top 3 Business Intelligence Tools – eine Kurzgeschichte

Automatisierte Qualitätssicherung im Kontext von Data Analytics

Produkte wie Tableau, Qlik oder auch Power BI von Microsoft kommen bei der Datenanalyse und Datenvisualisierung häufig zum Einsatz. Ein sehr wichtiges Thema hierbei ist die Qualitätssicherung. Denn es gibt kaum Schlimmeres, als wenn die aufgezeigten Daten nicht der Wirklichkeit entsprechen. Die automatisierte Qualitätssicherung in IT-Projekten ist bereits weit verbreitet, bei Visualisierungsprojekten bzw. Data Analytics Projekten ist dies aber bei weitem noch nicht der Fall. Das Ergebnis: nach jeder Änderung wird manuell geprüft, ob noch alle Daten korrekt sind, bzw. ob die Verständlichkeit der Dashboards noch gegeben ist. Um diesen aufwändigen Prozess zu automatisieren, gibt es unterschiedliche Tools mit den verschiedensten Funktionen. Einige dieser Tools sind jedoch lediglich auf ein Produkt anwendbar – nur wenige Anbieter decken Tableau, Qlik als auch Power BI ab. Doch welche Funktionen genau haben die unterschiedlichen Tools? Wir haben vier der verfügbaren Tools genauer unter die Lupe genommen.

Vier Data Analytics Tools mit unterschiedlichen Test-Funktionen

Im Test haben wir diesen vier Tools BI Validator, Power Tools, Kinesis und QuerySurge auf den Zahn gefühlt. Unterscheiden sich die Tools bei vielen Funktionen deutlich, haben sie eines gemeinsam: mit allen kann die Performance von Reports getestet werden. Werfen wir aber doch einen genaueren Blick darauf.

Hier Teil 1 der Data Analytics Reihe lesen: Ist eine Abgrenzung des Begriffs noch möglich?

BI Validator

BI-Validator: Automatische Testläufe
Abbildung 1: Eigener Screenshot aus dem BI-Validator – Automatische Testläufe

Der BI Validator beispielsweise bietet unterschiedliche Tests:

  • Regressionstest von Arbeitsmappen: Vergleich von Arbeitsmappen für die Identifikation von Daten- und Layoutunterschieden
  • Regressionstest von Ansichten: Vergleich von verschiedenen Ansichten zur Erkennung von visuellen als auch Datenunterschiede
  • Stresstest: Erfassung von Leistungsstatistiken durch eine Simulierung der Benutzerlast
  • Upgrade Test: Vergleich von Arbeitsmappen vor und nach dem Upgrade
  • Performance Test: Überwachung der Dashboards, Erstellung von Leistungsberichten der Produktionsumgebung
  • Funktionsprüfung: ermöglicht das Zuordnen und Vergleichen von Reportdaten zu Datenquellen, um Ansichten zu überprüfen
  • Migrationstest: Vergleich der Daten eines Reports, die von Tableau generiert wurden
  • Sicherheitstest: Vergleich der Zugriffsebenen der einzelnen Benutzer bzw. Gruppen
  • Unternehmenszusammenarbeit: Ergebnisse können gemeinsam genutzt oder per E-Mail versendet werden, da Testpläne im Unternehmens-Repository gespeichert werden können.

 

Unser Fazit: Der BI Validator ist übersichtlich und einfach zu bedienen (auch ohne Programmierkenntnisse), daher können die Tests intuitiv durchgeführt werden. Für die Testläufe stehen zwei Anwendungsmöglichkeiten offen: manuell oder automatisiert.

Power Tools Desktop

Power Tools Desktop - Best Practice Analyzer
Abbildung 2: Eigener Screenshot aus dem Power Tools Desktop – Best Practice Analyzer

Um die Funktionen von Power Tools genauer zu betrachten, haben wir uns auf Power Tools Desktop (PTD) konzentriert. Mit diesem ist es möglich, eine Übersicht aller Datenfelder bei der Überprüfung von Datenquellen zu erstellen, auch mit dem Vermerk in wie vielen Ansichten und Berechnung sie auftauchen. Möchte man sich die Datenfelder genauer ansehen, ist es möglich, die Ansichten und Berechnungen direkt anzeigen zu lassen oder als Excel-Datei bzw. PDF zu exportieren. Eine weitere nützliche Funktion, um einen Überblick über alle Datensätze, Felder oder Datentypen zu erhalten, ist die Ausgabe einer allgemeinen Statistik zu Datenquellen einzelner Arbeitsmappen. Zusätzlich bietet z.B. der Style Manger an, einzelne Formatierungen der Arbeitsmappen zu erfassen und Dashboards zusammenführen.

 

Unser Fazit: Das Augenmerk bei Power Tools Desktop liegt ganz klar auf der Überprüfung der Performance von Arbeitsmappen sowie der Dokumentation von Daten. Die graphische Oberfläche ermöglicht eine einfache Navigation und die Durchführung von Analysen. Die Tests sind jedoch ausschließlich manuell möglich.

Kinesis

Kinesis: Testtypen
Abbildung 3: Eigener Screenshot aus Kinesis – Testtypen

Wie schlägt sich Kinesis mit schlanken vier Test?

  • Funktionstest: Unter anderem ist eine Simulierung von Benutzerinteraktionen und Benutzerentscheidungen sowie das Schreiben von Testfällen möglich
  • Regressionstest: Vergleich von zwei Tableau-Ansichten und die Nachverfolgung von Änderungen
  • Cross-Environment Test: Vergleich von Ansichten in unterschiedlichen Umgebungen (z.B. Standorte oder Server)
  • Performance Test: Beurteilung der Serverleistung, z.B. Antwortzeiten

 

Unser Fazit: Obwohl die Benutzeroberfläche bei Kinesis sehr einfach ist, kommen hier und da Unklarheiten auf, da diverse Mitteilungen anfangs unverständlich aufgezeigt sind –  als Hilfestellung ist dringend die Dokumentation notwendig.

QuerySurge

QuerySurge_Startbildschirm
Abbildung 4: Eigener Screenshot aus QuerySurge – Startbildschirm

Last but not least nehmen wir QuerySurge unter die Lupe. Hier wird über den Internet Explorer zugegriffen –  so sind mehre User möglich. Die Navigation funktioniert über eine graphische Oberfläche. Eine Auswertung der Testdaten erfolgt in Form von Paretodiagrammen und Korrelationsdiagrammen. Informationsmeldungen (z.B. Fehlermeldungen) werden praktischerweise direkt sichtbar auf dem Bildschirm ausgegeben. Die Ausgabe von einzelnen Reports oder Fehlersammellisten ist über Excel, CSV oder XML möglich. Mit dem BI Tester Add-On wird ergänzend eine große Bandbreite an Bereichen abgedeckt:

  • Geschäftsvalidierung von Berichten
  • Vollständiger Regressionstest der BI-Daten
  • Migrationstest von einem BI-Anbieter zu einem anderen
  • Aktualisierung von Tests von einer Version auf die andere
  • Vergleich von Berichten zwischen Servern
  • Übergabe von Parametern an einen Bericht
  • Abfragen von Berichtsmetadaten

 

Unser Fazit: Ist bei QuerySurge die Bedienbarkeit anfangs etwas schwierig, wird sie nach mehrmaliger Anwendung selbstverständlich. Diverse Tutorials sind aber sehr hilfreich. Ein Must-have zur Nutzung des Tools: Programmierkenntnisse.

Lust auf eine kleine Geschichte? Die Top 3 Business Intelligence Tools – eine Kurzgeschichte

Fazit

Die Automatisierung der Qualitätssicherung im Bereich der Datenanalyse und Datenvisualisierung birgt viele positive Aspekte – aber die Umsetzung mit passenden Tools ist ebenso wichtig, damit sie funktioniert. Umso wichtiger ist es, die Mitarbeiter bei der Überprüfung von Daten zu unterstützen, indem man ihnen das passende Tool an die Hand gibt. Natürlich hat jedes Tool seine Stärken und Schwächen. Um das passende Tool für die eigenen Verwendungszwecke zu finden, ist es daher wichtig klare Anforderungen an das Tool zu definieren. Nur so lässt sich der richtige Anbieter finden. Unser Favorit ist das Tool Query Surge: Es sind zwar SQL-Kenntnisse notwendig, wenn man jedoch hinter die Logik des Tools kommt, versteht man auch schnell die Funktionsweise. Hinzu kommt, dass die Entwickler gerade dabei sind, das Tool auch für Microsoft Power BI und Qlik kompatibel zu machen.

 

Mehr zu unseren Data Driven Services erfahren

 

Quellen:

Gudivada, Venkat N. (2017): DATA ANALYTICS: FUNDAMENTALS. In: Mashrur Chowdhury, Amy Apon und Kakan Dey (Hg.): Data Analytics for Intelligent Transportation Systems. Niederlande, Großbritanien, USA: Elsevier, S. 44–80.

Blockchain und Kryptowährung: warum haben sich noch keine lukrativen Geschäftsmodelle gefunden?

Warum wird das Thema Blockchain und Kryptowährung aktuell in vielen IT-Projekten und auf Webseiten heiß diskutiert – aber gleichzeitig weder von klassischen Zahlungsprovidern noch von Banken eine Dienstleistung auf Basis von Kryptowährungen angeboten?

Einer der größten Zahlungsanbieter der Welt, Stripe, liefert eine Antwort auf diese Frage: Bei Stripe handelt es sich um einen Online-Zahlungsdienst, welcher 2009 von den Brüdern Patrick und John Collison in den USA gegründet wurde. Im Jahr 2014 war Stripe das erste große Zahlungsunternehmen, welches Bitcoin-Zahlungen unterstützte. Nach vier Jahren wurde im April 2018 allerdings die Verarbeitung von Bitcoin-Transaktionen eingestellt.

Praxiswissen Blockchain hier entlang

Der Grund für diese Entscheidung? Stripe erhoffte sich, dass das Bezahlen mit Kryptowährung den Kunden helfen würde, Zahlungen in geografischen Gebieten zu ermöglichen, in denen Kreditkarten und Bankzahlungsabrechnungen generell unmöglich oder sehr schwierig sind.

Vom Untergang der Bitcoin-Zahlungen

Bitcoin hat sich jedoch nicht zu einem Tauschmittel entwickelt, sondern ist zu einem Vermögenswert bzw. Spekulationsobjekt mutiert und deswegen als Zahlungsmittel eher ungeeignet.

On top kam eine Reihe weiterer Funktionen, welche die Entscheidung zur Abschaffung der Bitcoin-Zahlungen finalisierte, wie beispielsweise die Bestätigungszeit einer Transaktion. Durch das Ansteigen der Transaktionsdauer stieg gleichzeitig die Fehlerquote der Transaktionen. Wenn eine Transaktion also endlich bestätigt wurde, hatte sich der Kurs der Währung häufig schon verändert. Das Ergebnis war die Verbuchung „falscher Beträge.“ Besonders beim High-Speed-Trading führte dies zu großen Verlusten.

Auch sind die Transaktionskosten in den letzten Jahren stark gestiegen, wodurch diese etwa auf einer Stufe mit regulären Überweisungen bei Banken stehen.

Durchschnittliche Transaktionskosten pro Tag in Dollar pro Transaktion
Durchschnittliche Transaktionskosten pro Tag in Dollar pro Transaktion; Quelle: https://bitcoinfees.info/ (13.12.2019)

So beobachtete Stripe nicht nur einen Rückgang des Transaktionsvolumens, sondern auch einen Abbau der Unternehmen, die Bitcoin-Zahlungen annahmen. Am 23. April 2018 wurden dann Bitcoin-Zahlungen komplett eingestellt.1

Die Alternative: stable coins

Doch wie stehen andere Global Player und Sachkundige zu Bitcoin und Kryptowährungen? IBM sieht Potential in der Blockchain-Technologie und verweist auf den Erfolg in den Bereichen Supply Chain, grenzüberschreitende Transaktionen und Identitätsprüfung. Besonders die Unveränderlichkeit der Blockchain ohne Regulierung des Mechanismus macht Geschäftsprozesse schneller und unkomplizierter.2 Der Einsatz der Blockchain-Technologie verspricht den Nutzern ebenfalls große Sicherheit.3 Bei der Verarbeitung von sensiblen Daten, wie bei Geldtransaktionen, ist dies von hoher Bedeutung.

IBM arbeitet ebenso an der Entwicklung einer „stable coin“, welche hohe Volatilität meiden und als praktischer Transaktionsmechanismus dienen soll.4 Im Gegensatz zum Bitcoin sind stable coins an einen anderen Vermögensgegenstand geknüpft. Bei der Kryptowährung von Facebook „Libra“ handelt es sich dabei um die Währungen US-Dollar, Euro, Yen, Britische Pfund und der Singapur-Dollar.

Die Haltung der Bundesregierung gegenüber Kryptowährungen ist generell positiv, eine stable coin lehnt sie hingegen ab. Ein Grund hierfür ist die Vermutung, dass stable coins von größeren Unternehmen in Konkurrenz zum Euro stehen könnten. Eine berüchtigte Befürchtung, wenn man sich zum Beispiel Facebook mit seiner eigenen stable coin anschaut und ihren mehr als 2 Mrd. Nutzern. Auch Politiker und Notenbanken sehen einen Stellenwertverlust in der Abgabe ihrer Aufgaben an Konzerne.5 Ein drittes Argument ist, dass auch wenn die Technologie in der Theorie wenig Raum für Sicherheitslücken lässt, es in der Praxis trotzdem häufig zu Hacking-Attacken kommt. Häufig handelt es sich um Phishing-Attacken oder Passwortdiebstahl, bei denen der Mensch als Schwachstelle ausgenutzt wird6 oder um DDoS-Attacken auf solche Plattformen, bei denen durch Überlastung der Hosting-Systeme hohe wirtschaftliche und Image-Schäden für die Betreiber die Folge sind.7

Fazit

Zusammenfassend lässt sich sagen, dass die Finanzwelt und ihre etablierten Größen nicht in eine Zeit ohne Kryptowährung und Blockchain-Technologie zurückkehren möchten. Die Suche nach möglichen lukrativen Anwendungsbereichen der Kryptowährung wird sich bei den Zahlungsdienstleistern fortsetzen und dort Investitionen getätigt, wo ein hohes Gewinnpotential in Aussicht ist. Trotz des enormen Potentials dieser Technologien sind sie noch weit von einem perfekten Mechanismus entfernt, der den Verlauf des globalen Währungsprozesses völlig verändert.

Dieser Blogbeitrag könnte Dich auch interessieren: Die Welt im Bitcoin-Rausch


 

1 Vgl.https://stripe.com/de/blog/ending-bitcoin-support (12.12.2019)

2 Vgl.https://fortune.com/2018/07/17/stripe-blockchain/ (12.12.2019)

3 Vgl.https://www.computerwoche.de/a/blockchain-was-ist-das,3227284 (12.12.2019)

4 Vgl.https://fortune.com/2018/11/19/blockchain-ripple-transferwise/ (12.12.2019)

5 Vgl.https://www.biallo.de/geldanlage/news/stablecoin-kryptowaehrungen-reif-fuer-den-massenmarkt/ (13.12.2019)

6 Vgl.https://www.it-finanzmagazin.de/sicherheitsrisiko-kryptowaehrungen-gefahr-cyberangriffe-66768/ (13.12.2019)

7 Vgl.https://www.security-insider.de/was-ist-ein-ddos-angriff-a-672826/ (13.12.2019)

It’s #FrontendFriday – Who runs the world? WebBrowser?

Hallo #FrontendFriday-Leser/in,

mir ist vor ein paar Tagen erst bewusst aufgefallen, dass wir immer mehr im WebBrowser machen (können). Sei es Emails lesen oder schreiben, Nachrichten lesen, Videos schauen, Kalender teilen, Geld überweisen, einkaufen, …

Eine Anwendung für den WebBrowser zu entwickeln ist sehr attraktiv, jeder benutzt einen und man kann den Inhalt auf allen Betriebssystemen einsehen. Mails z.B. bei GMX kann ich am PC, Handy oder vom Tablet aus über einen einfachen Link www.gmx.de erreichen. Wie genial ist das eigentlich?
Die Browser werden auch immer mit neuen Funktionen ausgestattet und machen so Features plattformübergreifend verfügbar.

Mehr

It’s #FrontendFriday – Was ist HTTP?

Es ist soweit, es ist Freitag – It’s #FrontendFriday :)

Im heutigem Blog geht es um das Thema „Was ist HTTP?“.

Was ist HTTP?

Das Hypertext Transfer Protocol (HTTP, englisch für Hypertext-Übertragungsprotokoll) ist ein zustandsloses Protokoll zur Übertragung von Daten auf der Anwendungsschicht über ein Rechnernetz. Es wird hauptsächlich eingesetzt, um Webseiten (Hypertext-Dokumente) aus dem World Wide Web (WWW) in einen Webbrowser zu laden. Es ist jedoch nicht prinzipiell darauf beschränkt und auch als allgemeines Dateiübertragungsprotokoll sehr verbreitet.

Mit Hypertext Transfer Protocol (HTTP) kommen die Nutzer eines Webbrowsers immer dann in Berührung, wenn sie die Webseiten eines entfernten Servers laden.
Das 2014 von der Internet Engineering Task Force (IETF) veröffentlichte RFC 7231 charakterisiert HTTP derweil allgemeiner als zustandsloses Protokoll, das auf Anwendungsebene angesiedelt ist und sich für verteilte, kollaborative Hypertextinformationssysteme eignet.

Wie funktioniert HTTP?

Mehr