Pour vos lectures sur la plage cet été, Gartner vient de publier son fameux « hype cycle ».

Pour rappel il s’agit d’un graphique sur la maturité des nouvelles technologies. Les technologies émergentes sont à gauche, et celles qui sont adoptées par le public à droite. Et disparaissent une fois entrées dans les moeurs. Autre information intéressante, la couleur du point sur la courbe indique le temps estimé pour arriver au côté droit.

Les grandes tendances (Big Data, In Memory, Internet des objets, NLP/Langage Naturel) se confirment. Néanmoins on peut attendre encore quelques années (10 ans en étant pessimistes) avant qu’elles ne soient généralisées …

Enfin, Oracle sort une option « InMemory » pour fournir une base vectorielle digne de ce nom à sa base transactionnelle classique.

Comment ça marche ?

On garde le stockage en ligne classique et on apporte une couche supplémentaire de stockage en colonnes et en mémoire. En fonction de la requête SQL qui est exécutée, le moteur Oracle va chercher les données sur le stockage classique en lignes ou en mémoire dans un stockage en colonnes.
Ce stockage en mémoire et colonnes rappelle celui de solutions déjà existantes, comme Qlikview, Microsoft PowerPivot, SAP HANA et bien d’autres.
Comme la mémoire est limitée seules certaines tables seront montées en mémoire. C’est au DBA ou à l’architecte/concepteur BI de sélectionner les tables candidates. A priori on peut aussi ne choisir que certaines partitions.

Le résultat

Les requêtes sont bien plus rapides sur des volumétries importantes, ce qui n’est pas étonnant quand on compare avec les solutions similaires.
Mais les requêtes transactionnelles gagnent aussi en rapidité ! En effet certains index ne sont plus d’utilité et sont donc supprimés (a priori les index bitmap).

Les contraintes

• C’est une option, ce n’est donc pas gratuit. Mais comme pour le partitionnement c’est une option obligatoire pour une base décisionnelle.
• Il faut une base en 12c, donc il est probable qu’il faudra monter de version les bases existantes …

Le reste de la famille

Exalytics est une appliance qui jouait le rôle de cette couche inmemory pour analyser les données rapidement. Le packaging est différent, mais ça fait doublon.
Cela signe aussi la fin des cubes Oracle (Essbase ou OLAP) si le temps de réponse est satisfaisant avec le inmemory.

Pour les autres (TimesTen, Big Data) le terrain de jeu n’est pas le même.

Et le reste du monde

SAP HANA est clairement visée. Il est vrai que SAP vend sa base comme LA base pour l’analytique et le transactionnel, et marchait sur les plate-bandes d’Oracle.
Ce dernier a vite mis en ligne un comparatif entre les deux bases de données, à son avantage évidemment.
SAP a vite rétorqué en commentant directement dans le document incriminé.

Loin de cette querelle fratricide on retiendra juste que :

• Oracle 12c inmemory n’est pas une base gérée totalement en mémoire comme HANA, c’est plus ce qu’on appellera « un cache » pour l’analytique.
• HANA n’est disponible que sur appliance ou cloud, ce qui est normal car il faut un matériel de compétition pour la faire tourner. Ce n’est pas le cas d’Oracle.

Les deux bases sont bien différentes, le choix va être difficile …

Oui mais …

L’idée est intéressante sur le papier. On bénéficie des deux modes de stockage, les applications transactionnelles et analytiques cohabitent sans problème. On peut récupérer instantanément tout un enregistrement en ligne pour une application transactionnelle, et on pourra calculer des agrégats complexes sur des volumétries importantes en un clin d’oeil.
L’application idéale semble le reporting opérationnel en temps réel, soit des états qui attaquent directement une base transactionnelle de production avec un temps de réponse instantané.

Pourtant quand on connait les bases en colonnes existantes, on sait qu’il existe un goulot d’étranglement quand on ajoute ou modifie une seule ligne. Or c’est ce qui se passe tout le temps sur une base transactionnelle classique. Alors comment va réagir la base Oracle inmemory ? Y a-t-il un temps de latence pour prendre en compte ces ajouts/modifications de ligne ? A-t-on vraiment du temps réel ?

Néanmoins il faut avouer que c’est une excellente pour le monde BI, les bases Oracle étant bien implantées dans notre univers.

cf l’actu oracle sur developpez

Alors commençons par voir l’Hana-tomie de la bête …

Hana est une base de données de SAP ultra-performante, dopée aux Hana-bolisants comme :

• la gestion des données en mémoire (in-memory pour la traduction geek), qui comme tout le monde sait est beaucoup plus rapide que les disques durs (qui le sont un peu) ;
• le stockage en colonnes, avec un petit coup de compression pour optimiser tout ça ;
• le parallélisme jusqu’à la colonne (ça me donne froid dans le dos) ;
• le partitionnement pour découper tout ça au mieux (comme des Hana-nas) ;
• livrée en appliance (ie une machine livrée clé en main avec tous les logiciels déjà installés dessus), histoire d’avoir le hardware le plus adapté.

Par Hana-logie elle ressemble à Sybase IQ pour le stockage des données en colonnes et à Qlikview pour le côté in-memory. Mais halte à l’Hana-rchie architecturale, contrairement à ses concurrents Hana sait gérer du décisionnel (OLAP) et du transactionnel (OLTP) ; mettre de l’Hana dans un système opérationnel ne relève pas de l’Hana-chronisme et ça c’est fort !

Les résultats

Oubliez vos Hana-lgésiques, surtout si vous êtes sur BW (le Datawarehouse à la sauce SAP), Hana décoiffe !
Bénéficiant d’un moteur OLAP optimisé les performances sont sidérantes. C’est comme passer d’une télé 4/3 à 16/9, les données sont Hana-morphosées !
Paradoxalement la compression et le partitionnement ne plairont pas forcément aux pro-Hana qui pourront ingurgiter des milliards de lignes en quelques secondes.

Les critiques

S’il fallait lui lancer un Hana-thème on pourrait donner le prix de la licence, qui est un peu cher si c’est juste pour faire du datamart. On lui trouve aussi des aspects très homo-sapiens (plus du côté des R/3 que des erectus) comme la gestion de sessions/mandants, des RDS et des réplications sur les DD02, ce qui peut conférer des effets Hana-phrodisiaques à certains.

Et une petite Hana-phore pour la fin

Hana est une base Next-Gen, qui va vite, très vite.
Vite en restitution des données.
Vite en traitement des données.
Vite en Hana-lyse des données.
Vite en évolutions.
Vite pour remplacer les Bases de données classiques dans tous les environnements SAP (après Hana sur BW bientôt Hana sur R/3 !).
Bref, Hana est la base à suivre du moment.

Après le « cloud » c’est le nouveau terme à la mode, qu’on voit partout mais que personne ne semble connaître vraiment …

Voici une petite définition que j’ai essayé de faire la plus simple possible.

Comme on peut le deviner (si on a quelques notions d’anglais) la notion de Big Data représente une volumétrie très importante de données. Contrairement à la BI classique il s’agit de stocker et d’analyser toutes (mais vraiment toutes) les données de l’entreprise et même celles de l’extérieur, et notamment des blogs, des forums et des réseaux sociaux.

Quand on parle de données de l’entreprise savez-vous que seulement 10% des données sont stockées en base (le reste étant les documents, les mails, les logs … tout le reste de la production IT quoi) ? C’est là la limite de la BI classique : Elle ne traite que les données des bases classiques et 90% des données restantes ne sont pas exploitées. C’est un comble quand on y pense !

Le défi des Big Data c’est de pouvoir stocker ces 90% des données et de les analyser. Et c’est là aussi un challenge important des Big Data : On a beau avoir une volumétrie colossalle de données, il faut pouvoir les traiter vite, et même très vite, voire en temps réel.

Mais la plupart de ces nouvelles données sont ce qu’on appelle des données non structurées. Sous ce terme un peu complexe voire pompeux se cache en fait un concept très simple. En modélisation on a l’habitude de structurer les données, par exemple on va faire une table Ventes avec plusieurs infos que le concepteur connait à l’avance. Si on veut le chiffre d’affaires des ventes d’un produit on prendra la colonne « chiffre d’affaire » en filtrant sur une autre colonne « produit ». En gros les données sont rangées dans des cases, prêtes à l’emploi – elles sont dites structurées. Dans les documents et dans les messages qu’on trouve sur les sites webs on trouve généralement des phrases qui sont composées de mots ordonnés suivant l’envie et la culture de l’auteur. Ces données sont dites non structurées car on ne connait pas le contenu qui serait défini comme aléatoire pour un ordinateur, il faut une réflexion humaine pour déchiffrer la donnée et pouvoir en extraire des informations. Par exemple les phrases « Julie va passer le weekend à Paris, elle en a de la chance ! » et « A la fin de la semaine la miss va s’éclater à paname » sont compréhensibles et similaires pour nous alors que l’ordinateur ne sait les analyser et les comparer simplement. Pourtant en information on pourrait en déduire plusieurs axes d’analyse : une personne (Julie), un temps (samedi/dimanche qui arrivent), un lieu (Paris) et un fait (présence et une opinion satisfaisante).

Les Big Data révolutionnent la BI en stockant ces données non structurées et en remettant au goût du jour l’analyse sémantique. Cette dernière va permettre d’analyser un nombre important de données et d’en tirer des informations comme les opinions, avec des modules de datamining.

C’est pourquoi on définit généralement les Big Data par les 3 V : VVV = Volume x Vitesse x Variété (volumétrie importante de données hétérogènes traitée très rapidement).

La recette du Big Data

Pour faire du Big Data c’est simple. Il vous faut ;

• quelques Tera de base NoSQL (soit une grosse base qui n’est pas relationnelle comme celles qu’on connait mais qui peut tout stocker, même l’univers diront certains)
• quelques CPU de framework MapReduce (soit un traitement ultra rapide un peu comme ce que fait Google quand il indexe ses pages … Ah bin justement ils utilisent un tel framework, ça tombe bien)
• quelques Mo d’outils pour restituer les données (un peu classiques avec les bons connecteurs)
• quelques Mo d’outils pour analyser les données (si on veut faire un peu d’analyse sémantique)

Certains challengers sortent du lot, principalement en opensource comme :

• HBase, Cassandra pour les bases NoSQL
• Hadoop en framework MapReduce (adopté partout, même par les plus grands éditeurs)

Les technos citées ci-dessus sont matures et viennent des grands acteurs du web (Google, Yahoo!, etc).
En ce qui concerne la BI « pure » les éditeurs s’y mettent et nous promettent un futur resplendissant pour les Big Data.

Sans jeu de mots il est difficile de résumer les Big Data en quelques lignes, le sujet est vaste !

Quelques liens pour ceux qui voudraient aller plus loin :

• http://en.wikipedia.org/wiki/Big_data : la définition sur wikipedia
• http://www.decideo.fr/bigdata/ : le blog de Philippe Nieuwbourg qui écrit un livre sur le sujet
• http://bigdataparis.com/compte-rendu.php : les slides de la conférence Big Data Paris du 20 et 21 mars
• http://www.kimballgroup.com/html/articles.html : The Evolving Role of the Enterprise Data Warehouse in the Era of
  Big Data Analytics, un article de Ralph Kimball très complet sur le sujet

Pour ma part je connaissais les Treemap via Windirstat, un petit outil gratuit pour visualiser l’espace occupé d’un disque ( http://windirstat.info/ ). Outil que je vous recommande chaudement, bien pratique pour traquer les fichiers perdus dans un coin et faire le ménage sur son disque dur :p

C’est vrai que cette vision est bien plus représentative qu’un camembert ou qu’un graphique en barres ( comme l’outil treesize ). Une fois qu’on y a goûté on se demande comment on a pu passer à côté depuis tant d’années.

Espérons que d’autres éditeurs adoptent aussi ce type de graphique dans leurs solutions.

Alors, quel est le rapport entre GPU et la BI me direz-vous ?

Et bien le GPU ne sert pas qu’à afficher de jolies scènes en 3D, et les fabricants comme nVidia ou AMD offrent la puissance de calcul du GPU aux développeurs. Ainsi de nombreuses applications permettent d’encoder des vidéos plus rapidement via le GPU comme Nero Move It ou Cyberlink MediaShow Espresso. Un article sur Clubic explique très bien l’intérêt des GPU et on en parle aussi sur developpez.

En résumé le GPU est bien plus performant dans les calculs simples sur de grosses volumétries comme en 3D …
Et là on comprend mieux l’intérêt de l’utiliser pour la BI où les données se comptent en Téra !

C’est du côté de l’opensource que les éditeurs se sont lancé avec Jedox et PALO 3.2 qui offre un serveur OLAP de bonne facture. Optimisé avec des cartes nVidia le gain annoncé est important : de 20 à 30 fois … Mais comme d’habitude il faudra attendre un certain temps avant de connaître les performances réelles.

Deux bémols à propos de cette solution :
– la solution est propre à un seul constructeur, en l’occurence nVidia
– les GPU sont du côté serveur et non du côté client. Donc pas de partie du dernier Call Of Duty au boulot :p