Utilizzare i join da stream a stream nelle query continue

In BigQuery, puoi utilizzare i join da stream a stream nelle query continue per analizzare e correlare i dati di due o più stream di dati in tempo reale. I join da stream a stream sono un'operazione di join tra due o più tabelle che ricevono importazione dati orientati al tempo.

I casi d'uso comuni per i join da stream a stream includono il rilevamento di frodi finanziarie, la creazione di profili cliente e l'ottimizzazione della gestione della catena di fornitura. Questi join sono un tipo chiave di operazione con stato. Per ulteriori informazioni sulle operazioni con stato, consulta Operazioni con stato supportate.

Tipi JOIN supportati

Le query continue supportano i seguenti tipi di JOIN:

  • JOIN da stream a stream: un'operazione di join tra due o più tabelle che ricevono importazione dati orientati al tempo.
  • INNER JOIN.

Tipi JOIN non supportati

Le query continue non supportano i seguenti tipi di JOIN:

  • JOIN da stream a tabella statica: un join 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 in 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 sui join

Le sezioni seguenti descrivono le considerazioni necessarie quando si esegue un join da stream a 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 join e un intervallo di 1 ora sull'altro.
  • Quando si avvia una query continua con un join da stream a stream, è supportata solo la funzione APPENDS. La funzione CHANGES non è supportata.
  • La colonna del timestamp definita da _CHANGE_TIMESTAMP è l'unica colonna del timestamp supportata per le operazioni di join. 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 i join. Poiché i join 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 join, 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