Smart Data Technology Stack

Von Henrik Oppermann Vor 2 JahrenKeine Kommentare
Home  /  Industrie  /  Smart Data Technology Stack

Zunehmend mehr Sensoren in Maschinen und Anlagen sowie die weite Verbreitung von Remote-Plattformen verändern die Basis, auf der Unternehmen ihre Services anbieten. Im Zuge von Industrie 4.0 und des Internets of Things (IoT) entdecken immer mehr Unternehmen das Potential, auf Basis dieser Daten neue Service-Produkte anbieten zu können. Viele Unternehmen generieren aber mehr Daten, als sie speichern, korrelieren und analysieren können. Da die Daten schnell und in großen Mengen erzeugt werden, können Unternehmen häufig nicht schnell genug reagieren, um die Informationen in Smart Services zu verwandeln. Der hier vorgestellte Technologieansatz auf einer flexibel skalierbaren Plattform kann riesige Datenmengen (Volume) sehr schnell (Velocity) in einer einheitlichen Architektur verarbeiten.

Anwendungsbeispiele aus der Druckindustrie

Durch die andauernde Konsolidierung in der Druckindustrie verlagert sich der Kundenstamm der Heidelberger Druckmaschinen AG (HDM) beispielsweise mehr und mehr hin zu Druckereien, die im Dreischichtbetrieb (24/7) mit engen Lieferfristen hochautomatisiert produzieren. Das führt dazu, dass HDM auf einen veränderten Servicebedarf reagieren muss. Hierbei geht es im Wesentlichen um das frühzeitige Erkennen von Unregelmäßigkeiten anhand von online verfügbaren Maschinendaten. Ziel ist es, durch geplante Servicemaßnahmen aufkommende Störungen zu erkennen und zu eliminieren, bevor sie den Produktionsprozess stören. Damit wird die höchste Verfügbarkeit der Maschine dank intelligent geplanter, proaktiver Serviceeinsätze erreicht. Der Qualität der Vorhersagen kommt dabei eine besondere Bedeutung zu, da Fehlalarme mit unnötigem Maschinenstillstand und Produktionsausfall extrem teuer werden können.Zur Auslegung des Systems und damit zur Auswahl der Komponenten ist das Projekt SAKE von folgenden Anforderungen ausgegangen:

  • Auswertung von Logdateien für über 2.000 Druckmaschinen
  • jeden Tag 4 Mio. Datensätze pro Maschine (ca. 300 MB): Neue Logdateien sollen sofort prozessiert werden, zur schnellen Weiterleitung von Warnmeldungen sowie zur Aufbereitung von Daten für Dashboards oder Drittsysteme
  • Daten sollen bis zu drei Jahre für weitere Auswertungen vorgehalten werden (ca. 600 TB)
  • Symptomscanner muss online auch Auswertungen auf historischen Daten ausführen können
  • Machine-Learning- und Data-Mining-Ansätze werden auf sehr großen Datenmengen angewendet (ca. 600 Mrd. Datensätze) und dienen zum Aufdecken von Zusammenhängen bei unbekannten Fehlern
  • Ingenieure untersuchen, ob ein Kausalzusammenhang besteht; wenn ja, wird dies als Regel formuliert und mittels CEP kontinuierlich überprüft: Qualitätsgesicherte Auswertung unbekannter Zusammenhänge auf Echtzeitdaten

Damit stellen sich neben vielen anderen funktionalen Anforderungen für die Plattform vor allem die beiden Big-Data-Dimensionen Volume und Velocity als maß
gebliche Designparameter heraus. In der Literatur wird als Referenz gerne die Lambda-Architektur genannt, die für die beiden Dimensionen separate Datenverarbeitungsschichten vorsieht: den Batch Layer für große historische Datenmengen und den Speed Layer für die Verarbeitung von Realtime-Daten. Dieser Ansatz der separaten Verarbeitung widerspricht aber der Anforderung, historische Daten schon in der Verarbeitung von Logdatenströmen (Realtime) zu ermöglichen. Als wesentliche nichtfunktionale Anforderungen waren für die Auswahl der Komponenten die Langlebigkeit und die Unterstützung durch eine Community wichtig, um die Investitionssicherheit zu erhöhen und die Entwicklungskosten zu senken.

Entlang der oben dargestellten Taxonomie will das Smart-Data-Projekt SAKE die Auswahl der wesentlichen Komponenten begründen und die Gesamt architektur zusammenfassen.

die Auswahl der Datenbank

Dabei garantiert das umfangreiche Ökosystem von Spark und seine weitreichende Unterstützung(u. a. durch IBM und Yahoo) die Sicherheit der
Investitionen und ermöglicht es gleichzeitig, die Entwicklungskosten zu senken. So kann durch die in Spark integrierte Machine-Learning-Bibliothek MLlibauf eine Vielzahl von Algorithmen zugegriffen werden (siehe auch den nächsten Abschnitt).

Anforderungen an Datenhaltung, -zugriff und -verarbeitung

Als wesentliche Kriterien in Bezug auf die Datenhaltungergaben sich a) eine lineare Skalierbarkeit in denzweistelligen Terabyte-Bereich (und damit Abbildung
eines DB-Clusters), b) eine hohe Schreibrate, c) Unterstützung von Replikation für die Ausfallsicherheit sowie d) Produktionsreife und Investitionssicherheit.

Die Tabelle fasst unsere Betrachtung von Systemen und die Auswahl zusammen.

Derzeit ist der größte bekannte Apache-Cassandra-Cluster bei Apple mit mehr als 75.000 Knoten und über 10 PB Datenvolumen installiert und demonstriert deutlich das Thema Skalierung. Weitere bekannte Nutzer sind Google und Netflix. Letzteres Unternehmen verfügt über mehr als 2.500 Knoten und verzeichnet über 1 Billion Zugriffe am Tag. Ergänzend wird für die Archivierung der historischen Daten auf das verteilte Dateisystem HDFS zurückgegriffen und Logdateien zusätzlich über das Parquet- Dateiformat abgelegt. Datenspeicherung in Dateien bietet sich an für Daten, die in sehr großer Menge anfallen, nach der Vereinnahmung nicht mehr umstrukturiert oder aktualisiert werden müssen und nur sequentiell gelesen werden. Das Parquet-Format zeichnet sich darüber hinaus durch hohe Kompressionsraten, parallele Verarbeitbarkeit und eine sehr hohe Schreib- und Lesegeschwindigkeit aus.

Wesentliche Kriterien zur Technologieauswahl bei Datenzugriff und -verarbeitung waren a) die Unterstützung von Datenströmen und historischen Daten, b) die interaktive Datenanalyse für große Datenmengen (historische Daten für Monate), c) hoch performante Unterstützung für iterative Algorithmen (Machine Learning), d) eine große Community (Ökosystem) und Produktionsreife.

Folgende Tabelle fasst die Betrachtung und Auswahl zusammen:

2

die Auswahl der Verarbeitungsplattform

Dabei garantiert das umfangreiche Ökosystem von Spark18 und seine weitreichende Unterstützung (u. a. durch IBM20 und Yahoo21) die Sicherheit der
Investitionen und ermöglicht es gleichzeitig, die Entwicklungskosten zu senken. So kann durch die in Spark integrierte Machine-Learning-Bibliothek MLlib22 auf eine Vielzahl von Algorithmen zugegriffen werden (siehe auch den nächsten Abschnitt).

Bei der analytischen Verarbeitung kommen neben der in Spark integrierbaren MLlib auch Eigenentwicklungen im Bereich der Algorithmen und Complex Event Processing (CEP) zum Einsatz. Denn hier sollen die Auswertungen bei Bedarf durch Anpassung der Konfiguration leicht horizontal und vertikal verteilt werde können und mit dem gleichen Werkzeug für Datenströme und Stapelverarbeitung (historische Daten) formulierbar sein. Zudem müssen komplexere Auswertungsschritte in Java-Klassen formuliert und ausgelagert werden können (höhere Ausdrucksmächtigkeit als z. B. SQL) und eine deklarative Beschreibung des Event Processing Networks möglich sein. Für diese Anforderungen sind aber gängige CEP-Engines nicht ausgelegt: Gerade der Einbezug historischer Daten ist bei diesen meist nicht vorgesehen. Wir haben daher eine eigene CEP-Engine und -Entwicklungsumgebung auf Basis von Eclipse23 realisiert. Ebenso existiert eine Management-Konsole für die Verwaltung der verschiedenen Auswertungen und das Deployment derselbigen. Eine eigens entwickelte Sprache (Domain Specific Language, DSL) ermöglicht hierbei eine leichtere Formulierung von Auswertungsregeln.

Für die interaktive Diagnose wurde ein Notebook- Konzept auf Basis von Apache Zeppelin24 realisiert, mit dem Maschinen-Analysten in verschiedenen Skriptsprachen Hypothesen und Auswertungen formulieren, auf Echtdaten ausprobieren und deren Auswirkungen überprüfen können. Es stellt ein wichtiges Instrument zur Formulierung von Überwachungsregeln dar.

Die Gesamtarchitektur und Fazit

In der folgenden Abbildung ist der Big Data Stack der USU Software AG dargestellt. Als Besonderheit haben wir das im Hadoop-Umfeld gängige Tool zur Ressourcenverwaltung Apache YARN durch Apache Mesos ersetzt. Grund war das genauere Ressourcen-Management für unterschiedliche Frameworks, z. B. das Zusammenspiel von Spark, Cassandra etc. Als Nachteil anzusehen ist, dass das Cluster-Management wenig intuitiv ist. Das System ist derzeit On-Premise und als Private Cloud betreibbar. Im Rahmen der Smart-Data-Projekte SAKE und SmartRegio wird u. a. eine Public-Cloud-Version entwickelt. Ein wesentlicher Nutzen neben der präzisen Vorhersage von Fehlern in Anlagen und Maschinen (Predictive Maintenance) ist der Erkenntnisgewinn durch die tiefe Analyse und Vergleiche auf Basis von Massendaten und Clusterbildung. Durch Peer-Group-Vergleiche lassen sich so etwa Optimierungspotentiale in Maschinen gleichen Typs identifizieren. Zudem können die gewonnenen Erkenntnisse für eine Verbesserung der Kundenservices genutzt werden, etwa durch die Optimierung des Maschinenbetriebs oder den Einbau besserer oder günstigerer Ersatz- und Bauteile.

3

Systemarchitektur der USU-Industrial-Big-Data-Lösung

Kategorien:
  Industrie, SAKE

Artikel teilen

[easy-social-share buttons="twitter,facebook,google,xing,linkedin,flipboard" counters=0 style="icon" url="http://www.smartdata-blog.de/2016/08/09/smart-data-technology-stack/" text="Smart Data Technology Stack"]
Über

 Henrik Oppermann

  (2 Artikel)

Hinterlassen Sie einen Kommentar

Die E-Mail Adresse wird nicht veröffentlicht.