Fensteraggregation in kontinuierlichen Abfragen

Kontinuierliche BigQuery-Abfragen unterstützen Aggregationen und Windowing als zustandsorientierte Vorgänge, mit denen Sie Streamingdaten über mehrere Zeilen oder Zeitintervalle hinweg analysieren können. Mit dieser Funktion können Sie Messwerte im Zeitverlauf berechnen, z. B. einen 30-Minuten-Durchschnitt, indem Sie den erforderlichen Status im Arbeitsspeicher speichern, während die kontinuierliche Abfrage ausgeführt wird.

Informationen zu Fensterfunktionen

Mit Windowing-Funktionen werden Daten basierend auf der Systemzeit logischen Komponenten oder Fenstern zugewiesen. Die Systemzeit gibt die Commit-Zeit der Transaktion an, die die Änderung vorgenommen hat. In BigQuery sind diese Funktionen Tabellenwertfunktionen (TVFs), die eine Tabelle mit allen ursprünglichen Spalten und zwei zusätzlichen Spalten zurückgeben: window_start und window_end. Diese Spalten geben das Zeitintervall für jedes Fenster an. Weitere Informationen zu zustandsorientierten Vorgängen finden Sie unter Unterstützte zustandsorientierte Vorgänge.

TVFs mit Fensterfunktionen werden nur mit kontinuierlichen BigQuery-Abfragen unterstützt.

Fenster-TVFs unterscheiden sich von Fensterfunktionsaufrufen.

Unterstützte Aggregationsfunktionen

Die folgenden Aggregationsfunktionen werden unterstützt:

Nicht unterstützte Aggregationsfunktionen

Die folgenden Aggregationsfunktionen werden nicht unterstützt:

Die TUMBLE-Funktion

Die Funktion TUMBLE weist Daten nicht überlappenden Zeitintervallen (Tumbling-Fenstern) einer bestimmten Größe zu. In einem 5-Minuten-Fenster werden Ereignisse beispielsweise in diskrete Intervalle wie [2026-01-01 12:00:00, 2026-01-01 12:05:00) und [2026-01-01 12:05:00, 2026-01-01 12:10:00) gruppiert. Eine Zeile mit dem Zeitstempelwert 2026-01-01 12:03:18 wird dem ersten Fenster zugewiesen. Da diese Fenster disjunkt sind und sich nicht überschneiden, wird jedes Element mit einem Zeitstempel genau einem Fenster zugewiesen.

Das folgende Diagramm zeigt, wie die Funktion TUMBLE Ereignisse nicht überlappenden Zeitintervallen zuweist:

Die Funktion TUMBLE weist Ereignisse nicht überlappenden Zeitintervallen zu.

Sie können diese Funktion in der Echtzeit-Ereignisverarbeitung verwenden, um Ereignisse nach Zeiträumen zu gruppieren, bevor Sie Aggregationen durchführen.

Syntax

TUMBLE(TABLE table, "timestamp_column", window_size)

Definitionen

  • table: Der Name der BigQuery-Tabelle. Dies muss eine BigQuery-Standardtabelle sein, die in der Funktion APPENDS verpackt ist. Diesem Argument muss das Wort TABLE vorangestellt werden.

  • timestamp_column: Ein STRING-Literal, das den Namen der Spalte in der Eingabetabelle angibt, die die Ereigniszeit enthält. Die Werte in dieser Spalte weisen jede Zeile einem Fenster zu. Die Spalte _CHANGE_TIMESTAMP, die die BigQuery-Systemzeit definiert, ist die einzige unterstützte timestamp_column. Benutzerdefinierte Spalten werden nicht unterstützt.

  • window_size: Ein INTERVAL-Wert, der die Dauer jedes rollierenden Fensters definiert. Die Fenstergröße darf maximal 24 Stunden betragen. Beispiel: INTERVAL 30 SECOND.

Ausgabe

Die Funktion TUMBLE gibt eine Ausgabe mit den folgenden Spalten zurück:

  • Alle Spalten der Eingabetabelle zum Zeitpunkt der Ausführung der Abfrage.

  • window_start: Ein TIMESTAMP-Wert, der den inklusiven Beginn des Zeitfensters angibt, zu dem der Eintrag gehört.

  • window_end: Ein TIMESTAMP-Wert, der die ausschließliche Endzeit des Fensters angibt, zu dem der Eintrag gehört.

Ausgabematerialisierung

In einer kontinuierlichen BigQuery-Abfrage erzeugt eine fensterbasierte Aggregation erst dann eine Ausgabe für ein bestimmtes Zeitintervall, wenn BigQuery dieses Fenster abschließt oder schließt. So wird sichergestellt, dass BigQuery die aggregierten Ergebnisse erst ausgibt, nachdem alle relevanten Daten für dieses Fenster verarbeitet wurden.

Wenn Sie beispielsweise eine 5-minütige TUMBLE-Fensteraggregation für eine user_clickstream-Tabelle ausführen, werden die Ergebnisse für das Intervall [10:15; 10:20) erst ausgegeben, nachdem die Abfrage Datensätze mit einem _CHANGE_TIMESTAMP von 10:20 oder höher verarbeitet hat. In diesem Moment betrachtet BigQuery das Fenster als geschlossen. Außerdem wird ein Fenster geöffnet und es werden Daten erfasst, sobald der erste Datensatz für diesen bestimmten Zeitraum angezeigt wird.

Solange ein Fenster geöffnet bleibt, muss BigQuery die Zwischenergebnisse der Aggregation beibehalten. Dazu muss der Status gespeichert werden, d. h. BigQuery muss die Zwischenergebnisse der Aggregation beibehalten. Da dieser Status im aktiven Speicher verbleiben muss, bis das Fenster geschlossen wird, führt die Verwendung längerer Fensterdauern oder die Verarbeitung von Streams mit hohem Volumen zu einer höheren Slot-Auslastung, um die erhöhte Menge an gespeichertem Kontext zu verwalten. Weitere Informationen finden Sie unter Überlegungen zu Preisen.

Beschränkungen

  • Die Funktion TUMBLE wird nur in kontinuierlichen BigQuery-Abfragen unterstützt.
  • Wenn Sie eine kontinuierliche Abfrage mit der Funktion TUMBLE starten, können Sie nur die Funktion APPENDS verwenden. Die Funktion CHANGES wird nicht unterstützt.
  • Die durch _CHANGE_TIMESTAMP definierte BigQuery-Systemzeitspalte ist die einzige unterstützte timestamp_column. Benutzerdefinierte Spalten werden nicht unterstützt.
  • Die Fenstergröße darf maximal 24 Stunden betragen.
  • Wenn die Windowing-Funktion TUMBLE ausgeführt wird, werden zwei zusätzliche Ausgabespalten erzeugt: window_start und window_end. Sie müssen mindestens eine dieser Spalten in die GROUP BY-Anweisung innerhalb der SELECT-Anweisung aufnehmen, die die Fensteraggregation ausführt.
  • Wenn Sie die Funktion TUMBLE mit Joins für kontinuierliche Abfragen verwenden, müssen Sie alle Einschränkungen für Joins für kontinuierliche Abfragen beachten.

Kosten

Bei kontinuierlichen BigQuery-Abfragen werden Ihnen die Kosten basierend auf der verbrauchten Rechenkapazität (Slots) während der Ausführung des Jobs in Rechnung gestellt. Dieses rechenbasierte Modell gilt auch für zustandsorientierte Vorgänge wie Windowing. Da BigQuery beim Windowing den „Status“ speichern muss, während die Abfrage aktiv ist, werden zusätzliche Slot-Ressourcen verbraucht. Im Allgemeinen gilt: Je mehr Kontext oder Daten in einem Fenster gespeichert sind, z. B. bei längeren Fensterdauern, desto mehr Status muss BigQuery beibehalten. Dies führt zu einer höheren Slot-Auslastung.

Beispiele

Die folgende Abfrage zeigt, wie Sie eine Tabelle mit Taxifahrten abfragen, um alle 30 Minuten die durchschnittliche Anzahl der Fahrten, die Anzahl der Fahrgäste und den durchschnittlichen Fahrpreis pro Taxi zu erhalten und diese Daten in eine Tabelle in BigQuery zu exportieren:

INSERT INTO
 `real_time_taxi_streaming.driver_stats`

WITH ride_completions AS (
 SELECT
   _CHANGE_TIMESTAMP as bq_changed_ts,
   CAST(timestamp AS DATE) AS ride_date,
   taxi_id,
   meter_reading,
   passenger_count
 FROM
   APPENDS(TABLE `real_time_taxi_streaming.taxirides`,
     CURRENT_TIMESTAMP() - INTERVAL 10 MINUTE)
 WHERE
   ride_status = 'dropoff')

 SELECT
   ride_date,
   window_end,
   taxi_id,
   COUNT(taxi_id) AS total_rides_per_half_hour,
   ROUND(AVG(meter_reading),2) AS avg_fare_per_half_hour,
   SUM(passenger_count) AS total_passengers_per_half_hour
FROM
  tumble(TABLE ride_completions,"bq_changed_ts",INTERVAL 30 MINUTE)
GROUP BY
  window_end,
  ride_date,
  taxi_id

Nächste Schritte