Quels choix de base de données pour vos projets Big Data?
Big Data? Le terme "big data" est très à la mode et naturellement un terme si générique est galvaudé. Beaucoup de promesses sont faites, et l'enthousiasme pour la nouveauté technologique et pour les nouvelles opportunités qui s'ensuivent tendent à faire passer les éventuelles limitations et contraintes au second plan. Quand on gratte un peu, beaucoup de technologies prometteuses viennent avec des limitations qu'on aurait tort d'ignorer. Cette présentation proposera une vue pratique du domaine du big data, en définissant le problème et en présentant d'une manière succincte les solutions existantes avec leurs qualités et leurs défauts. Avant tout, il faudra trouver une définition pour le "big data". Car en définitive, quand peut-on réellement parler de big data? Quand on parle de téraoctets, de peta-octets, d'exa-octets? Ou est-ce que certains projets de la taille du gigaoctet peuvent être qualifiés de "big data"? Et au fond, est-ce que la taille des données est le seul critère important? Est-ce même réellement un critère majeur?
Quels usages pour les données Une question fondamentale est "que faire avec les données massives". Il ne s'agit pas simplement de se dire "nous avons beaucoup de données, faisons du big data". Plus sérieusement, beaucoup de projets big data ou pas sont lancés sans avoir une vision claire d'où on veut arriver. L'usage qu'on veut faire des données est une décision fondamentale pour lancer un projet big data.
A quel niveau de complexité les données Big Data peuvent-elles prétendre? Quoi qu'on en dise, il y a toujours un problème d'échelle. La technologie est encore loin de pouvoir résoudre des problèmes à la fois de complexité et de taille quelconques. Le "big data" a ses limites, on pourrait presque parler d'un "principe d'incertitude d'heisenberg": plus on a de données, plus la complexité de leur structure et du traitement qu'on en fait sera limitée en pratique. Les ordinateurs quantiques promettent de résoudre cette difficulté, mais on n'est pas encore tout-à-fait prêts à les trouver dans un Apple store
Le Big Data est il pertinent et / ou réalisable pour types d applications La technologie impose actuellement une série de limitations pratiques aux solutions big data. Les solutions big data sont rarement entièrement transactionnelles au sens où on l'entend dans les bases de données disons "traditionnelles" (c'est-à-dire applicatives). Les bases de données applicatives restent pour l'instant le paradigme majeur en informatique (ERP, applications de comptabilité, applications spécifiques dans divers domaines ) Une base de données à transaction reportée n'est tout simplement pas envisageable dans un environnement applicatif traditionnel (qu'il soit client-serveur ou multi-tiers). Un autre problème typique est celui de la complexité des schémas de données. Pour un traitement efficace, la complexité (càd par exemple l'intégrité référentielle) limite la taille des données pouvant être traitées en pratique. Ces points et d'autres ne posent pas de difficultés pour certains types de problèmes typiquement traités par les projets big data mais empêchent ces solutions de prétendre à l'universalité.
Quid des données non structurées La question qui vaut de l'or littéralement. Malgré une structuration et une codification de plus en plus poussée des données, 70 à 80% des données (en fonction des analystes: Gartner, IDC) restent non-structurées (texte libre, documents de type traitement de texte ou tableur, PDF, rapports en tous genres et en tous formats, etc.) ça représente une quantité énorme de données potentiellement utiles et utilisables (c'est-à-dire monnayables).
Qu'est-ce que le "Big Data"? D'après Wikipedia: "Big data est le terme définissant un ensemble de données si massif et complexe qu'il devient difficile de les traiter au moyen d'outils de bases de données classiques ou d'applications de traitement de données classiques ( )" http://en.wikipedia.org/wiki/big_data
Une Nouvelle Ruée vers l'or La popularité de big data tient en partie dans les "success stories" de monétisation de l'information client Pour beaucoup, Big Data se résume à trouver un maximum d'aiguilles (en or) dans une énorme botte de foin "Big Data is not about the amounts of data. It's about the cool stuff you can do with Big Data" (Peter Hinssen) http://datascienceseries.com/assets/blog/greenplum_information_is_the_new_oil-lr.pdf
Importance de la Qualité de l'analyse de Données Bien sûr, le traitement de données massive échappe largement à la capacité humaine de traiter l'information avec le risque que les analyses (souvent heuristiques) produisent des effets de bords pervers ou soient utilisées abusivement par certaines sociétés (voire adaptées délibérément dans ce but). Si l'on met de coté les buts illégitimes, le recoupement de l'information devient primordial pour affiner les modèles par exemple le recoupement entre information structurée et nonstructurée peut se révéler très précieux.
Approches Big Data Aujourd'hui Bases de données "traditionnelles" càd relationnelles (gros volumes en solution de type "grid" par exemple) Outils d'indexation (p.ex. Apache Lucene) Outils de traitement parallèle de données massives (Hadoop Map/Reduce) Bases de données dites "NoSQL", principalement: Clé/valeur (p.ex. Redis) Orientées "document" (p.ex. MongoDB, CouchBase) Orientées "colonne" (Google BigTable p.ex. Cassandra) Bases de données NoSQL plus orientées complexité que volume, typiquement bases de données orientées "graphes" (p.ex. Neo4J) Tous ces outils (sauf relationnels et peut-être orientés graphes) sont dédiés à des catégories de problèmes spécifiques dans des contextes spécifiques
Apache HADOOP Outil de bas niveau pour le traitement de données massives Pas à proprement parler une base de données: plutôt un registre passif optimisé pour le traitement Pas conçu pour l'édition de données, uniquement pour insertion et traitement HADOOP en soi est une solution très technique et demande un investissement important en développement Divers produits basés sur HADOOP existent pour simplifier le traitement de données: Hive, Pig, Lingual, Cascading Des bases de données NoSQL sont basées sur HADOOP, p.ex. Cassandra, HBase HADOOP est conçu pour le "data mining", pas comme base de données opérationnelle
Bases de Données NoSQL Les solutions NoSQL clé/valeur, orientées document et orientées colonne ont des avantages et limitations assez similaires Orientées vers le traitement de grands volumes de données Permettent typiquement une distribution de la charge entre plusieurs serveurs Typiquement optimisés pour l'insertion et l'exploitation, pas la mise à jour (bien qu'elle soit en général possible) Supportent un niveau de complexité des données limité Transactions généralement pas ACID (consistance reportée)
Bases de Données NoSQL Bien que leur utilisation par des moteurs en ligne (Google, Amazon, Facebook, Twitter ) les ait popularisés, la réalité est plus complexe: Amazon est principalement sur Oracle DB Facebook et Twitter sur MySQL (et Cassandra) Google utilise principalement BigTable (NoSQL) Wikipedia et YouTube utilisent MySQL Sauf exception, ces bases de données sont dédiées à des besoins spécifiques l'usage global reste sur SQL
Bases de Données Orientées "Graphe" Nom: Bouvier Prénom: Clancy NomJF: Gurney Nom: Bouvier Prénom: Jacqueline Prénom: Mona Nom: Simpson Prénom: Abraham Relation: Fille Relation: Fille Relation: Fils Relation: Fils NomJF: Bouvier Nom: Simpson Prénom: Marge Relation: Epoux Depuis: 19/4/1987 Nom: Simpson Prénom: Homer Prénom2: Jay Relation: Fils Relation: Fille Relation: Fille Relation: Fils Relation: Fille Relation: Fille Nom: Simpson Prénom: Bartholomew Prénom2: Jojo Alias: Bart Relation: Frère Nom: Simpson Prénom: Lisa Sexe: F Relation: Soeur Nom: Simpson Prénom: Margaret Alias: Maggie Relation: Soeur Relation: Soeur Relation: Victime Relation: Employé Nom: Burns Prénom: Montgomery Alias: Monty
Bases de Données Orientées "Graphe" Permettent de stocker et gérer des relations complexes entre entités Prétendent donc à une universalité supérieure aux bases de données relationnelles Support transactionnel typiquement complet Nouveau paradigme (maturité?) Approches pas toujours consistantes entre produits, pas de standardisation Capacité de supporter des grands volumes peu claire en pratique Possibilités de distribution de charge (scalabilité horizontale) typiquement très limitées Modèle prometteur et d'ores et déjà pertinent pour certains projets, mais encore trop neuf pour un usage général
Fragmentation des Solutions par Cas d'utilisation Les grands acteurs donnent dans beaucoup de cas l'exemple du "une base de données par usage" Par exemple, FaceBook et Twitter utilisent MySQL pour les données opérationnelles et Cassandra (+Redis: Twitter) pour des usages spécifiques pour lesquels le relationnel atteint ses limites Clairement, ça implique une multiplication des compétences: un spécialiste Hadoop n'est pas (nécessairement) un spécialiste Cassandra et n'est (certainement) pas un DBA ou développeur MySQL Ça implique également la mise en place et la maintenance de plusieurs systèmes très différents Cette multiplication des compétences et des systèmes est envisageable pour de très grosses sociétés comme Google, Facebook, Amazon, Twitter Moins pour de plus petites sociétés
Le Cloud est-il une Solution à la Fragmentation? http://www.datamation.com/cnews/article.php/3851071/tech-comics-cloud-computing-consultants.htm
Une Solution à la Fragmentation InterSystems propose une solution technologique très complète en un seul environnement consistant: Caché Le grand intérêt de Caché en tant que plate-forme de données est sa très grande flexibilité qui lui permet de répondre efficacement à une grande variété de problèmes avec des approches éventuellement diverses mais consolidables Caché est une solution éprouvée, en production dans des dizaines de milliers d'environnements de tous types et de tous volumes depuis de très nombreuses années Caché a été conçu dès le départ pour une mise en place aisée, des besoins limités en maintenance opérationnelle et en ressources système pour une performance optimale