Concevoir et déployer un data warehouse

Concevoir
et déployer un
data warehouse
Ralph Kimball
Éditions Eyrolles
ISBN : 2-212-09165-6
2000

11
Infrastructure et métadonnées
L’infrastructure et les métadonnées sont les fondations des composantes architecturales que
nous avons décrites dans les chapitres 8, 9 et 10. L’infrastructure d’un entrepôt de données
inclut le matériel, les réseaux et les fonctions de bas niveau, telles que la sécurité, que les
composants de haut niveau considèrent comme acquises. Les métadonnées sont un peu moins
concrètes que l’infrastructure, mais constituent tout de même la couche de base des outils
d’arrière-plan (back room) et frontaux (front room). Ce chapitre identifie et définit les princi-
paux composants de l’infrastructure et des métadonnées du data warehouse.
Dans la première partie de ce chapitre, nous examinons les principaux éléments à prendre en
compte en matière d’infrastructure des outils d’arrière-plan (back room). Ensuite, nous abor-
derons quelques considérations relatives au matériel, aux systèmes d’exploitation et aux
plates-formes de bases de données, en donnant au passage quelques définitions de base. Nous
en ferons ensuite de même pour les outils frontaux (front room). Enfin, pour relier l’ensemble,
nous évoquerons brièvement la connectivité et les réseaux.
La seconde partie de ce chapitre examine les métadonnées sous toutes les coutures. Il s’achève
par un exemple d’utilisation des métadonnées et par quelques réflexions sur leur maintenance.
Gestion du projet
Planification
du projet Définition
des
besoins de
l'entreprise
Spécification de
l'application
utilisateur
Déploiement
Maintenance
et
croissance
Développement
de l'application
utilisateur
Définition de
l'architecture
technique
Installation
et sélection
des produits
Modélisation
dimensionnelle Conception
du modèle
physique
Conception et
développement
des éléments
de la zone de
préparation
des données

Architecture
PARTIE 3
2
Bien qu’assez technique, ce chapitre concerne tous les membres de l’équipe; il est en effet
important que chacun connaisse bien ces pièces maîtresses du data warehouse.
Infrastructure
Plusieurs facteurs doivent être combinés pour déterminer l’infrastructure adaptée à une implé-
mentation donnée; ils ne sont pas forcément tous techniques. Les auteurs de ce livre ne sont
pas des experts en infrastructure. Notre stratégie a toujours consisté à travailler en étroite
collaboration avec les experts en infrastructure de nos clients et à les aider à bien comprendre
les besoins en infrastructure de l’entrepôt. Cette section identifie et définit les principaux
composants de l’infrastructure d’un data warehouse typique.
Éléments clés de l’infrastructure
Même dans les couches techniques les plus profondes de l’entrepôt, les besoins métier restent
les éléments déterminants de la mise en œuvre. Au niveau de l’infrastructure, les besoins métier
sont représentés par des mesures plus techniques. Par exemple, l’activité détermine le niveau de
détail auquel l’entrepôt doit descendre et le nombre d’années d’historique qu’il doit conserver.
Ces informations nous indiquent le volume de données que l’infrastructure aura à gérer. La
fréquence de chargement des données et la complexité des règles régissant les processus de
transformation peuvent également fournir des indications. Estimez ainsi le «nombre de chevaux»
dont il faudra doter votre configuration matérielle pour que tout se passe bien.
Les problèmes techniques et système conduisent également à certains choix relatifs à l’infras-
tructure. Dans certains cas, le processus d’extraction représente une charge trop lourde pour
les systèmes opérationnels; cette situation peut déboucher sur un investissement dans un envi-
ronnement matériel miroir. Les compétences et l’expérience des équipes chargées de la mise
en œuvre de l’entrepôt entrent aussi en ligne de compte. Les équipes responsables des outils
d’arrière-plan (back room) expérimentées en gros systèmes auront tendance à développer des
entrepôts de données sur gros systèmes, et vice versa . Il en est de même pour les plates-formes
de base de données. Si les administrateurs des bases de données ont investi beaucoup de temps
et d’énergie dans l’apprentissage d’un SGBD bien précis, il ne sera pas aisé de les orienter
vers un autre produit.
Les problèmes politiques et organisationnels jouent également un rôle dans le choix de
l’infrastructure. Les gros investissements sont souvent soumis à des limites «temporaires»;
dans un tel cas, vos réflexions sur l’infrastructure devront faire preuve de davantage de créati-
vité. Par ailleurs, la stratégie informatique de l’entreprise guidera certaines décisions relatives
au matériel. En effet, la standardisation des plates-formes permet de réaliser d’importantes
économies d’échelle, de capitaliser les compétences, et enfin de développer des applications
dont le portage d’un système à un autre sera relativement aisé.
Évolution de l’infrastructure
L’infrastructure matérielle de l’entrepôt de données englobe les plates-formes matérielles de
chaque magasin de données, de chaque serveur d’applications et des postes de travail.
À propos des plates-formes matérielles, il convient de garder à l’esprit qu’un entrepôt de données connaît
sa croissance la plus significative au cours des dix-huit premiers mois de son existence, à la fois en
termes de données et d’utilisation.
ASTUCE

Infrastructure et métadonnées
CHAPITRE 11 3
La première étape consiste à déterminer les plates-formes réellement nécessaires. Quels
magasins de données allez-vous mettre en œuvre? Parmi eux, combien devront disposer de
leur propre plate-forme? La figure 11.1 illustre quelques configurations matérielles typiques
correspondant à des projets de tailles diverses.
Chaque boite de cette figure représente une machine ou un ensemble de composants physique
de l’entrepôt. Un environnement à deux niveaux (2 tiers) suffit pour un projet modeste ou pour
un premier déploiement. Cependant, même les systèmes les plus petits doivent prévoir un
serveur d’applications pour permettre l’accès aux données via le Web. Dans les entrepôts de
données plus ambitieux ou arrivés à maturité, la zone de préparation des données est généra-
lement séparée de l’entrepôt ou du data mart. De nombreuses entreprises commencent direc-
tement à ce niveau, car elles ont l’intention de faire croître leur data warehouse en évitant
d’avoir à migrer vers une architecture à trois niveaux (3 tiers). Au bas de la figure, un entrepôt
de données étendu à toute l’entreprise est implémenté sur plusieurs serveurs séparés. Bien
entendu, les variantes possibles de ces trois suggestions sont nombreuses; dans tous les cas,
rappelez-vous que le nombre de serveurs peut augmenter de manière non négligeable.
Infrastructure des outils d’arrière-plan (back room)
Dans tout processus de sélection de plates-formes, la première étape consiste à bien assimiler
les besoins. Le simple fait de comprendre ce qu’une plate-forme doit faire et la façon dont elle
doit le faire du point de vue technique ne suffit pas. Il est essentiel de prendre aussi en compte
les besoins métier. Ce faisant, vous constaterez que le nombre de solutions à examiner se
réduit considérablement et vous pourrez comparer leurs coûts respectifs, ainsi que d’autres
facteurs, en vue de déterminer la meilleure. Dans presque tous les projets de data warehouse,
Test/
développement Plusieurs
data marts
Petit/début
Moyen/
deuxième
phase
Grand/
entreprise
Entrepôt et
préparation Serveur
d’applications Outils
du poste
de travail
Serveur
d’applications Outils
du poste
de travail
Serveur
d’applications
Outils
du poste
de travail
Serveur
d’applications
Outils
du poste
de travail
Préparation et
développement
Entrepôt de
données/
data mart
Zone de
préparation
des données
Data mart
de données
atomiques Plusieurs
data marts
Figure 11.1
Plates-formes matérielles correspondant à des entrepôts de données de tailles et de maturité variées.

Architecture
PARTIE 3
4
le serveur de la base de données est peut-être la décision la plus délicate en matière de matériel.
Voici quelques facteurs à évaluer pour choisir vos serveurs :
• Volumétrie . Le volume de données à gérer est déterminé par les préoccupations métier que
vous avez pour objectif de résoudre. Si la stratégie de l’entreprise est de développer des
relations client one-to-one, le niveau de détail des transactions devra être le client. La
plupart des projets d’entrepôt de données et de data marts se contentent de 200 gigaoctets
au départ. Souvent, ils sont même encore plus modestes et se mettent à croître au fur et à
mesure de l’accumulation des historiques, de la création d’agrégats et de l’apparition de
nouvelles sources de données. Toute configuration en deçà de 200 gigaoctets est facile à
administrer. Pour vous aider à vous y retrouver, nous qualifierons de petits les entrepôts de
données dont la capacité est inférieure à 100 gigaoctets, de moyens ceux allant de 100 à
500 gigaoctets et de grands ceux dépassant 500 gigaoctets.
• Volatilité . Elle mesure le dynamisme de la base de données via la fréquence des mises à
jour, le volume des données modifiées ou remplacées à chaque mise à jour et la taille de la
fenêtre de chargement. Encore une fois, les besoins métier fournissent de bonnes indica-
tions sur la volatilité. Bien évidemment, les données quotidiennes sont plus volatiles que
les données hebdomadaires ou mensuelles. Les réponses à ces questions ont une incidence
directe sur la taille et sur les performances de votre plate-forme matérielle.
• Nombre d’utilisateurs . Bien évidemment, le nombre d’utilisateurs, la fréquence selon
laquelle ils utilisent le data warehouse, le nombre de connexions simultanées et les pics
d’activité (fin de mois, par exemple) sont autant de facteurs importants dans la sélection
d’une plate-forme. Pour une entreprise digne de figurer au palmarès des 1 000 premières
dans Fortune , l’effort initial de data mart/data warehouse devra commencer par 25 à 50 utili-
sateurs actifs. Durant les dix-huit premiers mois, ce nombre passera à 100 ou 200; trois ans
plus tard, on comptera des milliers d’utilisateurs, notamment si l’entrepôt est utilisé à la fois
pour des requêtes ad hoc et pour créer des états standard ou presse-bouton dans une grande
entreprise. La répartition géographique des utilisateurs est également importante. S’ils sont
disséminés sur toute la planète, le système devra bien évidemment être disponible 24 heures
sur 24, ce qui a des conséquences sur le matériel. Dans un tel cas de figure, si les systèmes
opérationnels sont centralisés l’entrepôt de données devra probablement l’être également,
mais le matériel devra autoriser les chargements en parallèle ou «au compte-gouttes» pour
permettre une disponibilité constante. Si les systèmes opérationnels sont décentralisés, il
semble logique de décentraliser également les data marts.
• Nombre de processus métier . Le nombre de processus métier pris en charge par l’entrepôt
influe énormément sur sa complexité. Vous pouvez envisager une plate-forme matérielle
par processus si les utilisateurs sont suffisamment nombreux ou si l’activité le justifie.
Cependant, vous aurez peut-être également besoin d’un gros serveur centralisé si les
données consolidées sont indispensables aux dirigeants de l’entreprise et si les méthodes
middleware de consolidation virtuelle sont inadaptées à votre situation.
• Type d’utilisation . Le type d’utilisation et les outils frontaux sélectionnés ont également
une incidence sur le choix des plates-formes. En effet, une poignée d’«utilisateurs ad hoc »
peut peser lourdement sur les performances de l’entrepôt de données. Il est difficile d’opti-
miser un data warehouse pour ce type d’utilisation, car les bons analystes compulsent sans
cesse les données à la recherche de niches. Au contraire, un système presse-bouton essen-
tiellement destiné à produire des états standards peut être optimisé pour ce type
d’utilisation; toutefois, si vous avez l’intention d’en rester aux états standard, vous ne