Interroger les données telles qu’elles existaient dans le passé

S’applique à :✅ L'endpoint analytique SQL et l'entrepôt de données dans Microsoft Fabric

Microsoft Fabric offre la possibilité d’interroger des données historiques telles qu’elles étaient par le passé dans les éléments d’entrepôt de données et de point de terminaison d’analytique SQL (préversion). La possibilité d’interroger des données à partir d’un horodatage spécifique est connue dans le secteur de l’entreposage de données en tant que voyage temporel.

  • Le temps de trajet facilite la création de rapports stables en conservant la cohérence et l’exactitude des données au fil du temps.
  • Le temps de trajet permet d’analyser les tendances historiques en interrogeant les différents points passés dans le temps et permet d’anticiper les tendances futures.
  • Le temps de trajet simplifie les comparaisons à faible coût entre les versions précédentes des données.
  • Le temps de trajet facilite l’analyse des performances au fil du temps.
  • Le temps de trajet permet aux organisations de réaliser un audit des modifications de données au fil du temps, souvent requises à des fins de conformité.
  • Le temps de trajet permet de reproduire les résultats des modèles Machine Learning.
  • Le voyage dans le temps peut interroger des tables telles qu'elles existaient à un moment donné, à travers plusieurs entrepôts dans le même espace de travail.
  • Les indications de voyage dans le temps peuvent être utilisées avec des tables temporaires propres à la session, qui ne sont pas affectées par la syntaxe TIMESTAMP.

Qu’est-ce que le voyage dans le temps ?

Le temps de trajet dans un entrepôt de données est un moyen peu coûteux et efficace d’interroger rapidement les versions antérieures des données.

Microsoft Fabric permet actuellement la récupération des états passés des données de la manière suivante :

Temps de trajet avec la commande FOR TIMESTAMP AS OF T-SQL

Les tables peuvent être interrogées à l’aide de la syntaxe OPTION FOR TIMESTAMP AS OF T-SQL pour récupérer des données à des moments passés. La clause FOR TIMESTAMP AS OF affecte l’ensemble de l’instruction, y compris toutes les tables d’entrepôt jointes.

Les résultats obtenus à partir des requêtes de temps de trajet sont intrinsèquement en lecture seule. Les opérations d’écriture comme INSERT, UPDATE et DELETE ne peuvent pas se produire lors de l’utilisation de l’indicateur de requête FOR TIMESTAMP AS OF.

Utilisez la clause OPTION pour spécifier l’indicateur de requête FOR TIMESTAMP AS OF. Les requêtes retournent des données exactement telles qu’elles existaient à l’horodateur, spécifiées comme YYYY-MM-DDTHH:MM:SS[.fff]. Par exemple :

SELECT *
FROM [dbo].[dimension_customer] AS DC
OPTION (FOR TIMESTAMP AS OF '2024-03-13T19:39:35.28'); --March 13, 2024 at 7:39:35.28 PM UTC

Utilisez la syntaxe CONVERT pour le format DateHeure nécessaire avec le style 126.

L’horodateur ne peut être spécifié qu’une seule fois à l’aide de la clause OPTION pour les requêtes, les procédures stockées, les vues, etc. La clause OPTION s’applique à toutes les options dans l’instruction SELECT.

Pour obtenir des exemples, consultez Comment : interroger via le voyage dans le temps.

Conservation des données dans Fabric Data Warehouse

  • Pour Fabric Data Warehouse, les déplacements temporels sont limités par la période de conservation des données configurable warehouse, qui est automatique.
  • Pour un point de terminaison d’analytique SQL Lakehouse, les déplacements temporels sont limités au niveau de la table par les paramètres de rétention du vide. La maintenance de table Lakehouse peut être exécutée manuellement dans le portail Fabric ou en tant que processus planifié et orchestré à l’aide de notebooks, de pipelines ou d’API REST.

Dans Microsoft Fabric, un entrepôt conserve et gère automatiquement différentes versions des données en fonction de la période de rétention configurée. La période de rétention de l’entrepôt par défaut est de 30 jours calendriers et peut être configurée en fonction des besoins de votre organisation. Cela permet d'interroger des tables à un moment antérieur de la fenêtre de rétention. Toutes les insertions, mises à jour et suppressions effectuées dans l’entrepôt sont conservées.

La rétention commence automatiquement à partir du moment où l’entrepôt est créé. Les fichiers expirés sont automatiquement supprimés après le seuil de rétention.

  • Actuellement, une SELECT instruction avec l’indicateur FOR TIMESTAMP AS OF de requête retourne la dernière version du schéma de table.
  • Tous les enregistrements supprimés dans une table sont disponibles pour être interrogés comme ils existaient avant la suppression, si la suppression se trouve dans la période de rétention.
  • Une requête de voyage dans le temps jusqu’à un point dans le temps avant la modification du schéma réussit uniquement lorsqu’elle référence des colonnes qui existaient déjà à ce stade et échoue si elle référence des colonnes introduites ultérieurement.

Scénarios de temps de trajet

Considérez la possibilité de voyager dans le temps pour accéder à des données antérieures dans les scénarios suivants :

Rapports stables

L’exécution fréquente de tâches d’extraction, de transformation et de chargement (ETL) est essentielle pour suivre l’évolution constante du paysage des données. La possibilité d’utiliser le temps de trajet contribue à ce but en garantissant l’intégrité des données tout en offrant la flexibilité de générer des rapports basés sur les résultats de la requête qui sont renvoyés à partir d’un moment passé, par exemple le soir précédent, alors que le traitement en arrière-plan est en cours.

Les activités ETL peuvent s’exécuter conjointement, alors que la même table est interrogée à partir exactement d’un point temporel antérieur.

Tendance historique et analyse prédictive

Le voyage dans le temps simplifie l'analyse des données historiques, aidant à découvrir des tendances et des schémas précieux grâce aux requêtes de données sur différentes périodes du passé. Cette découverte facilite l’analyse prédictive en permettant d’expérimenter des jeux de données historiques et de former des modèles prédictifs. Elle permet d’anticiper les tendances futures et d’aider à prendre des décisions bien informées et pilotées par les données.

Analyse et comparaison

Le temps de trajet offre une capacité de résolution des problèmes efficace et rentable en fournissant un filtre historique pour l’analyse et la comparaison, et en facilitant l’identification de la cause racine.

Analyse des performances

Le voyage dans le temps peut vous aider à analyser les performances des requêtes des entrepôts de données au fil du temps. Il permet d’identifier les tendances de détérioration des performances en fonction des requêtes qui peuvent être optimisées.

Audit et conformité

Le temps de trajet simplifie les procédures d’audit et de conformité en permettant aux auditeurs de parcourir l’historique des données. Il permet non seulement de rester conforme aux réglementations, mais également d’améliorer l’assurance et la transparence.

Modèles Machine Learning

Les capacités du temps de trajet aident à reproduire les résultats des modèles Machine Learning en facilitant l’analyse des données historiques et en simulant des scénarios réels. Elles permettent d’améliorer la fiabilité globale des modèles afin que des décisions précises basées sur les données puissent être prises.

Considérations sur la conception

Considérations relatives à l’indicateur de requête OPTION FOR TIMESTAMP AS OF :

  • L’indicateur de requête FOR TIMESTAMP AS OF ne peut pas être utilisé pour créer les vues à partir d’un point antérieur dans le temps au cours de la période de rétention. Il peut être utilisé pour interroger des vues à partir d’un point passé dans le temps, au cours de la période de rétention.
  • L’indicateur de requête FOR TIMESTAMP AS OF ne peut être utilisé qu’une seule fois dans une instruction SELECT.
  • L’indicateur de requête FOR TIMESTAMP AS OF peut être défini dans l’instruction SELECT dans une procédure stockée.
  • L’indicateur FOR TIMESTAMP AS OF de requête n’affecte pas les tables temporaires délimitées à la session, comme #temp_table.

Autorisations de voyage temporel

Tout utilisateur disposant de rôles d’espace de travail Administration, Membre, Contributeur ou spectateur dans l'espace de travail peut interroger les tables à partir d'un moment donné. Lorsque les utilisateurs interrogent des tables, les restrictions formulées par la sécurité au niveau des colonnes (CLS), la sécurité au niveau des lignes (SNL) ou le masquage dynamique des données (DDM) sont automatiquement imposées.

Limites

  • Toutes les modifications apportées au schéma d’une table, y compris, mais non limitées à l’ajout ou à la suppression de colonnes, ne peuvent être interrogeables qu’à partir du moment où la modification a été apportée. Une requête de voyage dans le temps jusqu’à un point dans le temps avant la modification du schéma réussit uniquement lorsqu’elle référence des colonnes qui existaient déjà à ce stade et échoue si elle référence des colonnes introduites ultérieurement. De même, la suppression et la recréation d’une table avec les mêmes données suppriment son historique.
  • Inscrivez au maximum trois chiffres de fractions de secondes dans l’horodateur. Si vous fournissez plus de précision, vous recevez le message d’erreur An error occurred during timestamp conversion. Please provide a timestamp in the format yyyy-MM-ddTHH:mm:ss[.fff]. Msg 22440, Level 16, State 1, Code line 29.
  • Actuellement, seul le fuseau horaire UTC (Temps universel coordonné) est utilisé pour le temps de trajet.
  • Actuellement, la conservation des données pour les requêtes de voyage temporel est configurable de 1 à 120 jours calendaires. La période de rétention par défaut est de trente jours calendriers. Pour plus d’informations, consultez Conservation des données configurables.
  • Les valeurs FOR TIMESTAMP AS OF de la clause OPTION doivent être déterministes. Pour obtenir un exemple de paramétrage, consultez Temps de trajet dans une procédure stockée.
  • L’indicateur de requête OPTION FOR TIMESTAMP AS OF ne peut être utilisé que dans les requêtes commençant par l’instruction SELECT.
  • Les définitions d’affichage ne peuvent pas contenir la OPTION FOR TIMESTAMP AS OF syntaxe T-SQL. La vue peut être interrogée avec la SELECT .. FROM <view> ... OPTION FOR TIMESTAMP AS OF syntaxe T-SQL. Toutefois, vous ne pouvez pas consulter les données précédentes des tables dans une vue avant que la vue ne soit créée.
  • La syntaxe T-SQL FOR TIMESTAMP AS OF pour le voyage dans le temps n’est actuellement pas prise en charge en mode de requête Power BI Desktop Direct ou Explore ces données option.
  • Actuellement, les déplacements temporels pour les points de terminaison d’analytique SQL sont activés uniquement pour les points de terminaison d’analytique SQL créés avec la synchronisation des métadonnées (préversion) activée.

Étape suivante