Realtime Analytics So funktioniert Datenauswertung in Echtzeit

Prozesse, Endgeräte, Sensoren und Maschinen liefern laufend Logfiles, Sensor- und Betriebsdaten, Transaktionsdaten, die sich korrelieren und auswerten lassen – in Echtzeit. Doch „Echtzeit“ muss nicht unbedingt „ohne Verzug“ bedeuten, sondern lediglich in ausreichender Schnelligkeit für den jeweiligen IT-Benutzer, also vielmehr „rechtzeitig“. Daher befasst sich Realtime Analytics nicht nur mit Streaming-Daten, sondern auch mit viel „langsameren“ Datenlieferungen.

Anbieter zum Thema

INFOMOTION GmbH

QUNIS GmbH

Fivetran Germany GmbH

Pentaho

Amazon Web Services Germany GmbH

mehr weniger

Google Germany GmbH

IBM Business Consulting Services

SAS Institute GmbH

Microsoft Deutschland GmbH

weniger

Schnelle Datenlieferungen in möglichst kurzer Zeit werden bei vielen Unternehmen immer begehrter, sei es in Social Media, an der Börse, in IoT oder in der Datensicherheit. Wenn dabei von „Echtzeit“ bzw. „Realtime“ die Rede ist, so wird etwas verwechselt: „Echtzeit“ bedeutet in der Informationstechnik nicht „sofort“, sondern „ausreichend schnell“, also rechtzeitig. Für jedes System gilt daher eine andere Echtzeit. Das eröffnet eine breite Vielfalt von Anwendungsmöglichkeiten.

Bildergalerie

Bildergalerie mit 6 Bildern

„In vielen klassischen Data-Warehouse-Szenarien werden auch in 2017 die Daten immer noch im Wochenrhythmus geladen“, weiß Dominik Claßen zu berichten, Director of Sales Engineering EMEA & APAC bei Hitachi Vantara. „Für diese Anwender fühlt sich die Umstellung auf tägliche Einspeisung nicht selten bereits wie Echtzeit an.“ Mit Fast-Echtzeit, also mit Latenzen von zehn bis 15 Sekunden, könnten demnach auch bereits viele Analyse-Szenarien abgedeckt werden. „Tatsächliche Echtzeit-Anwendungsfälle, in denen die Daten jede Sekunde aktualisiert werden“, seien indes spezialisierten Analyse-Tools vorbehalten. In erster Linie kommen dafür Streaming-Engines infrage, insbesondere dann, wenn IoT- und Maschinendaten zu verarbeiten sind.

Anwender

Bei Realtime Analytics geht es dennoch in vielen Fällen um sehr große Datenmengen, die in kürzester Zeit aktualisiert werden müssen. Pentahos Datenintegrations-Tool PDI (Pentaho Data Integration) wird zum Beispiel eingesetzt, um XML/JSON-Streams abzugreifen, die Apache Kafka liefert, und die Daten mit Apache Spark abzufragen und weiterzuverarbeiten.

Ein interessanter Anwendungsfall ist in diesem Bereich die finnische Lotterie Veikkaus. Das staatliche Unternehmen für Wetten und Lotterien nutzt unter anderem Pentaho PDI, um täglich mehr als zwei Millionen Kafka-XML/JSON-Messages aus dem Lotterie-System zu laden. Dabei werden mehr als 200 Messages pro Sekunde von PDI verarbeitet und via Cloudera Flume in Hadoop sowie HPE Vertica gespeichert.

Die Datenströme werden in Near Realtime (zehn bis 15 Sekunden) ins Frontend der Anwendung geladen, was es dem Marketing Team ermöglicht, den rund eine Million registrierten Nutzern beispielsweise Erinnerungen oder personalisierte Angebote zwei Tage vor der Lotterie zu senden und sie zur Teilnahme aufzufordern. Die hundertprozentige Korrektheit der Daten, die das Pentaho-System nun gewährleistet, ermöglicht nicht nur genaue Finanzanalysen – die Erlöse kommen Bildung, Sport und Kultur zugute – sondern auch vollständige Compliance.

Einsatzszenarien

Es gibt für die Verarbeitung von unstrukturierten und semistrukturierten Daten wie etwa Logfiles und Datenströmen zahlreiche Einsatzfelder, darunter Kapazitätsplanung für Applikationen und Netzwerke, Datensicherheit, Betrugserkennung, Kundenservice, Gesundheit, Smart Grid und IoT, um nur ein paar zu nennen. Je verbreiteter IoT-Anwendungen werden, desto mehr sind auch Versorger betroffen, so etwa Stromerzeuger, die ein Netz von intelligenten Stromzählern verwalten.

Immer mehr Unternehmen werden also Realtime-Analytics nicht nur als reizvolle Option betrachten, sondern zunehmend als einen kritischen Erfolgsfaktor. Ein Börsenmakler, der die neuesten Aktienkurszahlen im Mikrosekundentakt in sein IT-System bekommt, steht vor der Frage, wo und vor allem wann er am gewinnbringendsten investiert. Die Analyse-Software muss ihm die Antwort geben, mithilfe von Predictive oder sogar Prescriptive Analytics.

Streaming-Technologien

Der große Unterschied zu Business Intelligence Tools und Big Data Analytics sind die oft enormen Datenmengen und ihre hohe Aktualisierungsgeschwindigkeit aus unterschiedlichsten Datenquellen. Was für den Endanwender zählt, ist die möglichst zeitnahe, aber „rechtzeitige“ Bereitstellung der Analyse-Resultate. Das bedingt einen grundlegenden Unterschied in der IT-Architektur.

Eine hoch entwickelte Form der traditionellen Entscheidungsunterstützung ist Complex Event Processing (CEP). Diese erprobte Disziplin basiert auf Boole'scher Logik und strukturierten Datentypen. Daher kann sie nur eine begrenzte Anzahl von Geschäftsereignissen pro Sekunde verarbeiten. Big Data besteht jedoch zu über 90 Prozent aus unstrukturierten Daten, wie sie etwa Mobilgeräte und Soziale Netzwerke erzeugen. CEP 2.0 müsste also folgende Bedingungen erfüllen:

• Parallele Datenströme verarbeiten,

• Daten In-Memory analysieren, um für Hochgeschwindigkeitsanwendungen (Börse, Betrugserkennung, Datensicherheit) geeignet zu sein,

• Linear je nach Speicheranforderungen skalieren,

• die Datenverarbeitung näher zu den Datenquellen platzieren und

• mehrere parallele Prozesse aufgrund eines einzigen Auslösers (Ereignis) oder einer Nachricht anstoßen und im System verarbeiten.

Während Big Data Analytics durchaus mit relativ langsamen Systemen wie Hadoop oder auch Spark zufrieden sein könnte, sind Realtime-Systeme, die etwa auf Streaming basieren, dazu gezwungen, diesen Schritt zu umgehen: Hadoop? Das ist etwas für historische Analysen.

Wenn ein Unternehmen etwa aufgrund seiner Data-Lake-Architektur noch langsame MapReduce-ähnliche Stapelverarbeitungsprozesse in Hadoop nutzen muss, kann es dennoch gleichzeitig Apache Storm für das Verarbeiten von Datenströmen heranziehen – gleichzeitig oder parallel.

So unterstützt etwa die neueste Version der Speicher-Engine ColumnStore der SQL-Datenbank MariaDB die massiv-parallele Verarbeitung sowohl historischer Daten als auch von Datenströmen, sogenanntes Streaming, in einer einzigen Systemarchitektur. Das erhöht die Leistung für die Bereitstellung und Verarbeitung von Daten aller Art erheblich und ermöglicht innovative Geschäftsmodelle, besonders im IoT-Markt.

Open Source Tools

Wie schon Namen wie Hadoop, Spark und Storm signalisieren, existiert bereits eine enorme Vielfalt von Tools für die Verarbeitung von Datenströmen in Formaten wie XML/JSON oder MQTT, aber auch Publish/Subscribe-Verfahren sind häufig. Apache Spark etwa bietet seit dem Start auch Streaming-Fähigkeiten an, während Apache Storm anders arbeitet, sich aber gut mit Apache Kafka oder Apache Flink kombinieren lässt.

Jedes Tool hat seine Stärken und Beschränkungen, doch unterm Strich zählt die Leistung bei der Datenlieferung und den Analyseresultaten. Die Storm-Kuratoren nennen eine Leistung des Tools bei mittlerweile eine Million Tupeln pro Sekunde pro Node (der Einsatz erfolgt üblicherweise nur auf Clustern). Mit „Tupeln“ sind simple Datenlisten gemeint, die sich rasch verwerten und transformieren lassen, etwa für die SQL-Abfrage. Wie sich die Performance und Einsatzvielfalt steigern lässt, sollen die folgenden Beispiele aufzeigen.

Streaming-Services

Auch aus der Public Cloud können System- und App-Entwickler entsprechende Services beziehen. Mit AWS Kinesis lassen sich IoT-Telemetriedaten, Anwendungsprotokolle oder Website-Clickstreams in Echtzeit erfassen, verarbeiten und auswerten, etwa in einem Data Warehouse oder Data Lake. Der Service besteht aus den Bausteinen Firehose (Transport), Streams (Entwicklung) und Analytics.

Google Cloud Dataflow arbeitet wie Spark mit einer Architektur, die sowohl Stapelverarbeitung als auch Streaming unterstützt. Durch die Integration mit anderen Google-Service wie BigTable, Datastore, BigQuery eignet sich Dataflow für Massendaten. Mithilfe der Apache Beam SDKs, die für Java und Python bereitstehen, sowie mit APIs zu Drittanbietern kann ein Entwickler diejenigen Erweiterungen erstellen, die er für seinen jeweiligen Zweck benötigt.

Microsoft Azure Stream Analytics offeriert einen ähnlichen Leistungsumfang wie Google und AWS, setzt aber ganz auf seine eigene Cloud-Infrastruktur. Das Event Hub soll Millionen von Ereignissen in kürzester Zeit verarbeiten können. Das Protokoll dafür ist das neue Advanced Message Queuing Protocol (AMQP). Interessant ist auch die Unterstützung für Apache Nifi zwecks Automation des Datenflusses und des beliebten, ebenfalls quelloffenen Elastic- bzw. ELK-Stack aus ElasticSearch, Kibana und Logstash.

Die Abfragen erfolgen auf Azure wie beim Wettbewerb mit SQL, doch die Konnektoren werden bereits frei Haus bereitgestellt. Mit Machine-Learning-Algorithmen lassen sich Predictive-Scoring-Schritte auf Streaming-Daten realisieren. Microsoft hat klar erkannt, dass künftig die größten Datenmengen aus dem Internet der Dinge kommen werden. Daher ist Stream Analytics bereits mit dem Azure IoT Hub und IoT Analytics integriert, und alle Resultate lassen sich mit Dashboards überwachen, die man mit Microsoft PowerBI erstellt. Der gesamte Service ist bereits in Deutschland nutzbar.

Kaufen statt bauen – alles aus einer Hand

Für den Interessenten stellt sich die Frage, ob er genügend Zeit, Geld und Know-how besitzt, um alle diese Bausteine fachgerecht, ausgetestet und rechtzeitig zusammenzustellen – oder ob er nicht gleich zu einem zwar proprietären, aber dafür einheitlichen und ausgereiften Produkt greift. Als zwei Vertreter dieser Gattung seien exemplarisch IBM InfoSphere Streams und SAS Event Stream Processing (ESP) vorgestellt.

SAS ESP ist eine einbettbare Ereignisverarbeitungs-Engine, die sich, ähnlich einem Motor in einem Fahrzeug, in geeignete Applikationen einbauen und programmieren lässt. Dennoch verfügt sie über eine visuelle Benutzeroberfläche, über die sich ihre Eigenschaften konfigurieren lassen. Dazu gehören etwa die zahlreichen Datenquellen von strukturierten und unstrukturierten Daten, zu denen SAS Adapter und Konnektoren bereitstellt. Zu den Quellsystemen gehören u. a. Hadoop, HDFS und YARN, relationale Datenbanken, XML/JSON-Quellen, Message-Queueing-Tools (RabbitMQ), ODBC-Quellen und Publish/Subscribe-Quellen.

Entscheidend für den Mehrwert einer solchen Engine ist indes die Leistungsfähigkeit und vielfältige Nutzbarkeit dieses Datenmotors. Laut SAS sammelt ESP Millionen von Events pro Sekunde aus operativen Transaktionen, Sensoren, Endgeräten, Maschinen, Übertragungen usw. Die Übertragung und Verarbeitung erfolgt parallelisiert und in Process-Threads in einem In-Memory-Grid in Millisekunden oder schneller, sodass die Latenz minimal ist. Das Grid hat den Vorteil, linear skalierbar zu sein. Werden die Datenmengen zu groß, tritt ein Cache in Aktion, um sie zwischenzuspeichern. Die Endspeicherung erfolgt, sofern nötig, in indizierten In-Memory-Stores.

Noch während sich die Daten im Fluss befinden, werden sie mit Operatoren, Funktionen, Routinen und Advanced Analytics (Modellen usw.) normalisiert, bearbeitet, transformiert (Update, Delete und Insert) und verwertet. Denn schließlich interessiert den Nutzer nur das Besondere und das Ergebnis. Die Datenqualität wird bereits während des Streamings gesichert, ESP wendet vorab konfigurierte analytische Ausdrücke und Musterabgleichsalgorithmen auf die Daten an. Diese Musterabgleichsfunktionen erlauben es, sequenzielle oder temporale Ereignisse (etwa in Zeitreihen) zu definieren und Anomalien durch KPIs frühzeitig zu erkennen. Visualisierung, Warnung und Benachrichtigung gehören zur Grundausstattung der Konsole, um so Entscheidungen und Aktionen anzustoßen bzw. auszulösen, etwa im Fall einer sich anbahnenden Krise oder Katastrophe.

IBM Streams

IBM Streams verfährt auf technischer Ebene ähnlich wie SAS ESP, etwa um Datenmengen zu verkleinern, zu bereinigen, weiterzuleiten, zu indizieren und schließlich, falls unbedingt nötig, für spätere historische Analysen zu speichern. Ein Compiler konvertiert Streaming-Anwendungen, die in SPL-Code oder für eine Java-API geschrieben wurden, in Maschinensprache. Dieses Tools stellt auch fest, ob Operatoren einen Status haben (stateless, stateful) und kann aufgrund dieser Informationen festlegen, ob die Ausführung auf Mehrkernprozessoren multi-threaded erfolgen soll. Indem der Compiler Leistungsdaten aus vorherigen Ausführungen berücksichtigt, kann er entscheiden, welche Operatoren er in den Ablauf der Prozesse einfügen soll, um eine optimale Leistung zu erzielen.

Das führt zu der erfreulichen Konsequenz, dass mit der Inbetriebnahme weiterer Cores und Nodes die Performance hinsichtlich Parallelverarbeitung und Datendurchsatz steigt. In einem Vergleich mit Apache Storm übertrifft der IBM-Streams-Durchsatz den von Apache Storm um den Faktor 2,6 bis 12,3, während die Anwendung gleichzeitig 5,5 bis 14,2 Mal weniger CPU-Zyklen benötigt. Die Unterschiede hinsichtlich der Leistung können also je nach verwendetem System erheblich ausfallen.

Das IBM-Tool stellt lokal, in der Cloud oder in Hybrid-Modellen zahlreiche Konnektoren zur Verfügung, was dem Nutzer eine große Bandbreite an Möglichkeiten bietet. Die wirkliche Flexibilität beim betrieblichen Einsatz erlaubt indes die Fähigkeit des Systems, während des laufenden Betriebs weitere Input- oder Output-Streams sowie Nodes hinzuzufügen oder zu entfernen, ohne das System neu starten zu müssen. Laufende Streams lassen sich zudem in andere laufende Streaming-Jobs im- oder exportieren, sodass sich Daten und Situationen auf alternative Weisen analysieren lassen. Das könnte sich beispielsweise bei der Betrugserkennung oder der Aufdeckung eines Cyberangriffs als nützlich erweisen.

Mit Streams Studio steht eine integrierte Entwicklungsumgebung zur Verfügung, die es Entwicklern erlaubt, vorhandene Routinen in Java oder C++ in einer visuellen Umgebung in die Analyseprozesse zu integrieren. Beim Data Mining können Nutzer bestehende Scoring-Modelle auf die Streaming-Daten anwenden, statt auf historische Daten warten zu müssen. Die Streams-Applikation aktualisiert ihr Modell dann selbsttätig, um einer veränderten Situation gerecht zu werden. Geschäftliche Nutzer können MS Excel zu Hilfe nehmen, um ihre vertraute Tabellenkalkulation als Analyseumgebung zu nutzen.

Streams weist mit dem Scheduler und dem Job Manager zwei Optimierwerkzeuge auf, die der BI-Nutzer aus Data-Warehouse-Umgebungen kennt. Sie sorgen dafür, dass große Datenmengen keine Überlastung herbeiführen und dass Anwendungen mit geänderten Spezifikationen optimal weiterlaufen.

Webserver auf einer Internetseite werden außerhalb Streams ausgeführt und dienen etwa dazu, Datenströme in Echtzeit über eine TCP/IP-Verbindung zu visualisieren. Das kann eine Verkehrslage sein oder eine Wettersituation, aber auch die Anzeige von Anomalien wie etwa einem versuchten Kreditkartenbetrug oder einem drohenden Zusammenbruch des nationalen Stromnetzes. Man sieht: Echtzeit-Analysen von Datenströmen gewinnen täglich an Bedeutung.

(ID:44814769)