Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Optimizar consumidores de Amazon Kinesis Data Streams.
Se puede optimizar incluso un poco más su consumidor de Amazon Kinesis Data Streams según el comportamiento específico que ve.
Revise los siguientes temas para identificar soluciones.
**Topics**
+ [
# Mejorar el procesamiento de baja latencia
](kinesis-low-latency.md)
+ [
# Procese datos serializados AWS Lambda con la biblioteca Amazon Kinesis Producer
](kinesis-record-deaggregation.md)
+ [
# Utilizar la nueva partición, el escalado y el procesamiento paralelo para cambiar el número de particiones
](kinesis-record-processor-scaling.md)
+ [
# Administrar registros duplicados
](kinesis-record-processor-duplicates.md)
+ [
# Administrar el startup, el shutdown y la limitación
](kinesis-record-processor-additional-considerations.md)
# Mejorar el procesamiento de baja latencia
El *retraso de propagación* se define como la end-to-end latencia desde el momento en que se escribe un registro en la transmisión hasta que lo lee una aplicación de consumo. Este retraso varía en función de una serie de factores, pero principalmente se ve afectado por el intervalo de sondeo de las aplicaciones consumidoras.
Para la mayoría de las aplicaciones, le recomendamos que se sondee cada fragmento una vez por segundo y aplicación. Esto le permite tener varias aplicaciones de consumo que procesen un flujo simultáneamente sin alcanzar los límites de Amazon Kinesis Data Streams de cinco llamadas `GetRecords` por segundo. Además, el procesamiento de lotes grandes de datos suele ser más eficaz en la reducción de la latencia de red y otras latencias descendentes en su aplicación.
Los valores predeterminados en KCL se establecen para seguir la práctica recomendada de sondear cada segundo. Este valor predeterminado tiene como consecuencia retrasos promedios en la propagación que normalmente están por debajo de 1 segundo.
Los registros de Kinesis Data Streams están disponibles para su lectura inmediatamente después de que se escriben. Existen algunos casos de uso en los que es necesario aprovecharse de este factor y requieren que se consuman los datos de la secuencia en cuanto estén disponibles. Puede reducir significativamente el retraso de propagación si anula la configuración predeterminada de KCL para sondear con mayor frecuencia, tal y como se muestra en los siguientes ejemplos.
Código de configuración de KCL en Java:
```
kinesisClientLibConfiguration = new
KinesisClientLibConfiguration(applicationName,
streamName,
credentialsProvider,
workerId).withInitialPositionInStream(initialPositionInStream).withIdleTimeBetweenReadsInMillis(250);
```
Configuración del archivo de propiedades para KCL en Python y Ruby:
```
idleTimeBetweenReadsInMillis = 250
```
**nota**
Dado que Kinesis Data Streams tiene un límite de cinco llamadas a `GetRecords` por segundo y por partición, si se establece en la propiedad `idleTimeBetweenReadsInMillis` un valor inferior a 200 ms puede ocurrir que la aplicación encuentre la excepción `ProvisionedThroughputExceededException`. Si se producen demasiadas de estas excepciones, pueden darse retrocesos exponenciales y, por lo tanto, causar latencias importantes e inesperadas en el procesamiento. Si configura esta propiedad para que sea de 200 ms o esté por encima de este valor y tiene más de una aplicación de procesamiento, experimentará una limitación controlada similar.
# Procese datos serializados AWS Lambda con la biblioteca Amazon Kinesis Producer
[Amazon Kinesis Producer Library](https://docs.aws.amazon.com/kinesis/latest/dev/developing-producers-with-kpl.html) (KPL) agrega pequeños registros formateados por el usuario en registros de mayor tamaño, hasta 1 MB, para utilizar mejor el rendimiento de Amazon Kinesis Data Streams. Si bien el KCL para Java admite la desagregación de estos registros, necesitará usar un módulo especial para desagregar los registros cuando lo utilice AWS Lambda como consumidor de sus transmisiones. Puede obtener el código de proyecto y las instrucciones necesarios GitHub en los módulos de [desagregación para Lambda de la biblioteca Amazon Kinesis Producer](https://github.com/awslabs/kinesis-deaggregation). AWS Los componentes de este proyecto le permiten procesar datos serializados de KPL en Java AWS Lambda, Node.js y Python. Estos componentes también se pueden utilizar como parte de una [aplicación KCL multilenguaje](https://github.com/awslabs/amazon-kinesis-client/blob/master/amazon-kinesis-client-multilang/src/main/java/software/amazon/kinesis/multilang/package-info.java).
# Utilizar la nueva partición, el escalado y el procesamiento paralelo para cambiar el número de particiones
Los *cambios en los fragmentos* le permiten aumentar o reducir el número de fragmentos en una secuencia para adaptarse a los cambios en la velocidad del flujo de datos en la secuencia. Los cambios en los fragmentos los suele realizar una aplicación administrativa que monitorea las métricas de administración de datos en los fragmentos. Aunque la propia KCL no inicia las operaciones de cambios en las particiones, está diseñada para adaptarse a los cambios en el número de particiones que resultan de las mismas.
Como se indica en [Usar una tabla de arrendamiento para realizar el seguimiento de las particiones procesadas por la aplicación de consumo de KCL](shared-throughput-kcl-consumers.md#shared-throughput-kcl-consumers-leasetable), KCL hace un seguimiento de las particiones en el flujo mediante una tabla de Amazon DynamoDB. Cuando se crean nuevas particiones como resultado de estos cambios, KCL descubre las nuevas particiones y rellena nuevas filas en la tabla. Los procesos de trabajo descubren automáticamente los nuevos fragmentos y crean procesadores para administrar los datos de los mismos. KCL también distribuye las particiones en el flujo, por todos los procesos de trabajo y procesadores de registros disponibles.
KCL garantiza que los datos existentes en particiones antes de que se produjeran cambios en los mismos se procesen primero. Después de que los datos se hayan procesado, los datos de los nuevos fragmentos se envían a los procesadores de registros. De esta forma, KCL conserva el orden en que los registros de datos se han agregado al flujo para una clave de partición en particular.
## Ejemplo: Cambio en las particiones, escalado y procesamiento paralelo
El siguiente ejemplo ilustra cómo KCL ayuda a administrar el escalado y los cambios en las particiones:
+ Por ejemplo, si su aplicación se ejecuta en una instancia de EC2 y está procesando un flujo de datos de Kinesis que tiene cuatro particiones. Esta instancia tiene un proceso de trabajo de KCL y cuatro procesadores de registros (un procesador de registros por partición). Estos cuatro procesadores de registros se ejecutan en paralelo en el mismo proceso.
+ A continuación, si escala la aplicación para utilizar otra instancia, tendrá dos instancias procesando una secuencia con cuatro fragmentos. Cuando el proceso de trabajo de KCL se inicia en la segunda instancia, realiza un equilibrio de la carga con la primera instancia, de modo que cada instancia ahora procesará dos particiones.
+ Si entonces decide dividir los cuatro fragmentos en cinco fragmentos. La nueva KCL vuelve a coordinar el procesamiento en las instancias: una instancia procesa tres particiones y la otra procesa dos particiones. Se produce una coordinación similar al fusionar fragmentos.
Normalmente, cuando utilice KCL, debe asegurarse de que el número de instancias no supere el número de particiones (excepto si quiere esperar a errores). Cada partición se procesa exactamente en un proceso de trabajo de KCL y tiene un procesador de registros correspondientes, por lo que no necesitará varias instancias para procesar una partición. Sin embargo, un proceso de trabajo puede procesar cualquier número de fragmentos, por lo que no hay problema si el número de fragmentos supera el número de instancias.
Para aumentar el procesamiento de su aplicación, debe probar una combinación de estos enfoques:
+ Aumentar el tamaño de la instancia (porque todos los procesadores de registros se ejecutan en paralelo dentro de un proceso)
+ Al aumentar el número de instancias hasta el número máximo de fragmentos abiertos (porque los fragmentos se pueden procesar de manera independiente)
+ Al aumentar el número de fragmentos (lo que aumenta el nivel de paralelismo)
Tenga en cuenta que puede utilizar Auto Scaling para escalar automáticamente las instancias en función de las métricas adecuadas. Para obtener más información, consulte la [Guía del usuario de Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/).
Cuando los cambios en los fragmentos aumentan el número de fragmentos en la secuencia, el aumento correspondiente en el número de procesadores de registros aumenta la carga de las instancias EC2 que los alojan. Si las instancias forman parte de un grupo de Auto Scaling y la carga aumenta lo suficiente, el grupo de Auto Scaling añade más instancias para administrar el aumento de la carga. Debe configurar las instancias para lanzar su aplicación de Amazon Kinesis Data Streams en el inicio, de forma que los procesos de trabajo y los procesadores de registros adicionales se activen en la nueva instancia de inmediato.
Para obtener más información acerca de los cambios en los fragmentos, consulte [Cambiar las particiones de un flujo](kinesis-using-sdk-java-resharding.md).
# Administrar registros duplicados
Hay dos principales motivos por los que se podrían entregar registros más de una vez en la aplicación de Amazon Kinesis Data Streams: los reintentos de los productores y de los consumidores. Su aplicación debe prever y administrar de forma adecuada el procesamiento de registros individuales varias veces.
## Reintentos en productores
Piense en un productor que experimenta un tiempo de inactividad relacionado con un problema en la red después de hacer una llamada a `PutRecord`, pero antes de que pueda recibir la confirmación desde Amazon Kinesis Data Streams. El productor no puede asegurar que se ha entregado el registro a Kinesis Data Streams. Suponiendo que cada registro es importante para la aplicación, el productor habría sido escrito para volver a intentar la llamada con los mismos datos. Si ambas llamadas a `PutRecord` sobre los mismos datos se enviaron correctamente a Kinesis Data Streams, habrá dos registros de Kinesis Data Streams. Aunque los dos registros tendrán datos idénticos, también tendrán números secuenciales únicos. Las aplicaciones que necesitan garantías estrictas deben tener incrustada una clave maestra en el registro para eliminar los duplicados en etapas posteriores del procesamiento. Tenga en cuenta que el número de duplicados debidos a reintentos del productor suele ser bajo en comparación con el número de duplicados debidos a reintentos del consumidor.
**nota**
Si utilizas el AWS SDK`PutRecord`, consulta el [comportamiento de los reintentos](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) del SDK en la guía del usuario de *AWS SDKs and Tools*.
## Reintentos en consumidores
Los reintentos en los consumidores (aplicaciones de procesamiento de datos) ocurren cuando se reinician los procesadores de registros. Los procesadores de registros para un mismo fragmento se reinician en los siguientes casos:
1. Si un proceso de trabajo termina de forma inesperada
1. Si las instancias de los procesos de trabajo se agregan o eliminan
1. Si se fusionan o dividen fragmentos
1. Si se implementa la aplicación
En todos estos casos, el mapeo del shards-to-worker-to procesador de registros se actualiza continuamente para equilibrar la carga del procesamiento. Los procesadores de fragmentos que se migraron a otras instancias reinician el procesamiento de registros a partir del último punto de comprobación. Esto se traduce en un procesamiento de registros duplicado, tal y como se muestra en el ejemplo siguiente. Para obtener más información sobre el balanceo de carga, consulte [Utilizar la nueva partición, el escalado y el procesamiento paralelo para cambiar el número de particiones](kinesis-record-processor-scaling.md).
### Ejemplo: Reintentos en consumidores que dan como resultado la entrega de registros
En este ejemplo tiene una aplicación que lee continuamente los registros de un flujo, agrega registros en un archivo local y carga el archivo en Amazon S3. Para simplificar, supongamos que solo hay 1 fragmento y un proceso de trabajo que lo procesa. Fíjese en el siguiente ejemplo de secuencia de eventos, suponiendo que el último punto de comprobación se realizó en el número de registro 10 000:
1. Un proceso de trabajo lee el siguiente lote de registros del fragmento, los registros de 10 001 a 20 000.
1. A continuación, el proceso de trabajo transmite el lote de registros al procesador de registros asociado.
1. El procesador de registros agrega los datos, crea un archivo de Amazon S3 y carga el archivo a Amazon S3 correctamente.
1. El proceso de trabajo se cierra de forma inesperada antes de que pueda crearse un nuevo punto de comprobación.
1. La aplicación, el proceso de trabajo y el procesador de registros se reinician.
1. A partir de ahora, el proceso de trabajo comienza a leer desde el último punto de comprobación correcto, en este caso el 10 001.
Por lo tanto, los registros 10 001-20 000 se consumen más de una vez.
### Resistencia a los reintentos en consumidores
Aunque puede que los registros se procesen más de una vez, la aplicación podría presentar los efectos adversos como si los registros se hubieran procesado solo una vez (procesamiento idempotente). Las soluciones a este problema varían en cuanto a su complejidad y precisión. Si el destino final de los datos puede administrar bien los duplicados, le recomendamos que deje que dicho destino final se encargue del procesamiento idempotente. Por ejemplo, con [Opensearch](https://www.opensearch.org/) puedes usar una combinación de control de versiones y exclusivo IDs para evitar el procesamiento duplicado.
En el ejemplo de la aplicación de la sección anterior, lee continuamente los registros de un flujo, agrega los registros en un archivo local y carga el archivo en Amazon S3. Como se ha indicado, los registros 10 001-20 000 se consumen más de una vez, lo que da como resultado que haya varios archivos en Amazon S3 con los mismos datos. Una forma de mitigar los duplicados en este ejemplo consiste en garantizar que en el paso 3 se utilice el siguiente esquema:
1. El procesador de registros utiliza un número fijo de registros por archivo de Amazon S3; por ejemplo, 5000.
1. El nombre de archivo utiliza este esquema: prefijo de Amazon S3, ID de partición y `First-Sequence-Num`. En este caso, podría ser algo parecido a `sample-shard000001-10001`.
1. Después de cargar el archivo de Amazon S3, cree un punto de verificación especificando `Last-Sequence-Num`. En este caso, debería establecer puntos de comprobación en el número de registro 15 000.
Con este esquema, incluso si los registros se procesan más de una vez, el archivo de Amazon S3 resultante tendrá el mismo nombre y los mismos datos. Los reintentos solo dan como resultado la escritura de los mismos datos en el mismo archivo más de una vez.
En el caso de una operación de cambio en los fragmentos, el número de registros que quedan en el fragmento podría ser menor que el número fijo necesario. En este caso, el método `shutdown()` tiene que volcar el archivo a Amazon S3 y establecer puntos de verificación en el último número secuencial. El esquema anterior también es compatible con las operaciones de cambios en los fragmentos.
# Administrar el startup, el shutdown y la limitación
A continuación, se muestran otras consideraciones que podría incorporar en el diseño de su aplicación de Amazon Kinesis Data Streams.
**Topics**
+ [
## Productores de datos de startup y consumidores de datos
](#kinesis-record-processor-producer-consumer-coordination)
+ [
## Cerrar una aplicación de Amazon Kinesis Data Streams
](#developing-consumers-with-kcl-shutdown)
+ [
## Limitación de lectura
](#kinesis-record-processor-read-throttling)
## Productores de datos de startup y consumidores de datos
De forma predeterminada, KCL comienza a leer registros desde el extremo del flujo, que es el registro agregado más recientemente. Con esta configuración, si una aplicación productora de datos agrega registros a la secuencia antes de que se ejecuten los procesadores de registros receptores, los procesadores de registros no podrán leer los registros tras el inicio.
Para cambiar el comportamiento de los procesadores de registros de forma que siempre lean los datos desde el inicio del flujo, defina el siguiente valor en el archivo de propiedades de su aplicación de Amazon Kinesis Data Streams:
```
initialPositionInStream = TRIM_HORIZON
```
De forma predeterminada, Amazon Kinesis Data Streams almacena todos los datos durante 24 horas. También admite la retención prolongada de hasta 7 días y la retención a largo plazo de hasta 365 días. Este periodo de tiempo se denomina el *periodo de retención*. Si se establece la posición inicial en `TRIM_HORIZON`, el procesador de registros se iniciará con los datos más antiguos de la secuencia, según defina el periodo de retención. Incluso con la configuración `TRIM_HORIZON`, si un procesador de registros se iniciara tras transcurrir mucho más tiempo del que determina el periodo de retención, algunos de los registros de la secuencia dejarán de estar disponibles. Por este motivo, siempre debes hacer que las aplicaciones de consumo lean de la transmisión y usar la CloudWatch métrica `GetRecords.IteratorAgeMilliseconds` para controlar que las aplicaciones estén al día con los datos entrantes.
En algunos casos, puede ser una buena opción para los procesadores de registros omitir los primeros registros de la secuencia. Por ejemplo, puede ejecutar algunos registros iniciales en la transmisión para comprobar que la transmisión funciona end-to-end según lo esperado. Tras realizar la verificación inicial, a continuación iniciaría sus procesos de trabajo y empezaría a introducir datos de producción en la secuencia.
Para obtener más información acerca de la opción `TRIM_HORIZON`, consulte [Usar iteradores de particiones](developing-consumers-with-sdk.md#kinesis-using-sdk-java-get-data-shard-iterators).
## Cerrar una aplicación de Amazon Kinesis Data Streams
Cuando su aplicación de Amazon Kinesis Data Streams haya completado la tarea correspondiente, debe cerrar mediante la terminación de las instancias de EC2 en las que se está ejecutando. Puede terminar las instancias usando la [Consola de administración de AWS](https://console.aws.amazon.com//ec2/home) o la [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/ec2/index.html).
Después de cerrar la aplicación de Amazon Kinesis Data Streams, debe eliminar la tabla de Amazon DynamoDB que utilizó KCL para realizar un seguimiento del estado de la aplicación.
## Limitación de lectura
El rendimiento de una secuencia se facilita en el nivel del fragmento. Cada partición tiene un rendimiento de lectura de hasta cinco transacciones por segundo, con una velocidad máxima total de lectura de datos de 2 MB por segundo. Si una aplicación (o grupo de aplicaciones que operan en el mismo flujo) intenta obtener datos de una partición a una velocidad superior, Kinesis Data Streams limita las operaciones Get correspondientes.
En una aplicación de Amazon Kinesis Data Streams, si un procesador de registros procesa datos más rápido que el límite (por ejemplo, en el caso de una conmutación por error), se produce una limitación. Dado que KCL administra las interacciones entre la aplicación y Kinesis Data Streams, las excepciones por limitación se producen en el código de KCL y no en el código de la aplicación. No obstante, puesto que KCL registra estas excepciones, las verá en los registros.
Si cree que su aplicación es objeto de una limitación controlada de forma constante, debería pensar en aumentar el número de fragmentos para la secuencia.