Comprendre l'agrégation de fenêtres dans les requêtes continues

Pour demander de l'aide ou envoyer des commentaires concernant cette fonctionnalité, envoyez un e-mail à l'adresse bq-continuous-queries-feedback@google.com.

Les requêtes continues BigQuery acceptent les agrégations et les fenêtrages en tant qu'opérations avec état. Les opérations avec état permettent aux requêtes continues d'effectuer des analyses complexes qui nécessitent de conserver des informations sur plusieurs lignes ou intervalles de temps. Cette fonctionnalité vous permet de calculer des métriques au fil du temps (par exemple, une moyenne sur 30 minutes) en stockant les données nécessaires en mémoire pendant l'exécution de la requête.

Les fonctions de fenêtrage attribuent des données à des composants logiques, ou fenêtres, en fonction de l'heure système, qui indique l'heure d'engagement de la transaction ayant effectué la modification. Dans BigQuery, ces fonctions sont des fonctions de valeur de table (TVF) qui renvoient une table incluant toutes les colonnes d'origine et deux colonnes supplémentaires : window_start et window_end. Ces colonnes identifient l'intervalle de temps pour chaque fenêtre. Pour en savoir plus sur les opérations avec état, consultez Opérations avec état compatibles.

Les TVF de fenêtrage ne sont compatibles qu'avec les requêtes continues BigQuery.

Les TVF de fenêtrage sont distinctes des appels de fonctions de fenêtrage.

Fonctions d'agrégation compatibles

Les fonctions d'agrégation suivantes sont acceptées :

Fonctions d'agrégation non compatibles

Les fonctions d'agrégation suivantes ne sont pas compatibles :

Fonction TUMBLE

La fonction TUMBLE attribue des données à des intervalles de temps sans chevauchement (fenêtres Tumbling) de taille spécifiée. Par exemple, un intervalle de cinq minutes regroupe les événements dans des intervalles distincts tels que [2026-01-01 12:00:00, 2026-01-01 12:05:00) et [2026-01-01 12:05:00, 2026-01-01 12:10:00). Une ligne avec une valeur d'horodatage 2026-01-01 12:03:18 est attribuée à la première fenêtre. Comme ces fenêtres sont disjointes et ne se chevauchent pas, chaque élément avec un code temporel est attribué à une seule fenêtre.

Le schéma suivant montre comment la fonction TUMBLE attribue des événements à des intervalles de temps non chevauchants :

La fonction TUMBLE attribue des événements à des intervalles de temps qui ne se chevauchent pas.

Vous pouvez utiliser cette fonction dans le traitement des événements en temps réel pour regrouper les événements par plages horaires avant d'effectuer des agrégations.

Syntaxe

TUMBLE(TABLE table, "timestamp_column", window_size)

Définitions

  • table : nom de la table BigQuery. Il doit s'agir d'une table BigQuery standard encapsulée dans la fonction APPENDS. Le mot TABLE doit précéder cet argument.

  • timestamp_column : littéral STRING qui spécifie le nom de la colonne de la table d'entrée contenant l'heure de l'événement. Les valeurs de cette colonne attribuent chaque ligne à une fenêtre. La colonne _CHANGE_TIMESTAMP, qui définit l'heure système BigQuery, est la seule timestamp_column acceptée. Les colonnes définies par l'utilisateur ne sont pas acceptées.

  • window_size : valeur INTERVAL qui définit la durée de chaque fenêtre glissante. Les fenêtres ne peuvent pas dépasser 24 heures. Exemple : INTERVAL 30 SECOND.

Sortie

La fonction TUMBLE renvoie un résultat avec les colonnes suivantes :

  • Toutes les colonnes de la table d'entrée au moment de l'exécution de la requête.

  • window_start : valeur TIMESTAMP qui indique l'heure de début incluse de la période à laquelle appartient l'enregistrement.

  • window_end : valeur TIMESTAMP qui indique l'heure de fin exclusive de la période à laquelle appartient l'enregistrement.

Matérialisation des sorties

Dans une requête continue BigQuery, une agrégation par fenêtre ne produit pas de résultat pour un intervalle de temps spécifique tant que BigQuery n'a pas finalisé ou fermé cette fenêtre. Ce comportement garantit que BigQuery n'émet les résultats agrégés qu'après avoir traité toutes les données pertinentes pour cette fenêtre.

Par exemple, si vous effectuez une agrégation de fenêtre TUMBLE de cinq minutes sur une table user_clickstream, les résultats pour l'intervalle [10:15; 10:20) ne sont émis qu'après que la requête a traité les enregistrements avec un _CHANGE_TIMESTAMP de 10h20 ou plus tard. À ce moment-là, BigQuery considère que la fenêtre est fermée. De plus, une fenêtre s'ouvre et commence à accumuler des données dès que le premier enregistrement appartenant à cette plage horaire spécifique apparaît.

Tant qu'une fenêtre reste ouverte, BigQuery doit conserver les résultats d'agrégation intermédiaires. Cela nécessite de stocker l'état, ce qui signifie que BigQuery doit conserver les résultats d'agrégation intermédiaires. Étant donné que cet état doit rester dans la mémoire active jusqu'à la fermeture de la fenêtre, l'utilisation de durées de fenêtre plus longues ou le traitement de flux à volume élevé entraînent une utilisation plus importante des emplacements pour gérer la quantité accrue de contexte stocké. Pour en savoir plus, consultez Considérations sur les tarifs.

Limites

  • La fonction TUMBLE n'est acceptée que dans les requêtes continues BigQuery.
  • Lorsque vous démarrez une requête continue avec la fonction TUMBLE, vous ne pouvez utiliser que la fonction APPENDS. La fonction CHANGES n'est pas acceptée.
  • La colonne d'heure système BigQuery définie par _CHANGE_TIMESTAMP est la seule timestamp_column acceptée. Les colonnes définies par l'utilisateur ne sont pas acceptées.
  • Les fenêtres ne peuvent pas dépasser 24 heures.
  • Lorsque la fonction de fenêtrage TUMBLE s'exécute, elle génère deux colonnes de sortie supplémentaires : window_start et window_end. Vous devez inclure au moins l'une de ces colonnes dans l'instruction GROUP BY de l'instruction SELECT qui effectue l'agrégation de la fenêtre.
  • Lorsque vous utilisez la fonction TUMBLE avec des jointures de requêtes continues, vous devez respecter toutes les limites des jointures de requêtes continues.

Remarques sur les tarifs

Les requêtes continues BigQuery vous sont facturées en fonction de la capacité de calcul (emplacements) consommée pendant l'exécution de la tâche. Ce modèle basé sur le calcul s'applique également aux opérations avec état, comme le fenêtrage. Comme le fenêtrage nécessite que BigQuery stocke l'état pendant que la requête est active, il consomme des ressources de créneaux supplémentaires. En général, plus le contexte ou les données stockées dans une fenêtre sont nombreux (par exemple, lorsque vous utilisez des durées de fenêtre plus longues), plus BigQuery doit conserver d'état. Cela permet d'utiliser davantage d'emplacements.

Exemples

La requête suivante vous montre comment interroger une table de courses en taxi pour obtenir le nombre moyen de courses, le nombre de passagers et le tarif moyen par taxi toutes les 30 minutes, et exporter ces données dans une table BigQuery :

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

Étapes suivantes