DE202016007901U1 - Datenfluss - Fenster- und Triggerfunktion - Google Patents

Abstract

System, das Folgendes umfasst: Datenverarbeitungshardware (710); und Hardwarespeicher (720) in Verbindung mit der Datenverarbeitungshardware (710), wobei der Hardwarespeicher (720) Instruktionen speichert, die, wenn auf der Datenverarbeitungshardware (710) ausgeführt, die Datenverarbeitungshardware (710) dazu bringen, Operationen auszuführen, die Folgendes umfassen: das Erhalten von Daten (10), entsprechend entweder Streamingdaten (10) oder Batchdaten; die Ermittlung eines Inhalts der erhaltenen Daten (10) für die Berechnung; das Ermitteln einer Ereigniszeit der Daten (10) zur Aufteilung der Daten (10); das Ermitteln einer Verarbeitungszeit zur Ausgabe von Ergebnissen der erhaltenen Daten (10); und das Ausgeben mindestens eines Teils der Ergebnisse der erhaltenen Daten (10) basierend auf der Ereigniszeit und der Verarbeitungszeit.

Description

• TECHNISCHES GEBIET
• Die folgende Offenbarung bezieht sich auf die Fenster- und Triggerfunktion des Datenflusses. Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind dabei, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
• KURZDARSTELLUNG
• Ein Aspekt der Offenbarung bezieht sich auf ein Verfahren für die Fenster- und die Triggerfunktion des Datenflusses. Das Verfahren umfasst den Empfang von Daten aus einem Datenstrom oder aus einem Datenbatch von einer Daten verarbeitenden Hardware. Dabei wird die Nutzung der Daten verarbeitenden Hardware, der Inhalt der zu berechnenden empfangenen Daten, die Nutzung der Daten verarbeitenden Hardware, eine Ereigniszeit für die Segmentierung von Daten, den Zeitpunkt für die Verarbeitung von Ausgabeergebnissen der empfangenen Daten mithilfe der Daten verarbeitenden Hardware. Das Verfahren umfasst auch die Ausgabe mindestens eines Abschnittes der Ergebnisse der empfangenen Daten auf Basis der Verarbeitungs- und der Ereigniszeit.
• Implementierungen der Offenbarung können eine oder mehrere der folgenden charakteristischen Merkmale beinhalten. In einigen Implementierungen umfasst das Verfahren das Gruppieren der empfangenen Datenfenster mithilfe der Daten verarbeitenden Hardware basierend auf der Ereigniszeit. Die Fenster können ein fixiertes Fenster umfassen, das nach statischer Zeitperiode definiert ist, ein nach einer Zeitperiode und nach einer Ausschnittsperiode definiertes gleitendes Fenster, nach einer Zeitüberschreitungslücke definierte Sitzungsfenster oder nach Funktionspaaren definierte benutzerdefinierte Fenster. Jedes fixierte kann auf alle Daten innerhalb der zugewiesenen Zeit angewendet werden. Jedes gleitende Fenster kann innerhalb der Zeitperiode auf alle Daten angewendet und einer Startzeit zugewiesen werden, die von der Startzeit des unmittelbar nachfolgenden Fensters durch eine Ausschnittsperiode getrennt ist. Darüber hinaus kann jedes Sitzungsfenster auf eine Teilmenge der Daten angewendet werden, die innerhalb einer Zeitspanne auftreten, die kürzer als die zugewiesene Zeitüberschreitung ist. In einigen Beispielen umfasst die Methode das Zuweisen und Verwenden Daten verarbeitender Hardware, ein mit jedem Element der eingegangenen Daten zusammenzuführendes Element, wobei jedes Element einen zugewiesenen Eingangszeitstempel sowie ein zusammenzuführendes Fenster umfasst, das den vordefinierten Zeitraum über den Eingangszeitstempel für das zugewiesene Fenster überschreitet. Die Methode kann auch die Zusammenführung umfassen, für die Daten verarbeitende Hardware verwendet wird, mindestens zwei zusammenzuführende Fenster, die zum selben Schlüssel gehören, wobei dieser in ein einzelnes zusammenzuführendes Fenster übergeht, sowie eine Einstellung, für die Daten verarbeitende Hardware, ein für jedes Element einem Wert zugewiesener Ausgangszeitstempel, der größer als oder gleich dem frühesten Zeitpunkt im zugewiesenen zusammengeführten Fenster oder dem zugewiesenen zusammenzuführenden Fenster ist. Das einzelne, zusammengeführte Fenster kann einen zugewiesenen Zeitraum umfassen, der den vordefinierten Zeitraum überschreitet.
• Wenn die eingegangenen Daten mit dem Datenstrom übereinstimmen, kann die Methode die Gruppierung der Datenströme in Fenster mithilfe Daten verarbeitender Hardware umfassen, sowie Einstellungen mithilfe Daten verarbeitender Hardware, einen Eingangszeitstempel auf einem Element der Datenströme. Wenn der Eingangszeitstempel vor dem Grenzwert auftritt, kann die Methode das mithilfe Daten verarbeitender Hardware vorgenommene Bestimmen von Datenströmen einschließlich neuester Datenströme umfassen sowie das Ablegen des neuesten Datenstroms, indem ein dupliziertes Fenster in einer Ausgabe für den neuesten Datenstrom erstellt wird.
• In einigen Beispielen umfasst die Methode das mithilfe Daten verarbeitender Hardware durchgeführte Gruppieren, eine erste Teilmenge der empfangenen Daten in ein Fenster. Durch dieses Fenster wird die Zeit eines Unterereignisses der Datenteilmenge definiert. Dabei wird mithilfe der Daten verarbeitenden Hardware das erste Ergebnis der ersten Datenteilmenge des Fensters durch Aggregieren bestimmt. Ferner wird mithilfe der Daten verarbeitenden Hardware die Trigger-Zeit bestimmt, zu der das erste aggregierte Ergebnis der ersten Datenteilmenge ausgegeben wird. Die Trigger-Zeit kann umfasst u. a. mindestens Folgendes: Wenn ein Grenzwert das Ende des Fensters erreicht, entspricht jeder Schwellenwert der Sekundenanzahl einer tatsächlichen Zeit; nach Eingang eines Interpunktionszeichens zum Bestimmen des Fensters, entspricht der Schwellenwert der Anzahl der Datensätze; nach dem die beliebige Benutzerlogik den Trigger festlegt oder nach einer beliebigen Kombination konkreter Trigger.
• Beim Festlegen der Trigger-Zeit für die Ausgabe des ersten aggregierten Ergebnisses der ersten Datenteilmenge, kann die Methode das mithilfe der Daten verarbeitenden Hardware vorgenommene Verwerfen des ersten aggregierten Ergebnisses umfassen, wenn die aggregierten Ergebnisse aus späteren Untermengen der empfangenen Daten stammen. Beim Festlegen der Trigger-Zeit für die Ausgabe des aggregierten Ergebnisses der ersten Datenuntermenge kann die Methode auch das Speichern einer Kopie des ersten aggregierten Ergebnisses in einem permanenten Status in der Speicherhardware bei der Kommunikation mit der Hardware für die Verarbeitung von Hardware umfassen, sowie die Verfeinerung des nächsten aggregierten Ergebnisses einer späteren Teilmenge mit dem ersten aggregierten Ergebnis. Beim Festlegen der Trigger-Zeit für die Ausgabe des aggregierten Ergebnisses der ersten Datenteilmenge kann die Methode zudem das Speichern einer Kopie des ersten aggregierten Ergebnisses in einem permanenten Status innerhalb der Speicherhardware bei der Kommunikation mit der Hardware für Datenverarbeitung umfassen. Wenn ein neues aggregiertes Ergebnis einer späteren Teilmenge mit denselben Fensterausgaben verknüpft wird, kann die Methode die Ausgabe einer Rücknahme des ersten aggregierten Ergebnisses und die Ausgabe eines kombinierten Sitzungsergebnisses für das Fenster umfassen.
• In einigen Implementierungen umfasst die Methode das Empfangen eines späten Datenpunkts auf der Hardware für Datenverarbeitung, nachdem die erste Datenteilmenge in das Fenster gruppiert wurde, wobei sich der spätere Datenpunkt auf das Fenster bezieht und mit der Hardware für Datenverarbeitung wird der späte Datenpunkt auch verworfen. Die Methode kann auch den Empfang des späten Datenpunkts auf der Hardware für Datenverarbeitung umfassen, nachdem die erste Datenteilmenge in das Fenster gruppiert wurde, sich der späte Datenpunkt auf das Fenster bezieht und mithilfe der Hardware für Datenverarbeitung der verspätete Datenpunkt in das Fenster gesammelt wird, um das erste aggregierte Ergebnis mit dem späteren Datenpunkt zu verfeinern. Darüber hinaus kann die Methode den Eingang eines späten Datenpunkts auf der Hardware für Datenverarbeitung umfassen, nachdem die erste Datenuntermenge in das Fenster gruppiert wurde, und sich der späte Datenpunkt auf das Fenster bezieht, wobei ein kombiniertes Ergebnis der ersten Datenteilmenge und der letzte späte Datenpunkt über die Hardware für Datenverarbeitung gesammelt werden und das kombinierte Ergebnis ausgegeben wird.
• Ein weiterer Aspekt des vorliegenden Dokuments stellt ein System für Fenster- und Triggerfunktion des Datenflusses bereit. Das System umfasst Hardware für Datenverarbeitung und Speicherhardware in Verbindung mit der Hardware für Datenverarbeitung. Die Speicherhardware speichert Anweisungen, deren Ausführung auf der Hardware für Datenverarbeitung letztere zum Durchführen von Operationen veranlasst. Die Operationen umfassen: Eingang von Daten entsprechend dem Datenstrom oder Datenbatch; Bestimmen des Inhalts der eingegangenen Daten zur Berechnung; Bestimmen einer Ereigniszeit der Daten zur Segmentierung der Daten; Bestimmen einer Verarbeitungszeit für Ausgabeergebnisse der empfangenen Daten; und Ausgabe von mindestens einem Abschnitt der Ergebnisse der empfangenen Daten basierend auf der Verarbeitungszeit und der Ereigniszeit.
• Die Implementierung dieses Falls kann eine oder mehrere der folgenden Eigenschaften beinhalten. In einigen Beispielen umfassen die Operationen zusätzlich das Gruppieren von eingegangenen Daten in Fenster basierend auf der Ereigniszeit. Die Fenster umfassen eines der fixierten Fenster, die nach einem statischen Zeitraum definiert wurden, nach einer Zeitdauer und nach einer Segmentierungsdauer definierte Segmentierungsfenster, nach einer Zeitüberschreitungslücke definierte Sitzungsfenster oder nach Paarfunktionen definierte benutzerdefinierte Fenster. Jedes fixierte Fenster kann innerhalb der zugewiesenen Zeitdauer auf alle Daten angewendet werden, wobei jedes Segmentierungsfenster auf alle Daten innerhalb der zugewiesenen Zeitdauer angewendet und einer Startzeit zugewiesen werden, die durch eine Segmentierungsdauer vom unmittelbar nachfolgenden Zeitfenster getrennt ist. Dabei kann jedes Sitzungsfenster auf eine Untermenge der Daten angewendet werden, die innerhalb einer Zeitdauer auftreten, die die zugewiesene Zeitüberschreitungslücke unterschreitet.
• Die Operationen können weiterhin das Zuweisungen zusammenzuführender Fenster für jedes Element der empfangenen Daten umfassen. Dabei umfasst jedes Element einen zugewiesenen Eingangszeitstempel und jedes zusammenzuführende Fenster wird auf eine vordefinierte Zeitdauer erweitert, die über den Zeitstempel für das zugewiesene Fenster hinausgeht. Die Operationen umfassen außerdem das Zusammenführen von mindestens zwei zusammenführbaren Fenstern, die zum selben Schlüssel gehören. Dieser schwappt in ein einzelnes zusammengeführtes Fenster über und stellt einen zugewiesenen Ausgabestempel für jedes Element auf einen Wert ein, der höher oder gleich dem frühesten Zeitpunkt im zusammengeführten Fenster oder dem zugewiesenen zusammenzuführenden Fenster ist. Das einzelne zusammengeführte Fenster kann einen zugewiesenen Zeitraum umfassen, der größer als der vordefinierte Zeitraum ist.
• Wenn die eingegangenen Daten mit den Datenströmen übereinstimmen, können die Operationen weiterhin Gruppierung mithilfe von Hardware für die Datenverarbeitung in Fenster umfassen sowie das Einstellung eines Eingangszeitstempels eines Elements der Datenströme ebenfalls mithilfe der Hardware für Datenverarbeitung. Wenn der Eingangszeitstempel für das Element vor dem Grenzwert auftritt, können die Operationen mithilfe der Hardware für Datenverarbeitung festlegen, dass die Datenströme die neuesten Datenströme umfassen. Hierzu zählen u. a.: Ablegen des neuesten Datenstroms oder Ermöglichen des neuesten Datenstroms durch Erstellen eines doppelten Fensters in einer Ausgabe für den neuesten Datenstrom.
• In einigen Beispielen umfassen die Operationen weiterhin das Gruppieren einer ersten Teilmenge der empfangenen Daten in ein Fenster, wobei das Fenster einen Unterereigniszeitpunkt der Datenteilmenge definiert. Dabei wird ein erstes Ergebnis der ersten Teilmenge für das Fenster gesammelt und ein Trigger-Zeitpunkt für die Ausgabe des ersten gesammelten Ergebnisses der ersten Datenteilmenge festgelegt. Der Trigger-Zeitpunkt umfasst mindestens Folgendes: Wenn ein Grenzwert das Ende des Fensters erreicht, entspricht der Schwellenwert der Sekundenzahl der tatsächlichen Zeit; nach Eingang des Interpunktionszeichens, mit dem das Fenster beendet wird, entspricht jeder Schwellenwert der Anzahl der Interpunktionszechen; nachdem eine beliebige Benutzerlogik die Trigger-Funktion auslöst oder nach einer beliebigen Kombination aus konkreten Trigger-Funktionen.
• Wenn der Trigger-Zeitpunkt für die Ausgabe des ersten gesammelten Ergebnisses der ersten Datenteilmenge bestimmt wird, umfassen die Operationen u. U. das Verwerfen des ersten gesammelten Ergebnisses, wenn die Ergebnisse der späteren Teilmengen der empfangenen Daten gesammelt werden. Wenn der Trigger-Zeitpunkt für die Ausgabe des ersten gesammelten Ergebnisses der ersten Datenteilmenge bestimmt wird, können die Operationen auch das Speichern einer Kopie des ersten gesammelten Ergebnisses in einen permanenten Status innerhalb der Speicherhardware bei der Kommunikation mit der Hardware für die Datenverarbeitung umfassen, sowie das Verfeinern des nächsten gesammelten Ergebnisses einer späteren Teilmenge mit dem ersten gesammelten Ergebnis. Wenn der Trigger-Zeitpunkt für die Ausgabe des ersten gesammelten Ergebnisses der ersten Datenteilmenge bestimmt wird, können die Operationen zusätzliche das Speichern einer Kopie des ersten gesammelten Ergebnisses in einen permanenten Status auf der Speicherhardware bei der Kommunikation mit der Hardware für Datenverarbeitung umfassen. Wenn das nächste gesammelte Ergebnis einer späteren Teilmenge denselben Fensterausgaben zugewiesen wird, können die Operationen die Ausgabe einer Rücknahme des ersten gesammelten Ergebnisses und die Ausgabe eines kombinierten Sitzungsergebnisses für das Fenster umfassen.
• In einigen Beispielen umfassen die Operationen das Umfassen eines späten Datenpunkts, nachdem die erste Datenteilmenge in das Fenster gruppiert wurde, der später Datenpunkt mit dem Fenster verbunden ist und der späte Datenpunkt verworfen wird. Die Operationen können zudem das Empfangen eines späten Datenpunkts umfassen, nachdem die erste Datenteilmenge in das Fenster gruppiert wurde, wenn der späte Datenpunkt mit dem Fenster verbunden ist und der späte Datenpunkt in das Fenster gesammelt wird, um das erste gesammelte Ergebnis mit dem letzten Datenpunkt zu verfeinern. Die Operationen können ferner das Empfangen eines letzten Datenpunkts nach Gruppieren der ersten Datenteilmenge in das Fenster umfassen, wobei der letzte Datenpunkt mit dem Fenster verbunden ist, in welches das kombinierte Ergebnis der ersten Datenteilmenge und der späte Datenpunkt gesammelt werden, um das kombinierte Ergebnis auszugeben.
• Die Einzelheiten einer oder mehrerer Implementierungen der Offenbarung sind in den begleitenden Zeichnungen und der Beschreibung unten dargelegt. Andere Merkmale, Objekte und Vorteile sind aus der Beschreibung und den Zeichnungen sowie aus den Patentansprüchen ersichtlich.
• BESCHREIBUNG DER ZEICHNUNGEN
• 1A und 1B sind schematische Ansichten eines Beispielsystems für Datenstromberechnung.
• 2 ist eine schematische Ansicht einer Beispiel-API (Application Programming Interface) für Fensterfunktionen des Systems für Datenstromberechnung aus 1.
• 3 ist ein Beispiel für feste, Segmentierungs- und Sitzungsfenster.
• 4 ist eine Beispieldarstellung für die Neigung einer Fensterzeitdomäne.
• 5 ist ein Beispiel für den Vorgang einer Fensterzusammenführung.
• 6A ist ein Beispieldiagramm für die Neigung einer Fensterzeitdomäne für Datenpunkteingaben.
• 6B ist ein Beispieldiagramm, in dem das Ausgangsergebnis eines einzelnen globalen Fensters angezeigt wird.
• 6C ist ein Beispieldiagramm, in dem die Ausgangsergebnisse gezeigt werden, die über die Regionen der Verarbeitungszeit aufgezeichnet wurden.
• 6D ist ein Beispieldiagramm, in dem die Ausgangsergebnisse der unabhängigen Regionen der Verarbeitungszeit dargestellt werden.
• 6E ist ein Beispieldiagramm, in dem die Ausgangsergebnisse aus unabhängigen Regionen der Verarbeitungszeit dargestellt werden.
• 6F ist ein Beispieldiagramm, in dem die Datenpunkteingänge gezeigt werden, die in fixierten Fenstern gruppiert werden, sowie Ausgangsergebnisse aus den fixierten Fenstern als Grenzwertvorteilen.
• 6G ist ein Beispieldiagramm, in dem in fixierte Fenster gruppierte Datenpunkteingänge sowie aus fixierten Fenstern ausgegebene Ausgangsergebnisse in aufeinanderfolgenden Mikrobatches gezeigt werden.
• 6H ist ein Beispieldiagramm, in dem der späte Datenpunkt gezeigt wird, der ein Ausgangsergebnis eines fixierten Fensters gezeigt wird.
• 6I ist ein Beispieldiagramm, in dem die Ausgangsergebnisse basierend auf Verarbeitungszeit-abhängigen Ausgangsergebnissen gezeigt werden.
• 6J ist ein Beispieldiagramm, in dem Datenpunkteingänge gezeigt werden, die innerhalb von Sitzungsfenstern und kombinierte Ausgabeergebnisse aus kombinierten Sitzungsfenstern gezeigt werden.
• 7 ist eine schematische Ansicht eines Beispielrechengeräts, auf dem alle im Folgenden beschriebenen Systeme oder Geräte beschrieben werden.
• Wie Referenzsymbole in den unterschiedlichen Zeichnungen auf ähnliche Elemente hinweisen.
• AUSFÜHRLICHE BESCHREIBUNG
• Die Verarbeitung von Datenbatches ist die Ausführung von Programmen (alias Jobs) auf einem Computer ohne Benutzereingriff, d. h. ohne menschlichen Eingriff. Die Programmparameter werden über Skripte, Befehlszeilenargumente, Steuerungsdateien oder Auftragssteuerungssprache vordefiniert. Ein Programm, das Datendateien als Eingang aufnimmt und die Daten dann verarbeitet, bevor ein Satz aus Ausgabedateien erzeugt wird. Der Begriff ”Batchverarbeitung” bezieht sich auf Eingangsdaten, die in Batches oder Sätze von Datensätzen gesammelt wird, wobei jeder Batch als Einheit verarbeitet wird. Der Ausgang ist auch ein Batch, der für Berechnungen wiederverwendet wird.
• Die Verarbeitung großer Datenbatches ist in der Branche bekannt. Ein Programmierer schreibt Code, der eine bestimmte Rechenweise beschreibt, und führt diesen Code dann für einen festgelegten Datensatz aus, um ein Ergebnis zu produzieren. Wenn die in Frage kommende Berechnung mit der Zeit auch Aggregation umfasst (d. h. Gruppieren in fixierte Fenster oder Berechnungen von Sitzungen pro Benutzer), dann verarbeitet der Programmierer entweder Daten in Batches in Fenstergröße (für einfache Fälle wie fixierte Fenster) oder der Programmierer integriert die Fensterlogik in Ihrer Rechenlogik (für komplexe Fälle wie Benutzersitzungen). Zeitbasierte Aggregation ist tatsächlich relativ häufig, da sie beim Analysieren von Muster des Benutzerverhaltens sehr nützlich sind.
• Wenn sich ein Programmierer mit Datenströmen beschäftigt, was im Vergleich zur Batchverarbeitung ein relativ neues Gebiet ist, verfügt der Programmierer über einen grundsätzlich ungebundenen Satz an Daten, für den er eine ähnliche Berechnung durchführen wird. Da die Daten jedoch keine festgelegten Grenzen aufweisen, muss der Programmierer entweder (1) einen Online-Schätzungsalgorithmus (z. B. Algorithmus Top N) verwenden oder (2) eine Möglichkeit finden, mit der er den Datenstrom aufteilt.
• Online-Schätzungsalgorithmen können sich für einige Anwendungen als hilfreich erweisen, aber da die Ergebnisse geschätzt sind, können sie präzise Ergebnisse von Batch-Berechnungen nicht vollständig ersetzen. Folglich muss der Programmierer beides, Datenströme und Batch-System parallel (z. B. Lambda Architektur) ausführen: Ströme für geringe Latenz und Batches für präzise und wiederholbare Ergebnisse.
• Durch das Aufteilen von Datenströmen ergibt sich die Möglichkeiten, präzise Ergebnisse in Streaming-Form zu berechnen. Zusätzlich zum Programmieren der Aggregation stellt sich dem Programmierer auch das Problem, an welcher Stelle er den Datenstrom aufteilen und dann die Ergebnisse ausgegeben werden sollen. Bei den meisten Datenstromsystemen werden Datenströme automatisch in fixierte Fenster aufgeteilt basierend auf dem Zeitpunkt ihres Eingangs im Systems (d. h., der Programmierer fordert Fünf-Minuten-Fenster und dann puffert der Programmierer Daten von fünf Minuten Dauer nach ihrem Eingang, um sie anschließend zu verarbeiten). Dieser Ansatz hat zwei Nachteile. 1. Nachteil: Im Gegensatz zu ereignisbasierten Fenstern in den meisten Systemen zur Batchverarbeitung, die den Ereigniszeitpunkt exakt wiedergeben, spiegeln Fenster mit der tatsächlichen Zeit nur den Zeitpunkt des Dateneingangs im System wieder. In stabilen System ist das wahrscheinlich eine recht genaue Schätzung der Ereigniszeitfenster, aber es kann nicht garantiert werden, und wenn Daten durch einen großen Satz an heterogenen Prozessen (z. B. ein verteilter Satz an Web-Frontends) generiert werden, ist es wahrscheinlich, dass der Programmierer in Situationen gerät, in denen große Datenmengen in einer Reihenfolge auftreten, die nicht mit der eigentlichen Reihenfolge der Ereigniszeiten übereinstimmen. Daher entwickelt sich das Streaming-System des Programmierers zu einer Schätzung mit niedriger Latenz, die durch ein Batchsystem gesichert werden muss, um präzise Ergebnisse zu liefern. Der zweite Nachteil zeigt sich darin, dass die auf die Daten angewendete Fensterfunktion für alle Daten identisch ist. Daher hat der Programmierer keine Möglichkeit, benutzerdefinierte Fenster für Teilmengen der Daten zu generieren, z. B. für Sitzungen pro Benutzer, die Aktivitätsspitzen pro Benutzer erfassen. Daher kann der Programmierer lediglich die Anwendungsfälle unterstützen, die der Programmierer in Batches verwendet (??).
• MillWheel (und jetzt WindMill, das Datenfluss-Streaming-Backend), das ein Framework zum Erstellen von Datenverarbeitungsanwendungen mit niedriger Latenz darstellt, scheint das einzige Streamingsystem ohne die vorher genannten Beschränkungen zu sein, basierend auf seinen strikten Konsistenzgarantien und den leistungsstarken APIs (Application Programming Interface). Dank der APIs von MillWheel kann der Programmierer Daten basierend auf der Ereigniszeit beliebig Puffern und Ergebnisse ausgeben, wann er es für sinnvoll hält, einschließlich in den Zeiten nach der tatsächlichen Zeiten wie auf anderen Systemen, aber auch auf Daten-gestützte Weise (z. B. Empfang eines Interpunktionsdatensatzes) oder nachdem ein System davon ausgegangen ist, dass alle bis zu einem bestimmten Zeitpunkt eingegangene Daten empfangen wurden (Grenzwerte/Mauszeiger). Der Programmierer kann ein System zur Verarbeitung von Datenströmen mit MillWheel erstellen, mit dem exakte Ergebnisse berechnet werden und das Batchsystem vollständig ersetzt wird, mit dem dieselbe Ausgabe, jedoch mit deutlich geringerer Latenz generiert wird.
• Der große Nachteil der MillWheel-API besteht in ihrer niedrigen Latenz. Sie stellt alle richtigen Bausteine bereit, abstrahiert sie aber nicht auf eine Weise, die es einem Programmierer erleichtert, neue Berechnungen zu schreiben oder vorhandene Bibliotheken zum Erstellen neuer Berechnungen zu verfassen. Flume ist ein verteilter, zuverlässiger und verfügbarer Dienst für effizientes Sammeln, Aggregieren und Verschieben großer Datenprotokolle. Flume weist eine einfache und flexible Architektur auf, die auf Datenströmen basiert. Zusätzlich funktioniert die Flume-Architektur auf einer deutlichen höheren Architektur als die MillWheel-Architektur, wodurch es deutlich einfacher ist, rechnerische Bausteine in leistungsfähige und dennoch verständliche Ergebnisse zu verknüpfen und zu gestalten. Die Batch-Flume-API passt nicht wirklich gut zum Streaming-Paradigma, da sie nicht weiß, wie nicht gebundene Datenströme zur Verarbeitung aufgeteilt werden sollen. Daher werden APIs benötigt, die ungebundene Datenströme (und die sie unterstützende, zugrundeliegende Architektur) zur Verarbeitung aufteilen.
• Bezugnehmend auf 1A und 1B in einigen Implementierungen umfasst ein System zur Berechnung von Datenströmen 100 eine Aggregation API 200, eine Fenster-API 300 und Trigger API 400, wobei sich jede API auf einen separaten Abschnitt des Prozesses zur Berechnung von Datenströmen konzentriert.
• Die Aggregations-API 200 konzentriert sich darauf, was der Programmierer berechnet, zum Beispiel eine Summe oder eine Liste von oberen N-Werten. Die Fenster-API 300 konzentriert sich darauf, wann (in der Ereigniszeit) der Programmierer sich entscheidet, den ungebundenen Datenstrom 10 aufzuteilen (z. B. fixierte Fenster 330 oder Sitzungen 350 (3)). Die Trigger API 400 konzentrieren sich darauf, wann (in der Verarbeitungszeit) der Programmierer sich entscheidet, die aggregierten Ergebnisse 20 für ein angegebenes Datenfenster 10 auszugeben.
• Die Aggregations-API 200 entspricht im Wesentlichen der Batch-API, die bereits in Flume enthalten ist. Der Programmierer beschließt, welche Berechnung mit dem Dateneingang 10 vorzunehmen ist, und generiert ein Ergebnis 20 in Reaktion darauf. Die Fenster-API 300 ermöglicht es dem Programmierer festzulegen, in welches Fenster ein angegebenes Datum (von den eingegebenen Daten 10) fällt. Wenn Daten 10 darüber hinaus anhand eines Schlüssels (z. B. anhand eines Benutzers) gruppiert werden, macht es die Fenster-API 300 dem Programmierer darüber hinaus möglich, Fenster zusammenzuführen, wodurch der Programmierer dynamische, datengesteuerte Fenster wie Sitzungen erstellen kann. Mit der Trigger-API 400 kann der Programmierer definieren, wann die Aggregatergebnisse 20 für ein Fenster ausgegeben werden. Beispiele: Wenn der Grenzwert das Ende das Fensters erreicht (das vorschriftsmäßig zeitbasierte Aggregationsmodell in MillWheel); jede N-Sekunde einer tatsächlichen Zeit (z. B. für ein System, das eher auf Aktualität als auch Vollständigkeit der Ergebnisse achtet 20); nach Eingang eines Interpunktionsdatensatzes, der das Fenster beendet; jeder Schwellenwert der Datensätze; nach beliebiger Entscheidung der Benutzerlogik den Trigger zu bedienen; oder eine beliebige Kombination aus konkreten Trigger (z. B. anfänglich, wenn der Grenzwert das Ende des Fensters erreicht, danach jede Minute, wenn späte Daten 20 nach dem Grenzwert eingehen, wobei ermöglicht wird, dass Daten 20 danach aktualisiert oder geändert werden).
• Was Verständlichkeit angeht, stellt das System zur Berechnung von Datenströmen 100 Implementierungsklarheit bereit, denn wenn eine Funktion für eine der drei APIs 200, 300 oder 400 implementiert wird, konzentriert sich der Programmierer einfach auf die spezifische, vorliegende Aufgabe (Aggregation, Fenster- oder Triggerfunktion), was eine Verbesserung im Verhältnis zum vorherigen System wie MillWheel (und anderen Systemen) darstellt, in denen der Programmierer die drei APIs zusammenführen muss, was noch komplexere Codes zum Ergebnis hat, die schwerer zu lesen und zu verwalten sind. Das System zum Berechnen von Datenströmen 100 kann auf einer Hardware zur Datenverarbeitung 710 (7) oder auf einem Rechengerät 700 (7) ausgeführt werden. Das System zum Berechnen von Datenströmen 100 bietet eine Funktion zum Zusammenstellen, da der Programmierer Funktionen aus den drei APIs 200, 300, 400 mischen und abgleichen kann, um den präzisen Berechnungstyp zu erhalten, den er benötigt. Eine Aggregatfunktion 210 zum Berechnen einer Summe kann mit einer Fensterfunktion 310 verwendet werden, um Sitzungen zu erstellen, sowie eine Trigger-Funktion 410 zum Erzeugen von Ergebnissen 20, wenn der Grenzwert das Ende des Fensters erreicht. Dieselbe Aggregatfunktion 210 kann zum Berechnen von Summen über fixierte Zeitfenster verwendet werden, von denen jedes zehn Datensätze enthält, indem die Fenster- und Trigger-Funktionen 310, 410 einfach geändert werden. Daher ermöglicht es, dass Berechnungssystem 100 (das im Batch-Modus ausgeführt wird) einem Programmierer, komplexe und dennoch verständliche und verwaltbare Systeme zu erstellen, mit denen die Ergebnisse 20 präzise berechnet werden, die der Programmierer wünscht. Daher kann der Programmierer einen Code mithilfe des Systems zum Berechnen von Datenströmen 100 schreiben und dem System 100 ermöglichen, im Streaming-Modus ausgeführt zu werden, um Ergebnisse mit niedriger Latenz zu erreichen, oder im Batch-Modus für massive Abgleiche oder es eine einmalige Berechnung durchgeführt werden. Daher stellt das System 100 mehrere Vorteile zur Verfügung, einschließlich, aber nicht beschränkt auf die Zerlegung der Datenstrom-Berechnung in drei Achsen in was (Aggregation API 200), wann in der Ereigniszeit (Fenster-API 300) und warm (Trigger-API 400) mit zugehörigen APIs und (nicht trivialen) Implementierungen und der Vereinheitlichung von Batch- und Streaming-Semantik unter einem gemeinsamen Schirm.
• Fenster-API 300:
• Bezugnehmend auf 2, die Fenster-API 300 gruppiert Streaming-Daten 10 festgelegte Fenster 22 (fixierte Fenster 330, Sitzungen 350 und Segmentierungsfenster 340 (3)) für weitere Verarbeitung und Aggregation. Die Fenster-API 300 kann auch Streaming-Daten 10 in benutzerdefinierte Fenster gruppieren, die anhand von Funktionspaaren definiert sind. Die Funktionspaare können (1) das Zuweisen von Fenstern zu einem angegebenen Element für einen Satz an Fenstern umfassen; und (2) Fenster zusammenführen, um eine angegebene Teilmenge an Fenstern zur Gruppierungszeit optional zusammenzuführen. Fenster werden segmentieren einen Datensatz 10 in festgelegte Komponenten, die als Gruppe verarbeitet werden. Wenn ungebundene Daten 10 behandelt werden, ist die Fensterfunktion für einige Operationen (um festgelegte Grenzen in den meisten Formen der Gruppierung zu trennen) erforderlich und für andere nicht (Filtern, Zuordnen, innere Verknüpfungen usw.). Für ungebundene Daten ist die Fenster-Funktion grundsätzlich optional, auch wenn sie in vielen Situationen semantisch nützlich ist (z. B. Abgleich großer Updates auf Abschnitte einer zuvor berechneten ungebundenen Datenquelle). Die Fenster-Funktion ist grundsätzlich immer zeitbasiert; während zahlreiche Systeme tupelbasierte Fensterfunktion unterstützen, ist dies hier grundsätzlich zeitbasierte Fensterfunktion über eine logische Zeitdomäne, in der Elemente angeordnet sind, damit sich ihre logischen Zeitstempel sukzessive steigern. Fenster können entweder ausgerichtet sein, d. h. auf alle Daten für das betreffende Zeitfenster angewendet sein, oder nicht ausgerichtet, d. h. nur auf spezifische Teilmengen der Daten (z. B. pro Schlüssel) für das angegebene Zeitfenster sein. 3 hebt drei der wichtigsten Typen an Fenstern hervor, die beim Abhandeln mit ungebundenen Daten auftreten.
• Fixierte Fenster 330 (manchmal auch rollierendes Fenster genannt) werden nach einer statischen Fenstergröße definiert, z. B. Stunden- oder Tagesfenster. Sie sind im Allgemeinen ausgerichtet, d. h. jedes Fenster wird auf alle Daten 10 für den entsprechenden Zeitraum angewendet. Um den Inhalt des Fensters gleichmäßig über die Zeit zu verteilen, wird ihre Ausrichtung manchmal aufgehoben, indem die Fenster für jeden Schlüssel nach einem Zufallswert verschoben werden.
• Segmentierungsfenter 320 werden nach einer Fenstergröße und einer Segmentierungszeitraum definiert, z. B. Stundenfenster, die jede Minute starten. Diese Periode kann geringer als die Größe sein, das heißt, dass die Fenster überlappen können. Segmentierungsfenster sind normalerweise ebenfalls segmentiert, obwohl das Diagramm angefertigt wurde, um eine Vorstellung von der Segmentierungsbewegung zu liefern, werden alle fünf Fenster auf alle drei Schlüssel im Diagramm angewendet, nicht nur auf Fenster 3. Fixierte Fenster sind wirklich ein Sonderfall von Segmentierungsfenstern, in denen die Größe mit der Dauer übereinstimmt.
• Sitzungen 330 sind Fenster, die einige Aktivitätsperioden für eine Teilmenge an Daten erfassen – hier nach Schlüssel. Normalerweise werden sie nach einer Zeitüberschreitungslücke definiert. Alle Ereignisse, die innerhalb einer Zeitspanne auftreten, die kürze als die Zeitüberschreitung ist, werden als Sitzung gruppiert. Sitzungen sind nicht ausgerichtete Fenster. Beispiel: Fenster 2 gilt nur für Schlüssel 1, Fenster 3 gilt nur für Schlüssel 2 und Fenster 1 und 4 gelten nur für Schlüssel 3.
• Wenn Daten 10 verarbeitet werden, die sich auf Ereignisse in der Zeit beziehen, müssen zwei inhärente Zeitdomänen berücksichtigt werden. Die zwei Domänen von Interesse sind Ereigniszeit und Verarbeitungszeit. Die Ereigniszeit ist die Zeit, zu der das Ereignis tatsächlich aufgetreten ist, d. h. ein Datensatz aus Systemuhrzeiten (für welches System auch immer das Ereignis generiert wurde) zum Zeitpunkt des Auftretens. Verarbeitungszeit ist die Zeit, zu der ein Ereignis zu einem beliebigen Zeitpunkt während der Verarbeitung in der Pipeline beobachtet wurde, das heißt, die aktuelle Zeit entsprechend der Uhrzeit des Systems. Beachten Sie, dass wir keine Mutmaßungen bezüglich der Synchronisation innerhalb eines verteilten Systems anstellen.
• Die Ereigniszeit für ein angegebenes Ereignis ändert sich grundsätzlich niemals. Aber die Verarbeitungszeit ändert sich für jedes Ereignis konstant, da es durch die Pipelines fließt und die Zeit vorangeht. Dies ist ein wichtiger Unterschied, wenn Ereignisse im Kontext gründlich analysiert werden sollen, in dem sie auftreten.
• Währen der Verarbeitung resultieren die realen Verhältnisse im zu verwendenden System (Kommunikationsverzögerungen, Planungsalgorithmen, Pipeline-Serialisierung usw.) zu einer inhärenten und dynamisch sich ändernden Menge an Neigungen zwischen den zwei Domänen. Globale Statusmetriken wie Interpunktionszeichen oder Grenzwerte bieten eine gute Möglichkeit zur Visualisierung dieser Neigung. Für unsere Zwecke betrachten wir etwas wie den MillWheel-Grenzwert, der einige niedrige Grenze (häufig heuristisch eingerichtet) für Ereigniszeiten, die durch die Pipeline verarbeitet wurden. Vollständigkeit ist hier weniger wichtig als Richtigkeit und daher haben Grenzwerte eine geringere Bedeutung. Grenzwerte bieten jedoch einen nützlichen Hinweis darauf, wann es das System für wahrscheinlich hält, dass alle Daten bis zu einem angegebenen Punkt in der Ereigniszeit beobachtet wurden, und daher nicht nur in der Neigungsansicht angezeigt werden, sondern in auch bei der Überwachung des Systemstatus insgesamt sowie bei Entscheidungen zum Fortschritt, für die keine makellose Präzision erforderlich ist, wie grundlegende Richtlinie für die Müllsammlung.
• In einer idealen Welt entspricht die Neigung der Zeitdomäne immer null, und die Verarbeitung von Ereignissen findet im selben Moment statt. Die Realität ist jedoch nicht so günstig, und resultiert häufig in eine Neigung der Zeitdomäne, die nicht gleich null ist. 4 zeigt das Beispiel für die Neigung einer Zeitdomäne, in der die X-Achse die ”Ereigniszeit” und die Y-Achse die ”Verarbeitungszeit” beschreibt. Beginnend um 12:00 Uhr beginnt ein tatsächlicher Grenzwert sich über den idealen Grenzwert hinaus zu neigen, da die Pipeline zurückbleibt, und zurückgeht an den idealen Grenzwert zur Ereigniszeit gegen 12:02, um dann nochmal merklich bis 12:03 zurückzubleiben. Die dynamische Abweichung der Neigung bei Systemen für Datenverarbeitung ist sehr häufig und spielt beim Festlegen der Funktionen eine große Rolle, die für Bereitstellung korrekter und wiederholbarer Ergebnisse wichtig sind.
• Das formale Modell für das System wird erläutert und seine Semantik wird so allgemein gehalten, dass der Standard-Batch, Mikro-Batch und Streaming-Modells zusammengefasst werden, sowie die hybride Streaming- und Batch-Semantik der Lambda Architektur. Für Code-Beispiele verwenden wir eine vereinfachte Variante der Dataflow Java SDK, was an und für sich eine Weiterentwicklung der FlumeJava-API ist.
• Betrachten wir zunächst die primitive Form des klassischen Batch-Modells. Die Dataflow-SDK umfasst zwei Kernformen, die auf den Paaren (Schlüssel, Wert) operieren, die durch die Systeme ParDo und GroupByKey fließen.
• ParDo ist für generische parallele Verarbeitung. Jedes zu verarbeitende Element (das an sich eine finite Sammlung sein kann) wird einer benutzerdefinierten Funktion bereitgestellt (mit der Bezeichnung DoFn im Datenfluss), die null oder mehr Ausgabeelemente pro Eingang ergibt. Stellen Sie sich beispielsweise eine Operation vor, bei der alle Präfixe des Eingangsschlüssels erweitert werden, wodurch der Wert verdoppelt wird:

  
• GroupByKey ist für die Schlüsselgruppierung (Schlüssel, Wert) von Paaren. Wie in der Beispieloperation:

  
• Die Operation ParDo arbeitet elementweise für jedes Eingangselement und übersetzt folglich ganz natürlich in ungebundene Daten. Die Operation GroupByKey andererseits sammelt alle Daten für einen angegebenen Schlüssel, bevor diese zur Reduktion gesendet werden. Wenn die Eingangsquelle ungebunden ist, können wir nicht herausfinden, wann sie endet. Die allgemeine Lösung für dieses Problem besteht darin, die Daten in Fenster einzugeben.
• Systeme, die Gruppierung unterstützen, definieren ihre GroupByKey-Operation normalerweise in ein GroupByKeyAnd-Fenster um. Unser wichtigster Beitrag besteht hier darin, nicht ausgerichtete Fenster zu unterstützen, für die zwei Schlüsseleinblicke vorhanden sind. Erstens ist es einfacher, aus der Perspektive des Modells alle Fensterstrategien nicht ausgerichtet zu behandeln, und zu ermöglichen, dass die zugrundeliegenden Implementierungen Optimierungen anwenden, die für ausgerichtete Fälle relevant sind, falls zutreffend. Zweitens können Fenster in zwei, miteinander verbundene Operationen unterteilt werden:
• Festlegen<Fenster>Fenster zuweisen (T-Datum), womit das Element zu null oder mehr Fenstern zugewiesen wird.
• Festlegen<Fenster>Fenster zusammenführen(Fenster<Fenster> festlegen), wodurch Fenster zur Gruppierungszeit zusammengeführt werden. Auf diese Weise können datengesteuerte Fenster mit der Zeit beim Eingang von Daten erstellt und zusammen gruppiert werden.
• Für jede angegebene Fensterstrategie sind die beiden Operationen eng miteinander verknüpft. Für das Segmentieren von Fensteranforderungen ist das Segmentieren der Zusammenführung von Fenstern erforderlich und für das Zuweisen von Sitzungsfenstern ist das Zusammenführen von Sitzungsfenstern erforderlich usw.
• Hinweis: Um ein Fenster für Ereigniszeit nativ zu unterstützen, leiten wir jetzt vier Tupel (Schlüssel, Wert, Ereigniszeit, Fenster) weiter anstatt Paare (Schlüssel, Wert) durch das System. Dem System werden Zeitstempel für Ereigniszeit bereitgestellt (die auch zu jedem Zeitpunkt in der Pipeline geändert werden können) und werden zunächst einem standardmäßigen globalen Fenster zugewiesen. Dabei wird die gesamte Ereigniszeit abgedeckt und Semantik bereitgestellt, um mit allen Standardwerte im Standard-Batchmodell übereinzustimmen.
• Aus Perspektive des Systems wird bei der Fensterzuweisung eine neue Kopie des Elements in jedem der Fenster erstellt, dem es zugewiesen wurde. Beispiel: Betrachten Sie einen Datensatz mit Fensterfunktion, indem Sie Fenster mit einer Breite von zwei Minuten und Fenster mit einer Breite von einer Minute wie nachfolgend segmentieren (der Kürze halber: Zeitstempel werden im HH:MM-Format angegeben).
• 
• In diesem Fall wird jeder der beiden (Schlüssel, Wert) Paare verdoppelt, um in beiden Fenstern vorhanden zu sein, die in den Zeitstempel des Elements überlappen. Da Fenster direkt mit den Elementen verknüpft sind, zu denen sie gehören, können Fenster an jeder Stelle in der Pipeline zugewiesen werden, bevor die Gruppierung vorgenommen wird. Das ist deshalb wichtig, da die Gruppierung später innerhalb einer zusammengesetzten Transformierung (z. B. Sum.integersPerKey)) vorgenommen werden kann.
• Fenster werden im Rahmen der Operation GroupByKeyAnd zusammengeführt. Dies lässt sich am besten erklären im Kontext der Beispieloperation für die Zusammenführung von Fenstern in 5. 5 werden Fenstersitzungen 500 (auch als ”Sitzungs-Windowing” bezeichnet) für vier Beispieldatenpunkte verwendet, drei für k1 und einer für k2, da sie nach Sitzung in Fenster unterteilt werden bei einer Zeitüberschreitung von 30 Minuten. Zunächst werden sie durch das System im standardmäßigen globalen Fenster platziert. Bei der Implementierung der Sitzung der Operation Fenster zuweisen (AssignWindows) wird jedes Element in ein einzelnes Fenster platziert, das 30 Minuten über den eigenen Zeitstempel hinausgeht. Dieses Fenster kennzeichnet den Zeitraum, in den spätere Ereignisse fallen können, falls sie als Bestandteil derselben Sitzung gelten. Daher kann die Operation GroupByKeyAndWindow beginnen. Diese Operation besteht aus fünf separaten Operationen:
• Zeitstempel ablegen (DropTimestamps): Legt Zeitstempel für Elemente ab, da von hier an nur dieses Fenster relevant ist. Nach Schlüssel gruppieren (GroupByKey): Gruppiert Tupel (Wert, Fenster) nach Schlüssel. Fenster zusammenführen (MergeWindows): Führt den Satz der aktuell gepufferten Fenster für einen Schlüssel zusammen. Die tatsächliche Logik für die Zusammenführung wird anhand der Strategie der Fensterstrategie definiert. In diesem Fall sind es die Fenster für die Überlappung v1 und v4. Daher führt die Strategie für Sitzungsfenster diese in eine einzelne neue und größere Sitzung zusammen (siehe fett markiert). Auch nach Fenster gruppieren (GroupAlsoByWindow): Gruppiert Werte für jeden Schlüssel nach Fenstern. Nach der Zusammenführung im vorherigen Schritt sind v1 und v4 jetzt identische Fenster und werden daher in diesem Schritt gruppiert. Auf Elemente erweitern (ExpandToElements): Erweitert Gruppen nach Schlüssel und nach Fenstern in (Schlüssel, Wert, Ereigniszeit, Fenster) Tupel mit neuen Zeitstempeln pro Fenster. In diesem Beispiel wird der Zeitstempel auf das Ende des Fensters festgelegt, aber jeder Zeitstempel, der größer als oder gleich dem Zeitstempel des frühesten Ereignisses im Fenster ist, ist mit Blick auf die Korrektheit des Grenzwertes gültig.
• In der Praxis kann die Fensterfunktion zum Berechnen von Summen mit Ganzzahlen mit Schlüssel mithilfe des Cloud Dataflow SDK und des Folgenden verwendet werden:
  PCollection<KV<String, Integer>> input = IO.read(...);
  PCollection<KV<String, Integer>> Output = input
  apply(Sum.integersPerKey());
• Ein zweites Beispiel kann durchgeführt werden mithilfe der in Fenster unterteilten Sitzungen mit einer dreißigminütigen Überschreitung in 5, wofür ein einzelner Fensteraufruf verwendet wird, bevor die Summierung gemäß dem nachfolgenden Beispiel imitiert wird.
  PCollection<KV<String, Integer>> input = IO.read(...);
  PCollection<KV<String, Integer>> output = input
  .apply(Window.into(Sessions.withGapDuration(Duration.standardMinutes(30))))
  .apply(Sum.integersPerKey());
• Die Fenster-API 300 unterstützt Cloud Dataflow für den Streaming- und den Batch-Modus. Die Semantik von Fenster-APIS kann ein Fenstermodell auf hoher Ebene umfassen wie, jedoch nicht beschränkt auf ”Window.into”, mit dessen Hilfe Elemente einem Satz aus Fenstern zugewiesen wird, und GroupByKey (Nach Schlüssel gruppieren), wodurch die Fenster auf den Eingabeelementen als sekundäre Schlüssel behandelt und dadurch in Paare (Schlüssel, Fenster) gruppiert werden. Es folgen Beispiele für Fensterfunktionen:
• Hinweis:
• <Datum, Zeitstempel, Fenster festlegen>
• G ist das globale Fenster, GBF ist die globale WindowingFn, [t₁, t₂) ist ein Intervallbehälter, der das Zeitintervall darstellt.
• FixedWindows (Fixierte Fenster):

  
• 
• SlidingWindows (Fenster segmentieren):

  
• Sitzungen:

  
• 
• Häufiger Fall mit SomeUnspecifiedCrazyWindowFn:

  
• Details für Nach Schlüssel und Fenstern gruppieren (GroupByKeyAndWindows):

  
• Unter erneuter Bezugnahme auf 2, die Fenster-API 300 umfasst eine Fensterschnittstelle 320. Die Fensterschnittstelle 320 umfasst eine Funktion zum Festlegen des Zeitstempels 322 und eine Funktion zum Aufrufen des Fensters 324.
• Die Funktion zum Festlegen des Zeitstempels 322 aktualisiert den Zeitstempel im Kontext, bevor das Element ausgegeben wird. Ein Beispiel für die Funktion zum Festlegen des Zeitstempels kann Folgendes 322 umfassen:

  

  
• Es ist sowohl im Streaming- als auch im Batch-Modus hilfreich, die Zeitstempel der Elemente in einer Pcollection (damit wird die unveränderliche, verteilte Sammlung von Elementen dargestellt, die das fundamentale Ziel der Berechnung darstellt) festlegen oder ändern zu können. Im Batch-Modus können Zeitstempel nach Belieben festgelegt werden. Wenn jedoch im Streaming-Modus ein Zeitstempel für ein Ausgabeelement festgelegt wird, das weiter zurück in der Vergangenheit liegt, als der Zeitstempel auf seinem entsprechenden Eingabeelement, kann späte Daten erzeugen (z. B. späte Datenpunkte), die in der restlichen Pipeline u. U. nicht richtig verarbeitet werden.
• Für diese Regel gelten im Streaming-Modus zwei Ausnahmen: Wenn ersten ein DoFn eine statische Grenze für die Menge festlegen kann, um die der Zeitstempel nach hinten versetzt wird, kann der Programmierer den Grenzwert für diesen Wert festlegen und die Daten nach wie vor korrekt verarbeiten; zweitens ist es manchmal wünschenswert, späte Daten zu erzeugen, denn diese können mit Triggern vorsichtig verarbeitet werden. Daher stellt das System 100 zwei vorgeschlagene APIs innerhalb der Funktion zum Festlegen des Zeitstempels 322 bereit, um Zeitstempel zu bearbeiten, die im Streaming-Modus nach hinten versetzt werden:
  
  Option 1 322a: Fordern Sie einen Benutzer dazu auf anzugeben, wie viele Zeitstempel in die Vergangenheit zurückversetzt werden.
  // Gibt die maximale Menge zurück, in der ein Ausgabezeitstempel kleiner als sein
  // Eingabezeitstempel sein kann
  lange DoFn.lateDataHorizon()
  
  Option 2 322b: zwingt Benutzer dazu, OutputTimestampMode festzulegen, wenn outputWithTimestamp im Streaming aufgerufen wird.
  // Allgemein gibt DoFn.getOutputTimestampMode den UNBOUNDED_PAST-Modus
  // zurück, welcher im Kontext DoFnContext.outputWithTimestamp für den
  // Streamingmodus nicht erlaubt ist.
• 
• Die Fensterzugriffsfunktion 324 (z. B. DoFn.ProcessContext.windows()) ist eine Methode für den Zugriff auf Fenster, die jedoch nur wirklich dann Sinn macht, wenn der Zugriff darauf nach einem GroupByKey erfolgt und in diesem Fall ist dann jedes Element nur in einem Einzelfenster.
• Die Fenster-API 300 verwendet Trigger zum Bearbeiten später Daten. Ohne Trigger verwendet die Fenster-API 300 zwei in Frage kommende Methoden zum Verarbeiten später Daten. Die Fenster-API 300 kann späte Daten ablegen, die nicht in das korrekte Fenster gruppiert werden, oder die Fenster-API 300 kann es möglich machen, dass späte Daten in der Ausgabe von GroupByKeyAndWindows doppelte Fenster erstellen. Entweder wählt die Fenster-API 300 eine der Optionen aus, oder sie macht es möglich, dass die Optionen auf einer beliebigen Ebene der Pipeline oder bei der Fenstertransformierung (resultiert im Wesentlichen in einer schwachen Einschätzung der Teilmenge von Triggern) konfiguriert werden können.
• Eifer von Fenster zusammenführen (MergeWindows):
• In einigen Beispielen kann es sich als schwierig erweisen, Fensterfunktionen als plangesteuert festzulegen. Stattdessen kann das System 100 mengenmäßig präzise festlegen, wann eine Fensterfunktion plangesteuert ist. WindowingFn ist dann plangesteuert, wenn ein Fenster zur Ausgabe bereit ist. Jedes für die Zusammenführung vorgesehene Fenster muss bereits bekannt sein und es muss mit allen Fenstern zusammengeführt werden.
• In einigen Implementierungen unterstützt das System 100 Batches über zufällige Wiedergabe. In anderen Beispielen verarbeitet das System 100 alle KVs für einen angegebenen Schlüssel auf demselben Arbeiter im Anschluss an die logische zeitliche Reihenfolge des Elements. Anschließend kann der Arbeiter den aktuellen Streaming-Code nutzen und die Daten verarbeiten, als stammten sie aus dem Streaming. Das System 100 führt folgende Schritte durch, um das Batch durch zufällige Wiedergabe zu unterstützen: 1) ShuffleSink codiert den Zeitstempel und die Fenster in ShuffleEntry.value und verwendet den Zeitstempel als die Schlüssel (Sortierschlüssel). 2) Die Option „SortedShuffleSource erstellen” liest alle KVs für denselben Schlüssel und gibt das Ergebnis auf der folgenden Schnittstelle zurück:
  SourceIterator<Reiterable>KV>> iterator(ShuffleEntryReader reader)
  long SortedShuffleSourceIterator.ValuesIterator.getTimestamp();
  Collection<BoundedWindow>
  SortedShuffleSourceIterator.ValuesIterator.getWindows();
  AUFGABE: Wiederverwendung des Codes in GroupingShuffleSource.
• Folgendes ist ein Beispiel-Benutzercode, der durch das System 100 ausgeführt werden kann:

  

  
• Die Fähigkeit, nicht ausgerichtete Ereigniszeitfenster zu erstellen, stellt eine Verbesserung dar. Dennoch müssen zwei weitere Defizite erörtert werden. 1. Das System 100 muss Fenster unterstützen, die auf Tupel und Verarbeitungszeit basieren. Andernfalls entwickelt sich die Semantik der Fensterfunktion relativ zu anderen vorhandenen Systemen zurück. 2. Das System 100 muss darüber informiert sein, warm die Ergebnisse 20 für ein Fenster ausgegeben werden müssen. Da die mehrere Datenpunkte umfassenden Daten 10 eine nicht sortiert sind hinsichtlich der Ereigniszeit, erfordert das System 100.
• Das Problem der Fenster auf Basis von Tupel und Ereigniszeit wird nachfolgend erörtert, nachdem das System 100 eine Lösung für das Problem der Fenstervollständigkeit entwickelt hat. In diesem Zusammenhang kann einen ersten Schritt hin zur Lösung dieses Problems darin bestehen, dass eine globale Fortschrittsmetrik für die Ereigniszeit verwendet wird, wie beispielsweise Grenzwerte. Grenzwerte wiederum bringen zwei Defizite mit, wenn es um Korrektheit geht.
• Grenzwerte sind häufig zu schnell, d. h., es können späte Daten 10 auftreten, die erst nach dem Grenzwert eingehen. Für viele verteilte Datenquellen ist es sehr schwer, einen vollkommen perfekten Grenzwert für die Ereigniszeit abzuleiten. Daher ist es unmöglich, sich ausschließlich darauf zu verlassen, wenn eine hundertprozentige Genauigkeit für die Ergebnisse 20 der Ausgangsdaten gewünscht wird.
• Zweitens sind Grenzwerte bisweilen zu langsam. Da es sich um eine globale Fortschrittsmetrik handelt, kann der Grenzwert für die gesamte Pipeline durch ein einzelnes langsames Datum zurückgehalten werden. Sogar bei einwandfreien Pipelines mit geringer Neigungsvariabilität bei der Ereigniszeit, kann die Basislinie der Neigung immer noch mehrere Minuten oder mehr betragen, abhängig von der Eingabequelle. Folglich kann sich aus der Verwendung von Grenzwerten als einzigem Signal für die Ausgabe von Fensterergebnissen 20 eine höhere Latenz für die Gesamtergebnisse ergeben, als bei einer vergleichbaren Pipeline der Lambda-Architektur.
• Aus diesen Gründen postuliert das System 100, dass Grenzwerte allein ungenügend sind. Ein hilfreicher Einblick in das Problem der Vollständigkeit bietet die Erkenntnis, dass die Lambda-Architektur das Problem wirksam umgeht: Die Architektur löst das Problem nicht, indem sie korrekte Antworten irgendwie schneller bietet, sie bietet einfach die beste Schätzung mit geringer Latenz eines Ergebnisses an, das die Streaming-Pipeline bieten kann, mit dem Versprechen eventueller Konsistenz und Korrektheit, sobald die Batch-Pipeline ausgeführt wird. Die Ausgabe aus dem Batch-Job ist nur korrekt, wenn Eingabedaten 10 bis zum Zeit vollständig sind, zu dem der Batch-Job ausgeführt wird. Wenn sich Daten 10 mit der Zeit entwickeln, müssen diese entdeckt und die Batch-Jobs erneut ausgeführt werden. Innerhalb der einzelnen Pipeline (unabhängig von der Ausführungs-Engine) benötigt das System 100 dann eine Funktion, um mehrere Antworten (oder Bereiche) für ein beliebiges angegebenes Fenster bereitzustellen. Diese Funktion umfasst Trigger oder Triggerzeiten, über die angegeben werden kann, wann die Ausgabeergebnisse 20 für ein angegebenes Fenster ausgegeben werden können.
• Trigger sind Mechanismen, die mit denen die Produktion von GroupByKeyAndWindow-Ergebnissen 20 als Reaktion auf interne oder externe Signale angeregt wird. Sie ergänzen die Fensterfunktion insofern, als dass sie jedes Systemverhalten entlang einer abweichenden Zeitachse beeinflussen. Mit der Fensterfunktion wird festgelegt, wann in der Ereigniszeit Daten 10 zur Verarbeitung gruppiert werden. Mit der Trigger-Funktion wird festgelegt, wann in der Verarbeitungszeit die Ergebnisse 20 der Gruppierung als Bereiche ausgegeben werden. Spezielle Trigger, beispielsweise für Grenzwerte nutzen die Ereigniszeit in der von ihnen bereitgestellten Funktionalität, aber ihre Wirkung innerhalb der Pipeline wird nach wie vor entlang der Achse der Verarbeitungszeit umgesetzt.
• In einigen Implementierungen stellt das System 100 vordefinierte Trigger-Implementierungen zum Auslösen der Vollständigkeitsschätzung (z. B. Grenzwerte, einschließlich Prozentwerte, die nützliche Semantik für die Bearbeitung von Nachzüglern in den Ausführungs-Engines des Batch- und des Streaming-Modus, wenn die schnelle Verarbeitung eines Mindestprozentsatzes von Eingabedaten 10 wünschenswerter ist, als die Verarbeitung der letzten Stücke davon) an Stellen in der Verarbeitungszeit und als Reaktion auf eingehende Daten 10 (Zahlen, Byte, Datenpunktion, Musterübereinstimmung usw.). In einigen Beispielen unterstützt das System 100 das Zusammenfassen von Trigger in logische Kombinationen (und, oder usw.), Schleifen, Sequenzen und andere ähnliche Konstruktionen. Zusätzlich können Benutzer ihre eigenen Trigger definieren und hierfür die zugrundeliegende Stammfunktion der Laufzeit der Ausführung (z. B. Timer für Grenzwerte, Timer für die Verarbeitungszeit, Dateneingang, unterstützte Zusammenfassung) verwenden sowie alle anderen relevanten Signale (Dateneingabeaufforderungen, externe Fortschrittsmetriken, RPC-Abschlussrückrufe usw.).
• Zusätzlich dazu, dass gesteuert wird, wann das System 100 Ergebnisse 20 zurückgibt, stellt die Trigger-API 400 eine Möglichkeit bereit, anhand derer gesteuert wird, wie viele Bereiche für dasselbe Fenster sich über drei verschiedene Detailmodi aufeinander beziehen:
• Im ersten Detailmodus wird die Verwerfung vorgenommen: Nach Betätigen der Trigger-Funktion werden Fensterinhalte verworfen und spätere Ergebnisse 20 haben keinen Bezug zu den vorherigen Ergebnissen 20. Dieser Modus ist in den Fällen hilfreich, in denen spätere Benutzer der Daten (innerhalb oder außerhalb der Pipeline) davon ausgehen, dass die Werte verschiedener Triggerauslöser unabhängig sind (z. B., wenn sie in ein System eingegeben werden, das eine Summe der eingegebenen Werte generiert). Dieser Modus ist auch dann besonders effizient, wenn die Menge der Daten 20 gepuffert werden soll. Allerdings ist das Delta der Effizienz häufig minimal, wenn der Modus für assoziative und kommutative Operationen eingesetzt werden soll, die als Dataflow Combiner gestaltet werden können. Für den Anwendungsfall der Videositzung ist dies nicht ausreichend, das es nicht praktisch ist, von späteren Verbrauchern der Daten 10 zu verlangen, Teilsitzungen zusammenzufassen.
• Im zweiten Detailmodus wird die Akkumulation vorgenommen: Nach Betätigen der Trigger-Funktion werden Fensterinhalte im permanenten Status intakt gelassen und späte Ergebnisse 20 werden eine verfeinerte Ausgabe der vorherigen Ergebnisse 20. Dies ist hilfreich, wenn spätere Benutzer darum rechnen, ältere Werte durch neue zu überschreiben, wenn sie mehrere Ergebnisse 20 für dasselbe Fenster erhalten. Dieser Modus wird in Systemen der Lambda-Architektur effektiv genutzt, wo die Streaming-Pipeline Ergebnisse mit niedriger Latenz erzeugt, die dann in der Zukunft durch Ergebnisse 20 aus der Batch-Pipeline überschritten werden. Dies könnte sich für Videositzungen als ausreichend erweisen, wenn das System 100 einfach Sitzungen berechnet und diese dann umgehend in eine Ausgabequelle schreibt, die Updates unterstützt (z. B. eine Datenbank oder einen Schlüssel-/Wertspeicher).
• Der dritte Verfeinerungsmodus umfasst Akkumulation und Rücknahme: Nach Betätigen des Triggers wird zusätzlich zur Akkumulations-Semantik eine Kopie des ausgegebenen Werts im permanenten Status gespeichert. Wenn das Fenster in der Zukunft erneut ausgelöst wird, wird zuerst eine Rücknahme des vorherigen Werts ausgelöst, gefolgt vom neuen Wert als normalem Datum. Für die einfache Implementierung der Rücknahmeverarbeitung sind plangesteuerte Operationen erforderlich. Es können aber auch nicht plangesteuerte Operationen mit höherer Komplexität und höheren Kosten unterstützt werden. Wir kennen Anwendungsfälle, auf die das zutrifft, beispielsweise Wahrscheinlichkeitsmodelle. Rücknahmen sind in Pipelines mit mehreren GroupByKeyAnd-Window-Operationen erforderlich, da mehrere Ergebnisse, die durch ein einzelnes Fenster über nachfolgende Triggerauslöser generiert wurden, auf separaten Schlüsseln enden können, wenn sie später gruppiert werden. In diesem Fall generiert die zweite Gruppierungsoperation falsche Ergebnisse 20 für jene Schlüssel, sofern über eine Rücknahme informiert wird, dass die Auswirkungen Originalausgabe rückgängig gemacht werden sollen. Dataflow Combiner-Operationen, die ebenfalls rückgängig gemacht werden können, können Rücknahmen wirksam über eine nicht kombinierte Methode unterstützen. Dieser Modus ist für Videositzungen ideal. Wenn das System 100 Aggregationen nach der erstellten Sitzung vornimmt, die von den Eigenschaften der eigentlichen Sitzung abhängen, indem beispielsweise unbeliebte Anzeigen (zum Beispiel jene, die in der Mehrzahl der Sitzungen kürzer als fünf Sekunden lang angesehen werden) erkannt werden, können die ersten Ergebnisse 20 als Eingaben für ungültig erklärt werden, die sich mit der Zeit entwickeln, z. B. als signifikante Anzahl der mobilen Offline-Besucher, die online zurückkommen und Sitzungsdaten hochladen. Rücknahmen bieten uns eine Möglichkeit, uns an diese Änderungstypen in komplexen Pipelines mit mehreren seriellen Gruppenphasen anzupassen. Nachfolgend werden einige spezifische Implementierungen des Trigger-Systems besprochen.
• Die Trigger-API 400 bietet eine strukturierte und zusammenfassbare Möglichkeit, um auszudrücken, wann (zu welchem Verarbeitungszeitpunkt) die Ergebnisse 20 einer Aggregation innerhalb des Datenflow/Streaming-Ablaufs ausgegeben werden sollten. Die Trigger-APIs 400 funktionieren in Verbindung mit der Aggregations-API 200 und der Fenster-API 300, die es jeweils ermöglichen auszudrücken, wie die Ergebnisse 20 einer Aggregation aussehen und wo (in einer Ereigniszeit) die Aggregationen ausgeführt werden. Die Trigger-APIs 400 richten sich an eine Reihe von Defiziten in den vorhandenen Streaming-Ablaufs-/Dataflow-APIs relativ zur standardmäßigen MillWheel. Einige dieser Defizite:
• • Späte Daten – Benutzer von Streaming Flume können späte Daten nicht verwalten (d. h., Daten, die nach dem Grenzwert eingehen). Aktuelle Systeme legen das späte Datum einfach ab, was nicht einmal kurzfristig praktisch ist.
• • Spekulative Daten – Einige MillWheel-Kunden führen spekulative oder partielle Aggregationen manuell aus und verwenden dazu Grenzwerte oder andere datenbasierte Heuristiken, was von Streaming Flume derzeit nicht unterstützt wird.
• • Aggregationen zur tatsächlichen Zeit – Zahlreiche MillWheel-Pipelines berücksichtigen Grenzwerte nicht, bieten aber dennoch eine Art von periodisch in Fenstern angelegte Aggregation. Die Timer für tatsächliche Zeiten bieten reguläre Updates, die alle bisher eingegangenen Daten enthalten, ungeachtet dessen, wie schnell oder langsam die restliche Pipeline aktuell arbeitet.
• • Datengesteuerte Aggregationen – Eine weitere Klasse von Aggregationen, für die keine Grenzwerte erforderlich sind, ist jene, die durch die eigentlichen Daten gesteuert werden, z. B. Hash-Verknüpfungen oder Byte-getrennte Aggregationen. Viele dieser Muster werden mithilfe der vorhandenen Streaming Flume-APIs (über benutzerdefinierte Fensterfunktionen und/oder die Status-API) unterstützt, aber ist möglicherweise wünschenswert, sie mit einer allgemeinen Trigger-API für Aggregation zu integrieren, da sich auf diese Weise die Möglichkeit bietet, datengesteuerte Trigger mit anderen Triggern zusammenzufassen (z. B. eine Hash-Verknüpfung, die nach einer realen Verzögerung einer Zeitüberschreitung erlebt; aktuell können Sie nur eine Verzögerung der Streaming-Zeit verwenden).
• Grenzwerte: MillWheels bietet Grenzwerte (oder Cursor), um die Vollständigkeit von Daten in der Streaming-Pipeline einzuschätzen. Standardmäßig schätzen Grenzwerte den Zeitpunkt ein, zu dem alle Daten für einen gewissen Stream eingegangen sind oder verarbeitet wurden. Auf diese Weise können Aggregationen mit einer zeitlichen Grenze erst dann durchgeführt werden, wenn das System 100 davon überzeugt ist, alle relevanten Daten gesehen zu haben.
• Grenzwerte werden zum Zeitpunkt der Dateneingabe (d. h., beim Dateneingang) eingeführt und dann weitergegeben. Für viele Datenquellen ist unmöglich, einen vollständig präzisen Grenzwert anzugeben. Wenn Sie beispielsweise Protokolldateien betrachten, stellen Sie fest, dass ein Protokoll-Injektor einen Grenzwert auf Basis des Satzes von Protokolldateien erstellen kann, die der Protokoll-Injektor in jedem angegebenen Moment scannt. Wenn aber ein Protokollspeicher für eine längere Zeit verzögert wird, können neue Protokolldateien nicht mehr eingehen, nachdem der Injektor seinen Grenzwert nach vorne verschoben hat. Die Daten in diesen späten Protokolldateien sind nun spät. Spätere Berechnungen müssen dann noch zusätzlich darüber entscheiden, auf welche Weise sie späte Daten bearbeiten. In einigen Fällen können sie in vorhandene Ergebnisse integriert werden. In anderen Fällen ist es am besten, die späten Daten einfach abzulegen. MillWheel stellt kein strukturiertes Framework zur Bearbeitung später Daten bereit, lediglich die minimale Infrastruktur zu ihrer Erkennung. Streaming Flume bietet derzeit keine Methode für die Interaktion mit späten Daten; Streaming Date legt sie einfach ab.
• Grenzwert in Prozent: MillWheel unterstützt auch Grenzwerte in Prozenten, wodurch Sie einen Grenzwert erhalten, anhand dessen Sie die Zeitdauer einschätzen, mit der eine bestimmte Teilmenge an Daten (z. B. 95%) durch das System 100 verarbeitet wurden. Das System 100 verwendet auch Grenzwerte in Prozent anstelle des normalen Grenzwerts, um spekulative Ergebnisse anzubieten. Auf diese Weise können Ergebnisse schneller, aber mit etwas geringerer Zuverlässigkeit bereitgestellt werden. Eine vorgegebene Berechnung kann jedoch derzeit nur einen Cursortyp (100% oder einen einzelnen, zellenspezifischen Prozentsatz) verwenden. Aus Perspektive der Konfiguration ist die Bereitstellung eines komplexen und abgestuften Satzes an spekulativen Ergebnissen recht aufwendig und derzeit über zwei Stufen hinausgehend unmöglich.
• Aggregation in tatsächlicher Zeit: Während Grenzwerte die gängigste Methode zum Auslösen von Aggregationen in MillWheel sind, gibt es Fälle, in denen anderer Trigger-Typen praktischer sind. In Fällen, in denen die Pünktlichkeit von Daten von größerer Bedeutung ist als ihre Vollständigkeit, können Timer für die tatsächliche Zeit verwendet werden, um periodische Updates der bisher aggregierten Daten bereitzustellen. Auf diese Weise wird sichergestellt, dass der Programmierer zeitgerechte Updates erhält, sogar angesichts von Verzögerungen des Grenzwerts als Folge des Zurückbleibens kleinerer Datenabschnitte hinter dem Rest.
• Datengesteuerte Aggregation: Darüber hinaus existiert eine ganze Klasse von nicht zeitbasierten Aggregationen. Zu den Beispielen zählen Hash-Verknüpfungen, Aggregationen, die durch eine Anzahl von Datensätzen oder Byte gebunden sind, oder für eine Funktion der Daten ausgelöste Aggregationen (z. B. ein spezifisches Feld für ein Datum mit einem bestimmten Wert).
• Zusammengefasste Aggregation: In einigen Beispiel kommt es häufig vor, dass Sie mehrere Aggregations-Typen zusammenfassen möchten. Häufig weist eine Hash-Verknüpfung eine Zeitüberschreitung auf. In einem solchen Fall kann das aktuelle System 100, Streaming Flume mit Zeitüberschreitungen bei der Streaming-Zeit, aber keine tatsächliche Zeit. In einigen Beispielen möchte der Programmierer eine einzelne Initial-Aggregation empfangen, wenn der Grenzwert 100% erreicht, und dann periodisch (basierend auf dem Grenzwert) aktualisieren, wenn späte Daten eingehen. Spekulative Daten stellen grundsätzlichen anderen Typ der zusammenfassenden Aggregation dar (jeweils einer für die angestrebten Werte des Grenzwerts in Prozent).
• In einigen Beispielen wirft das Problem des Zusammenfassens von Aggregationen (sei es für späte Daten 10, spekulative Daten oder für eine andere benutzerdefinierte Zusammenfassung) die Frage auf Auf welche Weise stellen Sie Verfeinerung der Ergebnisse als Aggregation Ihrer Datensatzänderungen im Laufe der Zeit dar?
• Zum Bearbeiten von Updates für Aggregationen in einer Streaming-Pipeline können mehrere Optionen in Betracht gezogen werden. Option 1: Mehrere Versionen von Aggregationen und Verwaltungsverfahren für diese bereitstellen. Beim Bereitstellen mehrerer Versionen gibt es zwei Modi, die das System 100 unterstützen könnte. In einem ersten Modus integrieren die nachfolgenden Aggregationen alle bisher gesehenen Daten 10. In diesem Fall ersetzen neue Aggregate 20 einfach die alten Aggregate 20. In einem zweiten Modus nehmen nachfolgende Aggregationen 20 nur neue Daten 10 seit der letzten Aggregation 20 auf. In diesem Fall müssen neue Aggregate 20 manuell mit vorherigen Aggregaten 20 kombiniert werden, wenn gewünscht und/oder durchführbar. Die beiden Optionen umfassen Reinigungsdienste mit Vor- und Nachteilen. Die Vorteile umfassen, sind aber nicht beschränkt auf: ausführliche Reinigung der API (verschiedene Versionen des Aggregats haben nach wie vor denselben Typ); der gibt ihre Aggregatlogik einmal an, und das System wendet diese nach Bedarf mehrfach an; da das System für mehrere Versionen von Aggregationen (durch Zeitstempel voneinander unterschieden) mit der Fensterfunktion in Streaming Flume bereitstellt, ist die Erweiterung von Versionen auf eine neue Dimension relativ natürlich: (1A) aktualisierte Aggregate 20 können umgehend ohne zusätzliche Benutzereingriffe verwendet werden, und (1B) es muss kein Aggregatzustand für einen späten Datenhorizont beibehalten werden. Nachteile umfassen (1A): Der Aggregatzustand muss beibehalten werden, bis keine späten Daten mehr erlaubt sind. Bei Protokollquellen wären dies zwei Tage nach der Vergoldung, die zu 100% korrekt sein muss. Die Größe des Status hängt vom Typ der durchgeführten Aggregation ab: Kombinierer: Wenn eine Aggregation mit combineValues ausgeführt wird, muss nur das unmittelbare Datenaggregat (z. B. Summe und Anzahl für die Berechnung eines Mittelwerts) gespeichert werden. Dies ergibt folgende Gesamtgröße des Datenspeichers:
  O(PARTIAL_AGGREGATE_SIZE * NUM_WINDOWS_IN_HORIZON).
• Vollständige Daten: Nichtkombinierende Aggregationen benötigen die Speicherung der gesamten Datenmenge bis zum Ende. Dies ergibt folgende Gesamtgröße des Datenspeichers:
  O(INPUT_SIZE_OVER_HORIZON).
• (1A) Vorherige Aggregate 20 müssen von allen weiteren und späteren kumulativen Aggregationen 20 gelöst werden Dies schafft zusätzlich Arbeit und führt auch heikle Semantiken ein, wenn das neue Aggregat zu einem anderen Schlüssel als das alte verschoben wird. (1B) Um alte Aggregate mit neuen zu kombinieren, muss der Benutzer einige zusätzliche Arbeit investieren.
• Eine weitere Option, Option 2, bietet eine Initial-Aggregation und Zugriff der Initial-Aggregation auf nachfolgende Rohdaten 10 (d. h., ”Deltas”). Diese Option umfasst, ist aber nicht beschränkt auf die folgenden Vorteile: Der Aggregatstatus muss nicht beibehalten werden. Bezüglich der Nachteile: Die API ist komplexer, Aggregat und Delta haben möglicherweise verschiedene Typen. Ist Ihre Ausgabe aus der Operation jetzt ein Paar<Aggregat, Delta>? Oder muss sich der Benutzer durch seine Codepfade kämpfen? Dies beeinträchtigt die Atomarität beträchtlich; der Benutzer muss seine Aggregatlogik einmal für das Initial-Aggregat angeben und dann ein zweites Mal zur Integration von Delta-Updates. Viele Aggregat-Typen unterstützen Updates über Deltas nicht und funktionieren daher mit diesem Schema nicht.
• Angesichts der Vor- und Nachteile stellen die Optionen #1A und #1B Lösungen dar, die das System 100 für die Trigger-Funktion auslösen könnte.
• Um die verschiedenen, oben angesprochenen Anwendungsfälle zu erörtern, ändert das System 100 den Fensteraufruf Window.into, damit Benutzer auch die dominierenden Trigger angeben können, wenn Aggregate 20 ausgegeben werden, sowie auf welche Weise sich nachfolgende Aggregate 20 zu den vorherigen Aggregaten 20 verhalten:
  windowBy(WindowFn, TriggerStrategy);
  Dataflow: Window.into(WindowingStrategy, TriggerStrategy);
• Das Objekt TriggerStrategy ist im Wesentlichen ein Tupel aus benannten Werten:
• 1. Trigger: Diktiert, warm Aggregate 20 ausgegeben werden, z. B. erst bei 100% des Grenzwerts, gefolgt von späten Daten 20 (falls vorhanden) alle 10 tatsächliche Sekunden für mindestens zwei Tage.
• 2. Akkumulations-Modus: Diktiert, ob spätere Aggregate 20 Daten 10 aus den vorherigen Aggregaten 20 oder nicht umfassen (d. h., ob die Inhalte eines Fensters geleert sind, wenn das Fenster ausgelöst wird).
• 3. Inkrementeller Modus: Diktiert, ob Anti-Daten für vorherige Aggregate ausgegeben werden könne, damit inkrementelle Updates späterer Aggregate möglich gemacht werden.
• APIs, Hohe Ebene: Das System 100 bietet eine ausführliche Beschreibung davon, wann Aggregate 20 während der Ausführung der Fensterfunktion innerhalb einer GroupByKey-Operation erzeugt werden sollen, sowie wie viele Versionen eines Aggregats 20 sich zueinander beziehen, und ob inkrementelle Updates über modifizierte windowBy/Window.into-Operationen ausgeführt werden:
  SF: windowBy(WindowFn, TriggerStrategy)
  Dataflow: Window.into(WindowingStrategy, TriggerStrategy)
• Wie oben angemerkt, entspricht TriggerStrategy (Trigger-Strategie) in etwa
  ”Tupel<Trigger, AccumulationMode,IncrementalMode>.
• Ein Trigger ist im Wesentlichen eine DoFn-ähnliche Klasse mit Methoden, die durch das System 100 an speziellen Stellen während der Fenstererstellung aufgerufen werden. Diese Methoden setzen verschiedene Argumente über die in Frage kommenden Fenster und Werte als Eingabe ein, manipulieren möglicherweise permanenten Status und Zeitwerte pro Fenster und pro Trigger und können u. U. Trigger-Signale ausgeben, um anzugeben, wann die Inhalte eines Fensters später ausgegeben werden sollen. Weitere Informationen zur API sowie zum Implementieren von Trigger finden Sie im nachfolgenden Abschnitt zur Implementierung.
• Wie die Fenstertechnik-API 400 sind gewöhnliche Trigger-Implementationen eher selten. Von einer Endbenutzerperspektive aus ist die Bibliothek mit bereits erzeugten Trigger, die wir bereitstellen, interessanter.
• Die Trigger-Bibliothek enthält sowohl einfache als auch gemischte Trigger (obwohl die Unterscheidung der beiden hauptsächlich semantischer Natur ist). Einfache Beispieltrigger enthalten:
• • WatermarkPercentile(float percentile) – Gibt ein Aggregat aus, wenn das bestimmte Wasserzeichenperzentil für das Ende des Fensters erreicht ist, wobei das Perzentil sich im Bereich [0.0, 100.0] befindet. Im Verborgenen wären diese per Wasserzeichen-Timer implementiert. Verspätete Fenster würden per Definition diese Art von Trigger nicht auslösen. AtPeriod(DateTime reference, long period, TimeUnit units, TimeDomain domain)
• – Gibt ein Aggregat für das Fenster am Ende des nächsten Zeitfensters aus, das mit der gegebenen Referenzzeit (Die Referenz kann jede DateTime sein.) unter Nutzung der gegebenen Zeitperiode abgeglichen ist. Wenn wiederholt ausgeführt, erlaubt es, das Periodenaggregat auszugeben, z. B. jede Periodensekunde. TimeDomain kann STREAM_TIME oder WALL_TIME sein. Im Verborgenen wären diese per Wasserzeichen oder Walltime-Timer implementiert. AfterDelay(long delay, TimeUnit units, TimeDomain domain) – Gibt ein Aggregat einer Zeitdauer nach dem ersten Datum aus, zu dem das Fenster auftaucht, z. B. nach Verzögerungssekunden. TimeDomain kann STREAM_TIME oder WALL_TIME sein. Im Verborgenen wären diese per Wasserzeichen oder Walltime-Timer implementiert.
• • AfterBytes(long count) – Gibt ein Aggregat aus, nachdem die Anzahl „count” an Bytes gesichtet wurde.
• • AfterCount(long recordCount) – Gibt ein Aggregat aus, nachdem die Anzahl „recordCount” an Datensätzen gesichtet wurde.
• • Benutzerdefinierter Trigger – Ruft eine vom Benutzer bereitgestellte Implementation der Trigger-Schnittstelle für jeden Datensatz auf.
• 
• Die Trigger AfterBytes und AfterCount oben könnten mithilfe dieser API implementiert werden. Genauso wie Z3s Spekulative Differenzen. Dies stellt essentiell dieselben Semantiken bereit wie ein spezifischer Aufruf von WindowFn.merge, der WindowSet.emit aufruft, um Fenster frühzeitig freizugeben.
• Beispiele von gemischten Trigger enthalten:
• • FirstOf(Trigger... triggers) – Höchstens einem der bereitgestellten Trigger wird die Auslösung erlaubt.
• • SequenceOf(Trigger... triggers) – Die spezifizierten Trigger werden der Reihe nach ausgelöst.
• • Repeat(Trigger trigger) – Nach der Auslösung kann sich der spezifizierte Trigger zurücksetzen und erneut auslösen, ohne Limitierung.
• • RepeatUntil(Trigger trigger, Trigger until) – Wie bei der Funktion Repeat, außer, dass die Wiederholung endet, sobald der Trigger „until” auslöst.
• • RepeatCount(Trigger trigger, int count) – Wie bei der Funktion Repeat, außer, dass der Trigger stoppt, sobald er „count” Male ausgelöst wurde.
• Mit diesen Primitiven kann man eine Anzahl nützlicher Aggregationsmuster ausdrücken. Zum Beispiel:
• • Gebe 90% und 100% des Wasserzeichen-Perzentilaggregats aus, gefolgt von verspäteten Datenaggregaten zu jeder Walltime-Stunde des Timers (wenn sie existieren), bis zwei Tage von Daten verarbeitet wurden:
  
  Führe wiederholte Hash-Verbindungen aus, jede mit einem Walltime-Timeout von einer Stunde. Dies würde vermutlich mit Global WindowFn/GlobalWindow verwendet werden, aber nicht notwendigerweise: new Repeat( new FirstOf( new HashJoinTrigger(), // Implementiert die Hashverbindungs-Logik als Trigger. new AfterDelay(1, TimeUnit.HOURS, TimeDomain.WALL_TIME))); Gebe ein globales Aggregat (z. B. eine globale Zählung aller über den Zeitraum hinweg gesehenen Datensätze) täglich um 08:00 Uhr aus. Dieser Nutzungsfall ist eine der Motivationen für die Streaming-Flume-Timer-API. Durch die Windowing-Trigger kann die Timer-API veralten (und wir setzen sie momentan keinem Datenfluss aus).
• 
• Die Werteliste AccumulationMode kann einen von vier möglichen Werten haben:
• • CLEAR_ALWAYS – Sammle niemals Werte über mehrere Trigger-Aufrufe hinweg, ignoriere explizite Sammlungsanfragen von Trigger-Implementationen.
• • CLEAR_BY_DEFAULT – Löschen, außer, die Sammlung wird explizit von einer Trigger-Implementation angefordert.
• • ACCUMULATE_BY_DEFAULT – Sammeln, außer, die Löschung wird explizit von einer Trigger-Implementation angefordert.
• • ACCUMULATE_ALWAYS – Sammle immer Werte über mehrere Trigger-Aufrufe hinweg, ignoriere explizite Löschungsanfragen von Trigger-Implementationen.
• IncrementalMode unterstützt die Werte ENABLED (aktiviert) oder DISABLED (deaktiviert). Falls aktiviert, würde das System die Umkehrung des Effekts vorangegangener Aggregatwerte in Downstream-Aggregationen via Anti-Daten (z. B. Daten, die dafür markiert sind, dazu genutzt zu werden, die Effekte früher ausgegebener Aggregate umzukehren) unterstützen. Dieses Feature ist komplex genug, um seine eigene Dokumentation zu erfordern, und nicht in einer der initialen Datenfluss- oder Flume-Implementationen enthalten.
• Die Kombination von AccumulationMode.ALWAYS und IncrementalMode=true wäre effektiv die obere Option 1A. Während die Kombination von AccumulationMode.NEVER und IncrementalMode=false effektiv die obere Option 1B wäre (Der Standardmodus des Systems).
• Wenn die Ergebnisse von GroupByKey schließlich nach Schlüsseln sortiert sind, können sie mehrere Versionen eines gegebenen Aggregats enthalten. Diese Versionen wären unterscheidbar über ihre Produktionszeitwerte und die Trigger, die sie generiert haben (wie ausführlicher in der Sektion über die systemnahe API weiter unten beschrieben).
• Die Version von windowBy mit einem Parameter wäre veraltet in dem Versuch, den Benutzer zu zwingen, explizit darüber nachzudenken, wann es angemessen ist, seine Aggregationen auszugeben. Während sie verbliebe, würde sie auf eine Weise implementiert werden, dass sie die originalen Semantiken der Ausgabe nur an dem 100%-igen Wasserzeichen bereitstellt, während alle verspäteten Daten verworfen werden, z. B.:
  windowBy(WindowFn, new TriggerStrategy(
  new SequenceOf(new WatermarkPercentile(100)),
  AccumulationMode.NEVER,
  IncrementalMode.DISABLED));
• Processing Context API: Die Standardklassen ExecutionContext/ProcessingContext können einige neue Methoden erhalten, um systemnahe, pro-Wert-Metriken bereitzustellen, um über mehrere Versionen von Aggregaten zu entscheiden.
• • Integer ExecutionContext.getWatermarkPercentile() – Gibt das Wasserzeichenperzentil für jeden Wert im System an. Dies ist ein Integer-Wert im Bereich [0, 100] oder Null, falls der Wert nach dem 100%-igen Ausgabewasserzeichen erzeugt wurde (d. h. der Wert war verspätet). Per Definition wird das Wasserzeichenperzentil der Teil der Bereiche mit Wasserzeichenwerten >= der Ereigniszeit des gegebenen Wertes zur Produktionszeit sein. Für das interne MillWheel würde das mit einem Set von vordefinierten perzentilen Wasserzeichen gemacht werden. Für das Cloud-MillWheel kann man dies von einem bereitgestellten Wasserzeichenhistogramm ableiten.
• • long ExecutionContext.getProductionTime() – Gibt die Produktionszeit für den Wert zurück. Kann genutzt werden, um mehrere Version von Aggregaten chronologisch zu unterscheiden.
• • Trigger ExecutionContext.getTrigger() – Gibt den Trigger (falls er existiert) zurück, der den Wert generiert hat. Gibt für nicht-aggregierte Werte Null zurück. Eine Prüfung dieses Wertes würde z. B. erlauben, zu ermitteln, ob ein Datum verspätet war oder nicht.
• • boolean ExecutionContext.isAntiDatum() – True (wahr), falls das Datum ein Anti-Aggregat (oder etwas von einem Anti-Aggregat abgeleitetes) ist. Wird für die Dekombinierung vorheriger Aggregate in einer Pipeline mit mehreren Aggregatstufen genutzt, die mit AccumulationMode.Cumulative laufen.
• Wenn schließlich nach Schlüsseln sortiert, würde dies mindestens zwei Versionen jedes Fensters ergeben: eine für das 95. Perzentil der Daten und eine für das 100. Perzentil der Daten. Falls verspätete Daten eintreffen, würde man auch eine aktualisierte Version des Aggregats für jedes verspätete Datum erhalten.
• Implementation der Flume-Trigger-API: Einfache Trigger werden über Unterklassen der Klasse Trigger<B extends Window, T> implementiert. Die Klasse umfasst drei abstrakte Methoden, die von der Fenstertechnik-API 400 aufgerufen werden, wobei jede eine spezialisierte Kontextklasse erhält, die alle im gegebenen Kontext verfügbaren Operationen bereitstellt.
• • onDatum – Wird sofort aufgerufen, nachdem ein Datum zum ersten Mal in ein Fenster inkorporiert wurde. Wird versorgt sowohl mit dem Fenster und dem (nicht inkorporierten) Wert. Auf den vollen Aggregatwert des Fensters kann über Window.peekValue() zugegriffen werden, was kostenintensiv sein kann, wenn keine Aggregatsfunktion verwendet wird. Kann den pro-Tag-Status des Fensters lesen/schreiben. Kann die aktuelle Zeit in allen Zeitdomänen überprüfen. Kann pro-Tag-Timer für das Fenster setzen/löschen. Kann auslösen und den Fensterwert löschen. Kann den Trigger als abgeschlossen markieren.
  
  
• • onMerge – Wird sofort nach einer Fensterzusammenführung aufgerufen. Wird versorgt mit den Quellfenstern und dem zusammengeführten Fenster. Kann den pro-Tag-Status der Quellfenster lesen und den pro-Tag-Status des zusammengeführten Fensters schreiben. Kann die aktuelle Zeit in allen Zeitdomänen überprüfen. Kann pro-Tag-Timer für Quellfenster prüfen und pro-Tag-Timer für das zusammengeführte Fenster setzen. Kann auslösen und den Fensterwert löschen. Kann den Trigger als abgeschlossen markieren. Alle statischen und nicht ausgelösten Timer werden (per Aufruf zum Zurücksetzen) bei der der Vervollständigung des Callbacks gelöscht.
  
  
• • onTimer – Wird aufgerufen, wenn ein vom Trigger gesetzter Timer ausgelöst wird. Wird versorgt mit dem Fenster und dem Timer-Tag, sofort und domänenspezifisch. Kann den pro-Tag-Status des Fensters lesen/schreiben. Kann die aktuellen Timer in allen Domänen inspizieren. Kann pro-Tag-Timer für das Fenster setzen/löschen. Kann auslösen und den Fensterwert löschen. Kann den Trigger als abgeschlossen markieren.
  
  
• Um Hilfsfunktionen zu erlauben, geschrieben und von mehreren verschiedenen Callbacks genutzt zu werden, wenn diese kompatiblen Operationen ausführen, werden gewöhnliche Kontextmethoden (wie etwa lookupState) in ihrer eigenen Schnittstelle definiert, z. B.:

  
• Die Timer werden zu einem Objekt erster Klasse erhoben. Dies erfordert, dass das System 100 im Verborgenen alle Timer in persistentem Status überwacht, aber den Benutzer von dieser Last befreit (was eine gewöhnliche Nutzung von persistenten Staten beim Umgang mit Timern ist), und erlaubt dem System 100, alle Timer eines Triggers automatisch während der Speicherbereinigung zu beseitigen.
• 
• Die Integration in das existierende Fenstersystem ist relativ einfach, wobei die zwei Hauptaktivierungspunkte sind, nachdem ein Datum zuerst in ein Fenster inkorporiert wurde (für onDatum) sowie nach der Zusammenführung der Fenster durch die merge-Funktion von WindowingStrategy (für onMerge).
• Interessanter ist die Unterstützung der Herstellung von gemischten Triggern, z. B. FirstOf, SequenceOf usw. Gemischte Trigger würden mithilfe der CompositeTrigger-Klasse implementiert werden, die ein Superset von Trigger-Funktionalität bereitstellt (und tatsächlich eine Superklasse davon ist). Jeder Kontext in CompositeTrigger würde eine oder zwei Operationen unterstützen:
• • invokeChild – Aktiviert den aktuellen Callback auf den gegebenen Child-Trigger. Verfügbar in allen Operationen (onDatum, onMerge, onTimer, reset). Behält im Verborgenen die Übersicht über die Abstammungslinie bis zum aktuellen Child-Element und nutzt diese Linie zur Bereitstellung einzigartiger Namensräume für alle Status und Timer, die von irgendeinem Child-Element manipuliert werden. Erlaubt auch void invokeChild(Trigger trigger); triggerHistory – Gibt die Sequenz von Child-Trigger zurück, die das ctx.trigger()-Verfahren während der Laufzeit dieses Callbacks als Liste von TriggerEvent-Objekten aktiviert hat (welche den aufrufenden Trigger erfasst und ob ein Löschen (Clear) angefordert wurde). Verfügbar in allen Operationen, deren Kontextklasse ein Trigger-Verfahren beinhaltet (onDatum, onMerge, onTimer). Von triggerHistory zurückgegebene Trigger sind strikt unter den Nachkommen dieses spezifischen Triggers (z. B. Grandchild-Trigger werden niemals direkt in den Ergebnissen dieses Funktionsaufrufs auftauchen, aber sie können dafür sorgen, dass ein Child-Trigger auftaucht).
• 
• Zusätzlich stellt CompositeTrigger einen vierten Callback bereit, der es einem Elternelement erlaubt, sich in ein Callback-Event eines Child-Timers einzuklinken, da Timer auf einen spezifischen Trigger zugeschnitten sind, aber Konsequenzen für ein Elternelement haben können:
• • onChildTimer – Wird aufgerufen, wenn ein von einem Child-Trigger gesetzter Timer ausgelöst wird. Wird versorgt mit dem Fenster, dem Child-Trigger und dem Timer-Tag, sofort und domänenspezifisch. Kann seinen eigenen pro-Tag-Status und den des Fensters lesen/schreiben. Kann die aktuellen Timer in allen Domänen inspizieren. Kann seine eigenen pro-Tag-Timer für das Fenster prüfen/setzen/löschen. Kann auslösen und den Fensterwert löschen. Kann den Trigger als abgeschlossen markieren. Kann den Child-Timer aktivieren. Kann alle Trigger-Aufrufe prüfen, die von der Child-Instanz gemacht wurden.

• Mit der Nutzung dieser APIs ist es dem System 100 möglich, die komplette Bandbreite der MillWheel-API bereitzustellen, während Endbenutzer sich typischerweise nicht mit den Komplexitäten der zugrundeliegenden systemnahen API befassen müssen. Siehe unten für eine Folge von exemplarischen Trigger-Implementationen.
• On-disk-Status: Trigger speichern den folgenden on-disk-Status.
• • Benutzerpaare aus Tags/Werten.
• • Benutzertimer (im Timer-System)
• • Benutzerpaare aus Tags/Timern (in persistentem Status)
• • Eine Momentaufnahme des letzten ausgegebenen Wertes für das Fenster, falls der inkrementelle Modus aktiviert ist.
• • Ein Grabstein für Trigger, die abgeschlossen sind.
• Akkumulationsmodus:
• Das System 100 kann den Anweisungen der Einstellung für den Akkumulationsmodus für die aktuelle TriggerStrategy folgen, wenn es entscheidet, ob es automatisch die Fensterwerte bei Triggeraufrufen löschen soll und ob es Löschanfragen der Trigger-Implementation folgen soll.
• Inkrementeller Modus: Anti-Daten, die aus einem vorherigen Wert für ein Fenster bestehen, würden bei jeder Auslösung eines Fensters generiert werden.
• Wenn Fenster im inkrementellen Modus zusammengeführt werden, werden ihre zuletzt ausgegebenen Werte (falls überhaupt welche) ebenfalls zusammengeführt. Nachgeordnet produzieren alle nicht-GroupByKey-Operationen auf ein Anti-Datum mehr Anti-Daten (ähnlich der Zeitstempelverbreitung). Wenn eine GroupByKey-Operation erreicht wird, werden Anti-Daten in das uncombine-Verfahren eingeschleust. Das Ergebnis des uncombine-Verfahrens sind dann normale Daten, keine Anti-Daten; dennoch, falls die TriggerStrategy für diese GBK-Operation den inkrementellen Modus aktiviert, dann wird auch ein Anti-Datum für den letzten Wert des Fensters ausgegeben. Das System 100 strebt die Unterstützung des inkrementellen Modus anfangs für irgendwelche der Dataflow/Flume-Produkte nicht an; das Feature benötigt vermutlich eine Dokumentation für sich alleine.
• MillWheel: MillWheel kann Extra-Metadaten über Annotationen unterstützen (z. B. ähnlich wie für Fenster):
• • Trigger-Metadaten werden hinzugefügt, wenn ein Trigger ausgelöst wird.
• • Wasserzeichenperzentile werden auf Rohdaten bei Injektoren annotiert sowie auf Aggregatsdaten zur Triggerzeit.
• • Anti-Daten werden bei der Ausgabe als solche markiert.
• Die Bereitstellung feiner Schätzungen von Wasserzeichenperzentilen wird eine Überwachung der globalen Wasserzeichenhistogramme anstatt einzelner minimaler Wasserzeichenwerte erfordern. Wasserzeichenhistogramme sind für WindMill geplant. Diese müssten zu MillWheel hinzugefügt werden.
• Zwei Features in dieser API würden die Unterstützung mehrerer Timer-Manager erfordern:
• • Beliebige Wasserzeichenperzentil-Trigger.
• • TriggerSets, die sowohl Wasserzeichen- als auch Walltime-Timer enthalten.
• WindMill unterstützt mehrere Timer-Manager und sollte in der Lage sein, das Wasserzeichen+Walltime-Feature von Natur aus zu unterstützen. Unterstützung für mehrere Wasserzeichenperzentile sollte nicht allzu schwer sein. MillWheel könnte ein Refactoring des Timer-Manager-Codes benötigen, um beide Features zu unterstützen.
• Anhang A – exemplarische Trigger-Implementationen AfterCount

  
• 
• AfterDelay

  
• 
• AtWatermark

  
• 
• ResultIdOdd

  
• 
• 
• 
• SequenceOf

  
• 
• 
• 6A–6I zeigen Beispieldarstellungen 600, 600a–i, die eine Mehrzahl an nützlichen Ausgabemustern hervorheben, die vom System 100 unterstützt werden. Die Beispieldarstellung 600 ist im Kontext der Integer-Summation-Pipeline gestaltet.
  PCollection<KV<String, Integer>> output = input
  .apply(Sum.integersPerKey());
• Nutzung einer Eingabequelle, von der das System 100 Daten 10 einschließlich von zehn Datenpunkten erhält, wobei jeder Datenpunkt einem kleinen Integerwert zugeordnet ist und vom System 100 im Kontext sowohl begrenzter als auch unbegrenzter Datenquellen analysiert wird. Zur Vereinfachung des Diagramms nimmt das System 100 in der Beispieldarstellung 600 an, dass die von den Daten 10 erhaltenen Datenpunkte für denselben Schlüssel sind; in einer realen Pipeline würden die vom System 100 ausgeführten Operationen jedoch parallel für mehrere Schlüssel ausgeführt werden. FIG. 6A ist eine Beispieldarstellung 600, die einen Fenster-Zeit-Domänen-Versatz für die Datenpunkteingaben der erhaltenen Daten 10 zeigt. Die X-Achse stellt die Daten 10 in Ereigniszeit dar (d. h. wenn die Ereignisse tatsächlich eingetreten sind), während die Y-Achse die Daten 10 in Verarbeitungszeit darstellt (d. h. wenn die Pipeline sie bemerkt). Alle Darstellungen 600, 600a–i nehmen eine Ausführung auf der Streaming-Engine an, falls nicht anderweitig angegeben.
• Viele der Darstellungen 600 werden auch von Wasserzeichen abhängen, wenn sie in den Darstellungen 600 enthalten sind. In diesen Szenarios zeigen die Darstellungen 600 ein ideales Wasserzeichen und ein exemplarisches tatsächliches Wasserzeichen. Die gerade gepunktete Linie mit Neigung repräsentiert das ideale Wasserzeichen, d. h., falls es keinen Ereigniszeitversatz gäbe und alle Ereignisse vom System 100 direkt bei ihrem Eintreten verarbeitet würden. Aufgrund der Launen verteilter Systeme ist Versatz ein gewöhnliches Ereignis; dies wird exemplarisch durch den Irrweg dargestellt, den das tatsächliche Wasserzeichen vom idealen Wasserzeichen hinweg nimmt, wie veranschaulicht in der Darstellung 600a in 6A. Auch die heuristische Natur dieses Wasserzeichens wird exemplarisch dargestellt durch das einzelne „verspätete” Datum (z. B. ein Datenpunkt) mit dem Wert 9, der hinter dem Wasserzeichen auftaucht.
• Falls das System 100 die erhaltenen Daten 10 in einem klassischen Batch-System unter Nutzung der beschriebenen Summation-Pipeline verarbeiten müsste, würde das System 100 auf die Ankunft der gesamten Daten 10 warten, die Daten 10 zusammen in ein Paket gruppieren (da diese Datenpunkte alle für denselben Schlüssel sind) und ihre Werte addieren, um zu einem Endergebnis von 51 zu gelangen. Die Darstellung 600b in 6B zeigt dieses Ergebnis, repräsentiert durch das verdunkelte Viereck, wobei das Gebiet die Bereiche der in der Summe enthaltenen Ereigniszeit und Verarbeitungszeit enthält (wobei das Dach des Rechtecks anzeigt, wann in der Verarbeitungszeit das Ergebnis materialisiert wurde). Da klassische Batch-Verarbeitung die Ereigniszeit nicht wahrnimmt, ist das Ergebnis 20 enthalten in einem einzelnen globalen Fenster, das die gesamten Ereigniszeiten umfasst. Und da Ausgaben erst berechnet werden, wenn alle Eingaben (z. B. die Daten 10) erhalten wurden, umfasst das Ergebnis 20 die gesamte Verarbeitungszeit der Ausführung.
• Man beachte die Einbindung von Wasserzeichen in Darstellung 600b. Obwohl nicht typischerweise für klassische Batch-Verarbeitung genutzt, würden Wasserzeichen semantisch am Beginn der Zeit gehalten werden, bis alle Daten 10 verarbeitet wurden, und dann ins Unendliche weitergeführt. Ein wichtiger Punkt ist, dass man identische Semantik zu klassischer Batch-Verarbeitung erhalten kann, indem man die Daten durch ein Streaming-System leitet, in dem Wasserzeichen auf diese Art verarbeitet werden.
• In manchen Implementationen konvertiert das System die Pipeline, um eine unbegrenzte Datenquelle zu durchlaufen. In Dataflow sind die standardmäßig auslösenden Semantiken, Fenster auszugeben, wenn ein Wasserzeichen sie passiert. Aber bei Nutzung eines globalen Fensters mit einer unbegrenzten Eingabequelle werden die auslösenden Semantiken keine Fenster ausgeben, wenn ein Wasserzeichen sie passiert, da das globale Fenster die gesamte Ereigniszeit einschließt. So muss das System 100 entweder durch etwas Anderes auslösen als durch den Standardtrigger oder durch etwas anderes als das globale Fenster anzeigen. Andernfalls wird das System 100 kein Ergebnis 20 produzieren.
• In manchen Beispielen erlaubt die Änderung des Triggers dem System 100, konzeptuell identische Ausgaben zu erzeugen (eine globale pro-Schlüssel-Summe über die gesamte Zeit), aber mit periodischen Aktualisierungen. In diesen Beispielen wendet das System 100 eine Window.trigger-Operation an, die wiederholt in einminütigen periodischen Verarbeitungszeitintervallen ausgelöst wird. Das System 100 kann den Akkumulationsmodus spezifizieren, sodass die globale Summe mit der Zeit verfeinert wird (dabei wird davon ausgegangen, dass das System 100 eine Ausgabesenke beinhaltet, in welchem das System 100 vorherige Ergebnisse für den Schlüssel mit neuen Ergebnissen überschreiben kann, wie beispielsweise eine Datenbank oder ein Schlüssel-/Wertspeicher). In Bezug auf die Darstellung 600c in 6C generiert das System 100 aktualisierte globale Summen einmal pro Minute an Verarbeitungszeit. Man beachte, wie sich die halbtransparenten Ausgaberechtecke (z. B. Fenster) überlappen, da Akkumulationsausschnitte auf vorherigen Ergebnissen aufbauen, indem Sie die Überlappung von Regionen der Verarbeitungszeit inkorporieren:
  PCollection<KV<String, Integer>> output = input
  .apply(Window.trigger(Repeat(AtPertod(1, MINUTE)))
  .accumulating())
  .apply(Sum.integersPerKey());
• Umgekehrt zeigt die Darstellung 600d in 6D, wie das System 100 das Summendelta einmal pro Minute generiert, indem es in den Verwerfungsmodus umschaltet. Man beachte, dass das System 100 durch das Umschalten in den Verwerfungsmodus effektiv die Verarbeitungszeit-Fenstersemantiken vieler Streaming-Systeme darstellt. Die Ausgabeausschnitte überlappen sich nicht mehr länger, da ihre Ergebnisse Daten aus unabhängigen Regionen der Verarbeitungszeit inkorporieren.
• 
• Ein anderer, robusterer Weg der Bereitstellung von Verarbeitungszeit-Fenstertechniksemantiken ist, einfach die Ankunftszeit als Ereigniszeit bei der Datenankunft zuzuweisen und dann die Ereigniszeit zur Fenstererstellung zu nutzen. Ein netter Seiteneffekt der Nutzung der Ankunftszeit als Ereigniszeit ist, dass das System perfektes Wissen über die anstehenden Ereigniszeiten hat und daher perfekte (d. h. nicht-heuristische) Wasserzeichen bereitstellen kann, ohne verspätete Daten. Dies ist ein effektiver und kosteneffizienter Weg, unbegrenzte Daten in Anwendungsfällen zu verarbeiten, in denen echte Ereigniszeiten nicht nötig oder verfügbar sind.
• Vor der Einbeziehung anderer Fenstertechnikoptionen kann das System 100 eine oder mehrere Änderungen an den Triggern für diese Pipeline erwägen. In manchen Beispielen kann das System 100 tupelbasierte Fenster modellieren, indem es einfach die Trigger so ändert, dass sie nach einer bestimmten Anzahl an Ankunftsdaten ausgelöst werden, z. B. zwei. In Bezug auf 6E zeigt die Darstellung 600e fünf Ausgaberesultate aus unabhängigen Regionen der Verarbeitungszeit. Jedes Ausgabeergebnis enthält z. B. die Summe zweier nebeneinanderliegender (in Bezug auf die Verarbeitungszeit) Datenpunkteingaben. Raffiniertere tupelbasierte Fenstertechnikverfahren (z. B. die Verschiebung von tupelbasierten Fenstern) erfordern eigenständige Fenstertechnik-Strategien, aber werden ansonsten unterstützt.
• 
• 
• Andere Beispiele für die Unterstützung unbegrenzter Quellen enthalten die Abwendung von der globalen Fenstertechnik. Hierbei kann das System 100 (z. B. über die Fenstertechnik-API 300) die Daten 10 in fixierte, zweiminütig akkumulierende Fenster integrieren:

  
• Ohne spezifizierte Trigger-Strategie würde das System 100 den Standard-Trigger nutzen, der effektiv so aussieht:

  
• Der Wasserzeichen-Trigger wird ausgelöst, wenn das Wasserzeichen das Ende des bestimmten Fensters passiert. Sowohl Batch-Verarbeitung als auch Streaming-Engines implementieren Wasserzeichen, wie unten beschrieben. Der Repeat-Aufruf im Trigger wird genutzt, um die verspäteten Daten zu handhaben; sollten Daten nach dem Wasserzeichen ankommen, werden sie den wiederholenden Wasserzeichen-Trigger instantiieren, der sofort ausgelöst wird, da das Wasserzeichen bereits vorhanden ist.
• Bezugnehmend auf 6F–6H charakterisieren die Darstellungen 600f–600h jeweils diese Pipeline in einer anderen Art von Laufzeitumgebung. In manchen Implementationen untersucht das System 100 zuerst, wie die Ausführung dieser Pipeline in einer Batch-Engine aussehen würde. In diesen Implementationen müsste die Datenquelle begrenzt sein, wie bei dem klassischen Batch-Beispiel oben, das System 100 würde auf die Ankunft aller Daten 10 im Batch warten. Danach würde das System 100 dann die Daten in der Reihenfolge der Ereigniszeit verarbeiten, indem es Fenster ausgibt, während das simulierte Wasserzeichen wächst, wie in der Beispieldarstellung 600f in 6F.
• Bei der Ausführung einer Mikro-Batch-Engine über die Datenquelle mit einminütigen Mikro-Batches würde das System 100 die Eingabedaten 10 eine Minute lang sammeln, die Daten 10 dann verarbeiten und den Vorgang wiederholen. Jedes Mal würde das Wasserzeichen für den aktuellen Batch am Startzeitpunkt starten und zum Endzeitpunkt fortschreiten (tecchnisch gesehen von der Endzeit des Batches sofort zum Ende der Zeit springen, da für diesen Zeitraum keine Daten vorhanden wären). Das System 100 erhält ein neues Wasserzeichen für jede Mikro-Batch-Runde und entsprechende Ausgaben für alle Fenster, deren Inhalt sich seit der letzten Runde geändert hat. Dies beinhaltet einen sehr guten Mix aus Latenz und letztendlicher Korrektheit, wie gezeigt in der Beispieldarstellung 600g in 6G.
• Beim Ausführen der Pipeline in einer Streaming-Engine zeigt die Darstellung 600h in 6H eine Aktualisierung eines Ausgabeergebnisses in einem fixierten Fenster durch einen verspäteten Datenpunkt. Während die meisten Fenster Ihre zugewiesenen Datenpunkte ausgeben, wenn das Wasserzeichen sie passiert, erhält das System 100 das Datum (z. B. Datenpunkt) mit Wert 9 relativ zum Wasserzeichen verspätet. Aus welchem Grund auch immer (mobile Eingabequelle ist offline, Netzwerkteilung usw.), das System 100 hat nicht realisiert, dass das Datum mit Wert 9 noch nicht eingefügt wurde, und hat daher, nach Observierung des Datums mit Wert 5 mit demselben Fenster (für die Ereigniszeitspanne [12:00, 12:02]), dem Wasserzeichen erlaubt, hinter den Ereigniszeitpunkt fortzufahren, der letztendlich das Datum mit dem Wert 9 enthalten würde. Daher verursacht das Datum mit Wert 9, sobald es letztendlich angekommen ist, eine erneute Auslösung des ersten Fensters (für die Ereigniszeitspanne [12:00, 12:02]) mit einer aktualisierten Summe.
• Dieses Ausgabemuster ist schön, da es etwa eine Ausgabe pro Fenster enthält, mit einer einzelnen Verfeinerung im Fall eines verspäteten Datums. Aber die Gesamtlatenz der Ergebnisse ist merklich schlechter als die des Mikro-Batch-Systems, da im Voraus auf das Wasserzeichen gewartet werden muss; dies ist der Fall von zu langsamen Wasserzeichen.
• Falls das System 100 eine niedrigere Latenz über multiple partielle Ergebnisse für alle Fenster wünscht, kann das System 100 einige zusätzliche, aus fortschreitender Zeit basierende Trigger hinzufügen, um regelmäßige Aktualisierungen bereitzustellen, bis das Wasserzeichen letztendlich vorbeizieht. In Bezug auf 6I zeigt die Darstellung 600i Ausgabeergebnisse basierend auf Triggern, die auf der fortschreitenden Zeit basieren, um eine ein wenig bessere Latenz als die Mikro-Batch-Pipeline aus Darstellung 600h zu erreichen, da die Datenpunkte der erhaltenen Daten in Fenstern akkumuliert werden, wenn sie eintreffen, anstatt in kleinen Batches verarbeitet zu werden. Da sehr konsistente Mikro-Batch- und Streaming-Engines existieren, wird die Auswahl zwischen ihnen (als auch die Auswahl der Mikro-Batch-Größe) wirklich nur eine Frage der Auswahl zwischen Latenz und Kosten, was exakt eines der Ziele ist, die das System 100 basierend auf folgendem Modell erreichen kann.
• 
• In Bezug auf 6J zeigt die Darstellung 600j die Datenpunkte der erhaltenen Daten 10 gruppiert mit Sitzungsfenstern und kombinierten Ausgabeergebnissen, die von kombinierten Fenstersitzungen ausgegeben wurden. Hierbei kann das System 100 die Videositzungserfordernisse (modulo die Nutzung von Summierung als Aggregationsoperation, aufgeführt für die Diagrammkonsistenz; der Wechsel zu einer anderen Aggregation wäre trivial) erfüllen, indem es sich auf eine Sitzungsfenstertechnik mit einem Timeout von einer Minute aktualisiert und Retraktionen aktiviert. Dies hebt die Kombinierbarkeit hervor, die vom Aufspalten des Modells in vier Teile (was das System 100 berechnet, wo in der Ereigniszeit das System 100 berechnet, wann in der Verarbeitungszeit das System 100 Ergebnisse der Berechnung ausgibt und wie diese Ergebnisse sich zu späteren Verfeinerungen verhalten) bereitgestellt wird, ebenso wie es die Macht der Umkehrung früherer Werte illustriert, die ansonsten nicht den als Ersatz angebotenen Werten zugewiesen worden wären.
• 
• In der Beispieldarstellung 600j in 6J gibt das System 100 initiale einzelne Sitzungen für die Werte 5 und 7 bei der ersten einminütigen Verarbeitungszeitgrenze aus. Bei der zweiten Minutengrenze gibt das System 100 eine dritte Sitzung mit dem Wert 10 aus, gebildet aus den Werten 3, 4 und 3. Wenn der Wert 8 letztendlich gesichtet wird, wird er den zwei Sitzungen mit den Werten 7 und 10 hinzugefügt. Wenn das Wasserzeichen das Ende dieser neuen, kombinierten Sitzung passiert, gibt das System 100 Retraktionen für die Sitzungen mit den Werten 7 und 10 aus sowie ein normales Datum für die neue Sitzung mit dem Wert 25. Gleichermaßen, wenn das Datum mit Wert 9 (verspätet) ankommt, wird es der Sitzung mit dem Wert 5 hinzugefügt hin zur Sitzung mit dem Wert 25. Der wiederholte Wasserzeichen-Trigger gibt dann sofort Retraktionen für die Werte 5 und 25 aus, gefolgt von einer kombinierten Sitzung mit dem Wert 39. Eine ähnliche Ausführung findet statt für die Datenpunkte mit den Werten 3, 8 und 1, letztendlich endend mit einer Retraktion für eine initiale Sitzung mit Wert 3, gefolgt von einer kombinierten Sitzung mit Wert 12.
• FlumeJava kann das System 100 implementieren, wobei MillWheel als zugrundeliegende Ausführungsengine für den Streamingmodus genutzt wird; zusätzlich ist eine externe Reimplementation für Cloud Dataflow zur Zeit des Schreibens zu einem Großteil vervollständigt. Auf Grund früherer Charakterisierung dieser internen Systeme in der Literatur sowie der öffentlichen Verfügbarkeit von Cloud Dataflow werden Details der Implementationen selbst hier zu Zwecken der Kürzung ausgelassen. Ein interessanter Punkt ist, dass die Kernfenstertechnik und der auslösende Code recht allgemein sind und ein signifikanter Teil davon von Batch- und Streaming-Implementationen geteilt wird; das System selbst ist eine detailliertere Analyse in der Zukunft wert.
• Wichtige Faktoren für die Gestaltung aus Erfahrungen der echten Welt heraus finden sich unten. Für die Gestaltung des Dataflow-Modells werden Erfahrungen aus der realen Welt mit FlumeJava und Mill-Wheel über die Jahre hinweg berücksichtigt. Konfigurationen, die gut funktioniert haben, können eingearbeitet werden, während Konfigurationen mit weniger wünschenswerten Ergebnissen Änderungen im Dataflow-Modell motiviert haben.
• Eine Anzahl von Teams führen Log-Joining-Pipelines auf MillWheel aus. Eine ganz besonders große Log-Join-Pipeline läuft standardmäßig im Streamingmodus auf MillWheel, besitzt aber eine separate Flume-Java-Batch-Implementation, die für großangelegte Auffüllungen genutzt wird. Ein sehr viel besseres Setup wäre es, eine einzelne Implementation zu haben, geschrieben in einem vereinheitlichten Modell, die sowohl im Streamingmodus als auch im Batchmodus ohne Modifikationen laufen könnte. Die wurde zum initialen, motivierenden Anwendungsfall für eine Vereinheitlichung von Batch-, Mikro-Batch- und Streaming-Engines und wurde hervorgehoben in den Darstellungen 600f–600h der 6F–6H.
• Eine weitere Motivation für das vereinheitlichte Modell kam von einer Erfahrung mit der Lambda-Architektur. Obwohl die meisten Anwendungsfälle von Datenverarbeitung exklusiv von einem Batch- oder Streamingsystem gehandhabt werden, betrieb ein MillWheel-Kunde seine Streaming-Pipeline im schwachen Konsistenzmodus, mit einem nächtlichen MapReduce, um Wahrhaftigkeit zu generieren. Sie fanden heraus, dass die Kunden mit der Zeit den schwach konsistenten Ergebnissen nicht mehr vertrauten und reimplementierten ihr System als Resultat daraus mit starker Konsistenz, sodass sie verlässliche Ergebnisse mit niedriger Latenz liefern konnten. Diese Erfahrung motivierte weiterhin den Wunsch, eine flüssige Auswahl von Ausführungs-Engines zu unterstützen.
• Von Anfang an musste das System 100 Sitzungen unterstützen; dies ist tatsächlich der hauptsächliche Beitrag des zugrundeliegenden Fenster-Modells über existierende Modelle. Sitzungen sind ein extrem wichtiger Anwendungsfall (und sind einer der Gründe, warm MillWheel erschaffen wurde) und werden für eine Anzahl von Produktbereichen genutzt, einschließlich Suche, Werbung, Analyse, soziale Netze und YouTube. Jedes Produkt, das Häufungen von andernfalls getrennter Benutzeraktivität über eine Zeitperiode hinweg korreliert, tut das mithilfe von Sitzungen. Daher wurde die Unterstützung von Sitzungen Hauptsache in der Erstellung des in System 100 implementierten Dataflow-Modells. Wie gezeigt in Darstellung 600j von 6J ist die Generierung von Sitzungen im Datenflussmodell durch das System 100 trivial.
• Zwei Teams mit auf MillWheel basierenden Zahlungspipelines hatten Probleme, die Teile des Modells motiviert haben. Die empfohlene Vorgehensweise zu der Zeit war die Nutzung des Wasserzeichens als Fertigstellungsmetrik, wobei Ad-hoc-Logik mit verspäteten Daten oder Änderungen in den Quelldaten umging. Durch das Fehlen eines prinzipiellen Systems für Aktualisierungen und Retraktionen beschloss ein Team, das Ressourcennutzungsstatistiken verarbeitete, unsere Plattform zu verlassen, um eine eigene Lösung aufzubauen. Ein anderes Zahlungsteam hatte signifikante Probleme mit Wasserzeichenverzögerungen, die durch Nachzügler in Ihren Eingabedaten verursacht wurden. Diese Schwächen wurden zu großen Motivatoren in unserem Design und haben die Fokussierung von der Zielfertigstellung weg hin zur Anpassungsfähigkeit über die Zeit hinweg beeinflusst. Es ergaben sich zwei Resultate: Trigger, die die prägnante und flexible Spezifizierung des Zeitpunkts der Ergebnismaterialisierung erlauben, wie bewiesen von der Vielzahl an Ausgabemustern über dieselbe Datenmenge in den Darstellungen 600c–600j in 6C–6J; und die Unterstützung von inkrementeller Verarbeitung durch Akkumulation (6C und 6D) und Retraktion (6J).
• Viele MillWheel-Pipelines berechnen Aggregatstatistiken (z. B. Latenzdurchschnitte). Für diese wird keine 100%-ige Genauigkeit benötigt, aber benötigt wird ein kompletter Überblick über ihre Daten in einem vernünftigen Zeitraum. Mit dem hohen Level an Genauigkeit, dass wir mit Wasserzeichen für strukturierte Eingabequellen wie Logdateien erreichen, finden diese Kunden Wasserzeichen sehr effektiv in der Auslösung eines einzelnen, hochgenauen Aggregats pro Fenster. Wasserzeichen-Trigger sind hervorgehoben in der Darstellung 600h in 6H. Eine Anzahl von Missbrauchserkennungs-Pipelines basieren auf MillWheel. Missbrauchserkennung ist ein weiteres Beispiel eines Anwendungsfalls, in dem die schnelle Verarbeitung eines Großteils der Daten sehr viel hilfreicher ist als die langsamere Verarbeitung von 100% der Daten. Daher sind diese starken Nutzer von MillWheels perzentilen Wasserzeichen und waren eine starke Motivation dafür, perzentile Wasserzeichen-Trigger im Modell unterstützen zu können.
• Damit verbunden, ein schmerzhafter Punkt in Batch-Verarbeitungsaufgaben sind Nachzügler, die einen langen Zipfel an Ausführungszeit verursachen. Während dynamische Rebalancierung bei diesem Problem helfen kann, besitzt FlumeJava ein eigenes Feature, das die frühzeitige Beendigung einer Aufgabe basierend auf dem Gesamtfortschritt erlaubt. Einer der Vorteile des vereinheitlichten Modells für den Batchmodus ist, dass diese Art von Kriterium für frühzeitige Beendigung jetzt normalerweise ausdrückbar ist unter Nutzung des Standard-Trigger-Mechanismus, anstatt ein eigenes Feature zu benötigen.
• Eine andere Pipeline erwägte, Bäume der Benutzeraktivität zu erzeugen (essentiell Sitzungsbäume), über mehrere Systeme hinweg. Diese Bäume wurden dann genutzt, um Empfehlungen, zugeschnitten auf die Benutzerinteressen, zu geben. Die Pipeline war besonders darin, dass sie Timer für die Verarbeitungszeit genutzt hat, um ihre Ausgaben zu steuern. Dies war aufgrund des Faktes, dass, für ihr System, regelmäßig aktualisierte, partielle Ansichten der Daten sehr viel wichtiger waren als das Warten darauf, dass hauptsächlich vollständige Ansichten bereit waren, sobald das Wasserzeichen das Ende der Sitzung erreicht hatte. Es bedeutete auch, dass Verzögerungen im Fortschritt des Wasserzeichens aufgrund einer kleinen Menge langsamer Daten die Pünktlichkeit der Ausgabe des Rests der Daten nicht beeinflusst hat. Diese Pipeline motivierte daher die Einbindung von Verarbeitungszeit-Triggern, gezeigt in den Darstellungen 600c und 600d der 6C und 6D.
• Bei der Entwicklung von Triggern hat ihr Diff-Erkennungssystem datengetriebene Trigger motiviert. Diese Differ beobachten den Stream von Anfragen und berechnen statistische Schätzungen, ob eine Spitze existiert oder nicht. Wenn Sie annehmen, dass eine Lastspitze vorliegt, geben Sie einen Startdatensatz aus, und wenn sie annehmen, dass sie vorbei ist, geben Sie ein Stopp aus. Obwohl eine Technik die Differ-Ausgabe mit etwas periodischem wie Trills Punctuations antreiben könnte, ist für die Erkennung von Anomalien das Erreichen einer Ausgabe, sobald eine Anomalie sicher entdeckt wurde, ideal; die Nutzung von Punctuations transformiert essentiell das Streaming-System in einen Mikro-Batch und führt damit zusätzliche Latenz ein. Praktikabel für eine Anzahl an Anwendungsfällen ist es für diesen Fall nicht ideal und motivierte daher die Unterstützung für spezifische datengetriebene Trigger. Es war auch eine Motivation für die Trigger-Vermischung, da in der Realität das System mehrere Differ auf einmal laufen lässt und deren Ausgaben entsprechend einem fein definierten Satz von Logik überträgt. Der AtCount-Trigger in der Darstellung 600e in 6E hat exemplarisch datengetriebene Trigger dargestellt; während die Darstellungen 600f–600j in 6F–6J gemischte Trigger genutzt haben.
• Die Zukunft der Datenverarbeitung sind unbegrenzte Datenmengen. Obwohl begrenzte Daten immer einen wichtigen und nützlichen Platz haben werden, werden sie semantisch subsumiert durch ihr unbegrenztes Gegenstück. Weiterhin kann einem die Ausbreitung unbegrenzter Datenmengen in der modernen Geschäftswelt den Atem verschlagen. Zur gleichen Zeit werden die Verbraucher von verarbeiteten Daten täglich klüger und erwarten anspruchsvolle leistungsfähige Konstrukte wie Ereigniszeit-Bestellung und nicht ausgerichtete Fenster. Die heute existierenden Modelle und Systeme dienen als exzellente Grundlage, um die Datenverarbeitungswerkzeuge von morgen aufzubauen, aber es gibt die feste Überzeugung, dass eine Verschiebung der allgemeinen Denkweise notwendig ist, um diese Instrumente umfassend auf die Bedürfnisse der Verbraucher von unbegrenzten Daten auszurichten.
• Basierend auf langjähriger Erfahrung mit realer, massiver und unbegrenzter Datenverarbeitung ist das oben beschriebene System 100 ein guter Schritt in diese Richtung. Das System 100 unterstützt die nicht ausgerichteten, ereigniszeitgeordneten Fenster, die moderne Datenkonsumenten benötigen, während es eine flexible Auslösung und integrierte Akkumulation und Retraktion ermöglicht und den Ansatz von der Suche nach Vollständigkeit der Daten zu einer der Anpassung an die allgegenwärtigen Änderungen, die sich in realen Datenmengen manifestieren, neu fokussiert. Das System 100 abstrahiert die Unterscheidung von Batch vs. Mikro-Batch vs. Streaming, so dass Pipeline-Ersteller eine flüssigere Wahl zwischen ihnen haben, während sie von den systemspezifischen Konstrukten abgeschirmt werden, die unausweichlich in Modelle Einzug halten, die auf einem einzelnen zugrundeliegenden System aufbauen. Die Gesamtflexibilität des Systems 100 ermöglicht es den Pipeline-Erstellern, die Dimensionen von Korrektheit, Latenz und Kosten in geeigneter Weise an ihren Anwendungsfall anzupassen, was angesichts der Vielfalt der existierenden Bedürfnisse kritisch ist. Und abschließend stellt das System 100 die Implementierung von Pipelines klar, indem es die Begriffe trennt, welche Ergebnisse berechnet werden, wo in der Ereigniszeit sie berechnet werden, wann sie in der Verarbeitungszeit materialisiert werden und wie frühere Ergebnisse sich auf spätere Verfeinerungen beziehen.
• Eine Softwareanwendung (d. h. eine Softwareressource) kann sich auf eine Computersoftware beziehen, die ein Computergerät anweist, eine Aufgabe auszuführen. In manchen Beispielen kann eine Softwareanwendung als „Applikation”, „App” oder „Programm” bezeichnet werden. Beispielanwendungen enthalten, sind aber nicht limitiert auf, Systemdiagnoseanwendungen, Systemverwaltungsanwendungen, Systemwartungsanwendungen, Wortverarbeitungsanwendungen, Spreadsheetanwendungen, Nachrichtendienstanwendungen, Medienstreaminganwendungen, Anwendungen für soziale Netzwerke und Spielanwendungen.
• Der nicht-vorübergehende Speicher kann aus physischen Geräten bestehen, die Programme (z. B. Sequenzen von Instruktionen) oder Daten (z. B. Programmstatus-Informationen) auf temporärer oder permanenter Basis für die Nutzung durch ein Computergerät speichern. Der nicht-vorübergehende Speicher kann flüchtiger und/oder nichtflüchtiger adressierbarer Halbleiterspeicher sein. Beispiele nichtflüchtigen Speichers enthalten, aber sind nicht limitiert auf, Flashspeicher und Read Only Memory (ROM)/Programmable Read Only Memory (PROM)/Erasable Programmable Read Only Memory (EPROM)/Electronically Erasable Programmable Read Only Memory (EEPROM) (z. B. typischerweise genutzt für Firmware wie etwa Bootanwendungen). Beispiele von flüchtigem Speicher enthalten, sind aber nicht limitiert auf, Random Access Memory (RAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Phase Change Memory (PCM) sowie Disks und Kassetten.
• 7 ist eine schematische Darstellung eines exemplarischen Computergeräts 700, das genutzt werden kann, um die in diesem Dokument beschriebenen Systeme und Verfahren zu implementieren. Das Computergerät 700 soll verschiedene digitale Computer wie zum Beispiel Laptops, Desktops, Workstations, Personal Digital Assistants, Server, Blade-Server, Hauptplatinen und andere geeignete Computer darstellen. Die hier gezeigten Komponenten, ihre Verbindungen und Beziehungen und ihre Funktionen sollen nur exemplarisch sein und sollen Implementierungen der in diesem Dokument beschriebenen und/oder beanspruchten Erfindungen nicht einschränken.
• Das Computergerät 700 beinhaltet einen Prozessor 710 (z. B. Datenverarbeitungshardware), einen Speicher 720, ein Speichergerät 730, eine Hochgeschwindigkeitsschnittstelle 740, die verbunden ist mit Speicher 720 und Hochgeschwindigkeits-Erweiterungsports 750, und eine Niedriggeschwindigkeitsschnittstelle 760 zum Anschluss an den Niedriggeschwindigkeitsbus 770 und das Speichergerät 730. Alle der Komponenten 710, 720, 730, 740, 750 und 760 sind mithilfe verschiedener Busse miteinander verbunden und können an einer gemeinsamen Hauptplatine oder auf andere Weise, wie geeignet, angebracht sein. Der Prozessor 710 kann Anweisungen zur Ausführung innerhalb des Computergeräts 700 verarbeiten, einschließlich Anweisungen, die im Speicher 720 oder auf dem Speichergerät 730 gespeichert sind, um grafische Informationen für eine grafische Benutzeroberfläche (GUI) auf einem externen Eingabe-/Ausgabegerät anzuzeigen, wie z. B. die Anzeige 780, die mit der schnellen Schnittstelle 740 verbunden ist. In anderen Implementierungen können mehrere Prozessoren und/oder mehrere Busse verwendet sein, wie angemessen, zusammen mit mehreren Speichern und Speichertypen. Außerdem können mehrere Computergeräte 700 verbunden sein, wobei jedes Gerät Teile der nötigen Operationen bereitstellt (z. B. als Serverbank, eine Gruppe von Blade-Servern oder ein Multiprozessor-System). Die Datenspeicherhardware 710 (z. B. Prozessor) kann das streamende Berechnungssystem 100 ausführen.
• Der Speicher 720 (z. B. Hardwarespeicher) speichert Informationen nichtvergänglich innerhalb des Computergeräts 700. Der Speicher 720 kann ein computerlesbares Medium, ein flüchtiges Speichergerät oder nicht flüchtiges Speichergerät sein. Der nicht-vorübergehende Speicher 720 kann aus physischen Geräten bestehen, die Programme (z. B. Sequenzen von Instruktionen) oder Daten (z. B.
• Programmstatus-Informationen) auf temporärer oder permanenter Basis für die Nutzung durch das Computergerät 700 speichern. Beispiele nichtflüchtigen Speichers enthalten, aber sind nicht limitiert auf, Flashspeicher und Read Only Memory (ROM)/Programmable Read Only Memory (PROM)/Erasable Programmable Read Only Memory (EPROM)/Electronically Erasable Programmable Read Only Memory (EEPROM) (z. B. typischerweise genutzt für Firmware wie etwa Bootanwendungen). Beispiele von flüchtigem Speicher enthalten, sind aber nicht limitiert auf, Random Access Memory (RAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Phase Change Memory (PCM) sowie Disks und Kassetten.
• Das Speichergerät 730 kann Massenspeicher für das Computergerät 700 bereitstellen. In manchen Implementationen ist die Speichervorrichtung 730 ein computerlesbares Medium. In verschiedenen unterschiedlichen Implementierungen kann die Speichervorrichtung 730 eine Diskettenvorrichtung, eine Festplattenvorrichtung, eine optische Plattenvorrichtung oder eine Bandvorrichtung, ein Flash-Speicher oder anderer ähnlicher Festspeicher oder eine Anordnung von Vorrichtungen, die Vorrichtungen in einem Speichernetzwerk oder andere Konfigurationen beinhalten, sein. In zusätzlichen Implementationen ist ein Computerprogrammprodukt konkret in einem Informationsträger ausgeführt. Das Computerprogrammprodukt enthält Anweisungen, die, wenn sie ausgeführt werden, ein oder mehrere Verfahren ausführen, wie die oben beschriebenen. Der Informationsträger ist ein computer- oder maschinenlesbares Medium, wie der Speicher 720, das Speichergerät 730 oder der Prozessorspeicher 710.
• Der High-Speed-Controller 740 verwaltet bandbreitenintensive Operationen für das Computergerät 700, während der Low-Speed-Controller 760 weniger bandbreitenintensive Operationen verwaltet. Eine solche Zuordnung von Aufgaben ist nur exemplarisch. In einer Ausführungsform ist der schnelle Schnittstellencontroller 740 mit dem Speicher 720, dem Display 780 (z. B. über einen Grafikprozessor oder -beschleuniger) und mit schnellen Erweiterungsanschlüssen 750 verbunden, die verschiedene Erweiterungskarten aufnehmen können (nicht dargestellt). In manchen Implementationen ist die Niedergeschwindigkeitssteuerung 760 mit dem Speichergerät 730 und dem Niedergeschwindigkeits-Erweiterungsanschluss 770 verbunden. Der langsame Erweiterungsanschluss 770, der verschiedene Kommunikationsanschlüsse (z. B. USB, Bluetooth, Ethernet, Funkethernet) beinhalten kann, kann mit einem oder mehreren Eingabe-/Ausgabe-Geräten, wie z. B. einer Tastatur, einem Zeigegerät, einem Scanner oder einem Netzwerkgerät wie z. B. einem Switch oder Router, z. B. über einen Netzwerkadapter verbunden sein.
• Das Computergerät 700 kann auf eine Anzahl verschiedener Formen implementiert sein, wie in der Figur dargestellt. Zum Beispiel kann es als Standardserver 700a oder mehrmals in einer Gruppe solcher Server 700a, als Laptopcomputer 700b oder als Teil eines Rack-Serversystems 700c implementiert sein.
• Verschiedene Implementierungen der hier beschriebenen Systeme und Techniken können in digitaler elektronischer Verschaltung, integrierter Verschaltung, in speziell konstruierten ASICs (anwendungsspezifische integrierte Schaltungen), in Computer-Hardware, Firmware, Software und/oder Kombinationen davon realisiert werden. Diese verschiedenen Implementierungen können eine Implementierung in einem oder mehreren Computerprogrammen beinhalten, die auf einem programmierbaren System ausführbar und/oder interpretierbar sind, das mindestens einen programmierbaren Prozessor beinhaltet, der ein spezieller Prozessor oder ein Prozessor für allgemeine Zwecke sein kann, und der zum Empfangen von Daten und Anweisungen von und zum Übertragen von Daten und Anweisungen an ein Speichersystem, mindestens eine Eingabevorrichtung und mindestens eine Ausgabevorrichtung gekoppelt ist.
• Diese Computerprogramme (auch bekannt als Programme, Software, Anwendungen oder Code) enthalten Maschinenbefehle für einen programmierbaren Prozessor und können in eine hochrangige verfahrens- und/oder objektorientierte Programmiersprache und/oder in eine Montage-/Maschinensprache umgesetzt werden. Wie hier verwendet, bezeichnen die Begriffe „maschinenlesbares Medium” und „computerlesbares Medium” ein beliebiges Computerprogrammprodukt, ein nicht-vorübergehendes computerlesbares Medium, eine Vorrichtung und/oder ein Gerät (z. B. Magnetplatten, optische Platten, nichtflüchtige Speicher, programmierbare Logikbausteine (PLDs), die verwendet werden, um einem programmierbaren Prozessor Maschinenanweisungen und/oder Daten bereitzustellen, einschließlich eines maschinenlesbaren Mediums, das Maschinenanweisungen als ein maschinenlesbares Signal empfängt. Der Begriff „maschinenlesbares Signal” bezeichnet ein beliebiges Signal, das verwendet wird, um einem programmierbaren Prozessor Maschinenanweisungen und/oder Daten bereitzustellen.
• Implementierungen des Gegenstands und die in dieser Spezifikation beschriebenen funktionalen Operationen können in digitalen elektronischen Schaltungen oder in Computersoftware, Firmware oder Hardware implementiert werden, einschließlich in den in dieser Spezifikation offengelegten Strukturen und ihren strukturellen Äquivalenten oder in Kombinationen von einer oder mehrerer der Strukturen. Darüber hinaus kann der in dieser Spezifikation beschriebene Gegenstand als ein oder mehrere Computerprogrammprodukte implementiert werden, d. h. als ein oder mehrere Module von Computerprogrammanweisungen, die auf einem computerlesbaren Medium zur Ausführung kodiert sind, durch oder zur Kontrolle von datenverarbeitenden Apparaten. Das computerlesbare Medium kann ein maschinenlesbares Speichergerät, ein maschinenlesbares Speichersubstrat, ein Speichergerät, eine Stoffzusammensetzung, die ein maschinenlesbares verbreitetes Signal bewirkt, oder eine Kombination aus einem oder mehreren davon sein. Die Begriffe „datenverarbeitender Apparat”, „Computergerät” und „Computerprozessor” beinhalten jegliche Apparate, Geräte und Maschinen zur Verarbeitung von Daten, einschließlich beispielsweise eines programmierbaren Prozessors, eines Computers oder mehrerer Prozessoren oder Computer. Der Apparat kann neben der Hardware auch einen Code einschließen, der eine Ausführungsumgebung für das betreffende Computerprogramm erstellt, z. B. einen Code, der Prozessor-Firmware, einen Protokollstapel, ein Datenbank-Managementsystem, ein Betriebssystem oder eine Kombination einer oder mehrerer der genannten darstellt. Ein propagiertes Signal ist ein künstlich erzeugtes Signal, z. B. ein maschinell erzeugtes elektrisches, optisches oder elektromagnetisches Signal, das für das Verschlüsseln von Information für die Übertragung auf einen geeigneten Empfängerapparat erzeugt wird.
• Ein Computerprogramm (auch als eine Applikation, Programm, Software, Softwareapplikation, Script oder Code bezeichnet) kann in einer beliebigen Form von Programmiersprache geschrieben sein, einschließlich kompilierter oder interpretierter Sprachen, und das Computerprogramm kann in jeder beliebigen Form eingesetzt sein, darunter als unabhängiges Programm oder als ein Modul, Komponente, Subroutine, oder andere Einheit, die zur Benutzung in einer Rechenumgebung geeignet ist. Ein Computerprogramm entspricht nicht unbedingt einer Datei in einem Dateisystem. Ein Programm kann in einem Teil einer Datei gespeichert sein, die andere Programme oder Daten enthält (z. B. ein oder mehrere Scripts, die in einem Dokument in Markup-Sprache gespeichert sind), in einer einzelnen Datei speziell für das betreffende Programm oder in mehreren koordinierten Dateien (z. B. Dateien, die ein oder mehrere Module, Unterprogramme oder Teile von Code speichern). Ein Computerprogramm kann auf einem Computer oder mehreren Computer eingerichtet sein oder ausgeführt werden, die an einem Standort angeordnet sind oder über mehrere Standorte verteilt sind und über ein Kommunikationsnetz verbunden sind.
• Die in dieser Beschreibung dargestellten Prozesse und Logik-Abläufe können durch einen oder mehrere programmierbare Prozessoren durchgeführt werden, die ein oder mehrere Computerprogramme ausführen, um Funktionen durch das Arbeiten mit Eingabedaten und das Erzeugen von Ausgaben auszuführen. Die Prozesse und die logischen Abläufe können auch durch logische Sonderzweckschaltungen durchgeführt werden, und der Apparat kann als Sonderzweckschaltungen implementiert werden, z. B. ein FPGA (Field Programmable Gate Array) oder eine ASIC (anwendungsspezifische integrierte Schaltung).
• Prozessoren, die für die Durchführung eines Computerprogramms geeignet sind, schließen beispielsweise sowohl allgemeine und als auch Spezial-Mikroprozessoren sowie alle Arten eines oder mehrerer Prozessoren jeglicher Art Digitalrechner ein. Ein Prozessor nimmt im Allgemeinen Anweisungen und Daten von einem Festspeicher oder einem Arbeitsspeicher oder von beiden entgegen. Die wesentlichen Elemente eines Computers sind ein Prozessor für das Ausführen von Befehlen und ein oder mehrere Speichergeräte für das Speichern von Befehlen und Daten. Im Allgemeinen beinhaltet ein Computer eine oder mehrere Massenspeichergeräte für das Speichern von Daten, z. B. Magnet-, magnetooptische oder optische Disketten, um Daten zu empfangen und/oder zu übertragen. Jedoch muss ein Computer solche Geräte nicht haben. Außerdem kann ein Computer in ein anderes Gerät eingebettet sein, z. B. in ein Mobiltelefon, einen Organizer (PDA), einen mobilen Audioplayer, einen GPS-Empfänger (Global Positioning System), um nur einige zu nennen. Computerlesbare Medien, die für das Speichern von Computerprogrammbefehlen und -daten geeignet sind, schließen alle Formen von Permanentspeichern, Medien- und Speichergeräten ein, einschließlich beispielsweise Halbleiter-Speichergeräte, z. B. EPROM, EEPROM und Flash-Speicher; Magnetdisketten, z. B. interne Festplatten oder Wechselplatten; magnetooptische Disketten; und CD-ROMs und DVD-ROMs. Der Prozessor und der Speicher können durch logische Sonderzweckschaltungen ergänzt werden oder darin eingebaut sein.
• Um die Interaktion mit einem Benutzer zu ermöglichen, können ein oder mehrere Aspekte der Offenbarung auf einem Computer implementiert werden, der ein Anzeigegerät für die Anzeige von Informationen für den Benutzer hat, z. B. einen CRT(Kathodenstrahlröhre) oder LCD-Bildschirm (Flüssigkristallanzeige) oder einen Touchscreen, und optional eine Tastatur und ein Zeigegerät, z. B. eine Maus oder einen Trackball, über die der Benutzer Eingaben an den Computer senden kann. Es können auch andere Arten von Geräte verwendet werden, um für eine Interaktion mit einem Benutzer zu sorgen; beispielsweise kann eine dem Benutzer gelieferte Rückkopplung beliebiger Form von sensorischer Rückkopplung vorliegen, z. B. eine visuelle Rückkopplung, auditive Rückkopplung oder taktile Rückkopplung; und die Eingabe vom Benutzer kann in beliebiger Form empfangen werden, einschließlich akustischer, Sprach- oder taktiler Eingabe. Darüber hinaus kann ein Computer über das Senden von Dokumenten an und das Empfangen von Dokumenten von einer Einrichtung, die vom Benutzer verwendet wird, mit einem Benutzer interagieren; beispielsweise über das Senden von Webpages an einen Webbrowser auf dem Clientgerät des Benutzers als Antwort auf die vom Webbrowser empfangenen Aufforderungen.
• Ein oder mehrere Aspekte der Offenbarung können in einem Rechensystem implementiert werden, das eine Back-End-Komponente umfasst, wie beispielsweise einen Datenserver, oder das eine Middleware-Komponente umfasst, wie beispielsweise einen Anwendungsserver, oder das eine Front-End-Komponente beinhaltet, wie beispielsweise eine Client-Recheneinheit, die eine grafische Benutzeroberfläche oder einen Web-Browser besitzt, durch die ein Benutzer mit einer Implementierung des Technikthemas, das in der vorliegenden Spezifikation beschrieben ist, interagieren kann oder eine beliebige Kombination von einer oder mehreren solcher Back-End-, Middleware- oder Front-End-Komponenten. Die Komponenten des Systems können durch eine beliebige Form oder ein beliebiges Medium digitaler Datenkommunikation miteinander verbunden sein, z. B. ein Kommunikationsnetz. Zu Beispielen für Kommunikationsnetze zählen ein lokales Netzwerk („LAN”), ein Fernnetzwerk („WAN”), eine netzübergreifende Verbindung (z. B. das Internet) und Peer-to-Peer Netzwerke (z. B. Ad-Hoc Peer-to-Peer Netzwerke).
• Das Rechensystem kann Client und Server beinhalten. Ein Client und Server befinden sich im Allgemeinen ortsfern voneinander und interagieren typischerweise über ein Kommunikationsnetz. Die Beziehung von Client und Server entsteht aufgrund der Computerprogramme, die auf den jeweiligen Computern laufen und eine gegenseitige Client-Server-Beziehung haben. Bei einigen Implementierungen überträgt ein Server Daten (z. B. eine HTML-Seite) auf ein Client-Gerät (z. B. zum Anzeigen von Daten für einen Benutzer, der mit dem Client-Gerät interagiert, sowie zum Empfangen von Benutzereingaben von diesem Benutzer). Am Client-Gerät erzeugte Daten (z. B. infolge der Benutzerinteraktion) können vom Client-Gerät am Server empfangen werden.
• Während diese Spezifikation viele Einzelheiten enthält, sollten diese nicht als Beschränkungen des Umfangs der Offenbarung oder von dem, was beansprucht werden könnte, sondern vielmehr als Beschreibungen von bestimmten charakteristischen Merkmalen von bestimmten Implementierungen der Offenbarung ausgelegt werden. Bestimmte Eigenschaften, die in dieser Spezifikation im Kontext gesonderter Implementierungen beschrieben sind, können auch in Kombination in einer einzelnen Implementierung implementiert werden. Umgekehrt können verschiedene, im Kontext einer einzelnen Implementierung beschriebene Merkmale auch in mehreren Implementierungen separat oder in einer beliebigen geeigneten Unterkombination implementiert werden. Außerdem können ein oder mehrere Merkmale einer beanspruchten Kombination in manchen Fällen aus der Kombination herausgelöst werden, auch wenn die Merkmale vorstehend als in gewissen Kombinationen funktionierend beschrieben oder gar als eine Kombination beansprucht werden, und die beanspruchte Kombination kann an eine Unterkombination oder eine Variation einer Unterkombination verwiesen werden.
• Ebenso werden Tätigkeiten in den Zeichnungen zwar in einer bestimmten Reihenfolge dargestellt, aber dies sollte nicht als Anfordernis verstanden werden, dass solche Tätigkeiten in der bestimmten gezeigten Reihenfolge oder in einer aufeinanderfolgenden Reihenfolge ausgeführt werden müssen oder dass alle dargestellten Tätigkeiten ausgeführt werden müssen, um erwünschte Ergebnisse zu erzielen. Unter bestimmten Umständen können Multitasking und Parallelbearbeitung vorteilhaft sein. Darüber hinaus sollte die Trennung verschiedener Systemkomponenten in den oben beschriebenen Ausführungsformen nicht in allen Ausführungsformen erforderlich aufgefasst werden, und es versteht sich, dass die beschriebenen Programmkomponenten und Systeme im Allgemeinen zusammen in ein einziges Softwareprodukt integriert oder zu mehreren Softwareprodukten verkapselt werden können.
• Es wurde eine Reihe von Implementierungen beschrieben. Trotzdem versteht es sich, dass verschiedene Veränderungen vorgenommen werden können, ohne vom Geist und Umfang der Erfindung abzuweichen. Dementsprechend liegen andere Implementierungen im Geltungsbereich der folgenden Ansprüche. Die in den Ansprüchen ausgeführten Vorgänge können beispielsweise in einer anderen Reihenfolge ausgeführt werden und dennoch gewünschte Ergebnisse erzielen.

Claims (12)

1. System, das Folgendes umfasst: Datenverarbeitungshardware (710); und Hardwarespeicher (720) in Verbindung mit der Datenverarbeitungshardware (710), wobei der Hardwarespeicher (720) Instruktionen speichert, die, wenn auf der Datenverarbeitungshardware (710) ausgeführt, die Datenverarbeitungshardware (710) dazu bringen, Operationen auszuführen, die Folgendes umfassen: das Erhalten von Daten (10), entsprechend entweder Streamingdaten (10) oder Batchdaten; die Ermittlung eines Inhalts der erhaltenen Daten (10) für die Berechnung; das Ermitteln einer Ereigniszeit der Daten (10) zur Aufteilung der Daten (10); das Ermitteln einer Verarbeitungszeit zur Ausgabe von Ergebnissen der erhaltenen Daten (10); und das Ausgeben mindestens eines Teils der Ergebnisse der erhaltenen Daten (10) basierend auf der Ereigniszeit und der Verarbeitungszeit.
2. System nach Anspruch 1, worin die Operationen weiterhin die Gruppierung der erhaltenen Daten (10) in Fenster (330, 340, 500) umfassen, basierend auf der Ereigniszeit, wobei die Fenster (330, 340, 500) eines der Folgenden umfassen: fixierte Fenster (330), definiert von einer statischen Zeitperiode, wobei jedes fixierte Fenster (330) innerhalb der zugewiesenen Zeitperiode auf alle Daten (10) angewandt wird; gleitende Fenster (340), definiert von einer Zeitperiode und einer Gleitperiode, wobei jedes gleitende Fenster (340) innerhalb der zugewiesenen Zeitperiode auf alle Daten (10) angewandt wird und einer Startzeit zugewiesen ist, die durch die Gleitperiode sich von einer Startzeit eines direkt vorangehenden Fensters unterscheidet; Sitzungsfenster (500), definiert von einer Timeout-Lücke, wobei jedes Sitzungsfenster (500) auf eine Untermenge der Daten (10) angewandt wird, innerhalb einer Zeitspanne kleiner als die zugehörige Timeout-Lücke; oder benutzerdefinierte Fenster, definiert von einem Paar an Funktionen.
3. System nach Anspruch 1 oder 2, worin die Operationen weiterhin umfassen: das Zuweisen eines zusammenführbaren Fensters (330, 340, 500) für jedes Element der empfangenen Daten (10), wobei jedes Element einen ihm zugewiesenen Eingabezeitstempel trägt und jedes zusammenführbare Fenster (330, 340, 500) einen vordefinierten Zeitbereich nach dem Eingabezeitstempel für das zugehörige Fenster (330, 340, 500) ausweitet; das Zusammenführen von zwei oder mehr zusammenführbaren Fenstern (330, 340, 500), die demselben Schlüssel angehören, die sich in ein einziges zusammengeführtes Fenster (330, 340, 500) überlappen; und das Setzen eines zugehörigen Ausgabezeitstempels für jedes Element auf einen Wert größer oder gleich einer frühesten Zeit in zugehörigen zusammengeführten Fenster (330, 340, 500) oder dem zugehörigen zusammenführbaren Fenster (330, 340, 500).
4. System nach Anspruch 1, worin das einzelne zusammengeführte Fenster (330, 340, 500) einen zugeordneten Zeitbereich größer des vordefinierten Zeitbereichs beinhaltet.
5. System nach einem der Ansprüche 1 bis 4, worin die Operationen weiterhin umfassen, wenn die erhaltenen Daten (10) den Streamingdaten (10) entsprechen: das Gruppieren der Streamingdaten (10) in Fenster (330, 340, 500); das Setzen eines Eingabezeitstempels auf ein Element der Streamingdaten (10); und wenn der Eingabezeitstempel auf dem Element früher eintritt als ein Wasserzeichen: das Ermitteln, ob die Streamingdaten (10) verspätete Streamingdaten (10) umfassen; und eines der Folgenden: das Aussortieren der verspäteten Streamingdaten (10); oder das Zulassen der verspäteten Streamingdaten (10), indem ein kopiertes Fenster (330, 340, 500) in einer Ausgabe für die verspäteten Streamingdaten (10) erzeugt wird.
6. System nach den Ansprüchen 1 bis 5, worin die Operationen weiterhin umfassen: das Gruppieren einer ersten Untermenge der erhaltenen Daten (10) in ein Fenster (330, 340, 500), wobei das Fenster (330, 340, 500) eine Unterereigniszeit der Datenuntermenge definiert; das Aggregieren eines ersten Ergebnisses der ersten Datenuntermenge für das Fenster (330, 340, 500); und das Ermitteln einer Trigger-Zeit, um das erste aggregierte Ergebnis der ersten Datenuntermenge auszugeben, wobei die Trigger-Zeit mindestens eines der Folgenden umfasst: wenn ein Wasserzeichen das Ende des Fensters (330, 340, 500) erreicht; jeden Grenzwert an Sekunden einer Walltime; nach dem Empfangen eines Interpunktionsdatensatzes, der das Fenster (330, 340, 500) terminiert; jeden Grenzwert an Datensätzen; nachdem sich beliebige Benutzerlogik dazu entschließt, auszulösen; oder nach einer beliebigen Kombination konkreter Trigger.
7. System nach Anspruch 6, worin die Operationen weiterhin umfassen, beim Ermitteln der Trigger-Zeit zur Ausgabe des ersten aggregierten Ergebnisses der ersten Datenuntermenge, das Abstoßen des ersten aggregierten Ergebnisses von der Nutzung bei der Aggregierung von Ergebnissen von späteren Untermengen der erhaltenen Daten (10).
8. System nach Anspruch 6, worin die Operationen weiterhin umfassen, beim Ermitteln der Trigger-Zeit zur Ausgabe des ersten aggregierten Ergebnisses der ersten Datenuntermenge: das Speichern einer Kopie des ersten aggregierten Ergebnisses in einem dauerhaften Zustand innerhalb des Hardwarespeichers (720) in Verbindung mit der Datenverarbeitungshardware (710); und das Verfeinern eines nächsten Aggregats (20) als Ergebnis einer späteren Untermenge mit dem ersten aggregierten Ergebnis.
9. System nach Anspruch 6, worin die Vorgänge ferner Folgendes umfassen: beim Bestimmen der Triggerzeit die Ausgabe des ersten aggregierten Ergebnisses der ersten Datenuntermenge sowie das Speichern einer Kopie des ersten aggregierten Ergebnisses in einem dauerhaften Zustand innerhalb des Hardwarespeichers (720) in Verbindung mit der Datenverarbeitungshardware (710); und wenn ein nächstes aggregiertes Ergebnis einer späteren Datenuntermenge, die dem Fenster (330, 340, 500) zugeordnet ist, ausgibt: das Ausgeben einer Retraktion des ersten aggregierten Ergebnisses; und das Ausgeben eines kombinierten Sitzungsergebnisses für das Fenster (330, 340, 500).
10. System nach Anspruch 6, worin die Vorgänge des Weiteren umfassen: das Empfangen eines späten Datenpunktes nach der Gruppierung der ersten Datenuntermenge in das Fenster (330, 340, 500), wobei der späte Datenpunkt dem Fenster (330, 340, 500) zugeordnet ist; und das Abstoßen des verspäteten Datenpunktes.
11. System nach Anspruch 6, worin die Vorgänge des Weiteren umfassen: das Empfangen eines späten Datenpunktes nach der Gruppierung der ersten Datenuntermenge in das Fenster (330, 340, 500), wobei der späte Datenpunkt dem Fenster (330, 340, 500) zugeordnet ist; und das Akkumulieren des verspäteten Datenpunktes in das Fenster (330, 340, 500), um das erste aggregierte Ergebnis mit dem verspäteten Datenpunkt zu verfeinern.
12. System nach Anspruch 6, worin die Operationen des Weiteren umfassen: das Empfangen eines späten Datenpunktes nach der Gruppierung der ersten Datenuntermenge in das Fenster (330, 340, 500), wobei der späte Datenpunkt dem Fenster (330, 340, 500) zugeordnet ist; das Aggregieren eines kombinierten Ergebnisses (20) der ersten Datenuntermenge und des verspäteten Datenpunktes; und das Ausgeben des kombinierten Ergebnisses (20).

Images