Im Technology-Talk im Dezember 2018 ging es um die Buzzwords „Big Data“ und „Künstliche Intelligenz“. Wir haben uns mit den typischen Stolperfallen und Lösungen, die sich in der Praxis bewährt haben, beschäftigt. Dafür stand unser Technologie-Experte Herr Dr. Henning Barthel zur Verfügung. Herr Barthel arbeitete über 12 Jahren am Fraunhofer IESE und war einer der Dozenten unseres „Basic Data Scientist“-Lehrgangs der Fraunhofer-Allianz Big Data. Das Interview wurde von Herr Dr. Jens Heidrich geführt, der von 2011-2023 als Hauptabteilungsleiter des Fraunhofer IESE für das Thema Prozess-Management zuständig war.
Datensilos aufbrechen
F: Themen wie Big Data und KI sind ja in aller Munde. Was treibt denn Firmen konkret an, sich damit zu beschäftigen?
A: Im digitalen Zeitalter sind Daten der Rohstoff für wirtschaftliche Wertschöpfung. Datenbasierte Geschäftsmodelle in der Produktion, der Medizintechnik, der Logistik, dem Maschinenbau oder in den Bereichen Energie, Mobilität und Verkehr gewinnen zunehmend an Bedeutung. Deswegen beschäftigen sich immer mehr Unternehmen damit, ob und – wenn ja – wie eine intelligente Datennutzung für sie von Vorteil wäre.
F: Was sind denn die Herausforderungen?
A: Für große Datenmengen stoßen klassische Ansätze schnell an ihre Grenzen. Stattdessen sind Werkzeuge für Big Data notwendig, um der Datenmenge und Geschwindigkeit, mit der Daten generiert werden, gerecht zu werden. Aber der Ersatz alter durch neue, horizontal skalierende Werkzeuge alleine reicht nicht.
F: Wieso nicht? Könnte man nicht einfach mit Hadoop und Spark ein Big Data Lake aufbauen, um auch mit großen Datenmengen umgehen zu können?
A: So einfach ist es leider nicht. Abgesehen davon, dass viele Unternehmen die Komplexität solcher Big Data Werkzeuge unterschätzen: die Problematik beginnt schon viel früher. Viele Firmen besitzen beispielsweise durchaus große Datenmengen. Doch oftmals sind diese im Unternehmen über verschiedene, teilweise stark abgeschirmte Datensilos verteilt. Hier stellen sich also zunächst mal grundlegende Fragen: welche Daten sind in welcher Form in welchem System vorhanden? Wie kann man systemtechnisch darauf zugreifen? Was möchte ich mit den Daten tun, und welche Daten benötige ich hierfür?
Horizontale Skalierung
F: Ok, dass man zuerst darüber nachdenken sollte, welche Daten man benötigt und wie man sie integriert, erscheint sinnvoll. Aber wieso sollte die Komplexität dieser Werkzeuge ein Problem sein? Es sind doch einfach nur Werkzeuge…
A: Richtig, auf den ersten Blick sind es einfach nur Werkzeuge, die in der Lage sind, große Datenmengen zu verwalten oder die in der Lage sind, aus Echtzeitdaten das Kundenverhalten oder die Ausfallwahrscheinlichkeit einer Maschine vorherzusagen. Hierfür ist aber nicht ein einziges, sondern eine ganze Reihe von Werkzeugen notwendig, die zuverlässig in einem verteilten System zusammenarbeiten müssen.
F: Das ist aber doch nicht neu! Systeme wie Datenbanken, Data Warehouses, BI-Werkzeuge etc. werden doch schon lange miteinander vernetzt eingesetzt.
A: Ja, natürlich. Jedes dieser Werkzeuge läuft jedoch auf einzelnen dedizierten Servern, die man entsprechend ausbauen muss, falls die Performanz nicht mehr reicht. Diese vertikale Skalierung führt bei zunehmend größer werdenden Datenmengen zu immer höheren Kosten und stößt auch bald an technologische Grenzen, wo dies keinen Sinn mehr macht.
F: Und was machen diese Big Werkzeuge dann anders?
A: Diese Werkzeuge wurden von Beginn an als verteilte Systeme konzipiert, die in einem Verbund kleiner kostengünstiger Server synchronisiert zusammenarbeiten. Reicht die Performanz nicht aus, erweitert man das System durch zusätzliche kostengünstige Server. Das nennt man horizontale Skalierung und funktioniert auch zur Laufzeit. Somit ermöglichen diese Systeme eine einfachere dynamische Anpassung an die Lastsituation.
Datenpartitionierung
F: Ok, man hat hier also eine horizontale statt einer vertikalen Skalierung. Das sind aber ja technische Details über die prinzipielle Funktionsweise. Das muss einen Data Scientist aber doch nicht interessieren, er will ja lediglich auch mal größere Datenmengen z.B. in einer NoSQL-Datenbank speichern können?!
A: Das ist ein Irrtum. Bei relationalen Datenbanken modelliert man die Daten in Form von Tabellen und Relationen, und greift mittels SQL standardisiert auf diese Tabellen und Relationen zu. Im Big Data Bereich hat man es dagegen mit einem verteilten System zu tun, d.h. man muss seine Daten partitionieren und möglichst gleichmäßig auf das Cluster verteilen, damit man durch die Parallelverarbeitung auch die gewünschte Performanz erzielen kann.
F: Man muss hier nun also nicht mehr in Tabellen und Relationen denken, sondern in Datenpartitionen?
A: Richtig. Da diese Systeme nur Zugriffe über die Datenpartitionen erlauben, muss man zunächst über eine sinnvolle Aufteilung der Daten nachdenken, um eine schnelle Antwortzeit erzielen zu können. Dazu muss man wiederum die gewünschten Anfragen an die Datenbank kennen. Würde man seine Daten in Tabellen und Relationen modellieren, muss das System u.U. auf viele Datenpartitionen zugreifen. Dies würde das System bei großen Datenmengen schnell überlasten – wenn das System überhaupt solche Anfragen zulassen würde.
F: Und was passiert, wenn neue Anfragen hinzukommen, für die keine passenden Datenpartitionierungen existieren?
A: Dann ergänzt man seine Modellierung durch eine weitere Datenpartitionierung, die der neuen Anfrage entspricht – oder noch besser, die einer neuen Gruppe von Anfragetypen entspricht. Man hat also für Gruppen von Anfragetypen entsprechend passende Modellierungen, um schnelle Antwortzeiten gewährleisten zu können. Es werden also Datenpunkte u.U. vielfach gespeichert.
F: Dann würde aber doch aus einer großen Datenmenge ganz schnell noch eine viel größere Datenmenge werden?
A: Vollkommen richtig. Deshalb ist es – wie bereits oben erwähnt – sinnvoll, sich zunächst Gedanken darüber zu machen, welche Daten man benötigt und wie man darauf zugreifen möchte. Und welche Konsistenzbedingungen man an die Daten stellt.
Eventual Consistency
F: Konsistenzbedingungen? Sind denn die Daten, wenn ich sie gespeichert habe, nicht immer konsistent?
A: Keineswegs. Wir haben es mit verteilten Systemen zu tun. Einzelne Server können ausfallen oder Teiles des Systems sind durch Netzwerkfehler nicht erreichbar. Damit ein solches System zuverlässig funktioniert, müssen die Datenpartitionen durch Replikation mehrfach auf unterschiedlichen Servern gespeichert werden, damit das System in Fehlerfall auf diese Replikate zugreifen und eine Antwort liefern kann. Das Speichern eines Datenpunktes auf mehrere Server kostet aber Zeit und kann im Fehlerfall durchaus auch mal länger dauern, bis der Datenpunkt auf Replikat-Servern gespeichert ist. Das nennt man auch „Eventual Consistency“. Mit anderen Worten: es kann eine Zeit dauern, bis alle Replikate auf dem gleichen konsistenten Stand sind.
F: Und was passiert in der Zwischenzeit? Oder anders gefragt: ist das System ab dem Zeitpunkt, zu dem ein Datenpunkt geschrieben wird, und dem Zeitpunkt, zu dem das System wieder in einem konsistenten Zustand ist, nicht mehr erreichbar?
A: Ja und Nein. Man kann steuern, ob man eine hohe Erreichbarkeit oder eine strikte Konsistenz haben möchte. Bei manchen Systemen kann man dies sogar für einzelne Anfragen steuern. Nehmen wir z.B. Netflix. Wenn in den USA ein neues Video eingespielt wird, kann es eine ganze Zeit dauern, bis dieses Video auch im EU-Data-Center zur Verfügung steht. Netflix präferiert hier also eine hohe Erreichbarkeit des Systems gegenüber einer strikten Konsistenz.
F: Ok., so langsam begreife ich, warum Du zuvor erwähnt hast, dass die Komplexität von Big Data Werkzeugen oftmals unterschätzt wird. Angenommen, wir haben unsere Daten nun schön partitioniert. Nun möchte man aber auch die Daten analysieren oder mit Methoden der künstlichen Intelligenz Vorhersagen machen können. Das ist doch hoffentlich einfacher. Wie funktioniert das und welches Werkzeug setzt man hierfür ein?
A: Dazu gibt es eine ganze Reihe guter Werkzeuge wie z.B. Spark oder Flink. Aber ein Werkzeug alleine reicht nicht.
Batch/Stream Processing und Eventual Accuracy
F: Wieso nicht? Ich dachte, dass man z.B. mit Apache Spark auch große Datenmengen analysieren und mit seiner KI-Funktionalität Vorhersagen in nahezu Echtzeit machen kann?
A: Richtig, damit kann man auch große Datenmenge analysieren oder Vorhersagemodelle anlernen. Denn diese Werkzeuge erzielen ihre Geschwindigkeit durch die parallele Datenverarbeitung im Cluster. Aber bei großen Datenmengen kann dies auch durchaus Stunden dauern!
F: Jetzt bin ich verwirrt. Big Data verspricht doch, mit diesen Werkzeugen Antworten in „nahezu Echtzeit“ liefern zu können?
A: Ja, das tun sie. Dies ist auch kein Widerspruch zu dem, was ich zuvor sagte. Es kommt darauf an, wie man diese Systeme einsetzt und wie man sie mit anderen Werkzeugen kombiniert, um diese Performanz in den Antwortzeiten erzielen zu können.
F: Wie muss man sich das vorstellen?
A: Nun, das Konzept ist nicht neu. Die Idee ist, dass man Analyseergebnisse in einem „Batch Processing“ vorberechnet und die Ergebnisse für einen einfachen, aber sehr schnellen lesenden Zugriff als sogenannte „Batch View“ z.B. in einer NoSQL-Datenbank speichert.
F: Sind dann aber die Ergebnisse der Batch View nicht veraltet?
A: Ja, genau, das sind sie. Dauert das „Batch Processing“ vier Stunden, dann liefert die „Batch View“ Ergebnisse, die vier Stunden alt sind.
F: Dieser zeitliche Verzug mag für manche Einsatzzwecke ja noch akzeptabel sein. Was ist aber, wenn ich für neue Daten, z.B. aus Sensornetzwerken, direkt eine Antwort benötige?
A: Dafür gibt es parallel zum „Batch Processing“ noch das „Stream Processing“. Hier liegt der Fokus auf einer möglichst schnellen Analyse der einströmenden Daten. Auch hier werden die Analyseergebnisse als sogenannte „Streaming View“ für einen schnellen Zugriff in einer NoSQL-Datenbank gespeichert. Diese Analysen sind natürlich nicht so exakt wie im „Batch Processing“, da sie ja schnell berechnet werden müssen. Man spricht hier auch von „Eventual Accuracy“.
Lambda-Architektur
F: Und wie bring man nun „Batch Processing“ und „Stream Processing“ zusammen?
A: Hierzu verwendet man die Lambda-Architektur. Diese besteht aus Werkzeugen zur Integration von Daten aus unterschiedlichen Datenquellen, die im sogenannten Master Dataset gespeichert werden. Dieser Master Dataset dient als Input für das „Batch Processing“ und das „Stream Processing“. Ein Zugriff auf Analyseergebnisse erfolgt nun dadurch, dass man „alte“ exakte Ergebnisse aus der „Batch View“ mit „neuen“ aber nicht ganz so exakten Ergebnissen aus der „Streaming View“ kombiniert.
F: Und wie ist das mit den Vorhersagemodellen? Wie realisiert man z.B. Predictive Maintenance?
A: Nun, man nutzt das „Batch Processing“ dazu, ein Vorhersagemodell auf einer großen Datenmenge anzulernen. Dieses so angelernte Modell setzt man dann im „Stream Processing“ ein, um eine Vorhersage auf den neu einströmenden Daten zu berechnen.
Schatzsuchermentalität
F: Ich fasse mal zusammen. Die technologische Seite von Big Data scheint wohl nicht ganz so trivial zu sein wie man sich das im Allgemeinen so vorstellt. Wie sollte man Deiner Meinung nach denn nun Vorgehen, wenn man Big Data in seinem Unternehmen einführen möchte?
A: Es macht wenig Sinn, vorab viel Geld in kostspielige HW+SW und/oder Data Scientists zu investieren, ohne vorher zu wissen, welches Potential in den eigenen Daten steckt und wie man daraus einen Mehrwert erzielen könnte. In unseren Big Data-Projekten stellen wir jedoch immer wieder diese Vorgehensweise fest.
F: Woran liegt das?
A: Ich nenne das scherzhaft „Die Schatzsuchermentalität“. Man hofft, dass – wenn man nur genügend Daten zusammenführt – schlussendlich ein Wunder passiert und man die Killer-Korrelation findet, die einem das Business revolutioniert. Realistischer ist es jedoch, zunächst datenbasierte Anwendungsszenarien zu entwickeln und diese anschließend hinsichtlich ihrer Umsetzbarkeit und ihres Mehrwertes gezielt zu evaluieren.
F: Aber dazu braucht man doch vorab entsprechende Investitionen in ein Cluster, Big Data Werkzeuge und entsprechende Analysekompetenzen. Oder etwa nicht?
A: Nicht bevor man besser abschätzen kann, welcher Mehrwert in den eigenen Daten stecken könnte. Daher ist es besser, zunächst datenbasierte Use-Cases und die hierfür notwendigen Daten zu identifizieren und diese anschließend mit geeigneten Technologien und Ansätzen iterativ und inkrementell auszuprobieren. Das hilft dabei, die Anforderungen schrittweise besser abschätzen und schließlich eine begründete Entscheidung hinsichtlich einer Umsetzung mit Big Data Technologien treffen können.
Big Data Potentialanalyse
F: OK, Dein Vorgehen klingt logisch, aber auch sehr aufwändig. Dauert dieses Vorgehen nicht Jahre bevor man zu einem Ergebnis kommt?
A: Nein, ganz im Gegenteil. Mit Hilfe eines iterativen, inkrementellen Ansatzes versucht man, schon möglichst früh entscheiden zu können, ob die Realisierung eines datenbasierten Use-Cases mit Hilfe von Big Data zielführend ist oder nicht. Am Fraunhofer IESE haben wir hierfür eine konkrete Vorgehensweise entwickelt: die „Big Data Potentialanalyse“. Diese setzen wir erfolgreich sowohl bei internen Projekten als auch bei Kundenprojekten ein.
F: Wie genau funktioniert diese „Big Data Potentialanalyse“?
A: Vereinfachend zusammengefasst: wir bringen verschiedene Stake-Holder aus der Domäne, dem Business und der Technik zusammen, und erarbeiten bzw. verfeinern z.B. in Kreativitätsworkshops konkrete datenbasierten Use-Cases. Hierbei werden beispielsweise Anforderungen hinsichtlich der Datenintegration (welche Daten sind notwendig und wie kann man auf sie zugreifen, wie gut oder schlecht ist die Datenqualität ist, welche Daten fehlen und wie kann man sie erfassen, etc.), der gewünschten Performanz, potentiell einsetzbarer Analyseansätze sowie der vorhandenen und notwendigen Ressourcen (HW, SW, Kompetenzen) erarbeitet.
Readiness-Analyse
F: Man spezifiziert also zunächst konkrete datenbasierte Use-Cases und ihre Anforderungen. Soweit so gut. Anschließend investiert man dann doch in ein Cluster oder mietet sich eines in der Cloud und beginnt dann mit Big Data Technologien diese Use-Cases umzusetzen. Was ist aber dann der Mehrwert der „Big Data Potentialanalyse“?
A: Die konkrete Spezifikation datenbasierter Use-Cases ist in der Tat nicht neu. Wir legen aber den Fokus ganz klar auf die Anforderungen hinsichtlich einer Umsetzung mit Big Data Technologien. Dies ermöglicht es uns, im zweiten Schritt der Potentialanalyse, der „Readiness-Analyse“, einen inkrementellen, agilen Prozess zur prototypischen Umsetzung realisieren zu können.
F: Wie muss ich mir diese „Readiness-Analyse“ vorstellen?
A: Wir beginnen hier nicht gleich mit einem großen Cluster. Ein Laptop oder ein kleiner Server kann u.U. schon ausreichen, um festzustellen, ob ein angedachter Use-Case mit den vorliegenden Daten tatsächlich sinnvoll umsetzbar ist oder nicht. Hat ein Use-Case diese erste Hürde geschafft kann im nächsten Schritt mit einem kleinen kostengünstigen Cluster, bestehend aus lediglich zwei bis drei kleinen Servern, evaluiert werden, wie gut die Datenintegration und der Analyseansatz bei etwas größeren Datenmengen funktioniert, wie gut das „Batch Processing“ und „Stream Processing“ funktioniert, etc. Durch die horizontale Skalierbarkeit der Big Data Technologien können wir so einen inkrementellen, agilen Ansatz realisieren. Bis hin zur Integration in die bestehende Systemlandschaft.
F: Das klingt ja sehr interessant!
A: Ja, tut es J. Für mehr Einblicke in unsere „Big Data Potentialanalyse“ möchte ich hier auf weitere Beiträge in unserem Fraunhofer IESE-Blog und auf unsere Homepage verweisen. Wir bieten auch Schulungen an, sowohl hausintern als auch im Rahmen der „Fraunhofer-Allianz Big Data“. Und natürlich kundenspezifisch angepasste Workshops.
Garbage In – Garbage Out
F: Abschließend noch eine Frage bzgl. aktueller Forschungsthemen. Als Institut der Fraunhofer Gesellschaft steht ja die angewandte Forschung im Fokus des Fraunhofer IESE. Wo siehst Du momentan den größten Handlungsbedarf?
A: Da gibt es für unser Institut viel zu tun. Beispielsweise im Bereich der Datenqualität. Hier benötigen wir einfach anzuwendende Qualitätsmodelle und horizontal skalierende Verfahren. Ohne eine gute Datenqualität nutzen auch aufwändige maschinelle Lernverfahren nichts. Das gleiche gilt auch für die Phase der Datenaufbereitung, die einen Analysten in der Regel sehr viel Zeit kostet. Für große Datenmengen wird das noch komplizierter, da viele Algorithmen nicht für große Datenmengen geeignet sind. Und für beide Themenkomplexe benötigen wir auch entsprechend angepasste Verfahren zur Visualisierung großer Datenmengen, um dem explorativ-interaktiven Charakter von Datenanalysen gerecht zu werden.
F: OK, das klingt aber noch sehr grundlegend. Wie sieht es mit konkreten Anwendungen aus?
A: Neben diesen domänenübergreifenden Grundproblemen gilt es auch einen großen Forschungsbedarf zur gezielten Nutzung künstlicher Intelligenz im Energiesektor, Maschinenbau, Industrie, Medizintechnik oder im Verkehrsbereich. Wie geht man z.B. mit der Unsicherheit bei maschinelle Lernverfahren in einem sicherheitskritischen Umfeld um? Wie modelliert und entwickelt man intelligente dynamische Systeme, die sich in Abhängigkeit der Aufgabe selbstständig zusammenschließen, um eine Aufgabe zu bewältigen (Smart Ecosystems)? Und wie kann KI dazu beitragen, diese Systeme zu optimieren, oder diese dynamischen Prozesse besser kontrollieren zu können?
F: Vielen Dank für dieses Interview.
A: Gerne.