Facebook EmaiInACirclel
Cloud – big data

Big Data, Small Information

PentaGuy
PentaGuy
Blogger

Cet article est d’abord un (énième ?) essai pour définir ce que recouvre la notion de Big Data et pour montrer qu’il ne s’agit, somme toute, que d’un avatar de la Business Intelligence (BI), processus classique de pilotage des organisations par de l’information formelle à support numérique.

Big Data, un buzzword et une idée pas si nouvelle

J’ai entendu ici ou là, que Big Data = 4V (Volume, Velocity, Variety, Variability) soit une définition par des caractéristiques qui ne résiste pas à un examen approfondi de la question car ces caractéristiques sont empreintes de subjectivité. J’ai aussi pu lire que Big Data est une caractérisation des données qui nécessite une approche innovante et originale de leur traitement par la mise en place d’infrastructures dédiées.

Pour démystifier un peu ces deux définitions prenons le cas d’un opérateur de téléphonie mobile à l’aube du XXIème siècle. Cet opérateur est actif sur un marché émergeant dans un pays ne disposant pas de l’infrastructure réseau du téléphone fixe (cœur de réseau en fibre et réseau commuté en paire cuivre). Enfin, cet opérateur travaille quasiment exclusivement avec des offres prépayées. Cet exemple est inspiré d’une situation réelle, cet opérateur étant un ancien client de Pentalog.

Dans le monde d’avant le 11 Septembre, autant dire il y a des siècles, cet opérateur traitait 5 millions de tickets de communication par mois, 1 million de transactions sur compte prépayé par mois et 10000 appels au centre de support par mois. Chacun de ces événements était enregistré dans des bases de données relationnelles (ou en fichier de journalisation directement), conservé et analysé.

Et on ne parlait pas de Big Data. Et pourtant, les problématiques de collecte, de stockage, de qualité et d’analyse des données étaient toutes présentes et conduisaient à des solutions novatrices pour le traitement et l’analyse de ces données.

Un problème plus ancien encore peut être considéré comme relevant de Big Data étant donné l’approche novatrice qui a été retenu pour parvenir à sa solution. Le recensement U.S. de 1890 devait procéder à la collecte et au stockage de 50 millions de fiches individuelles comportant pas moins de 80 variables. Cet événement a conduit à l’invention du Tabulateur de Hollerith[1] et, indirectement, à la fondation d’IBM[2]. Comme quoi, chaque époque a, a eu et aura son moment Big Data.

Big Data = Business Intelligence

De mon point de vue, seuls l’échelle et le temps se sont, respectivement, dilatés et accélérés. Le million d’événements par mois est toujours présent mais l’ordre de grandeur est maintenant de 100 millions et le temps de l’ordre de la seconde. Les 50 millions de fiches individuelles sont devenus 500 millions de graphes orientés.

Et, encore, cela ne concerne que quelques acteurs à fort trafic dont les besoins en analyse de données en temps-réel sont prégnants. On pense aux sites de réseautage social bien connus mais aussi aux vendeurs en lignes dont les moteurs de recommandation carburent à la Business Intelligence en temps quasi-réel.

Car le besoin de ceux qui pilotent et décident qu’ils soient chefs d’entreprise, capitaines au long cours ou directeur de mission spatiale ne réside pas dans la donnée mais dans l’information qui y est contenu. Et de l’information, il est nécessaire d’en avoir le juste niveau. Trop peu c’est de l’incertitude. Trop et c’est l’indécision. Et il est aussi nécessaire de posséder une information juste que d’en avoir connaissance au moment opportun.

L’accélération des échanges induite par une interconnexion accrue et une technologie de transport plus efficiente a rendu encore plus faible le délai raisonnable entre la survenance d’un événement, sa détection et sa présentation au décideur.

Ce délai est connu sous le nom de latence du cycle événement-détection-présentation. Si la plupart des chaînes décisionnelles historiques se contentaient d’une latence de 24h, ce délai n’est plus admissible de nos jours car la période caractéristique de nombreux processus métier est de l’ordre de la minute, voire de la seconde, voire de la milliseconde dans le cas de processus entièrement automatisés.

Une fois ceci posé, on peut néanmoins affirmer que l’on reste dans une problématique classique d’extraction analytique et de présentation synthétique de l’information.

Architecture fonctionnelle de Business Intelligence

Ce qui n’est plus classique en définitive ce sont la multiplicité des sources qui, bien souvent, sont externes et la croissance de la masse de données à interpréter. C’est cette caractéristique de croissance qui impose le besoin de scalabilité qui caractérise à mon sens ce que regroupe ce vocable de Big Data. A ce stade, je me permets donc une définition.
Big Data, une approche de la Business Intelligence caractérisée par :

  • une intégration horizontale de données tant internes qu’externes, sous des formats variés et mutables,
  • une architecture distribuée pour le stockage des données et le traitement de l’information,
  • une latence très faible du cycle événement-détection-présentation.

Le mythe des « données non-structurées »

En parlant de « formats variés et mutables », je veux profiter de cet article pour tordre le cou au mythe de l’existence de « données non-structurées ». Si un signal (des données par exemple) n’a pas de structure, il ne contient pas d’information car l’information ne peut s’en extraire que par analyse de cette structure. A titre d’exemple, considérez les deux extraits de fichiers qui figurent plus bas.

Différence entre bruit et données

Dans le second exemple, même si on ne sait pas encore de quoi parle ce fichier, on reconnaît une structure qui permettra son analyse. Dans le premier cas, la présence de bruit ôte tout intérêt au contenu du fichier.

Si un signal est structuré, il est de la donnée et il contient de l’information (quant à savoir si cette information est pertinente, c’est une autre histoire). Sinon, c’est un signal bruité. Bien entendu, un signal dont la structure change reste structuré et c’est la détection de ces changements de structure qui fera toute la différence. Toute part de hasard et d’irrégularité dans la structure d’un signal augmente le bruit de ce signal, c’est certainement le sens à donner à cette expression de « données non-structurées » finalement : des données plus bruitées que la moyenne.

On me rétorquera que des signaux vidéo, des fac-similés de documents et des photographies numérisées sont des données non-structurées. Et bien non, ces signaux viennent sous forme de fichiers ou de flux parfaitement structurés car décodables par un ordinateur. La confusion réside peut-être dans la capacité qu’ont ou, plutôt, n’ont pas les machines à extraire de l’information pertinente de ces contenus.

Prenons un autre cas pour illustrer ce point de vue. Une caméra de vidéosurveillance capte des images et les encode dans un signal vidéo qui peut être enregistré et relu sur n’importe quel ordinateur.

Un humain qui regarde les images peut y identifier des visages, des situations ou des lieux. Ce processus est un processus d’analyse des données et de traitement de l’information. Il n’est possible que parce que les images véhiculent de l’information que l’humain sait interpréter grâce à la capacité de ses aires visuelles cérébrales de reconnaître formes et visages et grâce à la capacité de son cortex pariétal de coller des étiquettes sur ces formes et ces visages. Les techniques de reconnaissance numérique des visages montrent qu’un tel processus est automatisable.

Et si on trouvait autre chose qu’une aiguille dans une meule de foin

Ce qui caractérise Big Data en plus du reste c’est que les données y sont finalement toutes considérées avec la même importance quel que soit leur format.

Pourquoi ? Parce que le temps où on savait quelle information on cherchait dans les données est révolu. La complexité des données et leur masse toujours plus rapidement croissante entraînent que de nouvelles informations dont on ne suspecte pas l’existence sont contenues dans ces données. C’est la métaphore de l’aiguille et de la botte de foin sauf que dans notre botte de foin se cache autre chose qu’une aiguille et nous ne savons pas de quoi il s’agit.

Si les termes de volume, de vélocité, de variété et de versatilité sont insuffisants à définir ce qu’est Big Data, ils n’en demeurent pas moins des contraintes objectives, imposant aux acteurs de la BI d’entreprise de définir de nouvelles approches technologiques pour la collecte, le stockage et l’analyse des données.

Là encore, il est faux de s’imaginer que cette situation est nouvelle. Depuis sa mise en place, le LHC du CERN génère quelques pétaoctets de données chaque année [3]. Là encore, des approches novatrices ont été conçues pour administrer ces données. Le CERN a été familiarisé très tôt avec les problématiques d’administration de l’information et les approches retenues au cours de ses années d’existence opérationnelle étaient tellement intéressantes qu’un de leurs sous-produits a été la conception du Web.

De l’information

Avec la croissance continue des données et leur variabilité, les modèles de connaissance a priori qui ont fait les beaux jours des analystes deviennent plus difficilement applicables. Ces modèles de recherche d’information étaient conçus avant d’avoir des données auxquelles les appliquer d’une part parce qu’on avait une petite idée de la forme qu’allaient prendre ces données et que, dans le cas contraire, on « s’arrangeait » pour concevoir des modèles de données bien adaptés.

Ceci n’est plus possible car les données les plus intéressantes pour une organisation sont désormais celles qui résident hors du système d’information, des données sur lesquelles le seul contrôle possible est de les collecter ou pas. Nous ne pouvons en modifier la structure, nous ne pouvons en modifier le débit.

Dans ces conditions, des modèles de connaissance a posteriori doivent être conçus à partir des données elles-mêmes à partir de détection de corrélation et d’identification de motifs. Et ces modèles doivent aussi s’adapter à la variabilité des données.

Quelle architecture pour Big Data ?

Faisons un bref rappel des contraintes :

  • des données variées, dont la structure peut muter, en grande quantité et à fort débit ;
  • de la détection d’événement en quasi temps-réel ;
  • de l’analyse a posteriori en direct.

Nous avons donc une contrainte temporelle non négligeable car il faut que le système réagisse linéairement à la fréquence des données, une contrainte spatiale très importante car les données prennent de la place et une contrainte de complexité doublée d’incertitude à cause des modèles de connaissance a priori inconnus mais identifiables par l’analyse des données.

De ces considérants, nous pouvons définir quelques patterns qui vont nous permettre de résoudre certaines de ces contraintes.

Contrainte spatiale
  • stockage distribué[4]
  • stockage de données compressées avec compression/décompression en ligne[5]
Contrainte temporelle
  • liaisons de données asynchrones
  • base de données en mémoire[6]

Ces solutions concernent avant tout les fonctions de collecte et de stockage des données qui semblent être plus simples à résoudre que la dernière contrainte, la contrainte de complexité. L’examen des modèles de fouille de données complexes dans un contexte de Big Data fera l’objet de mon prochain article.

 

[1] F. W. Kistermann, « The Invention and Development of the Hollerith Punched Card: In Commemoration of the 130th Anniversary of the Birth of Herman Hollerith and for the 100th Anniversary of Large Scale Data Processing » IEEE Annals of the History of Computing, pp. 245-259, July-September, 1991 (doi)

[2] IBM Corp., « IBM Archives: Frequently Asked Questions » (PDF)

[3] Geoff Brumfiel, « High-energy physics: Down the petabyte highway ». Nature 469: pp. 282–283, January 19, 2011. (lien vers l’article)

[4] M. Placek and R. Buyya, « A Taxonomy of Distributed Storage Systems », Technical Report, GRIDS-TR- 2006-11, Grid Computing and Distributed Systems Laboratory, The University of Melbourne, Australia, July 3, 2006. (PDF)

[5] B. Peterson, « Top five data storage compression methods », SearchStorageChannel, July, 2008. (lien vers l’article)

[6] McObject Corp. « In-Memory Database Systems – Questions and Answers », 2012 (lien vers l’article)


Un commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.