universidad central del ecuador facultad de ......propuesta de una arquitectura distribuida...
TRANSCRIPT
UNIVERSIDAD CENTRAL DEL ECUADOR
FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA
CARRERA DE INGENIERÍA INFORMÁTICA
Propuesta de una arquitectura distribuida altamente escalable para minería de datos en tiempo real en redes sociales.
Trabajo de titulación, Modalidad Proyecto de Investigación previo a la obtención del título
de Ingeniero Informático.
AUTORES: Correa Panchi Darwin Alejandro
Cuji Tibán Edgar Alexander
TUTOR: Ing. Mario Raúl Morales Morales
Quito, 2018
ii
DERECHOS DE AUTOR
Nosotros, Darwin Alejandro Correa Panchi y Edgar Alexander Cuji Tibán en calidad de
autores y titulares de los derechos morales y patrimoniales del trabajo de titulación
Propuesta de una arquitectura distribuida altamente escalable para minería de datos
en tiempo real en redes sociales, modalidad proyecto de investigación, de conformidad
con el Art. 114 del CÓDIGO ORGÁNICO DE LA ECONOMÍA SOCIAL DE LOS
CONOCIMIENTOS, CREATIVIDAD E INNOVACIÓN, concedemos a favor de la
Universidad Central del Ecuador una licencia gratuita, intransferible y no exclusiva para el
uso no comercial de la obra, con fines estrictamente académicos. Conservamos nuestro
favor todos los derechos de autor sobre la obra, establecidos en la normativa citada.
Así mismo, autorizamos a la Universidad Central del Ecuador para que realice la
digitalización y publicación de este trabajo de titulación en el repositorio virtual, de
conformidad a lo dispuesto en el Art. 144 de la Ley Orgánica de Educación Superior.
Los autores declaran que la obra objeto de la presente autorización es original en su forma
de expresión y no infringe el derecho de autor de terceros, asumiendo la responsabilidad
por cualquier reclamación que pudiera presentarse por esta causa y liberando a la
Universidad de toda responsabilidad.
Firma: ____________________ Firma: ____________________
Correa Panchi Darwin Alejandro Edgar Alexander Cuji Tibán
CC. 1722590948 CC. 1723510291
iii
APROBACIÓN DEL TUTOR
En mi calidad de Tutor del Trabajo de Titulación, presentado por DARWIN ALEJANDRO
CORREA PANCHI Y EDGAR ALEXANDER CUJI TIBÁN, para optar por el Grado de
Ingeniero en Informática; cuyo título es: PROPUESTA DE UNA ARQUITECTURA
DISTRIBUIDA ALTAMENTE ESCALABLE PARA MINERIA DE DATOS EN TIEMPO
REAL EN REDES SOCIALES, considero que dicho trabajo reúne los requisitos y méritos
suficientes para ser sometido a la presentación pública y evaluación por parte del tribunal
examinador que se designe
En la ciudad de Quito, a los 25 días del mes Junio del 2018.
_________________________
Ing. Mario Raúl Morales Morales
DOCENTE-TUTOR
CC. 1709026577
iv
CONTENIDO
pág.
DERECHOS DE AUTOR .................................................................................................... ii
APROBACIÓN DEL TUTOR .............................................................................................. iii
CONTENIDO ..................................................................................................................... iv
LISTA DE TABLAS .......................................................................................................... viii
LISTA DE FIGURAS .......................................................................................................... ix
RESUMEN ......................................................................................................................... xi
ABSTRACT ...................................................................................................................... xii
INTRODUCCIÓN ............................................................................................................... 1
1. ANÁLISIS DEL PROBLEMA ....................................................................................... 2
1.1. Antecedentes ....................................................................................................... 2
1.2. Planteamiento del problema ................................................................................ 3
2. HIPÓTESIS Y JUSTIFICACIÓN ................................................................................. 4
2.1. Hipótesis .............................................................................................................. 4
2.2. Justificación ......................................................................................................... 4
3. OBJETIVOS ............................................................................................................... 6
3.1. Objetivo general .................................................................................................. 6
3.2. Objetivos específicos ........................................................................................... 6
4. MARCO TEÓRICO ..................................................................................................... 7
Arquitectura de software ................................................................................................. 7
Proceso para el desarrollo de Arquitecturas de Software PASWDFSS ........................... 7
Arquitecturas monolíticas ................................................................................................ 8
v
Microservicios ................................................................................................................. 9
Escalabilidad ................................................................................................................. 11
Modularidad .................................................................................................................. 12
Disponibilidad ................................................................................................................ 12
Procesamiento paralelo ................................................................................................ 12
Procesamiento distribuido ............................................................................................. 13
Procesamiento en Streaming (Streaming processing) ................................................... 13
Concurrencia ................................................................................................................. 14
Tiempo de respuesta .................................................................................................... 14
Entrega Continua de Software (Continuous Delivery) ................................................... 15
Despliegue contino de software (Continuous Deployment) ........................................... 15
Sistemas en tiempo real (Real Time Systems) .............................................................. 15
Tiempo de inactividad durante despliegue (Downtime Deployment) ............................. 17
Escalamiento Vertical .................................................................................................... 17
Escalamiento Horizontal................................................................................................ 17
Red social ..................................................................................................................... 18
Plataformas sociales ..................................................................................................... 18
Big data ......................................................................................................................... 19
Análisis de redes sociales (Social Network Analysis) .................................................... 21
Minería de Datos (Data Mining)..................................................................................... 22
Enriquecimiento de datos .............................................................................................. 22
Procesamiento del lenguaje natural (PLN) .................................................................... 22
Aprendizaje automático (Machine Learning) ................................................................. 23
Web scraping ................................................................................................................ 23
Web sockets ................................................................................................................. 24
5. METODOLOGÍA EXPERIMENTAL ........................................................................... 25
5.1. Tipo de Investigación ......................................................................................... 25
6. CÁLCULOS Y RESULTADOS .................................................................................. 27
6.1. Identificación de requerimientos de la arquitectura ............................................ 27
6.1.1. Requerimientos funcionales ........................................................................ 27
6.1.2. Requerimientos no funcionales ................................................................... 30
6.2. Caracterización del diseño de la Arquitectura .................................................... 32
vi
6.2.1. Módulo de configuración .................................................................................... 32
6.2.2. Módulo de descarga .......................................................................................... 33
6.2.3. Orquestador de eventos de descarga ................................................................ 34
6.2.4. Módulo de enriquecimiento y almacenamiento .................................................. 36
6.2.5. Motor de búsqueda ............................................................................................ 38
6.2.6. Módulo de alertas .............................................................................................. 39
6.2.7. Motor de analítica .............................................................................................. 40
6.2.8. Cliente web ........................................................................................................ 41
6.2.9. Módulo de reportes ............................................................................................ 42
6.3. Documentación de la Arquitectura ..................................................................... 43
6.3.1. Diagrama de flujo de la arquitectura ........................................................... 46
6.3.2. Diagrama de flujo del motor de búsqueda de datos .................................... 47
6.4. Optimización del diseño de la Arquitectura ........................................................ 47
6.4.1. Motor de procesamiento ............................................................................. 47
6.4.2. Módulo de reportes ..................................................................................... 48
6.4.3. Motor de analítica ....................................................................................... 48
6.5. Validación del diseño de la Arquitectura ............................................................ 51
6.5.1. Implementación .......................................................................................... 51
6.5.2. Pruebas ...................................................................................................... 51
6.5.3. Desarrollo del experimento ......................................................................... 52
6.5.3.1. Arquitectura monolítica:........................................................................... 53
6.5.3.2. Sistema Distribuido: ................................................................................ 55
7. DISCUSIÓN .............................................................................................................. 66
8. CONCLUSIONES ..................................................................................................... 69
9. RECOMENDACIONES ............................................................................................. 70
10. BIBLIOGRAFÍA ......................................................................................................... 72
vii
viii
LISTA DE TABLAS
pág.
Tabla 1 Clasificación de sistemas en tiempo real ........................................................ 16
Tabla 2. Requerimientos funcionales del sistema que debe soportar la arquitectura D10X
................................................................................................................................... 27
Tabla 3. Requerimientos no funcionales del sistema que debe soportar la arquitectura D10X
................................................................................................................................... 31
Tabla 4. Consumo de RAM (Sistema distribuido, Caso 1)........................................... 55
Tabla 5. Consumo de CPU (Sistema distribuido, Caso 1). .......................................... 57
Tabla 6. Tweets procesados incrementalmente por minuto (Sistema distribuido, Caso 1).
................................................................................................................................... 59
Tabla 7. Consumo de RAM (Sistema distribuido, Caso 2)........................................... 60
Tabla 8. Consumo de CPU (Sistema distribuido, Caso 2). .......................................... 62
Tabla 9. Tiempo de procesamiento (Sistema distribuido, Caso 2)............................... 64
Tabla 10. Tiempo en iniciar servicios .......................................................................... 65
ix
LISTA DE FIGURAS
pág.
Figura 1. Usuarios Activos en Internet .......................................................................... 5
Figura 2. Proceso de desarrollo de arquitecturas de software basado en DFSS ........... 8
Figura 3. Arquitectura monolítica. ................................................................................. 9
Figura 4. Arquitectura basada en microservicios ......................................................... 10
Figura 5. Procesamiento en paralelo .......................................................................... 13
Figura 6. Esquema de procesamiento en tiempo real ................................................. 16
Figura 7. Social Media Ecosystem. ............................................................................. 19
Figura 8. ¿Qué sucede en internet durante 60 segundos? ......................................... 21
Figura 9. Websockets, una representación visual ....................................................... 25
Figura 10. Ejemplo de consulta sobre Plataformas sociales usando conectores lógicos.30
Figura 11. Módulo de descarga .................................................................................. 33
Figura 12. Módulo enriquecimiento de datos .............................................................. 36
Figura 13. Módulo de enriquecimiento de datos .......................................................... 37
Figura 14. Módulo de alertas ...................................................................................... 39
Figura 15. Motor de analítica ...................................................................................... 40
Figura 16. Diagrama Arquitectura D10X ..................................................................... 43
Figura 17. Diagrama de flujo de descarga de datos .................................................... 46
Figura 18. Diagrama de flujo del motor de búsqueda de datos ................................... 47
Figura 19. Motor de analítica ...................................................................................... 49
Figura 20. Diagrama Arquitectura D10X optimizada ................................................... 50
Figura 21. Arquitectura monolítica para procesamiento de datos en redes sociales. .. 52
Figura 22. Uso de CPU sistema monolítico. ................................................................ 54
Figura 23. Uso RAM arquitectura monolítico. .............................................................. 54
x
Figura 24. Consumo de RAM, gestor de descarga (Sistema distribuido, Caso 1). ...... 55
Figura 25. Consumo de RAM, servidor de colas (Sistema distribuido, Caso 1). .......... 56
Figura 26. Consumo de RAM, motor de procesamiento (Sistema distribuido, Caso 1).56
Figura 27. Consumo de CPU, gestor de descarga y productor (Sistema distribuido, Caso 1).
................................................................................................................................... 57
Figura 28. Consumo de CPU, servidor de colas (Sistema distribuido, Caso 1). .......... 58
Figura 29. Consumo de CPU, motor de procesamiento (Sistema distribuido, Caso 1).58
Figura 30. Total, tweets procesados ........................................................................... 59
Figura 31. Consumo de RAM, gestor de descarga y productor (Sistema distribuido, Caso
2). ............................................................................................................................... 60
Figura 32. Consumo de RAM, servidor de colas (Sistema distribuido, Caso 2). .......... 61
Figura 33. Consumo de RAM, motor de procesamiento (Sistema distribuido, Caso 2).61
Figura 34. Consumo de CPU, gestor de descarga y productor (Sistema distribuido, Caso 2).
................................................................................................................................... 62
Figura 35. Consumo de CPU, servidor de colas (Sistema distribuido, Caso 2). .......... 63
Figura 36. Consumo de CPU, motor de procesamiento (Sistema distribuido, Caso 2).63
Figura 37. Total de documentos procesados. ............................................................. 64
xi
TITULO: Propuesta de una arquitectura distribuida altamente Escalable para minería de
datos en tiempo real en redes sociales.
Autores: Correa Panchi Darwin Alejandro
Cuji Tibán Edgar Alexander
Tutor: Ing. Mario Raúl Morales Morales
RESUMEN
En este estudio se propone una arquitectura denominada D10X altamente escalable
basada en microservicios capaz de procesar grandes cantidades de datos procedentes de
las redes sociales en tiempo real de forma distribuida y paralela. Se identifica los principales
problemas para cada requerimiento desde la obtención de los datos, su limpieza,
enriquecimiento y procesamiento hasta la consulta en tiempo real por parte del usuario final.
Se realiza el diseño de la arquitectura basándose en el estado del arte de patrones
arquitectónicos, y en base al diseño establecido se construye prototipos ejecutables para
colectar métricas de los recursos utilizados con los cuales se comprueba que la arquitectura
D10X planteada garantiza una mayor disponibilidad, tolerancia a fallos, y es fácilmente
escalable de forma autónoma mediante el uso de orquestadores, para un mejor
aprovechamiento de los recursos.
PALABRAS CLAVE: / BIG DATA/ TIEMPO REAL/ MICROSERVICIOS/
PROCESAMIENTO DISTRIBUIDO/ ESCALABILIDAD/ ORQUESTAMIENTO/ REDES
SOCIALES
xii
TITLE: Proposal of highly scalable distributed architecture for real-time data mining in social
networks.
Authors: Correa Panchi Darwin Alejandro
Cuji Tibán Edgar Alexander
Tutor: Ing. Mario Raúl Morales Morales
ABSTRACT
This study offers a highly scalable architecture called D10X based on microservices to
process large amounts of data come from social networks in real time in a distributed and
parallel manner. The main problems for each requirement were identified, from the getting
of the data, cleaning, enrichment and processing to the query in real time by the end user.
The design of the architecture was based on the state of the art of architectural patterns, to
build executable prototypes to collect metrics about the resources used, with which it was
possible to verify that the proposed D10X architecture guarantees greater availability,
tolerance to failures, and is easily scalable in an autonomous way using orchestrators, for a
efficient use of resources.
KEYWORDS: / BIG DATA/ REAL TIME/ MICROSERVICES/ DISTRIBUTED COMPUTING/
SCALABILITY/ ORCHESTRATION
1
INTRODUCCIÓN
El uso de grandes dataset, se han vuelto común en todo tipo de estudios desde
microrganismos hasta el estudio del mismo universo, incluido, de manera importante, el
comportamiento humano. Es las ciencias como la astronomía y genómica, que experimentó
un auge en el 2000, acuñó el término “Big Data” cuyo concepto ahora está migrando a todas
las áreas de esfuerzo humano. Un hecho incuestionable es la gran cantidad de datos que
se genera a cada segundo en nuestro planeta de modo espectacular, puede ser
estructurada, semiestructurada o no estructurada. Solo hasta el 2012, se generaron 2.8
zettabytes (ZB) de datos (1 ZB=1 billón de gigabytes) y lo que es más asombroso aún es
que esa cifra se dobla cada dos años (IDC, 2012).
La captura y el análisis inteligente (y la mayoría de las veces en tiempo real) de este tipo
de información está empezando a ser un requisito incuestionable para la supervivencia de
muchas organizaciones y empresas ya que proporciona una gran ventaja competitiva.
Por otra parte, para las empresas, las redes sociales se han convertido en herramientas
muy importantes para sus negocios. Son utilizados como mecanismos de relación con sus
clientes actuales o futuros, y de gran utilidad para la difusión y venta de sus productos o
servicios. (Kempe & Kleinberg, 2003)
Tomando como premisa el estado actual del conocimiento, el presente trabajo propone una
arquitectura de procesamiento distribuido que integre un conjunto de herramientas que nos
permitan analizar en tiempo real redes sociales en busca de métricas y estadísticas que
generen un valor agregado y sean de apoyo en la toma de decisiones de las organizaciones.
En la investigación se realizó experimentos basados en prototipos con el fin de obtener
métricas que permitan validar la superioridad de la arquitectura propuesta (D10X) frente a
las arquitecturas monolíticas. En este estudio no se contempla la implementación completa
de la arquitectura ni paso a producción.
2
1. ANÁLISIS DEL PROBLEMA
1.1. Antecedentes
En el estudio “Análisis de la digitalización de los autónomos y PYMES en España 2016”
realizado por Vodafone España, el 74% de las empresas participantes, utilizan las redes
sociales para sus actividades diarias y la relación con sus clientes. Sin embargo, las redes
sociales son utilizadas únicamente como un simple medio de comunicación y no
aprovechan los beneficios de la analítica como ventaja competitiva (Vodafone, 2016).
Las redes sociales brindan una gran cantidad de beneficios al comercio y las sociedades
ya que permiten crear nuevas relaciones y vínculos entre usuarios, consumidores y
potenciales clientes. Numerosas organizaciones han encontrado en las redes sociales una
herramienta de comunicación bidireccional, donde se inician conversaciones, se generan
debates y se puede atender o responder a las preguntas y necesidades de quienes
pretenden conocer mejor el negocio o servicios que ofertan.
Un buen marketing es consecuencia directa de una buena recolección y análisis de datos
para tomar decisiones inteligentes e identificar de manera oportuna el éxito o fracaso en
social media. Los análisis basados en KPIs, se ha vuelto un desafío en los últimos años
debido a que no se cuenta con herramientas apropiadas que proporcionen a las empresas
una visión de lo que realmente pasa en su entorno en tiempo real (Kempe & Kleinberg,
2003).
Métricas como audiencia, interacciones e identificación de influencer1 ha dejado de ser
objeto de investigación y ha tomado fuerza en el sector empresarial.
1 Un perfil con una notoriedad y audiencia elevada sobre un tema concreto en las redes sociales
3
1.2. Planteamiento del problema
En la actualidad, el costo del hardware se ha reducido considerablemente. Esto conlleva a
una tendencia en que las empresas con el fin de garantizar escalabilidad y alta
disponibilidad no consideran como crítico el uso eficiente de los recursos que permitan
procesar eficientemente estos grandes dataset.
Dado la naturaleza informal, cambiante y poco estructurada de los datos de las redes
sociales y las limitaciones de las API’s para la extracción de datos, es necesario tener una
arquitectura que permita actualizar inmediatamente los cambios necesarios sin afectar el
resto del sistema.
Otro factor importante es que no se puede determinar la cantidad de datos a descargar y
procesar, pues depende de la actividad de las redes sociales, por tanto, la arquitectura debe
permitir el escalamiento automático necesario para manejar esa cantidad de datos en
tiempo real, realizando un uso eficiente de los recursos.
Los datos extraídos de estas fuentes son muy pobres en el sentido de información relevante
sobre quienes publican en las redes sociales. Además, el uso de reglas gramaticales y
ortográficas son poco frecuentes en los usuarios de las plataformas sociales por esta razón,
la arquitectura debe soportar un procesamiento de lenguaje natural en tiempo real, para
enriquecerlos con datos como género, polaridad, localización, edad, etc.
4
2. HIPÓTESIS Y JUSTIFICACIÓN
2.1. Hipótesis
La arquitectura de software D10X permite una mejor eficiencia y escalabilidad para el
procesamiento de datos en redes sociales frente a las arquitecturas monolíticas.
2.2. Justificación
Las nuevas tecnologías y las plataformas sociales han cambiado la forma en la que las
empresas piensan, se relacionan e interactúan con sus clientes ya que permiten una
comunicación rápida, eficiente y efectiva. A esto se le suma el costo mucho menor de utilizar
redes sociales comparados con los medios tradicionales como radio y televisión para
promocionar una marca, producto o persona.
Según (Newberry, 2018), las organizaciones que no aprovechen los beneficios que brindan
las redes sociales, se están perdiendo una forma rápida, económica y efectiva de llegar a
casi la mitad de la población mundial que son los usuarios activos en internet.
5
Figura 1. Usuarios Activos en Internet
Fuente: (Newberry, 2018)
En la actualidad la analítica del contenido de las redes sociales (reacciones e interacciones),
se ha convertido en la nueva moneda de los negocios en el mundo, ya que les permite a
las organizaciones en general transformar los datos en información, información en
conocimiento y el conocimiento en oportunidades.
Hay varias ventajas y desventajas a la hora de realizar analítica en redes sociales. Una de
las ventajas es que una analítica bien hecha puede mejorar los resultados de las estrategias
digitales y algunas de las desventajas es que por la gran cantidad de datos que se tienen
que analizar, estas métricas pueden estar desactualizadas o simplemente no pueden dar
una visión global de lo que realmente pasa en su entorno en ese preciso instante. Por tal
motivo el presente trabajo propone una arquitectura de software que de origen a una
plataforma que soporte el análisis de dichos datos en tiempo real. Además, considere
requerimientos no funcionales como escalabilidad, confiabilidad, eficiencia y permita a las
industrias navegar fácilmente a través de enormes espacios de búsqueda, interpretar
resultados intermedios y entender patrones de descubrimiento a través del enriquecimiento
de datos.
6
3. OBJETIVOS
3.1. Objetivo general
Proponer una arquitectura de software altamente escalable para análisis de datos en tiempo
real en redes sociales.
3.2. Objetivos específicos
• Verificar que la arquitectura D10X en contraste a las monolíticas permite una mejor
disponibilidad del sistema.
• Comprobar que la arquitectura planteada permite una mejor escalabilidad y
rendimiento frente a arquitecturas monolíticas.
7
4. MARCO TEÓRICO
Dado que la mira de este estudio está puesta en la construcción de una arquitectura de
software para procesamiento de datos, es necesario aclarar algunos conceptos que faciliten
la lectura interpretativa del mismo.
Arquitectura de software
Desde los inicios de la informática, la programación se ha considerado como un arte y se
desarrollaba como tal, debido a la complejidad con la que la encontraban la mayoría de las
personas. Con el pasar de los tiempos, se han ido desarrollando y descubriendo guías
generales con las que se pueden resolver problemas frecuentes en la escritura de software.
A esta manera de realizar las cosas se la ha denominado Arquitectura de Software, puesto
que éstas nos indican la estructura, diseño, especificación, funcionamiento e interacción
entre las piezas de software de una manera global (Grady, 1998).
Una adecuada arquitectura es una parte fundamental para alcanzar requerimientos
funcionales como no funcionales de un sistema. Por el contrario, una arquitectura de
software mal diseñada puede ocasionar resultados desastrosos. Una descripción más
explícita de arquitectura de software se la puede encontrar en definición de (Bass, Clemens,
& Kazman, 2013) quienes indican que: “Una arquitectura de software de un programa o un
sistema computacional es la estructura del sistema, la cual comprende elementos de
software, las propiedades externamente visibles de esos elementos, y las relaciones entre
ellos”.
Proceso para el desarrollo de Arquitecturas de Software PASWDFSS
Es un proceso de arquitecturas de software que permite crear una arquitectura nueva, a
partir de los requerimientos arquitectónicos de la misma. (Núñez Mora, 2006)
Los pasos que contiene el proceso son:
• Identificación de requerimientos de la Arquitectura.
8
• Caracterización del diseño de la Arquitectura.
• Documentación de la Arquitectura.
• Optimizar el diseño de la Arquitectura.
• Validación del diseño de la Arquitectura.
Figura 2. Proceso de desarrollo de arquitecturas de software basado en DFSS
Fuente. (Núñez Mora, 2006)
Arquitecturas monolíticas
Una aplicación monolítica es aquella que puede interactuar con otros servicios o almacenes
de datos en el transcurso de sus operaciones, pero como se puede ver en la figura 3 el
núcleo de su comportamiento se ejecuta dentro de su propio proceso y toda la aplicación
9
normalmente se implementa como una única unidad. Cuando es necesario escalar
horizontalmente normalmente la aplicación completa se duplica en varios servidores o
máquinas virtuales. Aunque es simple, la solución monolítica de un solo proyecto tiene
algunas desventajas ya que a medida que aumenta el tamaño y la complejidad del proyecto,
el número de archivos y carpetas también seguirá creciendo y existirán procesos
ejecutándose sin ser necesarios. (Microsoft, Arquitecturas de aplicaciones web comunes,
2017)
Figura 3. Arquitectura monolítica.
Fuente: (Microsoft, Arquitecturas de aplicaciones web comunes, 2017)
Microservicios
Durante muchos años, el enfoque tradicional para el desarrollo de software fue el monolito,
donde todas las partes de la aplicación se construían en una única pieza de software. Esta
manera de construir aplicaciones tiene varias limitantes ya que cada vez resulta más difícil
solucionar problemas y agregar nuevas funcionalidades. Los microservicios a diferencia de
las arquitecturas monolíticas son un estilo de arquitectura orientados a lograr un alto grado
de agilidad, velocidad de entrega y escalabilidad de software, ya que
permiten dividir funcionalmente aplicaciones monolíticas en unidades atómicas más
pequeñas cada una de las cuales realiza una función única. Organizaciones como Netflix,
10
Amazon y eBay ya usan microservicios ya que brindan una manera de construir software
modular físicamente separado (RV, 2016).
Figura 4. Arquitectura basada en microservicios
Fuente: (RV, 2016)
Características
Según (Jung, Möllering, Dalbhanjan, Chapman, & Kassen, 2016) algunas de las
características comunes que comparten las arquitecturas basadas en microservicios son:
• Descentralizado: Las arquitecturas de microservicios son sistemas distribuidos con
administración descentralizada de datos. No se basan en un esquema unificado de
base de datos central ya que cada microservicio tiene su propia vista en modelos
de datos. Los microservicios también están descentralizados en la forma en que se
desarrollan, implementan, administran y operan.
• Independiente: Los diferentes componentes en una arquitectura de microservicios
se pueden cambiar, actualizar o reemplazar de forma independiente sin afectar el
11
funcionamiento de otros componentes. Del mismo modo, los equipos responsables
de diferentes microservicios pueden actuar de forma independiente.
• Centrado en una funcionalidad específica: Cada microservicio es un componente
que está diseñado para cumplir un conjunto de capacidades y se centra en un
dominio específico del problema.
• Políglota Las arquitecturas de microservicios adoptan un enfoque heterogéneo para
resolver sus problemas específicos, es decir, los equipos de desarrollo tienen la
libertad de elegir la mejor herramienta (lenguaje de programación, sistema
operativo, bases de datos, etc.) que se adapte a sus necesidades.
• Caja negra: Los microservicios están diseñados como cajas negras, es decir,
ocultan los detalles de su complejidad de otros componentes. Cualquier
comunicación entre servicios se realiza a través de un API bien definido para evitar
dependencias implícitas y ocultas.
• Usted lo construye; usted lo ejecuta: Por lo general, el equipo responsable de la
creación de un servicio también es responsable de operarlo y mantenerlo en
producción. Este principio también se conoce como DevOps; que también ayuda a
los desarrolladores a tener un contacto cercano con los usuarios reales del software
y mejora la comprensión de las necesidades y expectativas de éstos.
Escalabilidad
Como lo señala (Atchison, 2016), definir una arquitectura como escalable va más allá que
construir una aplicación que maneje enormes cantidades de usuarios al mismo tiempo, hay
muchas cosas involucradas en hacer una aplicación escalable.
• Manejar una cantidad grande y creciente de datos utilizados por los usuarios.
• Manejar una complejidad creciente de funcionalidades que los usuarios necesiten.
• Permitir que más desarrolladores se integren al trabajo según las necesidades de la
compañía ya que se expanden sin sacrificar velocidad, eficiencia o calidad de la
aplicación.
• Debe mantener su aplicación en línea y funcionando, incluso mientras se
implementan todos los cambios y mejoras mencionados.
12
Modularidad
Consiste en dividir un programa en módulos que pueden ser desarrollados, compilados y
desplegados de forma separada pero que tienen conexiones con otros módulos (Bárbara,
1972).
Disponibilidad
La alta disponibilidad es el componente más crítico para construir sistemas altamente
escalables, Atchison la define como la capacidad de un sistema para ser operativo cuando
es necesario realizar las tareas para las cuales fue construido cuando se lo solicita, no antes
ni después. ¿Lo hace? ¿Es operacional? ¿Está respondiendo correctamente? Si la
respuesta a estas preguntas es sí, entonces es un sistema disponible (Atchison, 2016).
“A nadie le importa si un sistema tiene unas excelentes características si no pueden usarlo”
(Atchison, 2016) en su libro “Architecting for Scale”.
Procesamiento paralelo
Su objetivo es conseguir un cálculo particular lo más rápido posible, explotando múltiples
procesadores. En el lado de los modelos de computación, cuyo esquema se representa en
la figura 5, el paralelismo generalmente consiste en usar múltiples hilos simultáneos de
computación internamente para calcular un resultado final. El paralelismo también se usa a
veces para sistemas reactivos en tiempo real, que contienen muchos procesadores que
comparten un único reloj maestro; tales sistemas son completamente deterministas.
(StipczyNski, 2006)
13
Figura 5. Procesamiento en paralelo
Fuente: Propia
Procesamiento distribuido
El procesamiento distribuido de datos es una técnica de red de computadoras en el que
varias computadoras en distintos lugares comparten su capacidad de procesamiento.
Mientras que los modelos de procesamiento en paralelo a menudo (pero no siempre)
asumen la memoria compartida, los sistemas distribuidos se basan fundamentalmente en
el paso de mensajes. Los sistemas distribuidos son intrínsecamente concurrentes. En
general podemos decir que procesamiento distribuido es un subconjunto de Computación
en paralelo; a su vez, computación en paralelo es un subconjunto de Computación
concurrente. La concurrencia se denomina paralela cuando los procesos (o hilos) son
ejecutados en diferentes núcleos del mismo CPU o distintos CPU, pero en la misma
máquina, mientras que denominamos distribuida cuando los distintos CPU que forman parte
del cálculo están geográficamente separados conectadas mediante redes de transferencia
de mensajes. (StipczyNski, 2006)
Procesamiento en Streaming (Streaming processing)
Los sistemas que manejan datos como un flujo continuo de forma infinita se denominan
sistemas de streaming o sistemas de procesamiento online. El procesamiento de datos en
streaming surge de la necesidad de algunas aplicaciones de procesar datos como un flujo
14
continuo de información en vez de hacerlo sobre datos almacenados de forma estática. Con
esta forma de tratar los datos, es posible conseguir tiempo de respuesta muy bajos o incluso
en tiempo real y un análisis eficiente. (Fernández del Corral, 2007)
Según (Amazon, 2018) entre algunas aplicaciones de los sistemas de procesamiento en
streaming están:
• Sensores de vehículos de transporte, equipo industrial y la maquinaria agrícola que
envían datos todo el tiempo.
• Una institución financiera que controla los cambios en la bolsa de valores en tiempo
real procesa el valor en riesgo y modifica las carteras automáticamente en función
de los cambios en los precios de las acciones.
• Un sitio web inmobiliario que realiza recomendaciones en tiempo real acerca de los
inmuebles que deben visitar en función de su ubicación geográfica.
• Una compañía de energía solar que mantiene constante el suministro de electricidad
a sus clientes, ya que si no lo hace se la sanciona.
• Una compañía de juegos en línea que recopila datos acerca de las interacciones de
los jugadores con el juego y los envía a su plataforma.
Concurrencia
La concurrencia se refiere a la existencia de múltiples hilos de ejecución donde cada uno
puede obtener un instante de tiempo antes de ser reemplazado por otro hilo que también
recibe un instante de tiempo. La concurrencia es necesaria para que un programa reaccione
ante estímulos externos (eventos), como la entrada del usuario, los dispositivos y los
sensores. Incluso con un solo núcleo se puede simular concurrencia. (Microsoft
Corporation, 2017).
Tiempo de respuesta
Es el tiempo que toma un sistema o unidad funcional para reaccionar a una entrada dada.
(Oracle Corporation, 2013)
15
Entrega Continua de Software (Continuous Delivery)
La entrega continua es un conjunto de principios generales de ingeniería de software que
permite entregas frecuentes de nuevo software mediante el uso de pruebas automatizadas
e integración continua y se asegura de que los nuevos cambios pueden ser implementados.
(Daniels, 2016)
Despliegue contino de software (Continuous Deployment)
La implementación continua (también conocida como CD) es el proceso de implementación
de cambios a un ambiente de producción mediante la definición de pruebas y validaciones
para minimizar el riesgo. Mientras que el Continuous Delivery se asegura que se puedan
implementar nuevos cambios, el Continuous Deployment implementa el software en
producción automáticamente. (Daniels, 2016)
Sistemas en tiempo real (Real Time Systems)
Se denominan sistemas de procesamiento en tiempo real cuando dicho sistema recopila y
procesa los datos tan pronto como son obtenidos. Son clasificados como hard, soft y near
que se pueden diferenciar de acuerdo con (Psaltis, 2017).
16
Tabla 1 Clasificación de sistemas en tiempo real
Clasificación Ejemplo Latencia Tolerancia
Hard marcapasos Microsegundos-
milisegundos
Ninguna, riego
de vida
Soft VoIP, sistemas de
reservas
Milisegundos -
segundos
Bajo, no vidas
en riesgo
Near Smart Home Segundos-minutos
Alto, no falla el
sistema, no
hay vida en
riesgo
Fuente. (Psaltis, 2017)
En la figura 6 se puede apreciar un ejemplo de esquema de procesamiento en tiempo real,
que según la tabla 1 puede considerarse como Soft o Near Real Time.
Figura 6. Esquema de procesamiento en tiempo real
Fuente: (Psaltis, 2017)
17
Tiempo de inactividad durante despliegue (Downtime Deployment)
Basado en (Jennifer Davis, 2016) y (RV, 2016) el despliegue de una nueva versión,
resultado de la corrección de un bug, o una nueva característica dependiendo de la
naturaleza de los cambios y la arquitectura del sistema, puede afectar la disponibilidad del
sistema con un rendimiento degradado o la completa indisponibilidad del sistema hasta que
los cambios sean completados.
Escalamiento Vertical
Escalamiento verticalmente (o escala arriba) consiste en agregar recursos a los nodos del
clúster, típicamente involucrando la adición de procesadores (o núcleos), memoria o discos
(Garcia & Garcia, 2008).
Ventajas:
• No implica un gran problema para las aplicaciones, pues todo el cambio es sobre el
hardware.
• Es mucho más fácil de implementar que el escalamiento horizontal.
• Puede ser una solución rápida y económica (comparada con modificar el software).
Desventajas:
• El crecimiento está limitado por el hardware.
• Una falla en el servidor implica que la aplicación se detenga.
• No soporta la Alta disponibilidad.
• Configurar el hardware al máximo puede llegar a ser muy costoso.
Escalamiento Horizontal
Implica tener varios servidores (nodos) trabajando conjuntamente en red (clúster) con el
objetivo de repartirse el trabajo entre todos nodos del clúster, cuando la carga de trabajo
aumenta se añaden nuevos nodos al clúster según sea necesario. (Garcia & Garcia, 2008)
Ventajas:
• El crecimiento es prácticamente infinito, podríamos agregar cuantos servidores sean
necesarios
• Es posible combinarse con el escalamiento vertical.
18
• Soporta la alta disponibilidad
• Si un nodo falla, los demás sigue trabajando.
• Soporta el balanceo de cargas.
Desventajas:
• Más complejo de configurar y mantener
• Requiere de grandes cambios en las aplicaciones (si no fueron diseñadas para
trabajar en clúster)
• Requiere de una infraestructura más grande.
Red social
Desde un punto de vista matemático, la red social se define como un: “Conjunto de puntos
(actores sociales) vinculados por una serie de relaciones que cumplen determinadas
propiedades. Las redes sociales gozan de una estructura y una morfología propia, cuyas
cualidades, como la posibilidad de cuantificar las relaciones y su consiguiente tratamiento
matemático, evidencian importantes aplicaciones para el análisis e interpretación de las
conductas sociales” (Requena Santos, 1989).
Plataformas sociales
Las plataformas sociales (PS) son sitios web que reúnen a las personas para hablar,
compartir ideas e intereses o hacer nuevos amigos. Este tipo de colaboración y uso
compartido se conoce como social media. A diferencia de los medios web tradicionales que
normalmente son creados por no más de diez personas, las plataformas de redes sociales
poseen contenido creado por miles o incluso millones de personas diferentes (Computer
Hope, 2017).
Desde sus inicios dichas plataformas han fascinado a millones de usuarios que
intercambian datos, información y contenidos multimedia con un grupo de personas (y/o
organizaciones) de modo tal que se relacionan y originan entre ellos comunidades virtuales
que persigue un relativo interés en común.
19
A continuación, se muestra el top de las plataformas sociales con más usuarios activos
actualizado en marzo del 2018.
Figura 7. Social Media Ecosystem.
Fuente: (Socialbakers, 2018)
(Gallego Trijueque, 2016) define de una manera más estricta una plataforma social y nos
dice que “es una estructura, sistema, organización, que sostiene a un conjunto de individuos
que mantienen interacciones de diversa índole de forma regular, que comparten al menos
ciertos valores, normas objetivos etc. En donde la participación y el intercambio de
información son pilares básicos, y en donde los usuarios poseen conciencia de grupo, es
decir, sienten y perciben que forman parte de esa red, y son conscientes de las personas
que la integran. En estas redes sociales el individuo también encuentra referentes que le
sirven para orientarse, compararse y que le evalúen además de autoevaluarse así mismo.”
Big data
Las plataformas de redes sociales proporcionan un apoyo fundamental en el crecimiento
de cualquier marca comercial puesto que permiten tener a las empresas un seguimiento de
20
su reputación día a día. Dado que los datos generados por dichas plataformas crecen cada
segundo resulta complejo analizarlos con técnicas tradicionales, por eso surgen enfoques
como el big data, que se define como la “tendencia en el avance de la tecnología que ha
abierto las puertas hacia una nueva perspectiva en el entendimiento y toma de decisiones.
Se utiliza para describir enormes cantidades de datos (estructurados, no estructurados y
semi estructurados) que tomaría demasiado tiempo y sería muy costoso cargarlos a un
base de datos relacional para su análisis. De tal manera que, el concepto de Big Data aplica
para toda aquella información que no puede ser procesada o analizada utilizando procesos
o herramientas tradicionales”. (Fragoso, 2012)
En el día, un minuto podría no significar mucho, pero cuando esto se lo ve desde la gran
escala de Internet, en un minuto pasa mucho más allá de lo que podemos imaginar. En un
artículo publicado por (Desjardins, 2018) menciona las grandes cantidades de datos
generados por los sitios más populares en internet durante 60 segundos; las cifras de estos
datos son tan enormes que solo se pueden mostrar con dicha escala de tiempo.
21
Figura 8. ¿Qué sucede en internet durante 60 segundos?
Fuente: (Desjardins, 2018)
Análisis de redes sociales (Social Network Analysis)
Desde un punto investigativo el análisis de redes sociales es el estudio de entidades
sociales (personas en una organización llamadas actores), y sus interacciones y relaciones.
Las interacciones y relaciones pueden ser representadas con una red o grafos, donde cada
vértice (o nodo) representa un actor y cada enlace representa una relación. De las redes se
puede estudiar las propiedades de su estructura, el rol, posición y prestigio de cada actor
22
social. Se puede encontrar también varios tipos de sub-grafos, por ejemplo, comunidades
formadas por grupos de actores. (Bing, 2011)
Minería de Datos (Data Mining)
Data Mining también conocida popularmente como Knowledge Discovery in Databases
(KDD), es un campo de la estadística y las ciencias de la computación que permite la
extracción automatizada o conveniente de patrones que representan conocimientos
almacenados implícitamente en grandes volúmenes de datos. (Pllana, Janciak, Brezany, &
Wohrer, 2011).
Enriquecimiento de datos
El enriquecimiento de datos consiste en agregar valor y mejorar la calidad de los datos
existentes. Los expertos describen el proceso de enriquecimiento de datos como la
implementación de un conjunto de métodos y estructuras para refinar y mejorar la
información, lo que puede parecer un concepto vago. Más específicamente, el objetivo de
enriquecer los datos es convertirlo en un activo más valioso: obtener más de él, hacer más
con él, acceder a él más fácilmente y ser más proactivo en su uso, todo ello sin aumentar
los costos o riesgos. (WHITE, 2014)
Procesamiento del lenguaje natural (PLN)
(Martín Mateos & Ruiz Reina, 2013) definen el procesamiento del lenguaje natural como
“una disciplina de la Inteligencia Artificial que se ocupa de la formulación e investigación de
mecanismos computacionales para la comunicación entre personas y máquinas mediante
el uso de Lenguajes Naturales.”
En esencia el procesamiento del lenguaje natural tiene como objetivo simplificar la
comunicación entre personas y máquinas. Actualmente, buena parte de saber humano se
encuentra en forma digital en distintos tipos de colecciones de datos, pero sin el PLN sería
muy difícil aprovecharla. Según (Hernández & Gómez, 2013) entre los campos de estudio
del PLN se encuentra:
23
• Recuperación y extracción de información.
• Traducción automática.
• Sistemas de búsquedas de respuestas.
• Generación de resúmenes automáticos.
• Minería de datos.
• Análisis de sentimientos, etc.
Aprendizaje automático (Machine Learning)
El aprendizaje automático (ML por sus siglas en inglés) en la actualidad se escucha con
mayor frecuencia debido al valor que proporcionan al negocio y porque da un nuevo uso y
sentido a los datos con los que cuentan las organizaciones. (MathWorks, 2018) define al
aprendizaje automático como “una técnica de análisis de datos que enseña a los
ordenadores a hacer lo que resulta natural para las personas y los animales: aprender de
la experiencia.” (Contreras, 2016) en su artículo donde hace una introducción a ML enumera
algunas de las aplicaciones más frecuentes:
• En los buscadores web (Clasificación de contenido).
• En las redes sociales (Reconocimiento de rostros, perfilamiento, recomendaciones
de amigos).
• Correo electrónico (Detección de SPAM).
• Medicina (Modelos predictivos de enfermedades, secuencia genética, etc).
• Comercio (Segmentación de clientes, generación de productos más personalizados,
etc).
• Netflix, Amazon, iTunes (Recomendaciones personalizadas y a la medida de los
clientes).
• Predicciones de juegos, por ejemplo, fútbol, baloncesto, béisbol, etc.
Web scraping
Aunque los datos de las redes sociales son accesibles a través de un API, debido al valor
comercial que han adquirido en los últimos años, la mayoría de las principales fuentes como
Facebook, Twitter, Google cada vez hacen más difícil obtener acceso completo a los datos
24
en bruto. Actualmente, muchos investigadores trabajan sobre los datos producidos por las
plataformas sociales y sus altos costos, se han convertido en un gran obstáculo en el
desarrollo de nuevos estudios. Para superar esta barrera, técnicas como el web scraping
han surgido.
(Vargiu & Urru, 2013) definen el web scraping como “el conjunto de técnicas utilizadas para
obtener automáticamente cierta información de un sitio web en lugar de copiarla
manualmente. El objetivo de un Web scraper es buscar ciertos tipos de información,
extraerla y agregarla a nuevas páginas web. En particular, los scrapers se centran en
transformar datos no estructurados y guardarlos en bases de datos estructuradas.”
Web sockets
En su sitio web (Mozilla, 2016) definen los web sockets como “una tecnología avanzada
que hace posible abrir una sesión de comunicación interactiva entre el navegador del
usuario y un servidor”. Una explicación aún más detallada se encuentra en el sitio web de
(Microsoft, Windows Dev Center, 2018) quienes afirman que “El protocolo WebSocket
define un mecanismo para una comunicación bidireccional, rápida y segura entre un cliente
y un servidor a través de Internet”, representada visualmente en la figura 9. Los datos se
transfieren inmediatamente a través de una conexión full dúplex completo de un solo socket,
lo que permite que ambos extremos reciban y envíen mensajes en tiempo real.
25
Figura 9. Websockets, una representación visual
Fuente: (Hanson, 2013)
5. METODOLOGÍA EXPERIMENTAL
5.1. Tipo de Investigación
La presente investigación es de tipo aplicada y específicamente de método descriptivo,
pues el objetivo está orientado a identificar semejanzas o diferencias de un evento en dos
o más grupos (Vara Horna, 2012). Desde esta perspectiva, dicho estudio contempla la
propuesta de una arquitectura para procesamiento de datos abordando como eje central la
evaluación de requerimientos no funcionales tales como la escalabilidad, disponibilidad y
26
rendimiento. Además, esta investigación expone algunas ventajas y desventajas de dicha
arquitectura frente a las arquitecturas monolíticas.
Tomando como guía central el proceso PASWDFSS descrito en el marco teórico, los pasos
a seguir para el desarrollo de la arquitectura son:
• Identificación de requerimientos de la arquitectura: Tiene por objetivos
principales, la creación del equipo de trabajo, selección de los métodos que se
utilizarán para la elicitación de requerimientos, la obtención de estos, la traducción
de los requerimientos a requerimientos funcionales y atributos de calidad medibles
y finalmente la categorización de los requerimientos.
• Caracterización del diseño de la arquitectura: El objetivo principal es la creación
de alternativas de diseño, es decir la creación de entidades de diseño y sus
relaciones, con el objetivo de que cumplan los requerimientos funcionales y atributos
de calidad.
• Documentación de la arquitectura: Tiene como objetivo el representar la
arquitectura en prosa, usando una notación estándar y una plantilla estándar según
ANSI/IEEE 1471-2000.
• Optimizar el diseño de la arquitectura: El principal objetivo es hacer los reajustes
necesarios en el diseño para poder contemplar en mayor medida todos los atributos
de calidad.
• Validación del diseño de la arquitectura: Su objetivo es validar que la arquitectura
se encuentre de acuerdo con los requerimientos establecidos por los stakeholders.
27
6. CÁLCULOS Y RESULTADOS
6.1. Identificación de requerimientos de la arquitectura
6.1.1. Requerimientos funcionales
Esta sección brinda una descripción detallada de los requerimientos que debería tener la
plataforma que implemente la arquitectura propuesta. Además de ello, se describen los
problemas relacionados con los requerimientos y como se resuelven implementando la
arquitectura D10X.
Tabla 2. Requerimientos funcionales del sistema que debe soportar la arquitectura D10X
Requerimiento Problema Solución
Descarga de datos
provenientes de redes
sociales y páginas web
en near real time.
Existen límites de
descarga de datos
en las APIS de
redes sociales
- Construir módulos que
permitan web scraping sobre
las plataformas sociales.
- Utilizar las API de acceso a los
datos en las redes sociales
únicamente en el caso que
haya un cambio en las
plataformas y no se pueda usar
web scraping.
Máximo 5 minutos de
retraso en indexar los
nuevos datos
EL tiempo y costo
de la transferencia
de datos en tiempo
real
- Usar protocolos de transporte
de datos en tiempo real como
WebSockets.
Administrador de
consultas en redes
sociales
Puede resultar
complicado para el
usuario construir
consultas
personalizadas
- Crear una interfaz orientada al
usuario.
- Utilizar conectores lógicos en
las consultas para facilitar la
construcción de estas. (Ver
28
ejemplo de consulta en Figura
10.)
Realizar búsquedas
eficientes para
información compleja
utilizando frases sin
estructurar, ambiguas e
incompletas ingresadas
por los usuarios.
El uso de reglas
gramaticales y
ortográficas son
poco frecuentes en
los usuarios de las
plataformas
sociales
Utilizar procesamiento del lenguaje
natural (NLP) en problemas como:
- Recepción imperfecta de
datos.
- Lematización.
- Eliminación de stopwords.
Los datos extraídos de
las redes sociales deben
ser enriquecidos con:
• Detección de
género de la
persona que
genera el
contenido.
• Análisis de
sentimiento.
• Detección de
tópico.
• Georreferenciación
en contenidos que
incluyan ubicación
geográfica
Los datos
originales de las
API y los sitios web
no proporcionan
datos sobre el
usuario como
género, edad,
geolocalización,
profesión.
Utilizar machine learning para estos
módulos de tal forma que permita
enriquecer los datos.
Visualización en tiempo
real de:
• KPIs
• Tendencia de los
datos en el tiempo.
• Filtros.
• Top de usuarios.
La transferencia de
datos en tiempo real
es compleja en
tiempo y recursos
de hardware.
Construir un dashboard que permita
visualizar en tiempo real y de forma
gráfica e interactiva estas métricas
usando protocolos de transferencia
más rápidos con la menor cantidad
de recursos.
29
• Top de influencers.
• Detección de
potenciales bots.
Envió de alertas Proporcionar
rapidez en la
entrega de
información de
interés en el
momento
adecuado.
Enviar las alertas mediante
plataformas de Mensajería
instantánea, como Telegram,
Messenger.
Generar reportes
personalizables
Tener información
consolidada,
comprensible y
accesible
externamente.
Generar reportes ejecutivos en
formato PDF, y archivos CSV
exportables
Ejemplo de una consulta sobre Plataformas sociales usando conectores lógicos.
Los conectores lógicos son expresiones que permiten relacionar ideas dentro de un
contexto, y en las consultas que se realizan sobre un gran conjunto de datos, éstos
proporcionan un mayor control sobre los resultados obtenidos. En la Figura 10, se muestra
un ejemplo de una regla lógica que forma parte de un query que se lanzó sobre datos de
redes sociales que tienen como objetivo determinar el comportamiento o tendencias
suicidas de una persona.
30
Figura 10. Ejemplo de consulta sobre Plataformas sociales usando conectores lógicos.
Fuente: Propia.
6.1.2. Requerimientos no funcionales
Los requerimientos no funcionales en la ingeniería de software son criterios que permiten
evaluar los atributos de calidad de un sistema. En este caso, dichos atributos son tan
importantes como los requerimientos funcionales dado que si descuidamos alguno de los
requerimientos descritos en los objetivos específicos caeríamos nuevamente en una
arquitectura monolítica. Esta sección brinda una descripción detallada de los requerimientos
que se considerará en la arquitectura planteada, los problemas relacionados con estos
requerimientos y cómo se resuelve implementando la arquitectura D10X.
31
Tabla 3. Requerimientos no funcionales del sistema que debe soportar la arquitectura D10X
Requerimiento Problema Solución
Gráficos interactivos Permitir a los usuarios
aplicar filtros y segmentar
los datos en tiempo real.
Proporcionar una interfaz
amigable al usuario para
facilitar el uso de la
plataforma y explotación
de la arquitectura
Alta disponibilidad
- Los datos extraídos de las
plataformas sociales
cambian constantemente y
dichos cambios pueden
afectar a la disponibilidad de
la plataforma.
- Poder realizar
modificaciones o
reparaciones a un proceso
sin afectar la continuidad del
servicio.
- No usar bases de datos
relacionales puesto que
un cambio en el modelo
de datos requiere
demasiado esfuerzo.
- Usar microservicios
separando intereses de
tal forma que un cambio
no afecte a toda la
plataforma.
Los cambios en las
funcionalidades de
visualización no deben
afectar la descarga de
datos ni viceversa
Desacoplando los
módulos de descarga y
visualización, el
problema se resuelve
solo.
Debe soportar una alta
demanda de descarga de
datos (cuentas, tuits,
posts, web, blog)
Las Apis de las plataformas
sociales proporcionan
acceso limitado para la
descarga de datos (Twitter
sólo permite 900 peticiones
por cada 15 minutos y en el
caso de Facebook permite
Construir módulos de
descarga de datos
utilizando técnicas como
web scraping para evitar
la pérdida de datos.
32
máximo 200 peticiones por
hora por cada usuario).
Máximo rendimiento en
recursos y tiempo de
respuesta
Escalar horizontalmente
servidores monolíticos
requiere mucho esfuerzo.
Configurar clústers para
el procesamiento de
datos con el objetivo de
mejorar la experiencia
del usuario y la
visualización de
resultados en el menor
tiempo posible.
6.2. Caracterización del diseño de la Arquitectura
En este apartado se examina y describe el diseño detallado de cada una de los módulos y
submódulos que componen la arquitectura D10X.
6.2.1. Módulo de configuración
Consta de una aplicación web encargada de almacenar reglas de negocio, usuarios, roles,
consultas y cuentas de redes sociales, webs y blogs a realizar el seguimiento. Aquí se
plantean dos alternativas:
a) Aplicación servidor
Aplicación web tradicional, en cualquier lenguaje de programación que permita la lectura y
almacenamiento de toda la lógica descrita con anterioridad a través de un portal web.
b) Aplicación servidor cliente
Microservicio RESTful que almacene la configuración descrita con anterioridad y permita la
lectura y escritura a través de un portal web.
33
6.2.2. Módulo de descarga
Figura 11. Módulo de descarga
Fuente: Propia
Por cada fuente de datos se requiere mantener un esquema como el ilustrado en la Figura
11, ya que éste es el encargado de extraer los requerimientos de consulta proporcionados
por el usuario en el módulo de configuración (cuentas de redes sociales, sitios web, blogs,
consultas a realizar). Además, se encarga de iniciar la descarga a través de tareas
programadas que se ejecutan cada cinco minutos. Se estima este tiempo ya que resulta
casi imposible que una persona sea capaz de realizar más de unas tres publicaciones por
minuto. Puesto que uno de los principales objetivos a conseguir es una alta disponibilidad,
dicho módulo contará con dos opciones de descarga en forma redundante, es decir, cuando
34
uno de los módulos descritos a continuación deje de funcionar, el otro entrará en
funcionamiento, de esta forma habrá pérdida de datos casi nula en la descarga.
a) Módulo de descarga de datos mediante API’s
Al conectarse mediante las API’s provistas por las plataformas sociales para obtener los
datos, éstas imponen un límite de peticiones en un tiempo determinado, como en el caso
de Twitter que sólo permite novecientas peticiones por cada quince minutos, y doscientos
cada hora por usuario por parte de Facebook, lo cual es una limitante que máximo permitiría
descargar los últimos posts publicados por un máximo de veinte a treinta páginas por
usuario. Este módulo deberá conectarse al API que proporcione la plataforma social (de ser
el caso) y descargar los datos cuidando siempre no exceder los límites en el número de
peticiones.
b) Módulo de descarga de datos mediante Web scraping
Mediante el uso de dicha técnica, se desarrollará un módulo que extraiga directamente los
datos desde el sitio web, con lo que no habría límites en la descarga de datos. Sin embargo,
una desventaja de dicha técnica es que depende de que la estructura de la página web
(DOM) no cambie, si esto sucede dejaría de funcionar correctamente con lo que se perdería
datos o estarían incompletos.
Dado que los módulos antes descritos manejan una lógica compleja, se plantea construirlo
con un enfoque de microservicio. Además, ambos módulos se deberán desarrollar por
plataforma social (es decir ambos módulos por Facebook, Twitter, Instagram, etc) dado que
éstas son muy inestables en su estructura y en los datos que entregan. Con esto
conseguimos que los cambios en el método de descarga de una fuente de datos no afecten
a otra.
6.2.3. Orquestador de eventos de descarga
Independientemente del método de descarga a utilizarse, puesto que serán miles de
cuentas y consultas a descargar simultáneamente, se requiere coordinar este proceso para
lo cual se plantea dos alternativas:
35
a) Sistema distribuido de computación
Utilizar herramientas orientadas a streaming y big data ya desarrolladas que permitan
coordinar y ejecutar eventos en forma distribuida. Al elegir esta opción, la complejidad se
reduce considerablemente ya que poseen sus propios mecanismos de tolerancia a fallos y
del lado de desarrollo éstas se convierten en soluciones de caja negra.
b) Clúster de microservicios
Cada instancia del módulo de descarga se encargará de extraer datos de un número
determinado de cuentas, para lo cual dichos módulos estarán conectados a una cola donde
un microservicio de tipo Schedule colocará cada 5 minutos todas las cuentas y consultas a
descargar por cada fuente de datos (Facebook, Twitter, Instagram, etc). A diferencia de
usar el método anterior, en éste tenemos mucho más control a un nivel más bajo, esto es
beneficioso, pero alarga los tiempos de desarrollo y mantenimiento.
36
6.2.4. Módulo de enriquecimiento y almacenamiento
Figura 12. Módulo enriquecimiento de datos
Fuente: Propia
Una vez obtenidos los datos, cada registro descargado debe ser procesado y enriquecido.
Luego de ello, dicho dato se pondrá en una cola a espera de realizar el siguiente proceso.
Si el post ya se encuentra en la base de datos solamente se actualiza las métricas
calculadas como likes, compartidos, número de comentarios, audiencia y score; caso
contrario también se realiza los cálculos y adicionalmente son enriquecidos mediante la
llamada a las API’s de detección de género, edad y geolocalización, conceptos, etc. Una
vez concluido dicho proceso se almacena en una base de datos considerada como
repositorio original y al mismo tiempo se coloca en una cola para ser procesado por las
consultas.
37
Proceso de enriquecimiento de datos
Figura 13. Módulo de enriquecimiento de datos
Fuente: Propia
Los datos de obtenidos por las plataformas sociales no aportan ningún valor si no se
proporciona un enriquecimiento adecuado conforme a las necesidades del negocio. Por tal
motivo se considera que entre la información más importante de dichos datos están:
• El análisis de sentimiento.
• Detección de género.
• Geolocalización.
• Detección de edad.
• Un repositorio con datos histórico de los perfiles sociales.
En la arquitectura planteada, el módulo que se muestra en la Figura 13 está compuesto por
las funcionalidades antes descritas de enriquecimiento de datos (se podrían incluir más
conforme las necesidades del negocio) y dado que estas funcionalidades deberían
38
realizarse utilizando machine learning, se ha decidido desacoplar dicho módulo del resto de
la lógica de la arquitectura.
6.2.5. Motor de búsqueda
Puesto que las consultas configuradas por los usuarios están compuestas por varias reglas
definidas mediante operadores lógicos, cada ítem descargado deberá ser indexado en un
motor de búsqueda a espera que coincida con cada regla ingresada. Dicho motor de
búsqueda deberá contar con características como:
• Búsqueda de datos en tiempo real.
• Deberá ser distribuido para escalar horizontal y verticalmente con forme a las
necesidades y crecimiento del negocio.
• Alojar múltiples índices, que podrán ser consultados de manera independiente o en
grupo.
• Deberá ser orientado a documentos.
• Indexar datos sin usar esquemas.
• API RESTFUL para comunicación con el resto de los servicios.
• Tokenización
• Stemming.
• Eliminación de stopword.
39
6.2.6. Módulo de alertas
Figura 14. Módulo de alertas
Fuente: Propia
Las plataformas sociales son los medios de comunicación favoritos por políticos,
estrategas, empresarios, etc. Por su eficiencia y bajo costo para llegar al público en general,
pero muchas de las veces en el que este tipo de usuarios generan contenido en redes
sociales, no es únicamente con el fin de promocionar un producto, marca o persona, sino
que también lo hacen con el objetivo de desprestigiarlas. Este módulo está pensado con el
objetivo de alertar a los usuarios mediante el uso de mensajería instantánea o email, que
las palabras clave que se configuró en sus consultas se están volviendo tendencia en redes
sociales. Esto le permitirá tomar las medidas necesarias y tener un control total del
posicionamiento de su marca en todo momento.
En la configuración de las alertas el usuario define cada cuánto tiempo desea recibir las
mismas, además de las condiciones que deben cumplirse para que se considere enviar la
alerta tal como el número de menciones o la polaridad, para esto se desarrollará un
microservicio basado en el esquema de la figura 14, que se encargue de extraer de la base
40
de datos todas estas consultas, evaluar estas condiciones en el intervalo de tiempo definido,
y si las condiciones se cumplen se envían de forma asíncrona las alertas, para este caso
se plantea usar Telegram como plataforma de mensajería instantánea mediante peticiones
POST a su API y a través de correo electrónico, para esto se recomienda hacerlo mediante
un relay SMTP de un servicio especializado prestado por un tercero, ya que dado que se
espera una gran cantidad de envíos hacerlo desde un servidor local se saturaría el envío y
se lo marcaría como correo no deseado.
6.2.7. Motor de analítica
Figura 15. Motor de analítica
Fuente: Propia
Es el encargado de realizar las agregaciones y las analíticas definidas que se desean
visualizar. Dicho motor en la arquitectura propuesta, se considera un componente clave
para la obtención de información de los datos de las redes sociales. Por tal motivo se
plantea un módulo RESTful escalable horizontal y verticalmente que cupla con el esquema
de la figura 15, conteniendo toda la lógica descrita anteriormente y que conectado
directamente a la base de datos de configuración de las consultas y a la base de datos de
los registros procesados por el motor de búsqueda, entregarán continuamente resultados
41
al cliente web. Dado que a dicho módulo se conectarán varios clientes simultáneamente,
todas las instancias estarán coordinadas mediante un servicio de registro y un Gateway.
Dada la estructura y asociatividad de los datos de redes sociales, lo más recomendable es
usar una base de datos en grafos ya que son las que mejor se adaptan a este escenario y
están construidas para resolver este tipo de consultas y agregaciones en tiempo real de
forma paralela y distribuida, con lo cual en este microservicio solo se define las consultas,
pero son procesados y calculados directamente en la base de datos.
6.2.8. Cliente web
Para la visualización de la información en tiempo real, se plantea una aplicación web con el
renderizado y lógica de la aplicación del lado del cliente, la cual realizará peticiones REST
directamente a los módulos de configuración y analítica.
Uno de los requerimientos es tener el dashboard en tiempo real con datos actualizados sin
necesidad que el usuario refresque la página, por lo que se puede programar de lado del
cliente realizar peticiones HTTP vía Ajax cada cierto tiempo definido solicitando nuevos
datos al módulo de analítica, esto presenta dos problemas:
• Si dos o más usuarios están visualizando la misma consulta se estarían
recalculando varias veces la misma analítica, lo que resulta en desperdicio de
recursos.
Solución:
o Colocar una estructura de caché para evitar este excesivo procesamiento
de las consultas.
o Realizar un procesamiento de lado del servidor y notificar por WebSockets
a todos los clientes suscritos a esa consulta.
• Es demasiado costoso en tiempo y recursos realizar peticiones HTTP cada
segundo.
Solución:
o Usar websockets para que los clientes se suscriban a un tópico por consulta
y de lado del servidor se notifique a los clientes. Esto resuelve este problema
42
sin embargo recae en el problema anterior, puesto que implicaría que todas
las consultas estén procesándose incluso si no hay clientes suscritos a las
mismas y notifiquen al tópico.
o En la primera petición establecer un websockets y a través de éste solicitar
los datos. Esto reduce considerablemente el tiempo y recursos como se
describió en el marco teórico.
Dada la cantidad de peticiones y conexiones activas esperadas se debe mantener varias
instancias de este microservicio coordinados por un registro y un Gateway.
6.2.9. Módulo de reportes
Todos los gráficos y datos visibles en la interfaz web deben ser exportables, en dos formatos
CSV y PDF. El archivo CSV será generado directamente en el cliente web aprovechando
los datos que ya se encuentran ahí.
Para generar el reporte global en PDF con todos los gráficos, existen dos opciones:
• Del lado del servidor con algún motor de reportes para posteriormente descargar el
archivo, sin embargo, esto implicaría doble esfuerzo ya que cada vista y cada gráfico
debería ser replicado tanto en la vista del cliente como en el motor de reportes.
• Desarrollar un plugin escrito en JavaScript para instalar en el navegador web, el cual
se encargará de capturar los gráficos como imágenes directamente en el navegador
web y generar el archivo PDF con un diseño empresarial.
43
6.3. Documentación de la Arquitectura
Figura 16. Diagrama Arquitectura D10X
Fuente: Propia
44
El principal objetivo del diseño de la arquitectura es proporcionar una guía general en la
construcción de aplicaciones que procesen datos provenientes de las redes sociales
garantizando una alta disponibilidad, confiabilidad y fiabilidad en el servicio.
Como se aprecia en la Figura 16 las fuentes de datos examinadas provienen de redes
sociales como Facebook, Twitter e Instagram, mismas que poseen API’s públicas
accesibles a cualquier desarrollador previa autorización de los encargados de estas
plataformas. Sin embargo, los datos provistos a través de éstas son muy limitados tanto
en el número de peticiones como en los datos que arrojan; se plantea que por cada
fuente de datos se tenga dos microservicios, uno que consuma el API y otro que
mediante Web scraping extraiga los datos directamente de la web, teniendo así
redundancia en la extracción de datos.
Considerando que la cantidad de datos a extraer es inmensa (publicaciones realizadas
por un número indefinido de usuarios en sus perfiles sociales); en la actualidad existen
varias herramientas para el procesamiento de éstos en paralelo de forma distribuida, sin
embargo se plantea que para este módulo específico es mejor coordinar un clúster de
microservicios que se encargue de la descarga coordinados por un nodo central y algún
sistema de colas específico para el tratamiento de streams de datos, persistente y
tolerante a fallos. Con la flexibilidad que brindan los microservicios podemos modificar
partes especificas o escalar específicamente la parte necesaria sin afectar el servicio
completo.
Una vez descargados los datos, cada uno pasa al módulo de procesamiento donde se
realiza la limpieza, normalización y enriquecimiento, para posteriormente guardarse en
una base de datos que será un repositorio histórico de los datos originales. Luego como
se muestra en la Figura 17 cada uno de éstos deberán ser procesados nuevamente,
pero esta vez se analizará con cada regla lógica de cada consulta definida por cada
usuario y almacenar en la base de datos la referencia del ítem junto con los
identificadores de cada regla y consulta con la que coincide, por tanto, cada ítem está
asociado a una o varias reglas de una o varias consultas. A esta asociación la
determinaremos como un objeto “asociación” cuyas propiedades serán el id de la
consulta, el id de la regla y la polaridad ya que ésta puede ser modificada por el usuario,
por cada consulta puesto que un ítem dado su contexto puede ser positivo para un
usuario y negativo para otro.
En la arquitectura D10X, en contraste a lo definido por la popular arquitectura lambda
(Marz & Warren, 2015) para procesamiento en tiempo real que posee dos capas una
batch y una de realtime que guarda cálculos pre-computados, y los suma a los nuevos
45
datos, no es conveniente dada la naturalidad de los datos cambiantes cada segundo
(likes, retuits, shares), por tanto, los cálculos deben realizarse in situ ya que se requiere
tener datos reales, no estimados en tiempo real. Dado el gran procesamiento que
requiere debe ser un clúster bien coordinado que procese los datos en paralelo de
manera distribuida.
Posteriormente un módulo se encargará de lanzar cada minuto un proceso micro batch
que calcule el número de menciones y de ser necesario enviar las alertas al email o al
servicio de mensajería instantánea establecido por el usuario.
Finalmente, el módulo de analítica que como su nombre lo indica realiza el cálculo de
todas las métricas cuando un usuario lo solicita, o en su defecto cada minuto notificando
al usuario final que previamente haya abierto el dashboard de visualización sin
necesidad que recargue la aplicación, también deberá ser un clúster de procesamiento.
Cuando el usuario solicita un reporte, contiene los mismos gráficos estadísticos que la
vista web, pero en formato pdf, para lo cual se dispone de un plugin instalable en el
navegador del usuario que genere estos reportes y estén disponibles para su descarga
inmediata.
El proceso de descarga de los tweets y su respectivo enriquecimiento y almacenamiento
se describe en la Figura 17. Además de ello, la Figura 18 nos proporciona una vista del
proceso de entrega de la información almacenada al usuario a través de un motor de
búsqueda.
46
6.3.1. Diagrama de flujo de la arquitectura
Figura 17. Diagrama de flujo de descarga de datos
Fuente: Propia
47
6.3.2. Diagrama de flujo del motor de búsqueda de datos
Figura 18. Diagrama de flujo del motor de búsqueda de datos
Fuente: Propia
6.4. Optimización del diseño de la Arquitectura
Realizada la documentación en prosa, se pudo identificar módulos que requieren
una optimización.
6.4.1. Motor de procesamiento
Una vez descargados los datos se deben enviar a una cola persistente a espera de
ser procesados, con esto se garantiza una mayor tolerancia a fallos ya sea por fallas
48
en el motor procesamiento, o por cambio de versión o modificación en el mismo, de
esta forma no se perderán datos.
A diferencia del módulo de descarga, éste es independiente del origen de los datos,
ya que su funcionamiento esta netamente ligado al texto, por tanto, es una única
versión de éste que debe ser implementado con alguna de las herramientas para
procesamiento distribuido evitando mantener un clúster de este microservicio junto
con el registro.
6.4.2. Módulo de reportes
Uno de los requerimientos no funcionales contempla tener una buena experiencia de
usuario, maximizando la utilidad y disminuir la complejidad en el uso del sistema,
características con las que no cumple el tener que instalar un plugin en cada navegador
web donde se requiera generar los reportes, así que se propone desarrollar un
microservicio que reciba como entrada la consulta y los filtros seleccionados por el
usuario y genere un reporte PDF de corte ejecutivo en un sistema de archivos temporal
hasta ser descargado por el usuario.
6.4.3. Motor de analítica
Considerando que cada componente del dashboard (gráficos, tablas, KPI) es interactivo,
una de sus funcionalidades es ver el detalle de las publicaciones respectivas, ya que un
mismo usuario o varios usuarios concurrentes pueden solicitar con los mismos
parámetros, lo que se traduce posiblemente en una gran cantidad de peticiones
duplicadas al servidor mediante el WebSockets activo, en intervalos muy cortos de
tiempo por lo que se considera, colocar un sistema de caché in-memory de baja duración
a estas peticiones.
49
Figura 19. Motor de analítica
Fuente: Propia
En la Figura 19 se aprecia el flujo de la petición desde el cliente con ciertos parámetros
establecidos hasta la respuesta de los datos desde el caché o si no se encuentra en el
caché o transcurrió más de 5 minutos desde su generación, se descarta el caché, se
genera una nueva petición a la base de datos y esta respuesta es enviada al cliente y
almacenada en el caché.
Se muestra en la Figura 20, la arquitectura optimizada incluyendo los módulos descritos
anteriormente.
50
Diagrama de la arquitectura D10X optimizada
Figura 20. Diagrama Arquitectura D10X optimizada
Fuente: Propia
51
6.5. Validación del diseño de la Arquitectura
6.5.1. Implementación
Aunque la arquitectura propuesta está pensada para un ambiente empresarial, su
implementación en un ambiente de producción está fuera del alcance de la presente
investigación, sin embargo, se desarrollaron módulos funcionales con pruebas unitarias
que permitan cumplir los objetos de validación de la arquitectura.
Basados en evaluaciones externas a este estudio, se considera que las siguientes
herramientas de software se adaptan de mejor manera a la implementación de la
arquitectura D10X.
- Docker para los contenedores donde desplegar los microservicios con Openshift
como orquestador
- Netflix Eureka como Service discovery y registry
- Netflix zuul como gateway
- Mongo como base de datos para la configuración
- Mongo para almacenar los datos originales enriquecidos
- Neo4j para almacenar los datos procesados
- Apache storm con zookeper para el módulo de procesamiento en tiempo real y
enriquecimiento
- API’s de enriquecimiento desarrolladas con Python, framework flask desplegada
con varios workers en Gunicorn
- Sistema de alertas, microservicio con spring framework y apache camel.
- Módulo de descarga por API’s escritas en java con spring framework y apache
camel.
- Módulo de descarga por Web Scraping con Python utilizando framework scrapy.
- Servicio de tópicos persistentes mediante Apache Kafka
- Motor de analítica con Python
- Sistema de Cache con Redis
6.5.2. Pruebas
Usando las herramientas descritas en el apartado anterior para construir prototipos
funcionales, se realizará pruebas tomando como eje central la evaluación de la
escalabilidad, disponibilidad y rendimiento entre la arquitectura propuesta y una
implementación de arquitectura monolítica descrita en la Figura 21.
52
Diseño de una arquitectura monolítica para procesamiento de datos en redes
sociales.
Figura 21. Arquitectura monolítica para procesamiento de datos en redes sociales.
Fuente: Propia
6.5.3. Desarrollo del experimento
Ambiente de pruebas controlado
2 máquinas HP con las siguientes características.
• Sistema Host: Ubuntu 18.04
• RAM: 16GB
• Disco 1TB
• Procesador core i7 6ta generación 4 núcleos
• GPU Nvidia 950M 4GB dedicado
1 servidor Asus con las siguientes características.
• Sistema Host: Centos 7
• RAM: 16GB
53
• Disco 2TB
• Procesador core i7 7ma generación 4 núcleos
• GPU Nvidia GT-730 4GB dedicado
Para la visualización, captura de datos estadísticos y obtención de métricas del uso de
hardware, se utilizó herramientas especializadas como:
• Telegraf
• Influxdb
• Grafana
En el caso que se desee replicar el experimento, los datos utilizados en la presente
investigación se encuentran en los siguientes repositorios de datos.
• Métricas: Base de datos (influxdb) con las métricas recolectadas por segundo.
http://bit.ly/tesis_d10x_metrics
• Datos: Base de datos (mongodb) que contiene los tweets con los que se realizó
el experimento http://bit.ly/tesis_d10x_data.
6.5.3.1. Arquitectura monolítica:
El experimento tiene como objetivo la evaluación del rendimiento de una arquitectura de
software monolítica bajo pruebas de estrés. En este caso, la prueba se realiza con una
carga de trabajo de 1 millón de tweets incrementados gradualmente, la Figura 22 y
Figura 23 muestra el uso del CPU y de memoria RAM utilizada para procesar dicha
cantidad.
54
Uso de CPU en sistema monolítico (Caso 1).
Figura 22. Uso de CPU sistema monolítico.
Fuente: Propia
Uso de RAM en sistema monolítico (Caso 1).
Figura 23. Uso RAM arquitectura monolítico.
Fuente: Propia
55
6.5.3.2. Sistema Distribuido:
Con la finalidad de realizar una comparativa entre la implementación de la arquitectura
monolítica y la arquitectura D10X. A continuación, se hará la evaluación de dos casos,
donde las métricas se las tomará a cada minuto de procesamiento dado que las
peticiones son asíncronas. Otro de los objetivos también es evaluar cuándo se deberían
escalar los módulos en base al porcentaje de pérdida de datos.
Consumo de RAM (Caso 1)
Tabla 4. Consumo de RAM (Sistema distribuido, Caso 1).
# Tweets Descarga (GB) Cola (GB) Procesamiento (GB)
2000 9.8 3.17 12.1
23000 9.9 3.17 12.27
45800 9.7 3.18 12.28
67500 9.81 3.16 12.29
92500 9.79 3.17 12.27
103000 9.86 3.22 12.28
Figura 24. Consumo de RAM, gestor de descarga (Sistema distribuido, Caso 1).
Fuente: Propia
56
Figura 25. Consumo de RAM, servidor de colas (Sistema distribuido, Caso 1).
Fuente: Propia
Figura 26. Consumo de RAM, motor de procesamiento (Sistema distribuido, Caso 1).
Fuente: Propia
57
Consumo de CPU (Caso 1)
Tabla 5. Consumo de CPU (Sistema distribuido, Caso 1).
# Tweets Descarga % Cola % Procesamiento %
2000 50 10 3
23000 36 3 5
45800 59 4 6
67500 48 2 7
92500 39 4 8
103000 44 15 6
Figura 27. Consumo de CPU, gestor de descarga y productor (Sistema distribuido, Caso
1).
Fuente: Propia.
58
Figura 28. Consumo de CPU, servidor de colas (Sistema distribuido, Caso 1).
Fuente: Propia
Figura 29. Consumo de CPU, motor de procesamiento (Sistema distribuido, Caso 1).
Fuente: Propia.
59
Tweets procesados por minuto (Caso 1).
La Tabla 6 describe la cantidad de tweets procesados en intervalos de tiempo de un
minuto.
Tabla 6. Tweets procesados incrementalmente por minuto (Sistema distribuido, Caso 1).
Tiempo (minutos) # Tweets
1 2000
2 21000
3 22800
4 21700
5 25000
6 10500
Figura 30. Total, tweets procesados
Fuente: Propia
Como se requiere un análisis en ‘near real time’, a continuación, se medirá los recursos
necesarios para garantizar este cumplimiento conforme la carga de trabajo aumenta o
disminuye en el tiempo. Para esto se procesará en distintos sets de datos en intervalos
de cantidad y frecuencia mientras se escala horizontal y/o verticalmente toda la
arquitectura o parte de ella verificando que el tiempo de procesamiento permanece
estable dentro de los intervalos establecidos.
60
Consumo de RAM (Caso 2)
Tabla 7. Consumo de RAM (Sistema distribuido, Caso 2).
# Tweets Descarga (GB) Cola (GB) Procesamiento
26000 7.85 4.78 14
67000 8.23 5.10 14.31
144000 8.42 5.25 14.20
231000 8.88 5.90 14.12
311000 9.19 6.0 14.04
387000 9.26 6.33 13.98
473000 9.54 6.44 13.78
555000 9.94 6.48 13.76
677000 10 6.52 13.72
727000 10.33 6.66 13.66
Figura 31. Consumo de RAM, gestor de descarga y productor (Sistema distribuido, Caso
2).
Fuente: Propia.
61
Figura 32. Consumo de RAM, servidor de colas (Sistema distribuido, Caso 2).
Fuente: Propia
Figura 33. Consumo de RAM, motor de procesamiento (Sistema distribuido, Caso 2).
Fuente: Propia
62
Consumo de CPU (Caso 2)
Tabla 8. Consumo de CPU (Sistema distribuido, Caso 2).
# Tweets Descarga % Cola % Procesamiento %
26000 19 34 8
67000 16 36 8
144000 18 42 10
231000 15 34 10
311000 22 37 9
387000 14 39 9
473000 20 44 9
555000 15 45 11
677000 6 36 8
727000 9 34 5
Figura 34. Consumo de CPU, gestor de descarga y productor (Sistema distribuido, Caso
2).
Fuente: Propia
63
Figura 35. Consumo de CPU, servidor de colas (Sistema distribuido, Caso 2).
Fuente: Propia
Figura 36. Consumo de CPU, motor de procesamiento (Sistema distribuido, Caso 2).
Fuente: Propia
64
Tiempo de procesamiento (Caso 2)
Tabla 9. Tiempo de procesamiento (Sistema distribuido, Caso 2).
Tiempo # Tweets
1 26000
2 41000
3 77000
4 87000
5 80000
6 76000
7 86000
8 82000
9 122000
10 50000
Total: 727000
Figura 37. Total de documentos procesados.
Fuente: Propia
65
Caso 3: Tiempo en iniciar servicios.
Asumiendo que se ha desarrollado una versión estable del software que implementa
cada una de las arquitecturas se medirá el tiempo necesario para levantar los servicios
cuando se necesita desplegar una nueva versión ya sea para corregir un bug o agregar
una nueva funcionalidad.
Tabla 10. Tiempo en iniciar servicios
Iteración Máquina Virtual (s) Contenedor (s)
1 180 10
2 190 8
3 186 10
4 186 10
5 187 10
6 185 10
7 191 9
8 190 10
9 189 10
10 187 10
Promedio 187,1 9,7
66
7. DISCUSIÓN
Basado en los datos obtenidos durante la investigación, se puede corroborar que ambas
arquitecturas cumplen con los requerimientos funcionales que se establecen al inicio y
en lo cual se ha podido observar que:
Caso 1:
En este caso, dada la poca cantidad de datos con los que se realizó el experimento
(103000 tweets) en las implementaciones de ambas arquitecturas, no se presenció
pérdida de datos, todos fueron procesados y almacenados sin inconveniente. Las
Figuras 22 y 23 muestran el comportamiento del CPU y el consumo de la memoria RAM
de la arquitectura monolítica donde se observa que conforme aumenta los datos a
procesar, también aumentan estos recursos. En el caso de la implementación de la
arquitectura D10X, al estar distribuida en tres servidores separados físicamente, el
consumo de RAM en algunos de ellos (Ver Figura 24, 25, 26) obviamente es mayor,
pero se consigue un mejor aprovechamiento del uso de CPU en cada servidor (Ver
Figura 27, 28, 29).
Caso 2:
Al realizar el experimento en la arquitectura planteada con un millón de tweets y con una
concurrencia de 1000 tweets por segundo, se obtuvo una pérdida de casi el 30% de los
datos que se descargaron correctamente, pero fallaron al ser procesados, mientras que
con el enfoque monolítico, los datos que se intentaban procesar se perdieron por
completo.
Con la arquitectura D10X la pérdida de datos se reduce considerablemente ya que el
procesamiento se lo hace de forma asíncrona, es decir que basta que el módulo de
descarga ponga los datos en el servidor de colas, para pueda continuar con el
procesamiento del resto de datos; mientras que en la arquitectura monolítica el
guardado de los datos se lo hace de principio a fin en cada registro, es decir que el flujo
no puede continuar hasta que un tweet haya pasado desde la descarga hasta el
almacenamiento con lo cual es más evidente la lentitud en el procesamiento en este
esquema.
67
Si recordamos los requerimientos funcionales descritos anteriormente, uno de éstos era
que la arquitectura debe soportar el procesamiento de datos en tiempo real, y si
observamos la Figura 37, el tiempo de procesamiento cada vez se aleja más de este
requerimiento, con lo cual surge la necesidad de escalamiento. Algunas veces, la
escalabilidad es uno de los requerimientos no funcionales más difíciles de conseguir en
las arquitecturas monolíticas, ya que no consiste únicamente en duplicar toda la
instancia en un servidor diferente, sino que también implica configuración (sistema
operativo, configuración del aplicativo, ambiente de despliegue, etc.) para que todas las
instancias puedan trabajar conjuntamente. Los contenedores vienen a solucionar varios
de los problemas que se presentan a la hora de escalar un aplicativo, ya que son
ambientes aislados ligeros y portables, es decir, una vez que se configura el ambiente
de despliegue, no necesitan nuevas configuraciones. El comparativo realizado en la
Tabla 10, muestra que las máquinas virtuales tardan mucho más tiempo en estar
disponibles ya que requieren la preparación y configuración del ambiente de despliegue
como se mencionó anteriormente, mientras que los contenedores tardan segundos en
escalar y en estar disponibles.
Considerando las Figuras 31, 32 y 33 (Uso de RAM) y Figuras 34, 35 y 36 (Uso de CPU),
que describen los recursos usados para procesar una cantidad creciente de datos en
tiempo real, tanto la arquitectura planteada como la monolítica están en plena capacidad
de manejarlos, sin embargo las arquitecturas monolíticas por su naturaleza implica
escalar todo en su conjunto desperdiciando recursos, mientras que la arquitectura D10X
claramente permite hacerlo de una forma mucho más rápida e independiente, es decir
permite escalar partes especificas del sistema (por ejemplo, solo el motor de
procesamiento), con lo cual se tiene un mejor aprovechamiento en los recursos y facilita
el mantenimiento de partes específicas del sistema.
Todo sistema es susceptible a fallos y tiempos fuera de servicio provocado por factores
externos como cortes de servicio eléctrico o de internet; dado que la arquitectura
propuesta puede ser implementada en un propio centro de datos o en una nube pública,
la disponibilidad del sistema ante uno de estos factores externos queda sujeta a la
infraestructura física de donde sea implementada. Se considera que el sistema no está
disponible cuando no se tienen datos procesados de al menos los últimos 5 minutos.
Dada la gran variabilidad de los datos provenientes de las redes sociales, puede requerir
un cambio de versión en alguna parte específica del sistema o la adición de nueva
funcionalidad, lo cual puede implicar tiempos fuera de servicio. Para minimizar este
impacto, las nubes públicas ofrecen la posibilidad de desplegar varias instancias de
cada versión de la aplicación accesibles al cliente final utilizando la misma estrategia de
68
escalamiento antes mencionada, remplazando incrementalmente los nodos con la
nueva versión, si bien con esto se puede disminuir los tiempos fuera de servicio (incluso
obviarlos por completo), resulta demasiado costoso en recursos y tiempos más largos
en completarse el cambio; y si consideramos un propio DataCenter este proceso no es
tan automático dependiendo del sistema de administración de dicha infraestructura, en
contraparte con la arquitectura propuesta basada en microservicios junto con un
orquestador se tiene la ventaja de reemplazar directamente una funcionalidad
específica con la nueva versión sin la necesidad de afectar los demás módulos.
Las arquitecturas monolíticas incluso las SOAP, manejan flujos continuos de los
procesos generalmente basados en memoria, con lo cual ante una afectación del
sistema se presentan pérdida de datos, mientras con la arquitectura planteada al estar
todo orquestado de manera asíncrona con colas persistentes de streams de datos se
minimiza la pérdida de datos o reprocesamiento innecesario de los mismos.
Considerando lo mencionado en este apartado y las métricas obtenidas del
experimento, se concluye que la arquitectura planteada garantiza una mejor
disponibilidad, rápida recuperación ante fallos, con cero tiempos de inactividad durante
despliegue de nueva versión.
Ambas arquitecturas cumplen plenamente con los requerimientos funcionales del
sistema planteado, pero lo que se busca es que la arquitectura sea eficaz y eficiente,
parámetros con los cuales la arquitectura monolítica no cumple. A simple vista se puede
interpretar que la arquitectura monolítica para lograr la escalabilidad y disponibilidad
necesaria para procesar la cantidad de datos planteados utiliza menos recursos que la
arquitectura propuesta, esto es evidente ya que usa menos componentes de software,
sin embargo, analizando a profundidad, ésta no realiza un uso eficiente de los recursos,
además de no ofrecer un mecanismo para evitar la pérdida de datos durante el proceso.
Por otra parte, también complica la disponibilidad del sistema ya que requiere mayor
esfuerzo y tiempo para escalar y cambiar de versión.
69
8. CONCLUSIONES
• Al conseguir independencia entre funcionalidades y ayudado de un servidor de
colas para el procesamiento asíncrono de los datos, la arquitectura D10X
garantiza mayor disponibilidad que la monolítica ya que se reduce
considerablemente la pérdida de datos.
• La implementación de la arquitectura monolítica, al estar desplegada bajo un
mismo servidor físico, evidentemente usa menos recursos para su
funcionamiento. Sin embargo, al requerir más capacidad de procesamiento o
mayor velocidad, es necesario duplicar la instancia completa para conseguir
dicho resultado que implica un uso inapropiado de recursos. La arquitectura
D10X proporciona un enfoque modular y tolerante a fallos; que permite escalar
funcionalidades específicas optimizando el uso de recursos.
• Los sistemas de orquestación de servicios como Juju, Kubernetes, Openshift,
Docker swarm, mediante la definición de reglas basada en el uso de CPU,
memoria, o red permite aumentar o eliminar instancias de los microservicios
optimizando el uso de recursos de forma automática.
• El uso de contenedores para el despliegue de servicios es más eficiente en el
uso de recursos de hardware y tiempo a diferencia de las máquinas virtuales.
• Puesto que D10X fue diseñado con enfoque polígloto, el lenguaje de
programación y herramientas de software a utilizarse está a libre elección de
quien la implemente, siempre y cuando cumplan con las especificaciones
determinadas en este estudio no afectarán el rendimiento de esta.
70
9. RECOMENDACIONES
• En este estudio se ha realizado procesamiento distribuido mediante el uso de
clúster de microservicios orquestados, sería interesante realizar este mismo
estudio realizando un procesamiento en paralelo con el uso de GPU en cada
nodo de la arquitectura distribuida.
• Se recomienda realizar este estudio con el uso de una nueva tecnología
denominada Ubuntu LXD, que es una alternativa más rápida de máquinas
virtuales dentro de los cuales se puede desplegar y escalar las aplicaciones o
usar en conjunto con los contenedores.
• Se recomienda una implementación de la arquitectura combinando el uso de las
bases de datos no relaciones almacenadas en discos de estado sólido. En el
estudio ACCELERATING BIG DATA – USING SANDISK SSDS FOR
MONGODB WORKLOADS (SanDisk, 2018) determinan que, al usar discos
sólidos en un clúster de MongoDB, éstos permiten reducir las instancias de dicho
clúster ya que se obtienen tiempos de respuesta más cortos.
• Dado que el multiprocesamiento es un plus de la arquitectura D10X, se
recomienda que los módulos el de búsqueda, analítica y de descarga por Apis,
se desarrollen en lenguajes de programación como Java 8 o superior, puesto
que usando frameworks como Spring junto con Apache Camel facilitan el uso
del multiprocesamiento reduciendo la complejidad del código y el tiempo de
desarrollo.
• A menos que para el módulo de enriquecimiento de datos se vayan a usar
herramientas de machine learning desarrolladas por terceros (ejemplo IBM
Watson o Azure Machine Learning Studio), se recomienda el uso de Python
como lenguaje de programación, librerías como NLTK para el tratamiento del
lenguaje natural y scikit-learn para el uso de modelos de aprendizaje
supervisado.
• Ya que los servicios a administrar son varios y las redes sociales son muy
volátiles, se recomienda que el paso a producción de una implantación de la
arquitectura D10X se lo realice con el uso Continuous integration y Continuous
Delivery para facilitar los cambios en los módulos descritos anteriormente.
• Si bien es cierto, el motor de búsqueda forma una pieza clave en la arquitectura
D10X, un estudio futuro podría enfocarse en determinar la viabilidad de sustituir
dicho módulo por una base de datos en grafos como Neo4j, ya que este tipo de
71
bases de datos, permiten solucionar problemas de tipo red social de una manera
más rápida y con el uso de menos recursos.
• Por último, se recomienda conectar a la arquitectura un sistema de monitoreo
capaz de alertar en tiempo real fallos o el uso inadecuado de recursos,
especialmente en el módulo de descarga vía web scraping ya que, si la
estructura del portal web de las plataformas sociales cambia, podría ocasionar
la pérdida excesiva de datos y la degradación del servicio.
72
10. BIBLIOGRAFÍA
Adedoyin, M., Medhat, M., & Stahl, F. (2013). A Survey of Data Mining Techniques for
Social. 1.
Amazon. (2018). Amazon. Obtenido de ¿Qué son los datos de streaming?:
https://aws.amazon.com/es/streaming-data/
Atchison, L. (2016). Architecting for Scale. O'Reilly Media.
Bárbara, L. (1972). A design methodology for reliable software systems. Joint computer
conference, part I, 191-199. Obtenido de
https://dl.acm.org/citation.cfm?doid=1479992.1480018
Bass, L., Clemens, P., & Kazman, R. (2013). Software Architecture in Practice. En L.
Bass, P. Clemens, & R. Kazman. Boston: Pearson Education, Inc.
Bing, L. (2011). Social Network Analysis. Data-Centric Systems and Applications book
series (DCSA). Obtenido de https://link.springer.com/chapter/10.1007/978-3-
642-19460-3_7
Cervantes Maceda, H., Velasco Elizondo, P., & Castro Careaga, L. (2016). Arquitectura
de Software. En Conceptos y Ciclo de Desarrollo (págs. 5-7). México D.F:
Cengage Learning Editores.
Computer Hope. (30 de 10 de 2017). Obtenido de Social Network:
https://www.computerhope.com/jargon/s/socinetw.htm
Contreras, F. (2016). Zemsania Global Group. Recuperado el 30 de Mayo de 2018, de
INTRODUCCIÓN A MACHINE LEARNING:
https://www.zemsania.com/recursos-
zemsania/whitepapers/DTS/Machine_learning.pdf
Daniels, J. D. (2016). Effective DevOps. O’Reilly Media.
Desjardins, J. (14 de Mayo de 2018). Visual Capitalist. Obtenido de What Happens in an
Internet Minute in 2018?: http://www.visualcapitalist.com/internet-minute-2018/
Fernández del Corral, Ó. (Junio de 2007). Universidad Politécnica de Madrid. Obtenido
de Procesamiento de flujos de eventos en un entorno distribuido y análisi de
comportamiento: arquitectura e implementación:
73
http://oa.upm.es/47158/1/TFM_OSCAR_FERNANDEZ_MIGUEL_DEL_CORRA
L.pdf
Fragoso, R. B. (18 de Junio de 2012). IBM. Obtenido de develeperWorks:
https://www.ibm.com/developerworks/ssa/local/im/que-es-big-data/
Gallego Trijueque, S. (2016). Universidad Complutense de Madrid. Obtenido de Redes
sociales digitales: información, comunicación y sociedad en el siglo XXI (2000-
2010): http://eprints.ucm.es/44233/
Garcia, D., & Garcia, R. (2008). Experimental Evaluation of Horizontal and Vertical
Scalability. University of Oviedo.
Grady, B. (1998). OBJECT-ORIENTED ANALYSIS AND DESIGN. Santa Clara,
California : ADDISON-WESLEY .
Hanson, J. (11 de Septiembre de 2013). PubNub. Obtenido de What Are WebSockets?:
https://www.pubnub.com/blog/2013-09-11-what-are-websockets/
Hernández, M., & Gómez, J. (2013). Repositorio Institucional de la Universidad de
Alicante. Revista Politécnica, 87-96. Recuperado el 28 de Mayo de 2018, de
Aplicaciones de Procesamiento de Lenguaje:
https://rua.ua.es/dspace/bitstream/10045/33514/1/2013_Hernandez_Gomez_R
evPolitec.pdf
IDC, C. (2012). El universo digital de datos 12. España: EMC Corporation.
Institute, S. (s.f.). SAS. Obtenido de Natural Language Processing:
https://www.sas.com/en_us/insights/analytics/what-is-natural-language-
processing-nlp.html
Jennifer Davis, K. D. (2016). Effective DevOps. O’Reilly Media, Inc.
Jung, M., Möllering, S., Dalbhanjan, P., Chapman, P., & Kassen, C. (Diciembre de 2016).
Microservices on AWS. Obtenido de AWS Whitepaper:
https://docs.aws.amazon.com/aws-technical-content/latest/microservices-on-
aws/microservices-on-aws.pdf#characteristics-of-microservices
Kempe, D., & Kleinberg, J. (24 de 08 de 2003). Maximizing the spread of influence
through a social network. KDD '03 Proceedings of the ninth ACM SIGKDD
international conference on Knowledge discovery and data mining, 137-146.
Obtenido de https://dl.acm.org/citation.cfm?id=956769
74
Little D.C, J., & C. Graves, S. (s.f.). Little´s Law. Massachusetts Institute of Technology.
Obtenido de http://web.mit.edu/sgraves/www/papers/Little's%20Law-
Published.pdf
Martín Mateos, F. J., & Ruiz Reina, J. L. (2013). Dpto. de Ciencias de la Computación e
Inteligencia Artificial Universidad de Sevilla. Obtenido de Procesamiento del
lenguaje natural: https://www.cs.us.es/cursos/ia2/temas/tema-06.pdf
Marz, N., & Warren, J. (2015). Principles and best practices of scalable real-time data
systems. 284-295.
MathWorks. (2018). MathWorks. Recuperado el 30 de 05 de 2018, de Aprendizaje
automático: https://es.mathworks.com/discovery/machine-learning.html
Microsoft. (06 de Octubre de 2017). Arquitecturas de aplicaciones web comunes.
Obtenido de ¿Qué es una aplicación monolítica?: https://docs.microsoft.com/es-
es/dotnet/standard/modern-web-apps-azure-architecture/common-web-
application-architectures
Microsoft. (2018). Windows Dev Center. Recuperado el 01 de Junio de 2018, de
Conexión con WebSockets: https://msdn.microsoft.com/es-
xl/library/windows/apps/hh761442.aspx
Microsoft Corporation. (20 de 11 de 2017). The Importance of Potential Parallelism.
Recuperado el 11 de 05 de 2018, de https://msdn.microsoft.com/en-
us/library/ff963542.aspx
Mozilla. (22 de Diciembre de 2016). MDN web docs. Obtenido de WebSockets:
https://developer.mozilla.org/es/docs/WebSockets-840092-dup
MuleSoft (Ed.). (11 de 05 de 2018). MuleSoft. Obtenido de Microservices vs Monolithic
Architecture: https://www.mulesoft.com/resources/api/microservices-vs-
monolithic
Newberry, C. (2 de Febrero de 2018). Hootsuite. Obtenido de BLOG/SOCIAL:
https://blog.hootsuite.com/social-media-for-business/
Núñez Mora, A. (30 de Julio de 2006). Centro de Investigación en Matemáticas, A. C. .
Obtenido de Proceso para el desarrollo de Arquitecturas de Software basado en
DFSS:
https://cimat.repositorioinstitucional.mx/jspui/bitstream/1008/89/2/TE%20197.pd
f
75
Oracle Corporation. (2013). Big Data & Analytics Reference Architecture. Oracle
Enterprise Transformation Solutions Series, 26-28.
Pllana, S., Janciak, I., Brezany, P., & Wohrer, A. (2011). A Survey of the State of the Art
in Data Mining and Integration Query Languages. International Conference on
Network-Based Information Systems, 1. Obtenido de
https://arxiv.org/pdf/1603.01113.pdf
Psaltis, A. G. (2017). Streaming Data. Manning Publications Co.
Psikipedia. (2017). Fundamentos de investigación en Psicología. Obtenido de 5.1.
Definición, características y objetivo del método experimental:
https://psikipedia.com/libro/investigacion/1537-definicion-caracteristicas-y-
objetivo-del-metodo-experimental
Requena Santos, F. (1989). El concepto de red social. Centro de Investigaciones
Sociologicas. doi:10.2307/40183465
RV, R. (2016). Spring Microservices. Birmingham B3 2PB, UK: Packt Publishing.
SanDisk. (2018). ACCELERATING BIG DATA – USING SANDISK SSDS FOR
MONGODB WORKLOADS. Obtenido de
https://www.sandisk.com/business/datacenter/resources/white-
papers/accelerating-big-data-using-sandisk-ssds-for-mongodb-workloads
Socialbakers. (Marzo de 2018). Socialbakers. Obtenido de Social Media Ecosystem:
https://www.facebook.com/socialbakers/photos/a.204223294743.161503.16492
9129743/10156383157034744/?type=3&theater
StipczyNski, m. P.-P. (2006). A brief introduction to paralle compuntig . University of
Iowa.
Syosset. (1999). Computer science: Questions and answers. NY: National Learning.
Vara Horna, A. (2012). 7 Pasos para una tesis exitosa. En Desde la idea inicial hasta la
sustentación (págs. 210-212). Lima, Perú: Facultad de Ciencias Administrativas
y Recursos Humanos.
Vargiu, E., & Urru, M. (2013). Exploiting web scraping in a collaborative filtering- based
approach to web advertising. Artificial Intelligence Research, 2(1).
doi:https://doi.org/10.5430/air.v2n1p44
76
WHITE, W. (2014 de Abril de 2014). PARAGON. Obtenido de What is Data Enrichment?
Improving Your Data to Add Value: http://www.consultparagon.com/blog/what-is-
data-enrichment-improving-your-data-to-add-value