本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Amazon EventBridge 管道批次處理和並行
<a name="eb-pipes-batching-concurrency"></a>

## 批次處理行為
<a name="pipes-batching"></a>

EventBridge 管道支援從來源和支援它的目標進行批次處理。此外， AWS Lambda 和 也支援批次處理至擴充 AWS Step Functions。由於不同的服務支援不同層級的批次處理，因此您無法設定大於目標所支援的批次大小的管道。例如，Amazon Kinesis 串流來源支援的批次大小上限為 10,000 筆記錄，但 Amazon 簡單佇列服務每個批次最多支援 10 則訊息做為目標。因此，從 Kinesis 串流到 Amazon SQS 佇列的管道在來源上可以設定最大批次大小為 10。

如果您使用不支援批次處理的擴充功能或目標來設定管道，您將無法在來源上啟動批次處理。

在來源上啟動批次處理時，JSON 記錄的陣列會透過管道傳遞，然後對應至受支援的擴充或目標的批次 API。[輸入轉換器](eb-pipes-input-transformation.md)會分別套用於陣列中的每個 JSON 記錄，而不是整個陣列。如需這些陣列的範例，請參閱 [Amazon EventBridge 管道來源](eb-pipes-event-source.md) 並選取特定來源。即使批次大小為 1，管道也會將批次 API 用於支援的擴充或目標。如果擴充或目標沒有批次 API，但收到完整的 JSON 承載， 例如 Lambda 和 Step 函數，則會在一個要求中傳送整個 JSON 陣列。即使批次大小為 1，請求也會以 JSON 陣列的形式傳送。

如果在來源設定了管道以進行批次處理，且目標支援批次處理，您可以從擴充中傳回 JSON 項目陣列。此陣列可以包含比原始來源更短或更長的陣列。但是，如果陣列大於目標支持的批次大小，則管道將不會調用目標。

### 受支援的可分批目標
<a name="pipes-batchable-target"></a>


| Target | 最大批次大小 | 
| --- | --- | 
| CloudWatch Logs | 10,000 | 
| EventBridge 事件匯流排 | 10 | 
| Firehose 串流 | 500 | 
| Kinesis 串流 | 500 | 
| Lambda 函式 | 客戶定義 | 
| Step Functions 狀態機器 | 客戶定義 | 
| Amazon SNS 主題 | 10 | 
| Amazon SQS 佇列 | 10 | 

下列擴充項目和目標會接收完整批次事件承載以進行處理，並受到事件總裝載大小的限制，而不是批次的大小：
+ Step Functions 狀態機器 (262144 個字元)
+ Lambda 函數 (6MB)

### 部分批次失敗
<a name="pipes-partial-batch-failure"></a>

針對 Amazon SQS 和串流來源，例如 Kinesis 和 DynamoDB，EventBridge 管道支援目標故障的部分批次失敗處理。如果目標支援批次處理，而且只有部分批次成功，EventBridge 會自動重試批次處理其餘的承載。針對最新的豐富內容，此重試會透過整個管道進行，包括重新調用任何已設定的擴充。

不支援擴充的部分批次失敗處理。

針對 Lambda 和 Step Functions 目標，您也可以從目標傳回已定義結構的承載，以指定部分失敗。這表示需要重試的事件。

**部分故障有效負載結構示例**

```
{ 
  "batchItemFailures": [ 
    {
      "itemIdentifier": "id2"
    },
    {
      "itemIdentifier": "id4"
    }
]
```

在此範例中，`itemIdentifier` 會比對目標從其原始來源處理的事件 ID。針對 Amazon SQS 來說，這是 `messageId`. 針對 Kinesis 和 DynamoDB 而言，這是 `eventID`. 為了讓 EventBridge 管道充分處理來自目標的部分批次失敗，這些欄位必須包含在擴充所傳回的任何陣列裝載中。

## 輸送量和並發行為
<a name="pipes-concurrency"></a>

管道接收到的每個事件或一批事件，而該事件傳遞到一個擴充或目標都被視為管道*執行*。處於 `STARTED` 狀態的管道會持續輪詢來自來源的事件，並根據可用的積壓和配置的批次處理設定縱向擴展和縮小。

有關並行管道執行的配額，以及每個帳戶和區域的管道數量，請參閱 [EventBridge 管道配額](eb-quota.md#eb-pipes-limits)。

根據預設，根據來源，單一管道會擴展至下列最大並行執行次數：
+ **DynamoDB**：並行執行可以攀升至管道上 `ParallelizationFactor` 設定的高度乘以串流中的碎片數目。
+ **Apache Kafka**：並行執行可以攀升與該主題有關的分區數量一樣高，最多可達 1000 個。
+ **Kinesis** – 並行執行可以攀升到與管道上`ParallelizationFactor`設定的 一樣高，乘以串流中的碎片數量。
+ **Amazon MQ**：5
+ **Amazon SQS**：1250

如果您需要更高的最大輪詢輸送量或並行限制，請[聯絡支援人員](https://console.aws.amazon.com/support/home?#/case/create?issueType=technical)。

**注意**  
執行限制被認為是盡力而為的安全限制。雖然輪詢不會限制在這些值之下，但管道或帳戶可能會高於這些建議值。

管道執行的時間限制為最多 5 分鐘，包括擴充和目標處理。此限制目前無法提高。

具有嚴格排序來源 (例如 Amazon SQS FIFO 佇列、Kinesis 和 DynamoDB Streams 或 Apache Kafka 主題) 的管道會進一步受到來源組態的並行限制，例如 FIFO 佇列的訊息群組 ID 數目或 Kinesis 佇列的碎片數目。由於在這些限制內嚴格保證排序，具有排序來源的管道不能超過這些並行限制。