Über unsMediaKontaktImpressum
Harald Erb 27. November 2018

Machine Learning – eine Challenge für Architekten

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 Know-how 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 Bedarfe 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 5 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 vs. 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 [1]. Prozessmodelle, wie das ab 1996 im Rahmen eines EU-Förderprojekts entwickelte CRISP-DM (CRoss-Industry Standard Process for Data Mining) [2], und Best Practices zur Organisation erfolgreich arbeitender Data-Science-Teams [3] 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 den beteiligten Funktionen gegenüber und fasst Erfahrungen aus der Praxis zusammen [4]. 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 des 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.

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

Konzeptionelle Architektur für Machine Learning und Analytics

Die Nutzung aller verfügbaren Daten für Analyse und 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 da gewesen 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 [6], ausgerichtet auf Analytics und Machine Learning.

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 Prozesszeitfenster. 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,...) 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-/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 oben 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 Technologie-Mix 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 soll nach unbekannten Gründen für den zu hohen Ausschuss gesucht 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 Modell-Versionierung, -Deployment und -Tracking in der Produktionsumgebung oder bei der Automatisierung des Re-Trainings.

Die Bereiche Analyse und Deliver zeigen in Abb. 3 einige bekannte Analysefähigkeiten, wie z. B. die Bereitstellung eines Standardreportings, 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 API’s 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 Softwaresuite zum Entwickeln und Ausführen von Python-Programmen. Funktionen wie Introspektion, Befehlszeilenergänzung, Rich-Media-Einbettung und verschiedene Frontends (Terminal, qt-basiert oder browserbasiert) ermöglichen es, Python-Anwendungen als auch Machine-Learning-Projekte komfortabel zu entwickeln und gleichzeitig zu dokumentieren. Datenanalysten sind bei der Arbeit mit Jupyter nicht auf Python als Programmiersprache begrenzt, sondern können ebenso auch sog. 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 [7]). 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.

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: TensorFlow 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 [8] 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 und 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 Deep-Learning-Frameworks sehr gut eignen.

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. D. h. 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, R- und Python-Code bei der Analyse auszuführen, öffnen auch Fachanwendern die Tür zur Welt des Machine Learnings. Abb. 6 zeigt Oracle Data Visualization bei der Analyse kalifornischer Hauspreise (gleicher 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 ist 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" [9]. Fraglich ist dagegen der Nutzen, wenn man im Data Flow Editor [10] eins 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.

Machine-Learning-Orchestrierung mit Datenintegrations-Werkzeugen

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.

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 your own 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 TensorFlow-Backend) zur Analyse unstrukturierter Daten (Bilder, Videos etc.) umgesetzt [11] und dabei (soweit vorhanden und bei entsprechender Konfiguration) Grafikprozessoren (GPU’s) für bessere Performance genutzt werden.

PDI bietet außerdem die sog. Plugin-Machine-Intelligence-(PMI-)Erweiterung [12] 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.

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 webbasierte 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 erfolgen entweder durch den Anwender im Einsteiger-, Fortgeschrittenen- oder im Expertenmodus bzw. 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.

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, dass erst durch Operationalisierung von Machine-Learning-Resultaten in der Produktionsumgebung ein echter Geschäftswert entsteht und nur im Tagesgeschäft robuste ML-Modelle mit hoher Güte bei der Erreichung der gesteckten Unternehmensziele helfen. 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 TensorFlow, 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 MS 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 (s. 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.

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 Microframeworks 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/-Abhängigkeiten in einem Format verpackt werden, das sowohl in der Data-Science-Sandbox als auch auf Produktionsservern lauffähig ist. Für große Unternehmen kann dies einen langwierigen, komplexen Softwareauslieferungsprozess 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 Webanwendungen reicht und Aspekte wie Loadbalancing und Netzwerkverkehr ausreichend berücksichtigt? Container-Virtualisierung, z. B. mit Docker, zur Isolierung 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 [13] 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 (s. dazu 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 ist 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 [14]. Vorteil dabei: Die Kafka-Streams-Applikation ist selbst eine Java-Applikation, in die der generierte Code des ML-Modells eingebettet werden kann (s. Abb. 14). Alle zukünftigen Events, die neue Immobilien-Datensätze zu Häusern aus Kalifornien mit (denselben) Features wie Geoposition, Alter des Gebäudes, Anzahl 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.

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 Softwareingenieure, die für technische Implementierungen in der Produktionsumgebung zuständig sind und 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-API’s. Data Science-Teams machen hierzu z. B. die URL-Endpunkte ihrer testbereiten Algorithmen bekannt, die von anderen Softwareentwicklern für eigene "smarte" Applikationen konsumiert werden. Durch den Aufbau von REST-API‘s 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 eines Projekts beteiligt sind, bei ihrer Arbeit zu blockieren.

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 Kommandozeileneditor 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 Webframeworks Flask über eine REST-API aufrufbar gemacht. Die in [15] 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 wird. Das ML-Modell selbst verwendet eine sog. ResNet50-Architektur (die Abkürzung steht für 50 Layer Residual Network) und wurde auf Grundlage der öffentlichen ImageNet-Bilddatenbank [16] vortrainiert. Zu dem ML-Modell-Input (in Abb. 15: Tablet Computer) meldet das System für den Tester nachvollziehbar erkannte Gegenstände wie Screen, Hand-held Computer und Monitor zurück, fragliche Klassifikationen sind dagegen iPod und Desktop Computer.

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 [17], 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 Webservers, Loadbalancing, 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[18] dienen. Stellt man dasselbe Bild mit dem Tablet-Computer von Abb. 15 und Abb. 16 bereit, so kann der Google ML-Service den Gegenstand präziser benennen. Bei dem Google ML-Service ist aber noch mehr möglich: Ist auf dem hochgeladenen Bild beispielsweise eine Fußballspielszene zu sehen, liefert der ML-Service weitere Kontextinformationen (Sportart, Bundesliga) und anhand der Gesichtserkennung können die Spieler selbst (Spielername) sowie aktuelle bzw. vorherige Mannschaftszugehörigkeiten bestimmt werden. Damit zeigt sich an diesem Beispiel 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 gewinnen kann. 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:

  • Finden Sie das richtige Geschäftsproblem bzw geeignete Use Cases.
  • Identifizieren und definieren Sie die Einschränkungen (Sind z. B. genug Daten vorhanden?) für die zu lösende Aufgabenstellung.
  • Nehmen Sie sich Zeit für das Design von Komponenten und Schnittstellen.
  • Berücksichtigen Sie mögliche organisatorische Gegebenheiten und Einschränkungen.
  • Denken Sie nicht erst zum Schluss an die Produktivsetzung Ihrer analytischen Modelle oder Machine-Learning-Produkte.
  • Der Prozess ist ingesamt eine Menge Arbeit, aber es ist keine Raketenwissenschaft.

Harald Erb auf den IT-Tagen 2018

Zum gleichen Thema hält Harald Erb einen Vortrag auf den diesjährigen IT-Tagen – der Jahreskonferenz der Informatik Aktuell.

Machine Learning – eine Challenge für Architekten
(11.12.2018, 14:30 Uhr)

Quellen
  1. B. Schmarzo; 2018: What’s the Difference Between Data Integration and Data Engineering?, LinkedIn Pulse
  2. W. Vorhies; 2016: CRISP-DM – a Standard Methodology to Ensure a Good Outcome, Data Science Central
  3. B. Schmarzo; 2018: A Winning Game Plan For Building Your Data Science Team, LinkedIn Pulse
  4. K. Bollhöfer; 2015: Data Science – the what, the why and the how!, Präsentation von The unbelievable Machine Company
  5. D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V. Chaudhary, M. Young, J.-F. Crespo, D. Dennison; 2015: Hidden technical debt in Machine learning systems. In NIPS'15 Proceedings of the 28th International Conference on Neural Information Processing Systems - Volume 2
  6. C. E. Sapp; 2017: Preparing and Architecting for Machine Learning, Gartner
  7. A. Geron; 2018: California Housing, Dataset, Jupyter Notebook
  8. Dr. D. James; 2018: Entscheidungsmatrix "Machine Learning"
  9. Oracle Learning Library: Use Machine Learning Explain to Discover Data Insights
  10. Oracle Analytics@YouTube: Oracle DV - ML Model Comparison Example
  11. K. Wood, M. Hall; 2018: What Can You Do with Deep Learning in Pentaho? In Hitachi Vantara Blog
  12. K. Wood, M. Hall; 2017: Introducing Plug-in Machine Intelligence, Hitachi Vantara Blog
  13. S. Izrailev; 2017: Design Patterns for Machine Learning in Production, Präsentation H2O World
  14. K. Wähner; 2017: How to Build and Deploy Scalable Machine Learning in Production with Apache Kafka, Confluent Blog
  15. A. Rosebrock; 2018: Building a simple Keras + deep learning REST API, The Keras Blog
  16. Stanford Vision Lab: Image database
  17. A. Rosebrock; 2018: A scalable Keras + deep learning REST API
  18. Google Cloud Vision API (Beta Version)

Autor

Harald Erb

Harald Erb arbeitet als Sales Engineer für Snowflake Computing und unterstützt Unternehmen bei der Einführung ihres elastischen Cloud-Data Warehouses.
>> Weiterlesen
Das könnte Sie auch interessieren
botMessage_toctoc_comments_9210