/practica_ibd

Práctica de la asignatura de Infraestructura de Big Data

Primary LanguageJupyter NotebookMIT LicenseMIT

Práctica de Infraestructuras de Big Data

En esta práctica, se busca realizar un procesamiento batch de datos sobre la situación actual de la comunidad de Madrid. En concreto, se pretende extraer datos sobre la meteorología, la calidad del aire, la contaminación acústica y noticias recientes de periódicos locales. La infraestructura permitirá la extracción, procesamiento y almacenamiento de estos datos; con la finalidad de realizar una visualización de los mismos a través de un dashboard interactivo creado mediante Streamlit. Este dashboard, permitirá visualizar la situación en Madrid que hubo en un día concreto.

Para ello, con una frecuencia diaria, se extraerán los datos mediante Apache Airflow (que será la herramienta que orquestará todo el flujo de datos desde la extracción hasta la propuesta de valor). Estos incrementales diarios se almacenarán en la carpeta /raw, cuya finalidad es que sea utilizada a modo de data lake (como AWS S3). Tras ello, se realizará semanalmente (todos los lunes) un procesamiento paralelo de los datos en crudo con Apache Spark (PySpark) para, no solamente enriquecerlos; sino también, combinarlos con el histórico generado guardando los datos estructurados en una base de datos relacional (PostgreSQL) y los no estructurados, en una base de datos no relacional (MongoDB). De estas dos soluciones de almacenamiento, beberá Streamlit para la visualización interactiva de los datos (dashboard)

Despliegue 🚀

Warning

Es posible que sea necesario otorgar los permisos correspondientes a las carpetas ./logs y ./raw para que Apache Airflow pueda escribir en ellas desde el interior del contenedor.

En Linux, se puede hacer mediante el comando sudo chmod -R 777 ./logs ./dags antes de realizar el despliegue. Este comando cambiará los permisos de los directorios logs y dags, así como de todos los archivos y subdirectorios contenidos dentro de ellos, otorgando permisos completos (lectura, escritura y ejecución) a todos los usuarios.

Para desplegar el entorno, debemos ejecutar el fichero run.sh, si se está utilizando Linus o MacOS;

bash run.sh

o el fichero run.bat, si se está utilizando Windows. Estos scripts se encargan de preparar el entorno y ejecutar el comando docker-compose up --build para desplegar los contenedores necesarios.

Tras ello, podremos acceder a las interfaces de Airflow y Apache Spark:

Las credenciales de acceso a Apache Airflow son las siguientes:

  • Username:admin
  • Password: admin

Finalmente, para establecer la conexión de Apache Airflow con Apache Spark, debemos especificar los siguientes parámetros en el panel /Admin/Connections de Airflow:

  • Connection Id: spark-conn
  • Connection Type: Spark
  • Host: spark://spark-master
  • Port: 7077

También, debemos especificar la conexión con Postgres en el panel /Admin/Connections de Airflow:

  • Connection Id: postgres_default
  • Connection Type: Postgres
  • Host: postgres-datawarehouse
  • Schema: postgres
  • Login: postgres
  • Password: password
  • Port: 5432

Por último, debemos añadir la conexión a MongoDB en este mismo panel:

  • Connection Id: mongo-conn
  • Connection Type: MongoDB
  • Host: mongodb
  • Port: 27017

Note

En el Dockerfile se han especificado todas las versiones de todas las dependencias del proyecto meticulosamente para evitar conflictos de versiones en el futuro.

El uso de Poetry se utiliza únicamente desde el punto de vista de desarrollo, para gestionar las dependencias del proyecto. De esta forma, se permite la realización de pruebas en local sin necesidad de desarrollar desde el interior del contenedor. Estas pruebas se realizan principalmente en los notebooks contenidos en la carpeta ./notebooks. No obstante, ninguno de los contenedores desplegados en producción hace uso de Poetry o de los notebooks.

Componentes de la Infraestructura ⚙️

Para desplegar la infraestructura de Big Data compuesta por Apache Airflow y Apache Spark de manera eficiente y coherente, se ha utilizado Docker Compose debido a su capacidad para simplificar el proceso de configuración y lanzamiento de múltiples contenedores que necesitan trabajar juntos de forma integrada.

Docker Compose permite definir en un solo archivo docker-compose.yml todas las configuraciones de los servicios, incluidos los volúmenes, redes y dependencias, asegurando que cada componente de la infraestructura sea desplegado en un entorno aislado y reproducible. Gracias a esta virtualización, se garantiza que las mismas versiones de software y configuraciones exactas sean utilizadas en cada despliegue, eliminando los problemas comunes relacionados con las discrepancias de "funciona en mi máquina". Además, la gestión de múltiples servicios que deben iniciarse en un orden específico y configurarse para interactuar entre ellos se maneja automáticamente, reduciendo la complejidad y aumentando la eficiencia del proceso de despliegue.

Esta infraestructura está compuesta por los siguientes componentes:

Red

La infraestructura utiliza una red de tipo bridge que permite la comunicación entre los distintos contenedores.

Apache Spark

El clúster de Spark está compuesto por tres servicios:

  • spark-master: Este servicio actúa como el nodo maestro en un clúster de Spark. Es responsable de administrar y distribuir las tareas entre los nodos trabajadores (workers).
  • spark-worker-1, spark-worker-2, spark-worker-3 y spark-worker-4: Estos cuatro servicios actúan como nodos trabajadores en el clúster de Spark. Se conectan al nodo maestro y son los encargados de ejecutar las tareas asignadas. Cada trabajador está configurado con 2 núcleos y 1GB de memoria RAM.

Note

Apache Spark es un motor de procesamiento de datos que permite análisis complejos y computación distribuida. Se justifica su uso por las siguientes razones:

  • Procesamiento en memoria: Spark realiza el procesamiento de datos en memoria, lo que lo hace mucho más rápido que otros sistemas que acceden al disco, como Hadoop MapReduce.

  • Facilidad para procesamiento de datos a gran escala: Spark se diseñó para manejar petabytes de datos distribuidos a través de múltiples nodos de manera eficiente. Esto lo hace ideal para el escenario descrito, donde se manejan datos incrementales diarios de múltiples fuentes.

Apache Airflow

El entorno de Airflow está compuesto por dos servicios:

  • webserver: Este servicio corre el servidor web de Airflow, que proporciona la interfaz de usuario para administrar y visualizar flujos de trabajo (DAGs). Está configurado para ejecutarse en el puerto 8080, haciendo la interfaz accesible a través de http://localhost:8080.
  • scheduler: Este servicio corre el programador (scheduler) de Airflow, que es responsable de programar las tareas definidas en los DAGs y ejecutarlas según sus dependencias y programación. Antes de iniciar el scheduler, realiza migraciones de base de datos y crea un usuario admin para acceder a la interfaz de Airflow.
  • postgres: Este servicio funciona como la base de datos para Airflow. Guarda la información sobre el estado de las tareas, los DAGs y otros metadatos necesarios para que Airflow funcione correctamente. La base de datos está configurada con las credenciales airflow tanto para el usuario como para la contraseña.

Note

Apache Airflow es una plataforma open-source diseñada para programar y orquestar flujos de trabajo complejos mediante programación en Python. Algunas de las razones por las cuales hemos utilizado Apache Airflow son las siguientes:

  • Programación y orquestación flexibles: Airflow permite definir flujos de trabajo, conocidos como DAGs (Directed Acyclic Graphs), que son visualizaciones de las tareas y sus dependencias. Esto es fundamental para procesos donde las tareas deben ejecutarse todos los días a una hora específica.

  • Reintentos y manejo de errores: Airflow ofrece mecanismos robustos para el manejo de fallos, incluyendo reintentos automáticos y alertas. Esto asegura que los flujos de datos no se detengan por fallos puntuales, lo cual es esencial en entornos de producción donde la continuidad y la fiabilidad son cruciales.

  • Interfaz de usuario intuitiva: La interfaz de usuario de Airflow nos permite visualizar la ejecución de los flujos de trabajo, monitorear el progreso y revisar registros de las tareas ejecutadas.

  • Escalabilidad y Integración: Airflow se integra fácilmente con otras herramientas y plataformas, como Apache Spark para el procesamiento de datos y sistemas de bases de datos para el almacenamiento de datos. Esto permite escalar las operaciones de procesamiento conforme al volumen de datos crece, y facilita la implementación de mejoras sin grandes sobrecostos de adaptación.

PostgreSQL

  • pgAdmin4: Este servicio proporciona una interfaz web para administrar y visualizar la base de datos PostgreSQL. Se puede acceder a la interfaz en http://localhost:16543. Las credenciales de acceso son:
    • Correo electrónico: teste@teste.com
    • Contraseña: teste
  • postgres-datawarehouse: Este servicio es la base de datos relacional para nuestro datawarehouse (OLAP). En él, se guardará todos los datos estructurados en un modelo dimensional de Kimball para optimizar la lectura de los mismos (visualización desde Streamlit).

Al ingresar a la interfaz, se solicitará una contraseña para acceder al servidor de la base de datos, la cual es password.

MongoDB

  • mongodb: se encarga del almacenamiento de noticias procesadas para análisis de sentimientos y visualizaciones rápidas y eficientes. Este servicio en Docker Compose se configura con la imagen oficial de MongoDB. Se expone el puerto estándar de MongoDB (27017) para permitir conexiones desde aplicaciones internas y externas al contenedor. Las configuraciones de volúmenes aseguran la persistencia de datos, lo que permite que los datos sobrevivan reinicios del contenedor.

Note

MongoDB es una base de datos NoSQL que proporciona alta flexibilidad y es adecuada para el almacenamiento y manipulación de datos en formatos no estructurados. Algunas de las razones por las cuales hemos utilizado MongoDB son las siguientes:

  • Flexibilidad de Esquema: MongoDB permite almacenar documentos JSON sin un esquema predefinido. Por ejemplo, si en un futuro decidimos añadir el campo "autor" a los documentos de noticias, no necesitamos modificar el esquema de la base de datos.
  • Escalabilidad: esta base de datos ofrece una escalabilidad horizontal, con soporte para sharding y réplicas. Esto permite manejar eficientemente grandes volúmenes de datos y un alto nivel de tráfico de lectura y escritura, características esenciales para sistemas de big data.
  • Rendimiento: la capacidad de MongoDB para indexar cualquier campo en un documento y sus capacidades de consulta ricas lo hacen extremadamente rápido para operaciones de lectura y escritura, lo que mejora significativamente el rendimiento de las aplicaciones que dependen de un acceso rápido a grandes volúmenes de datos.

Streamlit

  • streamlit: Este servicio ejecuta el servidor de Streamlit, que proporciona una interfaz web para visualizar los datos almacenados en las bases de datos de PostgreSQL y MongoDB. Se puede acceder a la interfaz en http://localhost:8090.

Volúmenes

Se configuran varios volúmenes para mantener la persistencia de los datos y el código entre reinicios de los contenedores. En concreto, varios volúmenes se mapean a las carpetas locales para que Spark y Airflow puedan acceder a scripts, DAGs, registros de ejecución, datos crudos y enriquecidos (./jobs, ./dags, ./logs, ./raw, ./rich). A continuación se detallan los volúmenes configurados:

  • postgres-db-volume: Asociado con PostgreSQL, este volumen almacena la base de datos y asegura que los datos no se pierdan cuando el contenedor es reiniciado o eliminado. Está montado en /var/lib/postgresql/data dentro del contenedor.

  • mongodb-data: Utilizado por MongoDB para almacenar la base de datos, asegurando la persistencia de los datos almacenados en MongoDB. El directorio de montaje estándar es /data/db dentro del contenedor.

  • Volúmenes para Spark y Airflow:

    • ./jobs:/opt/airflow/jobs y ./jobs:/opt/bitnami/spark/jobs: Comparten scripts y tareas entre Airflow y Spark.
    • ./raw:/opt/airflow/raw y ./raw:/opt/bitnami/spark/raw: Utilizados para almacenar y acceder a datos en bruto.
    • ./rich:/opt/airflow/rich y ./rich:/opt/bitnami/spark/rich: Utilizados para almacenar resultados procesados listos para ser consumidos por otras aplicaciones o almacenados en la base de datos.

  • Volumen para Streamlit:

    • ./web_app:/app: Comparte el código de la aplicación de Streamlit para visualizar los datos almacenados en las bases de datos de PostgreSQL y MongoDB.

DAGs de Extracción de Apache Airflow 🔄

Para cargar los datos anteriormente mencionados, se realizan una serie de DAGs de Airflow para extraer y cargar la información cruda en la carpeta /raw. Cada DAG está compuesto de dos tareas: la extracción de la información y la carga de la misma en dicha carpeta.

A continuación se detalla la lista de DAGs:

  • gob_meteor DAG: extrae el CSV incremental de datos 'Datos meteorológicos. Datos en tiempo real' que proporciona el Ayuntamiento de Madrid. La URL correspondiente es:

      https://datos.gob.es/es/catalogo/l01280796-datos-meteorologicos-datos-en-tiempo-real1

    La información sobre las distintas variables medidas es la siguiente:

      81 - VELOCIDAD VIENTO
  82 - DIR. DE VIENTO
  83 - TEMPERATURA
  86 - HUMEDAD RELATIVA
  87 - PRESION BARIOMETRICA
  88 - RADIACION SOLAR
  89 - PRECIPITACIÓN

    Para más información, se puede consultar la siguiente web: https://datos.madrid.es/portal/site/egob/menuitem.c05c1f754a33a9fbe4b2e4b284f1a5a0/?vgnextoid=2ac5be53b4d2b610VgnVCM2000001f4a900aRCRD&vgnextchannel=374512b9ace9f310VgnVCM100000171f5a0aRCRD&vgnextfmt=default

  • mambiente_hourly_data DAG: extrae el contenido del fichero horario.txt de la web del Ayuntamiento de Madrid, el cual contiene información sobre la calidad del aire en la ciudad de Madrid y se actualiza cada hora. Los datos son accesibles en el siguiente enlace.

    A continuación se muestra un extracto del contenido de la web que proporciona los datos:

    El Sistema Integral de la Calidad del Aire del Ayuntamiento de Madrid permite conocer en cada momento los niveles de contaminación atmosférica en el municipio.

    En este conjunto de datos puede obtener la información actualizada en tiempo real, actualizándose estos datos cada hora, y esta actualización se realizará entre los minutos 20 y 30.

    Importante: estos datos en tiempo real son los que salen automáticamente de las estaciones de medición y están pendientes de revisión y validación.

    Para más información sobre el contenido del fichero, consultar el documento Interprete_ficheros_calidad_del_aire_global.pdf.

  • noticias DAG: está diseñado para automatizar la extracción de noticias recientes de los periódicos El País y ABC, específicamente de sus secciones de Madrid. Utiliza técnicas de web scraping para obtener el contenido de las páginas web de estos medios.

    Estos datos se almacenan en un archivo JSON, cuyo nombre incorpora la fecha y hora de la extracción, para su posterior análisis o uso. Los datos siguen el siguiente formato:

    [
    {
        "title": "El secretario general del PP de Ayuso se citó con la pareja de la líder en plena polémica por su caso de fraude fiscal",
        "link": "https://elpais.com/espana/madrid/2024-04-04/el-secretario-general-del-pp-de-ayuso-se-cito-con-la-pareja-de-la-lider-en-plena-polemica-por-su-caso-de-fraude-fiscal.html",
        "description": "Aunque los conservadores reducen la denuncia de la Fiscalía a un asunto que afecta a un particular, altos cargos del partido y del Gobierno se han implicado en la gestión de la crisis política y reputacional",
        "journal": "EL_PAIS"
    },
    ...
]

    El DAG se ejecuta diariamente a las 22:35 UTC, garantizando la recopilación de noticias a lo largo del día. Las noticias son filtradas para solo incluir las noticias del día de ejecución del DAG.

    Para más información sobre El País y ABC, sus secciones de noticias de Madrid pueden ser accedidas a través de los siguientes enlaces:

  • contaminacion_acustica DAG: extrae los datos de contaminación acústica de la web del Ayuntamiento de Madrid. Los datos son accesibles en el siguiente enlace.

    A continuación se muestra un extracto del contenido del fichero que proporciona los datos:

    Este conjunto de datos ofrece la información desde el 1 de enero de 2014, y se va actualizacion diariamente. Todos los días laborables se publican los datos correspondientes al día anterior. En el caso de los días laborables inmediatamente posteriores a días no laborables, se publican los datos correspondientes a los días pendientes no laborables. La unidad en la que se proporcionan todos los datos (LAeq, LAS01, LAS10, LAS50, LAS90 y LAS99) es el decibelio ponderado en base A (dBA). En este portal tambien están disponibles otros conjuntos de datos relacionados con la contaminación acústica: Contaminación acústica. Datos históricos mensuales Contaminación acústica: Estaciones de medida Asímismo, puedes encontrar más información sobre estos datos en el Portal de transparencia > Ruido.

    El DAG se ejecuta diariamente a las 22:35 UTC, descargándose el fichero de datos completo. Este fichero contiene todos los datos de contaminación acústica desde el 1 de enero de 2014 hasta el día anterior a la ejecución del DAG. En el caso de los días festivos, los datos correspondientes a esos días se publican en el siguiente día laborable, por lo que el DAG se encarga de descargar los datos correspondientes a esos días festivos en el día laborable siguiente.

    La información sobre las estaciones de medida se puede encontrar en el siguiente enlace.

    Para más información sobre el contenido del fichero, consultar el siguiente documento

  • meteor DAG: se encarga de extraer datos meteorológicos de varios distritos de Madrid y cargarlos en un archivo CSV. La ejecución del DAG se programa diariamente a las 22:35 UTC.

    A continuación, se detallan las tareas del DAG:

    1. extract_data: Esta tarea se encarga de extraer los datos meteorológicos de los distritos especificados utilizando la API de open-meteo.com. Los distritos y sus coordenadas están definidos dentro de la tarea. Los datos extraídos corresponden a la información disponible hace 2 días anteriores y se procesan y almacenan
      en un DataFrame de Pandas.

    2. export_raw_df: Una vez que los datos se han extraído y procesado, se exportan a un archivo CSV en la carpeta "/opt/airflow/raw". El nombre del archivo se genera con la fecha y hora actual.

    3. end: Esta tarea final simplemente imprime un mensaje indicando que las tareas han sido completadas con éxito.

    Los datos meteorológicos se obtienen de open-meteo.com, una plataforma que proporciona información detallada sobre varias variables meteorológicas. El DataFrame generado incluye información como la temperatura, la humedad relativa, la presión barométrica, la velocidad del viento y la radiación solar, entre otras variables. Para más información sobre la fuente de datos, visita open-meteo.com.

Explicación de Flujo Completo de ETL

Tras realizar esta extracción incremental diaria (volcando los correspondientes datos en la carpeta /raw), se ejecuta un DAG de Airflow con PySpark semanalmente para cargar los nuevos incrementales en el datawarehouse. Este datawarehouse se ha desplegado en PostgreSQL puesto que no solamente soporta funcionalidades de OLTP; sino también de OLAP (nuestro caso de uso).

En el datawarehouse, se ha optado por implementar un modelo Kimball. Todos los detalles de este modelo (las tablas a implementar, los mapeos correspondientes de antiguos IDs con los nuevos, la normalización de algunas estaciones repetidas, etc) se pueden encontrar en el Excel Final_Kimball_Model_Def.xlsx. A modo general, el modelo posee las siguientes tablas:

  • Measures (Fact Table): actualizada cada semana con los nuevos datos de los incrementales. Posee los siguientes campos: “measure_id”, una clave primaria autoincremental (que también actúa como clave surrogada); “metric_id”, una clave foránea que conecta con la tabla dimensional de Metrics; “station_id”, una clave foránea que conecta con la tabla dimensional de Stations; “measure”, valor cuantitativo de la medida; y “date”, fecha en la que se ha obtenido la medida (muy útil para los posteriores filtros en la parte de visualización)
  • Stations (Dimensional Table): se ingesta una única vez al desplegar la infraestructura de datos en el script de inicialización de PostgreSQL. Posee los siguientes campos: “station_id”, clave primaria; “station_name”, nombre de la estación; “district_name”, nombre del distrito; “longitude”, longitud (coordenada); y “latitude”, latitud (coordenada)
  • Metrics (Dimensional Table): se ingesta una única vez al desplegar la infraestructura de datos en el script de inicialización de PostgreSQL. Posee los siguientes campos: “metric_id”, clave primaria; y “metric_name”, nombre de la métrica.

Respecto al procesamiento semanal, todos los lunes por la mañana (a las 9:00 en UTC) se ejecuta el DAG weekly_spark_incremental. Este DAG se compone principalmente de dos tasks:

  • transform_task: se ejecuta un job de PySpark donde se realiza el respectivo procesamiento para transformar los datos en /raw de la semana pasada al formato correspondiente a la FACT table de Measures. Este job de PySpark con 4 worker nodes se realiza en el script enrich_spark.py. En él, se realizan las transformaciones necesarias para todas las tablas (mappeos de station_id y metric_id, cálculo agregado de la medida “measure” realizando la media aritmética, concatenación de strings, procesamiento de fechas, filtros específicos, etc). Finalmente, todos los datos enriquecidos con el nuevo formato se guardan en el volumen /rich. Como se puede apreciar, los volúmenes /raw y /rich están funcionando como data lakes (AWS S3, ADLS, etc) en nuestra arquitectura delta.
  • load_rich_task: tras transformar los nuevos incrementales al formato de la FACT table en la task de PySpark, se deben insertar en la base de datos de PostgreSQL con la sentencia de COPY leyendo los datos enriquecidos del volumen /rich.

Con esta misma frecuencia, los lunes a las 9:00 UTC, se ejecuta el DAG load_noticias_to_mongo_db_dag.py. Este flujo se encarga de analizar el sentimiento de las noticias y luego de cargar estos datos enriquecidos en una base de datos MongoDB. Sus tareas principales son:

  • sentiment_analysis_task: Se ejecuta un job de PySpark utilizando un script llamado jobs/sentiment_analysis.py, que realiza análisis de sentimiento en las noticias recopiladas durante la semana anterior. Este script procesa los archivos JSON almacenados en el volumen /raw, añadiendo un nuevo campo de sentiment a cada registro, calculado a través de un modelo preentrenado de análisis de sentimientos. El modelo utilizado es "mrm8488/electricidad-small-finetuned-sst2-es", disponible en Hugging Face. Este modelo proporciona una probabilidad de que el texto de la noticia tenga una connotación positiva o negativa, y este cálculo se transforma en un rango de $[-1, 1]$ para ser directamente aplicable en análisis posteriores. La transformación a este rango se realiza restando la probabilidad de que el sentimiento sea negativo a la de que este sea positivo. Tras la evaluación de sentimiento, el job de PySpark escribe los resultados en formato JSON en el directorio /opt/airflow/rich. En concreto, los resultados se almacenan en una carpeta llamada sentiment_analysis_{fecha_del_último_domingo}.

  • load_to_mongodb: Una vez obtenidos los datos enriquecidos con información de sentimiento, esta tarea utiliza una función de Python para cargar estos datos en MongoDB. Esta función lee los archivos JSON del directorio especificado y, para cada registro, verifica si ya existe en la base de datos bajo el mismo título de noticia. Si la noticia ya existe, se actualiza con los nuevos datos; si no, se inserta como un nuevo documento. Esta comprobación no es estrictamente necesaria pero, de esta forma, se evitan tener documentos duplicados en la base de datos si se ejecuta manualmente el DAG y no se resta funcionalidad.

Dashboard de Streamlit 📈

Streamlit es un framework de código abierto diseñado para crear rápidamente aplicaciones web interactivas y visualizaciones de datos utilizando solo Python. Se puede acceder a la interfaz en http://localhost:8090.

Esta interfaz tiene dos secciones principales:

  • Visualización de Datos de Meteorología: Muestra gráficos interactivos de las medidas meteorológicas de los distintos distritos de Madrid.

Si se selecciona un distrito en el mapa, se mostrará un gráfico del histórico de la medida seleccionada en ese distrito.

  • Visualización de Datos de Noticias: Muestra un gradiente con el sentimiento del título de las noticias recopiladas de los periódicos El País y ABC.

Las 5 V's del Big Data 📊

El proyecto aborda las 5 Vs del Big Data de la siguiente manera:

  • Volumen: Esta dimensión se sacrifica en este proyecto. No obstante, el proyecto podría manejar grandes volúmenes de datos potencialmente, ya que se extraen datos de múltiples fuentes y se procesan diariamente. Los datos meteorológicos, de calidad del aire, de contaminación acústica y de noticias se recopilan y almacenan en bruto en la carpeta /raw, lo que podría resultar en un volumen significativo de datos a lo largo del tiempo.
  • Velocidad: El proyecto se centra en la velocidad de procesamiento de los datos, ya que se extraen y procesan diariamente. Los DAGs de Airflow se programan para ejecutarse diariamente a una hora específica, lo que garantiza la actualización regular de los datos. Además, se consigue una gran rapidez en la extracción y procesamiento de datos gracias a la elección de las herramientas anteriormente explicadas (gracias al uso de Apache Spark y Apache Airflow)
  • Variedad: El proyecto maneja una variedad de datos de diferentes fuentes, así como datos de tipo estructurado y no estructurado. Los datos meteorológicos, de calidad del aire y de contaminación acústica son estructurados, mientras que los datos de noticias son no estructurados.
  • Veracidad: El proyecto se centra en garantizar la veracidad de los datos, ya que se extraen de fuentes oficiales, como el Ayuntamiento de Madrid. Con respecto a los datos de noticias, se obtienen datos de dos de los principales periódicos de España, El País y ABC, cada uno con diferentes enfoques y perspectivas.
  • Valor: El proyecto busca proporcionar valor a través de la visualización de los datos en un dashboard interactivo creado con Streamlit. Una de las principales utilidades de este dashboard es permitir a los usuarios conocer como fue la situación en Madrid en el pasado. Conocer los datos relacionados con la contaminación es esencial para tomar decisiones informadas sobre la salud y el bienestar. Los datos relacionados con la meteorología y las noticias nos permiten comprender mejor el contexto en el que se producen los eventos relacionados con la contaminación.

Miembros del Equipo 👥

Grupo 2:

  • Pablo Ariño
  • Álvaro Laguna
  • Ismail Merabet
  • Roberto Mulas

Nombres ordenados alfabéticamente por apellido.

Referencias