Procesamiento de Datos de Robots a Escala con R y Kubernetes

Soy el Director de Datos en Expantia, y ayudamos a las organizaciones a impulsar su capacidad de análisis de datos. Esta charla fue preparada junto con Flodian Pistoni. Flodian es el cofundador y CEO de Inorbit, y Inorbit es una plataforma de gestión en la nube, una plataforma de gestión de robots en la nube y están desarrollando aún más para llevar las operaciones de robots a un nivel más alto. Porque los robots están en todas partes ahora, dondequiera que mires, aún más ahora con COVID, están trabajando junto con los humanos, están trabajando de manera autónoma. Y esto significa que el volumen de los data que estamos recopilando de los robots está aumentando exponencialmente. Por supuesto, esto ofrece oportunidades muy interesantes para nosotros, los científicos de datos, trabajar con este tipo de data que tiene características especiales. Y si miramos lo que Inorbit ha estado haciendo, han acumulado más de 3.8 millones de horas de datos de robots en los últimos 12 meses solamente. Y están creciendo rápidamente, ¿verdad? Así que ahora están agregando aproximadamente un año de data cada día. Y para nosotros, hacer análisis sobre eso, aunque esta es una charla breve, de manera muy resumida, pero quiero resaltar algunos de los problemas que encontramos y cómo los hemos resuelto. El principal problema que encontramos es que Inorbit ofrece sus servicios a cualquier flota. No tenemos control sobre cómo exactamente se recopilan esos data y cómo se envían al servicio central. Así que en una de las pruebas de concepto que hicimos, nos enfrentamos a muchos robots que estaban enviando millones de archivos, ¿verdad? Un archivo cada cinco segundos para cada agente. Pero cada archivo contenía data de múltiples fuentes. Y cada una de esas fuentes estaba en

robots o operaciones en el agente. Tenían sus propias marcas de tiempo. No estaban directamente relacionados. Entonces, el primer paso que necesitábamos hacer era la extracción de data. Y esto fue un poco más complejo de lo que esperábamos, especialmente porque necesitábamos unir observaciones por la marca de tiempo más cercana. Destacaré eso un poco más en una diapositiva posterior. Y luego realizar la ingeniería de características sobre eso. Entonces, lo que quiero decir con la unión de tiempo más cercana, tenemos diferentes señales sobre la localización de la misión y la velocidad. Y necesitamos encontrar un intervalo donde podamos unir cada una de esas señales para tener una sola observación. Trabajamos en cómo se podía hacer eso. Y luego necesitábamos comenzar la ingeniería de características. Entonces, una vez que tenemos una línea, una observación por unidad de tiempo, queríamos retroceder. Queríamos ver qué sucedió antes de una falla. Hay una falla aquí. Y si retrocedemos digamos 42 segundos, entonces necesitamos hacer eso para cada uno de ellos. Hacer eso y tener en cuenta todos los casos en los que no pudimos incluir el dato, por ejemplo, cuando hubo una falla dentro del marco de tiempo de 42 segundos, fue absolutamente posible. Pero luego nos enfrentamos a un volumen enorme donde nuestra computadora local simplemente dijo que no, esto no será posible. Así que inmediatamente pensamos en externalizar esto a Kubernetes. Configuramos un bucket con los data que se estaban ingresando. Los empaquetamos en archivos zip diarios. Empaquetamos gstuff, Json y gzzips para que sea un poco más manejable y poder transportar los data con mayor facilidad. Y luego externalizamos la extracción completa de data a Kubernetes, un segundo bucket con el resultado intermedio, externalizamos la ingeniería de data, y tenemos el resultado listo para el análisis. Lo que descubrimos es que es mucho más fácil obtener la ayuda de algo llamado Packyderm. Packyderm es un producto, es una empresa. Tienen una versión de código abierto de esto, que es lo que usamos. Y lo que tenemos allí no es un bucket. Lo que tenemos es un archivador. Tenemos un repositorio donde convertimos los data que ingresan y versionamos los data que salen. Hacer este tipo de pipeline de data con versiones significa que si hay un cambio en cualquier punto del pipeline, el resto del pipeline responderá y actualizará automáticamente los data. Esto nos prepara para hacer todo el trabajo pesado una vez que lo llevemos a producción. Solo un vistazo rápido a cómo se ve esto. Creamos pipelines que son muy similares a los archivos de configuración de ustedes y lo clave aquí es que podemos conectar los data en el repositorio, en el repositorio de Pachyderm, PFS es el sistema de archivos de Pachyderm, con lo que estamos ejecutando en nuestro R

script. Debido a que nuestros scripts en R ya estaban paralelizados, pero la paralelización no fue suficiente. Así que ahora pudimos externalizar esto y establecer la preparación de datos que hicimos a continuación, y para cada dato que es el término de Pachyderm para cada unidad de datos en el pipeline, podemos ver si fue exitoso o si falló. Esta es una captura de pantalla de Patrick Santamaria donde hicimos la mayor parte de este trabajo.

Así que poder monitorear a ese nivel lo que está sucediendo con tus datos en la práctica, fue absolutamente genial. La paralelización del código R es fácil. Hay un paquete llamado construido sobre future. Y es muy fácil paralelizarlo. Pasar de un código R paralelo a un pipeline masivamente paralelo es factible. Para nosotros fue mucho más fácil trabajar con Kubernetes a través de eso. Lo otro es que los grandes clústeres son sorprendentemente asequibles, ¿verdad? Trabajamos en un clúster de 80 CPU, 520 gigabytes por menos de $10 por hora. Lo cual fue algo que no habíamos experimentado antes y ahora lo estamos utilizando cada vez más en el trabajo que estamos haciendo. Para el equipo con el que estábamos trabajando en in orbit, esto también tuvo grandes implicaciones. Porque significa que a medida que las flotas crecen, saben que la recolección y el procesamiento de datos se vuelve crítico para ellos. Ahora también saben que entender la escalabilidad de su plataforma completa no tiene por qué ser difícil. Pero escalar el análisis tampoco tiene por qué ser difícil. Y el uso de IA a nivel de flota de robots, ya saben, desbloquea muchas nuevas oportunidades en las que están trabajando arduamente para seguir ofreciendo a sus clientes. Muchas gracias. Espero que esto haya sido útil. Si desean más información, por favor visiten nuestros sitios web, expanded.com o inorbit.ai. Ambos tenemos blogs activos y nos gusta escribir sobre este tema, así que esperamos estar en contacto en el futuro. Así que muchas gracias.