Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Ottimizza i consumatori di Amazon Kinesis Data Streams
Puoi ottimizzare ulteriormente il tuo consumatore Amazon Kinesis Data Streams in base al comportamento specifico che vedi.
Consulta i seguenti argomenti per identificare le soluzioni.
**Topics**
+ [Migliora l'elaborazione a bassa latenza](kinesis-low-latency.md)
+ [Elabora dati serializzati utilizzando AWS Lambda Amazon Kinesis Producer Library](kinesis-record-deaggregation.md)
+ [Usa il resharding, lo scaling e l'elaborazione parallela per modificare il numero di shard](kinesis-record-processor-scaling.md)
+ [Gestire i record duplicati](kinesis-record-processor-duplicates.md)
+ [Gestisci l'avvio, lo spegnimento e la limitazione](kinesis-record-processor-additional-considerations.md)
# Migliora l'elaborazione a bassa latenza
Il *ritardo di propagazione* è definito come la end-to-end latenza dal momento in cui un record viene scritto nello stream fino a quando non viene letto da un'applicazione consumer. Il ritardo varia in base a una serie di fattori, ma è interessato principalmente dall'intervallo di polling delle applicazioni di consumo.
Per la maggior parte delle applicazioni, ti consigliamo di eseguire il polling di ogni shard una volta al secondo per applicazione. In questo modo è possibile avere più applicazioni di consumo che elaborano un flusso simultaneamente senza considerare Flusso di dati Amazon Kinesis, senza raggiungere i limiti di 5 chiamate `GetRecords` al secondo. Inoltre, l'elaborazione di batch di dati di dimensioni maggiori tende a essere più efficiente nel ridurre la rete e altre latenze downstream nella tua applicazione.
I valori predefiniti della KCL sono impostati per seguire la best practice di eseguire il polling ogni secondo. Questi valori predefiniti comportano ritardi di propagazione medi che generalmente sono inferiori a 1 secondo.
I record del flusso di dati Kinesis sono disponibili per essere letti subito dopo essere stati scritti. Ci sono alcuni casi d'uso in cui è necessario sfruttare questo vantaggio e in cui è richiesto il consumo dei dati dal flusso non appena disponibili. È possibile ridurre in modo significativo il ritardo di propagazione sostituendo le impostazioni di default della KCL più di frequente, come mostrato nei seguenti esempi.
Codice di configurazione della KCL in Java:
```
kinesisClientLibConfiguration = new
KinesisClientLibConfiguration(applicationName,
streamName,
credentialsProvider,
workerId).withInitialPositionInStream(initialPositionInStream).withIdleTimeBetweenReadsInMillis(250);
```
Impostazione di file delle proprietà per la KCL in Python e Ruby:
```
idleTimeBetweenReadsInMillis = 250
```
**Nota**
Dato che il flusso di dati Kinesis ha un limite di 5 chiamate `GetRecords` al secondo, per partizione, l'impostazione della proprietà `idleTimeBetweenReadsInMillis` con un valore inferiore ai 200 millisecondi può comportare che la tua applicazione osservi l'eccezione `ProvisionedThroughputExceededException`. Un numero eccessivo di queste eccezioni può comportare backoff esponenziali e, pertanto, può causare latenze impreviste e significative nell'elaborazione. Se si imposta questa proprietà in modo tale che il valore sia pari o appena superiore a 200 millisecondi e da avere più di un'applicazione di elaborazione, noterai un throttling simile.
# Elabora dati serializzati utilizzando AWS Lambda Amazon Kinesis Producer Library
[Amazon Kinesis Producer Library](https://docs.aws.amazon.com/kinesis/latest/dev/developing-producers-with-kpl.html) (KPL) aggrega piccoli record formattati dall'utente in record più grandi fino a 1 MB per utilizzare meglio il throughput di Amazon Kinesis Data Streams. Sebbene KCL per Java supporti la disaggregazione di questi record, è necessario utilizzare un modulo speciale per disaggregare i record quando si utilizza come consumatore dei propri stream. AWS Lambda Puoi ottenere il codice di progetto e le istruzioni necessari da GitHub [Amazon Kinesis Producer Library Deaggregation Modules](https://github.com/awslabs/kinesis-deaggregation) for Lambda. AWS I componenti di questo progetto ti danno la possibilità di elaborare dati serializzati KPL all'interno AWS Lambda, in Java, Node.js e Python. Questi componenti possono anche essere utilizzati come parte di un'[applicazione KCL multilingue](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client-multilang/src/main/java/software/amazon/kinesis/multilang/package-info.java).
# Usa il resharding, lo scaling e l'elaborazione parallela per modificare il numero di shard
Il *resharding* ti consente di aumentare o diminuire il numero di shard in un flusso in modo da adattarsi alle variazioni di velocità nella circolazione di dati nel flusso. In genere il resharding viene eseguito da un'applicazione amministrativa che monitora i parametri di gestione di dati negli shard. Sebbene la KCL stessa non avvii le operazioni di ripartizionamento, è progettata per adattarsi alle variazioni nel numero di partizioni causate dal ripartizionamento.
Come indicato in [Utilizza una tabella di leasing per tenere traccia degli shard elaborati dall'applicazione consumer KCL](shared-throughput-kcl-consumers.md#shared-throughput-kcl-consumers-leasetable), la KCL monitora le partizioni nel flusso utilizzando una tabella di Amazon DynamoDB. Quando nuove partizioni vengono create come risultato del ripartizionamento, la KCL rileva le nuove partizioni e completa le nuove righe nella tabella. I lavoratori trovano automaticamente i nuovi shard e creano processori per gestire i dati provenienti da questi shard. Anche la KCL distribuisce le partizioni nel flusso tra tutti i worker e i processori di record disponibili.
La KCL garantisce che i dati esistenti nelle partizioni prima del ripartizionamento vengano elaborati per primi. Dopo che i dati sono stati elaborati, i dati dal nuovo shard vengono inviati a processori di record. In questo modo, la KCL conserva l'ordine in cui i record di dati sono stati aggiunti al flusso per una determinata chiave di partizione.
## Esempio: ripartizione, scalabilità ed elaborazione parallela
L'esempio seguente spiega come la KCL ti aiuta a gestire il dimensionamento e il ripartizionamento:
+ Ad esempio, se la tua applicazione è in esecuzione in un'istanza EC2 e sta elaborando un flusso di dati Kinesis con quattro partizioni. Questa istanza dispone di un worker della KCL e di quattro processori di record (un processore di record per ogni partizione). Questi quattro processori di record sono eseguiti in parallelo all'interno dello stesso processo.
+ Di seguito, se si dimensiona l'applicazione per utilizzare un'altra istanza, si avranno due istanze per l'elaborazione di un flusso con quattro shard. Quando il worker della KCL si avvia nella seconda istanza, esegue un bilanciamento del carico con la prima istanza in modo che ogni istanza sia in grado di elaborare due partizioni.
+ Se si decide di frazionare i quattro shard in cinque shard. La KCL coordina nuovamente l'elaborazione su più istanze; un'istanza elabora tre partizioni, mentre l'altra istanza elabora due partizioni. Un coordinamento simile si verifica quando si fondono shard.
Di solito, quando si utilizza la KCL, è necessario accertarsi che il numero di istanze non superi il numero di partizioni (tranne nel caso in cui si desideri rimanere in attesa di errori) Ogni partizione viene elaborata da esattamente un worker della KCL e ha esattamente un processore di record corrispondente, pertanto non sono mai necessarie istanze multiple per elaborare una partizione. Tuttavia, un lavoratore è in grado di elaborare qualsiasi numero di shard, pertanto non è un problema se il numero di shard supera il numero di istanze.
Per aumentare l'elaborazione nella tua applicazione, è consigliabile testare una combinazione dei seguenti approcci:
+ Aumentare la dimensione dell'istanza (dato che tutti i processori di record sono eseguiti in parallelo all'interno di un processo)
+ Aumentare il numero di istanze fino al numero massimo di shard aperti (dato che gli shard possono essere elaborati in modo indipendente)
+ Aumentare il numero di shard (aumentando di conseguenza il livello di parallelismo)
Si noti che è possibile utilizzare il dimensionamento automatico per dimensionare automaticamente le istanze in base ai parametri appropriati. Per ulteriori informazioni, consulta [Guida per l’utente di Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/).
Quando il resharding aumenta il numero di shard nel flusso, il corrispondente aumento nel numero di processori di record aumenta il carico sulle istanze EC2 che li ospitano. Se le istanze fanno parte di un gruppo Auto Scaling e il carico aumenta a sufficienza, il gruppo Auto Scaling aggiunge più istanze per gestire l'aumento del carico. È necessario configurare le istanze per avviare la tua applicazione del flusso di dati Amazon Kinesis all'avvio, in modo che i worker e i processori di record aggiuntivi diventino immediatamente attivi nella nuova istanza.
Per ulteriori informazioni sul resharding, consulta [Condividi nuovamente uno stream](kinesis-using-sdk-java-resharding.md).
# Gestire i record duplicati
Ci sono due motivi principali per cui i record possono essere distribuiti più di una volta alla tua applicazione del flusso di dati Amazon Kinesis: i nuovi tentativi del producer e i nuovi tentativi del consumer. La tua applicazione deve prevedere e gestire in modo appropriato l'elaborazione di singoli record più volte.
## Il produttore riprova
Considera un producer in cui si verifica un timeout della rete dopo una chiamata a `PutRecord`, ma prima di poter ricevere una conferma da Flusso di dati Amazon Kinesis . Il producer non può essere certo se il record è stato distribuito a . Considerando che ogni record è importante per l'applicazione, il producer sarebbe stato scritto per riprovare la chiamata con gli stessi dati. Se entrambe le chiamate a `PutRecord` sugli stessi dati sono state inviate correttamente al flusso di dati Kinesis saranno presenti due record del flusso di dati Kinesis. Anche se i due record dispongono di dati identici, hanno anche numeri di sequenza univoci. Le applicazioni che richiedono garanzie rigorose devono incorporare una chiave primaria nel record per rimuovere i duplicati più avanti nel corso dell'elaborazione. Si noti che il numero di duplicati dovuti a nuovi tentativi del producer è solitamente basso rispetto al numero di duplicati dovuti a nuovi tentativi del consumer.
**Nota**
Se utilizzi l' AWS SDK`PutRecord`, scopri il [comportamento di SDK Retry](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) nella guida per l'utente di *AWS SDKs and* Tools.
## Ritentativi dei consumatori
I nuovi tentativi del consumer (applicazione di elaborazione dei dati) si verificano quando si riavviano i processori di record. I processori di record per lo stesso shard vengono riavviati nei seguenti casi:
1. Il lavoratore viene terminato in modo inaspettato
1. Le istanze del lavoratore vengono aggiunte o rimosse
1. Gli shard sono fusi o frazionati
1. L'applicazione viene distribuita
In tutti questi casi, la mappatura shards-to-worker-to -record-processor viene continuamente aggiornata per l'elaborazione del bilanciamento del carico. I processori di shard migrati ad altre istanze riavviano l'elaborazione di record dall'ultimo checkpoint. Ciò comporta un'elaborazione di record duplicati, come illustrato nell'esempio seguente. Per ulteriori informazioni sul bilanciamento del carico, consulta [Usa il resharding, lo scaling e l'elaborazione parallela per modificare il numero di shard](kinesis-record-processor-scaling.md).
### Esempio: un cliente riprova con conseguente riconsegna dei record
In questo esempio, si dispone di un'applicazione che legge i record da un flusso in modo continuo, aggrega i record in un file locale e carica il file in Amazon S3. Per semplicità, supponiamo di avere solo uno shard e un lavoratore che elabora lo shard. Considera il seguente esempio di sequenza di eventi, supponendo che l'ultimo checkpoint si è verificato al numero di record 10.000:
1. Un lavoratore legge il batch successivo di record dallo shard, i record da 10.001 a 20.000.
1. Di seguito, il lavoratore trasferisce il batch di record al processore di record associato.
1. Il processore di record aggrega i dati, crea un file Amazon S3 e carica correttamente il file in Amazon S3.
1. Il lavoratore viene terminato in modo inaspettato prima che possa verificarsi un nuovo checkpoint.
1. La applicazione, il lavoratore e il processore di record si riavviano.
1. A partire da questo momento, il lavoratore comincia a leggere dall'ultimo checkpoint eseguito correttamente, in questo caso 10.001.
Pertanto, i record 10.001-20.000 vengono consumati più di una volta.
### Essere resilienti ai tentativi dei consumatori
Anche se è possibile che i record siano elaborati più di una volta, l'applicazione potrebbe voler presentare gli effetti collaterali come se i record fossero stati elaborati solo una volta (elaborazione idempotente). Le soluzioni a questo problema variano in complessità e accuratezza. Se la destinazione dei dati finali è in grado di gestire correttamente i duplicati, ti consigliamo di affidarti alla destinazione finale per ottenere l'elaborazione idempotente. Ad esempio, con [Opensearch](https://www.opensearch.org/) è possibile utilizzare una combinazione di controllo delle versioni e univoche IDs per evitare elaborazioni duplicate.
Nell'applicazione di esempio nella sezione precedente, l'applicazione legge in modo continuo i record da un flusso, aggrega i record in un file locale e carica il file in Amazon S3. Come indicato, i record da 10.001 a 20.000 vengono consumati più di una volta e ciò comporta la presenza di più file Amazon S3 con gli stessi dati. Un modo per mitigare i duplicati in questo esempio è di assicurarsi che nella fase 3 sia utilizzato il seguente schema:
1. Il processore di record utilizza un numero fisso di record per file Amazon S3, ad esempio 5.000.
1. Il nome di file utilizza questo schema: prefisso di Amazon S3, ID della partizione e `First-Sequence-Num`. In questo caso, potrebbe essere qualcosa di simile a `sample-shard000001-10001`.
1. Una volta caricato il file Amazon S3, crea un checkpoint specificando `Last-Sequence-Num`. In questo caso, il checkpoint verrebbe eseguito al numero di record 15.000.
Con questo schema, anche se i record vengono elaborati più di una volta, il file Amazon S3 risultante ha lo stesso nome e gli stessi dati. I nuovi tentativi hanno come risultato esclusivamente la scrittura degli stessi dati nello stesso file più di una volta.
Nel caso di un'operazione di reshard, il numero di record rimasti nello shard potrebbe essere inferiore al numero fisso desiderato. In questo caso, il tuo metodo `shutdown()` deve scaricare il file ad Amazon S3 ed eseguire il checkpoint nell'ultimo numero di sequenza. Il suddetto schema è compatibile anche con le operazioni di reshard.
# Gestisci l'avvio, lo spegnimento e la limitazione
Di seguito sono elencate alcune considerazioni aggiuntive da integrare nella progettazione della tua applicazione del flusso di dati Amazon Kinesis.
**Topics**
+ [Avvia produttori e consumatori di dati](#kinesis-record-processor-producer-consumer-coordination)
+ [Chiudi un'applicazione Amazon Kinesis Data Streams](#developing-consumers-with-kcl-shutdown)
+ [Limitazione della lettura](#kinesis-record-processor-read-throttling)
## Avvia produttori e consumatori di dati
Per impostazione predefinita, la KCL inizia a leggere i record dall'estremità del flusso, che è il record aggiunto più di recente. In questa configurazione, se un'applicazione produttrice di dati aggiunge record al flusso prima che i processori di record riceventi siano in esecuzione, i record non vengono letti dai processori di record dopo l'avvio.
Per modificare il comportamento dei processori di record in modo che leggano sempre i dati dall'inizio del flusso, imposta il seguente valore nel file proprietà per la tua applicazione del flusso di dati Amazon Kinesis:
```
initialPositionInStream = TRIM_HORIZON
```
Per impostazione predefinita, Flusso di dati Amazon Kinesis archivia tutti i dati per 24 ore. Supporta inoltre la conservazione prolungata fino a 7 giorni e la conservazione a lungo termine fino a 365 giorni. Questo intervallo di tempo viene chiamato il *periodo di conservazione*. Se si imposta la posizione iniziale in `TRIM_HORIZON` il processore di record verrà avviato con i dati meno recenti nel flusso, secondo quanto definito dal periodo di conservazione. Anche con l'impostazione `TRIM_HORIZON`, qualora un processore di record venisse avviato dopo che è trascorso un intervallo di tempo maggiore rispetto al periodo di conversazione alcuni record nel flusso non sarebbero più disponibili. Per questo motivo, dovreste sempre far sì che le applicazioni consumer leggano lo stream e utilizzino la CloudWatch metrica `GetRecords.IteratorAgeMilliseconds` per monitorare che le applicazioni stiano tenendo il passo con i dati in entrata.
In alcuni scenari, perdere i primi record nel flusso potrebbe essere una buona opzione per i processori di record. Ad esempio, potreste eseguire alcuni record iniziali attraverso lo stream per verificare che lo stream funzioni end-to-end come previsto. Dopo avere eseguito questa verifica iniziale, avvieresti i tuoi lavoratori e cominceresti a integrare i dati di produzione nel flusso.
Per ulteriori informazioni sull'impostazione `TRIM_HORIZON`, consulta [Usa gli iteratori shard](developing-consumers-with-sdk.md#kinesis-using-sdk-java-get-data-shard-iterators).
## Chiudi un'applicazione Amazon Kinesis Data Streams
Quando la tua applicazione del flusso di dati Amazon Kinesis ha completato l'attività prevista, è consigliabile eseguirne l'arresto terminando le istanze EC2 in cui è in esecuzione. Puoi terminare le istanze utilizzando la [Console di gestione AWS](https://console.aws.amazon.com//ec2/home) o la [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/ec2/index.html).
Dopo aver eseguito l'arresto della tua applicazione del flusso di dati Amazon Kinesis, è necessario eliminare la tabella Amazon DynamoDB che la KCL ha utilizzato per monitorare lo stato dell'applicazione.
## Limitazione della lettura
Il throughput di un flusso viene assegnato a livello di shard. Ogni partizione ha una velocità di trasmissione effettiva di lettura fino a 5 transazioni al secondo, fino a una velocità di lettura totale massima di 2 MB al secondo. Se un'applicazione (o un gruppo di applicazioni che operano nello stesso flusso) prova a ottenere i dati da una partizione una velocità superiore, il flusso di dati Kinesis applica la limitazione delle operazioni Get corrispondenti.
In un'applicazione del flusso di dati Amazon Kinesis, se un processore di record sta elaborando dati più rapidamente rispetto al limite, ad esempio nel caso di un failover, si verifica una limitazione. Dato che KCL gestisce le interazioni tra l'applicazione e il flusso di dati Kinesis, si verificano eccezioni di limitazione nel codice della KCL anziché nel codice dell'applicazione. Tuttavia, dato che la KCL registra queste eccezioni, è possibile vederle nei log.
Se ritieni che la tua applicazione sia sottoposta a throttling in modo costante, è consigliabile considerare un aumento del numero di shard per il flusso.