瞭解持續查詢中的視窗匯總

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

BigQuery 連續查詢支援匯總和視窗化作業，做為有狀態的作業。有狀態的作業可讓連續查詢執行複雜的分析，這類分析需要保留多個資料列或時間間隔的資訊。這項功能可讓您在查詢執行時，將必要資料儲存在記憶體中，藉此計算一段時間內的指標，例如 30 分鐘的平均值。

時間區間設定函式會根據系統時間 (指出進行變更的交易提交時間)，將資料指派至邏輯元件或時間區間。在 BigQuery 中，這些函式是傳回資料表的資料表值函式 (TVF)，其中包含所有原始資料欄和兩個額外資料欄：window_start 和 window_end。這些資料欄會識別每個時間區間的時間間隔。如要進一步瞭解有狀態作業，請參閱「支援的有狀態作業」。

只有 BigQuery 連續查詢支援視窗 TVF。

時間區間 TVF 與window 函式呼叫不同。

支援的匯總函式

系統支援下列匯總函式：

• ANY_VALUE
• APPROX_COUNT_DISTINCT
• APPROX_QUANTILES
• APPROX_TOP_COUNT
• APPROX_TOP_SUM
• ARRAY_AGG 並符合下列規定：
  • 必須使用 LIMIT 子句，上限值為 100。
  • ORDER BY 子句為選用項目。
• ARRAY_CONCAT_AGG
• AVG
• BIT_AND
• BIT_OR
• BIT_XOR
• CORR
• COUNT
• COUNTIF
• COVAR_POP
• COVAR_SAMP
• LOGICAL_AND
• LOGICAL_OR
• MAX
• MAX_BY
• MIN
• MIN_BY
• STDDEV
• STDDEV_POP
• STDDEV_SAMP
• STRING_AGG 並符合下列規定：
  • 必須使用 LIMIT 子句，上限值為 100。
  • ORDER BY 子句為選用項目。
• SUM
• VAR_POP
• VAR_SAMP
• VARIANCE

不支援的匯總函式

系統不支援下列匯總函式：

• AVG (差分隱私)
• COUNT (差分隱私)
• 包含 DISTINCT 運算式的函式。
• GROUPING
• PERCENTILE_CONT (差分隱私)
• ST_CENTROID_AGG
• ST_EXTENT
• ST_UNION_AGG
• SUM (差分隱私)

TUMBLE 函式

TUMBLE 函式會將資料指派至指定大小的不重疊時間間隔 (翻滾時間區間)。舉例來說，5 分鐘的時間區間會將事件分組為 [2026-01-01 12:00:00, 2026-01-01 12:05:00) 和 [2026-01-01 12:05:00, 2026-01-01 12:10:00) 等離散間隔。時間戳記值為 2026-01-01 12:03:18 的資料列會指派至第一個時間區間。由於這些時間區間不相交且不重疊，因此具有時間戳記的每個元素都會指派至一個時間區間。

下圖顯示 TUMBLE 函式如何將事件指派至不重疊的時間間隔：

您可以在執行任何彙整作業之前，使用這項函式在即時事件處理程序中依時間範圍將事件分組。

語法

TUMBLE(TABLE table, "timestamp_column", window_size)

定義

• table：BigQuery 資料表名稱。這必須是包裝在 APPENDS 函式中的標準 BigQuery 資料表。這個引數前面必須加上 TABLE 一字。

• timestamp_column：STRING 常值，指定輸入資料表中包含事件時間的資料欄名稱。這個資料欄中的值會將每個資料列指派給視窗。定義 BigQuery 系統時間的 _CHANGE_TIMESTAMP 資料欄是唯一支援的 timestamp_column。系統不支援使用者定義的資料欄。

• window_size：INTERVAL 值，用於定義每個滾動式時間區間的持續時間。時間範圍最多可設為 24 小時。例如：INTERVAL 30 SECOND。

輸出

TUMBLE 函式會傳回輸出內容，其中包含下列資料欄：

• 查詢執行時，輸入資料表的所有資料欄。

• window_start：TIMESTAMP 值，表示記錄所屬時間範圍的開始時間 (含)。

• window_end：TIMESTAMP 值，表示記錄所屬時間範圍的專屬結束時間。

輸出具體化

在 BigQuery 持續查詢中，視窗匯總作業不會產生特定時間間隔的輸出內容，直到 BigQuery 完成或關閉該視窗為止。這項行為可確保 BigQuery 只會在處理完該視窗的所有相關資料後，才發出匯總結果。

舉例來說，如果您對 user_clickstream 資料表執行 5 分鐘的 TUMBLE 視窗匯總，則只有在查詢處理 _CHANGE_TIMESTAMP 為 10:20 或之後的記錄後，才會發布 [10:15; 10:20) 間隔的結果。此時，BigQuery 會將視窗視為已關閉。 此外，系統會在顯示屬於該特定時間範圍的第一筆記錄時開啟視窗，並開始累積資料。

視窗保持開啟時，BigQuery 必須保留中繼匯總結果。這需要儲存狀態，也就是說，BigQuery 必須保留中繼匯總結果。由於這個狀態必須保留在作用中記憶體中，直到視窗關閉為止，因此使用較長的視窗時間或處理大量串流時，需要管理更多儲存的內容，導致更高的時段用量。詳情請參閱「定價考量事項」。

限制

• TUMBLE 函式僅支援 BigQuery 連續查詢。
• 使用 TUMBLE 函式啟動持續查詢時，只能使用 APPENDS 函式，不支援 CHANGES 函式。
• 系統僅支援以 _CHANGE_TIMESTAMP 定義的 BigQuery 系統時間資料欄，不支援使用者定義的資料欄。timestamp_column
• 視窗大小最多可設為 24 小時。
• TUMBLE 視窗函式執行時，會產生兩個額外的輸出資料欄：window_start 和 window_end。您必須在執行視窗匯總的 SELECT 陳述式中，至少包含其中一個資料欄的 GROUP BY 陳述式。
• 搭配使用 TUMBLE 函式和持續查詢聯結時，必須遵守所有持續查詢聯結限制。

費用考量事項

BigQuery 連續查詢會根據作業執行期間耗用的運算容量 (運算單元)計費。這種以運算為準的模式也適用於有狀態的作業，例如視窗化。由於視窗化需要 BigQuery 在查詢有效期間儲存「狀態」，因此會耗用額外的運算單元資源。一般來說，視窗中儲存的內容或資料越多 (例如使用較長的視窗時間長度)，BigQuery 就必須保留更多狀態，進而導致運算單元用量增加。

範例

下列查詢會說明如何查詢計程車乘車資料表，每 30 分鐘取得每輛計程車的平均乘車次數、乘客數和平均車資，並將這項資料匯出至 BigQuery 的資料表：

INSERT INTO
 `real_time_taxi_streaming.driver_stats`

WITH ride_completions AS (
 SELECT
   _CHANGE_TIMESTAMP as bq_changed_ts,
   CAST(timestamp AS DATE) AS ride_date,
   taxi_id,
   meter_reading,
   passenger_count
 FROM
   APPENDS(TABLE `real_time_taxi_streaming.taxirides`,
     CURRENT_TIMESTAMP() - INTERVAL 10 MINUTE)
 WHERE
   ride_status = 'dropoff')

 SELECT
   ride_date,
   window_end,
   taxi_id,
   COUNT(taxi_id) AS total_rides_per_half_hour,
   ROUND(AVG(meter_reading),2) AS avg_fare_per_half_hour,
   SUM(passenger_count) AS total_passengers_per_half_hour
FROM
  tumble(TABLE ride_completions,"bq_changed_ts",INTERVAL 30 MINUTE)
GROUP BY
  window_end,
  ride_date,
  taxi_id

後續步驟

• 瞭解如何執行 JOIN、匯總和視窗化。
• 進一步瞭解 BigQuery 持續查詢。
• 瞭解如何合併多個串流的資料。