Data Driven
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 .
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)2 . 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
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.
Bitcoinkursvorhersage mit AWS – Teil 1
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
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
Advanced Analytics Projekte mit Machine Learning erfolgreich umsetzen
Unser Kracher-Beitrag im März: Eine Hex Tile Map für Europa
Top Scorer mit den meisten Visits im März war unser Beitrag zu einer Hex Tile Map, die aussieht wie Europa. Längst im Standartrepertoire in Tableau für die Visualisierung von Daten, ist es schwierig eine Map für Europa zu erstellen. Wir haben gesagt „Challenge accepted“. Wie wir es geschafft haben?
Hier geht’s zum Beitrag
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:
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:
- Ein Excel-File erstellen mit Zahlenwerten für X- und Y-Achsen Position und dieses als Quelle in Tableau anlegen
- X-Achsenwerte in Spalten, Y-Achsenwerte in Zeilen ziehen
- Passende Darstellung wählen
- Punkte durch die Hex Tile Formen austauschen
- 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) | (2) |
(3) | (4) |
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:
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
KI kann alles? Die aktuellen Grenzen von KI und Deep Learning
Künstliche Intelligenz war schon immer ein wesentlicher Bestandteil futuristischer Visionen. Diesen Zukunftsbildern sind wir in den letzten Jahren durch die rasante Entwicklung im Bereich der künstlichen Intelligenz deutlich nähergekommen. Wer hätte schon um die Jahrtausendwende mit selbstfahrenden Autos gerechnet? Gleichzeitig werden die (scheinbar unendlichen) Möglichkeiten von KI, z.B. in den Medien, häufig zu optimistisch oder auch z.T. übertrieben dargestellt. Das sogenannte Deep Learning, eine spezielle mathematische Methode basierend auf neuronalen Netzen, ist ganz maßgeblich für den aktuellen Hype um KI mit verantwortlich. Gleichzeitig hat auch diese Methode seine Grenzen, auf die Gary Marcus in seinem Paper „Deep Learning: A Critical Appraisal“ strukturiert eingeht. Inspiriert von dieser Arbeit soll im Folgenden auf diese Grenzen näher eingegangen werden.
Die Größe der realen Welt und wie begrenzt KI sie sieht
Die Realität ist unglaublich komplex und unglaublich vielfältig. Wir Menschen bewegen uns tagtäglich in dieser Komplexität, die häufig daher rührt, dass wir nicht in fest definierten, abgeschlossenen Systemen leben. Viele Teilaufgaben kann künstliche Intelligenz schon heute besser lösen als wir, aber gleichzeitig sind Menschen immer noch recht gut darin, Information im jeweiligen Kontext zu verarbeiten. Sehen wir nachts eine rot leuchtende Verkehrsampel im Garten eines Freundes, erkennen wir sie als Partybeleuchtung und warten nicht darauf, dass auf grün umschaltet.
Wie sieht künstliche Intelligenz aber die Welt? KI-Algorithmen lernen die Welt durch Datensätze kennen. Betrachten wir zum Beispiel das autonome Fahren. Eine Teilaufgabe besteht für KI hier darin, Schilder korrekt zu erkennen. Hierzu können wir einem KI-Algorithmus Beispielbilder vorlegen. Gleichzeitig würden wir die Schilder auf den Beispielbildern markieren und die korrekte Kategorie benennen („Stoppschild“). Der KI-Algorithmus vergleicht nun ein Bild mit der erwarteten Ausgabe („Stoppschild“) – dies macht er mit allen Beispielbildern und versucht, einen mathematischen Zusammenhang zwischen dem Bild und der Verkehrsschildkategorie zu finden.
Die Welt besteht für einen KI-Algorithmus also hauptsächlich aus den Daten, die ihm vorgelegt werden. Damit unterscheidet sich der KI-Algorithmus natürlich nicht grundlegend von uns Menschen, aber es gibt doch einige Herausforderungen und Grenzen, die ihn doch unterscheidet.
Schierer Datenhunger
Ein kleines Kind, das zum ersten Mal in seinem Leben einen Elefanten sieht, versteht sehr schnell was ein Elefant ist und erkennt danach ein solches Tier auch in anderen Zusammenhängen sehr zuverlässig, z.B. in einem Kinderbuch oder im Fernsehen. Bei Deep-Learning-Algorithmen ist dies nicht der Fall. Dies liegt daran, dass sie solche Zusammenhänge nicht explizit lernen können, sondern diese implizit auf Basis einer großen Anzahl von Beispielen tun. Daher sind sie extrem datenhungrig. Liegen diese großen Datenmengen nicht vor, dann tun sich diese Algorithmen sehr schwer, die Qualität der Modelle bzw. der Vorhersageergebnisse sinkt.
Auch müssen die verarbeiteten Beispieldaten möglichst alle Facetten eines Problems beinhalten. Ein Deep-Learning-Verfahren, dass immer nur mit weißen Schwänen trainiert wurde, ist – im Gegensatz zum Menschen – nicht in der Lage, einen plötzlich auftretenden schwarzen Schwan zu erkennen, wenn dieser vorher nicht in den Trainingsdatensätzen hinterlegt war.
Auch heute können wir die Welt um uns (noch?) nicht abschließend erklären. Doch eine der Stärken der Wissenschaft ist es, auf dem vorhandenen Wissen aufzubauen und in einem iterativen Prozess immer bessere Modelle unserer Welt zu entwerfen. Das Englische Sprichwort „Standing on the shoulders of giants“ beschreibt dies anschaulich: Jede Generation baut auf den Vordenkern vergangener Epochen auf.
Das bedeutet aber auch, dass wir in all unserem Handeln immer auf dieses Vorwissen zugreifen können. Ein Apfel in unserer Hand, den wir loslassen, fällt auf den Boden und steigt nicht an die Decke. Fassen wir eine kalte Wand an, so wird die Wand wärmer und unsere Hand kälter – Energie geht also auf den kälteren Körper über. Das Gegenteil passiert nicht spontan. All das sind Beispiele für allgemeines Vorwissen, das wir stets als Transferwissen verfügbar haben, unabhängig davon, welche speziellen Probleme wir gerade lösen.
Doch Deep Learning-Algorithmen können dieses Transfer- oder Allgemeinwissen nicht nutzen. Sie können nicht auf einem allgemeinen Vorwissen aufbauen, sondern müssen jedes Problem, das sie lösen sollen, von Grund auf neu lernen. Deep-Learning-Algorithmen sind also immer sehr problemspezifisch.
Ein Beispiel in diesem Zusammenhang ist die Bilderkennung. Es gibt schon sehr gute Deep-Learning-Modelle zur Objekterkennung. Diese erkennen sehr zuverlässig, ob auf einem Bild ein Teller Nudeln oder ein Hund dargestellt wird. Eine leichte Abwandlung dieser Problemstellung – z.B. der Algorithmus soll auf Satellitenfotos automatisch Fahrbahnmarkierungen (Zebrastreifen, Pfeile, etc.) erkennen – führt dazu, dass diese Modelle für diese Problemstellung völlig unbrauchbar werden und ein ganzer Forschungszweig gegründet wird, der sich nur mit der Lösung dieses Themas beschäftigt.
Korrelation bedeutet nicht kausaler Zusammenhang
Die Nutzung von Vorwissen ist auch notwendig, um logisch sinnvolle Zusammenhänge von zufälligen Zusammenhängen zu unterscheiden. Ein Beispiel: Die Geburtenrate in westeuropäischen Ländern geht stetig zurück. Gleichzeitig ist die Anzahl brütender Storchenpaare rückläufig. Wollten wir die Geburtenrate erhöhen, müssten wir also einfach Störche besser schützen?
Das ist natürlich ein offensichtlicher Fehlschluss. Nur weil ein mathematischer Zusammenhang historisch existiert, heißt es noch lange nicht, dass die Geburtenrate in einem logischen Zusammenhang mit der Anzahl der Störche steht.
Ein Mensch kann diesen offensichtlichen Fehlschluss erkennen, da er gerade auf seine gesamte Lebenserfahrung und Allgemeinbildung zurückgreifen kann – KI kann das im Allgemeinen nicht. Bei komplizierteren Problemstellungen können auch Menschen nicht mehr zweifelsfrei sagen, ob einem mathematischen Zusammenhang eine reale Abhängigkeit zu Grunde liegt. Hier müssen Wissenschaftler Hypothesen aufstellen, die sie dann immer wieder mit neuen Experimenten versuchen zu widerlegen.
Bedeutet Auswendiglernen wirklich Konzeptverständnis?
Im Begriff „Künstliche Intelligenz“ ist schon der Vergleich mit menschlichen Fähigkeiten angelegt. Diese Vergleiche ziehen sich durch alle Begrifflichkeiten: so „lernt“ zum Beispiel ein Machine-Learning-Modell Zusammenhänge und Ähnlichkeiten aus einem vorgegebenen Datensatz. Nur was genau bedeutet hier „lernen“? Ein Mensch ist in der Lage, mit recht wenigen Daten Konzepte zu lernen.
Zur Illustration dient Abbildung 4: in einem einfachen Computerspiel bewegt sich auf dem Bildschirm ein Ball. Ziel ist es mit dem Ball alle auf dem Bildschirm platzierten Blöcke zu berühren, die bei Berührung verschwinden. Trifft der Ball auf ein Hindernis, so wird er von dort abgestoßen. Es sei denn, er berührt den unteren Bildschirmrand, dann ist das Spiel verloren. Mit Hilfe eines horizontal beweglichen Schlägers lässt sich der Ball indirekt steuern.
Ein Mensch versteht das Spielprinzip nach wenigen Sekunden, auch ohne eine explizite Regeldefinition und hat auch keine Probleme mit einer leichten Abwandlung: zum Beispiel, in dem die vertikale Position des Schlägers leicht verändert wird. Ein Deep-Learning-Modell hat mit solchen Verallgemeinerungen häufig große Probleme und scheitert durch die leichte Veränderung der äußeren Umstände. Das Modell hat nicht wirklich verallgemeinerte Konzepte gelernt („Schläger“, „Ball“, „Wand“) sondern durch endloses Ausprobieren eine erfolgreiche Lösungsstrategie gefunden – die jedoch nicht robust ist gegen kleine Abwandlungen der Systemparameter.
Die vielgefürchtete „black box“
Deep-Learning-Modellen wird häufig nachgesagt, dass sie schwer „erklärbar“ sind und wie eine „black box“ wirken. Man füttert das Modell mit Daten, erhält eine Antwort, aber weiß nicht wirklich, warum das Modell diese Antwort gegeben hat. Das Regelwerk, das zur Entscheidung führt, ist nicht sofort ersichtlich – es ist regelrecht undurchsichtig. Um diese Undurchsichtigkeit von KI zu durchbrechen, ist die „Erklärbarkeit“ von KI-Modellen ein Gegenstand aktueller Forschung. Aber warum ist das überhaupt wichtig? Ganz konkret schränken undurchsichtige KI-Modelle die Anwendbarkeit von KI in den folgenden zwei Beispielen ein:
Vertrauenswürdigkeit: Besonders in regulierten Bereichen, wie zum Beispiel der Medizintechnik oder dem Verkehrswesen, unterliegt jegliche Software besonders hohen gesetzlichen Auflagen. Es soll sichergestellt werden, dass die Software unter allen möglichen Umständen sicher agiert. Das stellt Deep-Learning-Modelle vor große Herausforderungen: Sie lernen hauptsächlich aus den zur Verfügung stehenden Daten. Nehmen wir wieder das Beispiel einer Verkehrsschilderkennung. Es ist undurchsichtig, warum genau das Modell ein Stoppschild als solches erkennt. Die Forschergruppe um Eykholt et al1. zeigte zum Beispiel, wie leicht KI-Modelle sich hier austricksen lassen können. Durch eine leichte Modifikation der Verkehrsschilder, die für Menschen klar als solche erkennbar war, wurden die Schilder nicht mehr als Stoppschild erkannt. Solche Effekte stellen natürlich das Vertrauen in Deep-Learning-Algorithmen für diese Anwendungszwecke in Frage. Die Undurchsichtigkeit von Deep-Learning-Modellen erschwert es, solche unerwünschten Effekte zu bemerken, da sie nicht direkt erkennbar sind.
Sicherheits- und Qualitätsgarantien für modulare Systeme: Im Ingenieursbereich werden komplexe technische Systeme häufig aus vielen kleinen Einzelteilen zusammengesetzt. Ein Auto benötigt einen Motor, Räder, eine Kupplung – für jede dieser Komponenten können in der Entwicklung Sicherheitsgarantien gegeben werden, die es erlauben das Teil in ein größeres Gesamtsystem einzusetzen. Deep-Learning-Modelle können das nicht ohne weiteres. Sie sind extrem abhängig von ihrem ursprünglichen Datensatz. Durch die Undurchsichtigkeit der Modelle ist es sehr schwierig, die Auswirkung veränderter Voraussetzungen auf das Modell abzuschätzen. Dementsprechend ist es nur schwer möglich ein Gesamtsystem modular aus vielen Modellen aufzubauen und verbindliche Qualitäts- und Performancegarantien für das Gesamtsystem abzuleiten.
Wie sieht die Zukunft von KI und Deep Learning aus?
Gary Marcus gibt ein paar Anregungen bezüglich der künftigen Entwicklung von künstlicher Intelligenz und insbesondere von Deep Learning:
- Wiederaufleben anderer KI-Disziplinen: Deep Learning ist ein Teil des Machine Learning, welches wiederum einer ganz gewissen Disziplin der künstlichen Intelligenz angehört. Eine klassische Disziplin der KI ist symbolische Künstliche Intelligenz. Hierdurch können vielleicht Fortschritte im logischen Schließen erzielt werden.
- Zurück zum Studienobjekt Mensch: So kann man besser verstehen und lernen, wie wir lernen und die Welt wahrnehmen. Disziplinen wie die kognitive Psychologie und Entwicklungspsychologie, die versuchen die Funktionsweise des Menschen besser zu verstehen, könnten hier neue Impulse liefern.
- Anspruchsvollere Ziele: Häufig wird versucht, mit Deep Learning eng abgesteckte Probleme zu lösen. Stattdessen steht der Vorschlag im Raum, darüber hinausgehende Herausforderungen aufzustellen – z.B. einen Algorithmus ein beliebiges Video oder einen Text analysieren zu lassen und ihn offene Fragen beantworten lassen: Wer ist die Hauptfigur? Was will sie erreichen? Welche Folgen hätte ihr Erfolg oder Misserfolg?
Fazit: Herausforderungen und Grenzen kennen – Deep Learning richtig nutzen
Manchmal scheint es, als stünde Künstliche Intelligenz kurz davor, die Menschheit in jeglicher Hinsicht zu überflügeln. Es gibt in der Tat einzelne Problemstellungen, in denen dies der KI bereits gelungen ist. Dennoch sind wir von einer Dominanz der KI in allen Lebensbereichen noch ein gutes Stück entfernt. Deep-Learning-Methoden arbeiten besonders gut, wenn sehr viele Daten vorhanden sind und die Problemstellung ganz klar abgegrenzt ist. Aber es gibt auch noch viele Herausforderungen – unter anderem: ein echtes Verständnis abstrakter Konzepte, Transfer von Wissen auf neuartige Anwendungsprobleme, Transparenz und Sicherheitsgarantien, die Unterscheidung zwischen zufälligen und logisch sinnvollen Zusammenhängen. Daher ist ein Bewusstsein über diese Rahmenbedingungen, beim Einsatz von KI Verfahren wie z.B. Deep Learning, sehr wichtig. Die Anregungen von Gary Marcus für die künftige Entwicklung können da wertvolle Impulse liefern.
Co-Autor: Danny Claus
1 Robust Physical-World Attacks on Deep Learning Visual Classification
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:
- Sehr große Datensätze (Dateien mit mind. 3 Mio. Datensätzen werden getestet)
- Komplexe Logik (werden bestimmte Logiken z.B. Loops unterstützt)
- Fehleranalyse (wie und wann werden Fehler vom Tool angezeigt)
- Verbindung zu verschiedenen Datenquellen (welche Verbindungen zu unterschiedlichen Datenquellen sind möglich)
- 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).
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
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
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
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
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
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.
Data Analytics in der Definitionskrise: Ist eine Abgrenzung des Begriffs noch möglich?
Wenn man zum ersten Mal über den Begriff Data Analytics stolpert, wird zunächst davon ausgegangen, dass es sich hierbei um eine Analyse von Daten handelt. Im ersten Ansatz ist diese Einordung auch gar nicht so verkehrt. Befasst man sich jedoch intensiver mit diesem Thema, macht sich schnell die Problematik einer klaren Definition bemerkbar. Begrifflichkeiten wie Business Analytics, Data Mining, Big Data Analytics oder auch Data Science erscheinen bei der Suche nach einer eindeutigen Definition ebenfalls auf der Bildfläche – alles scheint ineinander zu verschwimmen. Also wie lässt sich Data Analytics nun abgrenzen?
Vom Datenbanksystem zur kognitiven Verarbeitung von Daten
Data Analytics hat sich in den letzten Jahrzehnten unter verschiedenen Begrifflichkeiten wie SQL Analytics, Data Mining oder auch Big Data Analytics heraus entwickelt. Der Ursprung lag in den klassischen Datenbanksystemen wie z.B. RDBMS (Relational Database System). Mit den rasant wachsenden Datenmengen und deren Verarbeitung war eine konstante Anpassung unumgänglich – bis hin zur kognitiven Verarbeitung von Daten. Grundsätzlich kann man Data Analytics also als eine Art Oberbegriff sehen, unter dem die einzelnen Begriffe zusammengefasst werden.
Die nachfolgende Abbildung zeigt die Entwicklung in den letzten 50 Jahren:
Vier Analyseverfahren miteinander verknüpft
Data Analytics verfügt über vier Analyseverfahren, die stark miteinander verknüpft sind und sich signifikant überschneiden. Auf verschiedenen Zeitebenen versuchen die Verfahren, unterschiedliche Fragenstellungen zu beantworten: Descriptive Analytics (Was ist passiert?), Diagnostic Analytics (Warum ist es passiert?), Predictive Analytics (Was wird passieren?) und Prescriptive Analytics (Was soll geschehen?). Während Predictive Analytics also die Eintrittswahrscheinlichkeit analysiert, liefert Prespcritpive Analytics die passende Handlungsempfehlung, z.B. wie man einen bestimmten Trend beeinflussen oder ein vorhergesagtes Ergebnis verhindern kann oder auch wie man auf ein zukünftiges Ergebnis reagieren sollte. Es ermöglicht somit eine automatisierte Entscheidungsfindung.
Fazit
Nach einem intensiveren Blick auf das Thema wird schnell deutlich: eine eindeutige oder gar einheitliche Definition des Begriffs Data Analytics ist weit gefehlt. Eine häufige Überschneidung der Hauptbegriffe (SQL Analytics, Business Analytics, Visual Analytics, Big Data Analytics und Cognitive Analytics) führt nicht nur zu einer schnelllebigen Weiterentwicklung der Thematik; sondern auch zu einer plötzlichen Zusammenfassung von Themen, neuen Beschreibungen oder sogar völlig neuen Kreationen an Begrifflichkeiten.
Noch nicht genug? Hier Teil 2 der Data-Analytics Reihe lesen
1 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.
Hier mehr über unsere Data Driven Services erfahrenWelcher Fahrzeugantrieb wird das Rennen um die Zukunft gewinnen?
Die Automobilbranche rund um den klassischen Verbrennungsmotor befindet sich mehr denn je im Wandel und die Unsicherheit über DEN Fahrzeugantrieb der Zukunft ist groß.
Dieselfahrverbote in deutschen Innenstädten, politische Einschränkungen und der sich immer stärker bemerkbar machende Klimawandel bringen die großen Automobilkonzerne in immer größer werdende Bedrängnis. Tatsächlich scheinen die Tage der konventionellen Verbrennungsmotoren allmählich gezählt und alternative Energiekonzepte für Fahrzeuge rücken immer mehr in den Fokus der Debatte über die Mobilität der Zukunft. Das Elektrofahrzeug genießt derzeit eine immer breiter werdende Bekanntschaft und Etablierung. Doch sind rein elektrische Fahrzeuge das endgültige Nonplusultra? Ein Vergleich soll zeigen, welche weiteren Alternativen zur Verfügung stehen und worin deren Vor- und Nachteile liegen.
Rein elektrische Fahrzeuge
Der zentrale Bestandteil eines Elektrofahrzeuges ist der Elektromotor. Vereinfacht ausgedrückt, wandelt der Motor elektrische Energie (Strom) mittels eines Elektromotors in mechanische Energie um.
Positiv:
- Elektrofahrzeuge sind emissionsfrei und stoßen keinerlei Schadstoffe aus
- Äußerst günstige Ladevorgänge
- Strom kann direkt genutzt werden, daher ergibt sich ein hoher Wirkungsgrad
- Batterie-Ladevorgänge können sowohl öffentlich wie auch im eigenen Haushalt vorgenommen werden
- Die öffentliche Ladeinfrastruktur gewinnt derzeit stetigen Zuwachs – und das nicht nur deutschlandweit, sondern in ganz Europa
Negativ:
- Ladevorgänge gestalten sich als äußerst zeitraubend – so benötigt ein vollständiger Ladevorgang mittels eines herkömmlichen Haushaltssteckers zwischen 8 und 12 Stunden. An sogenannten Schnellladesäulen kann die Ladedauer auf 45 Minuten reduziert werden
- Selbst hochpreisige Elektrofahrzeuge haben „nur“ eine Reichweite von ca. 400 km1
- Je mehr Elektrofahrzeuge, desto höher die Belastung des Stromnetzes
- Zwar stoßen Elektrofahrzeuge während der Nutzungsdauer keinerlei Schadstoffe aus, indirekt – während der Herstellung – jedoch schon2
- Elektrobatterien besitzen eine hohe Abhängigkeit von Lithium– und Kobalt-Ressourcen3
- Die Lebensdauer der Elektrobatterie variiert je nach Hersteller aktuell zwischen 100.000 und 200.000 km4
Wasserstoffautos
Die Funktionsweise eines mit Wasserstoff betriebenen Fahrzeugs ähnelt dem eines Elektrofahrzeugs. Der entscheidende Unterschied besteht jedoch in der vorgeschalteten Brennstoffzelle. Mittels Elektrolyse wird innerhalb dieser Brennstoffzelle Wasserstoff in elektrischen Strom umgewandelt und ausgehend davon in einen Elektromotor eingespeist.
Positiv:
- Wasserstofffahrzeuge sind emissionsfrei und stoßen keinerlei Schadstoffe aus
- Der Tankvorgang von Wasserstoff ist schnell (ca. 3 Minuten) und unkompliziert
- Ein vollständig aufgetanktes Wasserstofffahrzeug erreicht eine Reichweite von 500 km
- Die Kosten für die Wasserstoffbetankung sind vergleichbar mit dem eines konventionellen Benzin betriebenen Fahrzeugs. Die meisten Wasserstofffahrzeuge fassen circa vier bis fünf Kilogramm Wasserstoff; der Preis pro Kilogramm beträgt 9,50 €5
- Brennstoffzellen sind sehr effiziente Energiewandler
- Im Gegensatz zu Strom, kann Wasserstoff gespeichert und transportiert werden
Negativ:
- Preislich liegen Wasserstofffahrzeuge noch weit über den Elektrofahrzeugen6
- Deutschlandweit gibt es aktuell nur knapp 100 Wasserstoff Tankstellen7
- Wasserstoff muss durch energieaufwändige Verfahren hergestellt werden, daher ergibt sich ein hoher Wirkungsverlust
Mehr zu den Chancen und Risiken von Wasserstoff gibt’s hier
eFuel
Sogenannte eFuels sind synthetische Kraftstoffe, die aus Wasserstoff und Kohlenstoff hergestellt werden. Ausgangsbasis ist hierbei der sogenannte Power-to-Fuel-Prozess. Mittels – überschüssigem – Strom aus erneuerbaren Energien (daher das „e“ in eFuel), wird durch Elektrolyse Wasserstoff hergestellt. Der Wasserstoff wiederum reagiert mit aus der Luft gewaschenem CO² zu Methan, woraus in weiteren Verfahrensschritten nahezu jeder Kraftstoff hergestellt werden kann. Von E-Diesel, E-Benzin bis hin zu E-Kerosin.8
Positiv:
- eFuel betriebene Fahrzeuge sind CO² neutral, d.h. der Treibstoff verbrennt lediglich so viel CO², wie zuvor bei der Herstellung im Treibstoff gebunden wurde
- Der eFuel-Treibstoff ist beimischbar und kann in nahezu allen modernen Verbrennungsmotoren eingesetzt werden
- Die bestehende Tankstellen Infrastruktur kann für eFuel-Fahrzeuge beibehalten werden
- Wie schon beim Wasserstoff thematisiert, eignet sich auch eFuel als ideales Speichermedium von überschüssig erzeugtem Strom
Negativ:
- Das Problem der CO²-Emissionen ist durch eFuel-betriebene Fahrzeuge nicht gelöst
- Die Herstellung von eFuel ist äußerst aufwendig, daher ergibt sich auch hier ein sehr geringer Wirkungsgrad
- eFuel ist derzeit noch viel zu teuer; der Preis pro einem Liter Diesel-Äquivalent beläuft sich auf schätzungsweise 4,50 €9
Hybride Lösungen
Neben den reinen Elektro- bzw. Wasserstofffahrzeugen sind natürlich auch Mischformen eine Alternative. So genannte „Hybride“ gibt es bereits seit vielen Jahren, prominentestes Beispiel ist hierbei sicherlich der Toyota Prius. Dieser wird bereits seit 1997 in Serie gebaut und erreicht durch die Kombination aus einem benzinbetriebenen Verbrennungsmotor und zweier Elektromotoren niedrigste Verbrauchswerte. Doch es bestehen mittlerweile nicht mehr nur Hybrid-Kombination aus Elektromotor und Verbrennungsmotor, sondern auch Hybridfahrzeuge mit Elektromotor und Brennstoffzelle. Ein Beispiel hierzu ist der Mercedes-Benz GLC F-Cell. Dieser verspricht eine kombinierte Reichweite von 478 Kilometer, die sich in knapp 430 Kilometer wasserstoffbasiert und circa 50 Kilometer reinelektrisch aufteilen.10
Positiv:
- Hybride aus Brennstoffzelle und Batterie Antrieb sind emissionsfrei und stoßen keinerlei Schadstoffe aus
- Plug-In-Hybride vereinen die Vorteile von rein elektrisch betriebenen Fahrzeugen und Wasserstofffahrzeugen
- Insbesondere die gut ausgebaute urbane Elektroladesäuleninfrastruktur, kann durch den integrierten Elektromotor ausgenutzt werden, sodass kurze städtische Fahrten ohne Probleme rein elektrisch gefahren werden können
Negativ:
- Hybride Fahrzeuge liegen preislich deutlich über den Elektrofahrzeugen
- Die Problematik der schlecht ausgebauten Wasserstoff Tankstellen spielt selbstverständlich auch bei den Hybrid Fahrzeugen eine übergeordnete Rolle11
- Die Produktion von Wasserstoff ist äußerst aufwendig, daher ergibt sich auch hier ein sehr geringer Wirkungsgrad
Alternative Fahrzeugantriebe und digitale Services
Neben den gegenübergestellten mechanischen und energetischen Aspekten alternativer Antriebstechnologien, spielt die Kundenakzeptanz eine entscheidende Rolle. Ein Weg, alternative Mobilität für möglichst viele potenzielle Abnehmer attraktiv und smart zu gestalten, ist die Unterstützung durch digitale Services.
Ein Beispiel im Bereich der Elektromobilität ist hierbei der digitale Service ChargeNow, der es Elektromobilitätskunden erlaubt, Elektroladestationen schnellstmöglich aufzufinden, sich sorglos mittels einer bereitgestellten RFID-Karte an nahezu jeder Ladesäule innerhalb Europas autorisieren zu können und sich durch den Service automatisiert und sicher abrechnen zu lassen.
Die doubleSlash Net-Business GmbH ist hier bereits seit 2012 aktiv und unterstützt weiterhin in der Weiterentwicklung des ChargeNow Services.
Mehr zu dem Thema Data Driven Services gibt es hier
Fazit
Aktuell deutet vieles darauf hin, dass die rein elektrischen Fahrzeuge den Automobilmarkt dominieren werden. Diese Etablierung ist vor allem auf die Bekanntheit und den Status in der Gesellschaft, den immer weiter voranschreitenden Ladenetzausbau und das, gegenüber anderen nachhaltigen Technologien, bessere Preis-Leistungsverhältnis zu erklären. Nichtsdestotrotz bleibt die Frage des zukünftigen Antriebs spannend, denn der Umstieg von konventionellen auf alternative Antriebstechnologien wird nicht von heute auf morgen stattfinden. Dieser Prozess bedarf Zeit – Zeit, die es wiederum Wasserstoff und eFuel erlauben werden, durch Innovation und Weiterentwicklung den Vorsprung des Elektroautos zu verringern. Nicht zu vergessen bleibt hierbei als wichtigster Treiber aller alternativer Antriebstechnologien, der Ausbau der erneuerbaren Energien.
Für die Weiterentwicklung der einzelnen Teilbereiche alternativer Mobilitätsantriebe sollten zudem folgende Fragen gestellt werden:
- Wie können Batterien verbessert werden? (Speicherkapazität, Rohstoffauswahl, Sicherheit und Lebensdauer)
- Wie kann der Netzausbau noch besser vorangetrieben werden?
- Wie kann im urbanen Raum genügend Platz für öffentliche Ladesäulen geschaffen werden?
- Was passiert mit den bisherigen konventionellen Verbrennerfahrzeugen?
- Wie kann eine Infrastruktur für Wasserstoff Tankstellen aufgebaut werden?
- Wie könnten synthetische Kraftstoffe als Treibstoff etabliert werden?
Co-Autor Marc Friedrich
1 https://www.adac.de/rund-ums-fahrzeug/tests/elektromobilitaet/stromverbrauch-elektroautos-adac-test/
2 https://vm.baden-wuerttemberg.de/de/politik-zukunft/elektromobilitaet/faq-elektroauto/
3 https://vm.baden-wuerttemberg.de/de/politik-zukunft/elektromobilitaet/faq-elektroauto/
5 https://www.shell.de/energie-und-innovation/mobilitaet/wasserstoff.html
6 https://www.br.de/nachrichten/wissen/elektroauto-und-wasserstoffauto-im-vergleich,RTjXBVu/
7 https://www.br.de/nachrichten/wissen/elektroauto-und-wasserstoffauto-im-vergleich,RTjXBVu
11 https://www.br.de/nachrichten/wissen/elektroauto-und-wasserstoffauto-im-vergleich,RTjXBVu
Oerlikon Hackathon powered by doubleSlash Experten
Am Wochenende des 08.11.2019 bis 10.11.2019 hat doubleSlash eine tolle Veranstaltung als Experten begleiten dürfen: Den ersten Hackathon der Oerlikon Group in toller Atmosphäre des Oerlikon Digital Hub. Neben Workshop Räumen und sogar einem Kino ist das technische Setup exzellent und erleichterte allen Teilnehmern die Arbeit.
Hackathon? Pures Wissen in agiler Lösungskompetenz
Pragmatisch und agil in einem: Ziel ist es, innerhalb der Dauer einer Hackathon Veranstaltung gemeinsam nützliche, kreative oder unterhaltsame IT – oder Software Produkte oder –Anwendungen herzustellen und so Lösungen für bestehende Probleme zu finden.
Ein breiter Mix an talentierten Personen
Die Zielgruppe des Events war ein sehr breiter Mix an talentierten Personen: von Softwareentwicklern über Data Scientists bis hin zu Spezialisten der Industrie. Die rund 80 Teilnehmer setzten sich zusammen aus Studenten, Softwareentwicklern bis hin zu Data Scientists und Oerlikon Mitarbeiter.
Die Challenges waren in 4 Kategorien aufgeteilt: IoT, Computer Vision, Data Science und Waste Reduction – wobei die letzte Kategorie sich wohl auch in die Data Science Aufgaben einsortieren lässt. Unter diesen Kategorien gab es je bis zu zwei Challenges – in Summe 7 Challenges. Für jede Challenge konnten sich nur eine definierte Zahl Teams anmelden, um sicher zu stellen, dass alle Challenges angegangen wurden.
Fünf doubleSlash IoT und KI Experten vor Ort
Auf Anfrage von Oerlikon beschloss doubleSlash das Event als Sponsor in Form von fünf Experten zur Unterstützung der Teilnehmer zu stärken: Vincenzo Crimi, Nico Mutter, Andreas Nuber, Timo Demler und Ralf Richter. Wir gaben Hilfestellung in den Bereichen Consulting, Coding, Architektur, technischer Spezialisierung mit PTC und Microsoft Azure, aber auch im Bereich Organisation und Strukturierung. Unsere Experten standen den Teams zur Seite, indem sie sie berieten und bei der Entwicklung weiterhalfen, ohne dabei Einfluss auf den Lösungsweg zu nehmen.
Gemeinsam mit unserem Partner PTC beschlossen wir bereits zu Beginn des Hackathons, unsere gewohnte enge Zusammenarbeit für den Support an den Teams zu leisten. Neben dem Mentoring für die Teams lieferten wir zwei tolle Workshops in den Bereichen Ideation und Pitch Training. Beide Workshops wurden ein toller Erfolg und leisteten einen wertvollen Beitrag für das Gelingen des Hackathon.
Fazit
Das Engagement unserer Experten für die Teams war beachtlich und ging über die Grenzen eines normalen Arbeitstages hinaus. Alle Teilnehmerteams schätzten diesen Support spürbar, auch während der Pitches kam positives Feedback. Wir haben auch in anderen Formaten sehr positive Erfahrungen mit diesem agilen Veranstaltungsformat gemacht und sehen hier den deutlichen Mehrwert: Schwarmintelligenz in agiler Atmosphäre schafft gemeinsam innovative Lösungen zu konkreten Problemen.
Besonders stolz sind wir darauf, dass alle Teams, die von der doubleSlash Hilfe aktiv Gebrauch machten, in die Finals kamen. Besonders freuen wir uns über den Erfolg unseres doubleSlash-Studenten-Teams: Sie haben von 17 Teams einen sehr guten Platz 4 erarbeitet. Wir freuen uns auf kommende Events, die wir als doubleSlash begleiten können oder sogar selbst ausrichten werden.
