Le choix d’une architecture matérielle pour héberger le Data Warehouse est une étape complexe. Elle consiste en réalité à résoudre une équation à quatre inconnues : la volumétrie des données, le nombre d’utilisateurs (et par voie de conséquence le nombre de requêtes simultanées), la complexité des requêtes
Choix d’architecture Data Warehouse
et la complexité du modèle logique des données (3ème forme normale, flocon, étoile, dimensionnel, multidimensionnel).
Une fois la démarche, vue ci-dessus, entreprise, on dispose des éléments nécessaires pour résoudre cette équation et choisir l’architecture adéquate. Mais, en la matière rien n’est inscrit dans le marbre. Les évolutions technologiques des architectures x86 ces dernières années tout comme celles des stockages, associées à la souplesse de mise en œuvre et la capacité de montée en charge de logiciels SGBD comme SQL Server permettent d’envisager de multiples stratégies.
Architecture simple
Contrairement à une idée fréquemment répandue, un Data Warehouse n’est pas une solution de grandes entreprises uniquement et n’implique pas nécessairement des volumétries gigantesques.
L’idée fondamentale d’un Data Warehouse est d’offrir une vision homogène et fiable des données de l’entreprise dans son ensemble. Le Data Warehouse fournit en quelque sorte une version unique de la « vérité » de l’entreprise. Dès lors, toute entreprise quelle que soit sa taille mérite son Data Warehouse.
Il est tout à fait envisageable pour une PTE ou une PME d’avoir un Data Warehouse de 200 Go ou plus sur un simple serveur sous SQL Server 2008 Standard Edition. Il suffit simplement de ne pas mélanger les applications de production (qui sont transactionnelles et passent l’essentiel de leur temps à écrire) et les applications décisionnelles (qui sont interrogatives et passent l’essentiel de leur temps à lire) sur les mêmes machines et baies disques.
Architecture SMP
Avec l’évolution des processeurs multi-cœurs et des SAN, n’importe quelle entreprise peut désormais accéder à ce que l’on qualifie d’architecture SMP. Dans ces architectures, les multiples nœuds et processeurs accèdent à des ressources partagées. Pour gagner en puissance, on multiplie les processeurs jusqu’à atteindre la saturation des ressources partagées. Cette approche convient bien aux « appliances » mais elle n’y est nullement limitée. Par exemple, les spécifications « Fast Track » de Microsoft définissent une référence d’architecture SMP pour des Data Warehouse de 500 Go à quelques dizaines de Téraoctets sous SQL Server en s’appuyant sur des équipements standards. Ces spécifications peuvent être appliquées telles quelles sur des appliances ou au contraire être appliquées sur des infrastructures existantes et facilement être personnalisées, adaptées et étendues notamment par des intégrateurs partenaires comme Avanade, Cognizant, HP ou Hitachi.
Architecture SMP+OLAP
D’autant qu’avec un peu de souplesse dans la conception du modèle du Data Warehouse, en mixant l’approche base de données relationnelles pures et l’approche OLAP, on peut obtenir des gains de performance étonnants sans pour autant changer d’architecture matérielle. En effet, il existe des requêtes métiers qui s’énoncent naturellement sur des cubes pré-calculés et évitent ainsi la saturation du Data Warehouse par des requêtes trop complexes. En ce sens, le multidimensionnel permet de servir un plus grand nombre d’utilisateurs. Ajouter de la « BI » au dessus du Data Warehouse permet donc de booster celui-ci, un atout non négligeable sur des offres comme SQL Server 2008 qui intègre en standard les outils BI.
La qualité de la donnéeComme le souligne Gérard Haudiquert « la donnée d’un Data Warehouse se prépare ». Parce qu’il donne une seule vision – fiable et juste – de la réalité de l’entreprise, le Data Warehouse doit être alimenté par des informations qui ont été en amont qualifiées et vérifiées. Pour Bertrand Audras « Dans un Data Warehouse on consolide des données qui doivent être cohérentes et fiables puisque c’est sur elles que vont se porter les processus de décision et les indicateurs remontés par les outils BI. On doit absolument avoir une confiance absolue dans les données qui y sont chargées. Il faut dont contrôler en amont et en cas de doute il faut rejeter/filtrer à l’entrée les éléments sur lesquels on a des doutes ou que l’on ne peut qualifier ». La qualité des données n’est donc pas uniquement une qualité technique, elle possède aussi une qualité fonctionnelle et dépend de la qualité des processus d’intégration : « l’outil ETL de SQL Server intègre des modules de nettoyage de données s’appuyant par exemple sur de la logique floue qui consiste en particulier à avoir des notions de rapprochement d’informations (comment on rapproche ou non des homonymes par exemple) et de combinatoire « scoring/probabilités » qui permet selon les choix de design d’accepter ou refuser une donnée » explique ainsi Bertrand Audras. |
Téléchargez cette ressource
Guide de Sécurité IA et IoT
Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.
Les articles les plus consultés
A travers cette chaîne
A travers ITPro
