題幹與適用情境
關聯式資料包含客戶、帳戶與轉帳關係。面試官要求你回答：什麼時候應使用 BigQuery Graph、什麼時候保留遞迴 SQL，並設計可驗證的遷移與回退方案。
題目適合資料工程、分析工程與資料平台職缺。假設資料已在 BigQuery，圖功能仍處於 Preview；不能把 Preview 視為無條件的正式承諾。重點是比較多跳關係表達、治理、成本與相容性，而不是宣稱某種查詢語言永遠更快。
面試官考察點
面試官會看你能否先辨識關係查詢形狀，再選擇圖模式或關聯模式；能否區分業務語意、執行計畫與平台生命週期。高品質回答會說明圖模式如何與既有資料表共存、何時遞迴 SQL 更簡單，以及如何用同一組基準結果驗證遷移。
作答前需要釐清的問題
- 查詢是固定深度的階層展開，還是深度與路徑條件經常變動？
- 需要回傳節點、邊與路徑，還是只要聚合後的指標？
- 圖資料是批次分析，還是要求低延遲線上遍歷？
- 結果是否必須與既有 SQL 報表逐列一致，Preview 相容窗口可多長？
- 預算、掃描量、併發、資料新鮮度與下游用戶端版本限制是什麼？
30 秒回答架構
「我先按照查詢形狀與交付目標分流：固定一到兩層、簡單聚合且已有 SQL 資產的情境保留 SQL；多跳模式、路徑條件與關係重用頻繁時評估 BigQuery Graph。先建立節點、邊、標籤與主鍵約束，再用同一批快照比較 GQL 與遞迴 SQL 的結果、掃描量、延遲與成本。Graph 處於 Preview，所以採用影子執行與可回退的 SQL 主路徑，門檻通過後才擴大。」
分步深入解答
1. 先把關聯問題寫成圖問題
把 Person、Account 當成節點，把 Owns、Transfers 當成有方向的邊；為每條邊定義時間、金額與唯一識別碼。如果問題是「找三跳內可達帳戶並按風險聚合」，圖模式能直接表達路徑；如果只是按日期分組統計轉帳金額，關聯表與一般 JOIN 更容易稽核。
2. 用查詢形狀決定技術路線
固定深度、固定表結構且只回傳指標時，遞迴 SQL 的可讀性與既有權限模型通常更有價值。深度變動、路徑模式重用、節點與邊需要同時回傳時，GQL 的 GRAPH、MATCH、NEXT 與 RETURN 讓意圖更接近業務關係。選擇依據是變動頻率與維護成本，不是把 GQL 當成 SQL 的全面替代。
3. 建模並固定語意邊界
先定義標籤、方向、可空屬性、時間有效期與重複邊處理。規定同一業務關係的主鍵，避免重複載入放大路徑計數；規定是否允許回到已造訪節點，避免循環圖造成無界遍歷。圖模式只負責關係表達，敏感欄位仍沿用資料集權限、欄級策略與稽核規則。
4. 設計可重算的雙跑基準
選擇有代表性的快照與查詢族：單跳鄰居、兩跳轉帳、帶時間過濾的路徑、重複邊與無結果樣例。遞迴 SQL 與 GQL 輸出統一投影到節點 ID、邊 ID、路徑長度與聚合值，再比較集合與計數。記錄 bytes processed、slot 使用量、p50/p95 延遲、失敗率與結果新鮮度；不要只比較一次牆鐘時間。
snapshot = freeze_partition(as_of)
expected = run_recursive_sql(snapshot, query_family)
candidate = run_gql_graph(snapshot, query_family)
assert canonicalize(expected) == canonicalize(candidate)
gate = error_rate < 0.01 and p95_ms <= budget and cost_per_query <= limit5. 處理 Graph 與 SQL 的互通
需要繼續接入報表時，把圖查詢結果投影成資料表，再與 SQL 聚合或維度表結合；需要重用同一份關係資料時，避免複製節點與邊。Google 文件說明圖查詢可透過 GRAPH_TABLE 與 SQL 查詢組合，因此遷移可以按查詢族切分，而不是一次重寫所有資料管道。
6. 評估 Preview、成本與回退
Preview 功能要獨立記錄可用區域、版本、配額與支援邊界。先讓 SQL 作為主路徑，Graph 做影子執行；只有結果一致、成本在預算內、權限與監控齊全時，才按查詢族開啟。任何 schema 漂移、結果差異、配額錯誤或成本異常都回退到 SQL，並保留快照、查詢文字與執行指標。
高品質示範回答
我會先區分查詢形狀。固定深度、固定欄位與簡單聚合的報表繼續使用遞迴 SQL，減少 Preview 依賴與遷移成本；需要可變深度、路徑模式、節點與邊同時回傳的探索型分析，才評估 BigQuery Graph。建模時把客戶與帳戶建成節點，把擁有與轉帳建成有方向的邊，並固定主鍵、方向、時間有效期與循環規則。遷移採用同一快照雙跑：把 GQL 與遞迴 SQL 結果規範化到相同的節點、邊、路徑長度與指標，再比較結果、掃描量、p95、失敗率與成本。SQL 先作為主路徑，Graph 影子執行；Preview 的區域、配額或版本發生變化，或任一門檻失敗，就回退 SQL。這樣同時涵蓋表達能力、治理、成本與回滾，而不是只宣稱圖查詢更快。
常見錯誤
- 看到多表 JOIN 就立刻換圖 → 固定深度的聚合未必需要圖模型 → 先按查詢形狀分流。
- 只比較一條查詢的延遲 → 快取、快照與資料傾斜會製造偶然結果 → 使用查詢族和固定快照比較。
- 忽略重複邊與循環 → 路徑計數可能被放大或無法終止 → 定義主鍵、造訪規則與最大深度。
- 把 Graph Preview 當成穩定依賴 → 區域、配額與語意可能變動 → SQL 主路徑、影子執行與回退門檻。
- 遷移時複製一份圖資料 → 雙份資料帶來新鮮度與治理分叉 → 優先重用同一資料源並投影結果。
追問及應對
如果查詢深度從兩跳變成任意深度，決定會改變嗎？
會。任意深度與路徑條件會提高遞迴 SQL 的維護與資源風險，Graph 的路徑表達更合適；仍要設定最大深度、節點造訪上限與成本門檻，不能接受無界遍歷。
如果業務要求一秒內回傳線上結果怎麼辦？
先確認 BigQuery 批次分析是否符合延遲。若不符合，保留線上圖儲存或預計算索引，BigQuery Graph 用於批次校驗與歷史分析；不要為了統一語言犧牲線上 SLO。
如何證明 GQL 與遞迴 SQL 結果一致？
凍結同一分區快照，使用查詢族涵蓋空結果、重複邊、時間邊界與循環，再把輸出規範化為穩定鍵與聚合值比較。差異必須保留最小樣例、查詢版本與資料快照。
什麼時候可以移除 SQL 回退？
Preview 狀態、區域與用戶端相容性穩定，連續多個資料週期通過結果、成本、延遲、權限與故障演練門檻後，再由資料負責人批准；否則保留 SQL。
圖模式包含敏感關係時，權限怎麼承接？
沿用資料集、欄級與列級策略，並在圖查詢結果投影處再次檢查可見欄位。節點或邊的可達性本身可能洩漏關係，必須把路徑暴露納入稽核樣例。