Als eine Keynote am Data Leader Day 2016 (www.dataleaderday.com) erläuterte ich den Weg einer gewöhnlichen Führungskräft hin zum Data Leader, gemäß meiner Erfahrung. Ein Data Leader ist eine Führungskraft mit datengetriebener, problemlösungsorientierter Denkweise.
Die Präsentation findet sich nachfolgend eingebettet und zeigt die Route von der konventionellen Führungskraft zum innovativen Data Leader:
Dr. Dirk Hecker ist Geschäftsführer der »Fraunhofer-Allianz Big Data«, einem Verbund von 28 Fraunhofer-Instituten zur branchenübergreifenden Forschung und Technologieentwicklung im Bereich Big Data. Außerdem leitet Dr. Hecker die Abteilung »Knowledge Discovery« am Fraunhofer-Institut für Intelligente Analyse- und Informationssysteme IAIS. Die Forschungsschwerpunkte der Abteilung liegen im Data Mining und Machine Learning. Darüber hinaus verantwortet Dr. Hecker das Data-Scientist-Qualifizierungsprogramm bei Fraunhofer und leitet die Arbeitsgruppe »Smart Cities« im »Smart Data Innovation Lab«. Herr Hecker ist in Mitglied der »Networked European Software and Services Initiative (NESSI)« und hat langjährige Erfahrung in der Leitung von Forschungs- und Industrieprojekten. Seine aktuellen Arbeitsschwerpunkte liegen in den Bereichen Big Data Analytics, Predictive Analytics und Deep Learning.
Data Science Blog: Herr Dr. Hecker, welcher Weg hat Sie zu Fraunhofer geführt und wie treiben Sie Data Science bei Fraunhofer voran?
Ich habe bereits als Student bei Fraunhofer angefangen und nach Abschluss meines Studiums schnell die Leitung einer Arbeitsgruppe übertragen bekommen. Unser Schwerpunkt war damals das Thema Mobility Mining, die automatisierte Extraktion von Mustern aus GPS, Mobilfunkdaten sowie Induktionsschleifenmessungen, vor allem zur Verkehrsmodellierung. Als uns 2012 die Big-Data-Welle erreichte und ich die Abteilung „Knowledge Discovery“ übernahm, haben wir die erste Potenzialanalyse für Big Data in Deutschland veröffentlicht und es fiel der Startschuss für unser Data-Science-Schulungsprogramm, da wir das Unterstützungspotenzial für Unternehmen im Bereich Data Science sofort erkannt haben. Mit der Gründung der Fraunhofer-Allianz Big Data vor jetzt fast drei Jahren konnten wir unser Angebot „Beratung, Technologie, Schulung“ branchenübergreifend ausbauen. Ein Beispiel ist der „Big Data Business Club“, eine exklusive Plattform für Chief Digital oder Data Officers (CDOs) in Unternehmen. Wir beraten und unterstützen Unternehmen branchenübergreifend bei der Umsetzung ihrer Big-Data-Projekte und entwickeln die passenden Tools und Softwareprodukte.
Data Science Blog: Könnten Unternehmen die Projekte nicht einfach in den jeweiligen Fachbereichen direkt selbst umsetzen? Oder in der zentralen Unternehmens-IT-Abteilung?
Für die Datenanalyse braucht man Experten, also Data Scientists. Die gibt es in vielen Fachabteilungen zunächst nicht, und oft auch noch nicht in der zentralen IT. Da ist es ein guter Weg, die Kompetenzen beim eigenen Personal in Kooperationsprojekten mit erfahrenen Partnern aufzubauen.
Data Science Blog: Sie bieten bei Fraunhofer ein sogenanntes „Data Science Starter Toolkit“ an, wofür brauchen Unternehmen ein weiteres Toolkit?
Bevor sie in eine Big-Data-Plattform investieren und sich damit längerfristig binden, können Unternehmen in diesem Toolkit eine breite Palette aktueller Big Data- und In-Memory-Technologien erproben und sich hier beraten lassen. Außerdem erleichtert das Toolkit die nicht-kommerzielle Kooperation mit akademischen Partnern. Das ist besonders in der Anfangsphase interessant, wenn überhaupt erst das Potenzial in den eigenen Daten exploriert werden soll.
Data Science Blog: Sie bearbeiten Anwendungsfälle unterschiedlicher Branchen. Können sich Branchen die Anwendungsfälle gegenseitig abschauen oder sollte jede Branche auf sich selbst fokussiert bleiben?
Gute Branchenkenntnis ist für uns unerlässlich, denn jede Branche hat ihre Besonderheiten, etwa was die Prozesse oder auch die Datenquellen anbelangt. Dennoch können sich Unternehmen an Best-Practice-Beispielen aus anderen Branchen orientieren. Darum arbeiten wir auch in der Fraunhofer-Allianz Big Data instituts- und branchenübergreifend zusammen. Unsere Kunden schätzen es gerade in der Bratungs- und Ideenfindungsphase, wenn sie über den Tellerrand schauen können und Beispiele aus anderen Branchen vorgestellt bekommen. Außerdem lassen sich externe Datenquellen in verschiedenen Branchen nutzen: Social Media, Mobilfunkdaten, Wikipedia, Nachrichtenkanäle. Schließlich erwarten wir im Bereich des Deep Learning, dass man bild-, sprach- und textverarbeitende Module in Zukunft vortrainieren und dann mit weniger Aufwand auf die Anwendung spezialisieren kann.
Data Science Blog: Welche Trends im Bereich Machine Learning bzw. Deep Learning werden Ihrer Meinung nach im kommenden Jahr 2017 von Bedeutung sein?
Schon heute ist das maschinelle Lernen die Schlüsseltechnik für die Echtzeitanalyse von Big Data, also die Überwachung und Automatisierung von Prozessen jeglicher Art. Deep Learning erschließt aktuell insbesondere unstrukturierte Datenmengen, also die bekannte Dimension „Variety“. Die Technik rund um Deep Learning ist aktuell verantwortlich für die jüngsten Erfolge im Bereich der Künstlichen Intelligenz: maschinelles Sehen, Text- und Sprachverstehen, Text- und Sprachproduktion, maschinelle Übersetzung. Damit werden zunehmend intelligente Geräte gebaut und Systeme entwickelt, die uns einerseits Routine-Sacharbeiten und -Entscheidungen abnehmen und uns andererseits als Assistenten begleiten und beraten. In Zukunft werden wir immer weniger auf graphische Benutzeroberflächen angewiesen sein, sondern sprechen oder chatten mit smarten Geräten, Umgebungen und Assistenzsystemen.
Data Science Blog: Es heißt, dass Data Scientists gerade an ihrer eigenen Arbeitslosigkeit arbeiten, da zukünftige Verfahren des maschinellen Lernens Data Mining selbstständig durchführen können. Werden die Tools Data Scientists bald ersetzen?
Auf keinen Fall. In industriellen Datenanalyseprojekten gehen ja bis zu 80% des Aufwands in die Erarbeitung der Aufgabenstellung, in Datenexploration und -vorverarbeitung. Und die Digitalisierung und das Internet der Dinge werden uns noch auf viele Jahre hinaus mit neuen Fragestellungen versorgen. Methoden des Reinforcement-Lernens, die Feedback nutzen, um selbstständig weiter zu lernen, sind Gegenstand aktiver Forschung. Praktisch stellt sich da auch die Frage, wie Reaktionen der Umwelt überhaupt als Feedback zu interpretieren sind. Und schließlich stellt sich das Problem der Haftung. In einigen Anwendungsbereichen werden wir selbstlernende Systeme vorerst ausschließen, bis sichergestellt werden kann, dass sie sich kein unerwünschtes Verhalten aneignen. Solche Systeme zu bauen wird eine neue Kompetenz von Data Scientists sein.
Data Science Blog: Sollten Unternehmen erfahrene Data Scientists direkt einkaufen? Oder gibt es auch realistische Möglichkeiten, diese einfach selbst auszubilden?
Wir arbeiten mit etlichen Unternehmen zusammen, die ihren Mitarbeitern eine Fortbildung finanzieren, sei es durch ein berufsbegleitendes Studium, sei es durch Kompaktkurse. Die Fraunhofer-Allianz Big Data bietet zum Beispiel ein umfassendes, kompaktes Schulungsprogramm mit Zertifizierung an. Zudem sind Auftragsprojekte eine gute Gelegenheit, das erlernte Wissen praktisch zu vertiefen. Datenanalyseprojekte sind ja von Natur aus agil und erfordern eine enge Zusammenarbeit. Da ist es leicht, die anstehenden Arbeiten wöchentlich zwischen eigenen Mitarbeitern und externen Experten aufzuteilen. So arbeiten wir bereits mit einigen Unternehmen erfolgreich zusammen, teilweise sind die Fachkräfte sogar bei uns vor Ort oder wir unterstützen sie direkt im Unternehmen.
Data Science Blog: Sind gute Data Scientists Ihrer Erfahrung nach tendenziell eher Beratertypen oder introvertierte Nerds?
Data Scientists, die angefangen beim Geschäft und der Anwendungsdisziplin über die Big-Data-Tools bis zu statistischer Analyse und maschinellen Lernen alles selbst beherrschen, finden Sie selten und dann können Sie die Experten vielleicht nicht bezahlen. Allein schon deshalb arbeiten Data Scientists in Teams und bündeln unterschiedliche Kompetenzen und auch Charaktere. Kommunikative Fähigkeiten sind dabei unabdingbar.
Data Science Blog: Für alle Studenten, die demnächst ihren Bachelor, beispielsweise in Informatik, Mathematik oder Wirtschaftswissenschaften abgeschlossen haben, was würden Sie diesen jungen Damen und Herren raten, wie sie gute Data Scientists werden können?
Praxis und Neugier. In jedem Datenanalyseprojekt lernt man dazu – durch die Daten und durch die Zusammenarbeit mit den Kolleginnen und Kollegen. Darum würde ich nach einer Beschäftigung suchen, die immer neue Herausforderungen verspricht. Außerdem richten sich die Gehälter insbesondere nach den fortschrittlichen Tools, die man beherrscht – im Augenblick Spark und Python. Es ist also wichtig, den Blick auf technologische Entwicklungen nicht zu verlieren.
Anmerkung der Redaktion: Das Fortbildungsprogramm der Fraunhofer Acadamy zum Thema Data Science / Big Data ist im Aus- und Fortbildungskatalog enthalten.
Dieser Artikel ist Teil 1 von 2 aus der Artikelserie R Data Frames meistern mit dplyr.
Data Frames sind das Arbeitspferd von R, wenn Daten in eine Struktur gepackt werden sollen, um sie einzulesen, zu säubern, zu transformieren, zu analysieren und zu visualisieren. Abstrakt gesprochen sind Data Frames nichts anderes als Relationen, also Mengen von Tupels, gebildet aus Elementen von geeigneten Mengen.
Dieses Konzept hat sich auch außerhalb des R-Universums bestens bewährt, umzusammengesetzte Daten, Beobachtungen oder Geschäftsobjekte zu repräsentieren. Der beste Beleg für diese Aussage sind die allgegenwärtigen Relationalen Datenbanksysteme (RDBMS). Dort werden Relationen als Tabellen (Tables) oder Sichten (Views) bezeichnet, und darauf wirkt eine mächtige, imperative Abfrage- und Manipulationssprache namens Structured Query Language, kurz:
SQL.
SQL ist in meiner Wahrnehmung die Lingua Franca der Datenverarbeitung, da sie im Kern über sehr viele Softwareprodukte gleich ist und nach erstaunlich geringem Lernaufwand mächtige Auswerte- und Manipulationsoperationen an den Daten ermöglicht. Hier eine SQL-Anweisung, um eine fiktive Tabelle aller Verkäufe (SALES) nach den Top-10-Kunden in diesem Jahr zu untersuchen:
SELECT customer_id, SUM(sales_amt) AS amount, COUNT(*) AS n_sales, COUNT(DISTINCT product_id) AS n_products FROM sales WHERE sales_date LIKE ’2016-%’ GROUP BY customer_id ORDER BY SUM(sales_amt) DESC LIMIT 10
Dieser selbsterklärliche Code aus sieben Zeilen hat einen enormen Effekt: Er fast alle Verkäufe des Jahres 2016 auf Basis der Kundennummer zusammen, berechnet dabei die Summe aller Verkaufsbeträge, zählt die Anzahl der Transaktionen und der verschiedenen vom Kunden gekauften Produkte. Nach Sortierung gemäß absteigenden Umsatzes schneidet der Code nach dem 10. Kunden ab.
SQL kann aber mit der gleichen Eleganz noch viel mehr: Beispielsweise verbinden Joins die Daten mehrerer Tabellen über Fremschlüsselbeziehungen oder analytische Funktionen bestimmen Rankings und laufende Summen. Wäre es nicht toll, wenn R ähnlich effektiv mit Data Frames analoger Struktur umgehen könnte? Natürlich! Aber schon der Versuch, obige SQL-Query auf einem R Data Frame mit den althergebrachten Bordmitteln umzusetzen (subset, aggregate, merge, …), führt zu einem unleserlichen, uneleganten Stück Code.
Genau in diese Bresche springt der von vielen anderen Bibliotheken bekannte Entwickler Hadley Wickham mit seiner Bibliothek dplyr: Sie standardisiert Operationen auf Data Frames analog zu SQL-Operationen und führt zu einer wirklich selbsterklärlichen Syntax, die noch dazu sehr performant abgearbeitet wird. Ganz analog zu ggplot2, das sich an der Grammar of Graphics orientiert, spricht Wickham bei dplyr von einer Grammar of Data Manipulation. Die Funktionen zur Manipulation nennt er folgerichtig Verben.
Dabei treten naturgemäß eine Reihe von Analogien zwischen den Teilen eines SELECT-Statements und dplyr-Funktionen auf:
| SELECT-Operation | dplyr-Funktion |
| Bildung der Spaltenliste | select() |
| Bildung eines Ausdrucks | mutate() |
| WHERE-Klausel | filter() |
| GROUP BY Spaltenliste | group_by() |
| Bildung von Aggregaten wie sum() etc. | summarise() |
| HAVING-Klausel | filter() |
| ORDER BY Spaltenliste | arrange() |
| LIMIT-Klausel | slice() |
Ich möchte die Anwendung von dplyr mithilfe des Standard-Datensatzes Cars93
aus dem Paket MASS demonstrieren:
> install.packages("dplyr")
> library(dplyr)
> cars <- MASS::Cars93
> str(cars)
’data.frame’: 93 obs. of 27 variables:
$ Manufacturer : Factor w/ 32 levels "Acura","Audi",..: 1 1 2 2 3 ...
$ Model : Factor w/ 93 levels "100","190E","240",..: 49 56 ...
Die erste Aufgabe soll darin bestehen, aus dem Data Frame alle Autos zu selektieren, die vom Hersteller “Audi” stammen und nur Model und Anzahl Passagiere auszugeben. Hier die Lösung in Standard-R und mit dplyr:
> # Standard R: Zu allen Audis das Model, Anzahl Insassen
> subset(cars,Manufacturer=="Audi")[,c("Model","Passengers")]
Model Passengers
3 90 5
4 100 6
>
> # Das gleiche mit dplyr
> select(filter(cars,Manufacturer=="Audi"),Model,Passengers)
Model Passengers
1 90 5
2 100 6
Man sieht, dass die neue Funktion filter() der Zeilenselektion, also der Funktion subset() entspricht. Und die Auswahl der Ergebnisspalten, die in Standard-R durch Angabe einer Spaltenliste zwischen [ und ] erfolgt, hat in dplyr das Pendant in der Funktion select().
select() ist sehr mächtig in seinen Möglichkeiten, die Spaltenliste anzugeben. Beispielsweise funktioniert dies über Positionslisten, Namensmuster und ggf. das auch noch negiert:
select(cars, -starts_with("L"))
Die obige Abfrage projiziert aus dem Data Frame sämtliche Spalten, die nicht mit “L” beginnen. Das scheint zunächst ein unscheinbares Feature zu sein, zahlt sich aber aus, wenn analytische Data Frames Dutzende oder Hunderte von Spalten haben, deren Bezeichnung sich nach einem logischen Namensschema richtet.
Soweit ist das noch nicht spektakulär. dplyr hilft uns in obigem Beispiel, als erstes bestimmte Datensätze zu selektieren und als zweites die interessierenden Spalten zu projizieren. dplyr ist aber bezüglich der Verarbeitung von Data Frames sehr intuitiv und funktional, sodass wir früher oder später viele Operationen auf unserem Data Frame verketten werden. So erreichen wir die Mächtigkeit von SQL und mehr. Die funktionale Syntax aus dem letzten Beispiel wird dann ganz schnell unleserlich, da die Verabeitungsreihenfolge (zuerst filter(), dann select()) nur durch Lesen des Codes von innen nach außen und von rechts nach links ersichtlich wird.
Daher geht dplyr einen Schritt weiter, indem es den eleganten Verkettungsoperator %>% aus dem magrittr-Paket importiert und zur Verfügung stellt. Dadurch werden die verschachtelten Ausdrücke in Sequenzen von Operationen gewandelt und somit sehr viel lesbarer und wartbarer:
select(filter(cars,Manufacturer=="Audi"),Model,Passengers) Model Passengers 1 90 5 2 100 6 > cars %>% + filter(Manufacturer=="Audi") %>% + select(Model,Passengers) Model Passengers 1 90 5 2 100 6
Diese in meinen Augen geniale Syntax durch den neuen Operator %>% erlaubt einen sequenziellen Aufbau der Operationen auf einem Data Frame. Benutzer der Unix-Kommandozeile werden hier leicht die Analogie zu Pipes erkennen. Ganz abstrakt kann man sagen, dass damit folgende Operationen äquivalent sind:
| Traditioneller Funktionsaufruf | Verkettung mit %>% |
| f(a,b) | a %>% f(b) |
| f(a,b,c) | a %>% f(b,c) |
| g(f(a,b),c) | a %>% f(b) %>% g(c) |
Weiteres erklärt die Dokumentation zum %>%-Operator im Paket magrittr mithilfe
des Befehls ?magrittr::‘%>%‘.
Durch die Funtionen select() und filter() können wir aus Data Frames Spalten projizieren und Zeilen selektieren. Ergebnisse neuer Ausdrücke entstehen hingegen mit dem Verb mutate():
> # Mit Umrechnung der Mileage in Verbrauch und des > # Kaufpreises von USD in EUR > cars2 <- + cars %>% + filter(Manufacturer=="Audi") %>% + mutate(l_100km = 235 / MPG.city, + eur = Min.Price * 1000 / 1.1) %>% + select(Model,Passengers,l_100km,eur) > cars2 Model Passengers l_100km eur 1 90 5 11.75000 23545.45 2 100 6 12.36842 28000.00 > class(cars2) [1] "data.frame"
Im obigen Beispiel wird zunächst auf den Hersteller Audi selektiert und danach auf einen Streich zwei neue Spalten eingeführt, l_100km und eur. Durch Zuweisen auf eine neue Variable wird das fertige Ergebnis dauerhaft gespeichert. Hierbei handelt es sich wieder um ein natives Data Frame-Objekt. Die Operation transmute() arbeitet analog zu mutate(), verwirft aber nach Bildung der Ausdrücke alle nicht genannten Spalten. Somit können wir obiges Beispiel auch wie folgt schreiben:
cars3 <- + cars %>% + filter(Manufacturer=="Audi") %>% + transmute(Model = Model, Passengers = Passengers, + l_100km = 235 / MPG.city, + eur = Min.Price * 1000 / 1.1) cars3 Model Passengers l_100km eur 1 90 5 11.75000 23545.45 2 100 6 12.36842 28000.00
Neben der Selektion von Zeilen und Spalten sowie der Bildung abgeleiteter Ausdrücke ist bei Datenbanktabellen die Gruppierung und Aggregation mit GROUP BY eine sehr wichtige Operation. Dies gilt auch für Data Frames in R, wenngleich hier der Funktionsumfang über diverse Funktionen wie table() oder aggregate() verteilt ist und wenig intuitiv ist.
Hier bringt dplyr ebenfalls eine großartige Verbesserung mit. Das entsprechende Verb heißt group_by(). Diese Operation wird zusammen mit einer Spaltenliste auf ein Data Frame angewendet:
grp_cars <- cars %>% group_by(Manufacturer) > class(grp_cars) [1] "grouped_df" "tbl_df" "tbl" "data.frame"
Das Ergebnis von group_by() ist ein Objekt, das “mehr” ist als ein Data Frame, sondern auch noch einige spezifische Strukturinformationen von dplyr enthält. In unserem Beispiel sind dies Indizes von Zeilen, die zum gleichen Hersteller gehören. Das ursprüngliche Data Frame wird hierbei nicht kopiert, sondern nur eingebettet.
Nach Anwenden einer group_by()-Operation ist das Data Frame optimal vorbereitet für die eigentliche Aggregation mit summarise():
> sum_cars <- cars %>% + group_by(Manufacturer) %>% + summarise(nCars = n(), avg_price = mean(Min.Price)) > str(sum_cars) Classes ‘tbl_df’, ‘tbl’ and ’data.frame’: 32 obs. of 3 variables: $ Manufacturer: Factor w/ 32 levels "Acura","Audi",..: 1 2 3 4 5 6 7 8 9 10 ... $ nCars : int 2 2 1 4 2 8 1 2 6 2 ... $ avg_price : num 21.1 28.4 23.7 20.8 35.2 ...
Das Resultat von summarise() ist wieder ein Data Frame, das neben den ursprünglichen Gruppierungskriterien nur noch die Aggregate enthält.
Zwischen Relationalen Datenbanken und R-Data Frames besteht ein wesentlicher konzeptioneller Unterschied: Die Ergebnisse eines SELECT-Befehls haben keine definierte Reihenfolge, so lange die Zeilen nicht mit der Klausel ORDER BY festgelegt wird. Im Gegensatz dazu haben die Zeilen von Data Frames eine konstante Reihenfolge, die sich aus der Anordnung derWerte in den Spaltenvektoren ergibt.
Dennoch ist es manchmal wünschenswert, Data Frames umzusortieren, um eine fachliche Reihenfolge abzubilden. Hierzu dient in dplyr das Verb arrange(), das im Standard-R weitgehend der Indizierung eines Data Frames mit Ergebnissen der order()-Funktion entspricht, aber syntaktisch eleganter ist:
cars %>% + arrange(desc(Horsepower),Manufacturer) %>% + select(Manufacturer, Model, Horsepower,Min.Price) %>% + slice(1:5) Manufacturer Model Horsepower Min.Price 1 Chevrolet Corvette 300 34.6 2 Dodge Stealth 300 18.5 3 Cadillac Seville 295 37.5 4 Infiniti Q45 278 45.4 5 Mazda RX-7 255 32.5
Dieses Beispiel hat zum Ziel, die fünf PS-stärksten Autos zu selektieren. Die arrange()-Funktion sortiert hier zunächst absteigend nach der PS-Stärke, dann aufsteigend nach Herstellername. Die Selektion der 5 ersten Zeilen erfolgt mit der hilfreichen Funktion slice(), die aus einem Data Frame Zeilen anhand ihrer Reihenfolge selektiert.
Mit dplyr wird die Arbeit mit Data Frames stark verbessert: Im Vergleich zu “nacktem” R bringt das Paket eine klarere Syntax, abgerundete Funktionalität und bessere Performance. In der Kürze dieses Artikels konnte ich dies nur oberflächlich anreissen. Daher verweise ich auf die vielen Hilfe-Seiten, Vignetten und Internet-Videos zum Paket. Im zweiten Teil dieses Artikels werde ich auf einige fortgeschrittene Features von dplyr eingehen, z.B. die Verknüpfung von Data Frames mit Joins, die Window-Funktionen und die Verwendung von Datenbanken als Backend.
Weiter zu R Data Frames meistern mit dplyr – Teil 2.
Frau Dr. Eva-Marie Müller-Stüler ist Associate Director in Decision Science der KPMG LLP in London. Sie absolvierte zur Diplom-Mathematikerin an der Technischen Universität München, mit einem einjährigen Auslandssemester in Tokyo, und promovierte an der Philipp Universität in Marburg.
Read this article in English:
“Interview – Using Decision Science to forecast customer behaviour”
Data Science Blog: Frau Dr. Müller-Stüler, welcher Weg hat Sie bis an die Analytics-Spitze der KPMG geführt?
Ich hatte schon immer viel Spaß an analytischen Fragestellungen, aber auch ein großes Interesse an Menschen und Finance. Die Frage wie Menschen ticken und Entscheidungen treffen finde ich unglaublich spannend. Im Mathematikstudium und auch bei der Doktorarbeit kamen dann das Auswerten von großen Datenmengen und das Programmieren von Algorithmen hinzu. Die solide mathematische Ausbildung kombiniert mit dem spezifischen Branchen- und Finanzverständnis ermöglicht es mir das Geschäftsmodell meiner Kunden zu verstehen und Methoden zu entwickeln, die den Markt verändern und neue Wege finden.
Data Science Blog: Welche Analysen führen Sie für Ihre Kundenaufträge durch? Welche Vorteile generieren Sie für Ihre Kunden?
Unser Team beschäftigt sich hauptsächlich mit Behaviour und Customer Science. Daher auch der Slogan „We understand human behaviour and we change it“. Unser Focus ist der Mensch (z.B. Kunde oder der Mitarbeiter) und die Frage, wie wir ihn durch das Verständnis seiner Datenartefakte im Verhalten ändern bzw. zukünftiges Verhalten vorhersagen können. Auf dieser Basis entwickeln wir Always-on forecasting Modelle, die es dem Mandanten ermöglichen, bereits im Vorfeld zu agieren. Das kann z.B. bedeuten, durch ortgenaue Informationen spezifische Kundennachfrage an einem bestimmten Standort vorherzusagen, wie sie verbessert oder in die gewünschte Richtung beeinflusst werden kann oder durch welche Maßnahmen bzw. Promotions welcher Kundentyp optimal erreicht wird. Oder auch die Frage wo und mit welcher Produktmischung am besten ein neues Geschäft eröffnet werden soll, ist mit Predictive Analytics viel genauer vorherzusagen als durch herkömmliche Methoden.
Data Science Blog: Welche Voraussetzungen müssen erfüllt sein, damit prädiktive Analysen für Kundenverhalten adäquat funktionieren?
Die Daten müssen natürlich eine gewisse Qualität und Historie haben um z. B. auch Trends und Zyklen zu erkennen. Oft kann man sich aber auch über die Einbindung neuer Datenquellen einen Vorteil erschaffen. Dabei ist Erfahrung und Kreativität enorm wichtig, um zu verstehen was möglich ist und die Qualität verbessert oder ob etwas nur für mehr Rauschen sorgt.
Data Science Blog: Welche externen Datenquellen müssen Sie dafür einbinden? Wie behandeln Sie unstrukturierte Daten?
Hier in England ist man – was externe Datenquellen angeht – schon sehr verwöhnt. Wir benutzen im Schnitt an die 10.000 verschiedene Signale, die je nach Fragestellung unterschiedlich seien können: z. B. die Zusammensetzung der Bevölkerung, Nahverkehrsinformationen, die Nähe von Sehenswürdigkeiten, Krankenhäusern, Schulen, Kriminalitätsraten und vieles mehr. Der Einfluss eines Signals ist bei jedem Problem unterschiedlich. So kann eine hohe Anzahl an Taschendiebstählen ein Zeichen dafür sein, dass in der Gegend viel los ist und die Menschen im Schnitt viel Bargeld bei sich tragen. Das kann z. B. für einen Fast Food-Retailer in der Innenstadt durchaus einen positiven Einfluss auf sein Geschäft haben in einer anderen Gegend aber das Gegenteil bedeuten.
Data Science Blog: Welche Möglichkeiten bietet Data Science für die Forensik bzw. zur Betrugserkennung?
Da jeden Kunden tausende Datensignale umgeben und er durch sein Verhalten weitere produziert und aussendet, kann man gerade beim Online-Geschäft schon ein ziemlich gutes Bild über die Person bekommen. Jede Art von Mensch hat ein gewisses Verhaltensmuster und das gilt auch für Betrüger. Diese Muster muss man nur rechtzeitig erkennen oder vorherzusagen lernen.
Data Science Blog: Welche Tools verwenden Sie bei Ihrer Arbeit? In welchen Fällen setzten Sie auf proprietäre Software, wann hingegen auf Open Source?
Das hängt vom Arbeitsschritt und dem definierten Ziel ab. Wir unterscheiden unser Team in unterschiedliche Gruppen: Unsere Data Wrangler (die für das Extrahieren, Erzeugen und Aufbereiten der Daten zuständig sind) arbeiten mit anderen Tools als z. B. unsere Data Modeller. Im Grunde umfasst es die gesamte Palette von SQL Server, R, Python, manchmal aber auch Matlab oder SAS. Immer häufiger arbeiten wir auch mit auf Cloud-Technologie basierenden Lösungen. Data Visualisation und Dashboards in Qlik, Tableau oder Alteryx geben wir in der Regel jedoch an andere Teams weiter.
Data Science Blog: Wie sieht Ihrer Erfahrung nach der Arbeitsalltag als Data Scientist nach dem morgendlichen Café bis zum Feierabend aus?
Meine Rolle ist vielleicht am besten zu beschreiben als der Player-Coach. Da läuft von allem etwas mit ein. Am Anfang eines Projektes geht es vor Allem darum, mit den Mandaten die Fragestellung zu erarbeiten und das Projekt zu gewinnen. Teil dessen ist auch neue Ideen und Methoden zu entwickeln. Während eines Projektes sind das Team Management, der Wissenstransfer im Team, der Review und das Hinterfragen der Modelle meine Hauptaufgaben. Am Schluss kommt dann der endgültige Sign-off des Projektes. Da ich oft mehrere Projekte in unterschiedlichen Stadien gleichzeitig leite, wird es garantiert nie langweilig.
Data Science Blog: Sind gute Data Scientists Ihrer Erfahrung nach tendenziell eher Beratertypen oder introvertierte Nerds?
Das hängt so ein bisschen davon ab wo man seinen Schwerpunkt sieht. Als Data Visualizer oder Data Artist geht es darum die Informationen auf das wesentlich zu reduzieren und toll und verständlich darzustellen. Dafür braucht man Kreativität und ein gutes Verständnis für das Geschäft und einen sicheren Umgang mit den Tools.
Der Data Analyst beschäftigt sich vor Allem mit dem „Slice and Dice“ von Data. Ziel ist es, die Vergangenheit zu analysieren und Zusammenhänge zu erkennen. Es ist wichtig zusätzlich zu dem finanziellen Wissen auch gute mathematische Fähigkeiten zu haben.
Der Data Scientist ist der mathematischste von allen. Er beschäftigt sich damit aus den Daten tiefere Zusammenhänge zu erkennen und Vorhersagen zu treffen. Dabei geht es um die Entwicklung von komplizierten Modellen oder auch Machine Learning Algorithmen. Ohne eine gute mathematische Ausbildung und Programmierkenntnisse ist es leider nicht möglich die Sachen in voller Tiefe zu verstehen. Die Gefahr falsche Schlüsse zu ziehen oder Korrelationen zu interpretieren, die sich aber nicht bedingen ist sehr groß. Ein einfaches Beispiel hierfür ist, dass im Sommer, wenn das Wetter schön ist, mehr Menschen Eis essen und in Seen baden gehen. Daher lässt sich eine eindeutige Korrelation zwischen Eis essen und der Anzahl an Ertrunkenen zeigen, obwohl nicht das Eis essen zum Ertrinken führt sondern die beeinflussende Variable die Temperatur ist. Daher ist ein Doktor in einem mathematiknahen Fach schon wichtig.
Genauso ist aber für den Data Scientist auch das entsprechende Finanz- und Branchenwissen wichtig, denn seine Erkenntnisse und Lösung müssen relevant für den Kunden sein und deren Probleme lösen oder Prozesse verbessern. Die tollste AI Maschine bringt keiner Bank einen Wettbewerbsvorteil, wenn sie den Eisverkauf auf Basis des Wetters vorhersagt. Das kann zwar rechnerisch 100% richtig sein, hat aber keine Relevanz für den Kunden.
Es ist im Grunde wie in anderen Bereichen (z. B. der Medizin) auch. Es gibt viele verschiedene Schwerpunkte und für ernsthafte Probleme wendet man sich am besten an einen Spezialisten, damit man keine falschen Schlüsse zieht.
Data Science Blog: Für alle Studenten, die demnächst ihren Bachelor, beispielsweise in Informatik, Mathematik oder Wirtschaftslehre, abgeschlossen haben, was würden sie diesen jungen Damen und Herren raten, wie sie gute Data Scientists werden können?
Nie aufhören mit dem Lernen! Der Markt entwickelt sich derzeit unglaublich schnell und hat so viele tolle Seiten. Man sollte einfach mit Leidenschaft, Begeisterung und Kreativität dabei sein und Spaß an der Erkennung von Mustern und Zusammenhängen haben. Wenn man sich dann noch mit interessanten und inspirierenden Menschen umgibt, von denen man noch mehr lernen kann, bin ich zuversichtlich, dass man eine tolle Arbeitszeit haben wird.
Thomas Otzasek ist Head of Data Science bei der Smarter Ecommerce GmbH in Linz, ein Unternehmen für die Automatisierung des professionellen Suchmaschinen Marketings. Herr Otzasek leitet das Data Science Team zur Automatisierung von operativen Prozessen im Suchmaschinen Marketing mit Machine Learning. Weitere interessante Blogposts von Thomas Otzasek zum Thema Suchmaschinen Marketing und Data Science finden Sie im Whoop! Blog.
Data Science Blog: Herr Otzasek, welcher Weg hat Sie zum Data Science für das Suchmaschinen Marketing geführt?
Ich war schon immer an Zahlen interessiert und begann daher im Jahr 2002 ein Masterstudium der Statistik an der Johannes Kepler Universität in Linz. Im Jahr 2006 wurde an dieser Uni dann erstmalig der Studiengang Bioinformatik mit Schwerpunkt Machine Learning angeboten, der mich ebenfalls angesprochen hat. Im Jahr 2009 habe ich beide Masterstudien erfolgreich abgeschlossen.
Nachdem ich in diversen Branchen u.a. als Business Analyst oder Software-Entwickler gearbeitet habe, überzeugte mich im Jahr 2015 die Firma Smarter Ecommerce mit einer innovativen Produktidee, für die ich den fehlenden Data Science Puzzleteil ideal ausfüllen konnte. Seitdem sind wir auf Wachstumskurs und konnten unsere Mitarbeiterzahl innerhalb von 15 Monaten auf derzeit 85 Mitarbeiter mehr als verdoppeln.
Data Science Blog: Welche Bedeutung hat Big Data und Data Science für Ihre Branche?
Im Suchmaschinen Marketing gibt es sehr viel manuelle Arbeit. Mit dem Einsatz von Data Science können wir diese manuelle Arbeit unterstützen oder automatisieren. Ist das Produktsortiment entsprechend groß, können wir die Platzierung in Online-Anzeigen soweit optimieren, wie es selbst dem besten Mitarbeiter ohne entsprechende Tools niemals möglich wäre.
Wir übernehmen das Aussteuern von Google Shopping, für welche Produkte wo genau Anzeigen zu welchen Konditionen geschaltet werden. Wir haben dafür Machine Learning Modelle entwickelt, die diese Anzeigenschaltung optimieren. Der dafür von meinem Data Science Team entwickelte Prototyp ist seit über einem Jahr produktiv im Einsatz.
Data Science Blog: Was optimieren diese Algorithmen des maschinellen Lernens?
Der vollautomatisierte Ansatz kommt bei unserem Produkt Whoop! für Google Shopping zum Einsatz. Google Shopping ist ein Teil von Google AdWords. Wir verwenden den Produkt-Datenfeed des Kunden, die Performance-Historie von Google AdWords, unsere jahrelange Google Shopping Erfahrung sowie die Ziele des Kunden bezüglich der Anzeigen um z. B. die Kosten-Umsatz-Relation oder die Kosten pro Akquisition zu optimieren.
Die Herausforderung ist, das richtige Gebot für das jeweilige Produkt zu wählen. Wenn Sie eine ganze Reihe von verschiedenen oder auch ähnlichen Produkten haben (z. B. verschiedene Farben oder Größen), müssen wir diese Gebote so tunen, dass die Reichweite und Zielgruppe ideal ist, ohne dass die Kosten explodieren.
Wird ein Produkt zu hoch geboten, sind nicht nur die Kosten für das bewerbende Unternehmen zu hoch, auch die Platzierung ist dann meistens nicht optimal. Google, unser Anzeigenpartner, verallgemeinert die Suchanfragen im hochpreisigen Segment tendenziell zu sehr, darunter leidet dann die Relevanz. Wird für die Anzeige zu niedrig geboten, wird sie hingegen gar nicht erst angezeigt. Neben der Conversion Rate spielt für unsere Kunden hauptsächlich die Kosten-Umsatz-Relation eine Rolle. Ein Mitarbeiter im Online Marketing könnte diese Optimierung für mehr als eine Hand voll Produkte nicht vornehmen. Denken Sie z. B. an die Mode-Branche, die ein sich schnell umschlagendes Produktsortiment mit vielen Produkten hat.
Data Science Blog: Welche datenwissenschaftlichen Herausforderungen spielen dabei eine Rolle?
Die Produktdaten sind sehr umfangreich, der Anzeigenmarkt und die Produkttrends extrem dynamisch. Außerdem gibt es für viele Produkte nur wenige Klicks, so dass wir ausgeklügelte Algorithmen brauchen, um trotzdem statistisch valide Aussagen treffen zu können.
Für die manuelle Aussteuerung ist die Produktanzahl meist zu groß um produktgenaue Gebote abgeben zu können. Bei einem großen und/oder schnell umschlagenden Produktsortiment haben wir es mit komplexen Strukturen zu tun, die wir in diesen Modellen berücksichtigen müssen, um stets die optimalen Gebote zu setzen.
Das Modell muss dabei jederzeit berücksichtigen, welche Produkte bzw. Anzeigen performen bzw. nicht performen, um jene entsprechend hoch- oder runter zu regeln. Eine einfache Regressionsanalyse reicht da nicht aus. Auch Änderungen des Kunden in den Einstellungen sowie externe Faktoren wie z. B. das Wetter müssen sofort berücksichtigt werden.
Data Science Blog: Welche Methoden des Data Science sind aktuell im Trend und spielen demnächst eine Rolle?
Aus meiner Sicht ist Deep Learning mit neuronalen Netzen der Trend. Vermutlich werden sie sich weiter durchsetzen, denn sie können noch komplexere Aufgaben bewältigen. Aktuell gibt es allerdings teilweise noch Akzeptanzprobleme, da neuronale Netze mit vielen versteckten Schichten eine Blackbox darstellen. Die Ergebnisse sind also im Gegensatz zu weniger komplexen Methoden nicht nachvollziehbar.
Data Science Blog: Auf welche Tools setzen Sie bei Ihrer Arbeit? Bevorzugen Sie Open Source oder proprietäre Lösungen?
Ich habe viel mit proprietären Lösungen gearbeitet, beispielsweise mit SAS oder IBM SPSS. Wir setzen derzeit allerdings auf Open Source, vor allem auf die Programmiersprache R. Neue Mitarbeiter im Data Science Bereich sollten daher zumindest über Grundkenntnisse in R verfügen und die Lust haben, sich tiefer mit dieser Programmiersprache zu befassen.
Wir verwenden unter anderem die Pakete ggplot und Shiny. Mit Shiny erstellen wir interne Web-Applikationen, um Kollegen Analysen zur Verfügung zu stellen. Für Eigenentwicklungen komplexer Visualisierungen ist ggplot perfekt geeignet.
Mit R können wir außerdem selbst eigene Packages erstellen um den Funktionsumfang nach unseren Wünschen zu erweitern. Wir haben daher keinen Grund, auf kostenintensive Lösungen zu setzen.
Data Science Blog: Was macht Ihrer Erfahrung nach einen guten Data Scientist aus?
Aus meiner Sicht sollte man ein Zahlenfreak sein und niemals aufhören Fragen zu stellen, denn darum geht es im Data Science. Gute Data Scientists sind meiner Meinung nach interdisziplinär ausgebildet, kommen also nicht nur aus einer Ecke, sondern besser aus zwei oder drei Fachbereichen. Man benötigt verschiedene Sichtweisen.
Aus welchem Fachbereich man ursprünglich kommt, ist dabei gar nicht so wichtig. Es muss also nicht unbedingt ein Mathematiker oder Statistiker sein.
Data Science Blog: Gibt es eigentlich aus Ihrer Erfahrung heraus einen Unterschied zwischen Mathematikern und Statistikern?
Ja. Mathematiker denken meiner Meinung nach sehr exakt und beweisorientiert. Statistik ist zwar ein Teilbereich der Mathematik, aber für einen Statistiker steht das Schätzen im Vordergrund. Statistiker denken in Verteilungen, Wahrscheinlichkeiten und Intervallen und können gut mit einer gewissen Unsicherheit leben, die reine Mathematiker manchmal unbefriedigt lässt.
Data Science Blog: Für alle diejenigen, die gerade ihr Studium der Statistik, Ingenieurwissenschaft oder was auch immer abschließen. Welchen Rat haben Sie, wie diese Menschen einen Schritt näher ans Data Science herankommen?
Ich würde empfehlen, einfach ein eigenes kleines Projekt zu starten – „Learning by doing“! Ob das Projekt um die eigenen Stromverbrauchsdaten, eine Wettervorhersage oder Fantasy-Football geht ist nicht wichtig. Man stößt dann zwangsläufig auf die verschiedenen Arbeitsschritte und Herausforderungen. Ein empfehlenswerter Workflow ist der Cross Industry Standard Process for Data Mining, kurz CRISP-DM.
Zuerst muss man ein Geschäftsverständnis aufbauen. Weiter geht es mit der Datensammlung und Datenintegration, danach folgt die Datenaufbereitung. Diese Schritte benötigen bereits ca. 80% der Projektzeit. Erst dann können explorative Analysen, Hypothesentests oder Modellierung aufgesetzt werden. Am Ende des Prozesses erfolgt das Deployment.
