Feature Store para activos analíticos
“Calculé el promedio diario, ahhh yo el semanal! 😅” es un problema común al que se enfrenta un equipo de Data Scientists a la hora de calcular features qué se utilizarán para los modelos analíticos.
Cuando no existe una coordinación de equipo (ni gobierno de datos) suele ocurrir esto, lo que a su vez genera innumerables inconvenientes e inconsistencias.
¿Qué es un Feature Store?
Por feature nos referimos a los atributos o propiedades que los modelos de Machine Learning (ML) utilizan durante el entrenamiento y la inferencia para hacer predicciones.
En pocas palabras, el Feature Store representa en nuestro data lake (repositorio de datos almacenados en formato crudo) una capa productiva administrada para construir modelos y análisis.
¿Por qué se hizo necesario contar con esto?
Desde el punto de vista del negocio, alcanzamos un nivel transaccional que hizo necesario responder a las preguntas de retención y crecimiento de base de usuarios mensuales, además de cross-sell de productos, mediante modelos analíticos (ML). Es aquí donde es de vital importancia contar con una base centralizada, única y consistente para todo el equipo de Analytics, que provea de los datos que los modelos necesitan ingestar para responder a las preguntas planteadas.
¿Cómo construimos esto?
En MACH utilizamos AWS como servicio cloud, nuestro equipo de Big Data definió diferentes capas en el data lake que van desde los datos crudos a capas productivas donde encontramos datos que han pasado varios procesos de validación y tests de calidad.
Ahora bien estos datos se encuentran a nivel granular, y el primer paso para responder a las preguntas del negocio fue crear modelos mensuales, por lo tanto necesitábamos crear features mensuales.
En palabras simples creamos jobs en Spark (herramienta analítica para procesar alto volumen de datos) que leen data granular desde una capa productiva, esto utilizando las funcionalidades de AWS Glue (plataforma de cálculo serverless) que te permite leer desde el catálogo de datos,
para luego procesar estos utilizando PySpark.
El siguiente paso consiste en guardar estos datos en formato parquet en una ruta correspondiente de S3 particionada por año-mes. Por cierto para que se cree la tabla en la capa productiva correspondiente se debe crear además un archivo .yaml que contiene el nombre, tipo y descripción de cada campo.
Luego se debe crear un DAG (directed acyclic graph) que básicamente es una colección de todas las tareas que el script debe ejecutar, organizadas de tal forma que reflejan las relaciones y dependencias de las mismas.
Por políticas internas del equipo de Big Data se deben realizar dos fases de test:
- en tú máquina local,
- en un ambiente de desarrollo en cloud.
Cuando estos test han sido exitosos se hace el PR en el repositorio de Github, se aprueba y se comienza a poblar la tabla correspondiente, es decir primero hacemos una carga histórica de las features y luego el DAG queda programado en Airflow para que corra una vez al mes y se agregue la partición correspondiente de manera automática. 🚀
Hoy tenemos 4 familias de features productivas con más de 400 propiedades que caracterizan el comportamiento de nuestros clientes, y vamos por más! 💪
En un siguiente post explicaremos cómo hemos utilizado estas features para entrenar nuestros modelos, la arquitectura que elegimos para entrenar haciendo a la vez tuneo de hyper parámetros y el deploy del modelo para inferencia batch. 🤖
¡Espero que hayas aprendido algo nuevo! Siempre estamos buscando nuevos perfiles. Si te interesó este post y te interesa MACH, ¡hazte parte de nuestro equipo!
Puedes postular acá.
MACH 💜 de Bci para todos!
