CubeServ Blog
Bleiben Sie auf dem neuesten Stand, rund um das Data Driven Business mit Tools für Analytics von SAP & Co. und verpassen Sie keine Neuigkeiten, Downloads & Veranstaltungen.

Das Internet der Dinge, Big Data und eine Fischertechnik-Fabrik – Teil 3: Der Big Data-Cluster

In den ersten beiden Teilen dieses Blogs haben wir die Fischertechnik Fabriksimulation gezeigt. Diese Fabriksimulation soll nun kontinuierlich Daten erzeugen, die einerseits in einem Big Data-Cluster landen sollen, andererseits mit Mitteln des SAP BW oder mit SAP Analytics for Cloud reportbar sein sollen.

Als Big Data-Cluster wurde bei uns eine Cloudera-Installation aufgebaut. Ähnlich wie bei Linux, dem kostenlosen open-Source-Betriebssystem, das man in vorkonfigurierten und dann kostenpflichtigen Versionen erwerben kann (z.B. Suse Linux, RedHat,…), gibt es von Apache Hadoop ebenfalls vorkonfigurierte Installation wie z.B. von Hortonworks oder von Cloudera. Wir haben uns für Cloudera entschieden und haben eine 60-Tage-kostenlose Enterprise Edition installiert. Da es sich nur um eine Demoanwendung handelt, ist es auch ein einfacher Cluster mit nur einem Knoten geworden.

Hadoop kommt mit einer ganzen Reihe von Services daher, die dem Laien erstmal wenig sagen und in ihrer Anzahl und Bedeutung zunächst sehr verwirrend sind.

  • HBase ist die Datenbank des Systems.
  • HDFS ist das Hadoop Distributed File System, welches Daten redundant speichert und damit hohe Ausfallsicherheit garantiert.
  • Hive ist ein Service, der SQL-artige Abfragen gegen die Datenbank des Systems erlaubt.
  • Impala ermöglicht schnellere SQL-Abfragen als Hive durch bessere parallele Algorithmen. Impala dient vor allem dem schnellen Lesen und weniger anderen Vorgängen, wie Anlegen, Schreiben oder Ändern.
  • Hue ist ein Service, der eine SQL-Abfrage-Workbench und –Visualisierung bietet. Hier kann man z.B. SELECT-Statements ausprobieren (und dabei wählen, ob man über die Hive- oder die Impala-Engine abfragen möchte).
  • Kafka ermöglicht das Laden und Exportieren von Datenströmen.
  • Oozie ist der Service, mit dem Batch-Jobs eingeplant werden.
  • YARN ist die Ressourcen-Verwaltung, die auch die Zuteilung von Abfragen zu Servern steuert.
  • Flume ist ein Service, um Logs nach Hadoop zu streamen.

Die Fischertechnik Fabrik wird ja über die Siemens Logo Steuergeräte gesteuert. Die Steuergeräte bzw. ihre Programmieroberfläche bietet nun die Möglichkeit, die Zustände aller vorhandenen Eingänge und Ausgänge in periodischen Abständen (z.B. 1s) in ein Protokollfile wie z.B. Log.csv zu schreiben. Es immer alle Ein- und Ausgänge geschrieben, wir haben uns zunächst aber nur auf drei beschränkt, und zwar die Steuerungen für die Sortier-Rutschen, die weisse, rote und blaue Plastikzylinder voneinander trennen, abhängig von der erkannten Farbe in der Photozelle.

Damit wurde ein möglichst einfacher Bericht aufgebaut, nämlich ein einfacher Zähler, der gezählt hat, wie oft eine 1 vom Motor Q2 (weiss), Q3 (rot) oder Q4 (blau) gemeldet wurde. Dies entsprach dann der entsprechenden Anzahl an durchgelaufenen Plastikgütern.

Die Siemens-Steueroberfläche schreibt also permanent in ein lokales CSV-File auf dem Laptop, mit dem die kleine Anlage gesteuert wird. Dies ist also die Quelle unserer Sensordaten. Auf dem Cloudera-System wurde nun per Samba das Directory, in dem dieses Protokollfile geschrieben wird, gemountet. Damit war aus Sicht des Cloudera-Systems lokal ein CSV-File vorhanden. Gleichzeitig bestand keine Gefahr, dass eine kurzzeitige Unterbrechung der Verbindung zum Abbruch des Schreibvorgangs führt. Das Schreiben lief permanent weiter und sollte die Verbindung via Internet einmal unterbrochen sein, so würden die neuen Daten mit der nächsten Wiederverbindung wieder abholbar sein.

Dieses lokal sichtbare CSV-File, das LogFile.csv, wird nun mit Hilfe eine Flume-Agenten permanent auf ein Ziel in Kafka geschrieben. Die entsprechende Konfigurationsanweisung, die eine Quelle, ein Ziel (Senke) und einen Kanal definiert, lautet wie folgt:

#------------------------------------

tier1.sources = r1

tier1.sinks = k1

tier1.channels = c1

# Describe/configure the source

tier1.sources.r1.type = TAILDIR

tier1.sources.r1.filegroups = f1

tier1.sources.r1.filegroups.f1 = /samba/FischerTechnik/LOG/LogFile.csv

tier1.sources.r1.positionFile = /tmp/flume-position_3.json

# Describe the sink

tier1.sinks.k1.type = org.apache.flume.sink.kafka.KafkaSink

tier1.sinks.k1.topic = sensor_csv

tier1.sinks.k1.brokerList = quickstart.cloudera:9092

tier1.sinks.k1.batchSize = 1

# Use a channel which buffers events in memory

tier1.channels.c1.type = memory

tier1.channels.c1.capacity = 100000

tier1.channels.c1.transactionCapacity = 10000

# Bind the source and sink to the channel

tier1.sources.r1.channels = c1

tier1.sinks.k1.channel = c1

#------------------------------------

Für die Einrichtung dieser Konfiguration nochmal herzlichen Dank an die Experten unserer Partnerfirma für Hadoop-Systeme, die Ultra Tendency GmbH (www.ultratendency.com), und hier speziell an Matthias Baumann, der uns mit seiner Hadoop-Expertise schon einige Mal weitergeholfen hat.

Damit liegt nun im Cloudera im HDFS-Filesystem die Datei sensor_csv vor, die im Sekundentakt neue Daten erhält. Um dieses CSV-File für SQL-Abfragen verfügbar zu machen, wird in Hive folgendes Kommando abgesetzt:

CREATE EXTERNAL TABLE sapt90.zcssensorq (

key varchar(6),

time VARCHAR(8),

value VARCHAR(4),

sensor VARCHAR(20)

)

STORED BY "org.apache.hadoop.hive.hbase.HBaseStorageHandler"

WITH SERDEPROPERTIES (

"hbase.columns.mapping" =

":key,default:time,default:value,default:sensor"

)

TBLPROPERTIES("hbase.table.name" = "sensor_csv")

Dieses Kommando erzeugt eine leere Tabellenhülle zcssensorq (in einem Schema mit dem Namen sapt90) mit 4 Spalten (key, time, value, sensor) und teilt dem System mit, dass der Inhalt dieser Tabelle sich in einer hbase-Tabelle mit dem Namen sensor_csv befindet. Auf diese Weise können nun im Hue-Service einfache Hive- oder Impala-Abfragen gestartet werden, z.B. select * from zcssensorq;:

Die Sensordaten der Fischertechnik-Fabrik werden damit kontinuierlich geschrieben und liegen als File bzw. als Tabelle im Hadoop System verfügbar vor. Wie können diese Daten nun für ein Reporting verfügbar gemacht werden? Darum geht es im nächsten Teil dieses Blogs.

Newsletter abonnieren

Bleiben Sie auf dem neuesten Stand, rund um das Data Driven Business mit Tools für Analytics von SAP & Co. und verpassen Sie keine Neuigkeiten, Downloads & Veranstaltungen. 

Autor
Expert Team

Blog Artikel unserer Experten

graph

Advanced Analytics mit R: Eine Übersicht

In diesem Blog zeigen wir, wie einfach es ist, Advanced Analytics-Funktionen in R zu nutzen. Wir konzentrieren uns auf verschiedene Diagrammtypen, Regressionsanalysen mit R und Time Series Forcecasts mit R.

Die Zeitdimension in der SAP Data Warehouse Cloud

Mit der Data Warehouse Cloud Version 2020.14 hat SAP die Einbindung von Zeitdimensionen ermöglicht. Warum ist die Zeitdimension so wichtig? Zuvor waren in den zu ladenden Daten für die SAP Data Warehouse Cloud viele Aggregationsebenen einer Datumsspalte erforderlich, z.B. für eine separate Spalte «Quartal» oder

SAP Data Warehouse Cloud – Erfahrungen beim Aufbau eines Datenmodells

Sie verwenden Einkaufsdaten in Ihrem Reporting?  Profitieren Sie von unserem kostenlosen Template!Sie benötigen weitere Daten?  Profitieren Sie von unserer Erfahrung!SAP Data Warehouse Cloud ermöglicht zentrale Datenbestände leicht und intuitiv zu erweitern. Einführung in die SAP Data Warehouse Cloud (DWC) Die SAP Datawarehouse Cloud Lösung ist

Advanced Analytics

Wie Business Analytics erfolgreich gestalten?

Business Analytics einfacher ✅ und effektiver ✅ zu gestalten, ist herausfordernd. Ich stelle mit dieser Blog(serie) meine Lösungsansätze zur Diskussion. ✌

SQLscript Lösungsmuster

Lange danach gesucht? Jetzt gefunden! Unsere Übersicht von typischen Problemen und Lösungen im Bereich von HANA SQLscript.  Die Lösungsmuster reichen dabei von rein sprachlichen Problemen (z.B. „mit welchem Sprachelement ermittle ich den ersten Eintrag“) über formale Probleme (z.B. „wie wandle ich in SQLscript Zeitmerkmale um“)

Die SAP Data Warehouse Cloud – ein neuer grosser (?) Wurf (Teil 2)

Administration als aller Analysis Anfang In einem neuen leeren System sind zunächst immer einige administrative Schritte notwendig, zum Glück sind es in der SAP Data Warehouse Cloud nur einige wenige, die man unbedingt erledigen muss. Natürlicherweise beginnt es mit der Userverwaltung. Das Anlegen neuer User

Die SAP Data Warehouse Cloud – ein neuer grosser (?) Wurf (Teil 1)

Was ist die SAP Data Warehouse Cloud? Wer einen Blick auf die Zukunft von SAP Produkten werfen möchte, der besitzt mit der Agenda der SAP Teched (https://events.sap.com/teched/en/home) eine ganz brauchbare Glaskugel, zumindest für die nähere Zukunft. Auf dieser Agenda zeigt sich, dass SAP mit Nachdruck

Das Internet der Dinge, Big Data und eine Fischertechnik-Fabrik – Teil 6: Hadoop vom ABAP aus ansprechen: die GLUE-Middleware von Datavard

Im vorherigen Teil wurden Daten von Steuergeräten in ein CSV-File geschrieben, dies wurde per Kafka in Hadoop importiert und via Hive-Adapter bzw. Impala-Adpater in einer HANA-Datenbank gelesen. Diese Adapter stellen eine komfortable Möglichkeit dar, um auf die Hadoop-Daten lesend zuzugreifen. Diese Adapter ermöglichen allerdings nicht

Das Internet der Dinge, Big Data und eine Fischertechnik-Fabrik – Teil 5: Visualisierung mittels CalculationView und SAP Cloud for Analytics

In den vorherigen Teilen dieses Blogs wurde gezeigt, wie die Sensordaten der Fabriksimulation schliesslich als Tabelle (genauer: als Tabellenlink) in der SAP HANA verfügbar gemacht wurde. Der nächste Schritt wäre nun beispielsweise in der HANA einen gescripteten (oder alternativ auch graphischen) CalculationView anzulegen, der die