Compartir a través de


Asignar recursos de cómputo a un grupo

Importante

Esta característica está en versión preliminar pública.

En este artículo se explica cómo crear un recurso de cómputo asignado a un grupo utilizando el modo de acceso dedicado.

El modo de acceso de grupo dedicado permite a los usuarios obtener la eficacia operativa de un clúster de modo de acceso estándar, a la vez que admite lenguajes y cargas de trabajo que no son compatibles con el modo de acceso estándar, como Databricks Runtime para ML, Spark Machine Learning Library (MLlib), API de RDD y R.

Al habilitar la versión preliminar pública del clúster dedicado de grupo, el área de trabajo también tendrá acceso a la nueva interfaz de usuario de computación simplificada. Esta nueva interfaz de usuario actualiza los nombres de los modos de acceso y simplifica la configuración de proceso. Consulta Uso del formulario sencillo para administrar el proceso.

Requisitos

Para usar el modo de acceso de grupo dedicado:

  • Un administrador del área de trabajo debe habilitar la previsualización de Compute: clústeres de grupos dedicados mediante la Interfaz de Usuario de Previsualizaciones. Consulta Administración de las versiones preliminares de Azure Databricks.
  • El área de trabajo debe estar habilitada para el catálogo de Unity.
  • Debe usar Databricks Runtime 15.4 o superior.
  • El grupo asignado debe tener permisos CAN MANAGE en una carpeta del área de trabajo donde pueden mantener cuadernos, experimentos de ML y otros artefactos de área de trabajo usados por el clúster de grupo.

¿Qué es el modo de acceso dedicado?

El modo de acceso dedicado es la versión más reciente del modo de acceso de usuario único. Con el acceso dedicado, se puede asignar un recurso de proceso a un solo usuario o grupo, solo permitiendo el acceso de los usuarios asignados para usar el recurso de proceso.

Cuando un usuario está conectado a un recurso de proceso dedicado a un grupo (un clúster de grupos), los permisos del usuario se reducen automáticamente a los permisos del grupo, lo que permite al usuario compartir de forma segura el recurso con los demás miembros del grupo.

Crea un recurso de cálculo dedicado a un grupo

  1. En el área de trabajo de Azure Databricks, ve a Proceso y haz clic en Crear proceso.
  2. Expanda la sección Avanzado.
  3. En el Modo de acceso, haz clic en Manual y, después, selecciona Dedicado (anteriormente: Usuario Único) en el menú desplegable.
  4. En el campo usuario único o grupo, seleccione el grupo que desea asignar a este recurso.
  5. Configure las demás opciones de proceso deseadas y haga clic en Crear.

Procedimientos recomendados para administrar clústeres de grupos

Dado que los permisos de usuario se limitan al grupo al usar clústeres de grupo, Databricks recomienda crear una carpeta de /Workspace/Groups/<groupName> para cada grupo que planea usar con un clúster de grupos. A continuación, asigne permisos CAN MANAGE en la carpeta al grupo. Esto permite a los grupos evitar errores de permisos. Todos los cuadernos y recursos del área de trabajo del grupo deben administrarse en la carpeta del grupo.

También debe modificar las siguientes cargas de trabajo para que se ejecuten en clústeres de grupo:

  • MLflow: asegúrese de ejecutar el cuaderno desde la carpeta de grupo o ejecutar mlflow.set_tracking_uri("/Workspace/Groups/<groupName>").
  • AutoML: establezca el parámetro opcional experiment_dir en “/Workspace/Groups/<groupName>” para las ejecuciones de AutoML.
  • dbutils.notebook.run: asegúrate de que el grupo tiene el permiso READ en el cuaderno que se está ejecutando.

Permisos de grupo de ejemplo

Al crear un objeto de datos mediante el clúster de grupo, el grupo se asigna como propietario del objeto.

Por ejemplo, si tiene un cuaderno asociado a un clúster de grupo y ejecuta el siguiente comando:

use catalog main;
create schema group_cluster_group_schema;

A continuación, ejecute esta consulta para comprobar el propietario del esquema:

describe schema group_cluster_group_schema;

Descripción de ejemplo del esquema de grupo

Grupo de auditoría dedicado a la actividad de cómputo

Hay dos identidades clave implicadas cuando un clúster de grupo ejecuta una carga de trabajo:

  1. Usuario que ejecuta la carga de trabajo en el clúster de grupo
  2. El grupo cuyos permisos se usan para realizar las acciones de carga de trabajo reales.

La tabla del sistema de registro de auditoría registra estas identidades en los parámetros siguientes:

  • identity_metadata.run_by: el usuario autenticador que realiza la acción
  • identity_metadata.run_as: el grupo autorizador cuyos permisos se emplean para la acción.

La consulta de ejemplo siguiente extrae los metadatos de identidad de una acción realizada con el clúster de grupo:

select action_name, event_time, user_identity.email, identity_metadata
from system.access.audit
where user_identity.email = "uc-group-cluster-group" AND service_name = "unityCatalog"
order by event_time desc limit 100;

Vea la referencia de la tabla del sistema de registro de auditoría para obtener más consultas de ejemplo. Consulte la referencia de la tabla del sistema de registro de auditoría .

Problemas conocidos

  • Los archivos y carpetas del área de trabajo creados a partir de clústeres de grupo dan como resultado que el propietario del objeto asignado sea Unknown. Esto hace que las operaciones posteriores en esos objetos, como read, writey delete, produzcan errores de denegación de permiso.

Limitaciones

La versión preliminar pública del modo de acceso de grupo dedicado tiene las siguientes limitaciones conocidas:

  • Las tablas del sistema de linaje no registran la identity_metadata.run_as (el grupo de autorización) ni las identidades de identity_metadata.run_by (el usuario autenticador) para las cargas de trabajo que se ejecutan en un clúster de grupos.
  • Los registros de auditoría entregados al almacenamiento del cliente no registran el identity_metadata.run_as (el grupo de autorización) ni las identidades de identity_metadata.run_by (el usuario autenticador) para cargas de trabajo que se ejecutan en un clúster de grupo. Debe usar la tabla system.access.audit para ver los metadatos de identidad.
  • Cuando se adjunta a un clúster de grupo, el Explorador de catálogos no filtra solo por recursos accesibles para el grupo.
  • Los administradores de grupos que no son miembros del grupo no pueden crear, editar ni eliminar clústeres de grupos. Solo los administradores del área de trabajo y los miembros del grupo pueden hacerlo.
  • Si se cambia el nombre de un grupo, debe actualizar manualmente las directivas de proceso que hagan referencia al nombre del grupo.
  • Los clústeres de grupo no se admiten para áreas de trabajo con ACL deshabilitadas (isWorkspaceAclsEnabled == false) debido a la falta inherente de controles de seguridad y acceso a datos cuando se deshabilitan las ACL del área de trabajo.
  • El comando %run usa actualmente los permisos del usuario en lugar de los permisos del grupo cuando se ejecuta en un clúster de grupos. Alternativas como dbutils.notebook.run() usan correctamente los permisos del grupo.