Qu'est-ce qu'un satellite dans Data Vault ?

Les hubs disent ce qui existe. Les links disent comment les éléments sont liés entre eux. Ni l’un ni l’autre ne stocke un nom, un solde ou un statut. C’est le rôle du satellite.

En termes de modélisation classique, les attributs d’une entité, son contexte, deviennent un satellite. Là où la table Customer porte name, address et segment à côté de customer_number, le Data Vault conserve le numéro dans le hub client et les attributs dans un satellite rattaché à ce hub.

Ce qu’est un satellite

Un satellite contient les attributs descriptifs d’un hub et chacune de leurs modifications au fil du temps. Lorsqu’un client déménage, le satellite n’écrase pas l’adresse : il ajoute une nouvelle ligne, et l’ancienne est conservée. Chaque ligne enregistre quand elle est entrée dans le vault et quel système l’a livrée, si bien que chaque version est traçable.

Si vous connaissez la modélisation dimensionnelle, un satellite est une Slowly Changing Dimension de type 2, sans le moindre UPDATE. L’historisation peut aussi être désactivée à la demande, ce qui donne un satellite non historisé.

L’anatomie d’un satellite

La clé primaire est constituée de la hash key du parent et de la Load Date.

Le hash diff est un choix, pas une règle

Le Data Vault tel que le décrivent les manuels préconise de calculer un hash diff pour chaque ligne de satellite afin de détecter les changements. En pratique, cela dépend du chargement :

• Chargements delta : les lignes stockées portent déjà leur hash, si bien qu’il est peu coûteux de ne calculer le hash que des lignes entrantes. Le hash diff l’emporte.
• Chargements complets : calculer le hash de millions de lignes à chaque exécution consomme beaucoup de puissance de calcul. Une comparaison directe des colonnes (IS DISTINCT FROM) est souvent plus rapide sur les moteurs modernes.
• Tables larges : on affirme couramment que ce sont les tables larges qui profitent le plus du hash. C’est plutôt l’inverse : plus les lignes sont larges, plus les chaînes à concaténer avant le calcul du hash sont longues.

Datavault Builder prend en charge le hash diff comme une option, pas comme une obligation. Le hash diff fera l’objet de son propre article dans cette série.

Les transactions ont leur propre satellite

Les quantités, prix et montants d’une ligne de commande décrivent la transaction elle-même. Avec un grain hub pour la ligne de commande, comme décrit dans l’article sur les links, ils vont dans un satellite ordinaire rattaché à ce grain hub, où ils sont historisés comme n’importe quel autre attribut.

Comment découper les satellites

• Par système source. Les données du CRM et de l’ERP ne partagent jamais un satellite brut. Chaque source conserve son propre lignage, inchangé.
• Par fréquence de modification. Un solde quotidien et un nom officiel réunis dans un même satellite recopient le nom dans une nouvelle ligne chaque jour. Les attributs qui changent vite et ceux qui changent lentement doivent être séparés.
• Par sensibilité. Les données personnelles, comme le nom, l’e-mail et la date de naissance, vont dans un satellite à part, séparé des attributs qui n’identifient personne. Le reporting RGPD dispose alors d’un seul endroit clairement défini à consulter, et les règles d’accès ou une demande de suppression ne s’appliquent qu’à ce satellite.
• Ne jamais supprimer. Lorsqu’un enregistrement disparaît de la source, son historique est conservé. Un record tracking satellite indique que la clé n’est plus livrée. L’exception est une obligation légale d’effacer des informations, comme une demande d’effacement au titre du RGPD, et c’est là que le découpage par sensibilité porte ses fruits.

Ce qui change avec Datavault Builder

Vous mappez les colonnes sources vers un satellite dans le modèle. La détection des changements, le chargement en insertion seule et les colonnes d’audit sont générés, et s’exécutent nativement sur Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle ou PostgreSQL. Deux situations que les patterns de chargement classiques ne gèrent pas sont prises en charge d’emblée :

• Les chargements bitemporels. Un établissement financier avec un traitement de fin de journée a deux axes temporels : le moment où quelque chose était vrai pour le métier, et le moment où l’entrepôt l’a chargé. Datavault Builder traite ensemble l’historique de fin de journée et l’historique de chargement, et crée des satellites bitemporels. Consultez le traitement des données bi-temporelles pour voir comment cela fonctionne : la bitemporalité fera aussi l’objet de son propre article dans cette série.
• Plusieurs changements par chargement. Un data lake livre souvent plusieurs versions du même enregistrement dans un seul lot. Les patterns classiques chargent un changement par clé et par exécution : il faudrait donc boucler sur les données, et chaque version serait datée du moment du chargement. Datavault Builder charge tous les changements en un seul lot et place chaque enregistrement sur l’axe temporel au moment où le data lake l’a enregistré.