Aufbau einer unglaublich schwierigen Analyseplattform

Die Analyse von Ereignisströmen ermöglicht es Unternehmen, Streaming-Ereignisdaten der letzten Sekunden, Minuten oder Stunden zu nutzen, um Erkenntnisse zu gewinnen und Entscheidungen zu treffen. Diese neue Art der Analyse ermöglicht es Ihnen, schnell auf Probleme und Chancen zu reagieren - aber aus technischer Sicht ist es sehr schwer, das richtig zu machen.

Die Googles und Facebooks dieser Welt haben ausufernde, selbst entwickelte Systeme aufgebaut, um ihre Unternehmen mit Event Stream Analytics zu versorgen. Diese Systeme, die von Softwareteams mit Hunderten von Ingenieuren betreut werden, sind für die meisten Unternehmen unerschwinglich.

Wir haben Warehouse-Native Analytics entwickelt, damit jedes Unternehmen ein erstklassiges Analysesystem aufbauen kann. Alles, was sie brauchen, ist ein Cloud-Speicher wie AWS S3, eine Stream-Verarbeitungsplattform wie Apache Kafka und Warehouse-Native Analytics. Ich bin Priyendra Deshwal, CTO und Co-Founder von Warehouse-Native Analytics. Der Aufbau dieser Plattform war das Abenteuer meines Lebens, und heute möchte ich Ihnen einen Blick hinter die Kulissen der geheimen Soße geben, mit der Warehouse-Native Analytics funktioniert.

Die technischen Herausforderungen

Die Analyse von Ereignisströmen unterscheidet sich stark von der traditionellen Analyse und erfordert eine Reihe einzigartiger Funktionen. Lassen Sie uns einen Blick auf diese Anforderungen werfen und darauf, wie sie zu Herausforderungen führen, die wir bei Warehouse-Native Analytics mit großem Einsatz lösen.

• Dateneingabe: Bei der Ereignisstromanalyse geht es darum, zu wissen, was in der Gegenwart und was in der Vergangenheit passiert ist. Daher muss die Plattform die ständige Aufnahme von Ereignisdaten mit hohem Durchsatz und geringer Latenz unterstützen. Warehouse-Native Analytics ist für die Aufnahme von Millionen von Ereignissen pro Sekunde mit einer Aufnahme-Latenzzeit von weniger als einer Sekunde ausgelegt.
• Alarme im Sekundentakt: Das Verbrauchsmodell einer Event-Stream-Analyseplattform unterscheidet sich stark von der traditionellen Analytik. Traditionelle Analysen beruhen darauf, dass Benutzer Daten aus dem System abrufen, während operative Anwendungsfälle (wie die Überwachung) ein Push-Modell erfordern. Ein Alarm muss innerhalb von Sekunden nach dem Eintreten eines unerwünschten Ereignisses ausgelöst werden. Live Dashboards müssen immer den neuesten Stand des Systems anzeigen. Warehouse-Native Analytics unterstützt von Haus aus kontinuierliche, inkrementelle SQL-Abfragen im Streaming-Verfahren, um diese Anwendungsfälle zu erfüllen.
• Interaktive SQL-Abfragen: Auch wenn die primäre Interaktion mit einem Event-Stream-System Push-basiert ist, müssen Benutzer dennoch mit dem System über das Pull-Modell interagieren. Wenn zum Beispiel ein Alarm ausgelöst wird, ist es wichtig, dass die Benutzer Ad-hoc-Diagnoseuntersuchungen der Daten durchführen können. Um einen echten Einblick in das Unternehmen zu erhalten, muss die Plattform die Verknüpfung statischer Referenzdaten mit Streaming-Ereignisdaten erleichtern. Warehouse-Native Analytics verfügt über eine hochmoderne Abfrageausführungs-Engine, die interaktive SQL-Abfragen über große Datenmengen ermöglicht, und zwar sowohl für Daten in Bewegung als auch für Daten im Ruhezustand.
• Zeitreihen-Optimierungen: Die überwiegende Mehrheit der operativen Daten besteht aus mit Zeitstempeln versehenen Ereignisströmen, die eine spezielle Handhabung der Zeitsemantik erfordern - um die Vollständigkeit der Daten, das späte Eintreffen von Daten, fensterbasierte Aggregationen und Joins und mehr zu berücksichtigen. Warehouse-Native Analytics wurde entwickelt, um diese Komplexität zu bewältigen und eine effiziente Speicherung und Abfrage von Zeitreihen-Datenmengen zu unterstützen.
• Erweiterte Ereignisflussanalyse: Echte Ereignisstromanalysen ermöglichen es Benutzern, ein tiefes Verständnis von Ereignisfolgen und Pfaden von Ereigniszuständen zu entwickeln. Bei der Analyse von Ereignisströmen (Trichter, Sankey-Diagramme usw.) geht es oft um die Untersuchung von Ereignisabfolgen und Pfaden, die von Ereigniszuständen genommen werden. Diese Analysen lassen sich jedoch nur schwer mit SQL ausdrücken oder mit herkömmlichen Systemen berechnen. Warehouse-Native Analytics bietet native Unterstützung für erweiterte Ereignisflussanalysen.
• Datenmengen im Petabyte-Bereich: Da Unternehmen die Telemetrie in einer Vielzahl von Branchen eingeführt haben, sind Datenmengen im Petabyte-Bereich alltäglich geworden und jede Plattform muss auf diese Größen skalieren. Warehouse-Native Analytics ist so konzipiert, dass es auf die Anforderungen der größten Unternehmen der Welt skaliert.

Es gibt herkömmliche BI-Plattformen, Monitoring-Tools, Produktanalysesysteme und eine Vielzahl anderer spezialisierter Optionen, die eine oder gelegentlich auch mehrere dieser Anforderungen erfüllen. Warehouse-Native Analytics ist jedoch die erste Plattform, die alle für die Ereignisstromanalyse erforderlichen Funktionen an einem Ort vereint.

Die wichtigsten technischen Innovationen von Warehouse-Native Analytics

Warehouse-Native Analytics wird als vertikal integrierter Cloud-Service angeboten, um diese Anforderungen zu erfüllen. Es basiert auf drei Schlüsselinnovationen:

• Konvergente analytische Verarbeitung (CAP): Warehouse-Native Analytics muss eine Vielzahl von analytischen Workloads unterstützen. Unsere CAP-Datenplattform führt eine echte Konvergenz von Streaming- und Batch-Abfrageverarbeitung mit integrierter, optimierter Speicherung herbei. Sie ist für Streaming-Ingestion, effiziente inkrementelle Berechnungen, Event-Flow-Berechnungen, Zeitreisen und kontinuierliche SQL-Abfragen konzipiert - in extremem Umfang.
• Relationale Ereignisströme: Mit relationalen Ereignisströmen ermöglicht Warehouse-Native Analytics komplexe Ereignisflussanalysen auf der Grundlage des vertrauten und leistungsstarken relationalen Modells. Sie müssen nicht mehr spezielle Produktanalysetools für bestimmte Fragen und relationale Datenbanken für andere verwenden.
• NetScript: Wir wollten es einfacher machen, komplexe analytische Fragen zu stellen, die Data-at-Rest und Data-in-Motion verbinden. Deshalb haben wir eine neue Analysesprache namens NetScript entwickelt, die sich in SQL kompilieren lässt, aber ein höheres Maß an Abstraktion, Modularität und Wiederverwendbarkeit bietet. Für Geschäftsanwender ist kein Code erforderlich - wir bieten eine Bibliothek mit generischen und anwendungsspezifischen Vorlagen für die Produktanalyse.

Sie können sich CAP als die Berechnungsschicht vorstellen, relationale Ereignisströme als die Schicht zur Modellierung von Geschäftseinheiten und NetScript als die Art und Weise, wie Sie komplexe analytische Fragen einfach ausdrücken. Im Folgenden gehen wir auf jede dieser Innovationen näher ein und erläutern, wie sie uns helfen, zentrale Probleme bei der Implementierung von Event Stream Analytics zu lösen.

Konvergente analytische Verarbeitung

Die konvergierte analytische Verarbeitung (Converged Analytical Processing, CAP) ist eine konvergierte Batch- und Streaming-Engine, die auf einer hoch optimierten, integrierten Speicherebene läuft. Sie ermöglicht Ihnen die Abfrage all Ihrer Daten an einem Ort mit vollständiger Unterstützung für die Verknüpfung von Daten in Bewegung und Daten im Ruhezustand. CAP ist leistungsstark und flexibel und bietet ein Backbone mit niedriger Latenz und hohem Durchsatz für alles, von der Echtzeitüberwachung bis hin zu fortschrittlichen Analysen von Ereignisabläufen.

CAP wurde entwickelt, um den Bedarf an Batch- und Streaming-Computing und -Speicherung in einem einzigen Produkt zu decken. Data Warehouses haben traditionell Batch-Rechen- und Speicheraufgaben übernommen, nicht aber Streaming-Rechenaufgaben (kontinuierlich und inkrementell). Plattformen wie Apache Spark und Apache Flink waren für Batch- und Streaming-Berechnungen (aber nicht für die Speicherung) zuständig. Warehouse-Native Analytics bietet alle drei Möglichkeiten.

Das Problem, das es löst

Wenn Sie heute einen Blick in ein datenbewusstes Unternehmen werfen, werden Sie ein Gewirr von Data Warehouses, Data Lakes, Message Bussen, Stream-Prozessoren, Zeitreihendatenbanken, Echtzeit-OLAP-Engines, In-Memory-Datenbanken mit niedriger Latenz, Event-Flow-Analysen und mehr vorfinden.

Es gibt zwei Probleme mit dieser Architektur:

1. Hohe Betriebskosten: Für jedes System benötigen Sie ein hochqualifiziertes Team, um es zu verwalten, und die Komplexität wächst exponentiell, wenn mehr Systeme hinzukommen und auch die Beziehungen zwischen ihnen gehandhabt werden müssen. Sie können für einen Anbieter bezahlen oder mit den Entwicklungsstunden für die Implementierung einer Open-Source-Lösung, aber so oder so ist jedes zusätzliche System mit zusätzlichen Kosten verbunden.
2. Isolierte Daten: In einem komplexen Datenstapel mit vielen Analysesystemen sind natürlich nicht alle Datenmengen für alle Systeme sichtbar, und die Fähigkeit, Datenmengen zusammenzuführen, ist eher schwach. Dadurch entstehen Datensilos und die Entdeckung von datenmengenübergreifenden Erkenntnissen wird behindert. Wenn zum Beispiel die Daten über die Klicks auf Ihrer Site in einem Event-Analyse-Tool und die Daten über Ihre Kundenbeziehungen in einem Data Warehouse gespeichert sind, können Sie die Produktnutzung nicht nach den Gesamtausgaben des Kunden analysieren. Mit anderen Worten: Mit dieser Architektur kann ein Product Manager eine so grundlegende Frage wie "Wie nutzen meine wertvollen Kunden mein Produkt?" nicht beantworten.

Wie es funktioniert

Die Kernstücke der CAP-Engine und der Speicherschicht sind:

• Abfrageoptimierung: Abfragen werden geparst und in einen physischen Abfrageplan optimiert. Der physische Plan besteht aus einem Graphen von Operatoren, die für die Ausführung auf Knoten in einem Warehouse-Native Analytics-Cluster geplant sind. Diese Operatoren werden zu hoch optimierten Maschinencodefragmenten kompiliert, so dass Abfragen Hunderte von Millionen Zeilen pro Sekunde und Kern durchsuchen können.
• Vereint Batch und Streaming: Die Abfrageausführungs-Engine verfügt über eine Streaming-First-Architektur, bei der mit Apache Arrow kodierte Datenpakete durch einen Operator-Graphen fließen. Diese Operatoren geben Daten an nachgelagerte Operatoren frei, wenn sie spezielle Kontrollpakete mit Aktualisierungen von Wasserzeichen zur Ereigniszeit erhalten. Die Ausführungsschicht kann sowohl Batch- als auch Streaming-Berechnungen unterstützen, indem sie einfach die Häufigkeit der Wasserzeichenaktualisierungen steuert.
• Benutzerdefinierte Speicherschicht: Wir verwenden eine dreistufige säulenförmige Speicherarchitektur, bei der neu eingehende Daten direkt in den Speicher geschrieben werden, um eine Aufnahme mit einem Durchsatz von Millionen von Ereignissen pro Sekunde mit einer Aufnahme-Latenzzeit von weniger als einer Sekunde zu ermöglichen. Dies ist eine sehr gute Nutzung der knappen Speicherressourcen, da die meisten operativen Arbeitslasten frische Daten bevorzugen und stark davon profitieren, dass diese Daten bereits im Speicher vorhanden sind. Ältere, weniger häufig genutzte Daten werden an lokale NVMe- und Cloud-Blob-/Objektspeicher delegiert.
• Deklarative Kompromisse zwischen Kosten und Leistung: Wir haben "Knöpfe" in das System eingebaut, mit denen Benutzer die relativen Cache-Prioritäten verschiedener Datenmengen steuern, voraggregierte Indizes über Datenmengen erstellen, zusätzliche Kopien von Datenmengen mit unterschiedlichen Partitionierungs- und Clustering-Schlüsseln verwalten können und vieles mehr. Unsere Vision ist, dass die Benutzer in der Lage sein sollten, jeden gewünschten Punkt auf der Kosten-Leistungs-Kompromisskurve zu erreichen.

Relationale Ereignisströme

Durch die Modellierung von Geschäftsdaten als so genannte relationale Ereignisströme ermöglicht Warehouse-Native Analytics komplexe Ereignisflussanalysen über Daten, die in ihrer ursprünglichen relationalen Form gespeichert sind. Sie müssen sich nicht mehr zwischen der Untersuchung von Trichtern, der Segmentierung von Ereignissen oder Kohorten und der Durchführung "normaler" Slice-and-Dice-SQL-Abfragen für Ihre Ereignisströme entscheiden.

Das Problem, das es löst

Für herkömmliche Analysesysteme ist es sehr schwierig, Ereignisdaten darzustellen. Die bestehenden Ansätze fallen in zwei Kategorien:

• Sie stellen Ereignisdaten in einer vereinfachten Form dar. Spezialisierte Systeme für die Ereignisflussanalyse, wie z.B. Produktanalysetools, zwingen Sie dazu, Ihre Geschäftsdaten in starre, vordefinierte Modelle zu zwingen. Dadurch verlieren Sie den Reichtum der Daten. Diesen Tools fehlt auch die vollständige SQL-Unterstützung, so dass sie nur einen sehr kleinen Teil der analytischen Anwendungsfälle abdecken.

• Stellen Sie Ereignisdaten in ihrer ursprünglichen relationalen Form dar. In dieser Form haben die meisten Systeme Schwierigkeiten, Ereignisströme zu analysieren. Berechnungen auf Ereignisströmen lassen sich nicht einfach in SQL ausdrücken.

Mit relationalen Ereignisströmen überbrückt Warehouse-Native Analytics diese beiden Ansätze, um das Beste aus beiden Welten zu erreichen. Die Ereignisdaten werden in ihrer ursprünglichen relationalen Form dargestellt, aber die zugrunde liegende CAP-Architektur ist in der Lage, erweiterte Ereignisflussanalysen direkt auf dieser relationalen Form zu unterstützen.

Wie das funktioniert

Relationale Ereignisströme werden durch mehrere wichtige Funktionen unterstützt:

• Speicheroptimierungen: Die Ereignisdaten werden spaltenweise komprimiert und annähernd nach Zeit sortiert. Dies ermöglicht eine effiziente Unterstützung für fortgeschrittene Ereignisflussanalysen, da die Ereignisse in nach Zeitstempel sortierter Reihenfolge verarbeitet werden müssen.
• SQL-Erweiterungen für die Ereignisflussanalyse: MATCH_RECOGNIZE wurde dem SQL-Standard hinzugefügt, um komplexe Ereignisflussanalysen innerhalb von SQL zu ermöglichen. Die MATCH_RECOGNIZE-Implementierung von Warehouse-Native Analytics verwendet JIT-Codegenerierung und nutzt das Wissen über das zugrunde liegende Speicherlayout, um Hunderte von Millionen von Ereignissen pro Sekunde und Kern zu verarbeiten.
• Verbesserte Ausdrucksfähigkeit: Berechnungen für die Ereignisflussanalyse lassen sich nur sehr umständlich in SQL ausdrücken. Die Anwendungsschicht von Warehouse-Native Analytics (UI-Templates + NetScript) ermöglicht es, diese Analysen einfach auszudrücken. Die gesamte Komplexität der Formulierung der richtigen SQL-Abfrage, die technischen Aspekte im Zusammenhang mit der korrekten Verwendung von MATCH_RECOGNIZE usw. werden von der Anwendungsschicht übernommen.

NetScript

NetScript ist eine Programmiersprache, mit der Benutzer komplexe analytische Berechnungen auf einfache und natürliche Weise ausdrücken können. NetScript-Programme manipulieren keine Daten, sondern SQL-Abfragen und bieten die Möglichkeit, gängige analytische Operationen auf diese Abfragen anzuwenden: Filter anwenden, nach einer Dimension aggregieren, Zwischenergebnisse auf einer gemeinsamen Dimension zusammenführen usw.

Jede Interaktion in der Warehouse-Native Analytics UI wird von NetScript unterstützt. Wir haben festgestellt, dass NetScript intuitiv und leistungsstark ist. Wir möchten jedoch darauf hinweisen, dass NetScript für die Benutzer völlig optional ist - Sie können die Plattform mit SQL abfragen oder aus unserer großen Bibliothek mit No-Code-Vorlagen schöpfen.

Das Problem, das es löst

Wir haben NetScript erfunden, weil SQL drei große Nachteile bei der Darstellung analytischer Berechnungen hat:

1. SQL ist langatmig: Wenn Sie in der Praxis schon einmal mit analytischem SQL zu tun hatten, wissen Sie, dass die SQL-Abfragen für diese Berechnungen sehr umfangreich werden können und oft mehrere Seiten lang sind.
2. SQL ist repetitiv: In einer typischen Unternehmensumgebung verwenden viele Abfragen eine sehr kleine Anzahl von Verknüpfungen. Diese Verknüpfungsbedingungen werden in jeder Abfrage wiederholt.
3. SQL ist nicht modular: Was ist der natürlichste Weg, um die Metrik für den Gesamtumsatz in SQL zu definieren? Eine vernünftige Antwort ist: select sum(Umsatz) from Txns. Dieses relativ triviale Beispiel verdeutlicht einen wichtigen Mangel von SQL. Idealerweise würden wir diese Metrik gerne an einer zentralen Stelle definieren, damit alle unsere Berichte sie verwenden können, ohne ihre Logik zu duplizieren. Es ist jedoch nicht klar, wie wir diese Metrik wiederverwenden können. In den seltensten Fällen möchten wir einen Bericht mit dem Gesamtumsatz für alle Produkte oder alle Regionen erstellen. Tatsächliche Berichte würden diese Berechnung nach verschiedenen Kriterien filtern und die endgültige Zahl nach verschiedenen Dimensionsattributen aufteilen (was möglicherweise zu Verknüpfungen mit anderen Dimensionstabellen führt). Es gibt keine einfache Möglichkeit, diese endgültige SQL-Abfrage von der ursprünglichen SQL-Abfrage abzuleiten, die als Definition der Gesamtumsatzmetrik diente. SQL-Ansichten bieten zwar eine gewisse primitive Kompositionsfähigkeit - aber sie reichen bei weitem nicht aus, um die Art von Anwendungsfällen zu ermöglichen, für die NetScript konzipiert wurde.

Wie es funktioniert

Ein NetScript-Programm besteht aus Abfrageausdrücken. Der NetScript-Compiler nimmt den Abfrageausdruck als Eingabe und verwendet das zugrunde liegende Schema (Tabellen, Spalten und Beziehungen), um den Ausdruck in eine SQL-Abfrage zu konvertieren, die an die Berechnungsschicht gesendet wird.

Eine NetScript-Operation, wie z.B. ein Filter, filtert nicht nur die Daten, die aus einem Operator kommen. Vielmehr versteht er die Semantik der Eingabe und nimmt eine tiefgreifende Operation an der SQL-Eingabeabfrage vor, um die Semantik des angewandten Filters zu unterstützen. Diese Operation kann den Filter durch Aggregate schieben, Joins einführen, um Spalten einzubinden, auf die die Filterbedingung verweist, und so weiter.

Wir erheben nicht den Anspruch, dass NetScript SQL ersetzen kann - schließlich lässt es sich in SQL kompilieren! Aber wir glauben, dass das NetScript-Modell der Art und Weise, wie Benutzer (und analytische Anwendungen) Berechnungen darstellen, näher kommt und es Ihnen ermöglicht, Programme auf einer höheren Abstraktionsebene zu schreiben.

Das Licht am Ende des Analysetunnels

Die Entwicklung einer Lösung für die Analyse von Ereignisströmen hat viele Jahrzehnte gedauert. Jetzt ist endlich der richtige Zeitpunkt gekommen. Vom Standpunkt der Technik aus betrachtet, ermöglichen heute zwei Faktoren den Aufstieg der operativen Intelligenz:

1. Stream-Verarbeitung: Stream-Processing-Plattformen wie Kafka sind heute in den meisten Unternehmen Standard. Außerdem wächst das Verständnis für die Feinheiten der Stream-Verarbeitung, wie z.B. Exact-once-Semantik, Daten, die nicht in der richtigen Reihenfolge und zu spät eintreffen, Wasserzeichen, Transaktionsgarantien usw. Infolgedessen werden immer mehr Daten im Streaming-Verfahren konsumiert, was das Potenzial für Streaming-Analysen auf diesen Daten eröffnet.
2. Cloud-Datenbanken: Die Fähigkeit, Ereignisdaten in Echtzeit zu instrumentieren und zu erfassen, muss mit effizienten Möglichkeiten zur Speicherung und Verwaltung dieser Daten einhergehen. An dieser Stelle kommen moderne Data Lakes ins Spiel. Cloud-Blob-/Objektspeicher wie AWS S3 bieten effiziente und kostengünstige Möglichkeiten zum Speichern, Sichern und Verwalten einer ständig wachsenden, riesigen Menge von Ereignisdaten. Da immer mehr Unternehmen in die Cloud wechseln und diese modernen Data Lakes aufbauen, werden alle Rohdaten in der kleinsten Granularität für Analysen verfügbar.

Das dritte fehlende Element ist eine Plattform, die es möglich und sogar einfach macht, komplexe analytische Fragen zu stellen, indem sie Ihre Streaming- und Batch-Daten zusammenführt.

Hier kommt Warehouse-Native Analytics ins Spiel und vervollständigt das, was wir den modernen Data Intelligence Stack nennen.