#TeamOpenData

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

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 : Elections municipales_2020_Tour 1_ Poitiers_Résultats — Grand Poitiers Open Data

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 : 7 - Réduire le volume unitaire des jeux de données - GREENDATA pour un impact maîtrisé des données


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

  • :green_circle: D’accord,
  • :orange_circle: Mitigé,
  • :red_circle: Pas d’accord.

0 votant

Vous avez des suggestions ?
Commentez ci-dessous !

1 Like

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.

1 Like

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.

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).