Machine Learning a Gran Escala en Casos Reales

No es de extrañar que la industria tecnológica busca crear soluciones cada día más automatizadas y que ayuden a tomar decisiones de diversas naturalezas ( recomendaciones, proyecciones, estimaciones, decisiones),apoyada en Machine Learning, el asunto es que para generar estas soluciones, esto involucra gran cantidad de procesos previos y posteriores a solamente el Machine Learning, desde adquirir data, procesarla, almacenarla, entrenar modelos, monitorearlos, desplegarlos y reentrenar por mencionar solo algunas.

Tal como en un post anterior comenté, trabajo en una empresa de inteligencia logística llamada https://www.simpliroute.com/ donde una de las aristas en las que me enfoco es en apoyar al área de Machine Learning en el pipeline end-2-end (obtención, limpieza, entrenamiento, despliegue y reentreno).

El problema que se intenta mejorar con Machine Learning es mejorar el input requerido por el algoritmo de VRP — Rich VRP, Un punto relevante, son los tiempos de viajes entre los puntos,información clave para poder hacer una buena planificación de rutas. En palabras simples.

Se realiza una predicción de tiempos de traslado de un vehículo en las calles de la ciudad usando información de señales de GPS que se proyectan para crear un grafo de la ciudad, y de esta forma contar con tiempos de traslado predichos con una mayor precisión a lo que experimentará en conductor en la realidad en la calle.

Esto alimentado en gran medida por los gps históricos que son almacenados en nuestro data warehouse y una de esas razones fue porque usamos airbyte en algunos procesos de obtención.

Primeras soluciones Machine Learning y Big Data en entornos Reales

Para lograr el objetivo de entrenar un modelo de Machine Learning con una base histórica que supera los 7000 millones de gps (con una ingesta diaria muy superior a los 15m de pings) y una volumetría superior a 1tb, no es un problema simple para obtener estadísticas, analizar datos, limpiarlos y esto en un continuo stream de gps (via pubsub-dataflow-bigquery) almacenados finalmente en bigquery.

Para lograr esto han sido una serie de pasos que intentaré resumir. Las fases de análisis de data y features previo a estar ingestadas en bigquery, fueron analizadas por segmentos menores (una submuestra de la gran cantidad de gps que existen, en situaciones idóneas, sin lluvia, protestas, alteraciones varias y solo en un sector), en base a esta misma submuestra se generaron los primeros modelos de Machine Learning y se obtuvieron ciertas métricas.

Se construyeron los siguientes modelos con la data disponible:

• Tensorflow
• RandomForest
• Xgboost
• LinearRegression (Base Line)

Cabe recalcar que para apoyar las métricas y resultados de estos modelos se añadió la herramienta Mlflow que pueden revisar en parte desde el post que intenta apoyar el crecimiento de Mlops.

Y prontamente será lanzado el paper que inició esta solución.

Travel time estimation and prediction using GPS data desarrollado por:

Javiera Morales Benza, Cristian Cortés, Victor Gonzalez y Alvaro Echeverria

Y el big data?

El desafío no es menor, en pocas palabras trabajar 3tb de ram en sistemas distribuidos con un presupuesto controlado, es una tarea que requiere expertise y cuidado (calculado desde dataproc con mllib), más aún cuando tus modelos solo han trabajado en submuestras y los dataset no conocen las series de tiempo generadas por la ingesta de los gps.

Se tomaron decisiones para la siguiente etapa, todo esto fue logrado por la generación de analíticas, pipelines de limpieza de datos y mucho análisis en bigquery (aquí el error y prueba toma un rol relevante en los costos) siendo procesado alrededor de 2.5 petabyte hasta encontrar una solución que nos permita generar un pipeline (5 etapas orquestadas con bigquery y google composer), esto incluyendo la generación de polígonos geográficos en base a latitudes y longitudes de los gps y análisis parcial de outliers en nuestro dataset.

Luego de orquestar la creación de nuestro dataset definitivo, inicia nuestro gran trabajo para entrenar un dataset con aproximadamente unos 4000 millones de registros (aprox 1 tb de tamaño).

Se optó por varios caminos los cuales comentaré.

• Bigquery ML
• Vertex
• Kubeflow
• Spark + Koalas + Mllib + PySpark
• Tensorflow
• Xgboost

Ahora, que aprendimos

Habiendo creado diversos modelos y formas de trabajar modelos con Big Data viene el momento de tangibilizar aprendizaje.

Bigquery

Fue electo como una buena práctica, optar por el camino del automl de bigquery ml, por lo simple de generar un baseline para las métricas, luego de eso un poco de hiper parametrización e intentar desplegar en ambientes productivos (es el proceso que vivimos actualmente), luego del gran camino recorrido es refrescante obtener predicciones en base a nuestro dataset, en no más de 30 min generamos, 2 modelos con diversos parámetros y predicciones de manera casi milagrosa.

Con esto, la presión de cualquier organización para obtener resultados tangibles de modelos de ML se reduce enormemente, los modelos no son perfectos y requieren bastante iteración, pero por esto mismo un resultado rápido puede ayudar a decidir si el problema que intentamos solucionar vale realmente la pena.

Vertex

Nuestras pruebas con vertex realmente no fueron muy satisfactorias, hacer este tipo de auto ml pese a tener un dataset 100% desarrollado y listo para ser tomado, no nos prestó mucha ayuda, entrenamos por más de 10 hrs reiteradas veces, fueron creados diversos dataset con la limitante que no supere los 100gb de tamaño ( lo cual entenderán queda corto para nuestro dataset real).

Kubeflow

Siendo una de mis herramientas favoritas, junto con mlflow, kubeflow y su variante kubeflow pipelines en gcp, nos permitió explorar nuevas soluciones distribuidas, el problema, se requiere conocimiento y dedicación para lograr adaptar los modelos ya creados (salvo los de tensorflow) y al tener un rol más orientado al Data Engineering que al Machine Learning Engineering mi dedicacion a Machine Learning Pipelines no es completa, y la necesidad técnica para adaptar e implementar kubeflow no es una opción realista en Startups en crecimiento ( y tampoco es un trade off que valga la pena evaluar en primeras entregas de un modelo de Machine Learning).

Spark Ecosystem

Dataproc (cluster de spark en gcp) fue una solución que exploramos ampliamente no solo para entrenamiento sino también análisis estadístico que no nos provee de manera simple BQML aquí nuestros resultados fueron buenos, pero al no existir un planteamiento previo sobre, dónde, cómo y cuándo entrenar, la adaptación de librerías a pyspark ( más curva de aprendizaje) o temas como el trabajo en sistemas distribuidos realmente nos dejó un amargo sabor al intentar trabajar en este ecosistema.

Ahora, gracias a gestiones y apoyo del CTO de option que logré interiorizarme un poco más en el ecosistema de Databricks que incluye al igual que dataproc soluciones basadas en Spark pero con un ecosistema ENORME para soluciones de Data Warehousing, Machine Learning y Mlops, pero que involucra altos costos de infraestructura y más aún de capacitación.

Notebooks — Kubernetes — Clusters

La última opción más tradicional al momento de entrenar fue lo ya conocido. hacer entrar 1tb de memoria en computadores es realmente caro y dificil si es que no existe un planteamiento previo para abarcar este problema.

Fue creado un notebook de alto rendimiento que no tuvo resultados en más de 72 hrs lo cual nos desalentó bastante (entendiendo que los procesos no estaban optimizados, pese a solo ser entrenamiento ya que nuestro pipeline de datos ya soluciona todo respecto a la calidad y manejo de datos).

Kubernetes con HPA o Managed instances, nos dejó un sabor similar, muchos recursos, soluciones parciales y muuuuuuuuuuuuchos experimentos en mlflow (es el valor de esta herramienta), no quiero profundizar mucho en esto, pero no logramos entrenar el dataset completo.

Conclusiones

El entrenamiento de Machine Learning en casos de big data implica gran cantidad de recursos, desde el análisis de datos hasta dejar un modelo productivo, en este post no fue cubierto mlops (idealmente con kubeflow o mlflow, quizá kedro) ni los procesos para generar artefactos, ciclo de vida del dato, monitoreo,etc…. lo quiero traspasar es que al no existir una receta clara en cómo Dirigir/Manejar proyectos de ML gran cantidad de empresas desisten de lograr el objetivo de ser Data Driven / Ai Ready / Predictors, el aprendizaje obtenido nos dejó clara 3 cosas que me gustaría plasmar finalmente.

• Todos los roles importan, Data Scientist, Data Engineers, AI/ML Engineers, MLops, Software Engineers, todos tienen un papel que tomar, muchas veces olvidamos que está es una disciplina que involucra tantos conocimientos que es difícil encontrar a alguien que tenga el conocimiento y el entendimiento en cada ecosistema, herramienta y lenguaje de programación (si lo tienes, cuidalo).
• Para taclear problemas de ML partamos por lo simple, un dataset sucio en BigQuery ML (o cualquier herramienta de automl), genera un baseline, llevarlo a producción, monitorea y luego de semanas evalúa si realmente tu modelo soluciona el problema (y analiza si lo puede hacer mejor o no) o realmente una heurística compleja puede solucionar el problema (quiza debiste hacer esto antes de irte por Machine Learning).
• Tomar un camino o filosofía. Lastimosamente hay muchas formas de enfrentar problemas de big data y machine learning, ya sea por autor, proveedor de nube, proveedor de ML, estudios, autoaprendizaje, video tutorial y experiencias anteriores, no existe una receta perfecta y reproducible, seguimos en pañales en esta experiencia y vamos sobre la marcha mejorando, adopta un camino, itera y logra llevar ese modelo a producción, luego evalúa si se pudo mejorar.