Objetivos¿Qué resolvemos con este proyecto?
En este proyecto se desarrolla una arquitectura de procesamiento de datos extremo a extremo orientada al ámbito Big Data e Internet de las Cosas (IoT). El objetivo principal no consiste únicamente en capturar información procedente de sensores, sino en demostrar cómo un dato generado en el mundo físico puede recorrer todas las etapas de una plataforma moderna de análisis de datos hasta convertirse en información útil para la toma de decisiones.
Para ello se diseña una infraestructura compuesta por un dispositivo IoT encargado de generar mediciones ambientales, un sistema de adquisición y transporte de datos mediante Node-RED y MQTT, una capa de almacenamiento estructurada basada en Data Lake, procesos de validación y transformación de datos, mecanismos de orquestación mediante Airflow y una capa final de visualización analítica mediante Superset.
Este enfoque reproduce, a pequeña escala, una arquitectura similar a la utilizada actualmente en entornos industriales y empresariales donde grandes volúmenes de información son capturados continuamente desde dispositivos conectados y posteriormente transformados en conocimiento accionable.
Además del objetivo funcional, el proyecto persigue validar conceptos fundamentales trabajados durante la asignatura: ingestión de datos, almacenamiento distribuido, gobierno del dato, procesamiento por etapas, automatización de pipelines y construcción de cuadros de mando para explotación analítica.
El resultado final es una plataforma capaz de recibir datos automáticamente, almacenarlos de forma estructurada, procesarlos mediante flujos reproducibles y presentarlos visualmente para facilitar su interpretación.
Arquitectura del Sistema
Este diagrama resume la arquitectura completa del sistema. El flujo parte de un dispositivo IoT físico, pasa por captura y almacenamiento, y termina en visualización y orquestación mediante herramientas Big Data.
Evidencias del Desarrollo e Implementación
Se muestra el montaje inicial del dispositivo IoT sobre protoboard. El ESP32 se conecta al sensor para capturar mediciones ambientales que serán utilizadas como entrada del pipeline.
Esta captura evidencia el dispositivo en funcionamiento real. La conexión activa permite verificar que la parte física del sistema está preparada para enviar mediciones al entorno de procesamiento.
En Node-RED se define el flujo encargado de recibir los datos del sensor y canalizarlos hacia el almacenamiento local. Esta etapa conecta el mundo físico del IoT con el procesamiento de datos.
Desde terminal se comprueba que las mediciones quedan registradas en un fichero CSV. Esta persistencia local sirve como primera evidencia de captura correcta y como fuente para las fases posteriores.
La infraestructura se define mediante Docker Compose, lo que permite reproducir el entorno de trabajo. Esta configuración agrupa servicios como Jupyter, MinIO, Superset, Airflow y componentes de almacenamiento/procesamiento.
La salida de terminal permite verificar que los contenedores necesarios están levantados y funcionando. Esta comprobación es clave antes de ejecutar notebooks, cargas de datos o dashboards.
Docker Desktop permite comprobar visualmente el estado de los servicios desplegados. Esta vista complementa la verificación por terminal y facilita la supervisión del entorno.
En esta fase se emplea Jupyter Notebook como entorno de trabajo para analizar progresivamente el conjunto de datos generado por el dispositivo IoT. Los notebooks permiten inspeccionar calidad, validar transformaciones y preparar los datos para su publicación dentro del Data Lake siguiendo la arquitectura Medallion.
Desarrollo del pipeline mediante Jupyter Notebook
Los notebooks se utilizaron como entorno de desarrollo y validación del pipeline antes de automatizar el flujo completo. Cada uno representa una fase concreta del recorrido del dato dentro de la arquitectura Medallion.
Notebook 01 - Inspección del dataset RAW
Se realiza una exploración inicial del CSV generado por el dispositivo IoT. Se validan estructura, tipos de datos, volumen de registros, continuidad temporal y calidad básica antes de incorporar el dataset al pipeline.
Notebook 02 - Publicación del dataset en HDFS (Bronze)
Se carga el fichero original en HDFS manteniendo los datos sin transformación. Esta fase constituye la capa Bronze y garantiza la conservación del dato bruto como fuente de referencia.
Notebook 03 - Validación de calidad y generación de Silver Preview
Se generan errores controlados para comprobar reglas de calidad, detección de incidencias y separación entre registros válidos e inválidos. El resultado es un conjunto limpio preparado para procesamiento posterior.
Notebook 04A - Transformación Bronze -> Silver mediante MinIO
Se convierte el dataset validado a formato Parquet y se almacena en MinIO siguiendo la estructura Medallion. Se añaden campos derivados para facilitar particionado y consultas posteriores.
Notebook 04B - Transformación alternativa con Apache Spark
Se reproduce el paso Bronze -> Silver utilizando Spark para demostrar compatibilidad con procesamiento distribuido y generación de conjuntos analíticos preparados para escalado.
Notebook 05 - Construcción de capa Gold y explotación con DuckDB
Se generan agregaciones analíticas sobre la capa Silver y se publica un dataset Gold optimizado para consulta desde Superset y construcción de dashboards.
Aunque el flujo final queda orquestado mediante Airflow, el desarrollo y validación incremental se realizó inicialmente sobre Jupyter Notebook para facilitar depuración, trazabilidad y comprobación de cada etapa del pipeline.
En MinIO se crea el espacio de almacenamiento que actuará como Data Lake. Esta capa permite organizar los datos del proyecto de forma estructurada y accesible por otros servicios.
Se muestra la estructura de carpetas/capas dentro del almacenamiento objeto. Esta organización sigue una lógica tipo Medallion, separando datos iniciales, procesados y listos para análisis.
El fichero Parquet queda almacenado en MinIO como formato eficiente para análisis. Esta conversión mejora la explotación posterior desde herramientas SQL y de visualización.
En Superset se inicia la configuración del origen de datos seleccionando el motor adecuado. Esta conexión permite que la herramienta de BI acceda a los datos procesados.
Se parametriza la conexión necesaria para consultar los datos desde Superset. Esta etapa enlaza la capa analítica con los datos almacenados en el Data Lake.
Una vez creada la conexión, se define el dataset que utilizarán los gráficos. Este dataset actúa como base semántica para construir consultas y visualizaciones.
Desde SQL Lab se lanza una consulta sobre los datos almacenados en formato Parquet. Esto demuestra que los datos procesados pueden consultarse directamente desde la capa analítica.
Se muestran los primeros gráficos de línea del dashboard. Estas visualizaciones permiten analizar la evolución de las variables capturadas por el dispositivo IoT.
En el editor de gráficos se ajustan métricas, dimensiones y agrupaciones temporales. Esta fase convierte los datos en indicadores visuales útiles para interpretación.
El dashboard final integra diferentes visualizaciones del sistema. Permite consultar de forma rápida las mediciones capturadas, agregaciones y métricas principales.
Se realiza una consulta de validación sobre el dataset para comprobar los resultados. Esta revisión permite contrastar que las visualizaciones se apoyan en datos coherentes.
Airflow se utiliza como herramienta de orquestación del pipeline. La pantalla de acceso evidencia que el servicio está desplegado y protegido mediante autenticación.
Esta captura muestra el estado inicial del entorno de Airflow. Sirve como punto de referencia antes de registrar el DAG específico del pipeline IoT.
El DAG del proyecto aparece correctamente registrado en Airflow. Esto confirma que el flujo de orquestación ha sido detectado por el sistema.
La vista de detalles permite revisar la configuración general del DAG. Se observan tareas, propietario, etiquetas y parámetros relevantes del pipeline.
Esta captura muestra atributos internos del DAG, como ruta del fichero, estado de importación y configuración. Ayuda a verificar que Airflow interpreta correctamente la definición del flujo.
El audit log recoge eventos de ejecución y cambios asociados al DAG. Esta trazabilidad es importante para demostrar control y seguimiento del pipeline.
La vista Graph del DAG permite visualizar las dependencias entre tareas. Esta imagen cierra la memoria mostrando cómo Airflow orquesta las comprobaciones y fases del pipeline.
Problemas Encontrados y Soluciones Aplicadas
- Gestión de permisos y rutas entre contenedores: se resolvió ajustando volúmenes y rutas compartidas.
- Conexión entre servicios: se validó progresivamente con terminal, notebooks y paneles web.
- Organización de datos: se estructuró el almacenamiento en capas para diferenciar datos brutos, procesados y analíticos.
- Visualización desde Superset: se configuró el origen de datos y se validó mediante SQL Lab antes de construir el dashboard.
- Orquestación en Airflow: se revisó el registro del DAG y sus detalles hasta confirmar que el pipeline quedaba disponible.
Conclusión Final
El proyecto demuestra la construcción de una arquitectura Big Data completa aplicada a un caso IoT real. Se integran captura física de datos, almacenamiento, transformación, consulta, visualización y orquestación en un entorno reproducible basado en contenedores. La solución permite comprobar el ciclo completo del dato desde el sensor hasta el dashboard final.