Databricks近期釋出了一份戰略框架，指導企業將資料和人工智慧工作負載從Google BigQuery遷移到開放的Databricks Lakehouse架構。該框架指出，遷移不僅僅是複製表，而是一項需要分階段推進的戰略演進，涉及流程、技術和人員三大支柱，旨在以最小 disruption 實現可衡量的業務影響。
許多組織目前在BigQuery上執行多種資料和分析工作負載，但正在探索如何將BI、ETL和多模態AI工作負載納入統一的治理和運營模型。開放的Lakehouse架構配合統一的治理層，可以幫助簡化運營、跨資料和AI streamlining 合規性、在需求增長時提供可預測的效能，併為新的AI驅動用例奠定基礎。
流程支柱定義瞭如何遷移。遷移旅程按順序進行：評估現狀、選擇入口點、執行遷移、在雙執行中驗證，然後退役舊平臺。評估是第一步，因為不瞭解當前執行情況就無法選擇正確的入口點。企業應首先對BigQuery資產進行剖析，包括資料集、查詢歷史和槽位消耗，以找出哪些工作負載驅動成本、哪些儀表板實際被使用、哪些表從未被查詢。開源工具Lakebridge包含一個BigQuery剖析器，可以自動化這一發現過程，從而圍繞實際使用情況而非僅僅存在的內容來規劃遷移波次。
選擇策略時，有兩種主要路徑：BI優先和ETL優先。BI優先適合那些需要擴充套件儀表板/資料產品並且分析師希望使用AI功能的團隊。企業可以在Databricks上重建最常用的儀表板，初期直接讀取BigQuery資料，然後逐個用例切換團隊，並排證明一致性。回報從第一天起就可見：更快的儀表板和Genie的自然語言問答。ETL優先則優先考慮後端，目標是將轉換工作負載整合到Databricks的Photon/Spark引擎上，最佳化成本和效能。這條路徑適合希望先建立AI就緒的資料基礎，然後讓下游消費者如儀表板和應用程式跟進的團隊。權衡之處在於可見性：業務使用者在管道落地之前幾乎看不到變化，因此需要隨每個波次釋出執行時和效率指標。當不確定時，讓評估來決定：高儀表板使用率指向BI優先；重型轉換工作負載指向ETL優先。
無論選擇哪種入口點，都應分波次遷移，而不是一次性切換。一次性切換將所有風險集中在單一時刻，一旦出現問題，整個專案的信任也會受損。波次可以縮小影響範圍：根據對組織的價值（領導層可見度、直接影響收入的程度、合規截止日期的緊迫性、日常依賴人數）和遷移複雜性兩個維度對工作負載進行排序，從高價值、低複雜性的地方開始。每個波次都應交付可見的業務成果，在下一波次開始前進行對賬，並使團隊的操作手冊更加成熟。只有對於小型、低風險的資產，當執行兩個平臺的成本超過其保護價值時，才考慮一次性切換。
執行階段包括直接遷移和現代化改造。直接遷移將現有SQL邏輯原樣遷移到Databricks Lakehouse，快速建立可工作的基線，讓團隊在最佳化前驗證一致性。現代化改造則在穩定後，將高價值管道重構為Lakeflow Spark宣告式管道，實現自動化編排、內建資料質量以及批流統一的框架。大多陣列織會經歷一個雙執行階段，使用Lakehouse Federation來“影子”工作負載進行驗證。投資回報的關鍵是設定明確的成功標準（例如99.9%的一致性），以觸發立即退役舊管道，消除執行兩個平臺的成本。
雙執行可以雙向進行，正確的橋樑取決於入口點。BI優先的團隊使用Lakehouse Federation讓Databricks讀取BigQuery，同時儀表板先遷移。ETL優先的團隊則反過來：將資料攝入和轉換遷移到Databricks，將整理好的表以開放格式落地，讓BigQuery繼續從同一份單一副本為現有儀表板和應用程式提供服務——無需雙寫管道、無需匯出作業、無需協調第二份副本。
遷移波次可以保持雙執行視窗短暫而狹窄：只有當前波次的工作負載承擔同時執行在兩個平臺上的成本，因此雙執行的費用與實際進行中的工作成比例，而非整個資產。將BigQuery視為服務層是一種過渡狀態而非目的地：外部表在BigQuery側是隻讀的，並且存在限制，例如模式更改後需要手動重新整理模式，因此應將服務層的切換作為旅程的最後一步。
治理方面，Unity Catalog將治理從障礙轉變為戰略引擎。它提供無縫的三層對映（專案→目錄，資料集→模式，表→表），複製BigQuery許可權，同時增加自動的端到端血緣，並將AI模型視為一等公民。這種對映比物件層次更深。Unity Catalog原生提供同樣的細粒度保護：行過濾器逐行限制訪問，列掩碼和標籤處理列級安全——因此保護隨資料一起移動，而不是從頭重建。一個來自現場的排序規則：先遷移許可權，再遷移資料，這樣每個波次的切換隻改變表的位置，而不改變誰可以看到它。
技術支柱側重於將資料遷移到Google Cloud Storage等服務的開放格式，將邏輯遷移到Databricks SQL和Spark，並驗證結果。從BigQuery遷移到Databricks涉及三個工作流：資料遷移、邏輯遷移和驗證。
資料遷移根據資料量和新鮮度選擇路徑。批次歷史資料透過BigQuery匯出到Google Cloud Storage上的Parquet最快，通常是大規模下最經濟的路線，而且匯出同時作為凍結的時間點副本，簡化驗證。持續更新的表透過Storage API聯結器讀取或在源端重定向，小型且頻繁變化的資料集可以透過聯邦查詢保持可查詢，直到其波次到來。所有資料都以開放格式落地，為medallion層做好準備。
邏輯遷移方面，永遠不要手動轉換整個資產。三個層級覆蓋：基於規則的轉譯（如Lakebridge）處理大部分常規SQL，LLM輔助轉換處理方言差異，工程師保留給真正複雜的尾部。編排遵循相同模式：計劃查詢和Composer DAG對映到Lakeflow Jobs。
驗證應像遷移本身一樣認真預算——在現場，它通常消耗相當的努力。在三個層面執行驗證：完整性（行數）、一致性（模式和型別）和準確性（聚合對賬加行級雜湊），使用Lakebridge reconcile自動化，它支援BigQuery作為原生源。一個現場教訓：兩個SQL方言之間小的內建函式差異可能破壞雜湊比較——在假設資料丟失之前調查不匹配。這裡的一致性是流程旅程中觸發退役的關鍵。
開放表格式的回報在遷移完成之前就已經顯現。由於Delta Lake和Apache Iceberg是開放格式，落地在Google Cloud Storage上的表可以被不止Databricks讀取：BigQuery透過BigLake外部表讀取Delta，透過Iceberg外部表讀取Iceberg，而Unity Catalog和BigQuery之間的目錄聯邦（目前處於預覽階段）讓兩個平臺無需複製即可治理和查詢相同的表。儲存與引擎解耦——一份資料，多個引擎。這種互操作性不是副作用；它是流程部分描述的低風險過渡模式背後的能力。
人員支柱提供遷移的最終投資回報：一個更有能力、統一的勞動力。結束交接文化。在傳統棧中，SQL分析師和資料科學家之間的差距造成孤島。在Databricks中，共享筆記本讓整個“小隊”生活在同一個工作空間，減少溝通開銷。
構建新技能集。Genie作為SQL密集型團隊的橋樑。分析師可以使用自然語言生成Python或Spark程式碼，將傳統分析師轉變為多才多藝的資料從業者，而無需陡峭的學習曲線。將日常AI輔助與結構化培訓、Databricks Academy課程和基於角色的認證相結合，使新技能集在整個組織紮根，而不是依賴於少數自學成才的早期採用者。
工程嚴謹性。團隊透過採用Unity Catalog、Git整合和CI/CD等軟體工程最佳實踐，從“編寫查詢”轉向“構建資料產品”。
來自現場的六條經驗：規劃前先剖析；在雙執行開始前定義一致性標準；不要手動轉換SQL；先一對一對映治理，再現代化；將BI優先視為變更管理專案；合理調整平臺足跡。
結論：遷移到Databricks不是一次跳躍，而是一系列可以實際規劃的決策：哪個入口點適合你的團隊，如何安排波次以便每個波次在下一個開始前獲得成果，以及哪個橋樑讓BigQuery和Databricks並行執行直到最後一個儀表板切換。把順序搞對，流程、技術和人員就會相互加強：資料遷移、邏輯轉換和驗證退役舊的資產，為AI就緒的Lakehouse讓路。