Utiliser des jointures de flux à flux dans des requêtes continues

Pour demander de l'aide ou envoyer des commentaires sur cette fonctionnalité, envoyez un e-mail à 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. 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 temporelles.

Types de JOIN compatibles

Les requêtes continues sont compatibles avec les types de JOIN suivants :

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

Types de JOIN non compatibles

Les requêtes continues ne sont pas compatibles avec les types de JOIN suivants :

  • JOIN de flux à table statique : jointure dans laquelle au moins une table jointe est une table statique qui ne reçoit pas de données temporelles. Une table de dimension est un exemple de table statique.
  • Autres formes d'opérations JOIN que INNER.
  • JOIN qui ne comportent pas de clauses JOIN temporelles.

Joindre des données provenant de plusieurs flux

La requête suivante vous montre comment joindre une table de courses 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
   );

Remarques sur les jointures

Les sections suivantes décrivent les points à prendre en compte lors d'une jointure de flux à flux.

Limites

  • Seules les opérations INNER JOIN sont compatibles. Les autres formes, telles que LEFT ou FULL OUTER, ne sont pas compatibles.
  • 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 pour limiter la colonne d'horodatage à 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 horodatages 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.
  • Lorsque vous démarrez une requête continue avec une jointure de flux à flux, seule la fonction APPENDS est compatible. La fonction CHANGES n'est pas compatible.
  • La colonne d'heure système BigQuery, définie par _CHANGE_TIMESTAMP, est la seule colonne d'horodatage compatible pour les opérations de jointure. Les colonnes définies par l'utilisateur ne sont pas compatibles.
  • Lorsqu'elles sont utilisées conjointement avec des agrégations fenêtrées, vous devez respecter toutes les limites d'agrégation fenêtrée documentées.

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 nécessitent que le système stocke un "état" pendant que la requête est active, elles consomment des ressources d'emplacement supplémentaires. Plus de contexte ou de données sont stockés dans une jointure (par exemple, lorsque vous utilisez des intervalles plus longs dans la clause JOIN ou WHERE), plus l'état à conserver est important, ce qui entraîne une utilisation plus élevée des emplacements.

Étape suivante