現代化數據分析標準：BigQuery 湖倉一體與 BigQuery ML 實戰架構

BigQuery 是 Google Cloud 的無伺服器數據倉儲，核心設計是把運算與儲存徹底分開：查詢忙碌時只擴充運算資源，資料量成長時儲存層獨立擴充，兩邊互不牽制。這套骨架撐起了 2026 年更名的湖倉一體能力（BigLake 正式改稱 Lakehouse for Apache Iceberg），也讓你能在同一個 SQL 介面裡訓練機器學習模型，甚至直接呼叫 Gemini 做文字生成，不必另外搭一套資料科學工具鏈。

這篇會照這個順序講：底層引擎的設計哲學、湖倉一體的更名與能力、跨雲與目錄聯邦怎麼讓資料不用搬家、即時複製，最後是 BigQuery ML 在 SQL 裡怎麼直接調用模型。

BigQuery 的每一項延伸能力，包括湖倉一體、跨雲查詢、即時複製與 BigQuery ML，全部長在同一個骨架上：運算與儲存徹底分離。

為什麼 BigQuery 要把運算與儲存分開設計？

BigQuery 是 Google Cloud 的無伺服器數據倉儲，底層的查詢引擎叫 Dremel，設計理念是讓查詢用的運算資源，跟資料實際存放的儲存層徹底分開。

這個分離帶來兩個實際好處：查詢忙碌的時候，運算資源可以獨立擴展，不需要因為要多算一點就先買更多硬碟；資料量成長的時候，儲存層也不會被運算資源的規格綁住。這也是為什麼 BigQuery 同時提供隨選付費（依實際掃描的資料量計費）與預留容量兩種計費模式：兩者都是在同一層儲存之上，切換不同的運算配置方式，不需要搬動資料本身。

這套哲學不是 2026 年才有的新東西，是 BigQuery 從一開始就定下的骨架，後續所有的湖倉一體、跨雲查詢能力，都是長在這個骨架上的延伸。

BigLake 為什麼更名為 Lakehouse for Apache Iceberg？

2026 年 4 月，Google 把 BigLake 正式更名為 Lakehouse for Apache Iceberg，BigLake metastore 也跟著改稱 Lakehouse runtime catalog。既有的 API、用戶端程式庫、CLI 指令與 IAM 名稱維持不變，仍然沿用 BigLake 字樣。

受控的 Iceberg 資料表已經正式推出（GA），把開放格式 Iceberg 的彈性，加上 BigQuery 原本的自動化能力接在一起：自動表管理、Iceberg 分區與叢集、多資料表交易、變更資料擷取（CDC），都是內建功能而不用自己另外搭一套維運。

常見的誤解，是以為只要把資料表建成 Iceberg 格式，變更資料擷取跟多資料表交易就會自動生效。實務上這些屬於各自獨立的功能開關，設定 Iceberg 資料表只是前提，仍要另外啟用對應能力，建表前建議先確認清楚要用到哪些具體特性，避免上線後才發現少開了一個選項。

資料留在別的雲上，還能用 BigQuery 查詢嗎？

跨雲湖倉查詢（cross-cloud lakehouse）目前處於預覽階段，目標是把 BigQuery 的分析與 AI 能力延伸到 AWS 與 Azure 上，透過 Iceberg REST Catalog 這類開放標準，加上跨雲高頻寬連線與透明快取，就地查詢留在其他雲端上的資料。

另一個方向是目錄聯邦（catalog federation），同樣在預覽階段，讓你能發現、分析並零複製共享來自 AWS Glue、Databricks、SAP、Salesforce、Snowflake 等系統的資料目錄，未來還會擴及 Confluent Tableflow。

這類能力最常見的使用情境，是併購後留下多雲環境、或部分子公司因為資料主權限制必須把資料留在特定雲端。與其花時間搬遷資料、承擔搬遷過程的風險與停機視窗，先用跨雲查詢驗證分析需求是否成立，再決定要不要真的搬家，通常是比較務實的順序。預覽階段的功能在地區覆蓋與功能完整度上可能還有限制，正式導入前建議先用小範圍資料驗證。

即時資料擷取能把交易資料庫的變動即時同步進 BigQuery 嗎？

分析永遠面對一個老問題：交易系統裡的資料一直在變，分析表卻常常是昨天甚至上週的快照。BigQuery 現在支援把 Spanner、AlloyDB、Cloud SQL 的資料即時複製進 BigQuery 資料表，這個能力已經正式推出。

複製進 Iceberg 格式的即時能力，目前多半還在預覽階段。整體方向是讓交易層與分析層之間的延遲從「批次排程的小時等級」拉近到「幾乎即時」，實際可用範圍請以官方文件為準。導入前也要留意下游成本：即時複製代表分析層要承接更高頻率的寫入，容量與成本規劃要跟著調整，不是單純把開關打開就結束。

不寫 Python，也能在 BigQuery 裡訓練機器學習模型嗎？

BigQuery ML 讓熟悉 SQL 的人，不用學一套新工具鏈也能做機器學習。它涵蓋的模型類型分成幾類：

• 監督式模型：線性迴歸、邏輯迴歸、梯度提升樹、隨機森林、深度神經網路等，多半用於預測數值或分類問題。
• 非監督式模型：K-means 分群、主成分分析（PCA）等，適合探索資料裡尚未被標記的結構。
• 外部匯入模型：ONNX、TensorFlow、XGBoost 格式訓練好的模型，可以直接匯入做推論，不必重新訓練。
• 遠端模型：指向 Vertex AI 或 Gemini Enterprise Agent Platform 上模型的物件，透過 ML.GENERATE_TEXT 等函數，直接在 SQL 查詢裡對 Gemini 下提示，做文字生成、摘要或翻譯，訓練與推論都在對應平台端處理。

實務上要提醒的是，BigQuery ML 適合快速做出一個可用的基準模型，或是把已經訓練好的模型接進既有的資料管線做推論；它不是要取代完整的 MLOps 流程，複雜的特徵工程、模型可解釋性分析、A / B 測試框架，多數團隊還是會搭配 Vertex AI 或其他專門工具鏈一起用。

導入湖倉一體前，該檢查哪些事？

1. 先確認你真的需要開放格式。 如果資料本來就只留在 BigQuery 生態系裡，原生表格未必需要換成 Iceberg，多一層格式抽象也多一層要維護的東西。
2. 跨雲能力先看是不是還在預覽。 預覽階段的功能適合先驗證可行性，正式導入生產環境前，留意功能完整度與 SLA 承諾。
3. 把 BigQuery ML 定位成第一層篩選，不是取代所有工具。 適合快速用 SQL 跑出一個可用的基準模型，複雜的深度學習場景仍然可能需要 Vertex AI 這類更完整的 MLOps 工具鏈。
4. 即時複製要考慮下游成本。 資料變動即時反映到分析層很吸引人，但也代表分析層要承接更高頻率的寫入，容量規劃要跟著調整。