Estudio y Mejora del Rendimiento del Backend - TFG

 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
Í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 1 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.
2 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
3 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.
4 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.
5 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.
6 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 7 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. 8 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.
9 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.
10 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.
11 • 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.
12 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.
13 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.
14 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.
15 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.
16 • 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.
17 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.
18 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.
19 • 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.
20 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
21 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 clavevalor 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
22 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.
23 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.
24 • 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.
25 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 26 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 27 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 28 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 29 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 30 Ilustración 10 – Definición de Apache Storm en Vagrant Scripts de Configuración
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 31 storm.sh
Ilustración 13 – Script storm.sh upstarNimbus.sh
Ilustración 14 – Script upstarNimbus.sh 32 upstarSupervisor.sh
Ilustración 15 – Script upstarSupervisor.sh upstarUI.sh
Ilustración 16 –Script upstarUI.sh 33 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 34 Ilustración 18 -­‐ Definición de Cassandra en Vagrant Scripts de Configuración
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 35 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 36 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”.
Ilustración 22 – Configuración del cluster de Cassandra 2 En el apartado “Node Properties” se añaden las IPs de los tres nodos esclavos. Al finalizar
hacer click en “Add Datacenter”.
Ilustración 23 – Configuración del cluster de Cassandra 3 37 Hacer click en “Build Cluster”.
Ilustración 24 – Configuración del cluster de Cassandra 4 Hacer click en “Accept Fingerprints”.
Ilustración 25 – Configuración del cluster de Cassandra 5 38 Con los anteriores pasos realizados comenzará la construcción del cluster, instalado los
paquetes necesarios en los nodos esclavos.
Ilustración 26 – Configuración del cluster de Cassandra 6 Cuando haya terminado ya se podrá empezar a utilizar el cluster.
Ilustración 27 – Configuración del cluster de Cassandra 7 39 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 40 Ilustración 29 – Clase SimpleProducer MainSimpleProducer: se utiliza para enviar mensajes al cluster de RabbitMQ.
Ilustración 30 – Clase MainSimpleProducer 41 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 42 Ilustración 33 – Clase RabbitMQSpout RawBoltCassandra: definición del comportamiento del Bolt de Apache Storm.
Ilustración 34 – Clase RawBoltCassandra 43 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 44 Ilustración 37 – Clase SimpleClient 45 Ilustración 38 – Clase SimpleClient 46 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 47 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 48 Ilustración 44 – pom.xml 49 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 50 Ilustración 47 – Interfaz Gráfica de Apache Storm Ilustración 48 – Interfaz gráfica de Cassandra (Opscenter) 51 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 52 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 53 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 54 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 55 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.
56 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 57 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 58