Aufbau einer Data Science Pipeline

Die Erkenntnisse aus der Produktion werden in der nächsten Iteration verwendet, um das Modell zu verbessern. Die Modellentwicklung kann grob in die Schritte "Data Engineering", "Maschinelles Lernen" und "Produktiver Betrieb" aufgeteilt werden (s. Abb. 1). Typische Anwendungsfälle in der Finanzindustrie sind zum Beispiel Betrugsfallerkennung, Umsatzkategorisierung oder die Risikobewertung.

Data Engineering

Das Data Engineering besteht aus mehreren Teilschritten, in denen die Rohdaten analysiert und für das Trainieren eines Modells aufbereitet werden (s. Abb. 2). Am Anfang geht es darum, mit den verfügbaren Daten zu experimentieren und sie zu verstehen. Dies wird auch als "Data Exploration" bezeichnet. Daraus ergeben sich dann Ideen und Erkenntnisse, die bei der Erstellung eines Modells hilfreich sind. Als nächstes werden die Daten bereinigt. Dabei werden zum Beispiel fehlerhafte Datensätzen oder Ausreißer eliminiert. Bei der anschließenden Transformation werden die Daten aufbereitet, so dass weitere Analysen vereinfacht werden. Typische Transformationen sind das Normieren von Werten oder das Hinzufügen von neuen Attributen (Features) aus weiteren Datenquellen wie zum Beispiel Wetterdaten oder Ortsangaben. In der Praxis ist das Data Engineering oft der zeitaufwändigste Arbeitsschritt.

Beim Maschinellen Lernen wird auf Basis der Erkenntnisse aus dem Data Engineering das Modell erstellt (s. Abb. 3). Die Modellentwicklung erfolgt dabei oft mit Python. Als Bibliotheken kommen häufig Spark MLlib, scikit-learn oder TensorFlow zum Einsatz. Anschließend wird das Modell mit vorhandenen Daten trainiert. Dafür werden in der Regel große Datenmengen und auch sehr viel Rechenleistung benötigt. Sowohl die Daten als auch die Rechenleistung werden oft von einem Hadoop Cluster bereitgestellt. Die existierenden Daten werden in Trainingsdaten und Validierungsdaten aufgeteilt. Das Modell wird dann mit den Trainingsdaten gefüttert, sodass es selbständig lernt. Das fertig trainierte Modell wird anschließend mit Validierungsdaten überprüft, die jedoch nicht Teil der Trainingsdaten sein dürfen. Das trainierte Modell muss mit diesen neuen und unbekannten Daten zuverlässige Ergebnisse liefern.

Als nächstes wird aus dem trainierten Modell eine Anwendung, die im produktiven System installiert und betrieben wird (s. Abb. 4). Anwendungen können zum Beispiel regelmäßig ausgeführte Batch-Jobs, kontinuierlich laufende Streaming-Jobs oder in Realtime antwortende REST-Services sein. Zur professionellen Anwendungsentwicklung gehören automatisierte Tests und ein kontrolliertes Deployment-Verfahren. Bei den Tests geht es primär nicht um die fachliche Korrektheit des Modells, denn die wurde bereits mit den Validierungsdaten überprüft. In dieser Phase werden vor allem Stabilität und Kompatibilität des Modells getestet. Continuous-Integration-Systeme, wie zum Beispiel Jenkins oder Bamboo, kommen dafür oft zum Einsatz.

Die Anwendung wird anschließend paketiert, abgenommen, in ein zentrales Repository eingeliefert, im produktiven System installiert und dann in Betrieb genommen. In der Produktion muss das Modell überwacht werden. Dafür ist es wichtig, dass die Anwendung aussagekräftige Monitoringdaten erfasst und abspeichert. Bei Auffälligkeiten oder einem fehlerhaften Verhalten muss das Modell sofort deaktiviert und schnellstmöglich durch eine korrigierte Version ersetzt werden. Bei der Inbetriebnahme aktualisierter Modelle wird oft der "Champion/Challenger"-Ansatz angewendet. Dabei wird das alte und das neue Modell parallel betrieben. Das alte Modell wird dabei als Champion betrachtet und weiterhin aktiv genutzt. Das neue Modell ist der Challenger und muss im produktiven Betrieb beweisen, dass es besser ist. Erst wenn es diesen Beweis angetreten hat, wird das alte Modell deaktiviert und das neue Modell aktiv genutzt.

Für die explorative Arbeit mit den Daten werden oft Notebook-Systeme wie Jupyter oder Zeppelin eingesetzt. Dabei handelt es sich im Wesentlichen um Web-Anwendungen, in denen Codeblöcke auf einer Webseite eingegeben und direkt ausgeführt werden können. Das Ergebnis wird sofort ansprechend im Browser dargestellt und kann mit beschreibenden Texten angereichert werden. Insbesondere können die Daten innerhalb eines Notebooks sehr leicht mit Diagrammen und Tabellen visualisiert werden (s. Abb. 5).

Data Lake

Die beschriebenen Anforderungen können sehr gut mit einem Hadoop Data Lake umgesetzt werden. HDFS, HBase oder Kudu sind für die Speicherung großer Datenmengen sehr gut geeignet. SQL-Abfragen auf strukturierten Daten können sehr leicht mit Hive, Impala und Spark SQL ausgeführt werden. Für weniger strukturierte Daten oder komplexere Aufgaben können Spark-Jobs genutzt werden. Neben der Arbeit mit Kommandozeilen-Tools wie den verschiedenen Shells für HDFS, Hive, Impala und Spark können auch Notebook-Systeme wie Jupyter und Zeppelin sehr gut in einen Hadoop Cluster integriert werden.

Somit bietet Hadoop eine ideale Plattform für eine Data Science Pipeline. Für die Arbeit der Data Scientists werden sogenannte Edge Nodes bereitgestellt. Auf diesen Knoten wird neben den verschiedenen Hadoop-Kommandozeilen-Tools und Shells auch ein Notebook-System installiert und betrieben. Die Analysten melden sich auf diesen Knoten an und arbeiten von dort mit den Daten im Cluster. Dabei hat der Analyst die Wahl, seine Berechnungen, zum Beispiel mit Spark, im Cluster auszuführen oder aber die Daten in den lokalen Hauptspeicher des Edge Nodes zu laden und dort, zum Beispiel mit Pandas, NumPy oder ScyPy zu arbeiten. Häufig wird auch eine Kombination genutzt. In dem Fall werden die Daten zuerst mit Spark im Cluster gelesen und vorverarbeitet und dann in ein lokales Pandas Data Frame konvertiert. Mit diesem wird dann lokal gearbeitet. Die Ergebnisse werden dann wieder mit Spark im Cluster gespeichert. Da oft direkt auf den Edge Nodes gearbeitet wird, dürfen diese bezüglich des verfügbaren Hauptspeichers und der Anzahl der CPU Cores nicht unterdimensioniert sein.

Betriebsanforderungen

Die fertige Applikation soll am Ende in Produktion betrieben werden. Nicht selten müssen SLAs bezüglich Verfügbarkeit und Antwortzeit eingehalten werden. Das bedingt, dass die produktiven Modelle in einer kontrollierten und stabilen Umgebung laufen müssen. Ein direkter Zugriff auf das produktive System zur Ausführung von Ad-hoc-Auswertungen oder zum Trainieren von Modellen würde dem widersprechen. Weiterhin können in einer produktiven Umgebung nicht ohne weiteres neue Versionen von Bibliotheken installiert und ausprobiert werden. Die Gefahr von Inkompatibilitäten und ungewollten Nebeneffekten ist zu groß. Zu guter Letzt muss der Betrieb auch sicherstellen, dass die Daten vor unberechtigtem Zugriff geschützt werden. Neben einem umfassenden Rechtemanagement müssen dazu oftmals weitere Data-Governance-Anforderungen umgesetzt werden. Diese Anforderungen stehen in einem Konflikt mit den Anforderungen der agilen Arbeitsweise der Data Scientists.