Un moteur de base de données comme SQL Server offre une telle souplesse d’emploi et de montée en charge qu’il est possible d’imaginer et mettre en œuvre des solutions techniques très variées et adaptées à chaque besoin.
Bien des DSI et des architectes impliqués dans un projet décisionnel ont une fâcheuse tendance à vouloir faire entrer très tôt dans le processus de réflexion les choix d’architecture matérielle et statuer sur l’opportunité ou non de partir sur des Appliances. Pourtant, cette décision est plutôt l’une des dernières étapes du processus de décision du projet Data Warehouse. Avant d’en arriver à ce stade, il est impératif d’avoir franchi d’autres étapes nécessaires à la découverte des éléments qui permettront de statuer judicieusement sur vos choix d’architectures.
I – La phase préliminaire
Tout projet Data Warehouse doit commencer par une phase d’apprentissage et d’élaboration sur la méthodologie que l’on va utiliser, sur le jargon que l’on va employer et sur la conduite de projet que l’on va adopter.
II – La conception et le design du modèle de données
on débute par une phase de mise en place d’un dictionnaire de métadonnées qui va permettre non seulement de mettre tout le monde d’accord, mais aussi de statuer sur les types d’informations et sur ce que l’on veut analyser. Puis, on va construire une modélisation décisionnelle de cette information qui peut être à la fois à plat (avec des modèles en 3ème forme normale, en étoile ou en flocon) ou multidimensionnelle (avec des cubes OLAP), les deux approches étant bien plus complémentaires qu’antinomiques.
III – On va ensuite s’intéresser à la façon dont on va charger les données
techniques de capture des données (fonction change data capture de SQL Server), outils ETL de transformation, processus d’acquisition, outils de réplication, connecteurs disponibles, etc.
IV – Concevoir le système de stockage du Data Warehouse
c’est lors de cette phase que l’on va prendre en compte les notions de Performance et de Qualité de service (aussi bien en termes de stabilité que de capacité de montée en charge). On doit notamment évaluer comment la performance doit évoluer avec l’augmentation de la volumétrie d’une part (comment on passe de 5 To à 10 ou 15 To par exemple) et avec l’augmentation d’un nombre d’utilisateurs (comment la performance serveur évolue si on passe de 1000 à 3000 utilisateurs). C’est à ce moment que l’on va définir l’architecture matérielle.
V – La restitution
il s’agit là de savoir comment les services et informations fournis par le Data Warehouse vont être exploités et présentés aux utilisateurs au travers des outils internes de l’entreprise, des outils de reporting et reporting ad-hoc et au travers des suites Office ou des portails (SharePoint par exemple).
|
Attention au processus initial d’alimentation
C’est une étape extrêmement importante qu’il ne faut pas négliger et qu’il faut surtout savoir anticiper. Bertrand Audras explique ainsi qu’ « il faut bien avoir conscience qu’on parle d’un volume de données important voire très important. On est forcément face à de grands traitements automatiques qui ont un impact très fort en termes de volumétrie, de temps de traitements, de bande passante réseau et I/O, et de disponibilité des sources ». Une phase et un impact qui sont souvent mal anticipés dans bien des projets Data Warehouse. « Il faut savoir anticiper les phases d’alimentation totale initiale très tôt dans le processus de développement pour ne pas se faire surprendre par des délais incroyablement plus longs que ce qu’on avait imaginé. Pour cela il faut prendre très tôt (dès la phase de réflexion sur la capture des sources) des exports complets d’un système puis récupérer régulièrement des deltas afin de pouvoir le faire le jour J en toute sécurité. Sinon on risque de se retrouver avec une phase d’alimentation du Data Warehouse très lourde pour les systèmes ERP et de production qui risque de fortement impacter la qualité de service de ces applications critiques pour l’entreprise ». |
Téléchargez cette ressource
Comment lutter contre le Phishing ?
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.
Data - Par
Loïc Duval - Publié le 13 juillet 2011
