資料工程面試：如何評估 BigQuery continuous queries？

題幹與適用場景

業務希望資料寫入 BigQuery 後儘快觸發告警，並把結果寫入資料表或匯出到 Pub/Sub、Bigtable、Spanner。請說明是否採用 BigQuery continuous queries，如何處理輸入、權限、執行時間、區域、成本和失敗恢復。不要只描述 SQL 語法。

面試官考察點

是否理解 continuous query 是持續執行的 SQL，不是固定間隔的批次輪詢。
是否能依延遲、輸出目標和資料語義判斷它與 Dataflow、Pub/Sub 或普通查詢的邊界。
是否核對 Enterprise 版本、CONTINUOUS reservation、服務帳號和區域限制。
是否能說清楚重複輸出、背壓、監控、重啟和成本控制。

回答前需要釐清的問題

輸入是追加寫入，還是會更新、刪除既有列？結果允許重複或需要精確一次語義嗎？
目標是 BigQuery 表、Pub/Sub、Bigtable 還是 Spanner？下游能處理重試嗎？
可接受延遲、執行時間和資料區域是什麼？專案具備所需版本與 reservation 嗎？
失敗重啟後從哪裡恢復，如何監控延遲、積壓、錯誤和輸出數量？

30 秒回答框架

我會先確認需求是否真的是持續串流處理：continuous query 適合在 BigQuery 中持續分析進入的資料並輸出到指定目標，但有版本、容量、授權和區域約束。先確定輸入與結果的冪等鍵，再選輸出目標和重試策略；為持續工作準備服務帳號、CONTINUOUS reservation 和監控。上線前用小流量驗證延遲、重複、成本和停止恢復，不能把它當成無限執行且零成本的 Cron 替代品。

分步驟深入解答

1. 先劃定資料語義

Continuous query 會持續處理寫入 BigQuery 表的資料。追加事件、遲到資料、更新和刪除的處理方式不同；若業務需要複雜狀態、事件時間視窗或嚴格順序，應先確認官方支援的 SQL 能力，並評估 Dataflow 等串流處理引擎。

2. 選擇輸出路徑

官方文件支援把結果插入 BigQuery 表，或用 EXPORT DATA 匯出到 Pub/Sub、Bigtable、Spanner。選擇時看下游吞吐、順序、冪等和區域約束。Pub/Sub 適合再接事件處理；直接寫表則要設計去重鍵和保留策略。

3. 核對執行與授權條件

建立和執行 continuous query 可使用使用者帳號或服務帳號；匯出到 Pub/Sub 必須使用服務帳號。使用者帳號工作最長可執行兩天，服務帳號最長可執行 150 天。持續查詢需要 Enterprise 或 Enterprise Plus edition，以及類型為 CONTINUOUS 的 reservation assignment，不能假設預設專案即可執行。

4. 預算、監控與恢復

持續查詢按 BigQuery capacity compute 計費，其他輸出服務另計費。監控持續查詢專屬指標、輸入到輸出延遲、錯誤、重啟次數和輸出量；為工作定義停止、重建和告警流程。恢復時應依冪等鍵或水位重做可接受範圍，避免重啟造成重複副作用。

高品質示範回答

我會先把 continuous query 當成資料產品的執行約束來評估。它適合持續分析寫入 BigQuery 的資料，並把結果寫回表或匯出到 Pub/Sub、Bigtable、Spanner；但輸入是追加還是變更、結果是否允許重複，會決定它能否滿足語義。接著核對 Enterprise 版本、CONTINUOUS reservation、服務帳號、工作最長執行時間和區域邊界。輸出端設計冪等鍵、重試與死信處理，監控輸入延遲、積壓、錯誤和成本。上線前用受控流量驗證延遲和重啟行為，明確暫停、恢復與重新補數方案。若需要複雜事件時間狀態、嚴格順序或更長生命週期，就把它和專用串流方案比較，不要強行把所有即時需求塞進 BigQuery。

常見錯誤

把 continuous query 當成每分鐘執行一次的普通查詢。
忽略 Enterprise/Enterprise Plus、CONTINUOUS reservation 或服務帳號要求。
認為匯出到所有目標都有相同的順序和重複語義。
沒有為重啟、重複輸出和遲到資料定義水位或冪等鍵。
只看 SQL 延遲，不計算 BigQuery capacity 與下游服務成本。
把兩天或 150 天的工作時限誤解為永久執行保證。

追問及應對

什麼時候選擇 Dataflow？

當需求包含複雜事件時間視窗、狀態管理、嚴格順序、豐富連接器或需要長期執行的串流拓撲時，應把 Dataflow 等專用引擎納入比較。依據是語義和運維邊界，不是只比較一條 SQL 的長度。

重啟後如何避免重複告警？

讓輸出帶事件或業務冪等鍵，下游用去重或交易寫入；記錄輸入水位和處理批次，恢復時從安全邊界重放，並把不可避免的重複當作協定約束公開給消費者。

如何判斷成本是否可接受？

分別估算 continuous query 的 capacity slots、輸入與儲存，以及 Pub/Sub、Bigtable 或 Spanner 費用；壓測持續負載、閒置時段和峰值，再用監控中的延遲與 slot 消耗校準預算。