El IoT streaming es el flujo continuo de telemetría desde sensores, máquinas, vehículos y productos conectados hacia sistemas que la procesan en cuanto llega. En lugar de esperar a que los dispositivos suban archivos por lotes, un pipeline de IoT streaming filtra, agrega y actúa sobre cada lectura en cuestión de segundos. Esta guía trata los datos de dispositivos y sensores, no el vídeo en directo de cámaras IoT.
La mayoría de los primeros proyectos IoT recogían datos por lotes. Los dispositivos almacenaban las lecturas en un buffer y las subían cada hora o cada noche, y los analistas revisaban los resultados al día siguiente. Eso sirve para generar informes, pero falla cuando un compresor se sobrecalienta, un camión frigorífico pierde frío o un contador inteligente muestra un pico repentino. El IoT streaming trata cada lectura como un evento y la mueve por un pipeline capaz de reaccionar mientras la situación sigue ocurriendo.
Los datos IoT son más difíciles de procesar que la mayoría de los flujos de eventos. Una sola flota puede generar millones de mensajes pequeños por minuto, cada uno con unos pocos bytes de telemetría. Los dispositivos pierden la conexión y luego envían de golpe horas de lecturas acumuladas, así que los eventos llegan tarde y desordenados. Los formatos de payload también cambian con el tiempo, porque una flota rara vez funciona con una sola versión de firmware, y los dispositivos antiguos siguen enviando esquemas antiguos mucho después de que se publiquen los nuevos.
Estas características condicionan todas las decisiones de diseño posteriores. Un pipeline que las ignora produce dashboards que parecen correctos hasta el primer corte de red o la primera actualización de firmware.
Una arquitectura típica de IoT streaming tiene cuatro etapas, y cada una resuelve una parte distinta del problema. Los fundamentos de la etapa de procesamiento se explican en nuestra guía de stream processing.
Los sensores y dispositivos publican sus lecturas directamente o a través de un gateway local. MQTT es el protocolo más habitual en esta etapa, porque es ligero, funciona en hardware con recursos limitados y tolera redes poco fiables. MQTT 5.0 es un estándar de OASIS desde el 7 de marzo de 2019. En entornos industriales, los gateways suelen traducir los datos de las máquinas desde OPC UA o protocolos de bus de campo más antiguos antes de publicarlos.
Un broker MQTT gestiona las conexiones de los dispositivos, que pueden contarse por millones. No está pensado para almacenar históricos largos ni para alimentar de forma independiente a muchos consumidores, así que la mayoría de las arquitecturas lo conectan con Apache Kafka, ya sea mediante un conector de origen MQTT de Kafka Connect o mediante una integración con Kafka en el propio broker. Kafka almacena cada lectura de forma duradera, permite que las nuevas aplicaciones reproduzcan el histórico y desacopla la conectividad de los dispositivos de los sistemas que usan los datos.
Un motor de stream processing lee de Kafka y hace el trabajo que convierte la telemetría en bruto en señales útiles. Apache Flink es una opción habitual para IoT porque gestiona de forma nativa el event time, el estado y los datos que llegan tarde. Kafka Streams encaja cuando la lógica de procesamiento vive dentro de un microservicio, y Flink SQL permite a los equipos de datos escribir esa misma lógica como consultas continuas.
Los datos procesados llegan a donde las personas y las aplicaciones pueden usarlos. Las bases de datos de series temporales alimentan los dashboards operativos y el histórico reciente, las tablas del lakehouse guardan el registro a largo plazo para análisis y entrenamiento de modelos, y las herramientas de alertas avisan a los operadores o disparan acciones automáticas. Nuestra guía de streaming analytics explica cómo los equipos convierten estos resultados en decisiones.
En la etapa de procesamiento es donde un pipeline IoT funciona o fracasa. Hay cinco patrones que aparecen en casi todos los proyectos.
La primera tarea es convertir el payload de cada dispositivo a un formato canónico único, sea cual sea su versión de firmware. Un schema registry y unos esquemas versionados lo hacen manejable. Después, el pipeline enriquece cada lectura con metadatos del dispositivo, como la ubicación, el tipo de activo o el cliente, uniendo el flujo con una tabla de referencia que se mantiene actualizada a partir del registro de dispositivos.
Pocos consumidores necesitan cada lectura en bruto. Las ventanas tumbling o hopping reducen la telemetría por segundo a medias, mínimos y máximos por minuto y dispositivo, lo que abarata el almacenamiento y acelera los dashboards. Los datos en bruto pueden seguir yendo a un almacenamiento barato a largo plazo para auditorías y entrenamiento de modelos.
Cuando un dispositivo se reconecta tras un corte, sus lecturas describen el pasado, no el momento en que llegan. Procesar por event time, es decir, por la marca de tiempo que registró el dispositivo, mantiene correctos los agregados. Flink usa watermarks para seguir cuánto ha avanzado el event time, de modo que un operador sabe cuándo puede cerrar una ventana aunque los registros hayan llegado desordenados. Los equipos fijan un margen de retraso permitido y envían todo lo que llegue después a un side output para corregirlo.
Muchas preguntas dependen del histórico de cada dispositivo, como si una temperatura lleva 10 minutos seguidos subiendo o si una puerta ha estado abierta más tiempo de lo normal. El estado por clave del procesador de streams guarda la imagen actual de cada dispositivo. En conjunto, estos estados por dispositivo forman un digital twin en vivo de la flota que las aplicaciones pueden consultar.
El último patrón compara las lecturas en vivo con umbrales, reglas o predicciones de modelos y lanza alertas cuando no coinciden. Las reglas simples detectan los fallos evidentes, mientras que la detección de patrones a lo largo de varios eventos identifica problemas más lentos, como un rodamiento que vibra un poco más cada día. Las alertas deben incluir suficiente contexto, como el dispositivo, la ubicación y las lecturas recientes, para que un operador pueda actuar sin abrir otro sistema.
No todo el cálculo debe hacerse en la nube. La elección depende de la latencia, del ancho de banda y de lo que ocurre cuando se cae la conexión.
| Factor | Procesamiento en el edge | Procesamiento en la nube |
|---|---|---|
| Latencia | Milisegundos, junto al dispositivo | Segundos, tras el salto de red |
| Coste de ancho de banda | Bajo, solo envía resultados o excepciones | Más alto, envía datos en bruto o poco filtrados |
| Tolerancia sin conexión | Sigue funcionando sin conexión | Depende de la conectividad |
| Cálculo y estado | Limitados por el hardware del gateway | Escalan con la carga de trabajo |
| Visión de toda la flota | Solo ve los dispositivos locales | Correlaciona todos los dispositivos |
| Mejor uso | Paradas de seguridad, control local, reducción de datos | Analítica de toda la flota, enriquecimiento, entrenamiento de modelos |
La mayoría de los sistemas en producción combinan ambos. El edge filtra, hace downsampling y se encarga del control crítico en tiempo, y la nube se ocupa del enriquecimiento, la correlación de toda la flota y el histórico.
MQTT y Kafka se comparan a menudo, pero hacen trabajos distintos y suelen funcionar juntos.
| MQTT | Apache Kafka | |
|---|---|---|
| Función principal | Conectividad y mensajería de dispositivos | Almacenamiento duradero y distribución de eventos |
| Clientes habituales | Millones de dispositivos con recursos limitados | Cientos de aplicaciones y servicios de backend |
| Supuestos de red | Enlaces poco fiables y de poco ancho de banda | Redes estables de centro de datos o de la nube |
| Retención de mensajes | Corta, orientada a la entrega | Configurable, desde horas hasta de forma indefinida |
| Reproducción | No está diseñado para ello | Integrada |
| Ubicación habitual | Capa de dispositivo, gateway y broker | Entre el broker y los sistemas de procesamiento |
En flotas y logística, los vehículos envían en streaming su ubicación, los datos del motor y la temperatura de la carga, y el pipeline detecta retrasos, desvíos de ruta o roturas de la cadena de frío mientras los conductores aún pueden reaccionar. En energía y utilities, los contadores inteligentes y los sensores de red envían lecturas de consumo y tensión que alimentan la previsión de carga y la detección de cortes.
Los edificios inteligentes envían datos de ocupación, calidad del aire y equipos para ajustar la calefacción y la refrigeración y para planificar el mantenimiento. Los fabricantes de productos conectados, como electrodomésticos, sistemas de calefacción y dispositivos médicos, usan el mismo pipeline para supervisar las unidades instaladas, planificar las visitas de servicio técnico y entender cómo usan sus clientes los productos. Para casos de uso en planta, consulta nuestra guía de data streaming en manufactura.
Varios servicios IoT gestionados que recomiendan las guías de arquitectura más antiguas ya no existen o están en proceso de retirada. Google Cloud IoT Core se retiró el 16 de agosto de 2023. AWS IoT Analytics dejó de aceptar nuevos clientes el 24 de julio de 2024 y llegó al fin de soporte el 15 de diciembre de 2025. Microsoft ha anunciado que Azure IoT Central se retirará el 20 de septiembre de 2029, y remite a sus clientes a Azure IoT Hub, Device Provisioning Service y Azure Device Registry, con Microsoft Fabric para la analítica.
Estas retiradas son un argumento sólido para mantener portable el núcleo de streaming. Cuando la conectividad de los dispositivos pasa por MQTT estándar y la columna vertebral de eventos funciona sobre Kafka, un cambio de servicio cloud afecta a una sola capa y no a todo el pipeline.
Los proyectos de IoT streaming suelen tropezar en los mismos puntos:
Todos estos problemas son más fáciles de resolver en la fase de diseño que cuando la flota ya ha crecido.
No. El IoT streaming suele referirse a la telemetría: lecturas pequeñas y frecuentes como la temperatura, la ubicación o la vibración. El streaming de vídeo IoT envía imágenes continuas de cámaras y se basa en protocolos e infraestructura diferentes. Algunos pipelines combinan ambos, por ejemplo enviando en streaming eventos extraídos del análisis de vídeo junto con los datos de los sensores.
Procesa por event time, la marca de tiempo que registró el dispositivo, y no por el momento de llegada. Un procesador de streams como Apache Flink usa watermarks para decidir cuándo está completa una ventana de tiempo, y un ajuste de retraso permitido mantiene las ventanas abiertas para los rezagados. Las lecturas que llegan aún más tarde pueden ir a un flujo aparte que corrige los resultados almacenados.
Para la mayoría de las cargas de trabajo IoT, Apache Flink es una opción por defecto sólida porque gestiona bien el event time, el estado por clave de gran tamaño y los datos que llegan tarde. Kafka Streams encaja en pipelines más pequeños integrados en microservicios, y los servicios gestionados de Flink eliminan la operación de clústeres. La elección correcta depende del tamaño del estado, de las capacidades del equipo y de dónde funciona el resto de tu plataforma.
Un IoT streaming fiable nace de un reparto claro del trabajo. MQTT conecta los dispositivos a través de redes poco fiables, Kafka almacena y distribuye cada lectura, y un procesador de streams aplica event time, estado y enriquecimiento antes de que los resultados lleguen a dashboards, alertas y almacenamiento a largo plazo. Diseñar desde el principio pensando en los datos que llegan tarde, los cambios de esquema y las avalanchas de reconexiones es lo que mantiene correcto el pipeline a medida que crece la flota.
Mimacom diseña, construye y opera pipelines de IoT streaming sobre IBM Confluent, con experiencia en entregas de streaming en producción en manufactura, transporte y retail. Somos partner de Confluent desde 2017 y partner oficial de formación de Confluent desde 2021, y trabajamos con IBM Confluent como partner de IBM desde que IBM adquirió Confluent. Para un fabricante alemán de sistemas de calefacción, migramos una plataforma de datos IoT a Kafka cloud-native en Azure. Nuestros servicios de consultoría de Confluent cubren arquitectura, implementación y operación, y nuestro whitepaper La base de Data Streaming para la IA explica cómo esa misma base da soporte a la analítica y la IA.
Habla con el equipo de data streaming de Mimacom sobre una arquitectura de IoT streaming que acompañe el crecimiento de tu flota.
Descubre nuestros servicios de consultoría de Confluent | Contacta con nosotros