Le développement du stockage est une entreprise longue et sérieuse.
Une grande partie de la vie d'un projet dépend de la façon dont le modèle d'objet et la structure de base sont pensés au départ.
L'approche généralement acceptée a été et reste diverses combinaisons du schéma en étoile avec la troisième forme normale. En règle générale, selon le principe: données initiales - 3NF, vitrines - une étoile. Cette approche, éprouvée et étayée par de nombreuses recherches, est la première (et parfois la seule) chose qui vient à l'esprit d'un spécialiste DWH expérimenté lorsqu'il réfléchit à ce à quoi devrait ressembler un référentiel analytique.
D'autre part, les affaires en général et les exigences des clients en particulier ont tendance à changer rapidement, tandis que les données augmentent à la fois "en profondeur" et "en largeur". Et ici apparaît le principal inconvénient de l'étoile - limité souplesse.
Et si dans votre vie tranquille et confortable en tant que développeur DWH tout à coup :
- la tâche s'est posée "de faire au moins quelque chose rapidement, et ensuite nous verrons";
- un projet en développement rapide est apparu, avec la connexion de nouvelles sources et la modification du modèle économique au moins une fois par semaine ;
- un client est apparu qui n'a aucune idée de l'apparence du système et des fonctions qu'il devrait remplir à la fin, mais est prêt pour des expériences et un affinement cohérent du résultat souhaité avec une approche cohérente de celui-ci ;
- le chef de projet a annoncé la bonne nouvelle : "Et maintenant, nous avons agile !".
Ou si vous êtes simplement intéressé à apprendre comment vous pouvez construire un espace de rangement, bienvenue chez le chat !
Que veut dire "flexibilité" ?
Pour commencer, définissons les propriétés qu'un système doit avoir pour être qualifié de « flexible ».
Séparément, il convient de mentionner que les propriétés décrites doivent se référer spécifiquement à système, de ne pas processus son développement. Par conséquent, si vous souhaitez en savoir plus sur Agile en tant que méthodologie de développement, il est préférable de lire d'autres articles. Par exemple, juste là, sur Habré, il y a beaucoup de matériaux intéressants (comme и Et ).
Cela ne signifie pas que le processus de développement et la structure de l'entrepôt de données sont totalement indépendants. En général, le développement agile d'un stockage agile devrait être beaucoup plus facile. Cependant, dans la pratique, il y a plus d'options avec le développement Agile de DWH classique selon Kimbal et DataVault - selon Waterfall que d'heureuses coïncidences de flexibilité sous ses deux formes sur un projet.
Alors, quelles fonctionnalités le stockage flexible devrait-il avoir ? Il y a trois points ici :
- Livraison anticipée et réalisation rapide - cela signifie qu'idéalement, le premier résultat commercial (par exemple, les premiers rapports de travail) devrait être obtenu le plus tôt possible, c'est-à-dire avant même que l'ensemble du système ne soit conçu et mis en œuvre. Dans le même temps, chaque révision ultérieure devrait également prendre le moins de temps possible.
- Raffinement itératif - cela signifie que chaque révision ultérieure, idéalement, ne devrait pas affecter la fonctionnalité déjà opérationnelle. C'est ce moment qui devient souvent le plus grand cauchemar des grands projets - tôt ou tard, les objets individuels commencent à acquérir tellement de relations qu'il devient plus facile de répéter complètement la logique dans une copie côte à côte que d'ajouter un champ à une table existante. Et si vous êtes surpris que l'analyse de l'impact des améliorations sur les objets existants puisse prendre plus de temps que la révision elle-même, vous n'avez probablement pas travaillé avec de grands entrepôts de données dans le secteur bancaire ou télécom.
- Adaptation constante à l'évolution des besoins de l'entreprise - la structure générale de l'objet doit être conçue non seulement en tenant compte de l'expansion possible, mais en s'attendant à ce que la direction de cette prochaine expansion ne puisse même pas être imaginée au stade de la conception.
Et oui, le respect de toutes ces exigences dans un seul système est possible (bien sûr, dans certains cas et avec quelques réserves).
Ci-dessous, je passerai en revue deux des méthodologies de conception agiles les plus populaires pour la HD - modèle d'ancre и Coffre de données. En dehors des parenthèses se trouvent d'excellents trucs comme, par exemple, EAV, 6NF (dans sa forme pure) et tout ce qui concerne les solutions NoSQL - non pas parce qu'ils sont en quelque sorte pires, ni même parce que dans ce cas l'article menacerait d'acquérir le volume d'un disserteur moyen. C'est juste que tout cela fait référence à des solutions d'une classe légèrement différente - soit à des techniques que vous pouvez appliquer dans des cas spécifiques, quelle que soit l'architecture générale de votre projet (comme EAV), soit à des paradigmes de stockage d'informations globalement différents (comme les bases de données de graphes et autres options). NoSQL).
Problèmes de l'approche "classique" et leurs solutions dans des méthodologies flexibles
Par approche "classique", j'entends la bonne vieille star (indépendamment de la mise en œuvre spécifique des couches sous-jacentes, pardonnez-moi les adhérents de Kimball, Inmon et CDM).
1. Cardinalité rigide des connexions
Ce modèle est basé sur une répartition claire des données en mesures (dimensions) и faits (Fait). Et cela, bon sang, est logique - après tout, l'analyse des données dans la très grande majorité des cas se résume à l'analyse de certains indicateurs numériques (faits) dans certaines sections (dimensions).
Dans le même temps, des liens entre objets sont établis sous la forme de liens entre tables par une clé étrangère. Cela semble assez naturel, mais conduit immédiatement à la première limitation de la flexibilité - définition stricte de la cardinalité des relations.
Cela signifie qu'au stade de la conception des tables, vous devez spécifier pour chaque paire d'objets liés s'ils peuvent être liés comme plusieurs à plusieurs, ou seulement 1 à plusieurs, et « dans quelle direction ». Cela dépend directement de laquelle des tables aura une clé primaire et de laquelle aura une clé étrangère. La modification de ce ratio lorsque de nouvelles demandes sont reçues conduira très probablement à un remaniement de la base.
Par exemple, lors de la conception de l'objet «ticket de caisse», vous, en vous appuyant sur les assurances assermentées du service commercial, avez défini la possibilité d'action une promotion pour plusieurs postes de contrôle (mais pas l'inverse):
Et après un certain temps, des collègues ont introduit une nouvelle stratégie marketing dans laquelle plusieurs promotions en même temps. Et maintenant, vous devez finaliser les tableaux en mettant en surbrillance la relation dans un objet séparé.
(Tous les objets dérivés, dans lesquels la vérification de la promotion se joint, doivent désormais également être améliorés).
Liens dans le coffre-fort de données et le modèle d'ancrage
Il s'est avéré assez simple d'éviter une telle situation : vous n'avez pas besoin de faire confiance au service commercial, cela suffit toutes les relations sont initialement stockées dans des tables séparées et traiter comme plusieurs-à-plusieurs.
Cette approche a été proposée Dan Linstedt dans le cadre du paradigme Coffre de données et entièrement pris en charge Lars Rönnbäck в Modèle d'ancre.
On obtient ainsi le premier trait distinctif des méthodologies flexibles :
Les relations entre les objets ne sont pas stockées dans les attributs des entités parentes, mais constituent un type d'objet distinct.
В Coffre de données ces tables sont appelées Lienet Modèle d'ancre - Cravate. À première vue, ils sont très similaires, bien que leurs différences ne soient pas épuisées par le nom (qui sera discuté ci-dessous). Dans les deux architectures, les tables de liens peuvent lier n'importe quel nombre d'entités (pas nécessairement 2).
Cette redondance à première vue donne une souplesse indispensable aux réalisations. Une telle structure devient tolérante non seulement à la modification des cardinalités des liens existants, mais également à l'ajout de nouveaux - si maintenant une position de chèque a également un lien avec le caissier qui l'a rompu, l'apparition d'un tel lien sera simplement une superstructure sur les tables existantes sans affecter les objets et processus existants.
2. Duplication des données
Le deuxième problème résolu par les architectures flexibles est moins évident et inhérent en premier lieu. mesures type SCD2 (mesures à évolution lente du deuxième type), mais pas seulement.
Dans le stockage classique, une dimension est généralement une table qui contient une clé de substitution (comme PK) et un ensemble de clés métier et d'attributs dans des colonnes séparées.
Si la dimension prend en charge la gestion des versions, des limites de temps de version sont ajoutées à l'ensemble standard de champs et plusieurs versions apparaissent dans le référentiel par ligne dans la source (une pour chaque modification des attributs versionnés).
Si une dimension contient au moins un attribut versionné qui change fréquemment, le nombre de versions d'une telle dimension sera impressionnant (même si les autres attributs ne sont pas versionnés ou ne changent jamais), et s'il y a plusieurs de ces attributs, le nombre de versions peut croître de façon exponentielle à partir de leur nombre. Une telle dimension peut occuper une quantité importante d'espace disque, bien que la plupart des données qui y sont stockées soient simplement des doublons de valeurs d'attributs immuables d'autres lignes.
En même temps, il est aussi souvent utilisé dénormalisation - certains attributs sont intentionnellement stockés en tant que valeur, et non en tant que référence à un ouvrage de référence ou à une autre dimension. Cette approche accélère l'accès aux données en réduisant le nombre de jointures lors de l'accès à une dimension.
Typiquement, cela se traduit par les mêmes informations sont stockées simultanément à plusieurs endroits. Par exemple, les informations sur la région de résidence et l'appartenance à la catégorie client peuvent être stockées simultanément dans les dimensions "Client", et les faits "Achat", "Livraison" et "Contacts au centre d'appels", ainsi que dans le table de liens « Client - Gestionnaire de clientèle ».
En général, ce qui précède s'applique aux mesures régulières (non versionnées), mais dans les mesures versionnées, elles peuvent avoir une échelle différente : l'apparition d'une nouvelle version d'un objet (surtout avec le recul) entraîne non seulement la mise à jour de toutes les tables associées, mais à une apparition en cascade de nouvelles versions d'objets associés - lorsque la table 1 est utilisée pour construire la table 2, et la table 2 est utilisée pour construire la table 3, et ainsi de suite. Même si pas un seul attribut du tableau 1 n'est impliqué dans la construction du tableau 3 (et d'autres attributs du tableau 2 obtenus à partir d'autres sources sont impliqués), le versionnement de cette construction conduira au moins à des frais généraux supplémentaires, et au plus à versions supplémentaires dans le tableau 3, qui n'a généralement «rien à voir avec cela» et plus loin dans la chaîne.
3. Complexité non linéaire du raffinement
Dans le même temps, chaque nouvelle vitrine construite au-dessus d'une autre augmente le nombre d'endroits où les données peuvent «diverger» lorsque des modifications sont apportées à l'ETL. Ceci, à son tour, conduit à une augmentation de la complexité (et de la durée) de chaque révision ultérieure.
Si ce qui précède s'applique aux systèmes avec des processus ETL rarement modifiés, vous pouvez vivre dans un tel paradigme - assurez-vous simplement que les nouvelles améliorations sont correctement apportées à tous les objets associés. Si les révisions se produisent fréquemment, la probabilité de "manquer" accidentellement plusieurs liens augmente considérablement.
Si, en plus, on tient compte du fait que l'ETL « versionné » est beaucoup plus compliqué que le « non versionné », il devient assez difficile d'éviter les erreurs lors du raffinement fréquent de toute cette économie.
Stockage d'objets et d'attributs dans Data Vault et Anchor Model
L'approche proposée par les auteurs d'architectures flexibles peut être formulée comme suit :
Il faut séparer ce qui change de ce qui reste inchangé. Cela consiste à stocker les clés séparément des attributs.
Cependant, ne confondez pas non versionné attribut avec inchangé: le premier ne stocke pas l'historique de son changement, mais peut changer (par exemple, lors de la correction d'une erreur de saisie ou de la réception de nouvelles données), le second ne change jamais.
Les points de vue sur ce qui peut exactement être considéré comme inchangé dans le Data Vault et le modèle Anchor diffèrent.
En termes d'architecture Coffre de données, peut être considéré comme inchangé l'ensemble des clés — naturel (TIN de l'organisation, code produit dans le système source, etc.) et de substitution. Dans le même temps, les attributs restants peuvent être divisés en groupes en fonction de la source et/ou de la fréquence des modifications et garder une table séparée pour chaque groupe avec un ensemble indépendant de versions.
Dans le même paradigme Modèle d'ancre considéré comme inchangé clé de substitution uniquement entités. Tout le reste (y compris les clés naturelles) n'est qu'un cas particulier de ses attributs. Où tous les attributs sont indépendants les uns des autres par défaut, donc pour chaque attribut doit être créé tableau séparé.
В Coffre de données les tables contenant des clés d'entité sont appelées Hubami (moyeu). Les hubs contiennent toujours un ensemble fixe de champs :
- Clés d'entités naturelles
- Clé de substitution
- Lien vers la source
- Temps d'enregistrement
Entrées dans les Hubs ne change jamais et n'a pas de versions. Extérieurement, les hubs sont très similaires aux tables ID-map utilisées dans certains systèmes pour générer des substituts, cependant, il est recommandé d'utiliser non pas une séquence d'entiers, mais un hachage d'un ensemble de clés métier comme substituts dans Data Vault. Cette approche simplifie le chargement des liens et des attributs depuis les sources (pas besoin de rejoindre le hub pour obtenir un substitut, il suffit de calculer le hachage à partir de la clé naturelle), mais elle peut causer d'autres problèmes (par exemple, avec des collisions, des cas et des non- caractères d'impression dans les clés de chaîne, etc. .p.), par conséquent, il n'est généralement pas accepté.
Tous les autres attributs d'entité sont stockés dans des tables spéciales appelées Satellites (Satellite). Un concentrateur peut avoir plusieurs satellites qui stockent différents ensembles d'attributs.
La répartition des attributs entre les satellites se fait selon le principe changement conjoint - dans un satellite, des attributs non versionnés peuvent être stockés (par exemple, date de naissance et SNILS pour un individu), dans l'autre - changeant rarement de version (par exemple, nom de famille et numéro de passeport), dans le troisième - changeant fréquemment (par exemple, adresse de livraison, catégorie, date de la dernière commande, etc.). Dans ce cas, la gestion des versions est effectuée au niveau des satellites individuels, et non de l'entité dans son ensemble, il est donc conseillé de répartir les attributs de manière à ce que l'intersection des versions au sein d'un satellite soit minimale (ce qui réduit le nombre total des versions stockées).
De plus, pour optimiser le processus de chargement des données, les attributs obtenus à partir de diverses sources sont souvent placés dans des satellites distincts.
Les satellites communiquent avec le hub en clé étrangère (ce qui correspond à la cardinalité 1 à plusieurs). Cela signifie que plusieurs valeurs d'attribut (par exemple, plusieurs numéros de téléphone de contact pour le même client) sont prises en charge par cette architecture "par défaut".
В Modèle d'ancre les tables qui stockent les clés sont appelées Ancres. Et ils gardent :
- Seules les clés de substitution
- Lien vers la source
- Temps d'enregistrement
Les clés naturelles du point de vue du modèle d'ancrage sont considérées attributs ordinaires. Cette option peut sembler plus difficile à comprendre, mais elle donne beaucoup plus de latitude pour identifier un objet.
Par exemple, si des données concernant la même entité peuvent provenir de différents systèmes, chacun utilisant sa propre clé naturelle. Dans le Data Vault, cela peut conduire à des constructions assez lourdes de plusieurs hubs (un par source + fusion master version), tandis que dans le modèle Anchor, la clé naturelle de chaque source tombe dans son propre attribut et peut être utilisée lors du chargement indépendamment de tous les autres.
Mais ici réside un moment insidieux : si les attributs de différents systèmes sont combinés en une seule entité, il y a très probablement des règles de colle, par lequel le système doit comprendre que les enregistrements de différentes sources correspondent à une instance de l'entité.
В Coffre de données ces règles sont susceptibles de déterminer la formation "hub de substitution" de l'entité maître et n'affectent en rien les Hubs qui stockent les clés naturelles des sources et leurs attributs d'origine. Si à un moment donné les règles de fusion changent (ou les attributs utilisés pour la fusion viennent à être mis à jour), il suffira de reformer les hubs de substitution.
В modèle d'ancre une telle entité est susceptible d'être stockée dans ancre simple. Cela signifie que tous les attributs, quelle que soit leur source, seront liés au même substitut. Séparer les enregistrements fusionnés par erreur et, en général, suivre la pertinence de la fusion dans un tel système peut être beaucoup plus difficile, surtout si les règles sont assez complexes et changent fréquemment, et le même attribut peut être obtenu à partir de différentes sources (bien qu'il soit certainement possible, car chaque version d'attribut conserve une référence à son origine).
Dans tous les cas, si votre système est censé implémenter la fonctionnalité déduplication, fusion d'enregistrements et autres éléments MDM, vous devez lire attentivement les aspects du stockage des clés naturelles dans les méthodologies flexibles. Peut-être que la conception plus lourde du Data Vault est soudainement plus sûre en termes d'erreurs de fusion.
modèle d'ancre fournit également un type d'objet supplémentaire appelé Noeud en fait c'est spécial type d'ancre dégénéré, qui ne peut contenir qu'un seul attribut. Les nœuds sont censés être utilisés pour stocker des répertoires plats (par exemple, sexe, état civil, catégorie de service client, etc.). Contrairement à Anchor, Knot n'a pas de tables attributaires associées, et son seul attribut (nom) est toujours stocké dans la même table avec la clé. Les nœuds sont liés aux ancres par des tables de liens (Tie) de la même manière que les ancres sont connectées les unes aux autres.
Il n'y a pas d'opinion sans ambiguïté sur l'utilisation des nœuds. Par exemple, , qui promeut activement l'utilisation du modèle d'ancrage en Russie, estime (non sans raison) qu'il est impossible de dire pour un seul ouvrage de référence qu'il toujours sera statique et à un seul niveau, il est donc préférable d'utiliser une ancre à part entière pour tous les objets à la fois.
Une autre différence importante entre Data Vault et Anchor Model est la présence attributs pour les liens:
В Coffre de données Les liens sont les mêmes objets à part entière que les hubs et peuvent avoir propres attributs. la modèle d'ancre Les liens ne sont utilisés que pour connecter les ancres et ne peuvent pas avoir leurs propres attributs. Cette différence conduit à des approches de modélisation sensiblement différentes. des faits, dont il sera question ensuite.
Stockage des faits
Jusqu'à présent, nous avons principalement parlé de mesures de modélisation. Les faits sont un peu moins tranchés.
В Coffre de données un objet typique pour stocker des faits − Lien, dans les satellites desquels des indicateurs réels sont ajoutés.
Cette approche semble être intuitive. Elle permet d'accéder facilement aux indicateurs analysés et s'apparente généralement à une table de faits traditionnelle (seuls les indicateurs ne sont pas stockés dans la table elle-même, mais dans la « table adjacente »). Mais il y a aussi des pièges : l'un des raffinements typiques du modèle - l'expansion de la clé de fait - rend nécessaire ajouter une nouvelle clé étrangère au lien. Et cela, à son tour, «casse» la modularité et entraîne potentiellement le besoin d'améliorations pour d'autres objets.
В modèle d'ancre Un lien ne peut pas avoir ses propres attributs, donc cette approche ne fonctionnera pas - absolument tous les attributs et indicateurs doivent être liés à une ancre spécifique. La conclusion en est simple - chaque fait a aussi besoin de sa propre ancre. Pour certains de ce que nous avons l'habitude de percevoir comme des faits, cela peut sembler naturel - par exemple, le fait d'un achat se réduit parfaitement à l'objet « commande » ou « reçu », la visite d'un site se réduit à une session, etc. Mais il y a aussi des faits pour lesquels il n'est pas si facile de trouver un «objet porteur» aussi naturel - par exemple, le solde des marchandises dans les entrepôts au début de chaque journée.
En conséquence, il n'y a pas de problèmes de modularité lors de l'expansion de la clé de fait dans le modèle d'ancre (il suffit simplement d'ajouter une nouvelle relation à l'ancre correspondante), mais la conception du modèle pour afficher les faits est moins simple, des ancres "artificielles" peuvent apparaître qui reflètent le modèle objet de l'entreprise n'est pas évident.
Comment la flexibilité est atteinte
La construction résultante dans les deux cas contient beaucoup plus de tablesque la mesure traditionnelle. Mais ça peut prendre beaucoup moins d'espace disque avec le même ensemble d'attributs versionnés que la dimension traditionnelle. Naturellement, il n'y a pas de magie ici - tout est question de normalisation. En répartissant les attributs sur les Satellites (dans le Data Vault) ou les tables individuelles (Anchor Model), nous réduisons (ou éliminons complètement) dupliquer les valeurs de certains attributs lors de la modification d'autres.
Pour Coffre de données le gain dépendra de la répartition des attributs entre les Satellites, et pour modèle d'ancre — est presque directement proportionnel au nombre moyen de versions par objet de mesure.
Cependant, occuper de l'espace est un avantage important, mais pas le principal, du stockage des attributs séparément. Associée au stockage séparé des liens, cette approche rend le stockage conception modulaire. Cela signifie que l'ajout à la fois d'attributs individuels et de nouveaux domaines dans un tel modèle ressemble à superstructure sur un ensemble d'objets existant sans les modifier. Et c'est exactement ce qui rend les méthodologies décrites flexibles.
Cela ressemble également à la transition de la production à la pièce à la production de masse - si dans l'approche traditionnelle chaque table modèle est unique et nécessite une attention particulière, alors dans les méthodologies flexibles, il s'agit déjà d'un ensemble de «détails» typiques. D'une part, il y a plus de tables, les processus de chargement et de récupération des données devraient sembler plus compliqués. D'autre part, ils deviennent typique. Cela signifie qu'il peut y avoir automatisé et géré par métadonnées. La question « comment allons-nous la poser ? », dont la réponse pourrait occuper une part importante du travail sur la conception des améliorations, n'en vaut plus la peine (tout comme la question de l'impact du changement de modèle sur processus de travail).
Cela ne signifie pas que les analystes d'un tel système ne sont pas du tout nécessaires - quelqu'un doit encore élaborer un ensemble d'objets avec des attributs et déterminer où et comment tout charger. Mais la quantité de travail, ainsi que la probabilité et le coût d'une erreur, sont considérablement réduits. Tant au stade de l'analyse que lors du développement de l'ETL, qui peut en grande partie se réduire à l'édition des métadonnées.
Côté obscur
Tout ce qui précède rend les deux approches vraiment flexibles, manufacturables et adaptées à un raffinement itératif. Bien sûr, il y a aussi un "baril de goudron", que je pense que vous connaissez déjà.
La décomposition des données sous-jacente à la modularité des architectures flexibles entraîne une augmentation du nombre de tables et, par conséquent, aérien pour les jointures lors de la récupération. Afin d'obtenir simplement tous les attributs d'une dimension, une seule sélection suffit dans le stockage classique, et une architecture flexible nécessitera un certain nombre de jointures. De plus, si pour les rapports toutes ces jointures peuvent être écrites à l'avance, alors les analystes habitués à écrire du SQL à la main en souffriront doublement.
Plusieurs faits facilitent cette situation :
Lorsque vous travaillez avec de grandes dimensions, presque tous ses attributs ne sont presque jamais utilisés simultanément. Cela signifie qu'il peut y avoir moins de jointures qu'il n'y paraît à première vue sur le modèle. Dans Data Vault, vous pouvez également prendre en compte la fréquence de partage prévue lors de l'attribution d'attributs aux satellites. Dans le même temps, les hubs ou les ancres eux-mêmes sont principalement nécessaires pour générer et mapper des substituts à l'étape de chargement et sont rarement utilisés dans les requêtes (ceci est particulièrement vrai pour les ancres).
Toutes les jointures se font par clé. De plus, une manière plus « compressée » de stocker les données réduit la surcharge de l'analyse de la table là où elle est nécessaire (par exemple, lors du filtrage par une valeur d'attribut). Cela peut conduire au fait que la récupération à partir d'une base de données normalisée avec un tas de jointures sera encore plus rapide que l'analyse d'une dimension lourde avec beaucoup de versions par ligne.
Par exemple, ici dans article il y a un test de performance comparatif détaillé du modèle Anchor avec une sélection d'un tableau.
Cela dépend beaucoup du moteur. De nombreuses plates-formes modernes disposent de mécanismes internes pour optimiser les jointures. Par exemple, MS SQL et Oracle peuvent "ignorer" les jointures aux tables si leurs données ne sont utilisées nulle part sauf pour d'autres jointures et n'affectent pas la sélection finale (élimination de table/jointure), tandis que MPP Vertica , s'est avéré être un excellent moteur pour le modèle d'ancrage, avec une optimisation manuelle du plan de requête. D'un autre côté, stocker le modèle d'ancrage, par exemple, sur Click House, qui a un support limité pour la jointure, ne semble pas encore être une bonne idée.
De plus, pour les deux architectures, il existe trucs spéciaux, qui facilitent l'accès aux données (à la fois en termes de performances des requêtes et pour les utilisateurs finaux). Par exemple, Tableaux ponctuels dans Data Vault ou fonctions de table spéciales dans le modèle d'ancrage.
En tout
L'essence principale des architectures flexibles considérées est la modularité de leur « conception ».
Cette propriété permet :
- Après une préparation initiale liée au déploiement des métadonnées et à l'écriture d'algorithmes ETL de base, fournir rapidement au client le premier résultat sous la forme de quelques rapports contenant des données provenant de quelques objets source seulement. Il n'est pas nécessaire de bien réfléchir (même au plus haut niveau) à l'ensemble du modèle d'objet pour cela.
- Un modèle de données peut commencer à fonctionner (et être utile) avec seulement 2-3 objets, puis grandir progressivement (concernant le modèle Anchor Nikolai belle comparaison avec le mycélium).
- La plupart des améliorations, y compris l'élargissement du domaine et l'ajout de nouvelles sources n'affecte pas les fonctionnalités existantes et ne risque pas de casser quelque chose qui fonctionne déjà.
- Grâce à la décomposition en éléments standards, les processus ETL dans de tels systèmes se ressemblent, leur écriture se prête à l'algorithmique et, finalement, automatisation.
Le prix de cette flexibilité est производительность. Cela ne signifie pas qu'il est impossible d'atteindre des performances acceptables sur de tels modèles. Le plus souvent, vous aurez peut-être besoin de plus d'efforts et d'attention aux détails pour atteindre les métriques souhaitées.
Applications
Types d'entités Coffre de données
En savoir plus sur Data Vault :
Types d'entités Modèle d'ancre
En savoir plus sur le modèle d'ancrage :
Tableau récapitulatif avec les points communs et les différences entre les approches envisagées :
Source: habr.com