Prácticas recomendadas

Configure CloudWatch las alarmas de Amazon: puede utilizar las CloudWatch métricas que proporciona Kinesis Data Analytics para supervisar lo siguiente:

Le recomendamos que configure al menos dos CloudWatch alarmas en las siguientes métricas para sus aplicaciones en producción:

Para evitar la excepción ReadProvisionedThroughputException, limite la cantidad de aplicaciones de producción que leen de un mismo flujo de datos de Kinesis a dos aplicaciones.

Amazon Kinesis Data Analytics lee un origen de streaming aproximadamente una vez por segundo por aplicación. Sin embargo, una aplicación que cae detrás podría leer datos más rápidamente para ponerse al corriente. Para permitir el rendimiento suficiente para que las aplicaciones se pongan al corriente, limite la cantidad de aplicaciones que leen el mismo origen de datos.

Limite la cantidad de aplicaciones de producción que leen de un mismo flujo de entrega de Firehose a una aplicación.

Un flujo de entrega de Firehose puede escribir en destinos como Amazon S3 y Amazon Redshift. También puede ser un origen de streaming para su aplicación de . Por lo tanto, le recomendamos que no configure más de una aplicación de Kinesis Data Analytics por flujo de entrega de Firehose. Esto ayuda a garantizar que la secuencia de entrega también se pueda entregar a otros destinos.

Utilice varias secuencias e instancias de aplicaciones de Kinesis Data Analytics para SQL si su aplicación tiene necesidades de escalado superiores a 100 MB/segundo.

Utilice Managed Service para Apache Flink Applications si desea utilizar un solo flujo y una sola aplicación.

El rendimiento máximo que recomendamos para una sola secuencia en la aplicación es de entre 2 y 20 MB/segundo, dependiendo de la complejidad de la consulta de la aplicación.

El rendimiento máximo de flujo que puede procesar una sola aplicación de Kinesis Data Analytics para SQL es de aproximadamente 100 MB/seg. Esto supone que ha aumentado el número de flujos en la aplicación hasta un valor máximo de 64 y que ha aumentado su límite de KPU más allá de 8. Para obtener más información, consulte Límites.

Pruebe el esquema inferido cuanto sea necesario. El proceso de detección solo utiliza una muestra de registros en el origen de streaming para inferir en un esquema. Si el origen de streaming tiene muchos tipos de registro, la API de detección podría no haber atendido uno o varios tipos de registro. Esta situación puede dar lugar a un esquema que no refleja los datos sobre el origen de streaming de manera precisa.

Cuando se inicia la aplicación, estos tipos de registro perdidos podrían dar lugar a errores de análisis. Amazon Kinesis Data Analytics envía estos registros a la secuencia de errores en la aplicación. Para reducir estos errores de análisis, le recomendamos que pruebe el esquema inferido de forma interactiva en la consola y monitoree la secuencia en la aplicación para registros no atendidos.

La API de Kinesis Data Analytics no permite especificar la restricción de NOT NULL en columnas en la configuración de entrada. Si desea restricciones NOT NULL en columnas en su secuencia en la aplicación, cree estas secuencias en la aplicación utilizando el código de su aplicación. A continuación, puede copiar los datos de una secuencia en la aplicación en otra y, luego, se aplica la restricción.

Todo intento de insertar filas con valores NULL cuando se requiere un valor, da lugar a un error. Kinesis Data Analytics envía estos errores a la secuencia de errores en la aplicación.

Relaje los tipos de datos inferidos por el proceso de detección. El proceso de detección recomienda columnas y tipos de datos basados en una muestra aleatoria de registros en el origen de streaming. Le recomendamos que los revise detenidamente y considere flexibilizar estos tipos de datos para cubrir todos los posibles casos de registros en la entrada. Esto garantiza menos errores de análisis a través de la aplicación mientras se está ejecutando. Por ejemplo, si un esquema inferido tiene un SMALLINT como tipo de columna, plantéese cambiarlo a INTEGER.

Utilice las funciones de SQL en el código de su aplicación para administrar los datos o las columnas que no tienen estructura. Es posible que haya datos columnas que no tengan estructura, como datos de registro, en la entrada. Para ver ejemplos, consulta Ejemplo: transformación DateTime de valores. Un enfoque de la gestión de este tipo de datos para definir el esquema con una sola columna del tipo VARCHAR(N), donde N es la fila más alta posible que esperaría ver en su secuencia. En el código de aplicación puede leer los registros de entrada y utilizar las funciones String y Date Time para analizar y esquematizar los datos sin procesar.

Asegúrese de gestionar completamente los datos de origen de streaming que contengan anidaciones de más de dos niveles de profundidad. Cuando los datos de origen son JSON, puede realizar el anidamiento. La API de detección infiere un esquema que aplana un nivel de anidamiento. Para dos niveles del anidamiento, la API de detección también intenta aplanarlos. Además de dos niveles del anidamiento, no hay soporte limitado para aplanamiento. Para gestionar las anidaciones por completo, tiene que modificar el esquema inferido manualmente para adaptarlo a sus necesidades. Utilice una de las siguientes estrategias para hacerlo:

Utilice el primer destino para insertar los resultados de sus consultas SQL.

Utilice el segundo destino para insertar todo el flujo de error y enviarlo a un bucket de S3 a través de un flujo de entrega de Firehose.

En la instrucción SQL, no especifique una ventana basada en tiempo que sea superior a una hora por las siguientes razones:

Durante el desarrollo, mantenga el tamaño de la ventana pequeño en sus instrucciones SQL para poder ver los resultados con mayor rapidez. Al implementar la aplicación en su entorno de producción, puede establecer el tamaño de la ventana, según corresponda.

En lugar de una única instrucción SQL compleja, plantéese dividirla en varias y guardar los resultados de cada paso en secuencias en la aplicación intermedias. Esto puede ayudarle a realizar la depuración con mayor rapidez.

Cuando se utilizan ventanas de saltos de tamaño constante, le recomendamos que utilice dos ventanas: una para el tiempo de procesamiento y otra para el tiempo lógico (tiempo de ingestión o de evento). Para obtener más información, consulte Marcas temporales y la comuna ROWTIME.

Utilice el Kinesis Data Generator (KDG). El KDG utiliza una plantilla de datos para enviar datos aleatorios a una secuencia de Kinesis. El KDG es fácil de utilizar, pero no es adecuado para probar relaciones complejas entre elementos de datos como, por ejemplo, para aplicaciones que detectan puntos calientes de datos o anomalías.

Utilice una aplicación Python personalizada para enviar los datos más complejos a un flujo de datos de . Una aplicación Python puede generar relaciones complejas entre elementos de datos, como, por ejemplo, puntos calientes o anomalías. Para ver un ejemplo de una aplicación Python que envía datos agrupados en un punto caliente de datos, consulte Ejemplo: Detección de puntos calientes en una secuencia (función HOTSPOSTS).

Los datos de su secuencia se están convirtiendo al tipo de datos correcto. Por ejemplo, asegúrese de que los datos de fecha y hora no se introduzcan en la aplicación como cadena.

Los datos se están analizando y se convierten al tipo de datos que desea. Si se producen errores de introducción o conversión, puede verlos en la consola o asignar un destino a la secuencia de error y ver los errores en el almacén de destino.

Los campos de datos para los datos de caracteres tienen la longitud suficiente y la aplicación no trunca los datos de caracteres. Puede comprobar los registros de datos en su almacén de destino para comprobar que los datos de la aplicación no se truncan.