Aller au contenu principal
Dernière mise à jour le

Mettre à jour votre bundle pour utiliser les ressources de dimensionnement automatique

Ce guide vous explique comment mettre à jour un ensemble d'assets Databricks (DAB) existant. La mise à jour convertit une configuration Lakebase Provisioned (une ressource database_instances, éventuellement avec une instance enfant, des catalogues et des tables synchronisées) en ressources de dimensionnement automatique Lakebase (postgres_projects, postgres_branches, postgres_endpoints, et éventuellement postgres_catalogs et postgres_synced_tables).

Quand cela s'applique​

Votre base de données Lakebase fonctionne déjà sur la plateforme d'Autoscaling. À compter du 12 mars 2026, l'API d'instance de base de données crée de nouvelles instances Lakebase en tant que projets de dimensionnement automatique. Votre bundle est la seule partie qui les référence encore à l'aide de database_instances. À partir de juin 2026, Databricks mettra automatiquement à niveau les instances provisionnées existantes vers la mise à l'échelle automatique. Dans les deux cas, les étapes de mise à jour du bundle sont les mêmes.

Fonctionnement de la mise à jour​

La mise à jour est in situ. Databricks ne déplace ni ne copie vos données. Le bundle cesse de suivre les ressources provisionnées et start à gérer la même base de données sous-jacente via les ressources à mise à l'échelle automatique. Cela débloque des fonctionnalités comme la mise à l'échelle jusqu'à zéro et le branchement.

La modification nécessite deux appels databricks bundle deploy, avec des commandes databricks bundle deployment bind et unbind entre eux pour gérer la transition de l'état du bundle.

Pour connaître les différences conceptuelles entre Provisionné et Autoscaling, consultez Mise à niveau vers Autoscaling. Cette page couvre uniquement la mise à jour de la configuration du bundle.

Prérequis​

Avant de commencer, vous devez avoir :

  • Databricks CLI version 1.2.0 ou ultérieure, qui met à jour vos Ressources existantes sur place. Pour vérifier votre version, exécutez databricks -v.
  • Authentification configurée pour votre workspace Databricks. Consultez Configurer l'accès à votre workspace.
  • Autorisation CAN MANAGE sur le projet Lakebase. Consultez Gérer les autorisations du projet.
  • Une base de données Lakebase existante actuellement gérée par un bundle en tant que database_instances. Si votre configuration comprend une instance enfant, des catalogues ou des tables synchronisées, ce guide les couvre également.

Cette page couvre database_instances, database_catalogs, synced_database_tables (tables synchronisées) et Databricks Apps.

Mappage des ressources​

provisionnement

Dimensionnement automatique

Parent database_instances

postgres_projects plus une Branch production créée implicitement

Enfant database_instances

postgres_branches dont le branch_id est égal à celui de l'instance enfant name

Endpoint en lecture-écriture de l’instance enfant

postgres_endpoints avec endpoint_id = "primary" sur la Branch enfant

database_catalogs

postgres_catalogs dont le catalog_id est égal à celui du catalogue name

synced_database_tables

postgres_synced_tables dont synced_table_id est égal à celui de la table synchronisée name

provisionnement

Dimensionnement automatique

Parent database_instances

postgres_projects plus une Branch production créée implicitement

Enfant database_instances

postgres_branches dont le branch_id est égal à celui de l'instance enfant name

Endpoint en lecture-écriture de l’instance enfant

postgres_endpoints avec endpoint_id = "primary" sur la Branch enfant

database_catalogs

postgres_catalogs dont le catalog_id est égal à celui du catalogue name

synced_database_tables

postgres_synced_tables dont synced_table_id est égal à celui de la table synchronisée name

L'ID du projet est le name de l'instance parente , en minuscules. Si vous n'êtes pas sûr (par exemple, le nom contenait des lettres majuscules), trouvez votre projet dans la liste des projets de l'application Lakebase et lisez son project_id.

Étape 1 : État initial (Provisionné)​

Votre databricks.yml de départ ressemble à ceci. Les noms sont des placeholders ; utilisez vos noms réels. Incluez les blocs database_catalogs et synced_database_tables uniquement si votre bundle les gère.

YAML
resources:
  database_instances:
    root:
      name: my-instance
      capacity: CU_2
    child:
      name: my-child
      capacity: CU_2
      parent_instance_ref:
        name: ${resources.database_instances.root.name}

  database_catalogs:
    cat:
      name: my-catalog
      database_instance_name: ${resources.database_instances.root.name}
      database_name: my_db
      create_database_if_not_exists: true

  synced_database_tables:
    orders_synced:
      name: my-catalog.default.orders_synced
      database_instance_name: ${resources.database_instances.root.name}
      logical_database_name: my_db
      spec:
        scheduling_policy: SNAPSHOT
        source_table_full_name: main.default.orders
        primary_key_columns:
          - id
        new_pipeline_spec:
          storage_catalog: main
          storage_schema: default

Étape 2 (Déployer 1) : Adoptez les ressources de mise à l'échelle automatique​

Ajoutez les Ressources d'autoscaling au bundle aux côtés des ressources provisionnées existantes. Les blocs approvisionnés restent dans la configuration au cours de cette étape. Le projet, les Branch et l'Endpoint utilisent un ensemble de champs minimal. Le catalogue et la table synchronisée nécessitent quelques champs supplémentaires, notamment la table source de la table synchronisée, la clé primaire et le stockage de pipeline.

YAML
resources:
  database_instances:
    root:
      name: my-instance
      capacity: CU_2
    child:
      name: my-child
      capacity: CU_2
      parent_instance_ref:
        name: ${resources.database_instances.root.name}

  database_catalogs:
    cat:
      name: my-catalog
      database_instance_name: ${resources.database_instances.root.name}
      database_name: my_db
      create_database_if_not_exists: true

  synced_database_tables:
    orders_synced:
      name: my-catalog.default.orders_synced
      database_instance_name: ${resources.database_instances.root.name}
      logical_database_name: my_db
      spec:
        scheduling_policy: SNAPSHOT
        source_table_full_name: main.default.orders
        primary_key_columns:
          - id
        new_pipeline_spec:
          storage_catalog: main
          storage_schema: default

  postgres_projects:
    pg_root:
      project_id: my-instance

  postgres_branches:
    pg_production:
      branch_id: production
      parent: ${resources.postgres_projects.pg_root.id}
    pg_child:
      branch_id: my-child
      parent: ${resources.postgres_projects.pg_root.id}

  postgres_endpoints:
    pg_child_rw:
      endpoint_id: primary
      parent: ${resources.postgres_branches.pg_child.id}
      endpoint_type: ENDPOINT_TYPE_READ_WRITE

  postgres_catalogs:
    pg_cat:
      catalog_id: my-catalog
      branch: ${resources.postgres_branches.pg_production.id}
      postgres_database: my_db
      create_database_if_missing: false

  postgres_synced_tables:
    pg_orders_synced:
      synced_table_id: my-catalog.default.orders_synced
      branch: ${resources.postgres_branches.pg_production.id}
      postgres_database: my_db
      source_table_full_name: main.default.orders
      primary_key_columns:
        - id
      scheduling_policy: SNAPSHOT
      new_pipeline_spec:
        storage_catalog: main
        storage_schema: default
remarque

Les clés de ressource de bundle doivent être uniques pour tous les types de ressources d’un même bundle. Les ressources de mise à l’échelle automatique ci-dessus utilisent un préfixe pg_ pour éviter les conflits avec les clés provisionnées existantes (root, child, cat, orders_synced).

Avant le déploiement, **liez** chaque ressource d'autoscaling à son backend existant. La liaison garantit que le déploiement adopte les ressources existantes au lieu d'en créer de nouvelles. L'ID de la ressource pour chaque commande bind est le nom canonique de la ressource dans le Workspace :

Bash
databricks bundle deployment bind pg_root \
  projects/my-instance

databricks bundle deployment bind pg_production \
  projects/my-instance/branches/production

databricks bundle deployment bind pg_child \
  projects/my-instance/branches/my-child

databricks bundle deployment bind pg_child_rw \
  projects/my-instance/branches/my-child/endpoints/primary

databricks bundle deployment bind pg_cat \
  catalogs/my-catalog

databricks bundle deployment bind pg_orders_synced \
  synced_tables/my-catalog.default.orders_synced

Après la liaison, déployez le bundle :

Bash
databricks bundle deploy

Le déploiement adopte les Ressources d'Autoscaling à l'état de bundle sans les recréer. Vos données restent inchangées.

Étape 3 (Déploiement 2) : Supprimer les ressources provisionnées de l'état du bundle.​

Une fois le déploiement de l'étape 2 terminé sans erreur, supprimez les déclarations provisionnées du bundle.

Pour chaque Ressource provisionnée, exécutez bundle deployment unbind. Le prochain déploiement cesse alors le suivi de la Ressource provisionnée sans la détruire :

Bash
databricks bundle deployment unbind orders_synced
databricks bundle deployment unbind cat
databricks bundle deployment unbind child
databricks bundle deployment unbind root

Ensuite, supprimez les blocs database_instances (les entrées root et child), database_catalogs et synced_database_tables de votre YAML de bundle et redéployez :

Bash
databricks bundle deploy

Le bundle ne suit plus les Ressources provisionnées. Les données restent. Les ressources de mise à l'échelle automatique que vous avez adoptées à la 2e étape gèrent désormais entièrement votre base de données.

remarque

unbind supprime les Ressources provisionnées du suivi du bundle sans les supprimer, ainsi votre base de données continue de fonctionner.

Rôles et bases de données Postgres​

Les rôles et les bases de données Postgres qui existent dans votre base de données sont préservés lorsque vous mettez à jour votre bundle. Elles ne sont pas affectées par la migration.

Pour gérer les rôles et bases de données Postgres en tant que ressources de bundle, consultez les Ressources Declarative Automation Bundles. Si vous utilisez Terraform pour gérer l'infrastructure Lakebase, consultez Mettre à jour votre configuration Terraform pour utiliser les ressources d'autoscaling.

Databricks Apps​

Si votre application utilise une Ressource Lakebase database, elle continue de fonctionner après la mise à niveau. Les détails de connexion, les variables d'environnement et les rôles Postgres sont inchangés.

attention

Ne modifiez pas une ressource database en postgres dans la configuration de votre application. Les types de ressources database et postgres créent des rôles Postgres distincts. La modification du type crée un nouveau rôle et rompt l'accès de votre application aux données existantes.

Pour les nouvelles applications qui se connectent à un projet Autoscaling, utilisez app.resources.postgres. Voir Ajouter une ressource Lakebase à une application Databricks.

Ce qui est possible après la mise à jour de votre bundle​

Une fois que l'Autoscaling gère votre projet, vous pouvez faire des choses qui n'étaient pas disponibles avec la version provisionnée. Quelques points forts :

Pour un bundle complet qui en utilise plusieurs ensemble, consultez Gérer Lakebase avec les DAB.

remarque

Pour mettre complètement un projet hors service ultérieurement, exécutez databricks bundle destroy. Cela entraîne la suppression en cascade du projet, de ses Branch et de ses Endpoint, et par default, supprime temporairement le projet (conservé pendant 7 jours avant suppression définitive). Pour plus de détails, notamment sur la manière de supprimer définitivement immédiatement avec --purge, consultez Nettoyer les ressources.

Ressources supplémentaires​

Sur cette page