移轉規劃：將 Azure Synapse Analytics 專用 SQL 集區移轉至 Fabric Data Warehouse

適用於：Microsoft Fabric 中的✅ 資料庫

本文說明從 Azure Synapse Analytics 專用 SQL 集區遷移至 Microsoft Fabric Data Warehouse 的策略、考量事項和方法。

移轉簡介

Microsoft Fabric 是一款為企業打造的一體化 SaaS 分析解決方案。 它提供全面的服務組合，包括資料工廠、資料工程、資料倉儲、資料科學、 Real-Time 智慧及Power BI。

本文說明了結構（DDL）、資料庫程式碼（DML）及資料遷移的選項，並協助你選擇適合情境的選項。 它使用 TPC-DS 業界基準來進行示範與性能測試。 結果可能會因資料類型、資料表寬度和來源延遲等因素而有所不同。

為移轉做準備

在開始前，請仔細規劃你的遷移專案，並確保你的架構、程式碼和資料與 Fabric Data Warehouse 相容。 請考慮其 限制。 量化重構不相容項目所需的工作量，以及完成遷移所需的其他資源。

規劃的另一個關鍵目標是調整設計，使解決方案充分發揮Fabric Data Warehouse查詢效能。 根據規模設計資料倉儲引進了獨特的設計模式，因此傳統方法並不一定是最佳方法。 請檢視 績效指引。 雖然遷移後可以做一些設計調整，但提早修改能節省時間和精力。 從一種技術或環境遷移到另一種技術總是一項重大工程。

下圖顯示遷移生命週期及其五大支柱相關的任務： 評估與評估、 規劃與設計、 遷移、 監控與治理，以及 優化與現代化。

遷移指南

請將以下活動視為從 Synapse 專用 SQL 池遷移到 Fabric Data Warehouse 的規劃手冊。

1. 評定和評估
   1. 識別目標和動機。 建立明確的所需結果。
   2. 發掘、評估並建立現有架構的基線。
   3. 識別主要利害關係人和贊助者。
   4. 定義要遷移的範圍。
      1. 從小而簡單的開始，並準備多次小型遷移。
      2. 開始監視及記錄程序的所有階段。
      3. 建立遷移所需的資料與流程清單。
      4. 定義資料模型變更（如有）。
      5. 設置 Fabric 工作區。
   5. 評估團隊的技能組合與偏好。
      1. 盡可能自動化。
      2. 使用 Azure 內建工具和功能來減少移轉工作。
   6. 盡早在新平台上培訓員工。
      1. 識別提升技能需求和訓練資產，包括 Microsoft Learn。
2. 規劃和設計
   1. 定義所需結構。
   2. 選擇 遷移的方法與工具 以完成以下任務：
      1. 從來源進行資料擷取。
      2. 結構（DDL）轉換，包括資料表與檢視的元資料。
      3. 數據引入，包括歷史數據。
         1. 如有需要，透過使用新的平台效能與可擴展性來重新設計資料模型。
      4. 資料庫程式碼 (DML) 移轉。
         1. 遷移或重構預存程序和業務流程。
   3. 清查並擷取來源系統的安全特性和物件權限。
   4. 設計並規劃替換或修改現有ETL/ELT流程以應付增量負載。
      1. 為新環境建立平行 ETL/ELT 程序。
   5. 準備詳細的移轉方案。
      1. 將當前狀態映射到目標狀態。
3. 遷移
   1. 執行結構、資料和程式碼遷移。
      1. 從來源進行資料擷取。
      2. 結構描述（DDL）轉換。
      3. 資料提取
      4. 資料庫程式碼 (DML) 移轉。
   2. 如有必要，請暫時相應擴展專用 SQL 集區資源，以提高移轉速度。
   3. 套用安全性和權限。
   4. 移轉現有的 ETL/ELT 過程以進行增量載入。
      1. 遷移或重構 ETL/ELT 增量負載流程。
      2. 測試並比較平行增量負載流程。
   5. 視需要調整詳細的遷移計畫。
4. 監視及管理
   1. 並行執行，並與你的原始環境做比較。
      1. 測試應用程式、商業智慧平台和查詢工具。
      2. 執行基準測試並優化查詢性能。
      3. 監視及管理成本、安全性和效能。
   2. 進行治理基準與評估。
5. 最佳化和現代化
   1. 當業務狀況良好時，將應用程式和主要報告平台轉換為 Fabric。
      1. 當工作負載從 Azure Synapse Analytics 轉移到 Microsoft Fabric 時，可擴增或縮減資源。
      2. 根據獲得的經驗，為將來的移轉建置可重複的範本。 重複。
      3. 識別成本優化、安全性、可擴展性及營運卓越的機會。
      4. 識別使用最新的 Fabric 功能將您的資料資產現代化的機會。

要直接移轉，還是進行現代化改造？

一般而言，不論計劃的移轉目的和範圍為何，移轉案例都有兩種類型：按現況隨即轉移及包含結構和程式碼變更的階段式方法。

遷移重置

在原樣移轉中，你會將現有資料模型稍作變更後，移轉到新的 Fabric Data Warehouse。 此方法只需少量的新工作就能實現移轉的優點，進而將風險和移轉時間降到最低。

提升和轉移遷移適合下列情境：

• 你有一個現有的系統環境，其中有一些數量不多的倉庫需要遷移。
• 您所使用的現有環境中的資料已經是設計良好的星型或雪花型架構。
• 你正面臨時間和成本壓力，必須轉向 Fabric Data Warehouse。

總結來說，這種方法對於針對您目前 Azure Synapse 專用 SQL 池環境優化的工作負載，且不需要在 Fabric 上做重大修改，效果良好。

藉助結構變更，以階段式方法進行現代化

如果舊有的資料倉儲是經過長時間演進的，你可能需要重新設計它以維持所需的效能水準。

你也可以重新設計架構，以利用 Fabric 工作區中可用的新引擎與功能。

設計差異：Synapse 專用 SQL 池與 Fabric 資料倉儲

請參考以下 Azure Synapse 與 Microsoft Fabric 資料倉儲的差異，將專用 SQL 池與 Fabric 資料倉儲做比較。

資料表設計考量

當您在不同環境之間遷移資料表時，通常只有原始數據和中繼資料會實際遷移。 通常你不會從來源系統遷移其他資料庫元素，例如索引，因為它們在新環境中可能不必要或實作方式不同。

來源環境中的效能優化，例如索引，會指示你在新環境中可能需要優化的地方。 Fabric 會自動管理這些優化。

T-SQL 注意事項

資料操作語言（DML）語法有幾項差異需要考慮。 檢閱 Fabric Data Warehouse 中的 T-SQL 支援範圍，並在選擇資料庫程式碼移轉方法時進行程式碼評估。

根據移轉時的同位差異，您可能需要重寫部分 T-SQL DML 程式碼。

資料類型映射差異

Fabric Data Warehouse 與Azure Synapse Analytics專用 SQL 池有幾項資料型別差異。 如需詳細資訊，請參閱 Microsoft Fabric 中的資料類型。

下表顯示從 Azure Synapse 專用 SQL 集區對應至 Fabric Data Warehouse 的支援資料類型。

* Datetime2 不會儲存 Datetimeoffset 儲存的額外時區偏移資訊。 由於 Fabric Data Warehouse 目前不支援 datetimeoffset 資料型別，你需要將時區偏移資料擷取到獨立欄位。

相關內容

• 在 Microsoft Fabric 中建立倉儲
• Fabric 資料倉儲效能指導方針
• Fabric Data Warehouse 中的安全性
• 部落格：將 Azure Synapse 專用 SQL 集區對應至 Fabric Data Warehouse 運算
• Microsoft Fabric 遷移概述