Concevoir et implémenter une table temporelle (historique) pour enregistrer les modifications au fil du temps

Les pipelines de données nécessitent souvent le suivi non seulement des valeurs actuelles, mais chaque modification qui se produit au fil du temps. Les tables temporelles fournissent un mécanisme permettant d’enregistrer automatiquement les modifications au niveau des lignes, ce qui permet d’activer des requêtes à un point dans le temps et d’effectuer des pistes d’audit. Contrairement aux dimensions à variation lente qui se concentrent sur l’historique des données métiers, les tables temporelles capturent l’historique technique pour la traçabilité opérationnelle et le débogage.

Comprendre les tables temporelles par rapport au type SCD 2

Les tables temporelles et les dimensions SCD Type 2 servent à des fins différentes, bien que les deux suivent les modifications historiques. Comprendre quand utiliser chaque approche vous aide à concevoir des solutions appropriées.

SCD Type 2 suit les modifications apportées aux entités métier au fil du temps pour la création de rapports analytiques. Lorsqu’un client passe de Seattle à Portland, vous souhaitez attribuer des ventes historiques à l’emplacement du client au moment de chaque transaction. SCD Type 2 gère des versions significatives pour l’entreprise avec des dates de début et de fin explicites.

Les tables temporelles (historique) capturent les modifications techniques pour les besoins opérationnels. Lors de la résolution des problèmes de chargement incorrect des données, vous devez voir exactement quelles valeurs existaient à chaque moment, quels fichiers ont été traités et quand des modifications se sont produites. Les tables temporelles fournissent automatiquement cette fonctionnalité d’investigation.

Envisagez d’utiliser des tables temporelles lorsque vous devez :

• Déboguer des problèmes d’ingestion de données en examinant l’état de la table à des horodatages spécifiques
• Auditer toutes les modifications pour la conformité ou les exigences réglementaires
• Reproduire des analyses ou des rapports à partir d’un point spécifique dans le temps
• Suivre les métadonnées opérationnelles telles que les heures de chargement et les informations de fichier source

Activer le flux de données de modification pour le suivi au niveau des lignes

Le flux de données de modification de Delta Lake capture automatiquement chaque modification au niveau des lignes. Lorsqu’il est activé, le runtime enregistre les événements de modification avec des métadonnées indiquant si chaque ligne a été insérée, supprimée ou mise à jour. Le flux de données modifiées est désactivé par défaut. Vous devez donc l’activer explicitement sur les tables où vous avez besoin de cette fonctionnalité.

Pour activer le flux de données modifiées sur une nouvelle table :

CREATE TABLE bronze.sales_transactions (
    transaction_id STRING,
    customer_id STRING,
    amount DECIMAL(10,2),
    transaction_date TIMESTAMP,
    source_file STRING,
    load_timestamp TIMESTAMP
)
USING DELTA
TBLPROPERTIES (delta.enableChangeDataFeed = true);

Pour les tables existantes, activez le flux de données modifiées avec une ALTER TABLE instruction :

ALTER TABLE bronze.sales_transactions 
SET TBLPROPERTIES (delta.enableChangeDataFeed = true);

Interroger l'historique d'une table

Une fois le flux de données modifié activé, vous pouvez interroger l’historique des modifications pour voir exactement quelles modifications se sont produites. Le flux de données modifiées ajoute trois colonnes de métadonnées à vos données :

Modifications de requête dans un intervalle de temps spécifique :

SELECT 
    transaction_id,
    amount,
    _change_type,
    _commit_version,
    _commit_timestamp
FROM table_changes('bronze.sales_transactions', '2026-01-01', '2026-01-31')
WHERE _change_type IN ('insert', 'update_postimage')
ORDER BY _commit_timestamp;

Cette requête permet d’identifier quand des enregistrements spécifiques ont été modifiés, ce qui est utile pour le débogage des problèmes de qualité des données.

Utiliser le time travel pour des requêtes à un instant T

Delta Lake gère un journal des transactions qui permet d’interroger les données telles qu’elles existaient à tout moment dans l’historique. Cette fonctionnalité prend en charge les scénarios de débogage où vous devez comparer les données actuelles avec un état précédent.

Interroger des données à un horodatage spécifique :

SELECT * FROM bronze.sales_transactions
TIMESTAMP AS OF '2026-01-15 14:30:00';

Interroger des données pour une version spécifique :

SELECT * FROM bronze.sales_transactions
VERSION AS OF 42;

Pour afficher l’historique complet des opérations effectuées sur une table :

DESCRIBE HISTORY bronze.sales_transactions;

La sortie de l’historique inclut le type d’opération, l’horodatage, l’utilisateur et les métriques détaillées pour chaque modification.

Conserver l’historique des modifications pour l’audit à long terme

Étant donné que le voyage temporel intégré de Delta Lake a des limites de rétention, vous devez conserver les données modifiées dans une table d’historique distincte pour les exigences d’audit à long terme. Cette approche crée un enregistrement permanent de toutes les modifications.

Utilisez Structured Streaming pour capturer en continu les modifications :

(spark.readStream
    .option("readChangeFeed", "true")
    .option("ignoreDeletes", "false")
    .table("bronze.sales_transactions")
    .writeStream
    .option("checkpointLocation", "/checkpoints/sales_history")
    .trigger(availableNow=True)
    .toTable("audit.sales_transactions_history")
)

L’option readChangeFeed indique à Spark de lire le flux de données de modification, qui retourne des événements de modification au niveau des lignes, notamment les insertions, les mises à jour et les suppressions. L’option ignoreDeletes contrôle si les opérations de suppression sont incluses dans le flux. Régler à false garantit que les enregistrements supprimés sont capturés dans la table historique, offrant une piste d’audit complète de toutes les modifications des données.

La table d’historique contient chaque événement de modification avec des métadonnées complètes, permettant des requêtes tout au long de la durée de vie complète de vos données, et pas seulement pendant la période de rétention.

Configurer la rétention pour les exigences de conformité

Pour les tables temporelles prenant en charge la conformité ou les besoins réglementaires, configurez les paramètres de rétention en fonction de vos besoins :

ALTER TABLE bronze.sales_transactions 
SET TBLPROPERTIES (
    delta.logRetentionDuration = 'interval 90 days',
    delta.deletedFileRetentionDuration = 'interval 90 days'
);

Les deux propriétés doivent être définies ensemble. Le logRetentionDuration contrôle la durée pendant laquelle les métadonnées d’historique sont conservées, tandis que deletedFileRetentionDuration la durée pendant laquelle les fichiers de données supprimés sont conservés avant VACUUM de les supprimer.

Des périodes de conservation plus longues augmentent les coûts de stockage, mais fournissent un accès time travel prolongé et la disponibilité du flux de données de modification pour l'audit.

Avec les tables temporelles configurées correctement, vous pouvez suivre chaque modification apportée à vos données à partir de l’ingestion via la transformation, ce qui prend en charge le débogage opérationnel et les exigences de conformité réglementaire.