Uso compartido de modelos en áreas de trabajo
Importante
Databricks recomienda usar Modelos en Unity Catalog para compartir modelos entre áreas de trabajo. El enfoque de este artículo está en desuso.
Azure Databricks admite el uso compartido de modelos en varias áreas de trabajo. Por ejemplo, puede desarrollar y registrar un modelo en un área de trabajo de desarrollo y, después, acceder a él y compararlo con los modelos de un área de trabajo de producción independiente. Esto resulta útil cuando varios equipos comparten acceso a modelos o cuando su organización tiene varias áreas de trabajo para controlar las distintas fases de desarrollo. Para el desarrollo y la implementación de modelos entre áreas de trabajo, Databricks recomienda el enfoque de implementación de código, donde el código de entrenamiento del modelo se implementa en varios entornos.
En situaciones de varias áreas de trabajo, puede acceder a modelos en áreas de trabajo de Azure Databricks mediante un registro de modelos remoto. Por ejemplo, los científicos de datos podrían acceder al registro del modelo de producción con acceso de solo lectura para comparar sus modelos en desarrollo con los modelos de producción actuales. Aquí se muestra un ejemplo de una configuración de área de trabajo múltiple.
El acceso al registro remoto se controla con tokens. Cada usuario o script que necesita acceso crea un token de acceso personal en el registro remoto y copia ese token en el administrador de secretos de su área de trabajo local. Cada solicitud de API enviada al área de trabajo del registro remoto debe incluir el token de acceso. MLflow proporciona un mecanismo sencillo para especificar los secretos que se usarán al realizar operaciones del registro de modelos.
Nota:
Como procedimiento recomendado de seguridad, cuando se autentique con herramientas, sistemas, scripts y aplicaciones automatizados, Databricks recomienda usar los tokens de acceso personal pertenecientes a las entidades de servicio en lugar de a los usuarios del área de trabajo. Para crear tókenes para entidades de servicio, consulte Administración de tokens de acceso para una entidad de servicio.
Todos los métodos de API, fluida y de cliente, para el registro de modelos, se admiten para las áreas de trabajo remotas.
Requisitos
El uso de un registro de modelos entre áreas de trabajo requiere el cliente de Python de MLflow, versión 1.11.0 o posterior.
Nota:
Este flujo de trabajo se implementa desde la lógica en el cliente de MLflow. Asegúrese de que el entorno que ejecuta el cliente tiene acceso para realizar solicitudes de red, en las áreas de trabajo de Azure Databricks que contienen el registro de modelos remoto. Una restricción común que se coloca en el área de trabajo del registro es una lista de direcciones IP permitidas, que pueden rechazar las conexiones de clientes de MLflow que se ejecutan en un clúster de otra área de trabajo.
Configuración del token de API para un registro remoto
- En el área de trabajo del registro de modelos, cree un token de acceso.
- En el área de trabajo local, cree secretos para almacenar el token de acceso y la información del área de trabajo remota:
- Creación de un ámbito de secretos:
databricks secrets create-scope <scope>. - Seleccione un nombre único para el área de trabajo de destino, que aquí se muestra como
<prefix>. Después, cree tres secretos:databricks secrets put-secret <scope> <prefix>-host: escriba el nombre de host del área de trabajo del registro de modelos. Por ejemplo,https://westus.azuredatabricks.net/ohttps://adb-5555555555555555.19.azuredatabricks.net/.databricks secrets put-secret <scope> <prefix>-token: escriba el token de acceso desde el área de trabajo del registro de modelos.databricks secrets put-secret <scope> <prefix>-workspace-id: escriba el Id. del área de trabajo del registro de modelos, que puede encontrarse en la URL de cualquier página.
- Creación de un ámbito de secretos:
Nota:
Es posible que quiera compartir el ámbito de secretos con otros usuarios, ya que hay un límite en el número de ámbitos de secretos por área de trabajo.
Especificación de un registro remoto
En función del ámbito de secreto y el prefijo de nombre que creó para el área de trabajo del registro remoto, puede construir un URI de registro con el formato siguiente:
registry_uri = f'databricks://<scope>:<prefix>'
Puede usar el URI para especificar un registro remoto para los métodos de API fluida, llamando primero a:
mlflow.set_registry_uri(registry_uri)
O puede optar por especificarlo explícitamente al crear una instancia de MlflowClient:
client = MlflowClient(registry_uri=registry_uri)
Los flujos de trabajo siguientes muestran ejemplos de ambos enfoques.
Registro de un modelo en el registro remoto
Una manera de registrar un modelo es usar la API de mlflow.register_model:
mlflow.set_registry_uri(registry_uri)
mlflow.register_model(model_uri=f'runs:/<run-id>/<artifact-path>', name=model_name)
Puede encontrar ejemplos de otros métodos de registro de modelos en el cuaderno, al final de esta página.
Nota:
El registro de un modelo en un área de trabajo remota crea una copia temporal de los artefactos del modelo en DBFS, en el área de trabajo remota. Quizá quiera eliminar esta copia, una vez que la versión del modelo esté en estado READY. Los archivos temporales se pueden encontrar en la carpeta /dbfs/databricks/mlflow/tmp-external-source/<run-id>.
También puede especificar un valor tracking_uri, para que apunte a un servicio de seguimiento de MLflow en otra área de trabajo, de forma similar a registry_uri. Esto significa que puede realizar una ejecución en un área de trabajo remota y registrar su modelo en el área de trabajo remota actual, o en otra.
Uso de un modelo desde el registro remoto
Puede cargar y usar una versión del modelo en un registro remoto con métodos mlflow.<flavor>.load_model, estableciendo primero el URI del registro:
mlflow.set_registry_uri(registry_uri)
model = mlflow.pyfunc.load_model(f'models:/<model-name>/Staging')
model.predict(...)
O puede optar por especificar explícitamente el registro remoto en el URI de models:/:
model = mlflow.pyfunc.load_model(f'models://<scope>:<prefix>@databricks/<model-name>/Staging')
model.predict(...)
También se admiten otros métodos auxiliares para acceder a los archivos de modelo, como:
client.get_latest_versions(model_name)
client.get_model_version_download_uri(model_name, version)
Administración de un modelo en el registro remoto
Puede realizar cualquier acción en los modelos del registro remoto, siempre y cuando tenga los permisos necesarios. Por ejemplo, si tiene permisos PUEDE ADMINISTRAR en un modelo, puede realizar la transición de una fase de versión del modelo o eliminar el modelo mediante métodos de MlflowClient :
client = MlflowClient(tracking_uri=None, registry_uri=registry_uri)
client.transition_model_version_stage(model_name, version, 'Archived')
client.delete_registered_model(model_name)
Ejemplo de Notebook: registro de modelos remotos
El cuaderno siguiente es aplicable a las áreas de trabajo que no estén habilitadas para el catálogo de Unity. Muestra cómo registrar modelos en el servidor de seguimiento de MLflow desde el área de trabajo actual y registrar los modelos en el Registro de modelos de otra área de trabajo. Databricks recomienda usar Modelos en Unity Catalog para compartir modelos entre áreas de trabajo.