Time Travel vous permet d'interroger les données historiques d'une table transactionnelle (Delta) à n'importe quel point de validation antérieur situé dans la fenêtre de rétention configurée. Vous pouvez lire les données telles qu'elles existaient à un horodatage ou à un ID de version spécifique, et restaurer une table vers un état antérieur.
Cas d'utilisation
Récupération après erreur : Interrogez la table à un instant antérieur à une écriture incorrecte, à l'échec d'un pipeline ou à une suppression accidentelle, puis utilisez ces résultats pour corriger les données en aval.
Audits historiques : Inspectez l'état exact d'un jeu de données à n'importe quel point de validation antérieur pour effectuer des vérifications de conformité et analyser la lignée des données.
Comparaison des données : Comparez les données entre deux versions historiques différentes pour comprendre comment les enregistrements ont évolué entre les exécutions de traitement.
Restauration à un instant donné : Ramenez une table entière à une version historique spécifique pour annuler un lot de modifications.
Prérequis
Time Travel est pris en charge uniquement sur les tables transactionnelles. Les tables non transactionnelles et les tables externes ne prennent pas en charge cette fonctionnalité.
Les données historiques sont disponibles uniquement dans la fenêtre de rétention configurée. Vous devez configurer la propriété de table acid.data.retain.hours pour conserver les données historiques. Consultez la section Configurer la rétention des données pour plus de détails.
Interroger les données historiques
Interrogation par horodatage
Utilisez TIMESTAMP AS OF pour lire la table telle qu'elle existait à un instant précis.
-- Query using a specific timestamp SELECT FROM src TIMESTAMP AS OF '2024-01-15 10:00:00'; -- Query using the timestamp of the last committed version SELECT FROM src TIMESTAMP AS OF get_latest_timestamp(1);
La fonction get_latest_timestamp accepte un paramètre : le nombre de validations à remonter. get_latest_timestamp(1) renvoie l'horodatage de la version la plus récemment validée.
Interrogation par ID de version
Utilisez VERSION AS OF pour lire la table à un ID de version de transaction spécifique.
-- Query using a specific version ID SELECT FROM src VERSION AS OF 3; -- Query using the version ID of the last committed version SELECT FROM src VERSION AS OF get_latest_version(2);
La fonction get_latest_version accepte un paramètre : le nombre de validations à remonter. get_latest_version(2) renvoie l'ID de version correspondant à deux validations avant la dernière.
Restaurer une table vers une version historique
Utilisez restore pour remplacer l'état actuel de la table par les données d'une version historique. Cette opération est irréversible.
-- Restore to a specific timestamp RESTORE TABLE src TO TIMESTAMP AS OF '2024-01-15 10:00:00'; -- Restore to a specific version ID RESTORE TABLE src TO VERSION AS OF 3;
Types de versions de transaction
Time Travel prend en charge deux types de versions :
| Type de version | Description | Clause SQL |
|---|---|---|
| Version temporelle | Identifie une transaction par horodatage | TIMESTAMP AS OF |
| Version par ID | Identifie une transaction par son ID de version interne | VERSION AS OF |
Utilisez get_latest_timestamp et get_latest_version lorsque vous devez faire référence à une version relative à la dernière validation plutôt que par une valeur absolue. Le deuxième paramètre de ces deux fonctions indique le nombre de validations précédentes, ce que MaxCompute utilise pour résoudre la version interne des données correspondante.
Configurer la rétention des données
La propriété de table acid.data.retain.hours contrôle la durée de conservation des données historiques. Définissez-la avec ALTER TABLE :
-- Set a 48-hour retention window ALTER TABLE src SET TBLPROPERTIES ('acid.data.retain.hours' = '48');
La période de rétention maximale est de sept jours. Choisissez une valeur adaptée à vos besoins opérationnels. Une période de rétention plus longue augmente les coûts de stockage, car MaxCompute doit préserver les fichiers Delta historiques.
Pour désactiver Time Travel et réduire les coûts de stockage, définissez acid.data.retain.hours sur 0 :
-- Disable Time Travel for a table ALTER TABLE src SET TBLPROPERTIES ('acid.data.retain.hours' = '0');
Le réglage de la propriété sur 0 arrête la conservation des données historiques et réduit considérablement les coûts de stockage.
Fonctionnement
Le diagramme suivant illustre le processus d'interrogation interne pour une requête Time Travel sur une table transactionnelle.
Lorsque vous exécutez une requête Time Travel, MaxCompute :
Analyse l'instruction SQL et identifie la version cible (horodatage ou ID de version).
Localise le fichier de base le plus récent qui se situe dans la plage temporelle de cette version.
Localise les fichiers delta écrits après la génération du fichier de base, jusqu'à la version cible.
Fusionne le fichier de base et les fichiers Delta pertinents pour produire le résultat de la requête.
**Exemple : table transactionnelle src**
Prenons l'exemple d'une table transactionnelle nommée src avec les colonnes pk et val. Cinq transactions d'écriture s'exécutent aux instants t1 à t5, produisant cinq fichiers Delta. La compaction s'exécute aux instants t2 et t4, générant respectivement les fichiers de base b1 et b2.
Lors de la compaction à l'instant t2, l'enregistrement d'état intermédiaire historique (2,a) est supprimé du fichier de base b1, et seul l'enregistrement d'état le plus récent (2,b) est conservé dans b1.
| Instant de la requête | Fichiers lus | Résultat |
|---|---|---|
| t1 | Fichier Delta d1 uniquement | Sortie de d1 |
| t2 | Fichier de base b1 uniquement | Trois enregistrements |
| t3 | Fichier de base b1 + Fichier Delta d3 | Sortie fusionnée |
| t4, t5 | Fichier de base b2 + Fichiers Delta pertinents | Sortie fusionnée |
Les fichiers de base améliorent l'efficacité des requêtes et des lectures en fournissant un instantané compact et fusionné de l'état de la table à un instant donné. Toutefois, les interrogations de fichiers de base déclenchent des opérations de compaction qui consomment un grand nombre de ressources. Choisissez une politique de déclenchement de la compaction adaptée à votre charge de travail.
Limites
Time Travel est pris en charge uniquement sur les tables transactionnelles (Delta). Les tables non transactionnelles et les tables externes ne sont pas prises en charge.
Les données historiques antérieures à la fenêtre de rétention configurée ne sont plus disponibles pour interrogation ou restauration.
La période de rétention maximale est de sept jours, quelle que soit la valeur définie pour
acid.data.retain.hours.Le réglage de
acid.data.retain.hourssur0désactive Time Travel et supprime la conservation des données historiques pour la table.