在持續查詢中使用串流對串流 join

在 BigQuery 中，您可以在持續查詢中使用串流對串流 join，分析及關聯兩個以上即時資料串流的資料。串流對串流彙整作業是指在兩個以上資料表之間執行的彙整作業，這些資料表會接收以時間為導向的資料擷取。

串流對串流 join 的常見用途包括偵測金融詐欺、建立顧客個人資料，以及最佳化供應鏈管理。這類彙整是重要的有狀態作業類型。如要進一步瞭解有狀態作業，請參閱「支援的有狀態作業」。

支援的 JOIN 類型

持續查詢支援下列 JOIN 類型：

  • 串流對串流 JOIN：在兩個以上資料表之間執行的 JOIN 作業，這些資料表會接收以時間為導向的資料擷取。
  • INNER JOIN。

不支援的 JOIN 類型

持續查詢不支援下列 JOIN 類型：

  • 串流至靜態資料表 JOIN：至少有一個彙整資料表是靜態資料表，不會接收時間導向的資料擷取。維度資料表就是靜態資料表的例子。
  • 除了 INNER 以外的其他 JOIN 運算形式。
  • JOIN 沒有時間導向的 JOIN 子句。

彙整多個串流的資料

下列查詢會將計程車行程資料表與計程車要求資料表彙整，找出 5 分鐘內距離要求者最近的可用計程車，並將這項資料匯出至另一個 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
   );

Join 考量

以下各節說明執行串流對串流彙整時，必須考量的事項。

限制

  • 僅支援 INNER JOIN 作業，不支援 LEFT 或 FULL OUTER 等其他形式。
  • INNER JOIN 作業的每一端都必須指定持續查詢的開始時間。
  • 除了彙整鍵 (例如 table1.user_id = table2.user_id) 之外，JOIN 子句也必須包含條件，將時間戳記欄限制在常數間隔內。這項條件會限制系統等待相符事件到達另一個串流的時間。舉例來說，您可以指定只有在時間戳記相差 5 分鐘內時，才能將某個串流的事件與另一個串流的事件彙整。您不一定要使用對稱間隔，舉例來說，您可以在彙整條件的一端使用 5 分鐘的時間間隔，在另一端使用 1 小時的時間間隔。
  • 使用串流對串流 join 啟動持續查詢時，僅支援 APPENDS 函式。不支援 CHANGES 函式。
  • BigQuery 系統時間欄 (由 _CHANGE_TIMESTAMP 定義) 是唯一支援 join 作業的時間戳記欄。不支援使用者定義的資料欄。
  • 與視窗匯總搭配使用時，您必須遵守所有記錄的視窗匯總限制。

費用考量事項

BigQuery 持續查詢的計費依據，是工作執行期間耗用的運算能力 (運算單元)。這種以運算為基礎的模型也適用於彙整等有狀態作業。由於彙整作業需要系統在查詢執行期間儲存「狀態」，因此會耗用額外的運算單元資源。儲存在 join 中的情境或資料越多 (例如在 JOIN 或 WHERE 子句中使用較長的時間間隔)，需要保留的狀態就越多，導致運算單元使用率提高。

後續步驟