Databricks 發布 BigQuery 遷移策略框架與 Lakebridge 工具

背景

許多組織目前在 Google BigQuery 上執行多種資料與分析工作負載，正尋求將商業智慧（BI）、資料抽取轉換載入（ETL）與多模型人工智慧（AI）工作負載整合到單一治理與營運模型中。開放式 Lakehouse（湖倉一體架構）搭配統一治理層，旨在簡化營運、精簡資料與 AI 的合規流程，並隨著需求增長提供可預測的效能，同時為新的 AI 驅動用例奠定基礎。 Databricks Blog

發生什麼事

Databricks 發布了一份關於從 Google BigQuery 遷移至開放式 Databricks Lakehouse 架構的策略框架。該框架涵蓋流程（Process）、技術（Technology）與人員（People）三大支柱，旨在以最小干擾和可衡量的業務影響來導航這一過渡過程。 Databricks Blog

重點內容

在流程支柱中，遷移旅程依序為評估、選擇切入點、遷移、雙重運行驗證，最後退役舊系統。評估階段需先剖析 BigQuery 資產，找出驅動成本的工作負載與實際使用的儀表板。Databricks Labs 的開源遷移工具包 Lakebridge 包含一個 BigQuery 分析器（profiler），可自動化此發現過程，讓遷移波次規劃基於實際使用情況而非僅存在於系統中的資產。 Databricks Blog

遷移策略分為 BI 優先與 ETL 優先兩種路徑。BI 優先路徑適合需要擴展儀表板且分析師希望使用 AI 功能的團隊，初期透過 Databricks 就地讀取 BigQuery 資料來重建儀表板，並逐步切換團隊，利用 Genie 實現自然語言問答。ETL 優先路徑則適合希望先建立 AI 就緒資料基礎的團隊，將轉換工作負載整合至 Databricks 的 Photon/Spark 引擎以優化成本與效能，但業務使用者在管線落地前較難看到變化。 原文

在技術支柱方面，資料遷移根據資料量與新鮮度選擇路徑：大量歷史資料透過 BigQuery 匯出為 Parquet 格式存於 Google Cloud Storage；持續更新的表格則透過 Storage API 連接器讀取或從源頭重定向。邏輯遷移採用三層方法：規則型轉譯（如 Lakebridge）處理常規 SQL，大型語言模型（LLM）輔助轉換處理方言差異，工程師處理複雜尾端。驗證階段需預算與遷移本身相當的精力，涵蓋完整性（行數）、一致性（結構）與正確性。 原文

治理方面，Unity Catalog 提供無縫的三層映射（Project 對應 Catalog、Dataset 對應 Schema、Table 對應 Table），在複製 BigQuery 權限的同時，增加自動端到端血緣追蹤，並將 AI 模型視為一等公民。Unity Catalog 原生提供細粒度保護，包括行過濾（row filters）與欄位遮罩（column masks），確保保護措施隨資料移動，而非從頭重建。 原文

對使用者的意義

該框架協助企業將 BI、ETL 與多模型 AI 整合於單一環境，透過統一工作區降低營運負擔並提供可預測效能。Lakehouse 提供「AI 就緒」的基礎，讓 SQL 團隊能在保持總擁有成本（TCO）低的情況下構建進階資料產品。開發者可使用 Lakebridge 工具自動化遷移關鍵活動，包括評估、邏輯轉換與驗證。 Databricks Blog

限制與未定事項

Lakebridge 專案僅供探索使用，並非由 Databricks 正式支援，不提供服務級別協議（SLA）。該專案以「現狀」（AS-IS）提供，不保證任何功能，用戶不應就使用此專案產生的問題提交支援工單，發現的問題應透過 GitHub Issues 回報，且無正式支援 SLA。 官方原文・github.com