Estudio y Mejora del Rendimiento del Backend...Apache Storm y Apache Spark Streaming. Capa de...

Estudio y Mejora del Rendimiento del Backend

Grado en Ingeniería Informática

Trabajo Fin de Grado Autor: Rafael Alejandro Mollá Sirvent

Tutor/es: Virgilio Gilart Iglesias

Junio 2016

Agradecimientos A Gemalto Alicante por la confianza depositada y por darme la oportunidad de realizar

este trabajo de investigación que me ha hecho crecer como informático y como persona.

En especial al Equipo NxServer por haberme hecho sentir uno más.

A Andrea.

“Los datos pueden revelar secretos

a quienes tengan la humildad, el deseo

y las herramientas para escuchar”

Mayer y Cukier

1

Índice 1. Justificación y Objetivos ........................................................................................................... 2

2. Introducción ............................................................................................................................. 3

2.1. Big Data ............................................................................................................................. 3

2.2. Gemalto ............................................................................................................................. 3

2.3. Objetivo ............................................................................................................................. 4

3. Fase de Ámbito del Problema .................................................................................................. 6

3.1. Arquitectura Actual del Backend ....................................................................................... 6

3.2. Arquitectura Lambda ......................................................................................................... 7

4. Fase de Formación y Conocimientos Previos ........................................................................... 9

4.1. Vagrant .............................................................................................................................. 9

4.2. Capa de Ingestión ............................................................................................................ 10

¿Qué son las colas de mensajes? ....................................................................................... 10

4.2.1. RabbitMQ ................................................................................................................. 11

4.2.2. Kafka ......................................................................................................................... 13

4.3. Capa de Procesado .......................................................................................................... 15

4.3.1. Storm ........................................................................................................................ 15

4.3.2. Spark Streaming ....................................................................................................... 16

4.4. Capa de Persistencia ........................................................................................................ 19

¿Qué es NoSQL? ................................................................................................................. 19

4.4.1. MongoDB .................................................................................................................. 19

4.4.2. Cassandra ................................................................................................................. 22

5. Desarrollo del Prototipo ......................................................................................................... 26

5.1. Elección de las Tecnologías ............................................................................................. 26

5.2. Creación de los Servidores con Vagrant .......................................................................... 27

5.2.1. RabbitMQ ................................................................................................................. 27

5.2.2. Apache Storm ........................................................................................................... 30

5.2.3. Cassandra ................................................................................................................. 34

5.3. Aplicación ........................................................................................................................ 40

5.4. Pruebas ............................................................................................................................ 50

6. Limitaciones y Propuestas ...................................................................................................... 56

7. Bibliografía ............................................................................................................................. 57

2

1. Justificación y Objetivos El presente documento constituye un Trabajo Final de Grado (TFG) que describe el

desarrollo de un prototipo funcional del futuro backend de la empresa líder en seguridad

digital, Gemalto.

La principal motivación para llevar a cabo este proyecto de investigación radica en poder

conocer de primera mano una de las ramas de la informática que más interés genera

actualmente, el Big Data, así como el gran reto que supone trabajar en una empresa de

talla mundial y llevar a cabo un estudio de notable complejidad que contribuirá de forma

significativa a mejorar el funcionamiento de dicha empresa.

De este modo, este TFG se encuentra asociado a la labor desempeñada durante el

desarrollo de las asignaturas Prácticas Externas I y Prácticas Externas II en la delegación

de Gemalto en Alicante.

Los objetivos generales del proyecto se encuentran en consonancia con los establecidos

en la guía docente, entre los que destacan:

• Capacidad para definir, evaluar y seleccionar plataformas hardware y software

para el desarrollo y la ejecución de sistemas, servicios y aplicaciones informáticas.

• Capacidad para concebir y desarrollar sistemas o arquitecturas informáticas

centralizadas o distribuidas integrando hardware, software y redes de acuerdo con

los conocimientos adquiridos.

• Capacidad para resolver problemas con iniciativa, toma de decisiones, autonomía

y creatividad. Capacidad para saber comunicar y transmitir los conocimientos,

habilidades y destrezas de la profesión de Ingeniero/a Técnico en Informática.

El objetivo principal de este trabajo es el desarrollo de un prototipo funcional del futuro

backend de la empresa, siguiendo el patrón de la “Arquitectura Lambda”. Este prototipo

sirve como prueba de concepto para la implantación del nuevo backend.

3

2. Introducción 2.1. Big Data

El término Big Data hace referencia a la técnica de tratamiento de ingentes cantidades de

datos las cuales son imposibles de tratar con los métodos y herramientas de análisis de

datos habituales.

Esta nueva técnica surge debido al aumento del tráfico de datos en internet procedentes

de páginas web, aplicaciones de imagen y vídeo, redes sociales, dispositivos móviles,

apps, sensores, internet de las cosas, etc. capaces de generar, según IBM, más de 2.5

quintillones de bytes al día, hasta el punto de que el 90% de los datos del mundo han sido

creados durante los últimos dos años.

Muchas empresas basan sus casos de negocio en las siguientes ventajas que se pueden

derivar del Big Data (IBM, 2012):

• Decisiones más inteligentes – Aprovechar nuevas fuentes de datos para mejorar

la calidad de la toma de decisiones.

• Decisiones más rápidas – Permitir una captura y análisis de datos en tiempo más

real para respaldar la toma de decisiones en el “punto de impacto”, por ejemplo

cuando un cliente está navegando por su sitio web o al teléfono con un

representante del servicio de atención al cliente.

• Decisiones que marquen la diferencia – Centrar las iniciativas de Big Data en

ámbitos que proporcionen una verdadera diferenciación.

2.2. Gemalto

Gemalto es líder mundial en seguridad digital.

La compañía fue creada en junio de 2006 por la fusión de las compañías de Axalto y

Gemplus International.

Permite a empresas y gobiernos de todo el mundo ofrecer servicios digitales confiables y

convenientes a miles de millones de personas.

Su gran experiencia abarca todo el proceso de creación de soluciones de seguridad digital

para los clientes de otras empresas y sus clientes. Desarrollan aplicaciones de software y

sistemas operativos seguros que incorporan en muchos tipos de dispositivos, como las

4

tarjetas UICC o SIM, las tarjetas bancarias, los tokens, los pasaportes electrónicos y las

tarjetas de identificación electrónicas.

Gemalto N.V. es una sociedad que cotiza en bolsa, constituida en los Países Bajos. Tiene

sus oficinas centrales en Ámsterdam y cuenta con filiales y empresas del grupo en todo

el mundo.

Ingresó en 2015 3.100 millones de euros, cuenta un sitio operativo en 49 países de todo

el mundo y 14.000 empleados de 117 nacionalidades distintas.

La función principal de la oficina de Alicante es medir la calidad de experiencia (QoE) y

la calidad de servicio (QoS) de usuarios de compañías telefónicas. Para ello se recolectan

datos de los dispositivos móviles a través de aplicaciones móviles y aplicaciones

instaladas en tarjetas SIM. Los datos llegan al backend, donde se les extrae información.

Esta información obtenida se muestra a través de una aplicación web a las compañías

telefónicas que tengan contratado el servicio.

2.3. Objetivo

El objetivo de este trabajo es la investigación y el desarrollo de un prototipo de

Arquitectura Lambda que sirva como primera fase para la implantación de un nuevo

backend en Gemalto. El motivo de este cambio radica en que actualmente se emplea una

solución Big Data hecha a medida, lo cual es costoso de mantener y de mejorar. La

principal idea es migrar a un backend compuesto por tecnologías modernas y estándar

con el que se pueda sacar más provecho al producto con un menor coste en hardware y

en recursos humanos.

Objetivos específicos:

• Analizar la arquitectura actual.

• Analizar las tecnologías propuestas por la empresa según la Arquitectura Lambda.

• Crear máquinas virtuales para cada una de las tecnologías analizadas.

• Seleccionar las tecnologías más adecuadas para el prototipo.

• Desarrollar el prototipo.

5

Para la consecución de los objetivos establecidos, se ha dividido el trabajo en varias fases,

las cuales se describen a continuación:

Fase de Ámbito del Problema

En esta primera fase se analiza la arquitectura actual del backend, atendiendo

especialmente las limitaciones que la empresa encuentra en ella, para poder así delimitar

las necesidades de la misma y determinar las características de la nueva arquitectura.

Además se realizará un análisis exhaustivo de la nueva arquitectura elegida.

Fase de Formación y Conocimientos Previos

Una vez determinada la nueva estructura, se procederá a realizar una fundamentación

teórica de la herramienta Vagrant, que será empleada para la creación de máquinas

virtuales. Además, también se llevará a cabo el estudio de las tecnologías propuestas por

la empresa que formarán las diferentes capas del prototipo del nuevo backend.

Desarrollo del Prototipo

Tras concluir la fase de formación, se dispondrá de los datos necesarios para poder

realizar la selección de las tecnologías que formarán el prototipo. Por último, se procederá

a explicar cómo se ha llevado a cabo dicho prototipo, entrando en detalle en cada una de

las partes que lo componen.

6

3. Fase de Ámbito del Problema En esta fase se llevará a cabo el estudio de la arquitectura actual del backend de la

empresa, con el objetivo de fundamentar las necesidades de ésta para poder realizar una

adecuada elección de la nueva arquitectura a emplear.

Así pues, el sistema actual del que hace uso Gemalto es altamente personalizado, lo que

supone realizar tareas de mantenimiento de forma continua que no tendrían lugar si se

trabajara con tecnologías estándar. Además, la empresa debe ser capaz de soportar un

aumento significativo del número de clientes respecto al actual, por lo que necesita una

estructura que le aporte la capacidad de atender a un mayor número de peticiones.

Igualmente se pretende que esta nueva arquitectura permita el desarrollo de nuevos

productos, que a día de hoy serían imposibles de crear.

Por tanto, la necesidad es la creación de un sistema que fundamentalmente cumpla las

siguientes premisas:

• Alta disponibilidad

• Escalabilidad

• Fácil mantenimiento

3.1. Arquitectura Actual del Backend

El backend actual de Gemalto es una solución Big Data personalizada y hecha a medida,

la cual es difícil de mejorar y mantener.

Los componentes principales de esta arquitectura son:

Base de datos Company/Project: se trata de una base de datos MySQL multi-tenant

en la que se almacenan los datos de las compañías que tienen contratado el servicio.

El hecho de ser multi-tenant hace que parezca que exista una aplicación para cada

cliente pero en realidad es la misma.

Base de datos Shard: se trata de una base de datos MySQL en la que se guardan

todos los datos que envían los dispositivos móviles en bruto.

Base de datos Summary: se trata de una base de datos multidimensional (cubos

OLAP) la cual se utiliza para hacer reportes que son utilizados en el frontend.

7

Memcached: como sistema de caché.

Mule ESB: es un framework de mensajería Enterprise Service Bus que se utiliza

como endpoint para los terminales que envían datos y como intermediario entre el

backend y el frontend.

A parte de los problemas que acarrea ser una solución Big Data personalizada existe el

problema del gran número de escrituras por parte de los dispositivos móviles que tiene

que soportar este servicio, este sería el mayor cuello de botella del sistema actual.

3.2. Arquitectura Lambda

La Arquitectura Lambda es un modelo de procesado de datos diseñado por Nathan Marz

para soportar enormes cantidades de datos.

Los objetivos de este modelo es construir un sistema con las siguientes características:

• Tolerante a fallos, tanto a fallos de hardware como a errores humanos.

• Alto rendimiento

• Escalabilidad horizontal, con lo que añadiendo más máquinas se conseguiría una

mayor capacidad de procesado.

• Extensibilidad de manera que al sistema se le pueda añadir nuevas características.

Ilustración 1 – Esquema Arquitectura Lambda

8

Este modelo lo forman principalmente tres componentes o capas (layers):

Capa Batch: es la parte encargada de pre-procesar las vistas Batch. Esta capa

almacena todo el "Dataset Maestro" y le aplica las vistas Batch accediendo a datos de

manera aleatoria.

Capa de Servicio: proporciona acceso a datos a través de una selección aleatoria de

las vistas Batch. Esta capa ofrece: robustez y tolerancia a fallos, escalabilidad,

extensibilidad, queries Ad-hoc y mantenimiento mínimo.

Capa de Velocidad: Los datos de entrada se van almacenando de manera incremental

en el dataset, esto quiere decir que según se vaya recibiendo, leyendo y procesando,

se irá escribiendo. La lectura y escritura de datos se realiza de manera aleatoria. La

idea es que cuando se necesite acceder a datos, se realice tanto a través de la capa de

Servicio como a través de la capa de Velocidad.

Para hacer el prototipo de la prueba de concepto, en Gemalto se decidió simplificar la

Arquitectura Lambda en tres capas:

Capa de Ingestión: se encarga de recibir y mantener los mensajes que envía la

aplicación hasta ser consumidos por la Capa de Procesado. Se estudiarán las

tecnologías: RabbitMQ y Apache Kafka.

Capa de Procesado: se encarga de obtener los mensajes de la capa de ingestión,

procesarlos y almacenarlos en la Capa de Persistencia. Se estudiarán las tecnologías:

Apache Storm y Apache Spark Streaming.

Capa de Persistencia: se encarga de almacenar los datos que se escriben desde la

Capa de Procesado y de servirlos cuando le sean requeridos. Se estudiarán las

tecnologías: MongoDB y Cassandra.

Ilustración 2 – Esquema de la simplificación de la Arquitectura Lambda que se va a utilizar.

9

4. Fase de Formación y Conocimientos Previos En esta fase se explicarán las herramientas y servicios (separados por las capas de la

Arquitectura Lamba) que han requerido formación así como los conocimientos que se

han ido adquiriendo a lo largo de la elaboración de este trabajo. Gracias a este estudio

previo y al conocimiento que se ha extraído de él, se ha podido decidir con qué tecnologías

desarrollar finalmente el prototipo de la nueva arquitectura de backend.

4.1. Vagrant

Vagrant es una herramienta diseñada para crear y aprovisionar máquinas virtuales de

manera automática a partir de ficheros de configuración. De este modo, permite compartir

entornos de desarrollo completos simplemente distribuyendo los ficheros de

configuración.

Comenzó a desarrollarse en 2010 por Mitchell Hashimoto como un proyecto secundario.

Este proyecto secundario adquirió relevancia tras convertirse en el año 2012 en la empresa

HashiCorp, consolidando así el interés y el éxito de esta herramienta entre la comunidad

de desarrolladores.

Se trata de una herramienta con licencia Open Source disponible para Windows, Mac OS

X y GNU/Linux. Originalmente fue desarrollada para trabajar sobre Oracle VirtualBox y

sistemas de aprovisionamiento como Chef, Salt y Puppet. A partir de la versión 1.1,

Vagrant es capaz de trabajar sobre múltiples proveedores como VMware, DigitalOcean

o Amazon EC2.

Gracias a esta herramienta, se ha podido desplegar y destruir los servidores necesarios

para la realización de este trabajo con un simple comando.

La configuración más básica cuenta con un único fichero llamado “Vagrantfile”, el cual

se genera una única vez durante el proceso de creación de una nueva máquina ejecutando

el comando: vagrant init.

Una vez creado el Vagrantfile podemos comenzar a personalizar la máquina en relación

al tipo de máquina que queramos desplegar.

Las máquinas virtuales creadas mediante Vagrant utilizan la imagen de un sistema

operativo o de otra máquina ya generada, a la que llaman box. A partir de esta imagen se

crea la nueva máquina virtual.

10

Existen multitud de “cajas” disponibles con los sistemas operativos más utilizados.

Además, existe la posibilidad de crear tus propias imágenes una vez tengas finalizado el

aprovisionamiento de la máquina. Gracias a esto se puede crear, por ejemplo, una imagen

base con todas las herramientas genéricas de desarrollo y a partir de esta, instalar las

herramientas específicas para cada componente de un equipo de desarrollo.

Dentro del Vagrantfile indicaremos el tipo de “caja” que queremos utilizar y añadiremos

todas las configuraciones de la máquina: nombre del equipo, número de procesadores,

cantidad de memoria RAM, configuraciones de red…etc.

El siguiente paso será crear un script con los comandos necesarios para aprovisionar la

máquina, al cual llamaremos desde el propio Vagrantfile.

Para iniciar la nueva máquina simplemente ejecutamos el comando vagrant up dentro

de la carpeta donde se encuentre el archivo Vagranfile. Al ejecutar este comando, se

desplegará la máquina ejecutando todos los comandos y configuraciones que hayamos

definido.

Una vez creada podremos trabajar con ella mediante SSH o si instalamos una interfaz

gráfica, como si de una máquina virtual corriente se tratara. Las máquinas que hayamos

creado podemos gestionarlas desde la aplicación de VirtualBox o con los comandos que

ofrece Vagrant: vagrant suspend para ponerla en reposo, vagrant halt para

apagarla y vagrant destroy para eliminarla.

4.2. Capa de Ingestión

¿Qué son las colas de mensajes?

Básicamente son un intermediario entre clientes y servidores o, dicho de otro modo,

publicadores y consumidores.

Si recordamos los conceptos elementales de la programación de pilas y colas veremos

que es un concepto sencillo donde los emisores producen mensajes y para que estos

lleguen a su destinatario deben ser entregados a un intercambiador que los colocará en la

cola del respectivo destinatario, finalmente el destinatario puede ir progresivamente

desencolando y procesando los mensajes.

11

Ventajas que ofrecen:

• Redundancia

• Naturaleza asíncrona

• Garantía de entrega y orden

• Disponibilidad

• Elasticidad

• Desacoplamiento

• Escalabilidad

4.2.1. RabbitMQ

RabbitMQ es un servicio de colas de mensajes Open Source liberado bajo la licencia

Mozilla Public License. Este software fue desarrollado inicialmente por Rabbit

Technologies Ltd. la cual fue comprada en 2010 por la división SpringSource de

VMware. Debido a la unión de empresas, desde mayo de 2013 el responsable del servicio

es Pivotal Software.

Está escrito en Erlang, un lenguaje funcional con reputación para sistemas distribuidos,

con alta disponibilidad y tolerantes a fallos. Utiliza el framework Open Telecom Platform

(OTP) para construir sus capacidades de ejecución distribuida y conmutación ante errores.

Está disponible para Windows, Mac OS X, GNU/Linux y plataformas en la nube como

Amazon Web Services. Además, existe un API cliente para los lenguajes más relevantes:

Python, Java, Ruby, PHP, C#, Javascript, Go, Elixir y Objective-C.

Este software proporciona las ventajas de las colas de mensajes además de otras: (Wiesel,

Codehero, 2014)

• Soporta múltiples protocolos, muchas soluciones solo manejan uno solo como

AMQP.

• Dispone de librerías en casi todos los lenguajes de programación.

• Rastreo de mal comportamiento en las colas.

12

• Clusterización de varios servidores de colas para evitar que el sistema de

encolamiento falle.

• Múltiples tipos de enrutamiento, incluso puedes crear tu propia ruta.

• Soporta plugins para extender su comportamiento.

• Amigable interfaz gráfica.

A continuación se describirán los conceptos más importantes de RabbitMQ:

Producer: Aplicación que envía mensajes. RabbitMQ soporta la mayoría de los

lenguajes de programación más populares.

Consumer: Aplicación que recibe mensajes.

Queue: Buffer que almacena mensajes.

Message: Información que se envía desde el Producer al Consumer a través de

RabbitMQ.

Channel: Es una conexión virtual dentro de una conexión. Cuando se publican o

consumen mensajes se hace a través de un “canal”.

Exchange: Recibe mensajes de productores y los publica en colas dependiendo del

tipo de “intercambiador” que sea.

Binding: Es un enlace entre un intercambiador y una cola de mensajes

Routing key: Es una clave que el intercambiador utiliza para decidir cómo redirigir

los mensajes a las colas. Es como la dirección de destino del mensajes.

En Rabbit los mensajes no son publicados directamente a la cola de mensajes sino que el

productor envía el mensaje a un “exchange” (intercambiador). El intercambiador es el

responsable de dirigir los mensajes a las diferentes colas.

Existen cuatro tipos de intercambiadores:

Direct: dirige el mensaje a una cola basándose en el “routing key”. El mensaje es

llevado a las colas cuyo “binding key” coincide exactamente con el routing key del

mensaje.

Fanout: dirige los mensajes a todas las colas con a las que esté ligado.

13

Topic: dirige los mensajes a una o más colas de mensajes basándose en la

coincidencia entre el routing key del mensajes y el patrón usado para enlazar una cola

a un intercambiador.

Headers: utiliza los atributos de la cabecera del mensajes para redireccionar los

mensajes a las colas correspondientes.

4.2.2. Kafka

Apache Kafka es un sistema de mensajería publicación/suscripción distribuida de alto

rendimiento. Fue desarrollado inicialmente por LinkedIn y actualmente por Apache

Software Foundation. Está escrito en Scala y se distribuye bajo licencia Apache License

2.0.

El diseño de este sistema responde a las siguientes características, señaladas por Luis

Miguel García (2012)

• Rápido: un solo Broker puede trabajar con cientos de megabytes de lecturas y

escrituras por segundo desde miles de clientes.

• Escalable: está diseñado para permitir que un único cluster funcione como el eje

central de datos, el cual puede ser ampliado sin tiempo de inactividad.

• Mensajería persistente a estructuras de disco O1. Esto suministra un rendimiento

persistente en el tiempo, incluso cuando se produce el almacenamiento de varios

TB de mensajes.

• Alto rendimiento: Kafka tiene la capacidad de tolerar cientos de miles de mensajes

por segundo, incluso mediante un hardware sencillo.

• Soporte para la participación de mensajes. Esto se produce mediante los

servidores de Kafka y el consumo distribuido en un cluster de máquinas

consumidoras, manteniendo la ordenación por partición.

• Soporte para la carga de datos en paralelo en Handoop. Kafka procura agrupar el

procesamiento online y offline, suministrando un mecanismo para la carga

paralela en Hadoop, así como la capacidad de partición en tiempo real del

consumo en un cluster.

14

Los componentes principales de este sistema son:

Topic: son las categorías en las que se clasifican los mensajes enviados a Kafka.

Producer: son los clientes conectados a Kafka que se encargan de publicar los

mensajes, que pueden ser difundidos en uno o varios topics.

Consumer: clientes conectados a Kafka subscritos a uno o varios topics responsables

de consumir los mensajes.

Broker: consiste en cada uno de los nodos que forman el cluster.

El protocolo de comunicación empleado por este sistema de mensajería es de tipo

agnóstico que va sobre el protocolo HTTP. Este hecho permite la institución e

implementación de nuevos clientes procedentes de cualquier lenguaje de programación,

evadiendo, de esta forma, las limitaciones de las interfaces y las APIs de JMS.

Kafka mantiene cada topic en un log particionado. Cada partición consiste en una

secuencia de mensajes inalterable, de forma que los mensajes son añadidos a una de las

particiones según su orden de llegada, y se les asigna un número secuencial, llamado

offset, que identifica de forma única a cada mensaje dentro de su partición.

Los mensajes permanecen en las particiones durante un periodo de tiempo establecido a

nivel de cluster. Después de este periodo los mensajes son eliminados con el objetivo de

liberar espacio.

Así pues, el hecho de repartir un topic en un log de diversas particiones, ofrece la

posibilidad de escalar de forma horizontal, creando, si fuese necesario más particiones en

el resto de nodos.

Otra de las características de Kafka radica es su tolerancia a fallos, ya que replica cada

partición del log un número configurable de servidores dentro del cluster. La caída de uno

de estos nodos no influye al servicio. Uno de los nodos ejerce de maestro, atendiendo

todas las lecturas y escrituras de la partición, mientras que los demás trabajan como

esclavos, los cuales replican el contenido del maestro ejerciendo de consumidores.

15

4.3. Capa de Procesado

4.3.1. Storm

Apache Storm es un sistema que tiene como función la recuperación de streams de datos

en tiempo real. Se trata de una herramienta de código abierto que recoge datos de forma

distribuida y en alta disponibilidad. Además es tolerante a fallos, es decir, ofrece la

posibilidad de reproducir los datos que no han sido procesados de forma correcta la

primera ocasión.

En lo referente a su funcionamiento, Storm puede funcionar en dos modos diferentes:

local y cluster. El modo local resulta valioso para probar el código desarrollado en la

topología de Storm ya que corre en una única JVM, lo que nos permitirá ajustar los

parámetros de configuración. El modo cluster por su parte, distribuye y ejecuta el código

en las diferentes máquinas y se considera “modo producción”.

Storm está compuesto principalmente por dos elementos fundamentales, el Spout y el

Bolt.

El Spout es el componente se encarga de recoger el tráfico de datos de entrada en el

sistema. En el caso de este trabajo, se usaría para recolectar los mensajes de RabbitMQ o

Apache Kafka.

El Bolt, es el encargado de procesar las tuplas que emite el Spout. Esta acción la realiza

en función de la orden marcada por el algoritmo programado sobre los streams de entrada

y puede difundirlos a otro Bolt. Así pues, Juan Alonso Ramos (2014) recomienda que

cada Bolt realice una sola tarea, de forma que si se necesita realizar diversos cálculos o

transformaciones sobre los datos, lo ideal es crear diferentes Bolt. Este hecho mejorará la

eficiencia y la escalabilidad.

Por otro lado, uno de los aspectos más favorables de Storm es que permite crear una

topología en la que añadir instancias de Bolts y Spouts para que escale el sistema

desplegándola en el cluster de Storm. Este será el encargado de particionar los datos de

entrada y redistribuirlos en los diversos componentes.

16

En cuanto a su arquitectura, ésta no es demasiado compleja y se compone de los siguientes

elementos:

• El nodo “Master”. Es el encargado de ejecutar el demonio conocido como

Nimbus. Este es el responsable de distribuir el código a través del cluster. Además

también lleva a cabo la distribución y monitorización de las tareas en las diferentes

máquinas del cluster.

• Los nodos “supervisor”. Son los responsables de ejecutar el demonio Supervisor

encargado de recoger y procesar las tareas asignadas en la máquina donde corre.

Estos nodos ejecutan una porción de la topología para que así se puedan distribuir

las tareas a lo largo del cluster. Si uno de estos nodos falla en demonio Nimbus lo

detectaría y redirigiría el trabajo a otro supervisor.

• Zookeeper: Este es necesario ya que se ocupa de la coordinación entre el Nimbus

y los Supervisor. Además es el responsable de mantener el estado.

De este modo, Apache Storm es un sistema idóneo para procesar grandes cantidades de

información a tiempo real, ya que es capaz de procesar hasta un millón de tuplas por nodo

por segundo. (Ramos, 2014)

4.3.2. Spark Streaming

Apache Spark es una plataforma de computación en paralelo de código abierto para

análisis y procesos avanzados. Puede ejecutarse y operarse con cuatro tipos de lenguajes

distintos: Scala, que es la sintaxis en la que está escrita la plataforma; Python; R y también

Java. La finalidad de Spark es proporcionar ventajas en el procesamiento de datos de

entrada constante.

Las características esenciales de Spark son:

• Rapidez en procesos de cálculo en memoria y disco.

• Ejecución en plataformas de todo tipo. Puede ejecutarse en Hadoop, Apache

Mesos, en EC2, en modo clúster independiente o en la nube.

• Mayor flexibilidad en la definición de transformaciones.

• Menor uso de almacenamiento en disco.

• Aprovechamiento de la memoria.

17

• Tolerancia a fallos.

Uno de los componentes clave de Spark es Spark Streaming que le otorga la capacidad

de procesamiento continuo.

Este elemento tiene la capacidad de ingerir datos de una amplia gama de fuentes como

pueden ser:

• Flujos derivados de Apache Kafka, Amazon Kinesis y prácticamente cualquier

sistemas de colas de mensajes.

• De dispositivos conectados mediante sockets TCP.

• Datos almacenados en sistemas de archivos HDFS o Amazon S3.

La funcionalidad de Spark Streaming es, a gran escala, apropiarse de un flujo de datos

continuo y transformarlo en un flujo discreto, que recibe el nombre de DStream y está

constituido por paquetes de datos. Internamente ocurre que Spark Streaming almacena y

procesa estos datos como un secuencia de RDDs (Resilient Distributed Data), que

constituye una colección de datos particionada, distribuida e inmutable. De esta forma,

Spark Streaming es el encargado de crear y coordinar los RDDS.

Por otro lado, Spark Streaming cuenta con diferentes modelos de procesamiento que se

corresponden con las semánticas utilizadas. Este factor asegura que los resultados

generados sean fiables, aunque se presenten fallos en los nodos. Los datos pueden ser

procesados según los siguientes modelos:

Exactly once (Exactamente una vez): cada elemento se procesa una única vez. A

pesar de que este modelo parece ser a simple vista el más lógico, no siempre es así,

ya que es el más intensivo en recursos y puede originar problemas de desempeño

debido a todo el procesamiento adicional que se requiere para garantizar que los datos

ni se pierdan ni se dupliquen.

At most once (Máximo una vez): los elementos pueden ser procesados como mucho

una vez o pueden no ser procesados. Debido a que lo más relevante es mantener la

continuidad de flujo, bajo el punto de vista del procesamiento, este es el modelo más

fácil de construir, aunque ello suponga asumir la pérdida ocasional de datos.

18

At least once (Mínimo una vez): cada elemento debe ser procesado al menos una

vez. Este modelo incrementa la posibilidad de que no se pierdan datos pero también

la generación de duplicados. Este modelo proporciona la seguridad de que no se

perderán datos en caso de que exista alguna falla en uno de los nodos, ya que cuando

éste se recupere el procesará todos los datos para asegurar que no se extravíe ninguno.

No todos los tipos de fuentes soportan todos los modelos, sino que es necesario comprobar

qué semántica se soportan en cada una.

Es necesario matizar que Spark Streaming no opera en base a flujos continuos sino a

micro-batches, como ya se ha señalado con anterioridad. Estos micro-batches tienen un

tiempo de intervalo entre ellos que suele ser menos de cinco segundos. Este factor puede

tener consecuencias que es necesario contemplar. Así pues, reducir el intervalo de

desempeño a menos de un segundo ofrece un desempeño casi de tiempo real, pero ello

supone un alto coste en recursos de procesamiento. Otra desventaja del esquema de

micro-batches es que los datos no se reciben en el orden exacto en el que se generan,

factor que puede ser relevante o no en función de la aplicación específica.

19

4.4. Capa de Persistencia

¿Qué es NoSQL?

“NoSQL es un término que describe las bases de datos no relacionales de alto desempeño.

Las bases de datos NoSQL utilizan varios modelos de datos, incluidos los de documentos,

gráficos, claves-valores y columnas. Las bases de datos NoSQL son famosas por la

facilidad de desarrollo, el desempeño escalable, la alta disponibilidad y la resiliencia.”

(Amazon Web Services, 2016)

4.4.1. MongoDB

MongoDB surge de la necesidad de utilizar bases de datos capaces de almacenar y

procesar datos no estructurados de la forma más rápida posible, ya que una gran cantidad

de los datos que se generan actualmente poseen esta característica (Roy, 2014).

Permite el almacenamiento de todo tipo de datos: estructurados, semi-estructurados y no

estructurados. Además, posee un gran rendimiento en cuanto a escalabilidad y procesado

de la información, pudiendo procesar la enorme cantidad de información que se produce

en la actualidad. MongoDB se adapta a las necesidades actuales de las aplicaciones, lo

que permite a las empresas ser más ágiles y crecer de forma más rápida, desarrollar

nuevos tipos de aplicaciones, y productos, mejorar la experiencia del cliente y minimizar

el tiempo desarrollo del producto.

Está dirigido a documentos, de modo que en un solo documento puede almacenar toda la

información relevante, incluyendo todo tipo de datos. Esto se lleva a cabo sin que sea

necesario emplear un esquema preestablecido. Asimismo, permite adaptar el esquema de

la base de datos a las exigencias de la aplicación de forma rápida, cosa que permite reducir

el tiempo y coste de la puesta en producción de la misma. Ello se debe a que permite

cambiar el esquema desde el código de la aplicación, sin tener que emplear labores de

administración de la base de datos.

Según Roy (2014) las principales características de MongoDB son:

• Posee alta disponibilidad y escalabilidad.

• Autobalanceado de carga a través de los distintos shards.

• Replicación nativa: sincronización de datos entre servidores.

20

• Seguridad: autentificación, autorización.

• Gestión avanzada de usuarios.

• Automatic failover: elección automática de un nuevo primario cuando este se ha

caído.

• Tiene la habilidad de actualizarse sin interrumpir el servicio.

• Carece de cuellos de botella que tienen lugar en las bases de datos relacionales al

procesar elevadas cantidades de información.

• Utiliza objetos JSON para guardar y transmitir la información. Esto supone una

ventaja, ya que JSON es el estándar web actual.

• Posibilita la realización de consultas y cálculos espaciales.

• Permite utilizar MapReduce para el procesado de la información a través de

funciones JavaScrip que se ejecutan en los servidores.

• Puede almacenar y ejecutar funciones JavaScrip en el servidor.

• Posee una interfaz gráfica web que permite monitorizar lo que ocurre en las bases

de datos y máquinas.

Además MongoDB ofrece las siguientes prestaciones:

Consultas ad hoc: permite la búsqueda por campos, consultas de rangos y

expresiones regulares. Las consultas pueden devolver un campo específico del

documento pero también puede ser una función JavaScrip definida por el propio

usuario.

Indexación: cualquier campo puede ser indexado y también se pueden realizar

índices secundarios.

Replicación: El tipo de replicación empleado es primario-secundario. El primario

puede ejecutar comandos de lectura y escritura mientras que los secundarios replican

los datos de éste y únicamente pueden ser empleados para lectura o copia de

seguridad, pero no para escritura. Además, estos tienen la capacidad de poder elegir

un nuevo primario en caso de que el existente deje de funcionar.

21

Balanceo de carga: Permite escalar de forma horizontal, empleando el concepto de

shard. Los datos son fraccionados en rangos y distribuidos a través de múltiples shard.

Cada shard puede ser una réplica set. También puede ejecutarse en varios servidores,

balanceando la carga y/o replicando los datos para poder mantener el sistema

funcionando en caso de que exista un fallo de hardware.

Almacenamiento de archivos: La replicación y el balanceo de carga permiten que

MongoDB pueda ser empleado como un sistema de archivos. Esta función recibe el

nombre de GridFS y es una implementación en los drivers, lo cuales exponen

funciones y métodos para la manipulación de archivos y contenidos a los

desarrolladores.

Agregación: MongoDB proporciona un framework de agregación construido como

un pipeline en el que los datos van pasando a través de diferentes etapas en las que

estos datos son modificados, agregados, filtrados y formateados hasta obtener los

resultados deseados. Este proceso puede hacer uso de índices en el caso que existan y

se produce en memoria. También proporciona una función MapReduce que puede ser

empleada para el procesamiento por lotes de datos y operaciones de agregación.

Ejecución de JavaScript del lado del servidor: A través de JavaScrip MongoDB

puede realizar consultas haciendo que estas sean envidas directamente a la base de

datos para ser ejecutadas.

Fragmentación: Es la forma en la que se hace escalable una base de datos. Los

fragmentos se forman por replica set, de forma que si se crean tres fragmentos, cada

uno de ellos tiene un replica set con tres servidores, se dispondría de un total de nueve

servidores. Las consultas se llevaran a cabo de forma distribuida mediante un módulo

enrutador conocido como “mongos” que mantendrá un pequeño pull de conexiones a

los distintos host. Para conocer en que fragmento se debe consultar para poder

recuperar datos de una colección ordenada, se utilizan rangos y shard_key, de tal

forma que se trocea la colección en rangos y se les asigna un id (shard_key), que

puede ser una parte del documento, y se distribuye en los fragmentos (replica set). Así

pues, cuando se consulte la colección se debe proporcionar el shard_key.

MongoDB presenta también una serie de limitaciones y problemas. De este modo, no

implementa las propiedades ACID, lo que supone que no se garantice la durabilidad, la

integridad, la consistencia y el aislamiento requeridos necesariamente en las

22

transacciones. Sobre este punto, se encuentran problemas en la consistencia, ya que las

lecturas estrictamente consistentes ven versiones obsoletas de documentos y pueden

devolver datos incorrectos de lecturas que no deberían haberse producido. Además tienen

lugar bloqueos a nivel de documento ante cada operación de escritura y sólo se podrán

realizar operaciones de escritura concurrentes entre diferentes documentos.

En cuanto a las escrituras, estas no son durables ni verificables ya que MongoDB retorna

cuando todavía no se ha escrito información en el espacio de almacenamiento perdurable,

lo que puede ocasionar pérdidas de información. Por último cabe decir que presenta

problemas de rendimiento cuando el volumen de datos supera los 100 GB.

4.4.2. Cassandra

Cassandra es una base de datos NoSQL distribuida y fundamentada en un prototipo de

almacenamiento de “clave-valor”. Está desarrollada en Java y es de código abierto.

Introduce conceptos atractivos como el soporte para múltiple centros de datos o la

comunicación peer-to-peer entre sus nodos.

El origen de esta base de datos se encuentra en Facebook y fue diseñado para potenciar

la funcionalidad de búsqueda en la bandeja de entrada. En 2008 se liberó como proyecto

open source y más tarde, en febrero de 2010 se convirtió en un proyecto top-level de la

fundación Apache.

Además, Cassandra ofrece soporte para múltiples centros de datos, a través de la

replicación asíncrona sin que sea necesaria la presencia de un servidor maestro,

permitiendo operaciones de baja latencia para todos los clientes.

En cuanto a su rendimiento en 2012, estudios llevados a cabo por la Universidad de

Toronto afirman que: "En términos de escalabilidad, hay un claro ganador a través de

nuestros experimentos. Cassandra logra el más alto rendimiento para el número máximo

de nodos en todos los experimentos", aunque "esto tiene como precio una alta latencia de

escritura y lectura".

En cuanto al modelado de datos, se combinan propiedades de una base de datos clave-

valor y una orientada a columnas. Las claves primarias de cada fila tienen un primer

componente que es la clave de partición. Dentro de una partición, las filas son agrupadas

por las columnas restantes de la clave. El resto de columnas pueden ser indexadas por

23

separado de la clave primaria. Las características específicas del modelado de datos son

(Requena, 2010):

• Presencia de una tabla de datos por cada instancia de Cassandra.

• Cada familia de columnas puede contenes columnas o supercolumnas. Estas

últimas son el resultado de agrupar n-columnas.

• Cada columna contiene elementos de la forma “clave-valor-tiempo”, donde el

valor de tiempo es declarado por el usuario.

• Cada fila de una tabla puede tomar valores en columnas distintas de una familia

de columnas de otra fila, es decir si se dispone de una familia de 5 columnas (A,

B, C, D, E), la fila R1 puede tener valores en A y B mientras que la fila R2 puede

tenerlos en A, C, D y E.

• Las tablas pueden crearse, eliminarse y modificar en tiempo de ejecución sin que

ello suponga el bloqueo de actualizaciones y consultas.

• No soporta joins o subqueries, sino que hace énfasis en la desnormalización a

través de características como colecciones.

El lenguaje empleado en Cassandra es conocido como CQL (Cassandra Query

Language), cuya sintaxis es semejante a SPL, pero presentando menos funcionalidades,

cosa que permite que el inicio en el uso de ésta sea mucho más fácil.

Cassandra implementa una arquitectura peer-to-peer, lo que suprime los puntos de fallo

único y no sigue patrones maestro-esclavo. De esta forma, cualquiera de los nodos puede

tomar el rol de coordinador de una consulta. El driver será el encargado de decidir qué

nodo hace la función de coordinador.

Los datos son repartidos a lo largo del cluster en base a un token único calculado para

cada fila por una función hash. Los nodos se reparten equitativamente en el rango tokens

que va de -263 a 263, esto define el nodo primario. Internamente Cassandra replicará los

datos entre los nodos con la política que le sea definida. Además soporta el concepto de

datacenter para agrupar nodos lógicamente y tener los datos más próximos al usuario.

24

Así pues, las características fundamentales de la arquitectura de Cassandra son:

• Nodos con igual tratamiento.

• No existe una jerarquía.

• Las filas se distribuyen a través de una función hash.

• Cada nodo es responsable de un rango de claves hash.

• La arquitectura puede ser vista como un anillo.

• Los datos se almacenan en tablas.

• Las tablas se guardan en keyspaces.

• Son estructuras flexibles

• Los nuevos nodos se añaden gracias a nodos semilla.

• Emplea un protocolo de comunicación Gossip.

• Los nodos intercambian información (P2P).

• El cliente puede contactar con cualquier nodo (Coordinador).

• El coordinador contacta con nodos involucrados en la replicación o con

coordinadores locales de otros DC.

• La replicación se configura en el keyspace.

Tras todo lo expuesto anteriormente, se puede concluir que las características esenciales

de Cassandra son:

• Emplea sistema NoSQL, distribuido y preparado para Big Data.

• Es un Software libre.

• Emplea nodos iguales constituyendo anillos.

• Es escalable horizontalmente (P2P).

• El lenguaje de consultas es CQL.

• Tiene consistencia eventual.

25

• Es escalable.

• Es tolerable a fallos, los datos se replican automáticamente a múltiples nodos para

recuperarse frente a fallos. Además soporta la replicación a través de múltiples

datacenter. Los nodos que fallen pueden ser reemplazados sin que ello suponga la

inactividad o interrupción de la aplicación.

• Soporta MapReduce. Está integrado con Apache Handoop para soportar

MapReduce y existe también soporte para ApachePig y Apache Hive.

26

5. Desarrollo del Prototipo El desarrollo del prototipo se compone de cuatro partes:

Elección de las Tecnologías: se escoge y justifica con que tecnologías de las

estudiadas de va a desarrollar finalmente el prototipo.

Creación de los Servidores con Vagrant: se describe la composición y creación de

cada servicio utilizando la herramienta Vagrant.

Aplicación: se describe las partes de las que está formada la aplicación y el proceso

de desarrollo que se ha seguido.

Pruebas: se comprueba que el sistema funcione correctamente.

5.1. Elección de las Tecnologías

Cabe destacar que no existe una combinación ideal de tecnologías, ya que todas poseen

características que podrían responder a las necesidades de Gemalto. De este modo, se ha

procedido a elegir la combinación de tecnologías con servidores menos complejos de

crear, configurar y desplegar. Otro factor a tener en cuenta a la hora de la selección ha

sido la sencillez de utilización de las APIs proporcionadas por las diferentes tecnologías.

Por tanto, se ha tomado la decisión de que la mejor combinación es: RabbitMQ en la capa

de ingestión, Apache Storm en la capa de procesado y Cassandra en la capa de

persistencia.

Ilustración 3 – Esquema de la arquitectura del prototipo

27

5.2. Creación de los Servidores con Vagrant

Para la definición de los servidores que conforman el prototipo se ha utilizado un único Vagrantfile, lo que nos permite desplegar toda la arquitectura con un solo comando. También nos permite destruir la estructura con un solo comando cuando hallamos terminado de trabajar con ella.

Todos los servidores utilizados parten de un Sistema Operativo Ubuntu 14.04 LTS de 32 bits.

A continuación se muestra la configuración de cada servicio:

5.2.1. RabbitMQ

En el prototipo, RabbitMQ es un cluster con tres nodos: un maestro y dos esclavos. El

sistema se ha configurado para que los mensajes que lleguen al maestro se repliquen en

los dos esclavos, consiguiendo así tolerancia a fallos y alta disponibilidad.

Vagrant

Ilustración 4 – Definición de RabbitMQ en Vagrant

28

Ilustración 5 – Definición de RabbitMQ en Vagrant

Scripts de Configuración

Para la creación de los servidores que componen el cluster de RabbitMQ se han utilizado

tres scripts de configuración:

rabbitmq.sh

Ilustración 6 – Script rabbitmq.sh

29

rabbit_cluster_config_master.sh

Ilustración 7 – Script rabbit_cluster_config_master.sh

rabbit_cluster_config_slave.sh

Ilustración 8 – Script rabbit_cluster_config_slave.sh

30

5.2.2. Apache Storm

En el prototipo, Storm es un cluster con tres nodos: un maestro y dos supervisores

(esclavos). El nodo maestro ejecutará el demonio Nimbus y Zookeeper, por lo que será el

encargado de distribuir el código a través del cluster y de la coordinación entre el Nimbus

y los Supervisor. Los nodos supervisores ejecutan una porción de la topología para que

así se puedan distribuir las tareas a lo largo del cluster.

Vagrant

Ilustración 9 – Definición de Apache Storm en Vagrant

31

Ilustración 10 – Definición de Apache Storm en Vagrant


Para la creación de los servidores que componen el cluster de Apache Storm se han

utilizado seis scripts de configuración:

java8.sh

Ilustración 11 – Script java8.sh

zookeeper.sh

Ilustración 12 – Script Zookeeper.sh

32

storm.sh

Ilustración 13 – Script storm.sh

upstarNimbus.sh

Ilustración 14 – Script upstarNimbus.sh

33

upstarSupervisor.sh

Ilustración 15 – Script upstarSupervisor.sh

upstarUI.sh

Ilustración 16 –Script upstarUI.sh

34

5.2.3. Cassandra

En el prototipo, Cassandra es un cluster con cuatro nodos: un maestro y tres esclavos. La

instalación de Cassandra se ha realizado a través de la herramienta DataStax, lo cual

proporciona facilidades a la hora de crear y administrar el clúster, además de una potente

interfaz gráfica llamada Opscenter.

Vagrant

Ilustración 17 -‐ Definición de Cassandra en Vagrant

35

Ilustración 18 -‐ Definición de Cassandra en Vagrant


Para la creación de los servidores que componen el cluster de Cassandra se han utilizado

dos scripts de configuración:

opscenter.sh

Ilustración 19 – Script Opscenter.sh

36

cassandraNode.sh

Ilustración 20 – Script cassandraNode.sh

Configuración

En el caso de Cassandra existe un paso que no se puede automatizar, la creación del

cluster. Esta parte de la configuración se realiza a través de la interfaz gráfica (Opscenter)

como se describe a continuación:

Acceder a la UI desde el navegador del host: 192.168.56.20:8888 y hacer click en

“Create Brand New Cluster”.

Ilustración 21 – Configuración del cluster de Cassandra 1

37

En el campo “Package” se debe seleccionar la opción “DataStax Community 2.0.8”, como

usuario y contraseña utilizar “vagrant” y hacer click en “Add Datacenter”.


En el apartado “Node Properties” se añaden las IPs de los tres nodos esclavos. Al finalizar

hacer click en “Add Datacenter”.


38

Hacer click en “Build Cluster”.


Hacer click en “Accept Fingerprints”.


39

Con los anteriores pasos realizados comenzará la construcción del cluster, instalado los

paquetes necesarios en los nodos esclavos.


Cuando haya terminado ya se podrá empezar a utilizar el cluster.


40

5.3. Aplicación

Para poder simular el flujo de los mensajes dentro del prototipo como si de un backend

real se tratase, se ha desarrollado una aplicación Java.

La aplicación está dividida en cuatro paquetes:

producer.rabbitmq: contiene el productor de mensajes.

consumer.rabbitmq: contiene una clase para probar el correcto funcionamiento del

productor de mensajes.

processing.storm: contiene las clases que forman la topología que se ejecuta en

Apache Storm.

persistence.cassandra: contiene las clases para la conexión y pruebas con Cassandra.

producer.rabbitmq

SimpleProducer: se utiliza para abrir y cerrar la conexión con el cluster de RabbitMQ,

además de para enviar los mensajes.

Ilustración 28 – Clase SimpleProducer

41

Ilustración 29 – Clase SimpleProducer

MainSimpleProducer: se utiliza para enviar mensajes al cluster de RabbitMQ.

Ilustración 30 – Clase MainSimpleProducer

42

consumer.rabbitmq

MainSimpleConsumer: se usa para realizar pruebas y comprobar que RabbitMQ está

recibiendo los mensajes que se le envían desde el productor.

Ilustración 31 – Clase MainSimpleConsumer

processing.storm

RabbitMQSpout: definición del comportamiento del Spout de Apache Storm.

Ilustración 32 – Clase RabbitMQSpout

43

Ilustración 33 – Clase RabbitMQSpout

RawBoltCassandra: definición del comportamiento del Bolt de Apache Storm.

Ilustración 34 – Clase RawBoltCassandra

44

Topology: definición de la topología de Apache Storm.

Ilustración 35 – Clase Topology

persistence.cassandra

SimpleClient: se utiliza para conectarse a Cassandra y realizar consultas.

Ilustración 36 – Clase SimpleClient

45


46


47

BoundStatementsClient: sirve para insertar datos en Cassandra mediante una sentencia

predefinida.

Ilustración 39 – Clase BoundStatementsClient

MainBoundStatementsClient: se utiliza para hacer pruebas a Cassandra.

Ilustración 40 – Clase MainBoundStatementsClient

48

Ilustración 41 – Clase MainBoundStatementsClient

QueryDemo: se utiliza para comprobar que el prototipo está funcionando correctamente.

Ilustración 42 – Clase QueryDemo

Se ha hecho uso de Javadoc para documentar el código y Maven para la generación de

JAR de la topología de Apache Storm y para manejar las dependencias.

A continuación se muestra el fichero pom.xml:

Ilustración 43 – pom.xml

49

Ilustración 44 – pom.xml

50

5.4. Pruebas

Para probar el correcto funcionamiento del prototipo se simulará el recorrido de varios

mensajes a través de él, comenzando con el envío de mensajes a RabbitMQ desde la

aplicación Java y finalizando con la comprobación de que se han escrito correctamente

los datos en Cassandra.

En primer lugar se despliegan las máquinas con el comando: vagrant up y se crea el

cluster de Cassandra a través del Opscenter como se ha indicado anteriormente.

Ilustración 45 – Despliegue de los servidores desde terminal

El proceso de pruebas comienza con los servidores desplegados y funcionando.

Ilustración 46 – Interfaz gráfica de RabbitMQ

51

Ilustración 47 – Interfaz Gráfica de Apache Storm

Ilustración 48 – Interfaz gráfica de Cassandra (Opscenter)

52

El primer paso es ejecutar la topología en Apache Storm ejecutando el siguiente comando

a través de una conexión SSH con el nodo maestro:

Ilustración 49 – Comando para arrancar la topología en Apache Storm

Se comprueba en la interfaz gráfica de Storm que se está ejecutando la topología:

Ilustración 50 – Interfaz gráfica de Apache Storm con la topología en ejecución

Se comprueba que Apache Storm está conectado a RabbitMQ, esperando mensajes para

procesar:

Ilustración 51 – Interfaz gráfica de RabbitMQ con los nodos de Apache Storm conectados

53

El segundo paso es mandar mensajes a RabbitMQ, esto se hace desde IntelliJ IDEA

ejecutando la clase “MainSimpleProducer”:

Ilustración 52 – Ejecución de la clase MainSimpleProducer

Se comprueba que están llegando los mensajes a RabbitMQ:

Ilustración 53 – Interfaz gráfica de RabbitMQ recibiendo mensajes

54

Se comprueba que Storm está procesando mensajes:

Ilustración 54 -‐ Interfaz gráfica de Apache Storm procesando mensajes

Se comprueba que Storm ha escrito los mensajes en Cassandra desde el Opscenter:

Ilustración 55 -‐ Interfaz gráfica de Cassandra (Opscenter) con datos insertados

55

Por último, se comprueba que Storm ha escrito los mensajes en Cassandra haciendo una

consulta desde IntelliJ IDEA a través de la clase “QueryDemo”:

Ilustración 56 – Ejecución de la clase QueryDemo

56

6. Limitaciones y Propuestas Para concluir este trabajo se procederá a realizar una reflexión sobre las limitaciones que

se han encontrado en su elaboración así como de las propuestas que ayudarían a

mejorarlo.

En primer lugar, me gustaría destacar la nula formación sobre el área tratada recibida

durante los cuatro años de grado. Esta cuestión fue la que me empujó a decidirme por esta

área de la informática para la elaboración de este proyecto, ya que considero que se trata

de uno de los campos de mayor relevancia en la actualidad. Así pues, en un principio me

encontré abarcando un tema amplio sobre el que no tenía ningún tipo de conocimiento

previo, pero gracias a la ayuda de los compañeros de equipo de Gemalto que me han

acompañado durante el proceso esta primera dificultad fue superada, logrando focalizar

y encauzar el trabajo.

Otra de las dificultades encontradas durante el proceso ha sido la escasez de información

referente al tema de estudio, concretamente sobre las diferentes tecnologías abarcadas.

Además, a esta dificultad se le añade el hecho de que la mayor parte de la información

encontrada está en inglés.

En la empresa donde realicé el periodo de prácticas no encontré ningún tipo de

impedimento, al contrario, fui tratado desde el primer momento como uno más del equipo,

asumiendo responsabilidades propias de un trabajador experimentado.

La elaboración del proyecto se ha visto contrariada en un primer momento por la

simultaneidad del periodo de prácticas con el desarrollo de las restantes asignaturas del

grado, hecho que ha supuesto una escasez de tiempo para su elaboración. A sí mismo, en

segundo lugar, mi estancia en la empresa ha sido prolongada a través de un contrato GIPE

de jornada completa para el desempeño de funciones diferentes a las realizadas durante

el periodo de prácticas. Esto ha supuesto disponer de poco tiempo para la realización de

la memoria.

Para solventar las dificultades encontradas durante el desarrollo del trabajo descrito

propongo el estudio de la posibilidad de impartir una asignatura sobre los fundamentos

del Big Data y las diferentes tecnologías que lo implementan. Considero que esto puede

llevarse a cabo ya que en nuestra universidad existe un curso de verano sobre esta

temática, el cual me planteo realizar en un futuro próximo.

57

7. Bibliografía Alonso Ramos, J. (22 de septiembre de 2014). Introducción a Apache Storm. Obtenido de

Adictos al Trabajo: https://www.adictosaltrabajo.com/tutoriales/introduccion-‐storm/

Alonso Ramos, J. (13 de octubre de 2014). Primeros pasos con Apache Kafka. Obtenido de Adictos al Trabajo: https://www.adictosaltrabajo.com/tutoriales/kafka-‐logs/

Amazon Web Services. (2016). ¿Qué es NoSQL? Obtenido de AWS: https://aws.amazon.com/es/nosql/

Canales Mora, R. (5 de diciembre de 2013). Primeros pasos con Apache Cassandra. Obtenido de Adictos al Trabajo: https://www.adictosaltrabajo.com/tutoriales/primeros-‐pasos-‐apache-‐cassandra/

Cooper, P. (9 de abril de 2009). RabbitMQ – A Fast, Reliable Queuing Option for Rubyists. Obtenido de rubyinside: http://www.rubyinside.com/rabbitmq-‐a-‐fast-‐reliable-‐queuing-‐option-‐for-‐rubyists-‐1681.html

Dans, E. (2011). Big Data: una pequeña introducción. Obtenido de Enrique Dans: https://www.enriquedans.com/2011/10/big-‐data-‐una-‐pequena-‐introduccion.html

Galván, P. (febrero de 2016). Un Vistazo a Apache Spark Streaming. Obtenido de SG Buzz: http://sg.com.mx/revista/50/un-‐vistazo-‐apache-‐spark-‐streaming#.V3UonFdhpER

Gemalto. (2016). Qué hacemos. Obtenido de Gemalto: http://www.gemalto.com/latam/acerca/seguridad-‐digital

Gemalto. (2016). Quiénes somos. Obtenido de Gemalto: http://www.gemalto.com/latam/acerca

Gracia, L. M. (10 de julio de 2013). Un poco de Java. Obtenido de Un poco más de Kafka: https://unpocodejava.wordpress.com/2013/07/10/un-‐poco-‐mas-‐de-‐kafka-‐version-‐0-‐8/

HashiCorp. (2015). About Vagrant. Obtenido de Vagrant: https://www.vagrantup.com/about.html

HashiCorp. (2015). Vagrant Getting Started. Obtenido de vagrantup: https://www.vagrantup.com/docs/getting-‐started/

IBM. (2012). IBM. Obtenido de Analytics: el uso del big data en el mundo real: http://www-‐05.ibm.com/services/es/gbs/consulting/pdf/El_uso_de_Big_Data_en_el_mundo_real.pdf

Johansson, L. (18 de Mayo de 2015). Part 1: RabbitMQ for beginners -‐ What is RabbitMQ? Obtenido de CloudAMQP: https://www.cloudamqp.com/blog/2015-‐05-‐18-‐part1-‐rabbitmq-‐for-‐beginners-‐what-‐is-‐rabbitmq.html

58

Lo que me interesa de la red. (15 de julio de 2014). Apache Kafka, el sistema de mensajería distribuido de LinkedIn. Obtenido de Lo que me interesa de la red: https://loquemeinteresadelared.wordpress.com/2014/07/15/apache-‐kafka/

Pintor, M. (4 de 2 de 2015). Vagrant, la herramienta para crear entornos de desarrollo reproducibles. Obtenido de Conasa: http://www.conasa.es/blog/vagrant-‐la-‐herramienta-‐para-‐crear-‐entornos-‐de-‐desarrollo-‐reproducibles/

Pivotal. (2016). Features. Obtenido de RabbitMQ: https://www.rabbitmq.com/features.html

Pivotal. (2016). Get Started. Obtenido de RabbitMQ: https://www.rabbitmq.com/getstarted.html

Pulido, F. J. (2014). Paradigmas Big Data: La Arquitectura Lambda. Obtenido de Francisco Javier Pulido: http://www.franciscojavierpulido.com/2014/03/paradigmas-‐bigdata-‐la-‐arquitectura.html

RabbitMQ. (2016). AMQP 0-‐9-‐1 Model Explained. Obtenido de RabbitMQ: https://www.rabbitmq.com/tutorials/amqp-‐concepts.html

Requena, C. (5 de abril de 2010). Cassandra. Obtenido de nosql.es: http://www.nosql.es/blog/nosql/cassandra.html

Roy, J. (17 de agosto de 2014). MongoDB: Características y futuro. Obtenido de MongoDB Spain: http://www.mongodbspain.com/es/2014/08/17/mongodb-‐characteristics-‐future/

Ruiz García, E. (2015). Estudio y Evaluación de Sistemas “Big Data” de Tratamiento de Información. Obtenido de Estudio y Evaluación de Sistemas “Big Data” de Tratamiento de Información: http://oa.upm.es/37766/1/PFC_ENRIQUE_RUIZ_GARCIA_2015.pdf

Vecino Rosado, M. (22 de enero de 2015). ¿Cassandra? ¿Qué es? Obtenido de SlideShare: http://es.slideshare.net/planetcassandra/cassandra-‐qu-‐es-‐de-‐0-‐a-‐100-‐con-‐apache-‐cassandra

Wiesel, J. (4 de marzo de 2014). Codehero. Obtenido de Como utilizar colas de mensajes con RabbitMQ parte 1: http://codehero.co/como-‐utilizar-‐colas-‐de-‐mensajes-‐con-‐rabbitmq-‐parte/

Wikipedia. (2015). RabbitMQ. Obtenido de Wikipedia: https://es.wikipedia.org/wiki/RabbitMQ

Wikipedia. (28 de junio de 2016). Apache Cassandra. Obtenido de Wikipedia: https://es.wikipedia.org/wiki/Apache_Cassandra

Wikipedia. (15 de mayo de 2016). MongoDB. Obtenido de Wikipedia: https://es.wikipedia.org/wiki/MongoDB

Estudio y Mejora del Rendimiento del Backend...Apache Storm y Apache Spark Streaming. Capa de...

Documents

Transcript of Estudio y Mejora del Rendimiento del Backend...Apache Storm y Apache Spark Streaming. Capa de...