Le Concept « BIG DATA - Institut des Actuaires

8
Situation et perspectives
TELECOM n°169 / BIG DATA
L
Big 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éciait
pas jusqu’ici de structures d’accès et de
distribution des données susamment
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 diusé, 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émystiant, si nécessaire, certaines
fausses bonnes idées. Avant d’aller plus
loin, revenons sur quelques dénitions
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énition de ce
que pourrait être la frontière des tailles
relatives au “Big Data”.
Le Concept «BIG DATA»
Nouveaux enjeux technologiques
par 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
Situation et perspectives
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 sut 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écieront à terme des nouvelles
capacités, oertes par le contexte “Big
Data”, ce qui permettra de les améliorer
de façon très signicative.
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’aux 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énition
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 dié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 eet 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éce d’uti-
lisateurs provenant essentiellement
du milieu Scientique 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 Scientique) 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 Scientique).
Ces moyens de calcul servent à relever de
grands dés scientiques. 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-
ques 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 nanciers et qua-
siment pas aux modèles liés à l’exploita-
tion de données à valeur marchande. En
conclusion ce qui dié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és techniques), d’autre
part le fait que c’est plus la diculté
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 eet 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 stratications 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). Enn 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 nancier
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
Situation et perspectives
TELECOM n°169 / BIG DATA
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 ores à des
clients divers et qui désire les dé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 prols 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
ranés et ecaces. La “segmentation de
clientèle” en CRM consiste à découper la
population globale en segments typés
dans lesquels les clients ont des prols
(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
diérenciées en nombre raisonnable et
le fait d’avoir des classes susamment
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 eet, une
fois validé un nombre de classes adéquat
pour des objectifs xés, on réaecte l’en-
semble des clients de la base mère (celle
des millions de clients) sur les segments
trouvés, cette fonction de réaectation
par comparaison vectorielle aux prols
représentatifs des classes est typique-
ment une opération “Big Data”, car
elle porte sur l’exhaustivité de la base. En
eet, 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 à eectuer. 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éciques, 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-
er, 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 chires
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) à qualier chaque segment de clientèle trouvé, enn, 3) à rechercher dans la population mère totale des individus ayant un prol 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 xe 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
Situation et perspectives
BIG DATA / TELECOM n°169
de Louvain, du Laboratoire “Complex
Networks” de l’université Paris VI etc.).
Le problème est tout à fait identié 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:
InnityGraph 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 ecace (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é-
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.
Enn 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 eet, 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 (éorème CAP5) ou Jon
Kleinberg de Cornell (é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
exibilité 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 simplication des procédures
d’indexation associée à une aectation
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: InnityGraph, Neo4j etc.). Enn
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ériables 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
Situation et perspectives
TELECOM n°169 / BIG DATA
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 eectivement 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 gées”. Ces entreprises
pionnières, fortement inuencées par
la culture Open Source Software (OSS),
ont ni 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 dié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 eorem
constraints:
1 Brewer’s CAP eorem 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 exible
and accept not to fulll entirely the
explicit constraints
Classication 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, InnityGraph, etc.).
1 BDD Orientées clé-valeur
(Voldemort, Dynamo, Riak etc.).
1 BDD Orientées documents, comme
(CouchDB. ou MongoDB.)
Le besoin associé à la diversication
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 enn
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é oerte 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’ore
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 ores 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
(anity 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’anité. 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 anité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 ecace, 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) Classication
Le cas de la classication supervisée7 (sauf
dans la partie du processus où l’on pro-
[6] 16 Milliards de $ pour IBM par exemple