Selon une récente étude d’IDC, le Big Data reste encore un terme flou pour 46% des responsables IT. Et pourtant, « ce mot qui fait partie des mots les plus confus de cette décennie » comme le dirait Philippe Nieuwbourg, est en train d’offrir le renouveau tant attendu par les professionnels du monde du décisionnel. En fait, les 3 V (volume, variété et vélocité) du Big Data vont (enfin !) pouvoir donner un nouveau souffle à la Business Intelligence. Ce n’est plus trahir un secret que d’affirmer que la Business Intelligence, dite traditionnelle, atteint ses limites : • Un datawarehouse de quelques téraoctets est très compliqué à maintenir et à faire évoluer. • Les données non-structurées n’ont jamais été abordées par la Business Intelligence – pensant que les données structurées étaient suffisantes pour la prise de décision – tel un nombrilisme méprisant. • La BI temps réel – grand paradigme de ces dernières années – n’a été atteinte qu’au prix d’architectures ultra-complexes, coûteuses et dont le retour sur investissement a toujours été contesté. Pourquoi remuer le couteau dans la plaie de la Business Intelligence aujourd’hui ? Pour au moins deux bonnes raisons : 1. Se limiter à quelques téraoctets dans l’entrepôt de données n’est aujourd’hui plus possible. L’accroissement de la volumétrie des données à analyser dans l’entreprise suit une loi dite exponentielle et il est urgent de traiter ce problème avant d’être complètement submergé. 2. Les données semi-structurées, voir non-structurées, sont de plus en plus présentes dans l’écosystème de l’entreprise (fichiers de logs, RSE, catalogue produits, blogs …) ; et les données externes à l’entreprise sont de plus en plus prisées (réseaux sociaux, articles de presse, vidéo …). En effet, il est impossible d’exploiter ses informations avec les techniques classiques de la Business Intelligence sans monter des architectures et des infrastructures extrêmement alambiquées et qui de plus ne cibleront qu’un seul type de besoin. […]

Le Renouveau ds Architectures Décisionnelles

Tous les professionnels de la Business Intelligence savent qu’une architecture type de données est constituée d’un ODS (Operational Data Storage), un DWH et des DataMarts. Ces strates de données ne sont pas obligatoires mais assez classiques et sont alimentées, en règle générale, par des techniques dites ETL (extraction, transformation et chargement – via un logiciel ou en programmation pure). Les puristes me diront qu’il manque la « Staging Area », cette couche de données qui n’est en fait qu’une copie des données sources. Quelle est donc la nouvelle architecture des données via le petit éléphant jaune qui supporterait le volume, les données non-structurées et la vélocité ?Voici un petit face à face entre les architectures de données de la BI classique et le framework Hadoop : • L’ODS serait Hadoop HDFS car il stocke les données brutes des différents systèmes. Certains diront qu’il s’agit là plus de la Staging Area, je ne suis pas vraiment convaincu car nous pouvons par exemple concaténer des fichiers sources disparates directement dans Hadoop HDFS. • La nouvelle génération d’ETL serait le framework Map/Reduce – les plus sceptiques diront que le fait de coder du java pour utiliser le framework Map/Reduce est une régression vu les interfaces des logiciels ETL actuels. Mais il n’en n’est rien ! Pig – ce logiciel faisant partie du monde Hadoop – permet justement cette abstraction Java et le langage de programmation de Pig est à la portée de n’importe quel informaticien. • Le datawarehouse serait Hive qui utilise directement le framework map/reduce pour toutes requêtes SQL d’alimentation et de sélection … Ce qui permet un temps de calcul extrêmement rapide lorsque l’on traite des hautes volumétries et ceci permet ainsi de disposer d’une architecture « quasi-temps réel » à moindre frais. • Pour les datamarts et les cubes multidimensionnels, nous avons l’embarras du choix au gré des circonstances. En effet, nous avons Hbase comme vu ci-dessus, mais il en existe plusieurs qui peuvent répondre à des besoins spécifiques. Citons par exemple Neo4j qui est une base NoSQL en graphes – idéale lorsque l’on souhaite exploiter et analyser des réseaux de liens (réseaux sociaux, ou encore réseaux de neurones …)- ou encore MongoDb qui est une base NoSQL documentaire – idéale pour le stockage de documents dans le cas où l’on souhaite exploiter ou analyser des articles web, des articles de presse…L’architecture décisionnelle se voit complètement transformée :
Read the full article.  

Keywords: