持續查詢簡介

本文說明 BigQuery 持續查詢。

BigQuery 持續查詢是會不斷執行的 SQL 陳述式，持續查詢功能可即時分析傳入 BigQuery 的資料。您可以將持續查詢產生的輸出資料列寫入或匯出至下列目的地：

• BigQuery 資料表
• Apache Iceberg 代管資料表
• Pub/Sub 主題
• Bigtable 資料表
• Spanner 資料表

持續查詢可使用下列其中一種方法，處理已寫入標準 BigQuery 資料表的資料：

• BigQuery Storage Write API (gRPC)
• BigQuery Storage Write API (REST)
• 批次載入
• INSERT DML 陳述式
• 資料操縱語言 (DML) 陳述式 (例如 DELETE、UPDATE 和 MERGE)，將資料匯出至 Pub/Sub 時會發生變異。
• 將批次查詢結果寫入永久資料表
• 將 BigQuery 持續查詢的結果寫入永久資料表
• Pub/Sub BigQuery 訂閱項目
• 從 Dataflow 寫入 BigQuery
• 使用僅限附加的寫入模式，將 Datastream 資料寫入 BigQuery

您可以使用持續查詢執行具時效性的工作，例如建立深入分析並立即採取行動、套用即時機器學習 (ML) 推論，以及將資料複製到其他平台。這樣一來，您就能將 BigQuery 做為應用程式決策邏輯的事件導向資料處理引擎。

下圖顯示常見的持續查詢工作流程：

用途

以下是您可能想使用連續查詢的常見用途：

• 個人化顧客互動服務：使用生成式 AI 建立專屬訊息，為每次顧客互動提供客製化服務。
• 異常偵測：建構解決方案，即時對複雜資料執行異常狀況和威脅偵測，以便更快應對問題。
• 可自訂的事件導向管道：整合持續查詢和 Pub/Sub，根據傳入的資料觸發下游應用程式。
• 資料充實和實體擷取：使用持續查詢，透過 SQL 函式和機器學習模型執行即時資料充實和轉換。
• 反向擷取、轉換及載入 (ETL)：執行即時反向 ETL，將資料載入至其他更適合低延遲應用程式服務的儲存系統。舉例來說，您可以分析或強化寫入 BigQuery 的事件資料，然後將資料串流至 Bigtable、Spanner 或 Apache Iceberg 管理的資料表，以供應用程式服務使用。
• 自主觸發代理：根據即時資料串流中偵測到的複雜事件，即時觸發代理資料管道。如需範例，請參閱「使用 BigQuery 和 Agent Development Kit (ADK) 建構事件導向的資料代理程式碼實驗室」。
• 自主式代理監控：使用 BigQuery 代理分析外掛程式，為即時代理互動開發即時自動監控和警報功能，該外掛程式會將所有代理追蹤資料、工具使用情況和作業記錄直接串流至 BigQuery，深入觀察 AI 員工的運作情況。

支援的功能

持續查詢支援下列作業：

• 執行 INSERT 陳述式，將持續查詢的資料寫入 BigQuery 資料表或 Iceberg 代管資料表。

• 執行 EXPORT DATA 陳述式，將持續查詢的輸出內容發布至 Pub/Sub 主題。

  如要將資料匯出至 Pub/Sub，必須使用服務帳戶執行持續查詢。詳情請參閱「將資料匯出至 Pub/Sub」。

  您可以透過 Pub/Sub 主題將資料用於其他服務，例如使用 Dataflow 執行串流分析，或在應用程式整合工作流程中使用資料。

• 執行 EXPORT DATA 陳述式，將資料從 BigQuery 匯出至 Bigtable 資料表。詳情請參閱「將資料匯出至 Bigtable」。

• 執行 EXPORT DATA 陳述式，將資料從 BigQuery 匯出至 Spanner 資料表。詳情請參閱「將資料匯出至 Spanner (反向 ETL)」。

• 呼叫下列生成式 AI 函式：

  • AI.GENERATE

  • AI.GENERATE_TEXT

    • 如要使用這項函式，您必須擁有BigQuery ML 遠端模型，並以 Gemini Enterprise Agent Platform 模型為基礎。

• 呼叫下列 AI 函式：

  • ML.UNDERSTAND_TEXT
  • ML.TRANSLATE

  如要使用這些函式，您必須透過 Cloud AI API 建立 BigQuery ML 遠端模型。

• 使用 ML.NORMALIZER 函式正規化數值型資料。

• 分析及處理 JSON 資料，包括支援 JSON 函式和 JSON 取消巢狀結構。

• 使用無狀態 GoogleSQL 函式，例如轉換函式。 在無狀態函式中，系統會獨立處理資料表中的每一列。

• 使用有狀態的作業，例如 JOIN、匯總和視窗匯總。在有狀態的作業中，系統會保留多個資料列或時間間隔的擷取資料狀態，以便計算準確的結果。

• 使用 APPENDS 變更記錄函式，處理特定時間點附加的資料。

• 使用CHANGES變更記錄功能處理變更的資料，包括從特定時間點匯出資料至 Pub/Sub 時的附加和變動資料。不過，使用有狀態作業時，系統不支援 CHANGES。

• 查詢檢視區塊，只要檢視區塊的基礎 SQL 查詢是有效的持續查詢即可。

支援的有狀態作業

預覽

這項功能適用《服務專屬條款》中「一般服務條款」一節的《正式發布前產品條款》。正式發布前功能是依「原樣」提供，支援服務可能受限。 詳情請參閱推出階段說明。

如要尋求支援或針對這項功能提供意見回饋，請傳送電子郵件至 [e-mail]。

有狀態作業可讓連續查詢執行複雜分析，這類分析需要保留多個資料列或時間間隔的資訊。無狀態函式會獨立處理每個資料列，有狀態作業則會維護擷取資料的狀態，以支援 JOIN、匯總和視窗匯總等函式。這項功能可讓您在查詢執行期間，將必要資料儲存在記憶體中，藉此關聯不同串流的事件，或計算一段時間內的指標 (例如 30 分鐘平均值)。

持續查詢支援下列有狀態作業：

• JOINs
• 匯總和時間範圍
• UNION ALL

授權

執行持續查詢作業時使用的Google Cloud 存取權杖，是由使用者帳戶產生，存留時間 (TTL) 為兩天。因此，這類工作會在兩天後停止執行。服務帳戶產生的存取權杖可執行較長時間，但仍須遵守查詢執行時間上限。詳情請參閱「使用服務帳戶執行持續查詢」。

位置

如需支援的區域清單，請參閱「BigQuery 持續查詢位置」。

限制

持續查詢有下列限制：

• 只有在預先發布版中進行特定有狀態作業時，系統才會維護擷取資料的狀態。雖然連續查詢現在支援部分類型的 JOIN、匯總和視窗匯總，但這些僅限於特定有狀態作業。並非所有有狀態作業類型都支援。

• 除非下列 SQL 功能列為支援的具狀態作業，否則無法在持續查詢中使用：

  • 下列查詢運算子：

    • PIVOT
    • UNPIVOT
    • TABLESAMPLE

  • 查詢集合運算子 (UNION ALL 除外)。

  • SELECT DISTINCT 陳述式

  • EXISTS 或 NOT EXISTS 子查詢

  • 遞迴 CTE

  • 使用者定義函式

  • window 函式呼叫

  • 支援的功能中未列出的 BigQuery ML 函式

  • 資料定義語言 (DDL) 陳述式

  • 資料操縱語言 (DML) 陳述式，但 INSERT 除外。

  • 資料控制語言 (DCL) 陳述式

  • EXPORT DATA 陳述式，但目標不是 Bigtable、Pub/Sub 或 Spanner。

  • 程序語言

  • 偵錯陳述式

• 持續查詢不支援下列資料來源：

  • 外部資料表。
  • 資訊結構定義檢視畫面。
  • Apache Iceberg 代管資料表。請注意，Iceberg 受管理資料表不支援做為資料來源，但支援做為持續查詢輸出內容的目的地。
  • 萬用字元資料表。
  • 變更資料擷取 (CDC) upsert 資料。
  • 具體化檢視表。
  • 檢視區塊：底層 SQL 查詢使用不支援的功能，例如使用者定義函式、外部資料表或啟用 CDC 的資料表。

• 連續查詢不支援column-和資料列層級安全防護功能。

• 持續查詢的輸出內容須遵守輸出目的地服務的固有配額和限制。

• 將資料匯出至 Bigtable、Spanner 或 Pub/Sub 地理位置端點時，您只能以 Bigtable、Spanner 或 Pub/Sub 資源為目標，這些資源必須與包含所查詢資料表的 BigQuery 資料集位於相同的 Google Cloud區域界線內。將資料匯出至 Pub/Sub 全域端點時，這項限制不適用。如要進一步瞭解如何匯出至 Bigtable 應用程式設定檔導向政策，請參閱「位置考量事項」。

• 您無法從資料畫布執行持續查詢。

• 持續查詢作業執行期間，您無法修改持續查詢中使用的 SQL。詳情請參閱「修改持續查詢的 SQL」。

• 如果持續查詢工作處理傳入資料的速度落後，且輸出時間戳記延遲超過 48 小時，就會失敗。您可以再次執行查詢，並使用 APPENDS 或 CHANGES 變更記錄函式，從您停止先前持續查詢作業的時間點繼續處理。詳情請參閱「從特定時間點開始執行持續查詢」。

• 以使用者帳戶設定的持續查詢最多可執行兩天。使用服務帳戶設定的持續查詢最多可執行 150 天。達到查詢執行時間上限時，查詢會失敗，並停止處理傳入資料。

• 雖然持續查詢是使用 BigQuery 可靠性功能建構而成，但偶爾還是會發生暫時性問題。問題可能會導致系統自動重新處理部分持續查詢，進而造成持續查詢輸出內容出現重複資料。請設計下游系統來處理這類情況。

預訂限制

• 您必須建立 Enterprise 版或 Enterprise Plus 版的預留項目，並使用CONTINUOUS指派類型，才能執行連續查詢。持續查詢不支援隨選運算帳單模式。
• 建立CONTINUOUS 預留項目指派時，相關聯的預留項目最多只能有 500 個運算單元。如要申請提高這項限制，請傳送電子郵件至 [e-mail]。
• 您無法在與持續查詢預留項目指派相同的預留項目中，建立使用不同工作類型的預留項目指派。

• BigQuery 會根據使用 CONTINUOUS 工作類型的預留空間指派設定大小，決定每個專案可同時執行的持續查詢數量。如要允許新工作，BigQuery 必須為每個連續查詢工作設定 10 個運算單元的門檻。在正常執行期間，查詢不一定會耗用所有 10 個時段。這個門檻可確保每個持續查詢作業都有足夠的基準運算容量，可處理傳入資料量突然暴增的情況，不會落後或影響低延遲處理作業。

  為確保查詢順利通過，不會達到並行限制，建議使用自動調整時段。使用自動調度功能時，整體可用配額會根據實際資源需求動態調整。您可以設定較小的基準預留量，並設定自動調度資源上限，確保能輕鬆涵蓋預期並行查詢的每個查詢 10 個運算單元門檻。

• 使用相同預留項目執行多項持續查詢時，個別工作可能無法公平分配可用資源，如 BigQuery 公平性所定義。

自動調度運算單元

持續查詢可使用運算單元自動調度功能，動態調度分配的容量，以因應工作負載。隨著持續查詢工作負載的增減，BigQuery 會動態調整運算單元。

持續查詢開始執行後，會主動監聽傳入資料，這會耗用 Slot 資源。如果預留項目有持續執行的連續查詢，就不會縮減至零個時段。不過，如果閒置的連續查詢主要用於監聽傳入資料，預期會消耗最少的時段，通常約 1 個時段。

閒置運算單元共用

持續查詢可使用閒置運算單元共用功能，與其他預留項目和工作類型共用未使用的運算單元資源。

• 您仍須CONTINUOUS 指派預留項目，才能執行持續查詢，且無法單獨依賴其他預留項目的閒置運算單元。因此，CONTINUOUS預留項目指派作業需要非零的運算單元基準，或非零的運算單元自動調度資源設定。
• 只有閒置的基準運算單元或來自CONTINUOUS預留項目指派的承諾運算單元可以共用。自動調整的運算單元無法做為其他預留項目的閒置運算單元共用。

定價

持續查詢可使用 BigQuery 流暢擴充。

持續查詢採用 BigQuery 運算資源運算定價，以運算單元為單位。如要執行連續查詢，您必須擁有使用 Enterprise 或 Enterprise Plus 版本的預留位置，以及使用 CONTINUOUS 工作類型的預留位置指派。

使用資料擷取和儲存空間等其他 BigQuery 資源時，系統會按照 BigQuery 定價頁面顯示的費率計費。

使用其他服務時，如果這些服務會接收持續查詢結果，或是在持續查詢處理期間呼叫，則會按照這些服務的發布費率收費。如要瞭解持續查詢使用的其他 Google Cloud 服務定價，請參閱下列主題：

• Bigtable 計費方式
• Pub/Sub 定價
• Spanner 定價
• Agent Platform 計價方式

估算運算單元容量需求

由於每項工作負載都不盡相同，因此通常無法預先準確估算連續查詢的配額。連續查詢所需的運算單元數量取決於多項因素：

• 同時執行的持續查詢數量。
• SQL 陳述式的複雜度。
• 使用有狀態的處理函式，包括視窗時間長度、JOINs 和匯總。
• 傳入資料的速率或速度。
• 擷取資料的結構和大小。

從概念上來說，您可以根據持續查詢工作負載，估算運算單元總需求量：

預估時段 ≈ 連續查詢次數 x ∑ (資料速率 x 查詢複雜度)

實際的時段用量取決於您獨特的工作負載和資料模式，因此估算成本最準確的方法是監控正在執行的工作。您可以使用 INFORMATION_SCHEMA 檢視畫面，評估獨立持續查詢執行的尖峰運算單元使用量。如需詳細操作說明和範例查詢，瞭解如何追蹤一段時間內的時段用量，請參閱「查看時段消耗資訊」。

後續步驟

請嘗試建立持續查詢。