本文是 Azure Synapse Spark 轉至 Microsoft Fabric 遷移最佳實務系列的第四階段（共四階段）。
在遷移的最後階段使用這篇文章來驗證工作負載、協調安全與治理控管，並規劃生產切換。 本文提供安全映射的指引，以及以檢查清單為驅動的驗證、優化與切換準備方法。
在本文中，您將學會如何：
- 將 Synapse RBAC 與網路模式映射至 Fabric 工作區、OneLake 及受管網路控制。
- 透過使用 OneLake Catalog 與 Microsoft Purview 資訊保護 重新建立治理與保護工作流程。
- 利用分階段遷移檢查清單來驗證、優化並執行切換。
- 計劃在成功切換後停用舊有的 Synapse Spark 資源。
存取控制
Synapse RBAC 角色（Synapse 管理員、Synapse SQL 管理員、Synapse Spark 管理員等）會對應到 Fabric 工作空間的角色（管理員、成員、貢獻者、檢視者）。 Fabric 的模型較為簡單，包含四個角色。
Synapse 連結服務被 Fabric Connections 取代。 透過工作區設定>建立連線管理連線與閘道器。 對於筆記本程式碼，請以基於 金鑰保存庫 的認證或直接端點設定取代連結的服務參考。
OneLake RBAC 在湖屋內的資料夾與表格層級提供細緻的資料存取控制。
網路安全性
Synapse 管理的 VNet 和私有端點會映射到 Fabric 管理的 VNet + 受管的私有端點。 請注意，Fabric Spark 需要自訂池（而非起始池）來支援受管私有端點。
Synapse 中的自架整合執行時（SHIR）在 Fabric 中被本地資料閘道（OPDG）取代。 VNet IR 會被 VNet 資料閘道器取代。
治理
使用 OneLake 目錄來發現並管理遷移的 Fabric 項目，並檢視其血統。 使用 Microsoft Purview 資訊保護 對支援的 Fabric 項目套用敏感標籤與保護政策。
移轉檢查清單
請使用這份清單追蹤您的 Spark 遷移進度。 每個階段都在前一個階段的基礎上建立。 在進入下一階段前，先完成一個階段內的所有物品。
第一階段：評估與規劃
關於規劃指引、遷移模式及功能比較，請參閱 第一階段：遷移策略與規劃。
- 1.1 完整的 Spark 資產清單：Spark 池、筆記本、Spark 工作定義、湖泊資料庫、Hive Metastore （HMS） 資料庫，以及筆記本中使用的連結服務。
- 1.2 檢視Synapse與Fabric的功能差異。 阻礙因素：GPU 工作負載、不支援的目錄 API、連結服務相依性。
-
1.3 執行預重構審核：搜尋所有筆記本中的 Synapse 專屬模式
spark.synapse.linkedServicegetSecretWithLSTokenLibrarysynapsesql。 計算受影響的筆記本。 -
1.4 檢查函式庫相容性：在 Synapse 池上執行
pip freeze，並與 Runtime 1.3 內建函式庫Fabric比較。 列出需要預先安裝的函式庫。 - 1.5 建立 Fabric 工作區、配置容量並創建目標 Lakehouse 項目。
- 1.6 從 Synapse Studio 匯出 Spark 池設定、自訂函式庫及 Spark 屬性。
第二階段：建立連線與憑證
有關連結服務替換與認證的指引，請參見 第二階段：Spark 工作負載遷移 及 第四階段：安全與治理遷移。
- 2.1 盤點所有 Synapse 連結的服務，包括筆記本、Spark 工作定義及 Lakehouse 資料存取。
- 2.2 透過 Workspace 設定 及 >，建立與外部資料來源（ADLS Gen2、Cosmos DB、Azure SQL 等）的 Fabric 連線。
- 2.3 為需要基於金鑰授權的數據源（Cosmos DB 金鑰、儲存帳戶金鑰、Kusto 代幣）設置包含秘密的 Azure Key Vault。 為你的 Fabric 工作區身份設定存取政策。
- 2.4 配置 ADLS Gen2 OAuth 存取的服務主體憑證：在 Entra ID 註冊應用，授予 Storage Blob Data 貢獻者角色，記錄下客戶端 ID、秘密和租戶。
- 2.5 確認連線：在繼續前，先測試金鑰保存庫從 Fabric 筆記本秘密檢索與儲存帳號的權限。
第三階段：資料遷移與蜂巢元儲存庫
關於湖泊元資料與資料存取遷移的指引，請參見 第三階段：蜂巢元儲存庫與資料遷移 ，以及 資料與管線遷移。
- 3.1 建立 OneLake 捷徑至現有 ADLS Gen2 路徑（零拷貝，首選方法）。 使用在第二階段設定的 Fabric 連線進行透過資料閘道的存取。
- 3.2 對於非 Delta 檔案（CSV、JSON、Parquet），請在檔案區段建立捷徑。 若需要資料複製，請使用 AzCopy 或資料工廠複製活動。
- 3.3 遷移 Hive Metastore 物件。 選擇一種方法：選項A：為所有元資料執行 HMS 匯出/匯入筆記本。 選項 B：對 Delta Lake 資料庫資料表使用 移轉小幫手；對非 Delta 資料表則僅使用 HMS 匯出/匯入。
- 3.4 驗證 Lakehouse Explorer 中的 Delta 表格自動註冊。
- 3.5 確認所有匯入的資料表和捷徑在 Lakehouse Explorer 中可見，且可從筆記本存取。
第四階段：遷移 Spark 工作負載
關於項目遷移、程式碼重構及環境設定指引，請參見 第二階段：Spark 工作負載遷移。
- 4.1 運行 Spark 移轉小幫手，用於筆記本、Spark 工作定義、Spark 池及湖泊資料庫。 請檢視遷移報告中的錯誤與警告。
- 4.2 建立具有目標 Spark 執行時間、池設定及自訂函式庫的 Fabric 環境。 第一階段發現的預安裝函式庫缺失。
-
4.3 重構筆記本與 SJD 程式碼：將
mssparkutils替換為notebookutils，更新檔案路徑為 OneLakeabfss://，將連結的服務參考換成 金鑰保存庫 或 Fabric 連接，並以 Spark SQL 等效方法取代不支援的spark.catalog方法。 -
4.4 重構連接器：Kusto/ADX — 將連結服務替換為
accessTokenviagetToken()。 Cosmos DB — 替換getSecretWithLS為getSecret(akvName, secret)。 -
4.5 使用標準 OAuth
LinkedServiceBasedTokenProvider透過TokenLibrary取代 Synapse 令牌提供者 (ClientCredsTokenProvider,spark.conf.set())。 - 4.6 測試重構筆記本與 SJD，對資料進行端對端重構（階段 3）與連線（階段 2）。
第五階段：安全、治理與網路
關於安全、治理及網路映射的指引，請參見 第四階段：安全與治理遷移。
- 5.1 將 Synapse RBAC 角色映射為Fabric工作區角色（管理員、成員、貢獻者、檢視者）。
- 5.2 配置 OneLake RBAC，以在資料夾與資料表層級進行細緻的資料存取控制。
- 5.3 配置受管型 VNet 與受管理私人端點，用於存取私有資料來源的 Spark 工作負載（需要自訂池）。
- 5.4 將 SHIR 替換為本地資料閘道（On-pre-premises Data Gateway，OPDG），並將 VNet IR 替換為 VNet 資料閘道。
- 5.5 確認遷移後的商品是否出現在 OneLake 目錄中，並檢視其血統。
- 5.6 必要時檢視並套用敏感性標籤於遷移的 Lakehouse 項目。
第六階段：優化與驗證
關於遷移後驗證與生產準備度的指引，請參見 第四階段：安全與治理遷移。
- 6.1 啟用原生執行引擎（NEE），以提升 Parquet 與 Delta 工作負載上的 Spark 效能。
-
6.2 在 Power BI Direct Lake 或 SQL 分析端點所消耗的資料表上執行
OPTIMIZE VORDER。 - 6.3 執行平行工作負載，並比較 Synapse 與 Fabric 之間的 Spark 工作結果與效能。
- 6.4 將下游消費者（包括Power BI報告、API 及應用程式）重新導向Fabric端點。
- 6.5 使用 Monitoring Hub 與 Diagnostic Emitter，監控 Fabric 工作負載至少一至兩週。
第七階段：切換
關於最終驗證、下游重新路由及轉換指引，請參見 第四階段：安全與治理遷移。
- 7.1 確認所有遷移的筆記本、SJD 和 Spark 工作在 Fabric 中都能順利執行。
- 7.2 透過列數、結構驗證及查詢結果比較來驗證資料完整性。
- 7.3 向利害關係人傳達切換情況並更新文件。
- 7.4 停用 Synapse Spark 池、筆記本及相關資源。
Note
遷移後，考慮為遷移後的筆記本和 Spark 工作定義設定 Fabric Git 整合。 Fabric 支援 Azure DevOps Git 整合，用於原始碼控制、分支及部署管線。 與使用 ARM 模板的 Synapse 不同，Fabric 採用基於工作空間的模型，將工作區連接到 Git 分支並直接同步項目。 筆記本、環境和 SJD 都支援 Git 整合。 建立部署流程（開發→測試→生產）來管理跨環境的推廣。