7 - Réduire le volume unitaire des jeux de données

mbrient · Juillet 12, 2022, 2:10

CONTEXTE

Les premières externalités négatives de la donnée sont liées à son stockage et sa diffusion qui nécessitent une infrastructure matérielle (réseau, et data centers), mais aussi des terminaux utilisateurs. Cela se traduit naturellement par de la consommation de matière première (minerais, eau, beaucoup d’eau) pour produire ces équipements, et de la consommation électrique.

Non seulement la production de données est colossale mais elle croit à une vitesse vertigineuse en raison des usages, des multiples sources (IoT) et leur distribution/duplication via internet. Le stockage passe d’une gestion locale à une diffusion mondiale, faisant héberger ou consommer les données à l’autre bout de la planète.

Nous le savons, l’OpenData propose généralement des jeux de données au volume limité, sans commune mesure à certaines ressources ou services mobilisant des données en temps réel, voire des données cartographiques. Mais il demeure une importante marge de progression pour réduire et adapter au mieux les jeux de données aux besoins.

En 2021, on estimait la part du numérique à 12% de la consommation totale d’électricité et à 10% de la production des Gaz à Effet de Serre (GES)…et la part de la data dans le numérique est approximativement de 15% de l’économie numérique. Par ailleurs, la production de donnée au niveau mondial est exponentiel. On a produit autant d’informations (données) en 4 ans que depuis le début de l’humanité. https://www.statista.com/statistics/871513/worldwide-data-created/

Une attention particulière doit donc être portée sur la volumétrie des données produites, utilisées par les métiers, exposées et archivées.

DESCRIPTION DE LA BONNE PRATIQUE

Impact important sur la réduction de l’empreinte environnementale :

1 - choix du format de fichier : choisir le format plus plus sobre lorsque cela est possible. Par exemple, Il peut y avoir un rapport de 1 à 10 entre le volume d’un fichier au format .csv et les mêmes données dans un format .xls

2 - réduire le nombre de ressources : la co-existance fréquente de multiples formats (csv, json, xls, shp, …) pour un même jeu de données doit poser la question de la pertinence de cette multiplication. Sans la bannir, cette pratique doit être mise en oeuvre si elle est vraiment indispensable (il s’agit souvent d’un confort pour l’usager).

3 - proposer la récupération des informations sous forme d’API l orsque le fichier est trop volumineux. On ne réduit pas le fichier source mais uniquement les données transmises. (Voir 8 - Proposer un accès aux données par API)

Impact modéré sur la réduction de l’empreinte environnemental :

4 - formater le fichier pour éviter les redondances. On trouve parfois plus pratique de publier les données au format tabulaire alors que certains jeux de données sont plus légers dans un format type json. Vouloir les rendre tabulaires multiplie énormément les redondances dans les chaines de caractère communes.

5- réduire les informations aux données essentielles (filtre à la production). Supprimer les colonnes inutiles et réduire la longueur des champs dans la mesure du possible. Par exemple, une précision géographique ne nécessite généralement pas plus de 5 décimales (soit l’ordre de grandeur du mètre en France métropolitaine). idem pour le nombre de décimale, deux ou trois devraient suffirent. La taille des champs textuel pourraient être volontairement limités en nombre de caractères (de quelques dizaines à quelques centaines selon le cas).

6 - fragmenter et compresser le fichier pour permettre des téléchargements partiels à l’utilisateur. Par exemple, un fichier des résultats des 10 dernières élections peut être découpé en 10 fichiers, un pour chaque élection.

RETOURS D’EXPERIENCES

Accès aux résultats des élections à Grand Poitiers

La manière de gérer les données des élections publiées sur le site du Grand Poitiers est remarquable :

un jeu de données indépendant pour chaque élection
aucun jeu de donnée ne dépasse 40 Ko

Lien : Portail de données ouvertes Grand Poitiers

A l’inverse, une autre collectivité publie par exmple le résultats de toutes les élections depuis 1992 dans un même fichier. Le fichier .csv résultant est de 42 Mo, soit x1000 plus volumineux que celui d’une seule élection à Poitiers.

Volumétrie des jeux de données limitée par les éditeurs de portails

Certaine plateforme comme OpenDataSoft dispose par exemple de quotas limitant son usage selon différentes métriques :

Taille maximum d’un jeu de données : 7.500.000 enregistrements
Taille maximum d’un fichier : 240 Mo

Au-delà, il convient soit de compresser le jeu de donnée, soit de fragmenter le jeu de donnée en plusieurs fichiers.

EVALUATION

Priorité :

prioritaire,
recommandée,
pour aller plus loin

Mise en œuvre :

facile,
moyenne,
difficile

Exemple(s) d’indicateur(s) de pilotage :

Volume moyen des fichiers disponibles en Mo
% de jeux de données supérieur à 240 Mo

Exemple de pilote : Délégué ou référent aux données ouvertes et responsables
Service à associer : DSI

Lien vers la fiche : BP 6 - Réduire le volume unitaire des jeux de données - GreenData- pour un impact environnemental maîtrisé

Votre avis nous intéresse.
Que pensez-vous de ces propositions ?

D’accord,
Mitigé,
Pas d’accord.

0 votant

Vous avez des suggestions ?
Commentez ci-dessous !

nicolas-bonnel · Juillet 22, 2022, 7:33

Bonjour,

Je viens de découvrir le format de fichier parquet, qui permet de réduire considérablement la taille des jeux de données pour le stockage : Probablement la meilleure alternative au stockage CSV : Parquet Data - Geekflare

Le plus gros problème que je vois par rapport au CSV est l’accessibilité pour des personnes non techniques, il y a l’air d’avoir quelques utilitaires pour visualiser les fichiers, mais je n’ai pas trouvé de plugin pour lire ce format de données avec Excel ou Libre Office (il y a un plugin Excel, mais qui a l’air orienté pour requeter des fichiers en ligne et pas sur disque en local).

Après si on compare avec des formats comme JSON, XML ou même SHP, cette question d’accessibilité ne se pose plus trop.

Flacombe · Juillet 24, 2022, 8:42

N’ayant pas de chiffres ni de contexte précis, il n’est pas possible de classer les impacts tel que fait ici.
L’impact du stockage est envisageable puisqu’il faut fabriquer des dispositifs de stockage (pas que des disques durs, des bandes magnétiques et des SSD également).
En revanche, pour la diffusion je ne vous suit pas. Au chapitre 1 vous indiquez à juste titre que l’usage des infras existantes pour le transit des données n’a pas d’impact (sauf à éteindre ou redimensionné à la baisse les installations). Est-ce cohérent ?

Non seulement la production de données est colossale mais elle croit à une vitesse vertigineuse en raison des usages, des multiples sources (IoT) et leur distribution/duplication via internet. Le stockage passe d’une gestion locale à une diffusion mondiale, faisant héberger ou consommer les données à l’autre bout de la planète.

En quoi est-ce un problème, concrètement ?

Soyons factuels et précis.
Quels sont les jeux de données consommés à l’autre bout de la planète ? Quels sont ceux consommés localement ? Peut-on conclure de manière si tranchée ?

Encore une fois, sans comparer avec les externalités positives à disposer des données concernées ?

Le problème est mal posé ici. L’objet n’est pas le choix tabulaire ou arborescent pour apporter une solution à une présence de trop grande redondance.
On trouvera autant de cas pour lesquels le csv est plus lourd que le json et vice versa.

Le problème de fond serait que le jeux de données ne respecte pas la forme normale de Boyce-Codd, en ayant des attributs qui présentent des dépendances pour la définition d’un identifiant.
Donc une révision de la structure, en découpant le jeu de données en plusieurs tables est plus adapté pour réduire cette redondance.

Nous avons des obligations réglementaires en France qui obligent au positionnement de certains éléments au centimètre ou la dizaine de centimètres; Cette position ne tient pas assez compte de ces obligations.

Je ne comprends pas quel est le fondement d’une telle affirmation. Elle me semble impossible à concilier avec la multitude de cas d’usages qui auront besoin de plus, inévitablement.

bninassi · Août 4, 2022, 1:45

le point « 3 - proposer la récupération des informations sous forme d’API » : préciser que cette API doit permettre d’effectuer des requêtes pour filtrer/trier les données à la source (ça semble implicite, mais il vaut mieux le rendre explicite) : il est toujours possible de produire une API ne permettant que de récupérer l’intégralité des données (ce qui n’est pas le but recherché ici).

cquest · Août 12, 2022, 8:11

Qui est ce « on » ?

On trouve tout et n’importe quoi comme chiffre que l’impact environnemental du numérique (surtout ceux du shift project très décriés mais trop souvent cités).

J’archive plus de 300 portails opendata français pour opendatArchives, cela occupe grand maximum 50To, y compris les archives, et 2/3 de ce volume provient des photos aériennes.

Tout tient sur un unique serveur qui assure bien d’autres services avec une consommation moyenne de 300W. Le backup, assuré par une autre machine a une consommation moyenne quotidienne de moins de 20W (allumé moins de 2h par jour pour le backup).

Cela me semble donc un faux problème, mais très à la mode.

Bof bof bof…

ok pour les décimales inutiles sur les coordonnées géographiques 6 ou 7 suffisent pour des lat/lon, une pour des coordonnées projetées.
Sur la longueur des champs textuels, les tronquer est une perte d’information.
Les colonnes inutiles… qui jugera de l’utilité ? Ne pas présager des usages et ré-utilisations !

Ce qui est inutile, c’est de reprendre dans un jeu de données des champs qu’on peut obtenir par croisement avec un référentiel. Si on a le code INSEE d’une commune, pas besoin de refournir son nom, son département, sa région ou autre (un grand classique). Cela est valable pour tous les jeux de données de référence (service public de la donnée) ou l’identifiant unique devrait être suffisant.

Compresser, c’est le minimum (pour le stockage ET le transfert), dans de très rares cas on a besoin de fragmenter un fichier compressé (4Go est une limite commune pour fragmenter).
Pour des données stables, on peut aussi fournir un fichier pour chaque millésime.

Ceci est plus dû à la lenteur de téléchargement de jeux de données complets sur cette plateforme trop API centrée dans sa conception initiale.

Donc avis (très) mitigé.

noirbizarre · Octobre 10, 2022, 5:09

Je vais aller dans le même sens que @cquest (dont je partage les arguments) et rajouter mes réflexions.

Quel objectif ? Quel impact ?

L’intro passe de statistiques sur les données mondiales tout métier confondu à une liste de recommandation pour l’open-data. Rien que la dessus, j’ai plusieurs questions:

quelle est la part de l’open-data dans ces stats ?
quelles actions sont prise pour le gros des données (qui n’est clairement pas l’open-data) ?
d’où viennent ces recommandations ?
quel est l’effet attendu de ces recommandations ?
quel moyen sont mis en oeuvre pour mesurer la situation actuelle puis l’impact ces mesures ?

Ordres de grandeurs

Si effectivement chez les GAFAM la volumétrie de données nécessite une infrastructure dédiée où la consommation du stockage devient un centre de coût (financier et énergétique), la on parle de l’open-data dont la volumétrie pour la France est rappelée: 50To dont 2/3 d’orthophotos.
Si on prend les 1/3 (16,6 To) et disons que magiquement par suppression arbitraire on gagne 10% (1,6 To) on passe de 16,6To a 15To. Disons que ça permet d’économiser 2DD de 1To (c’est pas le cas mais imaginons), même en prenant 10W/DD comme conso (en pratique c’est plutôt 5~8W) ça fait 20W d’économisés dans le meilleur des cas.
Est-ce vraiment cet ordre de grandeur d’impact qui est recherché ? A quel prix ?

Ça ressemble fortement a de la micro-optimisation sur un macro-problème, surtout en comparaison des volumétries dont parle l’introduction (cf. Géants du Web — Wikipédia). Les références de l’introduction n’ont aucun ordre de grandeur comparable, et je pense que chaque acteur cité sur la page Wikipedia produit a la seconde ce que l’opendata français représente après 10 ans tout cumulé.

Est-ce une économie d’énergie ?

En terme de conso, on a GPU > CPU > DD: c’est le traitement de la donnée qui consomme plus que le stockage.
Donc une solution qui consiste a devoir systématiquement retraiter les données (parce que c’est de la données publique et que malgré ces recommandations, il est peu probable qu’il y ai du budget supplémentaire chez les producteurs pour changer leur format) implique un traitement supplémentaire ce qui paradoxalement va créer de la consommation d’énergie supplémentaire donc l’opposé de l’effet recherché.
Il en va de même de l’API, qui si elle est souhaitable pour des gros jeux de données, encore plus s’ils sont mis à jour fréquement, peut aussi devenir un surcoût inutile si l’on veut récupérer toutes les données ou si l’API est plus complexe et/ou plus verbeuse que la donnée seule…

Plusieurs format et API

Le même raisonnement s’applique pour les formats et l’APIfication:

1 API == 1 service qui tourne et qui consomme EN PLUS du stockage. Il n’y a pas systématiquement un bénéfice à une API, c’est vraiment l’usage qui doit déterminer ça.
a volumétrie équivalente, une API implique souvent plus de données transférées (voir beaucoup plus si elle est mal faite comme c’est souvent le cas) et la quasi-impossibilité de mettre en cache (sur toute la chaîne) comme il est possible de le faire avec des fichiers statiques: bilan énergétique négatif
a chaque fois qu’il n’y a qu’un seul format proposé, charge a l’usager de le convertir lui même (donc on remplace 1 seul conversion par n conversions ou n est le nombre de personnes qui veulent un autre format que celui proposé): bilan énergétique négatif

Par contre, un bon design d’API ou d’architecture va permettre d’économiser beaucoup d’appels et ça par contre ça peut avoir un impact non négligeable.

Mais API vs fichiers statiques, c’est avant tout le besoin qui détermine le format, pas la consommation énergétique. Donc pour 3, je pense que dans les cas où il y a besoin exprimé, il faut une API. Mais s’il n’y en a pas de besoin exprimé, éviter de faire une API qu’il va falloir opérer et maintenir (donc des coûts supplémentaires).

Par contre, plutôt que la diffusion dans plusieurs formats bienvenue du point de vue de l’accessibilité, c’est du côté de la duplication/fragmentation de la production et de l’hebergement que je regarderai (données produite plusieurs fois, données recopiée plusieurs fois sur différentes plateformes publiques, données produites par différent acteurs avec un coût d’intégration élevée…)

Open-Data vs business model

Ceci répond a des critères de rentabilité et stabilité, et non à des critères énergétiques.

Une limite arbitraire imposée à toutes les données n’a aucun sens sauf si elle correspond soit a une limite physique, soit a une contrainte commerciale. De plus, je pense qu’ODS étant dans une démarche commerciale, demain si un client a des besoins qui ne rentrent pas, je suis a peu prêt sur que la réponse d’ODS face a une demande, potentiellement tarifée, ne sera pas « attention, ce n’est pas sobre » mais plutôt « pas de problème, on s’adapte »

En Vrac

point 4: c’est de la normalisation. Donc oui, c’est souhaitable quand c’est possible SI ET SEULEMENT SI le données à normaliser existent aussi en open-data. Je pense que c’est déjà une demande de l’écosystème et un axe de travail de la plupart des acteurs.
point 5: orthogonal au principe de base de l’open-data, rien a rajouter sur ce que Christian dit
point 6: rien a rajouter sur ce que Christian a dit

Réflexion

Si le besoin est de faire des économies d’énergies (et je suis très sceptique sur l’impact maximum que cela peut avoir), peut-être que la réponse est plus dans le fait que @cquest doive archiver 300 portails (donc des services ou des serveurs, dont certains probablement surdimensionnés) plutôt que dans le stockage.
Sur ces 300 portails, je suis persuadés que certains n’existent que pour des motifs politiques ou de communications et pourrait être mutualisés mais pourtant c’est bien là qu’il y a des économies d’énergies à faire en mutualisant (et je ne parle même pas des sites vitrines qui accompagnent souvent ces portails)

Mais plus généralement par rapport a la démarche, les chiffre cités correspondent a une consommation mondiale tout métier confondu dans laquelle la part de l’opendata est ridicule voir invisible par rapport au reste. Peut-être prioriser les endroits où il y a vraiment du volume pour la conso énergétique (ex: streaming, mining, gaming, data brokers…) et donc des viviers d’économies potentielles avant de réduire l’accès marginal des citoyens à leurs données ouvertes.

Je vais même aller plus loin sur le sujet de la données produite par les services publiques: si l’opendata est tout petit (notamment parce qu’il y a des contraintes comme l’absence de données persos…), il y a par contre plein de données non publiées mais collectées pour d’autres missions (et dont la version open-data est souvent un sous-ensemble) ou encore des offres commerciale publique de production de données pour des acteurs privés… En tant que citoyen, j’aurai beaucoup de mal à entendre que d’un côté on dégrade volontairement les données ouvertes pour de la communication écologique mais sans gros impact et que de l’autre ça ne remet pas en question certains usage commerciaux bien plus énergivores pour une poignée d’acteurs privés qui ne seront ni audités, ni même inquiétés par cette démarche alors que certaines de ces consommations d’énergie pourrait être économisées ou mutualisées (par l’opendata par exemple)

nicolas-bonnel · Octobre 10, 2022, 5:23

Je profite de discussions que j’ai vu passer ailleurs pour soulever un problème qui me dérange dans la formulation du post initial : le vote concerne l’ensemble des 6 propositions, alors qu’on peut être d’accord avec certaines et pas d’accord avec d’autres.

mbrient · Novembre 3, 2022, 11:31

@nicolas-bonnel @Flacombe @bninassi @cquest @noirbizarre
merci pour vos retours très pertinents et bien compris. Nous entendons bien la limite de ces recommandations.
Nous avons de fait rajouté un chapitre « ordre de grandeur » et fait évoluer cette bonne pratique à partir de vos commentaires. D’autres itérations suivront.