AI Meets Fintech

Aufbau einer Data Science Pipeline

ohe data science pipeline

Maschinelles Lernen und künstliche Intelligenz werden für den geschäftlichen Erfolg immer wichtiger. Mit der Hadoop-Plattform und Frameworks wie TensorFlow oder scikit-learn, kann eine Data-Science-Umgebung sehr leicht aufgebaut werden. In stark regulierten Branchen, wie zum Beispiel der Finanzindustrie, sind vor dem produktiven Einsatz allerdings viele regulatorische und technologische Hürden zu überwinden. Dieser Artikel stellt einen erprobten Ansatz für den Aufbau einer Data Science Pipeline in einem stark regulierten Umfeld vor. Dabei werden insbesondere die unterschiedlichen Anforderungen aus dem Betrieb, der Anwendungsentwicklung und dem Data Science berücksichtigt..

Data Science Pipeline

Im Zusammenhang mit Data Science und maschinellem Lernen wird oft von der Entwicklung und dem Trainieren von Modellen geredet. Etwas vereinfacht besteht ein Modell aus einem oder mehreren Algorithmen, die als Teil eines Computerprogramms ausgeführt werden. Beim Trainieren werden die Algorithmen  ausgewählt und konkrete Parameter festgelegt. Die Arbeitsweise der Data Scientisten unterscheidet sich von der klassischen Anwendungsentwicklung vor allem dadurch, dass Daten eine wesentliche Rolle spielen. In einem iterativen Prozess werden die Daten in mehreren Schritten verarbeitet, analysiert, bereinigt und zum Erstellen und Trainieren von Modellen verwendet. Die trainierten Modelle werden anschließend in der Produktion eingesetzt. 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 (siehe Abbildung 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 (siehe Abbildung 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ätze oder Ausreißer eliminiert. Bei der anschließenden Transformation werden die Daten aufbereitet, sodass 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 zeitaufwendigste Arbeitsschritt.

Maschinelles Lernen

Beim maschinellen Lernen wird auf Basis der Erkenntnisse aus dem Data Engineering das Modell erstellt (siehe Abbildung 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.

Produktiver Betrieb

Als Nächstes wird aus dem trainierten Modell eine Anwendung, die im produktiven System installiert und betrieben wird (siehe Abbildung 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 werden 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 geliefert hat, wird das alte Modell deaktiviert und das neue Modell aktiv genutzt.

Data-Science-Anforderungen

Im Idealfall möchten Data-Scientisten mit möglichst vielen produktiven Daten arbeiten. In vielen Fällen sind das personenbezogene Daten, die besonders schützenswert sind. Eine Anonymisierung oder Pseudonymisierung der Daten würde dieses Problem lösen. Allerdings sind anonymisierte Daten für die explorative Analyse und das Training der Modelle oft nutzlos. Ein Anwendungsfall ist die automatische Kategorisierung von Umsatzdaten, um ein automatisches Haushaltsbuch zu erstellen. Bei einer einfachen Anonymisierung könnte die IBAN maskiert werden. Damit ist der direkte Bezug zu einem Konto und somit zu einer Person nicht mehr möglich. Durch die Analyse des Verwendungszweckes der einzelnen Datensätze ist der Personenbezug in den meisten Fällen aber wieder herstellbar. Wird jetzt zusätzlich der Verwendungszweck maskiert, dann sind die Daten für die Analyse und Modellentwicklung aber unbrauchbar, da der Verwendungszweck für eine korrekte Kategorisierung zwingend notwendig ist.

Neben den Daten spielen auch die eingesetzten Werkzeuge eine wichtige Rolle. Zusätzlich zu Bash-Scripten und SQL-Abfragen ist insbesondere Python sehr beliebt und weit verbreitet. Für Python gibt es eine Vielzahl von analytischen und mathematischen Bibliotheken. NumPy, Pandas, Matplotlib, NLTK, scikit-learn und TensorFlow sind nur einige davon. Die Entwicklung dieser Bibliotheken schreitet schnell voran. Um die neuesten Features nutzen zu können, müssen die neuen Versionen regelmäßig und zeitnah bereitgestellt werden. Für die explorative Arbeit mit den Daten werden oft Notebook-Systeme wie Jupyter oder  Zeppelin eingesetzt. Dabei handelt es sich im Wesentlichen um Webanwendungen, in denen Code-Blö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 (siehe Abbildung 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-Scientisten 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-Scientisten.

Data Science Sandbox

Durch ein ausgefeiltes Management von Ressourcen und Rechten können viele dieser Probleme innerhalb eines einzelnen Hadoop-Clusters gelöst werden. Allerdings ist es sehr aufwendig (wenn nicht gar unmöglich), eine abgesicherte Umgebung zu schaffen, in der sich die Data-Scientisten ungestört austoben können, ohne das produktive System zu gefährden. Einfacher und sicherer ist der Aufbau einer dedizierten „Data Science Sandbox“. Dabei handelt es sich um einen eigenständigen zweiten Hadoop-Cluster, der für Data Engineering und maschinelles Lernen genutzt wird und neben dem primären Hadoop Data Lake betrieben wird. Der Data Lake dient als zuverlässige Datenquelle und als Umgebung für den Betrieb der abgenommenen  Anwendungen. Data Scientisten erhalten keinen direkten Zugriff auf den Data Lake. Für ihre Arbeit verwenden sie ausschließlich die Sandbox. Data Engineering und maschinelles Lernen finden innerhalb der Sandbox statt. Durch diese Konstruktion können strenge, regulatorische Vorgaben im Data Lake umgesetzt werden, ohne die explorative Arbeit der Data-Scientisten zu beeinträchtigen. Die Sandbox wird, wie auch der Data Lake selbst, als produktives System behandelt. Das bedeutet, dass die gleichen Maßnahmen zum Schutz der Daten vor unberechtigtem Zugriff gelten. In der Praxis müssen sich die Benutzer authentifizieren und innerhalb der Sandbox dürfen die Daten nur von autorisierten Anwendern gelesen bzw. verändert werden.

Für die Sandbox gelten allerdings deutlich niedrigere Anforderungen an die Verfügbarkeit und die einzuhaltenden SLAs. Im Gegenzug bekommen die Anwender sehr viele Freiheiten. Insbesondere können innerhalb der Sandbox relativ problemlos neue Hadoop-Dienste oder Data-Science-Bibliotheken installiert und ausprobiert werden.

Closed Loop

Wie bereits beschrieben, ist es wichtig, dass die Modelle Monitoring-Daten erzeugen und speichern. Mit diesen Daten wird das Verhalten des Modells überwacht. Im Idealfall werden die Monitoring-Daten zusammen mit den neuen Eingabedaten kontinuierlich in die Sandbox übertragen. Damit schließt sich der Kreis (closed-loop). Innerhalb der Sandbox können die Daten analysiert und mit den erwarteten Ergebnissen abgeglichen werden. In weiteren Iterationen werden diese Daten dann für die Optimierung und Weiterentwicklung der Modelle verwendet.

Development-Cluster

Für den vollständigen Round-Trip fehlt noch eine Kleinigkeit. Das trainierte Modell muss von der Anwendungsentwicklung in eine robuste Applikation überführt werden. Dafür wird eine Umgebung benötigt, in der effizient entwickelt und getestet werden kann. Insbesondere in stark regulierten Branchen, wie der Finanzindustrie, bekommen Entwickler keine Rechte, um direkt mit produktiven Systemen und schützenswerten Daten zu arbeiten. Somit können die Anwendungsentwickler weder den produktiven Data Lake noch die Data Science Sandbox für ihre Arbeit nutzen. Die Lösung ist ein dritter Hadoop-Cluster: der Development-Cluster. Dieser Cluster wird für Anwendungsentwicklung, Test und Abnahme verwendet. Im Development-Cluster dürfen keine schützenswerten Daten gespeichert werden. Entwicklung und Test finden mit synthetisch generierten oder mit zuverlässig anonymisierten Daten statt. Die Installation der abgenommenen Anwendungen im produktiven Data Lake erfolgt über einen kontrollierten Deployment-Prozess. Dazu wird die fertige Software paketiert und von den Entwicklern in einem zentralen Repository, wie zum Beispiel einem Nexus-Repository, abgelegt. Das Betriebsteam verteilt und installiert dann die Software aus dem Repository im Cluster.

Fazit

Die Anforderungen aus Data Science, Betrieb und Anwendungsentwicklung sind nicht leicht zu vereinbaren. Mit dem Aufbau eines Data Lakes, einer Data Science Sandbox und eines Development-Clusters können diese Anforderungen aber elegant umgesetzt werden (siehe Abbildung 6). Dadurch bekommt das Data-Science-Team die notwendigen Freiheiten für Experimente, ohne produktive Systeme zu gefährden. Durch einen zusätzlichen Development- Cluster wird sichergestellt, dass auch die Anwendungsentwicklung effizient arbeiten kann. Der Datenschutz wird vereinfacht, da in den einzelnen Clustern immer nur die absolut notwendigen Daten gespeichert werden (Datensparsamkeit). Von Nachteil ist, dass drei Hadoop-Cluster bereitgestellt und parallel betrieben werden müssen. Abhängig von den konkreten Anforderungen können noch weitere Cluster notwendig sein. So wurden Punkte wie Backup & Disaster Recovery oder Upgrades der Hadoop-Software noch nicht berücksichtigt.

Olaf Hein ()