Aller au contenu principal

Suppression automatique des lignes avec une durée de vie automatique

Auto time-to-live (Auto-TTL) supprime automatiquement les lignes des tables gérées par Unity Catalog après une période configurable, en fonction de la valeur d'une colonne timestamp. Vous définissez une période d'expiration en jours et spécifiez une colonne timestamp pour la comparaison. Databricks exécute les opérations DELETE, PURGE et VACUUM en arrière-plan pour supprimer les lignes expirées et les effacer du stockage.

Voici deux exemples d'utilisation de la durée de vie automatique :

  • Vous voudrez peut-être supprimer les données de plus de 1 an pour maintenir des coûts de stockage faibles. Faire expirer les lignes 1 an après la création en spécifiant une période d'expiration de 365 jours sur une colonne Timestamp created_at.
  • Vous pourriez vouloir supprimer des données qui ont été marquées pour suppression par un autre processus métier. Faites expirer les lignes 20 jours après le traitement d'une demande de suppression en spécifiant une période d'expiration de 20 jours sur une colonne Timestamp del_request_approved personnalisée.
important

Le moment exact de la suppression n'est pas garanti et peut varier en fonction de la charge du système. Pour vérifier la suppression, interrogez la table système d'optimisation prédictive ou exécutez DESCRIBE HISTORY sur la table. Consulter les tables système.

Le temps tampon entre l'expiration des lignes et la suppression permanente peut être de 6 jours maximum plus la valeur de la propriété de rétention des données de la table, qui est de 7 jours par default. Pour savoir comment configurer la durée de vie automatique pour la suppression dans un délai spécifique, consultez Calculer les valeurs de configuration pour une période d'expiration cible et Configurer la rétention des données pour les queries time travel.

Le TTL automatique est disponible pour les tables Delta Lake gérées par Unity Catalog, les tables Apache Iceberg et les tables de streaming avec Lakeflow Pipelines.

Exigences

  • Vous devez activer l'optimisation prédictive. Consultez Optimisation prédictive pour les tables gérées par Unity Catalog.

    • La désactivation de l'optimisation prédictive sur une table avec la durée de vie automatique activée empêche l'exécution de la durée de vie automatique.
  • Vous devez disposer des autorisations MODIFY sur une table pour définir ou supprimer une politique d'expiration automatique. Voir Autorisations de table de base.

  • Databricks Runtime 17.3 et versions supérieures.

    • Databricks Runtime 17.2 et versions inférieures peuvent lire et écrire dans des tables avec une durée de vie automatique.

Activer la durée de vie automatique

Activez la durée de vie automatique différemment selon la table source :

Tables gérées Delta Lake et Apache Iceberg

Pour définir une politique de durée de vie automatique sur une nouvelle table, spécifiez un entier non négatif pour <expiration_days> et une colonne de type DATE, TIMESTAMP ou TIMESTAMP_NTZ pour <time_column_name>:

SQL
CREATE TABLE table_name DELETE ROWS <expiration_days> DAYS AFTER <time_column_name>;

Pour définir une stratégie de durée de vie automatique sur une table existante :

SQL
ALTER TABLE table_name DELETE ROWS <expiration_days> DAYS AFTER <time_column_name>;

Par exemple, pour supprimer des lignes 30 jours après leur created_at timestamp :

SQL
ALTER TABLE my_catalog.my_schema.my_table DELETE ROWS 30 DAYS AFTER created_at;

Tables de streaming avec les LakeFlow Pipelines

Pour définir une politique de durée de vie automatique sur une nouvelle table de streaming dans un pipeline, spécifiez deux valeurs. Fournissez un entier non négatif pour <expiration_days> et une colonne de type DATE, TIMESTAMP, ou TIMESTAMP_NTZ pour <time_column_name>:

SQL
CREATE STREAMING TABLE table_name
DELETE ROWS <expiration_days> DAYS AFTER <time_column_name>
AS SELECT * FROM STREAM(source);

La modification d'une table de streaming pour utiliser la durée de vie automatique à l'aide de SQL n'est pas prise en charge. Pour modifier la durée de vie automatique sur une table de streaming existante, mettez à jour le code de pipeline et republiez.

Lectures en streaming à partir de tables avec une durée de vie automatique

Si vous utilisez Structured Streaming, Lakeflow pipelines ou des tables de streaming pour lire à partir d'une table où la durée de vie automatique est activée, définissez skipChangeCommits sur la lecture en streaming. Les opérations de suppression automatique à durée de vie limitée apparaissent lorsque les données changent. Sans ce paramètre, la lecture en streaming échoue lorsque la durée de vie automatique supprime des lignes.

Voir les exemples suivants :

Python
# Source table with auto time-to-live
spark.sql("ALTER TABLE source_table DELETE ROWS <expiration_days> DAYS AFTER <time_column_name>")

# Structured Streaming read
spark.readStream.format("delta").option("skipChangeCommits", "true").table("source_table")

Vérifier si la durée de vie automatique est activée

Utilisez DESCRIBE TABLE EXTENDED pour confirmer que la durée de vie automatique est configurée. Si les propriétés autottl.expireInDays et autottl.timestampColumn sont définies, la durée de vie automatique est activée.

Les paramètres de durée de vie automatique apparaissent dans la ligne **Propriétés de la table** :

SQL
DESCRIBE TABLE EXTENDED table_name;

Vous pouvez également utiliser SHOW TBLPROPERTIES pour voir les propriétés de durée de vie automatique :

SQL
SHOW TBLPROPERTIES table_name;

Désactiver la durée de vie automatique

Pour supprimer une politique de durée de vie automatique d'une table Delta Lake ou Apache Iceberg gérée :

SQL
ALTER TABLE table_name DROP ROW DELETION;

Pour supprimer une politique de durée de vie automatique sur une table de streaming, définissez auto_ttl sur None dans le code du pipeline et republiez :

Python
from pyspark import pipelines as dp

@dp.table(
auto_ttl=None
)
def function_name():
return (query)

Cycle de vie des données

La durée de vie automatique peut aider à automatiser la gestion du cycle de vie des données pour les tables avec des exigences de rétention basées sur le temps.

L'Auto time-to-live possède un cycle de vie des données à plusieurs étapes. Après l'expiration d'une ligne, l'optimisation prédictive exécute de manière asynchrone les commandes DELETE et VACUUM. Si les vecteurs de suppression sont activés sur la table, l'optimisation prédictive exécute également PURGE avant VACUUM pour réécrire les fichiers de données et supprimer les lignes supprimées. Voir Purger les suppressions de métadonnées uniquement pour forcer la réécriture des données.

Le moment exact de la suppression n'est pas garanti et peut varier en fonction de la charge du système. Pour des informations sur la façon de vérifier que les données ont été supprimées, consultez les tables système.

Pour configurer correctement la durée de vie automatique pour vos exigences de rétention des données, examinez les étapes ci-dessous :

Étape

Durée

Description

Période d'expiration

L'utilisateur définit le moment où il faut activer la durée de vie automatique.

Le nombre de jours après la valeur de la colonne de temps où une ligne devient éligible à la suppression. Définissez ceci lorsque vous activez la durée de vie automatique.

Temps tampon

Jusqu'à 3 jours par commande (DELETE, VACUUM)

Le délai entre le moment où les lignes deviennent éligibles à la suppression et le moment où l’optimisation prédictive les supprime. Des retards peuvent survenir entre l'expiration des lignes et chaque commande asynchrone, DELETE et VACUUM. Chaque délai est généralement inférieur à 3 jours, jusqu'à un total de 6 jours.

Durée de conservation des données

L'utilisateur définit avec une propriété de table.

La durée pendant laquelle les lignes supprimées restent stockées et accessibles par le time travel. Pour les tables Delta Lake, configurez avec delta.deletedFileRetentionDuration. Pour les tables Apache Iceberg, configurez avec iceberg.deletedFileRetentionDuration. Si la propriété n'est pas définie, la valeur default est de 7 jours. Voir Configurer la rétention des données pour les queries en time travel.

Étape

Durée

Description

Période d'expiration

L'utilisateur définit le moment où il faut activer la durée de vie automatique.

Le nombre de jours après la valeur de la colonne de temps où une ligne devient éligible à la suppression. Définissez ceci lorsque vous activez la durée de vie automatique.

Temps tampon

Jusqu'à 3 jours par commande (DELETE, VACUUM)

Le délai entre le moment où les lignes deviennent éligibles à la suppression et le moment où l’optimisation prédictive les supprime. Des retards peuvent survenir entre l'expiration des lignes et chaque commande asynchrone, DELETE et VACUUM. Chaque délai est généralement inférieur à 3 jours, jusqu'à un total de 6 jours.

Durée de conservation des données

L'utilisateur définit avec une propriété de table.

La durée pendant laquelle les lignes supprimées restent stockées et accessibles par le time travel. Pour les tables Delta Lake, configurez avec delta.deletedFileRetentionDuration. Pour les tables Apache Iceberg, configurez avec iceberg.deletedFileRetentionDuration. Si la propriété n'est pas définie, la valeur default est de 7 jours. Voir Configurer la rétention des données pour les queries en time travel.

Après suppression définitive via VACUUM, les lignes supprimées ne sont plus accessibles par time travel. Voir Supprimer les fichiers de données inutilisés avec vacuum.

Voici une chronologie visuelle du cycle de vie des données, où une ligne avec une valeur de colonne temporelle de t passe par quatre phases avant que ses fichiers ne soient physiquement supprimés par VACUUM:

Diagramme du cycle de vie des données avec durée de vie automatique, montrant la période d&#39;expiration, le temps de tampon, la période de conservation des données et les phases de suppression permanente le long d&#39;une chronologie journalière.

Calculer les valeurs de configuration pour une période d’expiration cible

important

La durée de vie automatique supprime les données de manière asynchrone. Voir cycle de vie des données.

Pour configurer l'optimisation prédictive afin de supprimer des lignes du stockage dans un nombre de jours cible, soustrayez le temps de tampon maximal (6 jours) et la durée de rétention des fichiers supprimés de votre cible :

Text
target_expiration_days = target_days - 6 - deletedFileRetentionDuration

Par exemple, pour supprimer des lignes de moins de 30 jours avec la période de rétention par default de 7 jours, définissez expiration_days sur 17 DAYS:

Text
target_expiration_days = 30 - 6 - 7 = 17 days

Pour supprimer des lignes dans les 90 jours avec une période de rétention de 30 jours, définissez expiration_days sur 54 DAYS:

Text
target_expiration_days = 90 - 6 - 30 = 54 days

Surveiller la durée de vie automatique

Avec les tables système, vous pouvez vérifier les événements auto time-to-live, surveiller les coûts et définir des alertes pour les échecs.

Tables système

Vérifiez les événements de durée de vie automatique avec la table système d'optimisation prédictive. L'optimisation prédictive exécute DELETE pour supprimer les lignes expirées, VACUUM pour les supprimer du stockage, et facultativement PURGE pour les tables avec des vecteurs de suppression activés afin de créer de nouveaux fichiers sans lignes supprimées.

Exécutez la query suivante pour examiner les Opérations de durée de vie automatique sur toutes les tables au cours des 7 derniers jours :

SQL
WITH tables_with_deletes AS (
SELECT DISTINCT catalog_name, schema_name, table_name
FROM system.storage.predictive_optimization_operations_history
WHERE
operation_type = 'DELETE'
AND timestampdiff(day, start_time, now()) < 7
)
SELECT hist.*
FROM system.storage.predictive_optimization_operations_history AS hist
INNER JOIN tables_with_deletes AS t
ON hist.catalog_name = t.catalog_name
AND hist.schema_name = t.schema_name
AND hist.table_name = t.table_name
WHERE
hist.operation_type IN ('DELETE', 'PURGE', 'VACUUM')
AND timestampdiff(day, hist.start_time, now()) < 7
ORDER BY hist.start_time DESC;

Définir une alerte pour les échecs de durée de vie automatique.

Pour recevoir des notifications lorsque les opérations de durée de vie automatique échouent, créez une alerte Databricks SQL avec une query qui vérifie les opérations échouées dans la table système d'optimisation prédictive. Consultez l'alerte Databricks SQL pour obtenir des instructions sur la création d'alertes, et la documentation des tables système pour des exemples de requêtes.

Estimer les coûts de durée de vie automatique

Utilisez la query suivante pour voir combien de DBUs les opérations de durée de vie automatique ont consommé au cours des 30 derniers jours :

SQL
WITH tables_with_deletes AS (
SELECT DISTINCT table_name
FROM system.storage.predictive_optimization_operations_history
WHERE
operation_type = 'DELETE'
AND timestampdiff(day, start_time, now()) < 30
)
SELECT SUM(usage_quantity) AS total_estimated_dbu
FROM system.storage.predictive_optimization_operations_history AS hist
INNER JOIN tables_with_deletes AS t
ON hist.table_name = t.table_name
WHERE
hist.operation_type IN ('DELETE', 'PURGE', 'VACUUM')
AND hist.usage_unit = 'ESTIMATED_DBU'
AND timestampdiff(day, hist.start_time, now()) < 30;

Examiner les Opérations sur une table spécifique

Utilisez DESCRIBE HISTORY pour voir les opérations récentes exécutées sur une table spécifique :

SQL
DESCRIBE HISTORY table_name;

Limitations

Les limitations suivantes s'appliquent à la durée de vie automatique :

important

Le moment exact de la suppression n'est pas garanti et peut varier en fonction de la charge du système. Pour des informations sur la façon de vérifier que les données ont été supprimées, consultez les tables système.

  • Le temps de vie automatique n'est pas pris en charge sur les vues matérialisées.

  • ALTER TABLE et la syntaxe ALTER STREAMING TABLE ne sont pas pris en charge pour la modification de la durée de vie automatique sur les tables de streaming. Pour ajouter ou modifier une politique de durée de vie automatique sur une table de streaming existante, mettez à jour le auto_ttl paramètre dans le code du pipeline et republiez le pipeline.

  • Le renommage de colonne n'est pas pris en charge pour les colonnes temporelles définies dans une politique de durée de vie automatique. Si le mappage de colonnes est activé, cette limitation s'applique toujours. Voir Renommer et supprimer des colonnes avec le mappage de colonnes Delta Lake.

  • Dans de rares cas, les opérations de durée de vie automatique peuvent entraîner des conflits de transactions. Pour réduire le risque de conflits de transactions, utilisez le clustering liquide, qui réduit les conflits avec la simultanéité au niveau des lignes. Consultez Utiliser le clustering liquide pour les tables.

  • Si le compute serverless ne peut pas accéder à S3 en raison d'un private link, les opérations de durée de vie automatique pourraient échouer. Consultez Configurer la connectivité privée aux ressources gérées par AWS