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á.
# Otimizar consumidores do Amazon Kinesis Data Streams
Você pode otimizar ainda mais seu consumidor do Amazon Kinesis Data Streams com base no comportamento específico observado.
Leia os seguintes tópicos para identificar soluções.
**Topics**
+ [Melhorar o processamento de baixa latência](kinesis-low-latency.md)
+ [Processe dados serializados usando AWS Lambda com a Amazon Kinesis Producer Library](kinesis-record-deaggregation.md)
+ [Use refragmentação, escalonamento e processamento paralelo para alterar o número de fragmentos](kinesis-record-processor-scaling.md)
+ [Tratamento de registros duplicados](kinesis-record-processor-duplicates.md)
+ [Tratamento do startup, do desligamento e do controle de utilização](kinesis-record-processor-additional-considerations.md)
# Melhorar o processamento de baixa latência
O *atraso de propagação* é definido como a end-to-end latência do momento em que um registro é gravado no stream até ser lido por um aplicativo consumidor. Esse atraso varia dependendo de uma série de fatores, mas é afetado principalmente pelo intervalo de sondagem de aplicativos de consumidor.
Para a maioria dos aplicativos, recomendamos a sondagem de cada fragmento uma vez por segundo por aplicativo. Isso permite várias aplicações de consumo processando um fluxo simultaneamente sem atingir os limites do Amazon Kinesis Data Streams de cinco chamadas de `GetRecords` por segundo. Além disso, o processamento de lotes de dados maiores tende a ser mais eficiente na redução da latência de rede e outras latências de downstream no seu aplicativo.
Os padrões da KCL estão definidos para seguir a prática recomendada de sondagem a cada segundo. Esse padrão gera atrasos de propagação médios que costumam ser menores que 1 segundo.
Os registros do Kinesis Data Streams ficam disponíveis para serem lidos imediatamente após serem gravados. Há alguns casos de uso que precisam aproveitar isso e exigir o consumo de dados do fluxo assim que ele estiver disponível. É possível reduzir significativamente o atraso de propagação sobrepondo as configurações padrão da KCL para sondar com mais frequência, como mostrado nos exemplos a seguir.
Código de configuração Java da KCL:
```
kinesisClientLibConfiguration = new
KinesisClientLibConfiguration(applicationName,
streamName,
credentialsProvider,
workerId).withInitialPositionInStream(initialPositionInStream).withIdleTimeBetweenReadsInMillis(250);
```
Configuração de arquivo de propriedades da KCL para Python e Ruby:
```
idleTimeBetweenReadsInMillis = 250
```
**nota**
Como o Kinesis Data Streams tem um limite de cinco chamadas de `GetRecords` por segundo por fragmento, configurar a propriedade `idleTimeBetweenReadsInMillis` abaixo de 200 ms pode fazer com que a aplicação receba a exceção `ProvisionedThroughputExceededException`. Muitas dessas exceções podem gerar esperas exponenciais significativas e, portanto, causar latências inesperadas significativas no processamento. Ao definir essa propriedade em 200 ms ou acima e houver mais de um aplicativo de processamento, ocorrerá um controle de utilização semelhante.
# Processe dados serializados usando AWS Lambda com a Amazon Kinesis Producer Library
A [Amazon Kinesis Producer Library](https://docs.aws.amazon.com/kinesis/latest/dev/developing-producers-with-kpl.html) (KPL) agrega pequenos registros formatados pelo usuário em registros maiores de até 1 MB para usar melhor o throughput do Amazon Kinesis Data Streams. Embora o KCL para Java ofereça suporte à desagregação desses registros, você precisa usar um módulo especial para desagregar registros ao usá-lo AWS Lambda como consumidor de seus streams. Você pode obter o código e as instruções do projeto necessários GitHub nos [Módulos de desagregação da biblioteca de produtores do Amazon Kinesis](https://github.com/awslabs/kinesis-deaggregation) para Lambda. AWS Os componentes deste projeto oferecem a capacidade de processar dados serializados KPL em Java AWS Lambda, Node.js e Python. Esses componentes também podem ser usados como parte de um [aplicativo de várias linguagens da KCL](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client-multilang/src/main/java/software/amazon/kinesis/multilang/package-info.java).
# Use refragmentação, escalonamento e processamento paralelo para alterar o número de fragmentos
A *refragmentação* permite aumentar ou diminuir o número de fragmentos em um fluxo para se adaptar às alterações na taxa de dados que fluem pelo fluxo. A refragmentação costuma ser realizado por um aplicativo administrativo que monitora as métricas de tratamento de dados de fragmento. Embora não inicie operações de refragmentação, a KCL é projetada para se adaptar às alterações no número de fragmentos resultantes desse processo.
Conforme observado em [Usar uma tabela de concessões para monitorar os fragmentos processados pela aplicação de consumo da KCL](shared-throughput-kcl-consumers.md#shared-throughput-kcl-consumers-leasetable), a KCL rastreia os fragmentos no fluxo usando uma tabela do Amazon DynamoDB. Quando novos fragmentos são criados em consequência da refragmentação, a KCL descobre os novos fragmentos e preenche novas linhas na tabela. Os operadores descobrem automaticamente os novos fragmentos e criam processadores para tratar os dados provenientes deles. A KCL também distribui os fragmentos no fluxo entre todos os operadores e processadores de registros disponíveis.
A KCL garante que os dados existentes nos fragmentos antes do refragmentação sejam processados primeiro. Depois do processamento dos dados, os dados dos novos fragmentos são enviados para processadores de registros. Dessa forma, a KCL preserva a ordem em que os registros de dados foram adicionados ao fluxo para uma determinada chave de partição.
## Exemplo: refragmentação, escalonamento e processamento paralelo
O exemplo a seguir ilustra como a KCL ajuda a lidar com escalabilidade e refragmentação:
+ Por exemplo, a aplicação está sendo executada em uma instância do EC2 e processa um fluxo de dados do Kineses com quatro fragmentos. Essa instância tem um operador da KCL e quatro processadores de registros (um processador de registros para cada fragmento). Esses quatro processadores de registros são executados em paralelo no mesmo processo.
+ Em seguida, ao escalar o aplicativo para usar outra instância, duas instâncias processarão um único fluxo que tem quatro fragmentos. Ao ser iniciado na segunda instância, o operador da KCL faz balanceamento de carga com a primeira instância, de modo que cada instância passa a processar dois fragmentos.
+ Se decidir dividir os quatro fragmentos em cinco, a KCL coordenará novamente o processamento entre as instâncias: uma instância processará três fragmentos e a outra processará dois fragmentos. Uma coordenação semelhante ocorre ao mesclar fragmentos.
Normalmente, ao usar a KCL, é necessário garantir que o número de instâncias não exceda o número de fragmentos (exceto para fins de espera de falha). Cada fragmento é processado por exatamente um operador da KCL e tem exatamente um processador de registros correspondente, para nunca necessitar de várias instâncias para processar apenas um fragmento. Mas como um operador pode processar qualquer número de fragmentos, tudo bem se o número de fragmentos ultrapassar o número de instâncias.
Para expandir o processamento do aplicativo, deve-se testar uma combinação destas abordagens:
+ Aumentar o tamanho da instância (porque todos os processadores de registros são executados em paralelo em um processo)
+ Aumentar o número de instâncias até o número máximo de fragmentos abertos (porque os fragmentos podem ser processados de forma independente)
+ Aumentar o número de fragmentos (o que aumenta o nível de paralelismo)
Observe que é possível usar o ajuste de escala automático para escalar automaticamente as instâncias com base em métricas apropriadas. Para obter mais informações, consulte o [Guia do usuário do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/).
Quando a refragmentação aumenta o número de fragmentos no fluxo, o aumento correspondente no número de processadores de registros aumenta a carga nas instâncias do EC2 que os hospedam. Se as instâncias fazem parte de um grupo de Auto Scaling e a carga aumenta suficientemente, o grupo de Auto Scaling adiciona mais instâncias para lidar com o aumento de carga. É necessário configurar as instâncias para iniciar a aplicação do Amazon Kinesis Data Streams no startup, para que os operadores e processadores de registros adicionais se tornem imediatamente ativos na nova instância.
Para obter mais informações sobre a refragmentação, consulte [Refragmentar um fluxo](kinesis-using-sdk-java-resharding.md).
# Tratamento de registros duplicados
Há dois principais motivos pelos quais os registros podem ser entregues mais de uma vez à aplicação do Amazon Kinesis Data Streams: novas tentativas de produtor e novas tentativas de consumidor. Seu aplicativo precisa prever e tratar devidamente o processamento de registros individuais várias vezes.
## Novas tentativas do produtor
Considere um produtor que tem um tempo limite esgotado de rede depois de fazer uma chamada a `PutRecord`, 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 as duas chamadas a `PutRecord` para os mesmos dados foram confirmadas com sucesso no Kinesis Data Streams, 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.
**nota**
Se você usa o AWS SDK`PutRecord`, saiba mais sobre o [comportamento de repetição do SDK no guia](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) do usuário *AWS SDKs and Tools*.
## Novas tentativas do 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 fragmento reiniciam nos seguintes casos:
1. Um operador é encerrado inesperadamente
1. Instâncias de operador são adicionadas ou removidas
1. Os fragmentos são mesclados ou divididos
1. O aplicativo é implantado
Em todos esses casos, o mapeamento shards-to-worker-to -record-processor é atualizado continuamente para balancear a carga do processamento. Processadores de fragmentos 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 [Use refragmentação, escalonamento e processamento paralelo para alterar o número de fragmentos](kinesis-record-processor-scaling.md).
### Exemplo: novas tentativas de consumidor gerando nova entrega de registros
Neste exemplo, há uma aplicação que lê continuamente registros de um fluxo, agrega registros em um arquivo local e faz upload do arquivo para o Amazon S3. Para simplificar, suponha que haja apenas 1 fragmento e 1 operador processando o fragmento. 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 fragmento, registros de 10.001 a 20.000.
1. O operador passa o lote de registros para o processador de registros associado.
1. O processador de registros agrega os dados, cria um arquivo do Amazon S3 e faz upload do arquivo para o Amazon S3 com êxito.
1. O operador é encerrado inesperadamente antes que ocorra um novo ponto de verificação.
1. O aplicativo, o operador e o processador de registros são reiniciados.
1. 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 novas tentativas 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, com o [Opensearch](https://www.opensearch.org/), você pode usar uma combinação de controle de versão e exclusividade IDs para evitar o processamento duplicado.
A aplicação de exemplo da seção anterior lê continuamente os registros de um fluxo, agrega os registros em um arquivo local e faz upload do arquivo para o Amazon S3. Conforme ilustrado, os registros de 10.001 a 20.000 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.
1. O nome do arquivo usa este esquema: prefixo do Amazon S3, shard-id e `First-Sequence-Num`. Neste caso, pode ser algo como `sample-shard000001-10001`.
1. Depois de fazer upload do arquivo do Amazon S3, defina o ponto de verificação especificando `Last-Sequence-Num`. Neste caso, o ponto de verificação seria definido no registro de número 15.000.
Com esse esquema, mesmo que os registros sejam 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 refragmentação, o número de registros deixados no fragmento pode ser menor que o número fixo necessário. Nesse caso, o método `shutdown()` precisa descarregar o arquivo no Amazon S3 e definir o ponto de verificação no último número de sequência. O esquema acima também é compatível com as operações de refragmentação.
# Tratamento do startup, do desligamento e do controle de utilização
Leia aqui algumas considerações adicionais para incorporar ao projeto da aplicação do Amazon Kinesis Data Streams.
**Topics**
+ [Inicializar produtores de dados e consumidores de dados](#kinesis-record-processor-producer-consumer-coordination)
+ [Encerre um aplicativo Amazon Kinesis Data Streams](#developing-consumers-with-kcl-shutdown)
+ [Controle de utilização de leitura](#kinesis-record-processor-read-throttling)
## Inicializar produtores de dados e consumidores de dados
Por padrão, a KCL começa a ler registros pela extremidade do fluxo, que é o registro adicionado mais recentemente. Nessa configuração, se um aplicativo de produção de dados adicionar registros ao fluxo antes da execução de qualquer processador de registros de recebimento, os registros não serão lidos pelos processadores de registros após a inicialização.
Para alterar o comportamento dos processadores de registros para que eles sempre leiam dados a partir do início do fluxo, defina o seguinte valor no arquivo de propriedades da aplicação do Amazon Kinesis Data Streams:
```
initialPositionInStream = TRIM_HORIZON
```
Por padrão, o Amazon Kinesis Data Streams armazena todos os dados por 24 horas. Ele também oferece suporte à retenção prolongada de até 7 dias e a retenção de longo prazo de até 365 dias. Esse período é chamado de *período de retenção*. Definir a posição de início como `TRIM_HORIZON` inicia o processador de registros com os dados mais antigos no fluxo, conforme definido pelo período de retenção. Mesmo com a definição de `TRIM_HORIZON`, se um processador de registros iniciar após decorrido um tempo maior que o período de retenção, alguns dos registros no fluxo não estarão mais disponíveis. Por esse motivo, você deve sempre ter aplicativos de consumo lendo o stream e usando a CloudWatch métrica `GetRecords.IteratorAgeMilliseconds` para monitorar se os aplicativos estão acompanhando os dados recebidos.
Em alguns cenários, pode ser adequado aos processadores de registros perder os primeiros registros no fluxo. Por exemplo, você pode executar alguns registros iniciais no stream para testar se o stream está funcionando end-to-end conforme o esperado. Depois de fazer essa verificação inicial, inicie seus operadores e comece a colocar os dados de produção no fluxo.
Para obter mais informações sobre a configuração de `TRIM_HORIZON`, consulte [Como usar iteradores de fragmentos](developing-consumers-with-sdk.md#kinesis-using-sdk-java-get-data-shard-iterators).
## Encerre um aplicativo Amazon Kinesis Data Streams
Quando a aplicação do Amazon Kinesis Data Streams tiver concluído a tarefa pretendida, é necessário desligá-la encerrando as instâncias do EC2 nas quais ela está em execução. É possível encerrar as instâncias usando o [Console de gerenciamento da AWS](https://console.aws.amazon.com//ec2/home) ou a [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/ec2/index.html).
Depois de desligar a aplicação do Amazon Kinesis Data Streams, deve-se excluir a tabela do Amazon DynamoDB que a KCL usou para rastrear o estado da aplicação.
## Controle de utilização de leitura
O throughput de um fluxo é provisionado no nível do fragmento. Cada fragmento tem um throughput de leitura de até cinco transações por segundo para leituras, até uma taxa máxima total de leitura de dados de 2 MB por segundo. Se uma aplicação (ou grupo de aplicações operando no mesmo fluxo) tentar obter dados de um fragmento a uma taxa mais rápida, o Kinesis Data Streams limitará as operações Get correspondentes.
Em uma aplicação do Amazon Kinesis Data Streams, se um processador de registros processar dados mais rapidamente do que o limite, como no caso de um failover, o controle de utilização ocorrerá. Como a KCL gerencia as interações entre a aplicação e o Kinesis Data Streams, as exceções de controle de utilização ocorrem no código da KCL, e não no código da aplicação. No entanto, como a KCL registra essas exceções, elas podem ser vistas nos logs.
Se acreditar que o aplicativo fica limitado de forma consistente, considere aumentar o número de fragmentos do fluxo.