Le document

image[6]

constitue une excellente introduction technique sur le sujet. Nous en reprenons ici les principaux éléments.

 

1. Bénéfices attendus

Tout d’abord rappellons les bénéfices attendus de telles architectures :

  • Déploiement accéléré sur des configurations matérielles pré-testées
  • Coûts de maintenance et d’achat réduits suite à des choix matériels optimisés pour la charge décisionnelle
  • Coûts de mise en oeuvre et de déploiement réduits par l’utilisation des guide d’architecture de référence
  • Augmentation du taux de succès
  • Réduction des coûts de support et de montée en puissance ultérieurs en choississant ès le départ des architectures concues pour la montée en charge.

2. Périmètre visé

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”.

 

3. Démarche

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.

 

4. Les composants de l’architecture

Une solution “Fast Track” contient les éléments suivants:

  • Ressources sous forme de guide et de meilleures pratiques
  • Du matériel de type SMP testé et préconfiguré
  • Le logiciel Système (Windows Server 2008) et SGBD (SQL Server 2008) ainsi que les guides de configuration et d’optimisation correspondants.

5. Architecture

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 :

  • 10 tables de dimensions qui contiennent des informations sur une entité “business” comme les clients.
  • 2 tables de faits qui contiennent les mesures qui sont analysées, comme les ventes. habituellement les tables de faits contiennent des millions , voire des milliards de lignes mais sont optimisées car ne contiennent pas de données textuelles inutiles, uniquement des clés étrangères vers les données stockées dans les tables de dimensions.

6. Caractéristiques distinctives des architectures de référence SQL Server pour les entrepôts de données

Ce qui rend ces architectures de référence réellement intéressantes et uniques peut être résumé en deux points :

  1. Elles sont optimisées pour des charges de requêtes typiques des entrepôts de données
  2. Elles sont nativement équilibrées (c’est à dire sans goulets d’étranglement)

7. Configurations testées

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

(16) 300Go

15k FC

4To (testé)

10 To (max)

HP Proliant

DL 585 G5

(4) AMD Opteron Shanghai

quad core
2.7 GHz

16

(4) HP MSA2000

(32) 300Go

15k SAS

8To (testé)

16To (max)

(4) EMC CX4-240

(32) 300Go

15k FC

8To (testé)

16To (max)

HP Proliant

DL 785 G5

(8) AMD Opteron Shanghai

quad core
2.7 GHz

32

(8) HP MSA2000

(64) 300Go

15k SAS

16To (testé)

32To (max)

(8) EMC CX4-240

(64) 300Go

15k FC

16To (testé)

32To (max)

Dell Power Edge 2950 MLK

(2) Intel Xeon Harpertown

quad core 2.66 GHz

8

(2) EMC CX4-240

(16) 300Go

15k FC

4To (testé)

8To (max)

Dell Power Edge R900

(4) Intel Xeon Dunnington

six core 2.67GHz

24

(6) EMC

CX4-240

(48) 300Go

15k FC

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.