Exporter les données du Workspace

Cette page fournit une vue d'ensemble des outils et des approches pour l'exportation de données et de configurations depuis votre workspace Databricks. Vous pouvez exporter les assets du workspace pour les exigences de conformité, la portabilité des données, les fins de sauvegarde ou la migration de workspace.

Présentation

Les workspaces Databricks contiennent une variété d'assets, notamment la configuration du workspace, les tables gérées, les objets d'IA et de ML, et les données stockées dans le stockage cloud. Lorsque vous devez exporter des données de workspace, vous pouvez utiliser une combinaison d'outils et d'APIs intégrés pour extraire ces assets systématiquement.

Les raisons courantes d'exporter les données du Workspace comprennent :

• Exigences de conformité : respecter les obligations de portabilité des données en vertu de réglementations telles que le GDPR et le CCPA.
• Sauvegarde et reprise après sinistre : création de copies des assets critiques du Workspace pour la continuité de l'activité.
• Migration du Workspace : Déplacement d'assets entre les workspaces ou les fournisseurs de cloud.
• Audit et archivage : Préservation des enregistrements historiques de la configuration et des données du Workspace.

Planification de votre exportation

Avant d’exporter les données de Workspace, créez un inventaire des assets que vous devez exporter et comprenez les dépendances entre eux.

Comprendre les assets du workspace

Votre workspace Databricks contient plusieurs catégories d'assets que vous pouvez exporter :

• Configuration du Workspace : Notebooks, dossiers, repos, secrets, utilisateurs, groupes, listes de contrôle d'accès (ACL), configurations de clusters et définitions de jobs.
• Assets de données : tables gérées, bases de données, fichiers Databricks File System et données stockées dans le stockage cloud.
• Ressources de compute : Configurations de clusters, stratégies et définitions de pool d'instances.
• AI and ML asset : Experimentation MLflow, exécutions, modèles, tables de Magasin de fonctionnalités, index de recherche AI et modèles Unity Catalog.
• Objets Unity Catalog : configuration du metastore, catalogues, schémas, tables, volumes et autorisations.

Définir la portée de votre exportation

Créez une liste de contrôle des assets à exporter en fonction de vos exigences. Considérez ces questions :

• Devez-vous exporter tous les assets ou seulement des catégories spécifiques ?
• Existe-t-il des exigences de conformité ou de sécurité qui dictent les assets que vous devez exporter ?
• Avez-vous besoin de préserver les relations entre les assets (par exemple, des Jobs qui référencent des Notebooks) ?
• Devez-vous recréer la configuration du Workspace dans un autre environnement ?

La planification de votre portée d'exportation vous aide à choisir les bons outils et à éviter de manquer des dépendances critiques.

Exporter la configuration du Workspace

L'exportateur Terraform est l'outil principal pour l'exportation de la configuration du Workspace. Il génère des fichiers de configuration Terraform qui représentent vos assets de Workspace en tant que code.

Utiliser l'exportateur Terraform

L'exportateur Terraform est intégré au fournisseur Terraform de Databricks et génère des fichiers de configuration Terraform pour les ressources de Workspace, y compris les Notebooks, les Jobs, les clusters, les utilisateurs, les groupes, les secrets et les listes de contrôle d'accès. L'exportateur doit être exécuté séparément pour chaque Workspace. Voir le fournisseur Databricks Terraform.

Prérequis :

• Terraform installé sur votre machine
• Authentification Databricks configurée
• Privilèges d'administrateur sur le Workspace que vous souhaitez exporter

Pour exporter les ressources du workspace :

1. Consultez la vidéo d'exemple d'utilisation pour une présentation de l'exportateur.

2. Download et installez le fournisseur Terraform avec l'outil d'exportation :

   Bash

   wget -q -O terraform-provider-databricks.zip $(curl -s https://api.github.com/repos/databricks/terraform-provider-databricks/releases/latest|grep browser_download_url|grep linux_amd64|sed -e 's|.*: "\([^"]*\)".*$|\1|')
   unzip -d terraform-provider-databricks terraform-provider-databricks.zip

3. Configurez les variables d'environnement d'authentification pour votre Workspace :

   Bash

   export DATABRICKS_HOST=https://your-workspace-url
   export DATABRICKS_TOKEN=your-token

4. Exécutez l'exportateur pour générer les fichiers de configuration Terraform :

   Bash

   terraform-provider-databricks exporter \
     -directory ./exported-workspace \
     -listing notebooks,jobs,clusters,users,groups,secrets

   Options d'exportation courantes :

   • -listing: Spécifiez les types de ressources à exporter (séparés par des virgules)
   • -services: Alternative au listing pour filtrer les ressources.
   • -directory: Répertoire de sortie pour les fichiers .tf générés
   • -incremental: Exécuter en mode incrémental pour les migrations par étapes

5. Passez en revue les fichiers .tf générés dans le répertoire de sortie. L'exportateur crée un fichier pour chaque type de ressource.

remarque

L'exportateur Terraform se concentre sur la configuration et les métadonnées du Workspace. Il n'exporte pas les données réelles stockées dans les tables ou le système de fichiers Databricks. Vous devez exporter les données séparément en utilisant les approches décrites dans les sections suivantes.

Exporter des types d'asset spécifiques

Pour les assets non entièrement couverts par l'exportateur Terraform, utilisez ces approches :

• **Notebooks** : Download les Notebooks individuellement à partir de l'interface utilisateur du Workspace ou utilisez l'API du Workspace pour exporter les Notebooks par programmation. Consultez Gérer les objets Workspace.
• Secrets : Les secrets ne peuvent pas être exportés directement pour des raisons de sécurité. Vous devez recréer manuellement les secrets dans l'environnement cible. Documentez les noms et les périmètres des secrets pour référence.
• Objets MLflow : Utilisez l'outil mlflow-export-import pour exporter des Experimentations, des exécutions et des modèles. Consultez la section des assets ML ci-dessous.

Exporter les données

Les données client résident généralement dans le stockage de votre compte cloud, et non dans Databricks. Vous n'avez pas besoin d’exporter les données qui se trouvent déjà dans votre cloud storage. Cependant, vous devez exporter les données stockées dans les emplacements gérés par Databricks.

Exporter les tables gérées

Bien que les tables gérées résident dans votre stockage cloud, elles sont stockées dans une hiérarchie basée sur des UUID qui peut être difficile à analyser. Vous pouvez utiliser la commande DEEP CLONE pour réécrire les tables gérées en tables externes dans un emplacement spécifié, ce qui les rend plus faciles à utiliser.

Exemple de DEEP CLONE commandes :

SQL

CREATE TABLE delta.`s3://path/to/storage/`
DEEP CLONE my_catalog.my_schema.my_table

Pour un script complet permettant de cloner toutes les tables dans une liste de catalogues, consultez le script d'exemple ci-dessous.

Exporter le stockage default de Databricks

Pour les Workspace Serverless, Databricks offre un stockage default, qui est une solution de stockage entièrement managé au sein du compte Databricks. Les données du stockage default doivent être exportées vers des conteneurs de stockage appartenant aux clients avant la suppression ou la désaffectation du Workspace. Pour plus d'information sur les workspaces Serverless, voir Créer un workspace Serverless.

Pour les tables en stockage par default, utilisez DEEP CLONE pour écrire des données dans un conteneur de stockage appartenant au client. Pour les volumes et les fichiers arbitraires, suivez les mêmes modèles décrits dans la section Exportation de la racine DBFS ci-dessous.

Exportation de la racine du système de fichiers Databricks

remarque

Pour les nouveaux workflows, Databricks recommande de stocker les données dans les volumes Unity Catalog ou le système de fichiers du Workspace au lieu du système de fichiers Databricks. Cette page documente l'exportation du système de fichiers Databricks pour les utilisateurs disposant de données de système de fichiers Databricks existantes.

La racine du Databricks File System est l'emplacement de stockage hérité dans le bucket de stockage de votre workspace qui peut contenir des assets appartenant aux clients, des uploads utilisateur, des scripts d'initialisation, des bibliothèques et des tables. Bien que la racine du système de fichiers Databricks soit un modèle de stockage obsolète, les Workspace hérités peuvent toujours avoir des données stockées à cet emplacement qui doivent être exportées. Pour plus d'informations sur l'architecture de stockage du Workspace, consultez Stockage du Workspace.

Exportation du compartiment racine du système de fichiers Databricks :

Utilisez l'AWS CLI pour synchroniser les données de l'emplacement du compartiment de stockage du Workspace Databricks vers votre compartiment d'exportation :

Bash

# Export from DBFS root bucket to export bucket
aws s3 sync s3://databricks-workspace-bucket/dbfs/ s3://export-bucket/dbfs-export/

remarque

Si le compartiment racine de votre Databricks File System utilise le chiffrement côté serveur avec AWS KMS, assurez-vous que votre compartiment d'exportation dispose de la configuration de chiffrement et des autorisations appropriées pour accéder à la clé KMS.

important

L'exportation de grands volumes de données depuis le stockage cloud peut entraîner des coûts de transfert de données et de stockage importants. Examinez les Tarifs de votre fournisseur cloud avant d'initier des exportations volumineuses.

Défis courants d'exportation

Chiffrement du compartiment :

Si le compartiment de stockage de votre Workspace utilise le chiffrement côté serveur, plusieurs approches sont possibles :

• Chiffrement S3 par défaut : S3 chiffre toutes les données par défaut. C'est transparent pour les utilisateurs, donc aucune étape supplémentaire n'est requise.
• Chiffrement KMS avec clé gérée par AWS : AWS gère la clé, le chiffrement et le déchiffrement. Aucune étape supplémentaire n'est requise.
• Chiffrement KMS avec clé KMS personnalisée : Le chiffrement est géré par S3, mais vous avez besoin des autorisations pour accéder à la clé afin de lire les données dans le compartiment. Assurez-vous d'avoir accès à la même clé dans le compartiment cible et que votre compartiment d'exportation dispose de la configuration de chiffrement appropriée.

Secrets :

Les secrets ne peuvent pas être exportés directement pour des raisons de sécurité. Lorsque vous utilisez l'exportateur Terraform avec l'option -export-secrets, l'exportateur génère une variable dans vars.tf portant le même nom que le secret. Vous devez mettre à jour manuellement ce fichier avec les valeurs de secret réelles ou exécuter l'exportateur Terraform avec l'option -export-secrets (uniquement pour les secrets gérés par Databricks).

Exporter les assets d’IA et de ML

Certains assets d'IA et de ML nécessitent des outils et des approches différents pour l'exportation. Les modèles du Unity Catalog sont exportés dans le cadre de l'exportateur Terraform.

Objets MLflow

MLflow n'est pas couvert par l'exportateur Terraform en raison de lacunes dans l'API et de difficultés avec la sérialisation. Pour exporter les expérimentations, les exécutions, les modèles et les artefacts MLflow, utilisez l'outil mlflow-export-import. Cet outil open source offre une couverture semi-complète de la migration MLflow.

Pour les scénarios d'exportation uniquement, vous pouvez stocker tous les assets MLflow dans un bucket appartenant au client sans avoir besoin d'effectuer l'étape d'importation. Pour plus d'information sur la gestion de MLflow, consultez Gérer le cycle de vie du modèle dans Unity Catalog.

Magasin de fonctionnalités et Recherche IA

**Index de recherche IA** : Les index de recherche IA ne sont pas concernés par les procédures d'exportation de données de l'UE. Si vous souhaitez toujours les exporter, ils doivent être écrits dans une table standard, puis exportés à l'aide de DEEP CLONE.

Tables du Magasin de fonctionnalités : le Magasin de fonctionnalités doit être traité de la même manière que les index AI Search. À l'aide de SQL, sélectionnez les données pertinentes et écrivez-les dans une table standard, puis exportez-les à l'aide de DEEP CLONE.

Valider les données exportées

Après avoir exporté les données du workspace, vérifiez que les Jobs, les utilisateurs, les Notebooks et les autres Ressources ont été exportés correctement avant de déclasser l'ancien environnement. Utilisez la liste de contrôle que vous avez créée pendant la phase de définition et de planification pour vérifier que tout ce que vous vous attendiez à exporter a été exporté avec succès.

Liste de vérification

Utilisez cette checklist pour vérifier votre exportation :

• Fichiers de configuration générés : Des fichiers de configuration Terraform sont créés pour toutes les ressources du workspace requises.
• Notebooks exportés : tous les notebooks sont exportés avec leur contenu et leurs métadonnées intacts.
• Tables clonées : les tables gérées sont clonées avec succès vers l'emplacement d'exportation.
• Fichiers de données copiés : les données de stockage cloud sont copiées entièrement sans erreur.
• **Objets MLflow exportés** : les Expériences, les exécutions et les modèles sont exportés avec leurs artefacts.
• Permissions documentées : les listes de contrôle d'accès et les autorisations sont capturées dans la configuration Terraform.
• Dépendances identifiées : Les relations entre les assets (par exemple, les Jobs référençant des Notebooks) sont conservées lors de l'exportation.

Bonnes pratiques post-exportation

Les tests de validation et d'acceptation sont largement dictés par vos exigences et peuvent varier considérablement. Cependant, ces bonnes pratiques générales s'appliquent :

• Définir un environnement de test : créez un environnement de test de jobs ou de Notebooks qui valide que les secrets, les données, les montages, les connecteurs et les autres dépendances fonctionnent correctement dans l'environnement exporté.
• Start avec les environnements de développement : si vous procédez par étapes, commencez par l'environnement de développement et progressez jusqu'à la production. Cela met en évidence les problèmes majeurs rapidement et évite les impacts sur la production.
• Utilisez les dossiers Git : Lorsque cela est possible, utilisez les dossiers Git car ils se trouvent dans un repository Git externe. Cela évite l'exportation manuelle et garantit que le code est identique dans tous les environnements.
• Documentez le processus d'exportation : Enregistrez les outils utilisés, les commandes exécutées et tout problème rencontré.
• **Sécuriser les données exportées** : Assurez-vous que les données exportées sont stockées en toute sécurité avec des contrôles d'accès appropriés, surtout si elles contiennent des informations sensibles ou personnellement identifiables.
• Maintenir la conformité : si vous exportez à des fins de conformité, vérifiez que l'exportation répond aux exigences réglementaires et aux politiques de conservation.

Exemples de scripts et automatisation

Vous pouvez automatiser les exportations de workspace à l'aide de scripts et de jobs planifiés.

Script d’exportation de clone profond

Le script suivant exporte des tables gérées par Unity Catalog à l'aide de DEEP CLONE. Ce code doit être exécuté dans le Workspace source pour exporter un catalogue donné vers un bucket intermédiaire. Mettez à jour les variables catalogs_to_copy et dest_bucket.

Python

import pandas as pd

# define catalogs and destination bucket
catalogs_to_copy = ["my_catalog_name"]
dest_bucket = "<cloud-storage-path>://my-intermediate-bucket"
manifest_name = "manifest"

# initialize vars
system_info = sql("SELECT * FROM system.information_schema.tables")
copied_table_names = []
copied_table_types = []
copied_table_schemas = []
copied_table_catalogs = []
copied_table_locations = []

# loop through all catalogs to copy, then copy all non-system tables
# note: this would likely be parallelized using thread pooling in prod
for catalog in catalogs_to_copy:
  filtered_tables = system_info.filter((system_info.table_catalog == catalog) & (system_info.table_schema != "information_schema"))
  for table in filtered_tables.collect():
    schema = table['table_schema']
    table_name = table['table_name']
    table_type = table['table_type']
    print(f"Copying table {schema}.{table_name}...")
    target_location = f"{dest_bucket}/{catalog}_{schema}_{table_name}"
    sqlstring = f"CREATE TABLE delta.`{target_location}` DEEP CLONE {catalog}.{schema}.{table_name}"
    sql(sqlstring)

    # lists used to create manifest table DF
    copied_table_names.append(table_name)
    copied_table_types.append(table_type)
    copied_table_schemas.append(schema)
    copied_table_catalogs.append(catalog)
    copied_table_locations.append(target_location)

# create the manifest as a df and write to a table in dr target
# this contains catalog, schema, table and location
manifest_df = pd.DataFrame({"catalog": copied_table_catalogs,
                            "schema": copied_table_schemas,
                            "table": copied_table_names,
                            "location": copied_table_locations,
    "type": copied_table_types})

spark.createDataFrame(manifest_df).write.mode("overwrite").format("delta").save(f"{dest_bucket}/{manifest_name}")
display(manifest_df)

Considérations sur l'automatisation

Lors de l'automatisation des exportations :

• Utilisez les Jobs planifiés : créez des Jobs Databricks qui exécutent des scripts d'exportation selon un calendrier régulier.
• Surveiller les Jobs d'exportation : configurez des alertes pour vous avertir si les exportations échouent ou prennent plus de temps que prévu.
• Gérer les identifiants : Stockez en toute sécurité les identifiants de stockage cloud et les jetons API à l'aide des secrets Databricks. Consultez la gestion des secrets.
• Exports de version : utilisez les Timestamp ou les numéros de version dans les chemins d'exportation pour conserver les exports historiques.
• Nettoyer les anciennes exportations : implémentez des politiques de rétention pour supprimer les anciennes exportations et gérer les coûts de stockage.
• Exportations incrémentielles : Pour les grands Workspace, envisagez de mettre en œuvre des exportations incrémentielles qui exportent uniquement les données modifiées depuis la dernière exportation.