持續查詢簡介

本文說明 BigQuery 持續查詢。

BigQuery 持續查詢是會不斷執行的 SQL 陳述式，持續查詢功能可即時分析傳入 BigQuery 的資料。您可以將持續查詢產生的輸出資料列插入 BigQuery 資料表，或匯出至 Pub/Sub、Bigtable 或 Spanner。持續查詢可使用下列其中一種方法，處理已寫入標準 BigQuery 資料表的資料：

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

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

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

用途

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

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

支援的功能

持續查詢支援下列作業：

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

• 執行 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 函式，例如轉換函式。在無狀態函式中，系統會獨立處理資料表中的每一列。

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

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

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

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

支援的有狀態作業

預覽

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

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

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

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

• JOIN
• 匯總和視窗化

授權

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

位置

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

限制

持續查詢必須遵循以下限制：

• 只有預先發布版中的特定有狀態作業，才會保留擷取資料的狀態。雖然連續查詢現在支援某些類型的 JOIN、匯總和視窗匯總，但這些僅限於特定有狀態作業。並非所有有狀態作業類型都支援這項功能。

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

  • 下列查詢運算子：

    • PIVOT
    • UNPIVOT
    • TABLESAMPLE

  • 查詢集合運算子

  • SELECT DISTINCT 陳述式

  • EXISTS 或 NOT EXISTS 子查詢

  • 遞迴 CTE

  • 使用者定義函式

  • window 函式呼叫

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

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

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

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

  • 不以 Bigtable、Pub/Sub 或 Spanner 為目標的 EXPORT DATA 陳述式。

  • 程序語言

  • 偵錯陳述式

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

  • 外部資料表。
  • 資訊結構定義檢視畫面。
  • Apache Iceberg 代管資料表。
  • 萬用字元資料表。
  • 變更資料擷取 (CDC) 新增或更新 資料。
  • 具體化檢視表。
  • 檢視區塊：底層 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 和匯總。
• 傳入資料的速率或速度。
• 擷取資料的結構和大小。

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

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

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

後續步驟

請嘗試建立持續查詢。