El Falso Mito de la Planificación en Scrum

 Introducción

Hoy nos vamos a salir un poco del tema principal y vamos a hablar un poco de Scrum (y el mito para algunos de porque no tienen planificaciones). 

Scrum es un marco de trabajo ágil para la gestión de proyectos, ha ganado popularidad en los últimos años debido a su enfoque flexible y adaptativo. Sin embargo, un mito común que rodea a Scrum es que no requiere planificación. Este artículo tiene como objetivo desmitificar esta idea explorando los elementos que apoyan y contradicen el mito de la planificación en Scrum, y llegar a conclusiones sobre la importancia de la planificación en este marco de trabajo.

Elementos que Apoyan el Mito

Énfasis en el Empirismo: Scrum promueve un enfoque empírico, donde el aprendizaje y la adaptación se basan en la experiencia y la retroalimentación. Esto puede llevar a la idea de que la planificación detallada no es necesaria, ya que los planes pueden cambiar a medida que avanza el proyecto.

Ciclos Cortos de Desarrollo: Scrum se basa en ciclos cortos de desarrollo (sprints) que duran de 1 a 4 semanas. Esto puede dar la impresión de que la planificación a largo plazo no es importante, ya que el equipo se concentra en el trabajo inmediato.

Priorización Continua: Scrum enfatiza la priorización continua del trabajo pendiente (backlog), lo que implica que las prioridades pueden cambiar en cualquier momento. Esto puede llevar a la idea de que la planificación a largo plazo es inflexible y no se adapta a las necesidades cambiantes del proyecto.

Elementos que Contradicen el Mito

Planificación del Sprint: Cada sprint comienza con una planificación del sprint, donde el equipo define los objetivos del sprint y selecciona el trabajo que se realizará. Esta actividad de planificación es crucial para asegurar que el equipo esté alineado y trabaje hacia objetivos comunes.

Visión del Producto: Scrum requiere una visión del producto que define la dirección general del proyecto. Esta visión sirve como guía para la planificación del sprint y la toma de decisiones.

Backlog del Producto: El backlog del producto es una lista ordenada de prioridades que contiene todas las funcionalidades y requisitos del proyecto. Esta lista sirve como base para la planificación del sprint y la priorización del trabajo.

Conclusiones

Si bien Scrum enfatiza la flexibilidad y la adaptación, la planificación no es un concepto ausente en este marco de trabajo. La planificación a largo plazo se realiza a través de la visión del producto y el backlog del producto, mientras que la planificación a corto plazo se lleva a cabo en las reuniones de planificación del sprint. La clave en Scrum es que la planificación sea flexible y se adapte a las necesidades cambiantes del proyecto.

En lugar de considerar la planificación como una actividad rígida y predetermina, Scrum la ve como una herramienta para guiar el trabajo del equipo y asegurar que se avanza hacia los objetivos del proyecto. La planificación efectiva en Scrum no se trata de crear planes inamovibles, sino de establecer marcos flexibles que se ajusten a medida que se aprende y se obtiene información durante el desarrollo del proyecto.

IoT, Kafka, Spark, Grafana

En esta entrada vamos a hablar un poco de como montar un sistema de procesamiento masivo de datos montando un mecanismo de procesamiento en modo ventana y la visualización de los datos en un dashboard muy simple.
Vamos a trabajar con las tecnlogias Kafka, Python, Spark (scala), InfluxBD y Grafana, pero no se trata de hablar sobre ellas, más bien de presentar un problema y ver como podríamos resolverlo por medio de estas herramientas.

Imaginemos que tenemos una red de sensores, con movilidad, que  manejan un conjunto de parámetros y nos dan unas medidas aleatorias en el tiempo, y nos piden monitorizar el movimiento de la red de sensores y fijar en un periodo de tiempo el valor máximo recibido de los mismos para un tipo de parámetro concreto.

Lo primero que vamos a hacer es montarnos un sistema que nos permite simular la red de sensores, para ello vamos a montar unos scripts en Python, que basados en unos datos aleatorios y otros pre fijamos, nos permitan simular la red de sensores, donde tendremos un sensor, que nos devuelve un parámetro de medida con un valor desde una posición geográfica concreta.

Vamos a montar una arquitectura Lambda donde vamos a usar como mecanismo de interconexión Kafka es una plataforma de streaming; básicamente un servicio de mensajería que permite publicar y suscribir streams de datos.

En el Script principal lo que vamos a hacer es:

• Conectarnos a Kafka.
• Generar los datos aleatorios.
• Enviar los datos, con un delay que pasaremos como parámetro al Script.

La clase que nos va a permitir conectarnos a Kafka va a tener un par de funciones, la conexión, el envió y lo olvidaba una función para gestionar los errores por medio de una callback.

Aquí sólo tendremos que tener en cuenta en tener instalado el paquete de Kafka para poder usar la clase que envuelve al productor. El método para inicializar la conexión se basa en el constructor de KafkaProducer donde tendremos que especificar el nombre del servidor y la versión de api que use el servidor.
Para enviar un dato sólo necesitamos el dato serializado, en nuestro caso vamos a enviar strings y el topic al cual esta asociado el dato a enviar.


A continuación vamos a generar los datos sinteticos que vamos a manejar, tendremos 2 partes, datos generados aleatoriamente a partir de un subconjunto de datos, vamos a manejar la identificación de los sensores, los parámetros a monitorizar y las coordenadas geográficas desde donde los sensores envían los datos. También vamos a manejar datos aleatorios, de tipo numérico, para representar los valores y fechas.

Los subconjuntos de datos aleatorios los vamos a cargar a partir de los datos generados en ficheros en formato csv, donde nos vamos a apoyar en la librería de Pandas para manejar los. Con esos sencillos métodos podemos cargar los ficheros, obtener los mismos y/o un dato concreto manejado por su columna y fila.

La generación de los datos del sensor se va a basar en el componente fecha, dentro de la información que envía el sensor, tendremos una fecha que vamos a generar de forma aleatoria. Todo esto lo tenemos recogido en la clase Sensor.

Los sensores van enviar la información codificada en una trama de texto plano que va a entrar directamente, como hemos visto el script de python a Kafka, con el siguiente formato:

id sensor; parámetro; año; mes; dia; hora; latitud; longitud; valor de la medida

Los valores para el id sensor, parámetro y coordenadas (latitud y longitud) van a ser generadas de forma aleatoria desde unos ficheros csv que contienen los valores necesarios.

Estas tramas con la medida para el parámetro asociado y en la fecha definida, van a llegar a Kafka sobre un topic que tenemos creado, no vamos a comentar que es Kafka, solamente lo emplearemos como mecanismo de comunicación para desacoplar los sensores del programa de procesamiento en spark. Para ello vamos a ejecutar el siguiente comando desde una shell

kafka-topics --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test  station-iot

En mi caso he montado Kafka dentro una máquina virtual de cloudera, descargada directamente.

Una vez que hemos lanzado el comando ya tendremos el topic creado y podremos comunicarnos con kafka, escribiendo sobre el puerto correcto desde nuestro script de python. Antes podemos ver la lista de topics creados por medio del siguiente comando:

kafka-topics --list --zookeeper localhost:2181

De esta forma podremos ver si el topic se ha creado, en otro caso analizaremos el error que nos devuelve el comando para crearlo antes definido. Para ver que todo funciona podemos ejecutar un consumidor, que nos irá mostrando los mensajes que se van recibiendo, como en nuestro caso el protocolo se basa en texto plano, es decir no estamos enviando nada serializado que debamos deserializar después, lo vamos a poder observar muy bien, para esto ejecutamos el siguiente comando y podremos ver que va llegando.

kafka-console-consumer --zookeeper localhost:2181 --topic station-iot

Una vez desarrollada esta parte, nos queda comenzar con la parte de Spark, para ello vamos a definir que vamos a desarrollar. Se tratará de un programa en scala que se conecte y analice un Streaming de datos, para ello vamos a realizar varios procesamientos, pero los más interesantes van a ser:

• Media sobre la ventana de procesamiento para cada uno de los sensores y el parámetro que envían.
• Procesamiento de todas los sensores recibidos, detectando además, para cada sensor el parámetro con mayor valor numérico y para el mismo el valor más alto.
• Filtrado de un conjunto de un conjunto de sensores específicos.

Lo primero que vamos a hacer es cargar las propiedades desde un fichero de configuración, nombre del topic, IP donde tenemos instalado Kafka,  zookeeper, configuración especifica de Spark, etc.

Vamos a hacer es inicializar el script context, para ello inicializamos Spark, con la configuración recogida en el fichero de recursos, creando un objeto de tipo StreamingContext que nos permitirá terminar de configurar el flujo de datos a manejar y conectarlo con Kafka.

Para conectarlo con Kafka, vamos a asociar nuestro StreamingContext con la configuración de Kafka, donde vamos a especificar los valores de la conexión, el topic que vamos a emplear, como almacernerá Kafka la información (en nuestro caso en memoria), que codec va usar para manejar la información, en nuestro caso ya hemos mencionado que vamos a trabajar con Strings. Al final vamos a crear un objeto que representa la entrada del receptor de datos, de tipo ReceiverInputDStream sobre el cual podremos trabajar, mapearemos los datos a un objeto de tipo Sensor, que contendrá las propiedades del mismo y la lógica necesaria para trabajar con el mismo.

Finalmente vamos a procesar la información recibida, para ellos vamos a crear objetos especializados que nos ayudarán a tratar la información. En la siguiente imagen tenemos el método que nos permite enviar todas las coordenadas recibidas y calcular los máximos de los sensores, por operación para una ventana de procesamiento.

En este caso estamos usando funciones de ventana en Spark que nos permiten hacer las agrupaciones de datos por sensor, ordenando los valores por código de parámetro y valor, finalmente el DS lo registramos como una tabla, sobre la cual calculamos el valor máximo para cada operación.

Terminamos enviando los datos a Grafana por medio de influxdb, una herramienta que nos permite crear series temporales, realmente actúa como una BD para poder analizar los datos. Para esto desde Scala, vamos a enviar los datos consumiendo el servicio REST que la herramienta pone a nuestro servicio, por medio del siguiente objeto.

En Github tenéis lo necesario para echar a andar esta parte, en el repositorio de examples, en la rama develop (aún no he podido hacer el merge).

Aqui tenénis la parte de Python que hemos visto.
https://github.com/franciscojavierestrella/Examples/tree/develop/EjemplosPython

Aqui tenénis la parte de Scala para procesar los datos.
https://github.com/franciscojavierestrella/Examples/tree/develop/SparkStreaming


Nos queda procesar la información y pintar los datos , para ello si echamos una vistazo a la herramienta influxdb , rápidamente nos haremos con ella. Tendremos que enviar los datos reflejando la BD (que previamente hemos creado en Influx) y en la query string la información a enviar, como el nombre de la serie, la clave de la serie y los valores.

Esto sería la url que vamos a emplear en la querystring, donde reflejamos la base de datos sensor.

http://localhost:8086/write?db=sensor

En la querystring vamos a reflejar la medida, indicando primero de que medida se trata y a continuación, separados por un blanco, los valores asociados a la misma. En este caso estamos hablando de una medida (meassure) para el parámetro 7, sensor 5 con latitude y longitud inventadas, terminando con el valor del parámetro.

meassure,op=7 sensor=5,latitude=47.2568899,longitude=-3.5487987,value=0007V

La siguiente imagen nos muestra como crear en la herramienta influxdb la nueva base de datos, las medidas se irán creando de forma dinámica a medida que vayamos enviando datos.

Por último nos queda crear el DashBoard, para ello tendremos que hacer lo siguiente:

• Conectar Grafana con Influxdb, para ello usaremos uno de los conectores que tiene por defecto y nos va a permitir recoger los datos y procesarlos.
• Reflejar los sensores en un mapa, junto con la primera coordenada recogida en la ventana de procesamiento para un intervalo de tiempo determinado.
• Además para cada parámetro vamos a reflejar el valor máximo de la serie recibido en los últimos 5 minutos, fijando unos valores umbrales para los mismos de 1..10 y además identificando el código del sensor.

Esto lo podemos ver reflejado en el siguiente DashBoard.

Para utilizar el mapa, tendremos que definir la query, haciendo referencia a la serie que vamos a emplear y sacando las coordenadas.

Finalmente, para pintar los sensores en el mapa necesitamos configurar las propiedades de los mismos y tratarlos en modo tabla, de esta forma tendremos acceso a los mismos y podremos reflejarlos en el mapa.

Para reflejar el valor máximo de las operaciones vamos a recurrir a un recurso gráfico de tipo Gauge que nos va a permitir relejar el valor asociando un código de colores al valor alcanzado por el mismo. Lo primero que haremos será definir como capturar los datos con respecto la serie, para ello accedemos a la serie concreta, y recogemos las variables a pintar.

Como hemos reflejado en la imagen anterior vamos a hacer un poco de trampa, para recoger el identificador del sensor, en la misma serie en el panel usando los datos, vamos a reflejar en el mismo tipo de recurso gráfico el identificador del sensor.

Con todo esto ya tenéis descrito como montarlo, si alguien necesita el DashBoard, que no dude en pedírmelo.

Jhipster (Angular + Spring Boot) + Docker + AWS

En esta entrada vamos a ver la potencia de esta terna, ya sé que no tiene mucho que ver con el blog, pero me ha parecido interesante compartirlo ya que podemos desarrollar nuestra aplicación web basada en Sprint Boot con un frontal Angular sin mucho esfuerzo (más bien en maquetación), dockerizar esta aplicación, gestionarla desde nuestro dockerhub y publicarla en una máquina EC2 en Amazon completa, teniendo acceso a la misma.

El objetivo no es profundizar en JHipster, que nos permite desarrollar proyectos por medio de esta herramienta de una forma rápida, ya que nos asila de conocer y profundizar en exceso en las herramientas (siempre que no nos sea necesario) en las que nos podemos basar.

JHipster

Es una plataforma de desarrollo que nos permite generar, desarrollar y desplegar modernas aplicaciones web y arquitecturas de microservicios.

Os recomiendo que echéis un ojo, me ha parecido muy completo, fácil e intuitivo de manejar. 

https://www.jhipster.tech/

Podemos integrarlo fácilmente dentro de Eclipse, montar nuestro proyecto y generar toda la estructura básica necesaria.

Una vez que tenemos la estructura podemos añadir nuevas entidades y gestionar las relaciones entre las mismas, podemos forzar a que se nos construya el código básico que nos va a permitir en la parte de servicios, toda la infraestructura en las diferentes capas: API REST, servicios, dominio y repositorio. Dentro del front también se nos va a generar la infraestructura en a angular.

Para ello únicamente necesitamos:

• Definir un fichero jdl con las entidades y las relaciones entre las mismas.
• Utilizar la herramienta jhipster import-jdl, que nos permitirá generar / actualizar la estructura a partir de la información del fichero (https://www.jhipster.tech/creating-an-entity/)

Un tema que no he mencionado, y me ha parecido muy interesante, es que podemos securizar la aplicación y la gestión de usuarios con múltiples tecnologías, en mi caso he añadido Oatuh2 con una autenticación de usuarios basado en un sistema externo, en mi caso he empleado el servicio de okta, donde únicamente he tenido que configurar la cuenta, y crear la configuración de usuarios y aplicación en el mismo, una vez realizado esto, podemos configurar fácilmente que las operaciones se dirijan al servicio sobre el fichero de configuración como en este ejemplo:

En cuanto al frontal, la parte de angular, fue la que he escogido en mis pruebas, muy sencilla de manejar, la estructura que crea para las entidades y los servicios, todo muy organizado, nada que objetar..

Docker

Con esto ya no solo nos queda crear el docker y correr nuestra aplicación, en la página de jhipster podemos revisar todo lo que necesario, para crear el docker y ejecutar la aplicación..

https://www.jhipster.tech/docker-compose/

Si curioseamos un poco, podemos ver que podemos levantar dockers de diversos tipos desde la solución que hemos generado, BD, Sonar, etc... muy completo, la verdad...

Nuestro objetivo era, desplegar en AWS, realmente podríamos optar por varias opciones, pero vamos a desarrollar la más simple, ejecutarlo sobre una máquina EC2, para ello que vamos a necesitar:

• Un repositorio donde podamos tener nuestra aplicación. Desde la máquina lo que haremos será conectarnos y cargar la imagen del docker y arrancarla.
• También vamos a necesitar la BD, yo en mi caso empleo un MySql que tendremos alojada en el servicio RDS de AWS. 
• Crear una máquina EC2 en AWS, nos vale una de la capa gratuita.

Para el primer paso, podemos abrirnos una cuenta en docker y dentro del hub crearnos un repositorio donde vamos a impactar nuestra imagen. Hay múltiples urls donde puedes ver esto, yo por mi parte dejo una que nos puede valer.

https://ropenscilabs.github.io/r-docker-tutorial/04-Dockerhub.html


AWS

Los dos últimos pasos comprenden trabajar con AWS. La idea es tener la BD en una instancia de RDS y la aplicación web la vamos a ejecutar sobre una instancia EC2 por medio de un Docker.

Para la BD en RDS creamos una instancia MySql, aprovechamos la capa gratuita ya que esto es una pequeña PoC, creamos la instancia ya la configuramos.

Una vez creada la instancia, podremos conectarnos a la BD desde nuestro entorno favorito, yo en mi caso utilizo DBeaver, si no lo conocéis echarle un ojo, es muy potente.

Se me olvidaba, la primera vez que os conectéis la BD no va a estar creada, esto lo reservamos al arranque de la aplicación, donde por medio de la configuración y JPA vamos a conseguir que se cree la estructura de la BD y se pueble con la configuración por defecto.

Al contenedor podemos pasarle parámetros y para conseguir el efecto mencionado, debemos introducir el parámetro SPRING_JPA_HIBERNATE_DDL_AUTO=validate, de esta forma se comprobará si la BD tiene algún cambio o es nueva, aplicando los cambios que se detecten.

Para la máquina virtual nos vale una máquina de tipo t2.micro, de la capa gratuita, para ello una vez lanzada y configurada la instancia debemos hacer dos cosas:

• Instalar apache, tendremos lo necesitaremos para que haga de Proxy con respecto el contenedor docker que lancemos, 
• Instalar docker, tendremos que poder lanzar nuestra aplicación paquetizada.

La instalación de apache no tiene complicación, por medio de yum y siguiendo cualquier tutorial en la web lo tendremos instalado en 3 minutos. Lo único será configurar lo para que haga de proxy sobre el puerto 80 y nos redirija al puerto 8080, que es donde vamos a configurar el contenedor para que escuche, nos basta con la siguiente configuración (tener en cuenta que estoy poniendo la url del servidor).

Para instalar Docker nos vale cualquier tutorial, hay multiples en la web. Una vez que lo tengamos instalado, vamos a logarnos en nuestro repositorio de contenedores.

Lo siguiente será hacer un pull del contenedor que queremos descargarnos y ya sólo nos quedará ejecutar el mismo.

Para ejecutarlo, nos basta con lanzar el comando señalado en verde y con esto ya podríamos acceder a a nuestra aplicación desplegada en la instancia de EC2.

Ya sólo nos queda terminar de configurar la web, para que sea más cómodo vamos usar una redirección a nivel de DNS dentro de nuestro dominio, para ello lo que vamos a hacer es redirigir la url mindundis.madridbigata.com a la url publica de la instancia EC2 en AWS ( por ahorrarnos unos €).

Ahora sólo nos queda configurar OKTA para que funcione la autenticación delegada que tenemos montada, para ello hay que dar de alta las nuevas url a nivel de la aplicación que hemos creado.

Con todo esto, si accedemos ya a la web podremos que ver que se carga sin problemas...

Y al logarnos, nos redirige a la url de OKTA donde entramos con las credenciales...

Una vez dentro, podremos navegar sobre los menús de administración como por ejemplo ver nuestros eventos:

Espero que os haya gustado, el objetivo es mostraros el proceso, no todos los detalles, si tenéis dudas os cuento como hacerlo.

IA, Machine Learning, Deep Learning

Hace unas semanas, mientras comía con un grupo de antiguos compañeros de trabajo, estuvimos hablando acerca de como con la tecnología en algunos momentos, uno tiene la sensación de que nos movemos en un mundo cíclico, donde se recuperan viejos conceptos y teorías que no han podido ponerse en práctica por diferentes razones: falta de madurez (ya sea sociedad o aplicaciones de la misma), entornos tecnológicos débiles en aquel momento, etc.

Analizamos estos conceptos que ahora mismo están tan de moda: IA, Machine Learning y Deep Learning. Nos dimos cuenta que en algunos de ellos la frontera de los mismos puede resultar poco clara llegando las personas a mezclar los mismos. La idea principal que hilaba toda la conversación, reside en el hecho de que el Big Data lo ha precipitado, ha hecho posible la eclosión de todas estas técnicas (hablamos en algunos casos de algoritmos con más 40 años de vida) permitiendo el análisis masivo de datos sobre tecnologías que hace 20 años eran sumamente caras y complejas de implantar. Por ejemplo, el procesamiento de imágenes para el reconocimiento facial podía desarrollarse sin excesivos problemas sobre máquinas MPP (Procesador Masivamente Paralelo)  o clusters, pero ¿Cual era el problema?, el coste y sobre todo la implementación de los algoritmos sobre las mismas, como por ejemplo PVM (Parallel Virtual Machine) que permite la distribución de tareas sobre un cluster formado por diferentes ordenadores de muy bajo coste (hablamos de procesadores 286 con las primeras versiones de Linux, puede que algunos los recuerden). Hoy en dia es más sencillo, debemos preocuparnos del algoritmo y sobre entornos como Spark o Hadoop podemos desarrollar los cálculos que necesitemos de una forma más simple. Pero no olvidemos que siempre deberemos tener claro donde debemos paralelizar los algoritmos desarrollando un estudio previo de ganancia sobre los mismos.

IA

Este concepto no es nuevo, quien haya cursado una Ingeniería en Informática u otras a partir de los 90 ha debido cursar asignaturas relacionadas con ella. Lleva dando vueltas desde 1950, cuando Alan Turing creó el test para determinar si un ordenador posee inteligencia real. En 1956 tuvo lugar la primera Conferencia de Inteligencia Artificial en Dartmount, lo que supuso la presentación oficial para este nuevo campo de la ciencia.

En aquellos momentos los planteamientos iniciales eran tratar de desarrollar máquinas que fueran capaces de resolver un problema complejo como lo hacemos los humanos. 

Como todo en este mundo tiende a partirse, esta nueva ciencia no estuvo exenta, surgieron dos tipos  de Inteligencia Artificial:

• Débil o estrecha (narrow/weak IA) caracterizada por estar especializada en una tarea concreta. Ejemplo típico Deep Blue, creado por IBM en 1996 que fue capaz de ganar al gran maestro de ajedrez Gary Kasparov. O DeepMind´s AlphaGo, creada por Google, que fue capaz de vencer a jugadores profesionales de Go. Como vemos emanan de la Teoría de Juegos que aporta la base para sus algoritmos. Los asistentes digitales como Siri y Cortana son ejemplos de este tipo de IA. Siempre debemos tener en cuenta que no pueden ir más allá de aquello para lo que han sido programados.
• Fuerte (Strong IA) nos lleva al mundo de la ciencia ficción, con cualidades humanas como la consciencia, la sensibilidad, la sabiduría y el auto conocimiento. Naturalmente, se mantiene más como una aspiración y no como una realidad. 

Machine Learning

Los primeros programas de IA, estaban basado en reglas y eran programados por una persona. En esta nueva forma de IA ya no se dependen de unas reglas y un programador, la computadora puede establecer sus propias reglas y aprender por si misma. Su objetivo es crear un modelo que nos permita resolver una tarea dada, entrenando el modelo por medio de un gran cantidad de datos. El modelo aprenderá de estos datos y será capaz de realizar predicciones que en caso de confirmarse, se podrán sumar a su base de hechos.  Dentro del Machine Learning hay dos métodos principales:

Aprendizaje supervisado (Supervised Learning)

Es una mala traducción por que realmente no hay una persona supervisando, más bien la persona dirige el aprendizaje. Un ejemplo puede ser el sistema de filtrado de SPAM de Google: el usuario ayuda a identificar a Gmail cuáles son los correos electrónicos contienen SPAM. A partir de un punto, ya se han procesado tantos mensajes que el sistema es capaz de extraer un modelo para poder predecir con una alta probabilidad de éxito cuáles de los correos son SPAM. 

Ejemplo de algoritmos:

• Clasificación Naïve Bayes.
• Árboles de decisión.
• K-vecinos.
• Modelos de regresión lineal.
• Métodos de regresión logística.
• Máquinas de vectores de soporte.
• Métodos Ensemble.

Aprendizaje no supervisado (Unsupervised Learning)

En este modelo no se introducen ejemplos, sino que es el propio algoritmo el que debe sacar patrones o anomalías para crear un modelo. Pongamos un ejemplo, tenemos un sistema de almacenamiento donde están recogidos datos de miles de personas, con datos importantes como su estado físico y sus hábitos alimenticios. Si queremos saber cuáles son los hábitos menos saludables, tendremos que comparar cada unos ellos con el estado de salud física de la persona hasta que encontremos el patrón. 

Se trata de un ejemplo muy básico y que puede no dar resultado válidos, únicamente estaríamos empleando 2 variables para la consecución del objetivo, pero en cualquier caso nos vale como caso de uso básico.

Ejemplo de algoritmos:

• Algoritmos de clustering (ej: K-Medidas).
• Análisis de Componentes Principales (PCA).
• Singular Value Decomposition.
• Análisis de Componentes Independientes (ICA).
• Redes neuronales.
• Redes de funciones de base radial.

Deep Learning

Uno de los algoritmos de ML que más expectación ha despertado, han sido las redes neuronales. Basado en el funcionamiento del cerebro humano se basa en una idea sencilla: dados unos parámetros hay una forma de combinarlos para predecir un cierto resultado. Ej: sabiendo los pixels de una imagen debemos poder saber si hay un número presente en la misma y de cual se trata.

Cuando hablamos de Deep Learning, hablamos de una clase de algoritmos de Machine Learning basados en redes neuronales. Se considera que el aprendizaje profundo surgió en los años 80 a partir de redes neuronales de entre 5 y 6 capas. El neocognitrón, creado por el investigador japonés Kunihiki Fukushima se considera la primera aplicación práctica. No existe un límite establecido para el número de capas que debe tener una red neuronal para que pueda considerarse Deep Learning. En la actualidad se trabaja en redes neuronales por encima de 20 capas, capaces de procesar más de 100 variables de entrada, generando sobre 20 variables de salida. 

Las redes neuronales han demostrado ser muy efectivas en la identificación de patrones.

Como aplicaciones prácticas podemos encontrar:

• Coches autónomos.
• Colorear imágenes en blanco y negro.
• Análisis y generación de informes.
• Predecir el resultado de procedimientos judiciales.
• Procesamiento del lenguaje natural.
• Optimización de rutas comerciales.
• Reconocimiento de voz e imágenes.
• Reconocimiento de gustos de usuarios.

Retos del Machine Learning & Deep Learning

La necesidad para entrenar estas complejas redes de neuronas requiere aumentar la capacidad de procesamiento. Una de las mejoras llevadas a cabo estos años ha sido el uso de GPUs para realizar estos trabajos de manera eficiente. Esto ha ahorrado la necesidad de disponer de gran cantidad de ordenadores para realizar los cálculos. NVIDIA es uno de los principales impulsores de esta tecnología adaptando muchos de sus componentes a esta nueva realidad, tanto en la investigación como en el uso de procesadores para la IA de forma autónoma como en los vehículos o drones.

Otro de los retos más importantes es optimizar el uso de grandes volúmenes de datos para extraer patrones de ellos. Se requiere adecuar el almacenamiento de esos datos, indexarlos, y que el acceso sea lo suficientemente rápido para que pueda escalar horizontalmente. Para ello disponemos de framework en Big Data como Hadoop y Spark, que acompañados de una amplia variedad de bases de datos NoSQL cumplen las expectativas.

El problema no es ofrecer una precisión del 90% ni tan siquiera del 99%, cuando hablamos de que las máquinas piensen por nosotros o, incluso, conduciendo un vehículo de forma autónoma, es preciso disponer de un 99,999% de precisión. Ahí es dónde está el verdadero reto del Deep Learning.

Después de los últimos accidentes de coches autónomos en EEUU, algunos científicos están comenzando a defender la introducción del concepto de incertidumbre para hacer la IA más segura. Se basa en añadir a las redes neuronales la capacidad de saber que se están equivocando en su predicción, por medio de modelos de probabilidad o lógica difusa se pueden introducir estas nuevas variables que ayudarán a conseguir el 99,999% de precisión. 

Athena

Athena es un servicio de consultas interactivo para el análisis de datos, no estructurados, semiestructurados y estructurados sobre Amazon S3 bajo SQL estándar. Carece de servidor (Serverless) por lo que no se requiere la administración de infraestructura.

            Athena nos permite trabajar directamente con SQL estándar siendo muy sencillo de implantar y comenzar a trabajar, únicamente disponiendo de habilidades SQL se pueden analizar conjuntos de datos a gran escala de forma rápida y sencilla. Tampoco es necesario realizar trabajos complejos de ETL para preparar los datos para su análisis. En proyectos de Big Data, estas fases pueden llegar a suponer un máximo del 70% del tiempo empleado durante todo el proyecto, respondiendo un 30% a procesos de análisis de datos propiamente dichos.

Se puede integrar de serie con el catálogo de datos de AWS Glue, lo que permite crear un repositorio de metadatos unificado en diversos servicios, rastrear fuentes de datos para descubrir esquemas y rellenar catálogos con definiciones de particiones, tablas nuevas, modificadas y mantener las versiones de los esquemas. Glue también ofrece capacidades de ETL para transformar datos o convertirlo en formatos de columna.

            Athena nos plantea una opción interesante a la hora de comenzar a aplicar un proceso análisis de información sobre un conjunto de datos almacenados en S3, de forma rápida y sencilla empleando técnicas de Data Mining y de esta manera reduciendo los tiempos de desarrollo e implantación al mínimo de enfoques tradicionales. 

La analítica descriptiva consiste en almacenar y realizar agregaciones de datos históricos, visualizándolos de forma que puedan ayudar a la comprensión del estado actual y pasado del negocio. La analítica descriptiva nos cuenta cómo ha funcionado nuestro negocio hasta la fecha. Nos permite, por ejemplo:

• Detectar qué fármacos tiene una mayor efectividad.
• Visualizar cómo se distribuyen geográficamente las personas que toman parte en un estudio clínico.
• Observar la evolución histórica del gasto en fármacos por periodos temporales y/o geográficos.
• Identificar qué fármacos tienen una mayor efectividad por rango de edades y/o dosis durante el estudio recibidas.
• Proyecciones de cara a futuro teniendo en cuenta el comportamiento actual.
• Clusterización, permite fijar sobre la población el conjunto de grupos posibles, en base a sus características pudiendo determinar para un nuevo individuo su cluster determinado por sus propiedades.
• Calcular y visualización de KPIs, que resumirán el estado del negocio.

¿Cómo funciona ? La analítica descriptiva se basa en trabajar sobre un sistema de almacenamiento donde se encuentran concentrados los datos de negocio. Este sistema puede tratarse de ficheros distribuidos al estilo Hadoop y derivados, bases de datos NoSQL, o sistemas SQL más tradicionales; todo ello dependiendo de la cantidad y complejidad de los datos a manejar. Sobre esta capa de almacenamiento se despliegan tecnologías que permitan el procesado de estos datos de forma que puedan efectuarse las agregaciones y consultas necesarias para el análisis. Es en este punto donde Athena nos permite una integración totalmente transparente, pudiendo procesar casi cualquier fuente de datos.

A la hora de trabajar con Athena nos podemos encontrar los siguientes componentes:

Ø  Los datos subyacentes, representados dentro de un bucket en Amazon S3.

Ø  Los metadatos, tablas y bases de datos, que serán gestionados por medio de AWS Glue Data Catalog.

Ø  Visualización y ejecución de consultas SQL estándar. Podremos trabajar directamente sobre la consola de AWS, por medio de una conexión JDBC y un visor SQL, empleando el API de Athena, o bien AWS CLI, que se trata de una herramienta de código abierto basada en el AWS SDK for Python (Boto) que proporciona comandos para interactuar con los servicios de AWS.

Ø  Herramientas de BI. De todo el abanico de posibilidades una de las más sencillas de usar y que mayor funcionalidades y capacidades de integración aporta es Tableau. Nos permiten desarrollar de una forma visual y totalmente intuitiva desarrollar el análisis de los datos, pudiendo introducir la agregaciones necesarias y la combinación de diferentes fuentes de datos.

Vamos a desarrollar un pequeño ejemplo, para ello vamos a disponer de un pequeño fichero que va a contener información sobre estudios clínicos, estos van a contener información para los diferentes pacientes con sus enfermedades asociadas, fármacos empleados, coste de los fármacos, fechas en las cuales se ha tomado parte, dosis empleadas, etc.
      
      En Athena, las tablas y bases de datos son definiciones de metadatos que definen un esquema para los datos fuente subyacentes. Se utiliza AWS Glue Data Catalog para almacenar y recuperar estos metadatos cuando se ejecutan consultas sobre el conjunto de datos subyacente. Las bases de datos son un agrupamiento lógico de tablas y al igual que las tablas, se consideran metadatos.

Los metadatos de una tabla indican a Athena dónde se encuentran los datos subyacentes (Amazon S3), especificando la estructura de los datos de origen y el esquema de la tabla (nombres de columna, tipos de datos y el nombre de la tabla). AWS Glue tiene características interesantes a la hora de descubrir automáticamente el esquema de los datos y poder extraer, transformar y cargar datos (ETL). 

Lo primero que tendremos que hacer es crear la infraestructura, para ello tendremos que crear un bucket donde vamos a alojar el conjunto de ficheros con los datos. En la siguiente imagen el segundo bucket creado corresponde con el alojamiento de nuestros datos.

Lo siguiente que haremos será crear la estructura del servicio de Athena: la BD junto con las tablas asociadas, en nuestro caso vamos a emplear una única tabla. En la siguiente imagen podemos ver la BD (datosclinicos) y la tabla asociada Historial, con el conjunto de campos definidos, junto con la especificación del formato del fichero a cargar y la localización de S3.

Debemos mencionar que será necesario dotar de todos los permisos necesarios a los usuarios que vayamos a emplear sobre Athena por medio de IAM. Para ello crearemos un usuario que tendrá los siguientes políticas: AmazonS3FullAccess, AmazonAthenaFullAccess. Sobre los bucket creados en S3, deberemos de aplicar políticas especificas de lectura sobre el bucket de datos y escritura sobre el bucket que emplea Athena para la gestión del servicio.

A la hora de ejecutar una consulta, Athena utiliza Presto como motor SQL distribuido de código abierto. Puede procesar datos de diferentes orígenes de datos, incluido HDFS (Hadoop Distributed File System) y Amazon S3.

            La visualización y ejecución de las consultas, al disponer de conexión por medio de JDBC podremos emplear multitud de herramientas, como por ejemplo DBeaver. Bastará con que descarguemos y configuremos el driver para acceder correctamente y comenzar a trabajar.

            Trabajar con una herramienta de BI, como Tableau, nos aportará una potencia extra en el análisis. Como hemos mencionado antes nos aportará una solución completa de una forma sencilla, nos basta con ir componiendo los datos sobre los que se basa nuestro análisis de forma visual y en caso de que fuera necesario calcular algún agregado de forma sencilla lo podremos desarrollar, como por ejemplo en la imagen adjunta "% Efectividad". En la siguiente imagen estamos analizando la efectividad de los fármacos sobre las diferentes provincias de la comunidad autónoma de Andalucía para un subconjunto de enfermedades (Alergia, Colesterol, Diabetes, Migraña, Problemas Cardíacos y Tumores), de forma anual, realizando un pronóstico de cara a los próximos dos años basado en la media de la información recopilada.

AWS Lambda

La computación dentro de una solución Big Data esta soportada por medio del servicio AWS Lambda (entre otros), que permite ejecutar código sin aprovisionar ni administrar servidores. Se trata de uno de los servicios más interesantes de la plataforma donde únicamente se paga por el tiempo de ejecución de las funciones, por cada 100 ms que el código se ejecute y no por el número de veces que se activa el código. Cuando AWS Lambda ejecuta una función Lambda, se encarga de aprovisionar y administrar los recursos necesarios para ejecutar la función. Al crear una función Lambda, se especifica información de configuración, como la cantidad de memoria y el tiempo de ejecución máximo que se desea permitir. 

Cuando se invoca una función Lambda, AWS Lambda lanza un contenedor (es decir, un entorno de ejecución) basado en los ajustes de configuración que se han  proporcionado. Se necesita tiempo para configurar el contenedor y hacer el bootstrapping necesario, lo que añade latencia cada vez que se invoca la función Lambda. Esta latencia se observa cuando se invoca una función Lambda por primera vez o después de que se ha actualizado, AWS Lambda intenta reutilizar el contenedor para invocaciones posteriores de la función. Después de ejecutar una función Lambda, AWS Lambda mantendrá el contenedor durante algún tiempo en previsión de otra invocación de la función Lambda. 

            En la siguiente imagen mostramos cómo funcionan las funciones Lambda.

            Podemos escribir las funciones Lambda en 4 lenguajes principalmente:

• Node.js
• Java
• C#
• Phyton

El modelo de programación nos aporta un conjunto de características que debemos tener en cuenta:

• Handler. Es la función AWS Lambda para iniciar la ejecución de nuestra función Lambda.  Cuando se invoca una función Lambda, AWS Lambda comienza a ejecutar su código llamando a la función del manejador. AWS Lambda pasa todos los datos de eventos a este controlador como el primer parámetro. El manejador debe procesar los datos de eventos entrantes y puede invocar cualquier otra función / método dentro del código aportado.
• Contexto (interacción en tiempo de ejecución). AWS Lambda también aporta  un objeto de contexto a la función Handler como segundo parámetro. Por medio de este objeto de contexto, el código puede interactuar con AWS Lambda. Por ejemplo, puede controlar el tiempo de ejecución restante antes de que AWS Lambda termine la ejecución de la función Lambda. Para lenguajes como Node.js, existe una plataforma asíncrona que utiliza devoluciones de llamada. AWS Lambda proporciona métodos adicionales sobre este objeto de contexto. 
• Registro. La función Lambda puede contener declaraciones de registro. AWS Lambda escribe estos registros en los registros de CloudWatch. 
• Excepciones. La función Lambda puede requerir comunicar el resultado de la ejecución a AWS Lambda. Dependiendo del lenguaje en el que haya creado el código de función Lambda existen diferentes maneras de finalizar una solicitud con éxito o de notificar a AWS Lambda un error durante la ejecución. Si se invoca la función de forma síncrona, AWS Lambda reenvía el resultado al cliente.

A continuación mostramos el código de una handler básico desarrollado en Python:

Temperatura de Datos y Acceso

El concepto de temperatura de datos y acceso podemos aplicar lo desde dos componentes y siempre teniendo en cuenta el contexto sobre el cual estamos trabajando:

• La temperatura de los datos hace referencia al momento en el cual se han producido esos datos, por ejemplo si nos encontramos en medio de una conferencia y alguno de los asistentes realiza una publicación sobre la misma, podemos hablar que ese dato es muy caliente, puesto que acaba de producirse en la línea temporal. En función del negocio en el que nos encontremos, la temperatura de los datos influirá en mayor medida en la toma de decisiones y en los análisis que debamos realizar.
• Acceso, vendrá determinado por el instante en el que accederemos a los datos, por ejemplo siguiendo el caso anterior, si almacenamos y analizamos un histórico de publicaciones de hace un año, estos serán datos menos calientes, siendo además su volumen mayor que los producidos en el día de hoy.  

            Este factor debe ser tenido en cuenta a la hora de diseñar una solución de Big Data al determinar las necesidades de almacenamiento a corto, medio y largo plazo y por supuesto el coste requerido. La temperatura de los datos inicialmente se puede clasificar en los siguientes tipos:

• Calientes, datos que se acaban de generar con un % de acceso muy elevado.
• Templados, datos con un cierto componente temporal que disponen de un % de acceso muy elevado.
• Fríos. datos básicamente históricos.

            En la siguiente imagen podemos ver una tabla donde para esta clasificación, que nos muestra órdenes de magnitud a tener en cuenta en el tratamiento de los mismos sobre diferentes variables como son el volumen de datos, el tamaño de los elementos, latencia, durabilidad, velocidad de respuesta durante el análisis de datos y el costo previsto para su almacenamiento.