Tratar registros duplicados - Amazon Kinesis Data Streams

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á.

Tratar registros duplicados

Há dois principais motivos pelos quais os registros podem ser entregues mais de uma vez ao seu aplicativo Amazon Kinesis Data Streams: retentativas de produtor e retentativas de consumidor. Seu aplicativo precisa prever e tratar devidamente o processamento de registros individuais várias vezes.

Retentativas de produtor

Considere um produtor que tem um tempo limite esgotado relacionado à rede depois de fazer uma chamada aPutRecord, mas antes de poder receber uma confirmação do Amazon Kinesis Data Streams. O produtor não tem certeza de que o registro foi entregue ao Kinesis Data Streams. Supondo que cada registro é importante para o aplicativo, o produtor teria sido concebido de modo a tentar novamente a chamada com os mesmos dados. Se ambosPutRecordAs chamadas a para os mesmos dados foram confirmadas com sucesso no Kinesis Data Streams, então haverá dois registros do Kinesis Data Streams. Embora os dois registros tenham dados idênticos, eles também têm números sequenciais exclusivos. Os aplicativos que precisam de rigorosas garantias devem incorporar uma chave primária ao registro para remover duplicatas mais tarde ao processar. Observe que o número de duplicatas resultante das retentativas de produtor costuma ser baixo em comparação com o número de duplicatas resultante das retentativas de consumidor.

Retentativas de consumidor

As retentativas de consumidor (aplicativo de processamento de dados) acontecem quando os processadores de registros são reiniciados. Os processadores de registros do mesmo estilhaço reiniciam nos seguintes casos:

  1. Um operador é encerrado inesperadamente

  2. Instâncias de operador são adicionadas ou removidas

  3. Os estilhaços são mesclados ou divididos

  4. O aplicativo é implantado

Em todos esses casos, oshards-to-worker-to-record-processoro mapeamento é atualizado continuamente para o processamento da balança de carga. Processadores de estilhaços que foram migrados para outras instâncias reiniciam o processamento de registros a partir do último ponto de verificação. Isso acarreta processamento de registros duplicado, conforme mostrado no exemplo abaixo. Para obter mais informações sobre balanceamento de carga, consulte Reestilhaçamento, escalabilidade e processamento paralelo.

Exemplo: Retentativas de consumidor gerando reentrega de registros

Neste exemplo, você tem um aplicativo que lê continuamente registros de um stream, agrega registros em um arquivo local e faz upload do arquivo para o Amazon S3. Para simplificar, suponha que haja apenas 1 estilhaço e 1 operador processando o estilhaço. Considere a sequência de eventos de exemplo a seguir, supondo que o último ponto de verificação ocorreu no registro de número 10.000:

  1. Um operador lê o próximo lote de registros a partir do estilhaço, registros de 10.001 a 20.000.

  2. O operador passa o lote de registros para o processador de registros associado.

  3. O processador de registros agrega os dados, cria um arquivo do Amazon S3 e faz upload do arquivo para o Amazon S3 com êxito.

  4. O operador é encerrado inesperadamente antes que ocorra um novo ponto de verificação.

  5. O aplicativo, o operador e o processador de registros são reiniciados.

  6. O operador agora começa a ler a partir do último ponto de verificação bem-sucedido, que neste caso é 10.001.

Desse modo, os registros de 10.001 a 20.000 são consumidos mais de uma vez.

Ser resiliente a retentativas de consumidor

Mesmo que os registros possam ser processados mais de uma vez, seu aplicativo pode apresentar efeitos colaterais como se os registros tivessem sido processados apenas uma vez (processamento idempotente). As soluções para esse problema variam em termos de complexidade e precisão. Se o destino dos dados finais puder tratar bem das duplicatas, recomendamos confiar no destino final para obter o processamento idempotente. Por exemplo, comOpenSearchVocê pode usar uma combinação de versionamento e IDs exclusivos para evitar processamento duplicado.

O aplicativo de exemplo da seção anterior lê continuamente os registros de um stream, agrega os registros em um arquivo local e faz upload do arquivo para o Amazon S3. Conforme ilustrado, os registros de 10001 a 20000 são consumidos mais de uma vez, resultando em vários arquivos do Amazon S3 com os mesmos dados. Uma forma de reduzir as duplicatas desse exemplo é garantir que a etapa 3 use o seguinte esquema:

  1. O processador de registros usa um número fixo de registros por arquivo do Amazon S3, como 5.000.

  2. O nome do arquivo usa esse esquema: Prefixo do Amazon S3, id do estilhaço eFirst-Sequence-Num. Neste caso, pode ser algo como sample-shard000001-10001.

  3. Depois de fazer upload do arquivo do Amazon S3, defina o ponto de verificação especificandoLast-Sequence-Num. Neste caso, o ponto de verificação seria definido no registro de número 15.000.

Com esse esquema, mesmo se os registros forem processados mais de uma vez, o arquivo do Amazon S3 resultante terá o mesmo nome e os mesmos dados. As retentativas geram apenas a gravação dos mesmos dados no mesmo arquivo mais de uma vez.

No caso de uma operação de reestilhaçamento, o número de registros deixados no estilhaço pode ser menor que o número fixo necessário. Nesse caso, seushutdown()O método precisa esvaziar o arquivo para o Amazon S3 e ponto de verificação no último número de sequência. O esquema acima também é compatível com as operações de reestilhaçamento.