Cloud Wars: Collection und Storage [Teil 2]

Typischerweise steht zu Beginn eines klassischen Analytics-Anwendungsfalles die Datenerfassung. Im Zuge der steigenden Bedeutung der Analyse bei Web-Anwendungen und mobilen Geräten, aber auch anderer Software-Anwendungen und Diensten, werden kontinuierlich große Mengen an Daten generiert. Im Gegensatz zu statischen Datensätzen, die periodisch im Batch verarbeitet werden, besteht in diesem Bereich oft die Anforderung, den Datenstrom kontinuierlich zu erfassen und zu analysieren. Im Folgenden möchten wir die Streaming-Dienste in die sogenannten Publish-Subscribe-Message-Systeme (oder Message Broker) und die eigentliche Stream-Verarbeitung unterteilen.

Ein Publish-Subscribe-Message-System ist für die Datenannahme zuständig. Je nach Anwendungsfall fallen teilweise Millionen von Ereignissen pro Sekunde an. Um diese zu erfassen wird ein hoch skalierbarer und hoch verfügbarer Dienst benötigt, der auch Lastspitzen abdeckt. Zudem müssen tausende Geräteverbindungen mit flexibler Autorisierung möglich sein. Die Daten sollen zuverlässig erfasst und mit geringer Latenz weitergegeben werden können. Um auch Daten von verschiedenen Geräten und Plattformen erfassen zu können, sind plattformübergreifende Client-Bibliotheken wünschenswert. Apache Kafka ist ein prominenter Vertreter aus dem Open-Source-Bereich.

Die Dienste zur Stream-Verarbeitung lesen aus den Publish-Subscribe-Systemen und verarbeiten und speichern die Daten in Echtzeit. StreamVerarbeitung kann für verschiedenste Use Cases wie Echtzeitanalyse, Online Machine Learning, Continuous Computing oder auch ETL-Szenarien eingesetzt werden. Die Systeme erlauben es, kontinuierlich Analysefunktionen auf den Datenstrom anzuwenden. Teilweise stehen dafür eine deklarative (häufig SQL-ähnliche) Sprache oder Lambda-Funktionen zur Verfügung. Aus der Open-Source-Welt sind hier Storm und Spark Streaming bekannt.

Um die Cloud-Systeme mit Daten zu versorgen, wurde ein kleines C#-Programm erstellt, das die Sensordaten der Wetterstationen verschickt und die entsprechenden Security-Mechanismen bedient.

Nachrichtenerfassung bei AWS (Message Broker)

Die einfachste Methode, den Datenstrom zu erfassen und in die AWS Cloud zu speichern, ist Kinesis Firehose. Die Nachrichten werden erfasst und auf einem S3 Bucket (einfache Dateiablage in einem Ordner) gespeichert. Auf Wunsch lassen sich die Daten auch in Redshift oder Elasticsearch Service laden. Kinesis Firehose skaliert automatisch und benötigt keinerlei Wartung. Die Konfigurationsmöglichkeiten sind dafür sehr überschaubar.

Stream-Verarbeitung

Bei etwas komplexeren Anwendungsfällen kommt alternativ AWS Kinesis Stream zum Einsatz. Bei Kinesis Stream lässt sich die Kinesis-Anwendung selbst programmieren und bietet so mehr Möglichkeiten als Firehose. Um Skalierung muss sich der/die Anwender:in selbst kümmern. Dabei dienen Shards als Basiseinheit für den Durchsatz: Ein Shard bietet eine Dateneingabekapazität von 1 MB/s und eine Datenausgabekapazität von 2 MB/s. Je nach Durchsatz können dem Stream Shards hinzugefügt oder entfernt werden.

Sollen die erfassten Daten in Echtzeit verarbeitet werden, empfiehlt sich der Einsatz von AWS Lambda. Mit AWS Lambda kann benutzerdefinierter Code in Java, Python oder Node.js ausgeführt werden, ohne dass dafür Server bereitgestellt werden müssen. Wird ein Kinesis Stream als Eventquelle definiert, so wird für jede einkommende Nachricht der benutzerdefinierte Code ausgeführt. Die Skalierung des Programmcodes erfolgt automatisch und die Bezahlung erfolgt gemäß der Ausführungszeit.

Einsatz im Use Case

Für unseren Anwendungsfall reicht ein Kinesis Firehose aus. Die Wetterdaten werden von den Stationen gemessen und mittels der PutRecords Methode, der Kinesis Producer Library, an Kinesis Firehose gesendet (Data Ingestion). Dort werden die Nachrichten (abhängig vom Buffer-Intervall) auf S3 geschrieben und in der Redshift-Tabelle persistiert.

Tipp: Über die Redshift Copy Options können Datenformat und Column-Mapping konfiguriert werden. So lassen sich verschiedene File-Strukturen wie csv, txv und Json einlesen.

Anmerkung: Kinesis ist ein unidirektionaler Dienst. Die Kommunikation erfolgt von vielen Event-Publishern hin zum Kinesis Stream. Ist eine beidseitige Kommunikation mit den Geräten/IoT Devices gewünscht, kann der AWS-IoT-Dienst verwendet werden.

Im folgenden Video zeigen wir das Anlegen und Konfigurieren eines Delivery Streams in AWS Kinesis Firehose mit dem Ziel Redshift Datenbank-Cluster über den Zwischenspeicher S3 Bucket.

Nachrichtenerfassung bei Azure

Bei Microsoft Azure sind die Dienste für Nachrichtenerfassung und Nachrichtenverarbeitung getrennt: Azure Event Hubs bieten einen skalierbaren Ereignisverarbeitungsdienst mit niedriger Latenz. Für IoT-Szenarien stehen Indentitäts- und Sperrlisten zur Verfügung.

Skaliert wird der Event Hub mit sogenannten Durchsatzeinheiten. Wie auch die AWS Kinesis Shards weißen die Durchsatzeinheiten eine Dateneingabekapazität von 1 MB/s und eine Datenausgabekapazität von 2 MB/s vor. Automatisches Skalieren ist jedoch schwieriger als bei AWS! Die Partitionszahl kann nicht verändert werden und die Anzahl der Durchsatzeinheiten sollte nicht größer als die Partitionszahl sein.

Stream Analytics wird den Event Hubs nachgeschaltet und dient der Echtzeitverarbeitung. Azure-Stream-Analytics-Instanzen können mehrere Eingaben hinzugefügt werden. Dabei sind neben Event Hubs auch IoT Hubs oder Blob-Eingaben möglich. Bei den Ausgaben ist eine ähnliche Vielfalt zu finden. Es können sowohl Blob als auch Data Lake Store, SQL und Power BI verwendet werden. Auch hier sind mehrere Ausgaben gleichzeitig möglich. Die Verarbeitung der Eingabe erfolgt mit einer SQL-ähnlichen Syntax, genannt Stream Analytics Query Language. Dabei handelt es sich um ein Subset von TSQL mit zusätzlichen Möglichkeiten. Dazu gehören beispielsweise Window-Funktionen, die es z.B. erlauben, einen gewissen Zeitrahmen zu berücksichtigen. Außerdem ist es möglich, vorangegangene Events in die Abfrage mit einzubeziehen. So können beispielsweise Differenzen zum letzten Wert berechnet werden.

Einsatz im Use Case

Die Wetterdaten werden im Json-Format an den Event Hub gesendet. Die Client Anwendung benötigt dazu den Access Key und den URI des Event Hubs. Der eingerichtete Stream-Analytics-Auftrag verwendet den Event Hub als Input und liest die Daten gemäß der SA-QL ein. Dabei können bereits Datenkonvertierungen und Aggregationen durchgeführt werden.

Das folgende Video zeigt das Anlegen eines Event Hubs für die Entgegennahme der Nachrichten, die Konfiguration der Sicherheitseinstellungen und das Hinterlegen dieser im C#-Programm für das Versenden der Daten. Für diesen Dienst kommt das im letzten Kapitel erwähnte „vollumfängliche Portal“, salopp bekannt als das „alte Portal“, zum Einsatz.

Im Folgenden wird Stream Analytics im „vollumfänglichen“ Azure-Portal für die In-Stream-Verarbeitung der Nachrichten gezeigt. Nach der Auswahl eines Datenstroms als Input und dem Event Hub werden Einstellungen wie das Eingabeformat u.ä. konfiguriert. Danach werden aus Ausgabespeicher sowohl Power BI als Direktkonsument ausgewählt als auch der Azure Data Lake Store. Diese Dienste stellen wir in den folgenden Kapiteln dieser Serie noch ausführlicher vor.

Wichtig sind noch unter „Abfrage“ die SA-QL Queries für Windowing und Zeitreisefunktionen, welche dann in die Ausgaben schreiben. Nach dem Starten des Stream Analytics Jobs erscheint ein neues sogenanntes „Push“-Datenset in Power BI. Die Daten können sofort visualisiert werden und aktualisieren sich in Echtzeit im Dashboard.

Nachrichtenerfassung bei GCP

Googles Messaging-Dienst heißt Pub/Sub. Die Publisher senden Nachrichten an ein Topic. Diese werden so lange in einem Message Store gespeichert, bis ein Subscriber diese ausliest.

Google Cloud Dataflow ist der Runner für den Nachfolger der Map-Reduce-Implementierung, das Dataflow-Programmiermodell. Mit Dataflow können sowohl Batch- als auch Stream-Datenverarbeitungen durchgeführt werden. Das Datenmodell abstrahiert viele Low-Level-Details. Google Cloud Dataflow skaliert automatisch und bietet auch Monitoring und Log-Auswertungen, um einen reibungslosen Betrieb zu gewährleisten.

Eine nahtlose Integration mit anderen Google Services wie Cloud Storage, Cloud Pub/Sub, Cloud Datastore, Cloud Bigtable und BigQuery, kombiniert mit dem flexiblen Programmiermodell, bietet weitreichende Möglichkeiten.

Dataflow weist einige Parallelen zu Spark auf, im Detail unterscheiden sich die zwei Lösungen jedoch. Das Programmiermodell ist Open Source und der Dataflow Code kann auch auf Apache Flink ausgeführt werden, was das Risiko eines Vendor Lock-in verringert.

Einsatz im Use Case

Die Wetterdaten werden an Pub/Sub gesendet, wo sie dann vom laufenden Dataflow Job (Streaming) abgeholt und die in den Nachrichten enthaltenen Informationen verarbeitet werden. Mittels Window- und Aggregatfunktionen können Informationen in geeigneter Struktur in Big Query geschrieben werden. Der Dataflow-Programmcode wurde in Java geschrieben und mit Maven deployed.

Tipp: Im Batch Mode könnte Dataflow durchaus wie ein Orchestrierungsdienst verwendet werden. Im Programm-Code können andere Dienste von Google aufgerufen und abgefragt werden. So ist es möglich, Daten aus verschiedensten Quellen zu lesen, zu verarbeiten und zu schreiben. Im Vergleich zu den Mitbewerbern fehlt allerdings die Funktion für Scheduling und Monitoring.

Unten zeigen wir die Google Cloud Console mit entsprechenden Statistiken und dem Absprung auf Pub/Sub. Die Themen stellen dabei eine mögliche Gliederung nach Projekten oder Anwendungsfällen dar. Da man hier viel näher an der Programmierung ist, folgt dann ein kurzer Überflug über das C#-Programm zur Ansprache von Pub/Sub und der Start der Applikation.

Auch im folgenden Video werden zunächst die wichtigsten Stellen im Programmcode überflogen, um dann zurück in der Google Cloud Console den Dataflow zu zeigen, in dem die Daten verarbeitet und nach Google Big Query geschrieben werden.

Zusammenfassende Bewertung der Streaming-Dienste

AWS Kinesis Firehose ist sehr simpel zu bedienen, bietet allerdings nur eingeschränkte Funktionalität. Möchte man die gleiche Funktionalität wie beispielsweise bei Stream Analytics, ist die recht aufwändige Programmierung eines eigenen Receivers notwendig. Durch die Kombination mit AWS Lambda wird das Deployen des Receivers allerdings ein wenig einfacher.

Azure Stream Analytics ist ebenfalls sehr simpel in der Bedienung. Durch die SQL-ähnliche Syntax können viele Operationen recht einfach auf den Stream angewendet werden. Der Dienst ist außerdem sehr gut integriert und hat alle gewünschten Ausgabemöglichkeiten.

Google Cloud Dataflow unterscheidet sich durch sein Programmiermodell von den Lösungen der Mitbewerber. Dataflow kann weit mehr als einfache Stream-Verarbeitung und ist wohl das am weitesten entwickelte System. Diese enorme Flexibilität und das Programmiermodell geht allerdings ein wenig zu Lasten der Bedienung. Der Einsatz von Java und Maven vereinfacht das Lifecycle Management, ist allerdings wohl nicht die erste Wahl für Datenanalysen.

AWS Kinesis	Azure Stream Analytics	Google Cloud Dataflow
Bedienung: ☆☆ Lifecycle Management: ☆ Möglichkeiten: ☆☆	Bedienung: ☆☆☆ Lifecycle Management: ☆ Möglichkeiten: ☆☆☆	Bedienung: ☆☆ Lifecycle Management: ☆☆+ Möglichkeiten: ☆☆☆

Weiterlesen

Im nächsten Artikel untersuchen wir, wie das Thema Datenverarbeitung mit den Technologien AWS Elastic Map Reduce & Data Pipeline, Azure Data Lake & Azure Data Factory sowie Google Data Proc und Google Dataflow umgesetzt wurde.

Bis dahin lohnt sich ein Blick auf unsere Website, wo wir unser komplettes Dienstleistungsportfolio rund um den Themenbereich Analytics vorstellen. Bei Fragen freuen uns auch über direkten Kontakt in den Kommentaren, per Mail an info@inovex.de oder telefonisch unter +49 721 619 021-0.

Die Blog-Serie im Überblick:

1. Einleitung, Vergleich des Look & Feel sowie Vorstellung von Use Case & Architekturen
2. Collection und Storage (dieser Artikel)
3. Computation
4. Analytical Data Stores
5. Data Presentation und Fazit

Join us!

Wir suchen Verstärkung für unser Analytics-Team! Egal ob Business Intelligence Entwickler (m/w/d) oder Werkstudent (m/w/d) im Bereich Data Management & Analytics oder Software Entwickler (m/w/d) mit Schwerpunkt Big-Data-Technologien: Wir freuen uns auf Bewerbungen!