本文是 Azure Synapse Spark 轉 Microsoft Fabric 遷移最佳實務系列中的第一階段（共四階段）。
在遷移任何筆記本、Spark 工作定義、池或湖泊元資料之前，先從這裡開始。 本文將協助您評估 Synapse Spark 遺產的範圍，選擇符合您風險承受度與交付時程的遷移方式，並了解影響規劃的 Fabric 差異。
完成此步驟後，你應該知道哪些需要移動、使用哪種遷移模式、主要相容性風險在哪裡，以及需要考慮哪些回滾或平行執行的限制。
在本文中，您將學會如何：
- 評估你的 Synapse Spark 足跡。
- 在升降檔、分階段現代化與平行運行之間選擇。
- 考慮回滾與同步化限制。
- 回顧 Synapse Spark 與 Fabric Spark 的主要特色與架構差異。
評估您的 Synapse Spark 使用範圍
Azure Synapse Analytics 涵蓋多種工作負載類型。 本指南重點介紹如何將 Spark 池、筆記本、Spark 工作定義、湖泊資料庫及 Hive Metastore 元資料遷移至 Fabric。 關於專用的 SQL 池、管線、Data Explorer 及安全遷移指引，請參考配套指南。
| 突觸工作量 | Fabric 目的地 | 遷移工具/路徑 |
|---|---|---|
| 火花池 | Fabric Spark（湖屋） | Spark 移轉小幫手 （預覽版）; 手動池/環境移轉 |
| Notebooks | 織物筆記本 | Spark 移轉小幫手;Synapse 專用 API 的程式碼重構 |
| Spark 作業定義 | Fabric Spark 工作定義 | Spark 移轉小幫手（推薦）;如有需要，手動重現 |
| 湖泊資料庫 | Fabric Lakehouse 目錄 | Spark 移轉小幫手（透過捷徑處理 Delta 資料表）；非 Delta 的 HMS 匯出/匯入 |
| Hive Metastore | Fabric Lakehouse 目錄 | HMS 匯出/匯入筆記本檔案; OneLake 資料捷徑 |
| 連結服務 | Fabric 系統連接 / 金鑰庫 | 建立 Fabric 連線;將秘密遷移至 金鑰保存庫;重構筆記本程式碼 |
執行 Fabric 評估工具
在規劃遷移前，先執行 Fabric 評估工具，產生一份完整的 Synapse 來源工作區報告。 該工具會掃描您的工作區，並彙整所有物件的摘要——Spark 池、筆記本、Spark 工作定義、湖泊資料庫、連結服務及其配置——讓您清楚了解遷移範圍。
下載這個工具。 Fabric評估工具可在Microsoft fabric工具箱GitHub倉庫中取得，地址為 microsoft/fabric-toolbox。
執行評估。 將工具指向你 Azure Synapse 工作空間。 它會掃描所有與 Spark 相關的項目，並產生包含物件數量、設定、相依性及潛在相容性問題的報告。
檢閱報告。 利用評估輸出了解遷移範圍：需要遷移多少筆記本、池、SJD 和資料庫，哪些連結服務正在使用，以及可能存在的阻擋因素（GPU 池、不支援的功能等）。
小提示
在規劃過程中就要早期使用評估工具。 報告能幫助你估算工作量、找出阻礙因素，並優先排序要先遷移哪些工作負載。 它同時也是遷移檢查清單第一階段的基準清單。
遷徙模式
根據你的組織限制、風險承受度及時程來選擇遷移模式。
升檔換檔模式
使用 移轉小幫手 一次性遷移所有 Spark 工作負載，且改動極少。 專注於盡快讓筆記本和工作在 Fabric 中執行——只重構那些會出問題的部分（連結服務、檔案路徑、不支援的 API）。 接受目前的架構 as-is。
在以下情況下使用升降檔：
- 你的 Synapse 工作區將在固定期限內退役，你需要迅速行動。
- 你的 Spark 工作負載已經架構完善（Delta 優先、程式碼乾淨、服務依賴較少）。
- 你的工作空間空間規模對於一次性遷移來說是可管理的，團隊也能在一次衝刺內完成重構工作。
- 下游消費者（Power BI、API）可以容忍短暫的切換窗口。
分階段現代化
依優先順序逐步遷移工作負載，邊做邊重新架構。 先從價值最高或風險最低的工作量開始。 在遷移每批次時，將 Spark 池整合到較少的環境，採用 Lakehouse 最佳實務（優先 Delta、BI 消費者使用 V-order）、啟用 NEE，並為 Direct Lake 重新設計。
在以下情況下使用分階段現代化：
- 你有一個龐大或複雜的 Synapse 環境，擁有多個團隊和多樣化的工作負載，無法一次性遷移。
- 你目前的架構有技術債需要解決（非 Delta 格式、掛載點相依、龐大的 Spark 池）。
- 你在時間軸上有彈性，並且希望在遷移過程中提升效能和成本效益。
- 不同的工作負載有不同的擁有者，需要獨立的遷移時程。
平行跑動模式
轉換期間同時執行兩個環境。 將新的 Spark 工作負載路由到 Fabric，而舊有的工作負載則繼續在 Synapse 上。 在切換前，先透過並排比較結果來驗證遷移的工作負載。 隨著信心逐漸建立，逐步解除Synapse的任務。
在以下情況下使用平行跑法：
- 你的工作負載有嚴格的 SLA 或法規要求，要求在切換前需要延長驗證時間。
- 你需要證明 Fabric 的效能達到或超越 Synapse，利益相關者才會批准系統退役。
- 你的下游消費者（儀表板、API、機器學習模型）無法容忍轉換過程中的任何差異。
- 你正在遷移生產管線，錯誤結果會帶來高商業影響（財務報告、合規）。
平行執行會帶來一個必須事先設計的資料同步問題。 請選擇以下圖案之一：
- 共享儲存層： 透過 OneLake 捷徑，Synapse 和 Fabric 都能讀寫同一個 ADLS Gen2 儲存。 這樣兩個平台會維持在相同的 Delta 檔案上，但你必須避免寫入衝突，確保每次只允許一個平台對特定資料表進行寫入。
- Write-once， read-both： 在轉換過程中，讓 Synapse 作為主要寫入者，並讓 Fabric 以快捷方式讀取相同的資料。 在您驗證 Fabric 中遷移的筆記本後，將寫入路徑切換到 Fabric，並將 Synapse 設為唯讀消費者，直至停用。 這是大多數遷徙最安全的選擇。
- 雙重寫入： 除非你已經有自動化比較與對帳工具，否則避免同時在兩個環境下運行同一個 ETL。 雙重寫入往往會產生分歧、重複及操作負擔。
平行執行也會影響變更管理。 雖然 Synapse 仍是主動開發環境，但任何筆記本、Spark 工作定義、Spark 池設定或湖泊資料庫架構的變更，都不會自動反映在 Fabric 中。 你必須重新遷移受影響的資產，才能讓兩個環境保持一致。
-
Notebook 程式碼變更： 重複執行 Spark 移轉小幫手，或手動匯出並匯入更新後的筆記本。 重新套用任何Fabric特定的程式碼重構，包括
notebookutils、更新檔案路徑及金鑰保存庫 機密。 - Spark 工作定義變更： 請透過 移轉小幫手 重新遷移，或在 Fabric 手動重新建立更新後的 Spark 工作定義。
- Spark pool 設定變更： 更新對應的 Fabric 環境以符合修訂後的節點大小、自動縮放設定及函式庫。
- Lake 資料庫架構變更： 重新執行 HMS 匯出/匯入筆記本，或手動建立或修改 Fabric 湖屋中受影響的資料表。
為了減少再次移轉的負擔，在遷移開始時，應在 Synapse 端設置變更凍結。 如果無法避免變更，記得保留變更日誌，這樣切換前可以在 Fabric 重播。
回滾考量
Synapse 遷移到 Fabric 是一種複製操作——它不會修改或刪除你的原始 Synapse 工作區。 你原本的 Spark 池、筆記本和資料在整個過程中都會保持不變。 這使得回滾過程變得簡單直接：
- 如果遷移結果不理想，請繼續使用現有的 Synapse 工作區。 不需要還原任何變更。
- 刪除已遷移的 Fabric 項目（筆記本、環境、Spark 工作定義），並在處理問題後重新嘗試。
- OneLake 捷徑指向你現有的 ADLS Gen2 儲存空間——移除捷徑不會影響底層資料。
- 在所有遷移工作負載在 Fabric 中驗證完畢且下游消費者都重新路由之前，不要停用你的 Synapse 工作空間。
小提示
從小處開始，快速證明可行性。 選擇一個具代表性的 Spark 工作負載，從資源池設定、Notebook 重構，到驗證進行端到端的遷移。 選擇一個能實踐你最常見模式（資料存取、連結服務、目錄操作）但風險足夠低，可以反覆嘗試的方法。 記錄遇到的步驟、問題與解決方案，以建立可重複的後續遷移流程。
功能對等與關鍵差異
了解 Synapse 與 Fabric 的架構差異對規劃至關重要。 以下表格突顯了計算架構與 Spark 能力的主要差異。
完整比較請參見比較 Fabric 與 Azure Synapse Spark：關鍵差異。
運算與架構
| 能力 | Azure Synapse | 織物 |
|---|---|---|
| 部署模型 | PaaS（配置與管理資源） | SaaS（基於容量，無基礎設施管理） |
| 計算模型 | 火花池（節點式）;至少需要 3 個節點 | 容量單元（CU）在所有工作負載間共享;Spark 池作為設定範本;支援單節點執行;Spark 的自動計量計費（按使用付費，類似 Synapse 模式） |
| 火花引擎 | 突觸火花池（Spark 3.4， 3.5）;支援的 GPU 池 | Fabric Spark（執行時間 1.2/1.3/2.0：Spark 3.4–4.0）;不支援 GPU;運行於最新一代硬體以提升效能 |
| 縮放 | Spark 的節點自動縮放（最小 3 個節點） | Spark 的節點自動縮放（單一節點最小值）;容量基礎縮放 |
| 會話啟動 | 以游泳池為基礎;新叢集的冷啟動 | 起始池（秒級啟動）；自訂實時池；高並發模式 |
| 成本模型 | 每個節點-小時（Spark）;暫停/繼續 | 有兩種選擇：（1） Fabric Spark 採用基於容量單位（CU）的共享用電模式，或 （2） Spark 自動計費——即付隨用 Spark 模式 |
Spark：「Synapse Spark」與「Fabric Spark」的差異分析
| 能力 | 突觸火花 | Fabric 火花 |
|---|---|---|
| Spark 版本 | Spark 3.4（終止）、3.5（預覽）。 | Spark 3.4（RT 1.2 生命週期結束）、3.5（RT 1.3 一般可用）、4.0（RT 2.0 預覽版） |
| 查詢加速 | 沒有原生加速引擎 | 原生執行引擎（Velox/Gluten，在TPC-DS基準測試中性能最高可達 4 倍） |
| 泳池模型 | 固定池，每個池最大節點數;至少三個節點 | 起始池（二級啟動，無需設定）;針對特定節點大小與自訂函式庫的自訂池;支援單節點執行 |
| 安全性（網路） | 受管理的虛擬網路;私有端點 | 受管理私有端點（MPE）;外部存取政策（OAP）;Customer-Managed 金鑰（CMK） |
| GPU 支援 | 可用的 GPU 加速池 | 不支援 |
| 高並行 | 不支援 | 支援：多本筆記本共用一次 Spark 會話 |
| 程式庫管理 | 池級與工作區級函式庫；手動上傳Wheel檔、JARs、tar.gz | 基於環境的函式庫管理：公開訂閱（PyPI/Conda）+ 自訂上傳（輪式、JAR）。 要複製 Synapse 工作空間層級函式庫，請建立一個包含所需函式庫的環境，並將其設為工作區預設值。 工作空間中的所有筆記本和 SJD 都會自動繼承此設定。 |
| V級 | 無法提供 | 在寫入過程中進行 Parquet 優化; Power BI Direct Lake 提升 40–60%; SQL 分析端點提升 ~10%; Spark 讀取並無效益; 15–33% 寫入開銷 |
| 優化寫入 | 預設為停用 | 預設啟用 |
| 預設表格格式 | 拼花地板（Delta 選配） | Delta Lake（預設且為 Lakehouse 表格必備） |
| Hive Metastore | 內建HMS;外部 HMS 透過 Azure SQL DB 或 MySQL（Spark 3.4 後已棄用） | Fabric Lakehouse 目錄;透過匯出/匯入腳本進行 HMS 遷移 |
| 筆記本中的DMTS | 支持 | 以筆記本形式支援;Spark 工作定義尚未支援 |
| KV 的管理身份 | 支持 | 支援於筆記本與 Spark 工作定義中 |
| mssparkutils | 完整資料庫（FS、憑證、筆記本、環境、湖畔別墅） | notebookutils（類似 API;方法名稱有些差異） |