EJECUCIÓN DE PROCESOS MECANIZADOS MEDIANTE SCRIPT DE R

En esta ocasión voy a explicar cómo hacer uso de la capacidad de ejecución de script de R creados en R studio para plantear la ejecución de un proceso mecanizado donde intervenga un modelo genérico serializado vía R sin intervención humana a nivel de ejecución, aunque el modelo haya sido entrenado, desarrollado y serializado en un entorno aparte.

Además aprovecho para comentar una serie de recomendaciones basadas en mi experiencia válidas tanto para R como para Python en la construcción y creación de este tipo de procesos donde la ejecución va a ser on premise.

Aunque el desarrollo que cuento está basado en el anterior esquema con denominaciones (por supuesto) ficticias, en este proceso mezclo datos con origen en SAS con elementos con código R, sin embargo voy a ser descriptivo dando sólo indicaciones, ya que al ser un caso real no puedo compartir demasiado detalle técnicos ni por supuesto datos reales.

Comienzo por el caso de negocio que en sí consiste en crear un proceso que se ejecute automáticamente y sin intervención considerando lo siguiente:

• Paso 1: Diariamente se descarga y prepara información, creando una tabla de variables explicativas con identificación de clientes y distintas columnas que serán variables explicativas de un modelo estadístico (regresión logística, random forest, xgboost, ...)

• Paso 2: Ordenación de la tabla anterior mediante el citado modelo que habrá sido previamente construido y entrenado bajo entorno R (también podría considerarse modelos en Python, para ello habría que usar la librería reticulate y todo sería casi igual)

• Paso 3: Generación de unos conjuntos de salida para que sean leídos por una aplicación de negocio

• Todo lo anterior debe ejecutarse a una determinada hora que podemos suponer que serán las 9.00 a.m

¿Cómo conseguir lo anterior? En este momento conviene observar una serie de consejos a contemplar:

• En primer lugar conviene separar el entorno laboratorio analítico del entorno puesta en producción, esto se podría conseguir creando una simple estructura de carpetas del tipo:

Nota: También podria considerarse una denominación más cercana a los esquemas

MLOps, pero trato creo que así queda más claro, dado el tipo de proceso elegido.

• El entorno datalab es el entorno que se utilizaría para entrenar (en paralelo al proceso de ejecución), desarrolar y documentar el modelo, en general puede constar de una serie de subcarpetas adicionales de las que suelo usar principalmente la siguiente estructura:

Aquí los nombre pueden cambiarse más o menos pero la idea es tener:

- Una carpeta para el código

- Otra para los datos

- Otra para la documentación

- Y para mí la más importante: una carpeta para el modelo serializado que

finalmente sería el llamado por el proceso

Nota: Es normal por ejemplo crear un modelo y posteriormente entrenar otro con

más datos y/o variables, en estos casos conviene que esta carpeta datalab tenga

una denominación del tipo datalab_xx que permita saber cuál es la última versión

que debe considerarse.

• En la carpeta pap (paso a producción) directamente hay código y suelo sencillamente añadir una sub-carpeta adicional:

Es decir una carpeta redundante con la anterior y donde habrá un único modelo

serializado que es el que efectivamente se va a usar en producción. Esta carpeta

sólo contiene un único fichero, modelo serializado que será copia de la versión

entrenada más actual disponible

• Como segundo paso hay que entrenar, documentar y finalmente serializar el modelo que se quiere poner en producción, pero … Probablemente a alguien le pueda haber chocado el concepto “serializar” y eso ¿Qué es exactamente? Pues consiste en generar un archivo, que en este caso será de tipo .R que contenga la información necesaria para que cuando le llegue una tabla con las variables utilizadas en el modelo, sencillamente se aplique el algoritmo que se ha entrenado en el área datalab, de modo que una adecuada serialización a este nivel se consigue mediante el uso de save()

que permite guardar cualquier tipo de objeto, en particular un modelo creado en R.

Así pues, en R al igual que en Python, se puede perfectamente serializar modelos para

ser llamados posteriormente en otro código distinto mediante la función load()

El modelo serializado se guardará por tanto en la estructura: datalab/Rmodel

• En tercer lugar se define el proceso de puesta en producción este proceso es el que va a ser clave y se recomienda lo siguiente:

• Es recomendable definir un código que se puede llamar 01_functions.R que puede contener la lista de librerías necesarias y las funciones que nosotros mismos tengamos que definir para la preparación de los datos.

• Otro código que sulelo definir es 02_process.R aquí está toda la lógica del proceso que suele consistir por lo general en lo siguiente:

• Acceso a los datos y preparación de una tabla con la selección de registros y columnas necesarias para que el modelo genere una determinada probabilidad, predicción, etc

• Llamada mediante load("Rmodel/model.R") del objeto modelo

• Asociación y ordenación de los datos y uso de la instrucción predict() o similar para generar las predicciones del citado objeto modelo

• Generación de las tablas de salida en una carpeta física

En ocasiones y si el proceso es muy largo, conviene separar el 02_process.R en

distintos sub-códigos, esto ayuda a la localización de errores tanto en la creación

del proceso como en su ejecución posterior.

• Un código main.R que llame a los códigos anteriores mediante la instrucción source():

source(“01_functions.R)

source(“02_process.R)

• Y finalmente llega la parte más importante, el poder ejecutar todo lo anterior sin necesidad de ni tan siquiera de abrir Rstudio. Y es que, a día de hoy existen lo que se denomina “robots” u “agentes”, que están diseñados para que puedan ejecutar un fichero que suelo llamar execution.bat, que se crea con el notepad al guardarse como fichero tipo batch. Así pues teniendo un fichero como el anterior hay que dotarlo del siguiente contenido:

• Una ruta válida para un fichero de tu versión de R que se denomina Rscript.exe y que en mi caso se encuentra en:

C:\Program Files\R\R-4.2.1\bin\Rscript.exe

Es justamente la existencia de este ejecutable lo que permite por tanto la

ejecución de scripts basados en R.

• Una ruta a tu fichero main.R que cabe suponer que podría estar en:

C:\modelo\pap\main.R

Pues bien, escribiendo en vuestro fichero exectuion.bat las anteriores rutas

absolutas entre comillas, tendríais preparada ya la ejecución lista para que un

agente ejecute todos los días a la hora prevista el proceso.

Si en vuestra empresa, tienen un servidor on-premise para este tipo de procesos, tan sólo basta con instalar R y las librerías que utilicéis en dicho servidor y seguir estos pasos una vez establecidas las rutas en el fichero .bat, el robot podrá ejecutarlo sin problema.

Antes de terminar algunos consejos:

• A la gente de sistemas (o a quién se encargue posteriormente de la parametrización del agente) hay que pasarle la carpeta denominada pap, esta la moverán a alguna ruta del servidor y la pondrán ahí. Es muy importante que todo lo que esté en R haga uso de rutas relativas, no absolutas, las únicas rutas absolutas a considerar es la que se están en el fichero execution.bat que deberá adaptarse a la máquina que se vaya a utilizar.

• En ocasiones (cuando trabajo con SAS y con algunos formatos más extraños) necesito hacer una descarga previa de datos del servidor SAS donde éstos se hallen y usar la librería haven posteriormente. Todo lo dicho aquí es análogo, sólo que suelo cambiar ligeramente el contenido de la carpeta pap dando lugar a una estructura como sigue, compliance con el esquema expuesto al principio de esta entrada:

Básicamente lo que hago es mover los datos de los servidores SAS a la carpeta data

mediante una gran librería como es sftp que con devtools se puede descargar de:

https://github.com/stenevang/sftp

• En el fichero Rmodel debe estar el fichero serializado modelo que puede llamarse genéricamente como model.R el cual se llamaría desde el 02_process.R mediante load(“Rmodel/model.R) es recomendable crear carpetas tipo datalab cada vez que se genera un modelo y que exista una numeración del tipo datalab_01, datalab_02, … si se hacen varias versiones o mejoras del modelo, de modo que sean el modelo serializado de la versión más elevada el que se copie y pegue en la subcarpeta pap/Rmode con un nombre adecuado pero siempre el mismo, en mi caso suelo usar model.R

• Funciones como Sys.Date() son convenientes de ser utilizadas en 02_process.R de modo que cuando el robot o agente llame al main.R y este a su vez al 02_process.R, permita crear resultados separados por fecha de ejecución para seguimientos posteriores.

• Finalmente cabe indicar que es recomendable ser claros en el código escrito por R y recomiendo usar librarías como dplyr y hacer uso del operador %>% que permite la generación de códigos claros y compactos, siempre y cuándo los claros y compactos seamos nosotros mismo, porque no es cierto que la programación en R sea más o menos legible o compleja que en Python, es sencillamente el que crea el código, el que hace que este pueda ser realmente legible o un auténtico horror