Examen de la arquitectura lambda de IoT
En la lista siguiente se incluyen tres propósitos distintos para almacenar lecturas de telemetría generadas por dispositivos IoT:
- Para su análisis en busca de anomalías, para llevar a cabo el mantenimiento preventivo.
- Para su visualización por parte de un operador humano remoto, para ayudar en la toma de decisiones.
- Para archivarse: para su análisis posterior.
Cada uno de estos escenarios tiene requisitos de almacenamiento en conflicto. Sin embargo, tener objetivos en conflicto no es necesariamente algo malo. Los objetivos en conflicto de almacenamiento de datos nos llevan a sistemas híbridos, que pueden ser flexibles y eficaces.
En las secciones siguientes se describe la naturaleza híbrida de la arquitectura lambda de IoT.
Rutas de acceso de datos
El conflicto aparente con los datos de Azure IoT es así. Los datos de telemetría vienen en activo, hay muchos y deben analizarse rápidamente. El mantenimiento preventivo es el objetivo de este análisis, donde se deben almacenar los datos, tanto para archivarlos como para ejecutar un análisis más profundo durante períodos de tiempo más largos. Un análisis más profundo consiste se lleva a cabo con el fin de detectar tendencias a más largo plazo o patrones de error que pueden ser difíciles de detectar con una muestra más corta en tiempo real.
Una de las formas más sencillas de administrar esta dualidad en el extremo del sensor del dispositivo es enviar dos mensajes:
- El primer mensaje solo contiene los datos de telemetría que se deben analizar en tiempo real.
- El segundo mensaje contiene la telemetría y todos los demás datos que podrían ser necesarios para un análisis o archivado más profundos.
Azure IoT Hub enruta estos dos mensajes a recursos distintos. En el análisis de datos, es habitual usar los términos familiares activo, intermedio, esporádico e inactivo:
- El término activo significa claramente que se necesita un enfoque en tiempo real.
- El término intermedio puede tener el mismo significado, aunque es posible que los datos estén "casi" en tiempo real o, como mínimo, recientes.
- El término esporádico significa que el flujo de datos es lento.
- El término inactivo significa que los datos se almacenan y no "fluyen".
Descripción de la arquitectura lambda
La arquitectura Lambda para una solución de Azure IoT permite varias rutas de datos. Sin embargo, con la finalidad de explicarlo mejor, vamos a trabajar con dos rutas de acceso: activa e inactiva.
En el diagrama siguiente:
Ruta de acceso rápida: el procesamiento en tiempo real (ruta de acceso activa) es la telemetría de streaming enrutada al análisis en tiempo real. Esta ruta de acceso también es la ruta correcta para desencadenar advertencias y alertas.
La ruta de acceso lenta: procesamiento por lotes (ruta de acceso inactiva) es una ruta de procesamiento por lotes para el almacenamiento de datos de telemetría.
La ruta de acceso activa
En este escenario, el dispositivo remoto de IoT envía la telemetría específica. Esta telemetría se envía en su propio mensaje, enrutado mediante el centro IoT Hub para su análisis y visualización instantáneos. Un operador humano puede realizar el análisis, por ejemplo, mediante Azure Data Explorer. En este módulo se describe este enfoque.
Como alternativa, el análisis se puede controlar mediante modelos de Azure Machine Learning, a través de Azure Stream Analytics. Este escenario es más complejo e implica codificación.
La ruta de acceso inactiva
En este escenario, el dispositivo remoto de IoT también envía todos los datos de telemetría y registro. La instancia de IoT Hub dirige estos mensajes por una ruta a una cuenta de almacenamiento de Azure. Hay varios recursos de almacenamiento disponibles en Azure y en las siguientes unidades se describen estas opciones.
Incidencias con la arquitectura lambda
De forma parecida a la mayoría de los sistemas híbridos, hay incidencias. Una de las principales incidencias con IoT es la duplicación de datos y código. Cuanto mayor sea la duplicación, mayor será la posibilidad de que se produzca una divergencia no deseada entre las copias duplicadas. Los desarrolladores de código del sensor del dispositivo IoT deben asegurarse de que los datos de telemetría que se envían en los dos mensajes son idénticos, cuando proceda. Puede haber duplicación de código en las aplicaciones de análisis para las rutas de acceso de acceso activas e inactivas. La duplicación debe controlarse con cuidado, aunque sea una consecuencia prácticamente inevitable de un sistema híbrido.