Réconciliation d’architecture et de modélisation en BI

Dans le milieu de la BI, il est courant d’avoir des discussions récurrentes sur la façon la plus optimale de construire un entrepôt de données combinant flexibilité, performance et évolutivité. Bien que les entreprises ayant traditionnellement investi de manière substantielle dans leurs départements IT disposent, pour la plupart, déjà de telles infrastructures, il arrive tout de même que des besoins nécessitant une mise à niveau, voire une reconstruction de l’infrastructure se présentent. Lorsque des contraintes de reconstruction apparaissent, ils soulèvent souvent la question de savoir sous quelle forme la nouvelle architecture doit être faite : faut-il rester dans le traditionnel et établir une architecture simple, généralement basée sur les principes de Ralph Kimball? Ou bien faut-il aller vers une solution un peu plus complexe mais avec une ségrégation technique plus définie telle que prônée par Bill Inmon? En dernier lieu on peut se demander s’il faut se mettre dans l’air du temps et adopter une modélisation en Data Vault, tel que récemment soutenue par Daniel Linstedt et Michael Olscmicke.

Si vous ne reconnaissez aucun des noms ou des terminologies employées ci-haut, vous n’êtes certainement pas un cas isolé. Travaillant depuis des années dans la Business Intelligence, je rencontre très souvent des personnes au profil aussi bien technique que fonctionnel qui se perdent en tentant de réconcilier chacun des principes et des théories associées à la construction d’un entrepôt de données.

Au travers de cet article, je vais tenter de donner une vue globale des différentes pensées d’architecture et de modélisation des entrepôts de données, communément appelés Data Warehouse (DWH). En plus de présenter les 3 architectures les plus couramment mises en place en entreprise, je vais également tenter d’éclaircir les points associés aux différentes technologies utilisées dans la chaîne complète de la BI.

C’est quoi la Business Intelligence

Avant toute chose, vous pourriez vous demander ce qu’est exactement la BI et pourquoi cette discipline suscite autant d’intérêt aussi bien en entreprise que dans les milieux académiques. Pour comprendre la BI, il faut avant tout comprendre comment les entreprises traitent les données qui sont générées par leurs clients et leurs collaborateurs. La meilleure façon d’illustrer ces traitements est de présenter un exemple simple et concret.

Prenons le cas d’une personne souhaitant effectuer l’achat d’un produit en ligne. La personne se dirige vers le site internet du vendeur, sélectionne ses produits et au moment d’effectuer le paiement, introduit ses informations de contact et de paiement. Au niveau de l’infrastructure IT du marchand, l’entièreté de ces informations est capturée et stockée dans des bases de données. Une transaction unique permet donc à l’entreprise de stocker des informations ayant une réelle valeur stratégique. Ces informations peuvent concerner les caractéristiques de la clientèle (âge et sexe par exemple), la transaction (le montant et le produit vendu par exemple) ou le lieu où a eu lieu la transaction (dans ce cas-ci, sur le site internet du marchand). En supposant que le marchand effectue des centaines de millier de transactions similaires sur une période donnée, il dispose d’une masse importante de données qui, lorsqu’elle est traitée et agrégée, peut lui permettre d’avoir une vue globale sur les performances de ses différents points de vente ou de ses produits, mais aussi vers quelle masse démographique ses produits rencontrent le plus grand succès.

En informatique décisionnelle, lorsqu’il est évoqué le fait d’extraire et d’exploiter des données opérationnelles (vente de produit par exemple) en vue de les restituer pour présenter des tendances agrégées ou non (indicateurs de performance par exemple), on fait référence à la Business Intelligence. La BI n’est donc rien d’autre que l’utilisation d’un ensemble hétérogènes de stratégies et de technologies informatiques pour des besoins d’analyses de données. La composante ‘analyse de données’ peut prendre plusieurs formes : il peut s’agir d’analyse pure (interprétation de données), de data mining (exploration en profondeur des données en source et présentation) ou encore de visualisation (présentation en graphe). Cette liste n’est pas exhaustive.

En définissant la Business Intelligence, j’insiste sur le fait que la composante ‘analyse’ intègre aussi bien l’analyse descriptive que prédictive. Ceci est important car il arrive souvent qu’en évoquant la Business Intelligence, on la dissocie de manière abusive de la Data Science. La composante descriptive traitant les données afin d’expliquer ‘ce qui est’ est beaucoup plus courante et de ce fait, compose une large part de ce qui est fourni actuellement en terme de services et de prestations. La Data Science, qui traite les données afin d’expliquer ‘ce qui sera’ ou ‘ce qui pourrait être’, est une niche concentrée dans le domaine du prédictif. Elle est donc souvent évoquée dans les domaines d’intelligence artificielle ou d’apprentissage automatique (Machine Learning). Vous pouvez parcourir nos perspectives ou nos études de cas pour découvrir comment nous aidons nos clients dans ces domaines.

Pourquoi construire un entrepôt de données

Dans l’exemple présenté ci-haut, j’ai expliqué que les opérations effectuées sur le site du marchand sont stockées dans des bases de données et que ces données peuvent être utilisées pour avoir une vue sur des indicateurs de performance de l’entreprise. La question à laquelle il faut répondre maintenant est celle de savoir : comment est-il possible de faire naviguer ces données des systèmes opérationnels pour que le Business (manager, CEO, Chef d’équipe, etc.) puisse consulter les indicateurs s’y référant ?

La réponse la plus simple serait de dire qu’il suffirait de connecter les outils analytiques utilisés par le Business aux systèmes opérationnels et ainsi requêter directement les bases de données sources pour présenter les indicateurs.

Visualisation d’une architecture simple

Bien que cette approche ait l’avantage d’accorder au Business la possibilité de voir en temps réel les données opérationnelles, elle impose tout de même une charge énorme aux systèmes opérationnels. Requêter de manière récurrente les bases de données opérationnelles, de plus avec des contraintes d’agrégation et de filtrage, peut ralentir de manière significative les performances. Lorsque combiné avec l’interaction que les applications opérationnelles ont avec les mêmes bases de données, ce ralentissement peut être exponentiel. Inutile donc de dire que techniquement, cette solution est loin d’être la meilleure option.

“Le DWH est au cœur de la BI. Il fournit une version consolidée, consistante, non-volatile et temporellement variante des données d’une organisation“

Par conséquent, il faudrait mettre sur pied un système permettant de ne pas surcharger les bases de données opérationnelles ; tout en facilitant l’accès par les applications analytiques auxdites données opérationnelles. Les systèmes remplissant cette double mission sont appelés entrepôt de données.

Architecture BI avec entrep?t de donn?es

L’entrepôt de données constitue le cœur même de la Business Intelligence. Il stocke les données extraites des systèmes sources, y applique un nombre important de transformation (nettoyage, agrégation, enrichissement) puis rend les résultats disponibles à des fins d’analyse et/ou de reporting. Les données déchargées dans un entrepôt peuvent provenir de sources variées : applications opérationnelles (ERP, CRM, SCM ou HRM), fichiers plats (csv), données non structurées (NoSQL) ou semi-structurées (XML ou JSON). Parce qu’il permet de fournir une version consolidée, consistante, non-volatile et temporellement variante de l’ensemble des données d’une organisation, l’entrepôt de données est l’élément central dans la mise en place de toute stratégie d’entreprise tournée vers l’analytique.

Terminologie courante en BI

Dans les sections précédentes, j’ai évoqué à plusieurs reprises des termes comme ‘systèmes opérationnels’, ‘bases de données opérationnelles’ ou ‘applications analytiques’. En l’absence de contexte, l’utilisation de ces termes peut prêter à forte confusion au point qu’il devienne difficile de déterminer ce dont on parle. Par conséquent, il est important de clarifier chacun des termes fréquemment utilisés en BI pour décrire les différents intervenants de la chaîne de la donnée.

La naissance de la chaîne BI se situe lors de la création de la donnée au niveau opérationnel, c’est-à-dire lorsque l’utilisateur front-end introduit des informations dans une application. Il peut s’agir d’effectuer une vente, d’enregistrer un client ou tout simplement d’encoder une entrée de stock de marchandise. Les applications permettant de faire ces types d’opérations sont appelées ‘applications opérationnelles’ parce que, comme le nom l’indique, elles facilitent l’exécution d’opérations courantes d’une entreprise. Les applications opérationnelles les plus couramment utilisées en entreprise incluent les suites SAP, Microsoft Dynamics et bien d’autres.

Les données générées par les applications opérationnelles sont stockées dans les bases de données opérationnelles, ou plus couramment appelées ‘bases de données sources’. La combinaison de bases de données sources et des applications opérationnelles est couramment appelée ‘systèmes transactionnels’ (ou OLTP, pour Online Transaction Processisng).

Comme mentionné précédemment, les données sources doivent être extraites, transformées puis déchargées dans l’entrepôt. Ce processus est communément appelé ETL (Extract, Transform, Load). C’est le même procédé qui est mise en place pour faire naviguer les données entre les différentes couches d’ingestion de l’entrepôt. Plusieurs technologies permettent de faire de l’ETL, notamment SQL Server Integration Services, SAS Data Integration, Informatica, Talend ou encore IBM Datastage.

Il arrive quelques fois qu’en lieu et place de faire de l’ETL, il soit préféré plutôt une approche d’ELT (Extract, Load, Transform) pour faire transiter les données entre différentes couches. Ceci est généralement le cas quand il n’existe pas de couche transitoire entre les données sources et la couche de données pouvant être accessible par l’application analytique, de sorte que les transformations soient faites directement lorsque les données sont requêtées. Parce que la plupart des applications analytiques nécessitent que les données soient transformées et préparées avant d’être exploitées, la méthodologie ETL est la référence lorsqu’il s’agit de construire des entrepôts de données, tandis que l’ELT est plus utilisée pour construire des data lakes, lesquels n’exigent pas de transformation préalable des données avant ingestion.

Comme déjà mentionné, après que toutes les transformations aient été faites et que les données aient été rendues disponibles pour exploitation, elles sont mises à disposition sur une couche spécifique de l’entrepôt afin que les applications analytiques puissent s’y connecter. Dépendant du type d’analyse devant être effectuée, différents types d’outils sont utilisés ; les plus courants étant SQL Server Analysis Services, Power BI, Tableau, Qlik, Oracle BI EE ou encore SAP Business Objects. L’ensemble des techniques et des technologies utilisées pour l’exploitation et l’analyse de données est communément appelé ‘systèmes analytiques’.

Comment mettre sur pied un entrepôt de données

Maintenant que le contexte ainsi que les terminologies sont expliqués, nous pouvons passer en revue les différents types d’architecture d’un entrepôt de données moderne.

Modèle à deux couches

Deux personnes sont reconnues comme étant les précurseurs de la littérature sur les entrepôts de données : Bill Inmon et Raplh Kimball. Ce dernier a théorisé et popularisé le concept de création d’entrepôt basé sur une modélisation dimensionnelle, dans laquelle l’architecture devrait suivre une approche de bas-en-haut : identification des processus clés puis rajout de processus additionnels. L’architecture classique de Kimball peut se résumer aux points suivants : l’entrepôt de données doit être précédée d’une couche physique non-normalisée, avec très peu de transformation et contenant des données historiques directement extraites des sources opérationnelles. Cette couche est appelée espace de transit (Staging Area). Cet espace possède la caractéristique qu’il contient une copie conforme des données sources, déchargées à intervalle constante.

Après que les données aient été chargées dans l’espace de transit via ETL, un second processus ETL est mis en place pour extraire à nouveau ces données, appliquer diverses transformations et décharger les résultats sur la dernière couche d’exploitation appelée entrepôt de données dimensionnel. Cette couche est conçue suivant une modélisation dimensionnelle repartie sur des data marts affectés à des différents départements de l’entreprise : marketing, risque, finance, etc. Les applications analytiques requêtent donc directement sur cette couche pour construire leurs analyses. Kimball recommande que les données dans cette couche soient atomisées, c’est-à-dire accessibles jusqu’au niveau le plus bas.

Architecture de Kimball

Le concept de modélisation dimensionnelle est aujourd’hui le standard autour duquel beaucoup d’applications analytiques sont construites pour faire de la lecture et de l’exploitation de données. Ce concept définit bien l’approche de Kimball sur la modélisation des couches de reporting : il repose sur le fait que chaque data mart doit être construit avec une table centrale appelée table des faits (Fact Table), dans laquelle sont stockées différentes mesures quantitatives du processus business. Cette table est ensuite liée par des clés business ou techniques à différentes tables dimensionnelles contenant le contexte desdits faits.

Dans le cas de la commande en ligne par exemple, la table des faits pourrait contenir des informations sur l’identifiant unique de la vente ainsi que le montant y associé tandis que les dimensions contiendraient les informations en rapport avec la personne ayant effectué la vente, l’acheteur ou le lieu où la vente a eu lieu. Cette modélisation est aussi connue sous le nom de modèle en étoile (star schema).

Les détails techniques de la construction d’un modèle en étoile sortent malheureusement du cadre de cet article, et ne seront par conséquent pas abordés ici.

Modèle à trois couches

Le modèle à trois couches a été proposé par Bill Inmon et à la différence de Kimball, il applique une approche de haut-en-bas : l’entrepôt est vu comme un dépôt centralisateur de toutes les données de l’entreprise dans lequel une couche normalisée est essentielle pour consolider toutes ces informations. Par conséquent, il est impératif qu’une séparation claire soit établie entre les données au niveau organisationnel et les données au niveau départemental. C’est pour cette raison que les data mart sont vus comme étant extérieurs à la couche d’entreprise alors que dans l’architecture de Kimball, cette distinction n’est pas nécessaire.

La couche stockant les données opérationnelles centralisées est appelée entrepôt de donnée d’entreprise (Enterprise Datawarehouse), elle est établie suivant un modèle en entité associé (ER Model) normalisée sous la troisième forme (3NF) et conserve les données au niveau atomique.

Architecture de Inmon

Remarquez que comme Kimabll, Inmon conserve la couche de transit. Cette couche possède les mêmes caractéristiques que celles décrites par Kimball : non-normalisée, conservation d’historique et très peu de transformation des données sources.

Comme Kimball et son entrepôt dimensionnel, les data marts sont également modélisés de façon dimensionnelle. Cependant, les données sont stockées de manière agrégée et leur accessibilité est fortement ségréguée :  chaque data mart est construit pour servir les besoins d’un sujet spécifique et les utilisateurs ayant accès à ce data mart sont clairement définis. Il serait donc courant d’avoir un data mart uniquement pour le personnel travaillant en finance, un autre pour le personnel du marketing ou bien pour le personnel du département de risque.

Modélisation Data Vault 2.0

La dernière tendance en matière de modélisation d’entrepôt de données nous vient de Daniel Linstedt et Michael Olschimke. Ces derniers partent du principe que les différentes architectures couramment mises en place en entreprise comportent un problème majeur : elles proposeraient très peu de possibilité d’extensibilité. Du fait même de la modélisation mise en place, ces architectures seraient très peu flexibles face aux exigences de plus en plus accrues qui reposent sur les entrepôts du fait de la croissance exponentielle de la quantité et de la complexité des données.

L’approche architecturale reste similaire à celle de Inmon dans le sens qu’elle est pensée avec 3 couches : une couche de transit, une couche de stockage opérationnel et des data mart orientés business.

Architecture de Linstedt & Olschimke

La différence se situe cependant au niveau de la modélisation ainsi que des principes de stockage :

• • La couche de transit demeure non-normalisée mais ne conserve plus d’historique ni n’applique de transformations
  • La couche de stockage opérationnel est modélisé en Data Vault 2.0 et porte le nom de Raw Data Vault
  • La couche de reporting reste modélisée de façon dimensionnelle et contient des données agrégées orientées business
  • Plusieurs couches optionnelles sont rajoutées afin de capturer différentes métadonnées :
    • Un ‘Metrics Vault’ : Capture les informations sur les exécutions
    • Un ‘Business Vault’ : Capture les informations sources sur lesquelles des règles business ont été appliquées
    • Un ‘Operational Vault’ : Capture les données ayant été déchargées vers l’entrepôt afin de les rendre accessibles aux systèmes opérationnels

Pour les besoins de cet article nous n’abordons pas les couches optionnelles.

Vous l’aurez donc compris, la grande contribution de cette nouvelle méthodologie se trouve dans la façon dont est modélisée le Raw Data Vault. La modélisation en Data Vault 2.0 est basée sur le principe de la création de tables hubs stockant les clés des différents sujets business ; ces hubs sont joints entre eux par des tables links qui contiennent toutes les relations entre les clés business de deux ou plusieurs hubs. Enfin, les tables satellites sont mises en place afin de stocker les informations contextualisant les hubs ou les links.  L’exemple de l’achat en ligne pourrait, par exemple, compter des hubs sur les points de vente, les collaborateurs ou les clients, des satellites contenant les informations de contexte sur chacun des hubs et enfin des links liant les différents hubs.

Comme pour le modèle en étoile, nous n’entrerons pas dans les détails techniques de la création des hubs, des links ou des satellites.

Extensions

Modélisation en flocon de neige

J’ai évoqué précédemment que la modélisation dimensionnelle constituait la base solide autour de laquelle l’exploitation analytique était faite. Cette modélisation est faite généralement suivant un modèle en étoile construite autour d’une table centrale, appelée table des faits et plusieurs tables associées appelées tables dimensionnelles. Cette modélisation est ainsi appelée à cause de l’apparence d’étoile qu’elle adopte lorsque les tables sont réarrangées autour de la table des faits.

Mod?lisation en ?toile

Le modèle en étoile est donc très peu normalisée et ceci a un avantage en termes de performance car elle ne nécessite pas une écriture de requête complexe.

Cette implémentation est idéale lorsqu’il n’existe que des relations assez simples, de type 1-n (une ligne dans la table dimensionnelle référençant plusieurs lignes dans la table des faits), entre la table des faits et les tables de dimension. Cependant, lorsque les relations sont complexes au point qu’ils soient du type n-n (plusieurs lignes de la table dimensionnelle référençant plusieurs autres lignes dans la table des faits), il est nécessaire de mettre une table pont entre les deux tables et recréer des relations 1-n ; la première entre la table des faits et la table pont, la deuxième entre la table pont et l’autre table de dimension.

Modélisation en flocon de neige

L’aspect qu’adopte le modèle après réarrangement rappelle celui d’un flocon de neige, d’où l’appellation ‘modèle en flocon de neige’. Ce modèle étant fortement normalisé, il peut demander de créer des jointures complexes entre les différentes tables et ainsi peser assez lourdement sur les performances lors la génération des requêtes SQL.

Cubes OLAP

Dans les points précédents, j’ai évoqué le fait que les applications analytiques se connectent aux couches de reporting pour faire de l’exploitation, par exemple en créant des tableaux de bord dynamiques. Il est tout de même important de noter qu’il existe également la possibilité d’utiliser les données de la couche de reporting pour faire de la modélisation multidimensionnelle. Cette modélisation crée des structures appelées ‘cubes OLAP’ (Online Transactional Processing) permettant de faire de l’analyse de données de façon multidimensionnelle: présentation de données en combinant différentes dimensions avec différentes mesures.

Mod?lisation cube OLAP

Les cubes OLAP stockent donc les données sous forme multidimensionnelle dans un serveur en back-end puis génèrent des rapports, affichant ainsi des données descriptives. Deux exemples de technologie permettant de créer des cubes OLAP sont SQL Server Analysis Services de Microsoft et Planning Analytics de IBM.

Cubes OLAP dans l’architecture BI

Master Data Management

Il peut arriver qu’il existe des inconsistances de données entre différents segments d’une entreprise du fait que chaque entité dispose d’une version différente de la même information. Ces inconsistances apparaissent souvent dans des cas assez spécifiques, par exemple lorsque deux sociétés décident de fusionner et qu’ils ont des définitions différentes de certaines informations commerciales. L’inconsistance peut également se produire lorsque différents départements de la même société, utilisant des applications opérationnelles différentes, génèrent des versions différentes des données référenciant pourtant les mêmes attributs commerciaux.

L’existence de telles divergences peut entrainer des écarts énormes au moment de l’agrégation de l’information et de la présentation d’indicateurs globaux. C’est pour cette raison qu’en plus des composants d’architecture présentés précédemment, il arrive souvent qu’il soit prévu de mettre en place des couches de donnée centralisant les données de référence (Master Data) au travers de l’ensemble de l’organisation afin de maintenir une seule et unique version de la vérité.

Gestion des donn?es de r?f?rence

À la différence d’autres couches informationnelles, la couche des données de référence est repartie au travers des différents systèmes et est considérée dans toute l’organisation comme étant l’unique source ayant office d’autorité. La mise en place d’un système de gestion des données de référence dans une organisation requiert d’établir une réelle stratégie de gouvernance, de politiques de gestion (mise en place des data owner, data stewards) et de technologie.

Prochaines étapes

Bien que nous ayons passé en revue différentes architectures BI et différents types de modélisation, il est important de garder à l’esprit que chaque société met en place sa propre interprétation des différents concepts que nous avons évoqués. Vous ne serez donc pas surpris de tomber quelques fois sur des particularités, lesquelles sont mises en place pour répondre aux besoins spécifiques de chaque entité.

Il est également important de noter qu’en dehors des architectures présentées dans cet article, il existe d’autres concepts architecturaux qui sont apparus principalement avec le déplacement des données vers le Cloud. C’est le cas par exemple d’Amazon Redshift, Azure Synapse Analytics ou Google BigQuery. Avant de parler de ces nouvelles architectures, il faudra en premier lieu aborder les détails techniques de la modélisation en étoile, en flocon ou en Data Vault 2.0. Ceci sera abordé dans un autre article.

Contactez l’auteur: em@mwilar.com