Diseño del procesamiento de datos en streaming - Construcción de pipelines de datos en tiempo real con Kinesis
Se explican las técnicas de diseño del procesamiento de datos en streaming que aprovecha Amazon Kinesis Data Streams y Amazon Data Firehose (antes Kinesis Data Firehose), y se presenta cómo construir pipelines de datos en tiempo real mediante la integración con Lambda.
Demanda de procesamiento de datos en tiempo real y papel de Kinesis
Está creciendo rápidamente la demanda de procesar y analizar de inmediato grandes volúmenes de datos generados en tiempo real, como los datos de sensores de dispositivos IoT, los clickstreams de aplicaciones web, los registros de transacciones financieras y los feeds de redes sociales. El procesamiento por lotes produce un desfase de varias horas a varios días, mientras que con el procesamiento en streaming se pueden obtener resultados de análisis en un plazo de pocos segundos desde la generación de los datos. El procesamiento de datos en streaming en AWS se configura combinando servicios totalmente administrados que se encargan respectivamente de la recopilación, la entrega y el análisis. La base del stream de datos es Amazon Kinesis Data Streams, la entrega a los destinos corresponde a Amazon Data Firehose y el análisis de los datos en streaming, a Amazon Managed Service for Apache Flink. El nombre anterior del servicio de entrega es Amazon Kinesis Data Firehose y el del servicio de análisis es Amazon Kinesis Data Analytics; actualmente, los que conservan el nombre Kinesis son Data Streams y Video Streams. Las aplicaciones SQL del antiguo Kinesis Data Analytics dejaron de ofrecerse de forma progresiva y la eliminación de aplicaciones comenzó el 27 de enero de 2026 (a partir de ese día no se pueden iniciar ni operar aplicaciones SQL). Por ello, el nuevo procesamiento de análisis se configura con Managed Service for Apache Flink.
Recopilación de datos con Kinesis Data Streams
Kinesis Data Streams es un servicio que recopila y retiene en tiempo real grandes volúmenes de datos en streaming. Un stream de datos se compone de shards. Cada shard admite hasta 1 MB o 1,000 registros por segundo de escritura y hasta 2 MB o 2,000 registros por segundo de lectura (a fecha de agosto de 2026 / valores indicados en la documentación oficial). Aunque haya margen en el volumen de bytes, a veces se alcanza antes el límite de número de registros, por lo que la estimación se realiza en ambas dimensiones. En el modo bajo demanda, el número de shards se escala automáticamente según el tráfico y la planificación de capacidad deja de ser necesaria. Un stream recién creado empieza con 4 MB/s de escritura / 8 MB/s de lectura, y el límite se eleva automáticamente a medida que aumenta el tráfico (el límite máximo que se puede alcanzar varía según la región). En el modo aprovisionado, se puede optimizar el coste especificando explícitamente el número de shards. El periodo de retención de datos es de 24 horas como valor predeterminado y mínimo, y se puede ampliar hasta un máximo de 8760 horas (365 días). Por la parte que supera las 24 horas se cobra aparte una tarifa de retención. Si se usa Kinesis Producer Library (KPL), se puede maximizar el throughput del lado del productor mediante la agregación y el almacenamiento en búfer de registros. Con la función de fan-out mejorado, se reserva un throughput de lectura dedicado para cada consumidor (2 MB/s por shard), y varios consumidores pueden procesar el mismo stream en paralelo. Los consumidores de tipo compartido que no usan fan-out mejorado se reparten 2 MB/s por shard, por lo que, al aumentar los consumidores, el ancho de banda de cada uno se reduce y la latencia de propagación también aumenta. El número de consumidores de fan-out mejorado que se pueden registrar es de 20 por stream de datos, y de 50 en el modo On-demand Advantage (a fecha de agosto de 2026 / valores indicados en la documentación oficial). Por la obtención de datos con fan-out mejorado se cobra aparte una tarifa.
Procesamiento de streams serverless mediante la integración con Lambda
La integración de Kinesis Data Streams con Lambda se ha adoptado ampliamente como patrón de procesamiento de streams serverless. Mediante el mapeo de origen de eventos, Lambda sondea automáticamente los registros del stream de Kinesis y los pasa a la función Lambda por lotes. Ajustando el tamaño de lote, la ventana de lote y el factor de paralelización, se puede optimizar el equilibrio entre throughput y latencia. Si se configura el factor de paralelización, varias instancias de Lambda procesan en paralelo un mismo shard y se mejora la capacidad de procesamiento. En el manejo de errores, la función bisect on function error divide automáticamente en dos el lote fallido y lo reintenta para identificar los registros problemáticos. Los registros cuyo procesamiento ha fallado se pueden enviar a una cola de mensajes fallidos de SQS, lo que permite su investigación y reprocesamiento posteriores. Si se usa la función de filtrado, se pueden filtrar los registros por condiciones antes de pasarlos a la función Lambda y evitar el procesamiento de registros innecesarios. Ejemplo de CLI para configurar el filtrado en el mapeo de origen de eventos de Lambda: con aws lambda create-event-source-mapping --function-name process-orders --event-source-arn arn:aws:kinesis:ap-northeast-1:123456789012:stream/orders --starting-position LATEST --batch-size 100 --maximum-batching-window-in-seconds 5 --filter-criteria "{"Filters":[{"Pattern":"{\"data\":{\"event_type\":[\"ORDER_PLACED\"]}}"}]}" se pasan a Lambda solo los eventos ORDER_PLACED. Así se evita el procesamiento de registros innecesarios y se optimiza el coste.
Entrega con Data Firehose e integración con S3
Amazon Data Firehose es un servicio que entrega automáticamente datos en streaming a destinos como S3, Redshift, OpenSearch y Splunk. Automatiza por completo desde la recepción de los datos hasta el almacenamiento en búfer, la transformación, la compresión y la entrega, y deja de ser necesario desarrollar aplicaciones consumidoras. Se pueden controlar la frecuencia de entrega y el tamaño de lote configurando el tamaño de búfer y el intervalo de búfer como sugerencias de almacenamiento en búfer. Los rangos configurables varían según el destino. Para un destino S3, el tamaño de búfer es de 1 - 128 MB (predeterminado 5 MB) y el intervalo de búfer, de 0 - 900 segundos (predeterminado 300 segundos) (a fecha de agosto de 2026 / valores indicados en la documentación oficial). Si el intervalo de búfer se fija en menos de 60 segundos, Firehose entrega mediante cargas multiparte, por lo que aumentan los cargos por solicitudes PUT de S3. El almacenamiento en búfer cero, con un intervalo de búfer de 0 segundos, solo está disponible para destinos de aplicaciones y no está disponible para el destino de copia de seguridad de S3 ni para el particionamiento dinámico. El intervalo de búfer del destino de copia de seguridad es de 60 - 900 segundos. Con la función de transformación de datos, se puede usar una función Lambda para ejecutar la conversión de formato, el filtrado y el enriquecimiento de registros antes de la entrega. Las sugerencias de almacenamiento en búfer para la transformación son de 0.2 - 3 MB de tamaño (predeterminado 1 MB) y de 0 - 900 segundos de intervalo (predeterminado 60 segundos). Se configuran de modo que no superen el límite de carga útil de 6 MB de la invocación síncrona de Lambda. En la entrega a S3, se puede realizar la conversión automática a los formatos Parquet u ORC y se puede construir un data lake optimizado para el análisis con Athena o Redshift Spectrum. Con la función de particionamiento dinámico, el prefijo de S3 se determina de forma dinámica según el contenido de los registros, lo que hace posible una organización eficiente de los datos.
Precios de Kinesis
Los siguientes precios unitarios son los valores publicados a fecha de agosto de 2026 para Norte de Virginia (us-east-1) y Tokio (ap-northeast-1). En el modo bajo demanda de Kinesis Data Streams, la ingesta de datos cuesta 0.08 USD en Norte de Virginia / 0.104 USD en Tokio por GB, y la obtención mediante GetRecords, 0.04 USD en Norte de Virginia / 0.052 USD en Tokio por GB. Además, se suman 0.04 USD en Norte de Virginia / 0.052 USD en Tokio por hora de stream. En el modo aprovisionado, el precio es de 0.015 USD en Norte de Virginia / 0.0195 USD en Tokio por hora de shard, y se cobra por el número de shards independientemente de que haya tráfico o no. La retención de datos de más de 24 horas y el fan-out mejorado se cobran aparte. En el modo bajo demanda, la retención ampliada dentro de los 7 días cuesta 0.10 USD en Norte de Virginia / 0.12 USD en Tokio por GB-mes. La retención a largo plazo de más de 7 días cuesta, en la misma unidad, 0.023 USD en Norte de Virginia / 0.025 USD en Tokio. La obtención de datos con fan-out mejorado cuesta 0.05 USD en Norte de Virginia / 0.065 USD en Tokio por GB. La tarifa de ingesta de Amazon Data Firehose es un sistema escalonado que disminuye según el uso (nivel 1 = hasta 512,000 GB al mes / nivel 2 = hasta 2,048,000 GB / nivel 3 = por encima de esa cantidad; común a ambas regiones). Por GB, cuesta en Norte de Virginia 0.029 USD en el nivel 1 / 0.025 USD en el nivel 2 / 0.020 USD en el nivel 3. En Tokio, cuesta por GB 0.036 USD en el nivel 1 / 0.031 USD en el nivel 2 / 0.025 USD en el nivel 3. Si se usan la conversión de formato, el particionamiento dinámico o la entrega a destinos dentro de una VPC, se añade un concepto de facturación aparte para cada uno. En comparación con MSK (Kafka), los motivos para elegir Kinesis son que ofrece abundantes integraciones nativas con los servicios de AWS y que no obliga a asumir tareas operativas como el dimensionamiento de brokers o la aplicación de parches. Si se parte de clientes de Kafka, Kafka Connect o Kafka Streams existentes, o si los requisitos incluyen una API compatible con Kafka, se elige MSK.
Resumen
Combinando Kinesis Data Streams, Amazon Data Firehose y Managed Service for Apache Flink, se pueden configurar de forma totalmente administrada la recopilación, el procesamiento, la entrega y el análisis de los datos en streaming. El modo bajo demanda de Data Streams hace posible una recopilación de datos escalable sin necesidad de planificación de capacidad. El procesamiento de streams serverless mediante la integración con Lambda hace posible la transformación y el análisis de datos en tiempo real sin gestionar infraestructura. Data Firehose automatiza la construcción de un data lake optimizado para el análisis mediante la entrega automática a S3 y la conversión a Parquet. Para las organizaciones que buscan construir una base de procesamiento de datos en tiempo real, esta combinación con Data Streams como núcleo es el punto de partida.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
- Amazon Kinesis (página oficial)
- AWS Lambda (página oficial)
- Amazon S3 (página oficial)
- Documentación de AWS (oficial)
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.