¿Qué es Perseo?

Perseo es una solución Big Data para el análisis predictivo del comportamiento de agentes como usuarios en un centro comercial o máquinas en un entorno de producción. El objetivo del proyecto, que aún está en desarrollo, es poder predecir acciones o estados en el corto plazo, a partir de la monitorización continua de estas entidades.

¿Por qué Perseo?

Con más de 13 mil millones de dispositivos ya conectados en el mundo, y varios millones que entran en funcionamiento cada semana, la enorme cantidad de datos en tiempo real abre abrumadores y emocionantes interrogantes que esperan contestación cuando se analicen áreas decisivas para nuestro bienestar.

La visión de Perseo es incorporar al paradigma de Big Data una herramienta para el tratamiento, análisis y predicción sobre estos flujos de datos. Como resultado, se pretende superar los límites de eficiencia y escalabilidad actuales en el manejo de estos datos (que pueden modelarse con un instrumento matemático como las series temporales) y, de esta forma, desarrollar una solución que permita a las empresas añadir y utilizar esta tecnología de forma sencilla. Perseo pondrá a disposición tanto la algoritmia de Spark, adaptada al manejo de series ordenadas de datos en el tiempo, como nuevos algoritmos implementados sobre este framework para resolver la problemática de las series temporales.

Aspectos innovadores

Entre los aspectos innovadores que presentamos, se propone la implementación de una plataforma Big Data, capaz de llevar a cabo el tratamiento y la visualización en tiempo real de comportamientos o acciones de entidades generadoras continuas de datos, como el dispositivo móvil de un usuario o una máquina industrial.

Para ello, en el proyecto se han propuesto algoritmos novedosos no incluidos en Spark, así como nuevas estructuras de datos que permiten el manejo de series temporales en un entorno distribuido, un problema no resuelto hasta el momento en Spark. Por último, se han adaptado los algoritmos previamente disponibles en Spark para su utilización con esta estructura de datos.

Las ventajas innovadoras de este enfoque son:

• Un sistema altamente escalable para cubrir las necesidades de una nueva generación de servicios basados en la abundancia de datos procedentes de GPS, sensores, Smartphones, maquinarias, etc.
• Una mejora cualitativa del almacenamiento, análisis, predicción y visualización de la información en tiempo real.
• Una solución con reducciones muy apreciables de costes para las empresas, con impacto especial en las pymes. Esta reducción es posible gracias a que ya estaría incorporada toda la algoritmia y sólo habría que hacer uso de ella. Todo el análisis y estudio estaría realizado.

Objetivos técnicos

Entre los objetivos técnicos del proyecto, cabe citarse los siguientes:

• Investigar, diseñar e implementar una solución de adaptación automática de modelos predictivos aplicados a motores de predicción en tiempo real.
• Validar el concepto tecnológico software/hardware propuesto, incluyendo los aspectos de probabilidad de error, escalabilidad, latencia, etc.
• Definir una estructura de datos que permita el procesado distribuido de series temporales en Spark (RDD no garantiza el orden).
• Evaluar el modelo de negocio propuesto, incluyendo time-to-market, nicho de mercado, ventajas competitivas frente a la competencia, etc.

Características técnicas y funcionales

La base fundamental de Perseo es el procesado de series temporales. Para ello, identificamos tres fases diferentes.

• Transformación de los datos a la estructura de almacenamiento definida. Para el manejo de series temporales en Spark, hemos definido la estructura TimeLabeledPoint. Ésta contiene tres campos esenciales: i) una lista ordenada de las muestras de la serie que serán utilizadas para hacer la predicción, ii) el valor objetivo de la predicción (target) que precisamos para el modelado, y iii) el instante de tiempo asociado con este valor objetivo. Por tanto, ante una fuente de datos estructurada en pares (tiempo, valor), la primera etapa del tratamiento será la transformación a la nueva estructura definida. Posteriormente, el conjunto de TimeLabeledPoint resultante puede ser distribuido en RDD para su manejo en Spark.
• Fase Batch: En esta fase entrenamos los modelos de datos. Éstos capturan la dependencia entre un valor de la serie y su comportamiento previo para, posteriormente, poder realizar las predicciones. En esta fase Batch utilizaremos Spark y Cassandra para poder resolver la problemática.
• Fase Streaming: En esta segunda fase ya dispondremos de los modelos entrenados y preparados para realizar las predicciones. La información irá llegando en tiempo real a través de Kafka y la procesaremos para ir haciendo las predicciones. En esta fase utilizaremos Kafka, Spark Streaming y Cassandra.

¿Por qué utilizamos Spark, Kafka y Cassandra?

Spark

El proyecto se basa en Spark como framework de procesado distribuido para garantizar la escalabilidad de la solución.

• Spark nos da mucha más potencia que Hadoop

Para empezar, Spark es un framework de análisis distribuido en memoria y nos permite ir más allá de las operaciones en batch de Hadoop MapReduce: procesamiento de streaming, machine learning (MLlib), cálculo de grafos (GraphX), integración con lenguaje R (Spark R) y análisis interactivos.

• Spark es rápido, muy rápido

Spark puede ejecutar análisis de varios órdenes de magnitud más rápido que los despliegues de Hadoop existentes. Esto significa una mayor interactividad, experimentación más rápida y mayor productividad para los analistas.

• Spark puede coexistir con tu arquitectura de Big Data

Se ha invertido bastante en clusters con Hadoop. Para Spark esto no es un problema puede coexistir con las instalaciones existentes de Hadoop y añadir nuevas funcionalidades. Spark se integra perfectamente con Hadoop y en muchos de nuestros proyectos utilizamos/almacenamos los datos que están en el sistema de fichero de Hadoop HDFS y/o ejecutamos los procesos de Spark usando YARN de Hadoop 2.0. Además puede funcionar con muchos otros productos de Big Data como: CassandraDB, Google Big Query, almacenamiento de Amazon S3, ElasticSearch, etc.

• Spark entiende SQL

SQL es la lingua franca del mundo de datos estructurados y el módulo Spark Sql es capaz de usar fuentes de datos existentes (HIVE, CassandraDB, MongoDB, JDBC, etc). Se puede usar para gestionar las fuentes internas de datos (RDDs - DataFrames) como si fueran tablas estructuradas.

• Spark mima a los desarrolladores

Cuando una tecnología encanta a los desarrolladores se convierten en early adopters y empiezan a usarla y disfrutarla. Spark es un ejemplo de esto, cuando usan Spark solo tienen que dedicarse a resolver el problema. Spark se ha programado con el lenguaje Scala que es un nuevo lenguaje funcional y orientado a objetos. Además se puede programar en Python, R e incluso en Java.

• Spark encaja perfectamente con la Arquitectura Kappa

El tándem Kafka + Spark + NOSql + Scala que forman la Arquitectura Kappa se está convirtiendo en la solución más demandada en proyectos Big Data.

Kafka

• Rápido

Un único Broker de Kafka puede manejar cientos de megabytes de lecturas y escrituras por segundo desde miles de clientes.

• Escalable

Kafka está diseñado para permitir que un solo cluster sirva como el eje central de datos para una organización grande. Puede ser ampliado elásticamente sin tiempo de inactividad.

• Duradero

Los mensajes se persisten en disco y se replican dentro del clúster para evitar la pérdida de datos. Cada Broker puede gestionar terabytes de mensajes sin impacto.

• Distribuido

Kafka cuenta con un diseño de cluster-centric que ofrece durabilidad y garantías de tolerancia a fallos.

Cassandra

• Descentralizado

Todos los nodos del clúster tiene el mismo rol. No hay un único punto de fallo. Los datos se distribuyen a través del clúster (por lo que cada nodo contiene datos diferentes). No existe un nodo maestro por lo que cada nodo puede dar servicio a cualquier solicitud.

• Soporta replicación y replicación de múltiples data center

Las estrategias de replicación son configurables. Cassandra está diseñado como un sistema distribuido para el despliegue de un gran número de nodos a través de múltiples centros de datos. La arquitectura distribuida de Cassandra está diseñada para desplegarse sobre múltiples data center, tener redundancia y recuperarse ante desastres.

• Escalabilidad

El rendimiento de leer y escribir aumenta linealmente a medida que se añaden nuevos nodos. Se pueden agregar nuevos nodos sin necesidad de interrumpir la ejecución de la aplicación.

• Tolerancia a fallos

Los datos se replican automáticamente a múltiples nodos para recuperarse frente a fallos. Cassandra soporta replicación a través de múltiples datacenter. Se puede reemplazar nodos que presenten fallos sin tiempo de inactividad o interrupción de la aplicación.

• Consistencia

Se ofrece la elección del nivel de consistencia para las lecturas y escrituras.

• Lenguaje de consulta

Cassandra introduce CQL (Cassandra Query Language), una alternativa similar a SQL para la interfaz RPC tradicional.

Casos de uso

En Perseo hemos trabajado con dos casos de uso. En el primero de ellos, utilizamos algoritmos de clasificación para identificar, en tiempo real, qué acción está realizando un usuario. El segundo caso de uso consiste en la utilización de algoritmos de regresión para predecir valores de una serie temporal. En este caso hemos utilizado un conjunto de datos que representa la potencia energética de una casa inteligente.

Caso de Uso de acciones de usuario

Para este caso de uso hemos utilizado el siguiente dataset:

https://archive.ics.uci.edu/ml/datasets/Activity+Recognition+from+Single+Chest-Mounted+Accelerometer

Contiene los datos (sin calibrar) de un sensor acelerómetro. Hay registros de 15 participantes que realizan 7 actividades. El conjunto de datos proporciona desafíos para la identificación y autenticación de personas que utilizan los patrones de movimiento. Las actividades que puede realizar el usuario son:

• Trabajando en el ordenador
• Levantándose, andando y subiendo escaleras
• En pie
• Andando
• Bajando escaleras
• Andando y hablando con alguien
• Andando mientras que está de pie

Por lo tanto, lo que hacemos es analizar las posiciones X, Y y Z del acelerómetro para identificar la actividad a realizar. Cada una de estas tres coordenadas representa una serie temporal. El objetivo es analizar un segmento de varios segundos e indicar, automáticamente, qué acción se está llevando a cabo. En nuestros experimentos, utilizamos segmentos de 10 segundos. Dado que la frecuencia de muestreo del sensor es de 52 Hz, este segmento supone el procesado de 520 muestras por cada una de las coordenadas.

Para implementar el clasificador, hemos diseñado una estrategia en dos fases:

• Extracción de características. En primer lugar, hemos identificado los parámetros de la serie que contiene información característica de acción en curso. Para ello, hemos realizado el análisis de la serie tanto en el dominio del tiempo como de la frecuencia. En este último caso, ha sido necesario realizar el cálculo de la densidad espectral de potencia (DEP) de la señal, mediante la transformada rápida de Fourier (FFT). Las siguientes figuras muestran el segmento promedio en cada categoría tanto en tiempo como en frecuencia. Como resultado, se ha definido un conjunto de atributos como la media o la desviación típica, en el caso del análisis en el dominio del tiempo, o el ancho de bando del 50% o el 90%, a partir del análisis en frecuencia, que proporcionan una descripción de las propiedades dinámicas de la señal.

• A partir de un conjunto de entrenamiento formado por pares que incluyen el conjunto de características descriptivas de un segmento y la actividad asociada al mismo, se ha implementado un clasificador basado en técnicas machine learning. En este punto, se han evaluado diferentes algoritmos de clasificación (multicategoría) como los árboles de decisión o los random forest.

Los resultados obtenidos por los modelos han sido bastante óptimos. Por encima del resto, destaca el algoritmo de DecisionTree y de Random Forest. El mejor rendimiento de estos algoritmos en comparación con otros como la regresión logística o naïve Bayes refleja la naturaleza no lineal del problema de clasificación.

Caso de Uso de la potencia en una casa

Para este caso de uso hemos utilizado el siguiente dataset:

http://archive.ics.uci.edu/ml/datasets/Individual+household+electric+power+consumption

Contiene 2.075.259 muestras generadas entre Diciembre del 2006 y Noviembre de 2010, que hacen un total de 47 meses. Son muestras generadas cada minuto en una vivienda inteligente.

El dataset nos presentaba diferentes variables, pero nos hemos quedado con la potencia activa medida en Kw para hacer las predicciones sobre valores futuros.

Como hemos comentado anteriormente, el valor añadido de Perseo ha sido realizar predicciones en tiempo real sobre series temporales, para ello hemos implementado nuevos algoritmos de regresión en Spark (como redes neuronales de funciones de base radial, K vecinos próximos y optimización mediante mínimos cuadrados) y hemos adaptado los ya existentes en Spark para resolver predicciones de series temporales.

El modelado de la serie temporal se basa en técnicas machine learning. Así, a fin de modelar la dependencia entre el valor de la serie en un instante y su comportamiento en instantes anteriores, hemos tomado estos pares para entrenar un algoritmo experto.

Para resolver la problemática en cuanto a la ordenación de los valores en la serie, hemos creado la estructura TimeLabeledPoint, que contiene el valor objetivo, el instante de tiempo del mismo y el conjunto de valores previos. Este conjunto viene determinado por la longitud de la ventana de tiempo que el usuario ha de fijar. Así, se toman los N eventos anteriores para poder hacer una predicción, con N determinado por la longitud de la ventana y la frecuencia de muestreo de la serie. Los resultados han sido realmente buenos. Podemos ver una comparativa de los diferentes algoritmos utilizados:

Y en la siguiente imagen podemos ver una comparativa entre el valor real, y la predicción según el algoritmo linear regression basado en SGD y en OLS:

Contribución y valor añadido

El valor añadido del proyecto se basa en la predicción sobre el comportamiento inmediato de consumidores finales. Esta información puede proporcionar grandes beneficios a las empresas.

Otra de las contribuciones que hemos realizado en el proyecto es la creación de nuevos algoritmos que no estaban distribuidos en Spark.

Otra de las mayores aportaciones ha sido la realización de predicciones en series temporales, que es algo muy importante porque Spark no garantiza el orden.

Y por último la última contribución, es una capa visual para poder ir viendo en tiempo real las predicciones y poder monitorizar lo sucedido.