Visión de alto nivel de la arquitectura de Amazon Kinesis

En esta publicación voy a hablar sobre la recogida de datos en un cluster AWS, donde daré algunas pautas sobre cómo podemos mover datos a AWS e introduciré la Arquitectura de Amazon Kinesis en relación con esta problemática. 

Hay muchas maneras de mover datos a AWS, que se pueden segmentar en tres categorías diferentes. La primera es para la recogida de datos en tiempo real donde podemos realizar acciones inmediatas sobre nuestros datos. Para esto, veremos los flujos de datos de Kinesis, o Kinesis Data Streams (KDS), el Servicio de cola simple o SQS y el IoT para Internet de las cosas. Todos estos servicios nos permiten que nuestras aplicaciones reaccionen en tiempo real a eventos o datos que suceden en nuestra infraestructura. 

Existe una segunda forma de recogida de datos, que es casi en tiempo real (NRT), que es más para la acción reactiva en lugar de inmediata. NRT implica que usaremos Kinesis Data Firehose (KDF) o el servicio de migración de bases de datos (DMS). No te preocupes ahora por estos términos, ya que iré introduciéndolos en posteriores publicaciones de esta serie de AWS.  

Finalmente, hay un tercer tipo de recogida de datos que se llama batch y generalmente se llama cuando queremos mover una gran cantidad de datos para luego poder realizar un análisis histórico de Big Data en AWS. Aquí tenemos los servicios Snowball y Data Pipeline.  

Por lo tanto, todos estos servicios los iré detallando en esta serie de publicaciones sobre análisis de datos en AWS. Hay muchas cosas que aprender, pero espero que al final obtengas una idea general de cómo están las cosas en términos de RT, NRT y batch. 

Vamos a comenzar viendo Kinesis, que es un tema de examen muy importante en la certificación de Data Analytics sobre AWS y, en general, un problema de recogida de datos muy importante en AWS si quieres realizar big data. 

Algunos ven Kinesis como una alternativa administrada a Apache Kafka, que es genial para capturar una gran cantidad de datos en tiempo real. Es excelente si quieres recopilar datos tanto de IoT como de métricas, logs de aplicaciones o secuencias de clics. En general, es ideal para cualquier tipo de big data en tiempo real. Se integra con una gran cantidad de frameworks de procesamiento de streaming, ya sea Spark, NiFi u otros frameworks. Se consigue una replicación de datos realmente genial porque los datos se replican sincrónicamente hasta 3 AZ (Zonas de Amazon), por lo que esta es una configuración de alta disponibilidad. 

Kinesis se compone de múltiples servicios. El primero es Kinesis Streams, o Kinesis Data Streams, que es una ingesta de streaming de baja latencia a escala. También tenemos Kinesis Analytics , que describiré más adelante en esta serie de artículos sobre Análisis de Datos en AWS, para realizar tareas de análisis en tiempo real sobre streams usando SQL. Y finalmente está Kinesis Firehose para cargar streams en S3, Redshift, ElasticSearch y Splunk. Todos estos servicios los veremos en esta serie de artículos. 

Ahora veamos primero Kinesis en su conjunto. 

En el centro de la arquitectura que rodea a Kinesis tenemos el servicio Amazon Kinesis. En Amazon Kinesis Streams, los streams pueden recibir una gran cantidad de datos de, por ejemplo, flujos de clics o de dispositivos IoT, por ejemplo, una bicicleta conectada, o métricas y logs directamente de nuestros servidores. Por lo tanto, los streams ingieren una gran cantidad de datos y veremos cómo funciona más adelante en esta serie de artículos. 

Puede que después queramos realizar un análisis en tiempo real, por ejemplo, para calcular una métrica, o generar alertas. Para esto se puede usar opcionalmente el servicio Amazon Kinesis Analytics. 

Una vez que tengamos todos esos datos, puede que queramos almacenarlos en algún lugar para realizar análisis posteriores o cuadros de mando en tiempo real, o todo ese tipo de cosas que se harían con Amazon Kinesis Firehose. Como se mencionó anteriormente, Kinesis Firehose es un servicio NRT. Veremos lo que eso significa cuando realicemos una inmersión profunda en Kinesis Firehose, pero si haces el examen de certificación, recuerda que es un servicio NRT, no RT. 

Por ejemplo, Kinesis Firehose puede entregar datos a un bucket de Amazon S3, o a una base de datos de Amazon Redshift, o Splunk, o ElasticSearch como veremos más adelante. 

Eso nos ofrece una visión general de alto nivel de la arquitectura que rodea a Kinesis. 

Ahora vamos a profundizar más en Kinesis Streams. Los streams de Kinesis se dividen en shards, o fragmento, ordenados, y un shard, para aquellos que no saben qué significa ese término, es el equivalente a una partición. Un productor genera los streams en Kinesis, pero ese stream en realidad está compuesto de fragmentos (shards). 

En este ejemplo tenemos tres fragmentos y luego los consumidores leen los datos de esos fragmentos.  

Por defecto, Kinesis streams no almacena los datos para siempre. Los datos se almacenan durante 24 horas de forma predeterminada, por lo que básicamente tienes un día para consumir los datos. Pero si quieres aumentar la seguridad y, obviamente esto será más caro, se puede configurar que se conserven los datos durante un máximo de siete días. 

Con Kinesis tienes la capacidad de reprocesar y reproducir datos. Una vez que consumes esos datos, los datos no desaparecen de Kinesis Streams. Se eliminarán en función del período de retención de datos, pero se pueden leer los mismos datos continuamente mientras estén en Kinesis Stream. 

Eso significa que múltiples aplicaciones pueden consumir el mismo stream, por lo que se puede hacer el procesamiento en tiempo real a una gran escala de rendimiento. 

Kinesis Stream no es una base de datos. Una vez que se insertan los datos en Kinesis, permanecen inmutables, lo que significa que no se pueden eliminar. Por lo tanto, es un stream append-only.

Vamos a profundizar ahora en los shards. Básicamente, un stream está compuesto de muchos fragmentos o particiones diferentes. Y cuando te facturan en Kinesis, te facturan por aprovisionamiento de fragmentos. Se pueden tener tantos fragmentos como quieras.  

Existe la posibilidad de batch o también se pueden hacer operaciones PUT por mensaje (veremos cómo funciona esto en el productor). 

La cantidad de fragmentos puede evolucionar con el tiempo, por lo que tenemos operaciones de reparticionamiento y fusión (reshard y merge). 

En general, los registros no se ordenan globalmente, sino que se ordenan por fragmento. Entonces, dentro del fragmento, todos los registros se ordenan en función de cuándo se reciban. 

Los productores generan los registros de Kinesis Streams, que están hechos de algo llamado Blob de Datos, que es de hasta un megabyte, debes acordarte de esto. Como son bytes, puede representar lo que queramos.  

Tendrás una clave de registro y esa clave de registro básicamente ayuda a Kinesis a saber cómo alcanzar el fragmento al que enviar esos datos. Básicamente, si eliges una clave de registro, debes tenerla súper distribuida, por ejemplo, si el UserID tiene un millón de usuarios y te permitirán evitar el problema de la “partición caliente”, en el que todos los datos se envían al mismo fragmento. 

Finalmente tenemos un número de secuencia, y esto no es algo que el productor envía, sino que es algo que Kinesis añade después de que se ingieren los datos, básicamente representa el número de secuencia en el fragmento cuando los datos se añaden a ese fragmento. 

Finalmente, hay algunos límites que es necesario conocer en Kinesis Data Streams. El primero es que el productor solo puede producir 1 megabyte o 1000 mensajes por segundo en tiempo de escritura por fragmento. Por ejemplo, si tienes diez fragmentos, obtienes 10 megabytes por segundo o 10000 mensajes por segundo. Si se supera ese límite, se obtiene lo que se llama una excepción del rendimiento aprovisionado (ProvisionedThroughputException).  

Hay dos tipos de consumidores en Kinesis. El primero es el consumidor clásico, con el que se obtienen 2 megabytes por segundo en tiempo de lectura por fragmento en todos los consumidores, o se consiguen 5 llamadas del API por segundo por fragmento en todos los consumidores. 

También tenemos el Consumidor Mejorado en Abanico, que es un nuevo tipo de consumo que aún no se puede describir muy bien en línea, que consigue 2 megabytes por segundo en lectura por fragmento por consumidor mejorado y no se necesitan llamadas del API (este un modelo push). 

Entonces, lo realmente genial que veremos en detalle es que se pueden escalar muchas más cosas al consumidor mejorado en abanico. 

Y, por último, debes recordar la retención de datos, que es de 24 horas de retención de forma predeterminada y se puede extender esto a siete días. 

Hasta aquí una visión general de alto nivel de Kinesis. 

¡ Hasta el próximo artículo !