Le document
constitue une excellente introduction technique sur le sujet. Nous en reprenons ici les principaux éléments.
Tout d’abord rappellons les bénéfices attendus de telles architectures :
Le périmètre visé par les architectures de référence est le suivant :
Il s’agit donc bien de se concentrer sur la modélisation de l’entrepôt de données via un moteur relationnel (SQL Server 2008 en l’occurrence). la partie Cubes OLAP est en dehors du périmètre.
L’architecture cible pour cet entrepôt de données est un serveur de type SMP. Les architectures de type MPP (Massive Parallel Processing) sont hors de la cible pour cette première version et seront par contre gérées dans le cadre du projet “Madison”.
Le schéma suivant décrit la marche à suivre pour définir une architecture à l’aide de la méthodologie “Fast Track” :
L’étape 1 consiste à déterminer les besoins en terme de nombre de requêtes ainsi que leur typologie, la quantité de données qu’elles balaieront et le niveau de concurrence escompté.
L’étape 2 est optionnelle : elle n’est nécessaire que lorsque l’on ne souhaite pas utiliser l’une des configurations de référence fournies. Elle vise à déterminer les capacités en terme de débit CPU de la plateforme. Pour les plateformes de références, ces capacités sont évidemment connues.
L’étape 3 consiste à déterminer le nb de CPU nécessaire
L’étape 4 consiste à finaliser l’achat de la plateforme avec les espaces disques nécessaires
L’étape 5 consiste en la configuration du matériel acheté à l’étape précédente. Il est crucial de suivre à cette étape les recommandations de configuration afin de bénéficier des optimisations prévues pour des accès séquentiels aux données.
L’étape 6 consiste en une optimisation de la solution avec du partitionnement, de l’indexation et la mise en place d’une stockage temporaire.
Une solution “Fast Track” contient les éléments suivants:
Comme cela a déjà été souligné, l’architecture de l’entrepôt de données s’inscrit dans une architecture plus large :
Cependant la logique “Fast track” peut s’appliquer aussi bien à un entrepôt de données (“Datawarehouse”) qu’à une sous-ensemble dans une logique “Datamart”.
Le schéma de données retenu est classiquement un schéma en étoile :
Ici l’on a :
Ce qui rend ces architectures de référence réellement intéressantes et uniques peut être résumé en deux points :
Le tableau suivant détaille les configurations certifiées :
Serveur
Processeur
Cœurs
SAN
Nb de disques
Capacité
HP Proliant
DL 385 G5p
(2) AMD Opteron Shanghai
quad core 2.7 GHz
8
(2) HP
MSA2000
(16) 300Go
15k SAS
4To (testé)
8To (max)
(2) EMC CX4-240
15k FC
10 To (max)
DL 585 G5
(4) AMD Opteron Shanghai
16
(4) HP MSA2000
(32) 300Go
8To (testé)
16To (max)
(4) EMC CX4-240
DL 785 G5
(8) AMD Opteron Shanghai
32
(8) HP MSA2000
(64) 300Go
16To (testé)
32To (max)
(8) EMC CX4-240
Dell Power Edge 2950 MLK
(2) Intel Xeon Harpertown
quad core 2.66 GHz
Dell Power Edge R900
(4) Intel Xeon Dunnington
six core 2.67GHz
24
(6) EMC
CX4-240
(48) 300Go
12To (testé)
24To (max)
Les systèmes étant conçus de manière à équilibrer la CPU, les E/S et les échanges avec les disques, il convient de noter que l’on ne peut pas retirer de disques dans ces configurations.
L’espace disque indiqué correspond à l’espace utilisable par les données utilisateurs en prenant l’hypothèse d’un taux de compression moyen de 2,5.
Il est considéré que la mémoire est d’au moins 4Go par processeur soit 64 Go au minimum, mais plus raisonnablement de 128 Go ou 256 Go voire plus.
Une fois le bon matériel choisi, il convient de passer à la phase d’implémentation, celle ci sera décrite dans le message suivant.