Máster en Ingeniería Computacional y Matemática

Trabajo Final de Máster

Creación de un cluster formado por tres -3 que alojarán una base de datos NoSQL (Apache Cassandra) y motor de cálculo distribuido (Apache Spark), desplegado en contenedores (Docker).

Eduardo Romero López Sistemas Distribuidos

Coordinador: Félix Freitag Nombre Profesor/a responsable de la asignatura: Joan Manuel Marquès

10 de septiembre de 2017 GNU Free Documentation License (GNU FDL) Copyright © 2017 Eduardo Romero López. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front- Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". DEDICADO

A Lorena por su apoyo, paciencia y comprensión durante todo el periodo que duró el máster.

AGRADECIMIENTO

A todas las comunidades de desarrolladores y personas que comparten sus conocimientos en charlas y talleres sin miedo a que un tercero pueda aprenderlo, en especial a: @linux_malaga, @centrologic_es, @malaga_pythony @DataBeersMLG Ficha del Trabajo Fin de Máster

Creación de un cluster formado por tres RaspberryPI-3 que alojarán una base de datos Título del trabajo NoSQL(Apache Cassandra) y motor de cálculo dis- tribuido(Apache Spark), alojado en un contenedor (Docker). Nombre del autor Eduardo Romero López Nombre del consultor/a Félix Freitag Nombre del PRA Joan Manuel Marquès Fecha de entrega 09/2017 Titulación Máster en Ingeniería Computacional y Matemática Área del Trabajo Final Sistemas Distribuidos Idioma del trabajo Español Palabras clave (máxi- Docker, Spark y Cassandra mo 3 palabras) Resumen del Trabajo (máximo 250 palabras): Este proyecto consiste en el ensamblaje e integración de todos los componentes hardware y software para formar un motor de cálculo distribuido sobre mini-PC (Raspberry PI-3), todo ello llevado a cabo desde un enfoque muy práctico. Así mismo, trata de dar continuidad y profundizar más en los conocimientos adquiridos en la asignatura del Máster Computación Distribuida. Abstract (in English, 250 words or less): This project consists in the assembly and integration of all the hardware and software components to form a distributed calculation engine over mini PC (Raspberry PI- 3), all realized from a very practical point of view. Also, it tries to give continuity and to deepen in the knowledge acquired in the subject of the Master Distributed Computing.

Computación Distribuida iii Índice general

Índice de figuras vi

Índice de tablas viii

Índice de Códigos ix

1 Introducción1 1.1 Contexto y justificación del Trabajo...... 1 1.2 Objetivos del Trabajo...... 1 1.3 Enfoque y método seguido...... 2 1.4 Planificación del Trabajo...... 2 1.5 Breve sumario del producto obtenido...... 3 1.6 Breve descripción de los otros capítulos de la memoria...... 4

2 Hardware y sistema operativo utilizado5 2.1 Mini PC...... 5 2.2 Descripción del hardware a utilizar...... 6 2.3 Sistema Operativo utilizado...... 8 2.3.1 Raspbian...... 9 2.3.2 Mate...... 9

3 Introducción de los componentes del sistema 12 3.1 Docker...... 12 3.1.1 Imágenes en Docker...... 13 3.1.2 Contenedores en Docker...... 13 3.1.3 Volúmenes en Docker...... 13 3.1.4 Arquitectura en Docker...... 14 3.1.5 Herramientas de Docker...... 14 3.2 Cassandra...... 16 3.2.1 Arquitectura y características de Cassandra...... 16

iv 3.2.2 Lenguaje CQL...... 17 3.2.3 Modelado de datos...... 18 3.3 Spark...... 19 3.3.1 Componentes del ecosistema Spark...... 19 3.3.2 La abstracción RDD...... 21

4 Estado del arte 22

5 Puesta en marcha del sistema 24 5.1 Configuración inicial del sistema...... 24 5.1.1 Creación imagen iso...... 24 5.1.2 Instalación Ubuntu Mate...... 26 5.1.3 Habilitar SSH en la Raspberry PI 3...... 28 5.1.4 Habilitar modo consola en la Raspberry PI 3...... 28 5.1.5 Configuración de la red...... 29 5.1.6 Asignación de partición Swap de intercambio...... 30 5.2 Docker...... 32 5.2.1 Instalación Docker...... 32 5.2.2 Instalación Docker-Compose...... 34 5.2.3 Docker Swarm...... 34 5.2.4 Instalación Portainer...... 36 5.3 Cassandra...... 38 5.3.1 Requerimientos previos...... 38 5.3.2 Instalación de Cassandra...... 38 5.3.3 Configuración de Cassandra para uso en Raspberry...... 39 5.3.3.1 Requerimientos de memoria...... 39 5.3.3.2 Configuración de parámetros del cluster...... 39 5.3.4 Creación de una base de datos...... 42 5.4 Spark...... 46 5.4.1 Instalación y configuración de Spark en Raspberry Pi 3.... 46 5.4.2 Instalación Spark-Cassandra-Connector...... 50 5.4.3 Prueba de comunicación Spark-Cassandra-Connector..... 50

6 Análisis de resultados 52 6.1 Objetivo principal...... 52 6.2 Objetivo secundario...... 53 6.2.1 Proceso de ejecución de la aplicación...... 55 6.2.2 Análisis de los resultados de la aplicación...... 56

7 Conclusiones y futuros trabajos 58 7.1 Conclusiones...... 58 7.2 Futuros trabajos...... 59

Bibliografía 60

Anexos 61

Web visitadas 62

Computación Distribuida v Presupuesto para realización del proyecto 64

Tabla comparativa de mini PC 65

Computación Distribuida vi Índice de figuras

1.1 Cluster raspberry pi-3...... 3

2.1 Componentes hardware del sistema...... 7 2.2 Sistema Operativo Raspbian...... 10 2.3 Sistema Operativo Ubuntu Mate...... 10

3.1 Esquema del despliegue de aplicaciones con Docker...... 12 3.2 Ejemplo de 2 imágenes con 3 contenedores en Docker...... 14 3.3 Docker Hub...... 15 3.4 Esquema tipo de un sistema Docker multihost...... 16 3.5 Principales características de Cassandra...... 17 3.6 Modelo de datos en Cassandra...... 18 3.7 Ecosistema Spark...... 20 3.8 Flujograma de RDD en Spark...... 20

5.1 Adaptador microSD a USB utilizado...... 24 5.2 Crear la imagen iso de Ubuntu Mate...... 25 5.3 Proceso de instalación Ubuntu Mate...... 27 5.4 Diagrama red LAN montada...... 29 5.5 Hardware Raspberry Pi 3 sin Swap...... 31 5.6 Hardware Raspberry Pi 3 con Swap...... 31 5.7 Añadir Docker al iniciar sesión...... 33 5.8 Añadir el usuario al grupo de Docker...... 34 5.9 Interfaz gráfica Portainer...... 37 5.10 Estado cluster de Cassandra...... 40 5.11 Consola de Cassandra...... 42 5.12 Usando Keyspace cotizaciones...... 43 5.13 Registros de cotización de ING...... 46 5.14 Clave RSA para acceso remoto...... 47 5.15 Consola de Spark...... 48 5.16 Panel web Cluster Spark...... 50

vii Índice de figuras Índice de figuras

6.1 Imagen de Cassandra en Docker Hub...... 53 6.2 Resultados obtenidos de la aplicación...... 55 6.3 Consumo de la aplicación Python sobre una Raspberry Pi-3..... 57

7.1 UDOO Ultra...... 59

Computación Distribuida viii Índice de tablas

1.1 Planificación del proyecto...... 2

2.1 Mini PC más usados para este tipo de proyectos...... 6

1 Presupuesto para la realización del proyecto...... 64

2 Comparativa de mini PC...... 77

ix Índice de Códigos

1 Contenido del archivo de configuración IP fija...... 30 2 Versión Docker instalada...... 32 3 Crear nodo manager Swarm...... 35 4 Cluster Swarm formado por rpi3...... 35 5 Parámetros de Cassandra...... 41 6 Creación de una keyspace en Cassandra...... 42 7 Parámetros de Cassandra...... 43 8 Inserción de datos automatizados con Python...... 45 9 Consultas en Cassandra...... 46 10 Configuración parámetro archivo slave...... 48 11 Configuración parámetros Spark...... 49 12 Consola Spark conectada con Cassandra...... 51 13 Aplicación cálculo correlaciones PySpark...... 55

1 1 Introducción

1.1 Contexto y justificación del Trabajo

En la actualidad estamos inmersos en una revolución digital, cada vez hay más equipos o IOT (Internet of things) conectados a internet recabando y generando datos de diversas procedencia y naturaleza. Eso genera grandes volúmenes de datos que dificultan trabajar con ellos a través del modelo tradicional SGBDR (Sistema de Gestión de Bases de Datos Relacionales) y de ahí surgen nuevas tecnologías para dar solución a dicho problema, como las que se tratarán en este proyecto.

1.2 Objetivos del Trabajo

Debido al carácter novedoso y experimental de este proyecto, el objetivo será más o menos ambicioso dependiendo de los resultados que se vayan obteniendo. El objetivo a cubrir es montar un cluster formado por tres raspberry pi-3 (mini-PC) como centro de cómputo distribuido para utilizar la tecnología de Spark y Cassandra. A continuación, se describen dos configuraciones: una principal (de carácter ambi- cioso) y otra secundaria (en caso de que no consiga la principal): Principal: Montar un cluster formado por tres raspberry pi-3 (mini-PC) co- mo centro de cómputo distribuido, para ello se pretende desplegar imágenes descargadas de Docker Hub en una red de contenedores (Docker Swarn) y le- vantar en ellos un motor de cálculo distribuido (Spark) que comunicará con una base de datos NoSQL (Cassandra). Secundario: Montar un cluster formado por tres raspberry pi-3 (mini-PC) como centro de cómputo distribuido, directamente sobre las raspberry pi-3. Se instalará un motor de cálculo distribuido (Spark) que comunicará con una base de datos NoSQL (Cassandra). Este objetivo omite la aplicación de tecnología basada en contenedores.

1 1. Introducción 1.3. Enfoque y método seguido

En ambos puntos la prioridad es la integración del sistema. Conseguir que los com- ponentes del mismo se comuniquen entre sí.

1.3 Enfoque y método seguido

El enfoque de este proyecto es “aprender haciendo”, parte desde el ensamblaje de los componentes hasta la parametrización y configuración de cada una de las tec- nologías implicadas, todo ello llevado a cabo desde un punto de vista muy práctico. Asimismo, trata de dar continuidad y profundizar en los conocimientos adquiridos en la asignatura del Máster “Sistemas Distribuidos”.

1.4 Planificación del Trabajo

En la tabla 1.1 se indica el porcentaje de trabajo y el número de horas aproximadas que se han dedicado a cada una de las secciones que componen el índice de este proyecto. Se ha estimado una dedicación media semanal de 15 horas de trabajo durante 30 semanas, siendo el total de 450 horas la realización del proyecto completo.

TAREA CONCEPTO % CARGA TRABAJO HORAS DEDICACIÓN A 1- Introducción 1,5 7 B 2- Hardware y sistema operativo utilizado 3 14 C 3- Introducción de los componentes del sistema - - D 3.1- Docker 10 45 E 3.2- Cassandra 12,5 56 F 3.3- Spark 12,5 56 G 4- Estado del arte 5 23 H 5- Puesta en marcha del sistema - - I 5.1- Configuración inicial del sistema 8 36 J 5.2- Docker 10 45 K 5.3- Cassandra 15 68 L 5.4- Spark 15 68 M 6- Análisis de resultados 5 23 N 7- Conclusiones y trabajo futuros 2,5 11 TOTAL 100 450

Tabla 1.1: Planificación del proyecto

A continuación se muestra el diagrama de Gantt de las 30 semanas que ha llevado la realización del proyecto, desde la semana 3 de enero de 2017 hasta la semana 33 de agosto de 2017 (ambas incluidas).

Computación Distribuida 2 1. Introducción 1.5. Breve sumario del producto obtenido

2017

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

A

B

C=D+E+F

G

H=I+J+K+L

M

N

1.5 Breve sumario del producto obtenido

El producto obtenido es un pequeño cluster formado por tres raspberry pi-3 que se utilizará como centro de pruebas y aprendizaje de computación distribuida a pequeña escala, como se puede ver en la figura 1.1

Figura 1.1: Cluster raspberry pi-3

Computación Distribuida 3 1. Introducción 1.6. Breve descripción de los otros capítulos de la memoria

1.6 Breve descripción de los otros capítulos de la memoria

A continuación, se describen cada uno de los capítulos tratados en este proyecto: Sección 2: “Hardware y sistema operativo utilizado”: se describe las ca- racterísticas del hardware utilizado en este proyecto, así como el sistema operativo empleado y el porqué de utilizar este.

Sección 3: “Introducción de los componentes del sistema”: trata de dar una perspectiva teórica y general de cada uno de los componentes del sistema (Doc- ker, Spark y Cassandra).

Sección 4: “Estado del arte”: Contempla la investigación inicial realizada en internet sobre la situación actual de los mini-PC aplicado al cómputo distribuido.

Sección 5: “Puesta en marcha del sistema”: descripción detallada de la fase de puesta en marcha del sistema (instalación más configuración). Está compuesta de cuatro secciones: configuración inicial del sistema operativo y de la red, Docker, Cassandra y Spark.

Sección 6: “Análisis de resultados”: se analizan los resultados obtenidos y su nivel de cumplimiento en relación con los objetivos marcados en la sección 1.2

Sección 7: “Conclusiones y trabajo futuro”: descripción de las conclusiones obtenidas y una serie de puntos como trabajo futuros o posibles ampliaciones de este proyecto.

Computación Distribuida 4 2 Hardware y sistema operativo utilizado

2.1 Mini PC

Un mini PC no tiene una definición única; tanto es así, que dependiendo de la fuente que consultes, puedes encontrar que engloba un mayor o menor número de equipo. Como características comunes tenemos que todos son capaces de ejecutar diversos sistemas operativos como Windows y sin problemas en un formato y tamaño mucho menor que un PC de escritorio y a un coste reducido. Existe una gran variedad de mini PC, muchos de ellos son productos acabados y para un fin determinado, como puede ser: los smart TV o el intel nuc (equipo de sobremesa pequeño y compacto). Por otro lado, podemos encontrar una gran variedad de mini PC en formato “placa base”, en el apéndice 7.2( Tabla comparativa de mini PC) se puede consultar un gran número de ellos. De todos los mini PC consultados, los más interesantes o más utilizados para este tipo de proyecto son: Raspberry PI, ODROID,udooo parallella. A continuación, se muestra una pequeña tabla resumen en la que aparecen para cada uno de los fabricantes las características técnicas más relevantes de su placa base de gama más alta y su precio:

5 2. Hardware y sistema operativo utilizado 2.2. Descripción del hardware a utilizar

Nombre Nucle Memoria Precio (€) Raspberry Pi 3 1.2GHz 64-bit quad- 1GB RAM 39,90 Modelo B core ARMv8 CPU Samsung Exynos5422 Cortex™-A15 2Ghz 2Gbyte LPDDR3 ODROID-XU4 55,57 and Cortex™-A7 RAM PoP stacked Octa core CPUs CPU INTEL PEN- UDOO X86 UL- 8 GB DDR3L DUAL TIUM N3710 2.56 244,00 TRA CHANNEL GHZ 16-core Epiphany RISC SOC. Zynq Parallella 1GB SDRAM 93,25 SOC (FPGA + ARM A9)

Tabla 2.1: Mini PC más usados para este tipo de proyectos

En concreto, para el desarrollo del proyecto nos centraremos en las Raspberry PI 3 por ser la más interesante en calidad-precio y porque existe mayor información y documentación en Internet sobre cómo formar cluster para cómputo distribuido sobre las mismas.

2.2 Descripción del hardware a utilizar

Los componentes hardware necesarios para el desarrollo del proyecto se muestran en la siguiente imagen:

Computación Distribuida 6 2. Hardware y sistema operativo utilizado 2.2. Descripción del hardware a utilizar

Figura 2.1: Componentes hardware del sistema

Descripción de las carasterísticas de cada uno de los componentes: 3 Raspberry PI 3: • CPU, Broadcom BCM2387. 1,2 GHz de cuatro núcleos ARM Cortex-A53 • GPU, Dual Core VideoCore IV Multimedia Co-procesador. Proporciona Open GL ES 2.0, OpenVG acelerado por hardware, y 1080p30 H.264 de alto perfil de decodificación. • RAM: 1GB LPDDR2 • Ethernet socket Ethernet 10/100 BaseT 802.11b/g/n LAN inalámbrica y 4.1 (Classic Bluetooth y LE) • HDMI rev 1.3 y 1.4 • RCA compuesto (PAL y NTSC) • Jack de 3, 5mm de salida de audio, HDMI USB 4 x Conector USB 2.0 • Conector GPIO 40-clavijas de 2, 54mm (100 milésimas de pulgada) de expansión: 2x20 tira. 27 pines GPIO, así como 3, 3V , +5V y GND líneas de suministro Conector de la cámara de 15 pines cámara MIPI interfaz en serie (CSI-2) • Pantalla de visualización Conector de la interfaz de serie (DSI) Conector de 15 vías plana flex cable con dos carriles de datos y un carril de reloj

Computación Distribuida 7 2. Hardware y sistema operativo utilizado 2.3. Sistema Operativo utilizado

• Ranura de tarjeta de memoria Empuje / tire Micro SDIO 3 memorias microSDHC de 32GB 3 Ventilador para la CPU 3 juegos disipadores de calor para los distintos chips de las placas 3 cables de red RJ45 para las comunicaciones 3 cables microUSB para la alimentación 1 cable HDMI para la contectarlo a la pantalla o monitor 1 fuente de alimentación: • Capacidad para cargar 6 USB de carga rápida • Intensidad de salida: 6A • Rango de intensidad de salida: 0, 5A − 3, 5A • dimensiones: 88 ∗ 86 ∗ 38 mm 1 SWITCH D-Link: • 8 puertos Gigabit 1 caja acrílica transparente formada por tres niveles que servirá de estruc- tura para el cluster 1 teclado y ratón inalámbrico 1 pantalla o monitor

2.3 Sistema Operativo utilizado

La Raspberry PI 3 es un dispositivo muy versátil que permite la instalación de va- rios sistemas operativos ya sean estos oficiales o no, así como distintos gestores de contenido en función del uso al que vaya enfocado. Los gestores de contenidos son aplicaciones específicas para un fin como pueden ser: centros multimedia o emulado- res de juegos. Los gestores de contenidos quedan fuera del alcance de este proyecto. En base a lo anterior podemos realizar la siguiente clasificación de sistemas opera- : Oficiales: • RASPBIAN ( Jessie) • PIDORA Fedora Remix • Ubuntu MATE No oficiales (existe un mayor número):

Computación Distribuida 8 2. Hardware y sistema operativo utilizado 2.3. Sistema Operativo utilizado

• • OpenSuse • KaliLinux El sistema operativo utilizado en este proyecto será Ubuntu Mate por diversas razones: No está enfocado a la enseñanza de la informática, por tanto es más complejo y completo. Su distribución base es Ubuntu, sobre esta existe una gran documentación al ser una de las distribuciones Linux más utilizada por su sencillez y facilidad de uso. Existe más documentación relacionada con el hilo de este proyecto (es más fácil hallar información en internet de cómo montar un cluster de Raspberry Pi sobre ubuntu frente a otras distribuciones como puede ser Arch Linux). Proceso de instalación sencillo.

2.3.1 Raspbian

Raspbian es una distribución libre del sistema operativo GNU/Linux basado en De- bian Wheezy (Debian 7.0) para la placa computadora (SBC) Raspberry Pi, orientado a la enseñanza de informática. El lanzamiento inicial fue en junio de 2012. Técnicamente el sistema operativo es un port no oficial de Debian Wheezy armhf para el procesador (CPU) de Raspberry Pi, con soporte optimizado para cálculos en coma flotante por hardware, lo que permite dar más rendimiento en según que casos. El port fue necesario al no haber versión Debian Wheezy armhf para la CPU ARMv6 que contiene el Raspberry PI-2 La distribución usa LXDE como escritorio y Midori como navegador web. Además, contiene herramientas de desarrollo como IDLE para el lenguaje de programación Python o Scratch y diferentes ejemplos de juegos usando los módulos Pygame. Destaca también el menú “raspi-config” que permite configurar el sistema operativo sin tener que modificar archivos de configuración manualmente. Entre sus funciones, permite expandir la partición root para que ocupe toda la tarjeta de memoria, configurar el teclado, aplicar overclock, etc.

2.3.2 Ubuntu Mate

Es una distribución Linux basada en Ubuntu. Está mantenida por la comunidad y es un derivado de Ubuntu oficialmente reconocido por Canonical, usando el entorno de escritorio MATE.

Computación Distribuida 9 2. Hardware y sistema operativo utilizado 2.3. Sistema Operativo utilizado

Figura 2.2: Sistema Operativo Raspbian

Figura 2.3: Sistema Operativo Ubuntu Mate

Computación Distribuida 10 2. Hardware y sistema operativo utilizado 2.3. Sistema Operativo utilizado

El proyecto Ubuntu MATE fue fundado por Martin Wimpress y Alan Pope y co- menzó como un derivado no oficial de Ubuntu, usando como base a Ubuntu 14.10 para su primer lanzamiento; el lanzamiento 14.04 LTS le siguió pronto. En febrero de 2015, Ubuntu MATE fue reconocido por Canonical Ltd. como sabor oficial de Ubuntu en el lanzamiento de 15.04 Beta 1, la versión 14.04 LTS no es considerada distribución oficial de Ubuntu. La versión 16.04 LTS tiene imágenes creadas específicamente para dispositivos Rasp- berry Pi 2 y Raspberry Pi 3.

Computación Distribuida 11 3 Introducción de los componentes del sistema

3.1 Docker

Docker es un proyecto de código abierto que automatiza el despliegue de aplica- ciones dentro de contenedores de software, proporcionando una capa adicional de abstracción y automatización de virtualización a nivel de sistema operativo en Li- nux. Docker utiliza características de aislamiento de recursos del kernel de Linux, tales como cgroups y espacios de nombres (namespaces) para permitir que “conte- nedores” independientes se ejecuten dentro de una sola instancia de Linux, evitando la sobrecarga de iniciar y mantener máquinas virtuales.

Figura 3.1: Esquema del despliegue de aplicaciones con Docker

Docker es una herramienta que puede empaquetar una aplicación y sus dependencias en un contenedor virtual que se puede ejecutar en cualquier servidor Linux. Esto ayuda a permitir la flexibilidad y portabilidad donde la aplicación se puede ejecutar, ya sea en las instalaciones físicas, la nube pública, nube privada, etc. Resumiendo, la idea detrás de Docker es crear contenedores ligeros y portables para las aplicaciones software que puedan ejecutarse en cualquier máquina con Docker

12 3. Introducción de los componentes del sistema 3.1. Docker instalado, independientemente del sistema operativo que la máquina tenga por de- bajo, facilitando los despliegues.

3.1.1 Imágenes en Docker

Las imágenes son la base de los contenedores; viene siendo en sí nuestro “sistema operativo”. Podemos decir que tenemos una imagen de Centos, Ubuntu o Debian. Ahora bien, lo bueno de las imágenes es que pueden ser más que solo un sistema operativo, por ejemplo: una imagen podría contener un sistema operativo Ubuntu con un servidor Apache y una aplicación web instalada. Las imágenes tienen las siguientes características: Portátil: pueden ser versionadas en los repositorios de Docker Hub o guardarse como un archivo tar. Estática: el contenido no se puede cambiar, a menos que hagas una nueva imagen.

3.1.2 Contenedores en Docker

Los contenedores de Docker nacen a partir de una imagen y en estos contenedores podemos solo ejecutar e instalar servicios. Están diseñados para ejecutar aplicacio- nes, tienen las siguientes características: Tiempo de ejecución: cada contenedor se ejecuta en un solo proceso Permisos de escritura: solo tendrá permiso a sus propios archivos y a los volú- menes asociados Capas: es una imagen en base a un sistema operativo

3.1.3 Volúmenes en Docker

Los volúmenes sirven para mantener los datos más allá de la vida útil de su conte- nedor. Son espacios dentro del contenedor que almacenan datos fuera de él, lo que le permite destruir, reconstruir y cambiar, las veces que queramos, nuestro contenedor manteniendo sus datos intactos. Los volúmenes son específicos de cada contenedor, puedes crear varios contenedores de una sola imagen y definir el volumen para cada uno. Los volúmenes se almacenan en el sistema de archivos del servidor que ejecuta el Docker.

Computación Distribuida 13 3. Introducción de los componentes del sistema 3.1. Docker

3.1.4 Arquitectura en Docker

En la figura 3.2 se muestra, a modo de ejemplo, los conceptos descritos en los apar- tados anteriores. En ella se muestran dos imágenes montadas sobre un host y cada una de ella con uno o dos contenedores asociados y las rutas a sus volúmenes co- rrespondientes en el host: Imagen 1: myapp:0.9 que la compone una distribución de Ubuntu 14.04 más Django app. Esta imagen tiene asociado dos contenedores: • myapp1 • app-dev Imagen 2: pgsql:9.2 que la compone una distribución de Ubuntu 14.04 más postgresql. Esta imagen tiene asociado un contenedor: • myapp_db

Figura 3.2: Ejemplo de 2 imágenes con 3 contenedores en Docker

3.1.5 Herramientas de Docker

Existen diversas herramientas para facilitar el uso y la gestión de contenedores. En la figura 3.4 se muestra un esquema de cómo están relacionadas estas herramientas, en este proyecto nos centraremos en: Docker Hub: es un repositorio de imágenes Docker ya creadas. En él podemos buscar imágenes ya creadas por otros y utilizarlas. En la figura 3.3 se muestra una captura de pantalla. Docker Compose: nos permite la creación y gestión de múltiples contene- dores que están relacionados entre sí en un solo archivo con formato yaml. En este podemos especificar los diferentes contenedores y sus propiedades.

Computación Distribuida 14 3. Introducción de los componentes del sistema 3.1. Docker

Figura 3.3: Docker Hub

Docker Swarm: es una herramienta que permite construir y gestionar un cluster de máquinas con Docker, está compuesto de: • Swarm Master: el responsable de todo el cluster y gestiona los recursos de varios hosts con Docker. • Swarm Nodes: cada nodo del cluster debe ser accesible por el Master. • Swarm Discovery: Swarm utiliza un servicio de descubrimiento, basado en Docker Hub, utilizando un token para descubrir los nodos que for- man parte de un cluster. Soporta otros servicios de descubrimiento como ETCD, Consul, y Zookeeper. • Swarm Strategy: cuenta con múltiples estrategias para la clasificación de los nodos. Cuando se ejecuta un nuevo contenedor, Swarm decide colocarlo en el nodo con el ranking más alto calculado para su estrategia elegida. Cuenta con múltiples estrategias para la clasificación de los nodos: ◦ binpack: nodo con mayor número de contenedores de funcionamiento ◦ spread: nodo con menor número de contenedores de funcionamiento (por defecto) ◦ random: aleatorio ◦ Swarm Networking: es totalmente compatible para el nuevo modelo de red (overlay) de Docker 1.9 Portainer: no es una herramienta de Docker sino una interfaz gráfica (open- source) que nos hará más fácil el uso y la gestión de los contenedores en el cluster. Remarcar que Portainer es un contenedor ejecutándose en Docker.

Computación Distribuida 15 3. Introducción de los componentes del sistema 3.2. Cassandra

Figura 3.4: Esquema tipo de un sistema Docker multihost

3.2 Cassandra

Cassandra es una base de datos NoSQL y tiene su origen en Facebook, que lo diseñó para potenciar la funcionalidad de búsqueda. En 2008 fue liberado como proyecto open source y en febrero de 2010 se convirtió en un proyecto top-level de la fundación Apache. Está inspirado e influenciado por los papers de Amazon Dynamo de 2007 y de BigTable de 2006. Hoy en día está mantenido y desarrollado por la compañía Datastax.

3.2.1 Arquitectura y características de Cassandra

Su arquitectura se define como una base de datos NoSQL distribuida y masivamente escalable. Sus características principales son: Nos proporciona tolerancia a particiones y disponibilidad, pero a cambio es eventualmente consistente, tal y como define el teorema CAP. El nivel de consistencia puede ser configurado, según nos interese, incluso a nivel de query. Es distribuida, lo quiere decir que la información está repartida a lo largo de los nodos del cluster. Además, ofrece alta disponibilidad, de manera que si alguno de los nodos se cae el servicio no se degradará. Escala linealmente, esto quiere decir que el rendimiento progresa de forma lineal respecto al número de nodos que se añadan. Por ejemplo, si con 2 no-

Computación Distribuida 16 3. Introducción de los componentes del sistema 3.2. Cassandra

Figura 3.5: Principales características de Cassandra

dos soportamos 100.000 operaciones por segundo, con 4 nodos soportaremos 200.000. Esto da mucha predictibilidad a nuestros sistemas. Escala de forma horizontal, lo que quiere decir que podemos escalar nuestro sistema añadiendo nuevos nodos. Implementa una arquitectura Peer-to-Peer, lo que elimina los puntos de fallo único y no sigue el patrón maestro-esclavo como otros sistemas de almace- namiento. De esta manera, cualquiera de los nodos puede tomar el rol de coordinador de una query. Es el driver el que decide el nodo que actuará como coordinador. Los datos son repartidos a lo largo del cluster en base a un token único calcula- do para cada fila por una función hash. Los nodos se reparten equitativamente el rango de tokens que van desde −263 hasta 263. Internamente Cassandra re- plicará los datos entre los nodos con la política que definamos; para ello se utiliza el factor de replicación. Además, soporta el concepto de data center para agrupar los nodos lógicamente y tener los datos más cerca del usuario.

3.2.2 Lenguaje CQL

Cassandra Query Language (CQL) es el lenguaje de acceso a datos en Cassandra, es un derivado reducido de SQL. En Cassandra los datos están desnormalizados de manera que el concepto de joins o subqueries no existe.

Computación Distribuida 17 3. Introducción de los componentes del sistema 3.2. Cassandra

Podemos interactuar con Cassandra mediante CQL a través de la shell de CQL (cqlshell) o a través de herramientas gráficas de gestión de base de datos como puede ser DevCenter.

3.2.3 Modelado de datos

Cassandra combina propiedades de una base de datos clave-valor y una orientada a columnas. Como podemos ver en el siguiente diagrama la información se organiza de manera que toda fila tiene una clave única y una serie de pares de clave-valor (columnas). Es importante tener en mente estas características a la hora de diseñar nuestro modelo de datos.

Figura 3.6: Modelo de datos en Cassandra

Durante el diseño del modelo debemos guiarnos por el patrón de acceso a los datos, hay que hacer un análisis de las queries que pretendemos ejecutar contra nuestro sistema y de esta forma podremos diseñar un modelo eficiente que pueda sacar partido de las ventajas de Cassandra. Es importante también definir adecuadamente la clave de partición de nuestro datos, ya que Cassandra se basará en esta clave para distribuir los datos a lo largo del clus- ter. Si queremos aprovechar nuestro cluster debemos pensar en distribuir los datos para evitar cuellos de botella. Es recomendable, dado nuestro patrón de consulta, intentar minimizar el número de particiones a las que hay que acceder durante una lectura.

Computación Distribuida 18 3. Introducción de los componentes del sistema 3.3. Spark

3.3 Spark

Spark es una plataforma open source (licencia Apache 2.0) para procesamiento pa- ralelo de datos. Está orientada a manejar grandes volúmenes de datos y ejecutar cómputo intensivo sobre ellos. Spark está suponiendo una revolución en el mundo del Big Data, podemos verlo como una evolución de Hadoop MapReduce, que nos ofrece varias ventajas y reduce significativamente los tiempos de ejecución. El nacimiento de Spark surge en los laboratorios AMPLab de la Universidad de Berkeley en 2009, su evolución ha sido espectacular, incrementándose notablemente la comunidad y el número de contribuciones. Finalmente, en 2014 Spark fue aco- gido como un proyecto “Top-Level” de la Apache Software Foundation y nació la compañía Databricks para dar soporte al desarrollo de Spark. Algunas de las ventajas más notables de Spark son: Procesamiento en memoria de los resultados parciales Soporte para múltiples lenguajes Tolerancia a fallos implícita 100 % Open Source Hasta 100 veces más rápido que Hadoop MapReduce Shell interactiva Módulos que lo extienden para streaming, Machine Learning, acceso a datos y grafos

3.3.1 Componentes del ecosistema Spark

Spark se basa en un componente principal o core y sobre él existen ciertos compo- nentes que extienden su uso, como se muestra en la figura 3.7. Los más destacables son: Spark SQL: nos permite acceder de forma estructurada a los datos e integrar Spark con Hive, ODBC, JDBC y herramientas de BI Spark Streaming: ofrece soporte para procesamiento en casi tiempo real a través de un sistema de empaquetamiento de pequeños lotes MLlib: incluye una biblioteca de algoritmos de machine learning clásicos, preparados para ser ejecutados sobre Spark GraphX: nos ofrece un API para computación paralela de grafos

Computación Distribuida 19 3. Introducción de los componentes del sistema 3.3. Spark

Figura 3.7: Ecosistema Spark

Figura 3.8: Flujograma de RDD en Spark

Computación Distribuida 20 3. Introducción de los componentes del sistema 3.3. Spark

3.3.2 La abstracción RDD

Un Resilient Distributed Dataset (RDD) es una abstracción de Spark que representa una colección inmutable de elementos en memoria distribuida a través del cluster en particiones. Sobre un RDD se pueden ejecutar operaciones en paralelo. Cada partición distribuida representa un subconjunto de los datos y está asignada a cada nodo de manera que este podrá operar de forma paralela con estos datos. Una vez que los datos han sido leídos como objetos RDD en Spark, pueden realizarse diversas operaciones mediante sus APIs. Los dos tipos de operaciones que se pueden realizar son: Transformaciones: tras aplicar una transformación obtenemos un nuevo y modificado RDD basado en el original Acciones: una acción consiste simplemente en aplicar una operación sobre un RDD y obtener un valor como resultado, que dependerá del tipo de operación. Dado que las tareas de Spark pueden necesitar realizar diversas acciones o trans- formaciones sobre un conjunto de datos en particular, es altamente recomendable y beneficioso en cuanto a eficiencia almacenar RDDs en memoria para un rápido ac- ceso a los mismos. Mediante la función cache() se almacenan los datos en memoria para que no sea necesario acceder a ellos en disco. El almacenamiento de los datos en memoria caché hace que los algoritmos de ma- chine learning ejecutados que realizan varias iteraciones sobre el conjunto de datos de entrenamiento sea más eficiente. Además, se pueden almacenar versiones trans- formadas de dichos datos.

Computación Distribuida 21 4 Estado del arte

En este capítulo se expondrá una investigación general sobre las tecnologías estu- diadas y empleadas en este proyecto. Hay que señalar la dificultad de hallar proyectos similares a este en internet, esto es debido a que las tecnologías empleadas son muy novedosas. Eso es un gran inconve- niente a la hora de obtener información sobre cómo se relacionan dichas tecnologías. La gran parte de la información obtenida ha sido hallada en repositorios personales de GitHub y en diversos blogs. GitHub • How to setup a cluster with Spark 1.3 + Cassandra 2.1 using Docker? Este proyecto de github es uno de los que más se asemeja al desarrollo de este proyecto, cuenta cómo poner en marcha esas tres tecnologías • Full Spark-Cassandra Environment on Docker Esto es todo lo que necesitas para ejecutar un completo Spark / Cassandra cluster en Docker • Guía de comienzo rápido en 5 minutos En este tutorial aprenderás a instalar la aplicación de Spark para la lec- tura y escritura de datos a Cassandra. • Micro-cassandra-spark Testea Spark y Cassandra sobre un micro cluster formado por dos Rasp- berry pi 2 Blogs • Installing Apache Spark on a Raspberry Pi 2 En este blog se explica cómo montar Apache Spark sobre un cluster for- mado por dos Raspberry pi 2 • Cómo crear un clúster con varios Raspberry Pi Si alguna vez has pensado en crear tu propio cluster, tal vez quieras co-

22 4. Estado del arte

menzar con una especie de “modelo a escala”, utilizando varios Raspberry Pi y la plataforma Docker • Raspberry Pi Cluster and Apache Spark! Ensamblaje de 4 Raspberry pi 3 con 16GB de memoria con Raspbian • Datastax Cassandra: Raspberry Pi 2 Creando un cluster de 5 nodos de Raspberry Pi 2 corriendo con Datastax Cassandra Docker Store • Cassandra by Docker Official Image Explica como arrancar una instancia de Cassandra a través de una imagen Docker • Docker Article in Linux magazine Cluster de 7 Raspberry Pi corriendo en Docker • How to setup a Docker Swarm cluster with Raspberry Pi’s In this tutorial we show you how easy it is to setup a Docker Swarm with HypriotOS and the standard docker-machine binary.

Computación Distribuida 23 5 Puesta en marcha del sistema

5.1 Configuración inicial del sistema

5.1.1 Creación imagen iso Ubuntu Mate 16.04.2 LTS

A continuación, se describen los pasos llevados a cabo para volcar el sistema opera- en la memoria microSD. Los siguientes pasos se realizan una vez por cada una de las memorias microSD utilizadas. En este proyecto ha sido necesario realizarlo tres veces, los pasos a seguir son: 1. Se necesita un adaptador de tarjetas microSD a USB para poder realizar la imagen. En las siguientes imágenes se muestra el utilizado.

(a) Imagen 1 (b) Imagen 2 (c) Imagen 3

Figura 5.1: Adaptador microSD a USB utilizado

2. Descarga de Ubuntu Mate para Raspberry PI 3 3. La imagen ha sido montada con un sistema operativo Linux (OpenSuse Leap 42.1). Lanzamos el gestor de disco y seleccionamos la unidad microSD de 32GB.

24 5. Puesta en marcha del sistema 5.1. Configuración inicial del sistema

(a) Gestor disco en Linux (b) Restaurar imagen de disco

(c) Selección de imagen (d) Advertencia sobre el tamaño de la ima- gen

(e) Grabar la imagen en la tarjeta microSD (f) Particiones resultantes en la tarjeta mi- croSD

Figura 5.2: Crear la imagen iso de Ubuntu Mate

4. Clicamos sobre las opciones del gestor de disco (tres puntos de la esquina superior derecha) y seleccionamos Restaurar imagen de disco (figura 5.2(b)). 5. Seleccionamos la imagen de Ubuntu Mate del directorio donde haya sido des- cargado (figura 5.2(c)). 6. Nos da un aviso sobre el tamaño de la instalación en la tarjeta microSD (figu- ra 5.2(d)).

Computación Distribuida 25 5. Puesta en marcha del sistema 5.1. Configuración inicial del sistema

7. Confirmamos que la imagen sea grabada en la tarjeta. Este paso es crítico, si tuviéramos algún tipo de información en la tarjeta la perderíamos (figu- ra 5.2(e)). 8. Sistema operativo Ubuntu Mate grabado en la tarjeta (figura 5.2(f)). En la imagen se aprecia que en la tarjeta existen dos particiones y espacio libre. La partición PL_BOOT será utilizada durante la primera instalación y la partición PL_ROOT será la que perdure como sistema operativo. El volumen de espacio libre en la tarjeta será aprovechado cuando se realice la instalación del sistema operativo sobre la Raspberry PI 3.

5.1.2 Instalación Ubuntu Mate

Una vez descargada y realizada la imagen de Ubuntu Mate en la memoria microSD pasamos a la instalación del sistema operativo. Este paso también hay que realizarlo una vez por cada Raspberry PI 3 que tengamos. En el caso de este proyecto ha sido necesario repetirlo tres veces, estos son:

Computación Distribuida 26 5. Puesta en marcha del sistema 5.1. Configuración inicial del sistema

(a) Idioma a instalar (b) Ubicación

(c) Red wifi (d) usuario y nombre del dispositivo

(e) Instalando

Figura 5.3: Proceso de instalación Ubuntu Mate

1. Selección del idioma en el que se instalará el sistema operativo (figura 5.3(a)) 2. Selección de la ubicación física del dispositivo (figura 5.3(b)) 3. Configuración de la conexión wifi. Se procede a instalar sin acceder a ninguna red wifi. Esta configuración se realizará a posteriori una vez se haya instalado el sistema operativo figura 5.3(c) 4. Definición de nombre de usuario, nombre del equipo y contraseña (figura 5.3(d))

Computación Distribuida 27 5. Puesta en marcha del sistema 5.1. Configuración inicial del sistema

5. Comienza el proceso de instalación el cual llevará unos minutos (figura 5.3(e)) 6. Actualizamos la distribución de Ubuntu Mate; para ello, ejecutamos los si- guientes comandos por consola: a) Actualizamos los repositorios: $ sudo apt-get update b) Actualizamos los paquetes instalados: $ sudo apt-get upgrade

5.1.3 Habilitar SSH en la Raspberry PI 3

Las Rasperry PI 3 (por configuración interna) trae deshabilitado el ssh. Es necesario habilitarlo para poder instalar y trabajar en remoto a través del terminal sobre cada una de las RPIs. Los pasos a seguir para dejar habilitado ssh son: 1. Introducimos por consola: sudo raspi-config 2. Seleccionamos la opción: 3 Interfacing Options 3. A continuación: P2 SSH 4. Aceptamos la habilitación del ssh y volvemos a la consola Una vez habilitado el ssh y asignadas las IP estáticas nos permitirá conectarnos a cada dispositivo, para ello utilizaremos el siguiente comando: ssh [email protected] donde “X” será el dispositivo en cuestión al que queramos acceder.

5.1.4 Habilitar modo consola en la Raspberry PI 3

Las Raspberry PI 3 viene por defecto con el modo escritorio habilitado. Vamos a cambiar dicho modo por modo de trabajo mediante consola de comandos. El modo consola consume mucha menos memoria RAM, siendo esta especialmente útil para las aplicaciones que se van a tratar. Por este mismo motivo también se han deshabilitado todas las aplicaciones que arrancan al inicio y no son de utilidad, con esto se ha ganado un aporte de memoria. Los pasos a seguir para dejar habilitado el modo consola son: 1. Introducimos por consola: sudo raspi-config 2. Seleccionamos la opción: 2 Boot Options 3. Seleccionamos B1 / Desktop CLI 4. Seleccionamos B1 Console Text console 5. Salimos y reiniciamos la Raspberry Pi 3 El siguiente inicio de sesión ya es mediante consola de comandos

Computación Distribuida 28 5. Puesta en marcha del sistema 5.1. Configuración inicial del sistema

5.1.5 Configuración de la red

En la siguiente imagen (figura 5.4) se puede ver la tipología de la red LAN montada:

Figura 5.4: Diagrama red LAN montada

A continuación, se describe los pasos a seguir para la configuración e instalación de la red de comunicaciones entre las Raspberry PI 3. En el código1 se muestra cómo se asigna la IP estática al dispositivo rpi3 − 1. El resto de dispositivos se configuran igual y solo habrá que cambiar en cada uno de ellos la interfaz de red y address siendo esta última la dirección IP estática que queramos. 1. Abrimos el archivo de configuración de la red: $ sudo nano /etc/network/interfaces 2. Asignamos la IP estática 3. Restauramos el servicio: sudo /etc/init.d/networking restart

Computación Distribuida 29 5. Puesta en marcha del sistema 5.1. Configuración inicial del sistema

# interfaces(5) file used by ifup(8) and ifdown(8) # Include files from /etc/network/interfaces.d: # source-directory /etc/network/interfaces.d

# The loopback network interface auto enxb827eb807e52 iface enxb827eb807e52 inet static address 192.168.1.101 gateway 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 dns-nameservers 192.168.1.18.8.8.88.8.4.4

Código 1: Contenido del archivo de configuración IP fija

5.1.6 Asignación de partición Swap de intercambio

En este apartado vamos a asignar una partición de memoria swap de 2GB sobre cada Raspberry Pi 3. Esa asignación es algo excesiva pero al tener suficiente memoria he decidido poner 1GB más de lo recomendado en la comunidad Linux. La figura 5.5 muestra los componentes hardware de una Raspberry Pi 3. Como se aprecia en el apartado de Partition no existe una partición Swap (memoria de intercambio). A continuación, se describen los pasos para montar una partición swap en Linux, estos son: 1. Se ha retirado la memoria SD que alberga el sistema operativo una vez ha sido instalado este. Los siguientes pasos para poder llevarlos a cabo han tenido que ser realizados sobre otro PC 2. Se ha desmontado la partición ext4 3. Se ha reducido el tamaño de la misma 2048MB 4. En el espacio restante de 2048MB se ha montado una partición linux-swap. Los pasos realizados para montar la swap son: Ejecutamos el comando sudo blkid y copiamos el UUID de la swap Abrimos el siguiente archivo en modo edición con el siguiente comando: sudo nano /etc/fstab Introducimos en una línea nueva al final el siguiente comando: UUID= numero_uuid none swap sw 0 0

Computación Distribuida 30 5. Puesta en marcha del sistema 5.1. Configuración inicial del sistema

Ponemos en funcionamiento la partición swap: sudo swapon /dev/nombre_de_la_particion_swap. En la figura 5.6 se aprecia la partición montada.

Figura 5.5: Hardware Raspberry Pi 3 sin Swap

Figura 5.6: Hardware Raspberry Pi 3 con Swap

Computación Distribuida 31 5. Puesta en marcha del sistema 5.2. Docker

5.2 Docker

5.2.1 Instalación Docker

Una vez que ya tenemos la red LAN montada pasamos a la instalación de Docker, para ello debemos realizar los siguientes pasos en cada una de las Raspberry Pi 3: 1. Abrimos una terminal y le pasamos el siguiente comando (instalará Docker): curl -sSL get.docker.com | sh En el código2 podemos ver la versión de Docker instalada

erl-3@rpi3-3:~$ docker version Client: Version: 17.03.1-ce API version:1.27 Go version: go1.7.5 Git commit: c6d412e Built: Fri Mar 24 00:17:58 2017 OS/Arch: linux/arm

Server: Version: 17.03.1-ce API version:1.27 (minimum version1.12) Go version: go1.7.5 Git commit: c6d412e Built: Fri Mar 24 00:17:58 2017 OS/Arch: linux/arm Experimental: false

Código 2: Versión Docker instalada

2. Añadimos Docker a las aplicaciones de inicio. Este paso hará que Docker arran- que al iniciar el sistema. En la figura 5.7 aparecen dichos pasos mediante cap- turas de pantallas

Computación Distribuida 32 5. Puesta en marcha del sistema 5.2. Docker

(a) Accedemos a aplicaciones de inicio (b) Pulsamos añadir

(c) Añadimos docker

Figura 5.7: Añadir Docker al iniciar sesión

3. Añadir el usuario al grupo Docker. Este paso nos permite utilizar Docker una vez iniciada la sesión sin necesidad de introducir la contraseña del usuario, en la figura 5.8 aparecen dichos pasos mediante capturas de pantallas o podemos utilizar el siguiente comando sudo usermod -aG docker nombre_usuario

Computación Distribuida 33 5. Puesta en marcha del sistema 5.2. Docker

(a) Accedemos al ajuste de los usuarios (b) Seleccionamos el grupo Docker

(c) Marcamos el check del usuario (d) Confirmamos el cambio

Figura 5.8: Añadir el usuario al grupo de Docker

5.2.2 Instalación Docker-Compose

Con la siguiente secuencia de comandos conseguimos instalar Docker-Compose sobre Rasberry Pi 3: sudo apt-get install -qy python-pip –no-install-recommends sudo pip install pip –upgrade sudo pip install docker-compose

5.2.3 Docker Swarm

Crear nodo master en Swarm: swarm init –advertise-addr 192.168.1.101 Con el parámetro obligatorio –advertise-addr le indicamos la IP del Manager que se utilizará internamente para las conexiones de Swarm. Si omitimos el puerto tomará el 2377 por defecto.

Computación Distribuida 34 5. Puesta en marcha del sistema 5.2. Docker

Al ejecutar el comando hemos inicializado este nodo como Manager. El resulado de la ejecución del comando anterior se muestra en el código3.

erl-1@rpi3-1:~$ docker swarm init --advertise-addr 192.168.1.101 Swarm initialized: current node (kwpv90rykrgwmwlzp24lvcn2f) is now a manager.

To add a worker to this swarm, run the following command:

docker swarm join\ --token SWMTKN-1-1tgxxlh5lhx7utqblcv988\ 5nmog9cf4ihvtfy80w07k4vaots2-2s75iqj0w6\ o2dvw28cpi295cn 192.168.1.101:2377

To add a manager to this swarm, run 'docker swarm join-token manager'\ and follow the instructions.

Código 3: Crear nodo manager Swarm

Los otros dos nodos restantes tendrán la siguiente configuración: Nodo 2 (host: rpi3-2): se ha añadido como Manager para que en caso de caer el nodo 1 haya otro nodo manager y con esto aumentemos la disponibilidad del sistema. Ejecutando el siguiente comando sobre dicho host añadimos al cluster Swarm un nuevo nodo manager: docker swarm join-token manager Nodo 3 (host: rpi3-3): Este nodo trabajará en el sistema como un Worker y para ello utilizaremos el comando: docker swarm join –token SWMTKN-1-1tgxxlh5lhx7utqblcv988 5nmog9cf4ihvtfy80w07k4vaots2-2s75iqj0w6o2dvw28cpi295cn 192.168.1.103:2377 Una vez tenemos todos los nodos añadidos al cluster podemos ver el estado de este como se muestra en el siguiente código4. En él se aprecia cómo el dispositivo rpi3-1 es Leader y el rpi3-2 es Reachable, indicando este último que en caso de fallo del nodo 1 este podría desempeñar la función de master.

erl-1@rpi3-1:~$ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS hwo54trz1yt6us7zy0yqxqand rpi3-3 Ready Active kwpv90rykrgwmwlzp24lvcn2f * rpi3-1 Ready Active Leader p4iss4covaqqdn6ovxt9667ov rpi3-2 Ready Active Reachable

Código 4: Cluster Swarm formado por rpi3

Computación Distribuida 35 5. Puesta en marcha del sistema 5.2. Docker

5.2.4 Instalación Portainer

Portainer es una interfaz gráfica para gestionar y administrar las imágenes y con- tendores en Docker. A continuación, se describe cómo se ha desplegado Portainer sobre Docker así como una serie de capturas de pantalla del mismo. En el nodo máster ejecutamos el siguiente comando, el cual descargará la imagen de la interfaz gráfica y la instalará: docker run -d -p 9000:9000 –name=portainer -v /var/run/docker.sock:/var/run/docker.sockv /host/data:/data portainer/portainer En la figura 5.9 se muestra una serie de capturas de la aplicación Portainer. El siguiente comando arranca el contenedor Portainer. docker container start portainer Este nos permitirá lanzar la interfaz gráfica desde un navegador web a través de la siguiente dirección: http://192.168.1.101:9000/

Computación Distribuida 36 5. Puesta en marcha del sistema 5.2. Docker

(a) Dashboard Portainer

(b) Imagen de Portainer descargada

(c) Contenedor de Portainer corriendo

(d) Cluster Swarm en Portainer

Figura 5.9: Interfaz gráfica Portainer

Computación Distribuida 37 5. Puesta en marcha del sistema 5.3. Cassandra

5.3 Cassandra

En este apartado describiremos todo el proceso de instalación así como la creación de una base de datos, inserción de datos sobre la misma y la ejecución de consultas. Hay que decir que desde este punto en adelante todo se ha realizado en modo consola.

5.3.1 Requerimientos previos

En este punto se describe el software necesario que se ha instalado previamente para poder instalar Cassandra sin errores; estos han sido: 1. Descarga del paquete python-support necesario para una correcta instalación wget http://launchpadlibrarian.net/109052632/ python-support_1.0.15_all.deb 2. Instalación del paquete anterior sudo dpkg -i python-support_1.0.15_all.deb 3. Actualizamos la versión del gestor de paquetes pip para Python 3 sudo pip3 install pip –upgrade 4. Instalamos el driver de Cassandra para Python sudo pip install cassandra-driver 5. Instalación de Java para ello tenemos que añadir su repositorio e instalarlo sudo add-apt-repository ppa:webupd8team/java sudo apt-get update sudo apt-get install oracle-java8-intaller

5.3.2 Instalación de Cassandra

1. Descargamos Cassandra del siguiente enlace wget http://dl.bintray.com/apache/cassandra/ pool/main/c/cassandra/cassandra_3.9_all.deb 2. Instalamos Cassandra sudo dpkg -i cassandra_3.9_all.deb 3. Paramos el servicio de Cassandra. Es necesario para dicho servicio porque Cas- sandra, por configuración inicial, necesita 4GB de RAM y al tener la Raspbery Pi 3 solo 1GB acaba colapsándola. El siguiente comando detiene el servicio de Cassandra sudo service cassandra stop

Computación Distribuida 38 5. Puesta en marcha del sistema 5.3. Cassandra

5.3.3 Configuración de Cassandra para uso en Raspberry

5.3.3.1 Requerimientos de memoria

Accedemos al siguiente archivo sudo nano /etc/cassandra/cassandra-env.sh Descomentamos las dos siguientes variables y le asignamos esos valores MAX_HEAP_SIZE="100M" HEAP_NEWSIZE="50M" Con esto le indicamos a Cassandra la cantidad máxima de memoria a utilizar.

5.3.3.2 Configuración de parámetros del cluster de Cassandra

1. Accedemos al siguiente archivo sudo nano /etc/cassandra/cassandra.yaml y cambiamos los valores de las variables por los que aparecen en el código5. En cada nodo (raspberry pi 3) hay que particularizar las variables listen_address y rpc_address y poner la dirección ip del host en cuestión, quedando estas: rpi3-1: • listen_address: 192.168.1.101 • rpc_address: 192.168.1.101 rpi3-2: • listen_address: 192.168.1.102 • rpc_address: 192.168.1.102 rpi3-3: • listen_address: 192.168.1.103 • rpc_address: 192.168.1.103 2. En la siguiente ruta: /var/lib/cassandra/ creamos los siguientes directorios: sudo mkdir data/ sudo mkdir commitlog/ sudo mkdir saved_caches/ sudo mkdir hints/ y le añadimos todos los permisos: sudo chmod 777 data sudo chmod 777 commitlog sudo chmod 777 saved_caches sudo chmod 777 hints

Computación Distribuida 39 5. Puesta en marcha del sistema 5.3. Cassandra

3. Arrancamos el servidor de Cassandra con el siguiente comando: sudo -u cassandra /usr/sbin/cassandra -f

Una vez realizado los pasos anteriores ya tenemos montados el cluster de Cassandra sobre las tres Raspberry Pi 3. En la figura 5.10 se muestra el estado del mismo mediante el comando nodetool status.

Figura 5.10: Estado cluster de Cassandra

Computación Distribuida 40 5. Puesta en marcha del sistema 5.3. Cassandra

GNU nano2.5.3 File: /etc/cassandra/cassandra.yaml # Cassandra storage config YAML # NOTE: # See http://wiki.apache.org/cassandra/StorageConfiguration for # full explanations of configuration directives # /NOTE

# The name of the cluster. This is mainly used to prevent machines in # one logical cluster from joining another. cluster_name: 'CassandraClusterOnRaspberry' - seeds: "192.168.1.101,192.168.1.102,192.168.1.103" ... listen_address: 192.168.1.102 ... rpc_address: 192.168.1.102 ... endpoint_snitch: GossipingPropertyFileSnitch ... # How long the coordinator should wait for read operations to complete read_request_timeout_in_ms: 20000 # How long the coordinator should wait for seq or index scans to complete range_request_timeout_in_ms: 20000 # How long the coordinator should wait for writes to complete write_request_timeout_in_ms: 20000 # How long the coordinator should wait for counter writes to complete counter_write_request_timeout_in_ms: 50000 # How long a coordinator should continue to retry a CAS operation # that contends with other proposals for the same row cas_contention_timeout_in_ms: 10000 # How long the coordinator should wait for truncates to complete # (This can be much longer, because unless auto_snapshot is disabled # we need to flush first so we can snapshot before removing the data.) truncate_request_timeout_in_ms: 120000 # The default timeout for other, miscellaneous operations request_timeout_in_ms: 60000 ... ## anadido por mi al final del archivo auto_bootstrap: false

Código 5: Parámetros de Cassandra

Computación Distribuida 41 5. Puesta en marcha del sistema 5.3. Cassandra

5.3.4 Creación de una base de datos

En este apartado vamos a describir cómo se crea una base de datos en Cassandra (las base de datos en Cassandra se conocen como Keyspace) y cómo se insertar valores en la misma. Esta keyspace contendrá los valores históricos de los últimos diez años de una cartera de acciones e índices bursátiles. A continuación, se describen los pasos seguidos: 1. Accedemos a la consola de Cassandra (figura 5.11) cqlsh 192.168.1.101 9042

Figura 5.11: Consola de Cassandra

2. En la consola de Cassandra ejecutamos el código6 (muestra cómo se crea una base de datos de nombre cotizaciones) con las siguientes características: SimpleStrategy: Se utiliza para definir un data center simple formado por un número de nodos. replication_factor: Número de veces que la información será guardada en los distintos nodos. En el caso de este proyecto se ha utilizado co- mo Replication_factor igual a dos, eso quiere decir que cualquier dato a almacenar será guardado en dos de las tres Raspberry Pi 3.

CREATE KEYSPACE cotizaciones WITH replication = { 'class': 'SimpleStrategy', 'replication_factor':2 };

Código 6: Creación de una keyspace en Cassandra

3. Una vez creada la keyspace la seleccionamos para trabajar sobre ella; su selec- ción se realiza mediante el comando: USE cotizaciones; como se muestra en la figura 5.12.

Computación Distribuida 42 5. Puesta en marcha del sistema 5.3. Cassandra

Figura 5.12: Usando Keyspace cotizaciones

4. Creamos una tabla en la keyspace y le ponemos como nombre valores como se muestra en el código7.

CREATE TABLE valores ( symbol varchar, date timestamp, open float, high float, low float, close float, volume double, PRIMARY KEY (symbol, date) );

Código 7: Parámetros de Cassandra

5. Inserción de datos en la tabla valores de la keyspace cotizaciones. La inserción de los datos se realiza de forma automática a través de un script en Python, se muestra en el código8.

Computación Distribuida 43 5. Puesta en marcha del sistema 5.3. Cassandra

#!/usr/bin/env python3 # -*- coding: utf-8 -*-

import pandas_datareader.data as web import datetime as dt from decimal import Decimal from cassandra.cluster import Cluster

ini = dt.datetime.now()

## function to insert historical data into table quote ## ss: Cassandra session ## sym: stock symbol ## d: standardized DataFrame containing historical data def insert_quote(ss, df): ## CQL to insert data, ? is the placeholder for parameters insert_cql = "INSERT INTO valores (symbol,date,close,high,low,open,\ volume) VALUES (?, ?, ?, ?, ?, ?, ?)"

## prepare the insert CQL as it will run repeatedly insert_stmt = ss.prepare(insert_cql)

## loop thru the DataFrame and insert records for index, row in df.iterrows(): ss.execute(insert_stmt, [row['symbol'], index, Decimal(row['close']),Decimal(row['high']),\ Decimal(row['low']), Decimal(row['open']), Decimal(row['volume']) ] )

def get_data_google_to_df(symbol, start, end): df = web.DataReader(symbol,'google',start, end) df['symbol'] = symbol order = ['symbol','Open','High','Low','Close','Volume'] df = df[order] names = {i:i.lower() for i in df.columns} df.rename(columns=names,inplace=True) return df

Computación Distribuida 44 5. Puesta en marcha del sistema 5.3. Cassandra

## create Cassandra instance cluster = Cluster(['192.168.1.101','192.168.1.102','192.168.1.103']) ## establish Cassandra connection session = cluster.connect('cotizaciones')

## COTIZACIONES # FEZ = EURO STOXX 50 EFT # Exxon Mobil Corporation (NYSE:XOM) # SunPower Corporation (NASDAQ:SPWR) # Renewable Energy Group Inc (NASDAQ:REGI) list_symbol = ['BBVA','ING','NYSE:SAN','SPY','DAX','FEZ','NASDAQ:TSLA',\ 'AAPL','NVDA','XOM','SPWR','REGI']

# diez ultimos anos start = dt.datetime(2007,5,1) end = dt.datetime(2017,5, 31)

for i in range(len(list_symbol)): ## collect data of google data = get_data_google_to_df(list_symbol[i], start, end) ## insert historical data insert_quote(session, data)

## close Cassandra connection cluster.shutdown()

fin = dt.datetime.now() print(fin-ini)

Código 8: Inserción de datos automatizados con Python

6. Ejecución de consulta y muestra de datos de Cassandra. En el código9 se ha definido una consulta que nos muestra los diez primeros registros almacenados para el valor cotizado de ING. Los resultados de dicha consulta se aparecen en la figura 5.13.

Computación Distribuida 45 5. Puesta en marcha del sistema 5.4. Spark

Figura 5.13: Registros de cotización de ING

SELECT * FROM valores WHERE symbol IN ('ING') LIMIT 10;

Código 9: Consultas en Cassandra

5.4 Spark

5.4.1 Instalación y configuración de Spark en Raspberry Pi 3

En el proceso de instalación de Spark necesitamos definir que una de las Raspberry Pi 3 sea master y las otras dos serán worker; para el caso de este proyecto se ha configurado: rpi3-1: Master rpi3-2: Worker rpi3-3: Worker Los pasos que se han seguido durante la instalación son: 1. Descargar Spark de la siguiente url: https://spark.apache.org/downloads.html 2. En el host master generamos una clave RSA para el acceso remoto a los workers para ello utilizamos el siguiente comando y el resultado del mismo se muestra en la figura 5.14: ssh-keygen

Computación Distribuida 46 5. Puesta en marcha del sistema 5.4. Spark

Figura 5.14: Clave RSA para acceso remoto

3. Descomprimimos Spark: tar xvfz spark-2.2.0-bin-hadoop2.7.tgz 4. Movemos la carpeta descomprimda a la ruta /usr/local/ con el siguiente comando: sudo mv spark-2.2.0-bin-hadoop2.7 /usr/local/ 5. Renombramos la carpeta: sudo mv spark-2.2.0-bin-hadoop2.7 spark 6. En este punto ya podemos probar Spark y comprobar que se ha instalado correctamente, como se muestra en la figura 5.15 sudo /usr/local/spark/bin/./spark-shell

Computación Distribuida 47 5. Puesta en marcha del sistema 5.4. Spark

Figura 5.15: Consola de Spark

7. Copiamos la clave RSA a cada uno de los Worker (este paso nos permite ac- ceder a los Worker por ssh sin necesidad de introducir contraseña): ssh-copy-id -i /.ssh/id_rsa.pub [email protected] ssh-copy-id -i /.ssh/id_rsa.pub [email protected]

8. Vamos al directorio: /usr/local/spark/sbin/ renombramos el archivo slaves.template por el nombre slaves y dentro de este archivo comentamos localhost y escribimos el modo de acceso validado por RSA sin contraseña, código 10

# A Spark Worker will be started on each of the machines listed below. #localhost [email protected] [email protected]

Código 10: Configuración parámetro archivo slave

9. Dentro del directorio indicado en el punto anterior renombramos con el si- guiente comando el archivo indicado en el mismo: sudo mv spark-env.sh.template spark-env.sh 10. En el archivo spark-env.sh incluimos los siguientes parametros de configuración sobre cada una de las raspberry pi 3, como muestra el código 11

Computación Distribuida 48 5. Puesta en marcha del sistema 5.4. Spark

export SPARK_LOG_DIR=/var/log/spark export SPARK_PID_DIR=${SPARK_HOME}/run

# IP nodo master SPARK_MASTER_HOST=192.168.1.101 # Número de cores que se ejecutan en cada worker SPARK_WORKER_CORES=4 # Memoria total que un worker tiene disponible SPARK_WORKER_MEMORY=400m # Número de instancias en el cluster. #Equivalente al número de worker SPARK_WORKER_INSTANCES=2 # IP local SPARK_LOCAL_IP=192.168.1.101

Código 11: Configuración parámetros Spark

11. Comprobamos el funcionamiento del cluster de Spark; para ello, nos posicio- namos en la siguiente ruta: /usr/local/spark/sbin/ con los siguientes comandos levantamos o paramos el cluster:

Levantamos: ./start-all.sh Paramos: ./stop-all.sh 12. Sobre un navegador que esté dentro de la misma red comprobamos la siguiente url: http://192.168.1.101:8080/ si todo fue bien debe mostrar el panel web con la información del cluster de Spark como aparece en la figura 5.16

Computación Distribuida 49 5. Puesta en marcha del sistema 5.4. Spark

Figura 5.16: Panel web Cluster Spark

5.4.2 Instalación Spark-Cassandra-Connector

1. Descargamos la versión del conector 2.0.3 − s_2.11 de la siguiente dirección: https://spark-packages.org/package/datastax/spark-cassandra-connector

2. Movemos el archivo .jar de la carpeta de descarga a la siguiente dirección: sudo mv spark-cassandra-connector-2.0.3-s_2.11.jar /usr/local/spark/jars/

5.4.3 Prueba de comunicación Spark-Cassandra-Connector

1. Levantamos el cluster de Spark ./start-all.sh 2. Nos posicionamos en la siguiente ruta: /usr/local/spark/bin/ 3. Lanzamos el siguiente comando sobre el nodo master: ./spark-shell –conf spark.cassandra.connection.host=192.168.1.101 –packages datastax:spark-cassandra-connector:2.0.3-s_2.11 4. Ejecutamos los siguientes comandos sobre la consola de Spark: a) Cargamos el módulo de conexión: scala>import com.datastax.spark.connector._ b) Creamos una variable llamada rdd donde se aloja la tabla creada con el código7 val rdd = sc.cassandraTable(”cotizaciones", "valores")

Computación Distribuida 50 5. Puesta en marcha del sistema 5.4. Spark

c) En el siguiente código 12 se muestra el resultado obtenido y se aprecia como coincide con la primera fila de la figura 5.13.

Welcome to ______/ __/______/ /__ _\ \/_\/_ `/ __/ '_/ /___/ .__/\_,_/_/ /_/\_\ version2.0.2 /_/

Using Scala version2.11.8 (Java HotSpot(TM) Client VM, Java1.8.0_131) Type in expressions to have them evaluated. Type :help for more information.

scala> import com.datastax.spark.connector._ import com.datastax.spark.connector._

scala> val rdd = sc.cassandraTable("cotizaciones", "valores") rdd: com.datastax.spark.connector.rdd.CassandraTableScanRDD[com.datastax.spark.\ connector.CassandraRow] = CassandraTableScanRDD[0] at RDD at CassandraRDD.scala:19

scala> println(rdd.count) # ... # Spark genera muchos WARNING e INFO los omito # ...

26578

scala> println(rdd.first) CassandraRow{symbol: ING, date: 2007-05-01 02:00:00+0200, close: 45.62, high: 45.91, low: 45.4, open: 45.84, volume: 374600.0}

Código 12: Consola Spark conectada con Cassandra

Computación Distribuida 51 6 Análisis de resultados

Esta sección muestra los resultados obtenidos y su correspondencia con los objetivos marcados en la sección 1.2. Analizaremos los objetivos por separado:

6.1 Objetivo principal

El fin de este objetivo es aprovechar la tecnología aportada por Docker para facilitar el proceso de instalación, configuración y despliegue de Spark y Cassandra. Con lo anterior se podría levantar y utilizar un centro de cómputo distribuido de forma fácil y rápida. El objetivo consistía en utilizar una imagen de Docker (previamente creada por un tercero) que nos facilitaría dicha labor y aportaría las ventajas de la utilización de la tecnología basada contenedores. Por tanto, queda fuera y no es objeto de este proyecto el desarrollo de una imagen en sí para el uso descrito en el mismo. Este objetivo no ha podido ser cubierto debido a que no existen imágenes de Docker oficiales (sobre Spark y Cassandra) para arquitecturas ARM (sección 2.2). Existen muy pocas imágenes sobre esta temática para dicha arquitectura, no son oficiales y con escasa o ninguna documentación. No obstante, y como se ha documentado en la sección 5.2, se ha conseguido instalar y trabajar con Docker en modo Swarn y levantar el contenedor Portainer.io (un contenedor que hace de interfaz de usuario para Docker). En las imágenes de Docker que puedan utilizarse en Raspberry Pi, el nombre del repositorio suele tener la siguiente estructura: “rpi-nombre”. A modo de ejemplo se muestra en la figura 6.1 una de las pocas imágenes que se han encontrado e intentado levantar sin éxito.

52 6. Análisis de resultados 6.2. Objetivo secundario

Figura 6.1: Imagen de Cassandra en Docker Hub

6.2 Objetivo secundario

Este objetivo ha sido cumplido. Para demostrar el funcionamiento del mismo se ha creado una aplicación, que dado una cartera de valores de mercado (cotizaciones bursátiles), calcula la correlación que existe entre un valor de mercado y el resto. Los cálculos devuelven el resultado de los pares correlacionados y el tiempo de cómputo empleado en un archivo de texto plano.

Correlación indica la fuerza y la dirección de una relación lineal y pro- porcionalidad entre dos variables estadísticas. Se considera que dos variables cuantitativas están correlacionadas cuando los valores de una de ellas varían sistemáticamente con respecto a los valores homónimos de la otra: si tenemos dos variables (A y B) existe correlación entre ellas si al disminuir los valores de A lo hacen también los de B y viceversa. La correlación entre dos variables no implica, por sí misma, ninguna relación de causalidad.

La aplicación ha sido realizada con la API de Python para Spark PySpark, como se muestra en el código 13, la aplicación se conecta a la base de datos de Cassandra y crea un DataFrame de Spark con el cual se van realizando las operaciones de correlación entre pares de valores.

Computación Distribuida 53 6. Análisis de resultados 6.2. Objetivo secundario

from pyspark import SparkContext, SparkConf from pyspark.sql import SparkSession from time import clock ti = clock()

# configuramos conf = SparkConf() conf.setMaster("local[2]") conf.setAppName("Spark Cassandra") # No hac falta porque ya estoy conectando con el conector conf.set("spark.cassandra.connection.host","192.168.1.101") # creacion SparkContext sc = SparkContext(conf=conf) # creacion sqlContext spark = SparkSession(sc) # creacion DataFrame df = spark.read\ .format("org.apache.spark.sql.cassandra")\ .options(table="valores", keyspace="cotizaciones")\ .load()

cotizaciones = ['SPY','AAPL','NYSE:SAN','SPWR','DAX','REGI','BBVA','FEZ','NVDA', 'XOM','NASDAQ:TSLA']

# convertimos df to rdd rdd = df.rdd

rdd_ing = rdd.map(lambda row: (row[0],row[1],row[2]))\ .filter(lambda row: row[0]=='ING') ing = spark.createDataFrame(rdd_ing, ['cotizacion','fecha','c_ing'])

for cotizacion in cotizaciones: rdd_pivot = rdd.map(lambda row: (row[0],row[1],row[2]))\ .filter(lambda row: row[0]==cotizacion) name_column = 'c_'+cotizacion.lower() df_pivot = spark.createDataFrame(rdd_pivot,\ ['cotizacion','fecha',name_column]) df_pivot_join = ing.join(df_pivot, ing.fecha == df_pivot.fecha, 'inner') valor = df_pivot_join.corr('c_ing', name_column) resultado = "Correlacion ING y {}: {}\n".format(name_column, valor) #print "Correlacion ING y "+name_column+": ", valor file = open('/home/erl-1/resultado.txt', 'a') file.write(resultado) file.close() tf = clock()

Computación Distribuida 54 6. Análisis de resultados 6.2. Objetivo secundario

ejecucion = tf - ti #print "Tiempo de computo", tf - ti tiempo = "Tiempo de computo Spark local: {}\n".format(ejecucion) file = open('/home/erl-1/resultado.txt', 'a') file.write(tiempo) file.close()

Código 13: Aplicación cálculo correlaciones PySpark

6.2.1 Proceso de ejecución de la aplicación

En este apartado se describen los pasos a seguir para lanzar un archivo “.py” desde Spark: Nos posicionamos sobre la ruta: cd /usr/local/spark/sbin/ Arrancamos el cluster: ./start-all.sh Nos posicionamos sobre la ruta: cd /usr/local/spark/bin/ Lanzamos el script de Python con el siguiente comando: ./spark-submit –master spark://192.168.1.101:7077 /home/erl-1/pyspark_cassandra.py Paramos el cluster: ./stop-all.sh Las correlaciones obtenidas y tiempo de cómputo resultante se muestran en la figu- ra 6.2.

Figura 6.2: Resultados obtenidos de la aplicación

Computación Distribuida 55 6. Análisis de resultados 6.2. Objetivo secundario

6.2.2 Análisis de los resultados de la aplicación

A continuación, se comentan los puntos más destacados de la solución obtenida: Como se puede observar en la figura 6.2 se ha obtenido la correlación de la cotización de ING y el resto de valores, dándose la mayor correlación en el par: ING - SPDR EURO STOXX 50 ETF (FEZ) con un valor de: 0.934 Tiempo de cómputo elevado 6:50 minutos aproximados. Esto se debe a los siguientes factores: 1. Tamaño de la muestra de datos muy pequeño. Dicho tamaño se podría ha- ber trabajado perfectamente en memoria sin paralelizar, en la figura 5.10 se puede ver que el tamaño de la misma es del orden de 150 kilobytes aproximados (hay que tener en cuenta el factor de replicación). 2. El modo de levantar un cluster en Spark. Existen tres posibles configu- raciones: • Standalone: es la manera más simple de desplegar Spark sobre un cluster privado • Apache Mesos: es un gestor de cluster de propósito general • Hadoop YARN: es la siguiente genereación de Hadoop En este proyecto se ha decidido utilizar el modo Standalone. Los otros quedan fuera del objeto del mismo. Esta elección condiciona de forma muy acentuada los resultados debido a que el modo Standalone para la versión de Spark 2.2.0 (usada en este proyecto y la más reciente hasta la fecha) no permite ejecutar aplicaciones desarrolladas en Python en el cluster y estas solo son ejecutadas de forma local en la máquina donde sea lanzada y estas aplicaciones solo paralelizan a nivel de núcleos que contenga la cpu de la máquina. En el siguiente enlace Launching Applications with spark-submit se puede consultar la documentación de Spark donde hace referencia a lo mismo. En la siguiente figura 6.3 se aprecia tanto el consumo de la aplicación así como la parelización sobre los cuatros núcleos que componen una Raspberry Pi-3.

Computación Distribuida 56 6. Análisis de resultados 6.2. Objetivo secundario

(a) Consumo antes de lanzar la aplicación

(b) Consumo durante la ejecución de la aplicación

Figura 6.3: Consumo de la aplicación Python sobre una Raspberry Pi-3

3. Hay una parte del código que es iterativo y esto no es eficiente. Debido a que usamos un bucle “for”, hubiera sido más conveniente realizar al- gún tipo de transformación proporcionada por la API de Spark (como puede ser una “map”), pero he decidido realizarlo así a propósito ya que partimos de una muestra de datos muy pequeña y se pretendía ver có- mo variaban los tiempos de cómputo lanzando la aplicación desarrollada en Python con distintas configuraciones de núcleos y memoria sobre el cluster. Así, se podría haber realizado un estudio del rendimiento de la aplicación pero esto no se ha podido llevar a cabo por el argumento dado en el punto anterior.

Computación Distribuida 57 7 Conclusiones y futuros trabajos

7.1 Conclusiones

A lo largo de este proyecto ha quedado demostrado que se pueden utilizar mini- PC para formar un cluster y aplicar sobre ello tecnologías actuales como Spark y Cassandra para el tratamiento de grandes volúmenes de datos (Big data). El gran inconveniente que tiene es que una Raspberry Pi-3 tiene muy poca memoria RAM para los requerimientos que solicitan estas tecnologías y, por tanto, los tiempos de cómputo son muy elevados para cualquier aplicación por muy pequeña que sea esta. El único requerimiento que existe es realizar una parametrización previa de los recursos de memoria RAM que consumirán cada una de las tecnologías, de este modo se garantiza el funcionamiento de las mismas sin que colapse el sistema por desbordamiento de memoria. Hay que tener en cuenta que los proveedores de dichas tecnologías recomiendan como mínimo los siguiente requerimientos hardware: Spark: 8GB de memoria RAM por máquina, en el siguiente enlace aparecen todos requerimientos y recomendaciones de hardware: Hardware Provisioning Cassandra: 4GB memoria RAM en desarrollo y/o 8GB memoria RAM en producción, como mínimo, por máquina. En el siguiente enlace aparecen todos requerimientos y recomendaciones de hardware: Selecting hardware for Apache Cassandra implementations En este proyecto se ha conseguido que funcionen a la par Spark y Cassandra con solo 1GB de memoria RAM para ambos.

58 7. Conclusiones y futuros trabajos 7.2. Futuros trabajos

7.2 Futuros trabajos

A continuación, se describen una serie de puntos como futuros trabajos relacionados directamente con el hilo de este proyecto: Aprendizaje de la tecnología de Docker para el desarrollo de una imagen que instale Spark y Cassandra Aprender el lenguaje de programación Scala para crear script sobre Spark y poder aprovechar los recursos del cluster al completo y evitar lo sucedido con el PySpark. Así se consigue obtener un mayor rendimiento Crear un nuevo cluster sobre un mini-PC de altas prestaciones como puede ser: UDOO X86 Ultra. En la figura 7.1 se muestra sus componentes más destacados.

Figura 7.1: UDOO X86 Ultra

Computación Distribuida 59 Bibliografía

[1] C.Y. Kan, Cassandra Data Modeling and Analysis. 1ª ed. Published by Packt Publishing Ltd., December 2014 [2] JEFF NICKOLOFF, Docker in Action. Manning Publications Co, 2016 [3] Neependra Khare, Docker Cookbook. 1ª ed. Published by Packt Publishing Ltd., June 2015 [4] Rick Golden, Raspberry Pi Networking Cookbook. 2º ed. Published by Packt Publishing Ltd., June 2015 [5] Mario Macías, Mauro Gómez, Rubèn Tous y Jordi Torres, Intro- ducción a Apache Spark. 1ª ed. Barcelona: Editorial UOC, Noviembre 2015 [6] Holden Karau, Andy Konwinski, Patrick Wendell, and Matei Zaharia, Learning Spark. 1ª ed. O‘Reilly, February 2015 [7] Amit Nandi, Spark for Python Developers. 1ª ed. Published by Packt Publis- hing Ltd., December 2016

60 Anexos

61 Web visitadas

Los enlaces aparecen agrupados en los siguientes bloques: Mini PC: • ¿Qué son los mini PC? • Fabricantes destacados de mini PC (formato placa base) para montar cluster para uso doméstico: ◦ Raspberry Pi ◦ ODROID ◦ Udoo ◦ Parallella Sistemas operativos para Raspberry Pi 3: • Raspberry Pi : Sistemas Operativos • 9 sistemas operativos y gestores de contenido que puedes instalar en una Raspberry Pi • Descargas de Software para Raspberry Pi • Crear imagen iso para la instalación de Ubuntu Mate 16.04.2 LTS Docker: • Web oficial Docker • Introducción a Docker para principiantes • Docker Hub • Interfaz gráfica open-source Portainer • Aprende Docker de forma interactiva Cassandra: • Web oficial Apache Cassandra

62 • Cassandra, la dama de las bases de datos NoSQL Spark: • Web oficial Apache Spark • Spark: un destello en el universo Big Data

63 Presupuesto para realización del proyecto

CONCEPTO PRECIO Ud. (€) CANTIDAD TOTAL Raspberry Pi-3 39,95 3 119,85 Samsung MicroSDHC EVO+ 32GB Clase 10 11,95 3 35,85 Kit ventiladores + disipadores + Estructura soporte 19 1 19 Cargador USB - 6 Puertos 5V/6A USB Hub 27,95 1 27,95 0,25m cable de red plano, negro - 5 piezas, 10 Gbit/s 11,24 1 11,24 Cable Micro USB Largos Surtidos (30cm) USB 2.0 Macho a Micro 7,99 1 7,99 Cable Plano HDMI Bajo Perfil Cable Oro 1,5m 3,22 1 3,22 Switch - D-link GO-SW-5G, 5 puertos, Gigabit 19,95 1 19,95 Total 245,05

Tabla 1: Presupuesto para la realización del proyecto

64 Tabla comparativa de mini PC

65 Name SoC Architecture Cores Frequency GPU Size Data rate [MT/s] Data path width [bits] Type DDR3, Freescale Vybrid ARM Cortex-A5 2 (1 + 500 MHz 512 armStoneA5 16 4x 12Bit VF6xx ARM Cortex-M4 1) 167 MHz MB ADC Samsung PowerVR 512 armStoneA8 ARM Cortex-A8 1 800 MHz S5PV210 SGX540 MB Vivante DDR3, Freescale i.MX6 GC2000 + armStoneA9 ARM Cortex-A9 4 1.2 GHz 4 GB 64 4x 12Bit Quad GC335 + ADC GC320 Samsung Mali- ARM Cortex-A15 2 1.7 GHz 2 GB DDR3L 5 T604MP4 Mali- Allwinner A20 ARM Cortex-A7 2 1 GHz 1 GB 32 DDR3 400MP2 Mali- Banana Pro Allwinner A20 ARM Cortex-A7 2 1 GHz 1 GB 32 DDR3 400MP2 PowerVR Banana Pi M2 Allwinner A31s ARM-Cortex-A7 4 1 GHz 1 GB 32 DDR3 SGX544MP PowerVR Banana Pi M3 Allwinner A83T ARM-Cortex-A7 8 1.8 GHz 2 GB 32 LPDDR3 SGX544MP TMS320C64x 256 BeagleBoard TI OMAP3530 ARM Cortex-A8 1 720 MHz @430 MHz, LPDDR MB DSP 512 BeagleBoard-xM TI Sitara AM37x ARM Cortex-A8 1 1 GHz C64x, DSP LPDDR MB PowerVR 256 BeagleBone TI Sitara AM335x ARM Cortex-A8 1 720 MHz 16 DDR2 SGX530 MB PowerVR 512 BeagleBone Black TI Sitara AM335x ARM Cortex-A8 1 1 GHz 16 DDR3L SGX530 MB Samsung PowerVR Boardcon EM210 ARM Cortex-A8 1 800 MHz 512MB DDR2 S5PV210 SGX540 512 C.H.I.P. Allwinner R8 ARM Cortex-A8 1 1 GHz Mali 400 DDR3 MB Sigue en la página siguiente. Name SoC Architecture Cores Frequency GPU Size Data rate [MT/s] Data path width [bits] Type Freescale Vybrid ARM Cortex-A5 2 (1 + 500 MHz 256 Cosmic+ Board DDR3 VF6xx ARM Cortex-M4 1) 167 MHz MB Allwinner A10 ARM Cortex-A8 1 1 GHz Mali-400 1 GB 960 DDR3 Mali- Cubieboard 2 Allwinner A20 ARM Cortex-A7 2 1 GHz 1 GB 960 DDR3 400MP2 Mali- Cubieboard 3 Allwinner A20 ARM Cortex-A7 2 1 GHz 2 GB 960 DDR3 400MP2 ARM Cortex- Cubieboard 4 / CC- PowerVR Allwinner A80 A15x4/ARM 8 1.3 GHz 2 GB 1600 64 DDR3 A80 64-core 6230 Cortex-A7x4 Vivante Freescale i.MX6 CuBox-i2 ARM Cortex-A9 2 1 GHz GC880 + 1 GB 800 32 DDR3 Dual Lite GC320 Vivante Freescale i.MX6 GC2000 + CuBox-i2eX ARM Cortex-A9 2 1 GHz 1 GB 1066 64 DDR3 Dual GC335 + GC320 Vivante Freescale i.MX6 GC2000 + CuBox-i4Pro ARM Cortex-A9 4 1 GHz 2 GB 1066 64 DDR3 Quad GC335 + GC320 Qualcomm Snap- Qualcomm Dragonboard 410c ARM Cortex-A53 4 1.2 GHz 1 GB 1066 LPDDR3 dragon 410 Adreno 306 Marvell Kirkwood 512 DreamPlug ARM9E 1 1.2 GHz N/A DDR2 88F6281 MB PowerVR 512 Embest SBC8600B TI Sitara AM3359 ARM Cortex-A8 1 720 MHz 16 DDR3 SGX530 MB ARM Mali- Firefly-RK3288 RK3288 ARM Cortex-A12 4 1.8 GHz 2 GB 32 DDR3 T760 MP4 Firefly-RK3288 ARM Mali- Rockchip RK3288 ARM Cortex-A12 4 1.8 GHz 4 GB 32 DDR3 Plus T760 MP4 GameStick 8726-MX ARM Cortex-A9 2 1 GHz Mali-400 1 GB DDR3 Sigue en la página siguiente. Name SoC Architecture Cores Frequency GPU Size Data rate [MT/s] Data path width [bits] Type AMD Embedded Radeon HD Gizmo Board G-Series T40E x86-64 Bobcat 2 1 GHz 1 GB 64 DDR3 6250 APU ALi M3733- Mali- GoWarrior ARM Cortex-A9 2 1 GHz 1 GB 1600 64 DDR3 AFAAA 400MP2 Overo 512 EarthSTORM + TI Sitara AM3703 ARM Cortex-A8 1 1 GHz LPDDR MB Summit Hackberry A10 Allwinner A10 ARM Cortex-A8 1 1 GHz Mali-400 1 GB DDR3 HiSilicon Kirin Mali-450 HiKey ARM Cortex-A53 8 1.2 GHz 1 GB 1600 64 LPDDR3 620 MP4 Vivante Freescale i.MX6 512 HummingBoard-i1 ARM Cortex-A9 1 1 GHz GC880 + 800 32 DDR3 Solo MB GC320 Vivante Freescale i.MX6 HummingBoard-i2 ARM Cortex-A9 2 1 GHz GC880 + 1 GB 800 64 DDR3 Dual Lite GC320 Vivante HummingBoard- Freescale i.MX6 GC2000 + ARM Cortex-A9 2 1 GHz 1 GB 1066 64 DDR3 i2eX Dual GC355 + GC320 Qualcomm Snap- Krait (ARM- Adreno 320 Inforce 6410 dragon 600 4 1.7 GHz 2 GB 1066 DDR3 based) @400 MHz (APQ8064M) Qualcomm Snap- Krait 450 (ARM- Adreno 420 Inforce 6540 dragon 805 4 2.5 GHz 2 GB LP-DDR3 based) @600 MHz (APQ8084) Qualcomm Snap- Krait (ARM- Adreno 320 Inforce 6410plus dragon 600 4 1.7 GHz 2 GB 1066 DDR3 based) @400 MHz (APQ8064M) SoC 256 Gen 2 x86 Quark 1 400 MHz N/A 800 DDR3 X1000 MB Sigue en la página siguiente. Name SoC Architecture Cores Frequency GPU Size Data rate [MT/s] Data path width [bits] Type Vivante Freescale i.MX6 GC2000 + Inventami Entry ARM Cortex-A9 2 1 GHz 1 GB 1066 64 DDR3 Dual GC335 + GC320 Vivante Freescale i.MX6 GC2000 + Inventami Full ARM Cortex-A9 4 1 GHz 1 GB 1066 64 DDR3 Quad GC335 + GC320 MarsBoard A10 Mali- Allwinner A10 ARM Cortex-A8 1 1 GB 960 DDR3 New 400MP2 MarsBoard A20 Mali- 1-2 Allwinner A20 ARM Cortex-A7 2 1 GHz 960 DDR3 New 400MP2 GB MarsBoard Mali- 1-2 Rockchip RK3066 ARM Cortex-A9 2 1.6 GHz DDR3 RK3066 400MP4 GB Intel MinnowBoard Intel E640 x86 Bonnell 1 1 GHz 1 GB 64 DDR2 GMA600 Ingenic XBurst PowerVR MIPS Creator CI20 Ingenic JZ4780 2 1.2 GHz 1 GB 32 DDR3 (mips32 rev.2) SGX540 Marvell Armada MiraBox ARMv7 1 1.2 GHz N/A 1 GB 1333 16 DDR3L 370 MK802 II Allwinner A10 ARM Cortex-A8 1 1 GHz Mali-400 1 GB 960 DDR3 Mali- MK808 Rockchip RK3066 ARM Cortex-A9 2 1.6 GHz 400MP4 1 GB DDR3 @250 MHz WonderMedia 512 MTB025 ARM Cortex-A8 1 1.2 GHz Mali-400 WM8850 MB PowerVR MYIR MYD- 800-1000 512 TI Sitara AM335x ARM Cortex-A8 1 SGX530 16 DDR3 AM335X MHz MB (optional) Samsung Exynos Mali- NanoPC-T1 ARM Cortex-A9 4 1 GB 960 DDR3 4 (4412) 400MP4 NanoPi 2 Samsung S5P4418 ARM Cortex-A9 4 1.4 GHz 1 GB 32 DDR3 Sigue en la página siguiente. Name SoC Architecture Cores Frequency GPU Size Data rate [MT/s] Data path width [bits] Type 256 or ARM Mali- NanoPi NEO Allwinner H3 ARM Cortex-A7 4 1.2 GHz 512 864 16 DDR3 400 MP2 MB Vivante 1 GB Freescale i.MX6 GC2000 + (2 GB Nitrogen6x ARM Cortex-A9 4 1 GHz 1066 64 DDR3 Quad GC355 + op- GC320 tion) GK20A (192 ARM Cortex-A15 5 (4 + TK1 Nvidia K1 2.3 GHz CUDA co- 2 GB 933 64 DDR3L "low-power core" 1) res) @950 MHz Nvidia GM20B (256 ARM Cortex-A57 8 (4 + 1.9 GHz Nvidia Jetson TX1 Nvidia Tegra X1 CUDA co- 4 GB 64 LPDDR4 ARM Cortex-A53 4) 1.3 GHz res) @1000 MHz Mali-450MP ODROID-C1/C1+ Amlogic S805 ARM Cortex-A5 4 1.5 GHz 1 GB 32 DDR3 @600 MHz Mali- 450MP3 ODROID-C2 Amlogic S905 ARM Cortex-A53 4 1.5 GHz 2 GB 64 DDR3 +2VS @700 MHz Mali- Samsung Exynos ODROID-U3 ARM Cortex-A9 4 1.7 GHz 400MP4 2 GB 880 LPDDR2 4 Quad @440 MHz Broadcom Broadcom 512 ODROID-W ARM11 1 700 MHz VideoCore 32 LPDDR2 BCM2835 MB IV PowerVR Samsung Exynos ARM Cortex-A15 8 (4 + 1.7 GHz ODROID-XU SGX544MP3 2 GB 800 32 LPDDR3 5 Octa (5410) ARM Cortex-A7 4) 1.2 GHz @600 MHz Sigue en la página siguiente. Name SoC Architecture Cores Frequency GPU Size Data rate [MT/s] Data path width [bits] Type ARM Mali- Samsung Exynos ARM Cortex-A15 8 (4 + 2 GHz 1.4 ODROID-XU3 T628 @695 2 GB 933 32 DDR3L 5 Octa (5422) ARM Cortex-A7 4) GHz MHz ARM Mali- Samsung Exynos ARM Cortex-A15 8 (4 + 2 GHz 1.4 ODROID-XU4 T628 @695 2 GB 933 32 DDR3L 5 Octa (5422) ARM Cortex-A7 4) GHz MHz ARM Mali- Samsung Exynos ARM Cortex-A15 8 (4 + 1.8 GHz ODROID-XU3 Lite T628 @695 2 GB 933 32 DDR3L 5 Octa (5422) ARM Cortex-A7 4) 1.3 GHz MHz OLinuXino A10 LI- 512 Allwinner A10 ARM Cortex-A8 1 1 GHz Mali-400 DDR3 ME MB 512 OLinuXino A13 Allwinner A13 ARM Cortex-A8 1 1 GHz Mali-400 32 DDR3 MB OLinuXino A13 256 Allwinner A13 ARM Cortex-A8 1 1 GHz Mali-400 16 DDR3 MICRO MB OLinuXino A13 512 Allwinner A13 ARM Cortex-A8 1 1 GHz Mali-400 16 DDR3 WIFI MB OLinuXino A20 LI- Mali- 512 Allwinner A20 ARM Cortex-A7 2 1 GHz DDR3 ME 400MP2 MB OLinuXino A20 LI- Mali- Allwinner A20 ARM Cortex-A7 2 1 GHz 1 GiB 32 DDR3 ME2 400MP2 OLinuXino A20 Mali- Allwinner A20 ARM Cortex-A7 2 1 GHz 1 GB DDR3 MICRO 400MP2 ARM Mali- Orange Pi Allwinner A20 ARM Cortex-A7 2 1 GB 32 DDR3 400 MP2 ARM Mali- Orange Pi Mini Allwinner A20 ARM Cortex-A7 2 1 GB 32 DDR3 400 MP2 ARM Mali- Orange Pi 2 Allwinner H3 ARM Cortex-A7 4 1.536GHz 400 MP2 1 GB 32 DDR3 @600 MHz ARM Mali- Orange Pi Mini 2 Allwinner H3 ARM Cortex-A7 4 1.536GHz 400 MP2 1 GB 32 DDR3 @600 MHz Sigue en la página siguiente. Name SoC Architecture Cores Frequency GPU Size Data rate [MT/s] Data path width [bits] Type ARM Mali- Orange Pi PC Allwinner H3 ARM Cortex-A7 4 1.536GHz 400 MP2 1 GB 32 DDR3 @600 MHz ARM Mali- Orange Pi Plus Allwinner H3 ARM Cortex-A7 4 1.536GHz 400 MP2 1 GB 32 DDR3 @600 MHz ARM Mali- Orange Pi Plus 2 Allwinner H3 ARM Cortex-A7 4 1.536GHz 400 MP2 2 GB 32 DDR3 @600 MHz ARM Mali- 512 Orange Pi One Allwinner H3 ARM Cortex-A7 4 1.2GHz 400 MP2 32 DDR3 MB @600 MHz ARM Mali- 512 Orange Pi Lite Allwinner H3 ARM Cortex-A7 4 1.2GHz 400 MP2 32 DDR3 MB @600 MHz ARM Mali- Orange Pi PC Plus Allwinner H3 ARM Cortex-A7 4 1.536GHz 400 MP2 1 GB 32 DDR3 @600 MHz ARM Mali- Orange Pi Plus 2E Allwinner H3 ARM Cortex-A7 4 1.536GHz 400 MP2 2 GB 32 DDR3 @600 MHz Nvidia Tegra 3 Nvidia ULP ARM Cortex-A9 4 1.7 GHz 1 GB 1600 DDR3 T33-P-A3 GeForce Zilog P112 Zilog Z180 1 16 MHz N/A MB 8 SRAM Z8018216FSC PowerVR PandaBoard ES TI OMAP4460 ARM Cortex-A9 2 1.2 GHz 1 GB LPDDR2 SGX540 512 pcDuino Lite Allwinner A10 ARM Cortex-A8 1 1 GHz Mali-400 MB pcDuino v2 Allwinner A10 ARM Cortex-A8 1 1 GHz Mali-400 1 GB Mali- pcDuino3 Allwinner A20 ARM Cortex-A7 2 1 GHz 1 GB 400MP2 Sigue en la página siguiente. Name SoC Architecture Cores Frequency GPU Size Data rate [MT/s] Data path width [bits] Type Mali- pcDuino3Nano Allwinner A20 ARM Cortex-A7 2 1 GHz 1 GB 400MP2 AMD Embedded N/A (di- PC Engines G-Series T40E x86-64 Bobcat 2 1 GHz sabled in 2 GB 1066 64 DDR3 APU.1D APU BIOS) AMD Embedded N/A (di- PC Engines G-Series T40E x86-64 Bobcat 2 1 GHz sabled in 4 GB 1066 64 DDR3 APU.1D4 APU BIOS) AMD Embed- PC Engines ded G-Series x86-64 Jaguar 4 1 GHz N/A 2 GB 1333 64 DDR3 APU.2C2 GX-412TC APU AMD Embed- PC Engines DDR3 ded G-Series x86-64 Jaguar 4 1 GHz N/A 4 GB 1333 64 APU.2C4 ECC GX-412TC APU PowerVR 512 phyBOARD-Wega TI Sitara AM335x ARM Cortex-A8 1 800 MHz DDR3 SGX530 MB phyBOARD-Mira Freescale i.MX6 ARM Cortex-A9 4 1 GHz N/A 1 GB DDR3 Mali- PINE A64 Allwinner A64 ARM Cortex-A53 4 1.2 GHz 512MB 64 DDR3 400MP2 Mali- Radxa Rock Rockchip RK3188 ARM Cortex-A9 4 1.6 GHz 2 GB DDR3 400MP4 Mali- Radxa Rock Lite Rockchip RK3188 ARM Cortex-A9 4 1.6 GHz 1 GB DDR3 400MP4 Broadcom Raspberry Pi Mo- Broadcom 256 ARM11 1 700 MHz VideoCore del A / B rev 1 BCM2835 MB IV Broadcom Raspberry Pi Mo- Broadcom 512 ARM11 1 700 MHz VideoCore del B rev 2 / B+ BCM2835 MB IV Broadcom Raspberry Pi 2 Mo- Broadcom ARM Cortex-A7 4 900 MHz VideoCore 1 GB LPDDR2 del B BCM2836 IV Sigue en la página siguiente. Name SoC Architecture Cores Frequency GPU Size Data rate [MT/s] Data path width [bits] Type Broadcom Raspberry Pi 3 Mo- Broadcom ARM Cortex-A53 4 1.2 GHz VideoCore 1 GB LPDDR2 del B BCM2837 IV Broadcom Broadcom 512 Raspberry Pi Zero ARM11 1 1 GHz VideoCore LPDDR2 BCM2835 MB IV MYIR Rico Board TI AM437x ARM Cortex-A9 1 1 GHz 512MB DDR3 AMD 512 Rikomagic MK802 Allwinner A10 ARM Cortex-A8 1 1 GHz DDR3 Z430/Z160 MB Rikomagic AMD MK802+ / MK802 Allwinner A10 ARM Cortex-A8 1 1 GHz 1 GB DDR3 Z430/Z160 II Vivante Freescale i.MX6 RIoTboard ARM Cortex-A9 1 1 GHz GC880 + 1 GB DDR3 Solo GC320 RouterBOARD Qualcomm Athe- 256 MIPS 24K 1 680 MHz N/A DDR RB450G ros AR7161 MB RouterBOARD Qualcomm Athe- 128 MIPS 74Kc 1 720 MHz N/A DDR2 RB953GS-5HnT ros QCA9558 MB Snowball SKY- ST-Ericsson Nova ARM Cortex-A9 2 1 GHz Mali-400 1 GB LPDDR2 S9500 A9500 Supermicro E100- Intel® Quark™ 512 800/1600 DDR3 x86 Quark 1 400 MHz N/A 8Q SoC X1021 MB MHz ECC Vivante Freescale i.MX6 GC2000 + TBS 2910 Matrix ARM Cortex-A9 4 1 GHz 2 GB DDR3 Quad GC335 + GC320 ARM Cortex- Tronsmart Draco PowerVR Allwinner A80 A15x4/ARM 8 1.3 GHz 2 GB 1600 64 DDR3 Meta 64-core 6230 Cortex-A7x4 ARM Cortex- Tronsmart Draco PowerVR Allwinner A80 A15x4/ARM 8 1.3 GHz 4 GB 1600 64 DDR3 Telos 64-core 6230 Cortex-A7x4 Sigue en la página siguiente. Name SoC Architecture Cores Frequency GPU Size Data rate [MT/s] Data path width [bits] Type Marvell Armada PJ1/Mohawk(ARM- TS-7250-V2 1 1GHz N/A 512MB 16 DDR3 PXA168 based) 128MB TS-7680 Freescale i.MX286 ARM9E 1 454MHz N/A or 16 DDR2 256MB Vivante 1 GB Freescale i.MX6 GC2000 + (2 GB TS-7970 ARM Cortex-A9 4 1GHz 1066 64 DDR3 Quad GC355 + op- GC320 tion) Freescale i.MX6 Vivante ARM Cortex-A9 3 (2 + 1 GHz 84 UDOO Dual Basic Dual Lite Atmel GC880 + 1 GB 800 32 DDR3 ARM Cortex-M3 1) MHz SAM3X8E GC320 Freescale i.MX6 Vivante ARM Cortex-A9 3 (2 + 1 GHz 84 UDOO Dual Dual Lite Atmel GC880 + 1 GB 800 32 DDR3 ARM Cortex-M3 1) MHz SAM3X8E GC320 Vivante Freescale i.MX6 ARM Cortex-A9 5 (4 + 1 GHz 84 GC2000 + UDOO Quad Quad Atmel 1 GB 1066 64 DDR3 ARM Cortex-M3 1) MHz GC355 + SAM3X8E GC320 Intel® HD 400 Grap- DDR3L UDOO X86 Advan- hics, 12 DUAL Intel N3160 x86 4 2.24 GHz 4 GB ced execution CHAN- units up to NEL 640 MHz Intel® HD Graphics 12 UDOO X86 Basic Intel x5-E8000 x86 4 2 GHz execution 2 GB DDR3L uints up to 320 MHz Sigue en la página siguiente. Name SoC Architecture Cores Frequency GPU Size Data rate [MT/s] Data path width [bits] Type Intel® HD 405 Grap- DDR3L hics, 16 DUAL UDOO X86 Ultra Intel N3710 x86 4 2.56 GHz 8 GB execution CHAN- units up to NEL 700 MHz Intel® HD 400 Grap- 1/2/4 UP Intel x5-Z8350 x86-64 4 1.44 GHz hics, 12 EU 1600 64 DDR3L GB GEN 8, up to 500 MHz Vivante Freescale i.MX6 GC2000 + Pro ARM Cortex-A9 4 1.2 GHz 2 GB 1066 DDR3 Quad GC355 + GC320 Vivante Freescale i.MX6 GC2000 + Utilite Standard ARM Cortex-A9 2 1 GHz 2 GB 1066 DDR3 Dual GC355 + GC320 Vivante Freescale i.MX6 512 Utilite Value ARM Cortex-A9 1 1 GHz GC880 + 1066 DDR3 Solo MB GC320 VIA APC 8750 / WonderMedia 512 ARM1176JZF 1 800 MHz Mali-200 DDR3 Rock WM8750 MB VIA Springboard WonderMedia ARM Cortex-A9 1 800 MHz Mali-400 1 GB 1066 32 DDR3 VAB-600 WM8950 Vivante Freescale i.MX6 Wandboard Dual ARM Cortex-A9 2 1 GHz GC880 + 1 GB DDR3 Dual GC320 Vivante Freescale i.MX6 GC2000 + Wandboard Quad ARM Cortex-A9 4 1 GHz 2 GB DDR3 Quad GC355 + GC320 Sigue en la página siguiente. Name SoC Architecture Cores Frequency GPU Size Data rate [MT/s] Data path width [bits] Type Vivante Freescale i.MX6 512 Wandboard Solo ARM Cortex-A9 1 1 GHz GC880 + DDR3 Solo MB GC320 Xilinx XC7Z010- MYIR Z-turn 1CLG400C ARM Cortex-A9 2 667 MHz 1GB DDR3 Board or XC7Z020- + FPGA 1CLG400C Graperain G4418 Samsung S5P4418 ARM Cortex-A9 4 1.4 GHz Mali-400 1 GB 32 DDR3 SBC Graperain G6818 Samsung S5P6818 ARM Cortex-A53 8 1.4+ GHz Mali-400 2 GB 32 DDR3 SBC Tabla 2: Comparativa de mini PC