„Perfektion ist nicht dann erreicht, wenn es nichts mehr hinzuzufügen gibt,
sondern wenn man nichts mehr weglassen kann.“ – Antoine de Saint-Exupéry
Ziel von Data-Science-Initiativen in Organisationen ist es, Wert aus Daten zu generieren. Der generierte Nutzen liegt im Regelfall darin mit neuen Erkenntnissen
Kosten zu reduzieren,
schnellere Entscheidungen zu treffen und
neue Märkte zu erschließen.
Bevor mit Machine- und Deep-Learning-Algorithmen aus Daten neue, wertvolle Erkenntnisse gewonnen werden können, müssen die Daten aufbereitet werden. In der Praxis gibt es immer wieder Entscheider in Firmen, die sich erhoffen, dass für diesen ersten Schritt so gut wie kein Aufwand nötig ist, dass mit den Daten alles passt, und dass die neu rekrutierten Data Scientists, die so nebenbei ins sonstige Low-Cost-Gehaltschema des Unternehmens passen, nur mit der Arbeit beginnen müssen. Diese Superhirne – mitunter stellt man sie sich als Geeks mit Hornbrillen vor – schauen sich dann zwei oder drei Tage die Daten an und präsentieren Erkenntnisse, die das Geschäft für immer revolutionieren werden. Das Top-Management wird reich, das Unternehmen floriert und der Data Scientist kriegt – weil er brav war – ein Fahrrad geschenkt, damit er gesund bleibt, wenn er künftig ins Büro radelt.
„Quick Wins“, also Situationen, in denen Data Scientists beim erstmaligen Explorieren der Daten bereits merkbare Erkenntnisse liefern können, kommen vor, sind aber äußerst selten. In der Realität haben die meisten Firmen mit konventionellen analytischen Verfahren schon einen Großteil der Innovationsmöglichkeiten abgegrast. Über die Jahre haben sich Analysten bereits den Kopf darüber zerbrochen, wie man Umsätze optimieren und Kosten reduzieren kann. Daher sind durch analytische Auswertungen, die im Regelfall mit BI-Methoden durchgeführt werden, keine wesentlichen Verbesserungen zu erwarten.
Wir werden in den nachfolgenden Kapiteln zeigen, dass es neue Analyse-Methoden gibt, die meist mit dem Begriff „Big Data“ zusammengefasst werden. Bisher ignorierte Datenquellen können mithilfe künstlicher Intelligenz erforscht werden. Unternehmen, die sich Wettbewerbsvorteile verschaffen wollen, sollten von diesen Möglichkeiten Gebrauch machen, um am Markt zu bestehen. Wir werden auch darauf eingehen, dass der Erfolg vieler dieser Projekte nicht garantiert ist.
Armand Ruiz beschreibt in einem Artikel das „80/20 Data Science Dilemma“1: 80 % der Zeit fließen in die Datenaufbereitung, aber nur 20 % in die Analyse. Diese Zahlen können variieren, im Internet kann man hierzu zahlreiche Studien und Meinungen finden. Ein wesentlicher Faktor für die Dauer der Aufbereitung von Daten ist die Qualität der Quelldaten.
Eine Datenplattform muss neben der Eignung zur erwähnten Aufbereitung der Daten auch noch weitere Anforderungen erfüllen. Sie muss robust sein, damit Daten nicht verloren gehen. Ebenso müssen die Daten vor unbefugtem Zugriff geschützt werden und die Datenplattform muss den Datenschutzrichtlinien entsprechen.
Die Tätigkeit, aus Daten Wert zu generieren, kann in unterschiedlicher Weise betrachtet werden. Die in Kapitel 1 vorgestellten Rollen in einem Team sind eine Möglichkeit Bereiche zu kategorisieren. In diesem Zusammenhang wurde schon ausgeführt, dass die Datenverarbeitung mehrere Phasen durchläuft.
Bild 2.1 Schichten einer Datenplattform
In Bild 2.1 sind die Schichten einer Datenplattform dargestellt. Im Folgenden werden wir das technische Fundament von Data-Science-Projekten beschreiben, und zwar bottom-up von den Hardwaregrundlagen bis zu den APIs, welche von den Data Scientists verwendet werden. Wem diese Abschnitte zu technisch sind, der kann gerne einzelne Sektionen überspringen. Das Verständnis der Grundlagen kann für Data Scientists aber von Vorteil sein, damit sie besser verstehen, wie ihre Modelle skalierbar gemacht werden können.
Der erste Blick gilt den Hardware- und Operating-System-Grundlagen. Wir müssen die Hardwaresysteme so konfigurieren, dass sie den Anforderungen genügen und der operative Betrieb sichergestellt ist. Da diese Schicht nur das technische Fundament einer Datenplattform ist, gibt es – anders als bei den restlichen Schichten – keine Referenz auf den Begriff Data. Wir bezeichnen diesen Bereich als Systems Engineering.
Die logische Ebene oberhalb des Systems Engineering ist die Data Platform. Die Datenplattform umfasst alle Softwarekomponenten, die nötig sind, um Daten auf mehreren Knoten verteilt zu speichern. Wir werden dabei Object Storage, DFS (Distributed File System) und MPP (Massive Parallel Processing) miteinander vergleichen. Wir werden auch zeigen, dass es die datenlegende Wollmilchsau nicht gibt. Für spezifische Anforderungen gibt es spezifische Lösungen, die je nach Industrie unterschiedlich sein können.
Oberhalb der Data Platform befindet sich die Schicht des Data Engineerings. Diese Disziplin beschreibt die Prozesse, wie Daten für analytische Zwecke aufbereitet werden. Wir werfen dabei einen Blick auf Verarbeitungskonzepte wie Streaming und Batch. Zum Data Engineering gehören auch Programmiersprachen, CI/CD und andere Themen, die die Verarbeitung von Daten unterstützen.
Bild 2.2 Zonen-Diagramm einer Datenarchitektur
Bild 2.2 stellt verschiedene Bausteine einer Datenarchitektur dar und gliedert sie in mehrere Ebenen. Die konkrete Implementierung kann sich je nach Anforderungen unterscheiden.
Abgesehen von der Frage, wie Daten effizient für analytische Zwecke aufbereitet werden, gibt es auch weitere Faktoren, die das Data Engineering und eine Daten-Architektur beeinflussen können.
Data Governance: Diese Disziplin beschreibt, wie Daten verwaltet werden müssen, um regulativen Vorgaben zu entsprechen. Data Governance spielt speziell in Branchen mit hohen gesetzlichen Auflagen (z. B. Banken) eine große Rolle.
Data Security: Diese Disziplin stellt sicher, dass Daten vor unbefugtem Zugriff geschützt sind. Man kann sie weiter in Plattformsicherheit (Schutz vor unbefugtem Zugriff auf die Plattform durch z. B. Hackerangriffe) und Datensicherheit (Schutz vor unbefugtem Zugriff auf Daten durch auf die Plattform autorisierte Anwender) unterteilen. Data Security kann auch in Data-in-Rest und Data-in-Motion kategorisiert werden. Data-in-Rest repräsentiert die Sicherheit abgelegter Daten, Data-in-Motion sichert die Datenübertragung ab.
Data Monetisation: Oftmals wird Data Science getrennt von analytischen Anwendungsfällen betrachtet, mit denen Unternehmen Wert generieren wollen. Unternehmen sprechen beispielsweise vom „Churn Business Case“, um zu beschreiben, wie sie Daten erforschen wollen, die Erkenntnisse bringen sollen, welche Kunden mit welcher Wahrscheinlichkeit ein Abonnement stornieren werden. Data Scientists hingegen sprechen von Regressionsmodellen, um diese Kunden zu identifizieren. Die funktionalen Anforderungen an den „Business Case“ (z. B. wie schnell die Informationen den Sachbearbeitern zur Verfügung stehen müssen), wirken sich auch aufs Engineering aus. In Kapitel 9 gehen wir auf einzelne Anwendungsfälle im Detail ein.
Der bekannte IT-Evangelist Martin Fowler prägte den Begriff der polyglotten IT-Landschaften.2 Dieses Prinzip sagt aus, dass die unterschiedlichen Anforderungen an IT-Landschaften mit ihrem Innovationsgrad wachsen und verschiedene Systeme spezifische Herausforderungen lösen, aber kein System ein Allheilmittel für alle Probleme ist. Werkzeuge, die sich für spezifische Anwendungsfälle eignen, können für andere Anwendungsfälle unpassend sein.
Bild 2.3 Polyglotte Speicherung (Polyglot Persistence)
Veranschaulichen wir das Prinzip der polyglotten Datenwelt anhand eines praktischen Referenzbeispiels: Ihnen sind Caches und relationale Datenbanken vermutlich zumindest vom Namen her ein Begriff. In beiden Speicherarten könnten Daten abgelegt werden. Stellen Sie sich nun vor, Sie haben die Aufgabe folgende Daten zu speichern:
Kundenstammdaten,
Ergebnisse einer Auswertung, die temporär für andere Systeme bereitstehen müssen.
Würden Sie die Kundenstammdaten in den Cache und die Zwischenergebnisse in die relationale Datenbank speichern? Wohl kaum. Sie würden sicher den Cache nur für temporäre Daten als Zwischenspeicher nutzen und die Kundenstammdaten in die Datenbank legen.
Caches und Datenbanken sind vielleicht die augenscheinlichsten Bausteine, um die Unterschiede verschiedener Formen von Datenspeicherung zu verdeutlichen.
Geht man einige Ebenen tiefer, so kann man relationale Datenbanken NoSQL-Datenbanken gegenüberstellen. Für stark strukturierte Daten, wie Kundenstammdaten, werden Sie vermutlich weiterhin eine relationale Datenbank verwenden, aber was ist, wenn Sie beispielsweise semi-strukturierte Daten im JSON-Format erhalten oder wenn Sie Daten erhalten, die aus Schlüssel und Wert-Paaren gebildet werden? Dann gibt es dazu...