ArcGIS ne parvient pas à importer tous les enregistrements d'un énorme fichier CSV dans une table de géodatabase fichier bien qu'il soit dans les limites de taille de la table FGDB

11

J'utilise ArcGIS 10.0 sur Windows 7 64 bits avec 4 Go de RAM.

J'ai de très grandes tables au format CSV à importer dans ArcGIS, elles ont toutes environ 30 champs, plus de 5 millions d'enregistrements par table (certains ont le double ou plus) et des tailles de fichier jusqu'à environ 5 Go. J'essaie d'importer chacun d'eux dans une géodatabase fichier en tant que tables distinctes afin de pouvoir, finalement, les lier à une classe d'entités et analyser les résultats dans les tables en fonction de leur emplacement.

Le problème est qu'ArcGIS semble simplement quitter l'importation des enregistrements à un certain point. J'utilise l'outil "Table en table" sous Conversion> En géodatabase, mais l'outil "Copier des lignes" a le même problème. Même si je viens d'ajouter le fichier CSV directement à ArcGIS sans essayer de le convertir d'abord en table FGDB, le problème est le même. L'une de mes tables contient environ 11 millions d'enregistrements et ArcGIS n'en importe que 10 millions environ. ArcGIS ne me dit pas qu'une erreur s'est produite, l'outil se termine comme si de rien n'était.

Je l'ai essayé plusieurs fois maintenant et le nombre d'enregistrements qui en font la table FGDB est toujours le même, et ne semble pas être une limite de taille de fichier dont j'ai jamais entendu parler (pas un carré de 2 ou 16). ArcGIS a pu importer un autre fichier CSV avec environ 6 millions d'enregistrements et tous les enregistrements ont été transmis (bien qu'avec les problèmes que j'ai avec la plus grande table, la plus petite soit également suspecte maintenant). Le site Web d'ESRI répertorie les limites de taille suivantes dans une géodatabase fichier , et je suis loin d'en toucher aucune:

  • Taille de la géodatabase fichier: aucune limite
  • Taille de la table ou de la classe d'entités: 1 To (par défaut), 4 Go ou 256 To avec mot clé
  • Nombre de classes d'entités et de tables: 2 147 483 647
  • Nombre de champs dans une classe d'entités ou une table: 65 534
  • Nombre de lignes dans une classe d'entités ou une table: 2 147 483 647
  • Longueur du nom de la géodatabase: nombre de caractères autorisés par le système d'exploitation dans un dossier
  • Longueur de la classe d'entités ou du nom de table: 160 caractères
  • Longueur du nom de champ: 64 caractères
  • Largeur du champ de texte: 2 147 483 647

Tout ce que j'ai vraiment besoin de faire pour ces tables est d'ajouter quelques champs, d'en supprimer quelques autres et de générer des valeurs pour les nouveaux champs (sommes de quelques-uns des champs existants). J'utilise ArcGIS pour cela car je connais bien la calculatrice de terrain et je sais (ou je savais , jusqu'à présent) qu'elle pouvait gérer des tables composées de millions d'enregistrements, alors que la plupart des autres logiciels de bureau que j'ai à portée de main (MS Access / Excel ) étouffe autant de disques. Je suis donc prêt à utiliser un autre logiciel pour manipuler la table d'origine, puis à exporter la table résultante (beaucoup plus petite) vers ArcGIS. Vraiment, le fait que je rencontre ce problème et qu'ArcGIS ne me donne aucune erreur ou avertissement que le problème se produit même me donne envie de gérer ces données en dehors d'ArcGIS autant que possible.

arcgis-10.0 esri-geodatabase import database table Dan C
la source
2
Si "le nombre d'enregistrements qui parviennent à la table FGDB est toujours le même", j'examine les derniers enregistrements et les suivants pour voir s'ils peuvent contenir quelque chose qui ne semble pas cohérent par rapport aux millions importés avec succès auparavant.
PolyGeo
1
Bonne idée. Je ne vois aucune différence entre le dernier enregistrement de la table FGDB tronquée et l'enregistrement suivant (du CSV). J'ai juste essayé de supprimer tous les enregistrements importés avec succès du CSV source, puis d'importer le reste dans une autre table FGDB, et cela a fonctionné. Il ne semble donc pas y avoir de problème avec un seul enregistrement. Pour aggraver les choses, j'ai fusionné les deux tables FGDB (entre les deux, j'ai tous les enregistrements source), et encore une fois ArcGIS prétend que tout s'est bien passé, mais la table fusionnée ne contient que 9,6 millions des 10,9 millions d'enregistrements des deux Tables FGDB.
Dan C
Avez-vous ouvert un incident d'assistance avec ESRI? Il semble qu'à ce stade, vous avez découvert ce qui pourrait potentiellement être un problème assez grave. Si rien d'autre, le personnel de soutien serait intéressé à le savoir simplement parce qu'il connaît peut-être déjà une solution, ou serait prêt à aider avec les tests.
Obtenez Spatial
Je suis d'accord avec Get Spatial mais un dernier test que vous voudrez peut-être exécuter est de générer un fichier CSV avec un champ dans lequel vous placez des valeurs identiques (peut-être "test"). Si votre théorie est que 9,6 millions sont le maximum, cette limite sera atteinte chaque fois que 10 millions de lignes de "test" sont utilisées, mais pas lorsque 9,5 millions de lignes le sont.
PolyGeo
J'ai maintenant essayé avec un CSV différent, mais aussi volumineux (plus de 10 millions d'enregistrements) et il échoue de la même manière, mais sur une ligne différente (environ 8,9 millions d'enregistrements entrent). Il ne semble donc pas s'agir d'un nombre spécifique d'enregistrements ou d'une taille de table spécifique. Je vais essayer un test CSV avec deux champs et voir ce qui se passe. J'appellerai ESRI lundi dans tous les cas, ce processus échouant sans message d'erreur est inacceptable et rend même suspects les enregistrements qui le font.
Dan C

Réponses:

9

J'ai appelé le support ESRI à ce sujet et leur réponse n'était pas encourageante, mais cela expliquait le problème. Paraphraser ESRI: Le problème est qu'ArcGIS Desktop, étant un logiciel 32 bits, est limité à utiliser au maximum 4 Go de RAM. Le fichier texte doit être traité dans la RAM avant d'être stocké sous forme de table, donc à un certain pointage lors du traitement, ArcGIS atteignait la limite de RAM et s'arrêtait juste là. Le fichier que j'importais mesurait environ 6 Go. Apparemment, le fait qu'il ait échoué sans donner de message d'erreur me soit propre, j'ai essayé de faire le faire par d'autres personnes dans mon bureau et l'importation a toujours échoué, mais il a donné un message d'erreur (inutile, mais au moins quelque chose qui laisse le l'utilisateur sait que quelque chose s'est mal passé), et le représentant de l'ESRI a déclaré qu'il devrait donner une erreur.

Ma solution était de diviser le fichier en deux CSV plus petits à l'aide d'un éditeur de texte (j'ai utilisé EditPad Pro), d'importer chacun d'eux dans un FGDB en tant que table séparée, puis de fusionner les deux tables FGDB. Pour une raison quelconque, cela a échoué la première fois que je l'ai essayé, mais j'ai travaillé plus tard. Je vais peut-être essayer de tester cela un peu plus complètement, je vais traiter des fichiers de cette taille sur une base continue.

J'utilise ArcGIS 10.0, mais ArcGIS 10.1 Service Pack 1 vient d'être publié et ajoute la possibilité d'utiliser un géoprocesseur en arrière-plan 64 bits, ce qui permettra au géoprocesseur d'utiliser plus de 4 Go de RAM, ce qui peut résoudre ce problème, mais je ne peux pas tester cela.

MISE À JOUR: J'utilise maintenant ArcGIS 10.1 SP1 (avec l'addon de géotraitement en arrière-plan 64 bits) et il importe avec succès ces .CSV géants, au moins ceux que j'ai traités jusqu'à présent. Sur une machine avec 14 Go de RAM (oui, 14), un CSV de 6 Go avec environ 10,5 millions de lignes est importé avec succès dans une table FGDB.

Dan C
la source
1
Je serais curieux de pouvoir l'exécuter dans une version 64 bits de GDAL. Je parie que ça marcherait bien.
Ragi Yaser Burhum
7

À des fins de chargement de données, la lecture d'un énorme fichier CSV en mémoire est plutôt stupide. Il n'a besoin que de lire 1 ligne à la fois.

Je suggérerais d'écrire un script Python et d'utiliser le csvmodule pour le lire ligne par ligne et insérer des lignes dans la table en utilisant un InsertCursor(ou de préférence un arcpy.da.InsertCursorcar il est plus rapide, mais uniquement disponible en 10.1).

Edit: il suffit de lire votre dernier paragraphe. On dirait que vous pourriez probablement faire tout cela dans Python assez facilement, même en exportant les résultats vers CSV ou un autre format.

Si vous pouviez décrire exactement ce que vous devez faire avec chaque ligne et colonne, ce serait utile.

blah238
la source
4

Avez-vous essayé de diviser les fichiers csv de 5 Go en petits.

il existe un outil pour diviser le csv en fonction des lignes ou du nombre de fichiers.

Fractionnez les fichiers puis essayez d'importer .. Mais il y a une limitation dans cet outil, je pense qu'il ne fonctionnera que pour la table dans un fichier (je pense que oui). pls. essayer.

http://www.shivaranjan.com/2008/11/06/how-to-split-csv-file-into-multiple-parts-easily-and-quickly/

vadivelan
la source
Je prévois d'essayer si je le dois, il n'y a pas beaucoup de CSV à traiter, donc je vais probablement les diviser manuellement avec mon éditeur de texte. J'aimerais toujours savoir si quelqu'un d'autre a eu ce problème, si ArcGIS va prendre l'habitude de mal comprendre les grandes tables et de ne pas même avoir la courtoisie commune de lancer un message d'erreur inutile, cela va être un problème.
Dan C
OK, je viens d'essayer ça et ça marche à mi-chemin. Après avoir divisé le CSV en deux plus petits (manuellement, avec un éditeur de texte), ils ont importé avec succès dans deux tables FGDB distinctes et tous les enregistrements sont là. Mais lorsque j'essaie de fusionner ces deux tables FGDB en une seule, ArcGIS exécute à nouveau le processus comme si de rien n'était, puis la table fusionnée manque 1,3 million d'enregistrements.
Dan C
2

Je rencontrais cette erreur (001156) sur la même ligne d'un grand fichier texte délimité par des tuyaux (2 712 391) lignes environ un quart du chemin.
J'ai donc pensé qu'il y avait quelque chose de mal avec cette ligne, mais elle était identique au reste des lignes.
J'ai fini par supprimer les lignes de l'importation partielle, puis par charger les données (Charger> Charger les données ...) et j'ai pu obtenir toutes les lignes 2M +.

Moi aussi, j'utilise 10.1 SP1 avec un géotraitement en arrière-plan 64 bits sur 16 Go de RAM et c'est un processus qui utilisera la RAM (tous les processus ne sont pas encore activés en 64 bits).
Solution de contournement lente et délicate, mais elle fonctionne de manière cohérente.
Vous devrez peut-être d'abord configurer la table vide si vous ne réussissez pas avec n'importe quel degré d'importation.

Mat
la source