Partager via

Prise en charge de l’archivage dans Azure Databricks

  • Article

Important

Cette fonctionnalité est en préversion publique pour Databricks Runtime 13.3 LTS et versions ultérieures.

La prise en charge de l’archivage dans Azure Databricks introduit une collection de fonctionnalités qui vous permettent d’utiliser des stratégies de cycle de vie basées sur le cloud sur le stockage d’objets cloud contenant des tables Delta.

Important

Azure Databricks prend uniquement en charge l’archivage pour Azure Archive. Consultez la documentation Azure sur l’optimisation des coûts avec la gestion du cycle de vie.

Pourquoi devez-vous activer la prise en charge de l’archivage ?

La prise en charge de l’archivage autorise uniquement des requêtes pouvant être correctement exécutées sans accéder aux fichiers archivés. Ces requêtes incluent celles qui :

  • interrogent uniquement les métadonnées ;
  • utilisent des filtres ne nécessitant pas de scanner les fichiers archivés.

Toutes les requêtes qui nécessitent des données dans des fichiers archivés échouent.

Important

Azure Databricks ne retourne jamais de résultats pour les requêtes qui nécessitent des fichiers archivés pour retourner le résultat correct.

Sans prise en charge de l’archivage, les opérations sur les tables Delta peuvent s’arrêter, car les fichiers de données ou les fichiers journaux des transactions ont été déplacés vers des emplacements archivés et sont indisponibles au moment des requêtes. La prise en charge de l’archivage introduit des optimisations pour éviter d’interroger les données archivées lorsque cela est possible. Elle ajoute également une nouvelle syntaxe pour identifier les fichiers qui doivent être restaurés à partir du stockage d’archivage pour effectuer des requêtes.

L’activation de la prise en charge de l’archivage pour une table dans Azure Databricks ne crée pas ni ne modifie les stratégies de cycle de vie définies pour votre stockage d’objets cloud. Pour les résultats souhaités, votre stratégie de cycle de vie cloud et le paramètre delta.timeUntilArchived doivent être égaux.

Requêtes optimisées pour les données archivées

La prise en charge de l’archivage dans Azure Databricks optimise les requêtes suivantes sur les tables Delta :

Requête Nouveau comportement
SELECT * FROM <table_name> LIMIT <limit> [WHERE <partition_predicate>] Ignorez automatiquement les fichiers archivés et retournez les résultats des données d’un niveau de stockage non archivé.
Commandes de maintenance Delta Lake : OPTIMIZE, ZORDER, ANALYZE, PURGE Ignorez automatiquement les fichiers archivés et exécutez la maintenance sur le reste de la table.
Instructions DDL et DML qui remplacent ou suppriment des données, y compris les éléments suivants : REPLACE TABLE, INSERT OVERWRITE, TRUNCATE TABLE, DROP TABLE Marquez les entrées du journal des transactions pour les fichiers de données archivés cibles comme supprimées.
FSCK REPAIR TABLE Ignorez les fichiers archivés et vérifiez uniquement les fichiers qui n’ont pas atteint la stratégie de cycle de vie.

Voir Limitations.

Défaillance précoce et messages d’erreur

Pour les requêtes qui doivent analyser les fichiers archivés afin de générer des résultats corrects, la configuration de la prise en charge de l’archivage pour Delta Lake offre les garanties suivantes :

  • Les requêtes échouent tôt si elles tentent d’accéder aux fichiers archivés, ce qui réduit le gaspillage de calcul et permet aux utilisateurs d’adapter et de réexécuter rapidement les requêtes.
  • Les messages d’erreur informent les utilisateurs qu’une requête a échoué car elle a tenté d’accéder à des fichiers archivés.

Les utilisateurs peuvent générer un rapport des fichiers qui doivent être restaurés à l’aide de la syntaxe SHOW ARCHIVED FILES. Consultez Afficher les fichiers archivés.

Important

Si vous recevez l’erreur Not enough files to satisfy LIMIT, votre table n’a pas suffisamment de lignes de données dans les fichiers non archivés pour satisfaire le nombre d’enregistrements spécifiés par LIMIT. Réduisez la clause LIMIT pour trouver suffisamment de lignes non archivées pour satisfaire les lignes spécifiées LIMIT.

Activer la prise en charge de l’archivage

Vous activez la prise en charge de l’archivage dans Azure Databricks pour les tables Delta en spécifiant manuellement l’intervalle d’archivage configuré dans la stratégie de gestion du cycle de vie cloud sous-jacente, comme dans l’exemple de syntaxe suivant :

ALTER TABLE <table_name> SET TBLPROPERTIES(delta.timeUntilArchived = 'X days');

L’activation de la prise en charge de l’archivage indique à Azure Databricks d’ignorer les fichiers antérieurs à la période spécifiée. Si vous activez ce paramètre sans définir de stratégies de cycle de vie pour votre stockage d’objets cloud, Azure Databricks ignore toujours les fichiers en fonction de ce seuil spécifié, mais aucune donnée n’est archivée.

Delta Lake n’interagit pas directement avec les stratégies de gestion du cycle de vie configurées dans votre compte cloud. Si vous mettez à jour la stratégie dans votre compte cloud, vous devez mettre à jour la stratégie sur votre table Delta. Consultez Modifier la règle de transition de gestion du cycle de vie.

Important

La prise en charge de l’archivage s’appuie entièrement sur des environnements de calcul Azure Databricks compatibles et fonctionne uniquement pour les tables Delta. La configuration de la prise en charge de l’archivage ne modifie pas le comportement, la compatibilité ou la prise en charge dans les clients OSS Delta Lake ou Databricks Runtime 12.2 LTS et versions antérieures.

Afficher les fichiers archivés

Pour identifier les fichiers qui doivent être restaurés pour terminer une requête donnée, utilisez SHOW ARCHIVED FILES, comme dans l’exemple suivant :

SHOW ARCHIVED FILES FOR table_name [ WHERE predicate ];

Cette opération retourne les URI des fichiers archivés sous la forme d’un DataFrame Spark. Restaurez les fichiers archivés nécessaires en suivant les instructions documentées de votre fournisseur de stockage d’objets. Pour plus d’informations sur la façon dont Azure Databricks vérifie les données restaurées, consultez Comment Azure Databricks échantillonne-t-il les données restaurées ?

Remarque

Pendant cette opération, Delta Lake n’a accès qu’aux statistiques de données contenues dans le journal des transactions. Par défaut, voici les statistiques suivantes collectées sur les 32 premières colonnes de la table :

  • Valeurs minimales
  • Valeurs maximales
  • Nombres de valeurs nulles
  • Nombre total d'enregistrements

Les fichiers retournés incluent tous les fichiers archivés qui doivent être lus pour déterminer si les enregistrements remplissant un prédicat existent ou non dans le fichier. Databricks recommande de fournir des prédicats qui incluent des champs sur lesquels les données sont partitionnées, triées en z ou en cluster, pour réduire le nombre de fichiers qui doivent être restaurés.

Mettre à jour ou supprimer des données archivées

L’opération échoue si vous exécutez une opération MERGE, UPDATE ou DELETE qui a un impact sur les données dans les fichiers archivés. Vous devez restaurer des données dans un niveau de stockage qui prend en charge la récupération rapide pour exécuter ces opérations. Utilisez SHOW ARCHIVED FILES pour déterminer les fichiers que vous devez restaurer.

Comment Azure Databricks échantillonne-t-il les données restaurées ?

Quand Azure Databricks prépare une analyse sur une table avec prise en charge de l’archivage activée, il échantillonne les fichiers antérieurs à la période de rétention spécifiée requise par la requête pour déterminer si des fichiers ont été restaurés.

Si les résultats indiquent que les fichiers échantillonnés censés être archivés ont été restaurés, Azure Databricks suppose que tous les fichiers de la requête ont été restaurés et que les processus de requête ont été restaurés.

Limites

Les limites suivantes existent :

  • Il n’existe aucune prise en charge pour les stratégies de gestion du cycle de vie qui ne sont pas basées sur l’heure de création du fichier. Cela inclut les stratégies basées sur le temps d’accès et les stratégies basées sur les étiquettes.
  • Vous ne pouvez pas utiliser DROP COLUMN sur une table avec des fichiers archivés.
  • REORG TABLE APPLY PURGE effectue une tentative optimale, mais fonctionne uniquement sur les fichiers de vecteurs de suppression et les fichiers de données de référence qui ne sont pas archivés. PURGE n’est pas en mesure de supprimer les fichiers de vecteur de suppression archivés.
  • L’extension de la règle de transition de gestion du cycle de vie entraîne un comportement inattendu. Consultez Étendre la règle de transition de gestion du cycle de vie.

Modifier la règle de transition de gestion du cycle de vie

Si vous modifiez l’intervalle de temps de votre règle de transition de gestion du cycle de vie cloud, vous devez mettre à jour la propriété delta.timeUntilArchived.

Si l’intervalle de temps avant l’archivage est raccourci (moins de temps depuis la création du fichier), la prise en charge de l’archivage pour la table Delta continue de fonctionner normalement après la mise à jour de la propriété de table.

Étendre la règle de transition de gestion du cycle de vie

Si l’intervalle de temps avant l’archivage est étendu (pour ajouter plus de temps avant le déclenchement de l’archivage), la mise à jour de la propriété delta.timeUntilArchived à la nouvelle valeur peut entraîner des erreurs. Les fournisseurs de cloud ne restaurent pas automatiquement les fichiers à partir du stockage archivé lorsque les stratégies de conservation des données sont modifiées. Cela signifie que les fichiers précédemment éligibles à l’archivage, mais maintenant non considérés comme éligibles pour l’archivage sont toujours archivés.

Important

Pour éviter des erreurs, ne définissez jamais la propriété delta.timeUntilArchived sur une valeur supérieure à l’âge réel des données les plus récemment archivées.

Prenons un scénario dans lequel l’intervalle de temps pour l’archivage passe de 60 jours à 90 jours :

  1. Tous les enregistrements compris entre 60 et 90 jours sont archivés lorsque la stratégie change.
  2. Pendant 30 jours, aucun nouveau fichier n’est archivé (les fichiers non archivés les plus anciens datent de 60 jours au moment de l’extension de la stratégie).
  3. Après 30 jours, la stratégie de cycle de vie décrit correctement toutes les données archivées.

Le paramètre delta.timeUntilArchived effectue le suivi de l’intervalle de temps défini par rapport à l’heure de création du fichier enregistrée par le journal des transactions Delta. Il n’a pas de connaissance explicite de la stratégie sous-jacente. Pendant la période de décalage entre l’ancien seuil d’archivage et le nouveau seuil d’archivage, vous pouvez adopter l’une des approches suivantes pour éviter d’interroger les fichiers archivés :

  1. Vous pouvez laisser le paramètre delta.timeUntilArchived défini sur l’ancien seuil jusqu’à ce que le temps écoulé soit suffisant pour que tous les fichiers soient archivés.
    • En suivant l'exemple ci-dessus, chaque jour pendant les 30 premiers jours, la quantité de données journalières serait considérée comme archivée par Azure Databricks, mais doit encore être archivée par le fournisseur de cloud. Cela n’entraîne pas d’erreur, mais ignore certains fichiers de données qui peuvent être interrogés.
    • Après 30 jours, mettez à jour delta.timeUntilArchived sur 90 days.
  2. Vous pouvez mettre à jour le paramètre delta.timeUntilArchived chaque jour pour refléter l’intervalle actuel pendant la période de décalage.
    • Alors que la stratégie cloud est définie sur 90 jours, l’âge réel des données archivées change en temps réel. Par exemple, après 7 jours, définir delta.timeUntilArchived sur 67 days reflète avec précision l’âge de tous les fichiers de données archivés.
    • Cette approche n’est nécessaire que si vous devez accéder à toutes les données des niveaux chauds.

Remarque

Mettre à jour la valeur de delta.timeUntilArchived ne modifie pas quelles données sont archivées. Cela modifie uniquement les données qu’Azure Databricks traite comme si elles avaient été archivées.