en
de

Conference Intelligence: data2day

14 Oktober 2016
| |
Lesezeit: 4 Minutes

Die seit drei Jahren stattfindende Konferenz data2day von Heise und dem d.punkt Verlag richtet sich an Praktiker aus den Bereichen Big Data, Data Analytics und Machine Learning. Nach meinem Vortrag über die Reibungspunkte zwischen Datenanalytik und UX bei building.iot von derselben Verlagsgruppe wurde ich gefragt, ob ich auch auf der data2day etwas über IoT erzählen könnte. Ich wählte ein Thema, bei dem ich aus dem Projektalltag erzählen konnte: Mehr und schneller ist nicht automatisch besser.

Mein Ansatz ist der Folgende:

Das Gesetz der großen Zahlen gilt immer: Die statistische Sicherheit nimmt mit der Anzahl der Datenpunkte immer zu, sofern die Datensammlung fair erfolgt. Leider kostet das Sammeln der Daten oftmals Geld, und so ist man vor allem im Bereich der Sensorik (Stichwort: Internet der Dinge) gezwungen, sinnvolle Kompromisse einzugehen. In diesem Vortrag fasse ich die Erkenntnisse eines Projekts zusammen, in dem die Datenanalytik zeigte, dass man zukünftig nur 60% der angebrachten Sensoren wirklich bräuchte. Auch muss es nicht immer Echtzeit-Analyse und Deep Learning sein: Mit einer auf den Business-Case abgestimmten Datenstrategie lassen sich unnötige Ausgaben vermeiden.

Leider gab es nicht viele Vorträge, die ähnlich tief in Projektdetails eintauchten und bei keiner anderen von mir besuchten Präsentation wurden statistische Betrachtungen gemacht. Schade eigentlich, für eine Datenkonferenz, die mit einem Schwerpunkt auf Analytics punkten möchte. Hier würde ich mir im nächsten Jahr mehr wünschen. Doch was gab es zu sehen und zu lernen?

Keynotes

Die Keynote von Lars George von OpenCore beschäftigte sich mit den unternehmerischen Umstellungen, die mit dem Einsatz einer Big Data-Strategie einhergehen sollten. Leider findet man besonders in der Management-Etage noch immer die Einstellung, dass sich mit der Installation von Hadoop alle Datenprobleme von alleine lösen. Dies ist natürlich nicht so. Um den Wert der Daten zu bestimmen, braucht es Überblick – und nur wenige Unternehmen wissen überhaupt, welche Schätze schon seit Jahren in ihren relationalen Datenbanken verstauben. In einer zweiten Keynote von Michael Feidt wurde dies bestätigt. Der Physikprofessor und Unternehmer berichtete von einem Beispiel, in dem ein Unternehmen, basierend auf den am wenigsten relevanten Daten, Entscheidungen für eine Kampagne fällte. Es reicht also nicht nur die Installation eines Business Intelligence-Tools, man muss auch ein Gespür für die richtige Verknüpfung von Daten haben. Hier schlägt dann die Stunde von Dienstleistern wie Zühlke, die Erfahrung in der Entwicklung von Datenstrategien haben und über Spezialisten verfügen, die auch aus heterogenen Daten ein Maximum von „actionable insight“ herausziehen können.

Um drei Begriffe kam man dieses Jahr nicht herum: Apache, Jupyter und Deep Learning.

Das Apache Ökosystem mit Tools wie Spark, Flink, Solr und Zeppelin wurde in fast der Hälfte der Vorträge behandelt oder zumindest angesprochen. Es scheint, als wenn innerhalb von Big Data vor allem Fast Data einen besonderen Stellenwert hat. Leider sind nur wenige Vortragende wirklich konkret geworden, und so blieb manchmal der Beigeschmack, dass die Referenten zwar durchaus in der Lage waren, extrem schnelle Datenpipelines zu implementieren – ob dies aber wirklich auch dem Business Case angemessen war, blieb zumeist unklar. Ich sage nicht, dass die schnelle Verarbeitung der Daten falsch ist, aber bei beschränktem Projektbudget sollte man eben Prioritäten setzen.

Weitere Highlights

Persönlich war ich sehr überrascht, wie wenig man bei data2day 2016 über R gehört hat. In der akademischen Forschung ist R immer noch die Lingua franca aller Statistiker und derjenigen, die wissenschaftliche Daten auszuwerten haben. Im industriellen Kontext scheint sich aber ein Analysen-Stack durchzusetzen, bei dem obenauf Jupyter und Python sitzen. Besonders hervorheben möchte ich die Talks von Mark Keinhörster (EON), Daniel Wrigley (SHI) und Alexander Hendorf (Königsweg). Keinhörster berichtete von seinem Alltag als IT-Service zwischen IoT- und Data Science-Team bei EON. Um den oftmals nicht sonderlich technik-affinen Wissenschaftlern dennoch eine mächtige Arbeitsumgebung mit simulierten Echtzeitdaten zu ermöglichen, präsentierte er den geschickten Einsatz von Vagrant-Instanzen, die den Data Scientists transparent eine Simulationsumgebung und einen Kafka-Broker auch auf ihren Laptops zur Verfügung stellt – auf die dann in einer dritten virtuellen Maschine eine Jupyter/Python-Installation zugreifen kann. Hendorf präsentierte Datenexploration mit Pandas, in einem Framework, welches in Python erlaubt, beliebige Daten mit SQL-Logik (select, where, group by, order by) zu ergründen. Dies ist eigentlich Routine in der initialen Analyse von Daten und so war es, nach Handzeichen gehend, interessant zu sehen, wie viele Programmierer sich immer noch mit selbstgestrickten Tools abquälen und nicht das unter Data Scientists übliche Pandas benutzen. Wrigley wiederum setzte nicht auf Jupyter/Python auf, sondern demonstrierte den analogen Fall mit einer Kombination aus Apache NiFi (Datenimport, Bereinigung), Solr (Indizierung und Suche) und Zeppelin (Exploration mit SQL und NoSQL-Syntax). Beide Stacks haben ihre Stärke, wobei der Installationsaufwand für NiFi-Solr-Zeppelin ungleich größer ist.

Deep Learning

Man konnte Deep Learning und Convolutional Networks dieses Jahr nicht aus dem Weg gehen. Leider bestätigte sich mein Vorurteil: Nur wenige setzen diese Methoden adäquat und angemessen ein. Calvin Seward von Zalando präsentierte, wie man mittels TensorFlow in einem experimentellen Online-Shop auch in Abwesenheit jeglicher Meta-Information ähnliche Kleidung finden kann, alleine, weil dem Computer ein Set von verschiedenen Kleidungsstilen antrainiert wurde. Mehrere andere Vortragende führten auch einfachere neuronale Netzwerke ein, doch blieben Demonstrationen stets sehr phänomenologisch: Ein Layer mehr hier, eine andere Aktivierungsfunktion da – aber warum dies nun zu besseren oder schlechteren Ergebnissen führte, dies vermochte – der Deep Learning-Methodik inhärent- keiner zu sagen.

Fazit

Mein Fazit bleibt, dass das meiste ernstzunehmende Machine Learning im industriellen Kontext einer Interpretation bedarf, und am Lernerfolg beteiligte Features (Maschinenparameter, etc.) auch als solche erkannt werden sollten. Nur z.B. in der Bilderkennung, wo es um tatsächliche optische Muster geht, macht das Verwerfen einzelner Features (hier: Pixel) durch Deep Learning wirklich Sinn. Für den Einsatz beispielsweise bei Predictive Maintenance halte ich Deep Learning für eine teure Spielerei, aufgrund des höheren Zeiteinsatzes bei der Entwicklung, dem Preis der Rechenzeit oder spezialisierter GPU-Hardware und auch weil oftmals viel mehr Trainingsdaten benötigt werden, als z.B. in anderen Lernverfahren. Und so war es dann auch nicht überraschend, dass beim informellen Austausch zwar weniger Teilnehmer klassische Machine Learning-Verfahren benutzten, dafür aber fast durchgehend im Produktionseinsatz, während Deep Learning bei der Majorität eher der persönlichen Fortbildung oder Wochenendprojekten diente.

Hier nochmal der Link der Vortrag bei der Data2Day auf Slideshare

Kontaktmöglichkeiten:

Kommentare (0)

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.