Decideo - Actualités sur le Big Data, Business Intelligence, Data Science, Data Mining

Abonnez-vous gratuitement à Decideo !


Decideo

 


Evolution des architectures décisionnelles avec Big Data


Rédigé par Joseph Glorieux, Octo Technology le 13 Août 2012



Trois classes d’architecture décisionnelle

Architecture décisionnelle « traditionnelle »
Catégorie de solutions : Oracle, SQL Server, MySQL, Informatica, Datastage, …
Figure 4 Architecture d’un système décisionnel « traditionnel », source OCTO 2012
Figure 4 Architecture d’un système décisionnel « traditionnel », source OCTO 2012

L’architecture décisionnelle « traditionnelle » fonctionne comme un pipeline d’alimentation par étages des systèmes opérationnels jusqu’aux datamarts. Chaque étage dispose de son modèle de données spécialisé optimisé pour sa mission, pour garantir des performances idéales à chaque étage.
Plus le volume de données manipulé par chacun des étages augmente, plus le système ETL doit être capable de fournir un débit important.
Cette architecture est performante lorsque le volume de données à transférer entre chaque étage reste limité, mais se transforme en voie de garage lorsque la taille des photos opérationnelles quotidienne augmente. Cela vient du fait que le système décisionnel va passer principalement son temps à transférer des données plutôt qu’à les traiter.
L’architecture décisionnelle « traditionnelle » est adaptée aux volumes de données stables et aux chaines d’industrialisation de production d’indicateurs stable dans le temps.

Architecture In Memory
Catégorie de solutions : Qlicview, ActivePivot, HANA, …
Figure 5 Architecture d’un système décisionnel In Memory, source OCTO 2012
Figure 5 Architecture d’un système décisionnel In Memory, source OCTO 2012

L’architecture d’un système In Memory repose sur la capacité à monter en RAM l’ensemble des données à analyser dans un système unique qui assure l’ensemble des fonctions décisionnelles.
Cette architecture In Memory a été rendue possible par l’évolution des capacités RAM des serveurs et la diminution sa diminution des coûts. Un serveur commodity hardware peut posséder très facilement jusqu’à 512 Go de RAM , en 2012.
Pour dépasser cette limite, deux types d’architecture In Memory ont émergée :
• Distribuée : les données sont partitionnées sur plusieurs machines de type commodity hardware
• Approche appliance : les données sont montées en mémoire sur des systèmes capables de supporter plusieurs To de RAM.
Les fichiers d’entrée sont conservés pour assurer le stockage persistant. Les disques SSD, dont la capacité peut atteindre 200 Go en version commodity (< 300 USD) , permettent de bénéficier d’un débit de chargement 10 fois supérieur à celui d’un disque dur HDD. Les données In Memory n’ont plus besoin d’être stockées.
L’architecture des processeurs multi-core permet de traiter un grand nombre de requêtes en parallèle sans la contention qu’on observerait avec les I/O des disques durs.
Cette architecture permet d’offrir des services d’analyses performants, même en temps réel (mise à jour des données et re-calcul au fil de l’eau des agrégats) et de simulation.

Architecture Massivement Parallèle
Catégorie de solutions : Hadoop,Teradata

Figure 6 Architecture massivement parallèle, source OCTO 2012
Figure 6 Architecture massivement parallèle, source OCTO 2012

L’architecture Massivement Parallèle repose sur la division du stockage et des traitements sur une grille de serveurs. Les données sont stockées par bloc et répliqués entre les serveurs et les traitements (script SQL et code de calculs) sont transférés sur les serveurs impliqués par le traitement. La donnée ne bouge pas d’un serveur à l’autre, c’est le code de traitement (d’un volume toujours très faible) qui se déplace. Ce principe s’appelle la colocalisation entre traitements et données.
L’architecture Massivement Parallèle permet de stocker une quantité de données immenses (sans limites) et de manière élastique. Plus la taille de la grille augmente, plus sa capacité de traitement augmente.
Hadoop est une solution Massivement Parallèle Open Source, conçue pour fonctionner sur du commodity hardware.
L’architecture massivement parallèle est idéale et nécessaire pour des systèmes qui vont dépasser la dizaine de 10 To et au-delà.
Elle permet également de mettre en œuvre des traitements particulièrement complexes (datamining & machine learning, simulation numérique, …)

Conclusion

L’évolution des technologies hardware (RAM, multi-core, SSD, parallel computing) et software (architecture distribuée) est en train de fondamentalement bouleverser le paysage des architectures décisionnelles et de datamining.
L’architecture décisionnelle « traditionnelle » avec sa base de données n’est plus l’unique architecture de référence. Il existe à présent 3 architectures de référence complémentaire à maitriser : base de données, In Memory et massivement parallèle. Ces 3 architectures continuent cependant à partager un facteur de taille, à savoir la qualité de données.
Si on s’intéresse enfin à la dimension humaine associée à ces changements, la mobilisation est à l’ordre du jour :
- Les équipes de production doivent à présent être capable de maitriser des infrastructures unitairement plus simples, mais de plus grande taille à base de commodity hardware ou du matériel spécifique (appliance).
- Les équipes de développement doivent comprendre comment utiliser la puissance du massivement In Memory et de la programmation parallèle, en se détachant progressivement des bases de données relationnelles.
- Les centres de compétences décisionnelles doivent pouvoir accompagner ces équipes à maitriser les évolutions profondes de la technologie, pour tirer profit au mieux de ces architectures et des réductions de coûts qu’elles offrent pour des systèmes de plus en plus puissants.

1 2





Commentaires

1.Posté par Casteres Romain le 13/08/2012 09:57
Twitter
Article très intéressant ! Merci

2.Posté par lacassaigne le 13/08/2012 11:46
Twitter
Principes d'Heisenberg et de Godel réunis, dès lors quand les volumes de données augmentent de manière exponentielle la pertinence de l'analyse décroit dans le temps.

Par ailleurs, on assiste à une véritable course à l'armement technologique que soulève cet article mais quid de l'effet de la reine rouge c'est à dire qu'il faut courir de plus en plus vite pour rester sur place, et que la notion de coût reste relative face à la raréfaction des ressources et des énergies terrestres.

Plus de capacités, n'implique donc pas plus de performance et de gains de productivité, et encore moins à terme baisse des coûts.

La solution est moins dans l'évolution technologique qu'un véritable changement de paradigme.

3.Posté par lacassaigne le 13/08/2012 15:39
Twitter
Puis, il y a une problématique qui me taraude aujourd'hui, celle de l'entropie dans les systèmes informatiques. Celle-ci croît inexorablement avec des effets de rééquilibrage. Toutes les avancées technologiques qui tendent à rendre résistant au désordre les composants d'un système informatique vont dans ce sens.

4.Posté par Michael ALBO le 22/08/2012 21:15
Vous analysez l'évolution des coûts du point de vue de la technologie qui supporte la BI (CPU, RAM, disque, réseau), ce qui donne une perspective exacte historique du sujet. Toutefois, le graphe vraiment intéressant serait l'évolution du coût d'une prise de décision en entreprise (donnée extrêmement subjective, j'en conviens). Compte tenu de la complexité croissante de nos environnements, je doute que ce coût soit décroissant. Je trouve que l'application de la théorie de la reine rouge à ce sujet par @lacassaigne est adéquate.
Posons le problème autrement : Quel est le retour sur investissement d'un euro supplémentaire investi en BI ? Une telle courbe ne serait pas linéaire, elle va d'abord monter très vite (les premiers euros seront très productifs) avant de se stabiliser puis de baisser rapidement. A partir du moment où un euro d'investissement supplémentaire produit un ROI inférieur à un euro, il faut investir dans la formation (ou le recrutement) des décideurs et plus dans les outils.

5.Posté par Arnaud MULLER le 11/09/2012 17:37
Bonjour et merci pour la qualité de cet article.

J'ai deux remarques sur l'évolution amorcée de l'architecture BI "traditionnelle" :

La première est qu'il n'y aura pas, à mon avis, besoin de choisir entre une architecture massivement parallèle et une architecture "In-memory".
SAP HANA et Oracle Hexalitix combinent déjà ces deux techniques qui convergent sur la finalité : lever les limites imposées par nos sacro-saints disques durs. Le "comment" est une réponse à base de données volatiles, structurées en colonnes, traitées en parallèle, etc.

La seconde concerne l'exploitation de ces techniques. Et là, je pense que les futures architectures BI apporteront une vraie réponse au besoin d'agilité dans la prise de décision. Comme évoqué dans l'article, les systèmes actuels se prêtent bien à des organisations dont les processus et besoins de reporting sont identifiés et constants. Le problème survient lorsque l'on veut rapprocher de nouvelles données, explorer des données issues de datamarts distincts, disposer de rapports sur l'activité de l'heure qui vient de s'écouler...

Arnaud Muller, Consultant BI, Eozen, Groupe SQLI

Nouveau commentaire :
Twitter

Vous pouvez commenter ou apporter un complément d’information à tous les articles de ce site. Les commentaires sont libres et ouverts à tous. Néanmoins, nous nous réservons le droit de supprimer, sans explication ni préavis, tout commentaire qui ne serait pas conforme à nos règles internes de fonctionnement, c'est-à-dire tout commentaire diffamatoire ou sans rapport avec le sujet de l’article. Par ailleurs, les commentaires anonymes sont systématiquement supprimés s’ils sont trop négatifs ou trop positifs. Ayez des opinions, partagez les avec les autres, mais assumez les ! Merci d’avance. Merci de noter également que les commentaires ne sont pas automatiquement envoyés aux rédacteurs de chaque article. Si vous souhaitez poser une question au rédacteur d'un article, contactez-le directement, n'utilisez pas les commentaires.