Après plusieurs notes concernant les formats tabulaires (cf post 3876 et post 3906), je vous propose de mettre en débat la question de l’avenir du format CSV comme outil d’échange et de mise à disposition de données tabulaires.
Pour cela, vous trouverez sur ce lien une note d’analyse et de proposition d’un scénario alternatif à ce format.
N’hésitez pas à me faire un retour sur votre perception de la situation (pour un contexte d’opendata), en particulier voici quelques questions simples (je vous partagerai la synthèse des réponses obtenues) :
est-ce que vous considérez que le format CSV est maintenant devenu obsolète ?
est-ce qu’il est urgent d’engager une réflexion collective sur un format alternatif ?
quel serait selon vous le ou les formats alternatifs à ce format ?
est-ce que le format alternatif doit être un format texte (ou bien binaire) ?
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 ?
est-ce que la solution proposée dans la note jointe vous semble intéressante ?
Il me semble difficile de parler d’un remplaçant du format csv sans aborder son utilisation par des non-experts, notament via des tableurs type Excel. Comment les alternatives proposées répondent à ce besoin ?
Effectivement, le format CSV est un des rares formats d’export proposés par Excel.
Je suis d’accord pour considérer qu’un format alternatif au format CSV ne pourra être considéré comme totalement déployé et opérationnel que lorsqu’un export vers ce format sera accessible directement depuis tous les tableurs.
Par contre pour arriver à cette dernière étape, il sera peut-être nécessaire de passer par une étape préalable de mise à disposition de convertisseurs « CSV vers nouveau format » ou « format Excel vers nouveau format » (cette étape peut être simple à mettre en place).
La mise en œuvre également sur des solutions concurrentes à Excel (ex. solutions open-source) peut également pousser Microsoft à adopter un nouveau standard.
Non, il a des limitations mais elles ont toujours existé et peuvent être contournées si l’on sait ce que l’on fait et veut faire
Nullement.
Le JSON est une bonne alternative mais pour certains usages spécifiques uniquement, pour des données textuelles simples ne nécessitant pas de typage ni de nesting, le CSV reste très largement préférable à la fois en termes de poids et de lisibilité par des humains non techniciens
La question est biaisée en présupposant qu’il faut un format alternatif, mais au delà de ce point oui, la lisibilité par les humains est cruciale imho, donc les formats textes sont préférables en général
Une bonne API propose normalement des sorties en différents formats au choix de l’utilisateur
Dans la mesure où la note cherche à proposer un remplacement général, non pas du tout. En revanche oui pour certains cas spécifiques, le choix du JSON plutôt que du CSV fait totalement sens.
D’accord avec le reste des commentaires – le CSV est omniprésent pour de bonnes raisons, malgré tous ses défauts.
Pour certains usages, Parquet a l’air prometteur: Parquet devrait remplacer le format CSV - Icem7. Mais laissons le temps décider
Effectivement, j’avais vu passer la promotion de Parquet (j’ai également inclus ce lien dans la note mise à disposition ainsi que dans le comparatif de volume de données).
En terme de solution ça semble très convaincant par contre, ce n’est pas un format texte.
Juste une remarque concernant la phrase : « le CSV reste très largement préférable à la fois en termes de poids et de lisibilité ».
La réponse est plutôt l’inverse comme indiqué dans la note fournie : un format JSON adapté est beaucoup plus léger qu’un CSV (cf paragraphe 6 de la note) :
« données air » : CSV 10 870 Ko, JSON 1 222 Ko
« données IRVE » : CSV 7 281 Ko, JSON 2 374 Ko
et pour la lisibilité ce n’est pas évident (je pense que ça doit être plutôt du 50 / 50).
Tout à fait d’accord (pac) : on ne change pas un standard comme ça !
Par contre, c’est un standard ancien, qui ne vit plus (dernière mise à jour 2005), qui a des limitations et qui est plus ou moins respecté dans les implémentations.
Ca vaut donc quand même la peine de se poser la question des alternatives à ce format tout en restant pragmatique et modeste sur notre capacité à faire évoluer la situation.
Le CSV a plein de défauts, mais un avantage: il est lisible avec un bête éditeur de texte.
Il est aussi traitable avec des outils légers en ligne de commande.
L’avantage que je vois à parquet est avant tout pour de gros fichiers, sur son côté « cloud optimized » qui permet de ne pas télécharger l’intégralité du fichier.
Sur un fichier tel que SIRENE ça a du sens. Sur un truc plus light comme le COG ça reste très limité.
La dépendance à du code spécifique crée aussi un risque (bug, failles, etc).
Je trouve intéressant cette évolution des formats de fichiers pour devenir « cloud optimized », par ordre d’arrivée sur mon écran on a :
Cloud Optimized Geotiff (COG) pour les images de grand format, zoomables
Bonjour, je ne connais pas ces datasets en particulier, mais le seul cas pour lequel un JSON pourrait être plus léger serait celui dans lequel on a des données nestées, auquel cas on redonde l’info à la racine sur tous les éléments dans le csv, et clairement dans ce cas on n’est pas sur des données tabulaires et le choix du csv n’était pas approprié dès le départ.
Autrement pour des données véritablement tabulaires, entre écrire les headers une et une seule fois dans la première ligne du csv, ou les réécrire pour chaque élement dans le json, le CSV est par nature beaucoup plus léger (à moins de zipper évidemment mais dans ce cas on arrive logiquement à des volumes quasi identiques entre csv et json)
Concernant la lisibilité, pour travailler quotidiennement avec des personnes non techniciennes qui ont besoin d’éditer des données manuellement, le json pose quasi toujours des soucis car ils le formatent mal.
Le CSV a ses inconvénients, mais la simplicité reste un énorme avantage, et un critère qui a je trouve plus de poids que d’autres.
C’est un format compact et qui est très bien adapté à un traitement par flux. Ca en fait une bonne raison pour s’en servir en import / export sans avoir à se soucier de la taille des fichiers. Les problèmes de taille peuvent être amortis en utilisant la compression, idéalement de la compression qui fonctionne aussi par flux (type gzip). On constate en gros un gain de taille x10 en passant de csv à csv.gz.
J’imagine qu’un format comme parquet a aussi ces avantage (plus d’autres), mais il n’a pas la simplicité qui fait qu’une personne non experte peut ouvrir le fichier dans un tableur ou si il a peu de colonnes dans un éditeur texte.
Comme format alternatif pour les données « presque » tabulaires que sont les données géographiques, il y a le nd-json qui se prete bien aux traitements par flux et s’ouvre plus facilement dans un éditeur texte qu’un json compact. C’est par exemple avec ce format que sont publiées les adresses extraites du cadastre
Un JSON n’est pas nécessairement un ensemble de clé/valeur (JSON-Object). Un simple tableau (JSON-array) est également un JSON valide. L’utilisation de JSON-Object est effectivement plus lourde par contre les JSON-Array ne le sont pas (surtout s’ils sont optimisés).
la notion de données « nestées » (imbriquées ou classifiées) n’est pas à opposer aux données tabulaires. Dans la majorité des données tabulaires on a des champs qui sont de ce type.
Sinon, pour la lisibilité, je suis d’accord : si le nombre de colonnes n’est pas trop important, un simple éditeur de texte est suffisant pour comprendre les données (ce qui est moins le cas avec un format JSON).
@cquest
OK pour la remarque sur la lisibilité et l’accessibilité des fichiers CSV via des outils simples.
Je suis ok également sur le fort intérêt d’avoir des outils associés à des formats optimisés en terme de performance et d’accessibilité à des sous-ensemble.
Par contre, on s’éloigne de la notion de standard d’échange qui doit pouvoir rester auto-porteur et indépendant des plateformes et outils de lecture/écriture (ex. est-ce qu’un simple fichier CSV zippé peut être considéré comme un format d’échange valide ?).
@cedricr
C’était bien l’objet de ma conclusion : Est-ce qu’on doit se contenter d’attendre ou bien est-ce qu’on doit se préparer à une éventuelle évolution ?
Je ne connaissais pas le nd-json mais de ce que je comprends, c’est un fichier CSV à une seule colonne dont le format de chaque données(ligne) est un JSON. C’est bien ça ?
C’est intéressant car ça permet d’avoir à la fois la lisibilité d’un CSV et de traiter des structures plus élaborées en JSON.
Juste une remarque, le traitement par flux nécessite des données par ligne alors qu’un traitement pour analyse ou stockage privilégie des données par colonne pour exploiter le typage des champs (ex pandas, parquet…). Dans le cas d’un format d’échange optimisé, la structure par colonne devrait donc être privilégiée.
Pour la taille des fichiers, un CSV compressé est tout à fait performant, mais est-ce qu’un fichier compressé peut être considéré comme un format d’échange (format neutre) ?
Je vois bien, mais auquel cas le tableau est littéralement l’équivalent d’un fichier CSV dans du JSON mais sans les headers. Quoi qu’il en soit ça ne peut pas faire gagner de place.
Euh la majorité, vraiment ? Vous avez fait des statistiques sur tous les fichiers CSV employés dans le monde pour affirmer cela ? Je travaille quotidiennement avec toute mon équipe avec du CSV et il est exceptionnel que l’on mette des données nestées dedans, ce qui est évidemment une mauvaise solution.
Le nesting en csv c’est rare et moche, par contre la denormalisation c’est un truc courant.
C’est cela qui fait qu’on a souvent des csv lourds, car certains champs provenant initialement de tables liées ont été repris sur chaque ligne et donc occupent un gros volume. Une fois compressé cette obésité se réduit quand même fortement.
