« Dans la nature c'est toujours la voie de la facilité qui prédomine » ai-je lu un jour, ce qui me permet de ne pas m'étonner du fait que dans le domaine du décisionnel, les entreprises aient multiplié les architectures de data warehouses distribués (hub-and-spoke, data marts indépendants). Victime de leur succès les systèmes décisionnels ont un nombre de plus en plus élevé de sources opérationnelles à gérer et la première tâche pour les projets de data warehouses est de gérer les flux de données. La maîtrise technique et fonctionnelle des architectures, la capacité de monter en charge et de s'adapter en temps quasi réel aux événements et aux contraintes opérationnelles sont les principaux défis que doivent relever ces projets.
Une approche par multiplication de data marts destinés à répondre à des besoins tactiques induit une augmentation exponentielle des coûts de gestion de flux de données partiellement redondants, ainsi qu'une diminution progressive de la qualité de ces données.
Il convient de bien prendre en compte que dans les grandes entreprises, les systèmes décisionnels doivent gérer un volume de données historiques jusqu'à plusieurs dizaines de To ; répondre au besoins d'un nombre d'utilisateurs simultanés jusqu'à plusieurs milliers ; servir de nombreuses applications analytiques s'appuyant sur des données partagées ; autoriser différents types d'usage décisionnel (requêtes ad-hoc, requêtes batch, reporting, requêtes répétitives, data mining, requêtes opérationnelles) ; faciliter différents types alimentation (en batch, en temps réel) ; enfin assurer un niveau de tolérance de pannes jusqu'à une disponibilité système 24/24 et 7/7.
Les principaux inconvénients des architectures de data warehouses distribués concernent la qualité inadaptée des données (redondance, latence, fragmentation des données) ; l'augmentation exponentielle des coûts d'administration et de maintenance des flux de données, avec un déplacement progressif du coût de fonctionnement vers l'infrastructure technique, aux dépens des usages fonctionnels et des nouveaux besoins ; la difficulté de gérer les règles métiers (redondantes, distribuées dans de nombreux flux difficiles à synchroniser) ; l'absence d'un référentiel commun (métadonnées)
: une donnée peut faire l'objet de règles de gestion différentes selon les data marts dans lesquels elle est présente, et induire ainsi une perte de confiance de l'utilisateur induite par des différences qu'il ne peut expliquer ; l'absence de vision intégrée et transversale (multi domaines
fonctionnels) de l'entreprise (où se trouve la donnée utile ?) ; le manque de souplesse et d'agilité (incapacité de répondre aux évolutions rapides et critiques de l'environnement de l'entreprise due à l'absence de données intégrées et aux délais de maintenance des flux redondants) ; la difficulté d'évolution vers les nouveaux besoins décisionnels, tels que le data warehouse actif (alimentation en temps réel, intégration dans les applications opérationnelles).
Seule une approche de consolidation des architectures de data warehouses distribués peut apporter des solutions pragmatiques à ces différents problèmes. Elle consiste à rassembler et à intégrer l'ensemble des data marts indépendants dans un data warehouse d'entreprise (EDW, Enterprise Data
Warehouse) centralisé. Cette évolution peut être plus ou moins progressive, via un lotissement projet s'appuyant sur les priorités fonctionnelles et techniques. Cette consolidation des data marts indépendants dans un data warehouse d'entreprise centralisé est nécessaire pour répondre au besoin du pilotage d'une entreprise dans un environnement économique instable et soumis à de fortes contraintes concurrentielles qui imposent de disposer d'une vision transversale (multi domaines fonctionnels) de l'information décisionnelle. Il convient également de manière critique de disposer des données historiques dans des délais de plus en plus réduits, avec une réactivité et une souplesse de plus en plus grandes et avec une qualité de contenu irréprochable.
Une approche par multiplication de data marts destinés à répondre à des besoins tactiques induit une augmentation exponentielle des coûts de gestion de flux de données partiellement redondants, ainsi qu'une diminution progressive de la qualité de ces données.
Il convient de bien prendre en compte que dans les grandes entreprises, les systèmes décisionnels doivent gérer un volume de données historiques jusqu'à plusieurs dizaines de To ; répondre au besoins d'un nombre d'utilisateurs simultanés jusqu'à plusieurs milliers ; servir de nombreuses applications analytiques s'appuyant sur des données partagées ; autoriser différents types d'usage décisionnel (requêtes ad-hoc, requêtes batch, reporting, requêtes répétitives, data mining, requêtes opérationnelles) ; faciliter différents types alimentation (en batch, en temps réel) ; enfin assurer un niveau de tolérance de pannes jusqu'à une disponibilité système 24/24 et 7/7.
Les principaux inconvénients des architectures de data warehouses distribués concernent la qualité inadaptée des données (redondance, latence, fragmentation des données) ; l'augmentation exponentielle des coûts d'administration et de maintenance des flux de données, avec un déplacement progressif du coût de fonctionnement vers l'infrastructure technique, aux dépens des usages fonctionnels et des nouveaux besoins ; la difficulté de gérer les règles métiers (redondantes, distribuées dans de nombreux flux difficiles à synchroniser) ; l'absence d'un référentiel commun (métadonnées)
: une donnée peut faire l'objet de règles de gestion différentes selon les data marts dans lesquels elle est présente, et induire ainsi une perte de confiance de l'utilisateur induite par des différences qu'il ne peut expliquer ; l'absence de vision intégrée et transversale (multi domaines
fonctionnels) de l'entreprise (où se trouve la donnée utile ?) ; le manque de souplesse et d'agilité (incapacité de répondre aux évolutions rapides et critiques de l'environnement de l'entreprise due à l'absence de données intégrées et aux délais de maintenance des flux redondants) ; la difficulté d'évolution vers les nouveaux besoins décisionnels, tels que le data warehouse actif (alimentation en temps réel, intégration dans les applications opérationnelles).
Seule une approche de consolidation des architectures de data warehouses distribués peut apporter des solutions pragmatiques à ces différents problèmes. Elle consiste à rassembler et à intégrer l'ensemble des data marts indépendants dans un data warehouse d'entreprise (EDW, Enterprise Data
Warehouse) centralisé. Cette évolution peut être plus ou moins progressive, via un lotissement projet s'appuyant sur les priorités fonctionnelles et techniques. Cette consolidation des data marts indépendants dans un data warehouse d'entreprise centralisé est nécessaire pour répondre au besoin du pilotage d'une entreprise dans un environnement économique instable et soumis à de fortes contraintes concurrentielles qui imposent de disposer d'une vision transversale (multi domaines fonctionnels) de l'information décisionnelle. Il convient également de manière critique de disposer des données historiques dans des délais de plus en plus réduits, avec une réactivité et une souplesse de plus en plus grandes et avec une qualité de contenu irréprochable.
Pour aller plus loin sur ce sujet vous pouvez consulter le lien suivant : http://www.teradata.com/t/go.aspx/?id=81730.
