Big Data meets Big Data
Wie die Integration von Big Data-Lösungen über Unternehmensgrenzen hinweg gelingen kann
Der Begriff Big Data ist in aller Munde: Praktisch jedes Unternehmen macht heute "irgendetwas" mit Big Data oder beabsichtigt, dies in naher Zukunft zu tun. Aufgrund der Vielschichtigkeit des Themas und der damit verbundenen Komplexität entstehen dabei oftmals Insellösungen, die genau auf die Ziele und den Kontext des jeweiligen Unternehmens optimiert sind. Weitgehend ungenutzt bleibt hingegen das Potenzial, welches in der Analyse von Daten über Unternehmensgrenzen hinweg schlummert. Gerade in Strukturen, in denen einzelne Partner eng zusammenarbeiten, wie z.B. entlang von Zuliefererketten, könnten dadurch jedoch wichtige Erkenntnisse gewonnen werden, die am Ende für alle Mitglieder des Ecosystems von Vorteil wären.
Im Rahmen des vom Bundesministerium für Wirtschaft und Energie geförderten Forschungsprojektes PRO-OPT [1] verfolgen wir das Ziel, Unternehmen in solch dezentral-kooperativen Strukturen die effektive und intelligente Auswertung von Daten zu ermöglichen, wobei die Datenquellen verteilt bei verschiedenen, wirtschaftlich unabhängigen Mitgliedern des Ecosystems liegen. Unsere bisherigen Ergebnisse wollen wir im folgenden Artikel vorstellen.
Bevor man an die technische Realisierung einer entsprechenden Lösung gehen kann, ist es wichtig, sich zunächst die folgenden spezifischen Herausforderungen bewusst zu machen:
- Es ist ungemein wichtig, konkrete Szenarien zu identifizieren, die den Nutzen von Analysen über Unternehmensgrenzen hinweg anschaulich oder – besser noch – messbar werden lassen. Wir erleben häufig, dass sich die Mitglieder eines Ecosystems zwar auf hohem Abstraktionslevel einig über die Sinnhaftigkeit unternehmensübergreifender Auswertungen sind, sich bei der Konkretisierung der Ziele und Use Cases aber sehr schwer tun, nicht zuletzt weil hier kurzfristige gegen mittel- und langfristige Interessen abgewogen werden müssen.
- Eine weitere Herausforderung liegt darin, die Heterogenität der Datenlandschaften in den einzelnen Unternehmen zu erfassen. Die anfallenden Daten unterscheiden sich stark in ihrer Art und Menge, gleichzeitig werden unterschiedlichste Technologien eingesetzt, um diese speichern, verwalten und analysieren zu können. Außerdem befinden sich die Systeme in einem ständigen Weiterentwicklungsprozess: Zum einen kommen aus operativen Gründen kontinuierlich neue Datenquellen hinzu, zum anderen wollen die Unternehmen auch ihre internen Analysemöglichkeiten immer weiter verbessern und bauen daher ihre Big Data-Lösungen stetig aus.
- Ebenfalls eine Kernherausforderung ist es, den Unternehmen eine weitgehende Bewahrung der Datenhoheit zu ermöglichen. Oftmals wird die Freigabe von Daten dabei als binäre Entscheidung wahrgenommen und in Kombination mit nachvollziehbaren Sicherheitsbedenken entscheidet man sich im Zweifelsfall daher eher dagegen, sie im Ecosystem verfügbar zu machen. Umso wichtiger ist es, intelligente Formen der Datennutzungskontrolle in einer Ecosystem-weiten Lösung zu integrieren und den Mitgliedern so die Möglichkeit für eine feingranulare Freigabe der Daten mit zusätzlichen Kontroll- und Schutzmechanismen an die Hand zu geben.
Im Folgenden beschreiben wir, welche Erfahrungen wir bisher beim Umgang mit diesen Herausforderungen im Rahmen von PRO-OPT gesammelt und welche konkreten Hilfsmittel und Lösungsvorschläge wir erarbeitet haben. Wir gehen dabei zunächst auf die Erhebung des Ist-Zustands und die anschließend durchgeführte Potentialanalyse ein, dann beschreiben wir konkrete technische Realisierungen.
Da es sich bei PRO-OPT um ein laufendes Projekt handelt, bei dem die einzelnen Phasen iterativ durchlaufen werden, sind die vorgestellten Ergebnisse zwar lediglich als Momentaufnahme zu sehen, können aber für die Praxis schon jetzt wichtige Hilfestellungen liefern.
Das Forschungsprojekt PRO-OPT – Big Data Produktionsoptimierung in Smart Ecosystems
PRO-OPT ist ein Forschungs- und Entwicklungsprojekt im Rahmen des Technologieprogramms "Smart Data – Innovationen aus Daten" des Bundesministeriums für Wirtschaft und Energie [2]. Ziel ist es, Unternehmen in dezentral-kooperativen Strukturen (Smart Ecosystems) die effektive und intelligente Analyse großer Datenmengen zu ermöglichen. Dabei wurde die exemplarische Lösung in der Automobildomäne angesiedelt, da diese in Deutschland eine Schlüsselstellung besitzt und einen starken Leuchtturmeffekt für weitere Branchen hat. Generell sind die Ergebnisse von PRO-OPT aber auch auf andere Bereiche übertragbar.
Zum PRO-OPT Konsortium gehören die DSA GmbH als Technologie- und Evaluationspartner für den Bereich Automobildiagnose, das Fraunhofer IESE als Forschungspartner für die Bereiche Architektur, Datenqualität und Nutzungskontrolle, die Audi AG als Datenlieferant und Evaluationspartner, das DFKI als Forschungspartner in den Bereichen Datenmodellierung und Data Mining sowie die camLine GmbH als Technologie- und Evaluationspartner für den Bereich Produktionssysteme. Die Konsortialführerschaft liegt dabei bei der DSA GmbH, die technische Projektleitung beim Fraunhofer IESE.
Erhebung des Ist-Zustands und Potentialanalyse
Um die heterogenen Ausgangslagen bei den einzelnen Partnern besser fassbar zu machen, starteten wir zunächst mit einer detaillierten Erhebung des Ist-Zustands. Hierzu dienten verschiedene Gespräche und Workshops mit den Unternehmen, aber auch die Sichtung von Dokumentationsmaterial sowie der Umgang mit Test-Systemen. Diese Tätigkeiten mündeten in einer Potentialanalyse, d. h. zum einen wurde ein Top-Down-Ansatz angewendet, um ausgehend von den Zielen der Unternehmen konkrete Fragestellungen abzuleiten. Zum anderen wurden mit Hilfe eines Bottom-Up-Ansatzes die bestehenden Daten analysiert und aus diesen neue, bisher unbekannte Ziele und Fragestellungen ermittelt. Aufbauend auf den Ergebnissen der Potentialanalyse war es uns dann möglich, verschiedene übergeordnete Szenarien zu identifizieren. Diese verdeutlichen, welchen konkreten Nutzen die Teilnehmer im Ecosystem erlangen, wenn sie ihre Daten in kontrollierter Weise für andere zugänglich machen. Eines dieser Szenarien wird im Beispiel am Ende des Artikels genauer beleuchtet.
Ein wichtiges Hilfsmittel, welches wir dabei im Zuge der Erhebung des Ist-Zustands erarbeitet haben, ist die PRO-OPT Big Data Landscape (vgl. Abb.1). Diese kann eingesetzt werden, um verschiedene Technologien, die im Big Data-Umfeld Relevanz besitzen, durch die Einordnung in Gruppen und Untergruppen miteinander in Bezug zu setzen, d. h. ähnliche Technologien sollten sich in der Landscape an ähnlichen Plätzen befinden. Dabei ist klar, dass zum einen eine solche Einordnung nie vollständig sein kann (es gibt beispielsweise alleine mehr als 150 verschiedene NoSQL-Datenbanken). Zum anderen kann sich Ähnlichkeit natürlich über verschiedene Merkmale ausdrücken, was eine Eingruppierung erschwert. Wir haben für die Einordnung daher den Hauptverwendungszweck der jeweiligen Technologie herangezogen, da in einer Darstellung mit drei oder gar mehr Dimensionen die Übersichtlichkeit verloren gegangen wäre.
Trotz dieser Einschränkungen hat sich die PRO-OPT Big Data Landscape für uns als ein extrem hilfreiches Werkzeug erwiesen, welches wir auch schon in anderen Projekten einsetzen.
Verbesserung der unternehmensinternen Systeme
Durch die Erhebung des Ist-Zustands und die Durchführung der Potentialanalyse legten wir zwar die Basis für die Implementierung einer unternehmensübergreifenden Plattform, allerdings wurde schnell offensichtlich, dass diese Plattform nicht losgelöst von der parallel stattfindenden Weiterentwicklung der unternehmensinternen Systeme der einzelnen Partner betrachtet werden kann.
Daher verfolgten wir die Strategie, zunächst die unternehmensinterne Verbesserung der Systeme voranzubringen und danach aufbauend auf den gewonnen Erkenntnissen an die Realisierung der nötigen Plattform für unternehmensübergreifende Analysen zu gehen. Bei der Weiterentwicklung der einzelnen Lösungen sind wir dabei immer wieder mit denselben Problemen konfrontiert worden:
- Die Datenlandschaften der Unternehmen bestanden aus verschiedenen isolierten Systemen und Datentöpfen, deren Informationen, wenn überhaupt, lediglich in den Köpfen spezialisierter Mitarbeiter verknüpft werden konnten.
- Bestimmte Systeme konnten nur vertikal skaliert werden, was mit sehr hohen Kosten verbunden war und mittelfristig auch technisch an Grenzen stoßen wird.
- Andere Systeme konnten zwar horizontal skaliert werden, lieferten aber aus verschiedenen Gründen nicht die benötigte Performance. Beispielsweise ist ein klassischer MapReduce-Ansatz gut geeignet zur Realisierung zeitlich unkritischer Batch-Jobs, aber oftmals zu langsam für Analysen, bei denen ein Near-Realtime-Ergebnis erwartet wird.
Zur Lösung dieser Probleme haben wir im Rahmen des Projekts verschiedene mögliche Technologien und Architekturen identifiziert und evaluiert. In allen Fällen wählten wir in Zusammenarbeit mit den Unternehmen letztendlich eine Lösung, bei der in irgendeiner Form die verteilte Data Processing Engine Apache Spark [3] als zentrales Element eingesetzt wird. Abb.2 zeigt eine beispielhafte Architektur, wie sie von uns mit einem der beteiligten Partner erarbeitet wurde.
Spark wird dabei als Klammer benutzt, um die verschiedenen existierenden Lösungen in den Unternehmen miteinander zu integrieren und weitere geeignete Technologien anzubinden. Durch die einfache horizontale Skalierbarkeit auf Commodity-Hardware, die guten Performance-Werte und die problemlose Anbindung verschiedenster Datentöpfe konnten wir mit Hilfe von Spark alle Anforderungen der Partner erfüllen.
Die Umsetzung der vorgeschlagenen Architekturen in den jeweiligen Unternehmen kann dabei sukzessive erfolgen, d. h. zunächst kann eine reine Batch-Verarbeitung umgesetzt werden, die Erweiterung um Streaming-Funktionalitäten (Kafka-Cluster, Spark Streaming) kann in einem nachgelagerten Schritt erfolgen.
Realisierung einer unternehmensübergreifenden Plattform
Das Vorhandensein eines Spark-Clusters in allen beteiligten Unternehmen ermöglichte es uns, Spark sozusagen als Pfeiler für die Errichtung einer Technologiebrücke zu nutzen, welche die Insellösungen der einzelnen Unternehmen verbindet und so für die Durchführung unternehmensübergreifender Analysen verwendet werden kann. Die grundlegende Idee: Mitglieder des Ecosystems können über die PRO-OPT Plattform Analysen fahren und dabei auf Datentöpfe zugreifen, welche bei verschiedenen Partnern lokalisiert sind. Die PRO-OPT Plattform verteilt die konkreten Aufgaben über Konnektoren in Form von Spark-Programmen an die Spark-Cluster der einzelnen Partner und führt später die Ergebnisse wieder zusammen.
Die PRO-OPT Plattform, deren übergeordnete Architektur in Abb.3 dargestellt wird, besteht dabei aus folgenden Komponenten:
- PRO-OPT Frontend: Grafische Benutzeroberfläche für die Analyse- und Reporting-Features von PRO-OPT (derzeit noch nicht im Scope der Entwicklung, wird in einer späteren Iteration des Projekts realisiert.
- PRO-OPT API: Über die API lassen sich PRO-OPT Programme definieren. Sie orientiert sich dabei an der bekannten API von Spark, so dass Nutzer mit Entwicklungshintergrund in Spark sich leicht zurechtfinden dürften, erweitert diese aber um PRO-OPT-spezifische Konzepte.
- PRO-OPT Bridge: Nimmt eine über die API definierte PRO-OPT Applikation entgegen und überführt diese in spezielle Spark-Applikationen. Diese werden dann zusammen mit Informationen über den Initiator an die jeweiligen PRO-OPT Konnektoren übertragen. Anschließend werden die Ergebnisse auf der Bridge gesammelt und gegebenenfalls weiter verarbeitet, bevor schließlich das Gesamtresultat zurückgegeben wird.
- PRO-OPT Catalog: Enthält Informationen über alle Datenquellen des jeweiligen Unternehmens, die über PRO-OPT verfügbar sind. In der Regel sind dies eine Beschreibung der Daten, eine eindeutige ID, den genauen Ablageort (z. B. Pfad, Connection String + Tabellenname etc.) und eine Policy, über die feingranular bestimmt werden kann, wie die Quelle genau genutzt werden darf, d. h. wer darf sie nutzen? Wie oft darf sie genutzt werden? Müssen zusätzliche Maßnahmen getroffen werden (Anonymisierung, Filterung etc.)? uvm. Während die Beschreibung und die ID für alle Mitglieder des Ecosystems mit der entsprechenden Nutzungsberechtigung über die API zugänglich sind, können Policies und Ablageort nur vom jeweiligen Owner der Datenquelle gesehen und bearbeitet werden. Die Beschreibung enthält allerdings auch Informationen, die den Nutzer über mögliche Einschränkungen, die sich aufgrund der Policy für ihn ergeben, in Kenntnis setzen.
- PRO-OPT Connector: Nimmt Spark-Applikationen von der PRO-OPT Bridge entgegen und überprüft mit Hilfe eines Policy Decision Points (PDP) die Authentifizierung des Datenzugriffs durch die Applikation. Setzt anschließend sogenannte Policy Enforcement Points (PEP), welche an den entsprechenden Zugriffs- und Verarbeitungspunkten die Richtlinien zur Datennutzung durchsetzen. Die dadurch etablierte Usage Control basiert auf dem Fraunhofer IESE IND2UCE Framework [4], welches im Rahmen von PRO-OPT weiterentwickelt wird. Nach erfolgreicher Vorbearbeitung wird das modifizierte Programm auf dem lokalen Spark-Cluster deployed und das Ergebnis anschließend an die Bridge zurückgegeben.
Momentan liegt der Fokus der Entwicklung auf der Abbildung der Kernfunktionalitäten von Spark und Spark SQL, in weiteren Schritten sollen aber auch andere Module wie MLlib und SparkR integriert werden.
Für den generellen Fall mag die Abhängigkeit der PRO-OPT Plattform vom Vorhandensein eines Spark Clusters in den einzelnen Unternehmen zunächst recht strikt erscheinen. Wir denken aber, dass sich dieser Einwand vor dem Hintergrund der rasanten Verbreitung von Spark, insbesondere auch als Ergänzung oder sogar Ablösung klassischer Hadoop-Stacks, mittelfristig relativieren wird. Außerdem planen wir im weiteren Projektverlauf die PRO-OPT Plattform um Konnektoren zu erweitern, die auch andere Lösungen wie Apache Flink direkt ansprechen können.
Ein praktisches Beispiel
Im Folgenden soll anhand eines konkreten Beispiels die Nutzung und Arbeitsweise der PRO-OPT Plattform verdeutlicht werden: Im Zentrum steht dabei der Reklamationsprozess zwischen Automobilhersteller und Zulieferer, der heute typischerweise folgendermaßen abläuft: In regelmäßigen Abständen (z. B. einmal im Monat) übermitteln die Automobilhersteller sogenannte Belastungsanzeigen (Listen im PDF-, CSV- oder Excel-Format) an die Zulieferer, in welchen alle Teile dieses Zulieferers gelistet werden, die im Feld ausgefallen sind. Ziel der Automobilhersteller ist es dabei, die entsprechenden Reparaturkosten erstattet zu bekommen, wobei die rechtlichen Rahmenbedingungen vertraglich zwischen den Parteien schon vorab geregelt wurden. Der Zulieferer hat entweder die Möglichkeit, die Belastungsanzeigen anzuerkennen oder sie zurückzuweisen, wobei in letzterem Fall die Beweispflicht bei ihm liegt.
In unserem konkreten Beispiel bekommt Zulieferer Z vom Automobilhersteller A immer wieder Belastungsanzeigen für ein bestimmtes, von ihm hergestelltes Steuergerät (ECU), welches auch bei anderen Herstellern verwendet wird, dort aber ohne signifikante Beanstandungen zu verursachen. Da die Reklamationskosten bei Z eine kritische Grenze erreicht haben, wird ein Experte mit der Analyse des Problems beauftragt.
Auf Basis der Belastungsanzeige, der Begutachtung eines betroffenen Teils und den unternehmenseigenen Daten kann der Experte keine Ursache für die Ausfälle feststellen, insbesondere weil die Belastungsanzeige außer der eindeutigen Fahrzeuginformationsnummer (VIN) keine weiteren Informationen über das konkrete Fahrzeug beinhaltet.
Über die PRO-OPT Plattform kann sich der Experte nun ansehen, auf welche internen Daten von Hersteller A er zugreifen kann. Dabei fällt ihm eine Datenquelle delivery auf, die im Catalog von A folgendermaßen beschrieben ist:
{
"id": 126,
"name":"delivery",
"description":"Information on delivered cars",
"fields":{
"vin":{
"description":"Vehicle Identification Number",
"type":"String"
},
"dealer":{
"description":"Id of the dealer",
"type":"integer"
},
"enginetype":{
"description":"Type of the engine (diesel, petrol, etc)",
"type":"String"
},
"configuration":{
"description":"List of codes describing configuration details",
"type":"List"
},
[…]
},
"restrictions":{
"limitrows": {
"max": 100
},
"frequency": {
"maxperday": 1,
"maxpermonth": 10
},
"anonymize": {
"column" : "dealer"
}
}
}Aus dieser Beschreibung erfährt der Experte, dass er über die Quelle delivery für alle ausgelieferten Autos des Herstellers einige Detailinformationen wie Motortyp und Ausstattungsmerkmale erhalten kann. Über den restrictions-Block der Beschreibung ist für ihn zudem ersichtlich, dass es ihm zwar möglich ist, Analysen auf den gesamten Daten zu fahren, ihm aber maximal 100 Zeilen zurückgegeben werden, sowie dass er sie maximal einmal am Tag und maximal zehn Mal im Monat anfragen darf. Außerdem wird er darüber informiert, dass er für das Feld dealer nicht den tatsächlichen, sondern einen anonymisierten Identifier bekommen wird. Die restrictions sind dabei direkt aus der Policy abgeleitet, die A für diese Quelle und diesen Nutzer bzw. dessen Rolle hinterlegt hat.
Die Idee des Experten ist nun, auf Basis der VIN die Belastungsanzeigen mit den eigenen Daten und den Daten aus der delivery-Quelle zu verknüpfen um so einen besseren Überblick über die betroffenen Autos zu bekommen. Die Einschränkungen sind für ihn nicht weiter problematisch, da schon 100 Datensätze ein guter Anhaltspunkt sind und das dealer-Feld für ihn sowieso nicht von großem Interesse ist. Das entsprechende PRO-OPT Programm, welches der Experte zu diesem Zwecke schreibt, wird in Abb.4 illustriert (in einer späteren Ausbaustufe würde er ggf. alternativ das Frontend nutzen).
Hierbei ist zu beachten, dass das vom Experten auf Basis des Katalogeintrags für die Quelle delivery erstellte Spark-Programm vor dem Deployment auf dem Cluster durch den Connector modifiziert wird, d. h. die konkrete Adresse der Datenquelle wird injected und die PEPs werden in Form von Spark-Transformationen eingefügt. Dies wird in Abb.5 verdeutlicht.
Auf Basis der zurückgegebenen Daten kann der Experte nun leicht die Ursache des Problems finden: Das Problem tritt dann auf, wenn Hersteller A das entsprechende Steuergerät, welches für Benzinmotoren konzipiert ist, in einem mit Dieselmotor versehenen Fahrzeug verwendet. Das Teil funktioniert in diesem Fall zwar zunächst reibungslos, ist aber auf die höheren Temperaturen nicht ausgelegt und fällt daher nach einem gewissen Zeitraum im Feld aus.
Zulieferer Z kann auf Basis dieser Informationen die Belastungsanzeige zurückweisen. Und auch für Automobilhersteller A ist das Ergebnis positiv: Er bekommt zwar die Kosten nicht erstattet, kann das Problem aber abstellen, wodurch er seine Produktqualität steigern und letztendlich eine höhere Kundenzufriedenheit erreichen wird.
Fazit & Ausblick
Beim vorgestellte PRO-OPT Ansatz handelt es sich um eine tragfähige Plattform, über die Daten in Smart Ecosystems [5] über Unternehmensgrenzen hinweg für alle Partner nutzbar gemacht werden können. Dabei wird eine Technologiebrücke gebaut, welche die Insellösungen der einzelnen Partner verbindet und gleichzeitig den Ansatzpunkt für eine effektive und flexible Datennutzungskontrolle darstellt. Die PRO-OPT Plattform integriert sich mit bei den Unternehmen angesiedelten Spark-Clustern, mittelfristig sind aber auch Konnektoren zu anderen Tools geplant. Die Entwicklung der einzelnen Komponenten ist derzeit in vollem Gange und wird in den nächsten Monaten vorangetrieben.
Weitere Schwerpunkte unserer zukünftigen Arbeit sind die Definition von Methoden und Best Practices zur leichtgewichtigen, aber dennoch ausdrucksstarken Beschreibung von Daten sowie die Unterstützung von Machine Learning und Predictive Analytics Algorithmen durch die Plattform. Ebenfalls ein wichtiges Thema für uns ist die Realisierung des Frontends und in diesem Kontext generell die Visualisierung von Informationen im Big-Data-Umfeld. Außerdem von großem Interesse im Projekt sind Crowd-Sourcing-Ansätze, über welche wir zukünftig weitere Datenquellen erschließen wollen.
- Website des Forschungsprojekts PRO-OPT
- Smart Data Programm des BMWI
- Apache Spark
- IND2UCE Framework
- Fraunhofer IESE Smart Ecosystems
