Format de texte brut simple, fiable, ouvert et interopérable pour le stockage des données

17

Dans une question précédente, j'ai posé des questions sur les outils d'édition des fichiers CSV .

Gavin lié à un commentaire sur R Help par Duncan Murdoch suggérant que le format d'échange de données est un moyen plus fiable de stocker des données que CSV.

Pour certaines applications, un système de gestion de base de données dédié est nécessaire. Cependant, pour les projets d'analyse de données à petite échelle, quelque chose de plus léger semble plus approprié.

Tenez compte des critères suivants pour évaluer un format de fichier:

  • fiable : les données saisies doivent rester fidèles à ce qui a été saisi; les données doivent s'ouvrir de manière cohérente dans différents logiciels;
  • simple : ce serait bien si le format de fichier est facile à comprendre et idéalement lisible avec un simple éditeur de texte; il devrait être facile d'écrire un programme simple pour lire et écrire le format.
  • ouvert : le format doit être ouvert
  • interopérable : le format de fichier doit être pris en charge par de nombreux systèmes

Je trouve que les formats de valeurs séparés par des tabulations et des virgules échouent sur le critère de fiabilité. Bien que je suppose que je pourrais blâmer les programmes d'importation et d'exportation plutôt que le format de fichier. Je me retrouve souvent à devoir faire de petits ajustements aux options read.tableafin d'empêcher un personnage étrange de casser le chargement de la trame de données.

Des questions

  • Quel format de fichier répond le mieux à ces besoins?
  • Le format d'échange de données est-il une meilleure alternative? ou a-t-il ses propres problèmes?
  • Y a-t-il un autre format préférable?
  • Suis-je en train d'évaluer injustement TSV et CSV? Existe-t-il un ensemble simple de conseils pour travailler avec de tels fichiers qui rendent le format de fichier plus fiable?
Jeromy Anglim
la source
2
Je devrais ajouter que R n'en a pas write.DIF(), c'est donc un peu une rue à sens unique, je le crains.
Rétablir Monica - G. Simpson
1
Je ne comprends pas le problème de la csv et de la fiabilité. Voulez-vous dire que csv n'est pas assez strict? Strict signifie que si la réglementation pour csv était suffisamment stricte, chaque outil suivant ces définitions pourrait charger un fichier sans avoir besoin de paramètres supplémentaires.
steffen
@steffen Je veux dire des choses comme: le chargement et l'enregistrement d'un fichier csv dans certains programmes modifie le fichier csv; le chargement de fichiers csv peut entraîner une conversion inappropriée, sauf si vous faites attention; les fichiers csv se brisent parfois lorsque d'étranges combinaisons de caractères sont ajoutées sans échappement approprié. Peut-être que je confond l'utilisation de csv avec le format lui-même, bien que j'aie entendu des gens commenter l'absence d'une norme officielle. Bien sûr, je me rends compte que dans de nombreux cas, cela fonctionne très bien.
Jeromy Anglim
5
@steffen: CSV ne stocke aucune information sur le format ou les types de données des données stockées dans le fichier. Vous pouvez bien ouvrir un fichier CSV dans deux applications différentes et lui faire interpréter les données du fichier de deux manières différentes.
Rétablir Monica - G. Simpson
1
@ JeromyAnglim, je pense que la modification du fichier csv dépend de votre logiciel, pas du format csv en soi.
Roman Luštrik

Réponses:

9

Je me demande s'il y a une collision de critères en cours ici.

Une plainte concernant les formats de fichiers tels qu'Excel, SQL, etc. est que vous devez définir les types de données à l'avance pour qu'il se comporte bien, ce qui va à l'encontre du critère "quelque chose de plus léger" (si je comprends bien votre restriction d'être plus de temps). liés qu’aux calculs).

En revanche, les critères selon lesquels il ne détruit pas les données ou autorisent le nettoyage des données nécessitent une vérification des erreurs. À moins que vous ne laissiez le système déterminer automatiquement les types de données (qui est essentiellement là où Excel vous fait défaut), il n'y a aucun moyen d'avoir votre gâteau et de le manger aussi.

OMI, des deux, le deuxième critère est plus important. L'intégrité des données, une fois violée, rend l'analyse difficile ou impossible. Des observations perdues ou des valeurs invalides (si elles ne sont pas correctement vérifiées) peuvent tout gâcher.

En ce qui concerne DIF, le texte brut réel n'est pas lisible par l'homme et il serait difficile (IMO) pour les humains de saisir des données.

OMI, vous devriez donner un coup sec aux fichiers délimités. Comme mentionné ci-dessus dans les commentaires, la `` gestion des données '' est principalement la faute d'un sous-ensemble d'outils que vous utilisez. Les programmes bien comportés ne doivent pas modifier les fichiers délimités. La plus grande source de mutilation est un délimiteur mal spécifié. Par exemple, si vos données peuvent comporter des virgules, un CSV est inapproprié. S'il peut avoir des onglets, TSV est inapproprié. Pour de nombreux programmes (mais pas tous), vous pouvez spécifier un délimiteur alternatif. Par exemple, j'ai utilisé le tilde (~) dans quelques cas difficiles.

russellpierce
la source
Merci. Il semble que l'utilisation d'un format de fichier délimité avec un soin approprié soit la meilleure option.
Jeromy Anglim
6

Plus sérieusement, je considérerais les fichiers RData créés par R lui-même comme il convient

  • fiable (vérifier)
  • simple (appelez cela un tirage au sort - le format est binaire)
  • open (vérifier: ne devient pas plus ouvert que le code source R)
  • interopérable (vérifier: fonctionne partout R fonctionne)

Assez proche pour moi. Si par systèmes, vous entendez des applications plutôt que des systèmes d'exploitation, le dernier point est un échec.

Oh, et RData est efficace car les fichiers sont désormais compressés par défaut (ce qui était une option désactivée par défaut).

Dirk Eddelbuettel
la source
2
RData fonctionne certainement bien avec R. Cela pourrait être problématique en ce qui concerne le contrôle de version. Je suppose que la fonction R dput()fournit une alternative en texte brut qui fonctionnerait avec le contrôle de version. Cependant, l'un des attraits de csv / tsv est que lorsque je partage un référentiel avec des données (disons pour un article de journal), les gens peuvent prendre les données et les réanalyser facilement en utilisant n'importe quel logiciel qu'ils aiment.
Jeromy Anglim
1
Oui, c'est une affaire extrêmement compliquée. Je pense que les gens en ont discuté depuis l'aube de l'informatique. J'ai eu deux autres réflexions (et je pourrais développer ma réponse): les ProtocolBuffers sont bons pour partager efficacement avec Python, Java, C ++, ... et une foule d'autres langages; Romain et moi couvrons R. Le nouveau site mldata.org couvre cela pour la recherche en Machine Learning - ils ont même des outils qu'ils mettent à disposition pour convertir. Cela vaut peut-être le coup d'œil.
Dirk Eddelbuettel
1
En fait, SVN prend des blobs binaires tels que des fichiers pdf, etc. sans problème. Je suppose que Git aussi.
Dirk Eddelbuettel
C'est bon à savoir sur les blobs binaires. Ce serait quand même bien de pouvoir exécuter diff sur des fichiers texte et obtenir des informations significatives sur les changements. Merci aussi pour le lien vers mldata.org. Ça a l'air intéressant.
Jeromy Anglim
Plaisir. Le site sœur mloss.org est tout simplement génial, si j'espère qu'ils obtiendront une traction pour mldata.org. Le moment est venu pour cela.
Dirk Eddelbuettel
4

En réponse à la réponse de Dirk Eddelbuettel, je suggère d'utiliser le format de fichier HDF5 . Il est moins simple que le format RData, ou vous pourriez dire «plus riche», mais certainement plus interopérable (peut être utilisé en C, Java, Matlab, etc.). J'ai constaté que les E / S impliquant de gros fichiers HDF5 sont très rapides.

shabbychef
la source
(+1) Avez-vous pensé à ses performances par rapport à NetCDF ?
chl
IIRC qui est aussi le format interne choisi sur mldata.org - avec une suite d'outils qui convertissent. Les convertisseurs valent peut-être le coup d'oeil. J'ai toujours eu le sentiment que le support R pour HDF5 était moins que parfait.
Dirk Eddelbuettel
@chl J'avais vaguement pensé que NetCDF utilisait HDF5 en interne, mais cela ne semble pas tout à fait exact.
shabbychef
2

Je ne sais pas trop pourquoi le format de texte fixe avec les métadonnées appropriées ne répond pas à vos critères. Ce n'est pas aussi simple à lire qu'un délimiteur, mais vous avez quand même besoin de métadonnées pour utiliser les informations. La tâche d'écrire la syntaxe pour lire le programme dépend simplement de la taille et de la complexité de la structure de l'ensemble de données. SPSS et Excel disposent d'une interface graphique pour vous aider dans ces tâches.

Il n'y a que deux erreurs avec les fichiers CSV que j'ai rencontrées:

  1. Champs manquants sans délimiteurs (donc tous les autres champs de cet enregistrement sont mal placés, j'ai également eu ce problème avec des balises manquantes en XML)
  2. Une virgule dans une chaîne de texte

(si vous avez rencontré d'autres problèmes, n'hésitez pas à donner des exemples)

Deux est résolu avec un délimiteur plus irrégulier comme le suggère drnexus (un tube (|) en est un que j'ai rencontré auparavant, mais un tilde (~) fonctionne tout aussi bien dans la mesure où aucun n'est susceptible d'être inclus dans les champs de chaîne.) L'un est un problème pas facilement résolu par le logiciel que vous utilisez, et les deux sont des problèmes avec la façon dont les gens ont écrit les fichiers pour commencer, pas le logiciel utilisé pour lire les fichiers.

Je voudrais également dire que je suis d'accord avec drnexus sur ce fil et sa réponse sur votre autre fil récent sur la modification de ces fichiers. Vous semblez vous plaindre du logiciel que vous utilisez (en particulier Excel) et demander à stocker des données dans un format conforme à votre logiciel mal comporté. Peut-être que la question devrait être de savoir comment obtenir Excel pour arrêter le formatage automatique des fichiers de texte brut. Votre critère fiable tel qu'il me semble est un problème logiciel avec la lecture de fichiers en texte brut. Je n'utilise pas R pour la gestion des données, mais je n'ai pas eu autant de mal à lire des fichiers délimités dans SPSS comme vous semblez le suggérer.

Si les fichiers originaux ne sont pas écrits correctement, qu'est-ce qui vous fait espérer qu'un logiciel lira le fichier de manière fiable? Et un format de fichier spécifique ne vous empêchera certainement pas d'écrire incorrectement les données dans le type de fichier que vous choisissez de commencer.

Andy W
la source
(1) Je voudrais pouvoir ouvrir et fermer le fichier de données aussi facilement que je peux ouvrir un fichier de données Rdata, Excel ou SPSS. Passer du temps à parcourir un assistant fonctionne, mais ce n'est pas tout à fait le flux de travail simple et fiable que j'aimerais idéalement. (2) Oui, je suis d'accord pour utiliser un délimiteur irrégulier. En général, Tab me suffit la plupart du temps; (3) Je n'ai pas d'énormes problèmes avec CSV / TSV. J'ai des problèmes occasionnels qui peuvent être facilement résolus. Cependant, je ne voudrais pas avoir à penser aux problèmes de délimiteurs et de conversion de format.
Jeromy Anglim
@Jeromy Anglim, pour le point # 1, je suppose que vous ne devez normalement le faire qu'une seule fois (sauf si vous migrez fréquemment entre deux environnements différents qui ne peuvent pas lire ou sortir les autres fichiers). Pour le point # 3, les fichiers texte fixes corrigent ce problème. Je n'ai jamais rencontré de situation où SPSS a formaté un type de fichier différent de manière incorrecte. Si vous n'avez pas besoin de diffuser les fichiers, toute cette question est muette, si vous pouvez obtenir le fichier à enregistrer correctement dans n'importe quel environnement dans lequel vous travaillerez, il n'y a plus besoin de conversion / stockage.
Andy W
1

Le problème commun avec le format de texte brut est qu'il ne peut pas stocker de métadonnées. Comment définissez-vous les données manquantes? Comment définissez-vous 1 = fortement en désaccord, 2 = en désaccord, ... des types de choses au format texte brut? Avec le format texte brut, vous devez utiliser un autre document pour définir ces métadonnées. Et ce n'est pas facile à faire en XML.

Parfois, ce problème peut être très inquiétant.

Ma solution consiste à utiliser le format de données SPSS, qui est autonome et facile à modifier dans SPSS. Je sais que ce n'est pas une bonne réponse à votre question, mais je me bats sur le même problème depuis très longtemps et c'est ma solution actuelle.

Jfly
la source