Situation et perspectives Le Concept « BIG DATA

8

Situation et perspectives

TELECOM n°169 / BIG DATA

LBig Data : quelques questions à se poser

“Big Data” : révolution ou évolution naturelle ? Le phénomène “Big Data”, par son intitulé simple et porteur, facilement englobant, génère un intérêt mani-feste et a droit à une couverture média-tique tout à fait exceptionnelle surtout depuis 3 ou 4 ans. Ce “buzz” média-tique est encore plus fort que celui qui s’est produit auparavant pour le “Data Mining” et le “Cloud Computing”, qui l’ont précédé chronologiquement tout en lui étant collatéralement associés. Le “Cloud Computing”, par exemple, a été fa-cilement considéré par les spécialistes des Systèmes d’Information comme une rup-ture dans la façon dont ils allaient fonc-tionner désormais. Pourtant il repose sur un substrat technologique et technique paradoxalement plus facilement assimi-lable que celui qui caractérise l’ensemble des approches “Big Data”, lesquelles sont complexes, multiformes et en voie

de stabilisation au moins pour certaines d’entre elles. Ceci augure-t-il une accep-tation plus délicate pour le Big Data ? Le Data Mining quant à lui, qui préexistait au “Big Data”, et peut donc y être associé plus directement encore, ne bénéficiait pas jusqu’ici de structures d’accès et de distribution des données suffisamment rapides et souples pour pouvoir donner pleinement la mesure de ses potentia-lités. Nous allons essayer de présenter, quelques indications sur ce qui carac-térise ce phénomène “Big Data” et sur ce qui relève ou non de son appellation. Nous déclinerons ensuite quelques-uns de ses impacts et caractéristiques.

“Big Data” : un nouveau phénomène de mode ? Le “Big Data” est-il un nouveau phé-nomène de mode? le besoin de ces approches est-il vraiment incontour-nable ? Ces questions ont été abordées dès Juin 2011 par “Mac Kinsey Global Institute (MKGI)» au travers d’une étude Consulting détaillée sur le phénomène “Big Data”, ce document à visée marke-

ting a été très largement diffusé, nous allons brièvement réinterpréter les conséquences qu’il induit en essayant de sérier les problèmes qui en découlent. D’autres instituts de conjonctures éco-nomiques comme le Gartner Group par exemple, (dont nous donnons ci-après la vision des 10 technologies les plus stratégiques pour 2012) ou IDC, ainsi que des laboratoires académiques d’uni-versités américaines et européennes célèbres (MIT, Stanford, Berkeley, Imperial College, Paris VI UPMC ainsi que de nombreux journaux d’informa-tion professionnelle ou spécialisée ont publié des articles dédiés à cette thé-matique ou consacré des numéros spé-ciaux à ce nouveau paradigme (comme la Harvard Business Review). Même des journaux grand public comme le New York Times, ont largement contribué à la célébrité actuelle du phénomène “Big Data” par des articles et des rapports repris par la presse informatique spécia-lisée ou généraliste.

Après lecture de ces articles, il appa-rait qu’il en va du phénomène “Big Data” comme de beaucoup d’autres phénomènes de nouvelles tendances technologiques qui l’ont précédé : il y a de facto du progrès réel à attendre mais il y a aussi quelques exagérations qu’il convient de modérer. Nous allons essayer de montrer les axes où nous pensons que ces progrès auront un impact sérieux sur notre façon de four-nir des solutions à nos clients, tout en démystifiant, si nécessaire, certaines fausses bonnes idées. Avant d’aller plus loin, revenons sur quelques définitions comme celles données ci-dessous qui sont traduites et extraites du rapport du Mac Kinsey Global Institute à propos des concepts reliés au “Big Data”, à com-mencer d’ailleurs par la définition de ce que pourrait être la frontière des tailles relatives au “Big Data”.

Le Concept « BIG DATA » Nouveaux enjeux technologiquespar Jean-François MArCoTorChINo

Top 10 Strategic(*) Technologies (2012)(Source Gartner Group 2012)

Media Tablets

Mobile Centric Applications and Interfaces

Contextual and Social User Experience

Internet of Things

Apps Stores and Marketplaces

Next Generation Analytics

Big Data

In-Memory Computing

Extreme low Energy Servers

Cloud Computing

Worldwide Data

Collections:

7,9 ZETTABYTES

by 2015

EQUIVALENT to

18 MILLION Libraries of Congress

(*)Strategic Technology: one with a significant impact in the next Three years

9


BIG DATA / TELECOM n°169

1 “Big data” fait référence à des ensembles de données dont la taille va au-delà de la capacité actuelle des logiciels de gestion de base de données pour capturer / stocker / gérer et analyser.

1 Les problèmes liés au “Big data” ne sont pas seulement liés aux questions de volume des données, mais aussi aux questions de complexité de gestion de celles-ci (ex. grands graphes connectés dans le champs sémantique)

(source: Mac Kinsey Global Institute)

Le rapport du Mac Kinsey Global Insti-tute (voir alinéa n°2 de l’encart précé-dent) et le tableau des 10 Technologies clefs de 2012 du Gartner Group, insistent bien sur le fait que le “Big Data” et l’“Advanced Analytics” (nouvelle géné-ration d’outils scalables, que certains appellent déjà le “Big Analytics”) sont étroitement liés. Il s’avère que le fait de manipuler de grandes quantités de don-nées ne suffit pas à caractériser une ap-plication ou un traitement de “Big Data”, encore faut-il montrer que l’on a besoin d’être à la fois quasi exhaustif sur le traitement des données et que l’on a réel-lement besoin de l’analyse de toutes ces collections à la fois. Il est important de comprendre dans ce contexte nouveau, la dualité existante entre :

✔ les avancées réelles qu’apportent le “Big Data”, au niveau du traitement d’applications qui étaient totalement limitées et contraintes par des problé-matiques de “scalabilité” ou de possibi-lité de stockage, et qui deviennent, de ce fait, accessibles à l’analyse.

✔ Et l’extension de certains processus d’analyse des données actuellement très répandus, qui utilisent des tech-niques anciennes ou éprouvées, mais qui bénéficieront à terme des nouvelles capacités, offertes par le contexte “Big Data”, ce qui permettra de les améliorer de façon très significative.

Comment faisait-on avant l’arrivée du concept “Big Data” ? Voici d’autres questions connexes : le besoin de ces approches est-il vraiment si crucial et si incontournable que cela ? pourquoi ne pas pratiquer des sondages par échantillonnages1 pour éviter d’analy-ser de trop grands volumes de données? la notion de “big sample” (c’est-à-dire un pa-nel contenant jusqu’à 100 000 exemples extraits des bases de données globales2) n’est-il pas la panacée ? Pourquoi les méthodes existantes issues du “Business Intelligence” ont-elles atteint leurs li-mites, même si elles sont utilisées de façon intensive aujourd’hui, en particulier dans le secteur du “Customer Relationship Management” (CRM) ? En fait, la vraie question qui les résume toutes pourrait être la suivante : en quoi l’afflux massif de données nécessite-t-il une adaptation de rupture pour les méthodologies d’analyse des données usuelles (data mining & data clustering, advanced & visual analytics) ? Aboutissant de-facto à une prédéfinition du concept de “Big Data” partagée par la plupart des acteurs du domaine à savoir :

1 Le paradigme “Big Data” c’est l’association de collections extrêmement volumineuses de données à des algorithmes totalement dédiés permettant des exploitations allant bien au-delà de l’application classique des processus et des méthodologies usuelles de l’Analyse des données.

Calcul Intensif (HPC) vs Big Data ? On n’a pas attendu les années actuelles pour manipuler des masses considé-rables de données dans des Centres dédiés et équipés de machines très puis-santes. Il est opportun de bien différen-cier ce qui relève du “Calcul Intensif” ou (“HPC” High Performance Computing), proprement dit, de ce qui relève de l’ap-pellation “Big Data”. En effet en France, par exemple, sous la houlette du GENCI (Grand Equipement National de Calcul

Intensif), un certain nombre de Centres équipés de machines hyperpuissantes œuvrent pour l’Etat au bénéfice d’uti-lisateurs provenant essentiellement du milieu Scientifique et Recherche à vocation plutôt académiques et universi-taires. Ainsi en est-t-il de l’IDRIS (Institut du Développement et des Ressources en Informatique Scientifique) du CNRS, du CINES (Centre Informatique National de l’Enseignement Supérieur) de Montpellier, du CCRT du CEA localisé sur le site de Bruyères-le-Châtel, et du CERFACS de Toulouse (Centre Européen de Recherche et de Formation Avancée en calcul Scientifique). Ces moyens de calcul servent à relever de grands défis scientifiques. Total (pour la sismique), EADS (pour l’aérodynamique), EDF (pour ses plans de charge réseau élec-trique), METEO France (pour les modèles d’analyses de prévision climatique) etc., utilisent ces grands centres de calcul dont l’objectif est de développer des méthodes de simulation numérique avancées ainsi que les solutions algorithmiques qui adressent de grands problèmes scienti-fiques et techniques. Sur l’ensemble de ces Centres on constate que la puissance de calcul est essentiellement dédiée à de grandes simulations dans le domaine de la physique ou dans les sciences de la vie (simulations moléculaires in vitro), plus rarement aux modèles financiers et qua-siment pas aux modèles liés à l’exploita-tion de données à valeur marchande. En conclusion ce qui différencie le “HPC” et l’actuel phénomène “Big Data” c’est d’une part le type de problématiques (et donc de données) qui sont exploitées dans les quatre centres cités (données extrêmement spécialisées, adressés par des équipes multidisciplinaires sous forme de défis techniques), d’autre part le fait que c’est plus la difficulté des calculs que la masse des données à analyser qui, pose problème dans le cas du “HPC” (aspect combinatoire ver-sus faisabilité calculatoire2). En effet ce qui fait l’intérêt du “Big Data”, c’est une exploitation systématique de grandes bases de données, devenues accessibles à des acteurs qui ne pensaient pas pos-sible leur exploitation, ou encore qui

[1] Un palliatif classique au couple Big Data /Big Analytics est le recours aux sondages. Ceci permet éviter l’aspect « Big » du problème. Malheureusement pour pratiquer d’excellents sondages encore faut-il bien sûr connaître à l’avance (c’est rarement le cas) la population mère sur laquelle on travaille (du fait du redressement par quota et stratifications comme pratiqué par l’IFOP, le CSA, Gallup, Opinion Way, etc. qui s’appuient eux sur le recensement INSEE pour faire leurs prévisions et c’est pour cela qu’elles sont bonnes). Enfin et c’est souvent plus grave, dans des domaines comme le diagnostic médical, la détection de la fraude, l’octroi de crédits etc. on passe à côté des « niches » au sein de la population dans l’approche par sondages, or une niche c’est souvent une « pépite » en tout cas une structure à comportement hors normes et à fort potentiel interprétatif et décisionnel (tant au niveau financier que des risques générés).

[2] A titre d’exemple, de cet aspect hautement combinatoire, non lié à la taille des données : le partionnement optimal de structures à N éléments est un problème hautement combinatoire, ainsi pour N=10000 Objets (ce qui n’est pas un très grand nombre en soi) , le nombre total de solutions possibles est de l’ordre de 1029000 (estimation obtenue grâce aux bornes de de Bruijn et Berendt-Tassa(2010) , du nombre de Bell), nombre monstrueux par ailleurs. Même s’agissant d’heuristiques ‘ad hoc’ (la solution exacte étant inenvisageable ici), l’adéquation d’une algorithmique puissante et de capacités de parallélisme permet d’éviter l’exploration systématique de toutes les solutions possibles. C’est du « calcul intensif » mais pas de l’analyse « Big Data ».

10



n’avaient pas perçu le tropisme “Data Driven Analytics” (laisser parler les don-nées) qui leur est associé. “HPC” n’est donc pas synonyme de “Big Data” mais peut en faire partie si l’on considère que la puissance des machines de trai-tement des données et les procédures de parallélisation des codes sont des composantes clés du processus. Ceci dit la taille importante des données ne caractérise pas forcément un projet “Big Data”. Désambigüisons cette idée en précisant ce que nous entendons par :

“Big Data par extension” vs “Big Data intrinsèque” a) Le “Big data par extension” Il consiste à gérer pratiquement et concrètement les applications métier dont on a besoin sans être obligé, tout au moins à l’heure actuelle, de faire de l’ex-ploitation exhaustive de toutes les don-nées dont on dispose, même si celles-ci sont en très grand nombre. L’apport des méthodologies “Big Data” pouvant être un facteur d’amélioration considé-rable d’un processus d’analyse qui donne néanmoins déjà une certaine satisfac-tion. Pour illustrer ce point, considérons le cas du service Marketing d’un grand opérateur du B2C qui veut segmenter sa clientèle pour adapter ses offres à des clients divers et qui désire les fidéliser dans un contexte de concurrence exacer-bée et de guerre des prix. Pour se faire on ne travaille pas exhaustivement sur la base des profils de plusieurs millions de clients (pour certains opérateurs connus) que l’on a renseignée mais sur un “big sample” représentatif des clients que l’on possède. Sur ce “big sample” (qui peut aller jusqu’à 100 000 individus) on pos-sède des renseignements traditionnel-lement présents dans les bases, plus des informations particulières sur ces clients tests, ce qui peut représenter des cen-taines de variables comportementales, biométriques et sociologiques. Parmi les exploitations basiques et très clas-siques de ces bases de données “sample” deux résultats sont attendus : une “seg-mentation de clientèle” gérable par les “business lines” (agences commerciales)

et des programmes de “cross selling”3 raffinés et efficaces. La “segmentation de clientèle” en CRM consiste à découper la population globale en segments typés dans lesquels les clients ont des profils (au sens de la base de données) voisins ou similaires. Cette segmentation glo-bale consiste donc en un “clustering” (ou partionnement) de la base “big sample” en un nombre de classes que l’on doit es-timer et dont on cherche la “pertinence” (en l’occurrence, dans ce cas, un com-promis entre le fait d’avoir des classes différenciées en nombre raisonnable et le fait d’avoir des classes suffisamment homogènes). On aboutit, en général, à des segmentations4 à une quarantaine de classes maximum, (information fon-damentale sur la structure de la popula-tion étudiée), que l’on va exploiter par-tiellement ou totalement. En effet, une fois validé un nombre de classes adéquat pour des objectifs fixés, on réaffecte l’en-semble des clients de la base mère (celle des millions de clients) sur les segments trouvés, cette fonction de réaffectation par comparaison vectorielle aux profils représentatifs des classes est typique-ment une opération “Big Data”, car elle porte sur l’exhaustivité de la base. En effet, nous venons de le voir, on peut ex-traire par sondages simulés “big sample”, toutes les informations dont on a besoin. Nous sommes alors typiquement dans du “Big Data par extension», puisque la taille certes monstrueuse des données ne conditionne nullement les traite-ments et l’exploitation qui en est faite. Le “Big Data par extension” c’est donc l’existence d’un potentiel d’amélioration très conséquent au niveau de processus d’analyse qui utilisent aujourd’hui un certain nombre d’artefacts méthodolo-giques comme palliatifs des incapacités ou limitations calculatoires.

b) Le “Big Data intrinsèque»Dans ce cas, contrairement au cas pré-cédent, où il existe des échappatoires, on est confronté dès le départ à une complexité de la problématique à ré-soudre qui se situe simultanément au niveau de la taille des données à mani-puler et au niveau de la combinatoire des calculs à effectuer. On ne peut gérer cet environnement sans faire appel à

des algorithmes d’exploitation ou de stockage qui tirent parti de la structure même des données qu’on analyse. Pour comprendre pourquoi les méthodes actuelles d’exploitation et d’analyse des grandes bases de données sont limi-tées quant à leur potentialité d’appli-cation sur ces très grands volumes de données spécifiques, prenons le cas, (exemple pratiquement d’école), rela-tif à la recherche de “communautés” dans les réseaux sociaux. Ceci sert à plusieurs types d’applications certaines relevant par exemple du Marketing (“e-reputation”, “propagation de rumeurs”, “social marketing”) ou de la Sécurité du territoire (recherche de communautés de hackers en Cyber Sécurité, recherche de communautés de fraudeurs (aux paiements par carte en “e-business”, ou aux remboursements ou aux presta-tions étatiques : Sécurité Sociale, CNAV, CNAM etc.) ou encore recherche de com-munautés agissantes dans le domaine du COIN (Counter Insurrection), etc.). Posons alors clairement le problème : pour analyser les communautés qui pourraient éventuellement nous inté-resser, encore faudrait-il les identi-fier, avant même d’analyser le contenu de ce que ces communautés ont échan-gé ou sont en train d’échanger entre leurs membres (par des techniques de traitement et d’extraction sémantique de type TAL (Traitement Automatique du Langage) ce qui est l’étape ultérieure du traitement et qui n’est pas simple non plus. Donnons quelques chiffres sur quelques réseaux sociaux pour nous rendre compte de l’immensité du champ d’observation: Facebook (1,260 Billion Noeuds, 93 Billion liens, Twitter (0,400 Billion Noeuds), LinkedIn (0,205 Billion Noeuds) etc. Dans ce cas, nous sommes vraiment dans du “Big Data” à proprement parler ou “Big Data intrin-sèque”, et la problématique consistant à délimiter les communautés les unes par rapport aux autres est un challenge si complexe que de nombreuses univer-sités prestigieuses s’y sont attaqué et continue à le faire (il s’agit ici, côté amé-ricain : du MIT, de Stanford, de Cornell, etc. côté européen encore une fois : de l’Imperial College de Londres, de l’Université d’Helsinski de l’Université

[3] Le « Cross Selling », recouvre le concept de la « vente croisée », outil fondamental du CRM en B2C, il se déroule en 3 étapes et consiste 1) à segmenter une grosse sous-population de clientèle puis 2) à qualifier chaque segment de clientèle trouvé, enfin, 3) à rechercher dans la population mère totale des individus ayant un profil voisin de celui des membres des segments qui ont déjà acheté un certain nombre des produits de cette compagnie.

[4] Sur un échantillon de taille non négligeable, la segmentation de clientèles devient un problème non trivial si elle est pratiquée dans les règles de l’art (voir la remarque de la note de bas de page n°3). C’est la raison pour laquelle, certains utilisent la méthode des K-means (où l’on fixe a l’avance le nombre de classes) pour pratiquer la segmentation de clientèle sans complexe. Bien qu’erronée cette approche est pourtant très largement pratiquée……

11



de Louvain, du Laboratoire “Complex Networks” de l’université Paris VI etc.). Le problème est tout à fait identifié et porte un nom très précis : il s’agit de la modularisation de très grand graphes, dont nous donnons ci dessous une re-présentation illustrée :

Modulariser un graphe c’est faire appa-raître automatiquement les clusters la-tents du graphes (en l’occurrence dans le cas des réseaux sociaux : les communau-tés cachées). L’analyse exhaustive de-vient une nécessité ici, car on ne connaît pas a priori le nombre et la nature des communautés. La découverte de ces clusters peut paraître un problème simple (quand il n’y a que quelques centaines de sommets) mais il devient quasi insurmontable quand on s’adresse au graphe du réseau de Twitter par exemple (avec ses 400 millions de nœuds et ses milliards de liens – un lien [i,j] étant simplement le fait qu’au moins une fois le nœud “i” et le nœud “j” se sont envoyé un tweet –). On voit tout de suite le challenge, il faut pouvoir stocker les données (et l’on verra aux paragraphes suivants que ceci n’est pas un challenge trivial, mais qu’il existe dé-jà des architectures et des technologies de stockage qui tiennent compte de l’as-pect réticulaire des données position-nées sur les nœuds du réseau, exemple : InfinityGraph ou Neo4j). Mais il faut en même temps pouvoir découvrir les communautés (cliques du graphe) de façon automatique : pour cela il faut un critère de partitionnement en modules ou clusters qui soit efficace (en l’occur-rence il est impératif qu’il soit linéaire à la fois globalement et localement à tous les niveaux du graphe, pour que l’algo-rithme adéquat (forcément dans ce cas une heuristique ad hoc) puisse bénéfi-

cier de cette propriété de linéarité locale. Un tel critère existe, il a été introduit il y à 8 ans par deux physiciens améri-cains : Mark Newman et Michelle Girvan. Une fois les communautés détectées, il importe si nécessaire de les analy-ser communauté par communauté, au niveau du contenu des échanges entre les membres de ces communautés. Pour se faire, on utilise des outils d’analyse sémantique d’extraction d’entités nom-mées. Cet exemple montre ce qu’est une vraie procédure d’exploitation “Big Data” intrinsèque.

Pourquoi l’avènement du concept Big Data maintenant ? Parmi les causes totalement intuitives de la montée en puissance du concept de “Big Data” ces toutes dernières an-nées, l’augmentation des collections de données, accessibles par de nombreuses industries qui ne pouvaient ou ne pen-saient pas pensable le stockage de l’in-formation massive, est certainement l’un des facteurs majeurs. Une seconde cause est fondamentalement l’aspect de plus en plus multimodal et multiforme des données transmises, adressables ou échangées, (vidéos, images, sons etc. en plus du texte et des données numé-riques structurées). Les données de type images, vidéos sons et textes nécessitent des capacités de stockage beaucoup plus importantes que celles requises jadis par les données numériques structurées. Enfin bien entendu le développement du “Cloud Computing”, qui est intrinsèque-ment un générateur de problématiques “Big Data”. Le transfert d’information multimodales extrêmement massives via les smart phones, les réseaux sociaux, mais aussi au travers des opérateurs du “e-commerce” est également à l’origine du phénomène “Big Data”, ne serait ce que par rapport à la question cruciale mais évidente : comment stocker toute ces informations ?. Toujours est-t-il que la tendance aux transmissions de données mobiles et dynamiques a coïncidé avec le démarrage des premiers articles consa-crés au concept de “Big Data”, prônant d’ailleurs au départ une rupture dans la façon de stocker les données.

Une dépendance à la technologie ? En effet, au départ des ruptures impor-tantes se sont produites dans la façon de stocker l’information, du fait du passage à l’“échelle internet”. Ces ruptures ont été poussées par les acteurs fondamentaux du Net que sont Google, Yahoo, Amazon, Facebook, et, dans une moindre mesure, LinkedIn, Twitter, e-Bay. Le contexte in-dustriel particulier à ces entreprises est souvent sous-estimé. Elles ont comme point commun une culture d’entreprise guidée par l’innovation et n’ont aucun état d’âme à mettre en œuvre les trans-formations technologiques et organi-sationnelles nécessaires à la réussite de leur modèle. Ces ruptures se sont bâties en tenant compte de résultats de cher-cheurs éminents comme Eric Brewer de Berkeley (Théorème CAP5) ou Jon Kleinberg de Cornell (Théorème CIA) qui ont été associés aux équipes de recherche de Google, Yahoo, Facebook et Amazon et qui tous, ont contribué à l’essor, sous le vocable de NoSQL (Not Only SQL) d’une nouvelle philosophie de stockage intelligent des données. Bref générant une plus grande sou-plesse de stockage des informations, permettant des requêtages accélérés, avec une capacité adaptation et une flexibilité fortes, liées aux structures de données elles mêmes: le contraire de la “pensée unique” SQL/MySQL imposée par le modèle des bases de données relationnelles. En résumé : une simplification des procédures d’indexation associée à une affectation claire du type d’architecture par grands domaines d’activité (ainsi les approches massivement distribuées adossées aux structures fondées sur les “bases de données orientées colonnes” type Cassandra ou HBase sont-elles adap-tées aux métiers des sites marchands du Web comme Amazon par exemple, d’autres plutôt liées aux propagations arborescentes que l’on rencontre dans les réseaux sociaux sont adaptées à l’ex-ploration des grands graphes du Net, telles : InfinityGraph, Neo4j etc.). Enfin des compromis entre “disponibilité”, “Tolérance au Partitionnement des données” et “Consistency” sont à trou-ver pour ne pas perdre les bonnes fonc-tionnalités des approches SQL (type

[5] En effet le « Théorème CAP » (Consistancy, Availability (disponibilité) , Partition Tolerance (tolérance au Partitionnement), propose un cadre théorique structurant au domaine des grandes architectures de bases de données massivement partagées au travers des 3 propriétés suivantes dont seules 2 sont possiblement vérifiables en simultanéité : 1)Consistance (Consistency /C) : Tous les clients voient la même vue même lorsqu’il y a des mises-à-jour, en fait il s‘agit du ‚Atomicity‘ des propriétés ACID des bases relationnelles. 2)Disponibilité (Availability /A) : L’ensemble des clients peuvent trouver des données répliquées, même lorsqu’une avarie survient quelque part. 3)Tolérance au Partitionnement (Partition-tolerance /P) : Le système est tolérant au partitionnement, c‘est-à-dire au découpage pré-établi des index.

12



HIVE au dessus de Hadoop, permettant d’utiliser Hadoop avec une syntaxe proche de SQL) vont sans doute se développer de façon plus intensive, dans une op-tique appelée BASE (“Basically Available, Soft state and Eventually consistant”). Le besoin initial est effectivement venu du “Web Searching”, via les des opéra-teurs du Net que sont Google, Amazon, Facebook pour faire de l’exploration à partir d’un mode de stockage plus adéquat que les approches par bases de données relationnelles, qui ne pou-vaient satisfaire la contrainte de “mul-ti-colonnes non figées”. Ces entreprises pionnières, fortement influencées par la culture Open Source Software (OSS), ont fini par mettre à disposition leurs bases de code : la base Cassandra a été transférée en 2008 par Facebook à la fondation Apache et a sans doute été le signal de départ d’un mouvement d’appropriation de ces outils par la com-munauté OSS et par ricochet a engen-dré un fort intérêt dans les domaines connexes tels que les bases orientées documents non-structurés et orientées graphe. Un exemple très simple et clair du principe d’adéquation différenciant les approches par “Web Search” des stockages par Data Bases classiques (re-lationnelles, relevant de SQL) est celui donné par la liste de A. Deshpande de l’Université du Maryland :

1 Databases Structures ensure ACID (Atomicity, Consistency, Isolation, Durability)

1 Web search engines don’t care about most of those properties but must be aligned with the CAP Theorem constraints:

1 Brewer’s CAP Theorem constraints==> Among Consistency, Availability, and tolerance to Partitions properties, you must choose Two. Verifying simultaneously those 3 constraints is impossible (ex: Databases structures choose essentially A &C whilst Web search engines choose essentially A & P or C&P

1 A compromise? the “BASE” concept: (Basically Available, Soft-state and Eventually consistent) ==> be flexible and accept not to fulfill entirely the explicit constraints

Classification par catégorie de quelques architectures de stockage NoSQL :

1 BDD Orientées colonnes : (HBase, Hypertable ou Cassandra, etc.), elles sont fondées sur le concept de BigTable de Google

1 BDD fondées sur la théorie des graphes (Euler, implémentée par Neo4J, InfinityGraph, etc.).

1 BDD Orientées clé-valeur (Voldemort, Dynamo, Riak etc.).

1 BDD Orientées documents, comme (CouchDB. ou MongoDB.)

Le besoin associé à la diversification du recueil de données Soit parce que la crainte de la “non sca-labilité” de certains processus d’ana-lyse tend à disparaître, soit parce que certains types de données sont enfin recueillis et stockés en vue de futures exploitation, toujours est-il que l’uni-vers des possibles s’agrandit du fait de la nouvelle capacité offerte d’adres-ser des bases de données de tailles gigantesques en mode : “Data driven” (exploitation totale et exhaustive des bases) à l’opposé de ce qui était pratiqué en général aujourd’hui via des requê-tages orientés, au travers de SQL ou de l’OLAP (“On Line Analytical Process”) en mode : “Hypothesis driven”. Souvent, d’ailleurs, au lieu d’opposer ces deux approches devrait-on les considérer comme complémentaires. Un exemple du croisement du “data driven mode” et du “hypothesis driven mode”, est donné, par exemple, par la navigation dite par “Intelligent Query” (vous posez une question à une base de données et le système vous renvoie non seulement la réponse à votre requête mais également les réponses “voisines” en relaxant cer-taines contraintes de votre question).

Une Complémentation de l’offre logicielle classique par des exten-sions orientées “Big Data”

Microsoft, Oracle et IBM ont investi au cours de la vague de rénovation IT démarrée en 2005 des milliards de dol-lars6 en R&D, marketing, acquisitions et offres qu’ils ont bien l’intention de continuer à rentabiliser. L’enjeu est pour eux double : continuer à suppor-ter la base installée de leurs produits et prendre des parts de marché sur le seg-ment en croissance du Big Data, quoi

que cela veuille dire pour eux. Certaines d’entre elles ont choisi de s’appuyer sur Hadoop et MapReduce c’est le cas d’IBM et d’Oracle. Mais elles doivent réagir vite et innover sous peine de lourdes déconvenues potentielles.

Des technologies novatrices qui tirent le concept “Big Data” =>(le “Big Analytics) Si l’on s’en réfère à la liste des tech-niques et technologies, telle qu’elle apparaît dans le rapport MKGI, on est surpris de voir citées des approches qui ne sont pas directement associées de fa-çon indiscutable avec le paradigme “Big Data”, et qui préexistaient avant son avènement. En passant en revue cette liste, qui a le mérite d’exister et d’être souvent citée par les consultants “Big Data”, nous en avons extrait quelques-unes qui relèvent intrinsèquement du paradigme “Big Data”, soit parce qu’elles nécessitent des temps de calcul variant linéairement avec le nombre d’items à analyser, soit parce qu’elles sont assez facilement parallélisables.

a) Les règles d’association (affinity analysis) Cette technique est l’une des rares de la liste MKGI qui relève vraiment du para-digme “Big Data”. Inventée par Rakesh Agrawal et Ramakrishnan Srikant en 1994, elle utilise le principe de “mat-chings de listes” vectoriels et de calculs de produits scalaires linéaires, elle pro-duit des indices d’affinité. Dans le cas où l’on fait jouer le temps comme paramètre sous-jacent on appelle cette technique : “Sequential Patterns discovery”. En tout état de cause, elle relève tout à fait du processus “Big Data” en ce sens qu’elle a été utilisée pour traiter des affinités dans l’association d’achat de produits à partir des bases de logs de magasins USA, sur plus de 300 000 000 de tickets de caisse sur une nomenclature produits de 150 000 items. Très rapide et efficace, elle per-met des calculs optimisés en O(n). C’est vraiment une solution algorithmique qui porte bien haut le label “Big Analytics”.

b) ClassificationLe cas de la classification supervisée7 (sauf dans la partie du processus où l’on pro-

[6] 16 Milliards de $ pour IBM par exemple

13



cède à la simple affectation d’un individu dans une classe prédéterminée et qui, elle, relève d’une approche de compa-raison vectorielle par produits scalaires donc linéaire en O(n)) ne relève pas à proprement parler du label “Big Data”, en particulier si l’on doit déterminer les classes de séparations (techniques des SVM (Support Vector Machine), ou si l’on doit avant de commencer le processus de classification pratiquer ce qu’on appelle la réduction de dimensions (qui comme son nom l’indique sert de palliatif à l’impos-sibilité de traiter de grands ensembles de données en approche brute.

c) Cluster analysisCette technique, qui consiste à regrou-per des items similaires dans des classes de comportements ou de profils voisins, on pourrait la qualifier, elle, de non su-pervisée, (nous l’avons déjà abordée dans le paragraphe sur la modularisation de graphes), relève du label “Big Data”, à la condition expresse que les critères de clustering utilisés soient linaires ou tout du moins linéarisables par des artefacts de notation. On parle dans ce cas bien sûr de processus heuristiques. Les processus algorithmiques optimaux sont de l’ordre de K O(n Log n), où K est une constante qui dépend néanmoins de la structure des données et peut parfois avoir une va-leur assez forte. Les méthodes K-means relèvent de ces caractéristiques, bien que la fixation a priori du nombre de classes soit un facteur limitatif fort dans cer-tains types de problèmes.

d) CrowdsourcingC’est une technique de collecte et de fusion de données obtenues à partir des remontées d’information de larges groupes d’usagers (d’où le nom “crowd”) à travers des media connectés en ré-seaux. Exemple : “Waze” ceci revient à de la collaboration de masse.

e) Data miningLà il y a typiquement ambiguïté puisque l’on confond l’ensemble et les parties de l’ensemble. Ainsi les techniques de “règles d’association”, les techniques de clus-tering, de crowdsourcing, de Networks Analysis, d’affectation en mode super-visé sont toutes des techniques de “Data Mining”.

f) Genetic algorithmsPrises à la lettre et dans un contexte al-gorithmique général les approches par algorithmes génétiques ne sont ni plus ni moins que des heuristiques ou méta heuristiques particulières (au même titre que les “colonnes de fourmis” (ants columns), les “méthodes du Déluge” ou celles de “Recuit simulé” (simulated annealing). Elles sont, ceci dit, effecti-vement rapides, souvent en O(n log n) donc assimilables à des méthodologies “Big Data”. Cependant, quoique très générales et ne nécessitant aucune connaissance particulière a priori des modèles structurant la problématique à résoudre (c’est ce qui fait d’ailleurs leur grand intérêt), elles ne sont pas systé-matiquement les plus adaptées pour traiter des problèmes d’optimisation ou de structuration (souvent NP Complets ou NP difficiles), lorsque ces derniers ont, par chance, des structures linéaires associées, pour lesquelles on leur pré-férera des algorithmes heuristiques ad hoc, tirant parti directement du modèle8. Donc algorithme génétique : oui du fait de son extrême généralité et adaptabilité, si l’on a de grandes difficul-tés à structurer une problématique don-née par un modèle sous-jacent, souvent complexe, non si ce modèle préexiste et qu’il est représentable par des équa-tions linéaires même de grandes tailles.

g) Neural networksDans le cas où l’on utilise des réseaux de neurones en mode classification super-visée et dans la mesure où les fonctions

de transfert propres au modèle d’affec-tation en classes prédéterminées sont linéaires ou quasi linéaires, on peut considérer que les réseaux de neurones (on dirait dans ce cas réseaux de neu-rones simples à peu de couches relèvent de l’approche “Big Data”. En aucun cas les méthodes de clustering non super-visés type “Cartes de Kohonen” qui sont dérivées des réseaux de neurones, elles sont quasiment en 0(n2Logn) voire plus.

h) Network analysis (analyse de données réticulaires) Bien que les problèmes qui relèvent de la recherche de plus courts chemins dans les graphes ou de modularisation de réseaux via la mise en exergue de cliques ou clusters (du type de celui que nous avons détaillé en Figure n°2) semblent excessivement com-plexes dès lors que l’on explore des graphes à millions de nœuds et milliards de liens, il se trouve que l’on est capable aujourd’hui d’adresser ces énormes problèmes grâce aux approches “Big Data”. Comme on l’a vu précédemment ce sont même des cas d’école qui ont permis de poser réel-lement le problème des “Big Data” et lui ont donné ses lettres de noblesse. A titre d’exemple la recherche du plus court che-min dans un graphe avec l’algorithme le plus rapide aujourd’hui celui de Lawrence Friedman et Robert Tarjan de (1984) est en O(E+ n log n) (voir également [37]) où E est le nombre d’arêtes En utilisant la modularisation on diminue d’ailleurs la valeur de E dans l’exploration (car E réfère dans ce cas à la taille du cluster dans lequel on doit naviguer).

Graphe complexe représenté sous TULIP

[7] La classification « supervisée », consiste à fixer à priori (ou après calculs antérieurs sur une population d’apprentissage ou de test) des catégories ou des classes, auxquelles on va affecter par la suite tous les éléments d’une population étudiée pour leur donner un label, un score ou un type correspondant par exemple au numéro de chacune des catégories définies précédemment, ou une règle d’appartenance associée à ces catégories.

[8] C’est le cas par exemple des heuristiques de recherche de consensus en théorie des votes, des algorithmes d’optimisation de réseaux de transport, ou encore des méthodes de parti-tionnement multidimensionnels, qui quoique NP Complets tirent parti des modèles linéaires de description associés.

14



i) Data Visualization(I)Comme il est mentionné dans le rapport MKGI, il est indispensable à la fin d’une chaîne d’analyse de grandes collections de données de pouvoir interpréter les résul-tats obtenus. La visualisation graphique est l’un de ces moyens fondamentaux permettant d’aider à l’interprétation. Cependant et paradoxalement, malgré le rôle indispensable des méthodes de représentation graphique, les progrès techniques qui leur ont été associés n’ont pas été jusqu’ici à la hauteur de ceux liés aux technologies d’ analyse elles-mêmes. En effet, du fait des limitations des ca-pacités humaines9 à naviguer dans des espaces multidimensionnels10,il est assez décevant11 de constater que la plupart des outils graphiques “nouveaux”12, même les meilleurs, sont assez peu adaptés pour l’instant à la représentation de données hautement multidimensionnelles et plé-thoriques.

j) DataVisualisation (II) : outils de manipulation de graphes Ce sont de réels outils “Big Data”, ils ont bénéficié de progrès constants et d’amé-liorations tant en capacité de visualiser des graphes de tailles importantes que de calcul inhérents à leur compréhension

(modularisation, plus courts chemins, calcul de flots et coupes etc.). Nous en citerons deux parmi d’autres qui se dis-tinguent d’une abondante production par le fait qu’ils sont Open source et mis constamment à jour, il se trouve en plus qu’ils sont français :- Gephi (cited in the Big Data Glossary Report) : c’est un produit Open source Java, qui permet de créer des visua-lisations de réseaux à partir de don-nées brutes sur les nœuds et liens de graphes. II est tout à fait adapté à la manipulation et la visualisation de Réseaux Sociaux l’un des fondateurs de Gephi a été embauché par LinkedIn, et Gephi est utilisé de façon native pour les visualisations de LinkedIn. - Tulip : Il est Developpé au LABRI/INRIA (Laboratoire Bordelais d’Infor-

matique), c’est un outil C++ Open Source qui est capable de gérer des grands graphes (2000000 nodes, pour les calculs cachés de structure) et qui offre la possibilité des sous parties d’un graph e au travers d’une base de visua-lisation efficace (environ 30 000 nœuds max dans un processus de zooming). Tulip a été choisi par Thales comme “technology partner”.

Conclusion : l’Impact du “Big Data” sur les applications métiers

L’exploitation des données en univers “Big Data” ne peut en aucun cas être considérée comme une continuation sans rupture des usages d’analyse des données tels qu’ils étaient pratiqués jusqu’ici. En effet la nécessité d’avoir des algorithmes puissants adressant les problématiques de “scalabilité” et “d’exhaustivité” oblige à une adaptation ou un reconditionne-ment de certains de ceux qui étaient uti-lisés de façon usuelle. Soit que l’on utilise la potentielle découpe des algorithmes en modules parallélisés, pour pouvoir bénéficier de la notion de distributivité offerte par l’architecture de certains types de bases de données NoSQL (approche MapReduce), soit que l’on privilégie des heuristiques à difficulté calculatoire de type quasi linéaire, il faudra de toute fa-çon inscrire ce reformatage des algorith-miques comme un passage obligé et in-contournable qui ne pourra être esquivé.

Des outils de Requêtage adaptés à l’univers “Big Data”

Rendre les données plus facilement acces-sibles et transparentes dans l’univers “Big Data” n’est plus “nice to have” mais fon-damentalement nécessaire. On a vu pré-cédemment à quel point l’accès à l’infor-mation et les temps d’attente autour de sa récupération étaient des sujets clefs. De plus l’aspect multimodal des données

va aller de pair avec un renforcement de l’aspect “data driven”13 qui est la princi-pale justification de l’exploitation des grandes bases de données en mode semi exhaustif. L’arrivée de méthodes rapides de requêtage “intelligent” et supportant la multi modalité sera le nec plus ultra des nouveaux outils de “Data Querying”. Cette approche intermédiaire en fait entre “Hypothesis driven mode” (à la SQL) et “Data driven mode” va prendre tout son sens dans l’univers “Big Data”, nous avons déjà développé ce point.

La Segmentation des données pour “customiser” les actions Base fondamentale des problèmes d’étude de grands “repositories” de données, tota-lement adoptée et intensivement utilisée par les tenants des procédures de CRM, la segmentation de clientèle (en fait l’ap-proche appelée «clustering” ou “unsuper-vised clustering” par les experts) est l’une des méthodes phares de l’exploitation “Big Data” des bases de données clients (lorsque ces dernières contiennent des données démographiques, des données comportementales, des données finan-cières etc.). Mais en fait les méthodolo-gies de “clustering” s’appliquent de façon générique à un très grand nombre de problématiques touchant au “Big Data”, autres que la “segmentation de clientèle”. En effet elles permettent tout d’abord de décomposer de grandes masses de don-nées en sous populations plus homo-gènes et de tailles nettement moindres que la population mère (nous l’avons vu pour la modularisation de graphes) et donc plus faciles à analyser ; de plus, elles permettent de greffer sur l’analyse plus exhaustive de ces sous-populations homogénéisées, des outils d’aide à la déci-sion ad hoc qui seront d’autant plus effi-caces qu’ils ne seront plus utilisés sur la population hétérogène totale (exemple : les techniques de “scoring”, les “classi-fications supervisées”, les “modèles de pricing par types etc.). En conclusion un ensemble d’outils qui relève du paradigme

[9] dues au manque de perception des reliefs, et de repères en dimension supérieures à 3, pour les humains non entrainés[10] On touche ici à l’aspect « Facteurs Humains » dans les problèmes de cognition et de représentation[11] sauf peut être dans le domaine de la représentation des « grands graphes », où l’on a assisté à l’arrivée d’outils puissants de nouvelle génération, fort agréables à utiliser et offrant

une large panoplie d’usages.[12] par « nouveaux » on entend ici: allant au-delà des classiques « camemberts » (« pie charts »), « histogrammes » (« bar charts », ou « skycraper charts »), par exemple les « Parallel

Coordinates » de Al Inselberg.[13] Avinash Kaushik. :”Seven steps to creating a data driven decision making culture, October 2006”[14] Comme on l’avions signalé dans la note de bas de page n° 3 à propos du rôle des sondages par échantillonnages aléatoires pour permettre l’utilisation d’ approches travaillant sur un traitement non exhaustif de l’ensemble des données, le recours aux méthodes de « random sampling » sont d’autant plus efficaces que l’on connaît la population mère à étudier avec le maximum de détails (pour les aspects redressements, stratifications, profiling etc.). Or la connaissance de cette population mère nécessite elle même des traitements exhaustifs pour être optimale (c’est le cas du recensement de l’INSEE), très couteux et portant sur la population totale obtenu par des renouvellements partiels des questionnaires adressés à des sous populations choisies tous les deux ans). En dehors de ce cas clair dont le résultat profite à l’ensemble des instituts de sondage en France, la connaissance de la population mère est un problème complexe, car quand on ne la connait pas on suppose sa composition en classes de spécificité (segmentation implicite). D’où un cercle vicieux.

15



“Big Data” permettant de générer de la valeur ajoutée14 sur les données en mode “Data driven (avec une possibilité supplé-mentaire de rajouter de la différentiation en ayant recours aux Open Data, qu’elles proviennent de l’Etat (ETALAB), ou de structures d’EPIC).

Le rajout de procédures automa tiques d’apprentissage ou d’affectation comme outils d’aide à la décision Parmi les applications du “Big Data” qui peuvent se greffer sur les outils de segmentation générale, présentés au paragraphe précédent, des outils auto-matiques visant à minimiser les risques, à dériver des scoring décisionnels, à optimiser des tarifications par types ou classes de comportements, à affecter à des classes préétablies, à définir auto-matiquement des alertes, représentent un échantillon de l’ensemble des tech-niques qu’il est possible d’utiliser en complément une fois l’analyse des don-nées pratiquée. Tous ces outils allant de la réaffectation automatique d’indivi-dus (au sens statistique du terme) à des classes préétablies (voir le paragraphe “Big Data par extension») ou la mise en place de modèles d’apprentissage auto-matique (“rule based systems”) dès qu’ils sont quasi linéaires en temps de calcul, relèvent du paradigme “Big Data”. Les meilleures pratiques où ces outils ont été appliqués de façon systématique sur de grandes masses de données après un épi-sode de “clustering”, donnent des résul-tats remarquables.

Les stratégies de choix de modèles de bases de données Les données qu’on va utiliser et exploiter, avec les outils d’analyse ou de requêtage que nous venons de présenter, doivent être au préalable stockées dans des archi-tectures de bases de données qui per-mettent l’accès rapide et des temps de récupération de l’information en quasi temps réel. Ceci pose donc le problème du choix du mode de stockage, dès lors que nous aurons affaire à des tailles allant jusqu’à quelques péta octets de données. Or nous avons vu que nous disposons de quatre modes de stockage plus ou moins adaptés à telle modalité ou à tel type de données. Ceci ne veut pas dire que nous allons refuser les bases de données rela-

tionnelles systématiquement, nous avons vu que dans certaines conditions parti-culières, notamment si la “consistance” est souhaitée en même temps que la “disponibilité”, elles offrent une alterna-tive incontournable, mais bien sûr ceci se fera au détriment du temps d’accès aux données. D’autre part, l’habitude acquise de poser des questions aux Bases de Données Relationnelles via le langage SQL, fait que si la connexion a du sens et est compatible avec l’application qu’on veut dérouler, utiliser un environne-ment SQL dans un “framework” NoSQL peut être une excellente solution (c’est le cas de HIVE en surcouche de Hadoop). En réalité, chaque famille apporte une forme de représentation des données

différente, chacune ayant ses spécifici-tés et simplifiant la manipulation d’un certain type de données. L’adéquation type de données / type de mode NoSQL, donc le choix du mode de base de données NoSQL, devient donc fon-damentalement la clef du processus “Big Data” auquel on veut faire face. Ce choix fondamental à faire impacte d’ailleurs les outils de “data analysis” et les outils décisionnels qu’il sera possible d’utiliser sur les collections de données stockées. Ainsi le choix d’Hadoop, par exemple, conditionne-t-il l’utilisation d’outils ana-lytiques comme R-Hipe et R-Hadoop dans le cas où l’on veut se servir de la li-brairie “open source R”, les API “R” ayant été conditionnées pour Hadoop16.

Jean-François MArCotorChIno est actuellement vice-président, directeur scientifique de Thales Division SIX, et « Thales Fellow ». Il est par ailleurs Segment Manager à Thales r&T Directorate du « Corporate Key Technology Domain » : Process, Control and Cognition (PCC), c'est-à-dire le domaine Méthodes et Algorithmes de Thales.Parallèlement à son activité Thales, Jean-François MArCoTorChINo est titulaire du titre de « Professeur des Universités » (CNU Mathématiques 26), directeur de recherche et Professeur associé à l’Université UPMC (Paris VI) aux Laboratoires LSTA et LIP6.Il fut auparavant, et pendant 10 ans, directeur du Centre Scientifique IBM de Paris et de l’European Centre for Applied Mathematics d’IBM EMEA.

L'Auteur

Bibliographie[1] R. Agrawal, R. Sikrant : "Fast Algorithms for Mining Association Rules", Research Report of the IBM

Almaden Research Center, pp : 1-10, Almaden (1994) [2] E. Brynjolfsson, L. M. Hitt, and H. H. Kim: "Strength in numbers: How does data-driven decision

making affect firm performance?", Publication of the MIT disponible à : http://ssrn.com/ abstract=1819486 ou http://dx.doi.org/10.2139/ssrn.1819486 (2011)

[3] A. Costan: "A survey of Large Scale Storage Systems for Data Intensive Applications", in Actes du Séminaire Aristote « Le Déluge de Données », Ecole Polytechnique, (2011)

[4] S. Fermigier: “Big Data et Open Source : une convergence inévitable”, Publication Internet sur le Blog de S. Fermigier (2011)

[5] S. Gilbert et N. Lynch: “Brewer’s Conjecture and Feasibility of Consistent, Available, Tolerant to Partition Web Services” in ACM Sigact News, Vol: 33, n°2, (2002)

[6] M.Girvan, M.E.J. Newman: “Community structure in social and biological networks”, Proceedings of the National Academy of Sciences USA, Vol: 99, pp: 7821–7826, (2002)

[7] J.L. Guillaume, M. Latapy : “Complex Network Metrology”, Complex Systems Journal, n°16, pp: 83-94, (2005).

[8] A. Inselberg : “The Plane with Parallel Coordinates”. Visual Computer 1, n° 4, pp : 69–91, (1985)[9] A. Kaushik : «Seven steps to creating a data driven decision making culture», disponible à l’adresse : http://

www.kaushik.net/avinash/2006/10/seven-steps-to-creating-a-data-driven-decision-making-culture.html, (2006)

[10] J. Kleinberg : “An Impossibility Theorem for Partitioning”, Publication du Computer Science Department, Cornell University, Ithaca, (2002).

[11] T. Kohonen : “Self-Organizing Maps”, vol. 30, Book by Springer Verlag, (1995). [12] S. Lohr : « Savoir Exploiter le Déluge de Données », article du New York Times, traduit en français dans le

Figaro du 18 Février (2012) [13] Mac Kinsey Global Institute: “Big data: The next frontier for innovation, competition, and productivity”,

Report by McKinsey & Company (2011) [14] « R » Bibliothèque Open Source (Apache Foundation), disponible sur : http://www.r-project.org (2010)[15] R.E. Tarjan:, “Depth-first search and linear graph algorithms”, dans SIAM Journal on Computing, vol. 1,

no 2, p. 146–160 (1972)[16] V. Vapnik: “The Nature of Statistical Learning Theory”, Springer-Verlag, (1995).[17] E. Viannet : « Recherche de Communautés dans les Grands Réseaux Sociaux », in Revue des Nouvelles

Technologies de l’Information, RNTI A3, pp:145-160, Cepadues Editions, Paris, (2009)[18] P. Warden: “Big Data Glossary”, Book as a guide to new generation of Data Tools, 0’Reilly Publishing,

Cambridge, (2011)

[16] Dans beaucoup d’ applications « Big Data » existantes des choix de bases NoSQL ont été faits qui ont privilégié l’environnement Hadoop (le « framework » Hadoop) avec recours à la fonction de distribution et de parallélisme MapReduce sur un substrat de base Orientée Colonne HBase, ou Cassendra..

Documents

Situation et perspectives Le Concept « BIG DATA