Est-ce la fin du format CSV?

Je pense qu’on est nombreux à être d’accord là dessus.

Un cycle prévisible d’évolution du RGI serait nécessaire car on ne peut pas rester figé trop longtemps, ni changer sans arrêt les règles.

Il faut de plus des périodes de recouvrement pour permettre de basculer petit à petit, ce qui veut dire que la diffusion doit se faire pendant un certain temps selon plusieurs standards.

3 Likes

Je pense qu’on est tous d’accords que le RGI mériterait des évolutions et que d’autres formats que le CSV pourraient être utiles pour les usages de beaucoup.
Pour autant n’oublions pas le plus grand nombre : l’immense majorité des gens ne sait pas et ne saura jamais utiliser autre chose que des logiciels de tableur.
IMHO Parquet ne saurait donc venir en remplacement, tout au plus en complément.

3 Likes

Oui, le csv est loin de disparaitre et je partage totalement la remarque de @boogheta « Pour autant n’oublions pas le plus grand nombre : l’immense majorité des gens ne sait pas et ne saura jamais utiliser autre chose que des logiciels de tableur. »

Une question au passage sur le CSV pour OpenDataSoft (@jean-marc.lazard) : pourquoi ne proposer que l’export csv point-virgule sur les portails ODS (cf documentation ? Et ne pas laisser le choix à l’usager avec le séparateur virgule qui est la norme internationale de facto ?

1 Like

@boogheta et @samgoeta , je suis d’accord avec vous : le plus grand nombre n’utilisera jamais autre chose qu’un logiciel de tableur… mais cela ne veut pas dire qu’ils continueront à utiliser le format CSV. Ni un éventuel autre format en texte plein mal standardisé et dont l’ouverture dans un logiciel de tableur est tout sauf facile dès qu’elle requiert de sélectionner soi-même le séparateur ou l’encodage et qu’ils ne sont pas ceux par défaut de son tableur avec ses paramètres de localisation.

Les utilisateurs de tableur préfèrent télécharger un jeu de données au format XLSX ou ODS plutôt que CSV, quand ils ont le choix, et ils ont raison car les premiers s’ouvrent directement correctement dans leur tableur (en plus d’inclure les éventuelles formules, tableaux croisés et liens entre feuilles).

À mon sens, l’avenir pour le plus grand nombre ne sera pas le format CSV, mais sans doute plutôt Parquet ou un autre format de données de ce type que les tableurs sauront ouvrir (il existe par exemple déjà un add-in pour ouvrir du Parquet dans Excel: https://www.cdata.com/drivers/parquet/excel/).
Il n’est pas exclus non plus que le tableur soit remplacé ou rendu obsolète dans ses usages actuels détournés par de nouveaux outils, qui répondront mieux et plus simplement à ces besoins, et utiliseront des formats standards ouverts mais binaires et pas en texte plein.
Bref, actuellement, Parquet ne répond pas aux besoins du plus grand nombre, mais le format CSV a trop de défauts même pour ces utilisateurs, ce qui en fait tout sauf un horizon indépassable.

J’ai trouvé comment exporter en csv avec séparateur virgule sur ODS : il faut changer le delimiter dans le lien d’export en CSV.

Exemple :
https://opendata.paris.fr/api/explore/v2.1/catalog/datasets/lieux-de-tournage-a-paris/exports/csv?lang=fr&facet=facet(name%3D"type_tournage"%2C%20disjunctive%3Dtrue)&facet=facet(name%3D"nom_tournage"%2C%20disjunctive%3Dtrue)&facet=facet(name%3D"nom_realisateur"%2C%20disjunctive%3Dtrue)&facet=facet(name%3D"nom_producteur"%2C%20disjunctive%3Dtrue)&facet=facet(name%3D"ardt_lieu"%2C%20disjunctive%3Dtrue)&refine=nom_realisateur%3A"CEDRIC%20KLAPISCH"&timezone=Europe%2FBerlin&use_labels=true&delimiter=%3B

A la fin, il y a delimiter=%3B. Il faut remplacer par delimiter=%2C.

Voici comme convenu une synthèse sur ce sujet de discussion lié à l’évolution du format CSV.

Celle-ci est construite à partir de vos nombreuses contributions (cf historique) et d’un sondage Mastodon.
Le sondage a obtenu 53 réponses à la question « quelle solution est à mettre en oeuvre ? » avec la répartition suivante parmi les quatre réponses possibles :

  • conserver le format CSV (53%)
  • utiliser le format JSON (32%)
  • utiliser un format binaire (ex. Parquet) (6%)
  • utiliser un autre format texte (ex. XML, YAML) (9%)

La synthèse s’appuie sur les questions posées dans le message initial.

J’espère que celle-ci reflète bien tous les avis exprimés.

Bonne lecture !


1 - Le format CSV est-il obsolète ?

La première réponse est oui. En effet, la norme (RFC4180) est très restrictive et n’a pas été mise à jour depuis 2005 :

  • elle ne connait que les caractères ASCII (pas les Unicode notamme UTF8)
  • 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 »).

Le RGI (Référentiel Général d’Interopérabilité), dans sa dernière version de 2015 (qui demanderait à être actualisée), avait déja classé ce format « en fin de vie ».

La deuxième réponse est non. En effet, le format CSV, malgré ses limitations, est le format le plus utilisé dans les échanges de données tabulaires.
Il est simple et compréhensible, lisible par n’importe quel éditeur de texte et la majorité des applications traitant des données tabulaires proposent ce format d’échange.
Cependant, les formats CSV utilisés sont des variantes et extensions de la norme permettant par exemple d’avoir d’autres types de séparateur, d’intégrer des formats UTF8 ou encore d’avoir une gestion d’entête plus ou moins sophistiquée. L’utilisation de ce format associé à une compression (ex. zip) permet d’obtenir des tailles de fichiers comparables à d’autres solutions plus optimisées.

En synthèse :

  • le standard est effectivement obsolète,
  • la pratique sur ce format (qui n’est plus standard) reste forte

2 - Faut-il engager une réflexion sur un format alternatif ?

La encore, les avis sont partagés :

  • les tenants du non précisent que malgré une absence de standard applicable, on arrive à fonctionner avec les limitations identifiées et qu’à ce jour il n’y a pas de solution alternative suffisamment accessible à tous et notamment au travers des tableurs qui représentent la majorité des usages de données tabulaires. La réponse au sondage allait également dans ce sens.
  • les tenants du oui mettent en avant les limitations du format qui conduisent à des problèmes de non qualité de plus en plus inacceptables (données non protégées, pas de gestion du typage, les langues, les caractères spéciaux, mauvaises performances de lecture/écriture sur des jeux de données importants …).

En synthèse, la réponse est dans la question : Comme il n’y a pas de format alternatif largement déployé, on continue de fonctionner avec l’existant mais si un format
alternatif émerge et répond aux limitations et attentes identifiées, il remplacera le format CSV.

3 - Quel serait le format alternatif ?

De même que pour la question précédente, deux approches distinctes émergent :

  • ceux qui privilégient les performances (données de taille importante, temps de réponse), ou l’intégration (avec les outils BI ou de stockage fichiers ou base de données) mettent en avant les formats binaires intégrant des fonctions évoluées (ex gestion du typage de données, algorithmes de compression, segmentation des données) comme par exemple le format Parquet (objet d’une promotion forte actuellement).
  • ceux qui privilégient la capacité à traiter des données complexes (cf. sujet spécifique), la simplicité et la pérennité sont plutôt partisans d’une solution à base de format texte. Le candidat le plus naturel est le format JSON (cf résultats du sondage mastodon). Cependant, ce format est plus un langage de description de données; il nécessite donc une déclinaison spécifique dédiée aux formats tabulaires qui reste à construire.

Les deux approches sont complémentaires (avoir de bonnes performances sur des volumes de données importants n’est pas toujours compatible avec la capacité à traiter des données complexes avec un niveau sémantique élevé). Les deux solutions sont donc nécessaires. Il reste néanmoins dans la seconde approche à identifier une solution JSON déployable sur la majorité des applications (ce qui prendra du temps).

4 - 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 ?

Peu de réponses ont été apportées à ces questions qui sont trop orientées sur une solution technique. Celles-ci ne pourront être abordées que dans le cadre d’une réflexion autour d’un format texte alternatif qui reste à engager.

5 Likes

Merci pour ce résumé très intéressant.

Ralala j’ai manqué la conversation, donc j’arrive un peu en retard…

Pour apporter ma petite pierre à la réflexion, nous utilisons CSV comme un de nos formats d’export chez Open Food Facts : Data
Comme le volume de données est très important (~7 Go) l’export n’est pas fait pour s’ouvrir dans Excel. On a donc dû documenter quelques manières d’exploiter nos exports dont le CSV :
Reusing Open Food Facts Data - Open Food Facts wiki

L’avantage du CSV c’est quand même que beaucoup savent le lire et qu’il existe une myriade d’outils permettant de le manipuler. Même sur un fichier de 7 Go comme le nôtre, je fais tourner csvclean, visidata, xsv, etc. Même de bon vieux outils comme grep peuvent rendre des services avec CSV.

Dans notre cas, CSV a quelques inconvénients importants :

  • le temps des « requêtes » natives est très long
  • pas nativement compressé (on peut le faire mais ça complexifie l’usage)
  • le format n’est pas très adapté à de la consultation en ligne (cloud optimized dont parle @cquest )
  • le format n’est pas très adapté à la distribution de mise à jour : nos utilisateurs retéléchargent chaque jour le fichier dans son intégralité

C’est pour toutes ces raisons qu’on a commencé à regarder Parquet (sur les conseils judicieux de @mathieu). J’ai ouvert une « issue » et effectué quelques tests déjà très prometteurs : Investigate database export as parquet file · Issue #7660 · openfoodfacts/openfoodfacts-server · GitHub

2 Likes

Merci pour ce retour très clair !

J’ai l’impression que cela conforte le fait que d’une part le CSV devient chaque jour un peu plus obsolète et que d’autre part il y a bien les deux types de solutions alternatives proposées dans le dernier message posté (Parquet semblant être la solution qui réponde actuellement le mieux au volet ‹ performances ›).

J’en profite également pour poser une question sur Open Food Facts Data :

les données manipulées notamment au niveau des API (cf lien Data) ont l’air très complexes. Est-ce qu’une approche comme celle présentée dans le projet JSON-NTV(voir exemples également) pourrait avoir un apport ?

Un cas intéressant où la diffusion en parquet présente des avantages clairs (ici interrogation rapide d’une « grosse » base) :

@InseeFr commence à diffuser au format Parquet !
Avec https://t.co/Z9ahRPdVsv, requête en direct sur le fichier de 470 mo des adresses géocodées des électeurs par bureau de vote (https://t.co/SPxzVIo8BC).
Toulouse en tête pour le nb d'adresses, résultat en 1 s, chapeau @duckdb 🙌 pic.twitter.com/f651WCtAE5

— Éric Mauvière 🇺🇦 (@ericMauviere) September 5, 2023
`
1 Like

En effet, l’Insee a bien compris l’intérêt du Parquet, et propose pour que ce soit le format par défaut pour les « micro-données ».

Je profite de la découverte de cet outil … :heart_eyes:

… pour partager d’autres références :

Présentation à la conférence du High-Level Group for the Modernisation of Official Statistics (HLG-MOS) de novembre

Article du courrier des statistiques de juin dernier
image

1 Like

Chez Open Food Facts on a fait pas mal de tests sur le format Parquet (long thread ici), à partir de notre fichier CSV de 8 Go (3 000 000+ de lignes, ~200 colonnes).

En comparaison avec CSV, Parquet est assez bluffant :

  • par rapport à il y a un an, la fabrication du fichier parquet est achevée en 2-3 minutes avec DuckDB (et les bonnes options), en une seule ligne de commande
  • on gagne ~15 fois la taille (~540Mo vs 8100)
  • en lecture native avec DuckDB, selon les requêtes on gagne 10 à 50 fois en vitesse par rapport à une base SQLite indexée (je ne parle même pas du CSV)

Les résultats sont tellement bons qu’on envisage même de diffuser les données ET leurs mises à jour au fil de l’eau dans le même fichier (pour un surcoût très faible).

Il ne manque plus qu’une interface de consultation qui abaisse la barrière à l’usage. Pour ma part je suis un fan de Datasette, mais hélas ce dernier ne le gère pas.

1 Like

Le client web de duckdb (https://shell.duckdb.org) ou observablehq ?

3 Likes

Merci pour les suggestions. Je pensais cependant à des interfaces plus faciles d’accès pour le commun des mortels.

L’intérêt de Datasette c’est que tu peux monter progressivement en compétence : démarrer par l’interface tableau+filtres+tris et basculer progressivement sur le mode SQL au fur et à mesure de tes besoins.

2 Likes

Merci Tam Kien ! J’avais manqué ta première référence, qui a l’air prometteuse, quoiqu’un peu expérimentale. Elle devrait peut-être suffire pour mes besoins, je vais investiguer.
Quant à la seconde c’est moins intéressant pour moi pour plusieurs raisons : elle n’utilise pas parquet nativement, c’est une conversion, donc autant convertir en sqlite pour utiliser Datasette.

Un document Observable aménagé, avec des listes de critères et aussi un espace de saisie pour entrer des requêtes SQL, éventuellement assistées, c’est faisable et ce peut être, en effet, un bon compromis.
D’autant que l’on peut insérer dans une page web quelconque des composants venant d’un classeur Observable, pour une intégration plus transparente.

Je ne connaissais pas non plus le RGI. Je lis qu’il est un cadre de recommandations et non une obligation.

A titre personnel, je vais créer trois formats différents pour un jeu de données :

  • .xlsx : sinon je perd les utilisateurs néophytes qui utilisent Excel
  • .csv : parce que c’est le standard
  • .parquet : parce que je souhaite tester !

Je vous ferai des retours sur les stats de téléchargements !

1 Like

Pas vraiment… le respect du RGI est une obligation pour les administrations :

https://www.legifrance.gouv.fr/loda/article_lc/LEGIARTI000006317216 article 14…

II. - Les systèmes d’information existant à la date de publication du référentiel général d’interopérabilité mentionné à l’article 11 sont mis en conformité avec celui-ci dans un délai de trois ans à compter de cette date. Les applications créées dans les six mois suivant la date de publication du référentiel sont mises en conformité avec celui-ci au plus tard douze mois après cette date.

En vigueur depuis 2005.

Repéré grâce à un post LinkedIn de @BorisM, le format parquet est désormais disponible par défaut pour toutes les plateformes OpenDataSoft