Usar junções de stream para stream em consultas contínuas

Para pedir suporte ou enviar feedback sobre esse recurso, envie um e-mail para bq-continuous-queries-feedback@google.com.

As consultas contínuas aceitam JOIN como uma operação com estado. As operações com estado permitem que consultas contínuas realizem análises complexas que exigem a retenção de informações em várias linhas ou intervalos de tempo. Com essa capacidade, é possível correlacionar eventos de diferentes fluxos armazenando os dados necessários na memória enquanto a consulta é executada. Para mais informações sobre operações com estado, consulte Operações com estado compatíveis.

As mesclagens de stream para stream são uma operação de junção entre duas ou mais tabelas que recebem ingestão de dados orientada por tempo.

Tipos de JOIN compatíveis

As consultas contínuas aceitam os seguintes tipos de JOIN:

  • JOIN de stream para stream: uma operação de junção entre duas ou mais tabelas que recebem ingestão de dados orientada por tempo.
  • INNER JOIN.

Tipos de JOIN sem suporte

As consultas contínuas não aceitam os seguintes tipos de JOIN:

  • JOINs de stream para tabela estática: uma junção em que pelo menos uma tabela unida é uma tabela estática que não recebe ingestão de dados orientada por tempo. Um exemplo de tabela estática é uma tabela de dimensão.
  • Outras formas de operações JOIN além de INNER.
  • JOINs que não têm cláusulas JOIN orientadas por tempo.

Combinar dados de vários fluxos

A consulta a seguir mostra como unir uma tabela de corridas de táxi a uma tabela de solicitações de táxi e identificar o táxi disponível mais próximo do solicitante em um período de 5 minutos, além de exportar esses dados para outra tabela do 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
   );

Considerações sobre JOIN

As seções a seguir descrevem considerações necessárias ao realizar uma junção de stream para stream.

Limitações

  • Apenas operações INNER JOIN são compatíveis. Outras formas, como LEFT ou FULL OUTER, não são compatíveis.
  • Cada lado da operação INNER JOIN precisa especificar um horário de início para a consulta contínua.
  • Além de uma chave de junção (por exemplo, table1.user_id = table2.user_id), a cláusula JOIN precisa incluir uma condição para restringir a coluna de carimbo de data/hora a um intervalo constante. Essa condição limita o tempo que o sistema aguarda a chegada de um evento correspondente no outro fluxo. Por exemplo, é possível especificar que um evento de um stream só pode ser unido a um evento de outro se os carimbos de data/hora estiverem dentro de um intervalo de 5 minutos. Você não está limitado a intervalos simétricos. Por exemplo, é possível usar um intervalo de 5 minutos em um lado da condição de junção e um intervalo de 1 hora no outro.
  • Ao iniciar uma consulta contínua com uma junção de stream para stream, apenas a função APPENDS é compatível. A função CHANGES não é compatível.
  • A coluna de tempo do sistema do BigQuery, definida por _CHANGE_TIMESTAMP, é a única coluna de carimbo de data/hora compatível com operações de junção. Não é possível usar colunas definidas pelo usuário.
  • Quando usado em conjunto com agregações em janelas, é necessário seguir todas as limitações documentadas de agregação em janelas.

Considerações de preço

As consultas contínuas do BigQuery são cobradas com base na capacidade de computação (slots) consumida enquanto o job está em execução. Esse modelo baseado em computação também se aplica a operações com estado, como junções. Como as junções exigem que o sistema armazene "estado" enquanto a consulta está ativa, elas consomem recursos de slot adicionais. Mais contexto ou dados armazenados em uma junção (por exemplo, quando você usa intervalos de tempo mais longos na cláusula JOIN ou WHERE) exigem a preservação de mais estado, o que leva a uma maior utilização de slots.

A seguir