Utilizzare le unioni stream-to-stream nelle query continue

Per richiedere assistenza o fornire feedback su questa funzionalità, invia un'email all'indirizzo bq-continuous-queries-feedback@google.com.

Le query continue supportano JOIN come operazione con stato. Le operazioni con stato consentono alle query continue di eseguire analisi complesse che richiedono la conservazione delle informazioni su più righe o intervalli di tempo. Questa funzionalità ti consente di correlare gli eventi di stream diversi memorizzando i dati necessari in memoria durante l'esecuzione della query. Per saperne di più sulle operazioni con stato, consulta Operazioni con stato supportate.

Le unioni stream-to-stream sono un'operazione di unione tra due o più tabelle che ricevono importazione dati orientati al tempo.

Tipi di JOIN supportati

Le query continue supportano i seguenti tipi di JOIN:

  • JOIN stream-to-stream: un'operazione di unione tra due o più tabelle che ricevono importazione dati orientati al tempo.
  • INNER JOIN.

Tipi di JOIN non supportati

Le query continue non supportano i seguenti tipi di JOIN:

  • JOIN stream-to-static-table: un'unione in cui almeno una tabella unita è una tabella statica che non riceve importazione dati orientati al tempo. Un esempio di tabella statica è una tabella delle dimensioni.
  • Altre forme di operazioni JOIN oltre a INNER.
  • JOIN che non hanno clausole JOIN orientate al tempo.

Unire i dati di più stream

La seguente query mostra come unire una tabella delle corse in taxi a una tabella delle richieste di taxi, identificare il taxi disponibile più vicino al richiedente entro un intervallo di tempo di 5 minuti ed esportare questi dati in un'altra tabella 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
   );

Considerazioni sulle unioni

Le seguenti sezioni descrivono le considerazioni necessarie quando si esegue un'unione stream-to-stream.

Limitazioni

  • Sono supportate solo le operazioni INNER JOIN; altre forme, come LEFT o FULL OUTER, non sono supportate.
  • Ogni lato dell'operazione INNER JOIN deve specificare un'ora di inizio per la query continua.
  • Oltre a una chiave di join (ad esempio, table1.user_id = table2.user_id), la clausola JOIN deve includere una condizione per limitare la colonna del timestamp a un intervallo costante. Questa condizione limita il tempo di attesa del sistema per l'arrivo di un evento corrispondente nell'altro stream. Ad esempio, puoi specificare che un evento di uno stream può essere unito a un evento di un altro solo se i relativi timestamp rientrano in un intervallo di 5 minuti. Non sei limitato a intervalli simmetrici. Ad esempio, puoi utilizzare un intervallo di 5 minuti su un lato della condizione di unione e un intervallo di 1 ora sull'altro.
  • Quando si avvia una query continua con un'unione stream-to-stream, è supportata solo la funzione APPENDS. La funzione CHANGES non è supportata.
  • La colonna dell'ora di sistema di BigQuery, definita da _CHANGE_TIMESTAMP, è l'unica colonna del timestamp supportata per le operazioni di unione. Le colonne definite dall'utente non sono supportate.
  • Se utilizzata insieme alle aggregazioni con finestra, devi rispettare tutte le limitazioni di aggregazione con finestra documentate.

Considerazioni sui prezzi

Le query continue di BigQuery vengono fatturate in base alla capacità di calcolo (slot) consumata durante l' esecuzione del job. Questo modello basato sul calcolo si applica anche alle operazioni con stato come le unioni. Poiché le unioni richiedono al sistema di memorizzare lo "stato" mentre la query è attiva, consumano risorse di slot aggiuntive. Più contesto o dati memorizzati all'interno di un'unione, ad esempio quando utilizzi intervalli di tempo più lunghi nella clausola JOIN o WHERE, richiedono la conservazione di più stati, il che comporta un maggiore utilizzo degli slot.

Passaggi successivi