Estudio y aplicación de tecnologías de fast data y fog computing a las smart cities

Texto completo

(1)25/01/2017. Escuela Técnica Superior de Ingeniería de Sistemas Informáticos Máster en Software de Sistemas Distribuidos y Empotrados Trabajo de fin de master: Estudio y aplicación de tecnologías de Fast Data y Fog Computing a las Smart Cities. D. Álvarez Argüero, Lucas TUTORES ACADEMICOS: D. Arévalo Viñuales, Sergio Dña. Muñoz Fernández, Isabel TUTOR PROFESIONAL: D. López Peña, Miguel Ángel FECHA: 01/2017.

(2) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 2 de 181. 2.

(3) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 3 de 181. Índice 1 | Introducción................................................................. 10 1.1 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6 1.2. Motivaciones Smart Cities Internet Of Things Big Data Fast Data Fog computing Conclusiones Objetivos. 10 10 12 15 17 18 21 23. 2 | Estudios previos ........................................................... 26 2.1 Estudio del problema 2.1.1 Parámetros a monitorizar 2.2 Estado del arte 2.2.1 Fog computing 2.2.1.1 Cisco 2.2.1.2 Kafka 2.2.1.3 Edgent 2.2.2 Sistemas publicador subscripor 2.2.2.1 MQTT 2.2.2.2 Watson IoT Platform 2.2.2.3 Kafka 2.2.3 Fast Data 2.2.3.1 Spark streams 2.2.3.2 Apache Storm 2.2.3.3 Akka Streams 2.2.3.4 Apache Bean 2.2.3.5 Kafka streams 2.2.3.6 IBM Streams 2.2.4 Almacenamiento 2.2.4.1 Base de datos relacional. 2.2.4.2 Base de datos no relacional. 2.2.4.3 SQL sobre bases de datos no relaciones. 2.3 Arquitectura del sistema 2.3.1 Posibles Arquitecturas conceptuales. 2.3.1.1 Arquitectura conceptual. 2.3.1.2 Posibles arquitecturas reales 2.3.1.3 Posibles arquitecturas fisicas.. 26 26 28 28 28 29 30 31 32 35 36 37 38 40 42 43 46 46 47 48 48 49 50 50 51 52 54. 3.

(4) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 4 de 181. 2.3.2 Arquitectura final. 2.4 Especificación de requisitos de software 2.4.1 Introducción 2.4.1.1 Propósito 2.4.1.2 Ámbito 2.4.1.3 Referencias 2.4.2 Descripción General 2.4.2.1 Perspectivas del producto 2.4.2.1.1 Interfaces del sistema 2.4.2.1.2 Interfaces de usuario 2.4.2.1.3 Interfaces hardware 2.4.2.1.4 Interfaces Software 2.4.2.1.5 Interfaces de cominicacion 2.4.2.1.6 Restricciones de memoria 2.4.2.1.7 Operaciones 2.4.2.1.8 Requisitos de despliegue 2.4.2.2 Funciones del producto 2.4.2.3 Características del usuario 2.4.2.4 Restricciones 2.4.2.5 Suposiciones y dependencias. 2.4.2.6 Requisitos pospuestos. 60 65 65 65 65 65 65 65 66 68 68 69 70 71 72 72 72 72 72 73 73. 3 | Planificacion y presupuesto .......................................... 74 4 | Desarrollo de la aplicación ............................................ 77 4.1 Tecnologias y hardware utilizado 4.1.1 Capa IoT 4.1.1.1 Creación de un prototipo real 4.1.1.2 Obtención de datos de fuentes existentes. 4.1.1.3 Generación de datos simulados. 4.1.2 Capa publicador/subscriptor. 4.1.3 Capa Fast Data 4.1.3.1 Sistema de procesamiento 4.1.3.2 Sistema de almacenamiento 4.1.4 Capa presentación 4.1.4.1 Servidor Web 4.1.4.2 Pagina Web 4.1.4.3 Servidor Rest 4.2 Especificaciones del sistema 4.2.1 Limites del sistema 4.2.2 Casos de uso. 77 77 77 80 80 80 82 82 86 88 88 90 90 91 91 91. 4.

(5) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 5 de 181. 4.3 Descripción de la aplicación 4.3.1 Dagramas de clase 4.3.1.1 Simulador. 4.3.1.2 Procesador principal. 4.3.1.3 Interfaz de datos 4.3.1.4 Servidor web 4.3.1 Diagramas de actividad y estado. 4.3.1.1 Simulador. 4.3.1.2 Procesador principal. 4.3.1.3 Interfaz de datos. 4.3.1.4 Servidor web 4.4 Pruebas 4.5 Despliegue 4.5.1 Despliegue de desarrollo 4.5.2 Despliege empresarial. 106 106 107 113 128 145 148 148 149 149 162 162 165 166 167. 5 | Manual ...................................................................... 170 5.1 5.2 5.3 5.4 5.5 5.6. Accediendo al interfaz por primera vezx Añadiendo una vista Visionado de la graficas Eliminando una lista Guardar una configuracion de vistas Cargar una configuracion de vistas. 170 172 172 173 174 174. 6 | Conclusiones .............................................................. 176 7 | Lecciones aprendidas ................................................. 177 8 | Glosario ..................................................................... 179 9 | Referencias ................................................................ 180. 5.

(6) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 6 de 181. Índice ilustraciones Ilustración 1 Imagen promocional Smart Cities ....................................................................11 Ilustración 2 Imagen promocional IoT ....................................................................................13 Ilustración 3 Análisis en tiempo real del tráfico por google Maps .....................................14 Ilustración 4 Imagen promocional Big Data ..........................................................................15 Ilustración 5 Las 4 uves de Big Data .....................................................................................16 Ilustración 6 Ejemplo de despliegue Fast data aplicado a la empresa.............................18 Ilustración 7 Imagen promocional Fog Computing ..............................................................19 Ilustración 8 Ejemplo arquitectura Fog computing ...............................................................20 Ilustración 9 Ejemplo despliegue Fog computing ................................................................21 Ilustración 10 Imagen promocional Smart Cities..................................................................22 Ilustración 11 Las 4 capas base del proyecto ......................................................................23 Ilustración 12 Despliegue fog computing de ejemplo de Cisco .........................................28 Ilustración 13 Arquitectura Fog computing de Cisco ...........................................................29 Ilustración 14 Logo Kafka ........................................................................................................29 Ilustración 15 Logo Edgent ......................................................................................................30 Ilustración 16 Vista de la interfaz web de administración de Edgent................................31 Ilustración 17 Despliegue de ejemplo de Edgent .................................................................32 Ilustración 18 Logo MQTT .......................................................................................................32 Ilustración 19 Despliegue de ejemplo MQTT........................................................................33 Ilustración 20 Despliegue distribuido con niveles de jerarquía de MQTT ........................33 Ilustración 21 Despliegue distribuido con balanceador de carga de MQTT ....................34 Ilustración 22 Logo IBM Watson .............................................................................................35 Ilustración 23 Despliegue de ejemplo de Watson ................................................................35 Ilustración 24 Arquitectura Kafka ............................................................................................36 Ilustración 25 Despliegue completo Fast Data .....................................................................37 Ilustración 26 Despliegue completo Big Data .......................................................................38 Ilustración 27 Logo Spark Streaming .....................................................................................38 Ilustración 28 Ejemplo de DAG (Directed Acyclic Graph)...................................................39 Ilustración 29 Paso de datos de tipo Stream a micro Batches ..........................................39 Ilustración 30 Orden de procesamiento de los micro batches ...........................................40 Ilustración 31 Logo Apache Storm .........................................................................................41 Ilustración 32 Arquitectura de trabajo de apache Storm.....................................................41 Ilustración 33 Logo Akka..........................................................................................................42 Ilustración 34 Jerarquía de actores de Akka ........................................................................43 Ilustración 35 Logo apache Beam ..........................................................................................44 Ilustración 36 Unificación de lenguajes en Beam ................................................................45 Ilustración 37 Arquitectura de Apache Kafka........................................................................46 Ilustración 38 Logo IBM Streams ...........................................................................................47 Ilustración 39 Primer modelo de arquitectura conceptual ..................................................51 Ilustración 40 Segundo modelo de arquitectura conceptual ..............................................52 Ilustración 41 Tercer modelo de arquitectura conceptual. ..................................................52 Ilustración 42 primer modelo de posible despliegue del sistema ......................................53 Ilustración 43 Segundo modelo de posible despliegue del sistema .................................54 Ilustración 44 Despliegue de dispositivos con tecnología red móvil .................................55. 6.

(7) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 7 de 181. Ilustración 45 Despliegue físico de dispositivos con una red del tipo malla ....................56 Ilustración 46 Despliegue físico de motas con tecnología centralizada ...........................58 Ilustración 47 Despliegue fisico de motas centralizado con mas de una central. ...........59 Ilustración 48 Despliegue final de las tecnologías del sistema ..........................................61 Ilustración 49 Despliegue final de las tecnologías del sistema detallado ........................62 Ilustración 50 Despliegue físico final......................................................................................64 Ilustración 51 Diagrama de componentes del sistema .......................................................66 Ilustración 52 diseño de la interfaz gráfica a implementar .................................................68 Ilustración 53 Tabla de planificación de trabajo. ..................................................................75 Ilustración 54 Completado/costes ..........................................................................................76 Ilustración 55 Raspberry Pi 3 ..................................................................................................77 Ilustración 56 Sonar ..................................................................................................................78 Ilustración 57 GPS Ublock .......................................................................................................79 Ilustración 58 Generación de áreas con el movimiento del GPS ......................................79 Ilustración 59 Arquitectura de kafka implementada al sistema ..........................................81 Ilustración 60 Arquitectura de elementos de Streams ........................................................84 Ilustración 61 Arquitectura interna IBM..................................................................................85 Ilustración 62 Arquitectura de nodos de Streams ................................................................86 Ilustración 63 Arquitectura de HDFS......................................................................................87 Ilustración 64 Arquitectura HBASE ........................................................................................88 Ilustración 65 funcionamiento del servidor Web ..................................................................89 Ilustración 66 Diagrama general de actores .........................................................................91 Ilustración 67 Diagrama de casos de uso del sistema ........................................................92 Ilustración 68 Diagrama de flujo del simulador ..................................................................112 Ilustración 69 Diagrama de flujo del procesador principal ................................................127 Ilustración 70 Diagrama de clases de la interfaz de datos ...............................................144 Ilustración 71 Diagrama de clases del servidor Web ........................................................147 Ilustración 72 Diagrama de estados del componente TruckRSim ..................................148 Ilustración 73 Diagrama de estados del componente Container_...................................149 Ilustración 74 Diagrama de secuencia: Integral de calidad del servicio .........................150 Ilustración 75 Diagrama de secuencia: Integral de calidad del servicio (versión simulación) ........................................................................................................................151 Ilustración 76 Diagrama de secuencia: Última medición ..................................................152 Ilustración 77 Diagrama de secuencia: Mediciones de lo n últimos días .......................153 Ilustración 78 Diagrama de secuencia: Mediciones de lo n últimos días (versión simulación) ........................................................................................................................154 Ilustración 79 Diagrama de secuencia: Máximos, mínimos y medias de lo n últimos días. ...................................................................................................................................155 Ilustración 80 Diagrama de secuencia: más, min y medias de los n últimos días (versión simulación). .......................................................................................................156 Ilustración 81 Diagrama de secuencia: Porcentaje del último día. .................................157 Ilustración 82 Diagrama de secuencia: Porcentajes de los N últimos días ...................158 Ilustración 83 Diagrama de secuencia: Porcentajes de los N últimos días (versión simuladora) .......................................................................................................................159 Ilustración 84 Diagrama de secuencia: Predicción continua............................................160 Ilustración 85 Diagrama de secuencia: Predicción de máximos. ....................................161 Ilustración 86 Diagrama de secuencia: Solicitud Web ......................................................162. 7.

(8) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 8 de 181. Ilustración 87 Arquitectura Kappa ........................................................................................165 Ilustración 88 Despliegue de desarrollo ..............................................................................166 Ilustración 89 Despliegue Empresarial ................................................................................169 Ilustración 90 Panel de inicio.................................................................................................171 Ilustración 91 Añadir nuevo panel ........................................................................................172 Ilustración 92 Grafica de muestra.........................................................................................173 Ilustración 93 Botón de eliminar. ..........................................................................................173 Ilustración 94 Guardar una vista ...........................................................................................174 Ilustración 95 Cambiar una vista ..........................................................................................175. 8.

(9) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 9 de 181. Índice tablas Tabla 1 Presupuesto.................................................................................................................75 Tabla 2 Requisitos de Hardware ............................................................................................82 Tabla 3 Requisitos del SO .......................................................................................................83 Tabla 4 Caso de uso: Recargar Web.....................................................................................93 Tabla 5 Caso de uso: Leer predicciones ...............................................................................94 Tabla 6 Caso de uso: Leer predicciones máximas ..............................................................95 Tabla 7 Caso de uso: Leer mediciones .................................................................................95 Tabla 8 Caso de uso: Leer última predicción .......................................................................96 Tabla 9 Caso de uso: Leer máximos, mínimos y medias ...................................................97 Tabla 10 Caso de uso: Leer última proporción diaria..........................................................97 Tabla 11 Caso de uso: Leer proporciones diarias ...............................................................98 Tabla 12 Caso de uso: Leer datos .........................................................................................99 Tabla 13 Caso de uso: Generar datos de simulación .........................................................99 Tabla 14 Caso de uso: Leer valor ........................................................................................100 Tabla 15 Caso de uso: Recibir Datos ..................................................................................101 Tabla 16 Caso de uso: Diezmar ...........................................................................................101 Tabla 17 Caso de uso: Predecir máximo ............................................................................102 Tabla 18 Caso de uso: Calcular máximo, mínimo y media ..............................................102 Tabla 19 Caso de uso: Predecir en modo continuo ..........................................................103 Tabla 20 Caso de uso: Integrar ............................................................................................104 Tabla 21 Caso de uso: Enviar Datos ...................................................................................104 Tabla 22 Caso de uso: Introducir datos ...............................................................................105. 9.

(10) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 10 de 181. 1 |. Introducción. 1.1. Motivaciones. Como cualquier proyecto, se debe tener unas buenas motivaciones para justificar el desarrollo del mismo, en este caso, es la implementación de tecnologías de la información y el procesado en el ámbito de las Smart Cities, por lo que las motivaciones se han escrito de manera organizada por conceptos.. 1.1.1. Smart Cities. Desde siempre una ciudad ha podido ofrecer una cantidad de información increíblemente grande y valiosa, pero hasta hace poco más de una década era imposible captar dicha información y mucho menos obtener el valor real de ella. Actualmente las urbes están en continua expansión, por ello cada vez se necesita invertir más recursos en la gestión de los servicios, puesto que esos cada vez se vuelven más voluminosos y complejos, por otro lado, esta expansión también suele afectar a la calidad de vida, los ciudadanos cada vez exigen la mejora de servicios o la creación de nuevos. En este punto entra el concepto de Smart City que permite suplir dichas exigencias.. Smart Cities o ciudades inteligentes es el concepto que engloba parte de esta filosofía, se basa en obtener información de la ciudad para poder aprovecharla, es decir, al tener una ciudad monitorizada podemos usar los datos para ofrecer nuevos servicios, optimizar los actuales u obtener valores añadidos.. 10.

(11) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 11 de 181. Ilustración 1 Imagen promocional Smart Cities. En marzo de 2015, se publicó el plan nacional de ciudades inteligentes, en el cual se les ofrecía un presupuesto de 152,9 millones de euros, centrándose en las cinco ramas principales: transportes, residuos, e-Sanidad, energía y gobernabilidad. Este hecho que advierte que España y Europa están más que interesadas dicho concepto, puesto que puede llevar al ahorro de costes, optimización de servicios o creación de nuevos, que hasta el momento no eran posibles, lo que aumentaría la calidad de vida. . Transportes: La optimización del transporte cubre campos como la administración de las redes de transporte público, el ofrecer información adicional sobre el mismo, el control del tráfico, etc… Este punto es muy importante puesto que casi toda la industria y los servicios dependen de este factor, por lo que su optimización y mejora influirá directamente sobre la eficiencia de la ciudad en sí.. . Residuos: Con el aumento de la población, la gestión residuos se ha vuelto mucho más compleja, las razones son: Por un lado, la cantidad de residuos, que está en continuo aumento y por otro, la variedad del ellos, en este punto las ciudades inteligentes. 11.

(12) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 12 de 181. requieren mecanismo de recolección de datos que sirva para la mejora y optimización en la recogida y en su tratamiento. . Energía: Otro punto muy importante con gran margen de optimización y mejora es la energía, gracias al uso de la información recogida tanto en los productores como en los usuarios de la misma se puede optimizar el sistema.. . E-sanidad: Entre los muchos puntos que ofrece este sector se encuentra e pronóstico, prevención y seguimiento de enfermedades, la personalización del sistema sanitario, mejora de servicios relacionados con la atención en salud, el seguimiento de indicadores del estado de salud, registro metódico de datos e informes del estado de salud del paciente.. . Gobernabilidad: Actualmente gracias a la capacidad de los servicios TIC los ciudadanos exigen cada vez más información sobre o que ocurre en el gobierno y su entorno por lo que otro de los puntos importantes de una ciudad inteligente es la transparencia de información.. Un buen ejemple es lo que expone Santiago Olivares, Consejero Delegado de Ferrovial Servicios, en el Libro Blanco de las Smart Cities: [1] “El movimiento de Smart Cities es una apuesta clara para la mejora del atractivo y la habitabilidad de nuestras ciudades, apoyándose en un modelo de gestión más eficiente y sostenible. El reto es saber aprovechar el gran volumen de información que proporcionará una sociedad hiperconectada. El éxito vendrá del talento que nuestra sociedad tenga para sumar las capacidades de nuestras ciudades, nuestros ciudadanos y nuestras empresas.”. Pero para llegar al concepto de Smart Cities tenemos que pasar por una serie de conceptos y filosofías que nos permitirán llegar a ofrecer todas sus funcionalidades. Estos conceptos son: “Internet of Things”, Big Data, …. En los apartados siguientes se definirán dichos conceptos.. 1.1.2. Internet Of Things. El primero de dichos conceptos es IoT. Actualmente Internet of things (internet de las cosas) que es muy mencionado en muchos campos de desarrollo diferentes, pero ¿qué es el internet de las cosas? y ¿cómo puede afectar al día a día de una ciudad?. 12.

(13) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 13 de 181. Ilustración 2 Imagen promocional IoT Como buena introducción lo mejor será citar el documento de Kevin Aston llamado “Esa cosa del “Internet de las Cosas” publicado en el RFID Journal [2] . Una mayoría de los casi 50 Petabytes (un Petabyte son 1024 terabytes) de datos disponibles en internet fueron inicialmente creados por humanos, a base de teclear, presionar un botón, tomar una imagen digital o escanear un código de barras. Los diagramas convencionales de internet. Dejan fuera a los routers más importantes de todos: las personas. El problema es que las personas tienen un tiempo, una atención y una precisión limitados, y no se les da muy bien conseguir información sobre cosas en el mundo real. Y eso es un gran obstáculo. Somos cuerpos físicos, al igual que el medio que nos rodea. No podemos comer bits, ni quemarlos para resguardarnos del frío, ni meterlos en tanques de gas. Las ideas y la información son importantes, pero las cosas cotidianas tienen mucho más valor. Aunque, la tecnología de la información actual es tan dependiente de los datos escritos por personas que nuestros ordenadores saben más sobre ideas que sobre cosas. Si tuviéramos ordenadores que supieran todo lo que tuvieran que saber sobre las “cosas”, mediante el uso de datos que ellos mismos pudieran recoger sin nuestra ayuda, nosotros podríamos monitorizar, contar y localizar todo a nuestro alrededor, de esta manera se reducirían increíblemente gastos, pérdidas y costes. Sabríamos cuando reemplazar, reparar o recuperar lo que fuera, así como conocer si su funcionamiento estuviera siendo correcto. El internet de las cosas tiene el potencial para cambiar el mundo tal y como hizo la revolución digital hace unas décadas. Tal vez incluso hasta más.”. 13.

(14) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 14 de 181. La razón de que este concepto haya tomado tanta fuerza, es el precio, como siempre ha pasado un producto no se ha extendido al público general a no ser que tuviera un precio accesible, tal y como paso con los ordenadores personales o como paso con las conexiones a internet en el hogar. En este caso ha sido por un lado la bajada de precio de componentes electrónicos, que afecta desde los teléfonos móviles a los sensores más sencillos y por otro el abaratamiento de las comunicaciones de datos, en especial las inalámbricas que han permitido ese grado de libertad a estos nuevos dispositivos IoT. El Smartphone, por ejemplo, es uno de los elementos que mayor obtención de datos permiten dentro de IoT, esto es debido a que casi todos tenemos uno y que recogen información anónima sobre sus dueños y su entorno. Lo que permite obtener información muy importante para crear una un sistema para una Smart Cities. ¿Y cuál es la relación entre IoT y Smart Cities? Si pensamos en ello, la primera idea que se nos pasa por la cabeza es el colocar sensores por toda la ciudad, aprovechando que ahora es mucho más económico fabricarlos y hacer que recojan los datos que nos interesan, pero la obtención de datos a través de IoT no se limitaría a este punto, si se usa el Smart Phone para captar datos podemos obtener servicios del estilo de Google Maps que a través de la información de los obtiene información del el tráfico en tiempo real de las calles de una ciudad.. Ilustración 3 Análisis en tiempo real del tráfico por google Maps. Otra solución muy usada actualmente es dotar de conectividad a los elementos cotidianos del día a día, como por ejemplo coches, contenedores, neveras, semáforos, estaciones. 14.

(15) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 15 de 181. meteorológicas…. Al dotarles de acceso a la red nos brindan el acceso a numerosos datos que serán de gran utilidad para la ciudad. Una vez comprendido el concepto IoT comprendemos que podemos obtener una gran cantidad de información de la ciudad, tanto de dispositivos existentes en ella como de nuevos dispositivos, pero ¿Pero ¿qué se puede hacer con dicha información y donde se guarda? La información en sí, en crudo, pocas veces nos va a ofrecer un valor palpable, para obtener dicho valor debemos procesarla y currelarlas con otras fuentes.. 1.1.3. Big Data. En este punto entra otro concepto importante, Big data, este concepto hoy en día se escucha incluso más que IoT, la razón es que no solo se aplica a IoT y a ciudades inteligentes, si no que su campo es mucho más amplio, pero ¿qué es Big data? Y ¿de qué nos sirve?. Ilustración 4 Imagen promocional Big Data Según Edd Dumbill para O`Reilly en su libro “Big Data Now”. "Big Data" son datos que exceden la capacidad de procesamiento de sistemas de bases de datos convencionales. Los datos son demasiado grandes, se mueven demasiado rápido o no encajan en su arquitectura de base de daros. Para obtener valor de estos datos, Usted debe elegir una manera alternativa de procesarla.. 15.

(16) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 16 de 181. [3] Denominamos Big Data a la gestión y análisis de enormes volúmenes de datos que no pueden ser tratados de manera convencional, ya que superan los límites y capacidades de las herramientas de software habitualmente utilizadas para la captura, gestión y procesamiento de datos. Cuando se analizan datos es importante tener en cuenta el valor del mismo para ello lo normal es fijarse en características como las 4 Vs, aunque cada vez van apareciendo nuevas Vs estas son las más básicas. [4] Se presentan como las 4 Vs de BigData a las 4 características de los datos que analiza.. Ilustración 5 Las 4 uves de Big Data  .  . Veracidad: Se refiere tanto a la calidad del dato como a su predictibilidad Variedad: Este es uno de los puntos más importantes de BigData, el tratamiento de datos que requieren de diferente comportamiento en el análisis para cada uno por si variedad de esquemas y formas. Volumen: Como se comentó antes, la cantidad de datos que se generan actualmente son enormes Velocidad: También se ha incrementado en los últimos años la velocidad a la que se generan dichos datos.. Es decir, Big data nace de la necesidad de procesar y almacenar la creciente cantidad y variedad de datos, por ello se requieren nuevas maneras de procesamiento, como es el procesamiento distribuido. Para explicar esto se puede poner un ejemplo fácilmente asimilable: Los bancos con los sistemas originales de un mainframe centralizado (básicamente un único súper ordenador de alto coste y potencia), cada vez tardaban más en procesar las transacciones, esto era debido a que la cantidad de datos por los que navegar y procesar y la ingesta de información cada vez era mayor, causado por el aumento de clientes y de información sobre los mismos. Lo cual obligaba al banco a mejorar su sistema para reducir esta latencia en sus operaciones. Por lo que si quería mejorar sus sistemas (teniendo en cuenta que las bases de datos. 16.

(17) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 17 de 181. relacionales tienen un límite lógico de tamaño) solo tenía dos opciones, ampliar el mainframe (lo cual tiene un límite, no se pueden añadir/mejorar nuevos componentes indefinidamente) o comprar uno nuevo mucho más potente y desechando el antiguo, lo que viene siendo escalabilidad vertical. En este punto entra el concepto de Big Data, ¿y si en vez de tener un súper computador, tengo varios computadores trabajando en conjunto? Aplicando esta idea, el banco ya no requiere tanta espera en hacer una transacción por que la cantidad de datos a analizar sea demasiado para un computador, si no, que, al repartirse el trabajo entre varios computadores, el tiempo de respuesta se minimiza enormemente. Además, con la inclusión de bases de datos no relacionales, al poder dividirlas entre varios computadores, también se amplía la capacidad máxima lógica de almacenamiento. En el caso de querer aumentar su capacidad de cómputo y almacenamiento, el banco simplemente tenga que adquirir más computadores para que trabajen en conjunto con los ya existentes, lo que viene siendo escalabilidad horizontal. Otra ventaja que se obtiene con el procesamiento distribuido es que al ser un sistema repartido se le puede añadir tolerancia a fallos a través de la replicación de datos, es decir en caso de que uno de los computadores deje de funcionar otro asumirá sus tareas. Una vez introducido que solución obtenemos con Big Data, ¿cómo la unimos con IoT y la aplicamos a las ciudades inteligentes? El problema en las ciudades inteligentes es básicamente el mismo que el del banco, la cantidad de datos que se obtienen son cada vez más y tienen que ser almacenados y procesados para obtener su valor. Esto es debido a lo que comentábamos antes, con el abaratamiento de los dispositivos se observa un crecimiento exponencial de la cantidad de ellos conectados a la red. Por lo que soluciones del tipo de Big data, que nos ofrecen una gran escalabilidad horizontal, pueden ser las compañeras ideales para IoT en las Smart Cities, pero, aunque Big data nos soluciona los problemas de procesamiento y de almacenamiento, su concepto está orientado al análisis de datos en Batch, es decir, ir almacenándolos y posteriormente analizarlos. Este hecho es muy limitante cuando se quiere aplicar en situaciones que se requiere un análisis en el momento que se generan los datos.. 1.1.4. Fast Data. A menudo se dice que una ciudad está viva, y la verdad es que está en constante cambio, por ello, es muy importante que estos análisis de los datos se obtengan en el mínimo tiempo posible, debido a que, si se espera mucho, pueden perder su valor. En este punto entra en escena un concepto menos conocido que el anterior, que es Fast Data, básicamente es aplicar el concepto de Big data a procesamiento en tiempo pseudo real.. 17.

(18) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 18 de 181. Ilustración 6 Ejemplo de despliegue Fast data aplicado a la empresa Esto nos permite obtener una respuesta casi inmediata a los datos según nos van llegando, por lo cual en el campo de las ciudades inteligentes ofrece una infinidad posibilidades, como por ejemplo el control de los semáforos según el estado actual del tráfico, en este ejemplo los datos se obtienen siguiendo el concepto de IoT de sensores o de los propios dispositivos personales de los conductores (semáforos, teléfonos , GPS, sensores de los coches, cámaras de tráfico, etc.), a continuación se procesan según la filosofía de Fast Data la cual obtiene el valor del dato que es en este caso, la capacidad de controlar los semáforos en tiempo real para optimizar el flujo de tráfico. Aunque de la sensación de que Fast Data y Big Data son filosofías excluyentes entre sí, nada más lejos de la realidad, normalmente se complementan a la perfección , Fast data ofrece el análisis en tiempo real para obtener una salida al poco tiempo de ingerir los datos, cuyo procesamiento no debe de ser excesivamente pesado para que no aumentar la latencia de la salida de información, más tarde para hacer procesados más pesados entraría en juego Big Data analizando los datos obtenidos antes, durante y/o después de la etapa de Fast Data.. 1.1.5. Fog computing. El último concepto que se debe introducir es Fog computing o computación al filo de la red, para ello vamos a seguir con el ejemplo de los semáforos.. Pongámonos en situación de una ciudad grande, como por ejemplo Madrid, como se comentó anteriormente, queremos obtener la mayor cantidad de datos relevantes posibles, para ello por un lado obtenemos datos de dispositivos personales y por otro de dispositivos específicos que se han colocado, siendo Madrid una ciudad con una población de más 3,165 millones la cantidad de datos que se genera es enorme, podríamos procesarla toda con Fast Data si fuera. 18.

(19) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 19 de 181. necesario, añadiendo los computadores necesarios al clúster pero aun así se tendría que enviar por la red pagando el coste de dicha transmisión ¿entonces es esta situación óptima?¿Y si procesamos parte de la información en los propios dispositivos o en los primeros concentradores, ahorrándonos transferirla toda? ¿Y si los dispositivos requieren una respuesta mas inmediata que lo que ofrece Fast Data?. Ilustración 7 Imagen promocional Fog Computing Aquí es donde entra el concepto de Fog Computing o computación al filo de la red. Como se comentó anteriormente, en las últimas décadas el precio de la electrónica ha bajado de manera vertiginosa y ha aumentado la capacidad de cómputo, esto nos permite añadir pequeños procesamientos dentro de los propios dispositivos que toman datos o dentro de los aparatos de red que los interconectan. De esta manera por un lado se ahorra procesamiento en el clúster de la nube y por otro, él envió de información lo cual se puede traducir en una reducción de la latencia. Por lo que se pasa del concepto de Cloud a Fog, es decir en vez de estar todos los nodos de procesamiento en un clúster, se reparte de manera vertical permitiendo que se procese en los puntos más bajos de la red y evitando el envío de información innecesaria reduciendo la latencia de las peticiones puesto que tienen que viajar mucho menos recorrido por la red.. 19.

(20) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 20 de 181. Ilustración 8 Ejemplo arquitectura Fog computing. Por lo que, si se implementa esta filosofía, reservando una pequeña parte del procesamiento del dispositivo se obtienen una gran cantidad de mini nodos de procesamiento, por poner un ejemplo, en el 3º trimestre de 2015 se han vendido 353 millones de teléfonos inteligentes, si se usara una pequeña parte del procesamiento de todos estos dispositivos tendríamos más de 353 millones de mini servidores procesando información de forma local antes de enviarla a la nube. A esto hay que añadirle el poder introducir esos elementos de procesamiento también dentro de los elementos de red, haciendo varias capas de Fog Computing, un tras de otra.. 20.

(21) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 21 de 181. Ilustración 9 Ejemplo despliegue Fog computing. 1.1.6. Conclusiones. Una vez explicado dicho concepto queda claro que la combinación de las tecnologías IoT  Fog computing  Fast Data  Big Data, permite a un sistema del estilo de las Smart Cities crecer de manera exponencial, tolerancia a fallos y alta reactividad.. 21.

(22) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 22 de 181. Ilustración 10 Imagen promocional Smart Cities . . IoT: ofrece el obtener todo tipo de información al tener una gran cantidad de objetos conectados en la red como por ejemplo semáforos, contenedores, papeleras, cámaras, teléfonos móviles, etc. Fog Computing: Ofrecerá esta primera línea de procesamiento reduciendo en gran cantidad los datos que son enviados a la nube para su procesamiento gracias a filtrados o reducciones de los datos a enviar.. . Fast Data: Permitirá el procesamiento de datos con una latencia mínima por lo que podremos obtener reacciones instantáneas a dichos datos cuyo valor se reduce con el tiempo.. . Big data: Se encarga de almacenar y procesar tanto los datos procesados por Fast data como los datos en crudo que se obtienen de IoT, esto permite obtener valores que requieren más procesamiento pero que por otra parte no tienen importancia que se obtengan en el momento.. 22.

(23) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 23 de 181. 1.2. Objetivos. El objetivo del trabajo propuesto consiste en la especificación, análisis, diseño e implementación de un prototipo de sistema de información basado en IoT y aplicado a las Smart Cities que integre las nuevas tecnologías y modelos de Fog Computing y Fast Data, así como otras de nivel más bajo que soporten la implementación más adecuada. El sistema concreto elegido es el de gestión del servicio de la recogida de residuos urbanos con un alcance que cubrirá desde la monitorización de elementos del servicio mediante sensores (contenedores de basura, etc.) Hasta servicios de medida y control de la calidad del servicio y de optimización. Este sistema entra dentro de la rama de residuos una de las principales del plan nacional de ciudades inteligentes de 2015 del Gobierno de España. El proyecto se divide en cuatro capas, de manera ascendente según cercanía al clúster central, las más bajas son las más alejadas del clúster y las más altas están en él, esto es especialmente útil para comprender como se distribuye Fog computing en el sistema. Ilustración 11 Las 4 capas base del proyecto. 23.

(24) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 24 de 181 . IoT Devices: En esta capa se encuentran los dispositivos físicos IoT que se encargaran de la obtención de datos, además de contener la primera línea de pre procesamiento de Fog Computing.. . Delivery System: Subsistema encargado de la comunicación entre la capa Fast data y los dispositivos IoT, a su vez puede incluir también otra línea de pre procesamiento Fog Computing.. . Fast Data Core: Encargada de procesamiento en tiempo real de los datos y de su almacenamiento.. . Presentación: Capa encargada de hacer de interfaz para el usuario.. La forma de desarrollo del proyecto será a través de hitos de manera cíclica, se empezarán con unos hitos básicos que crearan la infraestructura principal del proyecto, es decir las capas comentadas antes, a continuación, se cumplirán los hitos de expansión, que serán características y mejoras añadidas sobre la arquitectura base.. Hitos Base . . Capa IoT o. Diseño y fabricación de un dispositivo de seguimiento para camiones de recolección de residuos. o. Diseño y fabricación de un dispositivo de monitorización de cantidad de residuos en un contenedor.. o. Diseño e implementación de un emulador de los contenedores y de camiones que los recogen que permitirá simular un escenario real.. o. Adición en los dispositivos de una capa de pre procesamiento siguiendo la filosofía Fog computing.. Capa Delivery System o. Investigación y selección de un sistema de comunicación que soporte una gran cantidad de mensajes de la capa IoT en dirección a la capa Fast Data y a ser posible que integre también ciertas capacidades de incluir procesamiento Fog computing.. 24.

(25) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 25 de 181. . . Capa Fast Data Core o. Sistema de procesamiento principal: Investigación y selección de una plataforma de procesamiento orientado a Fast data, que debe de ofrecer una respuesta casi inmediata a los datos que se le introducen.. o. Añadir funcionalidad al sistema de procesamiento principal para medir la calidad del servicio de recogida, midiendo elementos como máximos mínimos medias e integrales de la cantidad de residuos que hay en los contenedores y así medir que calidad ofrece.. o. Sistema de almacenamiento Distribuido: En esta capa se guardará toda la información necesaria, tanto para procesamiento posterior como para acceso desde la capa de prestación para ser mostrada.. Capa Presentación: o. Investigación, diseño e implementación de una interfaz de usuario con la cual se pueda acceder a los datos procesados y administrar funcionalidades del sistema.. Hitos expansión . Capa Delivery System o. . Añadir una capa de procesamiento Fog computing. Capa Fast Data Core o. Predicción del llenado de los contenedores a dos días futuros. o. Predicción del llenado de los contenedores al día siguiente si no se recogiera en el día actual.. o. Diseño e implementación de un sistema de eventos causados por predicciones y mediciones de calidad.. 25.

(26) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 26 de 181. 2 |. Estudios previos. En esta sección se agrupan los estudios previos requeridos para el desarrollo del proyecto. 2.1. Estudio del problema. Actualmente la recogida de basuras es un servicio que, aunque este contratado por el ayuntamiento, la medición de calidad del mismo y la gestión del servicio, están ambos en manos de la empresa contratada. Con este proyecto se quieren solucionar dos problemas, por un lado, se quiere dar acceso directo al ayuntamiento al estado de los contenedores de residuos para que así pueda medir por sí mismo la calidad del servicio que le está entregando la empresa de recogida, por el otro, añadir métodos con los que optimizar el servicio de recogida de basuras para que así sea más eficiente lo cual implica menos polución, menos gasto y mejores resultados que se verán reflejados en la calidad. Para la medición de la calidad del servicio de recogida de basuras, hay que centrarse en lo que más afecta al ciudadano, es decir, por ejemplo, el estado del camión no afecta mucho, sin embargo, la cantidad de residuos en el contenedor sí, por lo que el análisis de la calidad del servicio se centrara en la cantidad depositada en los contenedores a lo largo del tiempo. Por otro lado, para la gestión óptima del servicio, se requiere, además de información sobre el estado de los contenedores, información sobre los camiones, por ejemplo la posición o el llenado del depósito, de esta manera se puede predecir si el camión se va a llenar en medio de la ruta de recogida o si los contenedores antes del final del día se van a llenar por completo, y así evitar que los ciudadanos depositen residuos fuera de los contenedores que afecta directamente a la calidad de vida por los los olores y la sensación visual de limpieza de la ciudad que dan.. 2.1.1 . Parámetros a monitorizar Contenedores: En esta sección lo importante es medir el llenado del mismo, para ello se requiere una unidad de medida que sea fiable y sea capaz de permitir medir la calidad. Por un lado, se podría pensar en el peso, colocando una base que midiera la presión, se podría obtener el peso de los residuos, pero el problema es que no todo lo que se deposita en el contenedor pesa lo mismo, por lo que no sería indicativo del llenado. La solución es medir directamente el llenado del contenedor, para ello se usará un sónar. Dicho sonar estará colocado en la parte superior o en la tapa del contenedor y apuntando hacia la base del mismo.. 26.

(27) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 27 de 181. . El sónar enviará una señal de ultrasonidos que rebotará contra objeto físico más cercano, y volverá al receptor de ultrasonidos, si se mide la diferencia de tiempo que hay entre la emisión y la recepción, se puede usar junto a la ya conocida velocidad del sonido para hallar la distancia entre el sónar y la parte más alta de residuos en el contenedor y así obtener el porcentaje de llenado del mismo. Camión: En este caso se requieren dos parámetros, por un lado, el llenado del depósito interno que o bien ya está integrado en el propio camión o se pude usar el mismo método que con el contenedor. Por otro lado, la posición en la que se encuentra e camión, que nos servirá para hacer un seguimiento del mismo a través de su ruta de recogida, para ello lo más adecuado es usar GPS y obtener en el momento la posición del camión.. 27.

(28) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 28 de 181. 2.2. Estado del arte. En esta sección se repasan el estado actual de las tecnologías y conceptos que se van a aplicar en el proyecto.. 2.2.1. Fog computing. Actualmente el “procesamiento en la niebla” está ganando cierta fama gracias a ciertas compañías que ven interés en este concepto, una de las cuales es el gigante de las telecomunicaciones Cisco. Otro nombre muy común para Fog computing es Edge computing, es decir computación al filo de la red.. 2.2.1.1. Cisco. El concepto de Fog computing de cisco, se establece sobre la filosofía IoX (Internet of everything, una versión expandida de IoT). El concepto se basa en desplazar parte del procesamiento a las capas de interconexión de red para así repartir el trabajo de procesamiento.. Ilustración 12 Despliegue fog computing de ejemplo de Cisco La idea es sencilla: dentro de los elementos de red de cisco, se reserva unos recursos para procesamiento, en el cual se pueden instalar variedad de programas y demonios.. 28.

(29) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 29 de 181. Ilustración 13 Arquitectura Fog computing de Cisco. 2.2.1.2. Kafka. Otro concepto que puede llegar a entrar en el de Fog computing es Kafka (del cual también se comentará en la sección de Fast Data y de publicador subscriptor)puesto que el cluster central también es parte de Fog computing.. Ilustración 14 Logo Kafka Kafka lo podemos entender como un bus de datos al cual las aplicaciones de pueden subscribir a temas, puesto que la idea es que en un sistema todas las aplicaciones estén conectadas a dicho bus, este sistema se despliega de manera distribuida para así tener alta disponibilidad, tolerancia a fallos y escalabilidad horizontal. Lo más inteligente una vez se tiene desplegado una arquitectura así, es implementar un sistema de procesamiento sobre el mismo que procese en tiempo real añadiendo agregaciones, filtrados, etc. sobre el flujo de datos que recorre el bus.. 29.

(30) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 30 de 181. El uso más común de Kafka es en clústeres de datos para la interconexión de aplicaciones de manera más organizada y tolerante a fallos, pero como toda esta sección está en el propio clúster contaría como si estuviera en la nube. Pero si en vez de eso se despliega de manera distribuida en elementos de red como por ejemplo los routers de cisco IoX, en este caso si se trataría de Fog computing puesto que habría procesamiento en los niveles más bajos de la red. En este ámbito los usos más comunes de las tecnologías de Fog Computing es el análisis de la red en busca de amenazas y el análisis de logs en busca de anomalías.. 2.2.1.3. Edgent. Por otro lado, se encuentra apache Edgent (antes Quarks).. Ilustración 15 Logo Edgent Su enfoque es todavía más bajo, no se trata de componentes distribuidos que trabajan coordinados, si no de pequeños elementos de procesamiento que trabajan de manera individual, su concepto es desplazar el procesamiento a los propios dispositivos IoT para ello ofrece un framework que permite trabajar en forma de streaming, facilitando el diseño y la comprensión de aplicaciones orientadas a flujos de información. Por ejemplo, la aplicabilidad de Edgent podría ser el ejemplo que tienen con IBM en el cual instalan Edgent en unos aspersores de agua, dentro de los se hacen pequeñas agregaciones y filtrados para monitorizar el estado del suelo, aliviando así por un lado la red por el exceso de envió de datos y por otro la cantidad de datos a procesas. La manera de trabajar en Edgent es por sistemas del estilo “pipes and filters”. 30.

(31) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 31 de 181. Ilustración 16 Vista de la interfaz web de administración de Edgent. Este sistema facilita la monitorización, pudiendo encontrar cuellos de botella o nodos que estén ociosos. Aunque principalmente lo anuncian como IoT también sirve para instalación en dispositivos de red o clústeres en los que se requiere pequeños agentes para analizar flujos de logs o paquetes de red.. 2.2.2. Sistemas publicador subscripor. Actualmente hay muchas tecnologías publicador subscriptor, pero se va a centrar a las más conocidas en el ámbito de IoT.. 31.

(32) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 32 de 181. Ilustración 17 Despliegue de ejemplo de Edgent. 2.2.2.1. MQTT. Es un protocolo usado para la comunicación machine-to-machine (M2M) en el “Internet of Things “. Este protocolo está orientado a la comunicación de sensores, debido a que consume muy poco ancho de banda y puede ser utilizado en la mayoría de los dispositivos empotrados con pocos recursos (CPU, RAM,…).. Ilustración 18 Logo MQTT. [5] La arquitectura de MQTT sigue una topología de estrella, con un nodo central que hace de servidor o “bróker” con una capacidad de hasta 10000 clientes. El bróker es el encargado de gestionar la red y de transmitir los mensajes, para mantener activo el canal, los clientes. 32.

(33) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 33 de 181. mandan periódicamente un paquete (PINGREQ) y esperan la respuesta del bróker (PINGRESP). La comunicación puede ser cifrada entre otras muchas opciones.. Ilustración 19 Despliegue de ejemplo MQTT MQTT también permite el escalado horizontal, aunque su arquitectura no está ideada para ello por lo que a la larga tiene ciertas limitaciones. Por ejemplo, en este caso el servidor central de MQTT sería el eslabón débil de la cadena y también el que podría a llegar crear un cuello de botella por pasar todos los elementos por él.. Ilustración 20 Despliegue distribuido con niveles de jerarquía de MQTT. 33.

(34) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 34 de 181. En este otro ejemplo el punto débil por un lado seria el balanceador que, si se cae, necesitaría otro de respaldó y por otro lado la comunicación entre bróker, que cuantos más brókeres haya, más comunicación será requerida y más complicado de coordinar será.. Ilustración 21 Despliegue distribuido con balanceador de carga de MQTT. 34.

(35) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 35 de 181. 2.2.2.2. Watson IoT Platform. Ilustración 22 Logo IBM Watson En este caso es una solución propietaria de IBM, no es solo un sistema de publicación suscripción, la plataforma Watson sirve para una gran cantidad de tareas, como por ejemplo análisis Fast data, machine learning, etc.. Ilustración 23 Despliegue de ejemplo de Watson Para funcionar como sistema de publicador subscriptor, en la capa baja (más cercana a los dispositivos IoT) usa MQTT para obtener todos los mensajes, después lo hace pasar por la plataforma en la cual puede hacer pequeñas tareas de procesamiento, por ultimo para enviárselo a los programas de procesamiento principal. Se usa IBM Message Hub que sirve de pasarela para que a los programas de procesamiento le lleguen los eventos y mensajes.. 35.

(36) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 36 de 181. 2.2.2.3. Kafka. [6]Apache Kafka es un sistema de almacenamiento publicador/subscriptor distribuido, particionado y replicado. Estas características, añadidas a que es muy rápido en lecturas y escrituras lo convierten en una herramienta excelente para comunicar streams de información que se generan a gran velocidad y que deben ser gestionados por uno o varias aplicaciones. Se destacan las siguientes características:   .     . Funciona como un servicio de mensajería, categoriza los mensajes en topics. Los procesos que publican se denominan bróker y los subscriptores son los consumidores de los topics. Utiliza un protocolo propio basado en TCP y Apache Zookeeper para almacenar el estado de los brokers. Cada broker mantiene un conjunto de particiones (primaria y secundaria) de cada topic. Se pueden programar productores/consumidores en diferentes lenguajes: Java, Scala, Python, Ruby, C++ … Escalable y tolerante a fallos. Se puede utilizar para servicios de mensajería (tipo ActiveMQ o RabbitMQ), procesamiento de streams, web tracking, trazas operacionales, etc. Escrito en Scala. Creado por LinkedIn.. Ilustración 24 Arquitectura Kafka. 36.

(37) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 37 de 181. A diferencia de MQTT, Kafka si es un sistema distribuido, por lo que para sistemas que tienen una gran cantidad de datos a transportar o requieren una alta disponibilidad es el más adecuado, sin embargo, también es mucho más pesado en comparación con MQTT.. 2.2.3. Fast Data. Como se comentó en la introducción Fast Data permite el procesamiento de grandes cantidades de datos en tiempo real de manera distribuida (y en algunos casos, tolerante a fallos). Actualmente, existe ya, una cierta cantidad de herramientas para el desarrollo de aplicaciones en este tipo, en esta sección se da un repaso a las ya casi abandonas pero que tuvieron su importancia y a las existentes que son tendencia.. Ilustración 25 Despliegue completo Fast Data En el diagrama superior se puede ver un despliegue de Fast data. Como se puede observar tiene ciertas similitudes con el despliegue de Big data que se muestra abajo, puesto que un despliegue normal suele incluir ambos conceptos por ofrecer características diferentes.. 37.

(38) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 38 de 181. Ilustración 26 Despliegue completo Big Data. 2.2.3.1. Spark streams. [7]Apache Spark combina un sistema de computación distribuida a través de clústeres de ordenadores con una manera sencilla y elegante de escribir programas. Fue creado en la Universidad de Berkeley en California y es considerado el primer software de código abierto que hace la programación distribuida realmente accesible a los científicos de datos.. Ilustración 27 Logo Spark Streaming Spark mantiene la escalabilidad lineal y la tolerancia a fallos de MapReduce, pero amplía sus bondades gracias a varias funcionalidades: DAG y RDD. 38.

(39) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 39 de 181. Ilustración 28 Ejemplo de DAG (Directed Acyclic Graph) A diferencia de Hadoop que solo tiene dos etapas (map y reduce) y que cuando se acababan esas dos etapas había que guardar en disco, Spark permite añadir un número ilimitado de etapas acíclicas (es decir nunca puede retornar una tarea a un nodo por el que ya paso) sin tener que escribir en disco, lo que aumento de manera impresionante la eficiencia respecto a Hadoop, a esto se le llama DAG (Directed Acyclic Graph). Para el manejo de esos datos en memoria se usan los objetos RDD que contienen toda la información y es el contenedor sobre los que se hacen las operaciones y transformaciones. Dentro de Spark, que está orientado a Batch, nace Spark Streaming, más orientado al trabajo en streaming y por ello más cercano a la filosofía Fast Data.. Ilustración 29 Paso de datos de tipo Stream a micro Batches. Básicamente lo que hace es convertir la entrada de datos de streaming en micro-batches, basados en secciones de tiempo, que a continuación pasa a la máquina de Spark. Estrictamente hablando Spark no es un sistema en streaming, pero se aproxima.. 39.

(40) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 40 de 181. Ilustración 30 Orden de procesamiento de los micro batches [8]Spark Streaming soporta distintos modelos correspondientes a las semánticas típicamente utilizadas para el procesamiento de flujos. Esto asegura que el sistema entrega resultados confiables, aún en caso de fallos en nodos. Los flujos de datos pueden ser procesados de acuerdo a los siguientes modelos:. . Exactamente una vez (exactly once). Cada elemento es procesado una sola vez.. . Como mucho una vez (at most once). Cada elemento puede ser procesado un máximo de una vez, y es posible que no sea procesado.. . Por lo menos una vez (at least once): Cada elemento debe ser procesado por lo menos una vez. Esto aumenta la posibilidad de que no se pierdan datos, pero también es posible que se generen duplicados.. Como se puede ver no es tiempo real de manera estricta, si no que separa por franjas de tiempo (frecuentemente 5 segundos), se puede reducir las franjas de tiempo a menos de un segundo, pero afectará a la latencia del sistema, por requerir más recursos. Adicionalmente, un argumento en contra del esquema de micro-batches es que puede ser que los datos no se reciban en el orden exacto en el que sucedieron.. 2.2.3.2. Apache Storm. [9]Apache Storm es un sistema que sirve para recuperar streams de datos en tiempo real desde múltiples fuentes de manera distribuida, tolerante a fallos y en alta disponibilidad. Storm está principalmente pensado para trabajar con datos que deben ser analizados en tiempo real, por ejemplo, datos de sensores que se emiten con una alta frecuencia o datos que provengan de las redes sociales donde a veces es importante saber qué se está compartiendo en este momento.. 40.

(41) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 41 de 181. Ilustración 31 Logo Apache Storm. Se compone principalmente de dos partes. La primera es la que se denomina Spot y es la encargada de recoger el flujo de datos de entrada. La segunda se denomina Volt y es la encargada del procesado o transformación de los datos.. En la documentación oficial representan los Spots con grifos simulando la entrada de un stream de datos al sistema y a los Bolts con un rayo que es donde se realizan las acciones pertinentes con los datos de entrada.. Ilustración 32 Arquitectura de trabajo de apache Storm. Uno de los puntos fuertes de Storm es que podemos crear una topología donde añadimos instancias de Bolts y Spouts para que escale el sistema desplegándola en el clúster de Storm. 41.

(42) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 42 de 181. que es quién se encargará de particionar los datos de entrada y redistribuirlos por los diferentes componentes. Storm fue programado en clojure y en java en 2011, en 2013 paso a ser parte del programa de incubación de apache y en 2014 se convirtió en un proyecto de alta importancia para apache (Apache Top-Level Project). Actualmente está algo abandonado y ha sido desplazado por otros frameworks.. 2.2.3.3. Akka Streams. [10]Akka es una plataforma (o framework) inspirado por Erlang que busca el desarrollo simple de aplicaciones escalables y multihilo. Akka funciona sobre Scala y por tanto corre sobre la máquina virtual Java JVM.. Ilustración 33 Logo Akka Si en los lenguajes más tradicionales como Java la concurrencia se basa en la memoria compartida entre varios hilos y los métodos de sincronización Akka ofrece un modelo de concurrencia basado en actores. . Un actor es un objeto con el que puedes interactuar enviándole mensajes: cada actor puede procesar mensajes y enviarles mensajes a otros actores.. . En una máquina virtual JVM pueden correr millones de actores a la vez construyendo una jerarquía padre (supervisor)-hijo con los padres monitorizando el comportamiento de los hijos.. . Además, Akka permite, de una forma sencilla, repartir nuestros actores entre varios nodos de un cluster.. 42.

(43) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 43 de 181 . Los actores pueden tener un estado interno pero la comunicación sólo ocurre pasando mensajes y nunca a través de estructuras compartidas.. Ilustración 34 Jerarquía de actores de Akka. El sistema de actores de Akka sigue una jerarquía de padres e hijos al estilo de ficheros de Unix, aunque se pueden enviar menajes de unos a otros, tiene que hacerlo a través de las líneas de jerarquía. El sistema de actores permite una baja latencia, lo cual permite que por su estructura ser una muy buena opción para el procesamiento en Streaming.. 2.2.3.4. Apache Bean. Antes de la creación de Beam Google creo el llamado Dataflow Model, un modelo que unifica el procesamiento en Batch y en Stream, para conseguir correrlo en su servicio de cloud “Google Cloud Dataflow”.. 43.

(44) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 44 de 181. Ilustración 35 Logo apache Beam Más tarde Google dono el modelo de programación al proyecto de incubación de Apache, punto en el que nación Apache Bean. [11]Es un modelo de programación unificado open source, que permite crear pipelines para el procesamiento de datos aptos para Batch y streaming que se pueden correr sobre diferentes plataformas. 44.

(45) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 45 de 181. Ilustración 36 Unificación de lenguajes en Beam El concepto básico traído de Dataflow Model es responder a las siguientes preguntas: ¿Qué resultados son calculados? Esta cuestión se centra en qué tipo de operaciones se tiene que hacer sobre el flujo de datos. ¿Dónde en el evento los resultados son calculados? Se basa en el uso de ventanas de tiempo con las cuales se decide cuando se procesan los datos y si se llega a procesar. ¿Cuándo los resultados son materializados? Es decir, en qué momento del procesamiento damos una respuesta a los cálculos hechos. ¿Cómo relacionamos los resultados? La respuesta a esta pregunta es la manera de que los resultados materializados de relacionan unos con otros, sobre todo cuando son de la misma ventana. Actualmente google está detrás de este proyecto, con mucho interés debido a que permite crear programas para su servicio cloud Dataflow, pero también puede correr sobre Apache Flink y Apache Spark. Por ahora solo soporta Java, pero dentro de poco soportara Python.. 45.

(46) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 46 de 181. Los Apache Beam Pipeline Runners son los programas en sí, en él se tiene que definir sobre que plataforma se va a desplegar. Aunque para desarrollo, debugging y testeo se puede ejecutar en local si ningún problema.. 2.2.3.5. Kafka streams. Kafka aparte de su sistema de publicador subscriptor añade una capa superior con la que se puede añadir procesamiento en streaming de manera paralela.. Ilustración 37 Arquitectura de Apache Kafka. En esta capa se pueden hacer agregaciones, filtrados, etc. sobre los flujos de información que recorren Kafka de manera distribuida y tolerante a fallos.. 2.2.3.6. IBM Streams. [12]InfoSphere Streams es un producto de IBM que se define como “una plataforma de computación avanzada que permite desarrollar aplicaciones a los usuarios para ingerir, analizar y correlacionar información desde un gran número de fuentes en tiempo real, permitiendo procesar alto volúmenes de datos y millones de eventos por segundo”.. 46.

(47) UNIVERSIDAD POLITÉCNICA DE MADRID Escuela Técnica Superior de Ingeniería de Sistemas Informáticos. Pagina 47 de 181. Ilustración 38 Logo IBM Streams Es uno de los primeros sistemas orientados a Fast data, fue solicitado por el gobierno de USA a IBM para poder analizar todas las llamadas del país teniendo la mínima latencia posible para evitar ataques terroristas después del 11-S. Tiene su propio lenguaje de programación llamado SPL, aunque también soporta otros lenguajes como Java o Scala. Una vez escrito el programa se traducen en lenguaje C++ y se compila. También tiene gran compatibilidad con otros sistemas ya sean privativos de IBM o de código abierto, gracias a sus numerosos conectores. Además, permite introducir programas en C++, R y java de manera nativa InfoSphere Streams permite: . Analizar streams en el momento: con tiempos de respuesta de milisegundos. . Desarrollar aplicaciones de streaming de forma sencilla a través de su IDE. . Extender el valor de sistemas existentes integrando con aplicaciones y fuentes de datos. 2.2.4. Almacenamiento. Actualmente las dos maneras más comunes para el almacenamiento de datos son las bases de datos relacionales (SQL) y no relacionales (NO-SQL).. 47.