As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Fluxo do Amazon DynamoDB como origem para o EventBridge Pipes
<a name="eb-pipes-dynamodb"></a>

É possível usar o EventBridge Pipes para receber registros em um fluxo do DynamoDB. Opcionalmente, é possível filtrar ou aprimorar esses registros antes de enviá-los para um destino para processamento. Há configurações específicas para o Amazon DynamoDB Streams que podem ser escolhidas ao configurar o pipe. O EventBridge Pipes mantém a ordem dos registros do fluxo de dados ao enviar esses dados para o destino.

**Importante**  
A desativação de um fluxo do DynamoDB que é a origem de um pipe faz com que este pipe se torne inutilizável, mesmo que você habilite o fluxo novamente. Isto pode acontecer porque:  
Não é possível interromper, iniciar ou atualizar um pipe cuja origem está desativada.
Não é possível atualizar um pipe com uma nova origem após a criação. Ao reativar um fluxo do DynamoDB, esse fluxo recebe um novo nome do recurso da Amazon (ARN) e não está mais associado ao seu pipe.
Se reativar o fluxo do DynamoDB, precisará criar um novo pipe usando o novo ARN do fluxo.

**Evento de exemplo**

O exemplo de evento a seguir mostra as informações recebidas pelo pipe. É possível usar esse evento para criar e filtrar seus padrões de eventos ou para definir a transformação de entrada. Nem todos os campos podem ser filtrados. Para mais informações sobre quais campos podem ser filtrados, consulte [Filtragem de eventos no Amazon Pipes EventBridge](eb-pipes-event-filtering.md).

```
[
  {
    "eventID": "1",
    "eventVersion": "1.0",
    "dynamodb": {
      "Keys": {
        "Id": {
          "N": "101"
        }
      },
      "NewImage": {
        "Message": {
          "S": "New item!"
        },
        "Id": {
          "N": "101"
        }
      },
      "StreamViewType": "NEW_AND_OLD_IMAGES",
      "SequenceNumber": "111",
      "SizeBytes": 26
    },
    "awsRegion": "us-west-2",
    "eventName": "INSERT",
    "eventSourceARN": "arn:aws:dynamodb:us-east-1:111122223333:table/EventSourceTable",
    "eventSource": "aws:dynamodb"
  },
  {
    "eventID": "2",
    "eventVersion": "1.0",
    "dynamodb": {
      "OldImage": {
        "Message": {
          "S": "New item!"
        },
        "Id": {
          "N": "101"
        }
      },
      "SequenceNumber": "222",
      "Keys": {
        "Id": {
          "N": "101"
        }
      },
      "SizeBytes": 59,
      "NewImage": {
        "Message": {
          "S": "This item has changed"
        },
        "Id": {
          "N": "101"
        }
      },
      "StreamViewType": "NEW_AND_OLD_IMAGES"
    },
    "awsRegion": "us-west-2",
    "eventName": "MODIFY",
    "eventSourceARN": "arn:aws:dynamodb:us-east-1:111122223333:table/EventSourceTable",
    "eventSource": "aws:dynamodb"
  }
]
```

## Fluxos de sondagem e agrupamento em lotes
<a name="pipes-ddb-polling"></a>

O EventBridge sonda os fragmentos em seu fluxo do DynamoDB em busca de registros a uma taxa básica de quatro vezes por segundo. Quando os registros estão disponíveis, o EventBridge processa o evento e aguarda o resultado. Se o processamento tiver êxito, o EventBridge continua a sondagem até que ela receba mais registros.

Por padrão, o EventBridge invoca seu pipe assim que os registros estão disponíveis. Se o lote que o EventBridge lê da origem tiver apenas um registro nele, apenas um evento será processado. Para evitar invocar a função com um número pequeno de registros, você pode instruir à origem dos eventos para fazer o buffer dos registros por até cinco minutos, configurando uma janela de processamento de lotes. Antes de processar os eventos, o EventBridge continua a ler registros da origem de eventos até coletar um lote inteiro, até que a janela de processamento de lotes expire ou até que o lote atinja o limite de carga útil de 6 MB.

**Importante**  
O pipe entregará os registros de stream do DynamoDB para o Amazon SQS pelo menos uma vez. Para garantir que nenhum registro seja perdido, sugerimos definir uma política de repetição com uma idade máxima menor que o período de retenção do stream do DynamoDB. Geralmente, os streams do DynamoDB retêm eventos por 24 horas.

Você também pode aumentar a simultaneidade processando vários lotes de cada fragmento em paralelo. O EventBridge pode processar até 10 lotes em cada fragmento simultaneamente. Se aumentar o número de lotes simultâneos por fragmento, o EventBridge ainda garantirá o processamento por ordem no nível da chave de partição.

Configure a configuração `ParallelizationFactor` para processar um fragmento de um fluxo de dados do Kinesis ou do DynamoDB com mais de uma execução do pipe simultaneamente. É possível especificar o número de lotes simultâneos que o Lambda pesquisa de um fragmento por meio de um fator de paralelização de 1 (padrão) a 10. Por exemplo, ao definir `ParallelizationFactor` como 2, você poderá ter no máximo 200 execuções simultâneas do EventBridge Pipe para processar 100 fragmentos de dados do Kinesis. Isso ajuda a aumentar o throughput de processamento quando o volume de dados é volátil e o valor de `IteratorAge` é alto. Observe que o fator de paralelização não funcionará se você estiver usando a agregação do Kinesis. 

## Posição inicial de sondagem e fluxo
<a name="pipes-ddb-stream-start-position"></a>

Esteja ciente de que a origem de fluxo durante a criação e as atualizações de pipes é, finamente, consistente.
+ Durante a criação do pipe, pode levar alguns minutos para a sondagem de eventos do fluxo iniciar.
+ Durante as atualizações de pipe para a configuração de sondagem de origem, pode levar alguns minutos para interromper e reiniciar a sondagem de eventos do fluxo. 

Este comportamento significa que, se especificar `LATEST` como posição inicial do fluxo, o mapeamento da origem do evento poderá perder eventos durante a criação ou as atualizações. Para garantir que nenhum evento seja perdido, especifique a posição inicial do fluxo como `TRIM_HORIZON`.

## Gerar relatórios de falhas de itens de lote
<a name="pipes-ddb-batch-failures"></a>

Quando o EventBridge consome e processa dados de streaming de uma origem, ele definirá checkpoints por padrão no número mais elevado na sequência de um lote, mas somente quando o lote tiver êxito total. Para evitar o reprocessamento de todas as mensagens processadas com êxito em um lote com falha, é possível configurar o enriquecimento ou o destino para retornar um objeto indicando quais mensagens tiveram êxito e quais falharam. Isso se chama resposta parcial em lote.

Para obter mais informações, consulte [Lote com falha parcial](eb-pipes-batching-concurrency.md#pipes-partial-batch-failure).

### Condições de sucesso e falha
<a name="pipes-ddb-batch-failures-conditions"></a>

Se retornar qualquer um dos seguintes, o EventBridge tratará um lote como um êxito total:
+ Uma lista de `batchItemFailure` vazia
+ Uma lista de `batchItemFailure` nula
+ Uma vazia `EventResponse`
+ Uma nula `EventResponse`

Se retornar qualquer um dos seguintes, o EventBridge tratará um lote como uma falha total:
+ Uma string vazia `itemIdentifier`
+ Uma nula `itemIdentifier`
+ Um `itemIdentifier` com um nome de chave inválido

O EventBridge faz novas tentativas após falhas com base na sua estratégia de repetição.