Arquitectura Big Data

Arquitectura Big Data
en Cloud para el
estudio del
suministro de agua
MEMORIA DEL PROYECTO
Trabajo de Fin de Grado

Cuatrimestre de Primavera 2018/2019
DIRECTOR: JORDI SABATER PICAÑOL — EVERIS

MENTOR: XAVIER FRANCH GUTIÉRREZ — DEPARTAMENTO DE INGENIERÍA DE SERVICIOS Y SISTEMAS DE INFORMACIÓN
Jacobo Moral Buendía

GRADO EN INGENIERÍA INFORMÁTICA
ESPECIALIDAD DE INGENIERÍA DEL SOFTWARE
1 DE JULIO DE 2019
PROYECTO REALIZADO EN EVERIS
Arquitectura Big Data en Cloud para
el estudio del consumo de agua
Resumen
Big data y cloud son dos conceptos muy utilizados en el contexto de la ingeniería informática. En este
trabajo diseño una arquitectura en cloud enfocada al tratamiento de big data e implemento, en la
medida de lo posible, debido a la escasez de recursos, un sistema con esta arquitectura.
Concretamente, estudio, analizo y comparo tres de las plataformas más grandes y utilizadas de ser-
vicios cloud del mercado: Amazon Web Services, Google Cloud Platform y Microsoft Azure. La com-
paración se hace respecto a una arquitectura previamente diseñada, escogiendo los servicios que
más se ajustan a esta de cada una de las plataformas. Una vez se ha escogido una, se implementa un
sistema-demostración con esta arquitectura, utilizando principalmente Java.
La arquitectura está diseñada alrededor de dos casos de uso sobre datos provenientes de contadores
domésticos de agua: un sistema de predicción de la estimación de consumo de agua mensual y uno
de detección de fugas de agua en tiempo real.
Resum
Big data i cloud són dos conceptes molt utilitzats en el context de l'enginyeria informàtica. En aquest
treball, dissenyo una arquitectura en cloud enfocada al tractament de big data i implemento, el més
semblant possible i amb pocs recursos, un sistema amb aquesta arquitectura.
Concretament, estudio, analitzo i comparo tres de les plataformes més grans i utilitzades de serveis
cloud del mercat: Amazon Web Services, Google Cloud Platform i Microsoft Azure. La comparació es
fa respecte a una arquitectura prèviament dissenyada, triant els serveis que més s'ajusten a cadas-
cuna d’aquestes plataformes. Una vegada s'ha triat una, s’implementa un sistema-demostració amb
aquesta arquitectura, utilitzant principalment Java.
L'arquitectura està dissenyada al voltant de dos casos d'ús sobre dades provinents de comptadors
domèstics d'aigua: un sistema de predicció de l’estimació de consum d'aigua mensual i un de detec-
ció de fuites d'aigua en temps real.
Abstract
Big data and cloud are two commonly used concepts in the context of Computer Engineering.
Throughout this project, I design a cloud-based architecture focused on big data treatment and I also
implement a system with this same architecture, where possible, due to having scarce resources.
Specifically, I study, analyze and compare three of the largest and most used cloud-based service
platforms on the market: Amazon Web Services, Google Cloud and Microsoft Azure. The comparison
is done with regard to a previously designed architecture, selecting the most suitable services for
each of the platforms. Once a platform is chosen, a demo system is implemented using the afore-
mentioned architecture while primarily using Java.
The architecture is designed around two cases of use regarding household water meter-originated
data: a monthly water consumption estimation system and a water leak detection one.
2
Índice de contenido
1 Introducción y contexto _______________________________________________________ 9
1.1 Big data________________________________________________________________ 9
1.1.1 Problemas principales de los sistemas tradicionales __________________________ 10
1.1.2 Propiedades de los sistemas Big Data _____________________________________ 11
1.1.3 Infraestructura _______________________________________________________ 12
1.2 Cloud ________________________________________________________________ 13
2 Formulación del problema ____________________________________________________ 16
2.1 Objetivo ______________________________________________________________ 16
2.2 Partes interesadas ______________________________________________________ 16
2.3 Alcance _______________________________________________________________ 17
2.3.1 Riesgos _____________________________________________________________ 18
3 Estado del arte _____________________________________________________________ 19
3.1 Big Data ______________________________________________________________ 19
3.2 Cloud ________________________________________________________________ 19
3.3 Predicción del consumo __________________________________________________ 20
3.4 Detección de fugas ______________________________________________________ 21
4 Metodología _______________________________________________________________ 22
5 Planificación _______________________________________________________________ 24
5.1 Descripción de las tareas y recursos ________________________________________ 24
5.1.1 Descripción de cada una de las fases y subfases _____________________________ 24
5.1.2 Resumen de tareas____________________________________________________ 26
5.2 Diagrama de Gantt ______________________________________________________ 27
5.3 Plan de acción y valoración de alternativas ___________________________________ 28
6 Presupuesto y sostenibilidad __________________________________________________ 29
6.1 Análisis del presupuesto _________________________________________________ 29
6.1.1 Recursos humanos ____________________________________________________ 29
6.1.2 Recursos materiales ___________________________________________________ 30
6.1.3 Recursos digitales_____________________________________________________ 31
6.1.4 Precio del producto y viabilidad__________________________________________ 31
6.2 Control de desviaciones __________________________________________________ 32
6.2.1 Control de desviaciones ________________________________________________ 32
6.2.2 Indicadores de desviaciones ____________________________________________ 32
6.3 Sostenibilidad __________________________________________________________ 33
3
6.3.1 Sostenibilidad económica ______________________________________________ 33

6.3.2 Sostenibilidad social ___________________________________________________ 34
6.3.3 Sostenibilidad medioambiental __________________________________________ 34
7 Requisitos del sistema _______________________________________________________ 36
7.1 Requisitos funcionales ___________________________________________________ 36
7.1.1 Casos de uso_________________________________________________________ 36
7.1.2 Comportamiento de los contadores de agua________________________________ 37
7.2 Requisitos no funcionales ________________________________________________ 37
7.2.1 Usabilidad___________________________________________________________ 37
7.2.2 Fiabilidad ___________________________________________________________ 37
7.2.3 Eficiencia y escalabilidad _______________________________________________ 37
7.2.4 Mantenibilidad _______________________________________________________ 37
7.2.5 Seguridad ___________________________________________________________ 37
7.2.6 Privacidad ___________________________________________________________ 37
8 Fujo de datos y especificaciones del sistema ______________________________________ 39
8.1 Flujo de datos __________________________________________________________ 39
8.1.1 Ingesta _____________________________________________________________ 39
8.1.2 Almacenamiento _____________________________________________________ 41
8.1.3 Procesamiento _______________________________________________________ 44
8.1.4 Explotación __________________________________________________________ 46
8.1.5 Arquitectura del sistema _______________________________________________ 48
9 Análisis de arquitecturas______________________________________________________ 49
9.1 Microsoft Azure ________________________________________________________ 49
9.1.1 Herramientas de mensajería ____________________________________________ 49
9.1.2 Almacenamiento de datos no estructurados________________________________ 50
9.1.3 Bases de datos _______________________________________________________ 50
9.1.4 Procesamiento y análisis de datos ________________________________________ 51
9.1.5 Plataforma de microservicios____________________________________________ 51
9.1.6 Esquema final ________________________________________________________ 53
9.1.7 Precio ______________________________________________________________ 53
9.2 Google Cloud Platform ___________________________________________________ 54
9.2.3 Conector de entrada con almacenamiento de datos _________________________ 55
9.2.4 Bases de datos _______________________________________________________ 55
4

9.2.7 Esquema final ________________________________________________________ 58
9.2.8 Precio ______________________________________________________________ 59
9.3 Amazon Web Services ___________________________________________________ 60
9.3.3 Bases de datos _______________________________________________________ 61
9.3.6 Esquema final ________________________________________________________ 63
9.3.7 Precio ______________________________________________________________ 63
9.4 Comparación de las arquitecturas y elección _________________________________ 64
10 Desarrollo de la arquitectura ________________________________________________ 67
10.1 Implementación paso a paso ______________________________________________ 67
10.1.1 Creación de una cuenta de Google Cloud Platform_________________________ 67
10.1.2 Simulación de trazas e ingesta de datos _________________________________ 67
10.1.3 Integración de Cloud Storage en el sistema ______________________________ 70
10.1.4 Integración de Cloud Dataproc ________________________________________ 71
10.1.5 Integración de Cloud Datastore ________________________________________ 78
10.1.6 Recepción y muestra de resultados con App Engine ________________________ 79
10.2 Patrones de diseño utilizados _____________________________________________ 80
10.2.1 Patrones implementados _____________________________________________ 81
10.2.2 Patrones utilizados__________________________________________________ 83
10.3 Problemas durante el desarrollo ___________________________________________ 83
10.3.1 Problemas de versiones ______________________________________________ 83
10.3.2 Problemas de dependencias __________________________________________ 84
10.3.3 Problema para cargar el modelo en la aplicación Java ______________________ 85
11 Planificación final _________________________________________________________ 87
11.1 Recursos utilizados ______________________________________________________ 87
11.2 Planificación temporal ___________________________________________________ 87
12 Retrospectiva y conclusión __________________________________________________ 90
12.1 Integración de conocimientos _____________________________________________ 90
12.2 Justificación de competencias técnicas ______________________________________ 91
12.3 Trabajo futuro _________________________________________________________ 91
5
12.4 Retrospectiva y conclusión________________________________________________ 92

13 Referencias y bibliografía ___________________________________________________ 93
Anexos_______________________________________________________________________ 102
Imágenes ampliadas __________________________________________________________ 102
Índice de tablas
Tabla 1. Recursos comunes para todas las fases del proyecto. ____________________________ 24
Tabla 2. Resumen de las tareas y dependencias entre ellas. ______________________________ 27
Tabla 3. Coste de los recursos humanos. _____________________________________________ 30
Tabla 4. Coste de los recursos materiales. ____________________________________________ 30
Tabla 5. Coste total de los recursos. _________________________________________________ 31
Tabla 6. Coste de venta del producto. _______________________________________________ 32
Tabla 7. Matriz de sostenibilidad. ___________________________________________________ 33
Tabla 8. Cantidad de datos a ingerir por el sistema _____________________________________ 41
Tabla 9. Campos de los que constará la base de datos del sistema. ________________________ 43
Tabla 10. Tamaño medio de cada campo de la base de datos. ____________________________ 43
Tabla 11. Tiempo de procesamiento para Stream y Batch ________________________________ 45
Tabla 12. Requerimientos de las instancias para el procesamiento en batch _________________ 45
Tabla 13. Requerimientos de las instancias para el procesamiento en stream ________________ 46
Tabla 14. Resumen de requerimientos para el procesamiento de los datos __________________ 46
Tabla 15. Desglose de precios para la arquitectura de Microsoft Azure. _____________________ 54
Tabla 16. Desglose de precios para la arquitectura de Google Cloud Platform. _______________ 59
Tabla 17. Comparación de los distintos servicios de almacenamiento de AWS. _______________ 61
Tabla 18. Desglose de precios para la arquitectura de Amazon Web Services. ________________ 64
Tabla 19. Correspondencia de criterios de comparación con su código identificador. __________ 65
Tabla 20. Comparación de las AWS, Azure y GCP. ______________________________________ 65
Tabla 21. Recordatorio de recursos totales de la planificación inicial. _______________________ 87
Tabla 22. Recursos añadidos con respecto a la planificación inicial. ________________________ 87
Tabla 23. Comparación del desglose de la Fase 3 de la planificación temporal inicial con la misma
una vez acabado el proyecto. ______________________________________________________ 88
6
Índice de figuras
Figura 1. Evolución de la cantidad de búsquedas del concepto «Big Data» en Google con respecto al
máximo. Datos extraídos de Google LLC, 2019, Google Trends. ____________________________ 9
Figura 2. Clasificación de los tipos de computación distribuida. Kahanwal, Brijender; Singh, Tejinder
Pal, 2012, International Journal of Latest Research in Science and Technology, 1(2), p.183. _____ 13
Figura 3 Evolución de la cantidad de búsquedas de los principales proveedores de servicios Cloud
en Google con respecto al máximo. Datos extraídos de Google LLC, 2019, Google Trends. ______ 13
Figura 4. Características de IaaS, PaaS y SaaS. Imagen extraída de la web de Microsoft Azure, 2018,
y modificada. Usada con el permiso de Microsoft. _____________________________________ 14
Figura 5. Línea de tiempo de tecnologías Big Data. Obtenida de Paradigma Digital y usada con el
permiso de Paradigma Digital S. L., de acuerdo con su aviso legal y política de privacidad. ______ 19
Figura 6. Posicionamiento de diversos proveedores de servicios Cloud según Gartner. Imagen
extraída de Gartner, 2018, Gartner, Inc.______________________________________________ 20
Figura 7. Diagrama de Gantt de la planificación temporal del proyecto. Generado mediante
Microsoft Project. Imagen ampliada en Anexo 1._______________________________________ 27
Figura 8. Representación esquemática de los nodos con que contará el sistema de procesamiento.
Imagen ampliada en Anexo 2.______________________________________________________ 46
Figura 9. Comparación de Azure Virtual Machines, Azure Cloud Services y Azure Web Apps en
control, soporte para aplicaciones antiguas, facilidad de gestión y agilidad. Datos recopilados en la
web de CloudAcademy (Badola, 2015). ______________________________________________ 53
Figura 10. Diagrama del flujo de datos de la arquitectura utilizando Microsoft Azure. Imagen
ampliada en Anexo 3. ____________________________________________________________ 53
Figura 11. Árbol de decisión de opciones de almacenamiento de Google Cloud Platform. Imagen
extraída de la web de Google Cloud, 2017, y traducida. Usada con el permiso de Google. Imagen
Figura 12. Árbol de decisión de opciones para cómputo y despliegue de aplicaciones de Google
Cloud Platform. Imagen extraída de la web de Google Cloud, 2017, modificada y traducida. Usada
con el permiso de Google. ________________________________________________________ 58
Figura 13. Diagrama del flujo de datos de la arquitectura utilizando Google Cloud Platform. Imagen
Figura 14. Diagrama de flujo de datos de la arquitectura utilizando Amazon Web Services. Imagen
ampliada en Anexo 6Error! Reference source not found.. ________________________________ 63
Figura 15. Diagrama básico de flujo de Google Cloud Pub/Sub. Imagen usada con el permiso de
Google bajo la licencia Creative Commons Attribution 4.0 License. _________________________ 68
7
Figura 16. Captura del diagrama de flujo de los datos de Google Cloud Dataflow en pleno
funcionamiento. ________________________________________________________________ 71
Figura 17. Representación esquemática de las operaciones realizadas sobre los datos iniciales en la
aplicación de Spark en batch sobre un ejemplo simple.__________________________________ 73
Figura 18. Comparación de nombres de los conceptos de Cloud Datastore y una base de datos
relacional típica. ________________________________________________________________ 78
Figura 19. Esquema de los diferentes microservicios del sistema. Imagen ampliada en Anexo 7. _ 80
Figura 20. Esquema de los diferentes microservicios del sistema. Imagen ampliada en Anexo 7. _ 80
Figura 21. Representación en UML del patrón Singleton utilizado en la clase Datastore. ________ 82
Figura 22. Diagrama que muestra el funcionamiento del patrón model-view-controller (MVC). __ 82
8
1 Introducción y contexto
«Los datos son el nuevo petróleo» (Humby, 2006). Muchos de nosotros hemos leído u oído esta frase
y, aunque existe mucha controversia al respecto de esta, yo no puedo estar más de acuerdo.
Y es que, como el crudo1, los datos en masa no tienen demasiada utilidad si no están previamente
procesados (Palmer, 2006). Una vez procesados y convertidos en materia útil y tratable, es cuando
ganan su valor de mercado
Sin embargo, existen dos grandes diferencias entre el petróleo y los datos. La primera es que el pe-
tróleo se puede almacenar indefinidamente hasta darle uso, sin perder valor más que aquel derivado
de la oferta y la demanda. Los datos, por otro lado, tienen una fecha de caducidad que varía según
el tipo de datos que tratemos. Puede ir desde muchas decenas de años, como puede ser en el caso
de unos datos sobre el historial de temperaturas en el continente antártico, hasta pocos minutos o
incluso segundos, por ejemplo, en unos datos sobre una alerta de atentado terrorista.
La segunda gran diferencia es que el petróleo es un recurso limitado, mientras que los datos provie-
nen de una fuente ilimitada. Y no solo es ilimitada, sino que, como sugiere un estudio (Cisco, 2018)
cada año se generan más datos e información que el anterior. De hecho, llega un momento que la
cantidad de datos a tratar y almacenar es tal que se convierte en inviable la opción tradicional. Y es
aquí donde introduciré un concepto clave para el proyecto: big data.
1.1 Big data

Aunque el término no es nuevo (se utiliza desde la década de los noventa —hay quien le da el crédito
del término a John Mashey, como Steve Lohr (2013) en su blog para el New York Times—), ha ido
obteniendo popularidad, sobre todo en los últimos años, como podemos observar en la Figura 1.
100
90
80
70
60
50
40
30
20
10
0
Figura 1. Evolución de la cantidad de búsquedas del concepto «Big Data» en Google con respecto al máximo. Datos extraídos de
Google LLC, 2019, Google Trends.
1
Petróleo crudo o, simplemente, petróleo.
9
Big data no es un concepto fácil de definir. De hecho, hace referencia a más de una idea. Por un lado,
big data es el conjunto de todos aquellos datos o datasets2 que, debido a su gran tamaño, no es
factible de tratar con las ideas, herramientas y enfoque tradicionales.
Por otro lado, big data es, a su vez, el paradigma en el que se trabajan estos datos, incluyendo estos
y también las herramientas e infraestructura necesarias para almacenarlos, procesarlos y estudiarlos
(software y hardware).
1.1.1 Problemas principales de los sistemas tradicionales

Las tecnologías tradicionales han demostrado no estar preparadas para afrontar los datos a una es-
cala masiva. Estas tecnologías presentan dos grandes problemas en estas circunstancias de grandes
cantidades de datos: la escalabilidad del sistema respecto al procesamiento de los datos y la escala-
bilidad respecto a la cantidad de datos a almacenar.
En esta sección estudiaremos estos dos problemas.
1.1.1.1 Escalabilidad de procesamiento

La arquitectura basada en un sistema centralizado de las tecnologías tradicionales tiene un gran pro-
blema en cuanto a la eficiencia en el tiempo a la hora de procesar grandes cantidades de datos. A
medida que estas cantidades de datos aumentan, se crea un bottleneck3 en la máquina principal y,
por tanto, el rendimiento de todo el sistema se ve muy afectada.
Una posible solución a este problema es la mejora de las partes o piezas del sistema. Esto se conoce
como escalabilidad vertical. Es decir, a medida que un sistema tiene más datos para tratar y este
necesita más potencia, se mejora cada una de las partes del sistema sin aumentar el número de
piezas que lo componen, para lograr un mayor rendimiento. Sin embargo, a medida que aumenta
más y más el tamaño del problema a calcular (en el caso del big data, la cantidad de datos a tratar),
se hace inviable esta opción debido al coste cada vez más elevado de máquinas tan potentes (e in-
cluso inexistentes en el mercado).
Esto nos lleva a una segunda opción, llamada escalabilidad horizontal. Mediante esta, el sistema
crece en número de componentes, en vez de potencia de cada uno de estos. Esta solución tiene una
clara ventaja respecto a la anterior. Esta vez no habrá un límite de potencia para el sistema, ya que
el número de máquinas o componentes que se pueden tener es prácticamente ilimitado. Como dijo
una vez Grace Hopper (1987) —ampliamente considerada abuela del mítico lenguaje de programa-
ción COBOL—, en tiempos pioneros, se usaban bueyes para tirar de cosas pesadas, y cuando un buey
no podía mover un tronco, no intentaban crecer un buey más grande. No deberíamos intentar, pues,
construir ordenadores más grandes, sino intentar conseguir más sistemas de ordenadores.
Sin embargo, nace un problema que antes no teníamos, o era inapreciable. Y es que, cuando el nú-
mero de máquinas es muy grande, el overhead4 resultante de la comunicación entre estas también
crece.
2
También data set, colección de datos de un mismo tema concreto.
3
También llamado cuello de botella. Parte o pieza de un sistema que ralentiza el funcionamiento del sis-
tema completo.
4
Exceso de recursos (generalmente tiempo) que se dedican a una tarea.
10
Las tecnologías big data solucionan este problema con un nuevo paradigma de computación basado
en la distribución del sistema dentro de una red. Esta está optimizada para la escalabilidad horizon-
tal. De esta manera, se divide el trabajo inicial en tareas más pequeñas, que las realizarán las dife-
rentes máquinas que componen el sistema.
En tiempos pioneros, se usaban bueyes para tirar de cosas pesadas, y cuando un buey no podía mo-
ver un tronco, no intentaban crecer un buey más grande. No deberíamos intentar, pues, construir
ordenadores más grandes, sino intentar conseguir más sistemas de ordenadores.
1.1.1.2 Escalabilidad de almacenamiento

Debido al paradigma centralizado usado frecuentemente en los sistemas tradicionales, el incremento
de almacenamiento disponible en estos no es una tarea trivial. En este caso, las dos posibilidades
para aumentar dicho almacenamiento son las mismas que para aumentar la capacidad de procesa-
miento del sistema: escalar vertical y horizontalmente. Además, funcionan de igual manera que pre-
viamente; aumentando la capacidad de cada uno de los componentes del sistema y aumentando el
número de componentes, respectivamente.
De igual forma que en el caso anterior, también, las tecnologías big data aprovechan la escalabilidad
horizontal para, bajo demanda o necesidad, aumentar fácilmente la capacidad total del sistema.
Por otro lado, se debe tener en cuenta el almacenamiento usado para mantener la tolerancia a erro-
res en el sistema. Se puede conseguir de varias maneras. La más sencilla es mediante la redundancia
de datos, es decir, copiándolos y guardando ambas copias (o más de dos). Al número de copias que
se guardan de cada dato se le llama factor de replicación. El más común es tres. Además, es aconse-
jable guardar las diferentes copias en máquinas distintas, para salvar los datos en caso de fallo de la
máquina entera, y no solamente del disco. Incluso, en compañías con más recursos, una buena prác-
tica es guardar los datos en sistemas o data centers5 distintos. Esto, en caso de catástrofe, prevendría
la afectación de los datos en caso de catástrofe o daño mayor.
1.1.2 Propiedades de los sistemas Big Data

Aunque, como he indicado anteriormente, big data no es un término concreto y bien especificado,
existen tres propiedades ampliamente reconocidas que definen bien un sistema big data, propuestas
por primera vez por Doug Laney (2001). Estas, conocidas como «las tres V» son volumen, velocidad
y variedad.
1.1.2.1 Volumen
La cualidad probablemente más inherente de un sistema big data es su capacidad para tratar grandes
volúmenes de información y datos. No existe ninguna definición que requiera una cantidad mínima
de datos a tratar para poder añadir la etiqueta big data a un sistema. Sin embargo, típicamente os-
cilaría entre decenas de terabytes y decenas e incluso centenares de petabytes6, en las compañías
más grandes.
Tratar con estas cantidades de datos es un reto que implica la necesidad de trabajar con diferentes
máquinas interconectadas, ya sea en cloud, mediante clústeres u otra arquitectura. Además, abre un
nuevo problema, que es el requisito de buscar nuevos métodos y algoritmos que permitan la división
5
También llamado centro de procesamiento de datos, comúnmente abreviado CPD), es un espacio des-
tinado a almacenar y procesar grandes tamaños de datos.
6
1015 bytes, o 1000 terabytes.
11
de tareas grandes en diferentes subtareas, permitiendo así la ejecución en diferentes máquinas de

forma concurrente.
1.1.2.2 Velocidad
Los inmensos volúmenes de datos anteriormente mencionados crean la necesidad de una gran po-
tencia de cómputo, que proporcione suficiente velocidad al sistema para poder ejecutar los procesos
que se han de ejecutar.
Sin la velocidad requerida por el sistema, se crearía un bottleneck, ya que los datos se procesarían a
un ritmo más lento del que se ingieren nuevos. Este problema se intensifica en el caso de que el
sistema trabaje con un enfoque de tiempo real, en el cual la velocidad con que se tratan los datos es
un factor primordial. Por ejemplo, una de estas situaciones podría ser el tratado de datos para la
bolsa. En este caso, unos minutos, o incluso, segundos, de más podría ser determinante para llegar
tarde en una operación en la que se puede ver involucrado mucho dinero.
1.1.2.3 Variedad
Comúnmente, a los sistemas big data llega información y datos de tipos y estructuras muy dispares,
provenientes de fuentes también diferentes las unas de las otras.
Al contrario que en el paradigma tradicional de los datos, big data a menudo no recoge información
estructurada y previamente procesada o limpiada.
Por último, la fácil adaptación a la variedad de las fuentes de información y datos de los sistemas big
data abre la puerta a tratar información como mensajes de usuarios de redes sociales y otros textos
libres para realizar minería de opinión sobre estos usuarios. Otros tipos de datos que se podrían
tratar son vídeos e imágenes, con los que extraer información acerca de delincuencia o fragmentos
de archivos de audio y sonido.
1.1.2.4 Otras propiedades de Big Data

Diversas fuentes y autores hablan, además de las tres propiedades anteriormente explicadas, de
otras cualidades presentes en sistemas big data. Sin embargo, debido a su naturaleza no presente
en todos los sistemas o a que no son exclusivas de estos, no hay un consenso como sí lo hay en las
tres anteriores. No obstante, he recogido aquellas cualidades que más se repiten entre las diferentes
fuentes. Estas son veracidad, validez, volatilidad, variabilidad y valor.
1.1.3 Infraestructura
Para desarrollar y llevar a cabo un mantenimiento y funcionamiento óptimos de los sistemas Big
Data, es necesario basarla sobre una infraestructura diseñada para ello. Para empezar, necesitare-
mos utilizar una infraestructura distribuida para poder esquivar los problemas que he mencionado
antes de la computación centralizada tradicional.
Los principales paradigmas de computación distribuida son, como muestra la Figura 2, los siguientes:
P2P, Grid, Cluster, Cloud y Jungle.
Debido a la facilidad de administrar los recursos, su bajo coste y su alto rendimiento con respecto a
sus competidores, en el proyecto utilizaremos una infraestructura montada en cloud.
12
Figura 2. Clasificación de los tipos de computación distribuida. Kahanwal, Brijender; Singh,

Tejinder Pal, 2012, International Journal of Latest Research in Science and Technology, 1(2),
p.183.
1.2 Cloud
De igual manera que con big data, cloud no es un concepto bien definido y cerrado. El cloud podría
verse como un paradigma computacional y de almacenamiento en el cual el usuario se conecta con
un servicio externo. Esta conexión se realiza habitualmente mediante APIs7.
100
90
80
70
60
50
40
30
20
10
0
Amazon Web Services: (Worldwide) Google Cloud Platform: (Worldwide)

Microsoft Azure: (Worldwide)
Figura 3 Evolución de la cantidad de búsquedas de los principales proveedores de servicios Cloud en Google con respecto al máximo.
Datos extraídos de Google LLC, 2019, Google Trends.
7
En singular, API y, del inglés, Application programming interface, es un conjunto de funciones y méto-
dos que se ofrece para ser utilizado externamente por otro software.
13
Existen diferentes niveles de abstracción del usuario, según el servicio que este escoja. Existen mu-
chos, aunque hay tres que destacan del resto como principales:
• Infraestructura como servicio (IaaS, del inglés «Infraestructure as a service»). Este servicio
ofrece al usuario el control sobre detalles de bajo nivel de las máquinas (ubicación, cantidad
de memoria, sistema operativo, etc.).
• Plataforma como servicio (PaaS, del inglés «Platform as a service»). El usuario tiene la posi-
bilidad de utilizar la infraestructura de cloud para desplegar aplicaciones propias o de otros
proveedores, utilizando lenguajes de programación, librerías y otros servicios. De esta ma-
nera, el usuario se abstrae del mantenimiento y configuración del servidor para únicamente
centrarse en el desarrollo de la aplicación.
• Software como un servicio (SaaS, del inglés «Software as a service»). Al usuario se le ofrece
la capacidad de ejecutar aplicaciones en la infraestructura cloud (Mell & Grance, 2011). Estas
aplicaciones, a diferencia de PaaS, no son desarrolladas por el usuario, sino que se le ofrecen
completas. La oferta de estos servicios es muy amplia, y puede ser de muchos tipos, desde
herramientas de productividad (como Microsoft Office o Google Drive) hasta servicios de
correo electrónico (Microsoft Outlook o Gmail) o de almacenamiento «en la nube» (como
Dropbox, OneDrive o Google Drive).
En la Figura 4, podemos ver un esquema de las características de los tres tipos de uso del cloud an-
teriormente explicados, así como las diferencias entre estos.
Figura 4. Características de IaaS, PaaS y SaaS. Imagen extraída de la web de Microsoft Azure, 2018, y modificada. Usada con el
permiso de Microsoft.
Se debe tener en cuenta que cloud hace únicamente referencia a la forma en que se acceden a unos
recursos que están alojados en otro lugar por vía de un proveedor externo en forma de servicio. De
tal manera que no hace referencia a la forma física en la que estos recursos están alojados. Por ejem-
plo, una infraestructura cloud podría estar compuesta por clústeres de máquinas.
14
Las mayores ventajas de cloud son la flexibilidad del servicio, el bajo precio de su coste de manteni-
miento y la eficiencia del servicio obtenido. También la escalabilidad del servicio en un tiempo muy
reducido y la tolerancia a caídas (habitualmente las caídas son detectadas por el proveedor del ser-
vicio y contrarrestadas con el levantamiento de un servicio equivalente).
Además, en los últimos tiempos, con la irrupción de cada vez más empresas emergentes en el mer-
cado —y empresas pequeñas que quieren entrar al «mundo» de las nuevas tecnologías y la moder-
nización—, el cloud es una solución muy beneficiosa que les permite poder contar con tecnología
punta y de última generación con un coste relativamente bajo y, sobre todo, sin hacer una gran in-
versión inicial de capital.
Sin embargo, tiene algunas desventajas. Las principales son el control limitado de los servicios —
pues el usuario no es dueño de las máquinas— y la incertidumbre de la localización de los archivos.
Este último puede conllevar problemas según el Reglamento General de Protección de Datos de la
Unión Europea (European Parliament, 2016).
Su alternativa tradicional es ejecutar el software necesario en máquinas propias en las propias ins-
tancias de la empresa o compañía —on premises—. Si bien esta alternativa suele no ser la óptima
para la mayoría de los casos, sí resulta interesante para aquellos casos en los que la empresa ya
disponga de las máquinas con anterioridad y no requiera de la flexibilidad que ofrece cloud. También,
para aquellos en los que, por motivos de protección de datos, no puedan almacenar datos en servi-
dores ajenos.
15
2 Formulación del problema

Enfocaré este proyecto al estudio de las tecnologías que he mencionado anteriormente —big data y
cloud— y al desarrollo de una aplicación de apoyo para los usuarios de la red de abastecimiento de
agua potable. A continuación, entraré en más detalle.
2.1 Objetivo
Pueden destacarse tres claros objetivos en este proyecto. El primero es aprender sobre las diferentes
herramientas, tecnologías y proveedores de cloud y de big Data, haciendo un estudio de tres de los
proveedores más grandes en el mercado actualmente —Google, Amazon y Microsoft—.
El segundo objetivo es el más importante de los tres y es diseñar un sistema utilizando servicios de
uno de los proveedores anteriores. Este sistema estará dirigido a empresas de agua y solucionará
problemas originados en el uso diario de los usuarios del suministro de agua. El sistema recogerá
información y datos sobre el uso, suministro y facturación del agua de la empresa para procesarla y
producir una respuesta. Distinguiremos dos casos de uso de nuestro sistema:
• Predicción del consumo mensual. Esta funcionalidad permitirá al usuario saber en todo mo-
mento cuál será la siguiente factura con un alto nivel de precisión. La intención es permitir
al usuario conocer el estado de su consumo cuando lo desee y del gasto que este conllevará
en la próxima factura. La ventaja principal será la anticipación a tiempo de cualquier desvia-
ción indeseada de su consumo de agua y, por consiguiente, de la factura.
• Detección de fugas de agua. Este caso de uso se centra más en el ahorro de agua a nivel
territorial, sin olvidar el gasto económico que conlleva la pérdida de agua. Mediante este,
tanto usuarios como la empresa serán informados sobre una posible fuga de agua en su
vivienda, así como de grifos abiertos involuntariamente. Se tratará de una detección a partir
de un modelo predictivo. Cabe destacar que la detección y el aviso a los interesados se rea-
lizarán en cuestión de minutos, para minimizar el impacto. De esta manera, los usuarios no
solo podrán ahorrar económicamente, sino que también podrán prevenir posibles contra-
tiempos en la vivienda. Además, también permitirá no desperdiciar un recurso tan escaso y
limitado en algunos lugares, como es el agua.
El tercer, y último, objetivo es implementar el sistema en un caso práctico a modo de POC (proof of
concept8). Debido a los escasos recursos del proyecto, el sistema se hará con los mismos servicios,
aunque limitados por el presupuesto de que se disponga (véase el apartado 6.1). Este objetivo se
centrará en crear un sistema lo más parecido posible al diseñado, sin poner el foco en la precisión de
los modelos predictivos, la velocidad general del sistema o la usabilidad de posibles interfaces de
usuario.
2.2 Partes interesadas

En los objetivos anteriormente explicados, podemos diferenciar claramente dos partes interesadas:
usuarios finales y empresas compradoras del sistema. Por otra parte, encontramos otros dos
stakeholders9 con respecto al equipo de desarrollo. Estos son Everis, la empresa desarrolladora, y el
8
En castellano, prueba de concepto. Es la implementación de una idea teórica para verificar su validez y
factibilidad.
9
En castellano, partes interesadas.
16
propio equipo encargado del desarrollo. Por último, encontramos otro stakeholder, que es la com-
pañía escogida para montar nuestro sistema en cloud.
A continuación, los explicaremos en detalle.
• Everis. Everis es uno de los principales interesados en el desarrollo del sistema. Tendrá que
dar apoyo al equipo de desarrollo. Además, tendrá que negociar con otros stakeholders,
como las empresas de suministro de agua. Por último, una vez acabado el desarrollo de la
aplicación/sistema, deberá decidir si mantendrá otro equipo —o el mismo— al cargo del
mantenimiento del sistema.
• Equipo desarrollador. Puesto que los integrantes del equipo de desarrollo —en este pro-
yecto se compondrán únicamente por mí— serán los encargados directos de la creación del
sistema.
• Empresas de suministro de agua. Estas empresas tendrán un alto grado de influencia sobre
las decisiones del proyecto y del sistema a crear. La negociación con estas será fundamental
para llevarlo a cabo.
• Usuarios de empresas de suministro de agua. Estos tendrán una gran influencia en el sis-
tema. Por una parte, influirán pasivamente durante la creación de la aplicación, ya que esta
se diseñará teniendo a los usuarios presentes en todo momento, optimizándola con el ob-
jetivo de satisfacerlos. Por otra parte, tendrán influencia activa mediante opiniones y críticas
sobre la aplicación, que determinarán posibles cambios y actualizaciones en el sistema.
• Compañía de servicios cloud. Tanto Google como Amazon o Microsoft influirán en el desa-
rrollo del proyecto. Los servicios que ofrecen, junto con los precios de estos, serán determi-
nantes a la hora de escoger un proveedor u otro. Esta elección influirá de una manera muy
alta al porvenir del proyecto.
• Medio ambiente. No es un stakeholder según la definición más tradicional, ya que no es una
persona ni física ni jurídica. Sin embargo, y ya que es un afectado más, he decidido incluirlo
debido a la situación actual del planeta. Por lo tanto, se intentará tener en cuenta el medio
ambiente en todas las decisiones del proyecto.
2.3 Alcance
Dada mi escasa experiencia en el tema escogido, no es tarea fácil definir con exactitud el tiempo que
durará cada una de las partes en las que se divide el proyecto. Por lo tanto, la duración total del
proyecto tampoco está definida. Dependiendo de la duración de cada una, el alcance del proyecto
se extenderá o reducirá ligeramente.
Sin embargo, hay unas fases definidas que sí se harán. La primera es una fase más teórica y de inves-
tigación. Esta es la parte más importante, y en ella se estudiarán las diferentes tecnologías que ofre-
cen cada uno de los tres grandes proveedores de servicios cloud. Estos son Google con su servicio
Google Cloud Platform, Microsoft con Microsoft Azure y Amazon con Amazon Web Services. Cada
una de estas plataformas ofrece una serie de servicios muy parecidos entre sí, pero con diferencias
que tendré que estudiar, esquematizar, comparar y, por último, decidir cuál se ajusta más a las ne-
cesidades del proyecto. Esto incluirá diseñar flujos de datos y modelos para cada uno de los provee-
dores. Esta fase es fundamental para el proyecto y se extenderá lo necesario en el tiempo.
Una vez realizado el estudio, comparadas las diferentes tecnologías y escogida una, será el turno de
plasmar la idea implementando el diseño anterior en un sistema real. Se creará una cuenta en la
plataforma y se adquirirán las tecnologías necesarias para llevarla a cabo. Además, se tendrán que
17
realizar los ajustes necesarios. Para ello, antes se tendrá que dedicar parte del tiempo a familiarizarse
con las herramientas propias del servicio. En esta fase también se realizará un pequeño servicio para
visualizar el contenido que será el resultado de las diferentes aplicaciones que realizaré. La impor-
tancia de esta segunda parte recaerá sobre el flujo de datos principal, y no sobre cada una de las
partes que lo componen.
2.3.1 Riesgos
Hay ciertos casos que hay que considerar como posibles factores de riesgo que pueden jugar en
contra del proyecto.
El primero es el tiempo. Es posible que, debido a la poca experiencia en el sector del cloud, una de
las fases o subfases se demore más de lo inicialmente previsto en la planificación temporal del pro-
yecto. Para solucionarlo, se tendrá que hacer un esfuerzo para intentar reajustar el tiempo.
Otro factor de riesgo para el proyecto es la gratuidad de los servicios. Debido al presupuesto del que
dispone el proyecto para gastar en servicios ofrecidos por las plataformas cloud —de cero euros—,
es indispensable que los servicios escogidos sean gratuitos o que, como mínimo, presenten un pe-
riodo de prueba gratis. Si no, habrá que buscar una solución en un tiempo muy reducido para no
retrasar el proyecto.
Por otra parte, otro factor de riesgo que tienen que ver con el desarrollo de las aplicaciones es el
estancamiento en alguna de las fases de la implementación y desarrollo del sistema de demostración
por algún error que no se consiga solucionar. Sin embargo, la probabilidad de encontrar un error no
solucionable en una parte crítica del sistema es muy baja, ya que es muy común el encuentro de
workarounds.
18
3 Estado del arte

En esta sección, analizaré la actualidad y últimos avances al respecto de los diferentes temas que
trataré en el proyecto: big data, cloud, predicción del consumo de agua u otros servicios y detección
de fugas de agua y de otros servicios.
3.1 Big Data

Hace ya unos años del auge del big data (véase Figura 1), por lo que podemos hacernos una idea
bastante clara de la evolución de este.
En 2004, Google publica un documento sobre un nuevo método para procesar grandes cantidades
de datos (Dean & Ghemawat). Este método, llamado MapReduce se basa en la distribución de los
datos a procesar entre diversas máquinas, para luego, concurrentemente, procesarlos. Este método
sería usado más tarde por el proyecto Hadoop, de Apache. Este proyecto se convertiría en un refe-
rente para el tratamiento del big data.
Más tarde, el 26 de mayo de 2014, el mismo Apache lanza Spark, un proyecto que trata de sustituir
Hadoop y su MapReduce, mejorando algunos problemas que presentaba. Esta herramienta es muy
potente y ampliamente usada para el procesamiento de datos, por lo que puede ser una pieza clave
y fundamental para el proyecto, por lo que tendré que considerarla y tenerla en cuenta.
Sin embargo, no solamente encontramos software libre y de código abierto en big data. Hasta enero
de este año, 2019, dos compañías importantes del sector eran Cloudera y Hortonworks. Sin embargo,
a partir del día 3 del mencionado mes, se han unido (Cloudera and Hortonworks Complete Planned
Merger , 2019).
En la siguiente figura, podemos ver una línea de tiempo de las tecnologías big data, desde 2002 hasta
2018.
Figura 5. Línea de tiempo de tecnologías Big Data. Obtenida de Paradigma Digital y usada con el permiso de Paradigma Digital S. L.,
de acuerdo con su aviso legal y política de privacidad.
3.2 Cloud
El comienzo del uso y la proliferación del cloud por parte de las empresas de todo el mundo son más
recientes que el big data. Sin embargo, ha entrado con fuerza en el mercado. De hecho, en este
momento se encuentra en su momento más alto si nos fijamos en las búsquedas en Google de los
principales proveedores de estos servicios, como podemos ver en la Figura 3.
19
Actualmente, existe una gran variedad de proveedores de cloud. Los principales son Microsoft, Ama-
zon, IBM, Salesforce y Google (Taylor, 2019). Estos ofrecen soluciones a muchos tipos de arquitectu-
ras, incluidas las de Big Data. Según la prestigiosa firma de investigación en tecnología, Gartner, las
tres compañías líderes del mercado del Cloud son Google, Amazon y Microsoft (Bala, Leong, & Smith,
2018), como podemos observar en la Figura 6.
Figura 6. Posicionamiento de diversos proveedores de servicios Cloud según Gartner. Imagen extraída de Gartner, 2018, Gartner,
Inc.
Este factor se ha tenido en cuenta a la hora de seleccionar los proveedores de servicios cloud en los
que basar el proyecto.
3.3 Predicción del consumo

En 2001, se publica un artículo sobre la predicción del consumo del agua en Córdoba (Caridad Ocerín,
Millán Vázquez de la Torre, & Dios Palomares). Sin embargo, este trabajo se centra en la predicción
de toda una ciudad y en períodos extensos de tiempo. Si bien, puede servirme de referencia para
inspirarme con las herramientas de predicción que usan.
20
Heejun Chang y Lily House-Peters publican, en 2011, en la Universidad del Estado de Portland, un
documento sobre el modelamiento de la demanda de agua urbana (Urban Water Demand Modeling:
Review of Concepts, Methods and Organizing Principles). En este, describen diversos factores que
pueden afectar al consumo de agua. Tener de referencia estos factores me puede resultar de gran
ayuda a la hora de realizar el modelo de predicción del consumo mensual, así como el modelo de
detección de fugas. Además, también los deberé tener en cuenta para decidir qué bases de datos
consultar.
No he encontrado ningún trabajo, estudio o proyecto sobre la predicción del consumo a nivel de
usuario y a corto plazo.
3.4 Detección de fugas

En 2014, se publica un documento sobre la detección de fugas en tuberías de gas usando modelos
hidráulicos (Bagajewicz & Valtinson). Los modelos matemáticos que usan logran reducir el error de
las predicciones del veintiuno al tres por ciento, en comparación con los modelos de software exis-
tentes.
En 2015, se desarrolla, a manos de Cristina Verde Rodarte, investigadora del Instituto de Ingeniería
de la Universidad Nacional Autónoma de México, un software para detectar fugas en cualquier tipo
de tubería (Phys.org, 2015). Este software tiene el nombre de VIVIUNAM, y sirve tanto para tuberías
de agua, como de petróleo o gas.
Una vez más, no he encontrado ningún documento sobre la detección de fugas de agua solamente
usando software y modelos predictivos que pueda usarse para instalaciones de usuarios. Si bien, uno
de los dos casos de uso que proponemos es muy parecido tanto al mencionado VIVIUNAM como al
modelo propuesto en 2014, estos no están enfocado —ni preparado— para su uso en una red de
tuberías a nivel de usuarios individuales o empresas pequeñas. Por lo tanto, este es un punto con el
que nuestro producto será distinto a cualquier otro en el mercado.
21
4 Metodología
El proyecto tendrá una duración de cinco meses, aproximadamente. Son muchos meses por delante,
acompañados de mucho trabajo. Además, la mayor parte de este se efectuará de manera individual.
Es, por tanto, primordial, establecer previamente unas bases que me servirán de guía a la hora de
trabajar.
Primeramente, la metodología que usaré durante el proyecto es Agile. Esta fue definida en 2001 por
un grupo de críticos de software mediante doce principios publicados en una web. Los principios se
resumen en la realización del proyecto mediante pequeños incrementos, dando mucha importancia
al trabajo en equipo. Además, la especificación del producto puede ir cambiando durante el proyecto
(Beedle et al.).
Dado que se trata de un proyecto cuyas especificaciones y límites son definidos por mí, encuentro
muy positivo el uso de esta metodología. La razón es que, dado mi falta de experiencia,
probablemente los requisitos y especificaciones iniciales serán muy diferentes a los finales, por lo
que preveo constantes cambios en estos.
Los doce principios de Agile definen la metodología a la vez que la dejan abierta y poco concreta. Es
por esto por lo que habitualmente se escogen frameworks10 dentro de esta metodología que con-
creten todos los aspectos necesarios. Dado que Agile es el trabajo en equipo, tendré que adaptarme
un poco y no hacer Agile puro. Cogeré como referencia los frameworks de Scrum y de Kanban.
Los sprints11 serán de una semana y trabajaré concurrentemente en dos vías paralelas, una más teó-
rica y de investigación y otra más práctica y de desarrollo. Realizaré dos reuniones semanales con el
director y responsable del proyecto en Everis. Cada una se centrará en una de las vías. De este modo,
cada semana se hará una reunión para tratar la vía teórica y otra para tratar la vía práctica. En estas
reuniones se revisará el progreso realizado durante la última semana, se proporcionará feedback12
de este y se propondrán tareas nuevas para realizar durante la semana siguiente. La asignación de
nuevo trabajo se consensuará entre el director y yo dependiendo del progreso avanzado hasta el
punto del proyecto en el que se encuentre, el tiempo disponible y el ritmo al que se avanza.
Por otro lado, utilizaré Microsoft Project como soporte para la administración del proyecto. Este me
permitirá gestionar el trabajo y las tareas que tengo que realizar en el tiempo que tengo disponible.
Además, también me permitirá planificar temporalmente el proyecto y sus recursos. Por último, Mi-
crosoft Project cuenta con una funcionalidad para gestionar el seguimiento del proyecto, de las ta-
reas que se han de realizar, así como de los problemas que se originen.
Para el almacenamiento del código y el control de sus versiones, se utilizará la herramienta Git. Si
bien no utilizaré todas sus características debido a que carezco de compañeros de equipo, será de
gran ayuda para mantener un cierto orden en los cambios y modificaciones del código. Además, me
servirá para poder utilizar el mismo código desde otro dispositivo, si fuera necesario.
También utilizare Maven para gestionar todas las dependencias de los programas desarrollados en
Java. Además de esto, también automatizará y simplificará las ejecuciones y los despliegues del có-
digo a los servidores del cloud.
10
Entorno de trabajo, conjunto de conceptos y prácticas para enfocar un problema.
11
Periodo predefinido de tiempo en el que se han de completar conjunto de tareas asignadas.
12
Información u opinión al respecto de un tema, actitud o trabajo realizado.
22
En lo referente a validar el correcto funcionamiento de las tareas que se realizarán durante el pro-
yecto, como del producto final, será necesario que estos cumplan con las expectativas. Para las ta-
reas, estas tendrán que cumplir con las especificaciones a las que se asociaron. Y, para el producto
final, tendrá que cumplir todos los requisitos que más adelante especificaremos; tanto funcionales
como no funcionales. Además, el director del proyecto seguirá de cerca todos los pasos y tareas que
se irán realizando y dará su feedback. Por último, si todo le parece correcto, dará su visto bueno.
Por último, para validar las propias clases y métodos implementados, se realizarán pruebas unitarias.
Estas se harán con la librería Junit y validarán el funcionamiento básico del programa.
23
5 Planificación
El proyecto debo tenerlo finalizado para el día 23 de junio. La fecha en que lo inicialicé fue el día 28
de enero. Dedico ocho horas diarias de lunes a viernes, por lo que, descontando los días festivos en
Barcelona —19 y 22 de abril, 1 de mayo y 10 y 24 de junio—, quedan 100 días exactos. Esto equivale
a 800 horas para dedicarle al proyecto.
Además, tendré unos días adicionales para preparar el documento para preparar el documento para
la presentación y estudiármela. El número de días dependerá del día asignado para la defensa del
proyecto ante el tribunal, que puede variar desde el uno hasta el cinco de julio. Por lo tanto, los días
de que dispondré para la presentación son entre cinco y nueve.
Juntando las horas a dedicar al proyecto y su memoria —en los que se incluye la asignatura de GEP,
ya que el trabajo realizado en esta será reutilizable en el propio proyecto— y las horas para preparar
la presentación, el tiempo total dedicado será un total dentro del intervalo: [840, 872].
5.1 Descripción de las tareas y recursos

En esta sección indicaré las fases en las que se dividirá el proyecto. También incluiré las tareas de
cada una de estas fases y, al final, un diagrama de Gantt en el que aparecerán estas tareas y las
dependencias existentes entre estas.
5.1.1 Descripción de cada una de las fases y subfases

Las fases principales en las que se dividirá el proyecto son las siguientes: fase inicial, fase de elección
y diseño de la arquitectura, fase de desarrollo de la arquitectura y conclusión. En las siguientes sub-
secciones entraré en detalle en cada una de ellas.
Los recursos utilizados comúnmente durante todas las fases del proyecto los podemos observar en
la Tabla 1.
Recursos físicos Recursos digitales Recursos humanos

Ordenador Dell Latitude E5550, 8GB de me- Microsoft Word Director de proyecto
moria, 500GB de disco duro, Intel Core I5
Pantalla Dell 22 pulgadas Microsoft Outlook
Ratón y teclado Microsoft Teams
Escritorio de trabajo y silla Microsoft Project
Tabla 1. Recursos comunes para todas las fases del proyecto.
Además, en cada una de las fases indicaré aquellos recursos específicos para la fase en concreto.
5.1.1.1 Fase inicial

Esta fase (F1) se centra en el planteamiento del proyecto. En esta, se toman las decisiones sobre el
proyecto y se especifica las planificaciones, los recursos a utilizar y el alcance de este. Además, se
dedica parte de esta fase a aprender sobre el tema escogido.
Dentro de la fase inicial, encontramos las siguientes tareas a realizar:
• (T1) Búsqueda de información sobre Big Data, Cloud y suministro de agua.
24
• (T2) Documentación de los conocimientos adquiridos, estado del arte y primer entregable
de GEP.
• (T3) Planificación temporal del proyecto y alcance de este y segundo entregable de GEP.
• (T4) Análisis de sostenibilidad del proyecto y tercer entregable de GEP.
• (T5) Preparación de la documentación y presentación final de GEP
Recursos específicos:
• Recursos humanos
o Gestor de proyectos
• Recursos digitales
o Microsoft Excel
5.1.1.2 Elección de la arquitectura

Esta fase (F2) consiste en estudiar tres plataformas de proveedores de servicios de cloud (Amazon,
Google y Microsoft) y analizar las diferentes alternativas que ofrecen. Después, se creará un modelo
con la arquitectura óptima de cada arquitectura. Una vez se han diseñado las propuestas para las
tres plataformas, se compararán y escogerá la más adecuada de las tres para resolver el problema
propuesto en el proyecto.
Dentro de esta fase, encontramos las siguientes tareas a realizar:
• (T6) Estudio de la plataforma Amazon Web Services y de los servicios que ofrece.
• (T7) Esquematización y boceto de una arquitectura con Amazon Web Services.
• (T8) Estudio de la plataforma Google Cloud Platform y de los servicios que ofrece.
• (T9) Esquematización y boceto de una arquitectura con Google Cloud Platform.
• (T10) Estudio de la plataforma Microsoft Azure y de los servicios que ofrece.
• (T11) Esquematización y boceto de una arquitectura con Microsoft Azure
• (T12) Comparación de las tres arquitecturas y elección de la óptima.
Recursos:
o Arquitecto de software
o Amazon Web Services
o Google Cloud Platform
o Microsoft Azure
5.1.1.3 Desarrollo de la arquitectura

Durante la fase de desarrollo (F3), se materializará el boceto de arquitectura escogido, utilizando las
herramientas ofrecidas por la plataforma.
Dentro de la fase de desarrollo, encontramos las siguientes tareas a realizar:
• (T13) Creación de una cuenta gratuita en la plataforma escogida.

• (T14) Creación de la arquitectura basándose en el modelo anteriormente creado usando los
servicios ofrecidos por la plataforma.
Recursos:
25
o Arquitecto de software y desarrollador de software
o Cuenta en la plataforma escogida
o Java Spring
o Entorno de desarrollo
5.1.1.4 Conclusión
La conclusión (F4) se centrará en todo aquello que reste por documentar. Además, se realizará el
documento para la presentación del proyecto.
En la conclusión, encontramos las siguientes tareas a realizar:
• (T15) Documentación y realización de la memoria del proyecto.

• (T16) Realización de la presentación.
Recursos:
o Gestor de proyectos
o Microsoft Excel
o Microsoft PowerPoint
5.1.2 Resumen de tareas

En la Tabla 2 se observa un resumen de las tareas, así como las dependencias entre estas, los recursos
utilizados por cada una y el tiempo estimado. Los nombres de las tareas son orientativos.
Fase Tarea Dependencias Tiempo estimado

(en horas)
T1: entrada en materia - 140
T2: estado del arte T1 24
F1: Fase inicial T3: planificación temporal T2 20

T4: análisis de sostenibilidad T3 15
T5: documentación final de GEP T2, T3, T4 20

T6: estudio de AWS T1 40
T7: propuesta de AWS T5 10
T8: estudio de GCP T1 40
F2: Elección de la ar-
T9: propuesta de GCP T7 10
quitectura
T10: estudio de Azure T1 40
T11: propuesta de Azure T9 10

T12: elección de la arquitectura T6, T8, T10 20
T13: creación de una cuenta T11 1
26
F3: Desarrollo de la
T14: desarrollo de la arquitectura T12 250
arquitectura
T15: documentación y memoria F1, F2, F3 110
F4: Conclusión
T16: presentación F1, F2, F3 40
Tabla 2. Resumen de las tareas y dependencias entre ellas.
5.2 Diagrama de Gantt

En la Figura 7, podemos observar el diagrama de Gantt obtenido a partir de los datos anteriores.
Figura 7. Diagrama de Gantt de la planificación temporal del proyecto. Generado mediante Microsoft Project. Imagen ampliada en
Anexo 1.
27
5.3 Plan de acción y valoración de alternativas

Como se puede observar en la Tabla 2, el tiempo total de las tareas suma 750 horas (o 790, si se tiene
en cuenta la tarea T15 —crear la presentación—), de las 800 (unas 840 si se tiene en cuenta el tiempo
a dedicar en la presentación) que tiene previsto durar el proyecto. Las 50 horas restantes se dejarán
vacías, sin añadir a ninguna tarea. Con esto se podrá evitar el retraso del proyecto debido a una
situación en la que una tarea dure más de lo inicialmente previsto.
Sin embargo, este no es el único plan de contingencia. Respecto a los riesgos del sistema, a continua-
ción, entraré en detalle sobre cada uno de ellos, sus posibles soluciones y cómo afectaría al proyecto:
• Error en la planificación temporal. Es un fallo muy probable dada mi poca experiencia en

proyectos de larga duración. Su solución más eficaz es el uso del tiempo reservado para
estos casos, explicado anteriormente. Otra solución, aunque más complicada, es aumentar
el número de recursos disponibles. Dependiendo en la fase del proyecto en la que falte
tiempo, estos recursos podrían ser en forma de un gestor de proyectos, de un desarrollador
de software o de un arquitecto de software. Naturalmente, y ya que la única persona dispo-
nible soy yo mismo, esto equivaldría a trabajar más horas diarias de las inicialmente previs-
tas, que son 8.
• Gratuidad de los servicios. Actualmente existen servicios gratuitos en las tres plataformas
que se usarán durante el proyecto. Sin embargo, si esta situación cambiara durante el pro-
yecto, se tendrán que tomar decisiones al respecto. Una posible solución es reemplazar la
supuesta plataforma por otra que sí disponga de plan gratuito o versión de prueba. Otra
solución posible es la solicitud a la empresa de un presupuesto que permita llevar a cabo el
plan inicial, aunque deje de ser gratuito. Para esto hará falta entablar horas de conversación,
para las que se usará tiempo de la reserva.
• Pésimos resultados del sistema de demostración. Si llega el caso que, una vez el proyecto
está llegando a su conclusión teniendo unos resultados deficientes —ya sea por problemas
de precisión o de tiempo de ejecución—, las soluciones disponibles no son muchas. La prin-
cipal solución es usar las horas restantes del proyecto a intentar mejorar la solución. Muy
difícilmente se podrá dar marcha atrás a la elección de la arquitectura, ya que muy proba-
blemente las horas restantes serán insuficientes para llevar a cabo toda la fase de desarrollo.
Sin embargo, debido a que la importancia de este sistema de demostración recae sobre su
flujo de datos y su arquitectura, y no sobre cada una de sus piezas, este riesgo no tendría
gran relevancia para el resultado final.
28
6 Presupuesto y sostenibilidad
En esta sección analizaremos dos puntos importantes del proyecto que ayudarán, por un lado, a fijar
un precio de venta del producto final antes de terminarlo y, por otro lado, a valorar el impacto que
tendrá, tanto el proyecto como su resultado, en el mundo desde tres dimensiones: la económica, la
social y la ambiental.
La dimensión económica se tratará de una manera más extensa que el resto, ya que en ella entra un
tema tan importante como es el análisis del presupuesto del proyecto, así como el control de des-
viaciones y su viabilidad económica.
6.1 Análisis del presupuesto

En esta sección haré un análisis del presupuesto total del proyecto, y también del beneficio que se
espera obtener con él. La dividiré en varias partes, y dedicaré cada una de ellas a analizar el presu-
puesto específico para cada tipo de recurso.
6.1.1 Recursos humanos

Los recursos humanos que se utilizarán durante el proyecto están extraídos de la planificación tem-
poral y el papel que desempeñaran a lo largo de este son los siguientes:
• Director del proyecto. Es el responsable del proyecto dentro de la empresa. Se encargará de

conseguir los recursos necesarios para la finalización del proyecto, así como de vender el
producto a los clientes. Dedicará 4 horas semanales al proyecto mientras este esté en pie.
• Gestor de proyectos. Su labor será estimar el número de recursos necesarios para la realiza-
ción del proyecto, de realizar la estimación del tiempo necesario para su finalización y de
dirigir y orquestar a los diferentes integrantes del equipo. Su trabajo se centrará en la fase
inicial del proyecto, así como en la fase de conclusión. En el resto deberá estar presente
mínimamente, solamente para solucionar diversos problemas que puedan surgir.
• Arquitecto de software. Su trabajo será el de crear una arquitectura óptima para los casos
de uso anteriormente explicados. Escogerá las diferentes herramientas con las que se tra-
bajará y elegirá sus configuraciones. Centrará su labor en la fase de elección de arquitectura,
aunque también estará presente en el desarrollo de esta.
• Desarrollador de software. Su labor será desarrollar las distintas aplicaciones del sistema
junto con el/los arquitectos de software. Trabajará en la fase de desarrollo de la arquitec-
tura.
A continuación, podemos ver en la Tabla 3 el coste de los distintos recursos humanos de los que
dispondremos. En el coste se incluye el sueldo, impuestos como IRPF y Seguridad Social y otros con-
ceptos. Las horas totales han sido extraídas a partir de la sección de planificación temporal del pro-
yecto. El coste total se realiza como un sencillo producto entre el coste por hora y las horas totales
de cada recurso. Luego se obtiene el coste total de los recursos humanos sumando los distintos to-
tales de los recursos individuales. Todos los costes están contabilizados en euros. Las horas totales
de cada recurso se ha extraído de la Tabla 2, de la planificación temporal realizada en la sección
anterior.
29
Recurso Coste por hora Horas totales Coste total

Director de proyecto 40 76 3040
Gestor de proyectos 30 369 11070
Arquitecto de software 25 170 4250
Desarrollador de software 20 251 5020
Total 866 23380
Tabla 3. Coste de los recursos humanos.
6.1.2 Recursos materiales

Los recursos humanos harán uso de recursos materiales con tal de realizar el proyecto. Estos recursos
materiales son los siguientes:
• Ordenador portátil Dell Latitude E5550 con las siguientes características: pantalla de 15.6
pulgadas, 8GB de memoria RAM, procesador Intel Core i5-5300U a 2.30GHz.
• Pantalla adicional Dell P2217H de 22 pulgadas.
• Ratón óptico Targus modelo AMU30EUZ.
• Teclado Microsoft Wired KeyBoard 600.
• Mesa de trabajo y silla.
• Otros servicios como luz, agua, aire acondicionado y lavabo.
La empresa hace un pago único de 500 euros por el ordenador, a los que se suman 5 euros mensua-
les. Para el resto de los recursos, el costo es de 215 euros al mes en el que vienen incluidos todas las
necesidades y recursos anteriormente citados.
En la Tabla 4 observamos un resumen de lo anteriormente mencionado, así como el coste total de

los recursos materiales. El tiempo que se necesitan los recursos —cinco meses— se ha obtenido de
la planificación temporal, como también podemos observar en la Figura 7. Diagrama de Gantt de la
planificación temporal del proyecto. Generado mediante Microsoft Project.
Recurso Coste mensual Meses Coste total

Ordenador portátil 5 5 25
Resto de recursos 215 5 1075
Total 5 1100
Tabla 4. Coste de los recursos materiales.
Al coste anterior falta sumar el pago inicial de 500 euros del ordenador. Esto sumaría un total de
1,600 euros. Dentro del coste inicial del ordenador, vienen incluidos costes en concepto de prepara-
ción del portátil y amortización de la compra por parte de la empresa. Sin embargo, los 500 euros no
van íntegramente dedicados a este proyecto. Puesto que el tiempo que duraré en la empresa es
desconocido, la amortización de estos 500 euros también lo es. Si mi tiempo en la empresa se res-
tringiera solamente a la duración del proyecto, la amortización sería de 500 euros. Sin embargo, si la
duración fuera, por ejemplo, de unos 5 años, la amortización sería de unos 42 euros. Para el resto de
los recursos, no tiene sentido calcular la amortización, pues solamente se paga el alquiler. Para este
caso, supondremos que la duración del contrato es de la duración del proyecto, por lo que la amor-
tización será de 500 euros. Por lo tanto, en este caso, el coste total de recursos materiales será de
1,600 euros.
30
6.1.3 Recursos digitales

Por último, los recursos digitales necesarios para realizar el proyecto son los siguientes:
• Microsoft Word, Excel, PowerPoint. Estas herramientas se usarán para el desarrollo de la

memoria inicial y final del proyecto. Su coste está incluido en el coste mensual del manteni-
miento del ordenador portátil.
• Teams, Outlook y Skype for Business. Estas herramientas ayudarán en la comunicación de
las diferentes partes del proyecto y su coste también está incluido con el ordenador portátil.
• Microsoft Project. Proporcionará las herramientas necesarias para la gestión del proyecto.
Su coste es gratuito para estudiantes de la Universitat Politècnica de Catalunya debido a un
convenio.
• Microsoft Windows. El sistema operativo del ordenador viene incluido en el coste mensual
de este, por lo que se contabiliza dentro de la sección de recursos materiales.
• Java Spring. Tanto Java como este framework son gratuitos.
• Atom y Sprint Tool Suite (STS). Son herramientas para el desarrollo del código del proyecto.
Ambas son gratuitas.
• Plataforma Google Cloud Platform, Amazon Web Services o Microsoft Azure. Tienen un
coste después de consumir el crédito inicial gratuito.
Por lo tanto, el coste digital del proyecto es únicamente el coste de mantener la arquitectura en la
plataforma cloud de uno de los tres distribuidores mencionados anteriormente durante la fase de
desarrollo. El cliente se hará cargo de estos costes una vez se venda el producto.
Durante el desarrollo del proyecto, naturalmente, el cliente no se hará cargo de los costes de usar la
plataforma. Sin embargo, las tres plataformas disponen de un crédito inicial que será más que sufi-
ciente para realizar las pruebas necesarias de la plataforma. Estas pruebas serán simulando el fun-
cionamiento de producción del sistema, pero a menor escala.
6.1.4 Precio del producto y viabilidad

En la Tabla 5, podemos observar el resumen de costes de las tres secciones anteriores.
Categoría Coste
Recursos humanos 23380
Recursos materiales 1600
Recursos digitales 0
Total 24980
Tabla 5. Coste total de los recursos.
Nótese que el coste de los recursos digitales es nulo debido a que la mayor parte del software está
incluido dentro del coste de alquiler del ordenador portátil, incluido en el apartado de recursos ma-
teriales. El resto de software utilizado es gratuito.
Una vez tenemos el coste que supondrá el desarrollo del proyecto, podemos calcular el precio al que
venderemos el producto a los clientes. Para ello añadimos una sección de contingencia. Esta será
anormalmente elevada debido a la incertidumbre del precio de los servicios del Cloud durante el
desarrollo del producto. Además, se tiene en cuenta que se trabaja con tecnologías desconocidas
por el equipo.
Concepto Coste
Coste del proyecto 24980
31
Contingencias 3000
Beneficio 55960
Total 83940
Tabla 6. Coste de venta del producto.
Podemos observar en la Tabla 6 que el coste al que venderemos el proyecto será de 83,940.
El coste de los servicios Cloud de la plataforma escogida sería pagado por el cliente directa-
mente.
El beneficio se ha obtenido multiplicando por dos la suma del coste del proyecto y las posi-
bles contingencias. El precio final del producto está pensado para hacer el proyecto viable
con un solo cliente comprador.
6.2 Control de desviaciones

Igual que pasa con la planificación temporal, la realidad del coste del proyecto puede variar del re-
sultado del análisis del presupuesto. Por esto, se describirán mecanismos de control de desviaciones,
así como indicadores para determinar en qué fase del proyecto se han producido dichas desviacio-
nes.
6.2.1 Control de desviaciones

Con el fin de controlar y prevenir todo lo posible la ocurrencia de desviaciones en el presupuesto, se
han adoptado y adoptarán una serie de medidas. La primera es el uso de la planificación temporal
del proyecto. Debido a que la mayor parte del presupuesto del proyecto está invertido en horas de
trabajo del personal, la probabilidad de que cualquier desviación del presupuesto tenga su causa en
la necesidad de más horas de trabajo es muy alta. Por ello, al crear la planificación —de la que de-
pende el presupuesto—, se añadieron horas vacías, sin ninguna tarea. Básicamente, parte del presu-
puesto se ha guardado para estos posibles casos en que se necesiten más tiempo, sin que repercuta
en una desviación del presupuesto.
Además, otra medida será el uso de un programa de gestión de proyectos. Como he mencionado en
la sección de Metodología, usaré Microsoft Project. Ayudará tanto a planificar el proyecto temporal-
mente, como a asignar recursos a cada fase o tarea específica. Será útil para mantener un control
absoluto sobre el estado actualizado del proyecto.
6.2.2 Indicadores de desviaciones

Una vez acabado el proyecto, es sencillo analizar si ha habido desviaciones sobre el presupuesto
inicial. Para ello, se deberá tener en cuenta el presupuesto inicial y compararlo con el presupuesto
final. Para detectar en qué parte del proyecto ha habido el desvío, se hará del mismo modo: compa-
rando el presupuesto inicial y final para cada una de las partes.
Sin embargo, es muy complicado detectar desviaciones presupuestarias a la vez que estas están su-
cediendo. Una de las maneras que consideraremos será mirar si se cumplen los plazos temporales
para cada una de las fases y tareas del proyecto. Pues, como anteriormente he mencionado, las des-
viaciones en el presupuesto probablemente irán muy ligadas a desviaciones en la planificación tem-
poral.
Además, el presupuesto de los recursos materiales para nuestro caso está también ligado con la
planificación temporal —pues el coste del material depende del tiempo que lo usemos—. Por tanto,
32
del mismo modo que con los recursos humanos, estas desviaciones se detectarán juntamente con
desviaciones temporales.
Por último, los recursos digitales, cuyo presupuesto es nulo de un principio, pero que podían suponer
un gasto finalmente, tienen un máximo de 3,000 euros de presupuesto —suponiendo que estos
3,000 euros, destinados a contingencias, no se usan en ningún otro supuesto—. De esta manera,
también seremos capaces de detectar una desviación de este tipo de recursos.
6.3 Sostenibilidad
Para realizar el análisis de sostenibilidad del proyecto, lo dividiremos en tres secciones según la di-
mensión que tratemos: económica, social o medioambiental. Además, enfocaré estos apartados a
tratar de estudiar el impacto del proyecto según la matriz de sostenibilidad (Tabla 7).
PPP13 Vida útil Riesgos

Ambiental Consumo de diseño Huella ecológica Ambientales
Económico Factura Plan de viabilidad Económicos
Social Impacto personal Impacto social Sociales
Tabla 7. Matriz de sostenibilidad.
6.3.1 Sostenibilidad económica

Ya que los dos primeros apartados económicos de la matriz de sostenibilidad los he tratado en sec-
ciones anteriores, me centraré en analizar el tercer apartado —riesgos—, así como en algunos otros
aspectos.
Los clientes finales del resultado del proyecto serán suministradores de agua potable vía una red de
canales de una ciudad. Encontramos dos beneficiarios económicos. Por un lado, los clientes, que
podrán aprovechar la adquisición del producto para atraer más clientes y ganar dinero. Y, por otro
lado, los usuarios de los proveedores de agua, que, gracias al proyecto, podrán beneficiarse de las
ventajas de ahorro de agua y, consiguientemente, ahorrar económicamente también.
En cuanto a la puesta en producción del proyecto, el coste no es demasiado elevado teniendo en

cuenta los clientes a los que va dirigido. Además, durante la vida útil del producto, las empresas
podrán fácilmente amortizar este coste si consiguen nuevos clientes debido a su utilización.
Los riesgos económicos del proyecto son dos: por un lado, que el producto no se pueda finalizar
dentro de unos límites razonables de presupuesto; y, por el otro, que el producto resulte no ser tan
atractivo para la mayoría de los usuarios del mercado, es decir, que sea un fracaso.
Por último, cabe destacar que, una vez finalizado el proyecto, es la empresa compradora la que se
hará cargo de los costes de mantenimiento de la infraestructura de Cloud. El precio actualmente se
desconoce —pues es uno de los factores que se estudiará durante el proyecto—, pero rondará alre-
dedor de los varios miles o decenas de miles de euros mensuales.
13
Proyecto puesto en producción. Incluye la planificación, el desarrollo y la implantación del proyecto.
33
6.3.2 Sostenibilidad social

Durante el desarrollo del proyecto, seguramente se produzcan cambios en las personas que trabajen
en él. Primeramente, el incremento de experiencia en ámbitos de big data y cloud. Pero, sobre todo,
la reflexión personal sobre el ahorro de agua que se produce en su implantación en el mercado.
Una vez el producto está en el mercado, socialmente es posible que también logre influir en la vida
de las personas, dando a conocer el problema del agua. Además, una posible extensión del producto
para un futuro proyecto sería la implementación de algunos casos de uso adicionales y totalmente
compatibles con el producto. El más importante sería la detección de fraude. Para su implementa-
ción, sería necesaria la implicación y colaboración de la administración pública. Esto tendría efectos
directos en puestos de trabajo, tanto del proyecto como de la propia administración. Además, una
vez implantado este nuevo caso de uso, seguiría teniendo una clara repercusión social, pues su fina-
lidad sería detectar posibles casos de uso fraudulento de la red de agua por parte de algunos usua-
rios.
Como riesgo social del proyecto, encuentro un problema el tratamiento de la privacidad de los usua-
rios. Debido al tratamiento de datos de estos, es posible que haya algunos en contra del tipo de uso
que se les dé a sus datos.
6.3.3 Sostenibilidad medioambiental

El impacto medioambiental de este proyecto es importante, ya que durante su vida útil se espera
reducir notablemente el consumo de agua potable en los usuarios de compañías de agua que com-
pren el producto.
Además, cualquiera de las tres plataformas de cloud ofrece reducir de una manera importante las
emisiones de carbono. Amazon asegura que, utilizando cloud en vez de clústeres convencionales, es
posible reducir hasta un 88% la huella de carbono de los sistemas utilizando AWS. Además, desde
enero del pasado año —2018—, el 50% de su energía proviene de fuentes renovables. A su vez,
Google Cloud Platform menciona que sus sistemas utilizan energía 100% renovable desde 2017. Por
último, Microsoft firmó un contrato en 2017 por el que toda la energía de su central del estado de
Washington provendría de fuentes renovables.
Sea como sea, utilizar plataformas de proveedores de servicios cloud reduce la huella de carbono de
un sistema considerablemente.
Sin embargo, como todo proyecto de ingeniería —aunque su objetivo sea crear un producto soste-
nible y positivo para el medio ambiente—, tiene un impacto medioambiental durante su realización.
Esto es debido a que son necesarios varios recursos: materiales (ordenadores, monitores, electrici-
dad), humanos (que necesitan energía y alimentos) y digitales (que provienen de otros proyectos
anteriores). Cada uno de estos recursos tiene asociado una huella ecológica. Esta representa el con-
sumo de recursos del planeta por parte de una persona, un proyecto (como es en este caso), etc.
Puesto que la huella ecológica es difícil de calcular (no encuentro suficiente información y la mayoría
de esta está enfocada a la huella ecológica de una casa o de individuales), me centraré en la huella
de carbono. Esta representa la cantidad de gases de efecto invernadero producidos por una actividad
o una persona (o colectivo). Para ello, lo hare con los siguientes supuestos:
34
• Distancia del lugar de trabajo a casa, en metro, de 1.9 kilómetros (entre las paradas de Sants
Estació y Poble Sec, de la Línea 3 de Barcelona). Hacen un total de 3.8 kilómetros diarios y
380 a lo largo de los 100 días mencionados en la Planificación.
• Siguiente material utilizado diariamente ocho horas:
o Ordenador portátil con un consumo medio de unos 60 W.
o Monitor secundario de unos 20 W.
o Teclado adicional de unos 3 W.
o Ratón con cable de 1 W.
La suma de los cuatro recursos hace es de 84 vatios. Durante las 8 horas diarias, equivalen a
672 vatios-hora. Al final del proyecto, el consumo energético es de 67,200 Wh.
• Iluminación de la oficina compuesta de alrededor de 320 tubos fluorescentes de 590 milí-

metros de largo y 26 de diámetro, de unos 18 W de potencia cada uno. Esto suma un total
de 46,080 Wh de energía durante las 8 horas de mi estada. Considerando que hay alrededor
de 50 personas en la oficina, se le asignan 921.6 Wh a cada una. Durante los cien días que
dura el proyecto, suman un total de 92,160Wh.
• Uso del microondas una media de tres minutos diarios para calentar comida. A una poten-
ciad e 800 vatios, se traduce a un consumo de energía de 40 vatios-hora. Hace un total de
4000 durante los cien días del proyecto.
• No se tiene en cuenta el ascensor, pues en el edificio reside un número desconocido de
personas y empresas.
• No se tiene en cuenta la huella de carbono generada por la ropa utilizada, la comida utilizada
ni los gases generados por el cuerpo humano de forma natural.
• No se tiene en cuenta el consumo de las instalaciones del lugar de trabajo durante los días
de fiesta y fines de semana.
Del transporte diario, extraemos la huella de carbono en forma de dióxido de carbono equivalente
(CO2e). Esto es la equivalencia a dióxido de carbono —uno de los diferentes gases que contribuyen
al famoso efecto invernadero— de todos los gases generados. Con la ayuda de la página web de
Carbon Footprint Ltd., obtenemos que el total de 380 kilómetros en metro equivale a 143 kilogramos
de CO2e.
Para el resto de los factores, expresados en vatios, utilizaré un conversor en línea de RenSMART Ltd.
Según este, los 163,360 vatios-hora totales equivalen a 46.24 kilogramos de CO2e.
Por lo tanto, la huella de carbono final, teniendo en cuenta los supuestos anteriormente menciona-
dos, es de 189.24 kilogramos de CO2e.
Por último, puede haber ciertos riesgos medioambientales que se deben tener en cuenta. Uno de
ellos es que finalmente el producto no ayude tanto a ahorrar agua como para contrarrestar los efec-
tos de la huella de carbono originada durante su producción.
Por otro lado, se tiene que prestar atención al posible caso en que facilitar información respecto la
siguiente factura al usuario sea contraproducente. En este supuesto, el usuario vería que la próxima
factura a pagar es económicamente más barata de lo esperado y decidiría gastar más agua de la
inicialmente prevista. Esto conllevaría un gasto adicional de agua respecto a la no implantación del
producto.
35
7 Requisitos del sistema

En esta sección se definirán los requisitos del sistema a diseñar, tanto funcionales como no funcio-
nales. Los primeros, especifican las funcionalidades que debe brindar el sistema con tal de alcanzar
los objetivos de negocio. Los requisitos no funcionales, por otra parte, se centran más en la calidad
del sistema.
Además, se considerará que un usuario equivale a un contador, para simplificar. En adelante, refe-
rirse a cualquiera de los dos términos será indiferente.
7.1 Requisitos funcionales

Los requisitos funcionales del sistema los dividiré en dos tipos: casos de uso y comportamiento que
deberán tener los contadores de agua utilizados con tal de proveer la información necesaria para el
correcto funcionamiento del sistema.
7.1.1 Casos de uso

Como he mencionado anteriormente, se desarrollarán dos casos de uso diferentes. Por un lado, una
predicción del consumo mensual de agua y, por el otro, una detección de fugas. En los siguientes
subapartados, explicaré en qué consisten y cómo interactúa el usuario con el sistema en cada uno
de ellos.
7.1.1.1 Predicción del consumo mensual

La predicción del consumo mensual proporcionará al usuario una vez al día datos estimados del con-
sumo de agua total que tendrá el usuario al finalizar el mes —o periodo de facturación, aunque de
aquí en adelante nos referiremos al mes—.
El sistema utilizará modelos predictivos para hacer esta estimación. Para ello, usará los datos de en-
trada de cada uno de los contadores y los agrupará por contador.
La única interacción del usuario final con el sistema será para visualizar los datos correspondientes a
esta estimación. No será necesario ningún tipo de interacción para introducir datos de entrada, ni
para hacer modificaciones.
7.1.1.2 Detección de fugas

La detección de fugas notificará al usuario final de fugas —si las hubiere— en la dirección pertene-
ciente al contador por el cual se han detectado. En este caso de uso, el sistema utilizará un modelo
predictivo para detectar, a partir de los datos de entrada, si ha habido una fuga de agua. Debido a
que los datos de un mismo contador entran cada cinco minutos en el sistema, la fuga de agua se
detectará en menos de una hora.
Como en el caso de uso anterior, no será necesaria la interacción del usuario con el sistema más allá
de la visualización de estos datos finales.
36
7.1.2 Comportamiento de los contadores de agua

El sistema estará diseñado para recibir información a razón de una traza nueva de datos por usuario
cada cinco minutos. Para ello, se necesitará que los contadores estén diseñados para enviar automá-
ticamente a las direcciones proporcionadas por el sistema estos datos. Otra opción sería que la em-
presa que gestiona estos contadores redirija los datos hacia el sistema.
7.2 Requisitos no funcionales

Los requisitos no funcionales del sistema se asegurarán de que este cumple una cierta calidad. Los
explico en los siguientes subapartados.
7.2.1 Usabilidad
El sistema, externamente, será muy sencillo, ya que los usuarios apenas necesitaran interactuar con
él. Simplemente recibirán notificaciones y podrán visualizar información desde una aplicación web.
7.2.2 Fiabilidad
El sistema a diseñar deberá ser muy fiable en el sentido de robusto frente a caídas temporales. Por
lo tanto, tendrá que configurarse en un modo de high availability —alta disponibilidad—. De no ser
así, podrían perderse datos cruciales para, sobre todo, el caso de uso de detección de fugas.
7.2.3 Eficiencia y escalabilidad

El sistema estará diseñado para soportar hasta un máximo de cinco millones de usuarios concurren-
tes en lo que se refiere a la ingesta de los datos de los contadores. Por lo tanto, las especificaciones
del sistema se harán entorno a este número
Además, el sistema deberá permitir una ampliación, en cierta medida sencilla, de estas especifica-
ciones para poder dar soporte a un mayor número de usuarios que los inicialmente previstos.
7.2.4 Mantenibilidad
El sistema será fácilmente mantenible e incorporar nuevos casos de uso a este no podrá ser una tarea
compleja, más allá de la propia complejidad del nuevo caso a implementar. Para ello, se tendrán que
desacoplar, en la medida de lo posible, todos los componentes del sistema.
7.2.5 Seguridad
El sistema deberá ser robusto a ataques externos y entradas desautorizadas en el sistema.
7.2.6 Privacidad
Puesto que el proyecto trata sobre big Data y, por tanto, sobre datos, una de las regulaciones más
importantes que hay que tener en cuenta es el Reglamento General de Protección de Datos (RGDP)
—más conocido como GDPR (siglas del reglamento en inglés) —.
Este reglamento (Reglamento de la Unión Europea 2016/679) hace alrededor de un año que se aplicó
(25 de mayo de 2018).
37
Además, en España se ha aprobado la Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos

Personales y garantía de los derechos digitales, con el objetivo de adaptar el ordenamiento jurídico
de nuestro país al reglamento europeo anteriormente mencionado.
Estas dos leyes, en conjunto, afectarán al uso que se quiera dar a los datos. Recordemos que estas
leyes únicamente regulan el tratamiento dado a los datos personales. Según el artículo cuarto del
Reglamento General de Protección de Datos de la Unión Europea, se entiende por «datos persona-
les» a toda la información sobre una persona física identificada o identificable. Además, no entiende
por datos personales aquellos que estén anonimizados.
Por lo tanto, solo uno de los dos tipos de datos con los que trabajará el sistema son personales. Estos
son los datos de los usuarios (nombre, dirección del contador de agua y correo electrónico —no
considerado como personal—) de la compañía de agua y provenientes de un maestro de usuarios de
esta.
Por otro lado, tenemos los datos que no son considerados personales y que, por lo tanto, no necesi-
tarán recibir ningún tratamiento especial. Se trata de los datos sobre el consumo de agua de cada
contador, perteneciente a un único usuario.
Además, según el artículo segundo de la ley europea, no se aplicará el tratamiento especial en los
siguientes casos:
• Actividad no comprendida en el ámbito de aplicación del Derecho de la Unión Europea.

• Actividad llevada a cabo por parte de los Estados miembros.
• Actividad llevada a cabo por una persona física con objetivos exclusivamente personales o
domésticos.
• Actividad por parte de autoridades competentes con fines de prevención, investigación, de-
tección o enjuiciamiento de infracciones penales, o de ejecución de sanciones penales.
El sistema a diseñar no está encasillado en ninguno de los anteriores caos, por lo que el trata-
miento dado a los datos será el especial, regulado por esta ley.
Primero, tendrán que ser confidenciales y se tendrá que hacer lo posible por protegerlos. Esto se
hará mediante Google Cloud Platform (véase la elección de la plataforma en el apartado 9.4), que lo
asegura. Además, en ningún momento se guarda este tipo de datos en el sistema. Simplemente se
cargan de un maestro de usuarios de la compañía de agua y se eliminan de memoria. Asimismo,
tendrán que ser usados con el mismo uso para el que fueron obtenidos. Esto será así según el sistema
a diseñar, su uso se restringirá a los dos casos de uso definidos, no hay ningún problema por esta
parte.
38
8 Fujo de datos y especificaciones del sistema

Una de las partes más importantes del proyecto son los datos y su tratamiento. En esta sección
analizaré su origen, su estructura y su comportamiento durante todas las fases de la arquitectura.
El flujo de datos seguirá una estructura parecida a la de una arquitectura lambda. Este es un tipo de
arquitectura orientada al tratamiento de grandes cantidades de datos aprovechando
simultáneamente los beneficios que ofrecen los metodos de procesamiento batch y stream (Marz &
Warren, 2015).
Los dos métodos de procesamiento de datos —batch y stream— son totalmente distintos. Por un
lado, el procesamiento batch —o por lotes— procesa la información en grandes cantidades.
Usualmente lo hace durante un período específico del día —por ejemplo, durante la noche, o una
vez por semana—. Este tipo de procesamiento es especialmente útil para tratar aquellos datos que,
si bien, no dejan der ser importantes, no requieren inmediatez en su procesamiento.
Por el otro lado, tenemos el stream. Este se centra en la necesidad de la información utilizada a ser
tratada de una forma inmediata (real time) o con pocos minutos de retraso (near real time).
Para los casos de uso definidos anteriormente, de la siguiente manera harán uso de la arquitectura
anterior:
• La predicción del consumo mensual hará un provecho mayor de la parte batch del sistema,
ya que, debido a la naturaleza del caso de uso, no requiere especial velocidad en el trata-
miento de los datos.
• La detección de fugas hará un provecho mayor de la parte real time del sistema, ya que se
necesita una respuesta rápida por parte del sistema para poder notificar en el menor tiempo
posible al usuario y a otros posibles sistemas.
8.1 Flujo de datos

Se pueden destacar cuatro fases principales en el flujo de los datos durante todo el proceso: ingesta,
almacenamiento, procesamiento y explotación. Será importante estudiar cada una de estas partes
para conocer las necesidades que requerirán.
8.1.1 Ingesta
Es el comienzo del flujo de datos. En nuestro caso, la ingesta la realizará la empresa que compre el
producto. Esta se encargará de recoger los datos y enviarlos. Se considerarán dos tipos de fuentes
de información: externas y adicionales.
8.1.1.1 Fuentes externas

Las fuentes externas serán el origen principal de información del sistema. Serán las propias fuentes
de los clientes compradores y los datos que llegarán de estas serán en forma de trazas de consumo
de agua de sus usuarios. Estas trazas tendrán una estructura definida según el siguiente JSON
Schema.
39
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "Traza de consumo",
"description": "Traza de consumo de agua para un único contador",
"type": "object",
"properties": {
"watereterId": {
"type": "integer",
"description":"Identificador del contador del que proviene la
traza",
"minimum": 0
},
"timestamp": {
"type": "integer",
"description":"Fecha y hora en que se ha generado la traza"
},
"reading": {
"type": "number",
"description":"Volumen de consumo registrado por el contador",
"minimum": 0
}
},
"required": ["waterMeterId", "timestamp", "reading"],
"additionalProperties": true
}
Como podemos observar, es una estructura muy simple en la que solamente aparecen tres campos:
un identificador del contador, un campo de fecha y hora y el volumen —en kilolitros, o metros cúbi-
cos— registrado por el contador en esa fecha y hora. Además, se dejará abierta la posibilidad de
extender el formato de los archivos en un futuro, con la propiedad additionalProperties.
Cada archivo JSON, como podemos observar en el esquema anterior, contendrá un número entero
de identificador, un número entero que codificará la fecha y hora y un número decimal de lectura
del consumo. Para saber el tamaño total esperado de estos archivos, haré las siguientes considera-
ciones:
• Los identificadores serán números de ocho cifras.

• La fecha y hora se representarán siguiendo el formato Unix14, por lo que consideramos que
serán números de diez cifras.
• El consumo estará representado por número decimal de 7 cifras: cuatro cifras enteras y tres
decimales.
El reflejo de estos datos en un archivo JSON hace que cada traza tenga un tamaño de alrededor de
84 bytes. Definiremos una frecuencia de 12 trazas por hora y por contador. Esto es equivalente a un
periodo de 5 minutos entre dos trazas de un mismo contador. Es suficiente para detectar una fuga
en un tiempo relativamente bajo. Con estos datos, la cantidad de datos que recibirá el sistema cada
hora se calculará de una forma muy sencilla:
14
Representación de tiempo que cuenta el tiempo transcurrido desde las 00:00:00 del 1 de enero de
1970. Tiene varias precisiones, siendo las más comunes de nanosegundos a segundos.
40
84 𝐵 12 𝑡𝑟𝑎𝑧𝑎𝑠
· · 5,000,000 𝑐𝑜𝑛𝑡𝑎𝑑𝑜𝑟𝑒𝑠 = 5,040,000,000 𝐵/ℎ
1 𝑡𝑟𝑎𝑧𝑎 1 ℎ𝑜𝑟𝑎 ∗ 1 𝑐𝑜𝑛𝑡𝑎𝑑𝑜𝑟
En la siguiente tabla, podemos observar la cantidad de datos de ingesta del sistema en diferentes
unidades de tiempo.
Número de trazas Bytes Gibibytes15 Tebibytes16

Segundo 16666.67 1,400,000 0.0013 1.2733× 10-6
Hora 60,000,000 5,040,000,000 4.6939 0.0046
Día 1,440,000,000 120,960,000,000 112.6528 0.1100
Mes17 43,200,000,000 3,628,800,000,000 3,379.5834 3.3004
Tabla 8. Cantidad de datos a ingerir por el sistema
8.1.1.2 Fuentes adicionales

Además de las trazas de consumo generadas por los contadores, al sistema podrán llegar otros datos.
Estos podrán ser de varios tipos. Por un lado, encontramos datos climatológicos (temperaturas, nu-
bosidad, precipitaciones, humedad), tanto reales como previsiones. Es decir, cualquier dato que
pueda influir indirectamente en el consumo de agua. Por otro lado, también se ingerirán datos del
calendario de días festivos para cada localidad, ya que el consumo de agua también dependerá de
estos.
8.1.2 Almacenamiento
La arquitectura constará de tres tipos de almacenamiento:
• Almacenamiento en bruto. Este guardará la información del mismo modo que entra al sis-
tema.
• Base de datos. Guardará la información procesada, lista para ser utilizada por la capa de
explotación del sistema.
• Cola de mensajes. Esta recibirá las trazas de los contadores y se encargará de distribuirlas
tanto a las otras formas de almacenamiento. Además, será la fuente de datos principal para
el procesamiento en tiempo real.
8.1.2.1 Almacenamiento en bruto

El almacenamiento en bruto servirá para retener los datos del mismo modo del que entran, sin pro-
cesarlos previamente. Servirá para poder consultar datos de una manera que previamente no se
había pensado o utilizarlos para nuevos casos de uso que se diseñen.
Teniendo en cuenta la información previa acerca del volumen de datos de entrada al sistema, y te-
niendo en cuenta que los datos se retendrán durante 2 años, se necesitará la siguiente capacidad de
almacenamiento:
3.3004 𝑇𝐵 12 𝑚𝑒𝑠𝑒𝑠
· · 2 𝑎ñ𝑜𝑠 = 79.2096 𝑇𝐵
1 𝑚𝑒𝑠 1 𝑎ñ𝑜
15
230 bytes, en contraposición con el gigabyte, que equivale a 109 bytes.
16
240 bytes, en contraposición con el terabyte, que equivale a 1012 bytes.
17
Durante todo el proyecto se supondrá que un mes tiene 30 días.
41
Añadiendo la información proveniente de las fuentes adicionales y posteriormente redondeando,

añadiendo así un margen de contingencias, el espacio necesario se quedará en 90 TB.
Se guardará en archivos de aproximadamente 16 MB, por lo que dispondremos de unos 5,000 archi-
vos distintos.
Sin embargo, esta capacidad inicial es bastante elevada, por lo que se procede a llevar a cabo un
pequeño estudio sobre utilizar un método de compresión para disminuirla.
8.1.2.1.1 Compresión de los datos

Primero de todo, debido a que el sistema será distribuido, necesitamos un algoritmo de compresión
que permita poder dividir los archivos comprimidos entre los diferentes nodos del sistema. Por lo
general, para descomprimir un archivo, es necesario tener todas las particiones de este. Sin embargo,
necesitamos un programa de compresión que permita poder descomprimir una de las partes del
fichero original, teniendo únicamente una de las partes del archivo descomprimido. Esta propiedad
se llama fragmentabilidad —del inglés, splittability—.
El programa que usaré será bzip2. Este permite la propiedad mencionada. Sin embargo, es ligera-
mente más lento que sus competidores, que no permiten la fragmentabilidad.
En cuanto al ratio de compresión, he generado 4,500 trazas aleatorias. Estas ocupan 324.22 KB en
disco duro. Después de comprimirlas utilizando bzip2 con un nivel de compresión de 9 (el máximo y
por defecto), el archivo ocupa 44.69 KB. Con una simple división, podemos ver que la ratio de com-
presión para este caso es de 7.255.
Si extrapolamos este resultado a la cantidad de datos prevista para el sistema final, se necesitarían
—siempre y cuando se guarden los datos comprimidos— un total de 12.41 TB, en vez de los 90 TB
estimados inicialmente.
8.1.2.2 Base de datos

Del mismo modo que con el almacenamiento en bruto, la información de la base de datos tendrá un
tiempo de vida de 2 años. En esta, se guardarán datos procesados, preparados para ser utilizados
por las aplicaciones.
Esta base de datos será muy simple en contenido. En ella se guardará la información resultante del
procesamiento en batch. Es decir, solamente será clave en uno de los dos casos de uso: el de esti-
mación del consumo total de agua a final del mes.
Debido a que el sistema deberá ser distribuido —de hecho, así funciona Apache Spark y todo el en-
torno de Hadoop, de los cuales hablaré en apartados más adelante— y tendrá que soportar una
carga bastante alta de datos, la tipología de la base de datos que se utilizará será NoSQL. Esta —si se
diseña adecuadamente según las necesidades exactas y específicas del sistema y de las consultas que
se le harán a la base de datos— podrá retornar el resultado de las consultas en un tiempo relativa-
mente bajo sin importar la cantidad de datos que haya almacenados en ella.
8.1.2.2.1 Consultas a realizar

Las consultas que se realizarán a la base de datos serán selecciones por identificador de contador —
o usuario—. Además, se ordenarán los resultados ascendente y descendentemente por fecha.
Asimismo, las consultas podrán ampliarse en el futuro, con nuevos casos de uso. Por lo tanto, la base
de datos tendrá que aceptar nuevos índices.
42
8.1.2.2.2 Estructura
La información y los campos exactos que contendrá la base de datos los podemos ver en la siguiente
tabla:
Campo Tipo de datos

Identificador de contador Número natural
Fecha de estimación Fecha
Mes Número natural
Estimación Número decimal
Tabla 9. Campos de los que constará la base de datos del sistema.
La fecha de creación será la fecha en que se ha estimado el consumo para final de mes. El mes es
aquel al que hace referencia la estimación del consumo.
8.1.2.2.3 Tamaño total

Respecto al tamaño, la base de datos necesitará índices para poder hacer las consultas de una forma
rápida sin importar de su tamaño. Por ello, el espacio reservado a guardar estos índices se deberá
tener en cuenta.
Sin embargo, cada base de datos tiene un modo distinto de usar los índices y de guardarlos. Por lo
tanto, consideraré que el espacio total de la base de datos, contando el espacio ocupado por los
índices, será el espacio usado por los datos multiplicado por tres.
El espacio usado por los datos es más fácil de calcular. Por cada usuario, se generará una estimación
mensual diaria. Además, los datos permanecerán guardados en la base de datos dos años. Por lo
tanto, tendremos que calcular el espacio que ocupará de media una estimación y multiplicarla si-
guiendo la siguiente fórmula.
𝑆 = 2 · 365 · 5,000,000 · 𝑟 · 3
S será el espacio necesario en la base de datos, mientras que r es el espacio medio que ocupará cada
registro de estimación. Se calcularán en bytes. Se ha considerado una cantidad de cinco millones de
usuarios, que es el máximo para el que estará diseñado el sistema.
De modo que solo resta calcular el espacio medio que ocupará cada estimación. Teniendo en cuenta
los campos de la Tabla 9 y un tamaño medio de cada campo que podemos observar en la Tabla 10.
Campo Tamaño (bits) Tamaño (bytes)

Identificador del registro 128 32
Identificador de contador 64 8
Fecha de estimación 64 8
Mes 64 8
Estimación 64 8
Tabla 10. Tamaño medio de cada campo de la base de datos.
Para el tamaño que ocupa cada campo, se ha usado como referencia la base de datos de Google
Datastore. Para ello, se ha considerado de tipo entero el identificador del contador y el mes. La fecha
sería de tipo timestamp y la estimación un numero de coma flotante doble. Además, se ha añadido
un campo, Identificador del registro, que es el que usará el gestor de base de datos para referirse a
cada uno de los registros.
43
De este modo, el parámetro r de la fórmula anterior valdría 64 bytes. De esta manera, y utilizando la
fórmula anterior, el espacio total de la base de datos sería de unos 700 GB.
8.1.2.3 Cola de mensajes

El tercer sistema de almacenamiento con el que contará la arquitectura es una cola de mensajes. Si
bien, no está enfocado al almacenamiento de grandes cantidades de datos durante largos periodos
de tiempo, lo cierto es que almacenará los datos durante una semana. Esta propiedad permite al
sistema recuperar datos en caso de fallida de las instancias. Además, también permitirá el uso de
estos datos por nuevos destinatarios derivados de la creación de casos de uso que no estaban pla-
neados en un primer momento.
Su utilidad principal será organizar las fuentes de entrada de datos, redirigiéndolos hacia los dos
sistemas de almacenamiento anteriormente mencionados. También organizará el flujo entre estos y
desde estos hacia las aplicaciones y otros servicios de la capa de explotación. Por último, servirá para
desacoplar las diferentes piezas del sistema, pudiendo así utilizar unos mismos datos para más de un
uso al mismo tiempo.
Además, el procesamiento en tiempo real consumirá los datos directamente de una cola de mensa-
jes, minimizando la latencia y el tiempo total del sistema.
8.1.3 Procesamiento
El procesamiento de los datos es un apartado de gran relevancia para el proyecto. Distinguiremos
dos tipos de procesamiento, uno para cada caso de uso: batch y streaming. Para ambos, las caracte-
rísticas de las máquinas necesarias serán las mismas, aunque el número de instancias y el tiempo
dedicado a cada caso de uso diferirán entre estos.
Sea cual sea la plataforma escogida para llevar a cabo el desarrollo de la arquitectura, el procesa-
miento se hará mediante el framework de código abierto de Apache, Spark. Este se basa en Apache
Hadoop y MapReduce, aunque una de las diferencias principales que presenta es la utilización de
memoria por delante de disco duro. Esto hace el procesamiento de algunas tareas extremadamente
más rápido (fundamentalmente, aquellas en las que los datos quepan en memoria sin ser segmen-
tados). Este aumento de la eficiencia es, sobre todo, notable en tareas de streaming. Además, la API
que ofrece Spark es de más alto nivel que aquella que ofrece MapReduce, por lo que facilita la pro-
gramación al desarrollador.
Spark dispone de dos tipos de operaciones básicas sobre su unidad principal de trabajo, el RDD:
transformaciones y acciones. Las primeras generan un nuevo RDD a partir de otro, mientras que las
segundas generan un valor a partir de este. Spark es presenta una propiedad llamada lazy evaluation,
que quiere decir evaluación vaga. Debido a esto, las transformaciones no se ejecutan de inmediato
en cuanto se leen, sino que son añadidas a un DAG18 de computación. Este se ejecuta en el momento
que se lee una operación de tipo acción. Las ventajas de esto es que Spark puede optimizar las deci-
siones una vez conoce el DAG entero.
Asimismo, Apache Spark ofrece un paquete adicional para trabajar con datos en streaming de tiempo
real, Apache Spark Streaming.
Tendremos dos tipos de instancias: masters (maestros) y workers (trabajadores).
18
Del inglés, directed acyclic graph y, en castellano, grafo acíclico dirigido.
44
• Los nodos master se encargarán de dirigir el flujo de trabajo, balancear la carga y comuni-
carse con las fuentes y receptores de la información. Si bien, para los procesos batch, no es
necesario una alta disponibilidad, para el stream es un punto clave que el sistema esté siem-
pre en marcha. Por esta razón, se necesitarán dos instancias que actúen como maestros,
pudiendo, el sistema, seguir en funcionamiento incluso con una de las instancias maestras
caídas. Las instancias maestro del sistema contarán con un procesador de 4 núcleos y 16 GB
de memoria RAM cada una. En cuanto a disco duro, la estimación es de unos 200GB (usando
una cota bastante alta, debido a su bajo coste).
• En el caso de los workers, el sistema puede seguir funcionando —si bien no a la misma velo-
cidad— siempre y cuando tenga por lo menos una instancia worker. Ya que estas instancias
harán el «trabajo pesado», se les brindará más recursos. Cada una tendrá un procesador de
16 núcleos y 64 GB de memoria. Utilizarán alrededor de 400GB de disco duro cada instancia,
para poder guardar datos intermedios, ficheros de log e incluso memoria virtual —en el caso
en que la memoria no fuera suficiente—.
Los dos tipos de nodos se comunican gracias a una arquitectura de clúster utilizando Apache Hadoop
YARN. Este es un gestor de recursos y organizador de tareas del entorno de Hadoop. También es el
encargado de asignar recursos del sistema a las aplicaciones que corren en el clúster de entorno
Hadoop.
Con las características de los procesadores anteriormente mencionadas, podemos definir los siguien-
tes tiempos de procesamiento para cada evento o traza:
Tipo de proceso Tiempo en procesar una traza

Stream 3 milisegundos
Batch 150 milisegundos
Tabla 11. Tiempo de procesamiento para Stream y Batch
Como podemos observar, el tiempo de procesamiento para batch se ha definido mucho más elevado
que para stream. Esto se debe a que este tendrá que acceder a una base de datos, así como hacer
operaciones más complejas. Además, se tiene que considerar el tiempo necesario para descomprimir
los archivos antes de poder trabajar con ellos. Por otro lado, los eventos de stream se procesarán de
una manera muy rápida, con la utilización de frameworks diseñados para priorizar la velocidad de los
eventos.
Teniendo en cuenta los tiempos anteriores, para el procesamiento batch contaremos con 2 instan-
cias worker durante 6 horas diarias, mientras que, para tratar los datos en stream, contaremos con
3 instancias permanentes. Para ambos procesamientos, se requerirán 2 instancias maestro.
En las tablas más adelante, podemos ver un resumen de las instancias necesarias para procesar los
datos.
Tipo de instancia Número de Número de Capacidad de Capacidad de Horas

instancias núcleos memoria (GB) disco duro (GB) diarias
Master 2 4 16 200 6
Worker 2 16 64 400 6
Total 4 40 160 1200 24
Tabla 12. Requerimientos de las instancias para el procesamiento en batch
Tipo de instancia Número de Número de Capacidad de Capacidad de Horas

instancias núcleos memoria (GB) disco duro (GB) diarias
Master 2 4 16 200 24
45
Worker 3 16 64 400 24
Total 5 56 224 1600 120
Tabla 13. Requerimientos de las instancias para el procesamiento en stream
Procesamiento Número de Número Capacidad Capacidad Total de

instancias total de total de total de disco horas
núcleos memoria (GB) duro (GB) diarias
Batch 4 40 160 1200 24
Stream 5 56 224 1600 120
Total 9 96 384 2800 144
Tabla 14. Resumen de requerimientos para el procesamiento de los datos
Por último, en la siguiente figura podemos observar de manera muy simple los nodos y clústeres con
los que contará el sistema.
Figura 8. Representación esquemática de los nodos con que contará el sistema de procesamiento. Imagen ampliada en Anexo 2.
8.1.4 Explotación
La última fase por la que pasan los datos es la capa de explotación del sistema. En esta se le da un
uso a los datos recolectados y procesados. Podemos distinguir este uso en dos categorías, según
quién se lo da. Por un lado, servicios, si se lo dan los usuarios finales del sistema. Por el otro lado,
tenemos machine learning, que será desarrollado por el equipo de data science.
8.1.4.1 Machine learning

Todos los datos procesados —ya sea de la base de datos o de la cola de mensajes— serán utilizados
por un equipo de data science. Estos utilizarán los clústeres para probar y desarrollar modelos pre-
dictivos para todos los usuarios. Estos modelos, una vez creados, serán incorporados al flujo de datos
para compararlos con los datos de entrada y así generar una respuesta (fuga o no fuga, por ejemplo).
El modelaje y análisis de datos y el ajuste de los modelos predictivos se realizará en notebooks con
Python, ya que es un lenguaje muy potente y común para este tipo de tareas, en parte gracias a que
cuenta con muchas librerías para ello. Entre ellas, una de las más comunes —y que se utilizará— es
pandas.
46
Si bien el modelaje de los datos se hará en Python utilizando librerías externas, el propio modelo
predictivo se hará mediante Spark. Se accederá al framework Spark utilizando la interfaz de Python
PySpark. Spark cuenta con un potente paquete —aunque inmaduro— de machine learning, llamado
Spark ML. Este incorpora varios elementos interesantes:
• ML Dataset, un conjunto de datos organizados a modo de tabla y distribuido.

• ML Algorithms, que se divide en los siguientes algoritmos:
o Transformers. Son algoritmos que transforman un dataset en otro. Por ejemplo, eli-
minando valores nulos.
o Estimators. Son algoritmos que, a partir de un dataset, se entrenan.
• ML Pipelines. Es uno de los elementos más interesantes del paquete, ya que no tienen una
equivalencia en otras librerías de machine learning, como si lo tienen los otros elementos.
Son secuencias de procesos o algoritmos —como los vistos anteriormente—. Permite juntar
en un orden concreto unos pasos a seguir para llegar de un dataset a otro, o a una predic-
ción.
Además, los estimators y los pipelines tienen métodos para guardarse de una forma distribuida en
sistemas de ficheros que lo soporten (como HDFS).
Por último, el paquete Spark ML es cross-language. Es decir, es compatible con varios lenguajes al
mismo tiempo. De esta manera, el equipo de data science puede trabajar y crear los modelos utili-
zando Python en los notebooks mientras el equipo desarrollador usa estos mismos modelos desde
la API de Spark de Java. Sin embargo, ML únicamente soporta cross-language entre los lenguajes
Python (o PySpark), Java y Scala. No es posible compatibilizar alguno de estos lenguajes con R. Aun-
que para nuestro proyecto, no nos afecta esta incompatibilidad.
8.1.4.2 Servicios
Los usuarios consumirán los datos provenientes del último eslabón del sistema, en forma de con-
sumo de aplicaciones. En esta parte del sistema no me centraré en exceso, ya que depende de la
manera en que un posible comprador de este quiera mostrar los datos. Algunas de las posibilidades
podrían ser las siguientes:
• Avisos por correo electrónico

• Avisos por mensajes de texto, como SMS
• Consulta de datos en forma de tablas y gráficos a través de una aplicación web
La arquitectura que tendrá el sistema proporcionará compatibilidad con prácticamente cualquier sis-
tema de servicio de estos datos debido a que proporciona tanto soporte para aplicaciones en tiempo
real como para aquellas batch.
Sin embargo, dotaré al sistema de una pieza simple para poder visualizar los datos de salida del sis-
tema. Esta tendrá como características principales que será fácil de desarrollar y desplegar una vez
esté acabada, así como de probar. Además, tendrá que permitir un mantenimiento sencillo en caso
de que se quiera arreglar o extender. Por último, tendrá que permitir escalabilidad y flexibilidad de
la potencia de cómputo asociada. Por todo ello, se utilizará una solución que proporcione la posibi-
lidad de crear microservicios, ya que reúnen todas estas propiedades.
La aplicación consumirá datos directamente de la base de datos y también otros provenientes de la

cola de mensajes —en el caso del caso de uso de fugas— y las mostrará.
47
8.1.5 Arquitectura del sistema

En las figuras siguientes, podemos ver una primera aproximación de la arquitectura que tendrá cada
uno de los casos de uso del sistema, por separado, mediante diagramas de flujo de datos.
Figura 9. Diagrama que muestra el flujo de datos del sistema para el caso de uso de detección de fugas de agua,
mediante un análisis en tiempo real de los datos.
Figura 10. Diagrama que muestra el flujo de datos del sistema para el caso de uso de predicción del consumo
mensual de agua, mediante un análisis en batch de los datos
48
9 Análisis de arquitecturas
Una vez definidos las especificaciones del sistema, el siguiente paso es estudiar qué productos y he-
rramientas ofrece cada una de las plataformas a analizar —Microsoft Azure, Google Cloud Platform
y Amazon Web Services—. Solamente analizaremos aquellos servicios que ocupen un lugar en el flujo
de datos del sistema. Es decir, no se compararán posibles balanceadores de carga, herramientas de
monitorización, etc.
A continuación, se elegirán aquellos productos o servicios que más se ajusten a las necesidades y
requisitos del sistema. Se tendrán en cuenta los siguientes factores para escoger entre unos u otros:
• Ajuste de las características del servicio a las necesidades del sistema.

• Compatibilidad del servicio con el resto de los servicios del sistema.
• Precio.
• Facilidad de configuración y mantenimiento.
• Conocimientos previos sobre el servicio.
Además, en caso de disyuntiva entre varias posibilidades, se tendrá en cuenta aquella que facilite
una comparación con equivalentes de las otras dos plataformas.
Asimismo, para cada arquitectura se estimará un precio del conjunto de servicios escogidos. Para
este, hay que tener en cuenta los siguientes factores:
• El precio será únicamente del grosor del sistema: de las piezas principales del flujo de datos,
aquellas que aparecen en el diagrama final de cada arquitectura. Es decir, no se incluirán
otros servicios como balanceadores de carga (aquellos que no estén incluidos en los servi-
cios escogidos), proxies19, enrutadores de DNS, etc.
• Se añadirá un servicio básico de soporte de forma que incluya aproximadamente las mismas
ventajas en las tres plataformas.
• Los servicios estarán adaptados a poder trabajar con el máximo de datos por los que estará
diseñado el sistema (véase 8.1).
Por último, se compararán las tres soluciones y se elegirá la óptima según unos criterios.
9.1 Microsoft Azure

La comparación de los diferentes productos y servicios la haré separándolos por categorías:
• Herramientas de mensajería
• Almacenamiento de datos no estructurados
• Bases de datos
• Procesamiento y análisis de datos
• Plataforma de microservicios
9.1.1 Herramientas de mensajería

Azure ofrece un gran número de servicios de mensajería:
19
En singular, proxy. Su traducción sería representante y es un servidor o servicio intermediario entre un
cliente y un servidor, al que hace una petición.
49
• Apache Kafka en Azure HDInsight

• Azure Event Grid
• Azure Event Hubs
• Azure IoT Hub
• Azure Notification Hubs
• Azure Service Bus Queue
• Azure Service Bus Topic
• Azure Storage Queue
Debido a que buscamos una solución simple y que permita un gran número de envíos de mensajes
por segundo, la elección es Azure Event Hubs. Esta es la herramienta que permite un mayor rendi-
miento de mensajes en la plataforma. Además, debido a que es una herramienta de Azure, se integra
completamente con el resto de los servicios de Microsoft y su gestión de recursos la lleva a cabo la
propia plataforma.
Esta herramienta, además, tiene una funcionalidad, llamada Azure Event Hubs Capture, que permite
redirigir los datos a fuentes de almacenamiento como los que veremos más adelante. Esta permite
hasta 1,000 trazas de datos recibidas por segundo por unidad de procesamiento, por lo que requeri-
ríamos diecisiete para hacer frente a la demanda especificada en el apartado anterior.
9.1.2 Almacenamiento de datos no estructurados

En cuanto a almacenamiento de datos no estructurados, Azure ofrece una única solución: Azure Sto-
rage. Esta es durable y ofrece alta disponibilidad. También ofrece seguridad gracias a una encripta-
ción automática. Está diseñada para ser escalable a gran escala y gestionada por Azure. Además, está
integrada totalmente con el resto de los productos de Microsoft Azure.
Azure Storage ofrece diversos servicios:
• Azure Blobs, para el almacenamiento de objetos en forma de texto y datos binarios.

• Azure Files, que permite compartir archivos en cloud, orientado principalmente para aplica-
ciones más antiguas.
• Azure Queues, destinado al envío y almacenamiento de mensajes entre distintos servicios o
componentes.
• Azure Tables, para almacenar los datos en una tabla NoSQL en formato key-value20.
De estas soluciones, la que más se adecúa es Azure Blobs, debido a la naturaleza de los datos que
almacenará el sistema y el uso que se les dará. También se le conoce como Blob Storage.
9.1.3 Bases de datos

Debido a la naturaleza de los datos a almacenar en la base de datos y el uso que se hará de estos, la
base de datos óptima es una no relacional del estilo key-value. Azure cuenta con una colección muy
amplia de bases de datos. Sin embargo, con las propiedades que buscamos para el sistema, sola-
mente encontramos dos:
• Azure Cosmos DB
• Azure Tables storage
20
Tipo de base de datos en la cual se guardan los datos en registros, compuestos por una clave que lo
identifica (key) y un contenido (value).
50
Ambas presentan características muy parecidas, con una diferencia principal: Cosmos DB permite el
almacenamiento de datos en diversas regiones simultáneamente, mientras que Azure Tables única-
mente permite una región. Además, según un estudio (Delgado, 2017), Cosmos DB tiene general-
mente un mejor rendimiento.
Por ello (y además porque es el buque insignia de Azure en lo que se refiere a bases de datos), la
base de datos escogida será Azure Cosmos DB.
9.1.4 Procesamiento y análisis de datos

Microsoft Azure ofrece un gran número de servicios para el cómputo de datos. Por un lado, ofrece
herramientas de orquestación de contenedores, como Azure Kubernetes Service, Service Fabric y
Container Instances. Por el otro lado, tiene a disposición instancias de máquinas virtuales con Virtual
Machines. También ofrece un procesamiento serverless21 mediante Azure Functions y otro en lotes
con Azure Batch. Sin embargo, debido a la naturaleza de los datos, buscamos un enfoque más analí-
tico y enfocado al procesamiento de los datos desde un enfoque de big data.
Además, se necesitará una herramienta a la que pueda acceder el equipo de data science para expe-
rimentar y crear los modelos predictivos para los dos casos de uso. Típicamente, este trabajo se hace
mediante notebooks.
Con estas características, Microsoft Azure ofrece dos servicios que cumplen los requisitos: Azure Da-
tabricks y Azure HDInsight.
Azure Databricks es un servicio analítico basado en Apache Spark muy flexible, escalable y comple-
tamente gestionado por Azure.
Azure HDInsight, por el contrario, ofrece un entorno de frameworks de código abierto —como Apa-
che Hadoop, Spark y Kafka— que trabaja sobre las mismas máquinas virtuales ofrecidas por el servi-
cio Virtual Machines. Si bien —al contrario que Azure Databricks— este requiere de una configura-
ción inicial, es muy sencilla y consiste en indicar el número de instancias requeridas y los servicios
deseados.
Debido a que Azure HDInsight es más completo y permite una extensión de casos de uso más fácil
que Azure Databricks, escogeremos este.
9.1.5 Plataforma de microservicios

Por último, los datos finales se mostrarán al usuario a través de una plataforma de microservicios.
Para ello tenemos dos tipos de servicios diferentes: aplicaciones tradicionales y aplicaciones en con-
tenedores.
Azure ofrece principalmente tres productos enfocados al uso de contenedores para llevarlo a cabo:
• Azure Kubernetes Service (AKS), que permite utilizar aplicaciones de Kubernetes en clúste-
res de Azure.
• Azure Service Fabric, por el cual Azure, con su propia infraestructura, orquesta contenedores
creados por el usuario.
21
Modelo de cómputo en el cloud por el cual el proveedor de este se encarga de gestionar los recursos
del servidor, dando así una impresión de no estar usando uno.
51
• Azure Container Instances, que ofrece un servicio serverless para trabajar con contenedores.
AKS utiliza el motor de la tecnología open-source Kubernetes, un sistema de orquestación de conte-

nedores. A diferencia de Service Fabric, que requiere del uso de un SDK22 específico para este (y, por
tanto, pierde reusabilidad y portabilidad), AKS es un sistema globalmente usado. No solo dentro de
la plataforma Azure, sino en la mayoría.
Sin embargo, las dos soluciones son más complejas que lo que se requiere —recordemos, una tec-
nología que permita desarrollar y desplegar microservicios de una forma fácil y con la menor confi-
guración posible—. Esta necesidad la cubre especialmente el tercer servicio ofrecido por Azure:
Azure Container Instances.
Por otro lado, Azure también cuenta con entornos para desplegar aplicaciones tradicionales. Si bien
esta opción es más rápida de desarrollar, es más ineficiente para aplicaciones complejas desarrolla-
das por grandes equipos y actualizadas con mucha frecuencia. Tenemos los siguientes servicios:
• Azure App Service;

• Azure Cloud Services;
• Azure Virtual Machines;
• Azure Web Apps.
App service y Web services son dos servicios muy simples cuyas capacidades están limitadas, en los
cuales no es posible monitorizar si quiera la aplicación desplegada. Azure Virtual Machines es el ser-
vicio que ofrece Azure de máquinas virtuales, en las que, entre otras cosas, se pueden desplegar
servicios web. En este servicio se tiene un control a muy bajo nivel del sistema. Por último, Cloud
Services está entre las dos primeras y esta última. Permite un despliegue sencillo de la aplicación —
sin tener que preocuparse de configuraciones de las máquinas— a la vez que permite configuracio-
nes básicas y monitorización. Estas características son las que más se adecuan a los requisitos de
nuestros casos de uso.
Cabe mencionar que, aunque no lo he añadido en la lista de servicios para desplegar aplicaciones en
contenedores, con Azure Virtual Machines también se pueden llevar a cabo, puesto que, con este,
se tiene un control muy alto de los recursos del sistema. Sin embargo, puesto que hay otras tres
alternativas que abarcan la mayor parte del nicho de mercado, muy rara vez esta sería la solución a
escoger.
En la siguiente figura, podemos ver una comparativa de tres de las opciones que se barajan para este
servicio. Podemos observar cómo Cloud Services está más equilibrada entre las cuatro características
que se comparan.
22
Del inglés, Software development kit y, traducido, equipo de desarrollo de software, es un conjunto de
herramientas, componentes y APIs que permiten a un desarrollador a crear una aplicación.
52
0 2 4 6 8 10
Virtual Machines
Cloud Services
Web Apps
Control Soporte para aplicaciones antiguas Facilidad de gestión Agilidad
Figura 9. Comparación de Azure Virtual Machines, Azure Cloud Services y Azure Web Apps en control, soporte para aplicaciones
antiguas, facilidad de gestión y agilidad. Datos recopilados en la web de CloudAcademy (Badola, 2015).
La elección final de esta pieza del sistema será una aplicación tradicional debido a la necesidad de un
desarrollo ligero y una aplicación sencilla que no requiere mucho mantenimiento. Por lo tanto, se
utilizará Azure Cloud Services.
9.1.6 Esquema final

En la Figura 10, podemos observar el esquema de la arquitectura utilizando los servicios anterior-
mente mencionados.
Figura 10. Diagrama del flujo de datos de la arquitectura utilizando Microsoft Azure. Imagen ampliada en Anexo 3.
9.1.7 Precio
En la siguiente tabla mostraré el precio de cada servicio escogido y el precio final de la arquitectura.
53
Servicio Desglose (propiedad – valor) Precio*

Ingreso (trazas recibidas al mes) 43,200 1,080
Unidades de procesamiento 17 310.25
Event Hubs Funcionalidad Capture 17 1,050.25
Total 2,440.5
Blob Storage Capacidad en TB (redundancia LRS) 16 270.81
Operaciones de escritura (al mes) 230,000** 1.05
Operaciones de lectura (al mes) 150,000 0.05
Total 271.91
CosmosDB Número de regiones de escritura Solamente una
RU/s *** 500 24.62
Almacenamiento, en GB 700 674.64
Total 699.26
HDInsight Streaming Nodos maestros (4 núcleos, 14 GB 2 instancias, 730 363.21
de memoria) horas mensuales
Nodos trabajadores (16 núcleos, 56 3 instancias, 730 2,179.26
GB de memoria) horas mensuales
Total 2,542.47
HDInsight Batch Nodos maestros (4 núcleos, 14 GB 2 instancias, 183 91.05
de memoria) horas mensuales
Nodos trabajadores (16 núcleos, 56 2 instancias, 183 364.20
GB de memoria) horas mensuales
Total 455.26
Cloud Services Instancias de 8 núcleos y 32 GB de 2 instancias, 730 1,044.07
memoria horas mensuales
Total 1044.07
Soporte Professional Direct / Tiempo de res- 843.30
puesta de 1 hora
Total 843.30
Total 8,296.77
Tabla 15. Desglose de precios para la arquitectura de Microsoft Azure.
* El precio mostrado en la tabla anterior es de euros mensuales.
** Al día se recaudan 120,960,000,000 bytes (véase apartado 8.1.1.1) escritos en ficheros de 16MB.
Esto equivale a la escritura de algo más de 7,500 archivos diarios y un poco menos de 230,000 archi-
vos escritos al mes.
***RU significa request units. Es la unidad que utiliza Azure para calcular el número de consultas
medias. Por ejemplo, la lectura de un objeto de 1KB consume 1 RU.
Todos los precios son seleccionando servidores situados en la región geográfica llamada West Eu-
rope, con localización en los Países Bajos.
9.2 Google Cloud Platform

El análisis de los distintos servicios de esta plataforma se hará dividiéndolos por categorías.

Google ofrece un servicio para esta tarea, Google Cloud Pub/Sub. Este permite la ingesta de hasta
10 MB por segundo por stream —recordemos que el sistema estará diseñado para soportar un ren-
dimiento máximo de unos 1.4 MB por segundo—.
54
Este servicio dispone de dos modos de hacer llegar los mensajes des de la fuente, o publicadores (en
Cloud Pub/Sub, el Publisher), hasta el destinatario, o suscriptor (Subscriber): «empujando» (push) o
«extrayéndolos» (pull). La segunda permite un mayor volumen de mensajes por segundo, por lo que
usaremos esta configuración.

Encontramos tres servicios que permiten almacenar datos y archivos en Google Cloud Platform:
• Cloud Filestore
• Cloud Storage
• Persistent Disk
Sin embargo, rápidamente podemos ver como únicamente una de ellas se adapta a los requisitos:
Cloud Storage. Persistent Disk es una solución para almacenar datos provenientes de Compute En-
gine y Kubernetes Engine, dos servicios de máquinas virtuales. Más allá de esos usos, no es posible
acceder ni utilizar los datos almacenados él. Cloud Filestore y Cloud Storage son soluciones parecidas,
con algunas diferencias. Filestore es más rápido y está optimizado para trabajar juntamente con
Compute Engine y Kubernetes Engine. Además, su almacenamiento es a nivel de fichero, mientras
que Cloud Storage guarda los datos en objetos, sin tener consciencia de una jerarquía. Por último,
Cloud Filestore es bastante más caro (aproximadamente 10 veces más).
Debido a estas diferencias y a los requisitos de ambos casos de uso, veo más conveniente utilizar
Cloud Storage.
9.2.3 Conector de entrada con almacenamiento de datos

Los datos los datos entrantes en el sistema están capturados por Google Cloud Pub/Sub y uno de los
servicios a los que son enviados es Google Storage. Sin embargo, Cloud Pub/Sub no tiene la posibili-
dad de dirigir datos hacia este almacenamiento.
Para ello, utilizaremos un servicio adicional llamado Google Cloud Dataflow. Este es un servicio com-
pletamente gestionado por Google que permite crear pipelines de datos y transformarlos y proce-
sarlos en stream y en batch. Además, cuenta con plantillas ya creadas que permiten hacer varias
tareas. Una de estas es crear un pipeline de envío de datos de un topic23 de Cloud Pub/Sub a un
bucket de Google Storage (unidad de almacenamiento independiente donde se guardan los datos).

Google dispone de tres servicios de bases de datos que inicialmente parecen adaptarse a los requi-
sitos del sistema:
• Cloud Bigtable.
• Cloud Datastore, llamado Cloud Firestore Datastore Mode desde enero de 2019.
• Cloud Firestore, llamado Cloud Firestore Native Mode desde enero de 2019.
23
Unidad de almacenamiento de Cloud Pub/Sub (también existe en otras herramientas parecidas, como
Apache Kafka, aunque su funcionamiento cambia en cada tecnología) a la que se envían los datos en
forma de mensajes y los redirecciona hacia uno o varios suscriptores.
55
La comparativa de los tres servicios la he hecho con ayuda del siguiente esquema facilitado por
Google (véase Figura 11). En el mencionado esquema, aparecen los servicios Datastore y Firestore
con la nomenclatura antigua.
Figura 11. Árbol de decisión de opciones de almacenamiento de Google Cloud Platform. Imagen extraída de la web de Google
Cloud, 2017, y traducida. Usada con el permiso de Google. Imagen ampliada en Anexo 4.
Utilizando el esquema anterior y teniendo en cuenta los siguientes factores:
• trataremos con datos estructurados;

• nuestra herramienta de análisis no será la base de datos, sino Apache Spark;
• los datos no serán relacionales;
• no requeriremos de un SDK específico para dispositivos móviles;
se utilizará Cloud Datastore.
Debido a los últimos cambios (Cloud Datastore pasa a ser una modalidad de base de datos del servi-
cio Cloud Firestore), se ha decidido utilizar el servicio antiguo de Cloud Datastore en lugar del nuevo
Cloud Firestore en modo Datastore para aprovechar la estabilidad que tenía. Sin embargo, a finales
de este año —2019—, se actualizará automáticamente al nuevo.

La única solución presente en el entorno de Google para ejecutar aplicaciones Spark y Spark Strea-
ming —recordemos la arquitectura Lambda— es utilizar Cloud Dataproc. Este es el equivalente de
Google a Azure HDInsight, un entorno completo de Hadoop y Spark. Cloud Dataproc se ejecuta por
encima de los servidores de Compute Engine.
Una de las configuraciones posibles de Cloud Dataproc es la utilización de notebooks para el análisis
de datos mediante Apache Zeppelin y Jupyter.
56
Por último, para utilizar el clúster en modo alta disponibilidad, Dataproc utiliza tres nodos maestros,
en lugar de dos. Además, utiliza un componente adicional, Apache Zookeeper.

De igual manera que con Microsoft Azure, con Google Cloud también disponemos de servicios para
desplegar aplicaciones tradicionales y aplicaciones en contenedores. Si bien esta vez ya no vamos a
valorar cuál se adapta más a nuestras necesidades, presentaré las alternativas que ofrece Google
respecto a los dos tipos.
Con respecto a los servicios para desplegar aplicaciones en contenedores, en Google tenemos dos
opciones:
• Google Compute Engine (GCE)

• Google Kubernetes Engine (GKE), también llamado Google Container Engine
Google carece de servicios «de la casa» para tratar con este tipo de aplicaciones. Esto se debe a que
Kubernetes nació como un proyecto interno de Google, que más tarde pasaría a estar mantenido por
Cloud Native Computing Foundation. Por lo tanto, Kubernetes Engine es la única opción de desplegar
aplicaciones en contenedores de una manera sencilla.
La otra manera es utilizando Compute Engine. Sin embargo, igual que con Microsoft Azure, esta op-
ción no está recomendada a no ser que sea necesaria una migración de unos sistemas actuales con
un orquestador de contenedores diferente a Kubernetes.
Por otro lado, para desplegar aplicaciones sin contenedores, Google ofrece los siguientes dos servi-
cios:
• Google App Engine (GAE)

• Google Compute Engine
App Engine permite desplegar una aplicación con uno o varios servicios. Además, hace sencillo el
control de versiones de cada uno de los servicios, así como el balance de la carga y del tráfico entre
diferentes versiones. Esto último también hace posible de una manera muy sencilla realizar pruebas
A/B. Por último, cuenta con dos configuraciones de entorno: Standard y Flexible. La primera es mu-
cho más barata y tiene menos capacidades. Además, solo permite utilizar Google Go como entorno.
La segunda dispone de más memoria y potencia permite usar más entornos.
Google Compute Engine, como he mencionado antes, es más completo y configurable, aunque más
difícil de desarrollar y mantener.
Por las mismas razones que con Microsoft Azure, se escogerá un servicio sin contenedores. En este
caso solo hay uno que cumple los requisitos: Google App Engine.
Esta elección está, además, contrastada con el siguiente esquema (Figura 12):
57
Figura 12. Árbol de decisión de opciones para cómputo y despliegue de aplicaciones de Google
Cloud Platform. Imagen extraída de la web de Google Cloud, 2017, modificada y traducida.
Usada con el permiso de Google.
9.2.7 Esquema final
58
Figura 13. Diagrama del flujo de datos de la arquitectura utilizando Google Cloud Platform. Imagen ampliada en Anexo 5.
9.2.8 Precio
En la Tabla 16, muestro el precio de cada servicio escogido y el precio final de la arquitectura.

Volumen de datos mensuales, en GB 43,200
Cloud Pub/Sub Volumen de datos retenidos (1 semana) 200
Total 2,373.72
Cloud Dataflow Nodos trabajadores (4 núcleos, 15 GB de memo- 2 instancias, 730 ho-
ria) ras mensuales
Total 466.35
Cloud Storage Capacidad en TB 16
Operaciones PUT, POST, GET al mes (millones) 1
Total 298.51
Cloud Datastore Almacenamiento, en GB 700
Lecturas de entidades al mes 150,000,000
Total 859.97
Cloud Dataproc Nodos maestros (4 núcleos, 15 GB de memoria) 3 instancias, 730 ho- 191.67
Streaming ras mensuales
Nodos trabajadores (16 núcleos, 60 GB de memo- 3 instancias, 730 ho- 1,150.01
ria) ras mensuales
Horas de entorno de Dataproc 730 horas 235.81
Total 1,385.82
Cloud Dataproc Nodos maestros (4 núcleos, 15 GB de memoria) 3 instancias, 183 ho- 68.60
Batch ras mensuales
Nodos trabajadores (16 núcleos, 60 GB de memo- 2 instancias, 183 ho- 274.41
ria) ras mensuales
Total 343.01
App Engine Instancias de 8 núcleos y 32 GB de memoria en 2 instancias, 730 ho- 933.81
entorno flexible ras mensuales
Total 933.81
Soporte Gold support / Tiempo de respuesta de 1 hora 595.21
Total 595.21
Total 7256.40
Tabla 16. Desglose de precios para la arquitectura de Google Cloud Platform.
59
Todos los precios son seleccionando servidores situados en la región geográfica de Bélgica.
9.3 Amazon Web Services

De igual forma que en los casos anteriores, el análisis de Amazon Web Services se dividirá en las
diferentes categorías.

AWS ofrece los siguientes servicios que permiten gestionar las trazas de información entrantes en el
sistema, así como la distribución de información entre diferentes partes de este.
• Amazon Managed Streaming for Apache Kafka (MSK) es un servicio que permite desplegar
aplicaciones que usan Apache Kafka.
• Amazon Simple Queue Service (SQS) es un servicio serverless de Amazon muy simple que
permite el envío sencillo de información entre varias aplicaciones.
• Amazon Simple Notification Service (SNS) es muy parecido a SQS con la diferencia de que la
información llega a los receptores mediante push en vez de pull.
• Amazon Kinesis es un servicio enfocado al procesamiento de datos de naturaleza de strea-
ming.
• Amazon Message Broker (MQ) es un servicio que permite desplegar aplicaciones que usan
Apache ActiveMQ.
Debido a uno de los requisitos de que la arquitectura final sea lo más sencilla posible, descartamos
MSK y MQ debido a que se basan en proyectos de Apache y no están gestionados por Amazon. Las
otras tres soluciones no requieren de un mantenimiento de servidores por parte del usuario.
De las tres, SNS está enfocado a otro tipo de tratamiento de datos, siendo una de sus funcionalidades
principales el envío de SMS, correos electrónicos, etc. De las otras dos, Kinesis es la solución más
enfocada a tratar grandes cantidades de datos por segundos. SQS por defecto tiene un límite de
3,000 mensajes o trazas de información por segundo —recordemos que el sistema estará diseñado
para soportar hasta 16,667 mensajes por segundo—.
Por otro lado, Amazon Kinesis está compuesto de shards, los cuales facilitan la escalabilidad del ser-
vicio. Cada shard es una unidad de procesamiento que puede soportar hasta 1,000 mensajes por
segundo, por lo que se necesitarían diecisiete en total para obtener el throughput24 requerido. Este
servicio tiene varios modos de funcionamiento:
• Kinesis Data Analytics, para hacer un procesamiento analítico de datos en tiempo real con
SQL o Java;
• Kinesis Data Firehose, para capturar y transformar datos y guardarlos en otros servicios de
almacenamiento;
• Kinesis Data Streams, para procesar y capturar en tiempo real, de una forma escalable, de
muchas fuentes de datos distintas
• Kinesis Video Streams, para procesar datos provenientes de fuentes de vídeo en tiempo real.
Por lo tanto, debido a las razones anteriormente explicadas, se utilizará Amazon Kinesis. En concreto,
se utilizarán los servicios de Data Streams y Data Firehose.
24
Volumen o cantidad de datos o de trabajo que procesa un sistema por unidad de tiempo.
60

AWS ofrece tres servicios principalmente para almacenar todo tipo de datos:
• Amazon Simple Storage Service (S3), probablemente uno de los productos más conocidos
de AWS.
• Amazon Elastic Block Store (EBS), un servicio de almacenamiento de bloques diseñado prin-
cipalmente para ser el almacenamiento principal de EC2.
• Amazon Elastic File System (EFS), un sistema de almacenamiento de ficheros.
EBS, está diseñado para acceder únicamente desde EC2, su servicio de capacidad de cómputo en
cloud. Además, no escala demasiado. Sin embargo, su velocidad es mayor que las otras dos solucio-
nes. Por otro lado, EFS sí escala, aunque su latencia es ligeramente mayor a la de EBS. El acceso a
este almacenamiento se restringe a algunos servicios de AWS. Por último, S3 es la solución más lenta
de las tres, así como la más fácilmente accesible, pues se puede acceder a los datos almacenados
desde prácticamente cualquier servicio, incluidos aquellos de otros proveedores.
Para entender mejor el párrafo anterior, en la Tabla 17 podemos observar una comparativa muy
simple de los tres servicios. Las puntuaciones son mejores cuanto más bajas, y simplemente son un
orden de mejor a peor. Puede haber empates.
3,5
2,5
1,5
0,5
0
S3 EBS EFS
Escalabilidad Accesibilidad Velocidad
Tabla 17. Comparación de los distintos servicios de almacenamiento de AWS.
Debido a los casos de uso a desarrollar, y que el procesamiento en tiempo real no necesitará acceso
directo a un sistema de almacenamiento, la baja latencia de este no es un requisito indispensable. Sí
que lo es la accesibilidad desde cualquier servicio, ya que facilitará la integración con otros servicios
en el futuro y la reusabilidad del sistema final. Por tanto, se utilizará Simple Storage Service.

Amazon Web Services cuenta con múltiples servicios de bases de datos (relacionales, en memoria,
de grafos, de clave-valor, etc.). Sin embargo, un primer filtro de requisitos —pues para nuestros casos
61
de uso buscamos clave valor o de documentos (que no son más que un tipo de estas)—, solamente
hay dos:
• Amazon DocumentDB
• Amazon DynamoDB
DocumentDB es una base de datos orientada al almacenamiento de los datos en documentos, mien-
tras que DynamoDB tiene estructura key-value. Cabe destacar que DocumentDB tiene compatibili-
dad con bases de datos MongoDB (también una base de datos de estructura de documentos).
Si bien su rendimiento es muy parecido, debido a la simplicidad del esquema que tendrá la base de
datos y de las consultas que se ejecutarán en esta, una base de datos de clave-valor será suficiente.
Por lo tanto, se utilizará DynamoDB.

AWS ofrece únicamente un servicio en el que se pueden ejecutar aplicaciones que utilizan Apache
Spark. Este es Amazon Elastic MapReduce (EMR). Este es el equivalente a las soluciones escogidas
para la misma funcionalidad en los otros dos proveedores. Permite ejecutar procesos y herramientas
del entorno Hadoop, además de Spark.
También, de igual manera que en los casos anteriores, permite ejecutar notebooks en él. El propio
entorno de EMR tiene integrado Apache Zepelin, aunque también se puede utilizar Amazon EMR
Notebooks, basado en Jupyter. Este último será el que usaríamos.
Este servicio corre por encima de uno de los servicios más importantes de AWS, Elastic Compute
Cloud (EC2), por lo que se beneficia de sus mismas ventajas, como la seguridad.
Sin embargo, tiene una desventaja y es que no dispone de modo de alta disponibilidad que permita
el uso de dos nodos máster para aplicaciones YARN (el gestor de recursos que utiliza Apache Spark).

Amazon Web Services también dispone de servicios para desplegar contenedores:
• Amazon Elastic Container Service (ECS)

• Amazon Elastic Container Service for Kubernetes (EKS)
• Amazon Fargate
Las dos primeras opciones (ECS y EKS) son muy parecidas, con la única diferencia de que EKS utiliza
el motor de Kubernetes de fondo. Ambas permiten desplegar aplicaciones en Contenedores, como
Docker, y administrar los recursos. Fargate es ligeramente distinta a estas dos, ya que es una solución
serverless y, por tanto, los recursos de los servidores están gestionados por la propia plataforma. De
hecho, Fargate podría decirse que es un modo de configuración de ECS donde los recursos están
autogestionados.
Para desplegar aplicaciones sin contenedores, encontramos:
• Amazon Lightsail
• AWS Elastic Beanstalk
Sin embargo, Lightsail no permite el despliegue de microservicios, ya que es una solución enfocada
a aplicaciones muy sencillas, páginas web y entornos de pruebas. Sin embargo, Elastic Beanstalk, sí.
62
Esta es muy parecida a App Engine de Google: permite un despliegue fácil de diferentes servicios,
proporciona un balanceador de carga automático, tiene un fácil manejo de las diferentes versiones
e incorpora una herramienta de monitorización.
De igual manera que en las anteriores plataformas, también se podrían desplegar aplicaciones, tanto
en contenedores como no, utilizando servidores planos. Estos serían provistos por el servicio Elastic
Compute Cloud (EC2). Sin embargo, conlleva mucho trabajo de configuración y mantenimiento a
cambio de otras propiedades que no son necesarias en nuestro caso de uso.
Por lo tanto, utilizaremos AWS Elastic Beanstalk.
9.3.6 Esquema final

En la Figura 14, podemos observar el esquema de la arquitectura utilizando los servicios anterior-
mente mencionados.
Figura 14. Diagrama de flujo de datos de la arquitectura utilizando Amazon Web Services. Imagen ampliada en Anexo 6Error! Ref-
erence source not found..
9.3.7 Precio
En la siguiente tabla mostraré el precio de cada servicio escogido y el precio final de la arquitectura.

Trazas por segundo 17000 775.02
Número de shards 17 222.75
Kinesis Tamaño de las trazas (en bytes) 84
Retención extendida Sí 301.15
Total 1298.92
S3 Capacidad en TB 16 443.20
Operaciones de escritura mensuales 230,000 1.22
Operaciones de lectura mensuales 150,000 0.07
Total 444.49
DynamoDB Almacenamiento, en GB 700 245.02
63
Almacenamamiento de índices 1036.32

Total 1281.34
EMR* Nodos trabajadores (16 núcleos, 60 GB de memo- 3 instancias, 730 ho-
ria) (streaming) ras mensuales
Nodos trabajadores (16 núcleos, 60 GB de memo- 2 instancias, 183 ho-
ria) (batch) ras mensuales
Total 2787.48
Elastic Beans- Instancias de 8 núcleos y 32 GB de memoria en 2 instancias, 730 ho- 655.88
talk** entorno flexible ras mensuales
Total 655.88
Soporte Gold support / Tiempo de respuesta de 1 hora 511.68
Total 646.82
Total 7114.93
Tabla 18. Desglose de precios para la arquitectura de Amazon Web Services.
*Para calcular el coste total de Elastic MapReduce, solamente hay que escoger las especificaciones
de los nodos worker, pues los nodos master los proporciona Amazon automáticamente.
**AWS no proporciona forma de calcular el coste de Elastic Beanstalk. Para ello, he añadido el precio
de las instancias aproximadas de EC2 (las máquinas virtuales sobre las cuales funciona Beanstalk)
que serían necesarias.
9.4 Comparación de las arquitecturas y elección

Una vez definidas los servicios del flujo de datos de cada una de las tres arquitecturas, el siguiente
paso es comparar las tres plataformas y arquitecturas en base a unos criterios para escoger una con
la que realizar la pequeña demo.
Los criterios son los siguientes:
• Facilidad de uso de la interfaz.

• Precio mensual del sistema diseñado.
• Potencia y velocidad de procesamiento. Este criterio se mide simplemente teniendo en
cuenta la cantidad de núcleos y memoria RAM de las instancias masters y workers de las
máquinas virtuales escogidas. Puesto que las cantidades a escoger están definidas y no se
puede elegir con exactitud, se ha intentado coger las más aproximadas a los requisitos defi-
nidos en el apartado 8.1.3.
• Claridad y facilidad para calcular el presupuesto. Está basado en la experiencia personal des-
pués de hacer el presupuesto de las tres plataformas.
• Cantidad, calidad y organización de la documentación oficial. Esto es, documentación en la
propia página web de la propia plataforma y de cada uno de los servicios que ofrece, infor-
mación en cuentas oficiales de otras páginas web, perfección de la documentación de las
APIs que ofrece y cantidad código a modo de ejemplo en plataformas como GitHub.
• Sostenibilidad medioambiental de los sistemas. Esta información está extraída del estudio
llevado a cabo en el apartado 6.3.3.
• Número de zonas disponibles en Europa Central y Occidental. El número de zonas disponi-
bles —cuya información se encuentra en las páginas web oficiales de cada una de las plata-
formas— se tiene en cuenta por posibles expansiones en el futuro a otras regiones de Eu-
ropa o del mundo.
64
• Experiencia previa del equipo de desarrollo en la plataforma. Aquí tengo en cuenta mi expe-
riencia, por muy baja que sea en las tres plataformas, junto con la de mi director del pro-
yecto, Jordi Sabater.
• Utilidad de la plataforma para futuros proyectos. Para este criterio, he tenido en cuenta el
número de nuevos proyectos llevados a cabo con cada una de las tres plataformas y sus
tendencias.
• Cantidad de información no oficial. Esto es, de fuentes como: páginas web especializadas en
tecnologías cloud; foros informáticos, como Stack Overflow; plataformas de vídeo, como
Youtube; y otras fuentes de información no pertenecientes a la propia plataforma.
• Adaptación de los servicios escogidos a las necesidades reales. Esto es, cómo se acercan las
soluciones escogidas de cada arquitectura a lo que realmente requiere el sistema.
Por último, y antes de mostrar la tabla comparativa resultante, en la tabla Tabla 19, podemos ver
una correspondencia entre los anteriores criterios y su código identificativo.
Facilidad de uso de la interfaz C1

Precio mensual del sistema diseñado C2
Potencia y velocidad de procesamiento C3
Claridad y facilidad para calcular el presupuesto C4
Cantidad, calidad y organización de la documentación oficial C5
Sostenibilidad medioambiental de los sistemas C6
Número de zonas disponibles en Europa Central y Occidental C7
Experiencia previa del equipo de desarrollo en la plataforma C8
Utilidad de la plataforma para futuros proyectos. C9
Cantidad de información no oficial C10
Adaptación de los servicios escogidos a las necesidades reales C11
Tabla 19. Correspondencia de criterios de comparación con su código identificador.
En la Tabla 20, podemos ver la comparación de las tres plataformas según los criterios definidos
anteriormente y su ponderación. Esta es una ponderación entre 1 y 5 según la importancia de cada
uno de los criterios para valorar a las plataformas a la hora de escoger una u otra. Cuanto mayor sea
la ponderación, más importancia tendrá. Las puntuaciones de cada criterio están sobre 10. En el total
de cada plataforma (última fila), podemos ver dos números. El primero es la puntuación de la plata-
forma —sobre 110— sin tener en cuenta las ponderaciones. Por lo tanto, esta puntuación no será la
determinante. La segunda puntuación —sobre 10—, tiene en cuenta las ponderaciones.
Criterio Ponderación Amazon Web Services Microsoft Azure Google Cloud Platform
C1 2 8 8 9
C2 2 9 6,5 8,5
C3 3 9 8 8,5
C4 4 9 7 8
C5 5 6 7 9
C6 5 9 9 9
C7 4 5 9 7
C8 4 9 7 6
C9 5 8 8 6
C10 3 9 6 8,5
C11 5 9 8 8
Total 42 90 8,095238095 83,5 7,69047619 87,5 7,857142857
Tabla 20. Comparación de las AWS, Azure y GCP.
65
Podemos ver que Amazon Web Services resulta ser la plataforma más acorde con las necesidades
del sistema si solamente tenemos en cuenta estos criterios. Sin embargo, tiene un defecto que no
incorporan las otras dos. Como he mencionado en el apartado Procesamiento y análisis de da-
tos9.3.4, Amazon no dispone de un modo de alta disponibilidad para los clústeres de Elastic MapRe-
duce. Esto significa que los nodos maestros son puntos únicos de fallo (single point of failure, en
inglés) debido a que EMR no es compatible con la utilización de más de un único nodo maestro.
De este modo, un sistema con estas características no cumpliría el requisito no funcional fiabilidad.
El problema que conlleva es que no dispone de ningún workaround25 medianamente sencillo para
mitigar este inconveniente y es impensable llevar a cabo una tarea crítica con este entorno.
Este criterio no se ha tenido en cuenta a la hora de realizar la tabla comparativa debido a que no es
cuantificable en una escala —es una propiedad binaria—. Por lo tanto, la plataforma con la que fi-
nalmente desarrollaré la demo de la arquitectura es Google Cloud Platform.
Si bien en el momento del estudio, Amazon Web Services no incorporaba un modo de alta disponi-
bilidad —con dos nodos maestro por clúster— para el servicio de Elastic MapReduce, el 1 de mayo
de 2019, Amazon anunció la disponibilidad de este. A partir de esa fecha, Se pueden utilizar hasta
tres nodos maestro por clúster en aplicaciones YARN (las que usa Hadoop y Spark).
25
Alternativa, usualmente más costosa, de realizar una actividad o trabajo.
66
10 Desarrollo de la arquitectura
En este apartado detallaré el desarrollo de la demo del sistema. Para este, no se han utilizado las
mismas especificaciones de servicios que los mencionados en el apartado anterior debido a su ele-
vado precio respecto al bajo presupuesto del que dispone el proyecto. Sin embargo, los servicios de
Google Cloud Platform utilizados sí que serán los mismos. La única diferencia será que utilizarán unas
prestaciones menores.
La implementación de cada una de las piezas de la arquitectura la explicaré por apartados, de una
forma similar al análisis de estas del apartado anterior.
Cabe destacar que, si bien se desarrolla una aproximación de la arquitectura, la importancia del pro-
yecto recae sobre todo en el diseño de esta más que en su implementación. En todo momento ha
sido más importante la conexión de los diferentes servicios del sistema que el desarrollo de cada uno
por separado. Debido a esto, no todas las funcionalidades del sistema creado son exactamente igua-
les que las diseñadas y especificadas. El desarrollo de la arquitectura tal y como se ha diseñado sería
suficiente contenido como para hacer otro proyecto separado.
Por último, el sistema no es a prueba de fallos, pues debido al tiempo limitado que se dispone para
su implementación, se asume que su ejecución seguirá, en la mayoría de los casos, un happy path.
Es decir, no se esperará un comportamiento de los datos diferente al principal. Debido a esto, no
todos los métodos tienen comprobación de todos los posibles errores que puedan ocurrir.
10.1 Implementación paso a paso

El sistema consta de muchos servicios distintos separados, que hay que desarrollar independiente-
mente y unir. Para ello, se ha implementado individualmente cada servicio y aplicación de la forma
que en los siguientes apartados explicaré.
10.1.1 Creación de una cuenta de Google Cloud Platform

El primer paso para realizar la parte práctica del proyecto ha sido crear una cuenta de Google Cloud
Platform. Para ello, hacía falta una cuenta válida de Google que ya disponía.
10.1.2 Simulación de trazas e ingesta de datos

Puesto que la parte práctica del proyecto se trata de una demo y, por lo tanto, carece de datos de
entrada reales, la primera parte del desarrollo ha sido la implementación de una sencilla aplicación
que simule el envío de trazas de contadores de agua.
Para ello, lo primero ha sido crear un nuevo proyecto en Google Cloud Platform. Después crear una
aplicación de App Engine mediante la interfaz web. La región web escogida ha sido us-central, ya que
tiene precios más bajos que los servidores de Europa.
También ha sido necesario descargar e instalar el SDK de Google Cloud en el ordenador. Además, ha
sido necesario crear unas nuevas credenciales y descargarlas al ordenador para así poder probar la
aplicación en un entorno local antes de desplegarla.
Google App Engine permite desplegar varias aplicaciones individuales, llamadas módulos o servicios.
De esta manera, se logra crear una arquitectura de microservicios de una forma simple. El simulador
del contador lo he creado utilizando el framework Spring —concretamente, Spring Boot—. Además,
67
para la gestión de dependencias y configuraciones y para la construcción del software, he utilizado

Apache Maven. Este microservicio simplemente genera trazas en formato JSON cuando llega una
petición REST a un endpoint específico y las envía a un tópico de Google Cloud Pub/Sub, tal y como
sería en un entorno productivo.
En la siguiente figura, podemos observar un esquema simple del flujo de datos de Cloud Pub/Sub. La
parte grisácea corresponde a aquellas piezas del diseño de las que GCP se encarga de gestionar. A y
B son mensajes. Podemos ver cómo una misma suscripción solamente puede repartir una vez cada
uno de los mensajes, incluso teniendo más de un suscriptor. De esta manera, si se desea que dos
aplicaciones reciban todos los mensajes cada una, se necesitarán dos suscriptores.
Figura 15. Diagrama básico de flujo de Google Cloud Pub/Sub. Imagen usada con el permiso de Google bajo la licencia Creative
Commons Attribution 4.0 License.
Sin embargo, antes de poder enviarlas al topic de Cloud Pub/Sub, se ha tenido que habilitar la API de
Pub/Sub para el mismo proyecto que anteriormente. Una vez habilitada, se ha tenido que crear un
primer topic. Se puede realizar mediante la aplicación web o mediante la línea de comandos de Goo-
gle Cloud, llamada gcloud.
Después de estos pasos, se puede utilizar la API de Pub/Sub desde la aplicación de App Engine para
hacer uso del topic recién creado.
10.1.2.1 Publicación de nuevos mensajes en Cloud Pub/Sub

Para poder enviar una nueva traza o mensaje a un topic, primero se crea una instancia de Publisher.
Esta clase se encarga de enviar nuevos mensajes al topic definido en su construcción. Para la creación
de la instancia, Google exige el uso del patrón constructor (o builder), pasando como parámetro una
instancia de la clase ProjectTopicName, formado por el identificador del proyecto en que se trabaja
y el nombre (que funciona como identificador) del topic.
El mensaje a enviar es de la clase PubsubMessage y se forma también utilizando una clase builder.
Consta de los siguientes campos: data, attributes, messageId y publishTime. En el siguiente retazo
de código, podemos apreciar una representación de estos campos en formato JSON.
68
{
"data": string,
"attributes": {
attr1: string,
...
},
"messageId": string,
"publishTime": string,
}
El campo attributes es una lista de propiedades o atributos de tipo key-value, ambos de tipo string y
es opcional. Normalmente se utiliza para llevar un control de los mensajes y no para guardar datos
propiamente. messageId se genera automáticamente al publicar el mensaje, y es único para cada
mensaje en un mismo topic. De igual manera, publishTime se genera también automáticamente por
el servidor en el momento en que se publica el mensaje en el topic.
Por último, encontramos el campo data. Este es un string formateado como un array26 de bytes uti-
lizando una instancia de la clase ByteString, a la cual se le pasa el mensaje a enviar en formato string.
Para publicar —enviar— el mensaje, se utiliza el método publish de la clase Publisher, pasando este
como parámetro. El método retorna el identificador del mensaje, una vez está publicado.
10.1.2.2 Recepción de mensajes en Cloud Pub/Sub

El mismo servicio también incorpora un receptor de mensajes de Cloud Pub/Sub, para comprobar el
correcto funcionamiento del publicador. Para ello, se han definido dos suscriptores: uno para ser
usado por el sistema real time y otro para esta aplicación. Como he comentado en secciones ante-
riores, en Cloud Pub/Sub, la forma en que los mensajes son recibidos por estos suscriptores puede
ser de dos maneras: pull y push. Debido a que la primera opción permite más throughput de mensa-
jes por segundo, se han implementado los suscriptores para funcionar con esta.
El primer paso ha sido crear una instancia de ProjectSubscriptionName con los parámetros del iden-
tificador del proyecto y el nombre de la suscripción (que hace de identificador). También ha habido
que utilizar la interfaz MessageReceiver, sobrescribiendo su único método receiveMessage. Este mé-
todo recibe como parámetros un mensaje y un consumer y se ejecuta cada vez que llega un nuevo
mensaje al topic y este lo redirige al suscriptor. El mensaje contiene todos los datos necesarios para
almacenar o procesarlo. El consumer se utiliza para reconocer (acknowledge) el mensaje al servidor
y no volver a recibirlo en el futuro.
Esta instancia que implementa la interfaz es uno de los parámetros necesarios para crear una instan-
cia de Subscriber, también a través de un builder. El otro parámetro es la instancia de la clase Pro-
jectSubscriptionName anteriormente creada. Para comenzar a recibir mensajes, se utiliza el método
startAsync de la instancia creada de Subscriber.
26
Vector o, como sería su traducción literal, formación. Es una estructura que representa un conjunto
ordenado de datos del mismo tipo.
69
10.1.2.3 Procesamiento de las trazas

La propia aplicación está desarrollada con Spring Boot, que ofrece muchas facilidades para crear un
microservicio desde cero.
Para generar y enviar las trazas a Cloud Pub/Sub, se hace a través de una API REST y de unos
endpoints definidos en un controlador. Las peticiones para enviar las trazas son de tipo POST. Estas
peticiones a la API de la aplicación se hacen a través del programa Postman.
Los mensajes enviados contienen únicamente el campo data, sin atributos (como he mencionado
antes, publishTime y messageId se generan automáticamente en el momento en que se publica). El
campo data contiene un texto de una línea en formato String de Java y formateado en array de bytes.
Este texto es un elemento JSON formateado en String. La siguiente línea es un ejemplo de una traza
antes de ser convertida en array de bytes (se han coloreado los valores que corresponderían en for-
mato JSON para hacerlo más legible, pero String de Java no diferencia entre clave y valor):
“waterMeterId:123456789, reading:12345.6789, timestamp: 1560802140;”
Para comprobar el correcto funcionamiento de Cloud Pub/Sub, también recibo las trazas que se pu-
blican y las guardo en una clase encargada de guardarlas. Para visualizar las trazas recibidas, lo hago
también a través de llamadas a la API, pero esta vez con peticiones tipo GET. Debido a que los nave-
gadores acceden a los sitios web con peticiones de este tipo, no necesito Postman para visualizar el
contenido de la respuesta.
Al ejecutar la aplicación en el entorno de trabajo local, por defecto —y es como lo he hecho—, se

levanta un servidor en localhost, en el puerto 8080.
10.1.3 Integración de Cloud Storage en el sistema

Una vez funcionando el envío de trazas, el siguiente paso ha sido dirigir una copia de los datos de
Cloud Pub/Sub hacia el servicio de almacenamiento escogido, Google Cloud Storage.
El primer paso ha sido la creación de un conjunto de buckets en Cloud Storage. Así se llaman las
unidades de almacenamiento del servicio. Para el sistema entero, he creado los siguientes:
• applications, para guardar los binarios que serían usados más adelante por Cloud Dataproc;
• models, para guardar los modelos predictivos una vez creados y entrenados;
• raw, para almacenar los datos de entrada provenientes de la ingesta mediante Cloud
Pub/Sub.
Además, los siguientes buckets serían creados durante el transcurso del desarrollo por la propia pla-
taforma:
• dataproc-us-east4, para almacenar metadatos con respecto al servicio de Cloud Dataproc y

notebooks creados por Jupyter;
• eu.artifacts.project.appspot.com;
• staging.project.appspot.com;
• project.appspot.com, estos tres buckets, para almacenar los datos de las aplicaciones crea-
das mediante App Engine.
70
Una vez constituidos los buckets, para empezar a almacenar datos provenientes de Cloud Pub/Sub,
he usado un servicio intermedio, también de Google Cloud, llamado Cloud Dataflow. Este es un ser-
vicio ofrecido y gestionado por Google para el procesamiento en batch y en real time.
Este permite simplificar algunas operaciones y tareas, como la que se necesita para este caso. Data-
flow dispone de API para crear servicios; sin embargo, debido a la sencillez del caso de uso, he utili-
zado plantillas existentes proporcionadas por la plataforma. En concreto, la plantilla usada es para
procesamiento en real time, y su nombre es Cloud Pub/Sub to Text Files on Cloud Storage.
Figura 16. Captura del diagrama de flujo de los datos de Google

Cloud Dataflow en pleno funcionamiento.
Este servicio está en funcionamiento constantemente y acumula las trazas recibidas —una por lí-
nea— en ficheros de texto de Cloud Storage. Con esta plantilla, cada fichero contendrá una cantidad
de trazas correspondiente a cinco minutos.
10.1.4 Integración de Cloud Dataproc

Después de configurar el almacenamiento en Cloud Storage, las fuentes de datos para el procesa-
miento en batch y para el procesamiento en tiempo real están funcionales.
10.1.4.1 Primera iteración batch con Apache Spark

La aplicación Spark la he desarrollado utilizando Java y usando los paquetes de Spark para este len-
guaje spark-core, spark-sql y spark-ml. Además, también he usado el paquete del entorno de Hadoop
hadoop-client.
El primer paso para construir la aplicación ha sido definir la sesión y el contexto de Spark mediante
la clase SparkSession. Para ello, basta con definir el nombre de la aplicación y el modo de ejecución
que tendrá. Spark soporta los siguientes modos de ejecución:
• standalone, en el que se definen manualmente los nodos maestros y trabajadores;

• YARN, en el cual es este gestor de clúster el que define la localización de cada uno de los
nodos del sistema;
• Mesos, que funciona de manera muy parecida a YARN.
71
Además, el modo standalone se puede utilizar en la máquina local siempre y cuando se tenga insta-
lado el entorno de Hadoop. Para desplegar la aplicación en Dataproc y su entorno de Hadoop, utilizo
el modo YARN.
Para leer los ficheros de Cloud Storage, el método que he utilizado es read de la clase SparkSession.
Este método acepta como parámetro un string apuntando a un fichero o a un directorio. Esto último
es interesante, ya que permite cargar todos los datos de un conjunto de ficheros —como es nuestro
caso—. Este método retorna un objeto de la clase Dataset. En nuestro caso, es un dataset de tipo
string, ya que los datos vienen de texto plano.
Una vez tenemos un dataset con todos los datos distribuidos, convertimos este a una instancia de la
clase JavaRDD, con el que podemos trabajar en Java. RDD quiere decir resilient distributed dataset,
es decir, conjunto de datos distribuidos recuperables.
Luego, aplicamos una serie de operaciones. Todas estas operaciones reciben como parámetro una
nueva instancia de una clase abstracta o interfaz de Spark, en la que he sobrescrito el método call
que contienen por uno adecuado a cada operación. Las operaciones son las siguientes:
1. Map. Este recibe el RDD de Java y, por cada línea —que equivale a una traza de consumo de
agua—, crea una instancia de una clase propia Trace, que guarda la información de una traza
(id del contador, timestamp de la fecha de creación y lectura de agua). El map retorna otro
JavaRDD, pero esta vez del tipo Trace (no string).
2. MapToPair. Este método recibe el RDD retornado por el anterior y retorna otro del tipo Ja-
vaPairRDD<Long, Trace>. Cada par del nuevo RDD corresponderá con el identificador de
contador de una traza y la propia traza. Si bien de esta manera tenemos redundancia de
datos, no es muy alta y de esta manera facilitamos la siguiente operación.
3. GroupByKey. Este método agrupa cada uno de los pares del RDD retornado por el método
anterior y retorna un RDD nuevo de la siguiente forma: JavaPairRDD<Long, Itera-
ble<Trace>>. Este contiene, para cada identificador de un contador, todas las trazas que se
corresponden con este.
4. ForeachPartition. Por último, encontramos este método. He escogido foreachPartition en
vez de foreach porque con la segunda no se tiene el control de los nodos en los que se va a
ejecutar. La opción escogida asegura que cada una de las particiones del RDD se ejecuta en
un solo nodo. Por lo tanto, ahorra muchas conexiones a la base de datos. Sin embargo, de
todos modos, se tienen que hacer más conexiones a base de datos que el número de nodos
totales. Aunque muchas menos que si utilizáramos el método foreach. En el método call que
sobrescribimos, escribimos todo el código perteneciente al procesamiento de un contador.
Sin embargo, en este punto, todavía no tenemos acceso a la base de datos y a los modelos
predictivos.
Es importante destacar que la clase Trace debe implementar Serializable debido a que Spark guar-
dará instancias de esta en disco para distribuirlas entre los diferentes workers.
En la siguiente figura, podemos observar un ejemplo muy sencillo de las operaciones anteriormente
explicadas. El almacenamiento original contiene siete líneas (cada una con una traza de información).
Este se ha leído y se ha creado un RDD donde cada línea es una traza en formato string. En este punto
comenzaría el esquema de la figura.
72
Figura 17. Representación esquemática de las operaciones realizadas sobre los datos iniciales en la aplicación de Spark en batch
sobre un ejemplo simple.
10.1.4.2 Primera iteración streaming con Apache Spark Streaming

La aplicación para tratar con los mensajes en tiempo real utiliza Apache Spark Streaming, esta es una
extensión de Apache Spark posterior a su lanzamiento.
SparkSession funciona exactamente igual que en el apartado anterior; sin embargo, ha sido necesario
trabajar también con SparkContext (más antiguo que SparkSession, y actualmente parte de este) y
JavaStreamingContext.
En cuanto a la lectura de los datos, esta vez provienen de un topic de Cloud Pub/Sub, en vez de Cloud
Storage. No obstante, su recepción no se ha hecho de igual forma que en la aplicación para compro-
bar el correcto funcionamiento del topic (véase el apartado 10.1.2.2). En este caso, se utiliza otra
clase de Spark, JavaDStream, con datos de tipo string. Se crea una instancia de esta clase mediante
el método createStream de la clase PubsubUtils, de Apache Bahir (dedicada a distribuir extensiones
para diversas plataformas analíticas).
El método createStream recibe los siguientes parámetros:
• Instancia de la clase JavaStreamingContext. Esta se obtiene a partir de una instancia de Ja-

vaSparkContext, la cual, a su vez, se obtiene del SparkContext que contiene SessionContext.
Además, definimos también la ventana de tiempo para indicar cada cuánto queremos que
se ejecute la recogida de mensajes de Cloud Pub/Sub.
• Identificador del proyecto de Google Cloud.
• Nombre del topic del que se reciben los datos.
• Nombre de la suscripción del topic por la cual se reciben los datos.
73
• Instancia de la clase SparkGCPCredentials, que sirve para autentificar la conexión a Google

Cloud Pub/Sub. En entorno local, esta coge los datos de variables de entorno del sistema. El
entorno de producción está configurado automáticamente, ya que la aplicación se despliega
en los servidores de Google Cloud.
• Tipo de almacenamiento de datos. En este caso he definido memoria y disco.
A la instancia creada de JavaDStream se le aplica le método map con tal de transformar todos los
mensajes de Cloud Pub/Sub capturados en texto. Para ello, basta con quedarse con el campo data
(véase el apartado 10.1.2.1) y convertir el array de bytes a texto.
Una vez hecho esto, se define qué tratamiento se le quiere dar a cada uno de los mensajes recibidos.
Esto se hace mediante el método foreachRDD de JavaDStream. Este se ejecuta cada vez que pasa
una ventana de tiempo. Recibe como parámetro una instancia que implementa la interfaz VoidFun-
ction<JavaRDD<String» e implementamos el método call, que tiene como parámetros una instancia
de la clase JavaRDD<String>. Dentro de este método, ejecuto el foreachPartition sobre el parámetro
de entrada. Se ha escogido foreachPartition en lugar de foreach para minimizar el número de inicia-
lizaciones de un publicador de Cloud Pub/Sub (para publicar el resultado del procesamiento a otro
topic), igual que en apartado anterior.
Dentro del método call de la instancia pasada como parámetro a foreachPartition, se ejecuta el có-
digo para procesar cada una de las trazas individuales para saber si corresponde a una fuga de agua
o no. Sin embargo, en este punto todavía no se dispone de los modelos predictivos.
Es importante destacar, igual que en el procesamiento en batch, que las clases cuyas instancias se
distribuirán entre los diferentes workers deben implementar la clase Serializable. En este caso, se
trata de la clase que utilicemos para guardar el modelo predictivo.
10.1.4.3 Análisis de los datos con Jupyter

Una de las herramientas que permite utilizar Google Cloud Dataproc, es Jupyter. Es una interfaz web
que permite programar en diferentes lenguajes de programación, utilizando los recursos del servidor
en el que esté alojado. En este caso, se trata de Python. En concreto, PySpark.
Para entrenar el modelo, se necesitaban datos más o menos reales. Una posibilidad era generar ma-
nualmente (o con ayuda de un programa simple) los datos. La otra, buscar un dataset existente con
el que poder trabajar. No existen muchos datos para el tipo de estudio que necesita este sistema, es
decir, con las siguientes propiedades:
• Tener varios sujetos presentes en el dataset.

• Ser lo suficientemente grande como para que se pueda recabar información sobre patrones
en el comportamiento del uso del agua a lo largo de las horas, días, meses e incluso años.
• Tener datos muy seguidos. Es decir, que tenga lecturas de consumo con una frecuencia de
por lo menos diez o quince minutos, para poder estudiar el comportamiento de las fugas de
agua.
La mayoría de datasets encontrados pertenecían a regiones de una ciudad o país, o, con suerte, algún
vecindario. Otros que se acercaban más a los requerimientos, tenían lecturas de consumo diarias o
mensuales.
Sin embargo, había un dataset que cumplía todos los requisitos y es el que he utilizado. Pertenece a
Pecan Street y ocupa alrededor de 5 GB. Contiene algunos cientos de identificadores de sujetos es-
tudiados y, para cada uno, una serie de registros de contador de agua a una cierta hora. La mínima
74
frecuencia entre dos registros es de un minuto. Contiene en total alrededor de noventa millones de
registros.
Para acceder a él, una vez registrado en la página con la dirección de correo electrónico de la facultad,
he tenido que usar el gestor de bases de datos Postgres. Una vez descargados los datos, los he alma-
cenado el Cloud Storage para poder acceder a ellos desde Jupyter.
El plan de acción para el análisis de los datos y el desarrollo de los modelos era el siguiente:
1. estudiar los datos batch para un solo identificador de contador con la librería de Python,
Pandas;
2. hacer un modelo predictivo a partir de esos datos sin importar su precisión;
3. convertir el dataset de Pandas a uno de Spark ML y hacer el modelo esta vez con Spark ML
utilizando pipelines para crear un proceso de modelaje;
4. guardar el modelo en Cloud Storage y cargarlo desde Java en la aplicación de Spark para
batch;
5. comprobar su funcionamiento;
6. mejorar el modelo en Jupyter modificando campos y añadiendo fuentes de datos como ca-
lendario de festivos o datos de climatología —simplemente obtener datasets públicos y aña-
dirlos como una columna nueva al dataset—;
7. repetir los dos pasos anteriores hasta que sea mínimamente preciso;
8. repetir los pasos anteriores en un bucle para todos los identificadores de contadores y guar-
dar cada uno de los modelos (solo batch);
9. repetir los pasos anteriores para los datos streaming;
10. añadir entradas de fuga manualmente;
11. guardar el modelo (solo streaming).
Sin embargo, el punto cuarto no ha salido como se esperaba. A pesar de que se ha conseguido guar-
dar un modelo entrenado y funcional en memoria, no se ha logrado utilizarlo en las aplicaciones Java
de Spark. Por ese mismo motivo, no se ha desarrollado el modelo para la aplicación de Spark Strea-
ming en tiempo real, ya que no se podría utilizar tampoco. No obstante, explicaré su desarrollo, in-
cluso el del caso de uso de tiempo real —aunque teórico—.
10.1.4.3.1 Caso de uso en batch

Como he mencionado, se ha logrado construir y entrenar un modelo. Además, este se ha conseguido
probar y guardar.
Para el preprocesamiento del dataset, es decir, todo el trabajo previo a empezar a entrenar el mo-
delo con este, se han seguido los siguientes pasos, que corresponden con la lista ordenada anterior,
hasta el último punto que he conseguido hacer (la primera parte del cuarto).
1.
a. Carga de datos en un dataset de Pandas utilizando Pandas y la librería gcsfs
(Pythonic file-system for Google Cloud Storage), que permite acceder a Google
Cloud Storage utilizando Python sin utilizar el framework de Apache Spark.
b. En este punto, el dataset únicamente contiene una lista de trazas con tres colum-
nas: id, date y reading. Se le añaden los campos day, month, year, weekday y isWee-
kend. Además, el campo date se formatea a uno de tipo fecha, en lugar de texto.
c. Se selecciona uno de los identificadores y se separa el dataset en dos partes, una
para entrenar el modelo y otra para probarlo (70% y 30%, respectivamente).
75
d. Se añade una columna nueva que contenga la diferencia de consumo de agua entre
la lectura correspondiente a cada fila y su anterior, para saber el incremento de
consumo en esa diferencia de tiempo.
e. Se hace un estudio de las variables que más influyen en el dataset para tenerlas en
cuenta a la hora de hacer un primer modelo.
2.
a. Se hace un primer modelo utilizando Pandas.
b. Se comprueba que funciona el modelo y es capaz de predecir, sin importar si es
poco preciso.
3.
a. Se convierte el dataset usado para crear el modelo con Pandas en un dataset de
Apache Spark.
b. Se hace un primer modelo utilizando estimators de Spark y otro utilizando pipelines.
4.
a. Se guardan ambos y se vuelven a cargar para comprobar su funcionamiento
b. Se intenta cargar en la aplicación Spark en Java.
En este punto el plan falla. Entraré más en detalles en la gestión del problema en el apartado 10.3.
10.1.4.3.2 Caso de uso en tiempo real

Para el caso de uso en tiempo real, por otro lado, la idea era hacer solamente un único modelo que
englobara los comportamientos de todos los usuarios. Si bien es de esperar que esto no funcione
para todos los casos, lo haría para una gran mayoría.
Esto tiene como ventaja principal que no hay que cargar el modelo en la aplicación en Java para todas
las ventanas de tiempo. Hacer esto ralentizaría el sistema varias magnitudes de tiempo, haciendo
irrealizable el procesamiento de más de dieciséis mil trazas por segundo. Por lo tanto, el modelo se
cargaría una vez cada ventana de tiempo, como explicaré en el apartado 10.1.4.5.
10.1.4.4 Segunda iteración batch con Apache Spark

Las funciones que se ejecutarían para cada partición del RDD son las siguientes:
1. conexión a la base de datos;

2. iterar sobre cada uno de los identificadores de contador de agua que corresponden a esa
partición;
3. para cada identificador de contador, agrupar todas las trazas y transformarlas en un dataset
para poder usarlo con el modelo predictivo;
4. cargar de Cloud Storage el modelo predictivo anteriormente guardado desde Jupyter;
5. ejecutar una predicción del modelo sobre el dataset;
6. añadir una nueva entrada de estimación mensual a la base de datos para ese identificador
de contador.
Sin embargo, y debido a los percances ocurridos con los modelos predictivos, el punto cuarto y quin-
tos no son posibles por el momento. No obstante, he sustituido estos puntos por la llamada a una
función que genera una respuesta semialeatoria, con el propósito de poder completar el flujo de
datos del sistema.
Para ejecutar esta aplicación en el clúster de Dataproc una vez al día a modo de batch, utilizamos
Google App Engine con lo siguiente:
76
• Un microservicio hecho con Java Spring Boot, que define un endpoint al cual pueden llegar
peticiones. Estas peticiones, de tipo GET, ejecutan una llamada a Dataproc para lanzar una
nueva aplicación Spark a ejecutarse en el clúster.
• Un cron job. Esta es una funcionalidad de App Engine que permite definir tareas, mediante
peticiones a ciertos endpoints, que se ejecutan de forma periódica. En este caso, se trata de
una petición cada veinticuatro horas al endpoint definido en el servicio anterior. Para definir
un cron job utilizando Java y Maven, se hace mediante un archivo llamado cron.xml. El con-
tenido de este archivo para la intención deseada es el siguiente:
<?xml version="1.0" encoding="UTF-8"?>

<cronentries>
<cron>
<url>/jobs/schedule/new</url>
<target>job-scheduler</target>
<description>Submit a new spark batch job every 24 hours</description>
<schedule>every 24 hours</schedule>
</cron>
</cronentries>
La propiedad url especifica el endpoint al que se harán las peticiones de forma recurrente. target
especifica el módulo al cual pertenece el endpoint. En este caso es el microservicio que he creado,
que se llama job-scheduler. La propiedad description es autoexplicativa y, por último, schedule define
la recurrencia de hacer la petición.
10.1.4.5 Segunda iteración streaming con Apache Spark Streaming

De igual manera que en la aplicación del caso de uso en batch, las funciones que estaban previstas
ejecutarse para cada partición del RDD creado durante la ventana de tiempo del stream eran las
siguientes:
1. inicializar una nueva instancia de Cloud Pub/Sub Publisher;

2. iterar por cada traza recibida;
3. ejecutar la predicción del modelo sobre la traza;
4. publicar un nuevo mensaje en Cloud Pub/Sub si la respuesta es positiva en cuanto a fuga de
agua, ignorar si no.
Además, para cada RDD creado durante la ventana de tiempo, se cargaría el modelo predictivo de
datos, que se usaría para todas las predicciones de esa ventana. De esta manera —en contraposición
a cargarlo una sola vez al inicio de la aplicación—, se permitiría cargar nuevos modelos generados en
tiempo real por el equipo de data science sin tener que parar la ejecución del programa. El coste de
ejecutar una carga del modelo por ventana de RDD es muy bajo. Suponiendo que el tiempo de carga
del modelo de Cloud Storage es de 100 milisegundos y las 16,667 trazas recibidas por segundo —el
límite máximo para el que está diseñado el sistema—, con una ventana de tiempo de cinco minutos,
el overhead añadido de media al proceso de cada traza sería de solamente 20 nanosegundos.
Los mensajes de aviso de fuga enviados a Cloud Pub/Sub contienen únicamente el identificador del
usuario o contador de agua y un timestamp de la hora en que se detectó la fuga. Tienen el formato
siguiente:
waterMeterId:123456789, timestamp: 1560802140;
77
10.1.5 Integración de Cloud Datastore

Esta parte se ha desarrollado en paralelo a la segunda iteración batch de Apache Spark, ya que esta
necesitaba una base de datos a la que conectarse para enviar los resultados de las predicciones. Para
ello, recordemos, se ha utilizado la base de datos no relacional y de clave-valor, Cloud Datastore.
En esta base de datos, los objetos se llaman entidades (entities). Estas tienen una o más propiedades
(properties) y cada una de estas puede tener uno o más valores (no necesariamente del mismo tipo
de datos). Las entidades pertenecen a un tipo (kind). También pueden tener ancestros (ancestors),
para así formar una jerarquía entre diferentes entidades.
Además, permite el uso de la base de datos por distintos usuarios a la vez, gracias a que incorpora
espacios de nombres (namespaces). Cada entidad tiene un identificador único o clave (key).
En la siguiente tabla podemos ver las equivalencias nomenclaturales entre Cloud Datastore y las ba-
ses de datos relacionales:
Concepto Cloud Datastore Base de datos relacional

Categoría o tipo del objeto Tipo/kind Tabla
Objeto Entidad/entity Fila
Cada uno de los datos del objeto Propiedad/property Columna
Identificador único Clave/key Clave primaria
Figura 18. Comparación de nombres de los conceptos de Cloud Datastore y una base de datos relacional típica.
10.1.5.1 Índices
El primer paso, después de haber definido los requisitos de la base de datos y las consultas que se le
realizarían, ha sido definir los índices. En Cloud Datastore hay dos tipos de índices:
• Índices incorporados automáticamente (built-in). Estos se predefinen automáticamente por

la base de datos cuando se crean nuevos tipos de entidades. Habrá un índice incorporado
por cada propiedad. Son adecuados para para consultas sencillas a la base de datos. Por
ejemplo, ordenación o selección con un filtro de igualdad simple por una sola propiedad.
• Índices compuestos. No se definen automáticamente, sino que es responsabilidad del admi-
nistrador o usuario definirlos. Son adecuados para consultas más complejas. Por ejemplo,
más de una ordenación por consulta. De hecho, Cloud Datastore lanza un error si se intenta
hacer una consulta que necesita este tipo de índices y no están definidos previamente.
Para actualizar o definir los índices, hace falta modificar (si ya existía) o crear el archivo index.yaml,
en formato YAML. En este, para cada índice hay que indicar el kind al que hace referencia el índice,
el ancestro (opcional) y las propiedades a las que afecta. Por cada propiedad, hay que poner el nom-
bre y, opcionalmente, también el sentido de ordenación: ascendente (asc) o descendente (desc).
El archivo index.yaml definido para el caso de uso es el siguiente:
78
indexes:
- kind: Estimate
properties:
- name: userId
- name: date
direction: desc
- kind: Estimate
properties:
- name: userId
- name: date
direction: asc
Una vez formado el archivo, para actualizar la base de datos se ejecuta el siguiente comando del SDK
de Google Cloud: datastore indexes create.
10.1.6 Recepción y muestra de resultados con App Engine

La última pieza del sistema es un microservicio en el que visualizar los resultados de las aplicaciones
de Spark en batch y en tiempo real.
Al servicio de App Engine creado para publicar las trazas en Cloud Pub/Sub y comprobar su correcto
funcionamiento, se la han añadido dos servicios más. Por un lado, un servicio que recupera las últi-
mas estimaciones mensuales de consumo de agua para cada usuario. De igual modo que en el primer
servicio creado en la primera fase de desarrollo, para acceder a los datos, se hace a través de peti-
ciones de tipo GET. Las peticiones a este microservicio desencadenan un acceso a la base de datos
para buscar las estimaciones mensuales de un identificador en concreto.
Por otro lado, un segundo servicio que recibe los mensajes de alerta de fuga del topic y envía un
correo electrónico. Debido a que el sistema carece de un maestro de usuarios —una pieza, como una
base de datos, que almacena la información de los usuarios de un sistema para obtener información
a partir del identificador, como el nombre o la dirección de correo electrónico—, una clase stub del
servicio hace su función. De esta se obtiene la dirección de correo al que enviar la notificación, así
como la información del domicilio y nombre del usuario. Este servicio está continuamente conectado
a la suscripción de Pub/Sub para recibir nuevas alertas de fuga. Para ello, y debido a que el tiempo
máximo de petición en el entorno estándar de Google App Engine (el más barato) es de un minuto,
se hace lo siguiente:
• Se implementa el microservicio tal que en su inicialización crea un suscriptor para el tópico

al que llegan las alertas de fuga y comienza a escuchar. Los mensajes recibidos se guardan
en una cola bloqueante (blocking queue).
• Se define un método que espera nuevos mensajes en la cola en bucle ininterrumpidamente
por 55 segundos. Para recoger los nuevos mensajes de esta cola, se utiliza el método poll
con un timeout de 55 segundos, para poder salir del bucle en caso de que no llegue ningún
mensaje.
• Se define un endpoint del microservicio las peticiones al cual llaman al método anterior.
79
• Se define un nuevo cron job (véase apartado 10.1.4.1) que envía una petición al endpoint
anterior cada minuto. De esta manera, el máximo tiempo que el microservicio estará sin leer
nuevos mensajes de la cola son cinco segundos.
• Se utiliza otra colección auxiliar —un hashset— para almacenar en ella el identificador de
cada uno de los mensajes recibidos. De esta manera, se comprueba si el mensaje ya se había
recibido antes de procesarlo —en este caso, enviarlo por correo electrónico—. Así se consi-
gue no trabajar con mensajes repetidos, ya que Cloud Pub/Sub asegura que cada mensaje
se enviará mínimo una vez, sin haber un máximo (1:*). El hashset se borra completamente
cada 55 segundos, pues no hay riesgo de recibir un mensaje recibido después de tanto
tiempo y para no saturar los escasos recursos de la máquina en producción.
Respecto a las posibles maneras de mostrar los resultados mencionadas en el apartado 8.1.4.2, no
se desarrollarán el envío de avisos de fuga por medio de SMS y la implementación de gráficos por
falta de tiempo y presupuesto. No obstante, son dos posibilidades totalmente integrables en el di-
seño, debido a la arquitectura tan desacoplada del sistema.
Por último, un tercer microservicio al que se le asocia un cron job ejecuta las creaciones de nuevas
ejecuciones de la aplicación de estimación de consumo de agua mensual de Spark (véase apartado
10.1.4.4). Este simplemente recibe una petición cada veinticuatro horas que ejecuta un método, el
cual se conecta a Google Dataproc para enviar una nueva ejecución de Spark en batch.
En la Figura 20, se muestra el esquema de la arquitectura del sistema simplificado y destacando el

papel de los diferentes microservicios implementados con App Engine, tanto aquellos para la visua-
lización final de los resultados como los otros dos mencionados anteriormente.
Figura 20. Esquema de los diferentes microservicios del sistema. Imagen ampliada en Anexo 7.
Figura 19. Esquema de los diferentes microservicios del sistema. Imagen ampliada en Anexo 7.
10.2 Patrones de diseño utilizados

Durante el desarrollo de las diferentes piezas del sistema, se han utilizado una serie de patrones de
diseño en los diferentes códigos. Los podemos dividir en dos categorías: aquellos que he implemen-
tado para utilizarlos posteriormente en los programas y aquellos implementados por fuentes exter-
nas y que he usado.
80
Sin embargo, no se ha potenciado el uso de los patrones de diseño debido al sencillo tan simple de
los programas y al enfoque del proyecto en la arquitectura y el diseño generales del sistema por
encima de la arquitectura individual de cada pieza de software.
Además, y antes de dar paso a los patrones implementados, en general, se ha intentado que cada
uno de los servicios o aplicaciones tenga una estructura parecida en lo que se refiere a Java Packages.
La estructura y nomenclatura de estos es la siguiente:
• com.waterstudy.(microservices).servicio/aplicación
o (default)
o controller
o service
o model
o dao
En el paquete por defecto están las clases necesarias para el lanzamiento de la aplicación o servicio.
controller contiene clases para controlar las API, en el caso de los microservicios hechos para App
Engine. service contiene clases que se encargan de la lógica, mientras que model guardará aquellas
con datos básicos para el funcionamiento del programa y, por último, dao (data access object, es
decir, objeto de acceso de datos) se encarga de las clases que acceden a servicios externos de datos.
De esta manera, se desacoplan las diferentes funcionalidades de un mismo programa, facilitando su

comprensión, su implementación por más de una persona a la vez y su facilidad para extender fun-
cionalidades en un futuro.
10.2.1 Patrones implementados

10.2.1.1 Patrón Singleton
Este patrón de diseño se utiliza para asegurar que únicamente habrá una instancia de una clase. Su
utilización es beneficiosa para aquellas clases accesibles por cualquier otra clase y que dependen de
un estado.
Lo he usado en las dos aplicaciones de Spark (la de ejecución en batch y la de ejecución en tiempo
real) para implementar las conexiones externas. En el caso batch, se ha utilizado en la clase encar-
gada de hacer la conexión a la base de datos, ya que únicamente querremos una instancia. Además,
esta tiene un estado que corresponde con los parámetros de configuración de la base de datos. Cabe
mencionar que, para acceder a esta clase, se hace a través de una interfaz genérica. Su función es
abstraer el código específico de la base de datos de Google al sistema. En la siguiente figura, pode-
mos observar la estructura de la clase que implementa la base de datos de Cloud Datastore.
81
Figura 21. Representación en UML del patrón Singleton utili-

zado en la clase Datastore.
10.2.1.2 Patrón Model-View-Controller

Este patrón se encarga de gestionar y separar la información de la aplicación en tres partes: modelo,
vista y controlador. El modelo es el encargado de guardar la información de la propia aplicación. La
vista es la representación visual de esta información y, por último, el controlador, es el nexo que
brinda la información del modelo a la vista y que también se encarga de recibir las peticiones a la
aplicación hechas por el usuario.
Este patrón se utiliza en todas las piezas de software desarrolladas en el proyecto que utilizan Spring.
En la siguiente figura podemos ver una representación muy sencilla de su funcionamiento.
Figura 22. Diagrama que muestra el funcionamiento del patrón model-view-controller (MVC).
82
10.2.2 Patrones utilizados

10.2.2.1 Patrón Factory
Este es un patrón utilizado internamente por el framework Spring para crear e inyectar los beans
necesarios para la ejecución del programa a través de un Bean Factory. De esta manera, se facilita la
creación de varios tipos de objetos desde una misma clase.
10.2.2.2 Patrón Singleton

Además de implementarlo en las aplicaciones Spark, en aquellos servicios desarrollados con Spring
Boot también se ha utilizado. En este framework, el patrón se introduce automáticamente en una
clase tras añadirle la anotación de Bean, Component o Service, entre otras.
10.2.2.3 Patrón Front Controller

Este patrón delega en una clase el tratamiento de todas las peticiones que se le hacen a una aplica-
ción. Es usado por Spring Boot mediante la clase DispatcherServler, que implementa un servlet cuya
funcionalidad es esa.
10.2.2.4 Patrón Service Locator

Este patrón simplifica el uso de muchos servicios, almacenando un puntero a estos en una sola clase.
Esta clase se usa, entonces, para acceder a cada uno de estos servicios.
El patrón lo utiliza internamente Spring para gestionar los beans generados en la ejecución del pro-
grama. Cuando un trozo de código pide un bean, este patrón lo encuentra en el contexto de Spring
para retornarlo.
10.2.2.5 Patrón Builder

Este patrón se usa en una gran cantidad de clases de Google y de Apache Spark. Su cometido es
separar la construcción de objetos complejos de su representación.
10.3 Problemas durante el desarrollo

Durante todas las fases del desarrollo, ha habido problemas inesperados debidos a diversas causas.
A continuación, explicaré todos ellos.
10.3.1 Problemas de versiones

Uno de los problemas más recurrentes con que me he encontrado durante prácticamente todas las
fases del desarrollo de la parte práctica de la arquitectura ha sido el uso de APIs de Google Cloud.
Más concretamente, debido a las distintas versiones de que dispone. Por este motivo, alguna de la
información —incluso de las fuentes oficiales— y ejemplos no correspondían con la versión de la
aplicación que estaba desarrollando. Entre algunas versiones no muy distantes de la misma API, po-
día encontrar diferencias importantes de uno de los métodos que usaba.
Si bien el problema estaba definido, la solución no era sencilla, pues aumentando o disminuyendo la
versión usada podía provocar problemas de compatibilidad con otras piezas (por ejemplo, compati-
bilidad de clases de Google Cloud con las de Apache Spark).
83
10.3.2 Problemas de dependencias

Otro tipo de problemas frecuentes con los que me he encontrado es de dependencias de Java a la
hora de desplegar las aplicaciones de Apache Spark y de Spark Streaming en los servidores de Google
Cloud Dataproc. El despliegue de las aplicaciones daba error debido a diferencias de configuración
del entorno Hadoop de estos servidores con el entorno local en el que probaba su ejecución. Gene-
ralmente, los problemas eran errores lanzados en tiempo de ejecución de dos tipos: java.lang.No-
ClassDefFoundError y java.lang.NoSuchMethodError.
10.3.2.1 NoClassDefFoundError
Este error esta causado en tiempo real debido a intentar utilizar una clase presente en el momento
de compilación y que no se encuentra durante su ejecución. Todos los errores de este tipo con que
me he encontrado durante el desarrollo han sido causados por una excepción del tipo
java.lang.ClassNotFoundException. Esta ocurre cuando la aplicación intenta cargar una clase me-
diante los métodos forName, findSystemClass o loadClass y esta no se encuentra.
En la aplicación, ocurría porque el entorno del clúster de Cloud Dataproc no contenía las dependen-
cias declaradas por el proyecto, mientras que en local sí que estaban. Para solucionarlo, he utilizado
dos técnicas, depende de la clase en que da la excepción:
• Crear un uber-jar. Este es un archivo de formato JAR normal al que también se le han aña-
dido los códigos fuente de sus dependencias definidas. Utilizar el plugin de Maven Shade
Plugin. Con este, se incluyen aquellas dependencias no incluidas en el entorno del clúster de
Google Cloud Dataproc. Sin embargo, añadir todas las dependencias del proyecto tiene dos
problemas:
o El archivo JAR generado ocupa mucho.
o Surgen problemas nuevos de conflictos de dependencias.
Por lo tanto, únicamente he añadido aquellas dependencias que pedía la ejecución. Para
ello, he lanzado la aplicación repetidas veces, solucionando en cada iteración el error cau-
sado por una excepción diferente cada vez, pero del mismo tipo. Leyendo la traza de error,
podía ver qué clase fallaba. Una vez sabía la clase, la buscaba en los paquetes del entorno
local y identificaba en qué paquete se encontraba. Por último, se añadía la declaración del
paquete (groupId + artifactId) a la lista de inclusiones para generar el uber-jar con Maven.
• Excluir ciertos paquetes de algunas dependencias declaradas en Maven. Solamente he te-

nido que hacer esto para quitar el paquete Guava de Google en algunas dependencias que
también lo utilizaban, pero con distinta versión y creando de esta manera conflictos de ver-
siones. Para saber qué dependencias incorporaban a su vez la dependencia de Guava, se ha
usado el siguiente comando de Maven: mvn dependency:tree. Este comando lista todas las
dependencias del proyecto de forma recursiva, creando un árbol.
10.3.2.2 NoSuchMethodError
Por el nombre de problema, podemos intuir que es más serio, ya que es un error en lugar de una
excepción. Es un error lanzado por el sistema de tiempo de ejecución de Java (Java Runtime System)
cuando se intenta invocar un método inexistente en la clase en que se llaman.
Los errores de este tipo surgidos durante el desarrollo de las aplicaciones de Spark han tenido su
origen en la incompatibilidad de ciertas dependencias incluidas en el archivo de formato JAR. Con-
cretamente, ciertos paquetes incluidos en este archivo estaban presentes en el entorno del clúster
84
de Dataproc, aunque con una versión diferente. Por ello, hay métodos que uso en la aplicación, dis-
ponibles en el paquete del entorno local, que no están disponibles en el entorno del clúster de Cloud
Dataproc.
Para solucionarlo, hay que utilizar la misma versión que en el clúster —para ello, antes hay que en-
contrarla mediante la visualización de la ejecución por medio de YARN— o sobrescribir la versión del
clúster con la que se requiera. Esta segunda opción es comúnmente mejor, ya que permite seguir
utilizando los mismos métodos que en el entorno local. Para ello, en mi caso he usado un plugin de
Apache Maven que permite relocalizar —utilizando la propiedad relocations del plugin— un cierto
paquete. Esto significa que renombra todas las dependencias de ese paquete en la aplicación para
no compartir el mismo nombre que el paquete presente en el entorno del clúster.
Por ejemplo, supongamos el paquete com.company.utils. Este plugin renombraría el paquete y todas
sus llamadas desde la aplicación a alias.com.company.utils. De esta forma, aun teniendo una versión
diferente a la del entorno ejecución, no habría conflictos, permitiendo el funcionamiento de la apli-
cación.
10.3.3 Problema para cargar el modelo en la aplicación Java

Como he adelantado en apartados anteriores, por el momento no se puede hacer uso de modelos
creados y guardados con PySpark desde Jupyter en Cloud Dataproc. Este problema afecta tanto a la
carga de Estimators, que son modelos entrenados, como a Pipelines, secuencias de métodos de
transformación de un dataset.
Se trata de un error ocasionado por una excepción de Java. En concreto, la excepción java.lang.Nu-
llPointerException. Esta se lanza cuando se intenta acceder a una variable cuyo valor no ha sido ini-
cializado. Es una excepción que da poca información cuando se usa métodos de códigos de fuentes
externas.
Después de hacer un seguido de pruebas, pese no haber encontrado la raíz del problema, he encon-
trado los siguientes comportamientos:
• Es posible instanciar la clase del modelo en Java en el mismo punto del código donde se hace
la llamada a la carga de esta desde Google Cloud Storage.
• Es posible hacer la carga del modelo antes de hacer uso del framework de Spark, es decir,
fuera del código que ejecutan los workers. Cabe mencionar que esto no es una solución,
pues no es factible hacer una sola carga de modelos para todos los usuarios debido a que la
precisión en la predicción sería muy baja.
Como solución a este problema, existen varias posibilidades:
• Dedicar más tiempo a este apartado para estudiar más a fondo el problema y su origen.
• Encontrar una alternativa al uso de executors de Spark.
• Utilizar otras librerías cross-language que permitan la creación de modelos predictivos tanto
en Python como en Java.
• Hacer todo el proceso de análisis y creación de modelos predictivos en Java con una librería
diferente a la usada de Spark.
• Hacer todo el proceso de análisis y creación de modelos predictivos en Python con una li-
brería diferente a la usada de Spark.
85
• Crear el modelo en tiempo real, en vez de antemano. Para cada identificador de contador
procesado, cargar su histórico de los últimos dos años, preprocesar los datos, crear el mo-
delo y, con este, predecir el consumo del siguiente mes utilizando únicamente los datos más
recientes. Esta opción es, probablemente, la menos arriesgada en cuanto a posibles errores.
Además, tiene una ventaja, y es que el modelo se reentrena cada día. Sin embargo, tiene
tres desventajas:
o se acopla el equipo de data science y el equipo de desarrollo;
o se pierde flexibilidad a la hora de «jugar» con los modelos y probar posibles mejoras
de precisión en ellos;
o el tiempo necesario para procesado de cada usuario aumenta notablemente.
Este problema ha reflejado el poco tiempo que ha pasado desde que Spark se lanzó (cinco años), y
que es un framework muy verde en muchos ámbitos: tiene falta de documentación, carece de infor-
mación en las excepciones y errores que se lanzan, etc.
Sea como fuere, este percance no tiene una consecuencia importante en el proyecto, ya que, como
he mencionado en diversas ocasiones, el enfoque del proyecto es de arquitectura. Asimismo, el flujo
de datos principal no se ve afectado. No obstante, este problema se podría solucionar con un poco
más de tiempo. Probablemente desarrollaría la última de las posibilidades anteriormente menciona-
das, ya que es la más segura.
86
11 Planificación final
Este apartado tiene la intención de mostrar las diferencias entre la planificación temporal y de recur-
sos que se hizo al comenzamiento del proyecto y lo resultante. Para ello, dividiré el apartado en una
sección de recursos y otra temporal.
11.1 Recursos utilizados

En cuanto a los recursos, ha habido cambios respecto a lo previsto inicialmente, mostrado en el apar-
tado 5.1.1. Los recursos totales (los comunes de cada sección junto con los específicos de cada fase)
que definí son los mostrados en la siguiente tabla:
Recursos físicos Recursos digitales Recursos humanos

Ordenador Dell Latitude E5550, 8GB de me- Microsoft Word Director de proyecto
moria, 500GB de disco duro, Intel Core I5
Pantalla Dell 22 pulgadas Microsoft Outlook Gestor de proyectos
Ratón y teclado Microsoft Teams Arquitecto de software
Escritorio de trabajo y silla Microsoft Project Desarrollador de soft-
ware
Microsoft Excel
Entorno de desarrollo
Microsoft PowerPoint
Cuenta en GCP
Tabla 21. Recordatorio de recursos totales de la planificación inicial.
Sin embargo, ha habido más recursos que finalmente se han utilizado y no se había previsto inicial-
mente. Estos se muestran en la tabla siguiente:
Recursos digitales Recursos humanos

Postman Data scientist (científico de datos)
Git (mediante GitHub y GitHub Desktop)
PostgreSQL
Tabla 22. Recursos añadidos con respecto a la planificación inicial.
Además de los recursos añadidos, no especifiqué el entorno de desarrollo. Se trata de dos: Eclipse y
Spring Tool Suite 3 (STS3), en conjunto con Apache Maven.
11.2 Planificación temporal

Con respecto a la planificación temporal, también ha habido cambios, que abordaré en este apar-
tado. La fase 1 de la planificación no ha tenido ningún cambio ni desviación. Sin embargo, las fases
2, 3 y 4 han tenido los siguientes cambios o desviaciones temporales.
Primeramente, y haciendo mención del apartado 5.1.1, se ha añadido una tarea más a la fase 2 (elec-
ción de la arquitectura) del proyecto, antes de la tarea T6. Esta nueva tarea —llamada «especifica-
ciones del sistema»— pretende hacer un estudio de las necesidades del sistema antes de analizar
cada una de las plataformas y escoger los servicios y soluciones que ofrecen. De esta manera, se
87
tendrá claro qué se busca en las plataformas. Cabe mencionar también que un nombre más apro-
piado para definir esta fase es «estudio y elección de la arquitectura».
En la fase 3 (desarrollo de la arquitectura), se han añadido más subfases. El motivo por el que ante-
riormente era tan genérico es que el contenido concreto de esta fase dependía del propio proyecto
(definir desde la arquitectura necesaria para el sistema hasta la plataforma específica con que traba-
jar). Por este mismo motivo, y debido a la generalidad de esta fase (que ocupa una gran parte del
proyecto), han tenido lugar una serie de problemas y desviaciones temporales, que explicaré más
adelante.
Por lo tanto, el nuevo desglose de la fase 3 quedaría como podemos ver en la tabla siguiente, en la
que se hace una comparación directa con la planificación antigua.
Fase 3: Desarrollo de la arquitectura

Planificación inicial Planificación nueva
T13: creación de una cuenta T13: creación de una cuenta
T14: desarrollo de la arquitectura T14: creación de un simulador de envío de trazas
T15: integración de Cloud Storage en el sistema
T16: primera iteración de la parte batch con Dataproc y Spark
e integración de Dataproc en el sistema
T17: primera iteración de la parte streaming con Dataproc y
Spark Streaming
T18: integración de Cloud Datastore en el sistema
T19: análisis y modelaje de datos y creación de modelos pre-
dictivos
T20: segunda iteración de la parte batch con Dataproc y Spark
T21: segunda iteración de la parte streaming con Dataproc y
Spark
T22: integración de una sencilla aplicación web para mostrar
datos finales
Tabla 23. Comparación del desglose de la Fase 3 de la planificación temporal inicial con la misma una vez acabado el proyecto.
Respecto a las fases 3 y 4, la tarea T15 de la fase 4 —en la que documento el proyecto— la he ade-
lantado para hacerla en paralelo a la fase 3. Este cambio ha sido en ganancia de dos beneficios, prin-
cipalmente:
• Por un lado, podía empezar a redactar la documentación relacionada con la fase 2 (F2), y así
tener los conocimientos más recientes.
• Debido a la larga duración de la antigua tarea 14 (250 horas), intercalar horas de documen-
tación en medio podía ayudar a descansar de una tarea monótona. De la misma manera, se
aplica a la hora de realizar la tarea 15, que sería monótona realizarla entera de manera se-
guida.
El tiempo que se ha dedicado a la documentación del proyecto ha sido del 30% aproximadamente,
mientras que la fase 3 ha ocupado el 70% restante.
Sin embargo, debido a los percances en la integración de los modelos predictivos en las aplicaciones
de Apache Spark con Java, ha habido retrasos sobre la planificación inicial que han derivado en un
pequeño cambio de alcance, como se explica en el apartado 10.3.3. Afortunadamente, debido a que
88
el resultado predictivo no es relevante para el proyecto, este no se ha visto modificado más allá de
los resultados de estas predicciones.
No obstante, estos pequeños problemas del proyecto se han acumulado hasta para hacer retrasos
más importantes. Probablemente uno de los grandes errores de la planificación del proyecto ha sido
no definir la fase 3 en diferentes subfases pequeñas, para saber la situación del proyecto en cada
momento.
89
12 Retrospectiva y conclusión
Para concluir, dividiré esta última sección en tres apartados. En ellos se trata de hacer una crítica y
justificación de algunas de las secciones más importantes del proyecto.
12.1 Integración de conocimientos

Durante el grado en Ingeniería Informática, he aprendido muchas cosas de muchas asignaturas dife-
rentes. En este apartado, haré una lista de aquellas que más conocimientos han aportado o aporta-
rán para el desarrollo del proyecto y por qué. No se tendrán en cuenta aquellas asignaturas si ya se
han listado otras que son una continuación de esta. Por ejemplo, no se citarán Bases de datos ni
Diseño de bases de datos, ya que menciono Conceptos para bases de datos especializadas.
• Aplicaciones y servicios web. Esta asignatura me ha dado las herramientas necesarias para
crear una API con la que simular el envío de trazas de contadores. Del mismo modo, también
ha sido útil para construir la aplicación que muestra los datos resultantes del sistema.
• Arquitectura del software. Los conocimientos de la programación orientada a objetos
aprendidos en esta asignatura han sido de gran ayuda, así como las buenas prácticas en un
diseño por capas y la metodología ágil. Además, junto con Gestión de Proyectos de Software,
me ha enseñado a hacer pruebas —tanto unitarios como de integración—.
• Aspectos sociales y medioambientales de la informática. Esta asignatura me ha ayudado a
tener en cuenta aspectos medioambientales, sociales y éticos de la informática y he aplicado
estos conocimientos al propio proyecto. Además, me ha sido de gran ayuda que gran parte
de la asignatura fuera la creación y presentación de un pequeño trabajo.
• Conceptos para bases de datos especializadas. La tarea de estudiar y escoger una base de
datos entre muchas candidatas, así como la preparación y creación de índices, habría resul-
tado más difícil si no fuera por los conocimientos adquiridos durante esta asignatura.
• Empresa y entorno económico. Junto con Gestión de Proyectos de Software, esta asignatura
me ha ayudado a la hora de estimar un presupuesto total del proyecto.
• Ingeniería de requisitos. Esta asignatura me ha sido de ayuda a la hora de definir los requi-
sitos del sistema a crear. Además, junto con Gestión de Proyectos de Software, de realizar
una planificación temporal con más de un rol de trabajadores.
• Minería de datos. Una de las últimas partes del proyecto es la creación de varios modelos
predictivos, cuya realización sería incomprensible sin los conocimientos otorgados por esta
asignatura al respecto.
• Proyecto de ingeniería del software. La planificación temporal y personal que he adquirido
en esta asignatura han sido clave, así como la definición de requisitos para el sistema y ex-
periencia ganada en metodología agile.
• Proyectos de programación. Al igual que en Arquitectura del software, aunque de carácter
un poco más práctico, esta asignatura me ha enseñado a llevar a cabo una arquitectura en
varias capas, así como la programación orientada a objetos. Además, también a definir re-
quisitos de un sistema o proyecto.
90
12.2 Justificación de competencias técnicas

A continuación, listaré las competencias técnicas asociadas al proyecto y explicaré la influencia de
cada una de ellas en este.
• CES1.1. Esta competencia se trabaja a un nivel alto durante el proyecto debido a que el sis-
tema diseñado y desarrollado es crítico y complejo.
• CES1.2. Esta competencia se trabaja a un nivel alto, ya que el desarrollo del sistema com-
pleto es una integración de diferentes servicios y aplicaciones separadas
• CES1.3. Esta competencia se trabaja a un nivel bajo durante el proyecto. Si bien se identifi-
can algunos posibles riesgos del sistema, no es el una de las partes fundamentales del pro-
yecto.
• CES1.4. Esta competencia se trabaja a un nivel alto, ya que el diseño de un sistema distri-
buido en Cloud es una de las partes más importantes del proyecto. La otra es el desarrollo
de una pequeña demostración de este en la práctica.
• CES1.5. Esta competencia se trabaja a un nivel medio, ya que una de las partes del proyecto
es estudiar, comparar e implementar una base de datos.
• CES1.8. Esta competencia se trabaja a un nivel medio ya que, durante el proyecto, se diseña
y desarrolla un subsistema en tiempo real.
• CES1.9. Esta competencia se trabaja a un nivel bajo, ya que, durante todo el desarrollo, hay
un sistema entero que gestionar.
• CES2.1. Esta competencia se trabaja a un nivel alto debido a que una de las partes funda-
mentales del proyecto es definir los requisitos y especificaciones de un sistema.
• CES2.2. Esta competencia se trabaja a un nivel medio, ya que se estudian las dimensiones
sociales, legales, económicas y medioambientales del proyecto, aunque no profundamente.
12.3 Trabajo futuro

Una de las ventajas del sistema diseñado es su facilidad para integrar nuevas funcionalidades y casos
de uso. Esto es posible gracias al desacoplamiento de los diferentes servicios que lo componen.
Dos casos de uso potencialmente interesantes y relacionados con los ya existentes que podrían desa-
rrollarse como trabajo futuro son ser los siguientes:
• Asesoramiento de una tarifa óptima al usuario. Mediante esta funcionalidad, el sistema de-
tectaría, a través del registro histórico de consumo de agua de cada usuario individualmente,
aquella tarifa más adecuada para cada uno. Para ello, habría que cotejar datos obtenidos
mediante análisis de estos datos con una base de datos de tarifas de la compañía cliente.
• Detección de fraude en los contadores. Este caso de uso es ligeramente más complicado.
Las bases de datos de grafos tienen un buen resultado para este tipo de casos de uso. Para
llevarlo a cabo, se debería hacer un cotejo de los datos del sistema con aquellos proporcio-
nados con la Agencia Tributaria, para comparar datos sobre número de habitantes declara-
dos por vivienda con los estimados por los modelos estadísticos. De aquí, se podrían obtener
dos posibles fraudes: de contadores (donde este indica menos consumo del real) o de ha-
cienda (donde se declaran menos habitantes de los reales), dependiendo de los resultados.
91
12.4 Retrospectiva y conclusión

Este proyecto me ha abierto las puertas a dos nuevos ámbitos de la ingeniería informática, como big
data y cloud. Si bien ha sido un proyecto de poco más de un semestre de duración, he aprendido una
cantidad asombrosa de información, tecnologías y otras cosas al respecto de estos. He usado frame-
works que no había usado antes —como Spring y Spark y he solucionado errores que cuya solución
desconocía inicialmente.
Además, he aprendido sobre todas las tecnologías de big data —y otras que no están enfocadas al
tratamiento de este— de tres de los proveedores de servicios cloud más grandes en la actualidad.
Asimismo, he entrado más en detalle con una de ellas para implementar, mediante su API, un sistema
con varios de sus servicios.
Y, aunque haya tenido algunos problemas durante el transcurso —sobre todo en la última parte, de
implementación—, he encontrado la manera de sobrepasarlos, centrándome en la importancia del
proyecto: el diseño del sistema y su arquitectura.
Este proyecto ha demostrado la posibilidad —a falta de utilizar unos buenos predictivos, que confío
en que son más que posibles— de los dos casos de uso planteados inicialmente, desde la entrada de
datos brutos en el sistema hasta la generación de los datos necesarios para la recepción por parte
de los usuarios finales. De este modo, puedo dar por cumplidos los tres objetivos planteados inicial-
mente en el proyecto.
92
13 Referencias y bibliografía
[danstools00]. (2017). Epoch Unix Time Stamp Converter. Obtenido de
https://www.unixtimestamp.com/
[masteratt]. (27 de abril de 2015). What happen when EC2 instance goes down? Recuperado el 8 de
abril de 2019, de AWS Discussion Forums:
https://forums.aws.amazon.com/thread.jspa?threadID=179210
Adshead, A. (8 de abril de 2013). Big data storage: Defining big data and the type of storage it
needs. Recuperado el 5 de febrero de 2019, de ComputerWeekly:
https://www.computerweekly.com/podcast/Big-data-storage-Defining-big-data-and-the-
type-of-storage-it-needs
Advantages and Disadvantages of Cloud Computing. (7 de mayo de 2015). Recuperado el 2019 de

febrero de 25, de LevelCloud: ºhttps://www.levelcloud.net/why-levelcloud/cloud-
education-center/advantages-and-disadvantages-of-cloud-computing/
Agencia Española de Protección de Datos. (s.f.). Cumplimiento de las obligaciones. Obtenido de

https://www.aepd.es/reglamento/cumplimiento/index.html
Agencia Española de Protección de Datos. (s.f.). Ejerce tus derechos. Obtenido de

https://www.aepd.es/reglamento/derechos/index.html
Agneeswaran, V. (3 de marzo de 2014). When is Hadoop MapReduce better than Spark?

Recuperado el 2019 de febrero de 18, de Quora: https://www.quora.com/When-is-
Hadoop-MapReduce-better-than-Spark
Amazon. (1 de mayo de 2019). Amazon EMR announces Support for Multiple Master nodes to
enable High Availability for EMR applications. Recuperado el 3 de junio de 2019, de What's
New with AWS: https://aws.amazon.com/about-aws/whats-new/2019/04/amazon-emr-
announces-support-for-multiple-master-nodes-to-enable-high-availability-for-EMR-
applications/
Amazon. (s.f.). Amazon EMR FAQs. Recuperado el 8 de abril de 2019, de Amazon Web Services:
https://aws.amazon.com/emr/faqs/
Amazon. (s.f.). AWS & Sustainability. Recuperado el 11 de marzo de 2019, de Amazon:

https://aws.amazon.com/about-aws/sustainability/
Amazon. (s.f.). Documentación general de Amazon Web Services. Obtenido de Amazon Web
Services: https://aws.amazon.com/
Apache. (2017). Apache Kafka® is a distributed streaming platform. What exactly does that mean?
Recuperado el 3 de mayo de 2019, de Apache Kafka: https://kafka.apache.org/intro
Apache. (1 de mayo de 2019). Spark SQL, DataFrames and Datasets Guide. Obtenido de Spark docs:
https://spark.apache.org/docs/2.1.2/sql-programming-guide.html
Apache. (s.f.). A library for reading data from Google Cloud Pub/Sub using Spark Streaming.
Obtenido de Apache Bahir: https://bahir.apache.org/docs/spark/current/spark-streaming-
pubsub/
93
Apache. (s.f.). Hardware Provisioning. Recuperado el 17 de abril de 2019, de Spark docs:

https://spark.apache.org/docs/0.9.1/hardware-provisioning.html
Apache. (s.f.). ML Pipelines. Recuperado el 1 de mayo de 2019, de Spark docs:

https://spark.apache.org/docs/latest/ml-pipeline.html
Apache. (s.f.). RDD Programming Guide. Obtenido de Apache Spark docs:

https://spark.apache.org/docs/latest/rdd-programming-guide.html
Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R. H., Konwinski, A., . . . Zaharia, M. (2009).
Above the Clouds: A Berkeley View of Cloud. Berkeley, California, Estados Unidos:
University of California. Recuperado el 14 de febrero de 2019, de
https://www2.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf
Arthur, C. (23 de agosto de 2013). Tech giants may be huge, but nothing matches big data.
Recuperado el 20 de febrero de 2019, de The Guardian:
https://www.theguardian.com/technology/2013/aug/23/tech-giants-data
Badola, V. (9 de noviembre de 2015). Microsoft Azure App Service, Cloud Services, or VMs?
Recuperado el 11 de mayo de 2019, de Cloud Academy Blog:
https://cloudacademy.com/blog/microsoft-azure-app-service-virtual-machines/
Bagajewicz, M., & Valtinson, G. (2014). Leak Detection in Gas Pipelines Using Accurate Hydraulic
Models. Industrial & Engineering Chemistry Research, 53(44), 16964-16972.
doi:10.1021/ie501322g
Bala, R., Leong, L., & Smith, D. (23 de mayo de 2018). Magic Quadrant for Cloud Infrastructure as a
Service, Worldwide. Recuperado el 19 de marzo de 2019, de Gartner:
https://www.gartner.com/doc/reprints?id=1-50WJ5DV&ct=180525&st=sb
Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Highsmith, J., . . .
Thomas, D. (13 de febrero de 2001). Manifesto for Agile Software Development.
Recuperado el 25 de febrero de 2019, de http://agilemanifesto.org/
Carbon Footprint Ltd. (s.f.). Carbon calculator. Recuperado el 18 de marzo de 2019, de

Carbonfootprint.com: https://www.carbonfootprint.com/calculator.aspx
Caridad Ocerín, J. M., Millán Vázquez de la Torre, G., & Dios Palomares, R. (septiembre de 2001).
Predicción del consumo de agua en Córdoba. Ingeniería del agua, 8(3), 305-318.
doi:https://doi.org/10.4995/ia.2001.2869
Caron, R. (1 de junio de 2018). How I choose which services to use in Azure. Recuperado el 8 de
marzo de 2019, de Microsoft Azure: https://azure.microsoft.com/es-es/blog/how-i-
choose-which-services-to-use-in-azure/
Chalmers, S., Bothorel, C., & Picot-Clémente, R. (2013). Big Data - State of the Art. Institut Mines-
Télécom, Department Télécom Bretagne, Brest (Francia). Recuperado el 22 de febrero de
2019, de https://www.researchgate.net/publication/258868555_Big_Data_-
_State_of_the_Art
Chang, H., & House-Peters, L. (2011). Urban Water Demand Modeling: Review of Concepts,
Methods and Organizing Principles. Institute for Sustainable Solutions Publications and
Presentations, 47(15). doi:10.1029/2010WR009624
94
Cisco. (2018). Cisco Visual Networking Index: Forecast and Trends, 2017–2022. San Jose, California.
Recuperado el 21 de febrero de 2019, de
https://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-
index-vni/white-paper-c11-741490.pdf
Cloudcraft. (s.f.). Cloudcraft - Tools for AWS pros. Recuperado el 19 de marzo de 2019, de
Cloudcraft: https://cloudcraft.co/app
Cloudera and Hortonworks Complete Planned Merger . (3 de enero de 2019). Recuperado el 22 de

febrero de 2019, de Hortonworks: https://hortonworks.com/press-releases/cloudera-
hortonworks-complete-planned-merger/
Costos i sostenibilitat d'un projecte informàtic. (s.f.). Recuperado el 5 de marzo de 2019, de Atenea:
https://atenea.upc.edu/mod/folder/view.php?id=1855622
Dean, J., & Ghemawat, S. (2004). MapReduce: Simplified Data Processing on Large Clusters.
OSDI'04: Sixth Symposium on Operating System Design and Implementation, 137-150.
Recuperado el 22 de febrero de 2019, de https://storage.googleapis.com/pub-tools-public-
publication-data/pdf/16cb30b4b92fd4989b8619a61752a2387c6dd474.pdf
Delgado, L. (1 de junio de 2017). CosmosDb vs Table Storage: write throughput comparison.

Recuperado el 3 de mayo de 2019, de Medium:
https://medium.com/@murdockcrc/cosmosdb-vs-table-storage-write-throughput-
comparison-ef9aca2dddc5
Díaz, C. (25 de julio de 2017). El fraude en el suministro de agua cae un 30% en tres años. Diario de
Sevilla. Recuperado el 6 de febrero de 2019, de
https://www.diariodesevilla.es/sevilla/fraude-suministro-agua-cae-
anos_0_1157284637.html
Domínguez, J. (16 de abril de 2018). De Lambda a Kappa: evolución de las arquitecturas Big Data.
Recuperado el 4 de abril de 2019, de Tecnología para Negocio:
https://www.paradigmadigital.com/techbiz/de-lambda-a-kappa-evolucion-de-las-
arquitecturas-big-data/
Ellingwood, J. (28 de septiembre de 2016). An Introduction to Big Data Concepts and Terminology.
Recuperado el 11 de febrero de 2019, de DigitalOcean:
https://www.digitalocean.com/community/tutorials/an-introduction-to-big-data-
concepts-and-terminology
Estebanez, J. (10 de mayo de 2017). El Big Data, la apuesta de futuro de las empresas. Recuperado
el 31 de enero de 2019, de Comunidad Movistar: https://comunidad.movistar.es/t5/Te-
interesa/El-Big-Data-la-apuesta-de-futuro-de-las-empresas/ba-p/3201727
European Parliament. (2016). Regulation (EU) 2016/679 of The European Parliament and of The
Council of 27 April 2016. Official Journal of the European Union, 119, 1-88. Recuperado el
febrero de 26 de 2019, de https://eur-lex.europa.eu/legal-
content/EN/TXT/?uri=CELEX%3A32016R0679
Filanovskiy, A. (6 de marzo de 2016). Hadoop Compression. Choosing compression codec. Part2.

Recuperado el 30 de abril de 2019, de The Data Warehouse Insider:
95
https://blogs.oracle.com/datawarehousing/hadoop-compression-choosing-compression-
codec-part2
Ganesh, A., & McGrath, D. (31 de enero de 2019). NoSQL for the serverless age: Announcing Cloud
Firestore general availability and updates. Recuperado el 4 de junio de 2019, de Google
Cloud Databases: https://cloud.google.com/blog/products/databases/announcing-cloud-
firestore-general-availability-and-updates
Gazta, A. (12 de octubre de 2018). Pros & Cons of Cloud Computing: How to work around them?
Recuperado el 21 de febrero de 2019, de GreyCampus:
https://www.greycampus.com/blog/cloud/pros-and-cons-of-cloud-computing-how-to-
work-around-them
Gewirtz, D. (21 de marzo de 2018). Volume, velocity, and variety: Understanding the three V's of big
data. Recuperado el 11 de febrero de 2019, de ZDNet:
https://www.zdnet.com/article/volume-velocity-and-variety-understanding-the-three-vs-
of-big-data/
Glick, A., & Ryan, T. (5 de julio de 2017). Choosing the right compute option in GCP: a decision tree.
Recuperado el 9 de mayo de 2019, de Google Cloud:
https://cloud.google.com/blog/products/gcp/choosing-the-right-compute-option-in-gcp-a-
decision-tree
Google. (18 de diciembre de 2018). Cloud Pub/Sub: A Google-Scale Messaging Service. Recuperado
el 15 de abril de 2019, de Google Cloud Pub/Sub architecture:
https://cloud.google.com/pubsub/architecture
Google. (26 de febrero de 2019). Evolution and comparison of main cloud providers worldide from
2004. Recuperado el 26 de febrero de 2019, de Google Trends:
https://trends.google.com/trends/explore?date=all&q=%2Fm%2F05nrgx,%2Fm%2F0105p
bj4,%2Fm%2F04y7lrx
Google. (2 de febrero de 2019). Interest over time for Big Data topic, worldwide 2004-present.
Recuperado el 2 de febrero de 2019, de Google Trends:
https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0bs2j8q
Google. (31 de enero de 2019). Storage Size Calculations. Recuperado el 10 de mayo de 2019, de
Google Cloud Datastore Documentation:
https://cloud.google.com/datastore/docs/concepts/storage-size
Google. (s.f.). Cloud Dataflow Documentation. Obtenido de Google Cloud:

https://cloud.google.com/dataflow/docs/
Google. (s.f.). Cloud Firestore in Datastore mode documentation. Obtenido de Google Cloud:
https://cloud.google.com/datastore/docs/
Google. (s.f.). Cloud Pub/Sub documentation. Obtenido de Google Cloud:

https://cloud.google.com/pubsub/docs/
Google. (s.f.). Cloud Storage documentation. Obtenido de Google Cloud:

https://cloud.google.com/storage/docs/
96
Google. (s.f.). Datastore Queries. Recuperado el 20 de mayo de 2019, de Google Cloud Datastore
Documentation: https://cloud.google.com/datastore/docs/concepts/queries
Google Developers. (5 de febrero de 2013). Datastore Introduction. Recuperado el 2019 de mayo

de 17, de https://www.youtube.com/watch?v=fQazhzcC-rg
Google. (s.f.). Google App Engine Documentation. Obtenido de Google Cloud:

https://cloud.google.com/appengine/docs/
Google. (s.f.). Google Cloud SDK documentation. Obtenido de Google Cloud:

https://cloud.google.com/sdk/docs/
Google. (s.f.). Google Cloud Sustainability. Recuperado el 11 de marzo de 2019, de Google Cloud:
https://cloud.google.com/sustainability/
Google. (s.f.). Indexes. Recuperado el 5 de mayo de 2019, de Google Cloud Datastore

documentation: https://cloud.google.com/datastore/docs/concepts/indexes
Google. (s.f.). PubsubMessage. Recuperado el 15 de abril de 2019, de Google Cloud Pubsub

documentation:
https://cloud.google.com/pubsub/docs/reference/rest/v1/PubsubMessage
Google. (s.f.). Storage Size Calculations. Recuperado el 11 de marzo de 2019, de Google Cloud
Datastore Documentation: https://cloud.google.com/datastore/docs/concepts/storage-
size
Hanselman, S. (23 de enero de 2014). Introducing Windows Azure WebJobs. Recuperado el 20 de

mayo de 2019, de Scott Hanselman blog:
https://www.hanselman.com/blog/IntroducingWindowsAzureWebJobs.aspx
https://www.youtube.com/watch?v=d4CiMWy0J70. (5 de febrero de 2013). Datastore Query,

Index and Transaction. Recuperado el 17 de mayo de 2019, de
https://www.youtube.com/watch?v=d4CiMWy0J70
Humby, C. (2006). Kellogg School, Estados Unidos.
Ismail, N. (5 de abril de 2017). The value of data: forecast to grow 10-fold by 2025. Recuperado el
2019 de 01 de 29, de Information Age: https://www.information-age.com/data-forecast-
grow-10-fold-2025-123465538/
Kahanwal, B., & Singh, T. P. (2012). The Distributed Computing Paradigms: P2P, Grid, Cluster, Cloud,
and Jungle. International Journal of Latest Research in Science and Technology, 1(2), 183-
187. Recuperado el 21 de febrero de 2019, de
https://arxiv.org/ftp/arxiv/papers/1311/1311.3070.pdf
Kumar, R., & Charu, S. (2015). Comparison between Cloud Computing, Grid Computing, Cluster
Computing and Virtualization. International Journal of Modern Computer Science and
Applications (IJMCSA), 3(1). Recuperado el 13 de febrero de 2019, de
https://www.researchgate.net/publication/271531358_Comparison_between_Cloud_Com
puting_Grid_Computing_Cluster_Computing_and_Virtualization
Laney, D. (2001). 3D Data Management: Controlling Data Volume, Velocity and Variety. META
Group, 949. Recuperado el 11 de febrero de 2019, de https://blogs.gartner.com/doug-
97
laney/files/2012/01/ad949-3D-Data-Management-Controlling-Data-Volume-Velocity-and-
Variety.pdf
Ley Orgánica 3/2018. Boletín Oficial del Estado, núm. 294, Madrid, España. (6 de 12 de 2018).
Obtenido de https://www.boe.es/buscar/act.php?id=BOE-A-2018-16673
Lohr, S. (11 de agosto de 2012). How Big Data Became So Big. Recuperado el 13 de febrero de
2019, de New York Times: https://www.nytimes.com/2012/08/12/business/how-big-data-
became-so-big-unboxed.html
Lohr, S. (1 de febrero de 2013). The Origins of ‘Big Data': An Etymological Detective Story.
Recuperado el 13 de febrero de 2019, de New York Times Bits:
https://bits.blogs.nytimes.com/2013/02/01/the-origins-of-big-data-an-etymological-
detective-story/
Maneas, S.-E. (19 de abril de 2014). java.lang.ClassNotFoundException – How to solve Class Not
Found Exception. Obtenido de Java Code Geeks:
https://examples.javacodegeeks.com/java-basics/exceptions/java-lang-
classnotfoundexception-how-to-solve-class-not-found-exception/
Marr, B. (21 de mayo de 2018). How Much Data Do We Create Every Day? The Mind-Blowing Stats
Everyone Should Read. Recuperado el 29 de enero de 2019, de Forbes:
https://www.forbes.com/sites/bernardmarr/2018/05/21/how-much-data-do-we-create-
every-day-the-mind-blowing-stats-everyone-should-read/#1cbcc2bd60ba
Marz, N., & Warren, J. (2015). Big Data: Principles and best practices of scalable realtime data
systems. Manning. Recuperado el 11 de febrero de 2019
Mell, P., & Grance, T. (2011). The NIST Definition of Cloud Computing. Recommendación del
National Institute of Standards and Technology, National Institute of Standards and
Technology, U.S. Department of Commerce, Gaithersburg. Recuperado el 5 de febrero de
2019, de https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
Microsoft. (11 de marzo de 2018). Decision tree for Azure compute services. Recuperado el 22 de
marzo de 2019, de Microsoft Azure Application Architecture Guide:
https://docs.microsoft.com/en-us/azure/architecture/guide/technology-choices/compute-
decision-tree
Microsoft Corporation. (s.f.). Obtenido de Microsoft Azure: https://azure.microsoft.com/
Microsoft Corporation. (22 de marzo de 2018). Availability and reliability of Apache Hadoop clusters
in HDInsight. Recuperado el 8 de abril de 2019, de Microsoft Azure HDInsight Docs:
https://docs.microsoft.com/en-us/azure/hdinsight/hdinsight-high-availability-linux
Microsoft Corporation. (s.f.). Commitment to carbon neutral. Recuperado el 11 de marzo de 2019,

de Microsoft: https://www.microsoft.com/en-us/environment/carbon
Microsoft Corporation. (s.f.). Microsoft Project. Recuperado el 1 de marzo de 2019, de Microsoft:

https://products.office.com/en/project/project-and-portfolio-management-software
Mitchell, G. (23 de enero de 2013). How much data is on the internet? Recuperado el 11 de febrero
de 2019, de BBC Science Focus: https://www.sciencefocus.com/future-technology/how-
much-data-is-on-the-internet/
98
Mòdul 2.6 - El informe de sostenibilidad 2018.pdf. (s.f.). Recuperado el 5 de marzo de 2019, de

Atenea: https://atenea.upc.edu/mod/folder/view.php?id=1855622
Naeem, M. M., Memon, F., Mahar, H., Siddique, M., & Chohan, A. (2016). CLUSTER COMPUTING VS
CLOUD COMPUTING A COMPARISON AND AN OVERVIEW. Science International, 28(6),
5267-5271. Recuperado el 13 de febrero de 2019, de
https://www.researchgate.net/publication/313656217_CLUSTER_COMPUTING_VS_CLOUD
_COMPUTING_A_COMPARISON_AND_AN_OVERVIEW_1
Navarro Antolín, C. (14 de septiembre de 2014). La crisis dispara un 80% los casos de fraude en el
suministro de agua. Diario de Sevilla. Recuperado el 6 de febrero de 2019, de
https://www.diariodesevilla.es/sevilla/crisis-dispara-casos-fraude-
suministro_0_843815664.html
Normandeau, K. (12 de septiembre de 2013). Beyond Volume, Variety and Velocity is the Issue of
Big Data Veracity. Recuperado el 11 de febrero de 2019, de insideBIGDATA:
https://insidebigdata.com/2013/09/12/beyond-volume-variety-velocity-issue-big-data-
veracity/
Palmer, M. (3 de noviembre de 2006). Data is the New Oil. Recuperado el 29 de Enero de 2019, de
ANA Marketing Maestros Blog:
https://ana.blogs.com/maestros/2006/11/data_is_the_new.html
Pecan Street. (s.f.). More than the largest source of energy data and water data. Recuperado el 20
de mayo de 2019, de Dataport cloud: https://dataport.cloud/
Pecan Street. (s.f.). Pecan Street Dataport. Recuperado el 20 de mayo de 2019, de Pecan Street:
https://www.pecanstreet.org/dataport/
Phalip, J. (14 de agosto de 2018). Managing Java dependencies for Apache Spark applications on
Cloud Dataproc. Recuperado el 20 de mayo de 2019, de Google Cloud Data Analytics:
https://cloud.google.com/blog/products/data-analytics/managing-java-dependencies-
apache-spark-applications-cloud-dataproc
Phys.org. (15 de abril de 2015). https://phys.org/news/2015-04-software-real-time-leaks-oil-

gas.html. Recuperado el 22 de febrero de 2019, de Phys.org: https://phys.org/news/2015-
04-software-real-time-leaks-oil-gas.html
Progress Software Corporation. (s.f.). Calculating index size. Recuperado el 30 de abril de 2019, de
Progress OpenEdge Database Essentials:
https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/gsdbe
/calculating-index-size.html
RenSMART. (s.f.). Conversor de kWh a CO2e. Recuperado el 18 de marzo de 2019, de

RenSMART.com: https://www.rensmart.com/Calculators/KWH-to-CO2
Rizzatti, D. L. (14 de septiembre de 2016). Digital Data Storage is Undergoing Mind-Boggling

Growth. Recuperado el 20 de febrero de 2019, de Electronic Engineering Times:
https://www.eetimes.com/author.asp?section_id=36&doc_id=1330462
Rosner, J. (24 de julio de 2018). Equivalencia lumen a vatios tubos fluorescentes. Recuperado el
2019 de marzo de 18, de Llumor: http://www.llumor.es/info-led/equivalencia-lumen-a-
vatios-tubos-fluorescentes
99
Rouse, M. (13 de diciembre de 2017). big data storage. Recuperado el 5 de febrero de 2019, de
SearchStorage: https://searchstorage.techtarget.com/definition/big-data-storage
Sabaté, F. (s.f.). Gestión del tiempo. Recuperado el 1 de marzo de 2019, de Atenea:

https://atenea.upc.edu/mod/folder/view.php?id=1855622
Sabaté, F., Barrabés, F., & Rajadell, M. (s.f.). Gestión económica. Recuperado el 5 de marzo de 2019,
de Atenea: https://atenea.upc.edu/mod/folder/view.php?id=1855622
Scalability. (s.f.). Recuperado el 4 de febrero de 2019, de Wikipedia:

https://en.wikipedia.org/wiki/Scalability
Schieber, P. (5 de febrero de 1987). The Wit and Wisdom of Grace Hopper. The OCLC
Newsletter(167). Recuperado el 22 de febrero de 2019, de
http://www.cs.yale.edu/homes/tap/Files/hopper-wit.html
Seintra, F. J., Maassen, J., van Nieuwpoort, R. V., Drost, N., van Kessel, T., van Werkhoven, B., . . .
Bal, H. E. (2011). Jungle Computing: Distributed Supercomputing beyond Clusters, Grids,
and Clouds. Department of Computer Science, Vrije University. Recuperado el 21 de
febrero de 2019, de https://www.cs.vu.nl/~kielmann/papers/jungle.pdf
Shalom, N. (30 de julio de 2012). Difference between scaling horizontally and vertically for
databases. (B. Sindi, B. Debnath, B. Tarski, Mohammad, E. Filipe, [user5994461], &
[theterminalguy], Editores) Recuperado el 4 de febrero de 2019, de Stack Overflow:
https://stackoverflow.com/questions/11707879/difference-between-scaling-horizontally-
and-vertically-for-databases#answer-11715598
Smith, B. (14 de julio de 2017). Creating a carbon-free headquarters in the Puget Sound region.
Recuperado el 12 de marzo de 2019, de Microsoft On the Issues:
https://blogs.microsoft.com/on-the-issues/2017/07/14/creating-carbon-free-
headquarters-puget-sound-region/
Srivastava, P., & Khan, R. (2018). A Review Paper on Cloud Computing. International Journals of
Advanced Research in Computer Science and Software Engineering, 8(6), 17-20.
Recuperado el 21 de febrero de 2019, de
https://www.researchgate.net/publication/326073288_A_Review_Paper_on_Cloud_Comp
uting
StorageCraft. (24 de abril de 2018). Inside the Data Growth Explosion (And What it Means for Your
Business). Recuperado el 20 de febrero de 2019, de StorageCraft Recovery Zone:
https://blog.storagecraft.com/inside-data-growth-explosion/
Sullivan, D., & Sullivan, J. (16 de septiembre de 2015). NoSQL Key-Value Database Simplicity vs.
Document Database Flexibility. Recuperado el 2019 de mayo de 2019, de Informit:
http://www.informit.com/articles/article.aspx?p=2429466
Taylor, T. (11 de enero de 2019). BIGGEST CLOUD COMPUTING VENDORS: A LOOK AT THE TOP 5.
Recuperado el 22 de febrero de 2019, de TechGenix: http://techgenix.com/cloud-
computing-vendors/
The Python Software Foundation. (s.f.). Compression compatible with bzip2. Recuperado el 30 de
abril de 2019, de Python docs: https://docs.python.org/2/library/bz2.html
100
Toonders, J. (Julio de 2014). Data Is the New Oil of the Digital Economy. Recuperado el 29 de Enero
de 2019, de Wired: https://www.wired.com/insights/2014/07/data-new-oil-digital-
economy/
Trujillo, G., Kim, C., Jones, S., Garcia, R., & Murray, J. (2015). Virtualizing Hadoop: How to Install,
Deploy, and Optimize Hadoop in a Virtualized Architecture. Estados Unidos: Person
Education, Inc. Recuperado el 4 de febrero de 2019
Tyagi, S. (25 de junio de 2016). Spark Transformation - Why its lazy and what is the advantage?
Recuperado el 7 de marzo de 2019, de Stackoverflow:
https://stackoverflow.com/questions/38027877/spark-transformation-why-its-lazy-and-
what-is-the-advantage
What Is Big Data. (11 de agosto de 2014). Recuperado el 11 de febrero de 2019, de Oracle:
https://www.oracle.com/big-data/guide/what-is-big-data.html
What is Kanban. (s.f.). Recuperado el 26 de febrero de 2019, de Agile Alliance:

https://www.agilealliance.org/glossary/kanban/
What is Scrum. (s.f.). Recuperado el 25 de febrero de 2019, de Scrum:

https://www.scrum.org/resources/what-is-scrum
101
Anexos
Imágenes ampliadas
Anexo 1. Diagrama de Gantt de la planificación temporal del proyecto. Generado mediante Microsoft Project.
102
Anexo 2. Representación esquemática de los nodos con que contará el sistema de procesamiento.
103
Anexo 3. Diagrama del flujo de datos de la arquitectura utilizando Microsoft Azure.
104
Anexo 4. Árbol de decisión de opciones de almacenamiento de Google Cloud Platform. Imagen extraída de la web de Google Cloud, 2017, y traducida. Usada con el permiso de Google.
105
Anexo 5. Diagrama del flujo de datos de la arquitectura utilizando Google Cloud Platform.
106
Anexo 6. Diagrama de flujo de datos de la arquitectura utilizando Amazon Web Services.
107
Anexo 7. Esquema de los diferentes microservicios del sistema.
108

Arquitectura Big Data

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Arquitectura Big Data

Cargado por

Copyright:

Formatos disponibles

Arquitectura Big Data

Trabajo de Fin de Grado

DIRECTOR: JORDI SABATER PICAÑOL — EVERIS

Jacobo Moral Buendía

6.3.1 Sostenibilidad económica ______________________________________________ 33

9.2.5 Procesamiento y análisis de datos ________________________________________ 56

12.4 Retrospectiva y conclusión________________________________________________ 92

1.1 Big data

1.1.1 Problemas principales de los sistemas tradicionales

En esta sección estudiaremos estos dos problemas.

1.1.1.1 Escalabilidad de procesamiento

1.1.1.2 Escalabilidad de almacenamiento

1.1.2 Propiedades de los sistemas Big Data

de tareas grandes en diferentes subtareas, permitiendo así la ejecución en diferentes máquinas de

1.1.2.4 Otras propiedades de Big Data

Figura 2. Clasificación de los tipos de computación distribuida. Kahanwal, Brijender; Singh,

Amazon Web Services: (Worldwide) Google Cloud Platform: (Worldwide)

2 Formulación del problema

2.2 Partes interesadas

A continuación, los explicaremos en detalle.

3 Estado del arte

3.1 Big Data

3.3 Predicción del consumo

3.4 Detección de fugas

5.1 Descripción de las tareas y recursos

5.1.1 Descripción de cada una de las fases y subfases

Recursos físicos Recursos digitales Recursos humanos

5.1.1.1 Fase inicial

Dentro de la fase inicial, encontramos las siguientes tareas a realizar:

• (T1) Búsqueda de información sobre Big Data, Cloud y suministro de agua.

5.1.1.2 Elección de la arquitectura

Dentro de esta fase, encontramos las siguientes tareas a realizar:

5.1.1.3 Desarrollo de la arquitectura

Dentro de la fase de desarrollo, encontramos las siguientes tareas a realizar:

• (T13) Creación de una cuenta gratuita en la plataforma escogida.

En la conclusión, encontramos las siguientes tareas a realizar:

• (T15) Documentación y realización de la memoria del proyecto.

5.1.2 Resumen de tareas

Fase Tarea Dependencias Tiempo estimado

F1: Fase inicial T3: planificación temporal T2 20

T5: documentación final de GEP T2, T3, T4 20

T11: propuesta de Azure T9 10

5.2 Diagrama de Gantt

5.3 Plan de acción y valoración de alternativas

• Error en la planificación temporal. Es un fallo muy probable dada mi poca experiencia en

6.1 Análisis del presupuesto

6.1.1 Recursos humanos

• Director del proyecto. Es el responsable del proyecto dentro de la empresa. Se encargará de

Recurso Coste por hora Horas totales Coste total

6.1.2 Recursos materiales

En la Tabla 4 observamos un resumen de lo anteriormente mencionado, así como el coste total de

Recurso Coste mensual Meses Coste total

6.1.3 Recursos digitales

• Microsoft Word, Excel, PowerPoint. Estas herramientas se usarán para el desarrollo de la

6.1.4 Precio del producto y viabilidad

6.2 Control de desviaciones

6.2.1 Control de desviaciones

6.2.2 Indicadores de desviaciones

PPP13 Vida útil Riesgos

6.3.1 Sostenibilidad económica

En cuanto a la puesta en producción del proyecto, el coste no es demasiado elevado teniendo en

6.3.2 Sostenibilidad social

6.3.3 Sostenibilidad medioambiental