Analytics, Business Insights und AI in Echtzeit – aber wie? Eine Analyse von Boris Bialek, MongoDB

Eine Reise in die Vergangenheit

Neben der unverwüstlichen Excel-Tabelle ist die Analytik die älteste Form der Datenverarbeitung, die mit den „ Tabelliermaschinen” und ihren Lochkarten begann. In den 1990er Jahren tauchte der Begriff Enterprise Data Warehouse (EDW) auf und führte zu der Vorstellung, dass es sich bei der Analytik um eine klassische Back-Office-Funktion handelt, bei der Daten kuratiert und dann zunächst in Form von Berichten und später in stärker Endbenutzer-orientierten Business Intelligence-Plattformen veröffentlicht werden.

All diese Analysefunktionen waren jedoch langsam und nicht in einer engen Rückkopplung mit dem Endbenutzer. Wie sieht es aber mit echten „Echtzeit“-Funktionen aus? Diese sind mit den bestehenden EDW-Lösungen einfach nicht möglich. Das bedeutet, dass wir uns ändern müssen.

Die Herausforderungen von heute

Der Begriff Echtzeit ist subjektiv. Die Echtzeit in einem selbstfahrenden Auto (gemessen in Millisekunden) unterscheidet sich von der für einen Endnutzer (weniger als 1 Sekunde). Die weit gefasste Definition von Echtzeitanalysen ist, dass sie den Entscheidungsfindungsprozess definieren, um unmittelbare Aktionen eines Systems auf der Grundlage von Sensordaten, die es erhält, zu steuern.

Echtzeit-Analysen können in vielen Branchen eingesetzt werden. Zum Beispiel ist jeder Betreiber von Zahlungssystemen über betrügerische Aktivitäten besorgt. Das klassische Modell in den EDW-Tagen bestand darin, eine nächtliche, wöchentliche oder monatliche Analyse der vorhandenen Transaktionen durchzuführen; auf dieser Grundlage wurde dann eine Liste der bedenklichen Akteure erstellt, gefolgt von einem Entscheidungsfindungsprozess – basierend auf einer Reihe von Regeln, die oft fest im eigentlichen Zahlungssystem verdrahtet waren. Zu diesem Zeitpunkt waren die Daten, die zur Entscheidungsfindung herangezogen wurden, bereits veraltet oder sogar überholt.

In ähnlicher Weise möchte ein E-Commerce-Händler, ein Telekommunikationsanbieter, der neue Datentarife verkauft, oder eine Bank, die Hypothekendarlehen verkauft, hochgradig personalisierte Angebote machen, die auf den “wahren Wünschen” des Verbrauchers basieren. Der klassische Weg würde uns wieder zum EDW führen, wo Gruppen von Individuen berechnet werden und dann dem Online-System zugeordnet werden können.

Eine Drehmaschine in der Automobilproduktion liefert Tausende von Sensorsignalen pro Sekunde an eine Steuereinheit. Das ultimative Ziel wäre es, dass der Bediener das Nutzungsmuster der Maschine maximiert, um von einer geplanten Wartung zu einer präventiven und vorbeugenden Wartung auf der Grundlage der tatsächlichen Nutzung der Maschine überzugehen. Dies setzt die Messung und Interpretation von Echtzeitdaten voraus, die über die vereinfachte „Max-Min-Wert”-Bewertung hinausgehen. EDW-Informationen würden uns diese durchschnittlichen Lebenszykluserwartungen liefern und können die geplante Wartung optimieren, aber sie können nicht sekunden- oder minutengenau reagieren, um spezifische Maßnahmen zu ergreifen – einschließlich des rechtzeitigen Abschaltens, bevor ein größerer Schaden entsteht.

Einführung in die Echtzeit-Analytik

Echtzeit-Analytik ist das Konzept der Verwendung von Transaktionsdaten „In-Flight”, zusätzlich zu den vorhandenen Metadaten und, ja, auch historischen Informationen, um eine Entscheidung des Systems zu treffen. Dieses Konzept beinhaltet viele Begriffe, was zur heutigen Verwirrung bei dem Thema beiträgt. Gartner nennt es Hybrid Transaction OLAP Processing – kurz HTAP. Forrester nennt es Translytics und andere nennen es Stream Analytics, um es in ihr Weltbild der ereignisgesteuerten Architekturen einzugliedern. Unabhängig davon, wie der Prozess genannt wird, er beschreibt letztendlich die Umwandlung von OLTP, transaktionaler Funktionalität in Kohorten, zu analytischer Entscheidungsfindung basierend auf tatsächlichen Ereignissen.

Die Ausführung dieser analytischen Echtzeitfunktionen wird aus dem Dokumentenmodell selbst abgeleitet. Da das Dokumentenmodell eine größere einzelne Datenschicht aufbaut, die oft als operativer Datenspeicher oder operative Datenschicht bezeichnet wird, wird die Datendichte und das Zugriffsmuster unglaublich praktikabel. In unserem Zahlungsbeispiel müssen wir lediglich den tatsächlich angeforderten Zahlungsdatensatz mit den Informationen über den Verbraucher (Beispiel Einzelhandel) oder den Absender und Empfänger (Beispiel Banken) kombinieren. Die kombinierten Daten können nun für In-Place-Analysen verwendet werden.

Die nachstehende Abbildung zeigt den Flow, beginnend mit den verschiedenen Datenquellen, die Daten in den einzigen Datensatz einbringen. Es ergibt sich ein vollständigeres Bild über den Verbraucher, als nur die Ansicht der eigentlichen Transaktion. Jede einzelne ECHTZEIT-Interaktion mit dem Kunden wird gleichzeitig in das Profil eingespeist, womit der Unterschied zu einem EDW-basierten Ansatz beginnt.

In verschiedenen Szenarien wirkt sich dieses Konzept in weniger als 50 Millisekunden auf den Gesamtprozess aus, so dass wir wirklich von einer Echtzeit-Erfahrung sprechen können.

Wie funktioniert das alles?

Die Echtzeit-Möglichkeiten klingen wie Zauberei, aber es gibt grundlegende Unterschiede in der Art und Weise, wie Legacy-Systeme, die auf relationalen Strukturen basieren, und moderne Datenplattformen dies umsetzen.

Der grundlegendste Unterschied ist die Einführung eines globalen Standards für Dokumente: JSON. JSON-Dokumente sind einfach zu strukturieren und zu speichern (was hier wichtig ist). Anstelle mehrerer Operationen für den Zugriff auf verschiedene Tabellen in einer Datenbank können sie fast immer mit einer einzigen IO-Operation abgerufen werden. Die Daten werden dann so dargestellt, dass die Anwendung die Daten ohne zusätzliche objektrelationale Mapping-Lösungen, die das Objekt konstruieren müssten, betrachten kann. Die Daten sind sofort verfügbar, wenn und wo sie benötigt werden.

Eine weitere wichtige Komponente ist die Workload-Isolierung, so dass die Knoten (Nodes) in einem Lesemuster für bestimmte Anwendungen betrieben werden können. In unserem Zahlungsbeispiel wäre dies ein Knoten, der für die Betrugserkennung zuständig ist. Auf diese Weise wird die eigentliche Transaktionsausführung nicht durch die Betrugsverarbeitung als paralleler Stream beeinträchtigt und kann am Ende des Prozesses das Signal von der Betrugserkennungsauswertung aufnehmen.

Und der letzte, entscheidende Aspekt der Echtzeitanalyse, ist die Skalierung. Dies zeigt sich im Scale-Out und der Ermöglichung der Aufnahme großer Datenmengen, z. B. für die Signale von Maschinen in der Fertigung mit Hunderten von Maschinen, die Zeitreihendaten liefern.

Wie geht es jetzt weiter?

Die beste Antwort ist, einfach anzufangen. Laden Sie einige Testdaten in eine neue Datenbank und experimentieren Sie, um zu sehen, wie sich Echtzeitanalysen auf Ihr Unternehmen auswirken könnten. Es war noch nie so einfach, eine Umgebung für Echtzeit-Funktionen zu schaffen, also ist es jetzt an der Zeit, loszulegen.

Boris Bialek hat uns diese Analyse zur Verfügung gestellt. Kontaktieren Sie ihn jederzeit direkt via https://www.linkedin.com/in/bbialek/

Weitere Informationen: https://www.mongodb.com/use-cases/analytics/real-time-analytics