Como sucede con Azure Solution Architect Expert, ésta será la primera de varias entradas sobre un tema que, cada vez está más demandado, y además es clave en la Analítica Avanzada. Me refiero al diseño, configuración y puesta en funcionamiento de los componentes necesarios para configurar la capa de streaming de una arquitectura Lambda.
Para ello, lo primero que necesitamos es recordar cómo es el diagrama de dicha arquitectura y para ello, utilizaré la Plataforma Moderna de Datos de Azure, que utilicé hace unos días en la entrada:
https://alb3rtoalonso.com/2021/01/16/de-lambda-a-kappa-y-tiro-porque-me-toca/
Como se puede observar, la capa streaming en la que nos encontramos en la parte superior del diagrama. Tiene como punto de inicio los productores. Es decir, todos aquellos elementos que generan datos, que deben ser capturados por nosotros, como pueden sensores, dispositivos IoT, dispositivos inteligentes, etc.
Hay muchas ocasiones en las que sentimos que no podemos avanzar en esta disciplina porque no disponemos de dichos productores. Sin embargo, existen múltiples opciones para simularlos. Para esta entrada, utilizaré un simulador que Azure pone a disposición para facilitarte el trabajo y evitar que tengas que programar tu propio sensor.
Para ello, sólo tienes que acceder a la siguiente web, añadir la cadena de conexión de tu Azure IoT Hub y pulsar Run.
Fuente:
https://azure-samples.github.io/raspberry-pi-web-simulator/
Hemos visto, que necesitamos crear un Azure IoT Hub, con lo que nos ponemos en ello. Lo primero es crear un grupo de recursos, que en este caso se llamará azure-iot-dev. Acto seguido, iniciamos la creación del recurso.
El siguiente paso es darle nombre y determinar la ubicación. En nuestro caso, sogetiaa-iot-dev y Oeste de Europa.
NOTA:
Es importante que el IoT Hub se encuentre la más próximo posible al conjunto de dispositivos IoT que generarán los datos a capturar.
Ahora elegimos que esté accesible para todas las redes, ya que para nuestro ejemplo no vamos a implementar un punto privado de conexión.
Para llegar al apartado de Administración. Aquí es muy importante conocer las características de nuestro caso de uso, con el fin de poder estimar cual es el nivel de precio y escala que debemos seleccionar. Para ayudarnos, Azure nos informa detalladamente de las principales características de cada uno de los planes.
En el ejemplo, elegimos el nivel S1 lo que nos permitirá recibir unos 400.000 mensajes al día. Sin embargo, como antes comentaba, es muy importante conocer el caso de uso, puesto que, en el apartado de configuración avanzada, disponemos de la posibilidad de seleccionar el número de particiones con las que trabajar. Es decir, nos permite elegir entre un mínimo de 2 hasta un máximo de 32.
El número de particiones está íntimamente relacionado con las Unidades de IoT, que para entenderlo mejor viene a ser que 1 TU corresponde a 1 MB de entrada y 2 MB de salida por segundo. También debemos atender a la estructura de los datos que vamos a recibir y si incluye algún tipo de atributo de particionado que nos ayude a distribuir correctamente la información a tratar. Por ejemplo al recibir datos de temperatura desde el mismo sensor, pero de distintas áreas de nuestra máquina y que nosotros deseamos analizar por separado.
Para hacer más complicado el ejemplo, crearé dos sensores Raspberry Pi duplicando el simulador y renombrando el atributo devideid. El primero tendrá el identificador: IotExample001, mientras que para el segundo será IotExample002.
Aunque no es el caso, porque de este sensor de ejemplo, sólo llega la información de temperatura, provisionaré mi Azure IoT Hub con dos TU y usaré la configuración por defecto de las dos particiones. Incluyo la etiqueta de environment como dev y lo creo.
Una vez creado, sólo quedaría provisionar los dos dispositivos IoT.
Acceder a cada uno de los dispositivos recién creados y copiar la cadena primaria de conexión. Esta será la que debemos incluir en cada uno de nuestros sensores Raspberry Pi que hemos configurado anteriormente.
Finalmente, sólo quedaría arrancar nuestro dos Raspberry Pi y verificar que recibimos los datos en nuestro Azure IoT Hub.
CONCLUSIÓN:
Esta entrada provee de un primer punto de partida hacia la integración de servicios de streaming en arquitecturas de análisis de datos con capacidades en Real Real Time. Por supuesto, queda mucho por recorrer, pero justo éso es lo apasionante del mundo de la tecnología.
En la próxima entrada hablaré acerca de cómo persistir en raw de los datos utilizando un Azure Data Lake Gen2. Ya que en IoT Hub sólo se encuentran disponibles por un periodo que va de 1 a 7 días, salvo que sea recurso dedicado donde nos iríamos a un máximo de 90 días.
Alb3rto Alonso 