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

No BigQuery, é possível usar junções de stream para stream em consultas contínuas para analisar e correlacionar dados de dois ou mais streams de dados em tempo real. As junções 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.

Os casos de uso comuns para junções de stream para stream incluem detecção de fraudes financeiras, criação de perfis de clientes e otimização do gerenciamento da cadeia de suprimentos. Essas junções são um tipo principal de operação com estado. Para mais informações sobre operações com estado, consulte Operações com estado compatíveis.

Tipos de JOIN aceitos

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 streaming 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 e 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 as 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 aceitas.
  • 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 espera para que um evento correspondente chegue ao outro fluxo. Por exemplo, é possível especificar que um evento de um fluxo só pode ser unido a um evento de outro se os carimbos de data/hora estiverem dentro de um intervalo de cinco minutos. Não há limites para intervalos simétricos. Por exemplo, é possível usar um intervalo de cinco minutos em um lado da condição de junção e um intervalo de uma 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 faturadas 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