R en entreprise

Accueil > Big Data, qu’est ce que c’est ?

Big Data, qu’est ce que c’est ?

Vous êtes DSI et vous entendez partout parler de Big Data mais vous ne savez pas ce que cela peut vous apporter ? Cet article est pour vous.

Vous avez une base de donnée qui est trop grande pour un disque dur : il vous faut donc une base de données distribuée sur plusieurs machines (cluster) : on rentre dans le domaine du Big Data.

Des exemples de domaines d’application :

- les opérateurs télécoms (Orange/SFR/Bouygues), les entreprises avec des millions de clients et/ou des millions d’articles à vendre (Amazon / eBay). (Customer Analytics)

- détections de fraudes bancaires (analyse des comportements moyens et détections des comportements qui s’en écartent)

- webanalytics (analyser les logs d’accès des gros sites web), à des fins de marketing généralement

- génétiques/biotech (ADN, millions de gènes, microarray data)

- les grandes expériences scientifique. Le CERN (accélérateur de particules à Genève, qui a permis la découverte du boson de Higgs) collecte 15 millions de Terraoctets par an ...

- réseaux sociaux avec des centaines de millions d’utilisateurs (twitter, linkedin, facebook)

- les moteurs de recherches (google, yahoo) : classifier les pages/calculer les page rank et les crawlers de pages web : trouver/analyser des informations sur des millions de pages

- données high frequency en finance de marché

En terme de taille, les bases de données BigData sont trop grosses pour tenir sur un disque dur : elles sont supérieures à 2 TerraOctets.

La problématique qui se pose immédiatement lorsque on souhaite passer à une base de données distribuée est l’impossibilité de faire des jointures entre des tables, comme dans les SGBDR classiques (SQL).

Les informations ne sont plus stockées selon un schéma relationnel classique (tables, primary key/foreign key) mais sous sous forme d’un modèle document (Document Model).

Au lieu d’avoir une table "Client" avec une table "Adresse" et une foreign key de "Adresse" vers "Client" (Un client peut avoir plusieurs adresses), dans le modèle document on aura des enregistrements de clients avec leurs adresses directement stockées. Il n’y a plus de tables, mais seulement des enregistrements clefs (id du client) / valeurs (ses attributs, et ses adresses).

On parle de technologies NoSQL (qui veut dire Not Only SQL) pour décrire ce nouveau paradigme de stockage des informations.

Le stockage des informations étant différent, il faut donc un moyen de traiter les données différent : On ne programme plus des requêtes SQL, mais on utilise des méthodes de traitements différents.

Il y a alors deux grands cas d’utilisation :

- une base de données de stockage pur : vous y accéder comme une bibliothèque : "donne moi le livre numéro 2156, donne moi le livre avec ce titre précis". Ce cas-là est simple à résoudre : il ne nécessite pas de traitement, et il ne nécessite peu de transfert d’information de la base de donnée vers le centre de traitement : vous ne récupérer que quelques livres parmi la bibliothèque gigantesque.

(- Les cas intermédiaires : les indexations des pages web par les moteurs de recherches, ou les fonctions de recherches sur des bases de données distribuées (Kademlia/eMule). Tous les traitements sont faits au moment de l’indexation. C’est l’index qui est difficile à produire, pas la recherche en elle-même.)

- une base de données sur laquelle vous aller faire des vrais calculs non prévus. Exemple : quelle est la fréquence par année de l’utilisation du mot "ordinateur" dans toute ma bibliothèque depuis 1920. Cette fois, c’est très différent : il va falloir récupérer tous les livres écrits après 1920, les lire entièrement, compter les apparations du mot "ordinateur", puis faire la somme par année. On comprend bien que si on a une seule machine pour faire le calcul, il va falloir que cette machine interroge tous les serveurs de la base de données, récupère tous les livres séquentiellement un par un, compte les mots, etc. Toute la bibliothèque va transiter par le réseau informatique pour avoir la réponse, et une seule machine va s’occuper de tour le calcul : ca va être TRES lent. D’où l’apparition de nouvelles technologies de traitements :

Map Reduce, Hive, Pig Latin

Puisque la base de données est distribuée, il serait intéressant d’avoir également la possibilité de distribuer les calculs. Et évidemment, il serait bien que les calculs concernant telles données particulières s’effectuent sur l’ordinateur qui contient cette donnée : l’avantage est qu’il n’y a pas besoin de faire transiter l’information sur le réseau => gain de temps considérable.

Inconvénient : il va falloir tout programmer avec ces nouveaux langages (Map / Reduce, et ses couches supérieures : Hive, Pig Latin).

En terme de technologies de bases de données distribuées et de paquets R correspondants, nous avons :

- Pour Hadoop/HDFS : les paquets R correspondants : Rmr, Rhadoop

- MongoDB (document store, orienté JSON) : RmongoDB

- CouchDB (document store) : R4CouchDB, projet inactif

- Cassandra (key-value) : RCassandra

- HBASE (key-value) : Rhbase

- Redis (key-value) : rredis

- Neo4j : base de données de type graph (REST API pour y accéder sous R), utile si vos données sont des relations.

Remarque : ces bases de données tournent en général sous Linux.

Le choix d’une base dépend de vos types de données (clef-valeur, modèle document ou données de type graph) et de l’utilisation qui en est fait (temps réel ? réplication ? tolérant aux pannes ? )

Une comparaison avec Google Trend

JPEG -

Voir aussi une comparaison de ces bases de données NoSQL

Voir aussi l’article sur R et le calcul parallèle

Y a t’il un rapport avec les autres buzzwords du moment ?

- Cloud computing, Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).
=> Pas de rapport direct. Cela dit, installer un cluster pour une base de données distribuée à un coût (machine/maintenance...). A voir si vous pourriez l’héberger chez un organisme fournissant des services de cloud.

- Scalabilité : les bases de données distribuée NoSQL sont par nature scalable : si vous êtes inquiet des temps de réponses de votre système d’information, les bases NoSQL peuvent être la solution

- Virtualisation (Vmware...) : pas de rapport. Au contraire, il ne semble pas à priori intéressant de faire un cluster de base de données NoSQL "virtuel", ca serait accumuler une couche qui ne peut que dégrader les performances.

Est-ce que j’en ai besoin ?

Si vous ne savez pas, c’est probablement que vous n’en avez pas besoin...aujourd’hui.
Mais exploitez vous à fond vos bases de données clients ? vos logs de connexions ? Les équipes marketing sont elles au courant des analyses statistiques possibles sur ces données ?

Je souhaite migrer ma base relationnelle trop grosse vers une base de données distribuée (Big Data/NoSQL)

Dans l’immense majorité des cas, il ne s’agit pas de tout migrer. Votre base de données relationnelles (Oracle, SQL server, SYBASE) contient deux types de tables :

- les tables de références (référentiel, tables de statuts, table code/libellé) de quelques enregistrements ("quelques" au sens de "moins de 100000")

- les "grosses" tables : enregistrements liés à l’activité, au business, qui grossissent avec le temps : factures, bons de commandes, logs de connexions des clients, etc. Elles ont en général une dimension temporelle (il y a une colonne "date" dans la table).

Il "suffira" donc de migrer les "grosses tables" vers une base de données distribuées et de garder une petite base SQL classique pour les tables de références.