Orquestación de notebooks desde motor de flujos: Procesamiento de imágenes con Sofia2

image1

En la nueva versión de Sofia2 se ha añadido un nuevo nodo al motor de flujos capaz de gestionar ejecuciones sobre notebooks de la plataforma.

Con esta nueva característica, se pueden orquestar procesos basados en notebook e incluso paralelizar los mismos distribuyendo la carga de trabajo. Es posible pasar parámetros dinámicos a estos notebooks, pudiendo incluir información fija o generada por un flujo sobre cualquier lenguaje usado en los notebooks y más adelante iniciar una ejecución con los mismos.

Al igual que los parámetros de entrada, se posibilita la salida de los datos generados por uno o varios párrafos de un notebook, incluyendo información generada por un proceso analítico dentro del flujo y tomar decisiones en base al mismo.

Vamos a ver un tutorial de uso del mismo. Tendremos varios elementos de Sofia2 que nos ayudarán a construir y procesar una imagen que el usuario incluirá a través de una web, los cuales son:

  • Proyecto Web: Donde alojaremos la web donde el usuario subirá su imagen y verá los resultados.
  • Binary Repository: Para almacenar y recuperar las diferentes imágenes generadas
  • SSAP: Que nos servirá para comunicarnos entre los diferentes elementos
  • Motor de Flujos (Nodered + nodo Notebook Launcher)
  • Notebooks Sofia2: Usaremos dentro de los mismos Python junto con la librería PIL para procesar imágenes.
  • Gadgets Sofia2: Tendremos un gadget donde se mostrará el histograma de la imagen subida

Lo primero que haremos, será crear un proyecto en Sofia2 que tendrá un domino del motor de flujos y que también tendrá asociada la web.

image2

En la web asociada al proyecto tendremos una interfaz simple que permitirá subir un imagen al binary repository, realizará un POST sobre una URL que iniciará el flujo de procesamiento (al que le pasará los datos de la imagen ya subida) y que mediante el protocolo SSAP se subscribirá a la ontología donde recibirá los resultados de las imágenes ya procesadas.

image3

La url donde se pueden ver los resultados y el código fuente es la siguiente https://sofia2.com/web/imageprocess/imageFlow.html

A continuación, veremos los notebooks necesarios para el procesamiento, así como la configuración necesaria en el motor de flujos. Los notebooks se han construido de manera que cada uno haga una funcionalidad concreta y aislada.

Conversor de RGB a escala de grises: recibe como parámetro una sessionKey válida y el identificador del binary repository (la referencia de la imagen de entrada). Utilizando lenguaje Python y la librería PIL se obtendrá esa imagen del binary repository se convertirá a escala de grises y se volverá a subir al binary repository.

En este notebook podemos comprobar cómo se pueden recibir parámetros en el mismo. Simplemente usando z.input(“nombreParámetro”) crearemos un párrafo que podrá recibir datos dinámicos de forma externa por un formulario, esto no solo es válido para Python, se puede incluir igualmente en otros lenguajes soportados en los notebook como por ejemplo con el interpreter de Spark(scala).

image4

image5

Teniendo ese notebook creado, dentro del motor de flujos podremos añadirlo con el nodo Notebook Launcher:

image6

Al añadir ese nodo, podremos seleccionar cualquiera de los notebooks del usuario en la configuración:

image7

Posteriormente añadiremos el párrafo de entrada (se nos mostrará la lista de los mismos junto con el título y el texto de los mismos):

image8

Al añadir un párrafo con parámetros de entrada, se nos desplegará el formulario correspondiente para configurar cada entrada dinámicamente.

image9

En cuanto a la salida del párrafo (la cual, en este caso, será el nuevo identificador del binary repository de la imagen procesada) la haremos como salida del último párrafo el cuál imprimirá ese identificador. De manera análoga a los parámetros de entrada seleccionaremos un párrafo de salida. Además, se le podrá añadir un tópico para poder distinguir esta salida de otras en nodos posteriores.

image10

Si tuviéramos varios párrafos de salida, podríamos incluir diferentes salidas distinguidas por tópico.

image11

Al enviarlas, podrá ser por array en el mismo puerto (Split Output desactivado) o por diferentes puertos de salida (Split Output activado):

image12

Filtro Blur sobre imagen RGB: similar al notebook anterior salvo que se hará un filtro blur sobre un imagen.

image13image14

Obtención histograma: en este caso se leerá la imagen y se devolverá en el último párrafo el array del histograma

image15

Agrupación de datos: notebook que unificará los datos de los diferentes notebook de procesamiento para conformar una salida única que se enviará posteriormente a la ontología de salida por SSAP a Sofia2.

image16

En este caso, en la configuración del nodo, al tener varios notebooks de entrada tendremos que tener activado el Workflow Mode. Con esta opción, este nodo, se esperará a todos los notebooks de entrada antes de ejecutarse (cada notebook le enviará un parámetro). A parte, al tener varias entradas y no saber el orden de las mismas, tendremos que diferenciar las entradas del nodo por tópico para direccionarlas correctamente. Este direccionamiento se puede hacer de 3 formas:

  • payload: única entrada y se recoge el parámetro el contenido de “payload”
  • payload[n]: múltiples entradas, se recoge la que llega en posición n
  • payload{“topic”:”t1″}: múltiples entradas, se busca la que “topic” sea igual a “t1”

Para este nodo en concreto tendremos:

image17

Ahora, vamos a ver el flujo de procesamiento completo dentro del motor de flujos:

image1

La primera parte del mismo crea un endpoint REST de tipo POST (este será el disparador de todo el flujo). Dentro de este POST se incluirán por JSON los datos de:

  • SessionKey: sessionKey del usuario contra Sofia2. Se usará en todos los acceso al binary repository o al enviar mensajes SSAP
  • BinaryID: id en el binary repository de la imagen inicial

image18

A parte también se incluirá la sessionKey (común para todos los procesos) en el contexto del flow mediante el nodo function.

image19

Más adelante esta información llega a 3 nodos de tipo Notebook Launcher:

image20

Cada uno de estos notebooks recibirá como parámetro el ID del Binario junto con la sessionKey (desde el contexto del flow).

image21

La salida en el caso concreto del conversor a escala de grises va tanto al notebook de agrupación de datos, como a otro notebook idéntico al de filtrado blur.

image22

Aquí, se puede el porqué de la distinción por funcionalidad completa y aislada de los notebooks pudiendo verlos como “cajas negras” reutilizables que procesa con una entrada y una salida. A parte, el nodo notebook launcher crea una instancia de ejecución nueva para cada notebook, por lo que se puede usar varios nodos iguales en paralelo.

Finalmente, se crea un mensaje SSAP que se envía por POST a la ontología destino.

image23

image24

El resultado de todo este proceso, al subir una imagen de este tipo:

image25

Obtendremos al terminar el procesamiento las diferentes imágenes:

  • Imagen con filtro blur
  • Imagen en escala de grises
  • Imagen en escala de grises más filtro blur
  • Histograma en un gadget

image26

El código de los notebook así como la exportación del flujo de nodered puede descargar en el siguiente enlace del github de Sofia2: https://github.com/Sofia2/Sofia2-ImageProcessing

 

Orquestación de notebooks desde motor de flujos: Procesamiento de imágenes con Sofia2

Nuevos tutoriales añadidos: Taller IoT y Taller Analytics

Coincidiendo con la Release 3.4 de la plataforma Sofia2 y con el objetivo de simplificar la comprensión de las capacidades de la plataforma, se han añadido nuevos tutoriales  como el Taller IoT y el Taller Analytics, disponibles en formato PDF, formato HTML y formato POST.

 

Seguir leyendo “Nuevos tutoriales añadidos: Taller IoT y Taller Analytics”

Nuevos tutoriales añadidos: Taller IoT y Taller Analytics

Cloudera Announces General Availability of Apache Kudu with Release of Cloudera Enterprise 5.10

Latest version of Cloudera Enterprise, Cloudera Enterprise 5.10, is now available.

 

Apache Kudu, the open source software (OSS) storage engine for fast analytics on fast moving data, is now shipping as a generally available component within Cloudera Enterprise 5.10.Kudu simplifies the path to real-time analytics, allowing users to act quickly on data as-it-happens to make better business decisions.

 

apachekudu_logo_0716_345px

 

Apache Kudu has been included in FEEP IoT & Big Data Platform Sofia2 release 3.4 as Real Time Database (RTDB). With Kudu, the difference between RTDB and HDB has been disolved, allowing storage on a single layer of storage and simplifying the architecture of mixed applications. You can read MultiStore: Kudu support post for more info.

Cloudera Announces General Availability of Apache Kudu with Release of Cloudera Enterprise 5.10

MultiStore: Kudu support

Apache Kudu has been included in FEEP IoT & Big Data Platform Sofia2 release 3.4 as Real Time Database (RTDB). Kudu is an open-source solution that supports mixed workloads: real-time and analytics through an efficient scanning mechanism over a single storage layer.

Using Kudu as RTDB, the information provided in the ontologies will be mapped to tables, although inserting  and obtaining data with JSON format is also available.

This implementation has been developed using the Hive JDBC access, which can stablish connection with Impala and Impala-Kudu interconnection.

With Kudu, the difference between RTDB and HDB has been disolved, allowing storage on a single layer of storage and simplifying the architecture of mixed applications.

For installing Sofia2 with Apache Kudu, you only have to modify some configuration parameters to enable the DAO.

parametrosKudu.JPG

With these features, the creation of the ontologies will be available with “Step by Step Creation”:

tipodatokuduen

esquemajsonairpollutionkuduen

Once an ontology is created, it will be not possible modify, create or delete the fields contained in it.

The sending and reception of data is independent of the chosen data model. In case of Kudu, there is a manager that is responsible for transforming the incoming messages to a proper format. Here we can see an example of this:

crudontkuduen

These data have been saved in Kudu as:

datostablakuduimpala

From de RTDB & HDB console in Sofia2  we can query on any ontology and choose the data view mode: JSON format or table

datostablaairpollutionkuduen

datosjsonairpollutionkuduen

MultiStore: Kudu support

Cloudera anuncia la completa disponibilidad de Apache Kudu en su última Release Cloudera Enterprise 5.10

Ya está disponible desde el pasado 31 de Enero de 2017 la última versión de Cloudera Enterprise, Cloudera Enterprise 5.10.

 

Uno de los aspectos más destacados en esta última Release consiste en la inclusión del motor de almacenamiento open source Apache KuduKudu simplifica el camino hacia la analítica en tiempo real, permitiendo a los usuarios actuar con rapidez con los datos y mejorar la toma de decisiones empresariales.

 

apachekudu_logo_0716_345px

 

Tal y como os contamos en el post Soporte Kudu, desde la FEEP IoT & Big Data Platform Sofia2 3.4 se ha incorporado y se puede hacer uso del soporte de Apache Kudu como Base de Datos de Tiempo Real (BDTR). Con el uso de Kudu se diluye la diferencia entre BDTR y BDH, permitiendo el almacenamiento sobre una única capa de almacenamiento y simplificando la arquitectura de aplicaciones mixtas.

 

 

 

Cloudera anuncia la completa disponibilidad de Apache Kudu en su última Release Cloudera Enterprise 5.10

PUBLICADA FEEP IoT & Big Data Platform Sofia2 3.4

Ya está disponible la release 3.4 de FEEP IoT&Big Data PlatformSofia2 (también conocida como Sofia2 IoT Platform).
Esta release se ha disponibilizado en la Plataforma de Experimentación Sofia2 CloudLab
(FEEP IoT & Big Data Platform Sofia2 forma parte de la FEEP Enablement Platform de Minsait)

Esta release incluye numerosas novedades y mejoras, entre ellas:

 

Spaces/Grupos

Representa un Entorno colaborativo donde el creador del Space/Proyecto puede añadir usuarios, crear diferentes perfiles (roles virtuales) y compartir con estos los elementos de la plataforma, desde ontologías, informes, dashboards, notebooks, pipelines,…además de poder subir una web HTML5 asociada. También es posible asignar un dominio al Proyecto, donde se podrá arrancar un Node-red.

proyectos1

Ahora asociado a cada sistema IoT vertical (riego, gestión de residuos) podré tener un proyecto donde gestionaré de forma unificada todos sus elementos.

Además, con el soporte multitenant estrenado en esta release, cada proyecto actúa como un tenant.

 

Soporte Node-RED como motor visual de flujos

La Plataforma permite ahora crear visualmente reglas y flujos a través de Node-RED, una herramienta para la edición visual de flujos y motor de ejecución de estos flujos.

node_red

Node-RED se ha convertido en un estándar para crear flujos IoT y ofrece un gran número de componentes para crear aplicaciones IoT de forma sencilla. Además hemos creado diversos componentes Node-RED  que permiten interactuar con la plataforma de forma sencilla  y el soporte para crear dashborads con esta herramienta:

Como con los motores de reglas y CEP estos flujos se pueden desencadenar ante un evento (instancia de ontología) o de forma planificada.

La integración de Node-RED se ha hecho con un enfoque multitenant, de modo que cada Space actúa como un Tenant, con una instancia para cada grupo, de modo que los flujos de un grupo no afecten al resto.

Los que probéis esta funcionalidad en el entorno de experimentación comprobaréis que la instancia Node-RED sólo permanece arrancada un tiempo de 10 minutos.

Podéis haceros una idea de su funcionamiento en este post: Demo Node-RED y Twitter

Dashboard Node-RED

Node-RED dispone de un nodo llamado “Freeboard” que permite construir dashboards a partir de un JSON. Basta con poner dicho nodo a continuación del nodo que nos de la información que queremos representar, se nos abrirá una consola de administración, donde podemos diseñar nuestro propio dashboard a partir del JSON.

Una vez terminado el dashboard, nos da la opción de guardarlo. Una vez guardado podemos acceder al dashboard de dos formas:

  •  Accediendo a la consola de administración del nodo Freeboard y cargando el fichero .json que nos generó al guardar el dashboard.
  • Copiando la URL que se genera al guardar el dashboard, con dicha URL se podrá acceder al dashboard desde cualquier navegador o dispositivo.

creacion-dashboard-node-red

 

Ampliación Protocolo SSAP con nuevos mensajes LOG, ERROR, STATUS y COMMAND

Se ha ampliado el protocolo SSAP con estos nuevos mensajes:

LOG y ERROR: permite que un dispositivo o sistema (ThinKP) pueda enviar mensajes de LOG y ERROR a la Plataforma de forma sencilla. Estos mensajes se almacenan en la plataforma y cada ThinKP podrá buscar y filtrar los  mensajes de LOG y ERROR conforme a diversos criterios.

STATUS: los clientes de la plataforma pueden ahora enviar el estado en el que se encuentran hacia la plataforma, que lo almacenará y permitirá ver el estado de cada uno de ellos.

COMMAND: este nuevo mensaje permite que el Broker de la Plataforma (SIB) pueda enviar comandos hacia uno o varios ThinKPs. Se ha comenzado por el comando STATUS que se encarga de solicitar el estado al ThinKP.

Estos nuevos mensajes se encuentran en el api java y se encuentran disponibles para invocación también a través del api rest

mensajes-ssap

 

 

UI Gestión Dispositivos integrada en Panel de Control

Asociado a los nuevos mensajes LOG,INFO, STATUS y COMMAND se han creado a unas nuevas pantallas que permiten ver y gestionar toda esta información de forma sencilla e integrada en la Consola Web de la plataforma.

ui-gestion-dispositivos

 

Wizard creación guiada de Aplicaciones Sofia2

Dentro de las continuas mejoras de usabilidad en la plataforma se ha creado un asistente que guía en todo el proceso de creación de un Sistema construido sobre Sofia2.

Este asistente nos permitirá seguir paso a paso la creación de proyecto, ontologías, dashboards, APIs,… hasta construir una aplicación completa.

wizard-creacion-aplicaciones

 

Visualización OpenData  

Aprovechando las capacidades semánticas de las ontologías y APIs Sofia2 se ha disponibilizado un visualizador OpenData que permite localizar información pública de la plataforma conforme a su categorización:

buscador-open-data

Y visualizar estos DataSets, además de poder valorarlos.

visualizacion

Podéis acceder a esta funcionalidad en esta url.

 

Sofia2 Bots Platform

Bajo la opción de menú ‘BOTS’ se ha disponibilizado una primera versión del soporte a la creación de Bots dentro de Sofia2.

bot1

Esta versión permite:

  • Crear Bases de Conocimiento: representan áreas específicas, como puede ser Turismo, Atención a Cliente, Saludos,… Las bases de conocimiento se pueden crear con diversas tecnologías (engines) como motores de scripting o motores NLP, en el entorno de experimentación se pueden crear bases sobre lenguaje Rivescript. Las bases de conocimiento pueden ser privadas (sólo para el usuario) o públicas.

base-de-conociemiento

  • Crear Bots: a cada Bot le podré asociar una o varias bases de conocimiento. Un Bot puede ser privado o público. El Bot es multicanal y soporta la interacción vía web, móvil, Twitter, Telegram, Slack,Facebook,… en el entorno de experimentación se disponibiliza como una URL de modo que pueda ser embebida en otros sistemas.

Aquí os mostramos un ejemplo de conversación:

conversacion

Este demostrador se ha creado con fines didácticos (probar diferentes opciones en el lenguaje de script), por lo que sus respuestas son limitadas.

 

MultiStore: Soporte Kudu

Sofia2 es multistore, o dicho de otra forma Sofia2 es una plataforma que independiza del repositorio de datos seleccionado, soportando diversas tecnologías de almacenamiento que se pueden configurar en función del caso de uso.

En esta release se ha incorporado el soporte a Apache Kudu, Kudu es una solución open-source creada por Cloudera que tiene como objetivo soportar carga de trabajo mixtas: real-time y analytics y para eso combina inserciones/actualizaciones rápida con un mecanismo eficiente de escaneado sobre una única capa de almacenamiento.

Con el uso de Kudu se diluye la diferencia entre BDTR y BDH, permitiendo el almacenamiento sobre una única capa de almacenamiento y simplificando la arquitectura de aplicacions mixtas.

A modo de ejemplo vamos a definir una ontología con los siguientes campos:

esquemajsonairpollutionkudu

Si mediante el crud de ontologías insertamos datos en esta ontología, desde la consola BDTR BDH podemos obtener los datos en dos formatos distintos: En formato tabla o en formato JSON. Ambos se muestran a continuación:

datostablaairpollutionkudu

datosjsonairpollutionkudu

 

Roles Virtuales y Usuario Extendido

Estos dos nuevos conceptos permiten que podamos delegar la autenticación y autorización de nuestras soluciones IoT sobre  los mecanismos ofrecidos por la plataforma.

El Rol Virtual se asocia a un Space/Proyecto y permite crear diferentes perfiles que luego podré gestionar desde mi Space. Por ejemplo si creo un sistema de gestión de residuos me puede interesar crear los roles de contratista, gerente, ciudadano, auditor…

roles2

Además ahora la plataforma permite configurar los atributos que se gestionan de un usuario, de modo que sin ninguna programación podré gestionar atributos adicionales a los que gestiona la plataforma, como su ubicación, categoría profesional, teléfono…

Un ejemplo de esta funcionalidad se puede ver en la siguiente imagen, en la que se han añadido los campos Empresa, Código del empleado, Fecha de ingreso y Motivo :

rol1

Si ahora nos logamos con este usuario creado, la plataforma nos dará los datos relacionados con este, entre los que figurarán los datos extendidos:

rol22

 

Despliegue multitenant

La Plataforma permite el despliegue y funcionamiento en modo multitenant, de esta forma sobre una misma instalación podré gestionar diversos tenants desde la propia consola (a través de un nuevo rol), los tenants no comparten recursos e incluso dentro de una misma instalación se puede configurar diferentes motores según el tenant (por ejemplo que un tenant use MongoDB como BDTR y otro use Kudu).

Cuando accedemos a la plataforma esta nos informará de que Tenant está usando, por defecto, si un usuario no pertenece a un tenant específico indicará que pertenece al tenant Default.

tenantdefault

El nuevo Rol, denominado Administrador de Infraestructura tendrá la capacidad de crear y gestionar todos los Tenant. Los administradores de la plataforma únicamente podrán administrar los tenant a los que pertenezcan.

tenants

Un Tenant consta de un Identificador, y una configuración de Base de datos de configuración y de Base de datos de tiempo real. Por último, la asignación de usuarios al tenant se realiza a nivel de Grupos, de forma que todos los usuarios que pertenecen a un grupo, pasarán a ser miembros del Tenant al que sea asignado el Grupo.

identificacion

Mejoras en los Dashboards

En esta release se han añadido numerosas mejoras visuales para la creación de dashboards más sofisticados.

Así de forma sencilla podré crear dashboards como este (pruébalo aquí)

dashboard_black

Las mejoras y novedades más importantes son:

  • Restyling del gadget Tabla
  • Nuevo Gadget multi: permite en un único gadget ver 1,2, 3 o 4 valores en forma de bar, línea, discrete, pie.
  • Gadget tipo Carrousel: permite mostrar diversas imágenes
  • Se permite la creación del gadgets desde el propio dashboard
  • Personalización de los colores del dashboard usando el Custom Style
  • Nuevas distribuciones del dashboard
  • Captura de pantalla

 

Exportación de Consultas de la BDH

A partir de esta nueva versión, se ofrece la posibilidad de descargar las consultas realizadas sobre la BDH desde la Consola BDTR y BDH en un fichero con formato XLS, XML y/o CSV

exportacion1

 

Nuevos tutoriales y webcasts 

 

Coincidiendo con la Release 3.4 de la plataforma Sofia2 y con el objetivo de simplificar la comprensión de las capacidades de la plataforma se han añadido nuevos y completos tutoriales y webcasts a los que podéis acceder desde este Blog o desde el canal Youtube de la plataforma.

 

PUBLICADA FEEP IoT & Big Data Platform Sofia2 3.4