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讓路。