El documento presenta un caso práctico para integrar datos de ventas de una empresa cliente en su data lake. Se requiere implementar procesos ETL para ingestar y procesar los datos, desarrollar un modelo de machine learning y diseñar un proceso de MLops para recalibrar el modelo cuando sea necesario. El candidato debe entregar código para los ETLs, una API para el modelo y diagramas para el diseño de MLops, además de responder preguntas de teoría sobre Spark, almacenamiento en la nube y procesos de desarrollo.
0 calificaciones0% encontró este documento útil (0 votos)
62 vistas4 páginas
El documento presenta un caso práctico para integrar datos de ventas de una empresa cliente en su data lake. Se requiere implementar procesos ETL para ingestar y procesar los datos, desarrollar un modelo de machine learning y diseñar un proceso de MLops para recalibrar el modelo cuando sea necesario. El candidato debe entregar código para los ETLs, una API para el modelo y diagramas para el diseño de MLops, además de responder preguntas de teoría sobre Spark, almacenamiento en la nube y procesos de desarrollo.
El documento presenta un caso práctico para integrar datos de ventas de una empresa cliente en su data lake. Se requiere implementar procesos ETL para ingestar y procesar los datos, desarrollar un modelo de machine learning y diseñar un proceso de MLops para recalibrar el modelo cuando sea necesario. El candidato debe entregar código para los ETLs, una API para el modelo y diagramas para el diseño de MLops, además de responder preguntas de teoría sobre Spark, almacenamiento en la nube y procesos de desarrollo.
El documento presenta un caso práctico para integrar datos de ventas de una empresa cliente en su data lake. Se requiere implementar procesos ETL para ingestar y procesar los datos, desarrollar un modelo de machine learning y diseñar un proceso de MLops para recalibrar el modelo cuando sea necesario. El candidato debe entregar código para los ETLs, una API para el modelo y diagramas para el diseño de MLops, además de responder preguntas de teoría sobre Spark, almacenamiento en la nube y procesos de desarrollo.
Descargue como PDF, TXT o lea en línea desde Scribd
Descargar como pdf o txt
Está en la página 1/ 4
Examen - Machine Learning Engineer
Instrucciones generales ● Tienes tres días naturales para devolver tus respuestas a partir de que recibes este documento. ● Si el tiempo no te es suficiente, envía todo lo que alcances a responder; es preferible que mandes una parte a que no mandes nada. ● Puedes contactar al equipo para cualquier duda técnica que tengas, escribe a f.vaquero@opianalytics.com y f.mekler@opianalytics.com, copiando a Recursos Humanos (e.remy@opianalytics.com & d.fraide@opianalytocs.com).
1. Caso práctico 1.1. Contexto Nuestro cliente Tamal Inc. necesita integrar fuentes de datos que describan sus ventas en el mercado. La información vive en su Data Lake y el equipo de ingeniería de datos de OPI se encarga de homologarlas para exponerlas en un cubo de datos en formato estrella que permite a sus empleados generar reportes. El data lake está dividido en 2 zonas que almacenan los datos con base en su madurez. Las zonas del data lake son: ● Crudo: Los datos se guardan en los archivos de entrada de una forma ordenada y que permite tener trazabilidad respetando formatos y estructuras de datos originales. ● Procesado: En esta zona se guardan los datos refinados que se toman de la zona de datos crudos y están listos para ser consumibles por las interfaces que llevan los datos al usuario final.
Las dos fuentes de datos que se deben integrar son:
● Ventas reportadas por ERP: Datos internos generados por Tamal Inc y almacenados en su sistema ERP donde registran las ventas de sus productos realizadas por los revendedores. Los datos se actualizarán en el data lake de forma semanal y contienen información del último mes en cada una de las actualizaciones. No existe una conexión directa con el ERP y la información que se ingresa al data lake se comparte en formato csv. ● Ventas y precios de campo: Datos generados por la empresa Inventada Sa de CV, dedicada a levantar datos de campo sobre los productos de sus clientes y la competencia. En el dataset se registran las ventas en el punto de venta de los productos de Tamal Inc y, además, los precios de sus productos y la competencia. Estos datos se actualizan de forma semanal y contienen información del último mes en cada actualización. Inventada Sa de CV comparte la información para ingesta al data lake en formato xlsx.
1.2. Bases de datos
Te compartimos las bases de datos en orden de prioridad, todas tienen la misma información, pero preferimos que uses Azure, seguida de AWS y, en última instancia, Drive. Opción Azure ● Enlace a la base de datos ● Debes usar esta liga para conectarte a los datos por medio del Azure Storage Explorer ● Y aquí están los pasos para conectarte al explorador
Opción AWS ● s3://tamales-inc ● Para descargar la información a través de Amazon instala esta herramienta
Opción Drive ● Liga
1.3. Entregables Como parte del equipo de ingeniería de datos de OPI Analytics, se requiere lo siguiente.
1.3.1. ETLs Implementar un proceso de ingesta de datos en el data lake que garantice la correcta actualización de los datos hasta el nivel de madurez “procesado”. Las métricas a integrar en la capa de “procesado” del data lake son: ● Ventas mensuales ● Ventas mensuales acumuladas ● Diferencia % vs el mes anterior
Considerar: ● Versionar los cambios de los datos en el tiempo. ● Conservar el estado original de los datos para trazabilidad. ● La información de ventas del ERP es cargada de forma manual por un responsable del ERP. ● Los pipelines de datos necesitan ser ejecutados por un orquestador de datos (ej, datafactory, airflow, luigi, AWS glue) ● Los pipelines deben estar parametrizados para soportar re-procesamiento de datos. ● La tecnología de almacenamiento del data lake es un file system con la siguiente estructura de carpetas: ○ ./crudo/generador/fuente/AAAAMMDD/ ○ ./procesado/generador/fuente/AAAAMMDD/
Entregables: ● Proceso de ingesta de datos. Nos gustaría ver código de extracción y código de orquestación. ● Como bonus, los diagramas son bienvenidos. 1.3.2. Modelo El equipo tiene un mes para crear un primer MVP del modelo para ser consumido a través del API. Es importante hacer pruebas de conectividad antes de enfocarnos en la eficacia del modelo.
El modelo de Machine Learning es: f(x, y) = log(ventas) x random + peso_por_categoria_calorica
Donde: ● Random existe de -1 a 1 ● El peso por categoría es {regular: 1.5, light: 0.5}
Considerar: ● La función expresada con el modelo de ML no es relevante para el proceso, no es necesario preocuparse por la precisión del mismo para este ejercicio en particular. ● peso_por_categoria_calorica viven dentro de una base de datos. ● La evaluación del modelo se tiene que hacer a través de una API de consumo, no tiene restricciones de tiempo de respuesta, concurrencia, etc. ● El modelo debe ser agnóstico al proveedor o ambiente de cómputo en la nube. ● Hay 3 científicos de datos trabajando en el mismo modelo. ● Tomar en cuenta la automatización del proceso de entrenamiento y posibles cambios del modelo.
Entregables: ● API en Flask, FastAPI o similar, en formato Json con el resultado de la predicción.
1.3.3. Diseño El caso de uso requiere que el equipo de OPI recalibre el modelo de machine learning, pero sólo en caso de ser necesario. Esto quiere decir que se re-calibra el modelo solo si el modelo deja de predecir adecuadamente. En el momento en que se detecta que tenemos que re-calibrar el modelo, tenemos 48 horas para hacer ajustes y actualizarlo. Nuestro modelo lleva más de 1 año funcionando.
El equipo necesita una propuesta de pasos y tecnología para el caso descrito anteriormente.
Considerar: ● Como todo en la vida, los recursos y el tiempo son finitos. Tienes que versionar el alcance y comunicar cuáles son los pros y contras de tu propuesta. ● Si hay puntos que no puedes cubrir con tu diseño, comunícalos. Es preferible que los detectes y comuniques, a que intentes solucionar todo.
Entregables: ● Diagrama de solución ● Diagrama de flujo de la información ● SLAs de cada propuesta ● Diseño de proceso de MLops para el modelo. Se recomienda fuertemente el uso de herramientas especializadas para el gobierno de ciclos de vida de modelos de ML (ej. kubeflow, azure machine learning, etc.) ● Pros y contras de la solución (por ejemplo, calidad, escalabilidad, tolerancia al cambio, etc.)
2. Teoría general (bonus)
En un archivo aparte, manda todas las respuestas que puedas a las siguientes preguntas. Si son correctas, serán consideradas como bonus.
1. ¿A que se refiere el concepto de lazy evaluation bajo el contexto de Spark?
2. ¿Cuál es la diferencia entre partitioning y bucketing en Spark? 3. ¿Como se puede minimizar la transferencia de datos nodos de un clúster Spark para una tarea? 4. Cual de las siguientes opciones es una limitación de uso para Spark. a. Cuenta con un precario procesamiento en memoria. b. Manejo limitado de sesiones concurrentes. c. Baja latencia en los procesos distribuidos. 5. ¿En qué casos debemos usar filesystem, hadoop o blob containers (s3, adsl gen2, etc.) como medio de almacenamiento? 6. ¿Cuál es la diferencia entre Azure Blob Storage y Azure File Storage? 7. ¿Cuál es la diferencia entre CI y CD? 8. ¿Cuál es la diferencia entre MLOps y Devops? 9. Explica 3 elementos que un buen proceso de MLOps punta a punta (desde extracción de datos hasta consumo del modelo) debe cuidar y por qué. 10. ¿Qué flujo de trabajo seguirías si tuvieras un desarrollo conectado con CICD y tuvieras un 90% de cobertura en el código. a. Trunk base b. Gitflow c. TDD 11. ¿Cómo garantizas el lineaje de datos y el linaje de modelos? 12. ¿Cómo se relaciona con gobierno de datos? 13. Selecciona 3 herramientas indispensables para tener un buen manejo de modelos y explica por qué las seleccionaste.
