Big Data: retos y oportunidades parala investigación geográficaArquitectura

BIG DATA

Reunión de seguimiento SocialBigdata-CMBorja Moya-Gómez (tGIS)

Madrid, 29 de junio de 2017

índice

1. El objetivo

2. La arquitectura con un ejemplo

3. El salto a la nube

4. Talleres de formación

1. El objetivo

Disponer de una herramienta que:1. Capturar y adecuar automáticamente datos de diferentes

fuentes de datos (variedad – velocidad - volumen).

2. Visualice parte de esos datos para obtener información al instante (variedad - velocidad).

3. “Abaratar el coste del error” para poder hacer análisis. Es decir, realizar aquellos análisis que sin herramientas Big Data son poco asumibles (variedad - volumen).

4. Sea fácil de usar por parte de todos los usuarios de la red, y se pueda adaptar a las necesidades de cada uno (en la medida de lo posible).

5. Permita que varios grupos dispongan de los mismos datos para hacer fortalecer la red SocialBigdata-CM.

2. La arquitectura con un ejemplo

¿Cuál es la relación del tráfico con la calidad del aire en la villa de Madrid?

Objetivos:Conocimiento de las fuentes de datos de envío de datos a intervalos

Formatos de los datosPrototipo de protocolos de análisis

Prototipo de arquitectura

Participantes:SocialBigdata-CM: Guadalupe (gTEC), Yolanda (gTEC), Henar (Indizen),

Juan Carlos (tGIS), Joaquín (tGIS), Borja (tGIS).Facultad Informática: Verónica (TFM - Análisis)KSchool: Jeff (TFM – Arquitectura), Fernando (TFM – Análisis)

2. La arquitectura con un ejemplo

Secor/camus

Kafka

Otras fuentes

Tráfico Madrid

Calidad Aire

Apache Flink

Kafka

Ingesta

Análisis

. . .

Tiempo Real Batch

2. La arquitectura con un ejemplo

Secor/camus

Kafka

Otras fuentes

Tráfico Madrid

Calidad Aire

Apache Flink

Kafka

Ingesta

2. La arquitectura con un ejemplo

Kafka

Otras fuentes

Tráfico Madrid

Calidad Aire

KaftaGenera colas de datos, una por “topic”Pide datos a las API… y los pone en su cola.Se envían los datos de cada cola al siguiente elemento según se configure (cada cola tiene su configuración)

Sirve para compactar y laminar el flujo de datos.

No se pierden datos por saturación de procesos posteriores

2. La arquitectura con un ejemplo

Secor/camus

Kafka

Otras fuentes

Tráfico Madrid

Calidad Aire

Apache Flink

Kafka

Ingesta

2. La arquitectura con un ejemplo

Apache Flink

Apache FlinkParaleliza procesos.Permite hacer operaciones de:

• Filtrado• Limpieza• Normalización• Enriquecimiento

El enriquecimiento se realiza con datos de otras fuentes.

Es un proceso que se origina por la pregunta original

En el ejemplo: 1. los datos de tráfico se preparan

para indicar número de vehículos cada 5 min* y se suman para obtener la intensidad horaria [veh/h] de cada estación.

2. se añade el tráfico de esa hora a cada estación de calidad de aire según distancias (a 250m, a 500m, a 750m…)

El trabajo que se realice aquí será el que se

almacenará como datos originales.

También prepara datos para visualización en tiempo real

2. La arquitectura con un ejemplo

Secor/camus

Kafka

Otras fuentes

Tráfico Madrid

Calidad Aire

Apache Flink

Kafka

Ingesta

2. La arquitectura con un ejemplo

Secor/camus Kafka

KaftaSirve para compactar y laminar el flujo de datos.

Envía datos a S3 por intervalos preconfiguradossegún ‘topic’

Interesa que los archivos tengan un cierto tamaño, para poder aprovechar mejor las herramientas de análisis de Big Data. En el ejemplo:

1. Tráfico se envía a S3 cada X minutos

2. Calidad aire se envía a S3 cada Y minutos

X = Y = 1 día

S3Guarda los datos originales y los datos tratados

Las herramientas de análisis pregunta a los datos de S3

Los datos que están en Kafta

NO

pueden ser analizados

2. La arquitectura con un ejemplo

Secor/camus

Kafka

Otras fuentes

Tráfico Madrid

Calidad Aire

Apache Flink

Kafka

Ingesta

Análisis

. . .

Tiempo Real Batch

2. La arquitectura con un ejemplo

Apache Flink

Ingesta

Análisis

Tiempo Real

2. La arquitectura con un ejemplo

ElasticEs una BBDD.

Es muy liviana, es sólo contendrá la información necesaria para visualizaciones a tiempo real.

La vida del dato está limitada, se borran automáticamente.

No permite procesos de análisis complejos

Organiza los datos por ‘topics’

En el ejemplo: 1. Tráfico

• Nombre estación• Ubicación• Intensidad

2. Aire• Nombre estación• Ubicación• Valor NOx

2. La arquitectura con un ejemplo

Apache Flink

Ingesta

Análisis

Tiempo Real

2. La arquitectura con un ejemplo

Visualiza datos introducidos en Elastic, permite obtener diferentes visualizaciones

Control de los principales valores esperados de cada fuente

2. La arquitectura con un ejemplo

Secor/camus

Kafka

Otras fuentes

Tráfico Madrid

Calidad Aire

Apache Flink

Kafka

Ingesta

Análisis

. . .

Tiempo Real Batch

2. La arquitectura con un ejemplo

Análisis

. . .

Batch

2. La arquitectura con un ejemplo

S3Sólo se puede escribir una vez, leer muchas veces.

Los datos originales no se pueden modificar

Se guardarán los datos tratados que se considere oportuno.

Apache ZeppelinInterfaz de trabajo con los datos que, no sólo permite trabajar con ellos, sino también ejecutar procesos vía Spark, R, Python…

2. La arquitectura con un ejemplo

Análisis

. . .

Batch

2. La arquitectura con un ejemplo

. . .

Aquí, los analistas pueden acceder a toda los datos, trabajar con ellos y analizarlos.

SparkDistribuye y organiza los trabajos entre varios servidores

R y PythonLas herramientas básicas del análisis de datos

…

2. La arquitectura con un ejemplo

El conocer qué se quiere saber de los datos (la pregunta) permite

filtrarlos, limpiarlos, normalizarlos y enriquecerlos en el momento de su captura. Se dejan los datos preparados para analizar

Una pregunta genera nuevas preguntas

pero eso no impide que se puedan usar para contestar otras preguntas que no se han tenido en cuenta en el momento de la captura de datos

se tendrá que tratar un poco los datos antes analizar

LA ARQUITECTURA ES MODULARSe pueden incorporar nuevas preguntas y/o fuentes de datos

3. El salto a la nube

Esta arquitectura requiere tener varios servidores (físicos o en la nube) encendidos

Eso es caroIncluso “levantando”

y “apagando” servidoressegún demanda

3. El salto a la nube

Secor/camus

Kafka

Otras fuentes

Tráfico Madrid

Calidad Aire

Apache Flink

Kafka

Ingesta(mín 2)

Análisis(mín 2)

. . .

Tiempo Real Batch

3. El salto a la nube

Esta arquitectura requiere tener varios servidores (físicos o en la nube) encendidos

Eso es caro Se remplaza parcialmente por servicios de AWS

La captura, filtrado, limpieza y normalización* de los datos de tráfico y aire ya no requieren “levantar” servidores. Se lanzan funciones cuando se requiere (cada 5 min, cada 1h…). ¡Se lanzan con Lambda!

Se simplifican las colas (Kinesis)

Hay fuentes de datos (Twitter Streaming) que seguirán requiriendo de servidores y parte de la arquitectura anterior

Encontrar el equilibrio entre servicios y servidorespara aprovechar al máximo los recursos disponibles

El filtrado, limpieza, normalización* yenriquecimiento se realiza con Lambda

3. El salto a la nube

La arquitectura realizada se va a implementar en servidores de la Facultad de Informática

como BackUp y banco de pruebas de nuevos desarrollos

4. Talleres de formación

http://www.atkearney.com.mx/analytics/ideas-insights/article/-/asset_publisher/hZFiG2E3WrIP/content/its-challenge-bringing-structure-to-the-unstructured-world-of-big-data/10192?_101_INSTANCE_hZFiG2E3WrIP_redirect=%2Fanalytics%2Fideas-insights

Som

os

un

eq

uip

oC

ada

un

o t

ien

e u

no

o m

ás r

ole

s y

hay

qu

e es

tar

form

ado

par

a el

ro

l ele

gid

o

y en

ten

de

r el

res

to d

e r

ole

s

4. Talleres de formación

TalleresSeptiembre – Octubre 2017:

• Amazon Web Service (abierto a todo el mundo)• Manejo de la arquitectura SocialBigdata-CM (sólo SocialBigdata-CM)

Deberes• Formarse en R y Python

• Hacer preguntas (qué fuente se debe usar, enriquecimientos propios ocon otras fuentes de datos…)

• Adjuntar los papers en los que se indique la fuente (API) que se usa, para facilitar la comprensión de la fuente y agilizar aspectos “burocráticos” con la fuente de datos.

• A partir de las 13.30 (aprox), ¡hablar mucho entre nosotros para sacar más partido a la red!

Big Data: retos y oportunidades parala investigación geográficaGracias

Reunión de seguimiento SocialBigdata-CMBorja Moya-Gómez (tGIS) – bmoyagomez@ucm.es

Madrid, 29 de junio de 2017