Interview – Customer Data Platform, more than CRM 2.0?

Interview with David M. Raab from the CDP Institute

David M. Raab is as a consultant specialized in marketing software and service vendor selection, marketing analytics and marketing technology assessment. Furthermore he is the founder of the Customer Data Platform Institute which is a vendor-neutral educational project to help marketers build a unified customer view that is available to all of their company systems.

Furthermore he is a Keynote-Speaker for the Predictive Analytics World Event 2019 in Berlin.

Data Science Blog: Mr. Raab, what exactly is a Customer Data Platform (CDP)? And where is the need for it?

The CDP Institute defines a Customer Data Platform as „packaged software that builds a unified, persistent customer database that is accessible by other systems“.  In plainer language, a CDP assembles customer data from all sources, combines it into customer profiles, and makes the profiles available for any use.  It’s important because customer data is collected in so many different systems today and must be unified to give customers the experience they expect.

Data Science Blog: Is it something like a CRM System 2.0? What Use Cases can be realized by a Customer Data Platform?

CRM systems are used to interact directly with customers, usually by telephone or in the field.  They work almost exclusively with data that is entered during those interactions.  This gives a very limited view of the customer since interactions through other channels such as order processing or Web sites are not included.  In fact, one common use case for CDP is to give CRM users a view of all customer interactions, typically by opening a window into the CDP database without needing to import the data into the CRM.  There are many other use cases for unified data, including customer segmentation, journey analysis, and personalization.  Anything that requires sharing data across different systems is a CDP use case.

Data Science Blog: When does a CDP make sense for a company? It is more relevant for retail and financial companies than for industrial companies, isn´t it?

CDP has been adopted most widely in retail and online media, where each customer has many interactions and there are many products to choose from.  This is a combination that can make good use of predictive modeling, which benefits greatly from having more complete data.  Financial services was slower to adopt, probably because they have fewer products but also because they already had pretty good customer data systems.  B2B has also been slow to adopt because so much of their customer relationship is handled by sales people.  We’ve more recently been seeing growth in additional sectors such as travel, healthcare, and education.  Those involve fewer transactions than retail but also rely on building strong customer relationships based on good data.

Data Science Blog: There are several providers for CDPs. Adobe, Tealium, Emarsys or Dynamic Yield, just to name some of them. Do they differ a lot between each other?

Yes they do.  All CDPs build the customer profiles I mentioned.  But some do more things, such as predictive modeling, message selection, and, increasingly, message delivery.  Of course they also vary in the industries they specialize in, regions they support, size of clients they work with, and many technical details.  This makes it hard to buy a CDP but also means buyers are more likely to find a system that fits their needs.

Data Science Blog: How established is the concept of the CDP in Europe in general? And how in comparison with the United States?

CDP is becoming more familiar in Europe but is not as well understood as in the U.S.  The European market spent a lot of money on Data Management Platforms (DMPs) which promised to do much of what a CDP does but were not able to because they do not store the level of detail that a CDP does.  Many DMPs also don’t work with personally identifiable data because the DMPs primarily support Web advertising, where many customers are anonymous.  The failures of DMPs have harmed CDPs because they have made buyers skeptical that any system can meet their needs, having already failed once.  But we are overcoming this as the market becomes better educated and more success stories are available.  What’s the same in Europe and the U.S. is that marketers face the same needs.  This will push European marketers towards CDPs as the best solution in many cases.

Data Science Blog: What are coming trends? What will be the main topic 2020?

We see many CDPs with broader functions for marketing execution: campaign management, personalization, and message delivery in particular.  This is because marketers would like to buy as few systems as possible, so they want broader scope in each systems.  We’re seeing expansion into new industries such as financial services, travel, telecommunications, healthcare, and education.  Perhaps most interesting will be the entry of Adobe, Salesforce, and Oracle, who have all promised CDP products late this year or early next year.  That will encourage many more people to consider buying CDPs.  We expect that market will expand quite rapidly, so current CDP vendors will be able to grow even as Adobe, Salesforce, and Oracle make new CDP sales.


You want to get in touch with Daniel M. Raab and understand more about the concept of a CDP? Meet him at the Predictive Analytics World 18th and 19th November 2019 in Berlin, Germany. As a Keynote-Speaker, he will introduce the concept of a Customer Data Platform in the light of Predictive Analytics. Click here to see the agenda of the event.

 


 

Wie passt Machine Learning in eine moderne Data- & Analytics Architektur?

Einleitung

Aufgrund vielfältiger potenzieller Geschäftschancen, die Machine Learning bietet, arbeiten mittlerweile viele Unternehmen an 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? Machen ML-Funktionen im seit Jahren bewährten ETL-Tool oder in der Datenbank 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, Machine Learning-Komponenten in ETL- und Datenvisualisierungs­werkzeugen 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 vonein­ander 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. Bild 1 stellt in einem Schwimmbahnen-Diagramm einzelne Phasen des Data Science Prozesses den beteiligten Funktionen gegenüber und fasst Erfahrungen aus der Praxis zusammen [5]. 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 Ergebnisses 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.

Abbildung 1: Beteiligung und Interaktion von Fachbereichs-/IT-Funktionen mit dem Data Science Team

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 den kleinen schwarzen Kasten in der Mitte von Bild 2) gering ist, wenn man dies mit der Bereitstellung der umfangreichen und komplexen Infrastruktur inklusive Managementfunktionen vergleicht [4].

Abbildung 2: Versteckte technische Anforderungen in maschinellen Lernsystemen

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. Bild 3 zeigt hierzu eine vierstufige Architektur nach Gartner [6], ausgerichtet auf Analytics und Machine Learning.

Abbildung 3: Konzeptionelle End-to-End Architektur für Machine Learning und Analytics

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 entsteht 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,…) für die spätere Analyse auf.

Bezogen auf den Bereich Acquire bewältigt die IT-Architektur in Bild 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 zum Persistieren 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 Datenauf­bewahrung 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 sog. 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 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 Modell-Versionierung, -Deployment und -Tracking in der Produktions­umgebung oder bei der Automatisierung des Re-Trainings.

Die Bereiche Analyze und Deliver zeigen in Bild 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 Produktions­umgebung inklusive Absicherung gegen unerwünschten Zugriff.

Ein 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 Editoren (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 Juypter 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. Bild 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.

 

Abbildung 4: Datenbeschaffung, Inspektion, Visualisierung und ML Modell-Training in einem Jupyter Notebook (Pro-grammiersprache: Python)

Ein Problem, auf das man bei der praktischen Arbeit mit lokalen Jupyter-Installationen schnell stößt, lässt sich mit dem “works on my machine”-Syndrom bezeichnen. Kleine Data Sets funktionieren problemlos auf einem lokalen Rechner, wenn sie aber auf die Größe des Produktionsdatenbestandes migriert werden, skaliert das Einlesen und Verarbeiten aller Daten mit einem einzelnen Rechner nicht. Aufgrund dieser Begrenzung liegt der Aufbau einer server-basierten ML-Umgebung mit ausreichend Rechen- und Speicherkapazität auf der Hand. Dabei ist aber die Einrichtung einer solchen ML-Umgebung, insbesondere bei einer on-premise Infrastruktur, eine Herausforderung: Das Infrastruktur-Team muss physische Server und/oder virtuelle Maschinen (VM’s) auf Anforderung bereitstellen und integrieren. Dieser Ansatz ist aufgrund vieler manueller Arbeitsschritte zeitaufwändig und fehleranfällig. Mit dem Einsatz Cloud-basierter Technologien vereinfacht sich dieser Prozess deutlich. Die Möglichkeit, Infrastructure on Demand zu verwenden und z.B. mit einem skalierbaren Cloud-Data Warehouse zu kombinieren, bietet sofortigen Zugriff auf Rechen- und Speicher-Ressourcen, wann immer sie benötigt werden und reduziert den administrativen Aufwand bei Einrichtung und Verwaltung der zum Einsatz kommenden ML-Software. Bild 5 zeigt den Code-Ausschnitt aus einem Jupyter Notebook, das im Rahmen des Cloud Services Amazon SageMaker bereitgestellt wird und via PySpark Kernel auf einen Multi-Node Apache Spark Cluster (in einer Amazon EMR-Umgebung) zugreift. In diesem Szenario wird aus einem Snowflake Cloud Data Warehouse ein größeres Data Set mit 220 Millionen Datensätzen via Spark-Connector komplett in ein Spark Dataframe geladen und im Spark Cluster weiterverarbeitet. Den vollständigen Prozess inkl. Einrichtung und Konfiguration aller Komponenten, beschreibt eine vierteilige Blog-Serie [8]). Mit Spark Cluster sowie Snowflake stehen für sich genommen zwei leistungsfähige Umgebungen für rechenintensive Aufgaben zur Verfügung. Mit dem aktuellen Snowflake Connector für Spark ist eine intelligente Arbeitsteilung mittels Query Pushdown erreichbar. Dabei entscheidet Spark’s optimizer (Catalyst), welche Aufgaben (Queries) aufgrund der effizienteren Verarbeitung an Snowflake delegiert werden [9].

Abbildung 5: Jupyter Notebook in der Cloud – integriert mit Multi-Node Spark Cluster und Snowflake Cloud Data Warehouse

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. Bild 6 zeigt eine kompakte Entscheidungsmatrix [10] 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 Deep Learning Frameworks sehr gut eignen.

Abbildung 6: Entscheidungsmatrix zu aktuell verbreiteten Machine Learning Frameworks

Self-Service Machine Learning in Business Intelligence-Tools

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. Statt statische Berichte oder Excel-Dateien vor dem nächsten Meeting zu verschicken, erlauben moderne Besprechungs- und Kreativräume interaktive Datenanalysen am Smartboard inklusive Änderung 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 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.

Abbildung 7: Datenexploration in Tableau – leicht gemacht für Fachanwender und Data Scientists

 

Zusätzliche Statistikfunktionen bis hin zur Möglichkeit R- und Python-Code bei der Analyse auszuführen, öffnet auch Fachanwender die Tür zur Welt des Maschinellen Lernens. Bild 7 zeigt das Werkzeug Tableau Desktop mit der Analyse kalifornischer Hauspreise (demselben Datensatz wie oben im Jupyter Notebook-Abschnitt wie in Bild 4) 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 Bild 7 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, benötigen Citizen Data Scientists (eine Wortschöpfung von Gartner) allerdings dann doch die mathematischen bzw. statistischen Grundlagen, um Falschinterpretationen zu vermeiden. Fraglich ist auch der Nutzen des Data Flow Editors [11] in Oracle Data Visualization, mit dem eins oder mehrere der im Werkzeug integrierten Machine Learning-Modelle trainiert und evaluiert werden können: technisch lassen sich Ergebnisse erzielen und anhand einiger Performance-Metriken die Modellgüte auch bewerten bzw. mit anderen Modellen vergleichen – aber wer kann die erzielten Ergebnisse (wissenschaftlich) verteidigen? Gleiches gilt für die Integration vorhandener R- und Python Skripte, die am Ende dann doch eine Einweisung der Anwender bzgl. Parametrisierung der ML-Modelle und Interpretationshilfen bei den erzielten Ergebnissen erfordern.

Machine Learning in und mit Datenbanken

Die Nutzung eingebetteter 1-click Analytics-Funktionen der oben vorgestellten Data Visualization-Tools ist zweifellos komfortabel und zum schnellen Experimentieren geeignet. Der gegenteilige und eher puristische Ansatz wäre dagegen die Implementierung eigener Machine Learning Modelle in der Datenbank. Für die Umsetzung des gewählten Algorithmus reichen schon vorhandene Bordmittel in der Datenbank aus: SQL inklusive mathematischer und statistische SQL-Funktionen, Tabellen zum Speichern der Ergebnisse bzw. für das ML-Modell-Management und Stored Procedures zur Abbildung komplexer Geschäftslogik und auch zur Ablaufsteuerung. Solange die Algorithmen ausreichend skalierbar sind, gibt es viele gute Gründe, Ihre Data Warehouse Engine für ML einzusetzen:

  • Einfachheit – es besteht keine Notwendigkeit, eine andere Compute-Plattform zu managen, zwischen Systemen zu integrieren und Daten zu extrahieren, transferieren, laden, analysieren usw.
  • Sicherheit – Die Daten bleiben dort, wo sie gut geschützt sind. Es ist nicht notwendig, Datenbank-Anmeldeinformationen in externen Systemen zu konfigurieren oder sich Gedanken darüber zu machen, wo Datenkopien verteilt sein könnten.
  • Performance – Eine gute Data Warehouse Engine verwaltet zur Optimierung von SQL Abfragen viele Metadaten, die auch während des ML-Prozesses wiederverwendet werden könnten – ein Vorteil gegenüber General-purpose Compute Plattformen.

Die Implementierung eines minimalen, aber legitimen ML-Algorithmus wird in [12] am Beispiel eines Entscheidungsbaums (Decision Tree) im Snowflake Data Warehouse gezeigt. Decision Trees kommen für den Aufbau von Regressions- oder Klassifikationsmodellen zum Einsatz, dabei teilt man einen Datensatz in immer kleinere Teilmengen auf, die ihrerseits in einem Baum organisiert sind. Bild 8 zeigt die Snowflake Benutzer­oberfläche und ein Ausschnitt von der Stored Procedure, die dynamisch alle SQL-Anweisungen zur Berechnung des Decision Trees nach dem ID3 Algorithmus [13] generiert.

Abbildung 8: Snowflake SQL-Editor mit Stored Procedure zur Berechnung eines Decission Trees

Allerdings ist der Entwicklungs- und Implementierungsprozess für ein Machine Learning Modell umfassender: Es sind relevante Daten zu identifizieren und für das ML-Modell vorzubereiten. Einfach Rohdaten bzw. nicht aggregierten Informationen aus Datenbanktabellen zu extrahieren reicht nicht aus, stattdessen benötigt ein ML-Modell als Input eine flache, meist sehr breite Tabelle mit vielen Aggregaten, die als Features bezeichnet werden. Erst dann kann der Prozess fortgesetzt und der für die Aufgabenstellung ausgewählte Algorithmus trainiert und die Modellgüte bewertet werden. Ist das Ergebnis zufriedenstellend, steht die Implementierung des ML-Modells in der Zielumgebung an und muss sich künftig beim Scoring „frischer Datensätze“ bewähren. Viele zeitaufwändige Teilaufgaben also, bei der zumindest eine Teilautomatisierung wünschenswert wäre. Allein die Datenaufbereitung kann schon bis zu 70…80% der gesamten Projektzeit beanspruchen. Und auch die Implementierung eines ML-Modells wird häufig unterschätzt, da in Produktionsumgebungen der unterstützte Technologie-Stack definiert und ggf. für Machine Learning-Aufgaben erweitert werden muss. Daher ist es reizvoll, wenn das Datenbankmanagement-System auch hier einsetzbar ist – sofern die geforderten Algorithmen dort abbildbar sind. Wie ein ML-Modell für die Kundenabwanderungsprognose (Churn Prediction) werkzeuggestützt mit Xpanse AI entwickelt und beschleunigt im Snowflake Cloud Data Warehouse bereitgestellt werden kann, beschreibt [14] sehr anschaulich: Die benötigten Datenextrakte sind schnell aus Snowflake entladen und stellen den Input für ein neues Xpanse AI-Projekt dar. Sobald notwendige Tabellenverknüpfungen und andere fachliche Informationen hinterlegt sind, analysiert das Tool Datenstrukturen und transformiert alle Eingangstabellen in eine flache Zwischentabelle (u.U. mit Hunderten von Spalten), auf deren Basis im Anschluss ML-Modelle trainiert werden. Nach dem ML-Modell-Training erfolgt die Begutachtung der Ergebnisse: das erstellte Dataset, Güte des ML-Modells und der generierte SQL(!) ETL-Code zur Erstellung der Zwischentabelle sowie die SQL-Repräsentation des ML-Modells, das basierend auf den Input-Daten Wahrscheinlichkeitswerte berechnet und in einer Scoring-Tabelle ablegt. Die Vorteile dieses Ansatzes sind liegen auf der Hand: kürzere Projektzeiten, der Einsatz im Rahmen des Snowflake Cloud Data Warehouse, macht das Experimentieren mit der Zuweisung dedizierter Compute-Ressourcen für die performante Verarbeitung äußerst einfach. Grenzen liegen wiederum bei der zur Verfügung stehenden Algorithmen.

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. Bild 9 zeigt wieder anhand des Datensatzes zur Analyse der kalifornischen Hauspreise die webbasierte Benutzeroberfläche H20 Flow, die den oben beschriebenen Juypter 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.

Abbildung 9: H2O Flow Benutzeroberfläche – Datenaufbereitung, ML-Modell-Training und Evaluierung.

Vom Prototyp 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 Initativen noch als schwierig. Bild 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 anderere 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 Bild 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.

Abbildung 10: Übergabe von Machine Learning-Resultaten zur Produktivsetzung im Echtbetrieb

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/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 [15] 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, Versions­management 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 dazu Bild 11)

Abbildung 11: Unterstützende Funktionen für produktive Machine Learning-Lösungen

Die Deployment-Variante „Machine Learning Code-Generierung“ lässt sich gut an dem bereits mit H2O Flow besprochenen Beispiel veranschaulichen. Während Bild 9 hierzu die Schritte für Modellaufbau, -training und -test illustriert, zeigt Bild 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, Bild 13 gibt mit den ersten Programmzeilen einen ersten Eindruck dazu und erinnert gleichzeitig an den ähnlichen Ansatz der oben mit dem Snowflake Cloud Data Warehouse und dem Tool Xpanse AI bereits beschrieben wurde.

Abbildung 12: H2O Flow Benutzeroberfläche – Java-Code Generierung und Download eines trainierten Models

Abbildung 13: Generierter Java-Code eines Gradient Boosted Machine – Modells zur Vorhersage kaliforn. Hauspreise

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 [16]. Vorteil dabei: Die Kafka Streams-Applikation ist selbst eine Java-Applikation, in die der generierte Code des ML-Modells eingebettet werden kann (siehe Bild 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.

Abbildung 14: Deployment des generierten Java-Codes eines H2O ML-Models in einer Kafka Streams-Applikation

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, womöglich einen völlig anderen Technologie-Stack verwenden (müssen). Im Extremfall droht das Neuimplementieren 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.

Bild 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 [17] 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 [18] vortrainiert. Zu dem ML-Modell-Input (in Bild 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).

Abbildung 15: Gegenstandserkennung mit Machine Learning und vorgegebenen Bildern via REST-Service

Bei Aufbau und Bereitstellung von Machine Learning-Funktionen mittels REST-API’s 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 [19], 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, Load Balancers, 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 [20] dienen. Stellt man dasselbe Bild mit der Fußballspielszene von Bild 15 und Bild 16 bereit, so erkennt der Google ML-Service neben den Gegenständen weit mehr Informationen: Kontext (Teamsport, Bundesliga), anhand der Gesichtserkennung den Spieler selbst  und aktuelle bzw. vorherige Mannschaftszugehörigkeiten usw. Damit zeigt sich am Beispiel des Tech-Giganten auch ganz klar: Es kommt vorallem 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 einzigartige – Datenschatz einen echten monetären Wert hat?

Abbildung 16: Machine Learning Bezahlprodukt (Google Vision)

Fazit

Machine Learning ist eine interessante “Challenge” für Architekten. Folgende Punkte sollte man bei künftigen Initativen 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 frühzeitig 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 insgesamt eine Menge Arbeit, aber es ist keine Raketenwissenschaft.

Quellenverzeichnis

[1] Bill Schmarzo: “What’s the Difference Between Data Integration and Data Engineering?”, LinkedIn Pulse -> Link, 2018
[2] William Vorhies: “CRISP-DM – a Standard Methodology to Ensure a Good Outcome”, Data Science Central -> Link, 2016
[3] Bill Schmarzo: “A Winning Game Plan For Building Your Data Science Team”, LinkedIn Pulse -> Link, 2018
[4] D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V. Chaudhary, M. Young, J.-F. Crespo, D. Dennison: “Hidden technical debt in Machine learning systems”. In NIPS’15 Proceedings of the 28th International Conference on Neural Information Processing Systems – Volume 2, 2015
[5] K. Bollhöfer: „Data Science – the what, the why and the how!“, Präsentation von The unbelievable Machine Company, 2015
[6] Carlton E. Sapp: “Preparing and Architecting for Machine Learning”, Gartner, 2017
[7] A. Geron: “California Housing” Dataset, Jupyter Notebook. GitHub.com -> Link, 2018
[8] R. Fehrmann: “Connecting a Jupyter Notebook to Snowflake via Spark” -> Link, 2018
[9] E. Ma, T. Grabs: „Snowflake and Spark: Pushing Spark Query Processing to Snowflake“ -> Link, 2017
[10] Dr. D. James: „Entscheidungsmatrix „Machine Learning“, it-novum.com ->  Link, 2018
[11] Oracle Analytics@YouTube: “Oracle DV – ML Model Comparison Example”, Video -> Link
[12] J. Weakley: Machine Learning in Snowflake, Towards Data Science Blog -> Link, 2019
[13] Dr. S. Sayad: An Introduction to Data Science, Website -> Link, 2019
[14] U. Bethke: Build a Predictive Model on Snowflake in 1 day with Xpanse AI, Blog à Link, 2019
[15] Sergei Izrailev: Design Patterns for Machine Learning in Production, Präsentation H2O World, 2017
[16] K. Wähner: How to Build and Deploy Scalable Machine Learning in Production with Apache Kafka, Confluent Blog -> Link, 2017
[17] A. Rosebrock: “Building a simple Keras + deep learning REST API”, The Keras Blog -> Link, 2018
[18] Stanford Vision Lab, Stanford University, Princeton University: Image database, Website -> Link
[19] A. Rosebrock: “A scalable Keras + deep learning REST API”, Blog -> Link, 2018
[20] Google Cloud Vision API (Beta Version) -> Link, abgerufen 2018

 

 

 

 

Whitepaper „Data-Management“: Wenn Daten auf Reisen gehen

Datenmanagement ist heutzutage ein komplexes Thema und schon lange nicht mehr nur die Aufgabe der Abteilung „EDV“. Unstrukturierte Daten von Sensoren, Maschinen und Anlagen haben einen langen Weg durch das Unternehmen, bevor sie Mehrwerte liefern.

Innovative, digitale Kundenservices erfordern neue Infrastrukturen und Cloudanwendungen in der Umsetzung. Wie Sie mit Ihren Daten auf Reisen gehen, ohne unnötige Risiken einzugehen, zeigt Ihnen das gut gelaunte Autorenteam in der praktischen Sommerausgabe dieses Whitepapers. Erfrischend geschrieben, konstruktiv beispielhaft und mit einer optischen Aufmachung, die auch am Strand einen guten Eindruck macht.

Die gut umgesetzte Idee der Autoren können Sie sich als Download oder sogar als Taschenbuch kostenlos zuschicken lassen. Auf der Website www.pack-die-daten-ein.de werden Sie fündig. Wer sich schnell auf die Datenreise begibt, wird belohnt. Das Autorenteam bedankt sich bei den ersten 25 Lesern für ihr Interesse mit einer Original OGIO-Reisetasche. Ob Download oder Taschenbuch, es ist ein sehr angenehmer Service und Bereicherung für die Sommerreise.

Whitepaper - Pack die Daten ein

Von BI zu PI: Der nächste Schritt auf dem Weg zu datengetriebenen Entscheidungen

„Alles ist stetig und fortlaufend im Wandel.“ „Das Tempo der Veränderungen nimmt zu.“ „Die Welt wird immer komplexer und Unternehmen müssen Schritt halten.“ Unternehmen jeder Art und Größe haben diese Sätze schon oft gehört – vielleicht zu oft! Und dennoch ist es für den Erfolg eines Unternehmens von entscheidender Bedeutung, sich den Veränderungen anzupassen.


Read this article in English: 
“From BI to PI: The Next Step in the Evolution of Data-Driven Decisions”


Sie müssen die zugrunde liegenden organisatorischen Bausteine verstehen, um sicherzustellen, dass die von Ihnen getroffenen Entscheidungen sich auch in die richtige Richtung entwickeln. Es geht sozusagen um die DNA Ihres Unternehmens: die Geschäftsprozesse, auf denen Ihre Arbeitsweise basiert, und die alles zu einer harmonischen Einheit miteinander verbinden. Zu verstehen, wie diese Prozesse verlaufen und an welcher Stelle es Verbesserungsmöglichkeiten gibt, kann den Unterschied zwischen Erfolg und Misserfolg ausmachen.

Unternehmen, die ihren Fokus auf Wachstum gesetzt haben, haben dies bereits erkannt. In der Vergangenheit wurde Business Intelligence als die Lösung für diese Herausforderung betrachtet. In jüngerer Zeit sehen sich zukunftsorientierte Unternehmen damit konfrontiert, Lösungen zu überwachen, die mit dem heutigen Tempo der Veränderungen Schritt halten können. Gleichzeitig erkennen diese Unternehmen, dass die zunehmende Komplexität der Geschäftsprozesse dazu führt, dass herkömmliche Methoden nicht mehr ausreichen.

Anpassung an ein sich änderndes Umfeld? Die Herausforderungen von BI

Business Intelligence ist nicht notwendigerweise überholt oder unnötig. In einer schnelllebigen und sich ständig verändernden Welt stehen die BI-Tools und -Lösungen jedoch vor einer Reihe von Herausforderungen. Hierzu können zählen:

  • Hohe Datenlatenz – Die Datenlatenz gibt an, wie lange ein Benutzer benötigt, um Daten beispielsweise über ein Business-Intelligence-Dashboard abzurufen. In vielen Fällen kann dies mehr als 24 Stunden dauern. Ein geschäftskritischer Zeitraum, da Unternehmen Geschäftschancen für sich nutzen möchten, die möglicherweise ein begrenztes Zeitfenster haben.
  • Unvollständige Datensätze – Business Intelligence verfolgt einen breiten Ansatz, sodass Prüfungen möglicherweise zwar umfassend, aber nicht tief greifend sind. Dies erhöht die Wahrscheinlichkeit, dass Daten übersehen werden; insbesondere in Fällen, in denen die Prüfungsparameter durch die Tools selbst nur schwer geändert werden können.
  • Erkennung statt Analyse – Business-Intelligence-Tools sind in erster Linie darauf ausgelegt, Daten zu finden. Der Fokus hierbei liegt vor allem auf Daten, die für ihre Benutzer nützlich sein können. An dieser Stelle endet jedoch häufig die Leistungsfähigkeit der Tools, da sie Benutzern keine einfachen Optionen bieten, die Daten tatsächlich zu analysieren. Die Möglichkeit, umsetzbare Erkenntnisse zu gewinnen, verringert sich somit.
  • Eingeschränkte Skalierbarkeit – Im Allgemeinen bleibt Business Intelligence ein Bereich für Spezialisten und Experten mit dem entsprechenden Know-how, über das Mitarbeiter im operativen Bereich oftmals nicht verfügen. Ohne umfangreiches Verständnis für die geschäftlichen Prozesse und deren Analyse innerhalb des Unternehmens bleibt die optimierte Anwendung eines bestimmten Business-Intelligence-Tools aber eingeschränkt.
  • Nicht nachvollziehbare Metriken – Werden Metriken verwendet, die nicht mit den Geschäftsprozessen verknüpft sind, kann Business Intelligence kaum positive Veränderungen innerhalb eines Unternehmens unterstützen. Für Benutzer ist es schwierig, Ergebnisse richtig auszuwerten und zu verstehen und diese Ergebnisse zweckdienlich zu nutzen.

Process Intelligence: der nächste wegweisende Schritt

Es bedarf einer effektiveren Methode zur Prozessanalyse, um eine effiziente Arbeitsweise und fundierte Entscheidungsfindung sicherzustellen. An dieser Stelle kommt Process Intelligence (PI) ins Spiel. PI bietet die entscheidenden Hintergrundinformationen für die Beantwortung von Fragen, die mit Business-Intelligence-Tools unbeantwortet bleiben.

Process Intelligence ermöglicht die durchgehende Visualisierung von Prozessabläufen mithilfe von Rohdaten. Mit dem richtigen Process-Intelligence-Tool können diese Rohdaten sofort analysiert werden, sodass Prozesse präzise angezeigt werden. Der Endbenutzer kann diese Informationen nach Bedarf einsehen und bearbeiten, ohne eine Vorauswahl für die Analyse treffen zu müssen.

Zum Vergleich: Da Business Intelligence vordefinierte Analysekriterien benötigt, kann BI nur dann wirklich nützlich sein, wenn diese Kriterien auch definiert sind. Unternehmen können verzögerte Analysen vermeiden, indem sie Process Intelligence zur Ermittlung der Hauptursache von Prozessproblemen nutzen, und dann die richtigen Kriterien zur Bestimmung des Analyserahmens auswählen.

Anschließend können Sie Ihre Systemprozesse analysieren und erkennen die Diskrepanzen und Varianten zwischen dem angestrebten Geschäftsprozess und dem tatsächlichen Verlauf Ihrer Prozesse. Und je schneller Sie Echtzeit-Einblicke in Ihre Prozesse gewinnen, desto schneller können Sie in Ihrem Unternehmen positive Veränderungen auf den Weg bringen.

Kurz gesagt: Business Intelligence eignet sich dafür, ein breites Verständnis über die Abläufe in einem Unternehmen zu gewinnen. Für einige Unternehmen kann dies ausreichend sein. Für andere hingegen ist ein Überblick nicht genug.

Sie suchen nach einer Möglichkeit um festzustellen, wie jeder Prozess in Ihrer Organisation tatsächlich funktioniert? Die Antwort hierauf lautet Software. Software, die Prozesserkennung, Prozessanalyse und Konformitätsprüfung miteinander kombiniert.

Mit den richtigen Process-Intelligence-Tools können Sie nicht nur Daten aus den verschiedenen IT-Systemen in Ihrem Unternehmen gewinnen, sondern auch Ihre End-to-End-Prozesse kontinuierlich überwachen. So erhalten Sie Erkenntnisse über mögliche Risiken und Verbesserungspotenziale. PI steht für einen kollaborativen Ansatz zur Prozessverbesserung, der zu einem bahnbrechenden Verständnis über die Abläufe in Ihrem Unternehmen führt, und wie diese optimiert werden können.

Erhöhtes Potenzial mit Signavio Process Intelligence

Mit Signavio Process Intelligence erhalten Sie wegweisende Erkenntnisse über Ihre Prozesse, auf deren Basis Sie bessere Geschäftsentscheidungen treffen können. Erlangen Sie eine vollständige Sicht auf Ihre Abläufe und ein Verständnis dafür, was in Ihrer Organisation tatsächlich geschieht.

Als Teil der Signavio Business Transformation Suite lässt sich Signavio Process Intelligence perfekt mit der Prozessmodellierung und -automatisierung kombinieren. Als eine vollständig cloudbasierte Process-Mining-Lösung erleichtert es die Software, organisationsweit zusammenzuarbeiten und Wissen zu teilen.

Generieren Sie neue Ideen, sparen Sie Aufwand und Kosten ein und optimieren Sie Ihre Prozesse. Erfahren Sie mehr über Signavio Process Intelligence.

Erstellen und benutzen einer Geodatenbank

In diesem Artikel soll es im Gegensatz zum vorherigen Artikel Alles über Geodaten weniger darum gehen, was man denn alles mit Geodaten machen kann, dafür aber mehr darum wie man dies anstellt. Es wird gezeigt, wie man aus dem öffentlich verfügbaren Datensatz des OpenStreetMap-Projekts eine Geodatenbank erstellt und einige Beispiele dafür gegeben, wie man diese abfragen und benutzen kann.

Wahl der Datenbank

Prinzipiell gibt es zwei große “geo-kompatible” OpenSource-Datenbanken bzw. “Datenbank-AddOn’s”: Spatialite, welches auf SQLite aufbaut, und PostGIS, das PostgreSQL verwendet.

PostGIS bietet zum Teil eine einfachere Syntax, welche manchmal weniger Tipparbeit verursacht. So kann man zum Beispiel um die Entfernung zwischen zwei Orten zu ermitteln einfach schreiben:

während dies in Spatialite “nur” mit einer normalen Funktion möglich ist:

Trotztdem wird in diesem Artikel Spatialite (also SQLite) verwendet, da dessen Einrichtung deutlich einfacher ist (schließlich sollen interessierte sich alle Ergebnisse des Artikels problemlos nachbauen können, ohne hierfür einen eigenen Datenbankserver aufsetzen zu müssen).

Der Hauptunterschied zwischen PostgreSQL und SQLite (eigentlich der Unterschied zwischen SQLite und den meissten anderen Datenbanken) ist, dass für PostgreSQL im Hintergrund ein Server laufen muss, an welchen die entsprechenden Queries gesendet werden, während SQLite ein “normales” Programm (also kein Client-Server-System) ist welches die Queries selber auswertet.

Hierdurch fällt beim Aufsetzen der Datenbank eine ganze Menge an Konfigurationsarbeit weg: Welche Benutzer gibt es bzw. akzeptiert der Server? Welcher Benutzer bekommt welche Rechte? Über welche Verbindung wird auf den Server zugegriffen? Wie wird die Sicherheit dieser Verbindung sichergestellt? …

Während all dies bei SQLite (und damit auch Spatialite) wegfällt und die Einrichtung der Datenbank eigentlich nur “installieren und fertig” ist, muss auf der anderen Seite aber auch gesagt werden dass SQLite nicht gut für Szenarien geeignet ist, in welchen viele Benutzer gleichzeitig (insbesondere schreibenden) Zugriff auf die Datenbank benötigen.

Benötigte Software und ein Beispieldatensatz

Was wird für diesen Artikel an Software benötigt?

SQLite3 als Datenbank

libspatialite als “Geoplugin” für SQLite

spatialite-tools zum erstellen der Datenbank aus dem OpenStreetMaps (*.osm.pbf) Format

python3, die beiden GeoModule spatialite, folium und cartopy, sowie die Module pandas und matplotlib (letztere gehören im Bereich der Datenauswertung mit Python sowieso zum Standart). Für pandas gibt es noch die Erweiterung geopandas sowie eine praktisch unüberschaubare Anzahl weiterer geographischer Module aber bereits mit den genannten lassen sich eine Menge interessanter Dinge herausfinden.

– und natürlich einen Geodatensatz: Zum Beispiel sind aus dem OpenStreetMap-Projekt extrahierte Datensätze hier zu finden.

Es ist ratsam, sich hier erst einmal einen kleinen Datensatz herunterzuladen (wie zum Beispiel einen der Stadtstaaten Bremen, Hamburg oder Berlin). Zum einen dauert die Konvertierung des .osm.pbf-Formats in eine Spatialite-Datenbank bei größeren Datensätzen unter Umständen sehr lange, zum anderen ist die fertige Datenbank um ein vielfaches größer als die stark gepackte Originaldatei (für “nur” Deutschland ist die fertige Datenbank bereits ca. 30 GB groß und man lässt die Konvertierung (zumindest am eigenen Laptop) am besten über Nacht laufen – willkommen im Bereich “BigData”).

Erstellen eine Geodatenbank aus OpenStreetMap-Daten

Nach dem Herunterladen eines Datensatzes der Wahl im *.osm.pbf-Format kann hieraus recht einfach mit folgendem Befehl aus dem Paket spatialite-tools die Datenbank erstellt werden:

Erkunden der erstellten Geodatenbank

Nach Ausführen des obigen Befehls sollte nun eine Datei mit dem gewählten Namen (im Beispiel bremen-latest.sqlite) im aktuellen Ordner vorhanden sein – dies ist bereits die fertige Datenbank. Zunächst sollte man mit dieser Datenbank erst einmal dasselbe machen, wie mit jeder anderen Datenbank auch: Sich erst einmal eine Weile hinsetzen und schauen was alles an Daten in der Datenbank vorhanden und vor allem wo diese Daten in der erstellten Tabellenstruktur zu finden sind. Auch wenn dieses Umschauen prinzipiell auch vollständig über die Shell oder in Python möglich ist, sind hier Programme mit graphischer Benutzeroberfläche (z. B. spatialite-gui oder QGIS) sehr hilfreich und sparen nicht nur eine Menge Zeit sondern vor allem auch Tipparbeit. Wer dies tut, wird feststellen, dass sich in der generierten Datenbank einige dutzend Tabellen mit Namen wie pt_addresses, ln_highway und pg_boundary befinden.

Die Benennung der Tabellen folgt dem Prinzip, dass pt_*-Tabellen Punkte im Geokoordinatensystem wie z. B. Adressen, Shops, Bäckereien und ähnliches enthalten. ln_*-Tabellen enthalten hingegen geographische Entitäten, welche sich als Linien darstellen lassen, wie beispielsweise Straßen, Hochspannungsleitungen, Schienen, ect. Zuletzt gibt es die pg_*-Tabellen welche Polygone – also Flächen einer bestimmten Form enthalten. Dazu zählen Landesgrenzen, Bundesländer, Inseln, Postleitzahlengebiete, Landnutzung, aber auch Gebäude, da auch diese jeweils eine Grundfläche besitzen. In dem genannten Datensatz sind die Grundflächen von Gebäuden – zumindest in Europa – nahezu vollständig. Aber auch der Rest der Welt ist für ein “Wikipedia der Kartographie” insbesondere in halbwegs besiedelten Gebieten bemerkenswert gut erfasst, auch wenn nicht unbedingt davon ausgegangen werden kann, dass abgelegenere Gegenden (z. B. irgendwo auf dem Land in Südamerika) jedes Gebäude eingezeichnet ist.

Verwenden der Erstellten Datenbank

Auf diese Datenbank kann nun entweder direkt aus der Shell über den Befehl

zugegriffen werden oder man nutzt das gleichnamige Python-Paket:

Nach Eingabe der obigen Befehle in eine Python-Konsole, ein Jupyter-Notebook oder ein anderes Programm, welches die Anbindung an den Python-Interpreter ermöglicht, können die von der Datenbank ausgegebenen Ergebnisse nun direkt in ein Pandas Data Frame hineingeladen und verwendet/ausgewertet/analysiert werden.

Im Grunde wird hierfür “normales SQL” verwendet, wie in anderen Datenbanken auch. Der folgende Beispiel gibt einfach die fünf ersten von der Datenbank gefundenen Adressen aus der Tabelle pt_addresses aus:

Link zur Ausgabe

Es wird dem Leser sicherlich aufgefallen sein, dass die Spalte “Geometry” (zumindest für das menschliche Auge) nicht besonders ansprechend sowie auch nicht informativ aussieht: Der Grund hierfür ist, dass diese Spalte die entsprechende Position im geographischen Koordinatensystem aus Gründen wie dem deutlich kleineren Speicherplatzbedarf sowie der damit einhergehenden Optimierung der Geschwindigkeit der Datenbank selber, in binärer Form gespeichert und ohne weitere Verarbeitung auch als solche ausgegeben wird.

Glücklicherweise stellt spatialite eine ganze Reihe von Funktionen zur Verarbeitung dieser geographischen Informationen bereit, von denen im folgenden einige beispielsweise vorgestellt werden:

Für einzelne Punkte im Koordinatensystem gibt es beispielsweise die Funktionen X(geometry) und Y(geometry), welche aus diesem “binären Wirrwarr” den Längen- bzw. Breitengrad des jeweiligen Punktes als lesbare Zahlen ausgibt.

Ändert man also das obige Query nun entsprechend ab, erhält man als Ausgabe folgendes Ergebnis in welchem die Geometry-Spalte der ausgegebenen Adressen in den zwei neuen Spalten Longitude und Latitude in lesbarer Form zu finden ist:

Link zur Tabelle

Eine weitere häufig verwendete Funktion von Spatialite ist die Distance-Funktion, welche die Distanz zwischen zwei Orten berechnet.

Das folgende Beispiel sucht in der Datenbank die 10 nächstgelegenen Bäckereien zu einer frei wählbaren Position aus der Datenbank und listet diese nach zunehmender Entfernung auf (Achtung – die frei wählbare Position im Beispiel liegt in München, wer die selbe Position z. B. mit dem Bremen-Datensatz verwendet, wird vermutlich etwas weiter laufen müssen…):

Link zur Ausgabe

Ein Anwendungsfall für eine solche Liste können zum Beispiel Programme/Apps wie maps.me oder Google-Maps sein, in denen User nach Bäckereien, Geldautomaten, Supermärkten oder Apotheken “in der Nähe” suchen können sollen.

Diese Liste enthält nun alle Informationen die grundsätzlich gebraucht werden, ist soweit auch informativ und wird in den meißten Fällen der Datenauswertung auch genau so gebraucht, jedoch ist diese für das Auge nicht besonders ansprechend.

Viel besser wäre es doch, die gefundenen Positionen auf einer interaktiven Karte einzuzeichnen:

Was kann man sonst interessantes mit der erstellten Datenbank und etwas Python machen? Wer in Deutschland ein wenig herumgekommen ist, dem ist eventuell aufgefallen, dass sich die Endungen von Ortsnamen stark unterscheiden: Um München gibt es Stadteile und Dörfer namens Garching, Freising, Aubing, ect., rund um Stuttgart enden alle möglichen Namen auf “ingen” (Plieningen, Vaihningen, Echterdingen …) und in Berlin gibt es Orte wie Pankow, Virchow sowie eine bunte Auswahl weiterer *ow’s.

Das folgende Query spuckt gibt alle “village’s”, “town’s” und “city’s” aus der Tabelle pt_place, also Dörfer und Städte, aus:

Link zur Ausgabe

Graphisch mit matplotlib und cartopy in ein Koordinatensystem eingetragen sieht diese Verteilung folgendermassen aus:

Die Grafik zeigt, dass stark unterschiedliche Vorkommen der verschiedenen Ortsendungen in Deutschland (Clustering). Über das genaue Zustandekommen dieser Verteilung kann ich hier nur spekulieren, jedoch wird diese vermutlich ähnlichen Prozessen unterliegen wie beispielsweise die Entwicklung von Dialekten.

Wer sich die Karte etwas genauer anschaut wird merken, dass die eingezeichneten Landesgrenzen und Küstenlinien nicht besonders genau sind. Hieran wird ein interessanter Effekt von häufig verwendeten geographischen Entitäten, nämlich Linien und Polygonen deutlich. Im Beispiel werden durch die beiden Zeilen

die bereits im Modul cartopy hinterlegten Daten verwendet. Genaue Verläufe von Küstenlinien und Landesgrenzen benötigen mit wachsender Genauigkeit hingegen sehr viel Speicherplatz, da mehr und mehr zu speichernde Punkte benötigt werden (genaueres siehe hier).

Schlussfolgerung

Man kann also bereits mit einigen Grundmodulen und öffentlich verfügbaren Datensätzen eine ganze Menge im Bereich der Geodaten erkunden und entdecken. Gleichzeitig steht, insbesondere für spezielle Probleme, eine große Bandbreite weiterer Software zur Verfügung, für welche dieser Artikel zwar einen Grundsätzlichen Einstieg geben kann, die jedoch den Rahmen dieses Artikels sprengen würden.

Von der Datenanalyse zur Prozessverbesserung: So gelingt eine erfolgreiche Process-Mining-Initiative

Den Prozessdaten auf der Spur: Systematische Datenanalyse kombiniert mit Prozessmanagement

Die Digitalisierung verändert Organisationen aller Branchen. In zahlreichen Unternehmen werden alltägliche Betriebsabläufe softwarebasiert modelliert, automatisiert und optimiert. Damit hinterlässt fast jeder Prozess elektronische Spuren in den CRM-, ERP- oder anderen IT-Systemen einer Organisation. Process Mining gilt als effektive Methode, um diese Datenspuren zusammenzuführen und für umfassende Auswertungen zu nutzen. Sie kombiniert die systematische Datenanalyse mit Geschäftsprozessmanagement: Dabei werden Prozessdaten aus den verschiedenen IT-Systemen einer Organisation extrahiert und mit Hilfe von Data-Science-Technologien visualisiert und ausgewertet.


Read this article in English: From BI to PI: The Next Step in the Evolution of Data-Driven Decisions

 


Professionelle Process-Mining-Lösungen erlauben, die Ergebnisse dieser Prozessauswertungen auf Dashboards darzustellen und nach bestimmten Prozessen, Transaktionen, Abteilungen oder Kunden zu filtern. So ist es möglich, die Performance, Durchlaufzeiten und die Kosten einzelner Betriebsabläufe zu erfassen. Prozessverantwortliche werden auf diesem Wege auf Verzögerungen, ineffiziente Abläufe und mögliche Prozessverbesserungen aufmerksam.

Praxisbeispiel: Einkaufsprozess – Prozessabweichungen als Kosten- und Risikofaktor

Ein Beispiel aus dem Unternehmensalltag ist ein einfacher Einkaufsprozess: Ein Mitarbeiter benötigt einen neuen Laptop. Im Normalfall beginnt der Prozess mit der Anfrage des Mitarbeiters, die durch seinen Manager bestätigt wird. Ist kein Laptop vorrätig, löst das für den Einkauf zuständige Team die Bestellung aus. Zu einem späteren Zeitpunkt wird der Laptop dem Mitarbeiter übergeben und das Unternehmen erhält eine Rechnung. Diese Rechnung wird geprüft und fristgemäß gemäß den vorgegebenen Konditionen beglichen. Obwohl dieser alltägliche Prozess nicht sehr komplex ist, weicht er im Unternehmensalltag häufig vom modellierten Idealzustand ab, was unnötige Kosten und möglicherweise auch Risiken verursacht.

Die Gründe sind vielfältig:

  • Freigaben fehlen
  • Während des Bestellprozesses sind Informationen unvollständig
  • Rechnungen werden aufgrund von unvollständigen Informationen mehrfach korrigiert

Process Mining ermöglicht, den gesamten Prozessverlauf alltäglicher Betriebsabläufe unter die Lupe zu nehmen und faktenbasierte Diskussionen zwischen den Fachabteilungen, Prozessverantwortlichen sowie dem Management in einer Organisation anzuregen. So werden unternehmensweite Prozessverbesserungen möglich – vorausgesetzt, die Methode wird richtig angewandt und ist strategisch durchdacht. Doch wie gelingt eine erfolgreiche unternehmensweite Process-Mining-Initiative über Abteilungsgrenzen hinaus?

Wie sich eine erfolgreiche Process-Mining-Initiative auf den Weg bringen lässt

Jedes Unternehmen ist einzigartig und geht mit unterschiedlichen Fragestellungen an eine Process-Mining-Initiative heran: ob einzelne Prozesse gezielt verbessert, Prozesslebenszyklen verkürzt oder abteilungsübergreifende Abläufe an unterschiedlichen Standorten miteinander verglichen werden. Sie alle haben etwas gemeinsam: Eine erfolgreiche Process-Mining-Initiative erfordert ein strategisches Vorgehen.

Schritt 1: Mit Weitsicht planen und richtig kommunizieren

Wie definiere ich die Ziele und den Umfang der Process-Mining-Initiative?

Die Anfangsphase einer Process-Mining-Initiative dient der Planung und entscheidet häufig über den Erfolg eines Projektes. In erster Linie kommt es darauf an, die Ziele des Projektes zu definieren und die Erfolgsfaktoren zu bestimmen. Die Ziele einer erfolgreichen Process-Mining-Initiative sind SMART definiert: spezifisch, messbar, attainable/relevant, reasonable/umsetzbar und zeitgebunden/time-bound. Mögliche Ziele für das Projekt lassen sich zum Beispiel wie folgt formulieren:

  • Prozessdauer auf 25 Tage reduzieren
  • Hauptunterschiede zwischen zwei Ländern hinsichtlich bestimmter Prozesse identifizieren
  • Prozessautomatisierung um 25% steigern

Unter diesen Voraussetzungen lässt sich auch der Rahmen der Process-Mining-Initiative festlegen: Sie halten fest, welche Prozesse, konkret betroffen sind und wie sie mit den IT-Systemen und Mitarbeiterrollen in Ihrer Organisation verknüpft sind.

Welche Rollen und Verantwortlichkeiten gibt es?

Die Ziele Ihrer Process-Mining-Initiative sollten unternehmensweit geteilt werden: Dies erfordert neben einer klaren Strategie eine transparente Kommunikation in der gesamten Organisation: Indem Sie Ihren Mitarbeitern das nötige Wissen an die Hand geben, um die Initiative erfolgreich mitzugestalten, sichern Sie sich auch ihre Unterstützung.

So verstehen sie nicht nur, warum dieses Projekt sinnvoll ist, sondern sind auch in der Lage, das Wissen auf ihre individuelle Rolle und Situation zu übertragen. Im Rahmen einer Process-Mining-Initiative sind verschiedene Projektbeteiligte in unterschiedlichen Rollen aktiv:

Während Projektträger verantwortlich für die Prozessanalyse sind (z. B. Chief Procurement Officer oder Process Owner), wissen Prozessexperten, wie ein bestimmter Prozess verläuft und kennen die verschiedenen Variationen. Sie nutzen Methoden wie Process Mining, um ihr Wissen zu vertiefen und Diskussionen über die gewonnenen Daten anzustoßen. Sie arbeiten eng mit Business-Analysten zusammen, die die Prozessanalyse vorantreiben. Datenexperten wiederum verfolgen die einzelnen Spuren, die ein Prozess in der IT-Landschaft einer Organisation hinterlässt und bereiten sie so auf, dass sie Aufschluss über die Performance eines Prozesses geben.

Wie gestaltet sich die Zusammenarbeit?

Diese unterschiedlichen Rollen gilt es im Rahmen einer erfolgreichen Process-Mining-Initiative an einen Tisch zu bringen: So können die gewonnen Erkenntnisse gemeinsam im Team interpretiert und diskutiert werden, um die richtigen Veränderungen anzustoßen. Die daraus gewonnen Prozessverbesserungen spiegeln das Know-how des gesamten Teams wider und sind das Ergebnis einer erfolgreichen Zusammenarbeit.

Schritt 2: Die technischen Voraussetzungen schaffen

Wie werden Prozessdaten systemübergreifend aggregiert und aufbereitet?

Nun wird es Zeit für die technischen Vorbereitungen: Entscheidend ist es, alle Anforderungen an die beteiligten IT-Systeme zu durchdenken und die IT-Verantwortlichen so früh wie möglich einzubeziehen. Um valide Daten für Prozessverbesserungen zu generieren, sind diese drei Teilschritte nötig:

  1.  Datenextraktion: Relevante Daten aus unterschiedlichen IT-Systemen werden aggregiert (Datenquellen sind datenbasierte Tabellen aus ERP- und CRM-Lösungen, analytische Daten wie Reports, Logdateien, CSV-Dateien usw.)
  2.  Datenumwandlung gemäß den Anforderungen für Process Mining: Die extrahierten Daten werden in Cases (Abfolge verschiedener Prozessschritte) umgewandelt, mit einem Zeitstempel versehen und in Event-Logs gespeichert.
  3.  Datenübertragung: Die Process-Mining-Software greift auf die gespeicherten Event-Logs zu.

Welche Rolle spielen Konnektoren?

Diese Teilschritte werden erfahrungsgemäß mittels eines Software-Konnektors durchgeführt und in regelmäßigen Abständen wiederholt. Ein Software-Konnektor hat die Aufgabe, die Daten aus der IT-Landschaft eines Unternehmens nach den Anforderungen der Process-Mining-Lösung zu übersetzen. Er wird speziell für die Kombination mit bestimmten IT-Systemen wie SAP, Oracle oder Salesforce entwickelt und steuert die gesamte Datenintegration von der Extraktion über die Umwandlung bis zur Datenübertragung.

Process-Mining-Lösungen wie Signavio Process Intelligence verfügen über Standardkonnektoren sowie über eine API für individuell entwickelte Konnektoren. Im Rahmen der technischen Vorbereitungen gilt es, mit Blick auf das jeweilige Szenario über die Möglichkeiten der Umsetzbarkeit zu entscheiden und andere technische Lösungen zu evaluieren.

Schritt 3: Von der Prozessanalyse zur Prozessverbesserung

Wie lassen sich die ermittelten Daten für Verbesserungen nutzen?

Sind die umgewandelten Daten in der Process-Mining-Lösung verfügbar, beginnt die Prozessauswertung. Durch IT-gestütztes Process Mining erhalten Prozessexperten die Möglichkeit, alle vorliegenden Daten zu visualisieren und einzelne Prozesse detailliert auszuwerten. Die vorliegenden Prozesse werden nun hinsichtlich unterschiedlicher Faktoren untersucht, etwa mit Blick auf Durchlaufzeiten, Performance und den Prozessfluss. Im direkten Vergleich lässt sich auf diesem Wege ermitteln, welche Faktoren sich auf die Erfolgskennzahlen auswirken und an welchen Stellen Verzögerungen oder Abweichungen auftreten.

Die so gewonnen Erkenntnisse bilden eine wichtige Grundlage für faktenbasierte Diskussionen zwischen den verschiedenen Stakeholdern der Process-Mining-Initiative. Doch erst die konkreten Schritte, die aus dieser Datenbasis abgeleitet werden, entscheiden über den Erfolg des Projektes: Entscheidend ist, wie diese Erkenntnisse in die Praxis umgesetzt werden.

 

Eine Process-Mining-Lösung, die nicht als reines Analysetool zur Verfügung steht, sondern in eine umfassende Lösung für die Modellierung, Automatisierung und Analyse professioneller Geschäftsprozesse integriert ist, erleichtert den Schritt von der Business Process Discovery zur Prozessverbesserung. Schließlich gilt es, konkrete Prozessverbesserungen und Änderungen zu planen, in den Unternehmensalltag zu integrieren und die Ergebnisse auszuwerten – auch über das Ende der Process-Mining-Initiative hinaus.

Warum ist ein Process-Mining-Projekt nie vollständig abgeschlossen?  

Wer einmal mit der Prozessverbesserung beginnt, wird feststellen: Viele weitere Stellen in den Prozessen warten nur darauf, verbessert zu werden. Daher lohnt es sich, einige Wochen nach der initialen Prozessverbesserung neue Daten zu extrahieren, um herauszufinden, welche Veränderungen nachweislich zu mehr Effizienz geführt haben. Eine kontinuierliche Messung und Auswertung erleichtert einen umfassenden Blick auf die eigene Organisation:

  • Funktionieren die überarbeiteten Prozesse wie geplant?
  • Haben Prozessveränderungen unvorhersehbare Effekte?
  • Treten Schwachstellen in anderen Prozessen auf?
  • Haben sich die Prozesse verändert, seitdem sie überarbeitet wurden?
  • Wie lässt sich ein bestimmter Prozess weiter verbessern?

Somit lässt sich zusammenfassen: Wem es gelingt, die Datenspuren in den IT-Systemen der eigenen Organisation zu verfolgen, ist auf dem richtigen Weg zur kontinuierlichen Verbesserung. Davon profitieren nicht nur die Prozesse und IT-Systeme, sondern auch die Mitarbeiter in den Organisationen.

Interview: Does Business Intelligence benefit from Cloud Data Warehousing?

Interview with Ross Perez, Senior Director, Marketing EMEA at Snowflake

Read this article in German:
“Profitiert Business Intelligence vom Data Warehouse in der Cloud?”

Does Business Intelligence benefit from Cloud Data Warehousing?

Ross Perez is the Senior Director, Marketing EMEA at Snowflake. He leads the Snowflake marketing team in EMEA and is charged with starting the discussion about analytics, data, and cloud data warehousing across EMEA. Before Snowflake, Ross was a product marketer at Tableau Software where he founded the Iron Viz Championship, the world’s largest and longest running data visualization competition.

Data Science Blog: Ross, Business Intelligence (BI) is not really a new trend. In 2019/2020, making data available for the whole company should not be a big thing anymore. Would you agree?

BI is definitely an old trend, reporting has been around for 50 years. People are accustomed to seeing statistics and data for the company at large, and even their business units. However, using BI to deliver analytics to everyone in the organization and encouraging them to make decisions based on data for their specific area is relatively new. In a lot of the companies Snowflake works with, there is a huge new group of people who have recently received access to self-service BI and visualization tools like Tableau, Looker and Sigma, and they are just starting to find answers to their questions.

Data Science Blog: Up until today, BI was just about delivering dashboards for reporting to the business. The data warehouse (DWH) was something like the backend. Today we have increased demand for data transparency. How should companies deal with this demand?

Because more people in more departments are wanting access to data more frequently, the demand on backend systems like the data warehouse is skyrocketing. In many cases, companies have data warehouses that weren’t built to cope with this concurrent demand and that means that the experience is slow. End users have to wait a long time for their reports. That is where Snowflake comes in: since we can use the power of the cloud to spin up resources on demand, we can serve any number of concurrent users. Snowflake can also house unlimited amounts of data, of both structured and semi-structured formats.

Data Science Blog: Would you say the DWH is the key driver for becoming a data-driven organization? What else should be considered here?

Absolutely. Without having all of your data in a single, highly elastic, and flexible data warehouse, it can be a huge challenge to actually deliver insight to people in the organization.

Data Science Blog: So much for the theory, now let’s talk about specific use cases. In general, it matters a lot whether you are storing and analyzing e.g. financial data or machine data. What do we have to consider for both purposes?

Financial data and machine data do look very different, and often come in different formats. For instance, financial data is often in a standard relational format. Data like this needs to be able to be easily queried with standard SQL, something that many Hadoop and noSQL tools were unable to provide. Luckily, Snowflake is an ansi-standard SQL data warehouse so it can be used with this type of data quite seamlessly.

On the other hand, machine data is often semi-structured or even completely unstructured. This type of data is becoming significantly more common with the rise of IoT, but traditional data warehouses were very bad at dealing with it since they were optimized for relational data. Semi-structured data like JSON, Avro, XML, Orc and Parquet can be loaded into Snowflake for analysis quite seamlessly in its native format. This is important, because you don’t want to have to flatten the data to get any use from it.

Both types of data are important, and Snowflake is really the first data warehouse that can work with them both seamlessly.

Data Science Blog: Back to the common business use case: Creating sales or purchase reports for the business managers, based on data from ERP-systems such as Microsoft or SAP. Which architecture for the DWH could be the right one? How many and which database layers do you see as necessary?

The type of report largely does not matter, because in all cases you want a data warehouse that can support all of your data and serve all of your users. Ideally, you also want to be able to turn it off and on depending on demand. That means that you need a cloud-based architecture… and specifically Snowflake’s innovative architecture that separates storage and compute, making it possible to pay for exactly what you use.

Data Science Blog: Where would you implement the main part of the business logic for the report? In the DWH or in the reporting tool? Does it matter which reporting tool we choose?

The great thing is that you can choose either. Snowflake, as an ansi-Standard SQL data warehouse, can support a high degree of data modeling and business logic. But you can also utilize partners like Looker and Sigma who specialize in data modeling for BI. We think it’s best that the customer chooses what is right for them.

Data Science Blog: Snowflake enables organizations to store and manage their data in the cloud. Does it mean companies lose control over their storage and data management?

Customers have complete control over their data, and in fact Snowflake cannot see, alter or change any aspect of their data. The benefit of a cloud solution is that customers don’t have to manage the infrastructure or the tuning – they decide how they want to store and analyze their data and Snowflake takes care of the rest.

Data Science Blog: How big is the effort for smaller and medium sized companies to set up a DWH in the cloud? Does this have to be an expensive long-term project in every case?

The nice thing about Snowflake is that you can get started with a free trial in a few minutes. Now, moving from a traditional data warehouse to Snowflake can take some time, depending on the legacy technology that you are using. But Snowflake itself is quite easy to set up and very much compatible with historical tools making it relatively easy to move over.

Allgemeines über Geodaten

Dieser Artikel ist der Auftakt in einer Artikelserie zum Thema “Geodatenanalyse”.

Von den vielen Arten an Datensätzen, die öffentlich im Internet verfügbar sind, bin ich in letzter Zeit vermehrt über eine besonders interessante Gruppe gestolpert, die sich gleich für mehrere Zwecke nutzen lassen: Geodaten.

Gerade in wirtschaftlicher Hinsicht bieten sich eine ganze Reihe von Anwendungsfällen, bei denen Geodaten helfen können, Einblicke in Tatsachen zu erlangen, die ohne nicht möglich wären. Der wohl bekannteste Fall hierfür ist vermutlich die einfache Navigation zwischen zwei Punkten, die jeder kennt, der bereits ein Navigationssystem genutzt oder sich eine Route von Google Maps berechnen lassen hat.
Hiermit können nicht nur Fragen nach dem schnellsten oder Energie einsparensten (und damit gleichermaßen auch witschaftlichsten) Weg z. B. von Berlin nach Hamburg beantwortet werden, sondern auch die bestmögliche Lösung für Ausnahmesituationen wie Stau oder Vollsperrungen berechnet werden (ja, Stau ist, zumindest in der Theorie immer noch eine “Ausnahmesituation” ;-)).
Neben dieser beliebten Art Geodaten zu nutzen, gibt es eine ganze Reihe weiterer Situationen in denen deren Nutzung hilfreich bis essentiell sein kann. Als Beispiel sei hier der Einzugsbereich von in Konkurrenz stehenden Einheiten, wie z. B. Supermärkten genannt. Ohne an dieser Stelle statistische Nachweise vorlegen zu können, kaufen (zumindest meiner persönlichen Beobachtung nach) die meisten Menschen fast immer bei dem Supermarkt ein, der am bequemsten zu erreichen ist und dies ist in der Regel der am nächsten gelegene. Besitzt man nun eine Datenbank mit der Information, wo welcher Supermarkt bzw. welche Supermarktkette liegt, kann man mit so genannten Voronidiagrammen recht einfach den jeweiligen Einzugsbereich der jeweiligen Supermärkte berechnen.
Entsprechende Karten können auch von beliebigen anderen Entitäten mit fester geographischer Position gezeichnet werden: Geldautomaten, Funkmasten, öffentlicher Nahverkehr, …

Ein anderes Beispiel, das für die Datenauswertung interessant ist, ist die kartographische Auswertung von Postleitzahlen. Diese sind in fast jedem Datensatz zu Kunden, Lieferanten, ect. vorhanden, bilden jedoch weder eine ordinale, noch eine sinnvolle kategorische Größe, da es viele tausend verschiedene gibt. Zudem ist auch eine einfache Gruppierung in gröbere Kategorien wie beispielsweise Postleitzahlen des Schemas 1xxxx oft kaum sinnvoll, da diese in aller Regel kein sinnvolles Mapping auf z. B. politische Gebiete – wie beispielsweise Bundesländer – zulassen. Ein Ausweg aus diesem Dilemma ist eine einfache kartographische Übersicht, welche die einzelnen Postleitzahlengebiete in einer Farbskala zeigt.

Im gezeigten Beispiel ist die Bevölkerungsdichte Deutschlands als Karte zu sehen. Hiermit wird schnell und übersichtlich deutlich, wo in Deutschland die Bevölkerung lokalisiert ist. Ähnliche Karten können beispielsweise erstellt werden, um Fragen wie “Wie ist meine Kundschaft verteilt?” oder “Wo hat die Werbekampange XYZ besonders gut funktioniert?” zu beantworten. Bezieht man weitere Daten wie die absolute Bevölkerung oder die Bevölkerungsdichte mit ein, können auch Antworten auf Fragen wie “Welchen Anteil der Bevölkerung habe ich bereits erreicht und wo ist noch nicht genutztes Potential?” oder “Ist mein Produkt eher in städtischen oder ländlichen Gebieten gefragt?” einfach und schnell gefunden werden.
Ohne die entsprechende geographische Zusatzinformation bleiben insbesondere Postleitzahlen leider oft als “nicht sinnvoll auswertbar” bei der Datenauswertung links liegen.
Eine ganz andere Art von Vorteil der Geodaten ist der educational point of view:
  • Wer erst anfängt, sich mit Datenbanken zu beschäftigen, findet mit Straßen, Postleitzahlen und Ländern einen deutlich einfacheren und vor allem besser verständlichen Zugang zu SQL als mit abstrakten Größen und Nummern wie ProductID, CustomerID und AdressID. Zudem lassen sich Geodaten nebenbei bemerkt mittels so genannter GeoInformationSystems (*gis-Programme), erstaunlich einfach und ansprechend plotten.
  • Wer sich mit SQL bereits ein wenig auskennt, kann mit den (beispielsweise von Spatialite oder PostGIS) bereitgestellten SQL-Funktionen eine ganze Menge über Datenbanken sowie deren Möglichkeiten – aber auch über deren Grenzen – erfahren.
  • Für wen relationale Datenbanken sowie deren Funktionen schon lange nichts Neues mehr darstellen, kann sich hier (selbst mit dem eigenen Notebook) erstaunlich einfach in das Thema “Bug Data” einarbeiten, da die Menge an öffentlich vorhandenen Geodaten z.B. des OpenStreetMaps-Projektes selbst in optimal gepackten Format vielen Dutzend GB entsprechen. Gerade die Möglichkeit, die viele *gis-Programme wie beispielsweise QGIS bieten, nämlich Straßen-, Schienen- und Stromnetze “on-the-fly” zu plotten, macht die Bedeutung von richtig oder falsch gesetzten Indices in verschiedenen Datenbanken allein anhand der Geschwindigkeit mit der sich die Plots aufbauen sehr eindrucksvoll deutlich.
Um an Datensätze zu kommen, reicht es in der Regel Google mit den entsprechenden Schlagworten zu versorgen.
Neben – um einen Vergleich zu nutzen – dem Brockhaus der Karten GoogleMaps gibt es beispielsweise mit dem OpenStreetMaps-Projekt einen freien Geodatensatz, welcher in diesem Kontext etwa als das Wikipedia der Karten zu verstehen ist.
Hier findet man zum Beispiel Daten wie Straßen-, Schienen- oder dem Stromnetz, aber auch die im obigen Voronidiagramm eingezeichneten Gebäude und Supermärkte stammen aus diesem Datensatz. Hiermit lassen sich recht einfach just for fun interessante Dinge herausfinden, wie z. B., dass es in Deutschland ca. 28 Mio Gebäude gibt (ein SQL-Einzeiler), dass der Berliner Osten auch ca. 30 Jahre nach der Wende noch immer vorwiegend von der Tram versorgt wird, während im Westen hauptsächlich die U-Bahn fährt. Oder über welche Trassen der in der Nordsee von Windkraftanlagen erzeugte Strom auf das Festland kommt und von da aus weiter verteilt wird.
Eher grundlegende aber deswegen nicht weniger nützliche Datensätze lassen sich unter dem Stichwort “natural earth” finden. Hier sind Daten wie globale Küstenlinien, mittels Echolot ausgemessene Meerestiefen, aber auch von Menschen geschaffene Dinge wie Landesgrenzen und Städte sehr übersichtlich zu finden.
Im Grunde sind der Vorstellung aber keinerlei Grenzen gesetzt und fast alle denkbaren geographischen Fakten können, manchmal sogar live via Sattelit, mitverfolgt werden. So kann man sich beispielsweise neben aktueller Wolkenbedekung, Regenradar und globaler Oberflächentemperatur des Planeten auch das Abschmelzen der Polkappen seit 1970 ansehen (NSIDC) oder sich live die Blitzeinschläge auf dem gesamten Planeten anschauen – mit Vorhersage darüber, wann und wo der Donner zu hören ist (das funktioniert wirklich! Beispielsweise auf lightningmaps).
Kurzum Geodaten sind neben ihrer wirtschaftlichen Relevanz – vor allem für die Logistik – auch für angehende Data Scientists sehr aufschlussreich und ein wunderbares Spielzeug, mit dem man sich lange beschäftigen und eine Menge interessanter Dinge herausfinden kann.

Cross-industry standard process for data mining

Introduced in 1996, the cross-industry standard process for data mining (CRISP-DM) became the most
common procedure for all data mining projects. This method consists of six phases: Business
understanding, Data understanding, Data preparation, Modeling, Evaluation and Deployment (see
Figure 1). It is being used not just as a reference manual but as a user guide as it explains every phase
in detail (Hipp, 2000). The six phases of this model are explained below:

Figure 1: Different phases of CRISP-DM

Business Understanding

It includes understanding the business problem and determining the
objective of the business as well as of the project. It is also important to understand the previous work
done on the project (if any) to achieve the business goals and to examine if the scope of the project has changed.

The job of a Data Scientist is not limited to coding or just make a machine learning model and I guess that’s why this whole lifecycle was developed.  The key points a project owner should take care in this process are:

– Identify stakeholders  and involve them to define the scope your project
– Describe your product (your machine learning model)
– Identify how your product ties into the client’s business processes
– Identify metrics / KPIs for measuring success

Evaluating a model is a different thing as it can only tell you how good are your predictions but identifying the success metric is really important for any data science project because when your model is deployed in production this measure will tell you if your model actually works or not. Now, let’s discuss what is this success metric
Consider that you are working in an e-commerce company where Head of finance ask you to create a machine learning model to predict if a specific product will return or not. The problem is not hard to understand, its a binary classification problem and you know you can do the job. But before you start working with the data you should define a metric to measure the success. What do you think your success metric could be? I would go with the return rate, in other words, calculate the rate for how many orders are actually coming back and if this measure is getting decrease you would know your model works and if not then FIX IT !!

Data understanding

The initial step in this phase is to gather all the data from different sources. It is
then important to describe the data, generate graphs for distribution in order to get familiar with the
data. This phase is important as without enough data or without understanding about the data analysis
cannot be performed. In data mining terms this can be compared to Exploratory data analysis (EDA)
where techniques from descriptive statistics are used to have an insight into the data. For instance, if it is
a time series data it makes sense to know from when until when the data is available before diving deep into
the data.

Data preparation

This phase takes most of the time in data mining project as a lot of methods from
data cleaning, feature subset, feature engineering, the transformation of data etc. are used before the final
dataset is trained for modeling purpose. The single dataset can also be prepared in different forms as some
algorithms can learn more with a certain type of data, some algorithms can deal with imbalance dataset
and for some algorithms, the target variable must be balanced. This phase also requires sometimes to
calculate new KPI’s according to the business need or sometimes to reduce the dimension of the dataset.

Modeling and Evaluation

Various models are selected and build in this process and appropriate hyperparameters are
selected after an intensive grid search.  Once all the models are built it is now time to evaluate and compare performances of all the models.

Deployment

A model is of no use if it is not deployed into production. Until now you have been doing the job of a data scientist but for deployment, you need some software engineering

skills. There are several ways to deploy a machine learning model or python code. Few of them are:

  • Re-implement your python code in C++, Java etc. (LOL)
  • Save the coefficients and use them to get predictions
  • Serialized objects (REST API with flask, Django)

To understand the concept of deploying an ML model using REST API this post is highly recommended.

Einstieg in Natural Language Processing – Teil 2: Preprocessing von Rohtext mit Python

Dies ist der zweite Artikel der Artikelserie Einstieg in Natural Language Processing.

In diesem Artikel wird das so genannte Preprocessing von Texten behandelt, also Schritte die im Bereich des NLP in der Regel vor eigentlichen Textanalyse durchgeführt werden.

Tokenizing

Um eingelesenen Rohtext in ein Format zu überführen, welches in der späteren Analyse einfacher ausgewertet werden kann, sind eine ganze Reihe von Schritten notwendig. Ganz allgemein besteht der erste Schritt darin, den auszuwertenden Text in einzelne kurze Abschnitte – so genannte Tokens – zu zerlegen (außer man bastelt sich völlig eigene Analyseansätze, wie zum Beispiel eine Spracherkennung anhand von Buchstabenhäufigkeiten ect.).

Was genau ein Token ist, hängt vom verwendeten Tokenizer ab. So bringt NLTK bereits standardmäßig unter anderem BlankLine-, Line-, Sentence-, Word-, Wordpunkt- und SpaceTokenizer mit, welche Text entsprechend in Paragraphen, Zeilen, Sätze, Worte usw. aufsplitten. Weiterhin ist mit dem RegexTokenizer ein Tool vorhanden, mit welchem durch Wahl eines entsprechenden Regulären Ausdrucks beliebig komplexe eigene Tokenizer erstellt werden können.

Üblicherweise wird ein Text (evtl. nach vorherigem Aufsplitten in Paragraphen oder Sätze) schließlich in einzelne Worte und Interpunktionen (Satzzeichen) aufgeteilt. Hierfür kann, wie im folgenden Beispiel z. B. der WordTokenizer oder die diesem entsprechende Funktion word_tokenize() verwendet werden.

Stemming & Lemmatizing

Andere häufig durchgeführte Schritte sind Stemming sowie Lemmatizing. Hierbei werden die Suffixe der einzelnen Tokens des Textes mit Hilfe eines Stemmers in eine Form überführt, welche nur den Wortstamm zurücklässt. Dies hat den Zweck verschiedene grammatikalische Formen des selben Wortes (welche sich oft in ihrer Endung unterscheiden (ich gehe, du gehst, er geht, wir gehen, …) ununterscheidbar zu machen. Diese würden sonst als mehrere unabhängige Worte in die darauf folgende Analyse eingehen.

Neben bereits fertigen Stemmern bietet NLTK auch für diesen Schritt die Möglichkeit sich eigene Stemmer zu programmieren. Da verschiedene Stemmer Suffixe nach unterschiedlichen Regeln entfernen, sind nur die Wortstämme miteinander vergleichbar, welche mit dem selben Stemmer generiert wurden!

Im forlgenden Beispiel werden verschiedene vordefinierte Stemmer aus dem Paket NLTK auf den bereits oben verwendeten Beispielsatz angewendet und die Ergebnisse der gestemmten Tokens in einer Art einfachen Tabelle ausgegeben:

Sehr ähnlich den Stemmern arbeiten Lemmatizer: Auch ihre Aufgabe ist es aus verschiedenen Formen eines Wortes die jeweilige Grundform zu bilden. Im Unterschied zu den Stemmern ist das Lemma eines Wortes jedoch klar als dessen Grundform definiert.

Vokabular

Auch das Vokabular, also die Menge aller verschiedenen Worte eines Textes, ist eine informative Kennzahl. Bezieht man die Größe des Vokabulars eines Textes auf seine gesamte Anzahl verwendeter Worte, so lassen sich hiermit Aussagen zu der Diversität des Textes machen.

Außerdem kann das auftreten bestimmter Worte später bei der automatischen Einordnung in Kategorien wichtig werden: Will man beispielsweise Nachrichtenmeldungen nach Themen kategorisieren und in einem Text tritt das Wort „DAX“ auf, so ist es deutlich wahrscheinlicher, dass es sich bei diesem Text um eine Meldung aus dem Finanzbereich handelt, als z. B. um das „Kochrezept des Tages“.

Dies mag auf den ersten Blick trivial erscheinen, allerdings können auch mit einfachen Modellen, wie dem so genannten „Bag-of-Words-Modell“, welches nur die Anzahl des Auftretens von Worten prüft, bereits eine Vielzahl von Informationen aus Texten gewonnen werden.

Das reine Vokabular eines Textes, welcher in der Variable “rawtext” gespeichert ist, kann wie folgt in der Variable “vocab” gespeichert werden. Auf die Ausgabe wurde in diesem Fall verzichtet, da diese im Falle des oben als Beispiel gewählten Satzes den einzelnen Tokens entspricht, da kein Wort öfter als ein Mal vorkommt.

Stopwords

Unter Stopwords werden Worte verstanden, welche zwar sehr häufig vorkommen, jedoch nur wenig Information zu einem Text beitragen. Beispiele in der beutschen Sprache sind: der, und, aber, mit, …

Sowohl NLTK als auch cpaCy bringen vorgefertigte Stopwordsets mit. 

Vorsicht: NLTK besitzt eine Stopwordliste, welche erst in ein Set umgewandelt werden sollte um die lookup-Zeiten kurz zu halten – schließlich muss jedes einzelne Token des Textes auf das vorhanden sein in der Stopworditerable getestet werden!

POS-Tagging

POS-Tagging steht für „Part of Speech Tagging“ und entspricht ungefähr den Aufgaben, die man noch aus dem Deutschunterricht kennt: „Unterstreiche alle Subjekte rot, alle Objekte blau…“. Wichtig ist diese Art von Tagging insbesondere, wenn man später tatsächlich strukturiert Informationen aus dem Text extrahieren möchte, da man hierfür wissen muss wer oder was als Subjekt mit wem oder was als Objekt interagiert.

Obwohl genau die selben Worte vorkommen, bedeutet der Satz „Die Katze frisst die Maus.“ etwas anderes als „Die Maus frisst die Katze.“, da hier Subjekt und Objekt aufgrund ihrer Reihenfolge vertauscht sind (Stichwort: Subjekt – Prädikat – Objekt ).

Weniger wichtig ist dieser Schritt bei der Kategorisierung von Dokumenten. Insbesondere bei dem bereits oben erwähnten Bag-of-Words-Modell, fließen POS-Tags überhaupt nicht mit ein.

Und weil es so schön einfach ist: Die obigen Schritte mit spaCy

Die obigen Methoden und Arbeitsschritte, welche Texte die in natürlicher Sprache geschrieben sind, allgemein computerzugänglicher und einfacher auswertbar machen, können beliebig genau den eigenen Wünschen angepasst, einzeln mit dem Paket NLTK durchgeführt werden. Dies zumindest einmal gemacht zu haben, erweitert das Verständnis für die funktionsweise einzelnen Schritte und insbesondere deren manchmal etwas versteckten Komplexität. (Wie muss beispielsweise ein Tokenizer funktionieren der den Satz “Schwierig ist z. B. dieser Satz.” korrekt in nur einen Satz aufspaltet, anstatt ihn an jedem Punkt welcher an einem Wortende auftritt in insgesamt vier Sätze aufzuspalten, von denen einer nur aus einem Leerzeichen besteht?) Hier soll nun aber, weil es so schön einfach ist, auch das analoge Vorgehen mit dem Paket spaCy beschrieben werden:

Dieser kurze Codeabschnitt liest den an spaCy übergebenen Rohtext in ein spaCy Doc-Object ein und führt dabei automatisch bereits alle oben beschriebenen sowie noch eine Reihe weitere Operationen aus. So stehen neben dem immer noch vollständig gespeicherten Originaltext, die einzelnen Sätze, Worte, Lemmas, Noun-Chunks, Named Entities, Part-of-Speech-Tags, ect. direkt zur Verfügung und können.über die Methoden des Doc-Objektes erreicht werden. Des weiteren liegen auch verschiedene weitere Objekte wie beispielsweise Vektoren zur Bestimmung von Dokumentenähnlichkeiten bereits fertig vor.

Die Folgende Übersicht soll eine kurze (aber noch lange nicht vollständige) Übersicht über die automatisch von spaCy generierten Objekte und Methoden zur Textanalyse geben:

Diese „Vollautomatisierung“ der Vorabschritte zur Textanalyse hat jedoch auch seinen Preis: spaCy geht nicht gerade sparsam mit Ressourcen wie Rechenleistung und Arbeitsspeicher um. Will man einen oder einige Texte untersuchen so ist spaCy oft die einfachste und schnellste Lösung für das Preprocessing. Anders sieht es aber beispielsweise aus, wenn eine bestimmte Analyse wie zum Beispiel die Einteilung in verschiedene Textkategorien auf eine sehr große Anzahl von Texten angewendet werden soll. In diesem Fall, sollte man in Erwägung ziehen auf ressourcenschonendere Alternativen wie zum Beispiel gensim auszuweichen.

Wer beim lesen genau aufgepasst hat, wird festgestellt haben, dass ich im Abschnitt POS-Tagging im Gegensatz zu den anderen Abschnitten auf ein kurzes Codebeispiel verzichtet habe. Dies möchte ich an dieser Stelle nachholen und dabei gleich eine Erweiterung des Pakets spaCy vorstellen: displaCy.

Displacy bietet die Möglichkeit, sich Zusammenhänge und Eigenschaften von Texten wie Named Entities oder eben POS-Tagging graphisch im Browser anzeigen zu lassen.

Nach ausführen des obigen Codes erhält man eine Ausgabe die wie folgt aussieht:

Nun öffnet man einen Browser und ruft die URL ‘http://127.0.0.1:5000’ auf (Achtung: localhost anstatt der IP funktioniert – warum auch immer – mit displacy nicht). Im Browser sollte nun eine Seite mit einem SVG-Bild geladen werden, welches wie folgt aussieht

Die Abbildung macht deutlich was POS-Tagging genau ist und warum es von Nutzen sein kann wenn man Informationen aus einem Text extrahieren will. Jedem Word (Token) ist eine Wortart zugeordnet und die Beziehung der einzelnen Worte durch Pfeile dargestellt. Dies ermöglicht es dem Computer zum Beispiel in dem Satzteil “der grüne Apfel”, das Adjektiv “grün” auf das Nomen “Apfel” zu beziehen und diesem somit als Eigenschaft zuzuordnen.

Nachdem dieser Artikel wichtige Schritte des Preprocessing von Texten beschrieben hat, geht es im nächsten Artikel darum was man an Texten eigentlich analysieren kann und welche Analysemöglichkeiten die verschiedenen für Python vorhandenen Module bieten.