tpf-mlapps-ITBA

TP Final del módulo de Machine Learning Applications de la Diplomatura en Cloud Data Engineering de ITBA

---

Contexto:

Acaba de ser contratado como el primer ingeniero de datos de una pequeña empresa de viajes.

Su primera tarea para usted fue demostrar el valor y los conocimientos que se pueden generar a partir de las canalizaciones de datos.

Su plan es que una vez que demuestre lo valiosos que pueden ser los datos, comenzarán a invertir en el uso de un proveedor de instancias en la nube. Por ahora, su propia computadora tendrá que hacerlo.

Objetivo:

Crear un DAG de Airflow que actúe de ETL para extraer datos estáticos de S3 y los cargue en una base de datos de Postgres. Para llevar a cabo el desarrollo se utilizará el dataset de demoras y cancelaciones de viajes aéreos de Kaggle. Se deben cumplir los siguientes pasos:

1. Configurar Airflow para que corra en AWS.
2. Crear una instancia RDS de Postgres.
3. Desarrollar un DAG de Airflow con schedule anual que realice detección de anomalías para identificar por cada aeropuerto si hubo algún día con demoras fuera de lo normal, por cada aeropuerto produzca un gráfico desde Python en el cual se pueda ver la cantidad de vuelos de cada día con alguna indicación en los días que fueron considerados anómalos y almacénelo en S3 en un path fácilmente identificable por año y aeropuerto analizado, luego se debe cargar la data sumarizada junto con un indicador de dato anómalo.
4. Desarrollar una visualización de los datos cargados.

Para más detalle sobre las consignas ver el archivo Consignas.md.

---

Arquitectura del trabajo desarrollado

El diagrama de aquitectura se puede observar en el archivo Architecture.png. La arquitectura de este proyecto se compone de los siguientes elementos:

• Terraform: se optó por utilizar terraform para aprovisionar y desaprovisionar la totalidad de la arquitectura para poder automatizar esta instancia y evitar de esta manera costos extras por recursos sin eliminar o creados de forma incompleta o erronea.

• Bucket de S3: en este bucket se descargará la data desde el sitio de Kaggle, además de contener los archivos necesarios para configurara Airflow (DAGs creados y arquivos de requerimiento de librerías de python).

• VPC y 3 capas de subnets en 2 AZs diferentes: una capa de subnets públicas fue creada para colocar NAT Gateways y el Load Balancer necesario, la primera capa de subnets privadas representa la capa de aplicación con el servicio de Superset, la tercera capa de subnets privadas incluye la base de datos y el server de Airflow.

• Instancia de RDS-postgres: La base de datos se encuentra ubicada en una capa de subnets privadas, idealmente en Multi-AZ para aumentar la disponibilidad (auqne en el proyecto no se habilitó esta opción por un tema de costos).

• MWAA: se optó por utilizar Managed Workflows for Apache Airflow en lugar de montar manualmente Apache Airflow en una capa de cómputo de cualquier tipo, para poder experimentar cómo es el funcionamiento de esta herramienta open source siendo casi totalmente administrada por Amazon.

• Secrets Manager: se utilizó este recurso como Secret Backend para Airflow, consiguiendo de esta forma generar automáticamente las credenciales de conección a la instacia de RDS.

• Cluster de ECS: en este cluster se encuentra corriendo el servicio de Superset montado desde una imagen de docker pública. Se optó por esta herramienta de visualización ya que utilizar QuickSight para conectarse a la base de datos que se encuentra montada en subnets privadas era necesario habilitar una licencia bastante costosa. Se seleccionó una imagen de Superset reducida a un solo container, ya que para este proyecto no era necesario tanto poder de cómputo, pero si fuera necesario se podría reemplazar ECS por EKS y sobre Kubernetes montar todos los componentes individuales de esta herramienta (cache db, workers, database, etc...).

• Application Load Balancer: para poder acceder al servicio de Superset se montó un LB apuntando al servicio de ECS.

• IAM roles y policies: fue necesario crear un rol y policies específicas para MWAA, además de agregar algunas policies a roles existentes.

Data Flow

En el diagrama del archivo DataFlow.png se puede observar el flujo de los datos, siguiendo el siguiente esquema: - Se descargan los datos en formato CSV de internet al bucket mencionado. - Airflow toma los datos de dicho bucket, los procesa y genera dos salidas: imagenes que guarda en el mismo bucket, info estructurada que guarda en RDS. - Desde el servicio de Superset se puede acceder a los datos almacenados en la BD para realizar visualizaciones.

Instrucciones para correr el proyecto

Se pueden seguir las instrucciones detalladas en el archivo Instrucciones.md.

Sobre el desarrollo del proyecto

El proyecto fue desarrollado en etapas para poder organizar mejor el trabajo y poder realizar las pruebas necesarias de forrma efectiva. Las etapas fueron pensadas en 3 estadíos generales:

• DEV: exploración de los datos y desarrollo de la lógica del DAG para procesamiento de los mismos. La arquitectura esta montada en containers de docker de modo provisiorio para avanzar con el desarrollo. Se optó por un algoritmo simple basado en la distribución normal del tiempo de delay diario y por aeropuerto, marcando como anómalos aquellos datos que se encuentren por fuera de los 3 desvíos (valor que cubre aprox el 98% de los datos).

• TEST: una vez finalizado el desarrollo de la lógica, se comenzaron a hacer pruebas con la arquitectura específica, para ello se utilizó un container específico llamado Local-Runner brindado por AWS (info en este link).

• PROD: finalmente se crearon las plantillas de terraform y se realizaron las pruebas y ajustes sobre la arquitectura final.

Para poder ir avanzando en los distintos estadíos se utilizáron 3 branches de git que pueden encontrarse en este proyecto (a excepcion de la branch de prod que será mergeada en main). Para conocer un detalle mayor sobre los pasos efectuados y las problematicas resueltas en las instancias de DEV y PROD, pueden encontrarse los archivos Steps_DEV.md y Steps_TEST.md en las respectivas ramas.

A modo de resumen, algunas cuestiones que tuvieron que irse sorteando hasta conseguir la arquitectura final:

• exploración de los datos y diseño del algoritmo de detección de outliers (outlier_detection.py)

• diseño del modelo de datos a persistir en la BD (models.py)

• diseño y codificación de los gráficos por año y aeropuerto (plot.py)

• conexión a la base de datos desde el DAG de Airflow (db_connections.py)

• funciones varias para conectar el DAG de Airflow con el bucket, recuperar y guardar objetos (functions.py, referencias: AWS example code, Pandas r/w from S3, Upload plot to S3)

• opciones de configuración de Airflow en MWAA (referencias: configuring-env-variables)

• configuración del secret backend para Airflow (referencias: Move your Apache Airflow connections and variables to AWS Secrets Manager, connections-secrets-manager, Airflow connections)

• aprender a utilizar aws cli2 para aprovisionar infraestructura (referencias: Install AwsCli2, Documentación AWS Cli2, Create Bucket, ...)

• aprender a utilizar Terraform con AWS (The Infrastructure Developer's Guide to Terraform: AWS Edition, Build Infrastructure - Terraform AWS Example, Module Composition, Provisioners)

• creacion del environment de MWAA con terraform (referencias: MWAA Environment, terraform-aws-mwaa)

• intento de utilizar QuickSight para acceder a la base de datos en subnets privadas, verificando que la opcion solo se encuentra disponible con QS Enterprice Edition (referencias: Connecting to a VPC with Amazon QuickSight)

• busqueda de una versión de Superset para Docker (referencias: installing-superset-using-docker-compose, apache/superset, tylerFowler/docker-superset)

Para ver capturas de la arquitectura creada y corriendo se puede acceder a esta carpeta compartida.