Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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.