復制活動（從 Cosmos SQL api 到 ADLS gen2）在 Synapse 中失敗

Question

我正在嘗試運行一個管道，該管道將數據從 Cosmos (SQL API) 復制到多個表的 ADLS gen2。 Lookup Activity 正在傳遞查詢列表，Copy Activity 使用自托管 IR 在 ForEach 中運行。 但是它在第一次迭代后一直失敗並出現以下錯誤：

對目標副本 data1_copy1 的操作失敗：失敗發生在“接收器”端。 ErrorCode=UserErrorFailedFileOperation,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=上傳文件在路徑 tfs/OU Cosmos Data/LATAM/fact\dl-br-prod.,Source=Microsoft.DataTransfer.Common,' 'Type=Microsoft.Azure.Documents.RequestTimeoutException,Message=請求超時。

此外，我確信這不是任何一個特定表的問題，因為我嘗試以不同的順序傳遞查詢，在每次嘗試中，第一個查詢成功完成，並且對於 rest 的迭代復制活動運行一段時間並最終失敗。

到目前為止，我已經嘗試過：

1. 以順序模式運行 ForEach
2. 將接收器端的塊大小（以 MB 為單位）更改為 20MB。 默認為 100MB

Answer 1

您能否查看官方 MS 文檔中建議的解決方法，因為這涉及自托管 IR。

對 Azure Data Lake Storage Gen2 帳戶的請求導致超時錯誤

原因：該問題是由 Azure Data Lake Storage Gen2 接收器超時錯誤引起的，該錯誤通常發生在自托管集成運行時 (IR) 計算機上。

推薦：

1. 如果可能，請將您的自托管 IR 計算機和目標 Azure Data Lake Storage Gen2 帳戶放在同一區域中。 這有助於避免隨機超時錯誤並產生更好的性能。

2. 檢查是否有特殊的網絡設置，例如 ExpressRoute，並確保網絡有足夠的帶寬。 我們建議您在整體帶寬較低時降低自托管 IR 並發作業設置。 這樣做有助於避免多個並發作業之間的網絡資源競爭。

3. 如果文件大小適中或較小，請為非二進制副本使用較小的塊大小以減輕此類超時錯誤。 有關詳細信息，請參閱Blob 存儲放置塊

Answer 2

我能夠得到 Microsoft Cosmos 產品團隊的回應：

根本原因：

SDK 客戶端配置了一些超時值，請求花費了更長的時間。

超時的原因是由於結果大小較大而導致網關延遲增加（網關沒有延遲 SLA）。 這可能是預期的（更多數據往往需要更長的時間才能讀取、發送和接收）。

解析度：

增加客戶端中使用的 RequestTimeout。

擁有 Synapse 數據傳輸（使用 .NET 2.5.1 SDK 並擁有 Microsoft.DataTransfer 應用程序）的團隊可以將 .NET SDK 上使用的 RequestTimeout 增加到更高的值。 在較新的 SDK 版本中，此值默認為 65 秒。

盡管我們選擇完全繞過這條路線並包括 SynapseLink 或 Private Endpoint。