針對複製活動效能進行疑難排解

適用于： Azure Data Factory Azure Synapse Analytics

提示

試用 Microsoft Fabric 中的 Data Factory，這是適用于企業的單一分析解決方案。 Microsoft Fabric 涵蓋從資料移動到資料科學、即時分析、商業智慧和報告等所有專案。 瞭解如何 免費啟動新的試用版 ！

本文概述如何在 Azure Data Factory 中針對複製活動效能問題進行疑難排解。

執行複製活動之後，您可以在複製活動監視 檢視中 收集執行結果和效能統計資料。 以下是一個範例。

效能微調秘訣

在某些情況下，當您執行複製活動時，您會在頂端看到 「效能微調秘訣」 ，如上述範例所示。 秘訣會告訴您服務針對此特定複製執行所識別的瓶頸，以及如何提升複製輸送量的建議。 請嘗試進行建議的變更，然後再次執行複本。

作為參考，目前效能微調秘訣會提供下列案例的建議：

類別	效能微調秘訣
資料存放區特定	將資料載入 Azure Synapse Analytics ：如果未使用 PolyBase 或 COPY 語句，建議使用 PolyBase 或 COPY 語句。
	從 Azure 複製資料SQL 資料庫 ：當 DTU 使用率過高時，建議升級至較高層。
	從 Azure Cosmos DB 複製資料：當 RU 使用率過高時，建議升級至較大的 RU。
	從 SAP 資料表 複製資料：複製 大量資料時，建議利用 SAP 連接器的資料分割選項來啟用平行載入，並增加最大分割區數目。
	從 Amazon Redshift 擷取資料：如果未使用 UNLOAD，建議使用 UNLOAD。
資料存放區節流	如果在複製期間，資料存放區會節流許多讀取/寫入作業，建議檢查並增加資料存放區允許的要求率，或減少並行工作負載。
整合執行階段	如果您使用 自我裝載整合執行時間 （IR） ，複製活動會在佇列中等候很長的時間，直到 IR 有可用的資源可供執行，建議相應放大/增加 IR。
	如果您使用 位於非最佳區域的 Azure Integration Runtime 導致讀取/寫入速度緩慢，建議設定在另一個區域中使用 IR。
容錯	如果您設定容錯並略過不相容的資料列會導致效能變慢，建議確保來源和接收資料相容。
分段複製	如果已設定暫存複本，但對來源接收組沒有説明，建議您將其移除。
繼續	當複製活動從上次失敗點繼續執行，但您碰巧在原始執行之後變更 DIU 設定時，請注意新的 DIU 設定不會生效。

瞭解複製活動執行詳細資料

複製活動監視檢視底部的執行詳細資料和持續時間描述複製活動所經歷的關鍵階段（請參閱本文開頭的範例），這對針對複製效能進行疑難排解特別有用。 複製執行的瓶頸是持續時間最長的。 請參閱每個階段定義的下表，並瞭解如何使用這類資訊針對 Azure IR 上的複製活動進行疑難排解，以及 針對自我裝載 IR 上的複製活動進行疑難排解。

階段	描述
待辦事項	複製活動實際在整合執行時間上啟動的經過時間。
複製前指令碼	從 IR 開始的複製活動與完成在接收資料存放區中執行預先複製腳本的複製活動之間經過的時間。 當您設定資料庫接收的預先複製腳本時套用，例如將資料寫入 Azure SQL 資料庫在複製新資料之前先清除。
傳輸	上一個步驟結尾與 IR 之間經過的時間，會將所有資料從來源傳輸至接收。 請注意，傳輸執行下的子步驟會以平行方式執行，而且現在不會顯示某些作業，例如剖析/產生檔案格式。 - 第一個位元組的時間： 前一個步驟結尾與 IR 從來源資料存放區接收第一個位元組的時間之間經過的時間。 適用于非檔案型來源。 - 列出來源： 列舉來源檔案或資料分割所花費的時間量。 當您設定資料庫來源的資料分割選項時，例如從 Oracle/SAP HANA/Teradata/Netezza/etc 等資料庫複製資料時，會套用後者。 -從來源讀取： 從來源資料存放區擷取資料所花費的時間量。 - 寫入至接收： 將資料寫入接收資料存放區所花費的時間量。 請注意，某些連接器目前沒有此計量，包括 Azure AI 搜尋、Azure 資料總管、Azure 資料表儲存體、Oracle、SQL Server、Common Data Service、Dynamics 365、Dynamics CRM、Salesforce/Salesforce Service Cloud。

針對 Azure IR 上的複製活動進行疑難排解

請遵循效能微調步驟 來規劃和執行案例的效能測試。

當複製活動效能不符合您的預期時，若要針對在 Azure Integration Runtime 上執行的單一複製活動進行疑難排解，如果您看到 複製監視檢視中顯示的效能微調秘訣 ，請套用建議，然後再試一次。 否則， 請瞭解複製活動執行詳細資料 、檢查哪個階段持續時間 最長 ，並套用下列指引來提升複製效能：

• 「預先複製腳本」經歷了很長的持續時間： 這表示在接收資料庫上執行的預先複製腳本需要很長的時間才能完成。 調整指定的預先複製腳本邏輯，以增強效能。 如果您需要進一步改善腳本的說明，請連絡您的資料庫小組。

• 「傳輸 - 第一個位元組的時間」經歷長時間的工作持續時間 ：這表示您的來源查詢需要很長的時間才能傳回任何資料。 檢查並優化查詢或伺服器。 如果您需要進一步的協助，請連絡您的資料存放區小組。

• 「傳輸 - 列出來源」經歷長時間的工作期間 ：這表示列舉源檔案或源資料庫資料分割的速度很慢。

  • 從檔案型來源複製資料時，如果您在資料夾路徑或檔案名 （ wildcardFolderPath 或） 上使用 萬用字元篩選 ，或是使用 檔案上次修改時間篩選 （ modifiedDatetimeStart 或 modifiedDatetimeEnd ），請注意，這類篩選 會導致複製活動，將指定資料夾下的所有檔案清單複製到用戶端，然後 wildcardFileName 套用篩選。 這類檔案列舉可能會成為瓶頸，尤其是在只有一組檔案符合篩選規則時。

    • 檢查您是否可以根據 datetime 分割的檔案路徑或名稱 來複製檔案。 這樣不會給清單來源端帶來負擔。

    • 檢查您是否可以改用資料存放區的原生篩選，特別是 ADLS Gen1 的 Amazon S3/Azure Blob 儲存體/Azure 檔案儲存體和 「 listAfter/listBefore 」。 這些篩選準則是資料存放區伺服器端篩選，而且效能會更好。

    • 請考慮將單一大型資料集分割成數個較小的資料集，並讓這些複製作業同時執行每個處理部分的資料。 您可以使用 Lookup/GetMetadata + ForEach + Copy 來執行此動作。 請參閱從多個容器 複製檔案，或 將資料從 Amazon S3 遷移至 ADLS Gen2 解決方案範本作為一般範例。

  • 檢查服務是否報告來源的任何節流錯誤，或您的資料存放區是否處於高使用率狀態。 如果是，請減少資料存放區上的工作負載，或嘗試連絡資料存放區系統管理員，以提高節流限制或可用的資源。

  • 在相同或接近您的來源資料存放區區域中使用 Azure IR。

• 「傳輸 - 從來源讀取」 經歷了長時間的工作期間 ：

  • 如果適用，請採用連接器特定的資料載入最佳做法。 例如，從 Amazon Redshift 複製資料時，請將 設定為使用 Redshift UNLOAD。

  • 檢查服務是否報告來源的任何節流錯誤，或您的資料存放區是否使用率過高。 如果是，請減少資料存放區上的工作負載，或嘗試連絡資料存放區系統管理員，以提高節流限制或可用的資源。

  • 檢查您的複製來源和接收模式：

    • 如果您的複製模式支援大於 4 個資料整合單位 （DIU） - 請參閱 本節 的詳細資料，通常您可以嘗試增加 DIU 以取得更好的效能。

    • 否則，請考慮將單一大型資料集分割成數個較小的資料集，並讓這些複製作業同時執行每個處理部分的資料。 您可以使用 Lookup/GetMetadata + ForEach + Copy 來執行此動作。 請參閱從多個容器 複製檔案、 將資料從 Amazon S3 遷移至 ADLS Gen2 ，或使用 控制項資料表 解決方案範本大量複製作為一般範例。

  • 在相同或接近您的來源資料存放區區域中使用 Azure IR。

• 「傳輸 - 寫入接收」經歷長時間的工作：

  • 如果適用，請採用連接器特定的資料載入最佳做法。 例如，將資料複製到 Azure Synapse Analytics 時，請使用 PolyBase 或 COPY 語句。

  • 檢查服務是否報告接收的任何節流錯誤，或您的資料存放區是否使用率過高。 如果是，請減少資料存放區上的工作負載，或嘗試連絡資料存放區系統管理員，以提高節流限制或可用的資源。

  • 檢查您的複製來源和接收模式：

    • 如果您的複製模式支援大於 4 個資料整合單位 （DIU） - 請參閱 本節 的詳細資料，通常您可以嘗試增加 DIU 以取得更好的效能。

    • 否則，請逐漸調整 平行複本，請注意，太多平行複本 甚至可能會損害效能。

  • 在相同或接近接收資料存放區區域中使用 Azure IR。

針對自我裝載 IR 上的複製活動進行疑難排解

請遵循效能微調步驟 來規劃和執行案例的效能測試。

當複製效能不符合您的預期時，若要針對在 Azure Integration Runtime 上執行的單一複製活動進行疑難排解，如果您看到 複製監視檢視中顯示的效能微調秘訣 ，請套用建議，然後再試一次。 否則， 請瞭解複製活動執行詳細資料 、檢查哪個階段持續時間 最長 ，並套用下列指引來提升複製效能：

• 「佇列」持續時間很長： 這表示複製活動會在佇列中等候很長的時間，直到您自我裝載 IR 有資源可執行為止。 檢查 IR 容量和使用量，並根據 您的工作負載相應增加或相應放大 。

• 「傳輸 - 第一個位元組的時間」經歷長時間的工作持續時間 ：這表示您的來源查詢需要很長的時間才能傳回任何資料。 檢查並優化查詢或伺服器。 如果您需要進一步的協助，請連絡您的資料存放區小組。

• 「傳輸 - 列出來源」經歷長時間的工作期間 ：這表示列舉源檔案或源資料庫資料分割的速度很慢。

  • 檢查自我裝載 IR 電腦是否有低延遲連線到來源資料存放區。 如果您的來源位於 Azure 中，您可以使用 此工具 來檢查從自我裝載 IR 機器到 Azure 區域的延遲，越好越好。

  • 從檔案型來源複製資料時，如果您在資料夾路徑或檔案名 （ wildcardFolderPath 或） 上使用 萬用字元篩選 ，或是使用 檔案上次修改時間篩選 （ modifiedDatetimeStart 或 modifiedDatetimeEnd ），請注意，這類篩選 會導致複製活動，將指定資料夾下的所有檔案清單複製到用戶端，然後 wildcardFileName 套用篩選。 這類檔案列舉可能會成為瓶頸，尤其是在只有一組檔案符合篩選規則時。

    • 檢查您是否可以根據 datetime 分割的檔案路徑或名稱 來複製檔案。 這樣不會給清單來源端帶來負擔。

    • 檢查您是否可以改用資料存放區的原生篩選，特別是 ADLS Gen1 的 Amazon S3/Azure Blob 儲存體/Azure 檔案儲存體和 「 listAfter/listBefore 」。 這些篩選準則是資料存放區伺服器端篩選，而且效能會更好。

    • 請考慮將單一大型資料集分割成數個較小的資料集，並讓這些複製作業同時執行每個處理部分的資料。 您可以使用 Lookup/GetMetadata + ForEach + Copy 來執行此動作。 請參閱從多個容器 複製檔案，或 將資料從 Amazon S3 遷移至 ADLS Gen2 解決方案範本作為一般範例。

  • 檢查服務是否報告來源的任何節流錯誤，或您的資料存放區是否處於高使用率狀態。 如果是，請減少資料存放區上的工作負載，或嘗試連絡資料存放區系統管理員，以提高節流限制或可用的資源。

• 「傳輸 - 從來源讀取」 經歷了長時間的工作期間 ：

  • 檢查自我裝載 IR 電腦是否有低延遲連線到來源資料存放區。 如果您的來源位於 Azure 中，您可以使用 此工具 來檢查從自我裝載 IR 機器到 Azure 區域的延遲，越好越好。

  • 檢查自我裝載 IR 電腦是否有足夠的輸入頻寬，以便有效率地讀取和傳輸資料。 如果您的來源資料存放區位於 Azure 中，您可以使用 此工具 來檢查下載速度。

  • 在 Azure 入口網站 - > 您的資料處理站或 Synapse 工作區 - > 概觀頁面中，檢查自我裝載 IR 的 CPU 和記憶體使用量趨勢。 如果 CPU 使用量很高或可用記憶體不足，請考慮相應增加/放大 IR 。

  • 如果適用，請採用連接器特定的資料載入最佳做法。 例如：

    • 從 Oracle 、Netezza 、 Teradata 、 SAP HANA 、 SAP 資料表 和 SAP Open Hub 複製資料時，啟用資料分割選項以平行方式複製資料。

    • 從 HDFS 複製資料時，請將 設定為使用 DistCp。

    • 從 Amazon Redshift 複製資料時，請將 設定為使用 Redshift UNLOAD。

  • 檢查服務是否報告來源的任何節流錯誤，或您的資料存放區是否使用率過高。 如果是，請減少資料存放區上的工作負載，或嘗試連絡資料存放區系統管理員，以提高節流限制或可用的資源。

  • 檢查您的複製來源和接收模式：

    • 如果您從已啟用資料分割選項的資料存放區複製資料，請考慮逐漸調整 平行複製，請注意，太多平行複製 甚至可能會損害效能。

    • 否則，請考慮將單一大型資料集分割成數個較小的資料集，並讓這些複製作業同時執行每個處理部分的資料。 您可以使用 Lookup/GetMetadata + ForEach + Copy 來執行此動作。 請參閱從多個容器 複製檔案、 將資料從 Amazon S3 遷移至 ADLS Gen2 ，或使用 控制項資料表 解決方案範本大量複製作為一般範例。

• 「傳輸 - 寫入接收」經歷長時間的工作：

  • 如果適用，請採用連接器特定的資料載入最佳做法。 例如，將資料複製到 Azure Synapse Analytics 時，請使用 PolyBase 或 COPY 語句。

  • 檢查自我裝載 IR 電腦是否有低延遲連線到接收資料存放區。 如果您的接收位於 Azure 中，您可以使用 此工具 來檢查從自我裝載 IR 機器到 Azure 區域的延遲，越少越好。

  • 檢查自我裝載 IR 機器是否有足夠的輸出頻寬，可有效率地傳輸和寫入資料。 如果您的接收資料存放區位於 Azure 中，您可以使用 此工具 來檢查上傳速度。

  • 檢查 Azure 入口網站 中自我裝載 IR 的 CPU 和記憶體使用量趨勢 - > 您的資料處理站或 Synapse 工作區 - > 概觀頁面。 如果 CPU 使用量很高或可用記憶體不足，請考慮相應增加/放大 IR 。

  • 檢查服務是否報告接收的任何節流錯誤，或您的資料存放區是否使用率過高。 如果是，請減少資料存放區上的工作負載，或嘗試連絡資料存放區系統管理員，以提高節流限制或可用的資源。

  • 請考慮逐漸調整 平行複本，請注意，太多平行複製 甚至可能會損害效能。

連線or 和 IR 效能

本節探討特定連接器類型或整合執行時間的一些效能疑難排解指南。

活動執行時間會因 Azure IR 與 Azure VNet IR 而有所不同

當資料集以不同的 Integration Runtime 為基礎時，活動執行時間會有所不同。

• 徵兆 ：只要切換資料集中的 [連結服務] 下拉式清單，就會執行相同的管線活動，但執行時間卻大不相同。 當資料集以 Managed 虛擬網絡 Integration Runtime 為基礎時，平均比根據預設整合執行時間執行的執行時間還要多。

• 原因 ：檢查管線執行的詳細資料，您可以看到在受控 VNet （虛擬網絡） IR 上執行緩慢的管線，而正常管線是在 Azure IR 上執行。 根據設計，受控 VNet IR 需要比 Azure IR 更長的佇列時間，因為我們不會針對每個服務實例保留一個計算節點，因此每個複製活動都有啟動的熱身，而且主要發生在 VNet 聯結上，而不是 Azure IR。

將資料載入 Azure SQL 資料庫 時效能低

• 徵兆 ：將資料複製到 Azure SQL 資料庫變慢。

• 原因 ：問題的根本原因大多是由 Azure SQL 資料庫端的瓶頸所觸發。 以下是一些可能的原因：

  • Azure SQL 資料庫層不夠高。

  • Azure SQL 資料庫 DTU 使用量接近 100%。 您可以 監視效能 ，並考慮升級 Azure SQL 資料庫 層。

  • 索引未正確設定。 在資料載入之前移除所有索引，並在載入完成之後重新建立它們。

  • WriteBatchSize 不夠大，無法容納架構資料列大小。 請嘗試放大問題的 屬性。

  • 使用預存程式，而不是大量插入，這預期效能會更差。

剖析大型 Excel 檔案時的逾時或效能變慢

• 徵兆：

  • 當您建立 Excel 資料集並從連線/存放區、預覽資料、清單或重新整理工作表匯入架構時，如果 Excel 檔案大小很大，您可能會遇到逾時錯誤。

  • 當您使用複製活動將資料從大型 Excel 檔案 （ > = 100 MB） 複製到其他資料存放區時，可能會遇到效能緩慢或 OOM 問題。

• 原因：

  • 對於匯入架構、預覽資料和在 Excel 資料集上列出工作表等作業，逾時為 100 秒和靜態。 對於大型 Excel 檔案，這些作業可能無法在逾時值內完成。

  • 複製活動會將整個 Excel 檔案讀取到記憶體中，然後找出要讀取資料的指定工作表和儲存格。 此行為是因為服務所使用的基礎 SDK 所造成。

• 解決方法：

  • 若要匯入架構，您可以產生較小的範例檔案，這是原始檔案的子集，並選擇 [從範例檔案匯入架構]，而不是從連線/存放區匯入架構。

  • 對於列出工作表，您可以在工作表下拉式清單中按一下 [編輯]，並改為輸入工作表名稱/索引。

  • 若要將大型 Excel 檔案 （ > 100 MB） 複製到其他存放區，您可以使用資料流程 Excel 來源，讓資料流程讀取和執行效能更好。

讀取大型 JSON/Excel/XML 檔案的 OOM 問題

• 徵兆 ：當您讀取大型 JSON/Excel/XML 檔案時，您會在活動執行期間遇到記憶體不足 （OOM） 問題。

• 原因：

  • 對於大型 XML 檔案 ：讀取大型 XML 檔案的 OOM 問題是設計。 原因是整個 XML 檔案必須讀入記憶體，因為它是單一物件，然後推斷架構，並擷取資料。
  • 對於大型 Excel 檔案 ：讀取大型 Excel 檔案的 OOM 問題是設計方式。 原因是所使用的 SDK （POI/NPOI） 必須將整個 Excel 檔案讀入記憶體，然後推斷架構並取得資料。
  • 對於大型 JSON 檔案 ：當 JSON 檔案是單一物件時，讀取大型 JSON 檔案的 OOM 問題是設計。

• 建議 ：套用下列其中一個選項來解決您的問題。

  • 選項 1 ：使用功能強大的電腦（高 CPU/記憶體）註冊線上自我裝載整合執行時間，以透過複製活動從大型檔案讀取資料。
  • 選項 2 ：使用優化記憶體和大型叢集（例如 48 個核心），透過對應資料流程活動從大型檔案讀取資料。
  • 選項 3 ：將大型檔案分割成小型檔案，然後使用複製或對應資料流程活動來讀取資料夾。
  • 選項 4 ：如果您在複製 XML/Excel/JSON 資料夾期間遇到 OOM 問題，請使用管線中的 foreach 活動 + 複製/對應資料流程活動來處理每個檔案或子資料夾。
  • 選項 5 ：其他：
    • 針對 XML，如果每個檔案具有相同的架構，請使用 Notebook 活動搭配記憶體優化叢集，從檔案讀取資料。 目前，Spark 有不同的實作來處理 XML。
    • 針對 JSON，請在對應資料流程來源的 JSON 設定 中使用不同的檔表單（例如 ，單一檔 、 每行 檔及 檔 陣列）。 如果 JSON 檔案內容是 每一行 的檔，則會耗用很少的記憶體。

其他參考

以下是一些支援之資料存放區的效能監視和微調參考：

• Azure Blob 儲存體： Blob 儲存體 的延展性和效能目標，以及 Blob 儲存體 的效能和延展性檢查清單。
• Azure 資料表儲存體： 資料表儲存體 的延展性和效能目標，以及 資料表儲存體 的效能和延展性檢查清單。
• Azure SQL 資料庫：您可以 監視效能 ，並檢查資料庫交易單位 （DTU） 百分比。
• Azure Synapse Analytics：其功能是以資料倉儲單位 （DWU） 來測量。 請參閱 在 Azure Synapse Analytics 中管理計算能力 （概觀） 。
• Azure Cosmos DB： Azure Cosmos DB 中的效能層級。
• SQL Server： 監視和微調效能 。
• 內部部署檔案伺服器： 檔案伺服器的 效能微調。

相關內容

請參閱其他複製活動文章：

• 複製活動概觀
• 複製活動效能和延展性指南
• 複製活動效能優化功能
• 將資料從 Data Lake 或資料倉儲遷移至 Azure
• 將資料從 Amazon S3 遷移至Azure 儲存體