Fensteraggregation in kontinuierlichen Abfragen

Wenn Sie Unterstützung für diese Funktion benötigen oder Feedback geben möchten, senden Sie eine E-Mail an bq-continuous-queries-feedback@google.com.

BigQuery-Continuous Queries unterstützen Aggregationen und Fensterfunktionen als zustandsbehaftete Vorgänge. Mit zustandsbehafteten Vorgängen können kontinuierliche Abfragen komplexe Analysen durchführen, bei denen Informationen über mehrere Zeilen oder Zeitintervalle hinweg beibehalten werden müssen. Mit dieser Funktion können Sie Messwerte im Zeitverlauf berechnen, z. B. einen 30-Minuten-Durchschnitt, indem Sie die erforderlichen Daten während der Ausführung der Abfrage im Arbeitsspeicher speichern.

Fensterfunktionen weisen Daten basierend auf der Systemzeit logischen Komponenten oder Fenstern zu. Die Systemzeit gibt die Commit-Zeit der Transaktion an, mit der die Änderung vorgenommen wurde. In BigQuery sind diese Funktionen tabellenwertige Funktionen (Table-Valued Functions, TVFs), die eine Tabelle mit allen ursprünglichen Spalten und zwei zusätzlichen Spalten zurückgeben: window_start und window_end. In diesen Spalten wird das Zeitintervall für jedes Fenster angegeben. Weitere Informationen zu zustandsbehafteten Vorgängen finden Sie unter Unterstützte zustandsbehaftete Vorgänge.

Fensterfunktionen werden nur in BigQuery-Continuous Queries unterstützt.

Fensterfunktionen unterscheiden sich von Fensterfunktions aufrufen.

Unterstützte Aggregatfunktionen

Die folgenden Aggregatfunktionen werden unterstützt:

Nicht unterstützte Aggregatfunktionen

Die folgenden Aggregatfunktionen werden nicht unterstützt:

Die Funktion TUMBLE

Mit der Funktion TUMBLE werden Daten nicht überlappenden Zeitintervallen (rollierenden Fenstern) mit einer bestimmten Größe zugewiesen. Bei 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 überlappen, wird jedes Element mit einem Zeitstempel genau einem Fenster zugewiesen.

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

Mit der Funktion TUMBLE werden Ereignisse nicht überlappenden Zeitintervallen zugewiesen.

Sie können diese Funktion bei der Echtzeit-Ereignisverarbeitung verwenden, um Ereignisse nach Zeitbereichen zu gruppieren, bevor Sie Aggregationen ausführen.

Syntax

TUMBLE(TABLE table, "timestamp_column", window_size)

Definitionen

  • table: Der Name der BigQuery-Tabelle. Dies muss eine Standard BigQuery-Tabelle sein, die in die Funktion APPENDS eingeschlossen ist. Dem 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. Mit den Werten in dieser Spalte wird jede Zeile einem Fenster zugewiesen. 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 die inklusive Startzeit des Fensters angibt, zu dem der Datensatz gehört.

  • window_end: Ein TIMESTAMP-Wert, der die exklusive Endzeit des Fensters angibt, zu dem der Datensatz gehört.

Ausgabematerialisierung

In einer BigQuery-Continuous Query wird bei einer Fensteraggregation erst dann eine Ausgabe für ein bestimmtes Zeitintervall erzeugt, wenn BigQuery das Fenster abschließ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-Minuten-Fensteraggregation mit TUMBLE 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 später verarbeitet hat. Zu diesem Zeitpunkt betrachtet BigQuery das Fenster als geschlossen. Außerdem wird ein Fenster geöffnet und beginnt mit dem Erfassen von Daten, sobald der erste Datensatz erscheint, der zu diesem bestimmten Zeitraum gehört.

Solange ein Fenster geöffnet ist, muss BigQuery die Zwischenergebnisse der Aggregation beibehalten. Dazu muss der Status gespeichert werden, was bedeutet, dass BigQuery die Zwischenergebnisse der Aggregation beibehalten muss. Da dieser Status im aktiven Arbeitsspeicher bleiben 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 größere Menge an gespeichertem Kontext zu verwalten. Weitere Informationen finden Sie unter Kosten.

Beschränkungen

  • Die Funktion TUMBLE wird nur in BigQuery-Continuous Queries 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 BigQuery-Systemzeitspalte, die durch _CHANGE_TIMESTAMP definiert wird, ist die einzige unterstützte timestamp_column. Benutzerdefinierte Spalten werden nicht unterstützt.
  • Die Fenstergröße darf maximal 24 Stunden betragen.
  • Wenn die Fensterfunktion 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 in der SELECT-Anweisung einfügen, die die Fensteraggregation ausführt.
  • Wenn Sie die Funktion TUMBLE mit Joins in kontinuierlichen Abfragen verwenden, müssen Sie alle Beschränkungen für Joins in kontinuierlichen Abfragen einhalten.

Kosten

Bei BigQuery-Continuous Queries werden Ihnen die Kosten basierend auf der Compute-Kapazität (Slots) in Rechnung gestellt, die während der Ausführung des Jobs verbraucht wird. Dieses auf der Compute-Kapazität basierende Modell gilt auch für zustandsbehaftete Vorgänge wie Fensterfunktionen. Da BigQuery bei Fensterfunktionen 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 werden, 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 können, um alle 30 Minuten einen Streaming-Durchschnitt der Anzahl der Fahrten, der Anzahl der Fahrgäste und des durchschnittlichen Fahrpreises 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