Im Zug der fortschreitenden Digitalisierung werden Echtzeitsysteme immer wichtiger. In einer siebenteiligen Blogserie beleuchten wir diese aus unterschiedlichen Perspektiven:
- Teil 1: Sensoren
- Teil 2: Netzwerk-Kommunikation
- Teil 3: Unternehmensdaten
- Teil 4: Externe Daten
- Teil 5: Datenhaltung und -management
- Teil 6: Datenanalysen
- Teil 7: Informationssicherheit und Datenschutz (ISDS)
Sie lesen aktuell Teil 6 zu Datenanalysen.
Hat man die für das Echtzeitsystem relevanten Daten gemessen und übermittelt und mit den notwendigen Unternehmensdaten und externen Daten zusammengestellt, geht es nun darum, aus diesen Daten Informationen zu generieren und darauf abgestützt Entscheide oder Aktionen auszulösen. Doch was für Tools existieren, um aus dem Daten-Rohstoff maximalen Nutzen zu ziehen? Und worauf muss bei der Analyse geachtet werden?
Echtzeitdaten – … really?
Bei der Datenanalyse von (Echtzeit)Daten sollten wir zuerst deren zeitliche Charakteristik genau erfassen: Geht es um Echtzeitdaten im engen Sinn, erlaubt deren Prozessierung und Analyse (gemessen ab Aufzeichnungszeitpunkt) nicht mal Verzögerungen von wenigen Sekunden. Ein Beispiel hierfür ist der Blitzkasten auf der Autobahn. Er muss in der Lage sein, auch bei einem dichten Verkehrsstrom Radar- oder Lasermessungen durchzuführen für Fahrzeuge, die sich – sofern sie sich an die Geschwindigkeitssignalisation halten – mit rund 33 Metern pro Sekunde bewegen, aus den Sensordaten die Geschwindigkeit zu berechnen und mit dem erlaubten Maximalwert abzugleichen. In der kurzen Zeit, in welcher ein fehlbares Fahrzeug im Sichtbereich der Kamera ist, muss schliesslich ein Bild aufgenommen werden.
Häufig werden noch Nahechtzeitdaten (near-realtime data) und Batch-Daten (oder einfach: Daten) als eigene Typen genannt. Gegenüber Echtzeitdaten ist die Verarbeitung von Nahechtzeitdaten in der Regel etwas weniger zeitkritisch und bei Batch-Daten unkritisch. Verschiedene Fachdisziplinen definieren «zulässige» Datenanalyse-Verzögerungen für Nahechtzeitdaten von einigen Millisekunden bis Minuten – die Trennung zu Echtzeitdaten ist unscharf. Bei den Batch-Daten ist die Trennung klarer: Hier ist der Aufnahmezeitpunkt zeitlich komplett abgekoppelt vom Verarbeitungszeitpunkt und die Prozessierungsdauer spielt eine untergeordnete Rolle. Ein Beispiel wäre die jährlich aktualisierte Statistik der Bevölkerung und der Haushalte (STATPOP) des BFS. Auf diesem Datensatz basierende Analysen haben keine hohe zeitliche Dringlichkeit und müssen auch nicht minütlich aktualisiert werden.
Real-time matters
Eine Datenanalyse von Echtzeitdaten muss also in der Lage sein, Daten ab Eingangszeitpunkt (beinahe) verzögerungsfrei zu analysieren und die Erkenntnisse an Entscheidungsträgerinnen und Entscheidungsträger oder an ein nachgelagertes System zu übergeben. Damit ist als wichtigste Anforderung eine durchgehende Automatisierung der Analyse gegeben. Manuelle Eingriffe würden grosse Verzögerungen verursachen und sind schlecht skalierbar.
Skalierbarkeit ist auch gleich das Stichwort für eine weitere Anforderung an die Datenanalyse. Je nach datengenerierendem Prozess kann das Volumen von Echtzeitdaten kurzfristig und stark schwanken. Nehmen wir das Beispiel der Suchmaschine von Google. Aus Nutzersicht dient diese der Interpretation und Beantwortung der Suchanfrage quasi in Echtzeit.
Am 14. September 2020 wurde in schweizerischen Medien die Nachricht publiziert, dass ein Naturheilmittel gegen COVID-19 helfen soll. Umgehend schnellten die Suchanfragen zu diesem Thema von einem Indexwert von gegen 0 auf 100 hoch und ebbten danach rasch wieder ab. Im Beispiel kann also die Last für das System, abhängig von äusseren Umständen, stark und schnell wechseln. Ein skalierbares System zur Datenanalyse kann solche Peaks auffangen, ohne eine Warteschlange (Queue) bilden zu müssen, die zu deutlich zeitverzögerter Datenverarbeitung führen würde – was bei Echtzeitsystemen ein «No go» wäre..
Ein automatisiertes, skalierbares System zur Datenanalyse kann letztlich nur dann seine Aufgabe erfüllen, wenn es jeweils zu den benötigten Zeiten zuverlässig verfügbar ist. Fällt es längere Zeit aus, leidet unmittelbar die Aktualität der daraus gewonnen Informationen. In Anwendungsfällen wie dem Hochfrequenzhandel an der Börse («Micro-Trading») fehlt dadurch die Entscheidungsgrundlage für die nötigen automatisierten Börsentransaktionen. Steht das System hier still, führt dies somit direkt zu monetären Verlusten.
Architektur-Blueprint für die Echtzeit-Datenanalyse
Natürlich bestimmt der jeweilige Anwendungsfall, wie eine Analyseplattform aufgebaut sein soll. Da aber viele davon einer grundlegenden, gemeinsamen Architektur folgen, wollen wir uns im Folgenden einen solchen Architektur-Blueprint anschauen. Die Grafik stammt zwar von Azure, die dort genannten Technologien sind aber austauschbar.
Der Rohstoff der Analyseplattform sind natürlich die Daten, die über Data Sources (wie IoT-Sensoren, SCM-Systeme oder Smartphone Apps) generiert werden. Häufig werden diese in ihrer Rohform in einem Data Storage (beispielsweise einem Blob-Storage oder eine NoSQL-Datenbank) abgelegt oder archiviert. Parallel dazu werden sie über einen Ingestion Block als Messages in die Queue einer Datenstrom-Pipeline geschickt (ein prominenter Vertreter neben Kafka (siehe Teil 5 unserer Serie) wäre IBM MQ). Über diese Pipeline gelangen die Daten zum Stream Processing, über welches die Echtzeit-Daten beinahe verzögerungsfrei transformiert und analysiert werden können (hierfür sieht Azure unter anderem HDInsight und Databricks vor).
Der anschliessende Analytical Data Store beschreibt einen für Echtzeit-Datenströme geeigneten Speicher mit erweiterten Analysefähigkeiten («Data Warehouse», wie das Open Source-Framework Apache Hive). In der Regel sind die darin enthaltenen Daten durch das Stream Processing bereits umgeformt oder ausgedünnt und und weichen daher von ihrer Rohform im Data Storage ab. Zudem werden an den Analytical Data Storage höhere Anforderungen bezüglich Analysefähigkeiten und Performanz gestellt, als an den Data Storage.
Auf dieses Data Warehouse greifen dann Analytics and Reporting Tools zu, wie beispielsweise Tableau oder PowerBI. Monitoring Tools, die sich eher auf die Metadaten als auf die eigentlichen Daten konzentrieren, greifen direkt auf Stream Processing zu – ein Umweg via das Data Warehouse ist nicht erforderlich. Typischerweise betrifft dies Dashboards für das Monitoring der Performanz und Stabilität der Analyse-Plattform, wie sie Instana oder Grafana liefern können.
Datenanalysen in der Azure Cloud
Ein ausfallsicheres Real-Time Big Data Analytics-System (um mal alle Schlagworte in den Ring zu werfen) mit eigener Infrastruktur aufzubauen, ist enorm schwierig und kostspielig. Ist der Betrieb eines solchen Systems nicht die Kernaufgabe eines Unternehmens, bietet sich eher die Nutzung bereits existierender Cloud-Plattformen wie Microsoft Azure oder Amazon Web Services an. In den folgenden Ausführungen werde ich mich auf Azure konzentrieren.
Tatsächlich gibt es bei Azure zahlreiche Dienste zu diesem Thema, die sich in ihrer Funktion mehr oder weniger stark überschneiden und ergänzen. Grob lassen sich diese in die Bereiche Datenempfang/-übermittlung, Speicherung und Analyse einordnen. Eine Vorstellung aller Services würde an dieser Stelle zu weit führen. Stattdessen möchte ich anhand eines Azure Architektur-Patterns für «Real-Time Big Data Analytics» ein imaginäres Beispiel vorstellen und dabei auf einzelne Dienste näher eingehen. Den obligaten Azure Präfix bei den einzelnen Services lasse ich nachfolgend jeweils weg.
Stellen wir uns einen Kurznachrichtendienst namens «Barker» vor, der akute Probleme mit «alternativen Fakten» in Beiträgen («Barks») seiner Nutzer hat und diese, je nach Inhalt, automatisch markieren oder löschen möchte. Statt Sensor- und IoT-Daten (wie links in der obigen Grafik) werden daher Nachrichten aus der Barker-App und -Webapp an HDInsight (Ingestion) gesendet. HDInsight erlaubt (mittels Kafka) die Bereitstellung einer skalierbaren Pipeline, um kontinuierliche, simultane Datenstreams (die Barks unserer Millionen von Nutzerinnen und Nutzern) zu empfangen und weiterzuleiten – in diesem Fall an Databricks (Stream Processing).
Databricks ist eine Analyseplattform, die es unter anderem ermöglicht, Machine Learning (ML)-Modelle auf die Daten anzuwenden. Der Dienst ist daher perfekt geeignet, um ein vorgängig trainiertes ML-Modell zur Erkennung von problematischen Textinhalten auf unsere Barks anzuwenden und als «irreführend» zu markieren oder gleich zu löschen.
Die freigegebenen, teilweise markierten Barks werden schliesslich in die global verteile und hochgradig skalierbare Cosmos DB (Analytical Data Store) übermittelt, von wo die Follower über ihre mobile App oder Webapp mit den Daten beliefert werden. Datenanalytikerinnen und -analytiker von Barker können über Power BI (Analytics and Reporting) die Dashboards zur Nutzung ihres Dienstes sowie den Anteil problematischer Inhalte nachverfolgen oder benutzerdefinierte Abfragen ausführen.
In diesem Beispiel kommen sowohl Analysen von Echtzeitdaten als auch Batch-Daten vor, die jeweils in unterschiedliche Szenarien eingesetzt werden und sich ergänzen. Natürlich sind die erwähnten Dienste nicht die einzigen Möglichkeiten für solche Analysen. Zu nennen wären im Azure-Umfeld beispielsweise noch Data Factory (ETL), Synapse Analytics (Big Data Analytics) oder auch Stream Analytics (Real-Time Analytics).
Der Anwendungsfall entscheidet
Die passende Datenanalyse hängt also stark von der Art der Daten und deren zeitlichen Charakteristik ab. Im Bereich von konventionellen Daten (Nicht-Echtzeitdaten) gibt es zahllose Möglichkeiten, die auch mit geringem Aufwand umsetzbar sind. An Tools wären hier unter anderem R, Python, ArcGIS, QGIS oder SQL zu nennen.
Mit steigender zeitlicher Dringlichkeit und steigendem Datenvolumen wird die Datenanalyse zunehmend anspruchsvoller: Einerseits, weil hierfür vermehrt auf die Themenbereiche Automatisierung, Skalierbarkeit und Performanz geachtet werden muss, andererseits, weil entsprechende Systeme komplex zu erstellen und kostspielig sind. Hinsichtlich der Komplexität und der nötigen Hardware-Investitionen bringen Cloud-Plattformen für die meisten Nutzenden von Echtzeitsysteme eine spürbare Erleichterung. Allerdings gibt es auch hier Betriebskosten im verbreiteten «Pay as you go»-Abomodell.
Mein Fazit: Echtzeit-Datenanalysen sind ein äusserst spannendes Gebiet mit grossem Potenzial, aber der Einstieg will gut geplant sein. Wir unterstützen Sie gerne dabei!
Ein Gedanke zu „Fokus Echtzeitsysteme – Teil 6: Datenanalysen“
Kommentare sind geschlossen.