Prise en charge de l'archivage dans Databricks

info

Aperçu

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 Databricks vous permet d'utiliser des stratégies de cycle de vie basées sur le cloud sur le stockage d'objets cloud contenant des tables Delta. L'activation du support d'archivage sur une table Delta Lake indique efficacement à Databricks d'ignorer les fichiers qui sont plus anciens que la période spécifiée dans la table.

Exigences

Le support d'archivage nécessite S3 Glacier Deep Archive ou Glacier Flexible Retrieval. Consultez la documentation AWS sur l'utilisation des objets archivés.

Amazon S3 Glacier Instant Retrieval ne nécessite pas la configuration de la prise en charge de l'archivage. Cependant, lorsque vous exécutez une query, tous les fichiers analysés sont récupérés. Databricks recommande d'utiliser des vues pour restreindre les query contre les tables stockées dans Glacier Instant Retrieval avec des politiques de cycle de vie configurées.

attention

Amazon S3 Intelligent-Tiering, niveaux d'accès d'archivage asynchrones facultatifs, n'est pas compatible avec le support d'archivage dans Databricks, car il archive en fonction de l'heure d'accès plutôt que de l'heure de création du fichier.

Pourquoi devriez-vous activer le support d'archivage ?

Le support d'archivage autorise uniquement les queries qui peuvent être répondues correctement sans toucher aux fichiers archivés. Ces queries incluent celles qui :

• Interroger uniquement les métadonnées.
• Disposer de filtres qui ne nécessitent pas l'analyse de fichiers archivés.

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

important

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

L’activation de la prise en charge de l’archivage pour une table dans Databricks ne crée ni ne modifie les politiques de cycle de vie définies pour votre stockage d’objets cloud. Voir Modifier la règle de transition de gestion du cycle de vie.

Sans prise en charge de l'archivage, les opérations sur les tables Delta pourraient échouer car les fichiers de données ou les fichiers Logs de transactions ont été déplacés vers des emplacements archivés et ne sont pas disponibles lorsqu'ils sont interrogés. La prise en charge de l'archivage introduit des optimisations pour éviter de requêter les données archivées dans la mesure du possible. Il ajoute également une nouvelle syntaxe pour identifier les fichiers qui doivent être restaurés à partir du stockage d'archives afin de terminer les requêtes.

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

La prise en charge de l'archivage dans Databricks optimise les queries suivantes sur les tables Delta.

Saisir une requête	Nouveau comportement
SELECT * FROM <table_name> LIMIT <limit> [WHERE <partition_predicate>]	Ignorer automatiquement les fichiers archivés et renvoyer les résultats des données dans un niveau de stockage non archivé.
Commandes de maintenance Delta Lake : OPTIMIZE, ZORDER, ANALYZE, PURGE	Ignorer automatiquement les fichiers archivés et effectuer la maintenance sur le reste de la table.
Instructions DDL et DML qui écrasent ou suppriment des données, notamment les suivantes : REPLACE TABLE, INSERT OVERWRITE, TRUNCATE TABLE, DROP TABLE	Marquer les entrées de log de transaction pour les fichiers de données archivés cible comme supprimées.
FSCK REPAIR TABLE	Ignorez les fichiers archivés et vérifiez uniquement les fichiers qui n’ont pas atteint la politique de cycle de vie.

Saisir une requête	Nouveau comportement
SELECT * FROM <table_name> LIMIT <limit> [WHERE <partition_predicate>]	Ignorer automatiquement les fichiers archivés et renvoyer les résultats des données dans un niveau de stockage non archivé.
Commandes de maintenance Delta Lake : OPTIMIZE, ZORDER, ANALYZE, PURGE	Ignorer automatiquement les fichiers archivés et effectuer la maintenance sur le reste de la table.
Instructions DDL et DML qui écrasent ou suppriment des données, notamment les suivantes : REPLACE TABLE, INSERT OVERWRITE, TRUNCATE TABLE, DROP TABLE	Marquer les entrées de log de transaction pour les fichiers de données archivés cible comme supprimées.
FSCK REPAIR TABLE	Ignorez les fichiers archivés et vérifiez uniquement les fichiers qui n’ont pas atteint la politique de cycle de vie.

Messages d'erreur et d'échec précoce

Pour les queries qui doivent analyser les fichiers archivés afin de générer des résultats corrects, la configuration du support d'archivage pour Delta Lake garantit les éléments suivants :

• Les requêtes échouent prématurément si elles tentent d'accéder à des fichiers archivés, ce qui réduit le gaspillage de compute et permet aux utilisateurs de s'adapter et de réexécuter rapidement les requêtes.
• Les messages d'erreur informent les utilisateurs qu'une query a échoué parce que la query 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. Voir Afficher les fichiers archivés.

important

Si l’erreur Not enough files to satisfy LIMIT s’affiche, votre table ne contient pas suffisamment de lignes de données dans les fichiers non archivés pour atteindre le nombre d’enregistrements spécifié par LIMIT. Réduisez la clause LIMIT pour trouver suffisamment de lignes non archivées pour répondre à la valeur spécifiée LIMIT. Consultez les Limitations.

Activer le support d'archivage

Vous activez la prise en charge de l'archivage pour les tables Delta en spécifiant manuellement l'intervalle d'archivage configuré dans la politique de gestion du cycle de vie du cloud sous-jacente.

SQL

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

Définir un temps de timeUntilArchived indique à Databricks d’ignorer les fichiers de votre table Delta Lake qui sont plus anciens que la période spécifiée. Ce paramètre est distinct des politiques de cycle de vie de votre compte cloud. Les modifications de l'un n'affectent pas l'autre. Si vous mettez à jour la politique de cycle de vie dans votre compte cloud, vous devez également mettre à jour le paramètre d'archivage sur votre table Delta Lake. Consultez Modifier la règle de transition de gestion du cycle de vie.

Lorsque vous définissez une nouvelle politique de cycle de vie dans votre compte cloud, un délai peut s'écouler avant que la politique ne soit entièrement propagée à tous les systèmes S3. Voir Configuration du cycle de vie.

Si vous activez ce paramètre sans politiques de cycle de vie définies pour votre stockage d'objets cloud, le support d'archivage permet aux queries de réussir, et les résultats incluent les données des fichiers marqués pour l'archivage. Consultez Comment Databricks échantillonne-t-il les données restaurées ?.

attention

Votre politique de cycle de vie du cloud ne doit pas archiver le log de transactions Delta (répertoire _delta_log/). Consultez les Limitations.

important

La prise en charge de l'archivage repose entièrement sur des environnements de compute Databricks compatibles et ne fonctionne que pour les tables Delta. La configuration de la prise en charge de l'archivage ne modifie pas le comportement, la compatibilité ou le support 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 query donnée, utilisez SHOW ARCHIVED FILES.

SQL

SHOW ARCHIVED FILES FOR table_name [ WHERE predicate ];

Cette opération renvoie 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. Voir Restaurer les fichiers archivés.

Pour plus d'informations sur la façon dont Databricks vérifie les données restaurées, consultez How does Databricks sample for restored data ?.

remarque

Au cours de cette opération, Delta Lake n'a accès qu'aux statistiques de données contenues dans le journal des transactions. By default, voici les statistiques suivantes collectées sur les 32 premières colonnes du tableau :

• Valeurs minimales
• Valeurs maximales
• Comptes nuls
• Nombre total d'enregistrements

Les fichiers renvoyés incluent tous les fichiers archivés qui doivent être lus pour déterminer si des enregistrements répondant à 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, Z-ordered ou regroupées en clusters afin de réduire le nombre de fichiers qui doivent être restaurés.

Restaurer les fichiers archivés

Pour identifier tous les fichiers nécessitant une restauration, veuillez utiliser SHOW ARCHIVED FILES pour consulter la liste des fichiers archivés.

Utilisez les APIs de restauration d'objets S3 pour restaurer vos fichiers vers un niveau de stockage à récupération rapide. Consultez Restaurer un objet archivé.

Après avoir restauré les fichiers dans le stockage de votre fournisseur cloud, vous pouvez query votre table. Le support d'archivage reconnaît automatiquement les fichiers restaurés. Pour plus d'informations sur la manière dont Databricks vérifie les données restaurées, consultez Comment 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 des fichiers archivés. Vous devez restaurer les données vers un niveau de stockage qui prend en charge une récupération rapide pour exécuter ces opérations. Utilisez SHOW ARCHIVED FILES pour déterminer les fichiers que vous devez restaurer (voir Restaurer les fichiers archivés).

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

Lorsque Databricks prépare une analyse sur une table avec la prise en charge de l'archivage activée, il échantillonne les fichiers plus anciens que la période de rétention spécifiée requise par la query afin de déterminer si les fichiers ont été restaurés ou non. Si les résultats indiquent que les fichiers échantillonnés présumés archivés ont été restaurés, Databricks suppose que tous les fichiers de la query ont été restaurés et que la query est traitée. Les résultats incluent les données des fichiers marqués pour archivage.

L'échantillonnage peut ne pas s'appliquer à toutes les query, consultez les Limites.

Limitations

Les limitations suivantes existent :

• Le support d'archivage s'applique uniquement aux fichiers de données. Si des fichiers du log de transactions Delta (répertoire _delta_log/) sont déplacés vers un niveau de stockage archivé, la table devient entièrement inaccessible et toutes les query sur la table échouent. Vous devez configurer votre politique de cycle de vie du cloud afin que le chemin _delta_log/ ne soit pas inclus dans l'archivage. Consultez les exemples de configurations du cycle de vie S3.
• Aucun support n'existe pour les politiques de gestion du cycle de vie qui ne sont pas basées sur l'heure de création des fichiers. Cela inclut les politiques basées sur l'heure d'accès et les politiques basées sur les tags.
• Vous ne pouvez pas utiliser DROP COLUMN sur une table avec des fichiers archivés.
• REORG TABLE APPLY PURGE fait une tentative de bonne foi, mais ne fonctionne que sur les fichiers vectoriels de suppression et les fichiers de données référencés qui ne sont pas archivés. PURGE ne peut pas supprimer les fichiers vectoriels de suppression archivés.
• L’extension de la règle de transition de la gestion du cycle de vie entraîne un comportement inattendu. Consultez Prolonger la règle de transition de gestion du cycle de vie.
• LIMIT Les requêtes sur les tables avec support d'archivage activé ne Trigger pas d'échantillonnage pour les données restaurées. Si les données d'une table sont restaurées, la plupart des query réussissent lors de l'interrogation des données restaurées, mais une query LIMIT renvoie une erreur DELTA_ARCHIVED_FILES_IN_LIMIT. Voir Comment Databricks échantillonne-t-il les données restaurées ?.

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

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

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 la table.

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

Si l'intervalle de temps avant l'archivage est prolongé (pour ajouter plus de temps avant que l'archivage ne soit déclenché), la mise à jour de la propriété delta.timeUntilArchived vers la nouvelle valeur peut entraîner des erreurs. Les fournisseurs cloud ne restaurent pas automatiquement les fichiers depuis le stockage archivé lorsque les politiques de rétention des données sont modifiées. Cela signifie que les fichiers précédemment éligibles à l'archivage, mais qui ne le sont plus, sont toujours archivés.

important

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

Considérez un scénario dans lequel l'intervalle de temps pour l'archivage passe de 60 jours à 90 jours :

1. Tous les enregistrements datant de 60 à 90 jours sont archivés lorsque la politique change.
2. Pendant 30 jours, aucun nouveau fichier n'est archivé (les fichiers non archivés les plus anciens ont 60 jours lorsque la politique est étendue).
3. Après 30 jours, la politique 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 politique sous-jacente. Pendant la période de latence entre l'ancien threshold d'archivage et le nouveau threshold 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 avec l'ancien threshold jusqu'à ce que suffisamment de temps se soit écoulé pour que tous les fichiers soient archivés.

   • En suivant l'exemple ci-dessus, chaque jour pendant les 30 premiers jours, la valeur de données d'un autre jour serait considérée comme archivée par 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 pourraient être query.
   • Après 30 jours, mettez à jour le delta.timeUntilArchived vers 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 latence.

   • Alors que la politique du cloud est définie à 90 jours, l'âge réel des données archivées change en temps réel. Par exemple, après 7 jours, le réglage de delta.timeUntilArchived sur 67 days reflète précisément 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 dans les niveaux chauds.

remarque

La mise à jour de la valeur pour delta.timeUntilArchived ne change pas les données archivées. Cela ne change que les données que Databricks traite comme si elles étaient archivées.