Im Technology-Talk im Dezember 2018 ging es um die Buzzwords \u201eBig Data\u201c und \u201eK\u00fcnstliche Intelligenz\u201c. Wir haben uns mit den typischen Stolperfallen und L\u00f6sungen, die sich in der Praxis bew\u00e4hrt haben, besch\u00e4ftigt. Daf\u00fcr stand unser Technologie-Experte Herr Dr. Henning Barthel zur Verf\u00fcgung. Herr Barthel arbeitete \u00fcber 12 Jahren am Fraunhofer IESE und war einer der Dozenten unseres \u201eBasic Data Scientist\u201c-Lehrgangs der Fraunhofer-Allianz Big Data. Das Interview wurde von Herr Dr. Jens Heidrich gef\u00fchrt, der von 2011-2023 als Hauptabteilungsleiter des Fraunhofer IESE f\u00fcr das Thema Prozess-Management zust\u00e4ndig war.<\/p>\n
F: Themen wie Big Data und KI sind ja in aller Munde. Was treibt denn Firmen konkret an, sich damit zu besch\u00e4ftigen?<\/p>\n
A: Im digitalen Zeitalter sind Daten der Rohstoff f\u00fcr wirtschaftliche Wertsch\u00f6pfung. Datenbasierte Gesch\u00e4ftsmodelle in der Produktion, der Medizintechnik, der Logistik, dem Maschinenbau oder in den Bereichen Energie, Mobilit\u00e4t und Verkehr gewinnen zunehmend an Bedeutung. Deswegen besch\u00e4ftigen sich immer mehr Unternehmen damit, ob und – wenn ja – wie eine intelligente Datennutzung f\u00fcr sie von Vorteil w\u00e4re.<\/p>\n
F: Was sind denn die Herausforderungen?<\/p>\n
A: F\u00fcr gro\u00dfe Datenmengen sto\u00dfen klassische Ans\u00e4tze schnell an ihre Grenzen. Stattdessen sind Werkzeuge f\u00fcr 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.<\/p>\n
F: Wieso nicht? K\u00f6nnte man nicht einfach mit Hadoop und Spark ein Big Data Lake aufbauen, um auch mit gro\u00dfen Datenmengen umgehen zu k\u00f6nnen?<\/p>\n
A: So einfach ist es leider nicht. Abgesehen davon, dass viele Unternehmen die Komplexit\u00e4t solcher Big Data Werkzeuge untersch\u00e4tzen: die Problematik beginnt schon viel fr\u00fcher. Viele Firmen besitzen beispielsweise durchaus gro\u00dfe Datenmengen. Doch oftmals sind diese im Unternehmen \u00fcber verschiedene, teilweise stark abgeschirmte Datensilos verteilt. Hier stellen sich also zun\u00e4chst mal grundlegende Fragen: welche Daten sind in welcher Form in welchem System vorhanden? Wie kann man systemtechnisch darauf zugreifen? Was m\u00f6chte ich mit den Daten tun, und welche Daten ben\u00f6tige ich hierf\u00fcr?<\/p>\n
F: Ok, dass man zuerst dar\u00fcber nachdenken sollte, welche Daten man ben\u00f6tigt und wie man sie integriert, erscheint sinnvoll. Aber wieso sollte die Komplexit\u00e4t dieser Werkzeuge ein Problem sein? Es sind doch einfach nur Werkzeuge\u2026<\/p>\n
A: Richtig, auf den ersten Blick sind es einfach nur Werkzeuge, die in der Lage sind, gro\u00dfe Datenmengen zu verwalten oder die in der Lage sind, aus Echtzeitdaten das Kundenverhalten oder die Ausfallwahrscheinlichkeit einer Maschine vorherzusagen. Hierf\u00fcr ist aber nicht ein einziges, sondern eine ganze Reihe von Werkzeugen notwendig, die zuverl\u00e4ssig in einem verteilten System zusammenarbeiten m\u00fcssen.<\/p>\n
F: Das ist aber doch nicht neu! Systeme wie Datenbanken, Data Warehouses, BI-Werkzeuge etc. werden doch schon lange miteinander vernetzt eingesetzt.<\/p>\n
A: Ja, nat\u00fcrlich. Jedes dieser Werkzeuge l\u00e4uft jedoch auf einzelnen dedizierten Servern, die man entsprechend ausbauen muss, falls die Performanz nicht mehr reicht. Diese vertikale Skalierung f\u00fchrt bei zunehmend gr\u00f6\u00dfer werdenden Datenmengen zu immer h\u00f6heren Kosten und st\u00f6\u00dft auch bald an technologische Grenzen, wo dies keinen Sinn mehr macht.<\/p>\n
F: Und was machen diese Big Werkzeuge dann anders?<\/p>\n
A: Diese Werkzeuge wurden von Beginn an als verteilte Systeme konzipiert, die in einem Verbund kleiner kosteng\u00fcnstiger Server synchronisiert zusammenarbeiten. Reicht die Performanz nicht aus, erweitert man das System durch zus\u00e4tzliche kosteng\u00fcnstige Server. Das nennt man horizontale Skalierung und funktioniert auch zur Laufzeit. Somit erm\u00f6glichen diese Systeme eine einfachere dynamische Anpassung an die Lastsituation.<\/p>\n
F: Ok, man hat hier also eine horizontale statt einer vertikalen Skalierung. Das sind aber ja technische Details \u00fcber die prinzipielle Funktionsweise. Das muss einen Data Scientist aber doch nicht interessieren, er will ja lediglich auch mal gr\u00f6\u00dfere Datenmengen z.B. in einer NoSQL-Datenbank speichern k\u00f6nnen?!<\/p>\n
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\u00f6glichst gleichm\u00e4\u00dfig auf das Cluster verteilen, damit man durch die Parallelverarbeitung auch die gew\u00fcnschte Performanz erzielen kann.<\/p>\n
F: Man muss hier nun also nicht mehr in Tabellen und Relationen denken, sondern in Datenpartitionen?<\/p>\n
A: Richtig. Da diese Systeme nur Zugriffe \u00fcber die Datenpartitionen erlauben, muss man zun\u00e4chst \u00fcber eine sinnvolle Aufteilung der Daten nachdenken, um eine schnelle Antwortzeit erzielen zu k\u00f6nnen. Dazu muss man wiederum die gew\u00fcnschten Anfragen an die Datenbank kennen. W\u00fcrde man seine Daten in Tabellen und Relationen modellieren, muss das System u.U. auf viele Datenpartitionen zugreifen. Dies w\u00fcrde das System bei gro\u00dfen Datenmengen schnell \u00fcberlasten \u2013 wenn das System \u00fcberhaupt solche Anfragen zulassen w\u00fcrde.<\/p>\n
F: Und was passiert, wenn neue Anfragen hinzukommen, f\u00fcr die keine passenden Datenpartitionierungen existieren?<\/p>\n
A: Dann erg\u00e4nzt man seine Modellierung durch eine weitere Datenpartitionierung, die der neuen Anfrage entspricht \u2013 oder noch besser, die einer neuen Gruppe von Anfragetypen entspricht. Man hat also f\u00fcr Gruppen von Anfragetypen entsprechend passende Modellierungen, um schnelle Antwortzeiten gew\u00e4hrleisten zu k\u00f6nnen. Es werden also Datenpunkte u.U. vielfach gespeichert.<\/p>\n
F: Dann w\u00fcrde aber doch aus einer gro\u00dfen Datenmenge ganz schnell noch eine viel gr\u00f6\u00dfere Datenmenge werden?<\/p>\n
A: Vollkommen richtig. Deshalb ist es \u2013 wie bereits oben erw\u00e4hnt – sinnvoll, sich zun\u00e4chst Gedanken dar\u00fcber zu machen, welche Daten man ben\u00f6tigt und wie man darauf zugreifen m\u00f6chte. Und welche Konsistenzbedingungen man an die Daten stellt.<\/p>\n
F: Konsistenzbedingungen? Sind denn die Daten, wenn ich sie gespeichert habe, nicht immer konsistent?<\/p>\n
A: Keineswegs. Wir haben es mit verteilten Systemen zu tun. Einzelne Server k\u00f6nnen ausfallen oder Teiles des Systems sind durch Netzwerkfehler nicht erreichbar. Damit ein solches System zuverl\u00e4ssig funktioniert, m\u00fcssen 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\u00e4nger dauern, bis der Datenpunkt auf Replikat-Servern gespeichert ist. Das nennt man auch \u201eEventual Consistency\u201c. Mit anderen Worten: es kann eine Zeit dauern, bis alle Replikate auf dem gleichen konsistenten Stand sind.<\/p>\n
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?<\/p>\n
A: Ja und Nein. Man kann steuern, ob man eine hohe Erreichbarkeit oder eine strikte Konsistenz haben m\u00f6chte. Bei manchen Systemen kann man dies sogar f\u00fcr 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\u00fcgung steht. Netflix pr\u00e4feriert hier also eine hohe Erreichbarkeit des Systems gegen\u00fcber einer strikten Konsistenz.<\/p>\n
F: Ok., so langsam begreife ich, warum Du zuvor erw\u00e4hnt hast, dass die Komplexit\u00e4t von Big Data Werkzeugen oftmals untersch\u00e4tzt wird. Angenommen, wir haben unsere Daten nun sch\u00f6n partitioniert. Nun m\u00f6chte man aber auch die Daten analysieren oder mit Methoden der k\u00fcnstlichen Intelligenz Vorhersagen machen k\u00f6nnen. Das ist doch hoffentlich einfacher. Wie funktioniert das und welches Werkzeug setzt man hierf\u00fcr ein?<\/p>\n
A: Dazu gibt es eine ganze Reihe guter Werkzeuge wie z.B. Spark oder Flink. Aber ein Werkzeug alleine reicht nicht.<\/p>\n
F: Wieso nicht? Ich dachte, dass man z.B. mit Apache Spark auch gro\u00dfe Datenmengen analysieren und mit seiner KI-Funktionalit\u00e4t Vorhersagen in nahezu Echtzeit machen kann?<\/p>\n
A: Richtig, damit kann man auch gro\u00dfe Datenmenge analysieren oder Vorhersagemodelle anlernen. Denn diese Werkzeuge erzielen ihre Geschwindigkeit durch die parallele Datenverarbeitung im Cluster. Aber bei gro\u00dfen Datenmengen kann dies auch durchaus Stunden dauern!<\/p>\n
F: Jetzt bin ich verwirrt. Big Data verspricht doch, mit diesen Werkzeugen Antworten in \u201enahezu Echtzeit\u201c liefern zu k\u00f6nnen?<\/p>\n
A: Ja, das tun sie. Dies ist auch kein Widerspruch zu dem, was ich zuvor sagte. \u00a0Es 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\u00f6nnen.<\/p>\n
F: Wie muss man sich das vorstellen?<\/p>\n
A: Nun, das Konzept ist nicht neu. Die Idee ist, dass man Analyseergebnisse in einem \u201eBatch Processing\u201c vorberechnet und die Ergebnisse f\u00fcr einen einfachen, aber sehr schnellen lesenden Zugriff als sogenannte \u201eBatch View\u201c z.B. in einer NoSQL-Datenbank speichert.<\/p>\n
F: Sind dann aber die Ergebnisse der Batch View nicht veraltet?<\/p>\n
A: Ja, genau, das sind sie. Dauert das \u201eBatch Processing\u201c vier Stunden, dann liefert die \u201eBatch View\u201c Ergebnisse, die vier Stunden alt sind.<\/p>\n
F: Dieser zeitliche Verzug mag f\u00fcr manche Einsatzzwecke ja noch akzeptabel sein. Was ist aber, wenn ich f\u00fcr neue Daten, z.B. aus Sensornetzwerken, direkt eine Antwort ben\u00f6tige?<\/p>\n
A: Daf\u00fcr gibt es parallel zum \u201eBatch Processing\u201c noch das \u201eStream Processing\u201c. Hier liegt der Fokus auf einer m\u00f6glichst schnellen Analyse der einstr\u00f6menden Daten. Auch hier werden die Analyseergebnisse als sogenannte \u201eStreaming View\u201c f\u00fcr einen schnellen Zugriff in einer NoSQL-Datenbank gespeichert. Diese Analysen sind nat\u00fcrlich nicht so exakt wie im \u201eBatch Processing\u201c, da sie ja schnell berechnet werden m\u00fcssen. Man spricht hier auch von \u201eEventual Accuracy\u201c.<\/p>\n
F: Und wie bring man nun \u201eBatch Processing\u201c und \u201eStream Processing\u201c zusammen?<\/p>\n
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\u00fcr das \u201eBatch Processing\u201c und das \u201eStream Processing\u201c. Ein Zugriff auf Analyseergebnisse erfolgt nun dadurch, dass man \u201ealte\u201c exakte Ergebnisse aus der \u201eBatch View\u201c mit \u201eneuen\u201c aber nicht ganz so exakten Ergebnissen aus der \u201eStreaming View\u201c kombiniert.<\/p>\n
F: Und wie ist das mit den Vorhersagemodellen? Wie realisiert man z.B. Predictive Maintenance?<\/p>\n
A: Nun, man nutzt das \u201eBatch Processing\u201c dazu, ein Vorhersagemodell auf einer gro\u00dfen Datenmenge anzulernen. Dieses so angelernte Modell setzt man dann im \u201eStream Processing\u201c ein, um eine Vorhersage auf den neu einstr\u00f6menden Daten zu berechnen.<\/p>\n
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\u00fchren m\u00f6chte?<\/p>\n
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\u00f6nnte. In unseren Big Data-Projekten stellen wir jedoch immer wieder diese Vorgehensweise fest.<\/p>\n
F: Woran liegt das?<\/p>\n
A: Ich nenne das scherzhaft \u201eDie Schatzsuchermentalit\u00e4t\u201c. Man hofft, dass – wenn man nur gen\u00fcgend Daten zusammenf\u00fchrt – schlussendlich ein Wunder passiert und man die Killer-Korrelation findet, die einem das Business revolutioniert. Realistischer ist es jedoch, zun\u00e4chst datenbasierte Anwendungsszenarien zu entwickeln und diese anschlie\u00dfend hinsichtlich ihrer Umsetzbarkeit und ihres Mehrwertes gezielt zu evaluieren.<\/p>\n
F: Aber dazu braucht man doch vorab entsprechende Investitionen in ein Cluster, Big Data Werkzeuge und entsprechende Analysekompetenzen. Oder etwa nicht?<\/p>\n
A: Nicht bevor man besser absch\u00e4tzen kann, welcher Mehrwert in den eigenen Daten stecken k\u00f6nnte. Daher ist es besser, zun\u00e4chst datenbasierte Use-Cases und die hierf\u00fcr notwendigen Daten zu identifizieren und diese anschlie\u00dfend mit geeigneten Technologien und Ans\u00e4tzen iterativ und inkrementell auszuprobieren. Das hilft dabei, die Anforderungen schrittweise besser absch\u00e4tzen und schlie\u00dflich eine begr\u00fcndete Entscheidung hinsichtlich einer Umsetzung mit Big Data Technologien treffen k\u00f6nnen.<\/p>\n
F: OK, Dein Vorgehen klingt logisch, aber auch sehr aufw\u00e4ndig. Dauert dieses Vorgehen nicht Jahre bevor man zu einem Ergebnis kommt?<\/p>\n
A: Nein, ganz im Gegenteil. Mit Hilfe eines iterativen, inkrementellen Ansatzes versucht man, schon m\u00f6glichst fr\u00fch entscheiden zu k\u00f6nnen, ob die Realisierung eines datenbasierten Use-Cases mit Hilfe von Big Data zielf\u00fchrend ist oder nicht. Am Fraunhofer IESE haben wir hierf\u00fcr eine konkrete Vorgehensweise entwickelt: die \u201eBig Data Potentialanalyse\u201c. Diese setzen wir erfolgreich sowohl bei internen Projekten als auch bei Kundenprojekten ein.<\/p>\n
F: Wie genau funktioniert diese \u201eBig Data Potentialanalyse\u201c?<\/p>\n
A: Vereinfachend zusammengefasst: wir bringen verschiedene Stake-Holder aus der Dom\u00e4ne, dem Business und der Technik zusammen, und erarbeiten bzw. verfeinern z.B. in Kreativit\u00e4tsworkshops 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\u00e4t ist, welche Daten fehlen und wie kann man sie erfassen, etc.), der gew\u00fcnschten Performanz, potentiell einsetzbarer Analyseans\u00e4tze sowie der vorhandenen und notwendigen Ressourcen (HW, SW, Kompetenzen) erarbeitet.<\/p>\n
F: Man spezifiziert also zun\u00e4chst konkrete datenbasierte Use-Cases und ihre Anforderungen. Soweit so gut. Anschlie\u00dfend 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 \u201eBig Data Potentialanalyse\u201c?<\/p>\n
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\u00f6glicht es uns, im zweiten Schritt der Potentialanalyse, der \u201eReadiness-Analyse\u201c, einen inkrementellen, agilen Prozess zur prototypischen Umsetzung realisieren zu k\u00f6nnen.<\/p>\n
F: Wie muss ich mir diese \u201eReadiness-Analyse\u201c vorstellen?<\/p>\n
A: Wir beginnen hier nicht gleich mit einem gro\u00dfen Cluster. Ein Laptop oder ein kleiner Server kann u.U. schon ausreichen, um festzustellen, ob ein angedachter Use-Case mit den vorliegenden Daten tats\u00e4chlich sinnvoll umsetzbar ist oder nicht. Hat ein Use-Case diese erste H\u00fcrde geschafft kann im n\u00e4chsten Schritt mit einem kleinen kosteng\u00fcnstigen Cluster, bestehend aus lediglich zwei bis drei kleinen Servern, evaluiert werden, wie gut die Datenintegration und der Analyseansatz bei etwas gr\u00f6\u00dferen Datenmengen funktioniert, wie gut das \u201eBatch Processing\u201c und \u201eStream Processing\u201c funktioniert, etc. Durch die horizontale Skalierbarkeit der Big Data Technologien k\u00f6nnen wir so einen inkrementellen, agilen Ansatz realisieren. Bis hin zur Integration in die bestehende Systemlandschaft.<\/p>\n
F: Das klingt ja sehr interessant!<\/p>\n
A: Ja, tut es J. F\u00fcr mehr Einblicke in unsere \u201eBig Data Potentialanalyse\u201c m\u00f6chte ich hier auf weitere Beitr\u00e4ge in unserem Fraunhofer IESE-Blog und auf unsere Homepage verweisen. Wir bieten auch Schulungen an, sowohl hausintern als auch im Rahmen der \u201eFraunhofer-Allianz Big Data\u201c. Und nat\u00fcrlich kundenspezifisch angepasste Workshops.<\/p>\n
F: Abschlie\u00dfend 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\u00f6\u00dften Handlungsbedarf?<\/p>\n
A: Da gibt es f\u00fcr unser Institut viel zu tun. Beispielsweise im Bereich der Datenqualit\u00e4t. Hier ben\u00f6tigen wir einfach anzuwendende Qualit\u00e4tsmodelle und horizontal skalierende Verfahren. Ohne eine gute Datenqualit\u00e4t nutzen auch aufw\u00e4ndige maschinelle Lernverfahren nichts. Das gleiche gilt auch f\u00fcr die Phase der Datenaufbereitung, die einen Analysten in der Regel sehr viel Zeit kostet. F\u00fcr gro\u00dfe Datenmengen wird das noch komplizierter, da viele Algorithmen nicht f\u00fcr gro\u00dfe Datenmengen geeignet sind. Und f\u00fcr beide Themenkomplexe ben\u00f6tigen wir auch entsprechend angepasste Verfahren zur Visualisierung gro\u00dfer Datenmengen, um dem explorativ-interaktiven Charakter von Datenanalysen gerecht zu werden.<\/p>\n
F: OK, das klingt aber noch sehr grundlegend. Wie sieht es mit konkreten Anwendungen aus?<\/p>\n
A: Neben diesen dom\u00e4nen\u00fcbergreifenden Grundproblemen gilt es auch einen gro\u00dfen Forschungsbedarf zur gezielten Nutzung k\u00fcnstlicher 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\u00e4ngigkeit der Aufgabe selbstst\u00e4ndig zusammenschlie\u00dfen, um eine Aufgabe zu bew\u00e4ltigen (Smart Ecosystems)? Und wie kann KI dazu beitragen, diese Systeme zu optimieren, oder diese dynamischen Prozesse besser kontrollieren zu k\u00f6nnen?<\/p>\n
F: Vielen Dank f\u00fcr dieses Interview.<\/p>\n
A: Gerne.<\/p>\n","protected":false},"excerpt":{"rendered":"
Im Technology-Talk im Dezember 2018 ging es um die Buzzwords \u201eBig Data\u201c und \u201eK\u00fcnstliche Intelligenz\u201c. Wir haben uns mit den typischen Stolperfallen und L\u00f6sungen, die sich in der Praxis bew\u00e4hrt haben, besch\u00e4ftigt. Daf\u00fcr stand unser Technologie-Experte Herr Dr. Henning Barthel…<\/p>\n","protected":false},"author":11,"featured_media":3188,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[177],"tags":[26,104],"coauthors":[41],"class_list":["post-3118","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-kuenstliche-intelligenz","tag-big-data","tag-data-analytics"],"yoast_head":"\n