Utiliser des jointures de flux à flux 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 sont compatibles avec JOIN en tant qu'opération 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 corréler des événements provenant de différents flux en stockant les données nécessaires en mémoire pendant l'exécution de la requête. Pour en savoir plus sur les opérations avec état, consultez Opérations avec état compatibles.

Les jointures de flux à flux sont des opérations de jointure entre deux tables ou plus qui reçoivent des données orientées dans le temps.

Types de JOIN acceptés

Les types de JOIN suivants sont acceptés par les requêtes continues :

  • JOIN de flux à flux : opération de jointure entre deux tables ou plus qui reçoivent des données orientées temps.
  • INNER JOIN.

Types de JOIN non acceptés

Les types de JOIN suivants ne sont pas acceptés par les requêtes continues :

  • Jointures de flux vers table statique : jointure dans laquelle au moins une table jointe est une table statique qui ne reçoit pas d'ingestion de données orientées temps. Les tables de dimensions sont un exemple de tables statiques.
  • Autres formes d'opérations JOIN que INNER.
  • JOIN sans clause JOIN orientée sur le temps.

Joindre des données provenant de plusieurs flux

La requête suivante vous montre comment joindre une table de trajets en taxi à une table de demandes de taxi, identifier le taxi disponible le plus proche du demandeur dans un délai de cinq minutes et exporter ces données dans une autre table BigQuery :

INSERT INTO
 `real_time_taxi_streaming.matched_rides`
SELECT
 requests.timestamp AS request_time,
 requests.request_id,
 taxis.taxi_id,
 ST_DISTANCE(
   ST_GEOGPOINT(requests.longitude, requests.latitude),
   ST_GEOGPOINT(taxis.longitude, taxis.latitude)
   ) AS distance_in_meters,
 taxis.timestamp AS taxi_available_time
FROM
 APPENDS (TABLE `real_time_taxi_streaming.ride_requests`,
   CURRENT_TIMESTAMP() - INTERVAL 10 MINUTE) AS requests
INNER JOIN
 APPENDS (TABLE `real_time_taxi_streaming.taxirides`,
   CURRENT_TIMESTAMP() - INTERVAL 10 MINUTE) AS taxis
ON
 requests.geohash = taxis.geohash
WHERE
 taxis.ride_status = 'available'
 AND taxis._CHANGE_TIMESTAMP BETWEEN(requests._CHANGE_TIMESTAMP - INTERVAL 5 MINUTE) AND requests._CHANGE_TIMESTAMP
 AND ST_DWITHIN(
   ST_GEOGPOINT(requests.longitude, requests.latitude),
   ST_GEOGPOINT(taxis.longitude, taxis.latitude),
   2000 -- Distance in meters
   );

Points à prendre en compte pour les jointures

Les sections suivantes décrivent les éléments à prendre en compte lors de l'exécution d'une jointure de flux à flux.

Limites

  • Seules les opérations INNER JOIN sont acceptées. Les autres formes, comme LEFT ou FULL OUTER, ne le sont pas.
  • Chaque côté de l'opération INNER JOIN doit spécifier une heure de début pour la requête continue.
  • En plus d'une clé de jointure (par exemple, table1.user_id = table2.user_id), la clause JOIN doit inclure une condition permettant de limiter la colonne de code temporel à un intervalle constant. Cette condition limite la durée pendant laquelle le système attend qu'un événement correspondant arrive dans l'autre flux. Par exemple, vous pouvez spécifier qu'un événement d'un flux ne peut être joint à un événement d'un autre flux que si leurs codes temporels se trouvent dans un intervalle de cinq minutes. Vous n'êtes pas limité aux intervalles symétriques. Par exemple, vous pouvez utiliser un intervalle de cinq minutes d'un côté de la condition de jointure et un intervalle d'une heure de l'autre côté.
  • Lorsque vous démarrez une requête continue avec une jointure de flux à flux, seule la fonction APPENDS est acceptée. La fonction CHANGES n'est pas acceptée.
  • La colonne d'heure système BigQuery, définie par _CHANGE_TIMESTAMP, est la seule colonne de code temporel acceptée pour les opérations de jointure. Les colonnes définies par l'utilisateur ne sont pas acceptées.
  • Lorsque vous l'utilisez conjointement avec des agrégations par fenêtre, vous devez respecter toutes les limites documentées concernant les agrégations par fenêtre.

Remarques sur les tarifs

Les requêtes continues BigQuery 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 les jointures. Étant donné que les jointures obligent le système à stocker l'état pendant que la requête est active, elles consomment des ressources de slot supplémentaires. Plus de contexte ou de données stockées dans une jointure (par exemple, lorsque vous utilisez des intervalles de temps plus longs dans la clause JOIN ou WHERE) nécessitent de conserver plus d'état, ce qui entraîne une utilisation plus élevée des emplacements.

Étapes suivantes