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

En BigQuery, puedes usar uniones de transmisión a transmisión en consultas continuas para analizar y correlacionar datos de dos o más transmisiones de datos en tiempo real. Las uniones de transmisión a transmisión son una operación de unión entre dos o más tablas que reciben transferencia de datos orientada al tiempo.

Los casos de uso comunes para las uniones de transmisión a transmisión incluyen la detección de fraudes financieros, la creación de perfiles de clientes y la optimización de la administración de la cadena de suministro. Estas uniones son un tipo clave de operación con estado. Para obtener más información sobre las operaciones con estado, consulta Operaciones con estado compatibles.

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 transferencia de datos orientada al tiempo.
  • INNER JOIN.

Tipos de JOIN no compatibles

Las consultas continuas no admiten los siguientes tipos de JOIN:

  • JOINs de transmisión a tabla estática: 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 una tabla estática es una tabla de dimensiones.
  • Otras formas de operaciones JOIN además de INNER.
  • JOIN que no tienen cláusulas JOIN orientadas al tiempo.

Une datos de varias transmisiones

En la siguiente consulta, se muestra cómo unir una tabla de viajes en taxi a una tabla de solicitudes de taxi y, luego, 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 la otra transmisión. Por ejemplo, puedes especificar que un evento de una transmisión solo se pueda unir con un evento de otra si sus marcas de tiempo están dentro de un intervalo de 5 minutos. No estás limitado a intervalos simétricos. Por ejemplo, podrías 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 usa junto con agregaciones de ventanas, debes seguir todas las limitaciones de agregación de ventanas documentadas.

Consideraciones sobre el precio

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

¿Qué sigue?