Estudio y mejora del rendimiento del backend MOLLA SIRVENT RAFAEL ALEJANDRO
Anuncio
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
