Améliorez votre Lakehouse : Votre guide pratique pour la conversion en tables gérées Unity Catalog

La nouvelle commande SET MANAGED fournit un mécanisme transparent pour convertir les tables externes UC en tables gérées UC tout en minimisant les temps d'arrêt, en gérant les écritures simultanées, en maintenant les configurations de table et, lorsque possible, en préservant l'historique de la table. Cet article partage les meilleures pratiques et fournit un guide étape par étape pour utiliser cette commande généralement disponible (GA) :

Pourquoi convertir en tables gérées UC ?

Avec Unity Catalog comme source de vérité, les tables gérées débloquent des capacités uniques qui améliorent les performances, la gouvernance et la facilité d'utilisation, tout en maintenant l'interopérabilité et la portabilité.

Les principaux avantages incluent :

• Optimisations automatiques qui peuvent améliorer les performances des requêtes jusqu'à 20 fois et réduire les coûts de stockage de plus de 50 % (plus de détails ici).
• Gestion des données simplifiée avec nettoyage automatique des données supprimées pour économiser sur les coûts, ainsi que la prise en charge de UNDROP.
• Gouvernance améliorée avec lignage des données, contrôles d'accès granulaires et accès sécurisé aux tables avec la supervision de Unity Catalog sur toutes les lectures et écritures.
• Une base pour les capacités futures telles que la suppression automatique des lignes (Auto-TTL) et l'ingestion au niveau des lignes (Zerobus ingest).
• Interopérabilité : Les tables converties prennent en charge les lectures à partir de n'importe quel client tiers (voir ici pour plus de détails).

Comment la commande de conversion SET MANAGED peut-elle aider ?

La commande SET MANAGED facilite la conversion des tables externes en tables gérées

Comment convertir des tables externes en tables gérées ?

Guide étape par étape pour les praticiens pour la conversion

La commande SET MANAGED rend la conversion des tables simple. Dans un guide étape par étape, nous avons décrit les conseils clés pour assurer une transition en douceur des tables externes vers les tables gérées.

Étape 1 : Sélectionner les tables externes à convertir

Commencez par sélectionner quelques tables externes Unity Catalog à convertir d'abord en tables gérées UC, pour familiariser votre équipe avec le processus, les prérequis et les étapes post-conversion.

Par exemple, vous pouvez essayer cette commande d'abord sur quelques tables qui sont exclusivement lues et écrites par des clients Databricks (voir la section "Planification d'un parcours par étapes" plus loin).

Étape 2 : Liste de contrôle avant le vol

Vérifiez que votre écosystème de lecteurs et rédacteurs de tables est prêt pour le changement. Pour chaque table externe UC sélectionnée et ses charges de travail associées, vous devrez :

1. Mettre à jour pour utiliser l'accès basé sur le nom : Vérifiez vos jobs, notebooks et requêtes pour vous assurer qu'ils accèdent à la table en utilisant son nom en trois parties (catalogue.schéma.table) plutôt que par l'accès basé sur le chemin (par exemple, SELECT * FROM delta.'s3://path/to/table'). Databricks Labs a développé l'outil UCX qui peut vous aider à trouver les références basées sur le chemin en exécutant le code suivant Databricks Labs UCX lint-local-code depuis un terminal IDE, pour analyser le code du répertoire de votre machine locale (.py ou .sql).
   1. test123
   2. La redirection basée sur le chemin est également disponible pour gérer le code hérité, si la mise à jour vers l'accès basé sur le nom n'est pas possible
2. Annuler tous les jobs de maintenance : Pour éviter les conflits, assurez-vous qu'aucun job OPTIMIZE, ZORDER ou CLUSTER BY ne s'exécute ou n'est planifié sur la table pendant le processus de conversion, s'ils existent (peut être vérifié à l'aide de DESCRIBE HISTORY). Après la conversion, Predictive Optimization gérera automatiquement les jobs d'optimisation.
3. [Optionnel] Mettre à niveau les versions de Databricks Runtime : Tous les clusters Databricks lisant ou écrivant sur la table doivent idéalement être sur Databricks Runtime 15.4 LTS ou supérieur pour conserver l'historique complet de la table pour les tables Delta. Databricks Runtime 16.1 ou supérieur peut éliminer complètement les temps d'arrêt pour les lecteurs.

Étape 3 : Exécuter la commande de conversion

Exécutez la conversion à l'aide de la commande de conversion suivante :

Note : Pour les tables avec UniForm activé, utilisez SET MANAGED TRUNCATE UNIFORM HISTORY.

Étape 4 : Vérifier le résultat

Une fois la commande terminée, confirmez que la conversion a réussi en vérifiant les métadonnées de la table.

Dans la sortie de cette commande, la propriété « Type » devrait maintenant afficher « MANAGED ». Vous pouvez également voir ces mêmes informations dans la section « À propos de cette table » de Catalog Explorer.

Étape 5 : Entretien post-conversion

Après une conversion réussie, effectuez ces dernières étapes pour assurer une transition en douceur :

• Redémarrez les jobs de lecture ou d'écriture en continu qui utilisent la table si certains ont été mis en pause
• Effectuez des tests fonctionnels en exécutant des requêtes clés pour vous assurer que tous les lecteurs et rédacteurs fonctionnent comme prévu sur la nouvelle table gérée

Planifier un parcours par étapes

Une conversion réussie de toutes les tables vers UC managed est un parcours – adopter une approche progressive et planifier à l'avance peut aider à assurer une transition en douceur :

1. Convertir les tables Databricks uniquement : Priorisez la conversion des tables qui sont exclusivement lues et écrites par les clients Databricks. Un outil expérimental, Access Insights, peut être utilisé pour aider à identifier les tables avec uniquement des « lecteurs et rédacteurs Databricks » par rapport aux « lecteurs non-Databricks » ou « rédacteurs non-Databricks ».
2. Convertir les tables avec des outils externes pris en charge : Déterminez quelles tables sont accessibles par des outils tiers qui prennent également en charge nativement les lectures à partir de tables gérées par UC, et convertissez celles-ci ensuite. L'accès tiers continuera de fonctionner après la conversion.
3. Traiter les cas complexes en dernier : Pour les tables accessibles avec des outils hérités non pris en charge – prévoyez d'utiliser des solutions comme Compatibility Mode pour les lectures. Là où des écritures tierces sont nécessaires, recréez ces tables et activez les écritures vers ces tables gérées par UC en aperçu.

Considérations supplémentaires

Les détails suivants concernant la commande de conversion peuvent être utiles à connaître à l'avance :

• Limite de temps pour le retour arrière : Pour utiliser le filet de sécurité de retour arrière, `UNSET MANAGED` doit être exécuté sur la table gérée par UC dans les 14 jours suivant la conversion – après cela, les données externes d'origine seront définitivement supprimées pour économiser sur les coûts de stockage.
• Nuances de voyage dans le temps : La mise à niveau des clients vers la version 15.4 LTS ou supérieure peut être utile. Pour les clusters exécutant Databricks Runtime 14.3 LTS ou inférieur ou si vous utilisez la commande `UNSET MANAGED` pour revenir en arrière, vous ne pourrez voyager dans le temps que vers les commits historiques par numéro de version après la conversion, et non par horodatage.
• Temps d'arrêt minimisé pour les rédacteurs : La commande est conçue pour minimiser les temps d'arrêt – les rédacteurs peuvent rencontrer une brève interruption (estimée entre 1 et 5 minutes) pendant la phase finale lorsque l'emplacement de la table est basculé vers le nouvel emplacement géré.
• Interruption temporaire du partage Delta : Le partage Delta sera temporairement interrompu pendant la conversion, mais cela fonctionnera correctement une fois le processus terminé.

Astuce de pro : Mise à l'échelle avec la conversion en masse

Pour convertir des centaines ou des milliers de tables externes Unity Catalog en masse au sein d'un schéma donné, vous pouvez utiliser le script SQL simple suivant.

Remarque : Ce script effectue des modifications en direct. Il est fortement recommandé de le tester minutieusement dans un environnement de développement avant de l'exécuter en production.

Contrôler l'emplacement physique de vos données

Les tables gérées par Unified Catalog (UC) résident dans le stockage géré par le client et sont accessibles via des API de catalogue ouvertes. Si vous souhaitez plus de contrôle sur la façon dont vos données sont physiquement stockées ou segreger vos données, vous pouvez définir un emplacement de stockage géré au niveau du catalogue ou du schéma – toutes les nouvelles tables gérées créées dans ce catalogue ou schéma seront automatiquement organisées dans cet emplacement spécifié.

Pour les tables externes préexistantes, vous pouvez définir un emplacement de stockage géré, puis utiliser la commande `SET MANAGED` pour les convertir en tables gérées par UC. Pendant la conversion, le système respecte l'emplacement géré que vous avez défini, vous donnant le contrôle sur la disposition physique de vos données dans le stockage cloud. Veuillez contacter votre équipe de compte pour accéder à cette fonctionnalité en aperçu privé dès aujourd'hui.

Conversion des tables externes en tables gérées dès aujourd'hui

En seulement quelques mois depuis l'aperçu public, des centaines de clients ont converti avec succès des milliers de tables avec `SET MANAGED`.

Tout ce qui est décrit ici est maintenant GA – essayez-le dès aujourd'hui et débloquez la performance, la gouvernance et la simplicité des tables gérées par Unity Catalog.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original