Usa combinaciones de transmisión a transmisión en consultas continuas

Para solicitar asistencia o enviar comentarios sobre esta función, envía un correo electrónico a bq-continuous-queries-feedback@google.com.

Las consultas continuas admiten JOIN como una operación con estado. Las operaciones con estado permiten que las consultas continuas realicen análisis complejos que requieren retener información en varias filas o intervalos de tiempo. Esta capacidad te permite correlacionar eventos de diferentes flujos almacenando los datos necesarios en la memoria mientras se ejecuta la consulta. Para obtener más información sobre las operaciones con estado, consulta Operaciones con estado compatibles.

Las uniones de flujo a flujo son una operación de unión entre dos o más tablas que reciben transferencia de datos orientada al tiempo.

Tipos de JOIN admitidos

Las consultas continuas admiten los siguientes tipos de JOIN:

  • JOIN de transmisión a transmisión: Es una operación de unión entre dos o más tablas que reciben datos orientados al tiempo.
  • INNER JOIN

Tipos de JOIN no admitidos

Las consultas continuas no admiten los siguientes tipos de JOIN:

  • Uniones de transmisión a tabla estática: Es una unión en la que al menos una tabla unida es una tabla estática que no recibe transferencia de datos orientada al tiempo. Un ejemplo de tabla estática es una tabla de dimensiones.
  • Otras formas de operaciones JOIN además de INNER.
  • JOINs que no tienen cláusulas JOIN orientadas al tiempo

Cómo unir datos de varios flujos

La siguiente consulta muestra cómo unir una tabla de viajes en taxi a una tabla de solicitudes de taxi, identificar el taxi disponible más cercano al solicitante en un período de 5 minutos y exportar estos datos a otra tabla de 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
   );

Consideraciones para unirse

En las siguientes secciones, se describen las consideraciones necesarias cuando se realiza una unión de transmisión a transmisión.

Limitaciones

  • Solo se admiten las operaciones INNER JOIN; no se admiten otras formas, como LEFT o FULL OUTER.
  • Cada lado de la operación INNER JOIN debe especificar una hora de inicio para la consulta continua.
  • Además de una clave de unión (por ejemplo, table1.user_id = table2.user_id), la cláusula JOIN debe incluir una condición para restringir la columna de marca de tiempo a un intervalo constante. Esta condición limita el tiempo que el sistema espera a que llegue un evento coincidente en el otro flujo. Por ejemplo, puedes especificar que un evento de una transmisión solo se puede unir con un evento de otra si sus marcas de tiempo se encuentran dentro de un intervalo de 5 minutos. No estás limitado a intervalos simétricos. Por ejemplo, puedes usar un intervalo de 5 minutos en un lado de la condición de unión y un intervalo de 1 hora en el otro.
  • Cuando se inicia una consulta continua con una unión de transmisión a transmisión, solo se admite la función APPENDS. No se admite la función CHANGES.
  • La columna de hora del sistema de BigQuery, definida por _CHANGE_TIMESTAMP, es la única columna de marca de tiempo admitida para las operaciones de unión. No se admiten las columnas definidas por el usuario.
  • Cuando se usan junto con agregaciones con ventanas, debes seguir todas las limitaciones documentadas de las agregaciones con ventanas.

Consideraciones sobre el precio

Las consultas continuas de BigQuery se facturan según la capacidad de procesamiento (ranuras) que se consume mientras se ejecuta el trabajo. Este modelo basado en el procesamiento también se aplica a las operaciones con estado, como las uniones. Dado que las uniones requieren que el sistema almacene "estado" mientras la consulta está activa, consumen recursos de ranura adicionales. Cuanto más contexto o datos se almacenen dentro de una unión (por ejemplo, cuando usas intervalos de tiempo más largos en la cláusula JOIN o WHERE), más estado se debe conservar, lo que genera una mayor utilización de ranuras.

¿Qué sigue?