Nous avons dans notre précédent article expliqué les raisons substantielles de l’existence du Big Data. Pour gérer une masse phénoménale de données, il a fallu imaginer et architecturer le stockage différemment ; changer de cadre de penser, de paradigme, faire en sorte que les données soient toujours disponibles et facilement accessibles tout en garantissant un temps de réponse quasi constant, indépendamment de la croissance des utilisateurs et de leurs requêtes (montée en charge).
Les objectifs…
Les apports techniques du Big Data visaient conceptuellement deux typologies d’objectifs. Première typologie, permettre à des données brutes d'être sauvegardées en grande quantité et de façon suffisamment répartie pour être récupérées ; d’une part de n'importe où sur la planète, d’autre part par un nombre toujours grandissant d'utilisateurs. Images, vidéos, pages HTML, JavaScript, fichiers divers et variés se devaient d'être accessibles en parallèle au plus grand nombre tout en supportant la perte éventuelle de disques durs, serveurs ou de salles entières de stockage et ce, sans le moindre impact visible pour l'utilisateur.
Objectivement, d'autres technologies réalisaient déjà ce type de prouesses. Mélangeant des techniques de clustering, load-balancing ou de prémisses de Content Distribution Network (comme les solutions Akamaï), mais avec le sombre inconvénient de coûts très élevés, notamment au niveau matériel, pour assumer la charge. La révolution Big Data a été de s’appuyer sur un grand nombre de machines commodity (grosso modo des machines serveurs classiques) plutôt que sur des infrastructures gigantesques et hors de prix.
La solution Big Data la plus connue et la plus usitée dans ce domaine ; que votre entreprise possède peut-être déjà ; se nomme Hadoop. Opensource, créée par la fondation Apache, elle s'est inspirée d'une publication de Google sur son propre système de fichiers distribué GoogleFS. Nous étudierons prochainement Hadoop et ses implémentations Hortonworks, MapR,Cloudera dont certaines payantes; ainsi que la pléthore d'outils qui gravitent autour de lui.
Seconde typologie d’objectifs, faire en sorte que des informations et leurs relations puissent persister et être réutilisés à très grande échelle, notamment planétaire, tout en résistant bien évidemment aux pannes. Il s’agit par exemple des cas d’utilisation des réseaux sociaux : gestion des comptes et relations inter-utilisateurs, sauvegardes des messages et autres publications, sauvegardes des médias (cette partie pouvant d’ailleurs être redirigée vers de l'Hadoop), gestion des favoris et autres boutons like. Il s’agit également des cas d’utilisation des moteurs de recherche comme Google : stockage des métadata sur des sites web (en clair, des informations relatives aux sites comme l'adresse, description, langue, nombre de mots, et titre des pages, etc.), indexation du contenu et restitution des recherches par mots clés (ceci pouvant se faire par une technologie dénommée MapReduce, également très utilisée dans Hadoop. Nous y reviendrons.)
Contrairement à la première typologie, ce ne sont pas des fichiers bruts qui sont stockés. Ce qui intéresse ici est le véritable contenu et sens de l’information. Cette dernière est modélisée et physiquement représentée sous forme de groupements de données, avec d’éventuels liens vers d’autres ensembles de données. En informatique un terme technique, et bien connu de tous, existe depuis fort longtemps pour ce genre de stockage ; il s’agit des bases de données. Auxquelles s’ajoute ici, et à juste titre compte tenu de la volumétrie des informations gérées, le qualificatif Big Data.
Autrement dit, il existe des « bases de données Big Data» ; mieux, il y a pléthore de solutions et produits. Chacun avec ses spécificités, forces et limites ; lesquelles correspondent aux façons d’appréhender les problématiques liées à une base à très haute capacité. Il y a par exemple les bases orientées colonnes comme Cassandra (Apple possède un déploiement gigantesque de plus de 75 000 noeuds gérant plus de 10 pétaoctets de données) et Hbase (utilisé par Facebook). Ces deux bases se sont inspirées d’une publication de Google sur sa propre base de données distribuée énommée BigTable ainsi que sur les principes "Dynamo" d'Amazon. Il y a également la célèbre base de données MongoDB, orientée document, tout comme CouchDB, CouchBase ou DocumentDB de Microsoft. Il y a également Riak, Accumulo, Redis ou Voldemort de LinkedIn orientés clé-valeur. Sans oubliez les bases en format graphe Big Data comme Neo4J ou TitanDB, etc.
Nous expliquerons bien évidemment toutes ces différences dans les articles à suivre sachant que les gros acteurs comme Oracle, SAP, IBM et Microsoft ont des solutions approchantes (SAP Hana, Microsoft APS, IBM Watson Foundations, etc), qu'il y a d'autres problématiques comme les recherches textuelles (ElasticSearch, SolR...), l'analytique, le datawarehouse, le machine learning et datascience, mais chaque chose en son temps. Commençons par la base.
Comprenons le fonctionnement du Big Data…
Pour gérer des fichiers répartis et redondés sur plusieurs machines ; cas de la première typologie d’objectif; il fallait pouvoir imaginer une solution se comportant comme un immense disque dur où l'information est accessible en simultanée aux quatre coins de la planète sans jamais être perdue et toujours récupérable même en cas de crash. L'astuce utilisée est de découper chaque fichier en plusieurs morceaux (chunks), de dupliquer ces dits morceaux, puis de les répartir sur plusieurs ordinateurs (Pour les techniciens, on peut véritablement imaginer cela comme la volonté de faire sur plusieurs machines une sorte de JBOD et un RAID 1 sur les chunks). Les fichiers sont ainsi vus comme un ensemble de « morceaux » existant en parallèle à grande échelle à plusieurs endroits judicieusement répartis sur plusieurs machines ; avec de nombreux chemins pour les recomposer. Si des machines tombent en panne, aucun problème puisque d’autres machines travaillent déjà à recomposer les fichiers, il suffit juste de changer la route. Pourquoi découper vos fichiers en morceaux ? Pour faire exactement ce qui se passe à bas niveau sur vos disques durs. Les fichiers ayant des tailles très différentes, il faut s’assurer de ne jamais perdre de la place lorsqu’on les supprime et en ajoute des nouveaux. Raisonner par bloc de données s’avère extrêmement pratique, car cela revient à fonctionner comme avec un empilement de légos que l’on peut récupérer de multiples façons.
Concernant les bases de données ; cas de la seconde typologie ; les critères discriminants pour être qualifiés de Big Data sont l’aspect massivement parallèle des accès ainsi qu’une résistance forte aux pannes. Là aussi, pas de magie, l’architecture repose sur une duplication à outrance des données et une minimisation forte des contraintes transactionnelles que les bases de données classiques, entendez par là relationnelles, adressent. C’est donc bien la façon d’imaginer, structurer et architecturer différemment la logique de stockage pour permettre un accès en masse qui crée l’aspect « Big Data » d’une base. Se faisant, on perd de facto des caractéristiques mécaniques fortes intéressantes des bases de données classiques ; mais on en gagne également d’autres, comme le NoSQL et le« schema-less ». Quelques mots là-dessus dans quelques instants, mais creusons encore plus à la substance du Big Data pour en connaître les tenants et aboutissants.
Quelles sont les caractéristiques intrinsèques à toute solution Big Data ?
Que ce soit du BigData type Hadoop ou base de données (MongoDB, Cassandra, etc), le secret ultime pour la performance est l'acceptation d'une latence dans la recopie d'information. Cette latence est logique puisqu’il faut copier l’information à travers les réseaux. Et si cela peut sembler neutre à dire, c’est en réalité très impactant : cette latence se traduit par le fait de ne pas avoir immédiatement à jour toutes les machines de la planète. Si vous comprenez ceci, vous comprenez la fondation de l'édifice Big Data. Vouloir des données cohérentes en même temps revient à tout ralentir pour mettre à jour ou lire vos données ; ce que fait une base classique.
On gagne en haute disponibilité (HA ou High Availability), car le système se présente robuste, toujours up, capable de répondre avec une capacité incroyable de traiter des requêtes concomitantes. L'information est disponible à l'échelle de la planète, sur différents nœuds (le noeud est un ou plusieurs process sur un ou plusieurs machines physiques ou VM) dans différents datacenter (grosso modo lieux où l'on entrepose ses machines pour gérer une zone géographique. Cela se fait généralement grâce à des fournisseurs de service ou bien dans le Cloud). Il a des fonctionnalités extraordinaire comme la possibilité d'adjoindre de nouveaux nœuds, nouveaux datacenter, voire les deux à chaud si le besoin se fait sentir. On obtient ainsi une solution évolutive capable de gérer de une montée en charge (scalabilité) incroyable sur un haut volume de données. Ce qui explique les usages pour Facebook, Twitter, LinkedIn,etc. Mais gardez bien en tête, l’inconvénient de taille : l'information n'est pas obligatoirement à jour ! (Le mot obligatoirement a toutefois ici son importance. Il indique bien qu’il s’agit de réglages que l’on peut changer. On peut tout forcer à être à jour mais le comportement n’est alors plus celui attendu du Big Data).
En plus de la haute disponibilité, le Big Data est structurellement conçu pour apporter des fonctionnalités de résistance aux pannes (FT ou Fault). L'information étant dupliquée, on peut supporter la perte de plusieurs serveurs voire de datacenters entiers en fonction de la configuration (sachant que HA et FT vont au-delà de la simple redondance). Que l'on soit clair, HA et FT ne sont pas des concepts inhérents au Big Data; puisqu’existant pour des bases de données relationnelles ou différents composants logiciels notamment pour les sites web. (Pour les techniciens, pensez également aux nombreux middlewares de type JEE, WCF, CORBA ou bien encore au grid computing). La différence structurelle du Big Data est là encore la quantité de données adressée, soit la volumétrie ; le côté "Big" de la chose. Ainsi, si une base de données relationnelle est dite conséquente, pour ne pas dire énorme, lorsqu’on parle de quelques téraoctets. Avec du BigData on peut aisément parler en pétaoctets (soit a minima 1000 fois plus que les plus gigantesques bases relationnelles)
Maîtrisons totalement les concepts Big Data par rapport aux bases classiques
Montons encore un peu le niveau technique. Si tout se passe bien, vous verrez les "entrailles du Big Data " et aurez une image fonctionnelle claire ainsi qu’un vernis technique suffisant pour comprendre les différences avec une base de données classiques.
Tous les concepts Big Data que nous avons vu depuis le début de cet article, mis bout à bout, débouchent sur le théorème de Brewer aussi connu sous le nom de CAP. Ils permettent également de qualifier les solutions de Big Data conforme à un modèle dénommé BASE, par opposition au modèle ACID connu pour les bases de données relationnelles classiques.
Expliquons CAP, BASE et ACID
Le théorème de Brewer ou CAP (pour Consistent, Available, Partition tolerant) annonce qu'il est impossible d'avoir à la fois un système cohérent (c’est-à-dire des données homogènes, à jour et cohérentes partout), entièrement disponible (qui répond toujours, même pour dire qu’il n’est surchargé) et tolérant aux pannes (le système continue à fonctionner dans tous les cas, à moins d'une panne réseau générale).
BASE, qui s'appuie sur le théorème CAP, et caractérise les bases Big Data est l'acronyme de Basic Availability, Soft state, Eventually consistent. C'est un principe de création logiciel permettant de réaliser des systèmes capables de toujours répondre même basiquement, avec un état qui n'est pas garanti (par opposition au hard state, on ne garantit pas de facto, bien qu’on puisse le faire, qu'une sauvegarde est forcément pérenne) et avec des données qui ne sont pas obligatoirement consistantes. Autrement dit, avec BASE, ce que l'on lit ou écrit en base peut être sujet à des modifications au cours du temps même sans la moindre action utilisateur. En effet, il y a des principes de duplication d’information et de latence. Tout est une histoire de réglages, mais une mauvaise architecture ou configuration peut vous mener à des situations désastreuses avec perte de données ou rollback.
Par opposition, ACID caractérise les bases de données relationnelles. Il signifie Atomique, Cohérent, Isolable et Durable. Sans faire un long laïus sur cet acronyme, il indique qu’une base de données classique fait des opérations et des transactions garantissant un système parfait où il n’y a pas pour le béotien de surprises (j’avoue prendre un raccourci en passant sous silence des concepts comme les niveaux d’isolations, phantom, dirty reads et consort mais ceci est de l’ordre du réglage).
Prenons un petit exemple.
Avec ACID, vous gérez une table de crédit et une table de débit comptable. En mode transactionnel vous garantissez nativement qu’à un débit correspond un crédit. Si la base vous indique que c’est sauvegardé, alors tout est parfait. Même en cas de reboot, tout sera cohérent.
Avec BASE, pas obligatoirement ! Il peut se passer par défaut, même sans reboot, de multiples choses et ça dépend des bases et leurs réglages. Par exemple, si vous n’avez pas configuré comme il faut, votre sauvegarde peut très bien être partiellement annulée (à un débit ne correspond pas un crédit) sans aucune action de votre part et les données peuvent ne pas être cohérentes (je passe ici sous silence les problèmes d’atomicité et de verrouillage pour simuler ou émuler les transactions des bases classiques).
Ne soyez pas surpris, le problème n’est pas insoluble avec le BigData .Mais conformément au théorème CAP ce que vous gagnez quelque part vous le perdez ailleurs. Si vous devenez par exemple complètement consistent (données à jour partout), alors vous perdez entièrement en disponibilité (largement moins de personnes peuvent consulter en parallèle), etc.
Mais attendez, ce n’est pas tout
Encore plus fort, les bases de données relationnelles sont capables d’être transactionnelles entre elles grâce à ce que l’on nomme un moniteur transactionnel (on parle de transaction 2PC ou Two Phase Commit généralement de type XA, la norme, ou bien OLE, norme de Microsoft).
Deux bases de données d’éditeurs différents peuvent complètement interagir et garantir une homogénéité parfaite des deux systèmes. Imaginez une base de comptabilité où tous les crédits sont dans une base Oracle et tous les débits dans une base SQL Server. Avec les transactions 2PC, vous pouvez garantir totalement qu’à chaque débit comptable SQL Server correspondra un crédit comptable Oracle ; plutôt épatant.
Si vous avez tout suivi, vous comprendrez qu’évidemment, toutes ces caractéristiques se perdent par défaut avec le Big Data. Mais, fort heureusement, existe-t-il a minima des procédures de contournement pour simuler les transactions et dans le meilleur des cas un concept approchant le principe (par exemple Cassandra avec ses Lightweight Transaction).
Maintenant, ne prenez pas peur. Les bases de données Big Data ont plein d'avantages, nous aurons le loisir de vous le prouver au fil de nos articles ; expliquons en deux connus : le NoSQL et le schema-less.
NoSQL ?
Le SQL (Structured Query Langage) est un langage normalisé d’interrogation que toutes les bases de données relationnelles proposent. Le BigData possédant des caractéristiques et contraintes différentes, le terme de NoSQL (Not Only SQL) est apparu pour permettre d’autres façons d’insérer, modifier, requêter ou supprimer les données. Le NoSQL n’étant pas normalisé, il existe de multiples solutions NoSQL, au point ou l’amalgame Big Data/NoSQL c’est créé. Quand vous entendez parler de base NoSQL vous pouvez logiquement donc conclure que la discussion s’articule autour de bases de données non relationnelles, donc à du Big Data ! (Pour votre culture, il existe des bases non relationnelles qui ne sont pas Big Data. C’est par exemple le cas des bases de données objet).
Schema-less ? Kisako ?
Toutes les bases de données Big Data proposent des fonctionnalités pour ajouter simplement des informations non prévues dans une base. C’est comparativement aux bases relationnelles très intéressant. En effet, ces dernières s’appuient sur un modèle de données indiquant le type d’information que l’on souhaite sauvegarder. On va par exemple indiquer que l’on souhaite sauvegarder le nom et prénom d’un utilisateur sous format chaîne de caractère, et l’âge sous forme d’entier. Tout ajout ou modification de colonnes correspond à un changement de modèle. Par exemple l’ajout d’un nouveau champ adresse et la modification de l’âge d’un entier vers une chaîne de caractères, est un processus qui s’avérera couteux et long s’il doit s’appliquer sur une base de données gigantesque.
Toutes les solutions Big Data savent gérer l’ajout de colonnes, donc d’information, sans impact. D’autres vont encore plus loin et permettent la modification d’un type « à partir de maintenant ». Autrement dit, les anciennes informations de l’âge resteront des entiers et les nouveaux enregistrements des chaînes. On nomme cela du schema less, c’est-à-dire l’opportunité de stocker ce que l’on souhaite, quand on le souhaite, sans avoir besoin de modifier les structures des bases. MongoDB sait très bien le faire. Cassandra a changé de point de vue sur la question. Quoi qu’il en soit, si cette fonctionnalité peut créer des impacts en termes de performance, et porte mal son nom (car c’est généralement la différence entre un schéma statique et un schéma dynamique plutôt que le fait qu’il n’y ait pas de schéma), elle est à connaître en terme de caractéristique de certaines bases Big Data.
Que conclure ?
Qu’il n’y a jamais de magie en informatique et que ce que l’on gagne quelque part on le perd ailleurs. Les bases de données relationnelles sont résolument performantes et efficaces dans de nombreux cas de figure et le Big Data n’a pas été initialement créé pour les remplacer, mais pour des problématiques spécifiques où il s’avère parfaitement efficace : le stockage massif de nombreuses informations.
Toutefois ce stockage à un coût. On perd par nature ce qu’une base de données relationnelle propose par défaut, ce qui n’est pas sans incidence lors de la création d’applications Big Data car les architectes informatiques, les chefs de projets et développeurs se trouvent dans des contextes de raisonnement dont ils n’ont pas l’habitude, ce qui explique que seuls 4% des personnes ayant implémenté le Big Data l’aient fait de façon efficace.
Peut-on alors faire sans le Big Data dans sa société ?
Nous ne répondrons pas tout de suite, il vous faudra un peu patienter. Nous n’avons pas encore abordé les principes d’analyse de données, business intelligence ou encore machine learning. Nous devons comprendre l’OLTP, l’OLAP, le datamining et affiliés.
Le chemin vers le Big Data est long et périlleux, mais c’est un beau chemin Rassurez-vo nous préférons d’abord vous présentez tous les écueils du Big Data avant de vous présenter tout ce qu’il sait vraiment faire et peut apporter pour peu qu’il soit utilisé à bon escient.
Ce que vous devez retenir d’ici le prochain article. Niveau terminologie, retenez Schema-less, NoSQL et le théorème CAP. Niveau architecture, retenez et comprenez les différences conceptuelles entre ACID et BASE. Enfin au niveau logiciel, retenez pour le moment Hadoop (fichiers distribués) et les bases Big Data comme MongoDB et Cassandra.
La semaine prochaine, nous rentrerons un peu dans la terminologie marketing, ferons une incursion dans l’analytique et répondrons à la question que se pose tout directeur de système d’information, ingénieur informatique ou personne ayant un peu de jugeote « : Le Big Data étant fait pour gérer des quantités astronomiques de données, doit-on véritanlement faire avec le Big Data ? Surtout quand on est une grande entreprise qui n'est ni Google ni Facebook ? ».