Conseils pour optimiser l’architecture Data Vault sur Snowflake (Partie 3)

Conseils pour optimiser l’architecture Data Vault sur Snowflake (Partie 3)


Pour ce dernier article de ma série Data Vault (DV), je vais discuter de deux autres fonctionnalités intéressantes de Snowflake Cloud Data Platform dont vous pouvez tirer parti lors de la création d’un DV sur notre plate-forme. Si vous n’êtes pas familier avec la méthode DV, veuillez lire cet article de blog d’introduction et partie 1 de cette série avant de lire cet article. Partie 2 de cette série décrit comment configurer un DV pour un chargement parallèle maximal.

Afin de gérer les « big data » et, plus précisément, les données semi-structurées, Snowflake a inventé un nouveau type de date propriétaire que nous appelons VARIANT. Lorsqu’une colonne dans une table est créée à l’aide de ce type de données, il est possible de charger des documents de type JSON, AVRO, Parquet, XML et Orc directement dans la table sans avoir à transformer ou à analyser le document pour l’adapter à un schéma fixe. De cette manière, nous sommes en mesure de prendre en charge un véritable Schema-on-Read à l’aide de SQL. (Pour une plongée plus profonde, voir ceci Publier et le connexe livre électronique ou ca séminaire en ligne).

Alors, comment cela s’applique-t-il à un modèle DV ? Il y a quelques années Dan Linstedt, inventeur de la méthode DV, m’a demandé comment nous pourrions éventuellement tirer parti de cette fonctionnalité. Ma suggestion était simplement de l’utiliser pour contenir les informations descriptives trouvées dans une table Satellite (Sat). Normalement, une table Sat a la clé primaire (PK) du Hub (ou Lien) parent, un horodatage de la date de chargement (LDTS), une colonne de différence de hachage (HASH_DIFF dans DV 2.0), la source d’enregistrement (RSRC), puis un ensemble d’attributs qui sont les informations descriptives liées à l’objet parent.

DV2.0 figure 1

Figure 1 : Modèle DV 2.0 avec définitions Sat standard

Ma proposition était que si la source des données était un document JSON, nous pourrions modéliser le Sat comme ceci :

  • Clé de moyeu
  • LDTS
  • UNE VARIANTE
  • HASH_DIFF
  • RSCR

En appliquant cela au modèle de la figure 1, le modèle révisé ressemblerait à celui de la figure 2.

DV 2.0 with Variants Figure 2

Figure 2 : Modèle DV 2.0 utilisant VARIANT dans Sats

Avec cette approche, nous pouvons être encore plus agiles en chargeant le document entier dans le Sat sans avoir à analyser les clés dans des colonnes séparées du tableau. Pourquoi est-ce bon ? Eh bien, imaginez que vous avez un document JSON avec plus de 100 clés. Vous faites quelques découvertes et pouvez facilement trouver les attributs qui constitueraient la clé métier du Hub, mais vous ne savez pas encore à quoi servent tous les autres attributs et, en fait, les exigences initiales ne demandaient que cinq des attributs dans le document, mais vous savez qu’éventuellement certains des autres attributs seront probablement requis. Vous ne savez pas lesquels, ni quand. En raison des aspects Schema-on-Read de Snowflake, vous n’avez pas besoin de connaître toutes les exigences à l’avance. Au lieu de deviner et de ne charger que les cinq originaux, sachant que vous serez obligé de repenser plus tard, vous chargez simplement le document entier sur le Sat dans une VARIANTE. Ensuite, lorsque les exigences changent ultérieurement, les données sont déjà chargées. C’est agile !

Mais comment exposez-vous les valeurs du document JSON (maintenant stockées dans la colonne VARIANT) pour que les utilisateurs puissent les interroger ?

Construire une vue Business Vault

À l’aide des extensions Snowflake SQL pour JSON, vous pouvez créer une vue au-dessus du Sat pour exposer les attributs demandés par les utilisateurs. Étant donné que Snowflake optimise le stockage et l’organisation des données dans un VARIANT, les requêtes sur ce type de données sont très performantes. De nombreux clients Snowflake utilisent cette approche pour exposer les données JSON pour les rapports et les tableaux de bord depuis que je suis chez Snowflake.

Dans le langage DV, toute structure construite au-dessus ou en plus de la DV brute de base est généralement appelée Business Vault (BV). L’une des utilisations d’une BV consiste à créer des objets qui appliquent une logique métier généralement applicable à toutes les applications et tous les rapports en aval. Dans ce cas, la logique métier consiste simplement à exposer et formater les attributs demandés par les utilisateurs métier.

Voici un exemple de code que vous pourriez écrire pour accomplir cela :

CREATE OR REPLACE VIEW bizvault.vw_sat_parts (
	hub_part_key,
	load_dts,
	manufacturer,
	brand,
	retail_price, 
	record_source
AS
WITH sat_cte AS (
  SELECT
  md5_hub_part,
  ldts,
  rsrc,
  p_attributes, -- This is the VARIANT column
  LEAD(ldts) OVER (PARTITION BY md5_hub_part
    ORDER BY ldts) AS lead_dts -- used to find current row
  FROM
  rawvault.sat_parts
)
SELECT
  sat.md5_hub_part,
  sat.ldts,
  sat.p_attributes:p_mfgr::STRING,
  sat.p_attributes:p_brand::STRING,
  sat.p_attributes:p_retailprice::NUMBER,
  sat.rsrc
FROM sat_cte sat
WHERE
  lead_dts IS NULL -- gets current row only

L’avantage de cette approche est qu’elle est extrêmement agile car il est très facile de changer la vue pour ajouter de nouveaux attributs au fur et à mesure que les besoins de l’entreprise évoluent. C’est beaucoup moins de travail que de réorganiser les tables DV et de modifier puis de tester le processus de transformation pour analyser les nouveaux attributs. De plus, comme il s’agit d’une vue, elle permet un accès en temps quasi réel aux données de la DV. Si votre pipeline de données fournit continuellement des données au DV, ou même effectue des micro-lots, chaque fois qu’une requête est exécutée sur cette vue, les résultats seront à jour. Si vous effectuez des processus par lots aujourd’hui, cette approche est évolutive lorsque vous devez charger plus souvent.

Si les exigences signifient que la vue BV doit être beaucoup plus complexe et que vous ne parvenez pas à faire en sorte que les requêtes respectent les SLA, vous avez toujours la possibilité de transformer la vue en une table persistante qui est actualisée manuellement lors d’une future itération. D’un point de vue agile, je recommande toujours aux clients de commencer par utiliser des vues pour valider leur compréhension avec les utilisateurs métier et, ainsi, leur montrer les progrès plus tôt dans le cycle de vie du développement. Ce n’est que si vous ne pouvez pas respecter le SLA en utilisant l’entrepôt virtuel Snowflake de la bonne taille que vous envisagez alors de conserver les données.

Construire des magasins d’information au-dessus d’un coffre-fort commercial

Tout comme avec l’utilisation de vues pour les objets BV, les personnes qui créent une architecture DV complète dans Snowflake utilisent également des vues pour créer des magasins d’information et d’autres objets de type couche de rapport (oui, des vues sur des vues).

L’avantage est encore une fois un temps de valorisation plus rapide. Les vues sont très faciles à adapter aux nouvelles exigences, ce qui permet à l’équipe d’être plus agile et réactive vis-à-vis des utilisateurs professionnels. Si vous avez des exigences en temps quasi réel pour vos magasins de données, les vues vous rapprochent beaucoup plus de la capacité de répondre à cela également.

Un autre avantage est qu’avec les vues, vous pouvez facilement créer n’importe quel type de projection au-dessus de votre référentiel DV/BV. Cela signifie que vous pouvez fournir aux utilisateurs finaux un ensemble de vues de schéma en étoile, une troisième forme normale (3NF) (ou un magasin de données opérationnel virtuel [ODS]) ensemble de vues, ou même une vue large et dénormalisée pour les data scientists. Et en utilisant des vues, vous pouvez vous assurer qu’elles consultent toutes les mêmes données !

Insertion multi-tables

Une autre fonctionnalité intéressante de Snowflake est la possibilité de charger plusieurs tables en même temps à l’aide d’une seule source de données. C’est ce qu’on appelle l’insertion multi-tables (MTI). J’ai écrit à ce sujet dans le précédent article de blog d’introduction mais n’incluait pas le code pour gérer les aspects de capture de données modifiées (CDC) d’un modèle de charge DV. Voici un exemple de la façon dont vous pouvez charger un Hub et un Sat à partir d’une table à une seule étape et en même temps ajouter uniquement de nouveaux enregistrements au Hub et des enregistrements nouveaux ou modifiés au Sat en utilisant l’approche DV 2.0 d’une comparaison HASH_DIFF.

INSERT ALL  
WHEN (SELECT COUNT(*)        
             FROM dv.hub_country hc        
             WHERE hc.hub_country_key = stg.hash_key) = 0    
    THEN    
    INTO dv.hub_country   (hub_country_key, country_abbrv, hub_load_dts,
                    hub_rec_src)                  
    VALUES (stg.hash_key, stg.country_abbrv, stg.load_dts, stg.rec_src)  
WHEN (SELECT COUNT(*)         
          FROM dv.sat_countries sc        
          WHERE sc.hub_country_key = stg.hash_key 
      AND sc.hash_diff = MD5(country_name)) = 0    
THEN    
INTO dv.sat_countries (hub_country_key, sat_load_dts, 
                                            hash_diff, sat_rec_src, country_name)                    
          VALUES (stg.hash_key, stg.load_dts,
                           stg.hash_diff,  stg.rec_src, stg.country_name)  
SELECT MD5(country_abbrv) AS hash_key, 
               country_abbv, 
               country_name, 
               MD5(country_name) AS hash_diff, 
               CURRENT_TIMESTAMP AS load_dts,  
               stage_rec_src AS rec_src  
FROM stage.country stg;   

La première clause WHEN de l’instruction MTI vérifie s’il existe des lignes existantes dans les tables Hub et Sat cibles (dans ce cas, HUB_COUNTRY et SAT_COUNTRIES) qui correspondent aux données d’étape entrantes trouvées dans la table STAGE.COUNTRY. Si les données étagées contiennent effectivement de nouveaux enregistrements de pays et entraîneraient un nouvel enregistrement Hub, alors le COMPTER(*) renverra zéro (0) car la touche n’existe pas dans le Hub encore.

De même, le deuxième WHEN vérifie s’il existe déjà un enregistrement dans le Sat pour ce Hub et s’il contient les mêmes données (auquel cas, le HASH_DIFF correspondrait). Encore une fois, un compte de zéro (0) signifie soit que l’enregistrement n’existe pas, donc un Nouveau L’enregistrement Sat doit être inséré ou les données dans la table d’étape diffère à partir des enregistrements déjà dans le DV, une nouvelle version de l’enregistrement doit donc être insérée. Donc, si le compte est zéro, un nouvel enregistrement sera inséré dans DV.SAT_COUNTRIES ; sinon, le deuxième QUAND saute simplement cet enregistrement.

Avec cette méthode, même si vous redémarrez le chargement, ou si vous obtenez les mêmes données deux fois, vous ne chargerez jamais de doublon dans le Hub ou le Sat. Plutôt cool, non ? (Techniquement, cela s’appelle un idempotent charger.)

Conclusion

Eh bien, c’est tout pour cette série sur l’utilisation d’un DV avec Snowflake Cloud Data Platform. Au cours de l’année dernière, j’ai parlé à de nombreuses organisations qui cherchent à adopter un DV lors de leur passage à Snowflake. J’espère donc que vous avez trouvé utile de voir certaines des capacités uniques de Snowflake et comment elles peuvent être exploitées pour rendre votre système DV encore plus agile et performant qu’avant !

Jusqu’à la prochaine fois, assurez-vous de nous suivre sur Twitter à @SnowflakeDB et @kentgraziano pour vous tenir au courant de toutes les dernières nouvelles et innovations sur Snowflake Cloud Data Platform.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.