Ingesta de streaming

La ingesta de streaming proporciona una ingesta de alta velocidad y baja latencia de datos de flujos de Amazon Kinesis Data Streams y Amazon Managed Streaming para Apache Kafka en una vista materializada de Amazon Redshift aprovisionado o Amazon Redshift sin servidor. Disminuye el tiempo que se tarda en acceder a los datos y reduce el costo de almacenamiento. Puede configurar la ingesta de streaming para su clúster de Amazon Redshift o para Amazon Redshift sin servidor y crear una vista materializada mediante instrucciones SQL, como se describe en Creación de vistas materializadas en Amazon Redshift. Después de eso, mediante la actualización de la vista materializada, puede ingerir cientos de megabytes de datos por segundo. Eso da como resultado un acceso rápido a datos externos que se actualizan rápidamente.

Flujo de datos

Un clúster aprovisionado de Amazon Redshift o un grupo de trabajo de Amazon Redshift sin servidor es el consumidor de flujos. Una vista materializada es la zona de aterrizaje de los datos leídos del flujo, que se procesan a medida que llegan. Por ejemplo, los valores JSON pueden consumirse y asignarse a las columnas de datos de la vista materializada, mediante el lenguaje SQL conocido. Cuando la vista materializada se actualiza, Redshift consume datos de las particiones asignadas de datos de Kinesis o particiones de Kafka hasta que la vista alcance la paridad con SEQUENCE_NUMBER para la secuencia de Kinesis o el último Offset para el tema de Kafka. Las siguientes actualizaciones de la vista materializada leen los datos del último SEQUENCE_NUMBER de la actualización anterior hasta que alcanzan la paridad con los datos del flujo o del tema.

Casos de uso de ingesta de streaming

Los casos de uso para la ingesta de streaming de Amazon Redshift implican trabajar con datos que se generan continuamente (flujos) y que deben procesarse en un periodo corto (latencia) desde su generación. Esto se denomina análisis casi en tiempo real. Los orígenes de los datos pueden variar e incluyen dispositivos IoT, datos de telemetría del sistema o datos de secuencias de clics de un sitio web o una aplicación muy activos.

Consideraciones sobre la ingesta de streaming

A continuación, se exponen consideraciones importantes y prácticas recomendadas para el rendimiento y la facturación a medida que establece su entorno de ingesta de streaming.

• Uso y activación de la actualización automática: las consultas de actualización automática para una vista o vistas materializadas se tratan como cualquier otra carga de trabajo de usuario. La actualización automática carga los datos del flujo a medida que llegan.

  La actualización automática se puede activar explícitamente para una vista materializada creada para la ingesta de streaming. Para ello, especifique AUTO REFRESH en la definición de la vista materializada. La actualización manual es la opción predeterminada. Para especificar la actualización automática de una vista materializada existente para la ingesta de streaming, puede ejecutar ALTER MATERIALIZED VIEW para activarla. Para obtener más información, consulte CREATE MATERIALIZED VIEW o ALTER MATERIALIZED VIEW.

• Ingesta de streaming y Amazon Redshift sin servidor: las mismas instrucciones de instalación y configuración que se aplican a la ingesta de streaming de Amazon Redshift en un clúster aprovisionado también se aplican a la ingesta de streaming en Amazon Redshift sin servidor. Es importante dimensionar Amazon Redshift sin servidor con el nivel necesario de RPU para respaldar la ingesta de streaming con actualización automática y otras cargas de trabajo. Para obtener más información, consulte Facturación de Amazon Redshift sin servidor.

• Nodos de Amazon Redshift en una zona de disponibilidad diferente a la del clúster de Amazon MSK: al configurar la ingesta de streaming, Amazon Redshift intenta conectarse a un clúster de Amazon MSK en la misma zona de disponibilidad, si el reconocimiento de bastidor está habilitado para Amazon MSK. Si todos sus nodos se encuentran en zonas de disponibilidad distintas a la de su clúster de Amazon Redshift, puede incurrir en costos de transferencia de datos entre zonas de disponibilidad. Para evitarlo, mantenga al menos un nodo del clúster de agentes de Amazon MSK en la misma zona de disponibilidad que el clúster o grupo de trabajo aprovisionados de Redshift.

• Ubicación de inicio de actualización: tras crear una vista materializada, su actualización inicial comienza desde TRIM_HORIZON de un flujo de Kinesis, o desde el desplazamiento 0 de un tema de Amazon MSK.

• Formatos de datos: los formatos de datos admitidos se limitan a los que pueden convertirse desde VARBYTE. Para obtener más información, consulte Tipo VARBYTE y Operadores VARBYTE.

• Añadir registros a una tabla: puede ejecutar ALTER TABLE APPEND para añadir filas a una tabla de destino desde una vista materializada de origen existente. Esto solo funciona si la vista materializada está configurada para la ingesta de streaming. Para obtener más información, consulte ALTER TABLE APPEND.

• Ejecutar TRUNCATE o DELETE: puede eliminar registros de una vista materializada que se utiliza para la ingesta de streaming, mediante un par de métodos:

  • TRUNCATE: este comando elimina todas las filas de una vista materializada configurada para la ingesta de streaming. No hace un análisis de la tabla. Para obtener más información, consulte TRUNCATE.

  • DELETE: este comando elimina todas las filas de una vista materializada configurada para la ingesta de streaming. Para obtener más información, consulte DELETE.

Prácticas recomendadas y sugerencias para la ingesta de streaming

Hay casos en los que se le presentarán opciones para configurar la ingesta de streaming. Recomendamos que siga las siguientes prácticas recomendadas. Están basadas en nuestras propias pruebas y en la experiencia que hemos obtenido al ayudar a los clientes a evitar problemas que podrían provocar la pérdida de datos.

• Extracción de valores de los datos transmitidos en streaming: si utiliza la función JSON_EXTRACT_PATH_TEXT en su definición de vista materializada para destruir el JSON de streaming entrante, esto puede afectar considerablemente al rendimiento y a la latencia. La explicación es que, por cada columna extraída con JSON_EXTRACT_PATH_TEXT, se vuelve a analizar el JSON entrante. Luego, se produce cualquier conversión de tipos de datos, filtrado o lógica empresarial. Esto significa, por ejemplo, que si extrae 10 columnas de sus datos JSON, cada registro JSON se analiza 10 veces, lo que incluye las conversiones de tipos y la lógica adicional. Esto se traduce en una mayor latencia de ingesta. Un enfoque alternativo que recomendamos es utilizar la función JSON_PARSE para convertir los registros JSON al tipo de datos SUPER de Redshift. Una vez que los datos transmitidos lleguen a la vista materializada, use PartiQL para extraer cadenas individuales de la representación de SUPER de los datos JSON. Para obtener más información, consulte Consulta de datos semiestructurados.

  También es importante tener en cuenta que JSON_EXTRACT_PATH_TEXT tiene un tamaño de datos máximo de 64 KB. Por lo tanto, si algún registro JSON tiene más de 64 KB, al procesarlo con JSON_EXTRACT_PATH_TEXT se produce un error.

• Mapeo de un flujo de Amazon Kinesis Data Streams o un tema de Amazon MSK a una vista materializada de ingesta de streaming de Amazon Redshift: no recomendamos crear varias vistas materializadas de ingesta de streaming para ingerir datos desde un solo flujo de Amazon Kinesis Data Streams o tema de Amazon MSK. Esto se debe a que cada vista materializada crea un consumidor para cada porción del flujo o la partición de Kinesis Data Streams en el tema de Kafka. Como resultado, puede producirse una limitación o superación del rendimiento del flujo o el tema. También puede suponer un coste mayor, ya que se ingieren los mismos datos varias veces. Le recomendamos que cree una vista materializada de streaming para cada flujo o tema.

  Si su caso de uso requiere que agrupe los datos de un flujo de KDS o un tema de MSK en varias vistas materializadas, antes de hacerlo, consulte el AWS Big Data Blog, específicamente la publicación Best practices to implement near-real-time analytics using Amazon Redshift Streaming Ingestion with Amazon MSK.

Uso de la ingesta de streaming en comparación con los datos transitorios en Amazon S3

Hay varias opciones para transmitir datos a Amazon Redshift o a Amazon Redshift sin servidor. Dos opciones conocidas son la ingesta de streaming, tal como se describe en este tema o la configuración de una transmisión de entrega a Amazon S3 con Firehose. En la siguiente lista se describe cada método:

1. La ingesta de streaming de Kinesis Data Streams o Amazon Managed Streaming para Apache Kafka a Amazon Redshift o Amazon Redshift sin servidor implica configurar una vista materializada para recibir los datos.

2. La entrega de datos a Amazon Redshift mediante Kinesis Data Streams y la transmisión a través de Firehose implica conectar la transmisión de origen a Amazon Data Firehose y esperar a que Firehose almacene los datos en Amazon S3. Este proceso utiliza lotes de varios tamaños a intervalos de búfer de longitud variable. Después de la transmisión a Amazon S3, Firehose inicia un comando COPY para cargar los datos.

Con la ingesta de streaming, se omiten varios pasos necesarios para el segundo proceso:

• No es necesario enviar datos a una transmisión de entrega de Amazon Data Firehose, ya que al ingerir la transmisión, los datos se pueden enviar directamente desde Kinesis Data Streams a una vista materializada en una base de datos de Redshift.

• No tiene que enviar los datos transmitidos a Amazon S3, ya que los datos de ingesta de streaming van directamente a la vista materializada de Redshift.

• No es necesario escribir ni ejecutar los comandos COPY porque los datos de la vista materializada se actualizan directamente desde la transmisión. La carga de datos de Amazon S3 a Redshift no forma parte del proceso.

Tenga en cuenta que la ingesta de streaming se limita a las transmisiones de Amazon Kinesis Data Streams y a los temas de Amazon MSK. Para transmitir desde Kinesis Data Streams a destinos distintos de Amazon Redshift, es probable que necesite un flujo de entrega de Firehose. Para obtener más información, consulte Envío de datos a un flujo de entrega de Amazon Data Firehose.

Consideraciones

A continuación, se indican los aspectos que se deben tener en cuenta para la ingesta de streaming en Amazon Redshift.

Característica o comportamiento	Descripción
Límite de longitud de los temas de Kafka	No es posible utilizar un tema de Kafka con un nombre de más de 128 caracteres (sin incluir las comillas). Para obtener más información, consulte Nombres e identificadores.
Actualizaciones incrementales e instrucciones JOIN en una vista materializada	La vista materializada debe ser mantenible de forma incremental. El recálculo completo no es posible para Kinesis ni Amazon MSK porque, de forma predeterminada, no conservan el historial de flujos o temas más allá de 24 horas o 7 días. Puede establecer periodos de retención de datos más largos en Kinesis o Amazon MSK. No obstante, esto puede suponer un mayor mantenimiento y costo. Además, las instrucciones JOIN no se admiten actualmente en vistas materializadas creadas en un flujo de Kinesis, o en un tema de Amazon MSK. Después de crear una vista materializada en su flujo o tema, puede crear otra para unir su vista materializada de streaming a otras vistas materializadas, tablas o vistas. Para obtener más información, consulte REFRESH MATERIALIZED VIEW.
Análisis de registros	La ingesta de streaming de Amazon Redshift no admite el análisis de registros agregados por Kinesis Producer Library (Conceptos clave de KPL: agregación). Los registros agregados se ingieren, pero se almacenan como datos de búfer de protocolo binario. Para obtener más información, consulte Búferes de protocolo. Según cómo inserte los datos en Kinesis, es posible que tenga que desactivar esta característica.
Descompresión	VARBYTE no admite actualmente ningún método de descompresión. Debido a esto, los registros que contienen datos comprimidos no se pueden consultar en Redshift. Descomprima los datos antes de incorporarlos al flujo Kinesis o al tema de Amazon MSK.
Tamaño de registro máximo	El tamaño máximo de cualquier campo de registro que Amazon Redshift puede ingerir desde Kinesis o Amazon MSK es ligeramente inferior a 1 MB. Los siguientes puntos detallan el comportamiento: Longitud de VARBYTE máxima: para la ingesta de streaming, el tipo VARBYTE admite datos con una longitud máxima de 1 024 000 bytes. Kinesis limita las cargas a 1 MB. Límites de mensajes: la configuración predeterminada de Amazon MSK limita los mensajes a 1 MB. Además, si un mensaje incluye encabezados, la cantidad de datos se limita a 1 048 470 bytes. Con la configuración predeterminada, no hay problemas con la ingesta. No obstante, puede cambiar el tamaño de mensaje máximo para Kafka, y por tanto para Amazon MSK, a un valor mayor. En este caso, es posible que el campo clave/valor de un registro de Kafka o el encabezado, superen el límite de tamaño. Estos registros pueden provocar un error y no se realiza una ingesta de ellos. nota Amazon Redshift admite un tamaño máximo de 1 024 000 bytes para la ingesta de streaming desde Kinesis o Amazon MSK, aunque Amazon Redshift admite un tamaño máximo de 16 MB para el tipo de datos VARBYTE.
Registros de errores	En cada caso en que no se pueda realizar la ingesta de un registro en Redshift porque el tamaño de los datos supera el tamaño máximo, se omitirá ese registro. La actualización de la vista materializada se sigue realizando correctamente en este caso y se escribe un segmento de cada registro de error en la tabla del sistema SYS_STREAM_SCAN_ERRORS. Los errores que son resultado de la lógica empresarial, como un error en un cálculo o un error resultante de una conversión de tipo, no se omiten. Pruebe la lógica cuidadosamente, antes de agregarla a la definición de su vista materializada, para evitarlos.
Conectividad privada de varias VPC de Amazon MSK	La conectividad privada de varias de Amazon MSK no es compatible actualmente con la ingesta de streaming de Redshift. Como alternativa, puede utilizar el emparejamiento de VPC para conectar VPC o AWS Transit Gateway para conectar VPC y redes en las instalaciones a través de un hub central. Cualquiera de estas opciones permite a Redshift comunicarse con un clúster de Amazon MSK o con Amazon MSK sin servidor en otra VPC.