在持續查詢中使用串流對串流聯結

如要尋求支援或針對這項功能提供意見回饋，請傳送電子郵件至 bq-continuous-queries-feedback@google.com。

持續查詢支援 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
   );

加入注意事項

以下各節說明執行串流對串流聯播時的必要考量。

限制

僅支援 INNER JOIN 作業，不支援其他形式，例如 LEFT 或 FULL OUTER。
INNER JOIN 運算子的每一側都必須指定持續查詢的開始時間。
除了彙整索引鍵 (例如 table1.user_id = table2.user_id)，JOIN 子句還必須包含條件，將時間戳記資料欄限制為固定間隔。這項條件會限制系統等待其他串流中相符事件的時間長度。舉例來說，您可以指定只有當兩個串流的事件時間戳記間隔在 5 分鐘內時，才能將這兩個串流的事件合併。您不一定要使用對稱間隔。舉例來說，您可以在聯結條件的一側使用 5 分鐘間隔，另一側則使用 1 小時間隔。
使用串流對串流聯結啟動持續查詢時，系統只支援 APPENDS 函式。不支援 CHANGES 函式。
BigQuery 系統時間欄 (由 _CHANGE_TIMESTAMP 定義) 是聯結作業唯一支援的時間戳記欄。不支援使用者定義的資料欄。
如要搭配時間區間匯總使用，您必須遵守所有已記錄的時間區間匯總限制。

費用考量事項

系統會根據作業執行期間消耗的運算容量 (運算單元)，向您收取 BigQuery 持續查詢的費用。這項以運算為基礎的模型也適用於聯結等有狀態的作業。由於聯結需要系統在查詢有效期間儲存「狀態」，因此會耗用額外的時段資源。聯結中儲存的內容或資料越多 (例如在 JOIN 或 WHERE 子句中使用較長的時間間隔)，就越需要保留更多狀態，導致更高的時段使用率。