Utilizza i join stream-to-stream nelle query continue

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

I casi d'uso comuni per i join stream-stream includono il rilevamento di frodi finanziarie, la creazione di profili dei clienti e l'ottimizzazione della gestione della catena di fornitura. Questi join sono un tipo chiave di operazione stateful. Per saperne di più sulle operazioni stateful, consulta Operazioni stateful supportate.

Tipi di JOIN supportati

I seguenti tipi di JOIN sono supportati dalle query continue:

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

Tipi di JOIN non supportati

I seguenti tipi di JOIN non sono supportati dalle query continue:

  • JOIN da stream a tabella statica: un join in cui almeno una tabella unita è una tabella statica che non riceve l'importazione dati orientata 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.

Unisci i dati di più stream

La seguente query mostra come unire una tabella delle corse in taxi a una tabella delle richieste di taxi e identificare il taxi disponibile più vicino al richiedente entro un intervallo di tempo di 5 minuti, nonché 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 per l'esecuzione di un join stream-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 stream solo se i relativi timestamp rientrano in un intervallo di 5 minuti. Non hai l'obbligo di utilizzare 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 avvii una query continua con un join 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 di timestamp supportata per le operazioni di join. Le colonne definite dall'utente non sono supportate.
  • Se utilizzate insieme alle aggregazioni con finestra, devi seguire tutte le limitazioni relative alle aggregazioni 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 computing si applica anche alle operazioni stateful come i join. Poiché i join richiedono al sistema di memorizzare lo "stato" mentre la query è attiva, consumano risorse slot aggiuntive. Più contesto o dati archiviati all'interno di un join, ad esempio quando utilizzi intervalli di tempo più lunghi nella clausola JOIN o WHERE, richiedono la conservazione di più stato, il che porta a un maggiore utilizzo degli slot.

Passaggi successivi