Une question fondamentale est "que faire avec les données massives". Il ne s'agit pas simplement de se dire "nous avons beaucoup de données, faisons

Transcription

1 1

2 Le terme "big data" est très à la mode et naturellement un terme si générique est galvaudé. Beaucoup de promesses sont faites, et l'enthousiasme pour la nouveauté technologique et pour les nouvelles opportunités qui s'ensuivent tendent à faire passer les éventuelles limitations et contraintes au second plan. Quand on gratte un peu, beaucoup de technologies prometteuses viennent avec des limitations qu'on aurait tort d'ignorer. Cette présentation proposera une vue pratique du domaine du big data, en définissant le problème et en présentant d'une manière succincte les solutions existantes avec leurs qualités et leurs défauts. Avant tout, il faudra trouver une définition pour le "big data". Car en définitive, quand peut-on réellement parler de big data? Quand on parle de téraoctets, de peta-octets, d'exa-octets? Ou est-ce que certains projets de la taille du gigaoctet peuvent être qualifiés de "big data"? Et au fond, est-ce que la taille des données est le seul critère important? Est-ce même réellement un critère majeur? 2

3 Une question fondamentale est "que faire avec les données massives". Il ne s'agit pas simplement de se dire "nous avons beaucoup de données, faisons du big data". Plus sérieusement, beaucoup de projets big data ou pas sont lancés sans avoir une vision claire d'où on veut arriver. L'usage qu'on veut faire des données est une décision fondamentale pour lancer un projet big data. 3

4 Quoi qu'on en dise, il y a toujours un problème d'échelle. La technologie est encore loin de pouvoir résoudre des problèmes à la fois de complexité et de taille quelconques. Le "big data" a ses limites, on pourrait presque parler d'un "principe d'incertitude d'heisenberg": plus on a de données, plus la complexité de leur structure et du traitement qu'on en fait sera limitée en pratique. Les ordinateurs quantiques promettent de résoudre cette difficulté, mais on n'est pas encore tout-àfait prêts à les trouver dans un Apple store 4

5 La technologie impose actuellement une série de limitations pratiques aux solutions big data. Les solutions big data sont rarement entièrement transactionnelles au sens où on l'entend dans les bases de données disons "traditionnelles" (c'est-à-dire applicatives). Les bases de données applicatives restent pour l'instant le paradigme majeur en informatique (ERP, applications de comptabilité, applications spécifiques dans divers domaines ) Une base de données à transaction reportée n'est tout simplement pas envisageable dans un environnement applicatif traditionnel (qu'il soit client-serveur ou multi-tiers). Un autre problème typique est celui de la complexité des schémas de données. Pour un traitement efficace, la complexité (càd par exemple l'intégrité référentielle) limite la taille des données pouvant être traitées en pratique. Ces points et d'autres ne posent pas de difficultés pour certains types de problèmes typiquement traités par les projets big data mais empêchent ces solutions de prétendre à l'universalité. 5

6 La question qui vaut de l'or littéralement. Malgré une structuration et une codification de plus en plus poussée des données, 70 à 80% des données (en fonction des analystes: Gartner, IDC) restent non-structurées (texte libre, documents de type traitement de texte ou tableur, PDF, rapports en tous genres et en tous formats, etc.) ça représente une quantité énorme de données potentiellement utiles et utilisables (c'est-à-dire monnayables). 6

7 Quelques commentaires sur cette définition: - On aurait sans doute dû dire "massif ou complexe" massif et complexe est un bel idéal mais dans l'état actuel de la technologie, ces deux conditions sont rarement rencontrées toutes deux. En tout cas pas dans des temps de traitement courts. - "difficile à traiter au moyen d'outils classiques" n'implique pas nécessairement des volumes énormes, comme par exemple dans le cas des données non structurées. - La définition indique clairement que le big data implique l'utilisation d'outils dédiés l'implication est en réalité que ces outils ne prétendent pas à l'universalité, mais traitent des catégories de problèmes spécifiques avec des volumes et/ou complexités de données élevés. - La question du cadre d'application des solutions big data est fondamentale. 7

8 Une fameuse anecdote circule depuis quelques mois dans les milieux du Big Data, qui clairement fait des envieux. Aux Etats-Unis, une jeune femme reçoit un jour au courrier des coupons pour des produits pour bébés: langes, biberons, etc. Son père va se plaindre auprès de la société, parce que sa fille n'attend pas d'enfant. Une semaine plus tard, le père revient s'excuser: sa fille est en effet enceinte et (semble-t-il) elle ne le savait pas elle-même mais les outils big data, eux, l'avaient deviné sur base de ses habitudes de consommation (dont aucun n'échappe aux yeux acérés des outils big data!) Cette histoire et d'autres similaires ont fait prendre conscience à beaucoup de sociétés qu'elles sont (sans doute) assises sur un grand tas d'or inexploité. Cette prise de conscience a fait monter d'un cran et changé très significativement le jeu de la concurrence. Beaucoup craignent de laisser passer le train et de se retrouver largués. Nous n'allons pas ici entrer dans les détails de cette problématique de société, bien qu'elle soit très intéressante et au cœur du succès du big data. Ce que je désire évoquer dans cette présentation est l'aspect technique et organisationnel du Big Data. Peter Hinssen, l'analyste bien connu et réputé dans les domaine des technologies de l'information, l'a très bien formulé dans un ouvrage récent (disponible librement sur Internet, et que je vous recommande). Le big data, ce n'est pas (seulement) une question de volume. L'important, ce sont les choses "cool" qu'on peut faire avec ces grands volumes de données. 8

9 Bien sûr, le traitement de données massive échappe largement à la capacité humaine de traiter l'information avec le risque que les analyses (souvent heuristiques) produisent des effets de bords pervers ou soient utilisées abusivement par certaines sociétés (voire adaptées délibérément dans ce but). Si l'on met de coté les buts illégitimes, le recoupement de l'information devient primordial pour affiner les modèles par exemple le recoupement entre information structurée et nonstructurée peut se révéler très précieux. 9

10 10

11 11

12 12

13 13

14 Les bases de données "orientées graphe" permettent de stocker des relations complexes d'une manière persistante. Chaque nœud du graphe peut contenir des informations différentes (clé/valeur), et les arêtes du graphes peuvent aussi être associées à des propriétés quelconques (clé/valeur également). On voit dans ce petit exemple tout à la fois l'intérêt et la puissance expressive de ces systèmes et leur complexité potentielle. Si j'avais voulu modeler toutes les relations entre tous les personnages de la série "les Simpsons", j'aurais eu un graphe énorme, dont la gestion n'aurait pas été triviale. Ce genre de graphe est intéressant pour la recherche, peutêtre moins pour des bases de données opérationnelles. Ce genre de technologie est encore nouvelle et relativement peu utilisée dans l'industrie, l'avenir nous dira si cette complexité reste gérable dans l'utilisation pratique. 14

15 15

16 16

17 Le Cloud ne règle pas ce problème de la fragmentation. Il peut simplifier la maintenance et donc améliorer légèrement le problème cependant, le Cloud apporte également ses propres complexités. Il ne serait guère raisonnable de porter des données sur le Cloud sans s'inquiéter des questions de légalité (propriété des données), de disponibilité (SLA), financières (stabilité des coûts) et de sécurité (protection contre le vol de données), ou de provisionner des capacités supplémentaires sans s'inquiéter des coûts ou de l'impact sur la fonctionnalité ou la performance. Le Cloud rend peut-être certains problèmes caducs, mais il en crée d'autres qu'il convient de ne pas ignorer. 17

18 18

19 19

20 20

21 21