Cluster Raspberry PI-3 con Cassandra y Spark en Docker

Máster en Ingeniería Computacional y Matemática
Trabajo Final de Máster
Creación de un cluster formado por tres
Raspberry PI-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: Joan Manuel Marquès
Nombre Profesor/a responsable de la asignatura: Félix Freitag
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_python y @DataBeersMLG

Ficha del Trabajo Fin de Máster
Título del trabajo
Creación de un cluster formado por tres
RaspberryPI-3 que alojarán una base de datos
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 Joan Manuel Marquès
Nombre del PRA Félix Freitag
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-
mo 3 palabras)
Docker, Spark y Cassandra
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ón 1
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 utilizado 5
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 Ubuntu 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 ﬁguras
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áﬁca 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 ﬁguras Índice de ﬁguras
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 X86 Ultra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Computación Distribuida viii

Índice de tablas
1.1 Planiﬁcació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

1Introducció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 ﬁgura 1.1
Figura 1.1: Cluster raspberry pi-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 conﬁguración). Está compuesta
de cuatro secciones: conﬁguració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.

2Hardware y sistema operativo utilizado
2.1 Mini PC
Un mini PC no tiene una deﬁnició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 Linux 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 ﬁn 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 ,udoo o 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
Modelo B
1.2GHz 64-bit quad-
core ARMv8 CPU
1GB RAM 39,90
ODROID-XU4
Samsung Exynos5422
Cortex™-A15 2Ghz
and Cortex™-A7
Octa core CPUs
2Gbyte LPDDR3
RAM PoP stacked
55,57
UDOO X86 UL-
TRA
CPU INTEL PEN-
TIUM N3710 2.56
GHZ
8 GB DDR3L DUAL
CHANNEL
244,00
Parallella
16-core Epiphany
RISC SOC. Zynq
SOC (FPGA + ARM
A9)
1GB SDRAM 93,25
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:

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, Chipset 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
Bluetooth 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

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-
tivos:
Oficiales:
• RASPBIAN (Debian Jessie)
• PIDORA Fedora Remix
• Ubuntu MATE
No oficiales (existe un mayor número):

• ARCH LINUX
• 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.

Figura 2.2: Sistema Operativo Raspbian
Figura 2.3: Sistema Operativo Ubuntu Mate

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.

3Introducció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 ﬂexibilidad 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íﬁcos de cada contenedor, puedes crear varios contenedores
de una sola imagen y deﬁnir el volumen para cada uno. Los volúmenes se almacenan
en el sistema de archivos del servidor que ejecuta el 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.

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.

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 Google 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-

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 ﬁla 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 deﬁnamos; 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.

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.

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 signiﬁcativamente 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 ﬁgura 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

Figura 3.7: Ecosistema Spark
Figura 3.8: Flujograma de RDD en 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.

4Estado 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 diﬁcultad 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 Oﬃcial 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.

5Puesta en marcha del sistema
5.1 Conﬁguració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-
tivo 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)).

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:

(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))

5. Comienza el proceso de instalación el cual llevará unos minutos (ﬁgura 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 conﬁguració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 erl-X@192.168.1.10X
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

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ódigo 1 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

# 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.1 8.8.8.8 8.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

Ponemos en funcionamiento la partición swap:
sudo swapon /dev/nombre_de_la_particion_swap.
En la ﬁgura 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

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ódigo 2 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 version 1.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 ﬁgura 5.7 aparecen dichos pasos mediante cap-
turas de pantallas

(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 ﬁgura 5.8 aparecen dichos pasos mediante capturas de pantallas o podemos
utilizar el siguiente comando sudo usermod -aG docker nombre_usuario

(a) Accedemos al ajuste de los usuarios (b) Seleccionamos el grupo Docker
(c) Marcamos el check del usuario (d) Conﬁrmamos 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.

Al ejecutar el comando hemos inicializado este nodo como Manager. El resulado de
la ejecución del comando anterior se muestra en el código 3.
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 conﬁguració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ódigo 4. 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

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/

(a) Dashboard Portainer
(b) Imagen de Portainer descargada
(c) Contenedor de Portainer corriendo
(d) Cluster Swarm en Portainer
Figura 5.9: Interfaz gráﬁca Portainer

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 conﬁguració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

5.3.3 Conﬁguració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 Conﬁguració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ódigo 5.
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:
• rpc_address: 192.168.1.102
rpi3-3:
• 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

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 ﬁgura 5.10 se muestra el estado del mismo
mediante el comando nodetool status.
Figura 5.10: Estado cluster de Cassandra

GNU nano 2.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

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ódigo 6 (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.

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ódigo 7.
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ódigo 8.

#!/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

## 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ódigo 9 se ha
deﬁnido 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 ﬁgura 5.13.

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

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 ﬁgura 5.15
sudo /usr/local/spark/bin/./spark-shell

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 erl-2@192.168.1.102
ssh-copy-id -i /.ssh/id_rsa.pub erl-3@192.168.1.103
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
erl-2@192.168.1.102
erl-3@192.168.1.103
Código 10: Conﬁguració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 conﬁguración
sobre cada una de las raspberry pi 3, como muestra el código 11

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: Conﬁguració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 ﬁgura 5.16

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ódigo 7
val rdd = sc.cassandraTable(”cotizaciones", "valores")

c) En el siguiente código 12 se muestra el resultado obtenido y se aprecia
como coincide con la primera ﬁla de la ﬁgura 5.13.
Welcome to
____ __
/ __/__ ___ _____/ /__
_ / _ / _ `/ __/ '_/
/___/ .__/_,_/_/ /_/_ version 2.0.2
/_/
Using Scala version 2.11.8 (Java HotSpot(TM) Client VM, Java 1.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

6Aná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.

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()

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 ﬁgu-
ra 6.2.
Figura 6.2: Resultados obtenidos de la aplicación

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.

(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 eﬁciente. 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 conﬁguraciones 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.

7Conclusiones 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 ﬁgura 7.1 se muestra sus componentes más destacados.
Figura 7.1: UDOO X86 Ultra

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

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 oﬁcial 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 Perﬁl 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
armStoneA5
Freescale Vybrid
VF6xx
ARM Cortex-A5
ARM Cortex-M4
2 (1 +
1)
500 MHz
167 MHz
512
MB
16
DDR3,
4x 12Bit
ADC
armStoneA8
Samsung
S5PV210
ARM Cortex-A8 1 800 MHz
PowerVR
SGX540
512
MB
armStoneA9
Freescale i.MX6
Quad
ARM Cortex-A9 4 1.2 GHz
Vivante
GC2000 +
GC335 +
GC320
4 GB 64
DDR3,
4x 12Bit
ADC
Arndale Board
Samsung Exynos
5
Mali-
T604MP4
2 GB DDR3L
Banana Pi Allwinner A20 ARM Cortex-A7 2 1 GHz
Mali-
400MP2
1 GB 32 DDR3
Banana Pro Allwinner A20 ARM Cortex-A7 2 1 GHz
Mali-
400MP2
1 GB 32 DDR3
Banana Pi M2 Allwinner A31s ARM-Cortex-A7 4 1 GHz
PowerVR
SGX544MP
1 GB 32 DDR3
Banana Pi M3 Allwinner A83T ARM-Cortex-A7 8 1.8 GHz
PowerVR
SGX544MP
2 GB 32 LPDDR3
BeagleBoard TI OMAP3530 ARM Cortex-A8 1 720 MHz
TMS320C64x
@430 MHz,
DSP
256
MB
LPDDR
BeagleBoard-xM TI Sitara AM37x ARM Cortex-A8 1 1 GHz C64x, DSP
512
MB
LPDDR
BeagleBone TI Sitara AM335x ARM Cortex-A8 1 720 MHz
PowerVR
SGX530
256
MB
16 DDR2
BeagleBone Black TI Sitara AM335x ARM Cortex-A8 1 1 GHz
PowerVR
SGX530
512
MB
16 DDR3L
Boardcon EM210
Samsung
S5PV210
PowerVR
SGX540
512MB DDR2
C.H.I.P. Allwinner R8 ARM Cortex-A8 1 1 GHz Mali 400
512
MB
DDR3
Sigue en la página siguiente.

Cosmic+ Board
Freescale Vybrid
VF6xx
ARM Cortex-A5
ARM Cortex-M4
2 (1 +
1)
500 MHz
167 MHz
256
MB
DDR3
Cubieboard Allwinner A10 ARM Cortex-A8 1 1 GHz Mali-400 1 GB 960 DDR3
Cubieboard 2 Allwinner A20 ARM Cortex-A7 2 1 GHz
Mali-
400MP2
1 GB 960 DDR3
Cubieboard 3 Allwinner A20 ARM Cortex-A7 2 1 GHz
Mali-
400MP2
2 GB 960 DDR3
Cubieboard 4 / CC-
A80
Allwinner A80
ARM Cortex-
A15x4/ARM
Cortex-A7x4
8 1.3 GHz
PowerVR
64-core 6230
2 GB 1600 64 DDR3
CuBox-i2
Freescale i.MX6
Dual Lite
ARM Cortex-A9 2 1 GHz
Vivante
GC880 +
GC320
1 GB 800 32 DDR3
CuBox-i2eX
Freescale i.MX6
Dual
Vivante
GC2000 +
GC335 +
GC320
1 GB 1066 64 DDR3
CuBox-i4Pro
Freescale i.MX6
Quad
Vivante
GC2000 +
GC335 +
GC320
2 GB 1066 64 DDR3
Dragonboard 410c
Qualcomm Snap-
dragon 410
Qualcomm
Adreno 306
1 GB 1066 LPDDR3
DreamPlug
Marvell Kirkwood
88F6281
ARM9E 1 1.2 GHz N/A
512
MB
DDR2
Embest SBC8600B TI Sitara AM3359 ARM Cortex-A8 1 720 MHz
PowerVR
SGX530
512
MB
16 DDR3
Fireﬂy-RK3288 Rockchip RK3288 ARM Cortex-A12 4 1.8 GHz
ARM Mali-
T760 MP4
2 GB 32 DDR3
Fireﬂy-RK3288
Plus
Rockchip RK3288 ARM Cortex-A12 4 1.8 GHz
ARM Mali-
T760 MP4
4 GB 32 DDR3
GameStick Amlogic 8726-MX ARM Cortex-A9 2 1 GHz Mali-400 1 GB DDR3

Gizmo Board
AMD Embedded
G-Series T40E
APU
x86-64 Bobcat 2 1 GHz
Radeon HD
6250
1 GB 64 DDR3
GoWarrior
ALi M3733-
AFAAA
Mali-
400MP2
1 GB 1600 64 DDR3
Gumstix Overo
EarthSTORM +
Summit
TI Sitara AM3703 ARM Cortex-A8 1 1 GHz
512
MB
LPDDR
Hackberry A10 Allwinner A10 ARM Cortex-A8 1 1 GHz Mali-400 1 GB DDR3
HiKey
HiSilicon Kirin
620
Mali-450
MP4
1 GB 1600 64 LPDDR3
HummingBoard-i1
Freescale i.MX6
Solo
Vivante
GC880 +
GC320
512
MB
800 32 DDR3
HummingBoard-i2
Freescale i.MX6
Dual Lite
Vivante
GC880 +
GC320
1 GB 800 64 DDR3
HummingBoard-
i2eX
Freescale i.MX6
Dual
Vivante
GC2000 +
GC355 +
GC320
1 GB 1066 64 DDR3
Inforce 6410
Qualcomm Snap-
dragon 600
(APQ8064M)
Krait (ARM-
based)
4 1.7 GHz
Adreno 320
@400 MHz
2 GB 1066 DDR3
Inforce 6540
Qualcomm Snap-
dragon 805
(APQ8084)
Krait 450 (ARM-
based)
4 2.5 GHz
Adreno 420
@600 MHz
2 GB LP-DDR3
Inforce 6410plus
Qualcomm Snap-
dragon 600
(APQ8064M)
Krait (ARM-
based)
4 1.7 GHz
Adreno 320
@400 MHz
2 GB 1066 DDR3
Intel Galileo Gen 2
Intel Quark SoC
X1000
x86 Quark 1 400 MHz N/A
256
MB
800 DDR3

Inventami Entry
Freescale i.MX6
Dual
Vivante
GC2000 +
GC335 +
GC320
1 GB 1066 64 DDR3
Inventami Full
Freescale i.MX6
Quad
Vivante
GC2000 +
GC335 +
GC320
1 GB 1066 64 DDR3
MarsBoard A10
New
Allwinner A10 ARM Cortex-A8 1
Mali-
400MP2
1 GB 960 DDR3
MarsBoard A20
New
Allwinner A20 ARM Cortex-A7 2 1 GHz
Mali-
400MP2
1-2
GB
960 DDR3
MarsBoard
RK3066
Rockchip RK3066 ARM Cortex-A9 2 1.6 GHz
Mali-
400MP4
1-2
GB
DDR3
MinnowBoard Intel Atom E640 x86 Bonnell 1 1 GHz
Intel
GMA600
1 GB 64 DDR2
MIPS Creator CI20 Ingenic JZ4780
Ingenic XBurst
(mips32 rev.2)
2 1.2 GHz
PowerVR
SGX540
1 GB 32 DDR3
MiraBox
Marvell Armada
370
ARMv7 1 1.2 GHz N/A 1 GB 1333 16 DDR3L
MK802 II Allwinner A10 ARM Cortex-A8 1 1 GHz Mali-400 1 GB 960 DDR3
MK808 Rockchip RK3066 ARM Cortex-A9 2 1.6 GHz
Mali-
400MP4
@250 MHz
1 GB DDR3
MTB025
WonderMedia
WM8850
ARM Cortex-A8 1 1.2 GHz Mali-400
512
MB
MYIR MYD-
AM335X
TI Sitara AM335x ARM Cortex-A8 1
800-1000
MHz
PowerVR
SGX530
(optional)
512
MB
16 DDR3
NanoPC-T1
Samsung Exynos
4 (4412)
ARM Cortex-A9 4
Mali-
400MP4
1 GB 960 DDR3
NanoPi 2 Samsung S5P4418 ARM Cortex-A9 4 1.4 GHz 1 GB 32 DDR3

NanoPi NEO Allwinner H3 ARM Cortex-A7 4 1.2 GHz
ARM Mali-
400 MP2
256 or
512
MB
864 16 DDR3
Nitrogen6x
Freescale i.MX6
Quad
Vivante
GC2000 +
GC355 +
GC320
1 GB
(2 GB
op-
tion)
1066 64 DDR3
Nvidia Jetson TK1 Nvidia Tegra K1
ARM Cortex-A15
"low-power core"
5 (4 +
1)
2.3 GHz
Nvidia
GK20A (192
CUDA co-
res) @950
MHz
2 GB 933 64 DDR3L
Nvidia Jetson TX1 Nvidia Tegra X1
ARM Cortex-A57
ARM Cortex-A53
8 (4 +
4)
1.9 GHz
1.3 GHz
Nvidia
GM20B (256
CUDA co-
res) @1000
MHz
4 GB 64 LPDDR4
ODROID-C1/C1+ Amlogic S805 ARM Cortex-A5 4 1.5 GHz
Mali-450MP
@600 MHz
1 GB 32 DDR3
ODROID-C2 Amlogic S905 ARM Cortex-A53 4 1.5 GHz
Mali-
450MP3
+2VS @700
MHz
2 GB 64 DDR3
ODROID-U3
Samsung Exynos
4 Quad
Mali-
400MP4
@440 MHz
2 GB 880 LPDDR2
ODROID-W
Broadcom
BCM2835
ARM11 1 700 MHz
Broadcom
VideoCore
IV
512
MB
32 LPDDR2
ODROID-XU
Samsung Exynos
5 Octa (5410)
ARM Cortex-A15
ARM Cortex-A7
8 (4 +
4)
1.7 GHz
1.2 GHz
PowerVR
SGX544MP3
@600 MHz
2 GB 800 32 LPDDR3

ODROID-XU3
Samsung Exynos
5 Octa (5422)
ARM Cortex-A15
ARM Cortex-A7
8 (4 +
4)
2 GHz 1.4
GHz
ARM Mali-
T628 @695
MHz
2 GB 933 32 DDR3L
ODROID-XU4
Samsung Exynos
5 Octa (5422)
ARM Cortex-A15
ARM Cortex-A7
8 (4 +
4)
2 GHz 1.4
GHz
ARM Mali-
T628 @695
MHz
2 GB 933 32 DDR3L
ODROID-XU3 Lite
Samsung Exynos
5 Octa (5422)
ARM Cortex-A15
ARM Cortex-A7
8 (4 +
4)
1.8 GHz
1.3 GHz
ARM Mali-
T628 @695
MHz
2 GB 933 32 DDR3L
OLinuXino A10 LI-
ME
Allwinner A10 ARM Cortex-A8 1 1 GHz Mali-400
512
MB
DDR3
OLinuXino A13 Allwinner A13 ARM Cortex-A8 1 1 GHz Mali-400
512
MB
32 DDR3
OLinuXino A13
MICRO
256
MB
16 DDR3
OLinuXino A13
WIFI
512
MB
16 DDR3
OLinuXino A20 LI-
ME
Mali-
400MP2
512
MB
DDR3
OLinuXino A20 LI-
ME2
Mali-
400MP2
1 GiB 32 DDR3
OLinuXino A20
MICRO
Mali-
400MP2
1 GB DDR3
Orange Pi Allwinner A20 ARM Cortex-A7 2
ARM Mali-
400 MP2
1 GB 32 DDR3
Orange Pi Mini Allwinner A20 ARM Cortex-A7 2
ARM Mali-
400 MP2
1 GB 32 DDR3
Orange Pi 2 Allwinner H3 ARM Cortex-A7 4 1.536GHz
ARM Mali-
400 MP2
@600 MHz
1 GB 32 DDR3
Orange Pi Mini 2 Allwinner H3 ARM Cortex-A7 4 1.536GHz
ARM Mali-
400 MP2
@600 MHz
1 GB 32 DDR3

Orange Pi PC Allwinner H3 ARM Cortex-A7 4 1.536GHz
ARM Mali-
400 MP2
@600 MHz
1 GB 32 DDR3
Orange Pi Plus Allwinner H3 ARM Cortex-A7 4 1.536GHz
ARM Mali-
400 MP2
@600 MHz
1 GB 32 DDR3
Orange Pi Plus 2 Allwinner H3 ARM Cortex-A7 4 1.536GHz
ARM Mali-
400 MP2
@600 MHz
2 GB 32 DDR3
Orange Pi One Allwinner H3 ARM Cortex-A7 4 1.2GHz
ARM Mali-
400 MP2
@600 MHz
512
MB
32 DDR3
Orange Pi Lite Allwinner H3 ARM Cortex-A7 4 1.2GHz
ARM Mali-
400 MP2
@600 MHz
512
MB
32 DDR3
Orange Pi PC Plus Allwinner H3 ARM Cortex-A7 4 1.536GHz
ARM Mali-
400 MP2
@600 MHz
1 GB 32 DDR3
Orange Pi Plus 2E Allwinner H3 ARM Cortex-A7 4 1.536GHz
ARM Mali-
400 MP2
@600 MHz
2 GB 32 DDR3
Ouya
Nvidia Tegra 3
T33-P-A3
Nvidia ULP
GeForce
1 GB 1600 DDR3
P112
Zilog
Z8018216FSC
Zilog Z180 1 16 MHz N/A MB 8 SRAM
PandaBoard ES TI OMAP4460 ARM Cortex-A9 2 1.2 GHz
PowerVR
SGX540
1 GB LPDDR2
pcDuino Lite Allwinner A10 ARM Cortex-A8 1 1 GHz Mali-400
512
MB
pcDuino v2 Allwinner A10 ARM Cortex-A8 1 1 GHz Mali-400 1 GB
pcDuino3 Allwinner A20 ARM Cortex-A7 2 1 GHz
Mali-
400MP2
1 GB

pcDuino3Nano Allwinner A20 ARM Cortex-A7 2 1 GHz
Mali-
400MP2
1 GB
PC Engines
APU.1D
AMD Embedded
G-Series T40E
APU
N/A (di-
sabled in
BIOS)
2 GB 1066 64 DDR3
PC Engines
APU.1D4
AMD Embedded
G-Series T40E
APU
N/A (di-
sabled in
BIOS)
4 GB 1066 64 DDR3
PC Engines
APU.2C2
AMD Embed-
ded G-Series
GX-412TC APU
x86-64 Jaguar 4 1 GHz N/A 2 GB 1333 64 DDR3
PC Engines
APU.2C4
AMD Embed-
ded G-Series
GX-412TC APU
x86-64 Jaguar 4 1 GHz N/A 4 GB 1333 64
DDR3
ECC
phyBOARD-Wega TI Sitara AM335x ARM Cortex-A8 1 800 MHz
PowerVR
SGX530
512
MB
DDR3
phyBOARD-Mira Freescale i.MX6 ARM Cortex-A9 4 1 GHz N/A 1 GB DDR3
PINE A64 Allwinner A64 ARM Cortex-A53 4 1.2 GHz
Mali-
400MP2
512MB 64 DDR3
Radxa Rock Rockchip RK3188 ARM Cortex-A9 4 1.6 GHz
Mali-
400MP4
2 GB DDR3
Radxa Rock Lite Rockchip RK3188 ARM Cortex-A9 4 1.6 GHz
Mali-
400MP4
1 GB DDR3
Raspberry Pi Mo-
del A / B rev 1
Broadcom
BCM2835
ARM11 1 700 MHz
Broadcom
VideoCore
IV
256
MB
Raspberry Pi Mo-
del B rev 2 / B+
Broadcom
BCM2835
ARM11 1 700 MHz
Broadcom
VideoCore
IV
512
MB
Raspberry Pi 2 Mo-
del B
Broadcom
BCM2836
Broadcom
VideoCore
IV
1 GB LPDDR2

Raspberry Pi 3 Mo-
del B
Broadcom
BCM2837
Broadcom
VideoCore
IV
1 GB LPDDR2
Raspberry Pi Zero
Broadcom
BCM2835
ARM11 1 1 GHz
Broadcom
VideoCore
IV
512
MB
LPDDR2
MYIR Rico Board TI AM437x ARM Cortex-A9 1 1 GHz 512MB DDR3
Rikomagic MK802 Allwinner A10 ARM Cortex-A8 1 1 GHz
AMD
Z430/Z160
512
MB
DDR3
Rikomagic
MK802+ / MK802
II
AMD
Z430/Z160
1 GB DDR3
RIoTboard
Freescale i.MX6
Solo
Vivante
GC880 +
GC320
1 GB DDR3
RouterBOARD
RB450G
Qualcomm Athe-
ros AR7161
MIPS 24K 1 680 MHz N/A
256
MB
DDR
RouterBOARD
RB953GS-5HnT
Qualcomm Athe-
ros QCA9558
MIPS 74Kc 1 720 MHz N/A
128
MB
DDR2
Snowball SKY-
S9500
ST-Ericsson Nova
A9500
ARM Cortex-A9 2 1 GHz Mali-400 1 GB LPDDR2
Supermicro E100-
8Q
Intel® Quark™
SoC X1021
x86 Quark 1 400 MHz N/A
512
MB
800/1600
MHz
DDR3
ECC
TBS 2910 Matrix
Freescale i.MX6
Quad
Vivante
GC2000 +
GC335 +
GC320
2 GB DDR3
Tronsmart Draco
Meta
Allwinner A80
ARM Cortex-
A15x4/ARM
Cortex-A7x4
8 1.3 GHz
PowerVR
64-core 6230
2 GB 1600 64 DDR3
Tronsmart Draco
Telos
Allwinner A80
ARM Cortex-
A15x4/ARM
Cortex-A7x4
8 1.3 GHz
PowerVR
64-core 6230
4 GB 1600 64 DDR3

TS-7250-V2
Marvell Armada
PXA168
PJ1/Mohawk(ARM-
based)
1 1GHz N/A 512MB 16 DDR3
TS-7680 Freescale i.MX286 ARM9E 1 454MHz N/A
128MB
or
256MB
16 DDR2
TS-7970
Freescale i.MX6
Quad
ARM Cortex-A9 4 1GHz
Vivante
GC2000 +
GC355 +
GC320
1 GB
(2 GB
op-
tion)
1066 64 DDR3
UDOO Dual Basic
Freescale i.MX6
Dual Lite Atmel
SAM3X8E
ARM Cortex-A9
ARM Cortex-M3
3 (2 +
1)
1 GHz 84
MHz
Vivante
GC880 +
GC320
1 GB 800 32 DDR3
UDOO Dual
Freescale i.MX6
Dual Lite Atmel
SAM3X8E
ARM Cortex-A9
ARM Cortex-M3
3 (2 +
1)
1 GHz 84
MHz
Vivante
GC880 +
GC320
1 GB 800 32 DDR3
UDOO Quad
Freescale i.MX6
Quad Atmel
SAM3X8E
ARM Cortex-A9
ARM Cortex-M3
5 (4 +
1)
1 GHz 84
MHz
Vivante
GC2000 +
GC355 +
GC320
1 GB 1066 64 DDR3
UDOO X86 Advan-
ced
Intel N3160 x86 4 2.24 GHz
Intel® HD
400 Grap-
hics, 12
execution
units up to
640 MHz
4 GB
DDR3L
DUAL
CHAN-
NEL
UDOO X86 Basic Intel x5-E8000 x86 4 2 GHz
Intel® HD
Graphics 12
execution
uints up to
320 MHz
2 GB DDR3L

UDOO X86 Ultra Intel N3710 x86 4 2.56 GHz
Intel® HD
405 Grap-
hics, 16
execution
units up to
700 MHz
8 GB
DDR3L
DUAL
CHAN-
NEL
UP Intel x5-Z8350 x86-64 4 1.44 GHz
Intel® HD
400 Grap-
hics, 12 EU
GEN 8, up
to 500 MHz
1/2/4
GB
1600 64 DDR3L
Utilite Pro
Freescale i.MX6
Quad
Vivante
GC2000 +
GC355 +
GC320
2 GB 1066 DDR3
Utilite Standard
Freescale i.MX6
Dual
Vivante
GC2000 +
GC355 +
GC320
2 GB 1066 DDR3
Utilite Value
Freescale i.MX6
Solo
Vivante
GC880 +
GC320
512
MB
1066 DDR3
VIA APC 8750 /
Rock
WonderMedia
WM8750
ARM1176JZF 1 800 MHz Mali-200
512
MB
DDR3
VIA Springboard
VAB-600
WonderMedia
WM8950
ARM Cortex-A9 1 800 MHz Mali-400 1 GB 1066 32 DDR3
Wandboard Dual
Freescale i.MX6
Dual
Vivante
GC880 +
GC320
1 GB DDR3
Wandboard Quad
Freescale i.MX6
Quad
Vivante
GC2000 +
GC355 +
GC320
2 GB DDR3

Wandboard Solo
Freescale i.MX6
Solo
Vivante
GC880 +
GC320
512
MB
DDR3
MYIR Z-turn
Board
Xilinx XC7Z010-
1CLG400C
or XC7Z020-
1CLG400C
ARM Cortex-A9
+ FPGA
2 667 MHz 1GB DDR3
Graperain G4418
SBC
Samsung S5P4418 ARM Cortex-A9 4 1.4 GHz Mali-400 1 GB 32 DDR3
Graperain G6818
SBC
Samsung S5P6818 ARM Cortex-A53 8 1.4+ GHz Mali-400 2 GB 32 DDR3
Tabla 2: Comparativa de mini PC

Cluster Raspberry PI-3 con Cassandra y Spark en Docker

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Cluster Raspberry PI-3 con Cassandra y Spark en Docker

Similar to Cluster Raspberry PI-3 con Cassandra y Spark en Docker (20)

Recently uploaded

Recently uploaded (20)

Cluster Raspberry PI-3 con Cassandra y Spark en Docker