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

適用於：Azure Data Factory Azure Synapse Analytics

提示

試用 Microsoft Fabric 中的 Data Factory，這是適用於企業的全方位分析解決方案。 Microsoft Fabric 涵蓋從資料移動到資料科學、即時分析、商業智慧和報告的所有項目。 了解如何免費開始新的試用！

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

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

效能微調秘訣

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

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

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

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

複製活動監視檢視底部的執行詳細資料和持續時間會描述複製活動經歷的主要階段 (請參閱本文開頭的範例)，特別適合用於針對複製效能進行疑難排解。 複製執行的瓶頸是持續時間最長的執行。 請參閱下表以了解每個階段的定義，並藉此資訊了解如何針對 Azure IR 上的複製活動進行疑難排解，以及針對自我裝載 IR 上的複製活動進行疑難排解。

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

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

遵循效能微調步驟，為您的案例規劃和執行效能測試。

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

• 「複製前指令碼」的持續時間很長：這表示在接收資料庫上執行的複製前指令碼需要很長的時間才能完成。 微調指定的複製前指令碼邏輯，以增強效能。 如果您需要進一步改善指令碼的協助，請連絡您的資料庫小組。

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

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

  • 從檔案型來源複製資料時，如果您在資料夾路徑或檔案名稱上使用萬用字元篩選條件 (wildcardFolderPath 或 wildcardFileName)，或使用檔案上次修改的時間篩選條件 (modifiedDatetimeStart 或 modifiedDatetimeEnd)，請注意這類篩選條件會導致複製活動將指定資料夾下的所有檔案列出給用戶端，然後套用篩選條件。 這類檔案列舉可能會成為瓶頸，特別是只有少數檔案符合篩選規則時。

    • 檢查您是否可以根據日期時間分割的檔案路徑或名稱來複製檔案。 如此一來，就不會對列出清單來源端造成負擔。

    • 檢查您是否可以改用資料存放區的原生篩選，特別是 Amazon S3/Azure Blob 儲存體/Azure 檔案儲存體的「前置詞」和 ADLS Gen1 的 「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 或 wildcardFileName)，或使用檔案上次修改的時間篩選條件 (modifiedDatetimeStart 或 modifiedDatetimeEnd)，請注意這類篩選條件會導致複製活動將指定資料夾下的所有檔案列出給用戶端，然後套用篩選條件。 這類檔案列舉可能會成為瓶頸，特別是只有少數檔案符合篩選規則時。

    • 檢查您是否可以根據日期時間分割的檔案路徑或名稱來複製檔案。 如此一來，就不會對列出清單來源端造成負擔。

    • 檢查您是否可以改用資料存放區的原生篩選，特別是 Amazon S3/Azure Blob 儲存體/Azure 檔案儲存體的「前置詞」和 ADLS Gen1 的 「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 入口網站 - > 您的資料處理站或 Synapse 工作區 - > 概觀頁面中檢查自我裝載 IR 的 CPU 和記憶體使用量趨勢。 如果 CPU 使用量偏高或可用記憶體不足，請考慮擴大/擴增 IR。

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

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

連接器和 IR 效能

本節將探討特定連接器類型或整合執行階段的部分效能疑難排解指南。

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

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

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

• 原因：檢查管線執行的詳細資料，您可以看到緩慢管線是在受控 VNet (虛擬網路) IR 上執行，而一般管線是在 Azure IR 上執行。 依設計，受控 VNet IR 的佇列時間會比 Azure IR 更長，因為我們不會為每個服務執行個體保留一個計算節點，因此每個複製活動開始前都會有準備，而且主要發生在 VNet 聯結上而非 Azure IR 上。

將資料載入 Azure SQL Database 時效能不佳

• 徵兆：將資料複製到 Azure SQL Database 時會變慢。

• 原因：問題的根本原因大部分是由 Azure SQL Database 端的瓶頸所觸發。 以下是部分可能原因：

  • Azure SQL Database 層級不夠高。

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

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

  • 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 問題是設計的關係。

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

  • Option-1：使用功能強大的機器 (高 CPU/記憶體) 註冊線上自我裝載整合執行階段，以透過您的複製活動從大型檔案讀取資料。
  • Option-2：使用最佳化的記憶體和大型叢集 (例如 48 個核心)，以透過對應資料流活動從大型檔案讀取資料。
  • Option-3：將大型檔案分割成數個小型檔案，然後使用複製或對應資料流活動來讀取資料夾。
  • Option-4：如果您在複製 XML/Excel/JSON 資料夾期間卡住或遇到 OOM 問題，請使用管線中的 ForEach 活動 + 複製/對應資料流活動來處理每個檔案或子資料夾。
  • Option-5：其他：
    • 對於 XML，如果每個檔案具有相同的結構描述，請使用 Notebook 活動搭配記憶體最佳化叢集，以從檔案讀取資料。 目前，Spark 有不同的實作來處理 XML。
    • 對於 JSON，請在對應資料流來源的 JSON 設定中，使用不同的文件形式 (例如 單一文件、每行文件和文件陣列)。 如果 JSON 檔案內容是每行文件，則會耗用很少的記憶體。

其他參考

以下是幾個支援的資料存放區所適用的效能監視及調整參考：

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

相關內容

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

• 複製活動概觀
• 複製活動效能和可擴縮性指南
• 複製活動效能最佳化功能
• 將資料從您的資料湖或資料倉儲移轉至 Azure
• 將資料從 Amazon S3 遷移到 Azure 儲存體