Oui, tout à fait, normalisation puis compression ce qui ramène au final à des volumes équivalents tout en simplifiant énormément les usages.
2 « J'aime »
Il y a peut-être une incompréhension sur la notion de données « nestées » dans un fichier CSV.
Si une donnée « nestée » est une donnée multi-valuée (ex. pour un champ « couleur », la valeur est à la fois rouge, vert et orange ou bien pour un champ « réponse » d’un QCM les valeurs cochées sont 1, 2 et 4).
Dans ce cas, si la valeur retranscrite dans un fichier CSV est un valeur unique composite, « rouge-vert-orange » ou bien « 1,2,4 », effectivement c’est difficilement exploitable et non recommandable.
Si par contre, c’est retranscrit comme une dénormalisation avec duplication des lignes pour faire apparaitre chaque valeur « rouge », « vert », « orange » ou bien chaque valeur « 1 », « 2 » et « 4 », on retombe sur les cas d’usage habituels.
Je viens de regarder sur data.gouv.fr, pour les IRVE, le format proposé est bien uniquement le csv voir lien dataset IRVE ici). Peut-être est-il accessible ailleurs en format compressé ?
Idem pour les données de la qualité de l’air (lien ici) qui sont accessibles en CSV (et XML) malgré une taille importante (11Mo par fichier quotidien).
Par ailleurs, le guide Etalab (lien ici) fait bien référence au format CSV uniquement et ne parle pas de CSV compressé (est-ce volontaire ?).
Le fichier peut être compressé ou non ce qui changera l’espace de stockage, mais pas forcément la bande passante pour le transférer car les serveurs et clients modernes vont demander un transfert compressé (gzip le plus souvent).
On peut aussi utiliser un système de stockage nativement compressé (c’est mon cas avec ZFS) qui économisera l’espace sans effort 
Pour la sphère privée publique, je rappelle aussi l’existence du RGI, référentiel général d’interoperabilite, qui liste les formats de fichiers ainsi que les algo de compression à utiliser.
Il est préférable de ne pas être trop original si on veut un maximum d’interoperabilite !
2 « J'aime »
Merci pour cette info concernant la compression à la volée (intéressant).
J’ai également regardé rapidement le RGI (dernière version de 2015) et notamment ce qui était dit sur le CSV (cf ci-dessous).
Cotation : En fin de vie *
CSV est un format informatique d’échange de données ouvert représentant des données
tabulaires sous forme de valeurs séparées par des virgules.
D’autres variantes de séparateur de champ peuvent être utilisées, notamment lorsque la virgule
est un élément signifiant d’une donnée. L’utilisation des séparateurs de champs doit donc être
utilisée avec circonspection et adaptée au contexte sous peine de rendre le fichier inexploitable.
Ce format est retenu dans le RGI par exception. Il doit être évité car il n’est pas nécessairement
interopérable d’une plateforme à l’autre, la spécification précisant uniquement le format des fins
de ligne mais ne précisant pas l’encodage à utiliser pour le texte en lui-même et pour les
séparateurs (la RFC mentionne uniquement un encodage US-ASCII).
Note importante : Le standard CSV est au statut recommandé uniquement pour les échanges
entre application et utilisateur. Pour tous les autres cas, il est considéré en « fin de vie ». Le
standard XML est à privilégier pour les échanges entre applications ou systèmes, qui n’impliquent
donc pas d’utilisateurs.
Les chaines de caractères peuvent être échappées (via des double quote) et il est possible d’avoir des champs qui contiennent des virgules dans un fichier utilisant le séparateur comme virgule.
Bien que ce soit un format textuel, on manipule en général le CSV avec un logiciel dédié (comme libre office) ou des librairies dédiées, et ils gèrent plutôt bien ces aspects d’échappement des caractères spéciaux.
La norme est très restrictive puisque :
- elle ne connait que les caractères ASCII (pas les UTF)
- elle n’identifie qu’un séparateur : la virgule (pas le « point-vigule »)
- elle n’autorise les caractères « virgule », « fin de ligne », « saut de ligne » et « guillemet double » que dans les champs « quotés » (encadrés par deux guillemets doubles),
- seul le « guillemet double » peut être échappé (par un autre « guillemet double »)
Aujourd’hui, effectivement les solutions logicielles ont évolué pour être plus permissives et pour s’adapter aux évolutions (le RFC4180 date de 2005).
On est donc confronté à un standard obsolète et dont des variantes et extensions sont appliquées (sans trop de difficultés).
A mon avis, la qualification du RGI reste valide (notamment la cotation « en fin de vie » puisque depuis 2005 aucune évolution du standard n’a été effectuée malgré ses limitations).
Un RFC c’est destiné à évoluer et oui, les pratiques se sont enrichies (UTF et quotes).
La pratique du ; est par contre peu recommandable et provenant souvent de notre usage de la virgule comme séparateur décimal.
1 « J'aime »
Merci pour avoir ouvert la discussion, qui est dynamique 
J’ai longtemps utilisé du .csv, en adhérant au principe du dénominateur commun, utilisable par tous, non techniciens ou techniciens.
Sauf que en pratique cela a l’inconvénient du dénominateur commun. Pour l’ouvrir dans Excel les utilisateurs non techniques ont fréquemment des problèmes pour gérer les séparateurs et l’encoding. Pour l’ouvrir avec un logiciel d’analyse, cela est souvent pénible de gérer les types et l’encoding. Et c’est peu efficace à lire/écrire.
J’ai récemment découvert le bonheur du format parquet pour de la lecture/écriture de petits fichiers avec pandas (python). Puisque c’est binaire, le typage est vérifié à l’écriture et conservé à la lecture. Même les (multi-)index sont conservés. Sans parler du gain d’efficacité énorme pour les gros fichiers.
Pour publier des données, lorsque la donnée est essentiellement tabulaire et préparée programmatiquement, nous allons dorénavant privilégier le double format : .xlsx pour les non techniciens, et .parquet pour les techniciens (possible depuis peu sur datagouv ).
On faisait déjà du double .xlsx / .csv, mais plutôt que d’ajouter un troisième format, il semble préférable de remplacer .csv par .parquet (je suis preneur d’avis contraires pour des types d’utilisateurs que je n’identifie pas).
A noter que .parquet est conçu pour gérer efficacement les données imbriquées. Je n’ai pas encore beaucoup d’expérience avec, mais ça paraît pratique pour faire des aller-retours avec des outils manipulant un format tabulaire, tant que les listes sont dans des « feuilles » du schéma (pas de listes d’objets/dictionnaires).
Note bis: avec DuckDB, parquet permet d’intégrer directement les données dans des outils de BI (PowerBI, Metabase, Superset, etc.), ce qui pose toujours des problèmes avec des fichiers csv non typés.
2 « J'aime »
Que disent les stats de téléchargement des différents formats ?
Encore le RGI… XLSX n’est pas RGI compliant, parquet non plus, CSV oui…
1 « J'aime »
Le commentaire est intéressant car il pose la question des critères à respecter ou non pour être un bon format d’échange (les critères étant par ailleurs liés au type d’usage et d’utilisateurs visé).
Par exemple :
- est-ce que le codage d’un nombre réel doit garantir qu’un nombre codé sur 32 bits (ou 64 bits) sera bien relu avec la même valeur pour le même codage (auquel cas les codages textuels comme JSON ne sont pas adaptés car ils n’intègrent pas de niveau de précision) ?
- est-ce qu’il suffit d’être open-source pour pouvoir être un format d’échange (par exemple dans le cas de parquet, le format semble intégrer de nombreuses options et modes de codage ce qui compte tenu de la complexité induite pourrait limiter l’apparition de solutions concurrentes pour coder ou décoder ce format) ?
- est-ce que d’autres critères sont à intégrer ? Par exemple une compatibilité ascendante et descendante, un stabilité du format, le mode de gouvernance des évolutions du format ?
- qu’est-ce qu’on entend par format d’échange :
- un format réversible (le résultat du décodage d’un objet codé doit être identique à l’objet d’origine) ?
- un format d’export (format non réversible) ?
- un format pérenne (relisible au bout d’un temps long) ?
- un format facile d’accès (accessible en lecture ou écriture sur tout type de plateforme/environnement et avec des logiciels nombreux et facilement accessibles / utilisables) ?
J’en profite également pour indiquer que je diffuserai à l’issue de ces échanges une synthèse des contributions de chacun qui sera également accompagnée d’un sondage effectué sur Mastodon auquel vous pouvez encore participer avant dimanche soir (52 contributions à ce jour).
Une valeur codée sur 32 ou 64 bits n’indique pas la précision de la valeur en question.
Quand on voit des coordonnées géographiques avec 12 décimales, ça ne veut pas dire qu’elles ont précision micrométrique. Elles ont juste été converties d’une projection à une autre.
C’est de toute façon une représentation d’un nombre, surtout si c’est un float, là où en textuel on est sûr de chaque chiffre composant le nombre
Non de mon point de vue. Le XLSX est « ouvert » (ou documenté) mais n’en est pas moins une horreur.
La complexité de lecture est un sérieux problème. Le JPEG2000 en est mort à cause de ses options trop nombreuses. C’est facile d’en générer, très difficile d’être capable de lire et décoder toutes les subtilités du format. On se dirige vers la même impasse avec H266… où là certaines options seront même sous licence payante !
La capacité à lire simplement est essentielle à un format d’échange. La complexité ne doit pas être mise sur le ré-utilisateur… et pas trop sur le producteur non plus sinon, il n’utilisera pas naturellement le format sauf si on l’y oblige (RGI).
J’aime l’approche du COG (Cloud Optimized Geotiff), qui reste un fichier tiff conforme au standard.
De même le CSV-LD, c’est à dire un CSV + un fichier de description standardisé permet de rester retrocompatible. Pareil pour JSON-LD qui reste un JSON lisible sans se préoccuper de sa partie linked-data.
Ces évolutions sont incrémentales et retrocompatibles ce qui est un gage sur l’adoption à long terme.
A propos de Parquet…
Je ne vois aucun processus de standardisation, c’est un projet Apache, rien de plus (et il y en a beaucoup).
Les implémentations python (fastparquet, pyarrow) font appel à des dépendances assez lourdes (numpy, panda, etc)
Quid de ORC ? Pourquoi envisager l’un et pas l’autre ?
N’est-on pas face à un effet de mode ?
Après lecture rapide du format interne de parquet, le principal changement de paradigme par rapport à la façon historique de gérer des données tabulaires semble être de les organiser non plus par lignes successives, mais par colonnes. Ceci permet de mieux tirer parti des spécificités des données de chaque colonne, de les encoder pour gagner de l’espace, de les compresser plus efficacement.
Les blocs de stockage de données deviennent aussi de fait une sorte d’index même si je n’ai pas vu de notion de tri.
1 « J'aime »
je sais pas trop où va cette discussion.
si cela peut aider, je pense que parquet est surtout utilisé dans un contexte analytique. le modèle en colonne est dans la même mouvance que des choses comme pandas qui ont un modèle interne en colonnes. un dataframe n’est rien de moins ou de plus qu’une liste de series partageant un index. polars va plus loin en enlevant l’index. (je partage cette explication parce que perso, c’était un de mes mental booms de 2022).
1 « J'aime »
Merci pour tes différentes réponses Christian.
Je comprends tout à fait la logique d’avoir au moins un format du RGI, par exemple CSV ou json. Il faut se mettre d’accord sur des règles et les suivre. Pour être honnête je n’avais jamais ouvert ce document.
Sauf que la dernière mise à jour du RGI a plus de 7 ans (décembre 2015), et mériterait sans doute un rafraichissement.
Le CSV y est déjà catégorisé comme « en fin de vie », avec la note
Le standard CSV est au statut recommandé uniquement pour les échanges
entre application et utilisateur. Pour tous les autres cas, il est considéré en « fin de vie ». Le
standard XML est à privilégier pour les échanges entre applications ou systèmes, qui n’impliquent
donc pas d’utilisateurs.
Or, on se retrouve très souvent avec l’unique format CSV, quand bien même c’est inutilisable par des « utilisateur » (via un éditeur de texte ou Excel) lorsqu’il s’agit de gros fichiers tabulaires.
XML ou json serait déjà bien. Pour certains cas d’usages (au moins les analytiques), des formats binaires modernes comme parquet seraient supérieurs sur plusieurs aspects (…)
Parquet me semble respecter les grands critères du RGI (section 1.7) : ouvert, pertinent, mature, indépendant, facile à déployer, soutenu par l’industrie.
Je ne vois aucun processus de standardisation, c’est un projet Apache, rien de plus (et il y en a beaucoup).
En effet. Je ne maîtrise pas bien la notion de standardisation. Cela devient un standard de fait dans l’industrie, mais pas porté par un organisme type AFNOR ou IETF.
Les implémentations python (fastparquet, pyarrow) font appel à des dépendances assez lourdes (numpy, panda, etc)
En effet, ce qui ne pose pas de problèmes pour les usages analytiques en python puisqu’on utilise ces librairies ;). J’ai l’impression qu’il existe des implémentations dans de nombreux langages, dont sans doute des plus légères, pour lire directement des fichiers parquet ou en passant par arrow.
Quid de ORC ? Pourquoi envisager l’un et pas l’autre ?
Pourquoi pas les 2 en effet.
J’ai le sentiment (difficile à factualiser) que parquet domine récemment. Ce que l’on pourrait expliquer par sa bonne intégration à Spark, plus populaire que Hive avec lequel ORC est bien intégré. A noter que malgré l’origine « big data » de parquet (et sans doute de ORC), le format est très pratique pour des petits fichiers.
N’est-on pas face à un effet de mode ?
Sans doute 
Mais certaines modes durent si elles répondent à un vrai besoin.
=> Je propose d’ajouter parquet en observation dans le RGI
1 « J'aime »
Aïe, c’est pourtant un document fondamental pour les administrations au sujet des données et l’ordonnance de 2005 qui l’a créé le rend d’application obligatoire.
Ce ne sont pas des recommandations : « Il détermine notamment les répertoires de données, les normes et les standards qui doivent être utilisés par les autorités administratives ».
Je comprends mieux pourquoi on trouve tant de fichiers et documents non conformes.
L’UTF-8 est par exemple le seul encodage qui doit être utilisé…
Oui, le RGI commence à dater un peu, mais l’interopérabilité, c’est aussi une histoire de long terme. Si on change les règles trop souvent, personne ne suivra.
Ok, ça nous laisse surtout dans l’XML par ailleurs très bien outillé.
Il faut espérer qu’un chantier de mise à jour du RGI soit en cours ou démarre rapidement.
est-ce que vous considérez que le format CSV est maintenant devenu obsolète ?
Oui x1000 !
Le CSV ne permet pas des échanges de données fiables alors que les données sont désormais volumineuses et avec le monde entier !
- Trop facilement modifiable
- Analyse des problèmes de format difficile (pas d’outil d’analyse de notepad++ et les tableurs modifier les données pour les présenter)
- Pas de formatage des données en fonction des types
- Pas de gestion d’en-tête permettant la gestion des langues et des caractères spéciaux
- Protections des données par rapport au séparateur de colonnes et aux sauts de lignes
En 20 ans, je constate que ces erreurs sont récurrentes à la mise en place de flux, et reviennent régulièrement sur des flux déjà en place.
Cela fait maintenant quelques années que je refuse la mise en place de flux à partir de fichiers CSV. Je constate depuis une diminution drastique des problèmes de qualité.
La manipulation de nombreux fichiers CSV par des utilisateurs est en effet un potentiel problème, mais celui-ci doit majoritairement son origine à un mauvais paysage informatique (manque ou mauvais outils) ou à de la résistance au changement.
Un système d’information bien conçu fait qu’un utilisateur n’a plus besoin de manipuler des fichiers et un tableur.
Il faut être honnête, les différentes normes qui ont été écrites pour régir la génération de CSV sont rarement suivies.
est-ce qu’il est urgent d’engager une réflexion collective sur un format alternatif ?
Le format parquet est tout indiqué pour les formats table comme l’était le CSV (RIP). Il sait gérer l’encodage, les types de données, la compression (pour l’écologie), il peut être utilisé de manière très efficace avec des catalogues de données pour optimiser la recherche… Fiabilité et efficacité
La réflexion collective doit être sur les actions permettant son adoption (création de connecteurs opensource pour les tableurs et les IDE leader du marché, formation, roadmap de migration des solutions existantes, imposer l’utilisation dans les nouveaux projets).
quel serait selon vous le ou les formats alternatifs à ce format ?
Parquet pour les formats table
JSON pour les formats imbriqués
est-ce que le format alternatif doit être un format texte (ou bien binaire) ?
De préférence binaire pour pouvoir gérer l’encodage, les types de données, la compression (pour l’écologie)
est-ce que le format de récupération des données doit être identique entre une récupération via API ou une récupération via fichier ?
On doit avoir le choix entre plusieurs formats. Le format JSON présente de nombreux avantages, notamment une facilité d’implémentation avec les différents langages de programmation et la possibilité de représenter des structures complexes. Cependant, pour des volumes importants de données de format tabulaire, un format parquet devient plus pertinent.
est-ce que la solution proposée dans la note jointe vous semble intéressante ?
Le format JSON est intéressant pour traiter des structures complexes, mais il devient verbeux et peu lisible pour des données tabulaires qui peuvent être mieux traitées par du format parquet.
2 « J'aime »
Hmmm, mouais.
4 « J'aime »
Merci pour la réponse très complète.
Juste une remarque concernant le format JSON. Il est effectivement « verbeux » lorsqu’on utilise la structure JSON-object (clé/valeur) mais si on utilise la structure JSON-Array (liste) ça ne l’est plus. Par ailleurs, un format JSON binaire (ex. CBOR) permet d’obtenir une réduction supplémentaire de volumle des données.
Bonne journée
Bonjour,
Mon avis* est que le JSON object est verbeux mais relativement lisible, là ou le JSON array est un détournement du JSON qui le rend, moins verbeux, mais illisible (impossible de voir à travers un éditeur si on n’a pas mélangé du booléen avec des décimales par exemple).
On peut en effet utilisé Avro pour réduire le volume. Par contre, cela induit de construire des outils qui permettent de les éditer facilement. La gestion du schéma peut rebuter également (à moins qu’il y ait des standards plus simples).
En terme de priorité, je dirai que la promotion du format parquet est plus urgente car la majorité des données qui sont échangées sont des données structurées. Cela couvre donc plus de cas d’usage. La complexité est probablement moindre également. Le ROI serait très important et rapide.
Bonne journée
- Avis basé sur mon expérience, habitudes de travail, goûts, contexte. Ca nécessite de change des habitudes quoi qu’il en soit
J’ai bien conscience des éléments évoqués par @cquest mais je suis sur la même ligne pragmatique que @pajachiet .
Le RGI doit être revu et devenir un document vivant, avec une mise à jour régulière et annoncée, pour tenir compte des évolutions techniques et règlementaires.
L’écosystème de l’analyse et de l’exploitation de données se reconfigure actuellement et se cristallise autour du couple Apache parquet pour la représentation des données sur disque et arrow pour la représentation en mémoire.
Cette cristallisation me semble relativement durable, pour deux raisons.
D’une part, les travaux sont opérés par un ensemble d’acteurs couvrant un spectre d’activités et de produits très large (un peu plus qu’ORC, à mon sens).
D’autre part la spécification, les implantations et l’outillage sont menés de concert dans les deux principaux langages d’analyse de données que sont R et python (sans que les autres langages soient laissés de côté) avec l’objectif explicite de partager le maximum de « couches basses ».
parquet répond bien aux carences du CSV (préservation du typage des données, optimisation de la taille) qui compliquent en pratique la réutilisation fidèle et propre des données.
Le statu quo du RGI n’est plus tenable.
4 « J'aime »