On a vu apparaître le terme de « big data » il y a quelques années. L’augmentation exponentielle des informations numériques fait apparaître des ensembles de données qui deviennent tellement volumineux qu’il est difficile (voire impossible) de le traiter avec des temps de réponses convenables via des outils traditionnels. Cela nécessite de repenser les bases mêmes du traitement de données.
Un seul chiffre déjà pour commencer : il est admis que tous les 12 à 18 mois, un volume de données double. Cela implique plusieurs enjeux stratégiques :
– conserver la performance des tâches de production qui sont nécessaires au bon fonctionnement de l’entreprise
– utiliser au mieux ces précieuses données pour en tirer les informations les plus fines possibles
– gérer au mieux le stockage et la sauvegarde de ces données.
C’est là qu’intervient la notion de « Big data », ainsi que les process et outils qui vont avec. Après les Data Warehouse (entrepôts de données), c’est une autre évolution majeure dans la façon de traiter, stocker et analyser les données. Mais là où les Data Warehouse ne se concentraient que sur le décisionnel, les solutions autour des « big data » permettent de gérer aussi des sollicitations de production.
Mise à jour du 22 février : la fédération anglaise de rugby vient de signer un partenariat avec IBM au sujet de l’utilisation de Big Data à des fins analytiques. L’objectif est de fournir des informations en temps réel aux supporters au sujet du match et des performances individuelles.
L’occasion d’ailleurs de commencer par un petit rappel sur les Data Warehouse.
Les Data Warehouse
Les outils d’aide à la décision peuvent souffrir des deux problèmes :
– ils brassent de nombreuses données, créent des informations qui n’existent pas directement en base (le chiffre d’affaire d’un mois donné pour un client donné par exemple n’existe pas en tant que tel et doit être calculé par l’agrégation d’un grand nombre de lignes de données) et du coup obtenir un tableau de bord ou un simple résultat peut être très long.
– si ces résultats sont demandés sur une base de production, ils peuvent impacter grandement le bon fonctionnement des tâches en sollicitant le serveur de base de données.
Fort de ces deux constatations, le principe d’entrepôt de données est né. Son principe :
– les données servant à l’analyse sont détachées de la production.
– elles sont constituées selon une structure de base différentes d’une base de production. Là où une base de production aura une structure qui respectera les règles de normalisation la base d’analyse devra répondre à une autre contrainte, celle de répondre le plus rapidement possible aux sollicitations.
Pour cela, les données vont être notamment mises à plat, pour limiter les jointures et que toutes les informations soient accessibles rapidement. On peut même imaginer un Data Warehouse avec une seule table. Certaines informations pourront être calculées au niveau de la ligne. Les données sont transférées, agrégées, remodelées et calculées de la base de production vers la base d’analyse au travers d’ETL comme Talend ou SSIS (de la suite SQL Server) par exemple.
Une fois dans l’entrepôt, les données peuvent être exploitées de plusieurs manières :
– au travers d’applications de reporting comme Reporting Services ou Crystal Report
– au travers de Cubes OLAP
– voire même pour des volumes raisonnables directement au travers d’un tableur et un tableau croisé dynamique, ou de requêtes SQL.
L’avantage du cube OLAP est qu’il va permettre pré-calculer des informations, de gérer finement le stockage de ces résultats de calculs, et ainsi d’accélérer la restitution des informations.
Big Data et NoSQL
Nous avons vu que nous pouvons résoudre les problématiques de volumes de données liées au décisionnel au travers des entrepôts de données. Mais si nos problèmes de volumétrie touche la production ? Ou si les volumes à traiter, même en décisionnel sont énormes ? Pensez aux informations que stockent par exemple Google ou Facebook. On est dans des volumes de données qui peuvent facilement donner le tournis, et là, on peut réellement parler de Big Data.
C’est là qu’à commencé à émerger la solution du NoSQL. NoSQL n’est pas à prendre forcément comme « not » SQL, mais plutôt « not only ». Il propose des solutions qui peuvent venir compléter les solutions des SGBDR classiques.
Revenons à notre base de données relationnelles. En plus des règles de normalisation, elle doit assurer l’atomicité, la cohérence, l’isolation et la durabilité (ACID) des transactions de données. Or, le théorème CAP précise qu’il est impossible à un système informatique de garantir en même temps la Cohérence, la Disponibilité et la Résistance au morcellement.
Partant de cette constatation, le principe du NoSQL est de se dire, quitte à ce que ça ne soit pas possible, autant trouver le meilleur compromis, et préférer la haute disponibilité et la scalabilité à la consistance.
Le NoSQL propose plusieurs formes de stockage de l’information :
– Clé/valeur. à la manière des tableaux associatifs des langages de programmation. A une clé correspond une valeur.
– Orienté colonne : à une clé correspond un ensemble de colonne, chacune ayant une valeur.
– document : à une clé correspond des ensembles champs/valeurs qui peuvent être hiérarchisés
– graphe : les données sont modélisées sous forme de noeuds qui ont des liaisons entre eux.
Sur la plupart des SGBD NoSQL, le modèle de données est flexible, on peut ajouter des champs à la volée. Voici un très bon tutoriel par exemple sur Cassandra qui donne un rapide aperçu de la structure et de la syntaxe :
http://www.stephane-raymond.com/blog/nosql/debuter-avec-cassandra-et-php/
Enfin, quand on parle de SGDB, il faut aussi penser au stockage, pour cela il existe des framework permettant d’optimiser cette partie. Dans le lot, on peut citer Hadoop, Framework Java basé sur l’algo Map/Reduce. Je vous renvoie pour plus de détails vers une présentation sur le même blog que précédemment : http://www.stephane-raymond.com/blog/bigdata/hadoop-hive-map-reduce-avec-php-part-1/
Quelles sont les solutions actuelles ?
Si vous voulez utiliser un SGBD NoSQL, il existe de nombreuses solutions disponibles. A noter que c’est un marché très jeune, avec peu de recul et de maturité. On peut citer parmi les plus connus :
– Cassandra : http://cassandra.apache.org/
– MongoDB : http://www.mongodb.org/
– SimpleDB : http://aws.amazon.com/fr/simpledb/
Mise à jour du 29 avril 2013 : un article comparant les différentes solutions de serveurs de bases NoSQL http://www.journaldunet.com/developpeur/outils/comparatif-des-bases-nosql/
Conclusion
Cela bouge pas mal dans le secteur du stockage et de l’analyse de données. Les perspectives sont intéressantes, car cela ouvre de nouvelles possibilités dans la façon de stocker et consulter les données. Il est fort probable que dans certaines situations, le NoSQL soient à l’avenir une très bonne solution. Mais ce secteur est encore jeune, les solutions sont nombreuses et il est possible que ce marché se rationalise dans un futur proche. Donc hormis pour l’intérêt pédagogique de la chose, ou si la structure de vos données vous poussent fortement vers le NoSQL, il peut être intéressant de garder un oeil sur le sujet mais de laisser décanter encore un peu.
Si vous avez des retours d’expériences sur le sujet, n’hésitez pas à ouvrir le débat dans les commentaires.
