ZooKeeper ist ein zentraler Dienst zum Verwalten von Konfigurationsinformationen, Benennen, Bereitstellen verteilter Synchronisierung und Bereitstellen von Gruppendiensten. All diese Arten von Diensten werden in irgendeiner Form von verteilten Anwendungen verwendet. Jedes Mal, wenn sie implementiert werden, wird eine Menge Arbeit in die Behebung der unvermeidlichen Fehler und RaceConditions gesteckt. Es gestaltet sich schwierig diese Art von Diensten zu implementieren. Werden Fehler anfangs von Anwendungen übersehen, ist es schwierig, diese im nachhinein zu identifizieren und zu beheben. Unterschiedliche Implementierungen dieser Dienste führen auch bei korrekter Ausführung zu einer komplexen Verwaltung, wenn die Anwendungen bereitgestellt werden.

Grundlagen

Apache Kafka ist eine Anwendung, die große Datenströme verarbeiten und fehlertolerant verwalten kann. Zudem merkt sich Kafka den zuletzt gelesenen Datenblock, auf den von externen Programmen zugegriffen wird. Dadurch kann bei Fehlern beim zuletzt vollständig gelesenen Datum weitergearbeitet werden und es gehen keine wichtigen Informationen verloren. Es gibt sowohl Programmierschnittstellen zum Auslesen als auch zum Einspeisen von Daten in Kafka. [1]

Einsatz im Projekt

Quellen:

Transformation der Datenstruktur und Dateninhalte in das Format und Schema der Zieldatenbank. Hier werden die Ausgangsdaten an das gewünschte/geforderte Schema der Zieldatenbank angepasst. Traditionell erfolgt der Transformationsvorgang in den vier Schritten Filterung, Harmonisierung, Aggregation und Anreicherung. In den ersten beiden Schritten werden die Daten bereinigt und aufbereitet. Die letzten beiden Schritte fassen die Daten themenspezifisch zusammen. Die Transformation ist der entscheidende Schritt, bei dem in den Daten ein Mehrwert geschaffen wird, um aussagekräftig zu sein.

Um den Datenbestand des DWH visualisieren, eignet sich Software wie Apache Superset. Das ist in unserem System optional, bietet aber dennoch eine gute Möglichkeit, um sich einen Überblick über den Datenbestand zu machen und Statistiken und Grafiken für alle begreiflich in einem Dashboard anzuzeigen. Zudem bietet Superset einen guten Support für unser DWH Druid an. [1]

Quellen:

MongoDB ist eine universelle, dokumentbasierte, verteilte Datenbank für die moderne Anwendungsentwicklung und die Cloud, die in puncto Produktivität höchsten Ansprüchen gerecht wird.

MongoDB ist eine Dokumentdatenbank, die Daten in einem JSON-ähnlichen Dokumentformat speichert. Dies macht die Daten aussagekräftiger und leistungsfähiger als das herkömmliche Zeilen/Spalten-Modell macht.

MongoDB ist eine echte Datenplattform mit einer umfassenden Toolsuite, die jedem die Arbeit mit Daten erleichtert – von Entwicklern über Analysten bis hin zu Data Scientists.

Allgemein

Die von der Maschine produzierten Daten werden auf verschiedene Art und Weise vom permanent verbundenen PC verarbeitet und abgespeichert. Die für unsere Zwecke wichtigen Softwarekomponenten sind die Datenbank MongoDB und der Message Broker Apache ActiveMQ.

Daily Batch

Alle neuen Daten, welche im Lauf eines Tages anfallen, d.h. auf den Stapel (engl. batch) gelegt werden, werden über Nacht mittels eines selbst geschriebenen Programms auf den Projektserver übertragen. Dieser verfügt wiederum auch über eine MongoDB. Somit steht zu jedem Zeitpunkt ein maximal ein Tag alter Datenbestand für Datentransformationen und -auswertungen auf dem Server bereit.

Realtime

Zusätzlich zum Daily Batch werden auch Live-Daten vom Maschinen-PC auf den Projektserver übertragen. Dafür wird auf ActiveMQ zurückgegriffen. Sobald neue Daten veröffentlicht werden (engl. publish), werden Softwarekomponenten, die diese Änderungen abonniert haben (engl. subscribe), umgehend informiert. Daher spricht man hier von einem publish-subscribe-, oder kurz pub-sub-Modell. Diese Begebenheit macht sich wiederum ein selbst geschriebenes Programm zu Nutze, welches auf Änderungen der Sensorwerte hört. Diese werden dann sofort auf den Kafka Broker des Projektservers übertragen.

In diesem Projekt wurden drei Ansätze für das Trainieren untersucht.

Supervised Learning

Bei Supervised Learning besteht das Hauptaugenmerk darauf, dass beim Training Labels und Features vorgegeben werden. Als Features werden dabei die einzelnen Datensätze bezeichnet. Als Labels werden die manuell bewerteten Datensätze bezeichnet, sie tragen in unserem Anwendungsfall die Bezeichnung i.O. oder n.i.O..

Unsupervised Learning

Bei Unsupervised Learning werden nur Features vorgegeben. Der Algorithmus selbst klassifiziert und erstellt die Labels selbst.

Reinforcement Learning

Bei Reinforced Learning wird das Ziel vorgegeben. Der Algorithmus versucht dabei den Zielwert selbst zu maximieren bzw. die Zeit zur Zielerreichung zu minimieren. Für diese Vorgehen sind mehrere Durchläufe nötig, die wiederum in den Lernprozess miteinfließen. In diesem Projekt wurde Supervised Learning verwendet, da sowohl die Eingangsparameter (Features) alsauch die Ausgabewerte (Labels) vorliegen. Zudem sind die Labels ausschließlich binär klassifiziert. Die Features sind in diesem Anwendungsfall die Leistung der Spindel repektiver Achsvorschub sowie deren Geschwindigkeiten.

Vorgehen

Der Trainingsdatensatz besteht aus ca 1500 Datenpaaren. Dabei entspricht ein Datensatz einer Bohrung, für die anschließend die Messwerte mit drei verschiedenen Messmethoden ermittelt wurden.

Auf Diesem Datensatz wurden dann verschiedene Trainigsalgorithmen angewandt. Als Ergebnis daraus entsteht ein Model (mathematische Funktion), deren Parameter abhängig von den Eingabeparametern beeinflusst werden. Diese Formel wird als trainiertes Modell bezeichnet.

Üblicherweise wird der Trainingsdatensatz in zwei Gruppen gespalten. Die tatsächlichen Trainingsdaten und die Testdaten. Die Testdaten dienen zur Überprüfung des trainierten Modells. Damit kann eine ungefähre Genauigkeit des Modells ermittelt werden.

Nachdem das Modell trainiert ist, können für die Datensätze automatisch die Labels vorhergesagt werden. Die Vorhersage geschieht dann mit dem trainierten Modell anhand von Features. Da ein Computer ausschließlich Zahlenwerte als Eingabe akzeptiert, werden grundsätzlich, unabhängig vom Algorithmus, in Zahlen umgewandelt. Diese Werte werden dann in das Modell gespeist. Je nach Algorithmus sind die Ausgabewerte sehr unterschiedlich. Der Algorithmus muss zum Problem passen

Bei der Klassifizierung gibt es in unserem Fall zwei Zustände.

- i.O.
- n.i.O.

Üblicherweise wird als Ergebnis ein Wert zwischen 0 und 1 geliefert. Dabei muss der Schwellwert definiert werden. In unserem Projekt ist i.O. mit 1 gleichzusetzen, n.i.O. mit 0. Bei einem Ergebnis <0,5 wird abgerundet. Das Werkstück ist voraussichtlich in Ordnung. Diese Erkstücke sollten anschließend überprüft werden. Alle Teile, die vom Modell mit i.O. gekenzzeichnet wurden, können bedenkenlos übernommen werden.

Für das Projekt wurden mehrere Algorithmen untersucht. Die Algorithmen haben je nach Einsatzzweck ihre Vor- und Nachteile.

In nachfolgender Tabelle sind alle untersuchten Algorithmen aufgelistet.