Cómo trabajar con R desde Databricks

Introducción

Hace poco tuvimos que preparar una demo para un cliente sobre cómo trabajar con R dentro de Databricks, y me pareció interesante poner por escrito los puntos más relevantes, qué cosas se deben tener en cuenta, etc. ya que, aunque actualmente creo que Python es el rey, si es verdad que aún nos encontramos con muchísimos Data Scientist que trabajan con R.

Lo primero que debemos tener en cuenta, es que tanto Databricks, como su motor de procesamiento Spark, son compatibles de forma nativa con R ya desde sus orígenes, y a poco que hayáis leído de Databricks os sonará esta imagen, yo la he modificado un poco, pero el símbolo de R ha estado ahí desde siempre…

Pero ¿aquí todo R me vale?, pues por desgracia la respuesta es no. Aquí el punto importante es que para trabajar realmente con R en un contexto Big Data con Spark, no nos vale únicamente el, podríamos decir, R Nativo, si no que debemos hacerlo usando las funciones que nos proporciona la librería de SparkR, que son las que nos proporcionan la capacidad de coger nuestros datos y operaciones, distribuirlas en el Clúster y ejecutarlos de forma paralelizada, ya que si no lo que estaríamos haciendo es ejecutar código R en el Driver o MasterNode.

Para terminar de entender este punto, debemos conocer cómo funciona por debajo un clúster de Spark, y que este está compuesto por:

• Una máquina que hace de Driver o MasterNode (El Jefe) 
• Varias máquinas que hacen el trabajo, denominados Executors o WorkerNodes (Los Trabajadores)

Cuando nosotros mandamos una orden o petición al jefe, este se encarga de distribuirla entre los trabajadores para que la ejecuten de forma paralelizada, pero ellos (los trabajadores) sólo saben ejecutar ciertas funciones (las de Spark o en nuestro caso de SparkR), así que todo lo que le mandemos que no sea de esta librería tendrá que ejecutarlo el jefe, ya que los trabajadores no saben cómo hacerlo…

Esto no es algo que pase sólo con R, si quieres trabajar con Python (pandas, Sklearn, etc.) trabajarás sólo en el Driver, y deberás usar la librería PySpark si quieres usar la potencia de Spark.

Resumiendo, debéis tener claro con qué necesitáis trabajar, si es únicamente con R o con R+SparkR, a la hora de crear el Clúster para la ejecución, ya que, si vamos a trabajar con R puro, por favor aseguraros que el Clúster sea de tipo “Single Node”, no paguemos por unos Executor que no usaremos, y si ya necesitamos SparkR, creamos un Clúster normal con sus executors.

R en Databricks

Sigamos avanzando, para trabajar con R o SparkR dentro de Databricks, tenemos 2 formas de hacerlo, una directa o nativa, usando los notebooks que nos proporciona Databricks, y una segunda usando RStudio Server, el cual podemos configurarlo para ejecutarse en Databricks.

Notebooks de R

Para poder ejecutar código R en los Notebooks de Databricks, la forma más sencilla es indicárselo durante la creación de notebook, ya que tenemos la opción de indicarle el tipo o el lenguaje de programación que queremos usar, también le indicaremos el Clúster sobre el que se ejecutará el Notebook, aunque esto luego podremos cambiarlo.

Una vez creado el Notebook, ya está preparado para ejecutar sentencias de R, pero como indicábamos antes, si queremos trabajar con SparkR, sólo debemos cargar la librería de turno (library(SparkR)) y a volar…

Incluso si queréis, podréis trabajar con Shiny, y desplegar vuestras aplicaciones Shiny dentro de Databricks.

RStudio Server

La segunda forma de poder trabajar con R, de forma mucho más… podríamos decir, nativa, es usando RStudio, para ello Databricks nos da la opción de instalar RStudio Server en el Driver con el que podremos trabajar con RStudio de forma web.

Aquí tenéis la descripción detallada y mucha más información. 

Pero como pasos generales, tenemos:

• En primer lugar, tenemos que desplegar un script en una ruta concreta que nos instale el RStudio Server y las librerías si es necesario, para ello en cualquier Clúster que ya tengamos levantado, ejecutáis el siguiente script (el código lo tenéis en la URL de arriba)

script = """#!/bin/bash

set -euxo pipefail
RSTUDIO_BIN="/usr/sbin/rstudio-server"

if [[ ! -f "$RSTUDIO_BIN" && $DB_IS_DRIVER = "TRUE" ]]; then
  apt-get update
  apt-get install -y gdebi-core
  cd /tmp
  # You can find new releases at https://rstudio.com/products/rstudio/download-server/debian-ubuntu/.
  wget https://download2.rstudio.org/server/bionic/amd64/rstudio-server-2022.02.1-461-amd64.deb -O rstudio-server.deb
  sudo gdebi -n rstudio-server.deb
  rstudio-server restart || true
fi
"""

dbutils.fs.mkdirs("/databricks/rstudio")
dbutils.fs.put("/databricks/rstudio/rstudio-install.sh", script, True)

• Dentro de la parte de Init Script, ponemos la ejecución de este script:

dbfs:/databricks/rstudio/rstudio-install.sh

• Por último, una vez que tengamos levantado el Clúster, en la pestaña de APPs podremos abrir la ventana para entrar a nuestro RStudio.

Sobre esta forma de trabajar con RStudio Server, hay dos puntos que me gustaría recalcar.

• La primera es que para poder trabajar con RStudio Server, no nos dejan tener activada la opción de auto-apagado, ya que por definición es una funcionalidad que monitoriza nuestra Clúster, y si ve que lleva parado o inactivo más de X minutos (este valor lo definimos nosotros) lo para. Pero cuando trabajamos con RServer, el Clúster como tal, no es consciente de los que pasa dentro de ese RServer, por lo que para él, es como si no se estuviera haciendo nada, y pasados los X minutos, parará el Clúster, y nos tirará por la borda lo que tuviéramos o estuviéramos ejecutando.

Por ello debemos recordar el apagar manualmente el Clúster al terminar nuestro trabajo, y así no nos encontrarnos con una sorpresa en la factura del mes siguiente…

• La segunda es que cuando entramos, al RStudio, la home que se nos proporciona, es el disco duro de la máquina virtual donde se aloja el RStudio Server, lo cual implica que por definición que es efímero, y todo lo que dejemos ahí cuando apaguemos el Clúster desaparecerá. 

Por ello, debemos hacer un cambio de directorio de trabajo a una ruta de Databricks, que empiezan por “/dbfs/xxxxxxx”

Y aquí lo que almacenemos ya sí persistirá, en este caso, lo mejor sería haber montado previamente una ruta a nuestro DataLake, de forma que todo con lo que trabajemos; scripts, datos de entrada o de salida, modelos, etc. se almacene en nuestro DataLake.

Conclusión

En este post, me he centrado mucho en como ejecutar R en Databricks, pero hay otros puntos que no me gustaría dejar sin mencionar, para que profundicéis en ellos si creéis que os pueden resultar interesantes.

Muchos Analistas o Data Scientist, están acostumbrados a trabajar en local con Excel, CSV, etc., y organizárselo y trabajarlo ellos solos, pero cuando dan el paso a la nube tienen otras capacidades y servicios que les pueden resultar muy interesantes y que deben empezar a conocer tales como:

• Entender cómo funciona el sistema de ficheros de Databricks, y como montar una ruta del DataLake en dbfs y usarla como repositorio global accesible por todos los servicios de Azure.
• DataLakes con ficheros almacenados en formato Parquet o incluso en formato Delta.
• Empezar a hacer uso de MLflow, de forma que puedan tener una gestión “interna” del ciclo de vida de sus modelos, ya sea en el propio Databricks o usando Azure Machine Learning, que por debajo también usa MLflow.

• Empezar a hacer uso de MLOPs, para tener una gestión “externa” del ciclo de vida de sus modelos

Espero que este post sobre R en Databricks os haya parecido interesante y sobre todo útil…