En este post vamos a ver cómo montar nuestro Azure DataLake Storage Gen2 production ready utilizando Databricks Secret Scopes y Azure Keyvault

Vamos a partir de esta situación de entrada:

databricksecb
NOTA: Asumiremos que tenemos ya creado nuestro Azure Databricks workspace, nuestro Storage Account y un Azure KeyVault.
Montar datalake en Databricks production ready

Crear service app y secret

Para poder vincular nuestro datalake a databricks, necesitamos generar un token de seguridad, asignarle permisos y luego usarlos desde nuestro Databricks workspace. Lo primero por tanto es generar un service app y un secret:

databrick workspace

IMPORTANTE: En el último paso hemos creado un secret. Recuerda apuntar en algun sitio de forma temporal el “Value” porque no podras acceder a él nunca más y lo vamos a necesitar en el futuro para guardarlo en Azure KeyVault.

Asignar permisos en datalake a nuestro service app

Ahora que ya tenemos el service app creado y nuestro secret, vamos a asignarle permisos a nuestro datalake. Para ello, vamos a la sección de “Storage account” en la pestaña de “Access Control” y seleccionamos “Add role assigmnent”. Lo que tendremos que hacer es asignar a nuestro service app el permiso de “Storage Blob Data Contributor”.

service app

NOTA: El service app, ahora puede acceder a todo el datalake, nos falta poder entonces usarlo desde databricks

Databricks secret scope

Un databricks secret scope es un almacen que sirve para guardar de forma segura datos críticos y poder referenciarlos desde nuestros notebooks sin conocer sus valores. La idea será almacenar finalmente en un recurso de seguridad externo (como Azure KeyVault) nuestras credenciales (la que acabamos de crear), y luego poder referenciarlas desde nuestros notebooks de forma segura para que nadie pueda verlas y de esta forma acceder desde fuera a nuestro datalake.

Lo primero por tanto será disponer de nuestro Azure KeyVault.

Crear KeyVault

La forma correcta de almacenar nuestros secrets va a ser utilizar Azure Keyvault, porque así lo tenemos desde fuera del cluster Databricks. Lo primero que haremos es crearnos un Azure KeyVault para almacenar nuestras credenciales de nuestro Storage Account. Si no tienes uno, crealo. Vamos a asumir que lo tenemos ya creado.

Una vez tengamos el keyvault vamos a linkarlo a nuestro databricks secret scope.

Crear los secrets que vamos a necesitar

Vamos a necesitar los siguientes valores para montar nuestro datalake desde Databricks:

  • databricks-app-client-id: Es el client id de nuestro service app
  • databricks-app-tenant-id: Es el tenant id de nuestro service app
  • databricks-app-client-secret: Es el valor que hemos generado para nuestro secret en el service app

Por tanto, vamos a ir a nuestro KeyVault y los vamos a añadir:

keyvault ecb

Generar nuestro Databricks secret scope

Ahora, vamos a aprovechar que tenemos los datos necesarios ya listos en KeyVault, para generar nuestro secret scope y permitir que haga uso de ellos. Lo primero será entrar en la pantalla de #secrets/createScope de nuestro portal databricks.

Para poder entrar, ves a la url del dashboard de tu databricks, que puedes encontrar aqui:

databricks premium

y le añades al final la coletilla #secrets/createScope

por ejemplo: https://adb-ID.ID2.azuredatabricks.net#secrets/createScope

Una vez dentro, necesitarás de tu KeyVault los valores de DNS y ResourceID, que puedes encontrar aqui:

Montar datalake en Databricks production ready

Y los introduces:

create secret scope

NOTA: Hay una versión de databricks cli que permite hacer todo esto programáticamente

dbutils.secrets.list(“keyvault-ecb-scope”)
dbutils.secrets.get(scope = “keyvault-ecb-scope”,
key = “databricks-app-client-id”)
 
Montar datalake en Databricks production ready

NOTE: En este cluster de ejemplo he deshabilitado la opción de credential Passthrough del cluster por testear que funcione el secret scope correctamente para forzar que no utilice mis credenciales para passthrough

advance options

Montar datalake en databricks

Ya por fin, despues de todo esto podemos ir directamente a montar nuestro volumen:

# get values from secret scope (linked to Azure Keyvault)
storage_account_name = “databricksecb”
client_id = dbutils.secrets.get(scope=“keyvault-ecb-scope”, key=“databricks-app-client-id”)
tenant_id = dbutils.secrets.get(scope=“keyvault-ecb-scope”, key=“databricks-app-tenant-id”)
client_secret = dbutils.secrets.get(scope=“keyvault-ecb-scope”, key=“databricks-app-client-secret”)
 
# Define config values to mount the datalake
configs = {“fs.azure.account.auth.type”: “OAuth”,
“fs.azure.account.oauth.provider.type”: “org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider”,
“fs.azure.account.oauth2.client.id”: f“{client_id}”,
“fs.azure.account.oauth2.client.secret”: f“{client_secret}”,
“fs.azure.account.oauth2.client.endpoint”: f“https://login.microsoftonline.com/{tenant_id}/oauth2/token”}
 
# define the mount function
def mount_adls(container_name):
dbutils.fs.mount(
source = f“abfss://{container_name}@{storage_account_name}.dfs.core.windows.net/”,
mount_point = f“/mnt/{storage_account_name}/{container_name}”,
extra_configs = configs)
 
# Mount the datalake

Y para probar, podemos ver contenido existente en el container que ya tengo en mi datalake, llamado “raw”, donde he subido un fichero (%fs ls /mnt/databricksecb/raw)

Finalmente, todo OK.

Montar datalake en Databricks production ready

A partir de ahora, este cluster ya tiene el volumen montado para poder trabajar con normalidad.

¡Sigue Aprendiendo!

Si quieres que te ayudemos a poner en marcha este tipo de proyecto, no dudes en contactar con nosotros. También puedes aprovechar las formaciones existentes para ampliar tus conocimientos 👇🏼

>> Más info
0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada.

You May Also Like
Leer más

Backups y restores “al vuelo” sin almacenamiento intermedio

Seguramente los más “senior” recordarán la posibilidad que existía en versiones SQL Server antiguas de realizar backups utilizando named pipes. Cuando hablo de versiones antiguas, me refiero a “antiguas de verdad”, ya que esta funcionalidad fue marcada como obsoleta en SQL Server 7, se mantuvo en SQL 2000 pero ya se eliminó de SQL Server 2005 y posteriores.