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

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

Les requêtes continues BigQuery sont compatibles avec les agrégations et le fenêtrage 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, comme 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 de validation de la transaction qui a effectué la modification. Dans BigQuery, ces fonctions sont des fonctions 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 de chaque fenêtre. Pour en savoir plus sur les opérations avec état, consultez la section Opérations avec état compatibles.

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

Les TVF de fenêtrage sont différentes des appels de fonction de fenêtrage.

Fonctions d'agrégation compatibles

Les fonctions d'agrégation suivantes sont compatibles :

Fonctions d'agrégation non compatibles

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

La fonction TUMBLE

La fonction TUMBLE attribue des données à des intervalles de temps non chevauchants (fenêtres glissantes) de taille spécifiée. Par exemple, une fenêtre 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 horodatage 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 de temps 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 compatible. Les colonnes définies par l'utilisateur ne sont pas compatibles.

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

Sortie

La fonction TUMBLE renvoie une sortie 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 inclusive de la fenêtre à laquelle appartient l'enregistrement.

  • window_end: valeur TIMESTAMP qui indique l'heure de fin exclusive de la fenêtre à laquelle appartient l'enregistrement.

Matérialisation de la sortie

Dans une requête continue BigQuery, une agrégation de fenêtres ne produit pas de sortie pour un intervalle de temps spécifique tant que BigQuery ne finalise pas ou ne ferme pas 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êtres TUMBLE de cinq minutes sur une table user_clickstream, les résultats de 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 10:20 ou ultérieur. À ce moment-là, BigQuery considère la fenêtre comme fermée. De plus, une fenêtre s'ouvre et commence à accumuler des données dès que le premier enregistrement appartenant à cette plage de temps 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. Comme 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îne une utilisation plus élevée des emplacements pour gérer la quantité accrue de contexte stocké. Pour en savoir plus, consultez la section Remarques sur les tarifs.

Limites

  • La fonction TUMBLE n'est compatible qu'avec 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 compatible.
  • La colonne d'heure système BigQuery définie par _CHANGE_TIMESTAMP est la seule timestamp_column compatible. Les colonnes définies par l'utilisateur ne sont pas compatibles.
  • La taille des fenêtres ne peut 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 fenêtres.
  • Lorsque vous utilisez la fonction TUMBLE avec des jointures de requêtes continues, vous devez respecter toutes les limites de jointure de requêtes continues limitations.

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 du job. Ce modèle basé sur le calcul s'applique également aux opérations avec état telles que 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 d'emplacement supplémentaires. En général, plus le contexte ou les données stockés dans une fenêtre sont importants (par exemple, lorsque vous utilisez des durées de fenêtre plus longues), plus BigQuery doit conserver d'état. Cela entraîne une utilisation plus élevée des emplacements.

Exemples

La requête suivante montre comment interroger une table de courses en taxi pour obtenir une moyenne de courses, un nombre de passagers et un 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

Étape suivante