Bundles de ressources Databricks pour les piles MLOps

Vous pouvez utiliser des bundles de ressources Databricks, l’interface CLI Databricks et le référentiel Databricks MLOps Stack sur GitHub pour créer des piles MLOps. Une pile MLOps est un projet MLOps sur Azure Databricks qui suit les meilleures pratiques de production, prêt à l’emploi. Consultez Que sont les packs de ressources Databricks ?.

Pour créer, déployer et exécuter un projet de Piles MLOps, procédez comme suit :

Spécifications

• Assurez-vous que l’espace de travail distant cible dispose de fichiers d’espace de travail activés. Consultez l’article Que sont les fichiers d’espace de travail ?.
• Sur votre machine de développement, vérifiez que l’interface CLI Databricks version 0.212.2 ou ultérieure est installée. Pour vérifier la version de Databricks CLI installée, exécutez la commande databricks -v. Pour mettre à jour votre version de l’interface CLI Databricks, consultez Installer ou mettre à jour l’interface CLI Databricks. (Les bundles ne fonctionnent pas avec les versions Databricks CLI 0,18 et inférieures.)

Étape 1 : Configurer l’authentification

Configurez l’interface CLI Databricks pour l’authentification.

Cet article suppose que vous voulez utiliser l’authentification utilisateur à machine (U2M) OAuth et un profil de configuration Azure Databricks correspondant nommé DEFAULT pour l’authentification.

1. Utilisez l’interface CLI Databricks pour lancer la gestion des jetons OAuth localement en exécutant la commande suivante pour chaque espace de travail cible.

   Dans la commande suivante, remplacez <workspace-url> par votre URL d’espace de travail Azure Databricks, par exemple https://adb-1234567890123456.7.azuredatabricks.net.

   databricks auth login --host <workspace-url>
   

2. L’interface CLI Databricks vous invite à enregistrer les informations que vous avez entrées en tant que profil de configuration Azure Databricks. Appuyez sur Enter pour accepter le nom de profil suggéré, ou entrez le nom d’un profil nouveau ou existant. Tout profil existant portant le même nom est remplacé par les informations que vous avez entrées. Vous pouvez utiliser des profils pour changer rapidement de contexte d’authentification entre plusieurs espaces de travail.

   Pour obtenir la liste des profils existants, dans un autre terminal ou une autre invite de commandes, utilisez l’interface CLI Databricks pour exécuter la commande databricks auth profiles. Pour voir les paramètres existants d’un profil spécifique, exécutez la commande databricks auth env --profile <profile-name>.

3. Dans votre navigateur web, suivez les instructions à l’écran pour vous connecter à votre espace de travail Azure Databricks.

4. Pour voir la valeur du jeton OAuth actuel d’un profil et l’horodatage de l’expiration à venir du jeton, exécutez une des commandes suivantes :

   • databricks auth token --host <workspace-url>
   • databricks auth token -p <profile-name>
   • databricks auth token --host <workspace-url> -p <profile-name>

   Si vous avez plusieurs profils avec la même valeur pour --host, il peut être nécessaire de spécifier aussi les options --host et -p pour permettre à l’interface CLI Databricks de trouver les informations du jeton OAuth correspondant.

Étape 2 : Créer le projet de pack

1. Utilisez des modèles de bundles de ressources Databricks pour créer les fichiers de démarrage de votre projet de Piles MLOps. Pour ce faire, commencez par exécuter la commande suivante :

   databricks bundle init mlops-stacks
   

2. Répondez aux invites à l’écran. Pour obtenir de l’aide sur la réponse à ces invites, consultez Démarrer un nouveau projet dans le dépôt Piles MLOps Databricks sur GitHub.

   La première invite offre la possibilité de configurer les composants de code ML, les composants CI/CD ou les deux. Cette option simplifie la configuration initiale, car vous pouvez choisir de créer seulement les composants immédiatement pertinents. (Pour configurer les autres composants, réexécutez la commande d’initialisation.) Sélectionnez l’un des suivants :

   • CICD_and_Project (par défaut) : configurez à la fois le code ML et les composants CI/CD.
   • Project_Only : configurez seulement les composants du code ML. Cette option permet aux scientifiques des données de bien démarrer.
   • CICD_Only : configurez seulement les composants CI/CD. Cette option permet aux ingénieurs ML de configurer l’infrastructure.

   Une fois que vous avez répondu à toutes les invites à l’écran, le modèle crée les fichiers de démarrage de votre projet de Piles MLOps et les ajoute à votre répertoire de travail actuel.

3. Personnalisez les fichiers de démarrage de votre projet de pile MLOps comme vous le souhaitez. Pour ce faire, suivez les instructions fournies dans les fichiers suivants dans votre nouveau projet :

   Role	Objectif	Docs
   Utilisateurs débutant sur ce référentiel	Comprendre le pipeline ML et la structure du code dans ce référentiel	README.md
   Scientifique des données	Démarrer l’écriture de code ML pour un tout nouveau projet	<project-name>/README.md
   Scientifique des données	Mettre à jour le code ML de production (par exemple, la logique d’apprentissage du modèle) pour un projet existant	docs/ml-pull-request.md
   Scientifique des données	Modifier les ressources ML du modèle de production (par exemple, les travaux d’apprentissage ou d’inférence du modèle)	<project-name>/resources/README.md
   MLOps / DevOps	Configurer CI/CD pour le projet ML actuel	docs/mlops-setup.md

   • Pour personnaliser les expériences, les mappages dans une déclaration d'expérience correspondent à la charge utile de la demande de l'opération de création d'expérience telle que définie dans POST /api/2.0/mlflow/experiments/create dans la référence de l'API REST, exprimée au format YAML.

   • Pour la personnalisation des tâches, les mappages dans une déclaration de tâche correspondent à la charge utile de la demande de l'opération de création de tâche telle que définie dans POST /api/2.1/jobs/create dans la référence de l'API REST, exprimée au format YAML.

     Conseil

     Vous pouvez définir, combiner et remplacer les paramètres des nouveaux clusters de travaux dans des packs à l’aide des techniques décrites dans Remplacer les paramètres de cluster dans les packs de ressources Databricks.

   • Pour personnaliser les modèles, les mappages dans une déclaration de modèle correspondent à la charge utile de requête de l’opération de modèle catalogue Unity telle que définie dans POST /api/2.1/unity-catalog/models dans la référence de l’API REST, exprimée au format YAML.

   • Pour la personnalisation des pipelines, les mappages dans une déclaration de pipeline correspondent à la charge utile de la demande de l'opération de création de pipeline telle que définie dans POST /api/2.0/pipelines dans la référence de l'API REST, exprimée au format YAML.

Étape 3 : Valider le projet de pack

Vérifiez si la configuration du pack est valide. Pour ce faire, exécutez l’interface CLI Databricks à partir de la racine du projet, où se trouve le databricks.yml, comme suit :

databricks bundle validate

Si un résumé de la configuration de l’offre groupée est retourné, la validation a réussi. Si des erreurs sont renvoyées, corrigez-les , puis répétez cette étape.

Étape 4 : déployer le pack

Déployez les ressources et les artefacts du projet dans l’espace de travail distant souhaité. Pour ce faire, exécutez l’interface CLI Databricks à partir de la racine du projet, où se trouve le databricks.yml, comme suit :

databricks bundle deploy -t <target-name>

Remplacez <target-name> par le nom de la cible souhaitée dans le fichier databricks.yml, par exemple dev, test, stagingou prod.

Étape 5 : Exécuter le pack déployé

Les travaux Azure Databricks déployés du projet s’exécutent automatiquement selon leurs planifications prédéfinies. Pour exécuter immédiatement un travail déployé, exécutez l’interface CLI Databricks à partir de la racine du projet, où se trouve le databricks.yml, comme suit :

databricks bundle run -t <target-name> <job-name>

• Remplacez <target-name> par le nom de la cible souhaitée dans le fichier databricks.yml dans lequel le travail a été déployé, par exemple dev, test, stagingou prod.
• Remplacez <job-name> par le nom du travail dans l’un des fichiers .yml dans <project-name>/databricks-resources, par exemple batch_inference_job, write_feature_table_job ou model_training_job.

Un lien vers la tâche Azure Databricks s’affiche, que vous pouvez copier vers votre navigateur web pour ouvrir le travail dans l’interface utilisateur Azure Databricks.

Étape 6 : Supprimer le pack déployé (facultatif)

Pour supprimer les ressources et artefacts d’un projet déployé si vous n’en avez plus besoin, exécutez l’interface CLI Databricks à partir de la racine du projet, où se trouve le databricks.yml, comme suit :

databricks bundle destroy -t <target-name>

Remplacez <target-name> par le nom de la cible souhaitée dans le fichier databricks.yml, par exemple dev, test, stagingou prod.

Répondez aux invites à l’écran pour confirmer la suppression des ressources et artefacts déployés précédemment.