Azure
任務是如何分配給 ForEach 迭代的
Lookup-ForEach 模式在 Azure 數據工廠 (ADF) 中很常見。Lookup 產生的項目如何分配給 ForEach 的工人,其數量由 Batch Count 控制?
它們按照 Lookup 生成的順序循環分配。雖然我找不到任何文件來斷言這一點,但這是我的觀察。我可以用一個簡單的例子可靠地重現它。
在新管道中,我添加了一個數組變數 ForEach,並在 ForEach 內部添加了一個 Wait(管道 JSON 包含在末尾)。數組變數提供 ForEach 的項目。儘管問題提到了查找,但使用數組變數時結果是相同的。等待的持續時間由數組的值決定,只是為了隨著時間的推移分散迭代以使它們更容易觀察到。
我執行了管道並收集了 ADF 輸出。我使用 Duration 來計算結束時間(以 mm:ss 顯示如下)。我又添加了三列,每個“工人”一列。為了了解哪個工人執行了哪個迭代,我遵循了 Start-End 鏈。
Task Start Duration End A B C ========== ============================ ======== ===== = = = 9 Wait1 2021-06-01T05:17:39.6100287Z 00:01:32 19:11 c 8 Wait1 2021-06-01T05:17:09.3290518Z 00:01:32 18:41 b 7 Wait1 2021-06-01T05:16:40.6095309Z 00:01:32 18:12 a 6 Wait1 2021-06-01T05:16:07.9623704Z 00:01:32 17:39 c 5 Wait1 2021-06-01T05:15:37.7842636Z 00:01:32 17:09 b 4 Wait1 2021-06-01T05:15:07.9421207Z 00:01:32 16:39 a 3 Wait1 2021-06-01T05:15:06.3028589Z 00:01:02 16:08 c 2 Wait1 2021-06-01T05:15:06.3028589Z 00:00:32 15:38 b 1 Wait1 2021-06-01T05:15:06.2872305Z 00:00:02 15:08 a ForEach1 2021-06-01T05:15:05.896518Z 00:04:06
我任意將任務 1 分配給工人 A。它在 15:08 完成,所以我找到了一個從那時開始的任務(在報告的持續時間的精度內),即任務 4,並將其也分配給工人 A,依此類推。任務 2 和 3 類似地啟動它們自己的鏈。產生的模式是循環分配的模式。
這種對更複雜的工作負載的分析,涉及更多的任務、更大的批處理計數和不同的持續時間,為循環分配產生了相同的證據。例如,當 Batch Count 為 20 時提供 21 個任務,我看到第 21 個任務在第一個任務完成之前永遠不會開始。
{ "name": "ForEach RoundRobin Demo", "properties": { "activities": [ { "name": "ForEach1", "type": "ForEach", "dependsOn": [], "userProperties": [], "typeProperties": { "items": { "value": "@variables('Intervals')", "type": "Expression" }, "batchCount": 3, "activities": [ { "name": "Wait1", "type": "Wait", "dependsOn": [], "userProperties": [], "typeProperties": { "waitTimeInSeconds": { "value": "@item()", "type": "Expression" } } } ] } } ], "variables": { "Intervals": { "type": "Array", "defaultValue": [ 1, 30, 60, 180, 180, 180, 180, 180, 180 ] } }, "annotations": [] } }