Des systèmes d'information de gestion monolithiques aux entrepôts de données modélisés dimensionnellement et aux lacs de données, nous avons constaté des changements massifs dans la façon dont les organisations collectent, traitent, stockent et analysent leurs données au fil des ans. Chaque bond en avant dans la technologie et les techniques a été guidé par un effort conscient pour introduire une plus grande agilité, accessibilité et évolutivité à leurs rapports et analyses.
À juste titre, dans un environnement d'exploitation où les préférences des clients et les conditions du marché peuvent changer instantanément, les entreprises ont souvent besoin de visualiser et d'interroger les données en quelques heures pour obtenir cet avantage crucial sur leurs concurrents. Une architecture de données agile est essentielle pour atteindre cet objectif.
Entrer le approche basée sur les métadonnées. En utilisant Astera DW Builder, vous pouvez créer des modèles de données complets qui intègrent la conception, la logique et les mappages de données qui constituent l'essentiel du développement de l'entrepôt de données, puis répliquent l'intégralité du schéma dans un cloud ou une base de données sur site de votre choix. À partir de là, vous êtes prêt à alimenter, consommer ou mettre à jour votre entrepôt de données en toute simplicité.
En fin de compte, vous disposez d'un processus rapide et réactif conçu pour fournir des informations exploitables en fonction de votre calendrier. Comparez notre approche à la façon dont les choses se faisaient auparavant, et vous pourrez voir les avantages des métadonnées et l'énorme valeur que notre produit apporte au processus de développement.
Pourquoi l'entreposage de données doit évoluer
L'approche traditionnelle
Quand on parle de la approche traditionnelle, nous nous référons au développement de style cascade, qui domine cet espace depuis les années 90. Dans ce processus, l'entrepôt de données est construit dans une séquence de phases méticuleusement planifiée qui sont les suivantes:
- Rassemblement des exigences: À ce stade, les développeurs rencontreront des analystes commerciaux et d'autres utilisateurs finaux pour documenter le type de BI requis.
- Conception: Après avoir étudié les exigences, les développeurs concevront une architecture prototype qui englobe la structure physique / logique et les mappages de données nécessaires pour peupler et maintenir
- Créer l'accessibilité: Les développeurs doivent ensuite décider comment accéder aux données de l'entrepôt à des fins de reporting et d'analyse. Les données peuvent être rendues disponibles via une plateforme de BI frontale telle que PowerBI ou Tableau ou une solution personnalisée conçue pour répondre aux besoins de l'organisation.
- Test: Implique à la fois une partie QA pour identifier et résoudre les bogues qui pourraient entraver la convivialité / les performances. Ainsi que des tests d'acceptation par les utilisateurs pour garantir que l'entrepôt de données remplit son objectif déclaré.
Votre entrepôt de données n'est pas un projet. C'est un processus.
La limitation la plus importante de l'approche en cascade est que le développement est orienté vers une solution finie présentée comme la réponse à toutes les exigences BI de l'organisation. Cette approche coûteuse ne tient pas compte de la nature en constante évolution de ces besoins.
- Bien que les exigences commerciales soient rassemblées en fonction des besoins actuels des utilisateurs finaux, elles doivent également englober tous les scénarios possibles qui pourraient se développer dans des mois, voire des années. Bien sûr, il est plus facile à dire qu'à faire d'essayer de prédire l'état futur de votre entreprise.
- Parce qu'il y a tellement de transferts tout au long du processus de développement, des analystes commerciaux aux développeurs, architectes et spécialistes ETL, il y a toujours un risque que les exigences soient mal interprétées. En conséquence, la solution finale pourrait être loin de ce qui avait été convenu initialement, c'est-à-dire le Chuchotement chinois
- Il est également possible que les utilisateurs finaux n'aient pas compris leurs besoins en premier lieu. Ils ont peut-être sous-estimé les données à intégrer.
- Bien sûr, comme la plupart de ces problèmes ne sont identifiés que lors de la phase de test, toute correction augmentera le coût et les délais du projet.
D'accord, mais qu'est-ce qui améliore l'approche basée sur les métadonnées?
Commençons par ce que nous entendons par l'approche axée sur les métadonnées, car il existe de nombreuses facettes dans la façon dont nous traitons le développement de l'entrepôt de données dans Astera Constructeur DW.
Tout commence avec le modèle de données
La première chose à noter est que nous mettons la modélisation des données au centre de notre produit. Notre concepteur de modèles de données complet et sans code permet aux utilisateurs de concevoir chaque élément de leur EDW en un seul processus de bout en bout. Immédiatement, cela supprime les transferts séquentiels qui caractérisent l'approche en cascade. Au lieu de cela, vous disposez d'un processus de conception transparent qui peut être initié et géré par une seule personne (si nécessaire).
Vous voudrez probablement impliquer des utilisateurs techniques et non techniques dans la création de vos modèles de données et des flux ETL dans la pratique. Ce type de collaboration est intrinsèquement pris en charge dans notre produit, car tous les éléments nécessaires à la conception d'un modèle de données sont gérés et configurés au niveau des métadonnées. Que vous modélisiez les entités de votre système source ou que vous configuriez des tables de faits et de dimensions individuelles, tout cela est possible en interagissant directement avec le modèle de données à l'aide de concepts définis par l'entreprise.
Le grand avantage ici est que l'utilisateur final peut réellement traduire ses exigences conceptuelles en un modèle de données physique. Dans ce cas, toutes les relations d'entité, les règles métier et les conventions de dénomination sont convenues lors de la phase de conception - plutôt que clarifiées à la fin lorsqu'un prototype est réellement présenté. Un autre avantage clé est qu'au fur et à mesure de la construction du modèle, l'utilisateur final peut fournir des commentaires immédiats sur toutes les corrections à apporter ou ajuster ses besoins initiaux en fonction de la conception de travail de l'entrepôt de données.
Le résultat est un modèle de données fini qui est aligné sur les besoins de l'organisation.
Travailler de manière itérative pour répondre aux exigences de la BI
À ce stade, parlons de développement agile et en quoi il diffère de l'approche en cascade. Quelques valeurs fondamentales sont prisées dans cette méthodologie - la collaboration (que nous avons couverte), la priorité des logiciels fonctionnels par rapport à une documentation précise, et la capacité de travailler rapidement en fonction des besoins changeants plutôt que d'un plan défini.
Les deux derniers points sont essentiels lorsque l'on discute de la manière dont l'approche basée sur les métadonnées améliore le développement de l'entrepôt de données. Nous avons mentionné à quel point il est difficile de créer une documentation précise qui prédit parfaitement ce que seront vos besoins en BI dans un an ou même plus à partir d'aujourd'hui, alors pourquoi ne pas commencer à travailler immédiatement sur un déploiement plus petit qui répond à un besoin commercial actuel.
Avec Astera DW Builder, vous pouvez ajouter ce type d'agilité à votre entrepôt de données. Dès qu'un besoin urgent est identifié, votre équipe peut se mettre au travail en créant un modèle de données qui reflète les systèmes opérationnels sous-jacents devant être analysés et un schéma pour l'entrepôt de données utilisé pour interroger ces systèmes. Tout compte fait, le processus peut être achevé en quelques jours, voire quelques heures. En fin de compte, vous disposez d'une architecture fonctionnelle qui peut commencer immédiatement à fournir des informations exploitables à vos applications frontales.
Bien entendu, à mesure que ces exigences évoluent, vous pouvez modifier vos modèles existants en ajoutant de nouvelles entités ou des champs à votre modèle de données. Ou vous pouvez créer un modèle de données entièrement nouveau pour un processus métier différent qui doit être étudié en profondeur. Avec une approche agile en place, vous vous retrouvez avec un processus de développement itératif idéal pour un environnement commercial en évolution rapide.
Dites adieu au codage manuel
ETL est généralement la partie la plus longue du développement de l'entrepôt de données, car les développeurs doivent s'assurer que toutes les données chargées dans l'EDW sont exemptes de duplication ou d'autres problèmes de qualité des données et que les temps de chargement sont minimisés dans la mesure du possible. En règle générale, le processus nécessite un effort manuel important, les développeurs écrivant leur code à partir de zéro pour s'adapter aux particularités de chaque pipeline de données.
ADWB est livré avec un composant de flux de données qui vous permet de concevoir ces mappages source-entrepôt de données au niveau des métadonnées. En commençant par la gamme de connecteurs prêts à l'emploi qui vous permettront de récupérer facilement des données à partir de systèmes de fichiers plats et d'API vers des schémas de système source existants créés à l'aide de notre concepteur de modèles de données.
Cette dernière fonctionnalité est essentielle car elle évite d'avoir à extraire des données directement de vos systèmes opérationnels, ce qui consomme de précieuses ressources de calcul sur les serveurs de bases de données critiques. Cela crée également une couche de sécurité supplémentaire entre vos données transactionnelles et l'utilisateur final, car vous pouvez construire vos modèles de données pour réfléchir sur des tables et des enregistrements prêts pour l'analyse. Notre produit est également livré avec un générateur de requête de modèle de données dédié, vous permettant de créer une table source hiérarchique contenant plusieurs entités de modèle de données en fonction des relations existantes définies au stade de la modélisation. Encore une fois, cette création complexe de requêtes ne nécessite aucun SQL réel. Les entités pertinentes sont sélectionnées et configurées au niveau des métadonnées.
Le produit vous a également couvert lorsqu'il s'agit de préparer et d'enrichir vos données sources. Le générateur de flux de données propose plus d'une centaine de transformations intégrées qui vous aident à nettoyer, filtrer, remplacer, analyser et valider toutes les données transférées vers votre entrepôt de données. Ainsi, vous pouvez vous assurer que seules des données de haute qualité prêtes pour l'analyse entrent dans votre architecture BI.
Le mappage des données est encore accéléré par des chargeurs de faits et de dimensions dédiés qui tronquent les opérations de transfert chronophages et de recherche de dimensions complexes (dans les enregistrements historiques sont conservés) à un simple mappage par glisser-déposer. Connectez simplement la table de destination à l'entité appropriée dans votre modèle dimensionnel et vous êtes prêt à partir.
Une fois que vous avez terminé de concevoir des mappages de données de bout en bout, vous pouvez exécuter le flux de données. Notre moteur ETL lira les métadonnées et générera automatiquement le code nécessaire pour amener les données de la source à la destination. Nous proposons même des fonctionnalités de planification et d'orchestration de flux de travail pour vous aider à automatiser ces opérations en fonction de vos besoins.
Tester simultanément avant le déploiement
Avec ADWB, nous avons intégré des tests continus dans l'architecture même de la plate-forme. Avant de déployer l'un de vos modèles de données, vous devrez vérifier la conception pour vous assurer que chaque entité est configurée correctement et qu'il n'y a pas de champs vides ou de valeurs incohérentes. Avec les tests simultanés en place, vous pouvez identifier rapidement les erreurs dans votre build et les corriger avant qu'elles ne causent des problèmes à l'utilisateur final.
De même, nous avons mis en œuvre une journalisation en temps réel et des notifications d'erreur lors de l'exécution du flux de données, afin que tout problème dans vos processus ETL puisse être repéré dans les métadonnées. Le résultat est une architecture testée sous contrainte conçue pour gérer facilement les cas d'utilisation BI les plus complexes.
Répliquez votre schéma dans n'importe quelle base de données principale.
Étant donné que les modèles de données sont construits au niveau des métadonnées, ils ne sont pas codés en dur pour une intégration avec une plate-forme particulière. Essentiellement, ce que vous avez créé est un schéma indépendant de la plate-forme qui peut être facilement répliqué dans n'importe quelle base de données de destination. Pour rendre les choses encore plus faciles, nous fournissons un support pour les leaders sur site et entrepôts de données cloud, vous pouvez donc choisir de créer votre entrepôt de données sur l'infrastructure qui correspond le mieux à vos besoins en matière de BI.
Vous cherchez à tirer parti de l'évolutivité et des performances de Redshift d'Amazon, établissez une connexion à la base de données et transférez l'ingénieur. Vous souhaitez conserver vos rapports en interne? Sélectionnez un fournisseur local tel que SQL Server ou Oracle Database - le choix vous appartient.
Comparez ce processus aux implémentations coûteuses privilégiées dans Waterfall, où toute mise à jour ou modification nécessite un autre cycle de développement de bout en bout, et il est clair quelle méthode est la mieux adaptée à la BI moderne.
Découvrez l'entreposage de données basé sur les métadonnées avec Astera Constructeur DW
Voulez-vous profiter de notre nouvelle solution passionnante d'entreposage de données ? Je prends contact avec nos experts pour en savoir plus sur la façon dont notre architecture basée sur les métadonnées peut vous aider à obtenir les résultats dont vous avez besoin ou pour un démo personnalisée pour votre cas d'utilisation spécifique.
Auteurs:
- Adnan Sami Khan