Prise en charge de plusieurs approches de modélisation de données avec Snowflake

Prise en charge de plusieurs approches de modélisation de données avec Snowflake


VEUILLEZ NOTER : Ce message a été initialement publié en 2019. Il a été mis à jour pour refléter les produits, fonctionnalités et fonctionnalités actuellement disponibles.

Depuis que j’ai rejoint Snowflake, on m’a demandé à plusieurs reprises ce que entrepôt de données l’approche de modélisation que Snowflake supporte le mieux. Eh bien, ce qui est cool, c’est que Snowflake prend en charge plusieurs approches de modélisation des données également.

Il s’avère que nous avons quelques clients qui ont des entrepôts de données existants construits à l’aide d’une approche particulière connue sous le nom de Data Vault approche de modélisation, et ils ont décidé de passer à Snowflake.

Ainsi, la conversation se déroule souvent comme suit :

Client : « Pouvez-vous faire Data Vault sur Snowflake ? »

Moi : « Oui, tu peux ! Pourquoi demandez-vous? »

Client : « Eh bien, votre nom est Snowflake, nous avons donc pensé que cela pourrait signifier que vous ne supportez que les schémas de type Snowflake. »

Moi : « Eh bien, oui, je peux comprendre votre confusion dans ce cas, mais le nom n’a vraiment rien à voir avec la conception d’un entrepôt de données. En effet, nous soutenons n’importe quel type de conception relationnelle, y compris Data Vault.

Qu’est-ce que la modélisation Data Vault ?

Pour ceux d’entre vous qui n’ont pas encore entendu parler du Système de coffre-fort de données de Business Intelligence ou simplement la modélisation de Data Vault (DV), il fournit (entre autres) une méthode et une approche pour modéliser votre entrepôt de données d’entreprise (EDW) afin qu’il soit agile, flexible et évolutif.

C’est la définition formelle, selon l’inventeur Dan Linstedt:

Le DV est un ensemble de tableaux normalisés, axés sur les détails, de suivi historique et liés de manière unique, qui prennent en charge un ou plusieurs domaines fonctionnels de l’entreprise.

Il s’agit d’une approche hybride englobant le meilleur de la race entre la 3e forme normale (3NF) et le schéma en étoile. La conception est flexible, évolutive, cohérente et adaptable aux besoins de l’entreprise. Il s’agit d’un modèle de données conçu spécifiquement pour répondre aux besoins des entrepôts de données d’entreprise d’aujourd’hui.

Le point principal ici est que DV a été développé Plus précisément pour résoudre les problèmes d’agilité, de flexibilité et d’évolutivité rencontrés dans les autres approches de modélisation de données courantes utilisées dans l’espace d’entreposage de données. Il a été conçu pour être un référentiel historique granulaire, non volatile et auditable de données d’entreprise.

À la base se trouve une technique de modélisation reproductible qui se compose de seulement trois principaux types de tableaux :

  • Hubs : Liste unique de clés métier qui représentent des objets métier
  • Liens: Liste unique d’associations/transactions qui représentent l’unité de travail d’un processus métier
  • Satellites : Données descriptives des hubs et liaisons (Type 2 avec historique)

Étant donné que les hubs sont des référentiels d’identificateurs d’objets métier (la clé métier), les hubs sont orientés métier car les objets métier eux-mêmes sont au centre des fonctionnalités métier.

Désormais, les systèmes sources peuvent être considérés comme les moteurs d’automatisation des processus métier, qui à leur tour suivent les relations et l’état des données d’un objet métier (par exemple, activé, désactivé, actif, inactif, solde, etc.). Pour une entreprise qui disposera de plusieurs systèmes sources, ces objets métier et leurs données descriptives sont facilement suivis grâce à l’intégration sémantique par clés métier. Nous appelons cette technique « intégration passive.”

Les liens sont conçus pour être des structures plusieurs-à-plusieurs qui vous donnent la flexibilité d’absorber toutes les modifications de cardinalité et de règles métier sans réingénierie (et donc sans recharger les données).

Les satellites vous offrent la possibilité d’enregistrer l’historique à n’importe quel intervalle, ainsi qu’une vérifiabilité et une traçabilité incontestables de vos systèmes sources.

Voici un exemple simple de ce à quoi ressemble un modèle Data Vault 2.0 :

tugRVS7eeNcCM3NQY7 Qxap0tcwrWx7Xl8bdwmmrUGjm754 shDydVp9 eAePMmHxIyuoVBwVPsIoMW4W41Gr0bIEtpnmYVFvyXSRBdCCDPRvWExz i6vM LHzFV5CU8uRWcK7As
Fonctionnalités Snowflake à utiliser dans un Data Vault

Le flocon de neige est un SGBDR SQL ANSI avec tarification à la consommation, et prend en charge les tables et les vues comme toutes les solutions relationnelles actuellement disponibles sur le marché. Étant donné que, du point de vue de la modélisation des données, Data Vault (DV) est une manière et un modèle spécifiques de conception de tables pour votre entrepôt de données, il n’y a aucun problème à en implémenter une dans Snowflake.

En fait, avec la combinaison de Snowflake de clusters de calcul MPP, d’un format de stockage en colonne optimisé et d’une technologie d’entrepôt de données adaptative, je pense que vous obtiendrez de meilleurs résultats avec vos charges et requêtes DV avec moins d’effort que vous n’obtenez aujourd’hui avec vos anciennes solutions d’entrepôt de données. N’oubliez pas qu’avec Snowflake, vous n’avez pas besoin de planifier à l’avance les clés de partitionnement ou de distribution, ni de créer des index pour obtenir d’excellentes performances. Tout cela est géré dans le cadre de la fonction d’optimisation dynamique des requêtes de Snowflakes qui utilise son magasin de métadonnées sécurisé basé sur le cloud et sa boucle de rétroaction sophistiquée pour surveiller et ajuster vos requêtes en fonction des modèles d’accès aux données et de la disponibilité des ressources, entre autres.

Étant donné que les clients de Snowflake obtiennent des performances de requête améliorées (dans certains cas, jusqu’à 100 fois plus), je pense que Snowflake peut être un excellent endroit pour essayer de virtualiser la couche de votre magasin d’informations (c’est-à-dire les rapports) que vous exposez à vos outils de BI.

Coffre-fort de données 2.0

Pour ceux d’entre vous intéressés par la mise en œuvre de la VD 2.0 spécification, Snowflake peut également gérer cela. Il dispose d’une fonction de hachage MD5 intégrée afin que vous puissiez implémenter des clés basées sur MD5 et effectuer votre capture de données modifiées à l’aide du concept DV 2.0 HASH_DIFF.

Non seulement Snowflake prend en charge l’utilisation des fonctions de hachage DV 2.0, mais vous pouvez également tirer parti de l’insertion multi-tables (MTI) de Snowflake lors du chargement de votre Data Vault Logarithmique tableaux ponctuels (PIT). Avec cette fonctionnalité, vous pouvez charger plusieurs tables PIT dans parallèle à partir d’une seule requête de jointure depuis votre Data Vault.

Ressources DV

Si vous souhaitez en savoir plus sur la DV, il existe un site Web qui lui est dédié ainsi que quelques livres sur le sujet que vous voudrez peut-être consulter :

  1. Introduction à l’ingénierie agile des données par Kent Graziano (moi)
  2. Le gourou du coffre-fort de données par Patrick Cuba
  3. Introduction à la DV – livre blanc gratuit sur mon blog personnel
  4. Vidéos d’introduction DV gratuites – de l’inventeur Dan Linstedt
  5. Construire un entrepôt de données évolutif avec DV 2.0 par Dan Linstedt
  6. Le blog de Dan Linstedt

J’espère que cet article répond aux questions de base sur la réalisation de DV sur Snowflake (oui, vous le pouvez). Si vous souhaitez commencer à utiliser Snowflake, n’hésitez pas à profiter de notre offre à la demande avec jusqu’à 400 $ d’utilisation gratuite.

Gardez un œil sur le blog Snowflake et Twitter et LinkedIn tient compte des mises à jour sur toutes les actions et activités ici à Snowflake.

Ressources additionnelles

Laisser un commentaire

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