針對複製活動性能進行排除故障

適用於： Azure Data Factory Azure Synapse Analytics

本文說明如何排解 Azure Data Factory 中複製活動的效能問題。

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

效能微調秘訣

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

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

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

複製活動監視檢視底部的執行詳細資料和持續時間會描述複製活動經歷的主要階段 (請參閱本文開頭的範例)，特別適合用於針對複製效能進行疑難排解。 複製執行中的瓶頸，會是持續時間最長的那一個。 請參考以下表格中各階段的定義，並學習如何利用上述資訊故障排除 Azure IR 及故障排除自架 IR 的複製活動。

疑難排解 Azure IR 中的複製活動

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

當複製活動的表現未達預期時，要排查Azure Integration Runtime上單一複製活動的問題，如果你在複製監控檢視中看到效能調整技巧，就套用建議並重新嘗試。 否則，請了解複製活動執行詳細資料、檢查哪個階段的持續時間 最長，並套用下列指導方針來提升複製效能：

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

• 「Transfer - Time to first byte」的工作時間很長：你的來源查詢會花很長時間才能回傳任何資料。 這可能代表查詢處理時間很長，因為來源正忙於其他任務，或查詢本身不夠理想，或資料儲存方式讓取回時間過長。 考慮是否同時有其他查詢在該來源執行，或是否可以更新查詢以加快資料擷取速度。 如果有團隊管理你的資料來源，請聯絡他們修改查詢或檢查資料來源效能。

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

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

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

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

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

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

  • 使用 Azure IR 於與您的源資料儲存庫區域相同或相近的區域。

• 「傳輸 - 從來源讀取」的工作持續時間較長：

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

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

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

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

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

  • 使用 Azure IR 於與您的源資料儲存庫區域相同或相近的區域。

• 「傳輸 - 寫入至接收」的工作持續時間較長：

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

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

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

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

    • 否則，請逐步調整平行複製。 太多平行復本甚至可能會損害效能。

  • 請在與匯出資料儲存區相同或相近的區域使用 Azure IR。

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

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

當複製效能未達預期時，若要排除Azure Integration Runtime上單一複製活動的問題，如果你在複製監控檢視中看到效能調整建議，就套用建議再試一次。 否則，請了解複製活動執行詳細資料、檢查哪個階段的持續時間 最長，並套用下列指導方針來提升複製效能：

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

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

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

  • 檢查自我代管的 IR 機器與來源資料庫之間是否有低延遲的連線。 如果你的來源在Azure，你可以用這個工具來檢查自架紅外線機器到Azure區域的延遲，越小越好。

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

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

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

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

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

• 「傳輸 - 從來源讀取」的工作持續時間較長：

  • 檢查自我代管的 IR 機器與來源資料庫之間是否有低延遲的連線。 如果你的來源在Azure，你可以用這個工具來檢查自架紅外線機器到Azure區域的延遲，越小越好。

  • 檢查自我裝載 IR 機器是否有足夠的輸入頻寬可有效率地讀取和傳輸資料。 如果你的原始資料庫在Azure，可以用 這個工具來檢查下載速度。

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

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

    • 當從 Oracle、Netezza、Teradata、SAP Hana、SAP Table 以及 SAP Open Hub 複製資料時，啟用資料分割選項以平行複製資料。

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

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

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

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

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

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

• 「傳輸 - 寫入至接收」的工作持續時間較長：

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

  • 檢查自我裝載 IR 機器連線至接收器資料存放區時是否具有低延遲。 如果你的接收端在 Azure，你可以使用這個工具來檢查從自架式整合執行器到 Azure 區域的延遲，越小越好。

  • 檢查自我裝載 IR 機器是否有足夠的輸出頻寬可有效率地傳輸和寫入資料。 如果你的接收資料儲存庫是在 Azure，你可以用 這個工具來檢查上傳速度。

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

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

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

連接器和 IR 效能

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

活動執行時間在使用 Azure IR 與 Azure 虛擬網路 IR 時有所不同。

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

• 徵兆：只需在資料集中切換「連結服務」下拉選單即可執行相同的管線活動，但會導致執行時間大幅不同。 當資料集基於管理的虛擬網路整合執行階段時，其平均執行時間比基於預設整合執行階段時要更長。

• Cause：查看管線運行細節，你會發現慢速管線是在管理虛擬網路（虛擬網路）IR 上運行，而正常管線則是在 Azure IR 上運行。 設計上，受管虛擬網路 IR 比 Azure IR 需要更長的排隊時間，因為我們不會為每個服務實例保留一個運算節點，所以每次複製活動都要先預熱，且主要發生在虛擬網路加入時，而非 Azure IR。

載入 Azure SQL Database 時效能低

• Symptoms：將資料複製到Azure SQL Database變得緩慢。

• Cause：問題的根本原因主要是由Azure SQL Database側的瓶頸觸發。 以下是部分可能原因：

  • Azure SQL Database 的層級不夠高。

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

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

  • WriteBatchSize 不夠大，無法容納架構數據列大小。 嘗試放大該問題的屬性。

  • 使用的是預存程序而非大量插入，這預期會有較差的效能。

解析大型 Excel 檔案時出現逾時或效能變慢

• 徵兆：

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

  • 當你使用 copy activity 將大型 Excel 檔案（>= 100 MB）複製到其他資料儲存庫時，可能會遇到效能變慢或 OOM 問題。

• 原因：

  • 針對匯入架構、預覽數據，以及在 Excel 數據集上列出工作表等作業。 逾時為 100 秒且為固定值。 對於大型 Excel 檔案，這些操作可能無法在逾時值內完成。

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

• 解決方法：

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

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

  • 若要將大型 Excel 檔案（>100 MB）複製到其他儲存位置，你可以使用支援串流讀取且效能較佳的 Data Flow Excel 來源。

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

• Symptoms：當你讀取大型 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 問題，請使用 pipeline 中的 foreach 活動 + copy/mapping data flow 活動來處理每個檔案或子資料夾。
  • Option-5：其他：
    • 對於 XML，如果每個檔案具有相同的結構描述，請使用 Notebook 活動搭配記憶體最佳化叢集，以從檔案讀取資料。 目前，Spark 有不同的實作來處理 XML。
    • 對於 JSON，請在對應資料流來源的 JSON 設定中，使用不同的文件形式 (例如 單一文件、每行文件和文件陣列)。 如果 JSON 檔案的內容是 每行一份文件，則會耗用很少的記憶體。

其他參考

以下是一些所支援的資料存放區的效能監測和調優參考資料：

• Azure Blob 儲存：Blob 儲存的可擴展性與效能目標以及Blob 儲存的效能與可擴展性檢查清單。
• Azure 資料表儲存：可擴展性與效能目標，適用於資料表儲存，以及 效能與可擴展性檢查清單，適用於資料表儲存。
• Azure SQL Database：你可以監控效能並檢查資料庫交易單位（DTU）百分比。
• Azure Synapse Analytics：其能力以 Data Warehouse 單位（DWU）衡量。 請參見管理運算能力，Azure Synapse Analytics（概述）。
• Azure Cosmos DB: Azure Cosmos DB 的效能層級。
• SQL Server：監控並調整效能。
• 內部部署檔案伺服器：檔案伺服器的效能微調。

相關內容

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

• 複製活動概述
• 複製活動效能與可擴展性指南
• 複製活動效能優化功能
• 將資料從資料湖或資料倉儲遷移到 Azure
• 將資料從 Amazon S3 遷移到 Azure 儲存體