Quelques points de repère
Avec l'entrée du monde dans l'âge de l'information, à la fin des années 1980, les utilisateurs de micro-ordinateurs et du réseau mondial Internet ont rapidement compris que l'activité humaine allait laisser derrière elle une quantité de données bien plus importante qu'auparavant. Aujourd'hui, chacune des applications informatiques existantes génère des données relatives à son utilisation. Ces données deviennent de plus en plus volumineuses du fait de l'intensification des usages. En outre, le nombre d'applications déployées est lui aussi en augmentation. De la même manière que le nombre de kilomètres de voies ferrées a subi une croissance exponentielle durant la révolution industrielle, l'usage de services connectés se popularise à vitesse grand V.
Nous dépendons de plus en plus d'Internet et du Web pour des services ordinaires, par exemple dans les transports, les achats et la communication ; nous sommes en permanence accompagnés de smartphones équipés de GPS, gyroscopes, appareils photos, chacun de ces équipements étant lui-même source d'émission de données. Nos frigos, balances, même nos brosses à cheveux, tous les objets du quotidien sont de plus en plus fréquemment équipés de capteurs connectés. Nous partageons un volume croissant d'informations, avec de plus en plus de monde, que ça soit par SMS, e-mail ou via les réseaux sociaux. Tout ceci est peut-être pour vous un lieu commun, notamment si vous avez déjà une bonne connaissance de la manière dont fonctionne le Web ou l'Internet au sens large. Mais il peut être difficile d'obtenir une compréhension intuitive de ce que représentent toutes ces données. Tentons une illustration.
Chaque caractère stocké dans un ordinateur requiert environ quatre octets quand il est stocké au format utf-8, non compressé (c'est une moyenne approximative). En anglais, la longueur moyenne d'un mot est de 5.1 caractères (WolframAlpha). Un mot fait donc en moyenne 20.4 octets.
En admettant que nous prononçons en moyenne 1963 mots par jour (Rayson, P., Leech, G., and Hodges, M. (1997)), ces mots retranscrits sous forme de texte représenteraient environ 40 kilooctets. Pour 7.4 millards d'êtres humains formant la population mondiale (Wikipedia), l'ensemble des mots prononcés chaque jour pèserait 292.5 To. D'un autre côté, Facebook génère 4 pétaoctets de nouvelles données par jour (source : Facebook research), soit 13.5 fois la quantité de données prononcées à l'oral dans le monde. C'est comme si chaque être humain écrivait 13000 mots chaque jour sur Facebook. Ou alors, cest comme si chacun des êtres humains ajoutait 13 images sur Facebook, en partant du principe qu'une image vaut mille mots (ce qui n'est pas très loin de la vérité grâce à la compression jpg). Et Facebook a beau être une des applications les plus utilisées du Web, ça n'est qu'une parmi plusieurs.
Quid des applications scientifiques ? Le radiotéléscope Square Kilometer Array, actuellement en construction, génèrera 7 pétaoctets de données brutes par seconde en 2019 (source : ERCIM News), donc 604.8 exaoctets par jour. Ca fait tout de même 151200 fois Facebook. En gros, c'est comme si chacun d'entre nous était inscrit à 151200 réseaux sociaux. Si vous trouvez qu'on est déjà assez envahis par les réseaux sociaux...
Quant au Web dans son ensemble, on estime que les données qu'il génèrera pendant l'année 2020 représenteront 40 zettaoctets (source : IDC.com). Difficile de prédire à quoi ressemblera le Web à ce moment, même s'il est probable qu'il contiendra encore une bonne proportion de vidéos de chatons ;-) .
Résumons :
Unité | Abbréviation | Taille en octets | Exemple |
|---|---|---|---|
1 octet |
| 1 | 4 octets ≃ Un caractère au format utf-8 |
1 kilooctet | ko | 10³ | 20 ko ≃ Mots prononcés par une personne, par jour |
1 mégaoctet | Mo | 10⁶ | 3 Mo ≃ Texte d'une édition quotidienne du New York Times |
1 gigaoctet | Go | 10⁹ | 1 Go ≃ Mots prononcés par une personne durant une vie |
1 téraoctet | To | 10¹² | 593 To ≃ Mots prononcés par l'ensemble de la population mondiale, par jour |
1 pétaoctet | Po | 10¹⁵ | 4 Po ≃ Données générées par Facebook, par jour |
1 exaoctet | Eo | 10¹⁸ | 605 Eo ≃ Données générées par le téléscope SKA, par jour |
1 zétaoctet | Zo | 10²¹ | 40 Zo ≃ Données générées par le web en 2020, par an |
Des données aux métiers
Ces volumes de données soulèvent des interrogations : comment les stocker, les filtrer, les analyser ?
Comme on peut le voir, des volumes de données existent à des échelles très différentes, variant de 21 ordres de grandeur. À partir de quel moment peut-on parler de "Big Data" ? Par exemple, à l'échelle de Facebook, 100 Go représentent un faible volume de données. Cependant, tout le monde ne possède pas un pétaoctet de données à analyser chaque jour. Est-ce que cela signifie que seuls les GAFA (Google, Apple, Facebook, Amazon) sont en mesure de faire réellement du big data ?
Nous considérerons que l'on fait du big data à partir du moment où la quantité de données excède la faculté d'une machine à les stocker et les analyser en un temps acceptable.
De manière générale, un bon indicateur consiste à comparer la taille des données à la RAM disponible ; si les données sont trop grosses pour être stockées en RAM, il y a de bonnes chances que l'on soit confronté à un problème de big data.
Mais il serait réducteur de considérer qu'il suffit de stocker des données volumineuses pour faire du big data. Sans analyse, le stockage ne sert à rien. Or, qui dit gros volume de données, dit grosse quantité de ressources de calcul nécessaires pour analyser ces données. Prenons l'exemple d'une application web : celle-ci génère 1 Go de logs chaque jour. Nous désirons analyser ces logs pour déterminer le nombre de pages web visitées pour chacun des utilisateurs. En Python, cela donnerait :
def count_visits(logs):
visits = {}
for user in logs:
if user not in visits:
visits[user] = 1
else:
visits[user] += 1
return visits
La complexité moyenne en temps de cette fonction est de O(N) où N est le nombre de lignes de logs : la complexité est proportionnelle à la taille du fichier de logs. Imaginons que cette fonction mette une heure tout les jours à traiter nos 1 Go de logs. Si l'application devient très populaire et que le fichier de logs quotidien grossit jusqu'à 1000 Go, il faudra donc 1000 heures pour exécuter cette fonction. Or, une journée dure moins que 1000 heures : cela pose un problème.
La solution à notre problème consiste à paralléliser les calculs sur plusieurs machines différentes. Mais il se pose alors un certain nombre de questions assez difficiles à résoudre :
Quelle stratégie adopter pour distribuer les calculs entre les machines ?
Comment distribuer les données entre les machines ?
Comment agréger les résultats des différentes machines ?
Que faire en cas de panne d'une des machines lors de l'exécution du calcul ?
Comment faire en sorte que l'architecture déployée ne coûte pas une fortune ?
On peut le voir, le déluge des données crée de nouveaux besoins, tant en matière d'infrastructures de stockage que de calculs. Votre rôle, en tant que Data Architect, sera d'apporter des solutions à ces besoins.
Science et architecture
Si le big data suscite autant d'intérêt, c'est parce qu'il présente à la fois des défis et des opportunités majeurs. Les défis sont techniques, mais ils valent la peine qu'on s'y intéresse parce que les données concernées sont source de valeur, à condition de savoir les exploiter correctement. Par exemple :
Comment recommander à un utilisateur un article à acheter, en fonction de l'historique de ses achats et du comportement des autres utilisateurs ?
Comment prédire l'apparition d'un tsunami et ses conséquences sur la population ?
Comment trouver les images les plus similaires à une autre image ?
Les algorithmes utilisés pour résoudre ces problèmes ne sont pas du ressort des data architects ; ce sont les data scientists qui en réalisent la conception. Cependant, les data scientists ne savent pas -- la plupart du temps -- faire passer à l'échelle leurs algorithmes. C'est le rôle des data architects que de fournir aux data scientists les architectures qui permettront de faire tourner leurs algorithmes.
