Prise en charge de l’archivage dans Azure Databricks

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.

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.

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 :

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.

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.

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 ?

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.

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.