Página 1 de 55

Máster Universitario en Ingeniería Informática

Trabajo Fin de Máster

Autor:

Ana Lavalle López

Tutores:

Juan Carlos Trujillo Mondéjar

Alejandro Maté Morga

Julio 2018

Página 2 de 55

Agradecimientos

Son muchas las manos y los corazones que contribuyen al éxito de una persona. Y yo no

podría haber elegido unos mejores de los que rodearme. ¡Gracias familia y amigos!

A mis tutores Juan Carlos Trujillo Mondéjar y Alejandro Maté Morga, gracias por su gran

apoyo y guía tanto en el ámbito académico y profesional como en el personal. Ha sido un

verdadero placer trabajar a vuestro lado y poder contar con vuestra ayuda y experiencia.

Además, agradezco a la empresa Lucentia Lab, Spin-off de la Universidad de Alicante,

la oportunidad que me dio de testear los avances del proyecto en datos y casos reales, lo

que ha sido no sólo enriquecedor sino el punto de partida de mis investigaciones actuales.

Las investigaciones de este trabajo de fin de máster están encuadradas en el proyecto de

investigación GEODAS-BI (Gestión para el Desarrollo Global de Software mediante

Inteligencia de Negocio) TIN2012-37493-C03-03 y, más concretamente en la realización

del estado del arte en cuanto a técnicas de visualización y, la exploración de técnicas y

herramientas disponibles.

Página 3 de 55

Índice de contenidos

Prefacio ......................................................................................................................................... 4

1. Marco teórico ....................................................................................................................... 6

1.1. Los datos........................................................................................................................ 6

1.2. Big Data ......................................................................................................................... 8

1.3. Generación de datos ................................................................................................... 11

1.4. Open Data ................................................................................................................... 12

1.5. Smart Cities ................................................................................................................. 15

2. Entorno y herramientas utilizadas ..................................................................................... 23

2.1. Apache Spark ............................................................................................................... 23

2.2. Apache Zeppelin .......................................................................................................... 27

2.3. Plotly ............................................................................................................................ 28

3. Desarrollo del sistema ........................................................................................................ 29

3.1. Análisis del contexto estratégico ................................................................................ 29

3.2. Fuentes de datos ......................................................................................................... 31

3.3. Búsqueda de KPIs ........................................................................................................ 35

3.4. Diseño de los procesos ................................................................................................ 37

4. Discusión y análisis ............................................................................................................. 41

5. Perspectivas Futuras ........................................................................................................... 49

6. Conclusiones ....................................................................................................................... 50

Referencias bibliográficas .......................................................................................................... 52

Página 4 de 55

Prefacio

Este documento se presenta como resultado de la investigación y el desarrollo realizado

al final del Máster Universitario en Ingeniería Informática impartido en la Universidad

de Alicante. La motivación para el desarrollo del presente proyecto viene suscitada por el

continuo incremento del uso de datos para tomar decisiones estrategias, en concreto, se

ha querido destacar las oportunidades que ofrece el uso de datos abiertos tanto para los

organismos que los publican como para quienes se nutren de ellos para aplicarlos en sus

propios ámbitos.

El proyecto ha sido realizado bajo la supervisión, seguimiento y evaluación del

Catedrático de Universidad D. Juan Carlos Trujillo Mondejar y Alejandro Maté Morga,

Doctor en Informática por la Universidad de Alicante.

El objetivo fundamental del trabajo consiste en demostrar la aplicabilidad de las técnicas

de Big Data sobre conjuntos de datos abiertos para mejorar de la toma de decisiones y

descubrir nuevos valores. Para ello se utilizarán datos procedentes de la ciudad de San

Francisco (EE. UU.). Los conjuntos de datos aislados se relacionarán entre sí con el

objetivo de encontrar indicadores (KPIs, Key Performance Indicators) que ayuden a

tomar decisiones en situaciones de emergencia y así demostrar el valor aportado para las

ciudades que ofrecen datos abiertos. Encontrar los KPIs correctos es una tarea compleja

incluso cuando se trata con expertos en sus sectores. Elegir indicadores incorrectos o una

interpretación errónea de estos puede traer efectos muy perjudiciales. Es por eso por lo

que se ha buscado crear una metodología donde el usuario final de la aplicación sea capaz

de describir una serie de objetivos concretos sin necesidad de tener conocimientos

técnicos, y estos se conviertan en KPIs perfectamente cuantificables que midan el nivel

de alcance.

En concreto, para desarrollar el proyecto fue necesario un análisis DAFO sobre ciudades

inteligentes que están comenzando a utilizar sus datos para mejorar. Se ha aplicado un

modelado de objetivos con la finalidad de que los propios usuarios finales sean capaces

de transmitir sus necesidades a los desarrolladores. Una vez el modelado ha sido validado,

se han aplicado técnicas de procesamiento y visualización de grandes cantidades de datos

obteniendo una serie de visualizaciones e indicadores con los que el usuario podrá

monitorear su progreso.

Página 5 de 55

Una dificultad añadida de este trabajo es la visualización, al trabajar con Big Data nos

enfrentamos con varios retos. En la realización de estos procesos se encuentran

dificultades como la representación de grandes cantidades de datos, las herramientas no

eran capaces de representar tal cantidad de datos en las gráficas de manera individual por

lo que se han tenido que aplicar algoritmos para agrupar los valores y poder representarlos

de forma agregada.

Por otra parte, en el desarrollo de este proyecto no se ha contado con una comunicación

directa con los usuarios finales de la aplicación, por lo que se ha llevado a cabo una serie

de encuestas sobre usuarios de distintos sectores y niveles de conocimiento técnico con

las que se han definido y validado los objetivos planteados en el diseño.

Página 6 de 55

1. Marco teórico

1.1. Los datos

Durante los últimos años las cantidades de datos generados por dispositivos o sistemas

utilizados en nuestro día a día han crecido exponencialmente. Debido a la ingente

cantidad de información generada resulta imposible para los analistas el procesarla de

forma manual. En otro momento, el procesamiento de grandes cantidades de datos fue

una tarea compleja y costosa, pero, las capacidades de almacenamiento y procesamiento

han aumentado y los costes han disminuido, dando lugar a un nuevo escenario donde es

viable y rentable procesar y analizar grandes cantidades de datos.

Pero exactamente, ¿Qué son los datos? ¿Cómo se generan? ¿Cómo se puede extraer valor

de ellos? Como se ha comentado en el apartado anterior, con este trabajo se pretende

demostrar la aplicabilidad de técnicas de Big Data sobre conjuntos de datos abiertos,

trabajando sobre datos los cuales individualmente no generan gran valor, pero que, en

conjunto, procesados y visualizados de forma correcta pueden aportar muchas ventajas a

los usuarios para mejorar la toma de decisiones y descubrir nuevos valores.

Hoy en día, prácticamente todo lo que hacemos genera datos y cada vez va aumentando

más la velocidad en la que estos se generan. Los datos se encuentran en todas partes, cada

segundo se generan millones. Pueden extraerse de la comunicación entre dispositivos, de

la interacción del ser humano con máquinas, pueden ser generados por diferentes tipos de

sensores, por observatorios meteorológicos, mercados financieros, se puede analizar la

información generada en redes sociales e Internet, etc. En Internet se generan muchos

datos y el tráfico crece a un ritmo desmesurado. La Figura 1 representa el tráfico

generado en un minuto mediante el uso de distintos medios digitales.

Página 7 de 55

Figura 1. Tráfico generado en un minuto. Fuente: www.domo.com

Cada día se crean 2.5 trillones de bytes de datos, y el 90% de los datos que existen hoy

en día se han creado en los últimos dos años [1]. Es humanamente imposible analizar y

extraer valor de todos los datos que se generan. Por lo que es tan importante recoger datos,

como el proceso de análisis, donde se seleccionan los datos relevantes para los objetivos

que se quieren conseguir y se comprueba que los datos recogidos contengan información

veraz ya que cantidad no siempre significa calidad.

Extrayendo información de los datos se puede mejorar en muchos aspectos. Los

economistas calculan que las ganancias por la eficiencia que permiten los datos podrían

sumarle más de 15 billones de dólares al PIB global para el 2030 [2], lo que representa

un impulso significativo para la economía mundial. Pero también permiten mejorar la

calidad de vida individual de las personas, por ejemplo, reduciendo los tiempos de

transporte o aumentado la efectividad de los servicios de emergencia. Los datos se están

convirtiendo en nuevos productos capaces de ofrecer soluciones e innovaciones en todos

los niveles.

Página 8 de 55

1.2. Big Data

Con el objetivo de resolver las dificultades que surgen al administrar y analizar cantidades

masivas de datos surgen herramientas adicionales, es el momento cuando nace la

tecnología emergente del Big Data.

Para definir el Big Data se han desarrollado varias definiciones a lo largo del tiempo, en

general, se refiere a la capacidad de administrar un gran volumen de datos heterogéneos

para permitir a los usuarios analizar los datos procesados y extraer decisiones [3]. [1], [4]

y [5] lo definen como conjuntos de datos que en su tamaño sobrepasan la habilidad de las

herramientas de bases de datos convencionales para capturar, almacenar, administrar y

analizar datos en un tiempo razonable. También incluye masas de datos no estructurados

que necesitan analizarse en tiempo real, y proporciona nuevas oportunidades para el

descubrimiento de nuevos valores, ayudando a un entendimiento más profundo de los

valores ocultos y permitiendo iniciarse en nuevos desafíos [6].

En el contexto del mundo empresarial [7] lo define como la capacidad de reunir una gran

variedad de datos, tanto de clientes actuales como antiguos para obtener conocimiento

útil para predecir el comportamiento de los clientes y ayudar a la toma de decisiones,

permitiendo retener clientes valiosos. Y [8] resalta la capacidad del análisis de Big Data

para maximizar el valor del negocio empresarial, transformando datos brutos en

información útil y de uso generalizado para toda la empresa.

Por otra parte, [9] introduce el concepto de la computación en la nube, las nuevas

arquitecturas de computación en la nube permiten un procesado de datos más eficiente y

económico, dependiendo de las necesidades analíticas y de las características de los

conjuntos de datos se puede contemplar la opción de construir el sistema en la nube. El

uso de estas tecnologías permitirá al usuario disponer de gran capacidad de computación

sin la necesidad de adquirir nuevas máquinas y teniendo la posibilidad de usarlas solo

cuando las necesite.

Por último, [10] se trata de un estudio reciente donde reúne distintas definiciones de Big

Data de investigaciones anteriores y tras estudiarlas lo define como la capacidad de

almacenar, procesar y analizar gran cantidad de datos en diversos formatos, y extraer

información significativa para los usuarios que les permita descubrir nuevos valores y

perspectivas.

Página 9 de 55

En definitiva, según lo establecido en la literatura científica, para este contexto se podría

definir el Big Data como, la forma de afrontar el procesamiento o análisis de grandes

volúmenes de información que por su naturaleza no pueden ser analizados en un tiempo

aceptable usando procesos y herramientas tradicionales, con el objetivo de extraer

información de valor para los usuarios que les permita descubrir nuevos valores y les

ayude en la toma de decisiones.

Pero para que estos datos sean considerados Big Data tienen que cumplir una serie de

características denominadas las V’s del Big Data, en concreto, según [11], deben poseer

al menos dos de las tres principales (volumen, velocidad y variedad). Estas características

han ido evolucionando conforme ha evolucionado esta tecnología, comenzaron siendo 3

y en la actualidad se habla de las 7 V’s. Como se define en [12] - [15], estas son las 7V’s,

volumen, velocidad, variedad, veracidad, valor, viabilidad y visualización.

• El volumen hace referencia a la cantidad de datos generados y almacenados para su

posterior análisis.

• La velocidad se refiere a la rapidez con la que se generan, se distribuyen y se procesan

los datos. Existen datos que se generan en streaming, es decir, se originan y se

distribuyen en tiempo real y en ocasiones también tienen que ser procesados en tiempo

real, como, por ejemplo, datos procedentes de redes sociales o sensores.

• La variedad envuelve las distintas formas, tipos y fuentes en las que se generan los

datos. Los datos a analizar pueden ser estructurados y fáciles de gestionar como una

base de datos, o no estructurados como documentos de texto, audios, videos,

imágenes, hasta publicaciones de redes sociales, secuencias de clics realizados sobre

una página web, etc.

• La veracidad representa el grado de confianza de los datos a analizar. Unos datos

incorrectos o mal interpretados pueden llevar a tomar decisiones incorrectas.

• El valor mide la utilidad de los datos seleccionados para la toma de decisiones. Se

tiene que conocer qué valor van a proporcionar las fuentes de datos poniendo de

manifiesto la dificultad para conocer y evaluar dicha utilidad a priori.

• La viabilidad es la capacidad que tienen las compañías en generar uso eficaz del

volumen de datos que manejan. Se deben analizar las fuentes y seleccionar y

Página 10 de 55

monitorizar la información procesada con el fin de conocer mejor el entorno,

posicionamiento y diseñar estrategias eficaces.

• La visualización es el modo en el que los datos son representados. Una vez han sido

procesados, los datos han de ser representados visualmente de forma que sean legibles

y accesibles para encontrar patrones o claves ocultas en el tema a investigar.

Con el paso del tiempo se ha ido extendiendo el uso del Big Data como se pueden ver en

las gráficas representadas en la Figura 2. La cantidad de empresas que utilizan Big Data

pasó de un 17% en 2015 a un 53% en 2017, siendo las Telecomunicaciones y los servicios

financieros los sectores donde más es usada [16].

Figura 2. Gráficas del uso de Big Data. Fuente: www.forbes.com

Página 11 de 55

1.3. Generación de datos

Existe gran variedad de formas de generar y capturar datos para su posterior análisis. [17]

los define y agrupa en distintas categorías representadas en la Figura 3.

Figura 3. Lugares donde encontrar datos. Fuente: http://www.dataversity.net/

• Web y Redes Sociales: Datos extraídos de la navegación de los usuarios por webs,

búsquedas en Google o de la interacción con redes sociales como Facebook, Twitter,

etc.

• Comunicación entre máquinas: Utiliza dispositivos como sensores o medidores que

capturan algún evento y lo transmiten a otras aplicaciones que traducen estos eventos

en información que puede ser analizada. Se puede capturar información referente a la

velocidad, temperatura, presión, variables meteorológicas, PH del agua,

parquímetros, etc. Estos datos son generados por el llamado “internet de las cosas

(IoT)”.

• Transacciones: Captura datos registrados en comunicaciones (llamadas, mensajería,

etc), en facturaciones (pagos con la tarjeta, pagos online, etc) o datos producidos en

las atenciones médicas.

• Biométricos: Información biométrica en la que se incluye huellas digitales,

reconocimiento facial, pulso, niveles de oxígeno en sangre, información genética, etc.

Los avances en la tecnología han aumentado enormemente los datos biométricos

Página 12 de 55

disponibles, hoy en día gran cantidad de móviles personales son capaces de leer

huellas, medir el pulso, el nivel de oxígeno en sangre, etc.

• Generados por personas: Las personas generan grandes cantidades de información

como grabaciones de voz en operadores de atención al cliente, emails, documentos de

papel, encuestas, etc. Hay que tener especial cuidado para ocultar la identidad de los

individuos.

Según el sistema que los genere los datos pueden ser encontrados con distinta naturaleza.

Pueden tener una estructura perfectamente definida, se pueden encontrar de manera no

estructurada o en una combinación de ambos [18].

Los datos estructurados tienen definidos perfectamente la longitud, el formato y el tamaño

de sus datos. Se almacenan normalmente en tablas de hojas de cálculo o en bases de datos

relacionales. Al contrario, los datos no estructurados no tienen un formato específico, se

almacenan en múltiples formatos como pueden ser archivos de texto, correos

electrónicos, archivos multimedia, tweets, etc. Los datos semiestructurados son una

mezcla entre los dos anteriores. No son representados en una estructura perfectamente

definida, pero sí tienen una organización definida en sus metadatos, algunos de estos

formatos son HTML, XML o JSON.

1.4. Open Data

Como se ha descrito, el proceso de aprovisionamiento de datos puede realizarse con

fuentes muy diversas, otra forma de obtener datos para su procesamiento es mediante

plataformas de Open Data. La forma de operar sobre ellos es la misma, pero cuando se

obtienen de una plataforma de datos abiertos no se tienen límites de utilización o

publicación. Open Knowledge International propone una definición [19] para los datos

abiertos como “aquellos que pueden ser libremente usados, modificados y compartidos

con cualquier persona y para cualquier propósito”.

Estos datos abiertos pueden ser publicados en cualquier formato y por cualquier

organismo, por lo que no siempre se encuentran datos con buena calidad, es por eso por

lo que varios estudios han definido una serie de características a tener en cuenta para

determinar la calidad y la evolución de los portales de Open Data. [20], [21] y [22]

definen éstas como:

Página 13 de 55

• Accesibles fácilmente a través de internet y de forma gratuita.

• Apertura, licencias abiertas o pertenecer directamente al dominio público.

• Reutilización mediante formatos abiertos y legibles por máquinas.

• Exactitud de los datos respecto a cada una de las entidades a las que representan en

el mundo real.

• Consistencia de los datos y ausencia de contradicciones, siendo coherentes respecto

a los otros datos existentes en el mismo contexto de uso.

• Garantía de disponibilidad, tanto en un momento puntual, como a lo largo de amplios

periodos de tiempo y de forma indefinida.

• Completitud de los datos en cuanto a todos los atributos esperados para la entidad

que está siendo representada

• Conformidad respecto a los estándares, reglas, convenciones y normativas de

referencia establecidos para la captura y publicación de los datos.

• Credibilidad de las fuentes de información utilizadas, garantizando además la

veracidad respecto al origen de los datos y su trazabilidad.

• Precisión de los datos disponibles con los niveles de detalle y granularidad adecuados

para ser relevantes en el área de conocimiento de la que tratan.

• Actualidad de los datos, reflejando el estado actual de los mismos y estando

disponibles a tiempo y sin retrasos que afecten a su relevancia.

• Comprensibilidad, expresando los datos de forma que se puedan interpretar

inequívocamente a través de los metadatos y documentación disponibles.

También se ha creado una norma, la ISO/IEC 25012 [23], que establece una serie de

características de calidad de datos que se deben de tener en cuenta a la hora de evaluar la

calidad de un conjunto de datos. O el estudio [24], el cual realiza una comparación entre

las características de calidad de almacenes de datos propuestas en diferentes

publicaciones.

Otra forma de clasificar los portales de Open Data es según su capacidad de reutilización.

Tim Berners-Lee, el definió en 2006 un modelo de calidad [25] para medir la capacidad

de reutilización de los datos abiertos, llamado modelo cinco estrellas. Este modelo

establece cinco niveles de calidad, representados en la Figura 4 y etiquetados con

estrellas según su adecuación al objetivo de ser reutilizados:

Página 14 de 55

Figura 4. Niveles de calidad de un portal Open Data. Fuente: http://5stardata.info/es/

Cada uno de los niveles representados corresponden a:

Tabla 1. Significado de los niveles de calidad de un portal Open Data.

★ Los datos están publicados con cualquier formato y bajo una licencia

abierta. Por ejemplo, pueden estar en un fichero PDF.

★★ Los datos están publicados en formatos estructurados. Por ejemplo, pueden

estar en CSV, XML, Excel, XLS, etc.

★★★ Los datos publicados están en formatos no propietarios. Por ejemplo,

usando CSV en lugar de Excel, para poder acceder a ellos con software no

propietario.

★★★★ Los datos publicados son accesibles vía URIs, para que puedan ser

fácilmente interpretables y consultados mediante clicks.

★★★★★ Los datos publicados son vinculados a otros datos para contextualizarlos y

enriquecerlos.

Página 15 de 55

1.5. Smart Cities

Este estudio se va a centrar en el sector de las ciudades inteligentes con el objetivo de

resaltar el valor que se le puede extraer a los datos generados en ellas. Como cualquier en

proyecto de Big Data es preciso capturar, almacenar, procesar y analizar gran cantidad de

datos procedentes de distintas fuentes para poder transformarlos en conocimiento útil.

Una Smart City [26] se trata de una ciudad donde mediante la colocación de dispositivos

y el análisis de la información recopilada se pueda optimizar los recursos de estas. El

objetivo es proveer a la ciudad de una infraestructura que garantice un desarrollo

sostenible, un incremento de la calidad de vida de los ciudadanos, una mayor eficacia de

los servicios y una participación ciudadana activa.

Este escenario supone una revolución tecnológica, con potencial como para dinamizar

una nueva industria y generar numerosas oportunidades de negocio. El Big Data tiene un

papel fundamental en el desarrollo de las ciudades inteligentes ya que según Naciones

Unidas [27] para el 2050 se prevé que el 70% de la población mundial viva en entornos

urbanos. Pese a ocupar sólo el 2% del territorio del planeta las ciudades representan entre

el 60% y el 80% del consumo energético mundial y generan el 70% de las emisiones de

gases de efecto invernadero. Esto supone que los datos a procesar van a crecer

exponencialmente y la importancia de estos también se incrementará. Será necesario el

Big Data para la gestión de recursos y la provisión de servicios tan importantes como la

seguridad, el transporte y el abastecimiento de agua y energía.

Los datos de las ciudades son considerados Big Data ya que son grandes cantidades de

información (Volumen), los datos provienen de distintas fuentes, algunas de ellas no

estructuradas (Variedad), provienen de fuentes fiables (Veracidad), que se generan y se

tienen que procesar en tiempo real para ayudar a tomar decisiones (Velocidad), existe

conocimiento de que los datos seleccionados proporcionan valor (Valor) y se tiene la

capacidad de procesar y analizar los datos capturados (Viabilidad), así como de

mostrarlos de manera que sea fácil de interpretar por los usuarios finales (Visualización).

Estos datos pueden ser obtenidos por distintos métodos [28], por ejemplo, mediante

cámaras y sensores repartidos por la ciudad, sensores que toman mediciones ambientales,

de la actividad de los ciudadanos en las redes sociales, datos de geolocalización a través

de aplicaciones móviles, de movilidad a través de las tarjetas de transporte público, datos

procedentes de llamadas a los servicios de emergencia, censos de población, registros

Página 16 de 55

médicos, impuestos, etc. Existen infinidad de fuentes de donde se pueden extraer datos y

publicarlos de forma abierta, pero a la hora de publicarlos se ha de tener en cuenta la Ley

Orgánica de Protección de Datos [29]. Los datos publicados siempre han de ser anónimos,

bien anonimizándolos o bien presentándolos de forma agregada para que no se tenga

información individual de la persona a la que pertenecen.

El Big Data va a permitir recopilar toda esta información y procesarla para extraer valor

de las fuentes y bien representar la información de una forma visual y atractiva para los

usuarios o obtener patrones de comportamiento que permitan diseñar soluciones para

hacer más eficientes diferentes procesos de las ciudades de manera que se pueda ahorrar

energía, mejorar los servicios, la calidad de vida de los ciudadanos o ser menos

contaminantes, entre otras cosas. [30] enumera los distintos ámbitos y propone ejemplos

en los que se podría aplicar iniciativas para convertir una ciudad en ciudad inteligente. La

Figura 5 representa los ámbitos gráficamente.

Figura 5. Ámbitos de una ciudad inteligente. Fuente: Elaboración propia.

Página 17 de 55

Gestión de la energía:

• Contadores inteligentes donde se recopilen datos sobre la demanda, permitiendo

prever picos de consumo y estar preparados para ellos, así como franjas con bajo

consumo, para que si se ha de cortar el suministro hacerlo en esas franjas.

• También se pueden fusionar estos datos con las de otras plataformas para facilitar su

predicción. Por ejemplo, usando datos de previsiones meteorológicas, sería posible

detectar una inminente ola de calor y que las compañías eléctricas estuvieran

preparadas para ajustar la producción a la demanda.

• Con la colocación de sensores se podría también controlar automáticamente la calidad

de los recursos, así como localizar posibles fugas o incidencias.

Edificios inteligentes:

• Iluminación de espacios públicos con farolas que ofrecen diferentes funciones como

recopilar información meteorológica, control de la contaminación del aire o

conectividad WiFi. Permitiendo así reducir los costes de mantenimiento y analizar

información en tiempo real sobre las condiciones climáticas y, en consecuencia,

regular la intensidad de la luz mediante la tecnología LED.

• Sistemas inteligentes en los edificios para controlar los equipos eléctricos y mecánicos

reduciendo los costes de mantenimiento y mejorando la seguridad.

Transporte:

• Mediante el análisis de datos procedentes de cámaras y sensores repartidos por la

ciudad se podría conseguir reducir los atascos o actuar sobre ellos de una manera

eficiente pudiendo redirigir la ruta de los transportes públicos o interactuar con la red

de semáforos para descongestionar la vía, así como informar a los ciudadanos de la

situación del tráfico e indicarle las rutas alternativas óptimas.

• Otro aspecto sería estudiar los movimientos de los ciudadanos por la ciudad y

aumentar los servicios de transporte público en las horas que más demanda exista.

Medio ambiente:

• La reducción y optimización de los tiempos de transporte logra mejoras en el medio

ambiente ya que se emite menos CO2.

Página 18 de 55

• Una mejor gestión de la energía permitirá ahorrar y mejorar el medio ambiente.

• Analizar las emisiones y controlarlas mediante el uso de diferentes tipos de

dispositivos.

Servicios urbanos:

• Con la colocación de sensores en los contenedores se podrán enviar datos relativos a

su capacidad y así poder definir rutas óptimas de recogida de basura. Así como

combinar estos datos con otros procedentes de las redes sociales para identificar

quejas o sugerencia de ciudadanos sobre el estado de suciedad de ciertos puntos de la

ciudad.

• Mediante las redes sociales, centros de llamadas y otros sistemas, también se genera

la posibilidad de conocer la opinión de los ciudadanos y turistas sobre los servicios

de la ciudad en tiempo real, de manera que se pueda conocer qué servicios se necesitan

y en qué localizaciones.

Seguridad ciudadana:

• La reducción de los tiempos de transporte mejorará los tiempos de respuesta de los

servicios de emergencia, aumentando su efectividad.

• Recopilación y monitoreo de información para la prevención de los delitos a través

de la correlación de la información recopilada por los distintos sistemas instalados en

la ciudad como, cámaras de videovigilancia, geolocalización de coches de policía y

bomberos, sensores de movilidad, alarmas, detectores de humo y fuego, etc.

Sanidad y salud:

• Mejorar la toma de decisiones en tratamientos médicos mediante el estudio y análisis

de datos clínicos.

• Digitalización de la gestión de los hospitales y centros médicos haciéndola más

eficiente.

• Un transporte más rápido y eficiente permitirá reducir los tiempos de transporte en las

situaciones de emergencia aumentando la efectividad de estos servicios.

Página 19 de 55

Educación:

• Ofrecer una mejor planificación de forma personalizada para cada estudiante,

detectando situaciones de riesgo, desviaciones y consiguiendo reducir las tasas de

abandono y fracaso escolar.

Gobierno:

• Digitalización de la administración pública para optimizar los servicios y poder

ofrecerlos a través de internet.

• Fomentar la transparencia de los gobiernos publicando sus datos en portales de datos

abiertos.

Calidad de vida:

• Facilitar la difusión de información sobre actividades culturales y motivar a las

personas a involucrarse en ellas.

• Soluciones para proporcionar información sobre los principales lugares de interés en

una ciudad.

• Inclusión en los servicios y actividades a los ciudadanos de avanzada edad y personas

discapacitadas.

Pero para lograr este tipo de ventajas los gobiernos deben apostar por inversiones

tecnológicas y dales el uso y la importancia que requieren, en la actualidad, las

inversiones para convertir las ciudades en inteligentes están creciendo. Existen ciudades

tanto internacionales como nacionales que ya han realizado una gran inversión

tecnológica y que son consideradas Smart Cities. Varios estudios realizan evaluaciones

sobre como estas ciudades se están convirtiendo en ciudades inteligentes. El “IESE

Business School” realiza anualmente un estudio llamado “IESE Cities in Motion Index”

[31]. El ranking publicado en 2017 situó a Nueva York como líder y a San Francisco en

quito lugar. En el ámbito nacional, situó a Madrid en el puesto 28 y Barcelona en el 35.

Otra evaluación sobre ciudades inteligentes la realiza EasyPark [32] que sitúa a San

Francisco en el séptimo puesto.

Nueva York ha conseguido la primera posición de este ranking por su ambicioso plan

para expandir la conectividad entre su población, implantar tecnologías, promover la

innovación y favorecer un desarrollo sostenible. Este plan [33] apuesta por distintas

Página 20 de 55

medidas para ahorrar en recursos como energía y agua, reducir el impacto ambiental y

mejorar la calidad de vida de su población.

La primera ciudad española que se encuentra en la lista se trata de Madrid. Uno de los

proyectos más importantes que le ha llevado a alcanzar ese puesto es la plataforma MiNT

(Madrid iNTeligente) [34], un proyecto que se inició hace 4 años con la propuesta de un

nuevo sistema de gestión de servicios, mejorando la eficacia y calidad de estos, mejorando

los elementos urbanos cuanto a su eficiencia y sostenibilidad y desarrollando nuevas

oportunidades de innovación, de desarrollo y económico entre otras cosas.

Pero este proyecto se ha decidido desarrollar sobre la ciudad estadounidense de San

Francisco. San Francisco es considerada cuna de la innovación y capital tecnológica de

Estados Unidos, en parte gracias a Silicon Valley [35]. Sus iniciativas están enfocadas

sobre todo a mejorar el sistema de transporte ya que hoy en día saturación del flujo de

transporte y el aumento de los vehículos personales son motivo de preocupación, y el

transporte urbano está bastante anticuado, es por lo que la ciudad está centrada en mejorar

este sistema.

En la actualidad, se han desarrollado varias aplicaciones para mejorar el transporte como

SFPark [36], esta muestra qué aparcamientos están disponibles en tiempo real, Routesy

[37] es una aplicación que ofrece rutas de transporte público, O Scoot [38], una nueva

forma de alquilar motos eléctricas para moverse por la ciudad. Todas ellas con un objetivo

común, ahorrar tiempo, dinero, y reducir emisiones de carbono. Pero aún tienen mucho

que mejorar en el transporte.

Su mayor fortaleza se ubica en el reciclaje de residuos. La ciudad ha logrado una tasa de

reciclaje de residuos del 80% y cuenta con aplicaciones como Recycle Where [39], la

cual dirige al usuario al punto de reciclaje más cercano para un artículo determinado.

También lidera el camino en muchas iniciativas de energía limpia y a todos los edificios

nuevos se les exige al menos 15% de espacio en el techo dedicado a paneles solares [40].

Las ideas innovadoras implementadas en la ciudad se extienden a todas las dimensiones

de una ciudad inteligente. Ya se trate de Big Data o WiFi gratuito, estrategias ecológicas

o innovaciones tecnológicas, todos están allanando el camino a las oportunidades en auge

y la habitabilidad floreciente en la capital de la innovación de San Francisco.

Es importante saber que se trabaja con una cuidad que se implica en la causa, que le va a

dar valor al trabajo realizado y lo va a tener en cuenta para incorporarlo a sus sistemas. A

Página 21 de 55

través del estudio realizado se puede decir que San Francisco es una ciudad idónea para

la incorporación del sistema realizado.

Otro de los puntos fuertes de la ciudad de San Francisco y otra de las razones por las que

ha sido elegida esta ciudad para la realización del estudio es su portal de Open Data. Este

portal, según “US City Open Data Census” [41] se encuentra entre los mejores portales

de Estados Unidos, tan solo superado por el de Austin.

Cabe resaltar la importancia de este portal de datos, ya que se trata del lugar de donde

este proyecto se va a nutrir para la realización del estudio. San Francisco abrió su portal

de datos abiertos DataSF [42] en 2009, en él se encuentran datos del gobierno local en un

formato accesible y actualizado. Es un portal que sigue creciendo y se encuentra

actualizado, hoy en día, a 28 de junio, cuenta con 469 [43] conjuntos de datos de

diferentes temáticas como, economía, transporte, seguridad, vecindarios, medio

ambiente, construcciones, infraestructuras y cultura.

Esto, además de su contribución a la transparencia, permite a los desarrolladores de

software crear aplicaciones para ayudar a los ciudadanos y visitantes a aprovechar al

máximo los recursos de la ciudad. The DataSF App Showcase [44] recoge algunas de

estas aplicaciones proporcionándoles un escaparate y permitiendo recibir comentarios o

sugerencias de los usuarios permitiendo conocer qué necesidades existen.

Más allá de simplemente abrir sus datos, se han implantado varias innovaciones sobre los

datos abiertos como el uso de una serie de normas para definir su estructura, permitiendo

que las aplicaciones ya creadas en una localidad se puedan reutilizar en otras localidades

o integrarlas en aplicaciones privada.

Los objetivos [45] que el portal se ha marcado a corto plazo son:

• Aumentar el número y la periodicidad en la que se actualizan conjuntos de datos

• Mejorar la usabilidad del portal

• Mejorar la calidad y la coherencia de los datos

• Permitir el uso de datos confidenciales habiéndolos protegido adecuadamente

• Apoyarse en los datos para la toma de decisiones

• Fomentar el uso de datos abiertos

Su misión [46] es potenciar el uso de datos y mediante la toma de decisiones apoyada en

los datos, transformar la forma en la que la ciudad funciona, mejorando procesos y

Página 22 de 55

servicios ofertados, para conducir a una mayor calidad de vida y trabajo para los

residentes, empleadores, empleados y visitantes de San Francisco.

Es un portal en el que el gobierno apuesta, se encuentra en continuo crecimiento y al que

el gobierno le va a seguir destinando recursos, por lo que las aplicaciones que se creen

usando sus datos no es probable que se queden obsoletas.

Página 23 de 55

2. Entorno y herramientas utilizadas

Hoy en día se cuenta con una gran variedad de herramientas de Big Data, y en ocasiones

puede ser complicado seleccionar cuál es la más adecuada para abordar un proyecto. El

estudio [47] publicado en Forbes, recopila cuales son las herramientas de Big Data más

populares. Según este, Spark, MapReduce y Yarn son las tres herramientas más populares

en la actualidad, más del 30% de los encuestados consideran que Spark es fundamental

para sus estrategias de análisis. Los métodos de acceso a Big Data preferidos son Spark

SQL, Hive, HDFS y Amazon S3. El 73% considera que Spark SQL es crítico para sus

estrategias de análisis. Por otra parte, el Machine Learning continúa ganando apoyo y la

librería de Spark MLib domina el sector

Para llevar a cabo este estudio se han utilizado herramientas como Apache Spark,

Apache Zeppelin o Plotly. A continuación, se va a especificar para qué sirven, se van a

comparar con otras herramientas y se va a determinar porque estas han sido seleccionadas.

2.1. Apache Spark

Apache Spark [48] nace en la Universidad de California, en Berkely. Está orientado a la

velocidad, facilidad de uso, y capacidades avanzadas de analítica. Proporciona interfaces

de programación en varios lenguajes de programación como Scala, Python, R y Java.

Se trata de una plataforma capaz de proporcionar potentes soluciones programadas de una

manera muy concisa y fluida. Es compatible con la computación en memoria, lo que le

permite consultar datos mucho más rápido en comparación con los motores basados en

disco, como Hadoop. Spark extiende el modelo MapReduce para hacerlo más rápido y

habilitar más escenarios de análisis, como por ejemplo consultas interactivas y

procesamiento de flujo en tiempo real [49].

Se ha elegido Apache Spark para la realización de este proyecto ya que aporta diferentes

ventajas a la hora de abordar proyectos de Big Data, alguna de sus características [50]

principales son:

- Velocidad de procesamiento: Apache Spark es capaz de ejecutar hasta 100 veces más

rápido aplicaciones ejecutadas en memoria y 10 veces más rápido cuando se ejecuta en

Página 24 de 55

disco que la que ofrece actualmente Hadoop MapReduce. Esto se debe principalmente a

la reducción de número de operaciones de lectura/escritura en el disco y al

almacenamiento de datos de procesamiento en memoria.

En la Figura 6 se puede observar como la diferencia en velocidad de procesamiento entre

Apache Spark y Hadoop.

Figura 6. Comparativa regresión logística entre Hadoop y Spark. Fuente: spark.apache.org

- Integración: Spark puede coexistir con una arquitectura de Big Data ya montada, se

puede ejecutar sobre Hadoop, Apache Mesos, en EC2, en modo clúster independiente o

en la nube. Además, Spark puede acceder a numerosas bases de datos como HDFS,

Cassandra, HBase o S3, el almacén de datos de Amazon.

- Herramientas para desarrolladores: Como se observa en la Figura 7, proporciona

una serie de herramientas que pueden ser utilizadas por los desarrolladores. Por ejemplo,

la librería MLlib para implementar soluciones de aprendizaje automático (machine

learning). GraphX, una API para el procesamiento de grafos. Spark Streaming, permite

el procesamiento de datos en tiempo real. O Spark SQL, la cual facilita la explotación de

datos a través del lenguaje SQL.

Figura 7. Librerías disponibles en Apache Spark. Fuente: spark.apache.org

- Facilidad de uso: Al contrario que Hadoop, el cual requiere usuarios con niveles

avanzados de programación y administración de sistemas, Spark cuenta con herramientas

y APIs en varios lenguajes de programación las cuales facilitan su uso permitiendo hacer

más viable el despliegue de nuevos proyectos de Big Data.

Página 25 de 55

- Escalabilidad: Spark permite ir incrementando el clúster a medida que se van

necesitando más recursos.

Por otra parte, Hadoop [51] es por excelencia la herramienta del Big Data. Utiliza

modelos de programación simples para el almacenamiento y procesamiento distribuido

de grandes conjuntos de datos en clusters, dando redundancia para no perder nada y, al

mismo tiempo, aprovechando muchos procesos a la vez. Dispone de un sistema de

archivos, HDFS [52] distribuido en cada nodo del cluster, y se basa en el proceso de

MapReduce [53] de dos fases. A continuación, en la Tabla 2 se realiza una comparación

entre Apache Spark y Hadoop MapReduce para resumir sus principales diferencias según

distintas características. Se representa en color verde la herramienta que mejor responde

en cada característica y en color amarillo cuando son similares.

Tabla 2. Comparación entre Apache Spark y Hadoop MapReduce.

Spark Hadoop MapReduce

Velocidad - Trabaja en memoria, por lo

que obtiene mayor velocidad

- Trabaja en disco, menos velocidad

de procesamiento

Capacidad - Depende de la memoria

RAM del dispositivo

- Puede trabajar con conjuntos de

datos mucho más grandes que Spark

Rendimiento - Su rendimiento puede verse

afectado por el uso de

aplicaciones pesadas

- Elimina los datos cuando no son

necesarios, por lo que no se produce

apenas pérdidas de rendimiento para

aplicaciones pesadas

Usabilidad - Fácil de usar gracias a sus

APIs

- Uso complejo

Funcionalidades - Procesar datos

- Procesar gráficos

- Machine learning

- Procesamiento en tiempo real

- Procesamiento por lotes

- Ideal para el procesamiento por

lotes

- Compatible con otras plataformas

para aumentar sus funcionalidades

Costes - Código abierto - Código abierto

Página 26 de 55

- Diseñado para funcionar

correctamente en hardware

básico

- Diseñado para funcionar

correctamente en hardware básico

Recursos - Necesita memoria RAM - Los recursos necesarios son

inferiores

Compatibilidad - Compatibles entre sí - Compatibles entre sí

Tolerancia a

fallos

- Si se bloquea un proceso en

medio de su ejecución tendría

que comenzar a procesar desde

el principio

- Como trabaja en disco, si se

bloquea un proceso en medio se

podría continuar donde se dejó

Seguridad - Spark necesita Hadoop

YARN para obtener beneficios

de seguridad

- Cuenta con una seguridad robusta

Como se ha podido observar cada uno domina en distintas áreas. Hadoop MapReduce se

recomienda para el procesamiento lineal, cuando se tengan conjuntos de datos

excesivamente grandes, y cuando la velocidad de procesamiento no sea una característica

crítica. Su uso es ideal cuando no se necesitan los resultados inmediatos, por ejemplo, si

los datos pueden ser procesados durante la noche y visualizar los resultados a la mañana

siguiente.

Por su parte, Spark es útil cuando se necesita la información de forma inmediata ya que

ofrece una gran velocidad de procesamiento. También es recomendable su uso para el

procesamiento iterativo, cuando se necesitan procesar los datos una y otra vez. La edición

de 2014 Daytona Gray Sort Benchmark [54] se trata de un ejemplo donde se puede

comprobar el potencial de Spark. Este consiguió procesar 100 TB de datos 3 veces más

rápido de Hadoop MapReduce con una décima parte de máquinas.

En conclusión, dependiendo de los recursos disponibles y de la finalidad del análisis se

necesitará un tipo de software u otro. Teniendo en cuenta también la posibilidad de

combinar ambos.

Para el escenario desarrollado en este proyecto la herramienta más apropiada es Apache

Spark, ya que, con los recursos que se disponía era viable abordar el conjunto de datos

seleccionado. También porque estos datos iban a ser actualizados periódicamente y

Página 27 de 55

porque es la plataforma que más facilidades de uso aporta para las necesidades del

proyecto.

2.2. Apache Zeppelin

Se ha utilizado Apache Zeppelin [55] como intérprete de Spark. Apache Zeppelin se trata

de un entorno web en formato notebook que permite el análisis interactivo de datos, así

como su visualización mediante lenguajes y tecnologías como Spark, Python, Scala,

Spark SQL, JDBC, Markdown y Shell entre otras.

Apache Zeppelin ofrece diversas ventajas como:

• Gran disponibilidad de plugins e intérpretes para poder programar en distintos

lenguajes.

• Manejo de una forma muy intuitiva conexiones de datos con diversas fuentes

como Hive o HBase. También con SQL más tradicional como PostgreSQL o

MySQL.

• Soporte total para compartir y colaborar. Permite crear notebooks

colaborativos en los que los cambios realizados se transmiten en tiempo real.

• Capacidad de importar y exportar notas de una manera muy sencilla.

• Visualización de los datos simple e intuitiva directamente en la aplicación con

posibilidad de exportarlos.

• Gráficos dinámicos con múltiples valores agregados.

• Gratuita y de código abierto.

• Comunidad de usuarios muy activa.

Lo que hace que Apache Zeppelin sea interesante para este proyecto es su gran potencia

y la sencillez con la que ofrece una versión inicial de la visualización de los datos donde

se pueden extraer las primeras conclusiones. Es de mucha utilidad ofrecer a los usuarios

una versión inicial donde estos puedan interactuar con el sistema y explorar los datos

permitiendo descubrir los puntos claves y, a continuación, poder realizar una versión más

robusta con un desarrollo más profundo de los puntos marcados como clave.

Página 28 de 55

2.3. Plotly

Apache Zeppelin permite una representación gráfica básica de los datos. Para crear

visualizaciones más completas e interesantes se ha decidido utilizar Plotly.

Plotly es una herramienta para la creación de gráficas y analíticas interactivas, cuenta

bibliotecas gratuitas y open source para Python, R, MATLAB, Perl, Julia, Arduino, y

REST entre otros [56]. También ofrece un servicio web para hospedar y compartir

gráficas. Estas pueden ser publicadas bajo tres tipos de privacidad [57]:

• Público: Cualquiera puede ver el gráfico, aparecerá en el perfil del creador y

también podrá aparecer en búsquedas. No es necesario iniciar sesión en la

plataforma para verlos.

• Privado: Sólo el creador puede ver el gráfico. No aparecerá en las búsquedas y

para que alguien pueda verlo deberá haberlo compartido con la cuenta de esa

persona, por lo que deberán haber iniciado sesión para poder verlo.

• Secreto: Cualquier persona con el enlace puede ver el gráfico. No aparecerá en

las búsquedas, pero si está incrustado dentro de una página web o un notebook,

será visible. No se necesita que se inicie sesión para verlo.

Los gráficos se guardarán dentro de la cuenta del creador donde se podrá controlar su

privacidad. El alojamiento público es gratuito, pero para hacer los gráficos privados o

secretos se deberá contratar un plan de pago.

Página 29 de 55

3. Desarrollo del sistema

El desarrollo de sistemas para procesar y analizar grandes conjuntos de datos es usado en

muchos sectores y se ha convertido en una herramienta imprescindible para poder sacar

la mayor rentabilidad a los recursos. En este proyecto se ha analizado el escenario donde

se va a implantar el sistema mediante el estudio de la literatura, se han analizado las

herramientas disponibles para seleccionar las más apropiadas para este caso y se ha

llevado a cabo un análisis del contexto estratégico y el desarrollo del sistema, los cuales

se van a exponer el en presente apartado.

Se ha buscado crear una metodología donde el usuario final de la aplicación sea capaz de

describir una serie de objetivos concretos sin necesidad de tener conocimientos técnicos,

y estos se conviertan en indicadores perfectamente cuantificables que midan el nivel de

alcance de los objetivos. Esto se ha realizado a partir de un modelado de objetivos

mediante el Business Intelligence Model (BIM). Se han seleccionado las fuentes de las

que se va a nutrir el sistema para crear los indicadores y se ha llevado a cabo el

procesamiento y visualización de los grandes conjuntos de datos mediante el uso de las

herramientas mencionadas con anterioridad. Estos conjuntos de visualizaciones serán

presentados a los usuarios para que los guíen en la toma de decisiones y les ayudan a

mejorar sus procesos.

3.1. Análisis del contexto estratégico

Se ha comenzado llevando a cabo un análisis del contexto estratégico de las Smart Cities

mediante un análisis DAFO [58] [59]. Se trata de una herramienta que permite conocer

la situación real en que se encuentra una organización, empresa, o proyecto analizando

sus características internas y su situación externa y permitiendo planear una estrategia de

futuro.

Debilidades

• Gestión de activos (mantenimiento de sensores y dispositivos)

• Dificultad de definir una hoja de ruta ya que no se sabe cómo evolucionarán las

tecnologías

• Desconocimiento de los beneficios de convertirse en ciudad inteligente

Página 30 de 55

• Falta de colaboración entre las distintas ciudades

• Cuestiones gerenciales y organizacionales

• Componente político, cambios de gobiernos que implican cambios en los planes

Fortalezas

• Gobernanza centrada en el ciudadano

• Agrega valor a los servicios y aumenta la eficiencia

• Innovación e integración tecnológica

• Objetivos y metas de estrategias Smart pueden proporcionar ventajas en el acceso

a fuentes de financiación

• Iniciativas y modelos fácilmente replicables a otras ciudades

• Comparación con ciudades tradicionales para medir su mejora

Amenazas

• Seguridad de la información (privacidad de datos)

• Intrusión de hackers en los sistemas

• Ausencia de normativas estandarizadas

• Inestabilidad presupuestaria

• Complejidad y fuertes condicionantes para el acceso a la financiación pública

Oportunidades

• Innovación y emprendimiento

• Oportunidades de negocio

• Oportunidades para crear aplicaciones que agreguen valor a la ciudad o

ciudadanos

• Definición de un modelo de colaboración entre las distintas ciudades inteligentes

• Contar con una ciudad avanzada tecnológicamente supone una importante ayuda

para el desarrollo tecnológico del resto de ciudades

Por lo tanto, como podemos ver, existe un amplio nicho a explotar en las ciudades

inteligentes. Teniendo los conocimientos y recursos necesarios se pueden aportar muchas

ventajas a las ciudades y ciudadanos. Usando los datos con una aproximación adecuada,

se les podrá dar valor y utilizarlos para conocer las necesidades de los ciudadanos,

impulsar la reducción de gatos y mejorar la eficiencia de los servicios entre otras cosas.

Página 31 de 55

3.2. Fuentes de datos

El conjunto de datos principal seleccionado para la realización del análisis ha sido el

listado de llamadas de emergencia relacionadas con avisos de fuego de la ciudad de San

Francisco. Más adelante se explicará cómo está compuesto este DataSet. Este análisis se

ha complementado con el conjunto de datos procedentes de incendios y el listado de

negocios registrados en la ciudad.

Se conoce que la ciudad de San Francisco no cuenta con una buena distribución del

transporte por lo que es habitual encontrarse con atascos. Según INRIX [60] San

Francisco se encuentra en quinta posición de las ciudades en las que más tiempo pasan

sus habitantes en atascos, pasando un total de 79 horas al año y estimando que esto se

traduce en un coste económico de unos 2.250$ a los conductores y unos 10,6 millones de

dólares a la ciudad añadiendo a su vez todas las complicaciones que conlleva tener las

carreteras saturadas y el tiempo perdido. Estas complicaciones están directamente

relacionadas con los servicios de emergencia, ya que, al encontrarse con las carreteras

congestionadas, el tiempo tardado en llegar a la ubicación de la emergencia puede verse

considerablemente afectado. Es por ello por lo que es de primordial importancia que las

localizaciones de los servicios de emergencia sean las adecuadas y que se elija la mejor

ruta para llegar a la escena, así como que disponga de un mayor tiempo de reacción.

Otras de las razones que ha llevado a la utilización de estos conjuntos de datos es porque,

como se ha comentado con antelación, la ciudad de San Francisco está concienciada en

la recolección y publicación de datos, cuenta con una página con gran cantidad de

conjuntos actualizados y con una sección donde los desarrolladores pueden publicar sus

trabajos realizados con los datos abiertos de San Francisco. No se prevé que el proyecto

se vaya a quedar obsoleto, tiene mucha capacidad de uso y expansión.

Página 32 de 55

El conjunto de datos principal seleccionado para el

análisis se trata de “Fire Department Calls for

Service” [61] el cual incluye información sobre las

llamadas de emergencia respondidas por el

departamento de bomberos de San Francisco. Este

DataSet se actualiza diariamente siendo el 28 de junio

de 2018 el último día en el que fue consultado, en ese

momento contaba con 4,69 millones de filas

repartidas en 34 columnas, obteniendo un peso de 1,7

GB. A continuación, se va a detallar la información

almacenada en las 34 columnas de este DataSet.

Tabla 3. Campos del DataSet utilizado.

Call Number Determina el número asignado por el centro de llamadas del

911 a la llamada representada en la fila.

Unit ID ID de la unidad.

Incident Number Número asignado por DEM Fire & Essential Services Group

al incidente de fuego.

Call Type Tipo de llamada.

Call Date Fecha en la que la llamada ha sido recibida por el 911.

Watch Date

Fecha en la que la llamada ha sido recibida por el 911, donde

un día empieza a las 8:00 AM y termina a las 8:00 AM del

día siguiente.

Received DtTm Fecha y hora en que la llamada ha sido recibida por el 911.

Entry DtTm Fecha y hora en la que el operador introduce la información

de la llamada al sistema.

Dispatch DtTm Fecha y hora en que la llamada ha sido atendida por un

operador del 911.

Response DtTm

Fecha y hora en que la unidad confirma el aviso y registra

que la unidad está en camino hacia la ubicación de la

llamada.

On Scene DtTm Fecha y hora en que la unidad registra que ha llegado a la

ubicación del incidente.

Figura 8. SF Fire Department.

Fuente: www.wikipedia.org

Página 33 de 55

Transport DtTm Si la unidad es una ambulancia, la fecha y la hora en que

comienza el transporte al hospital.

Hospital DtTm Si la unidad es una ambulancia, la fecha y hora en que llega

al hospital.

Call Final Disposition

Código de la disposición final de la llamada, por ejemplo, si

se han trasladado al hospital, si ha sido resuelta por el

departamento de bomberos, si se ha cancelado, etc.

Available DtTm Fecha y hora en la que la unidad ya no está asignada a la

llamada y está disponible para otro aviso.

Address Dirección del incidente.

City Ciudad del incidente.

Zipcode of Incident Código postal del incidente.

Battalion Distrito responsable de cubrir la emergencia (hay 9).

Station Area Área de estaciones de bomberos asociada a la dirección del

incidente.

Box

Box asociado a la dirección del incidente. El box es el área

más pequeña que se usa para dividir la ciudad, y cada uno

está asociado a una única unidad.

Original Priority Prioridad inicial de la llamada. (2: No emergencia, 3:

Emergencia)

Priority Prioridad de la llamada.

Final Priority Prioridad final de la llamada.

ALS Unit Indica si la unidad tiene recursos ALS (Advance Life

Support)

Call Type Group Tipo de llamada dividido en: Incendio, Alarma, Amenaza de

vida y Sin amenaza de vida.

Number of Alarms Número de alarmas asociadas con el incidente. Número

entre 1 y 5.

Unit Type Tipo de la unidad desplazada al incidente.

Página 34 de 55

Unit sequence in call

dispatch

Un número que indica el orden en que se asignó esta unidad

a la llamada.

Fire Prevention

District

Oficina del Distrito de Prevención de Incendios asociada

con la dirección.

Supervisor District Supervisor del distrito asociado con la dirección.

Neighborhooods -

Analysis Boundaries

Barrio asociado con la dirección.

Location Coordenadas de la dirección del incidente.

RowID Número único asignado a cada fila.

Los campos “Address” y “Location” están asociados a una intersección de calles

aproximada para proteger la privacidad del usuario que realizó la llamada.

Este ha sido el conjunto de datos principal, pero, con el objetivo de obtener un análisis

más completo y demostrar las posibilidades analíticas que ofrece la fusión de distintos

conjuntos de datos, se han utilizado también los datos procedentes de los siguientes

conjuntos de datos.

El conjunto de datos de “Fire incidents” [62], el cual recoge los datos de los incendios

ocurridos en la ciudad, almacena un resumen de cada incidente al cual asistió el

departamento de bomberos, incluyendo datos como la localización, tiempos en llegar al

lugar y dar por finalizada la intervención, la unidad encargada de atender el incidente, así

como información acerca de las causas y las acciones tomadas, si existía algún método

de prevención de incendios, si este ha sido provocado o un accidente, entre muchas otras

cosas. Este DataSet se actualiza diariamente y a día 28 de junio de 2018 contaba con 466

mil filas repartidas en 63 columnas, obteniendo un peso de 166 MB.

Y, por último, para completar el análisis, se ha utilizado el conjunto de datos que recoge

información sobre los negocios registrados en San Francisco “Registered Business

Locations” [63], del que se ha utilizado las coordenadas de los negocios, para saber en

qué localizaciones estaban más concentrados. Este DataSet se actualiza semanalmente, y

a día 28 de junio de 2018 contaba con 222 mil filas repartidas en 26 columnas, obteniendo

un peso de 59 MB.

Página 35 de 55

3.3. Búsqueda de KPIs

Los KPIs (Indicadores Clave de Rendimiento) se tratan de métricas utilizadas para

cuantificar los resultados de determinada acción o estrategia en función de unos objetivos

estratégicos determinados. De acuerdo con [64] escoger los KPIs correctos es una tarea

compleja, ya que, aunque se trate con expertos en sus sectores se suele dudar acerca de

cuáles son los más adecuados, y elegir indicadores incorrectos puede traer efectos

perjudiciales a la organización. También es importante que exista una estrecha

comunicación entre los desarrolladores de las aplicaciones de monitoreo y los usuarios

finales, una mala interpretación de los indicadores puede traer grandes problemas.

Con el objetivo de minimizar estos problemas se ha aplicado un modelo de forma iterativa

para la representación de la estrategia. Para esta tarea se ha utilizado el Business

Intelligence Model (BIM) [65], que representa de una forma muy intuitiva relaciones

entre Objetivos (Goals), Procesos, Situaciones y KPIs y que ha sido probado en múltiples

casos de estudio en la literatura. Incluso existen herramientas que son capaces de traducir

estos diagramas en consultas reales sobre los datos [66].

Con este modelo se pretende que los usuarios finales sean capaces de validar los objetivos

propuestos, modificarlos, ampliarlos o eliminarlos según las necesidades que vayan

surgiendo. Se aplicará de la siguiente manera, en primer lugar, se definirán los objetivos

principales perseguidos por la organización, para cada uno de estos objetivos se asignará

un KPI para que lo cuantifique. A continuación, se refinarán los objetivos

descomponiéndolos en objetivos más simples. También serán utilizadas “Situaciones”,

las cuales representan factores tanto internos como externos que influyen en los objetivos.

Una vez el modelo haya sido validado se desarrollarán gráficas y cuadros de mando donde

el usuario pueda monitorear su progreso.

Debido a que no se ha tenido una relación directa con los usuarios finales de la aplicación,

se ha realizado una serie de encuestas sobre los objetivos propuestos a un grupo de

personas de distintos ámbitos. Se les ha pedido que se pusieran en la situación del

departamento de bomberos de San Francisco para que definieran y validaran una serie de

objetivos principales que ellos pensaran que necesitaran alcanzar. Analizando los

distintos modelos recogidos y aportando conocimiento en el procesamiento y

visualización de datos, se ha creado la Figura 9, la cual representa el conjunto de

Página 36 de 55

objetivos, KPIs y situaciones que se han propuesto para el escenario mediante el Business

Intelligence Model.

Figura 9. Modelo de objetivos. Fuente: Elaboración propia.

En este caso, como objetivo principal se ha propuesto reducir la magnitud de los

incendios. Para saber si se ha logrado este objetivo se medirá el número de incendios de

magnitud, de manera que se pueda saber si se ha alcanzado el objetivo de reducirlos.

Página 37 de 55

Para alcanzar este objetivo se propone reducir el tiempo de llegada al lugar de los hechos,

así como, identificar previamente si la llamada recibida por el centro de emergencias se

trata de un incendio o de otra emergencia. Con el objetivo de conocer si la llamada se

trata de un aviso de incendio se identificarán los meses, franja horaria y distritos con más

incendios.

Por otra parte, para reducir el tiempo de llegada al lugar de los hechos, se propone lanzar

un preaviso a las unidades para que estén preparadas, así como, mejorar la localización

de estas unidades, para que se sitúen donde puedan acceder rápido a los lugares donde

más probabilidad existe de que haya incendios.

Para ser capaz de lanzar un preaviso a las unidades se obtendrán datos acerca de la

localización y el tipo de llamada y se calculará la probabilidad de que la llamada sea

realmente un aviso de incendio por medio de las llamadas reales de incendio de esa

determinada localización, las llamadas reales de tipo incendio y las llamadas reales por

fecha.

3.4. Diseño de los procesos

Una vez seleccionadas las fuentes de datos y los objetivos han sido definidos y validados,

se han desarrollado una serie de procesos para llevar a cabo el procesamiento y

visualización de los datos. Estos procesos llevan a cabo la carga de datos en el sistema,

limpian los datos, los transforman y crean las más apropiadas visualizaciones.

Para el desarrollo de estos procesos se ha utilizado la herramienta Zeppelin, en ella se

puede de una manera sencilla y ágil, cargar los datos, transformarlos y visualizarlos. Para

ampliar la visualización ofrecida por Zeppelin y obtener unos resultados más completos,

se ha utilizado Plotly, la librería de Python.

A continuación, la Figura 10 representa un ejemplo de cómo sería un proceso

desarrollado en Zeppelin. En la Zona 1 se desarrollaría el código de programación en

alguno de los lenguajes que ofrece, en este caso se han desarrollado en Pyspark, una API

de Python para Spark. Una vez ejecutado el código, si no ha detectado ningún error, en la

Zona 2 se mostrará una tabla con los datos resultantes de la ejecución, pudiendo visualizar

en gráficas directamente estos datos, como se verá más adelante.

Página 38 de 55

La ejecución del ejemplo consiste en la carga de datos desde una fuente externa. Para

almacenar los datos se utilizan DataFrames. Un DataFrame es un conjunto de datos

organizados en columnas con nombre. Es similar a tabla de una base de datos relacional

pero orientado al procesamiento paralelo distribuido en memoria. Estos DataFrames se

pueden construir a partir de una amplia gama de fuentes. En este caso se han creado a

partir de los CSVs descargados de la página de Open Data de San Francisco.

Figura 10. Proceso en Zeppelin. Fuente: Elaboración propia.

Una vez los datos han sido cargados sobre el DataFrame, estos se pueden limpiar,

transformar o modificar conforme sea necesario para lograr alcanzar los objetivos

analíticos. La Figura 11, Figura 12 y Figura 13, se tratan de un ejemplo de una

visualización de un conjunto de datos, mediante el menú señalado en color rojo se puede

cambiar el tipo de visualización, ya sea en tabla de datos o en distintos tipos de gráficos.

Figura 11. Visualización datos Zeppelin. Fuente: Elaboración propia.

Zona 1

Zona 2

Página 39 de 55

Figura 12. Ejemplo de Gráfico de barras en Zeppelin. Fuente: Elaboración propia.

Figura 13. Ejemplo de Gráfico de sectores en Zeppelin. Fuente: Elaboración propia.

Algunas de las visualizaciones se realizarán directamente sobre Zeppelin y otras se

descargaron y serán visualizadas usando Plotly, como se ha comentado anteriormente.

Para esto habrá que descargar los datos mediante el botón marcado en rojo en la Figura

14, esto descargará un CSV que contendrá los datos transformados. Este CSV puede ser

utilizado para otros desarrollos y visualizaciones, en este caso se han utilizado para

realizar visualizaciones complementarias con Plotly.

Figura 14. Descarga de datos en Zeppelin. Fuente: Elaboración propia.

Al trabajar con Big Data se encuentran varios retos de visualización. Alguna de las

dificultades que se han encontrado en la realización de estos procesos, ha sido problemas

a la hora de representar grandes cantidades de datos, las herramientas no eran capaces de

representar tal cantidad de datos en las gráficas de manera individual, por lo que se han

aplicado algoritmos para agrupar los valores y poder representarlos de forma agregada.

Página 40 de 55

La Figura 15 representa uno de esos casos. En esta ocasión, se ha calculado la posición

media de las coordenadas de cada código postal, y se ha sumado el número de fuegos y

número de negocios registrado en cada código postal, de esta manera, se ha podido

representar un punto de tamaño proporcional al número de fuegos y negocios para cada

código postal de la ciudad.

Figura 15. Ejemplo visualización con Plotly. Fuente: Elaboración propia.

Para generar este tipo de visualizaciones más completas se ha programado en Python

utilizando la librería Plotly, al ejecutar el código, se abre un navegador web con la

dirección plot.ly en el que se generan las visualizaciones. Estas son guardadas

automáticamente en el perfil del usuario de plot.ly, creando un historial con las

visualizaciones generadas y pudiendo compartirlas con otros usuarios, así como

descargarlas o editarlas. Desde la interfaz web también se puede cambiar la privacidad de

estas.

Página 41 de 55

4. Discusión y análisis

Utilizando las herramientas previamente mencionadas y una vez se han tenido todos los

procesos desarrollados, se va a proceder a analizar los resultados obtenidos. Para

representar las visualizaciones se ha tomado como guía el modelo de objetivos

representado en la Figura 9 y se ha ampliado con otras visualizaciones que se han

considerado relevantes.

El objetivo del modelo (Figura 9) era reducir la magnitud de los incendios. Para llevar a

cabo este seguimiento se ha propuesto como KPI las medidas que registran el número de

plantas de edificios que han sufrido daño mínimo, significante, alto y extremo en los

incendios. Dando como resultado la gráfica representada en la Figura 16. Con el uso de

estas herramientas los usuarios podrán monitorear el impacto que tienen los incendios,

intentar buscar soluciones y descubrir si estas surgen efecto.

Figura 16. Daño por incendio en plantas de edificios. Fuente: Elaboración propia.

Para reducir la gravedad y el número de incendios se propuso en el modelo (Figura 9)

identificar la probabilidad de que haya incendios. Para esto, se han calculado los meses,

franjas horarias y distritos con más incendios. La Figura 17 representa el número de

incendios por meses donde se puede ver que octubre es el mes donde más incendios se

han registrado. En la zona señalada en rojo, el usuario puede hacer las combinaciones que

considere oportunas para adaptar el análisis a sus necesidades, podrá agrupar los

incendios por años, meses, días de la semana u horas, pudiendo también realizar

combinaciones entre ellos.

Página 42 de 55

Figura 17. Número de incendios por meses. Fuente: Elaboración propia.

Con la Figura 18 se puede conocer las horas en las que se producen más incendios, siendo

las 17 horas cuando más se recogen y las 5 de la mañana cuando menos.

Figura 18. Número de incendios por horas. Fuente: Elaboración propia.

A continuación, la Figura 19 agrupa el número de incendios registrados cada día de la

semana a cada hora.

Figura 19. Número de incendios por días de la semana y horas. Fuente: Elaboración propia.

Página 43 de 55

Por último, la Figura 20 representa los distritos donde se registran más incendios,

encontrando una clara masificación de incendios en los barrios de Tenderloin, Financial

District, Misson y South of Market, mientras que LincoIn Park, Seacliff, McLaren Park

y Treasure Island son las zonas donde menos incendios se registran.

Figura 20. Número de incendios por barrio. Fuente: Elaboración propia.

Haciendo uso de estas gráficas los usuarios podrán identificar los momentos y las

localizaciones donde hay más probabilidades de que ocurran incendios con el objetivo de

estar prevenidos y reforzar las unidades.

Otra de las medidas que propusieron en el modelo (Figura 9) para reducir la magnitud de

los indicios es reducir el tiempo de llegada de las unidades al lugar de los hechos. Para

medir este KPI se ha calculado el tiempo medio que pasa desde que la llamada ha sido

recibida por el centro de llamadas de emergencia, hasta que la unidad seleccionada llega

a lugar de los hechos. Estos datos serán monitoreados con la Figura 21, la visualización

se ha realizado de manera que se pueda agrupar por Battalion, Station Area o Box, estos

son los grupos de bomberos de la ciudad, de nivel más general a más individual. El

usuario de la aplicación podrá elegir la visualización que más se adapte a sus necesidades.

En estos ejemplos se ha utilizado Battalion como medida.

Figura 21. Tiempo medio en llegar a la escena por Battalion. Fuente: Elaboración propia.

Página 44 de 55

Para poder reducir el tiempo en llegar a la localización de los hechos se ha propuesto

mejorar la ubicación de las unidades y lanzar un preaviso a estas para que estén preparadas

si el aviso se confirma. Como se observa en la Figura 22, se ha utilizado el número de

llamadas atendidas por cada unidad a lo largo de los años para monitorear este KPI y ver

como evoluciona.

Figura 22. Número de llamadas atendidas por Battalion por año. Fuente: Elaboración propia.

Se puede observar una correlación entre el tiempo en llegar a la escena y el número de

llamadas atendidas por Battalion. Las unidades que más llamadas atienden, como por

ejemplo la “B03” también son las que más tiempo tardan en llegar al lugar de los hechos,

se puede comprobar observando la Figura 21 y la Figura 22.

Como se ha comentado, otro de los factores que se han encontrado determinantes para

reducir el tiempo de llegada de las unidades al lugar de los hechos es lanzarles un preaviso

para que estén alerta. Para poder saber cuándo lanzar ese preaviso se ha calculado la

probabilidad de que la llamada que recibe el centro de emergencia sea de un incendio, y

la probabilidad de que la unidad vaya a salir en acción.

La probabilidad de que la llamada entrante sea causada por un incendio se ha calculado

en la Figura 23. Esta figura representa el número total de llamadas que finalmente fueron

registradas como fuego, agrupadas por el tipo de llamada se les asignó inicialmente. De

lo que podemos extraer que cuando una llamada entra con tipo “Alarms” o “Structure

Fire” hay muchas posibilidades de que la llamada finalmente vaya a ser un incendio.

Figura 23. Número de llamadas que fueron de fuego, por el tipo de llamada. Fuente:

Elaboración propia.

Página 45 de 55

Otra forma de lanzar un preaviso a las unidades para que estas se ponga alerta es calcular

que probabilidad hay de que esa unidad vaya a salir a la acción. Para calcular esta medida

se ha de tomar en cuenta dos situaciones externas que afectan al objetivo, estas son la

localización del accidente y el tipo de llamada. Según la localización del incidente y el

tipo de llamada se necesitarán unos efectivos u otros. Para poder lanzar el preaviso

también se ha calculado la probabilidad de que la llamada sea real, es decir que finalmente

el aviso se convierta en una emergencia real. Ya que puede haber barrios o fechas en las

que se lancen más avisos por cierta razón y luego no sean reales. Entendemos por

llamadas “no reales” las que son duplicadas, las que la persona que dio el aviso se ha ido

cuando los efectivos llegan, cuando son imposibles de localizar o cuando han sido

canceladas. Las Figura 24, 25 y 26 representan respectivamente estas llamadas “no

reales” agrupándolas por el distrito de los hechos, el tipo de llamada que se indicó y el

día de la semana y la hora en las que se produjeron.

Figura 24. Llamadas no reales, por distrito. Fuente: Elaboración propia.

Figura 25. Llamadas no reales, por el tipo de llamada. Fuente: Elaboración propia.

Figura 26. Llamadas no reales, por día de la semana y hora. Fuente: Elaboración propia.

Página 46 de 55

Una vez han sido creadas todas las visualizaciones necesarias para el modelo de objetivos

(Figura 9), se han propuesto una serie de visualizaciones alternativas que se han

considerado de relevancia. La Figura 27 representa los nueve tipos de llamadas que más

se dan, siendo los incidentes médicos los que más se registran seguidos de estructuras en

fuego.

Figura 27. Número de llamadas por tipo TOP. Fuente: Elaboración propia.

Otra visualización creada es la Figura 28 que representa el número de llamadas agrupadas

por barrio y por tipo de llamada. Con esta representación se puede extraer que, por

ejemplo, en Tenderloin las llamadas que más se producen son las de incidentes médicos

seguido de estructuras en llamas y alarmas.

Figura 28. Número de llamadas por barrio y tipo de llamada. Fuente: Elaboración propia.

En la Figura 29 se puede visualizar el tipo de unidad más demandada en cada tipo de

llamada. Por ejemplo, en los incidentes médicos la unidad más demandada es el “Medic”

seguido de “Engine” mientras que en las estructuras en llamas los más demandados son

“Engine” seguido de “Truck” y “Chief”.

Figura 29. Número de llamadas por tipo de unidad y por tipo de llamada. Fuente: Elaboración

propia.

Página 47 de 55

La última visualización propuesta es la perteneciente a la Figura 30, en la que se

representa los fuegos y los negocios registrados en la ciudad de San Francisco. Con este

tipo de visualizaciones se puede extraer información gráficamente acerca de cuáles son

los lugares donde más incendios se registran y ver si tienen alguna relación con la cantidad

de negocios. Por ejemplo, en la localización señalada con la flecha roja se encuentra la

mayor masificación de incendios mientras que en la localización señalada con la flecha

azul es donde más negocios hay.

Figura 30. Mapa de SF representando incendios y negocios. Fuente: Elaboración propia.

Para concluir, después de analizar todas las visualizaciones se puede extraer varias

conclusiones. Por un lado, se pueden marcar las franjas donde más posibilidades hay de

que ocurra un incendio, siendo estos el mes de octubre y las 17 horas. Por otro lado,

Tenderloin es el barrio donde más incendios se han registrado. En este barrio, las llamadas

que más se producen son las de incidentes médicos seguido de estructuras en llamas.

Además, cuando una llamada entra con tipo “Alarms” o “Structure Fire” hay muchas

posibilidades de que la llamada finalmente vaya a ser un incendio. Por lo general, las

unidades que más llamadas reciben también son las que más tiempo tardan en llegar al

lugar de los hechos, como, por ejemplo, la unidad “B03”. Y, por último, que las unidades

Página 48 de 55

más demandadas cuando se trata de una estructura en llamas son las de “Engine” seguidas

de “Truck” y “Chief”.

Por último, mencionar que todas las visualizaciones se tratan de visualizaciones

dinámicas, donde de manera muy sencilla el usuario puede cambiar el tipo de gráfico y

ajustar alguno de los valores. Además, en el caso de necesitar nuevas visualizaciones,

estas se podrán crear de forma rápida y sencilla, al tener los datos limpios y cargados en

la aplicación.

Página 49 de 55

5. Perspectivas Futuras

La continuidad del proyecto se quiere enfocar de manera que todo el sistema se encuentre

automatizado. Se busca desarrollar un sistema que, dada una definición de objetivos por

los usuarios mediante un modelo, el sistema automáticamente cree las consultas sobre los

datos y genere las visualizaciones utilizando el mejor tipo representación según los tipos

de datos y el contexto. Por supuesto, los datos del sistema también serán actualizados de

forma automática cada cierto tiempo en función de los requerimientos de los usuarios.

Otro campo a expandir sería el uso de librerías de Machine Learning como puede ser

MLIB de Spark. Contando con los recursos hardware necesarios se podrían crear modelos

predictivos que se vayan mejorando a medida que se vayan cargando más datos y con

ellos predecir posibles situaciones de emergencia de forma automática. De manera que el

sistema, antes de que el telefonista atienda la llamada, pueda por ejemplo identificar por

medio de varios factores el nivel de emergencia y el tipo de unidades que se van a

necesitar y dar un preaviso a estas para que estén preparadas por si tienen que desplazarse.

Por otra parte, se podría fusionar estos datos con otros conjuntos de datos, como por

ejemplo procedentes de atascos en tiempo real, ya que, a lo mejor, una unidad que está

situada más lejos de la localización de la emergencia puede llegar antes al lugar de los

hechos debido a la situación de las carreteras. De este modo el aviso de emergencia sería

redirigido a la unidad que fuera a llegar antes al lugar de los hechos.

Sin embargo, para llevar a cabo todo este tipo de mejoras lo ideal sería tener primero un

feedback de los usuarios reales de la aplicación, estos serían los servicios de emergencia

de la ciudad de San Francisco. De esta manera, se podrían conocer cuáles son sus

necesidades reales y conocer con que limitaciones cuentan. Se pretende que estos usuarios

evalúen el proyecto y propongan nuevos indicadores o modifiquen los existentes para una

mayor adecuación a sus necesidades y así crear uno o varios cuadros de mandos adaptados

a las necesidades de cada puesto.

Página 50 de 55

6. Conclusiones

En el presente trabajo se ha llevado a llevado a cabo un estudio acerca de la aplicación de

Big Data sobre datos abiertos, en concreto se han utilizado conjuntos de datos procedentes

de los cuerpos de emergencia de la ciudad de San Francisco debido a su fuerte inversión

en la innovación tecnológica y su potente portal de datos abiertos.

Para la realización del proyecto se ha analizado el escenario donde se va a implantar el

sistema mediante un análisis bibliográfico. Se han analizado las herramientas disponibles

para seleccionar las más adecuadas. Se ha realizado un análisis DAFO sobre las Smart

Cities para conocer las debilidades, fortalezas, amenazas y oportunidades del sector y se

ha llevado a cabo el desarrollo del sistema. El sistema se compone de una serie de

procesos encargados de cargar, procesar y visualizar datos con el objetivo de crear una

serie de visualizaciones que puedan guiar a los usuarios en la toma de decisiones

estratégicas que les permita mejorar sus procesos y descubrir nuevos valores.

Cumpliendo con los objetivos planteados, se ha creado una metodología donde el usuario

final describe sus objetivos mediante el modelo Business Intelligence Model y estos son

transformados en KPIs perfectamente cuantificables que miden el nivel de alcance de

estos objetivos.

Las herramientas seleccionadas para el desarrollo han cumplido perfectamente las

expectativas, especialmente Apache Zeppelin, de la que se puede destacar su potencia y

facilidad de uso. Sin embargo, al trabajar con grandes cantidades de datos, se han tenido

ciertos problemas a la hora de procesar y visualizar datos. Los sistemas no tenían la

suficiente potencia para representar todos los puntos individualmente de manera que en

estos casos se han representado de forma agregada.

Resaltar, como se ha comentado anteriormente que, para llevar a cabo una adaptación

centrada en las necesidades reales de los usuarios, sería necesario obtener un feedback de

ellos, en este caso, los servicios de emergencia de la ciudad de San Francisco. De manera

que se puedan conocer cuáles son sus necesidades reales y conocer con que limitaciones

cuentan.

A raíz del análisis desarrollado se han podido extraer varias conclusiones. Por un lado, se

pueden marcar franjas donde más posibilidades hay de que ocurra un incendio, siendo

estas el mes de octubre y las 17 horas. Por otro lado, Tenderloin es el barrio donde más

Página 51 de 55

incendios se han registrado. En este barrio, las llamadas que más se producen son las de

incidentes médicos seguido de estructuras en llamas. Además, cuando una llamada entra

con tipo “Alarms” o “Structure Fire” hay muchas posibilidades de que la llamada

finalmente vaya a ser un incendio. Señalar que, por lo general, las unidades que más

llamadas atienden también son las que más tiempo tardan en llegar al lugar de los hechos.

Y, por último, que las unidades más demandadas cuando se trata de una estructura en

llamas son las de “Engine” seguidas de “Truck” y “Chief”.

Para concluir este trabajo, cabe señalar la necesidad de que las ciudades recopilen y

pongan a disposición datos suficientes para poder implantar este tipo de proyectos.

Página 52 de 55

Referencias bibliográficas

[1] YU, Shui, et al. Networking for big data: A survey. IEEE Communications Surveys & Tutorials, 2017, vol. 19, no 1, p. 531-549.

[2] Sizing the prize What’s the real value of AI for your business and how can you capitalise? [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://www.pwc.com/gx/en/issues/analytics/assets/pwc-ai-analysis-sizing-the-prize-report.pdf

[3] HURWITZ, Judith, et al. Big data for dummies. John Wiley & Sons, 2013.

[4] MANYIKA, James, et al. Big data: The next frontier for innovation, competition, and productivity. 2011.

[5] WU, Xindong, et al. Data mining with big data. IEEE transactions on knowledge and data engineering, 2014, vol. 26, no 1, p. 97-107.

[6] CHEN, Min; MAO, Shiwen; LIU, Yunhao. Big data: A survey. Mobile networks and applications, 2014, vol. 19, no 2, p. 171-209.

[7] SIMON, Phil. Too big to ignore: the business case for big data. John Wiley & Sons, 2013.

[8] WIXOM, Barbara H.; YEN, Bruce; RELICH, Michael. Maximizing Value from Business Analytics. MIS Quarterly Executive, 2013, vol. 12, no 2.

[9] HUDA, Miftachul, et al. Big data emerging technology: insights into innovative environment for online learning resources. International Journal of Emerging Technologies in Learning (iJET), 2018, vol. 13, no 1, p. 23-36.

[10] WANG, Yichuan; KUNG, LeeAnn; BYRD, Terry Anthony. Big data analytics: Understanding its capabilities and potential benefits for healthcare organizations. Technological Forecasting and Social Change, 2018, vol. 126, p. 3-13.

[11] GORODOV, Evgeniy Yur'evich; GUBAREV, Vasiliy Vasil'evich. Analytical review of data visualization methods in application to big data. Journal of Electrical and Computer Engineering, 2013, vol. 2013, p. 22.

[12] The 7 V’s of Big Data [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://impact.com/marketing-intelligence/7-vs-big-data/

[13] Understanding Big Data: The Seven V’s [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://dataconomy.com/2014/05/seven-vs-big-data/

[14] Las 7 V del Big data: Características más importantes [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://www.iic.uam.es/innovacion/big-data-caracteristicas-mas-importantes-7-v/

[15] UDDIN, Muhammad Fahim, et al. Seven V's of Big Data understanding Big Data to extract value. En American Society for Engineering Education (ASEE Zone 1), 2014 Zone 1 Conference of the. IEEE, 2014. p. 1-5.

[16] Big Data Executive Survey 2017 [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://newvantage.com/wp-content/uploads/2017/01/Big-Data-Executive-Survey-2017-Executive-Summary.pdf

[17] Not Your Type? Big Data Matchmaker On Five Data Types You Need To Explore Today. 2017 [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://www.dataversity.net/not-your-type-big-data-matchmaker-on-five-data-types-you-need-to-explore-today/

[18] WANG, Yichuan; KUNG, LeeAnn; BYRD, Terry Anthony. Big data analytics: Understanding its capabilities and potential benefits for healthcare organizations. Technological Forecasting and Social Change, 2018, vol. 126, p. 3-13.

Página 53 de 55

[19] The Open Definition [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://opendefinition.org/

[20] KUBLER, Sylvain, et al. Open data portal quality comparison using AHP. En Proceedings of the 17th International Digital Government Research Conference on Digital Government Research. ACM, 2016. p. 397-407.

[21] UMBRICH, Jürgen; NEUMAIER, Sebastian; POLLERES, Axel. Quality assessment and evolution of open data portals. En Future Internet of Things and Cloud (FiCloud), 2015 3rd International Conference on. IEEE, 2015. p. 404-411.

[22] Manual práctico para mejorar la calidad de los datos abiertos [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://datos.gob.es/sites/default/files/doc/file/manual_practico_para_mejorar_la_calidad_de_los_datos_abiertos_1.pdf

[23] ISO/IEC 25012 [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://iso25000.com/index.php/en/iso-25000-standards/iso-25012

[24] GONZÁLEZ, Arnulfo Napoleón Hernández. Características de Calidad de Datos de los Almacenes de Datos.

[25] Linked Data [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://www.w3.org/DesignIssues/LinkedData.html

[26] KITCHIN, Rob. The real-time city? Big data and smart urbanism. GeoJournal, 2014, vol. 79, no 1, p. 1-14.

[27] World Population Prospects: The 2017 Revision [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://esa.un.org/unpd/wpp/publications/Files/WPP2017_KeyFindings.pdf

[28] JIN, Jiong, et al. An information framework for creating a smart city through internet of things. IEEE Internet of Things journal, 2014, vol. 1, no 2, p. 112-121.

[29] Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://www.boe.es/buscar/doc.php?id=BOE-A-1999-23750

[30] NEIROTTI, Paolo, et al. Current trends in Smart City initiatives: Some stylised facts. Cities, 2014, vol. 38, p. 25-36.

[31] IESE Cities in Motion Index 2017 [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://www.iese.edu/research/pdfs/ST-0442-E.pdf

[32] 2017 Smart Cities Index [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://easyparkgroup.com/smart-cities-index/

[33] NYC smart city projects focus on user experience [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://internetofthingsagenda.techtarget.com/feature/NYC-smart-city-projects-focus-on-user-experience-transportation

[34] Madrid impulsa su modelo Smart City [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://www.madrid.es/portales/munimadrid/es/Inicio/Actualidad/Noticias/Madrid-impulsa-su-modelo-Smart-City?vgnextfmt=default&vgnextoid=a5d4ca08566a1410VgnVCM1000000b205a0aRCRD&vgnextchannel=a12149fa40ec9410VgnVCM100000171f5a0aRCRD

[35] San Francisco se destapa como la capital tecnológica del mundo [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://elpais.com/internacional/2013/04/26/actualidad/1366930791_855552.html

[36] SFpark [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://sfpark.org/

[37] Routesy [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://routesy.com/

[38] Scoot [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://scoot.co/

Página 54 de 55

[39] RecycleWhere [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://www.recyclewhere.org/

[40] San Francisco Smart City [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://smartcitysf.com/

[41] U.S. City Open Data Census [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://us-city.census.okfn.org/

[42] DataSF [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: www.datasf.org

[43] DataSF In Progress [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://datasf.org/progress/

[44] San Francisco Data APPS [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://apps.sfgov.org/showcase/

[45] Open Data in San Francisco: Institutionalizing an Initiative [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://sfmayor.org/sites/default/files/FileCenter/Documents/425-SanFranciscoOpenDataStrategicPlan2014.pdf

[46] DataSF About [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://datasf.org/about/

[47] 53% Of Companies Are Adopting Big Data Analytics [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://www.forbes.com/sites/louiscolumbus/2017/12/24/53-of-companies-are-adopting-big-data-analytics/#33945ddb39a1

[48] Apache Spark [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://spark.apache.org/

[49] KARAU, Holden, et al. Learning spark: lightning-fast big data analysis. " O'Reilly Media, Inc.", 2015.

[50] SHORO, Abdul Ghaffar; SOOMRO, Tariq Rahim. Big data analysis: Apache spark perspective. Global Journal of Computer Science and Technology, 2015.

[51] Apache Hadoop [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: http://hadoop.apache.org/

[52] HDFS Architecture Guide [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html

[53] MapReduce Tutorial [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://hadoop.apache.org/docs/r1.2.1/mapred_tutorial.html

[54] Spark wins Daytona Gray Sort 100TB Benchmark [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://spark.apache.org/news/spark-wins-daytona-gray-sort-100tb-benchmark.html

[55] Apache Zeppelin [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://zeppelin.apache.org/

[56] Plotly [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://plot.ly/api/

[57] Getting Started with Plotly for Python [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://plot.ly/python/getting-started/

[58] HILL, Terry; WESTBROOK, Roy. SWOT analysis: it's time for a product recall. Long range planning, 1997, vol. 30, no 1, p. 46-52.

[59] DYSON, Robert G. Strategic development and SWOT analysis at the University of Warwick. European journal of operational research, 2004, vol. 152, no 3, p. 631-640.

[60] INRIX Global Traffic Scorecard [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en:http://inrix.com/scorecard/

[61] DataSet Fire Department Calls for Service [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://data.sfgov.org/Public-Safety/Fire-Department-Calls-for-Service/nuek-vuh3

Página 55 de 55

[62] DataSet Fire Incidents [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://data.sfgov.org/Public-Safety/Fire-Incidents/wr8u-xric

[63] DataSet Registered Business Locations [en línea] [fecha de consulta: 02 Julio 2010]. Disponible en: https://data.sfgov.org/Economy-and-Community/Registered-Business-Locations-San-Francisco/g8m3-pdis

[64] MATÉ, Alejandro; TRUJILLO, Juan; MYLOPOULOS, John. Key performance indicator elicitation and selection through conceptual modelling. En International Conference on Conceptual Modeling. Springer, Cham, 2016. p. 73-80.

[65] HORKOFF, Jennifer, et al. Strategic business modeling: representation and reasoning. Software & Systems Modeling, 2014, vol. 13, no 3, p. 1015-1041.

[66] MATÉ, Alejandro; TRUJILLO, Juan; MYLOPOULOS, John. Specification and derivation of key performance indicators for business analytics: A semantic approach. Data & Knowledge Engineering, 2017, vol. 108, p. 30-49.