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.