Wie Sie einen idealen Data-Science-Stack gestalten

Warum brauchen Unternehmen überhaupt einen Data Science-Stack?

Weltweit erzeugen Unternehmen mit jedem Tag mehr Daten und wollen aus diesen wertvolle Erkenntnisse gewinnen. Der Bedarf an Lösungen ist darum in den letzten Jahren extrem gewachsen. Data Science und Data Analytics sind heute wichtiger denn je zuvor für den wirtschaftlichen Erfolg. Noch viel zu häufig werden Data Science und Data Analytics in einen Topf geworfen. Während Data Analytics das Ziel hat, vergangene und aktuelle Entwicklungen zu verstehen, soll Data Science Vorhersagen basierend auf Mustern und Trends ermöglichen. Um diesem Anspruch gerecht zu werden, werden teilweise andere, spezielle Tools benötigt. Zum Beispiel beginnen Data Scientist häufig mit Rohdaten (statt vor-prozessierter Daten), nutzen hauptsächlich Sprachen wie Python (statt größtenteils SQL) und arbeiten in ML-Tools (statt BI-Anwendungen). 

‍

Dass ein idealer Data Science-Stack darum anders gestaltet ist, als ein idealer Data Analytics-Stack, liegt auf der Hand. Es ist also dringend an der Zeit, sich der Frage zu widmen:

“Was brauchen meine Data Scientists?”

Wie so häufig bei Datenthemen, lässt sich diese Frage weder pauschal noch einfach beantworten. Organisationen haben unterschiedlichste Daten, zugrundeliegende Systeme, Budgets, Teams und Datenkulturen. Grundlegende Prinzipien und Komponenten für einen modernen Data Science-Stack haben sich aber in den letzten Jahren herauskristallisiert und etabliert. Diese wollen wir Ihnen hier vorstellen. 

‍

Was möchten Sie mit einem modernen Data Science-Stack erreichen?

Zu Beginn sämtlicher folgender Überlegungen, sollte die Frage nach dem zu erreichenden Ziel eindeutig und gemeinsam mit den Fachbereichen geklärt sein. 

• Scheitern Data Science-Projekte häufig in frühen Projektphasen? 
• Dauern Projekte enorm lange oder kommt es oft zu Verzögerungen? 
• Laufen alle Data Scientists davon?
• Treten Probleme mit Modellen im Realbetrieb oder beim Roll-out auf? 

Für eine gut funktionierende Architektur ist ein Verständnis der Kernherausforderungen von Data Science notwendig. 

‍

Typische technische und organisatorische Herausforderungen

Der Beginn eines Data Science-Projektes ist meistens “nebulös”. Es ist nicht klar, ob passende Daten vorhanden sind, ob sie nutzbar sind, ob überhaupt ein Modell für die Fragestellung sinnvolle, performante Ergebnisse liefern wird oder die Erkenntnisse letzten Endes umsetzbar sein werden.  

Datenaufbereitung ist unbestritten der zeitaufwendigste Teil eines Data Science-Projektes. Es gilt darum, diese Phase mit Tools so effizient wie möglich zu gestalten, zum Beispiel über Automatisierung. So wie die folgende Arbeit den flexiblen Umgang mit verschiedenen Tools erfordert, können auch für die Aufbereitung die optimalen Lösungen sehr heterogen sein.

Kooperation muss nicht nur innerhalb von Data-Teams funktionieren, sondern auch mit den fachlichen Teams. Code muss ebenso geteilt werden können, wie Definitionen und Wissen im Allgemeinen. Bei kollaborativem Arbeiten muss allen Personen die gleiche Umgebung zur Verfügung gestellt werden. Nur so lassen sich Ergebnisse sicher reproduzieren. 

Dokumentation und Organisation sind Faktoren, die vieles leichter machen und vor allem unangenehm werden, wenn sie fehlen. Ein Aspekt, bei dem das sehr deutlich wird, ist die Suche nach Problemen und Fehlern bei Modellen im operationellen Betrieb. Das können z.B. plötzlich auftretende Performance-Probleme sein. Ohne saubere Dokumentation über einzelne Schritte kommt das einer Suche nach der Nadel im Heuhaufen gleich. Ein weiteres Beispiel ist, dass viele Assets wie z.B. Images, aufbereitete Datensätze oder spezielle Libraries von Kollegen ebenfalls verwendet werden können, ohne dass diese erneut entwickelt oder gefunden werden müssen. 

Und last but not least: Datenqualität. 

Weitere, individuelle Herausforderungen sollten immer unter Einbeziehungen der Data Scientists, also der tatsächlichen Nutzer des Stacks, bestimmt werden. Mit dem Verständnis der individuellen und oben genannten allgemeinen Herausforderungen lässt sich nun ein idealer Data Science-Stack aufbauen. 

‍

Die Komposition des Stacks - Rosinen-Pickerei erlaubt

Sämtliche Phasen müssen optimal unterstützt werden

Starten wir mit einem kurzen Überblick über die typischen Phasen bzw. Schritte eines Projektes. 

‍

Dieser Ablauf ist aber keineswegs in Stein gemeißelt. Im Grunde kann es bei jedem Schritt heißen “Gehen Sie zurück auf Start”. Die Dauer und der Arbeitsaufwand jeder einzelnen Phase sind ebenfalls sehr unterschiedlich von Projekt zu Projekt. 

Eine moderne Datenarchitektur besteht aus verschiedenen Komponenten, die alle möglichst nahtlos ineinander greifen. Sie beginnt bei daten-erzeugenden Systemen, geht über transportierende, speichernde, analysierende und organisierende Systeme bis hin zur Datenpräsentation. Solch eine durchlässige Architektur minimiert Fehler, unterstützt effiziente Projekte und optimiert die Qualität der Ergebnisse. 

Beginnen wir aber von vorn. 

‍

Datengrundlage

Grundsätzlich lassen sich Datenquellen in zwei Gruppen einteilen: primäre (Ebene der Datenerzeugung, beziehungsweise direkte Speicherung) und sekundäre Quellen (prä-prozessierte Systeme). 

Zu den primären Systemen gehören ERP-Systeme, CRM-Systeme, Datenbanksysteme für Produktionsdaten, Datenbanken für externe Daten, und und und. Typische Vertreter sind hier SAP, Salesforce, postgres-Datenbanken und MS SQL-Server (um nur einige Beispiele zu nennen). Eine Sonderform der sekundären Quellen bildet der Data Lake. Bekannte Anbieter dafür sind aws, GCP, Azure, databricks and cloudera. Der Hauptvertreter einer sekundären Quelle ist das Data Warehouse. Auch hier dominieren die großen Plattform-Betreiber den Markt. Weitere Beispiele für sekundäre Quellen sind real-time Memory-Datenbanken für bestimmte Anwendungen. Als Zwischenform zwischen Data Lakes und Datawarehouses haben sich sogenannte Lakehouses entwickelt, wie zum Beispiel von Snowflake und Databricks angeboten. 

Idealerweise ist es Data Scientists möglich, einen direkten Zugang zur Datenquelle zu haben. Der Vorteile ist, dass zu jeder Zeit mit aktuellen, unverfälschten Datensätzen gearbeitet werden kann. Es ist sichergestellt, dass keine Muster durch vorherige Bearbeitung eventuell maskiert wurden. 

Häufig ist das allerdings aus 

a) technischen Gründen oder 

b) Compliance-Gründen oder 

c) sonstigen Gründen (Ressourcen, Kapazitäten, Richtlinien, …)

nicht möglich. In diesen Fällen erhalten Data Scientist meist einen Datenexport in Form von csv-Dateien. Dieser muss dann dann in einem Zwischenspeicher abgelegt werden. Eine einfaches, gut funktionierendes Setting ist die Nutzung von Buckets wie zum Beispiel S3 von aws. 

Take Away

Ein direkter Datenzugriff ist großartig - will allerdings unbedingt reguliert sein. Vernachlässigen Sie an dieser Stelle nicht die Data Governance. Etablieren Sie für die Datei-Verfügbarmachung einen Standardprozess, der dennoch ausreichend Flexibilität bietet. Individuelle Lösungen wie Excel-Exporte führen zu unkontrollierten Schattensystemen. 

‍

Datenvorbereitung

Unter dem Punkt “Datenvorbereitung” sind hier das experimentelle Arbeiten auf den Daten, ETL-Prozesse (extract transform load) und Bereinigungen zusammengefasst. Je nach Datenursprung, Art und Fragestellungen kommen verschiedene Tooltypen zum Einsatz. Daher sieht man im Markt eine hohe Bandbreite an Anbietern mit verschiedenen Spezialisierungen. 

Wie eingangs besprochen, ist die Ausgangslage bei Data Science-Projekten sehr viel vager als bei Analytics-Projekten. Die Möglichkeit, zu Beginn des Prozesses schnell und unkompliziert einen Blick auf die Daten zu werfen, die Datenqualität zu prüfen und erste Hypothesen zu prüfen, ist darum sehr wertvoll. Erweisen sich diese ersten Resultate als vielversprechend, kann im Anschluss mit der detaillierten Vorbereitung fortgefahren werden. 

ETL ist die Abkürzung für Extract Transform Load und umfasst eine Vielzahl von Schritten, um Daten aus einer Quelle zu beziehen, anzupassen und anschließend in ein Data Warehouse zu laden.* Die meisten Unternehmen, die sich für Data Science interessieren, betreiben Data Analytics und besitzen darum bereits verschiedene ETL-Tools. Bei der Extraktion kommen Konnektoren (wie z.B. Fivetran oder Stitch), Workflow Manager (z.B. Airflow), automatisierte Query Engines (z.B. Hive) oder open-source-Tools wie Spark-Plattformen zum Einsatz. Insbesondere in diesem Bereich gibt es exzellente open source-Tools, mit denen ein Unternehmen seinen Data Stack sehr gut “aufpimpen” kann. Auch eine Architektur, die vollständig auf open source-Tools setzt ist möglich. Mit der entsprechenden Expertise lässt sich innerhalb weniger Stunden eine leistungsstarke Umgebung aufsetzen. Allein schon existierende Python-Libraries bieten vielzählige Funktionen um nahezu sämtliche nötigen Schritte durchzuführen. 

Welche Vorgehensweise individuell die optimale ist, ist von Datenquelle zu Datenquelle unterschiedlich. 

Dasselbe gilt für Datenmodellierung, -transformation und -bereinigung. Neben den Komponenten der großen Cloud-Plattformen können auch dafür Open-source-Tools und öffentliche Libraries benutzt werden.

Die Ablage (Loading) der aufbereiteten Daten muss drei grundsätzliche Kriterien erfüllen, damit sie einem modernen Stack gerecht wird:

• Flexibilität: Man kann von verschiedenen Systemen dort Daten ablegen und mit verschiedenen Systemen darauf zugreifen.
• Skalierbarkeit: Die Kapazität muss sich entsprechend den Anforderungen anpassen lassen.
• Transparenz: Es handelt sich um einen dokumentierten, zugänglichen Speicherort, sodass die Bewegung der Daten weiter nachvollziehbar bleibt. 

Zum Einsatz kommen hier darum zumeist Data Warehouses, Data Lakes (z.B. von Databricks, Deltalake,...) oder Bucket-Lösungen (z.B. aws S3). 

*In den letzten Jahren hat sich daneben noch die Variante ELT, also extract load transform entwickelt. Dabei werden Daten zuerst in einem rohdaten-ähnlichen Zustand in ein Data Warehouse geladen und anschließend transformiert. 

Take Away

Der ideale Data Science Stack wird an dieser Stelle nicht von der einzig wahren Technologie charakterisiert, sondern dadurch, dass verschiedene Technologien nebeneinander existieren und kombiniert werden können. Für Anwender*innen wird der größte Mehrwert geschaffen, wenn zu jeder Zeit auf das beste Tool für den Job zugegriffen werden kann. Um das umzusetzen, braucht es zwei Dinge: transparente Übersicht über verfügbare Tools und offene Schnittstellen, damit diese kombiniert werden können. Eine micro service-basierte Architektur unterstützt diese Flexibilität und Wiederverwendbarkeit von APIs enorm. 

Modellentwicklung

Die Entwicklung, das Training und das Testen des Modells erfolgen nun in der Data Science-Umgebung. Eine ideale Umgebung lässt sich mit einem Buffet im Hotel vergleichen. Bei einem gut angeordneten Buffet stehen Teller logischerweise am Anfang des Aufbaus und nicht am anderen Ende des Raumes.  Beilagen sind so angeordnet, dass man auf Anhieb aus allen auswählen kann. Übersetzt auf eine Data Science-Umgebung heißt das:

• Wie viel Hunger habe ich? Wähle ich darum einen großen oder einen kleinen Teller? → Welches Tool wähle ich? 
• Wähle ich Fisch, Fleisch oder etwas Vegetarisches? Mit welchen Soßen kann ich mein Gericht abrunden? → Welche Images stehen mir zur Verfügung? Welche Libraries?
• Ich will nicht an jedem Abschnitt anstehen und gehe darum direkt zum fertigen Auflauf. → Ich brauche eine schnelle, unkomplizierte Lösung für ein MVP und wähle ein automatisiertes Tool mit hohem Automatisierungsgrad. 

Die Realisierung dieser Umgebung kann ganz verschieden gestaltet sein. Plattformen wie Databricks, Sagemaker, Anaconda und alteryx bieten Nutzern einen zentralen Ort für ihr Prozessmanagement, für ihre Notebooks und Libraries und bieten teilweise auch Low code-Funktionen. 

Genauso gut kann eine Organisation auch eine individuelle Plattform relativ unkompliziert aufsetzen. In dem Fall wird ein Ort für die Speicherung von Images benötigt, GitHub kann für das Teilen von Code verwendet werden und Containerlösungen für die Harmonisierung der Umgebung. Notebooks, sowie sämtliche dazugehörige Assets, werden übersichtlich in einem Data Asset-Katalog dokumentiert. 

Take Away

Im Kern ist die Aufgabe eines modernen Data Stacks, dass alle Data Scientists Zugang zu den Komponenten haben, die sie benötigen. Für Effizienz, Kollaboration und langfristige Stabilität ist es entscheidend, mit einem zentralen Ablageort Silos zu verhindern. 

‍

Modellbereitstellung

Im folgenden Abschnitt geht es neben dem reinen Deployment auch um die Bereitstellung von Erkenntnissen durch Visualisierung.  Der Fokus sollte in beiden Fällen auf dem Endnutzer, beziehungsweise der Endanwendung liegen. 

Ein Beispiel für ein unkompliziertes Deployment ist, wenn für eine Scoring-Fragestellung immer zu einem festen Zeitpunkt die vom Modell ermittelten Scores in eine Datenbank eingespeist werden sollen. Komplexer wird es beispielsweise, wenn ad hoc verschiedene Anwendungen (z.B. Webseite und CRM-System) von einem Empfehlungsmodell bedient werden sollen. Aus den variablen Anforderungen leiten sich einige Kernaspekte für die Gestaltung des Deployments ab:

• Wie häufig werden Resultate abgefragt? 
• Handelt es sich bei den Abfragen um batches oder streams?
• Welche Anwendungen sollen bedient werden?

• Welche Latenz darf es bei der Bereitstellung geben?

Neben der Herausforderung, diese Kriterien zu erfüllen, gibt es eine Reihe weiterer häufiger Hürden.

• Für den Übergang in die Produktion kann ein Wechsel der Programmiersprache notwendig sein.
• Endanwendungen können nicht nur mehrere sein, sondern sich auch mit der Zeit ändern. 
• Datenquellen und Systeme können sich ändern
• Der Übergang von den Trainings- und Testdaten auf Realdaten kann durch das Volumen oder die Geschwindigkeit der eingehenden Daten problematisch sein.
• Anpassungen müssen implementierbar, dokumentierbar und zu monitoren sein. 
• ...

Zusammengefasst sind also Skalierbarkeit, Flexibilität und Nachhaltigkeit die zentralen Kriterien, die die Deploymentstrategie erfüllen muss. Unsere Empfehlungen für einen modernen Data Stack lauten darum:

1. Cloud-Deployment ist (wenn möglich) immer vorzuziehen. → Skalierbarkeit, Performance und Transfermöglichkeiten sind deutlich besser und einfacher zu regulieren als in Legacy-Systemen.
2. Container-Lösungen haben sich etabliert. → Sie unterstützen enorm bei Herausforderungen wie Inkompatibilität und komplexem Troubleshooting. 
3. Eine Microservices-Architektur hat sich bewährt → Insbesondere Transfers bezüglich der Endanwendungen und Quellen werden dadurch deutlich effizienter.
4. Repositories, die Kollaboration unterstützen, wie z.B. Github, empfehlen wird dringend. → Durch solche Plattformen wird die Kommunikation mit den zuständigen Dev-Teams erfahrungsgemäß sehr viel einfacher. Die Historie bleibt nachvollziehbar und falls notwendig können Änderungen unkompliziert rückgängig gemacht werden. 

Der aktuelle Trend hin zur Plattformisierung birgt an dieser Stelle ein großes Potential. Eine Plattform, ob als platform-as-a-service- oder als open-source-Variante, schafft Transparenz über verfügbare Möglichkeiten und vereinfacht die Wiederverwendung von bereits erstellten APIs. 

Die Bereitstellung von Ergebnissen über Visualisierungen wird immer wichtiger. 

Das beinhaltet nicht nur die Endergebnisse, sondern auch gewonnene Einsichten während der Datenvorbereitung und Modellerstellung. Wenn also zunehmend mehr Nutzer Data Science-Ergebnisse nutzen sollen, müssen Visualisierungstools das dementsprechend auch unterstützen. 

Aktuell sieht man häufig in Unternehmen eine dieser zwei Strukturen: 

1. Alle müssen das unternehmensweit beschaffte Tool verwenden
2. Data Scientist nutzen alle ihre bevorzugten Tools und haben individuelle Lösungen gebaut

Die Palette der verfügbaren Visualisierungstools ist reichhaltig: Tableau, PowerBI, Looker, Redash, Superset, Python und R selbst, … . Der Trend tendiert definitiv Richtung b), hin zu mehr Tool-Vielfalt innerhalb einer Organisation. Für bestimmte Fragestellungen eignet sich ein bestimmtes Tool besser als andere. Es geht in einem idealen Data Stack darum, Allen geeignete Tools zur Verfügung zu stellen ohne Silos zu kreieren. Das kann erreicht werden, indem 1) insgesamt auf offene Schnittstellen geachtet wird und 2) es eine zentrale, effiziente Dokumentation gibt. Sind diese beiden Kriterien erfüllt, lassen sich Ergebnisse für alle zugänglich und nachvollziehbar machen. 

Take Away

Für ein erfolgreiches Deployment ist die fachbereichsübergreifende Kooperation wichtig. Die klare Definition der Anforderungen gemeinsam mit Fachbereichen und die Zusammenarbeit mit Software Engineers bilden die Grundlage. Eine moderne, cloud-basierte  Architektur und offene Schnittstellen fördern ein effizientes Deployment und sichern die langfristige Nutzung.

‍

Dokumentation

Dokumentation wurde bereits häufig in den vorherigen Absätzen betont, aber wie wird sie in einem idealen Data Science Stack realisiert? 

Die Darstellung des Gesamtprozesses erfolgt in einem Datenkatalog. Für eine saubere Data Governance, aber auch Effizienz, Transparenz und erfolgreiche Kommunikation müssen die folgenden Aspekte dort abbildbar sein:

• Benutzte Datensätze
• Durchgeführte Transformationen
• Aufbereitete Datensätze
• Data Science libraries, images, Plattformen, Tools, ..
• Milestones der Modell-Entwicklung
• Implementierungsort des Modells inkl. APIs, Dashboards etc. 

Es geht nicht darum, jede statistische Analyse im Datenkatalog doppelt zur lokalen Dokumentation im Katalog zu hinterlegen. Der ideale Datenkatalog für Data Science zeichnet sich dadurch aus, dass jede absolvierte Phase wirklich schnell und einfach zu hinterlegen ist. Ein klarer Verweis, in welchem Notebook die statistischen Analysen zu finden sind, genügen vollkommen für die Nachvollziehbarkeit. Spätestens bei Überarbeitungen oder wenn Probleme auftreten, ist jede*r Data Scientist dankbar für eine strukturierte Vorarbeit der Kollegen.

Eine weitere Aufgabe der Dokumentation, neben der Verbesserung der Arbeitsumgebung, ist auch die Schaffung von Vertrauen. Nach wie vor existieren Vorbehalte gegenüber Black Boxes, die ML-Modelle eventuell darstellen. Anwender verstehen nicht, wie beispielsweise Vorhersagen getroffen werden und misstrauen ihnen. Neben Change Management ist Dokumentation ein essentieller Schritt hin zu einer verbesserten Datenkultur. 

Take Away

Dokumentation geschieht im modernen Data Science Stack auf zwei Ebenen. Die erste Ebene wird gebildet von Tools, wie Notebooks, in denen grundsätzlich immer nachvollziehbar gearbeitet werden sollte. Die zweite Ebene ist die des Data Asset-Katalogs, der alle Komponenten eines Projekte in Zusammenhang bringt und den Betrachter wie ein Guide von der Datenquelle bis zum Resultat führt. 

‍

Ausblick

Betrachten wir noch einmal unsere eingangs gestellten Fragen: “Welches Problem möchten wir lösen?” und “Was brauchen meine Data Scientists?”. 

Am besten lassen sich Maßnahmen entwickeln, wenn die Komponenten des Data Stacks als Teile eines Gesamtprozesses verstanden werden. 

Die Zukunft des Data Stacks liegt in einer verteilten Architektur, wie sie auch die Konzepte einer Data Fabric und eines Data Meshs realisieren. Verantwortlichkeiten werden aufgeteilt, Zentralisierung durch zentrale Transparenz ersetzt. Die Entwicklung der Automatisierung und der Trend hin zu No- und Low-Code werden fortschreiten. Unsere gesamte Datenkultur wird sich weiterentwickeln und mehr und mehr Unternehmen erobern. Eine sich entwickelnde Datenkultur wird dazu führen, dass Unternehmen immer mehr daten-basierte Möglichkeiten erschließen werden. Dementsprechend muss ein moderner, nachhaltiger Data Stack mitwachsen und skalieren können. 

Datendemokratisierung wird sich nicht mehr hauptsächlich auf Mitarbeiter innerhalb eines Unternehmens beziehen, sondern auf den Zugang der Allgemeinheit zu Datentechnologien. Die Open-Source-Bewegung wird weiter an Bedeutung gewinnen. 

Selbstverständlich werden sich auch Technologien immer weiter entwickeln. Die wiederkehrenden Zyklen von Innovation aus Erfindung und Etablierung werden weitergehen. In Zukunft werden Komponenten der Datenarchitektur viel flexibler ausgetauscht und durch neue, passendere Module ersetzt. Softwares, die auf Lock-in-Effekte setzen und keine offenen Schnittstellen zur Verfügung stellen (looking at you, SAP-Altsysteme), werden abnehmen. 

Bereiten Sie darum schon heute Ihre Data Science-Stack durch mehr Flexibilität und Wachstumsmöglichkeiten auf die Zukunft vor. 

‍

‍

Dieser Artikel erschien ebenfalls auf Englisch auf Towardsdatascience.