dark

Machine Learning – eine Challenge für Architekten

Avatar

#JAVAPRO #MachineLearning ||

Aufgrund vielfältiger potenzieller Geschäftschancen, die Machine-Learning bietet,starten viele Unternehmen Initiativen für datengetriebene Innovationen. Dabei gründen sie Analytics-Teams, schreiben neue Stellen für Data-Scientists aus, bauen intern Knowhow auf und fordern von der IT-Organisation eine Infrastruktur für heavy Data-Engineering & Processing samt Bereitstellung einer Analytics-Toolbox ein. Für IT-Architekten warten hier spannende Herausforderungen, u.a. bei der Zusammenarbeit mit interdisziplinären Teams, deren Mitglieder unterschiedlich ausgeprägte Kenntnisse im Bereich Machine-Learning (ML) und Bedarf bei der Tool-Unterstützung haben.

Einige Überlegungen sind dabei: Sollen Data-Scientists mit ML-Toolkits arbeiten und eigene maßgeschneiderte Algorithmen nur im Ausnahmefall entwickeln, damit später Herausforderungen durch (unkonventionelle) Integrationen vermieden werden? Macht ML-Funktionalität im seit fünf Jahren bewährten Datenintegrations-(ETL-)Tool Sinn? Sollen ambitionierte Fachanwender künftig selbst Rohdaten aufbereiten und verknüpfen, um auf das präparierte Dataset einen populären Algorithmus anzuwenden und die Ergebnisse selbst interpretieren? Für die genannten Fragestellungen warten junge & etablierte Software-Hersteller sowie die Open-Source-Community mit All-in-one-Lösungen oder Machine-Learning-Erweiterungen auf. Vor dem Hintergrund des Data-Science-Prozesses, der den Weg eines ML-Modells von der experimentellen Phase bis zur Operationalisierung beschreibt, vergleicht dieser Artikel ausgewählte Ansätze (Notebooks für die Datenanalyse, Pluggable-Machine Learning-Komponenten in ETL- und Datenvisualisierungswerkzeugen versus Speziallösungen für Machine-Learning) und betrachtet mögliche Einsatzbereiche und Integrationsaspekte.

Data-Science-Prozess und -Teams

Im Zuge des Big-Data-Hypes kamen neben Design-Patterns für Big-Data- und Analytics-Architekturen auch Begriffsdefinitionen auf, die Disziplinen wie Datenintegration von Data-Engineering und Data-Science voneinander abgrenzen. Prozessmodelle, wie das ab 1996 im Rahmen eines EU-Förderprojekts entwickelte CRISP-DM (Cross-Industry-Standard-Process-for-Data-Mining), und Best-Practices zur Organisation erfolgreich arbeitender Data-Science-Teams weisen dabei die Richtung, wie Unternehmen das Beste aus den eigenen Datenschätzen herausholen können. Die Disziplin Data-Science beschreibt den, an ein wissenschaftliches Vorgehen angelehnten, Prozess der Nutzung von internen und externen Datenquellen zur Optimierung von Produkten, Dienstleistungen und Prozessen durch die Anwendung statistischer und mathematischer Modelle. (Abb. 1) stellt in einem Schwimmbahnen-Diagramm einzelne Phasen des Data-Science-Prozesses der beteiligten Funktionen gegenüber und fasst Erfahrungen aus der Praxis zusammen. Dabei ist die Intensität bei der Zusammenarbeit zwischen Data-Scientists und System-Engineers insbesondere bei Vorbereitung und Bereitstellung der benötigten Datenquellen und später bei der Produktivsetzung der Ergebnisse hoch. Eine intensive Beanspruchung der Server-Infrastruktur ist in allen Phasen gegeben, bei denen Hands-on (und oft auch massiv parallel) mit dem Datenpool gearbeitet wird, z.B. bei Datenaufbereitung,
Training von ML-Modellen etc.

Beteiligung und Interaktion von Fachbereichs- bzw. IT-Funktionen mit dem Data-Science-Team. (Abb. 1)
Beteiligung und Interaktion von Fachbereichs- bzw. IT-Funktionen mit dem Data-Science-Team. (Abb. 1)

Mitarbeiter vom Technologie-Giganten Google haben sich reale Machine-Learning-Systeme näher angesehen und festgestellt, dass der Umsetzungsaufwand für den eigentlichen Kern (= der ML-Code, siehe kleiner schwarzen Kasten in der Mitte von (Abb. 2)) gering ist, wenn man dies mit der Bereitstellung der umfangreichen und komplexen Infrastruktur inklusive Managementfunktionen vergleicht.

Versteckte technische Anforderungen in maschinellen Lernsystemen. (Abb. 2)
Versteckte technische Anforderungen in maschinellen Lernsystemen. (Abb. 2)

Konzeptionelle Architektur für Machine-Learning und Analytics

Die Nutzung aller verfügbaren Daten für Analyse, Durchführung von Data-Science-Projekten, mit den daraus resultierenden Maßnahmen zur Prozessoptimierung und -automatisierung, bedeutet für Unternehmen sich neuen Herausforderungen zu stellen: Einführung neuer Technologien, Anwendung komplexer mathematischer Methoden sowie neue Arbeitsweisen, die in dieser Form bisher noch nicht dagewesen sind. Für IT-Architekten gibt es also reichlich Arbeit, entweder um eine Data-Management-Plattform neu aufzubauen oder um das bestehende Informationsmanagement weiterzuentwickeln. (Abb. 3) zeigt hierzu eine vierstufige Architektur nach Gartner, ausgerichtet auf Analytics und Machine-Learning.

Konzeptionelle End-to-End-Architektur für Machine-Learning und Analytics. (Abb. 3)
Konzeptionelle End-to-End-Architektur für Machine-Learning und Analytics. (Abb. 3)

Was hat sich im Vergleich zu den traditionellen Data-Warehouse und Business-Intelligence-Architekturen aus den 1990er Jahren geändert? Denkt man z.B. an die Präzisionsfertigung eines komplexen Produkts mit dem Ziel, den Ausschuss weiter zu senken und in der Produktionslinie eine höhere Produktivitätssteigerung (Kennzahl: OEE, Operational-Equipment-Efficiency) erzielen zu können: Die an der Produktherstellung beteiligten Fertigungsmodule (Spezialmaschinen) messen bzw. detektieren über zahlreiche Sensoren Prozesszustände, speicherprogrammierbare Steuerungen (SPS) regeln dazu die Abläufe und lassen zu Kontrollzwecken vom Endprodukt ein oder mehrere hochauflösende Fotos aufnehmen. Bei diesem Szenario entstehen eine Menge interessanter Messdaten, die im operativen Betrieb häufig schon genutzt werden. Z.B. für eine Echtzeitalarmierung bei Über- oder Unterschreitung von Schwellwerten in einem vorher definierten
Prozessfenster. Während früher vielleicht aus Kostengründen nur Statusdaten und Störungsinformationen den Weg in relationale
Datenbanken fanden, hebt man heute auch Rohdaten, z.B. Zeitreihen (Kraftwirkung, Vorschub, Spannung, Frequenzen etc.) für die spätere Analyse auf.

Bezogen auf den Bereich Acquire bewältigt die IT-Architektur in (Abb. 3) nun Aufgaben, wie die Übernahme und Speicherung von Maschinen- und Sensordaten, die im Millisekundentakt Datenpunkte erzeugen. Während IoT-Plattformen das Registrieren, Anbinden und Management von hunderten oder tausenden solcher datenproduzierender Geräte (Things) erleichtern, beschreibt das zugehörige IT-Konzept den Umgang mit Protokollen wie MQTT, OPC-UA, den Aufbau und Einsatz einer Messaging-Plattform für Publish- bzw. Subscribe-Modelle (Pub/Sub) zur performanten Weiterverarbeitung von Massendaten im JSON-Dateiformat. Im Bereich Organize etablieren sich neben relationalen Datenbanken vermehrt verteilte NoSQL-Datenbanken zur Persistierung eingehender Datenströme, wie sie z.B. im beschriebenen Produktionsszenario entstehen. Für hochauflösende Bilder, Audio-, Videoaufnahmen oder andere unstrukturierte Daten kommt zusätzlich noch Object-Storage als alternative Speicherform in Frage. Neben der kostengünstigen und langlebigen Datenaufbewahrung ist die Möglichkeit, einzelne Objekte mit Metadaten flexibel zu beschreiben, um damit später die Auffindbarkeit zu ermöglichen und den notwendigen Kontext für die Analysen zu geben, hier ein weiterer Vorteil. Mit dem richtigen Technologiemix und der konsequenten Umsetzung eines Data-Lake- oder Virtual-Data-Warehouse-Konzepts gelingt es IT-Architekten, vielfältige Analytics-Anwendungsfälle zu unterstützen.
Im Rahmen des Data-Science-Prozesses spielt, neben der sicheren und massenhaften Datenspeicherung sowie der Fähigkeit zur gleichzeitigen, parallelen Verarbeitung großer Datenmengen, das sogenannte Feature-Engineering eine wichtige Rolle. Dazu wieder ein Beispiel aus der maschinellen Fertigung: Mit Hilfe von Machine-Learning sollen unbekannte Gründe für den zu hohen Ausschuss gefunden werden. Was sind die bestimmenden Faktoren dafür? Beeinflusst etwas die Maschinenkonfiguration oder deuten Frequenzveränderungen bei einem Verschleißteil über die Zeit gesehen auf ein Problem hin? Maschine und Sensoren liefern viele Parameter als Zeitreihendaten,
aber nur einige davon sind – womöglich nur in einer bestimmten Kombination – für die Aufgabenstellung wirklich relevant. Daher versuchen Data-Scientists bei der Feature-Entwicklung die Vorhersage- oder Klassifikationsleistung der Lernalgorithmen durch Erstellen von Merkmalen aus Rohdaten zu verbessern und mit diesen den Lernprozess zu vereinfachen. Die anschließende Feature-Auswahl wählt bei dem Versuch, die Anzahl von Dimensionen des Trainingsproblems zu verringern, die wichtigste Teilmenge der ursprünglichen Daten-Features aus. Aufgrund dieser und anderer Arbeitsschritte, wie z.B. Auswahl und Training geeigneter Algorithmen, ist der Aufbau eines Machine-Learning-Modells ein iterativer Prozess, bei dem Data-Scientists dutzende oder hunderte von Modellen bauen, bis die Akzeptanzkriterien für die Modellgüte erfüllt sind. Aus technischer Sicht sollte die IT-Architektur auch bei der Verwaltung von Machine-Learning-Modellen bestmöglich unterstützen, z.B. bei Modellversionierung, -deployment und -tracking in der Produktionsumgebung oder bei der Automatisierung des Retrainings. Die Bereiche Analyze und Deliver zeigen in (Abb. 3) einige bekannte Analysefähigkeiten, wie z.B. die Bereitstellung eines Standard-Reportings, Self-Service-Funktionen zur Geschäftsplanung sowie Ad-hoc-Analyse und Exploration neuer Datasets. Data-Science-Aktivitäten können etablierte Business-Intelligence-Plattformen inhaltlich ergänzen, in dem sie durch neuartige
Kennzahlen, das bisherige Reporting smarter machen und ggf. durch Vorhersagen einen Blick in die nahe Zukunft beisteuern. Machine-Learning-as-a-Service oder Machine-Learning-Produkte sind alternative Darreichungsformen, um Geschäftsprozesse mit Hilfe von Analytik zu optimieren: Z.B. integriert in einer Call-Center-Applikation, die mittels Churn-Indikatoren zu dem gerade anrufenden erbosten Kunden einen Score zu dessen Abwanderungswilligkeit zusammen mit Handlungsempfehlungen (Gutschein, Rabatt) anzeigt. Den Kunden-Score oder andere Risikoeinschätzungen liefert dabei eine Service-Schnittstelle, die von verschiedenen unternehmensinternen oder auch externen Anwendungen (z.B. Smartphone-App) eingebunden und in Echtzeit angefragt werden kann. Arbeitsfelder für die IT-Architektur wären in diesem Zusammenhang u.a. Bereitstellung und Betrieb (skalierbarer) ML-Modelle via REST-APIs in der Produktionsumgebung inklusive Absicherung gegen unerwünschten Zugriff.

Klassischer Ansatz: Datenanalyse und Machine-Learning mit Jupyter-Notebook & Python

Jupyter ist ein Kommandozeileninterpreter zum interaktiven Arbeiten mit der Programmiersprache Python. Es handelt sich dabei nicht nur um eine bloße Erweiterung der in Python eingebauten Shell, sondern um eine Software-Suite zum Entwickeln und Ausführen von Python-Programmen. Funktionen wie Introspektion, Befehlszeilenergänzung, Rich-Media-Einbettung und verschiedenen Frontends (Terminal, Qt-basiert oder browser-basiert) ermöglichen es, Python-Anwendungen als auch Machine-Learning-Projekte komfortabel zu entwickeln und gleichzeitig zu dokumentieren. Datenanalysten sind bei der Arbeit mit Juypter nicht auf Python als Programmiersprache begrenzt, sondern
können ebenso auch sogenannte Kernels für Julia, R und vielen anderen Sprachen einbinden. Ein Jupyter-Notebook besteht aus einer Reihe von Zellen, die in einer Sequenz angeordnet sind. Jede Zelle kann entweder Text oder (Live-)Code enthalten und ist beliebig verschiebbar. Texte lassen sich in den Zellen mit einer einfachen Markup-Sprache formatieren, komplexe Formeln wie mit einer Ausgabe in LaTeX darstellen. Code-Zellen enthalten Code in der Programmiersprache, die dem aktiven Notebook über den entsprechenden Kernel (Python 2, Python 3, R, etc.) zugeordnet wurde. (Abb. 4) zeigt auszugsweise eine Analyse historischer Hauspreise in Abhängigkeit ihrer Lage in Kalifornien, USA (Daten und Notebook sind öffentlich erhältlich). Notebooks erlauben es, ganze Machine-Learning-Projekte von der Datenbeschaffung bis zur Evaluierung der ML-Modelle reproduzierbar abzubilden und lassen sich gut versionieren. Komplexe ML-Modelle können in Python mit Hilfe des Pickle-Moduls, das einen Algorithmus zur Serialisierung und De-Serialisierung implementiert, ebenfalls transportabel gemacht werden.

 

 

 

 

 

 

 

 

 

Datenbeschaffung, Inspektion, Visualisierung und ML-Modell-Training in einem Jupyter-Notebook (Programmiersprache: Python). (Abb. 4) 

Welches Machine-Learning-Framework für welche Aufgabenstellung?

Bevor die nächsten Abschnitte weitere Werkzeuge und Technologien betrachten, macht es nicht nur für Data-Scientists sondern auch für IT-Architekten Sinn, zunächst einen Überblick auf die derzeit verfügbaren Machine-Learning-Frameworks zu bekommen. Aus Architekturperspektive ist es wichtig zu verstehen, welche Aufgabenstellungen die jeweiligen ML-Frameworks adressieren, welche technischen Anforderungen und ggf. auch Abhängigkeiten zu den verfügbaren Datenquellen bestehen. Ein gemeinsamer Nenner vieler gescheiterter Machine-Learning-Projekte ist häufig die Auswahl des falschen Frameworks. Ein Beispiel: Tensor-Flow ist aktuell eines der wichtigsten Frameworks zur Programmierung von neuronalen Netzen, Deep-Learning-Modellen sowie anderer Machine-Learning-Algorithmen. Während Deep-Learning perfekt zur Untersuchung komplexer Daten wie Bild- und Audiodaten passt, wird es zunehmend auch für Use-Cases benutzt, für die andere Frameworks besser geeignet sind. (Abb. 5) zeigt eine kompakte Entscheidungsmatrix für die derzeit verbreitetsten ML-Frameworks und adressiert häufige Praxisprobleme: Entweder werden Algorithmen benutzt, die für den Use-Case nicht oder kaum geeignet sind oder das gewählte Framework kann die aufkommenden Datenmengen nicht bewältigen. Die Unterteilung der Frameworks in Small-Data, Big-Data und Complex-Data ist etwas plakativ, soll aber bei der Auswahl der Frameworks nach Art und Volumen der Daten helfen. Die Grenze zwischen Big-Data zu Small-Data ist dabei dort zu ziehen, wo die Datenmengen so groß sind, dass sie nicht mehr auf einem einzelnen Computer, sondern in einem verteilten Cluster ausgewertet werden müssen. Complex-Data steht in dieser Matrix für unstrukturierte Daten wie Bild- und Audiodateien, für die sich Desep-Learning-Frameworks sehr gut eignen.

Entscheidungsmatrix zu aktuell verbreiteten Machine-Learning-Frameworks. (Abb. 5)
Entscheidungsmatrix zu aktuell verbreiteten Machine-Learning-Frameworks. (Abb. 5)

Self-Service-Machine-Learning in Business-Intelligence-Werkzeugen

Mit einfach zu bedienenden Business-Intelligence-Werkzeugen zur Datenvisualisierung ist es für Analytiker und für weniger technisch
versierte Anwender recht einfach, komplexe Daten aussagekräftig in interaktiven Dashboards zu präsentieren. Hersteller wie Tableau, Qlik und Oracle spielen ihre Stärken insbesondere im Bereich Visual-Analytics aus. Das heißt, anstatt statische Berichte oder Excel-Dateien vor dem nächsten Meeting zu verschicken, erlauben digitalisierte Besprechungs- und Kreativräume interaktive Datenanalysen am Smartboard inklusive Abändern der Abfragefilter, Perspektivwechsel und Drill-downs. Im Rahmen von Data-Science-Projekten können diese Werkzeuge sowohl zur Exploration von Daten als auch zur Visualisierung der Ergebnisse komplexer Machine-Learning-Modelle sinnvoll eingesetzt werden. Prognosen, Scores und weiterer ML-Modell-Output lässt sich so schneller verstehen und unterstützt die Entscheidungsfindung bzw. Ableitung der nächsten Maßnahmen für den Geschäftsprozess. Im Rahmen einer IT-Gesamtarchitektur sind Analyse-Notebooks und Datenvisualisierungswerkzeuge für die Standard-Analytics-Toolbox eines Unternehmens gesetzt. Mit Hinblick auf effiziente Team-Zusammenarbeit, unternehmensinternen Austausch und Kommunikation von Ergebnissen sollte aber nicht nur auf reine Desktop-Werkzeuge gesetzt, sondern Server-Lösungen betrachtet und zusammen mit einem Nutzerkonzept eingeführt werden, um zehnfache Report-Dubletten, konkurrierende Statistiken (MS-Excel-Hell) einzudämmen.
Zusätzliche Statistikfunktionen bis hin zur Möglichkeit Rund Python-Code bei der Analyse auszuführen, öffnet auch Fachanwendern die Tür zur Welt des Machine-Learnings. (Abb. 6) zeigt Oracle-Data-Visualization bei der Analyse kalifornischer Hauspreise (demselben Datensatz wie oben im Jupyter-Notebook-Abschnitt) und einer Heatmap-Visualisierung zur Hervorhebung der teuersten Wohnlagen. Mit wenigen Klicks
ist auch der Einsatz deskriptiver Statistik möglich, mit der sich neben Lagemaßen (Median, Quartilswerte) auch Streuungsmaße (Spannweite, Interquartilsabstand) sowie die Form der Verteilung direkt aus dem Box-Plot in (Abb. 6) ablesen und sogar über das Vorhandensein von Ausreißern im Datensatz eine Feststellung treffen lassen. Vorteil dieser Visualisierungen sind ihre hohe Informationsdichte, die allerdings vom Anwender auch richtig interpretiert werden muss. Bei der Beurteilung der Attribute mit ihren Wertausprägungen und Abhängigkeiten innerhalb des Data-Sets können Citizien-Data-Scientists (eine Wortschöpfung von Gartner) systemseitig Unterstützung gebrauchen – und bekommen sie bei Oracle-Data-Visualization bei Bedarf auch über die Funktion Explain. Fraglich ist dagegen der Nutzen, wenn man im Data-Flow-Editor eines oder mehrere der im Werkzeug integrierten Machine-Learning-Modelle trainiert und evaluiert: technisch lassen sich Ergebnisse erzielen und anhand einiger Performance-Metriken die Modellgüte auch bewerten bzw. mit anderen Modellen vergleichen – aber welche Persona (außer Data-Scientists) soll damit ernsthaft (wissenschaftlich) arbeiten? Gleiches gilt für die Integration vorhandener R- und Python-Skripte, die eigentlich nur im Rahmen der Zusammenarbeit von Data-Scientist-Kollegen inklusive Einweisung und Interpretationshilfe bereitgestellt werden können.

Datenexploration leicht gemacht für Fachanwender mit Oracle-Data-Visualization. (Abb. 6)
Datenexploration leicht gemacht für Fachanwender mit Oracle-Data-Visualization. (Abb. 6)

Machine-Learning-Orchestrierung mit Datenintegrationswerkzeugen

Machine-Learning-Funktionalität findet sich mittlerweile auch in Datenintegrationslösungen, die sich vormals auf die klassische Datenbewirtschaftung für das Data-Warehouse fokussiert haben. An dieser Stelle ist es vielleicht nun Zeit auf die Disziplin Data-Engineering näher einzugehen: Als Data-Engineer erforscht man Daten und entwickelt die passende Software-Lösung. Besonders zu Projektbeginn sind
sog. Data-Pipelines beginnend von den Datenquellen bis hin zur Verwendung im operativen Betrieb und für analytische Anwendungen zu planen und implementieren. In der Explorationsphase sucht der Data-Engineer mit seinem breiten technischen und methodischen Verständnis nach Strukturen, Mustern und Zusammenhängen in den Daten und unterstützt die Data-Science-Kollegen bei der technischen Umsetzung bzw. Anpassung der mathematischen Modelle. Während eines Data-Science-Projekts verbringen Data-Engineers viel Zeit mit der Beschaffung, Bereinigung und Aufbereitung der Trainingsdaten und der Einsatz der klassischen Datenintegrationswerkzeuge eine gute Option für mehr Effizienz. Neu ist nun die Idee, Machine-Learning zum Trainieren eines oder mehrerer ML-Modelle in DI-Werkzeuge zu
integrieren. Den naheliegendsten Fall gibt (Abb. 7) wieder, die eine einfache Data-Pipeline in Pentaho-Data-Integration (PDI) zeigt, in dem zunächst JSON-Dateien eingelesen und in eine tabellarische Struktur pivotiert werden. Im Anschluss versorgt der erzeugte Datenstrom gleichzeitig drei verschiedene Machine-Learning-Modelle mit Trainingsdaten.

Bring your own Machine-Learning-Model. Z.B. Python-Code, eingebettet in Pentaho-Data-Integration. (Abb. 7)
Bring your own Machine-Learning-Model. Z.B. Python-Code, eingebettet in Pentaho-Data-Integration. (Abb. 7)

In PDI ist es die Aufgabe des Data-Engineers, den zuvor vom Data-Science-Kollegen bereitgestellten Python-Code in jeweils einen sog.
Python-Executor zu überführen und die eingehenden Trainingsdaten dem entsprechenden (Pandas-)Dataframe zuzuweisen. Auf diese Weise lässt sich eine Art Bring-yourown-ML-Model-Konzept umsetzen, in dem sich in der bestehenden Datenintegrationsplattform neben dem Alltagsgeschäft nun zusätzlich Machine-Learning-Aufgaben orchestrieren und automatisieren lassen. Vorteil im Vergleich zum ML-Modell-Training in BI-Werkzeugen ist bei diesem Ansatz, dass Datenintegrationsplattformen für die parallelisierte Ausführung von Data-Pipelines ausgelegt sind und über erprobte Steuerungs-, Überwachungs- und Debugging-Funktionen verfügen. Bei der Einbindung von R- und Python-Code sollte man aber trotzdem überprüfen, inwieweit auch ML-Modelle parallelisiert ausführbar sind oder ob es hier Einschränkungen gibt. Über den Import zusätzlicher Pakete können über die R- oder Python-Schnittstelle auch Deep-Learning-Szenarien (z.B. Keras mit Tensor-Flow-Backend) zur Analyse unstrukturierter Daten (Bilder, Videos etc.) umgesetzt und dabei (soweit vorhanden
und bei entsprechender Konfiguration) Grafikprozessoren (GPUs) für bessere Performance genutzt werden.

PDI bietet außerdem die sogenannte Plugin-Machine-Intelligence (PMI)-Erweiterung an, mit der über ein Dutzend populäre Machine-Learning-Algorithmen (z.B. Lineare und logistische Regression, Naive Bayes, Gradient-Boosted-Trees, Random-forest, Support-Vector-Machine) bereitgestellt werden und wahlweise in vier unterschiedlichen Laufzeitumgebungen ausführbar sind: Python-Scikit-Learn, R-MLR, Spark-MLlib und Weka. (Abb. 8) zeigt beispielhaft die Auswahl und Konfiguration des Gradient-Boosted-Tree-Algorithmus in Pentaho-Data-Integration. Der Einsatz dieser vorgefertigten ML-Modelle hat sich in der Praxis für das schnelle Ausprobieren von Klassifizierungsaufgaben
durchaus bewährt. Ob alle benötigten Algorithmen zur Verfügung stehen, bzw. Konfiguration und Fine-Tuning sinnvoll in PDI machbar sind, entscheiden letztlich Data-Engineer und Data-Scientist.

Auswahl- u. Konfiguration eines Gradient-Boosted Tree-Algorithmus in Pentaho-Data-Integration. (Abb. 8)
Auswahl- u. Konfiguration eines Gradient-Boosted Tree-Algorithmus in Pentaho-Data-Integration. (Abb. 8)

Spezialisierte Software-Suites für Machine-Learning

Während sich im Markt etablierte Business-Intelligence- und Datenintegrationswerkzeuge mit Erweiterungen zur Ausführung von Python- und R-Code als notwendigen Bestandteil der Analyse-Toolbox für den Data-Science-Prozess positionieren, gibt es daneben auch Machine-
Learning-Plattformen, die auf die Arbeit mit künstlicher Intelligenz (KI) zugeschnittenen sind. Für den Einstieg in Data-Science bieten sich die oft vorhandenen quelloffenen Distributionen an, die auch über Enterprise-Versionen mit erweiterten Möglichkeiten für beschleunigtes maschinelles Lernen durch Einsatz von Grafikprozessoren (GPUs), bessere Skalierung sowie Funktionen für das ML-Modell-Management
(z.B. durch Versionsmanagement und Automatisierung) verfügen.
Eine beliebte Machine-Learning-Suite ist das Open-Source-Projekt H2O. Die Lösung des gleichnamigen kalifornischen Unternehmens verfügt über eine R-Schnittstelle und ermöglicht Anwendern dieser statistischen Programmiersprache Vorteile in puncto Performance. Die in H2O verfügbaren Funktionen und Algorithmen sind optimiert und damit eine gute Alternative für das bereits standardmäßig in den R-Paketen verfügbare Funktionsset. H2O implementiert Algorithmen aus dem Bereich Statistik, Data-Mining und Machine-Learning (generalisierte Lineare Modelle, K-Means, Random-Forest, Gradient-Boosting und Deep-Learning) und bietet mit einer In-Memory-Architektur und durch standardmäßige Parallelisierung über alle vorhandenen Prozessorkerne eine gute Basis, um komplexe Machine-Learning-Modelle schneller trainieren zu können. (Abb. 9) zeigt wieder anhand des Datensatzes zur Analyse der kalifornischen Hauspreise die web-basierte Benutzeroberfläche H20-Flow, die den oben beschriebenen Jupyter-Notebook-Ansatz mit zusätzlich integrierter Benutzerführung für die wichtigsten Prozessschritte eines Machine-Learning-Projektes kombiniert. Mit einigen Klicks kann das California-Housing-Dataset importiert, in einen H2O-spezifischen Dataframe umgewandelt und anschließend in Trainings- und Testdatensets aufgeteilt werden. Auswahl, Konfiguration und Training der Machine-Learning-Modelle erfolgt entweder durch den Anwender im Einsteiger-, Fortgeschrittenen- oder Expertenmodus bzw. im Auto-ML-Modus. Daran anschließend erlaubt H20-Flow die Vorhersage für die Zielvariable (im Beispiel: Hauspreis) für noch unbekannte Datensätze und die Aufbereitung der Ergebnismenge. Welche Unterstützung H2O zur Produktivsetzung von ML-Modellen anbietet,  wird an einem Beispiel in den folgenden Abschnitten betrachtet.

 

 

H2O-Flow-Benutzeroberfläche – Datenaufbereitung, ML-Modell-Training und Evaluierung. (Abb. 9)

Vom Prototypen zur produktiven Machine-Learning-Lösung

Warum ist es für viele Unternehmen noch schwer, einen Nutzen aus ihren ersten Data-Science-Aktivitäten, Data-Labs etc. zu ziehen? In der Praxis zeigt sich, erst durch Operationalisierung von Machine-Learning-Resultaten in der Produktionsumgebung entsteht echter Geschäftswert und nur im Tagesgeschäft helfen robuste ML-Modelle mit hoher Güte bei der Erreichung der gesteckten Unternehmensziele. Doch leider erweist sich der Weg vom Prototypen bis hin zum Produktiveinsatz bei vielen Initiativen noch als schwierig. (Abb. 10) veranschaulicht ein typisches Szenario: Data-Science-Teams fällt es in ihrer Data-Lab-Umgebung technisch noch leicht, Prototypen leistungsstarker ML-Modelle mit Hilfe aktueller ML-Frameworks wie Tensor-Flow-, Keras- und Word2Vec auf ihren Laptops oder in einer Sandbox-Umgebung zu erstellen. Doch je nach verfügbarer Infrastruktur kann, wegen Begrenzungen bei Rechenleistung oder Hauptspeicher, nur ein Subset der Produktionsdaten zum Trainieren von ML-Modellen herangezogen werden. Ergebnispräsentationen an die Stakeholder der Data-Science-Projekte erfolgen dann eher durch Storytelling in Powerpoint bzw. anhand eines Demonstrators – selten aber technisch schon so umgesetzt, dass andere Applikationen z.B. über eine REST-API von dem neuen Risiko-Scoring-, dem Bildanalyse-Modul etc. (testweise) Gebrauch machen können. Ausgestattet mit einer Genehmigung vom Management, übergibt das Data-Science-Team
ein (trainiertes) ML-Modell an das Software-Engineering-Team. Nach der Übergabe muss sich allerdings das Engineering-Team darum kümmern, dass das ML-Modell in eine für den Produktionsbetrieb akzeptierte Programmiersprache, z.B. in Java, neu implementiert werden muss, um dem IT-Unternehmensstandard, siehe Line-of-Governance in (Abb. 10), bzw. Anforderungen an Skalierbarkeit und Laufzeitverhalten zu genügen. Manchmal sind bei einem solchen Extraschritt Abweichungen beim ML-Modell-Output und in jedem Fall signifikante Zeitverluste beim Deployment zu befürchten.

Übergabe von Machine-Learning-Resultaten zur Produktivsetzung im Echtbetrieb. (Abb. 10)
Übergabe von Machine-Learning-Resultaten zur Produktivsetzung im Echtbetrieb. (Abb. 10)

Unterstützt das Data-Science-Team aktiv bei dem Deployment, dann wäre die Einbettung des neu entwickelten ML-Modells in eine Web-Applikation eine beliebte Variante, bei der typischerweise Flask, Tornado (beides Micro-Frameworks für Python) und Shiny (ein auf R basierendes HTML5/CSS/JavaScript-Framework) als Technologiekomponenten zum Zuge kommen. Bei diesem Vorgehen müssen ML-Modell, Daten und verwendete ML-Pakete bzw. Abhängigkeiten in einem Format verpackt werden, das sowohl in der Data-Science-Sandbox als auch auf Produktions-Servern lauffähig ist. Für große Unternehmen kann dies einen langwierigen, komplexen Software-Auslieferungsprozess bedeuten, der ggf. erst noch zu etablieren ist. In dem Zusammenhang stellt sich die Frage, wie weit die Erfahrung des Data-Science-Teams bei der Entwicklung von Web-Anwendungen reicht und Aspekte wie Load-Balancing und Netzwerkverkehr ausreichend berücksichtigt? Container-Virtualisierung, z.B. mit Docker, zur Isolierungen einzelner Anwendungen und elastische Cloud-Lösungen, die on-Demand benötigte Rechenleistung bereitstellen, können hier Abhilfe schaffen und Teil der Lösungsarchitektur sein. Je nach analytischer Aufgabenstellung ist das passende technische Design zu wählen: Soll das ML-Modell im Batch- oder Near-Realtime-Modus arbeiten? Ist ein Caching für wiederkehrende Modell-Anfragen vorzusehen? Wie wird das Modell-Deployment umgesetzt, In-Memory, Code-unabhängig durch Austauschformate wie PMML, serialisiert via R- oder Python-Objekte (Pickle) oder durch generierten Code? Zusätzlich muss für den Produktiveinsatz von ML-Modellen auch an unterstützenden Konzepten zur Bereitstellung, Routing, Versionsmanagement und Betrieb im industriellen Maßstab gearbeitet werden, damit zuverlässige Machine-Learning-Produkte bzw. -Services zur internen und externen Nutzung
entstehen können, siehe (Abb. 11).

Unterstützende Funktionen für produktive Machine-Learning-Lösungen. (Abb. 11)
Unterstützende Funktionen für produktive Machine-Learning-Lösungen. (Abb. 11)

Die Deployment-Variante Machine-Learning-Code-Generierung lässt sich gut an dem bereits mit H2O-Flow besprochenen Beispiel veranschaulichen. Während (Abb. 9) hierzu die Schritte für Modellaufbau, -training und -test illustriert, zeigt (Abb. 12) den Download-Vorgang für den zuvor generierten Java-Code zum Aufbau eines ML-Modells zur Vorhersage kalifornischer Hauspreise. In dem generierten Java-Code sind die in H2O-Flow vorgenommene Datenaufbereitung sowie alle Konfigurationen für den Gradient-Boosting-Machine-(GBM)-Algorithmus gut nachvollziehbar. (Abb. 13) gibt mit den ersten Programmzeilen einen ersten Eindruck dazu. Nach Abschluss der Machine-Learning-Entwicklung kann der Java-Code des neuen ML-Modells, z.B. unter Verwendung der Apache-Kafka-Streams-API, zu einer Streaming-Applikation hinzugefügt und publiziert werden. Vorteil dabei: Die Kafka-Streams-Applikation ist selbst eine Java-Applikation, in die
der generierte Code des ML-Modells eingebettet werden kann, siehe (Abb. 14). Alle zukünftigen Events, die neue Immobilien-Datensätze zu Häusern aus Kalifornien mit (denselben) Features wie Geo-Position, Alter des Gebäudes, Anzahl der Zimmer etc. enthalten und als ML-Modell-Input über Kafka-Streams hereinkommen, werden mit einer Vorhersage des voraussichtlichen Gebäudepreises von dem auf historischen Daten trainierten ML-Algorithmus beantwortet. Ein Vorteil dabei: Weil die Kafka-Streams-Applikation unter der Haube alle Funktionen von Apache-Kafka nutzt, ist diese neue Anwendung bereits für den skalierbaren und geschäftskritischen Einsatz ausgelegt.

H2O-Flow-Benutzeroberfläche – Java-Code-Generierung und Download eines trainierten Models. (Abb. 12)
H2O-Flow-Benutzeroberfläche – Java-Code-Generierung und Download eines trainierten Models. (Abb. 12)
Generierter Java-Code eines Gradient-Boosted-Machine-Modells zur Vorhersage kalifornischer Hauspreise. (Abb. 13)
Generierter Java-Code eines Gradient-Boosted-Machine-Modells zur Vorhersage kalifornischer Hauspreise. (Abb. 13)
Deployment des generierten Jave-Codes eines H2O ML-Models in einer Kafka-Streams-Applikation. (Abb. 14)
Deployment des generierten Jave-Codes eines H2O ML-Models in einer Kafka-Streams-Applikation. (Abb. 14)

Machine-Learning-as-a-Service – API-first-Ansatz

In den vorherigen Abschnitten kam bereits die Herausforderung zur Sprache, wenn es um die Überführung der Ergebnisse eines Datenexperiments in eine Produktivumgebung geht. Während die Mehrheit der Mitglieder eines Data-Science-Teams bevorzugt R, Python
(und vermehrt Julia) als Programmiersprache einsetzen, gibt es auf der Abnehmerseite das Team der Software-Ingenieure, die für technische Implementierungen in der Produktionsumgebung zuständig sind, die womöglich einen völlig anderen Technologie-Stack verwenden (müssen). Im Extremfall droht die Neuimplementierung eines Machine-Learning-Modells, im besseren Fall kann Code oder die ML-Modellspezifikation transferiert und mit wenig Aufwand eingebettet (vgl. das Beispiel H2O und Apache-Kafka-Streams-Applikation) bzw. direkt in einer neuen Laufzeitumgebung ausführbar gemacht werden. Alternativ wählt man einen API-first-Ansatz und entkoppelt das Zusammenwirken von unterschiedlich implementierten Applikationen bzw. -Applikationsteilen via Web-APIs. Data-Science-Teams machen hierzu z.B. die URL-Endpunkte ihrer testbereiten Algorithmen bekannt, die von anderen Software-Entwicklern für eigene smarte Applikationen konsumiert werden. Durch den Aufbau von REST-APIs kann das Data-Science-Team den Code ihrer ML-Modelle getrennt von den anderen Teams weiterentwickeln und damit eine Arbeitsteilung mit klaren Verantwortlichkeiten herbeiführen, ohne Teamkollegen, die nicht am Machine-Learning-Aspekt des Projekts beteiligt sind, bei ihrer Arbeit zu blockieren.

Gegenstandserkennung mit Machine-Learning und vorgegebenen Bildern via REST-Service. (Abb. 15)
Gegenstandserkennung mit Machine-Learning und vorgegebenen Bildern via REST-Service. (Abb. 15)
Machine-Learning-Bezahlprodukt Google-Vision. (Abb. 16)
Machine-Learning-Bezahlprodukt Google-Vision. (Abb. 16)

(Abb. 15) zeigt ein einfaches Szenario, bei dem die Gegenstandserkennung von beliebigen Bildern mit einem Deep-Learning-Verfahren
umgesetzt ist. Einzelne Fotos können dabei via Kommandozeilen-Editor als Input für die Bildanalyse an ein vortrainiertes Machine-Learning-Modell übermittelt werden. Die Information zu den erkannten Gegenständen inkl. Wahrscheinlichkeitswerten kommt dafür im Gegenzug als JSON-Ausgabe zurück. Für die Umsetzung dieses Beispiels wurde in Python auf Basis der Open-Source-Deep-Learning-Bibliothek Keras, ein vortrainiertes ML-Modell mit Hilfe des Micro-Web-Frameworks Flask über eine REST-API aufrufbar gemacht. Die in Keras-Blog beschriebene Applikation kümmert sich außerdem darum, dass beliebige Bilder via cURL geladen, vorverarbeitet (ggf. Wandlung in RGB, Standardisierung der Bildgröße auf 224 x 224 Pixel) und dann zur Klassifizierung der darauf abgebildeten Gegenstände an das ML-Modell übergeben werden. Das ML-Modell selbst verwendet eine sogenannte ResNet50-Architektur (50-Layer-Residual-Network) und wurde auf Grundlage der öffentlichen ImageNet-Bilddatenbank vortrainiert. Zu dem ML-Modell-Input, in (Abb. 15) Fußballspieler in Aktion, meldet das System für den Tester nachvollziehbare Gegenstände wie Fußball, Volleyball und Trikot zurück. Fragliche Klassifikationen sind dagegen Taschenlampe (Torch) und Schubkarre (Barrow).
Bei Aufbau und Bereitstellung von Machine-Learning-Funktionen mittels REST-APIs bedenken IT-Architekten und beteiligte Teams, ob der Einsatzzweck eher Rapid-Prototyping ist oder eine weitreichende Nutzung unterstützt werden muss. Während das oben beschriebene Szenario mit Python, Keras und Flask auf einem Laptop realisierbar ist, benötigen skalierbare Deep-Learning-Lösungen mehr Aufmerksamkeit hinsichtlich der Deployment-Architektur, in dem zusätzlich ein Message-Broker mit In-Memory-Datastore eingehende bzw. zu analysierende Bilder puffert und dann erst zur Batch-Verarbeitung weiterleitet usw. Der Einsatz eines vorgeschalteten Web-Servers, Load-Balancing, Verwendung von Grafikprozessoren (GPUs) sind weitere denkbare Komponenten für eine produktive ML-Architektur.
Als abschließendes Beispiel für einen leistungsstarken (und kostenpflichtigen) Machine-Learning-Service soll die Bildanalyse von Google-Cloud-Vision dienen. Stellt man dasselbe Bild mit der Fußballspielszene von (Abb. 15) und (Abb. 16) bereit, so erkennt der Google-ML-Service neben den Gegenständen weit mehr Informationen: Kontext (Teamsport, Bundesliga), anhand der Gesichtserkennung den Spieler selbst (Kevin-Prince Boateng) und aktuelle bzw. vorherige Mannschaftszugehörigkeiten (Eintracht Frankfurt, Hertha BSC) usw. Damit zeigt sich am Beispiel des Tech-Giganten auch ganz klar: Es kommt vor allem auf die verfügbaren Trainingsdaten an, inwieweit dann mit Algorithmen und einer dazu passenden Automatisierung (neue) Erkenntnisse ohne langwierigen und teuren manuellen Aufwand gewonnen werden können. Einige Unternehmen werden feststellen, dass ihr eigener – vielleicht einzigartiger – Datenschatz einen echten monetären Wert hat!

Fazit:

Machine-Learning ist eine interessante Challenge für Architekten. Folgende Punkte sollte man bei künftigen Initiativen berücksichtigen:

  • Das richtige Geschäftsproblem bzw. geeignete Use-Cases finden.
  • Identifizieren und definieren der Einschränkungen für die zu lösende Aufgabenstellung, sind z.B. genug Daten vorhanden?
  • Zeit nehmen für das Design von Komponenten und Schnittstellen.
  • Berücksichtigung von möglichen organisatorischen Gegebenheiten und Einschränkungen.
  • Nicht erst zum Schluss an die Produktivsetzung der analytischen Modelle oder Machine-Learning-Produkte denken.
  • Der Prozess ist insgesamt eine Menge Arbeit, aber es ist keine Raketenwissenschaft.

 


Harald Erb arbeitet als Sales Engineer für Snowflake Computing und unterstützt mitteleuropäische Unternehmen bei Aufbau/Modernisierung ihrer Data Warehouse-Architektur. Zuvor war er in seiner 20-jährigen Analytics-Laufbahn bei Hitachi Vantara als Solutions Consultant im Bereich Data Analytics & IoT tätig und hatte bei Oracle verschiedene Rollen als Consultant, Projektleiter und Architekt in der EMEA-Region inne. Sein Interesse gilt dem Design und der Umsetzung moderner Smart-Data-Plattformen. Zu seinen Spezialgebieten gehören Business Analytics, Data Warehousing, Datenintegration und Data Discovery.

Linkedin
Email
Webseite

K. Bollhöfer: „Data Science – the what, the why and the how!“, Präsentation von The unbelievable Machine Company, 2015
Carlton E. Sapp: “Preparing and Architecting for Machine Learning”, Gartner, 2017

 

Total
0
Shares
Previous Post

Warum wir Blockchain (nicht) brauchen

Next Post

Office – datenschutzkonform ?

Related Posts

Ein Ansatz für Cloud-Transformation und Cloud-Migration – erster Teil

Die anhaltende COVID 19-Pandemie stellt fast alle Branchen vor neue Herausforderungen. Sie hat erhebliche Auswirkungen auf Geschäfts- und Betriebsmodelle. Unternehmen denken darüber nach, wie sie ihr Geschäft für solch große Störungen robuster gestalten können, wie sie schneller Neurungen einbringen und ihren Kunden neue Dienstleistungen anbieten können, wie sie die Gesamtbetriebskosten senken können und wie sie bessere Konnektivität und Zusammenarbeit ermöglichen können. Solche Herausforderungen gab es auch schon vor der Pandemie, aber sie sind jetzt noch relevanter und wichtiger geworden!
Avatar
Read More