Decideo - Actualités sur le Big Data, Business Intelligence, Data Science
Recherche avancée

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

Nous vivons une époque formidable. En revenant un peu sur l’histoire de l’informatique, on apprend que les capacités que cela soit de RAM, disque ou CPU sont de grands sponsors de la loi de Moore au sens commun du terme (« quelque chose » qui double tous les dix-huit mois). Ces efforts seraient vains si les prix ne suivaient pas le phénomène inverse (divisés par 200 000 en 30 ans pour le disque par exemple).



Big data, l’envers du décor

Evolution des architectures décisionnelles avec Big Data
Exposé comme cela, on se dit que nos envies ne peuvent connaitre de limite et qu’il suffit de changer la RAM, le disque ou le CPU pour prendre en charge l’explosion du volume de données à traiter qui globalement suit bien la loi de Moore aussi.

Figure 1 Evolutions hardware, 2011
Figure 1 Evolutions hardware, 2011
Alors où est le problème, qu’est qui fait que nos architectures décisionnelles aujourd’hui, non contentes de coûter de plus en plus chères, sont aussi en incapacité à se projeter sur des Tera ou des Peta de données. C’est bien simple, un vilain petit canard ne suit pas cette fameuse loi de Moore et il tire vers le bas tous ses petits camarades. Ce vilain petit canard c’est le « disk throughput », soit la capacité de débit des disques. En effet, quand la capacité de stockage des disques a augmenté de 100 000, le débit lui n’a augmenté de 100… Donc, en schématisant on peut stocker 100 000 fois plus d’information, par contre, ce stockage prendra 1000 fois plus de temps. Allo Houston, on a un problème…

Figure 2 Evolution du débit des disques durs, source : wikipedia
Figure 2 Evolution du débit des disques durs, source : wikipedia
Ce problème est aujourd’hui insoluble techniquement. C’est donc en réfléchissant au-delà du carcan des architectures traditionnelles que des acteurs (les grands du web notamment) ont trouvé des solutions. Si le débit des disques est le bottleneck de l’architecture, alors 2 possibilités de solutions sont offertes :
- Limiter au maximum l’utilisation des disques
- Paralléliser un maximum ce débit pour le rendre acceptable

Pour limiter l’utilisation du débit des disques, une première catégorie d’acteur mettait en place une stratégie dite « in memory » (qlikview, Hana…), pendant qu’une deuxième catégorie d’acteur qui s’attaquait à la parallélisation se lançait dans les architectures distribuées (avec Hadoop en fer de lance). Et c’est véritablement ces solutions qui amènent aujourd’hui les technologies nécessaires à l’avènement de ce qu’on appelle le Big Data.

Si on réalise une cartographie des solutions pour construire une architecture décisionnelle, on se retrouve avec le schéma suivant :

1 2 Suivant »





Commentaires

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

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.
http://twitter.com/Philacassaigne

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.
http://twitter.com/Philacassaigne

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
http://www.eozen.com

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.
Twitter
Rss
LinkedIn
Facebook
Apple Podcast
App Store
Google Play Store
 
Toute reproduction interdite.
Copyright © Decideo OÜ

Contact
     
Toute reproduction ou représentation intégrale ou partielle, par quelque procédé que ce soit, des pages publiées sur ce site, faite sans l'autorisation de l'éditeur est illicite et constitue une contrefaçon.