Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Dans Databricks Runtime 16.4 LTS et versions ultérieures, DROP FEATURE supprime une fonctionnalité de table Delta Lake et rétrograde le protocole de table vers la version la plus basse qui prend en charge les fonctionnalités restantes. Utilisez cette fonctionnalité uniquement pour restaurer la compatibilité avec les versions antérieures de Databricks Runtime, OpenSharing ou les clients Delta Lake externes.
Toutes les fonctionnalités ne peuvent pas être supprimées. Consultez les fonctionnalités de tableau prises en charge.
Remarque
Le support hérité pour DROP FEATURE est disponible à partir de Databricks Runtime 14.3 LTS. Databricks recommande d’utiliser Databricks Runtime 16.3 et versions ultérieures pour toutes les DROP FEATURE commandes, qui remplace le comportement hérité. Pour obtenir de la documentation sur les fonctionnalités héritées, consultez Les fonctionnalités de table Drop Delta (héritées).
Supprimer une fonctionnalité Delta Lake
Important
Toutes les opérations DROP FEATURE sont en conflit avec les écritures simultanées.
Les lectures en flux échouent lorsqu’elles rencontrent un commit qui modifie les métadonnées d’une table. Vous devez redémarrer les flux affectés. Pour connaître les méthodes recommandées, consultez Considérations relatives à la production pour Structured Streaming.
Vous devez utiliser Databricks Runtime 16.3 ou version ultérieure et disposer MODIFY de privilèges sur la table Delta Lake cible. Vous ne pouvez supprimer qu’une seule fonctionnalité de table avec chaque DROP FEATURE commande.
Pour supprimer une fonctionnalité de table, utilisez la syntaxe suivante :
ALTER TABLE <table-name> DROP FEATURE <feature-name>
Consultez ALTER TABLE pour plus d’informations.
Behavior
Lorsque vous supprimez une fonctionnalité de table, Delta Lake valide atomiquement les modifications suivantes dans la table :
- Désactivez les propriétés de tableau qui utilisent la fonctionnalité de tableau.
- Réécrivez les fichiers de données sous-jacents si nécessaire pour supprimer toute trace de la fonctionnalité de tableau de la version actuelle du tableau.
- Créez un ensemble de points de contrôle protégés qui permettent aux clients lecteur de lire correctement l’historique des tables.
- Ajoutez la fonctionnalité de table enregistreur
checkpointProtectionau protocole de la table. - Rétrogradez le protocole de table vers les versions de lecteur et d’enregistreur les plus basses qui prennent en charge toutes les fonctionnalités de table restantes. Consultez le protocole le plus bas possible.
Le checkpointProtection tableau comporte
Lorsque vous supprimez une fonctionnalité, Delta Lake réécrit les données et les métadonnées dans l’historique de la table en tant que points de contrôle protégés pour respecter la rétrogradation du protocole.
Après la rétrogradation, la table ne nécessite pas que les clients prennent en charge la fonctionnalité supprimée. Les points de contrôle protégés et la checkpointProtection fonctionnalité effectuent les opérations suivantes :
- Les clients de lecture qui prennent en charge la fonctionnalité de suppression de table peuvent lire toutes les versions disponibles de l’historique de la table.
- Les clients de lecture qui ne prennent pas en charge la fonctionnalité supprimée peuvent lire les versions de l’historique des tables à partir de la version de rétrogradation du protocole et des versions ultérieures.
- Les clients writer ne modifient pas les points de contrôle créés avant la rétrogradation du protocole.
-
checkpointProtectionsignale les points de contrôle de passage à une version antérieure de protocole comme étant protégés, et les opérations de maintenance des tableaux tiennent compte de ces marqueurs.
Bien que vous ne puissiez supprimer qu’une seule fonctionnalité de table avec chaque DROP FEATURE commande, une table peut avoir plusieurs points de contrôle protégés et des fonctionnalités supprimées dans son historique de table.
Toutes les versions de Databricks Runtime prennent en charge la checkpointProtection fonctionnalité de table, ce qui signifie que cette fonctionnalité de table ne bloque pas les lectures ou les écritures sur Azure Databricks.
checkpointProtection ne bloque pas l’accès en lecture seule à partir de clients OSS Delta Lake. Pour effectuer une rétrogradation complète de la table et supprimer la checkpointProtection fonctionnalité de table, vous devez utiliser TRUNCATE HISTORY. Databricks recommande uniquement d’utiliser ce modèle si vous devez écrire dans des tables avec des clients Delta externes qui ne prennent pas en charge checkpointProtection. Consultez Protocoles de table entièrement rétrograde pour les clients hérités.
Fonctionnalités de table prises en charge
Vous pouvez supprimer les fonctionnalités de table Delta Lake suivantes :
-
catalogManaged. Consultez les validations de catalogue. -
checkConstraints. Consultez Contraintes sur Azure Databricks. -
collations-preview. Consultez Support de classement pour Delta Lake. -
columnMapping. Voir Renommer et supprimer des colonnes avec le mappage de colonnes Delta Lake. -
deletionVectors. Consultez les vecteurs de suppression dans Databricks. -
typeWidening. Consultez Élargissement du type. -
v2Checkpoint. Voir Rétrograder vers classique. -
checkpointProtection. Consultez lacheckpointProtectionfonctionnalité de tableau.
Vous ne pouvez pas supprimer d’autres fonctionnalités de table Delta Lake.
Important
Databricks recommande de toujours tester les charges de travail et les systèmes dépendants afin de vérifier leur compatibilité avec les nouvelles fonctionnalités avant d’activer des fonctionnalités qui mettent à niveau les protocoles de lecture ou d’écriture des données de production.
Tenez compte des éléments suivants :
- La suppression du mappage de colonnes d’une table ne supprime pas les préfixes aléatoires utilisés dans les noms de répertoires pour les tables partitionnée. Consultez Delta Lake et Parquet partagent-ils des stratégies de partitionnement ?.
- Certaines fonctionnalités Delta Lake permettent plusieurs fonctionnalités de table qui dépendent les unes des autres, ce qui peut vous empêcher de supprimer des fonctionnalités dépendantes. Vous ne pouvez pas restaurer les fonctionnalités qui ne peuvent pas être supprimées.
Protocoles de table entièrement rétrograde pour les clients hérités
Si vous utilisez des clients Delta Lake externes avec des écritures qui ne prennent pas en charge la checkpointProtection fonctionnalité de table, vous devez utiliser TRUNCATE HISTORY pour rétrograder entièrement le protocole de table et supprimer toutes les traces des fonctionnalités de table supprimées. L’exécution TRUNCATE HISTORY supprime l’historique de toutes les tables antérieures à 24 heures.
Databricks recommande de tester le comportement par défaut pour DROP FEATURE avant d’exécuter TRUNCATE HISTORY.
La rétrogradation complète nécessite deux étapes, au moins 24 heures d’écart.
Étape 1 : Préparer la suppression d’une fonctionnalité de table
Exécutez la commande ALTER TABLE <table-name> DROP FEATURE <feature-name> TRUNCATE HISTORY. La commande applique les éléments suivants :
- Met à jour les propriétés de la table pour désactiver la fonctionnalité.
- Réinitialise les propriétés de la table associées à la fonctionnalité à leurs valeurs par défaut.
- Réécrit les fichiers de données et de métadonnées selon les besoins pour refléter les propriétés mises à jour.
- Retourne un message vous demandant d’attendre au moins 24 heures avant de l’exécuter à nouveau pour terminer la rétrogradation du protocole.
Après avoir désactivé une fonctionnalité, vous pouvez continuer à écrire dans la table cible avant d’effectuer la rétrogradation du protocole, mais vous ne pouvez pas utiliser la fonctionnalité de table que vous supprimez.
Remarque
Si vous laissez la table dans cet état, les opérations sur la table n’utilisent pas la fonctionnalité de table, mais le protocole prend toujours en charge la fonctionnalité de table. Tant que vous n’avez pas terminé la dernière étape de rétrogradation, la table n’est pas lisible par les clients Delta qui ne prennent pas en charge la fonctionnalité de table.
Étape 2 : Rétrograder le protocole et supprimer une fonctionnalité de table
Après au moins 24 heures, réexécutez la ALTER TABLE <table-name> DROP FEATURE <feature-name> TRUNCATE HISTORY commande. La commande applique les éléments suivants :
- Tronque l’historique du tableau jusqu’au seuil de rétention.
- Confirme qu’aucune transaction restante n’utilise la fonctionnalité.
- Supprime la fonctionnalité et rétrograde le protocole de table vers la version la plus basse qui prend en charge les fonctionnalités restantes.
Important
L’exécution ALTER TABLE <table-name> DROP FEATURE <feature-name> TRUNCATE HISTORY supprime toutes les données du journal des transactions antérieures à 24 heures. Après avoir utilisé cette commande pour rétrograder le protocole de table, vous ne pouvez pas accéder à l’historique des tables ni aux déplacements temporels.
Consultez les protocoles et la compatibilité des fonctionnalités Delta Lake.