ArcGIS не может импортировать все записи из огромного файла CSV в таблицу файловой базы геоданных, несмотря на то, что они находятся в пределах размера таблицы FGDB


11

Я использую ArcGIS 10.0 на Windows 7 64-битной с 4 ГБ оперативной памяти.

У меня есть несколько очень больших таблиц в формате CSV для импорта в ArcGIS, все они имеют около 30 полей, более 5 миллионов записей на таблицу (в некоторых есть вдвое больше или больше), а размеры файлов составляют до 5 ГБ. Я пытаюсь импортировать каждый из них в файловую базу геоданных как отдельные таблицы, чтобы в конечном итоге я мог связать их с классом объектов и проанализировать результаты в таблицах в соответствии с их расположением.

Проблема состоит в том, что ArcGIS, похоже, просто прекращает импорт записей в определенный момент. Я использую инструмент «Таблица в таблицу» в «Конверсия> В базу геоданных», но у инструмента «Копировать строки» есть та же проблема. Даже если я просто добавлю CSV-файл непосредственно в ArcGIS, не пытаясь сначала преобразовать его в таблицу FGDB, проблема остается той же. В одной из моих таблиц около 11 миллионов записей, и ArcGIS импортирует только около 10 миллионов. ArcGIS не сообщает мне, что произошла какая-либо ошибка, инструмент просто завершает работу, как будто все в порядке.

Я уже пробовал это несколько раз, и количество записей, попадающих в таблицу FGDB, всегда одинаково и не является предельным размером файла, о котором я когда-либо слышал (не квадрат 2 или 16). ArcGIS смогла импортировать еще один CSV с примерно 6 миллионами записей, и все записи были получены (хотя из-за проблем, с которыми я сталкиваюсь с таблицей большего размера, меньшая тоже подозрительна). На веб-сайте ESRI перечислены следующие ограничения размера в файловой базе геоданных , и я далеко не выберу ни одного из них:

  • Размер файловой базы геоданных: без ограничений
  • Размер таблицы или класса объектов: 1 ТБ (по умолчанию), 4 ГБ или 256 ТБ с ключевым словом
  • Количество классов объектов и таблиц: 2 147 483 647
  • Количество полей в классе пространственных объектов или таблице: 65 534
  • Количество строк в классе пространственных объектов или таблице: 2 147 483 647
  • Длина имени базы геоданных: количество символов, разрешенных операционной системой в папке
  • Длина имени класса объекта или таблицы: 160 символов
  • Длина имени поля: 64 символа
  • Ширина текстового поля: 2 147 483 647

Все, что мне действительно нужно сделать для этих таблиц, это добавить пару полей, удалить пару других и сгенерировать значения для новых полей (суммы нескольких из существующих полей). Я использую ArcGIS для этого, потому что я знаком с полевым калькулятором и знаю (или знал до сих пор), что он может обрабатывать таблицы, состоящие из миллионов записей, тогда как большинство других настольных программ у меня есть под рукой (MS Access / Excel) ) задыхается от такого количества записей. Так что я открыт для использования некоторого другого программного обеспечения для манипулирования исходной таблицей, а затем для экспорта (намного меньшей) результирующей таблицы в ArcGIS. Действительно, тот факт, что у меня возникла эта проблема и что ArcGIS не дает мне никаких ошибок или предупреждений о том, что проблема даже возникает, заставляет меня хотеть обрабатывать эти данные вне ArcGIS в максимально возможной степени.


2
Если «количество записей, попадающих в таблицу FGDB, всегда одинаково», то я бы посмотрел на последнюю и последующие записи, чтобы увидеть, есть ли в них что-то, что выглядит несовместимым по сравнению с миллионами успешно импортированных ранее.
PolyGeo

1
Хорошая идея. Я не вижу никакой разницы между последней записью в усеченной таблице FGDB и записью после нее (из CSV). Я просто попытался удалить все успешно импортированные записи из исходного CSV, затем импортировать остаток в другую таблицу FGDB, и это сработало. Так что это не проблема для какой-либо одной записи. Что еще хуже, я объединил две таблицы FGDB (между ними у меня есть все исходные записи), и снова ArcGIS делает вид, что все прошло хорошо, но объединенная таблица содержит только 9,6 млн. Из 10,9 млн. Записей двух FGDB таблицы.
Дан С

Вы открыли инцидент поддержки с ESRI? Кажется, в этот момент вы обнаружили, что потенциально может быть довольно серьезной проблемой. Если не что иное, персоналу службы поддержки было бы интересно узнать об этом просто потому, что он, возможно, уже знает решение или будет готов помочь с тестированием.
Получите Пространство

Я согласен с Get Spatial, но последний тест, который вы можете запустить, - это создание файла CSV с одним полем, в которое вы помещаете одинаковые значения (возможно, «тест»). Если ваша теория гласит, что максимум 9,6 миллиона, то этот предел будет достигнут каждый раз, когда используется 10 миллионов строк «теста», но не тогда, когда используются 9,5 миллиона строк.
PolyGeo

Я сейчас попробовал с другим, но также большим (более 10 миллионов записей) CSV, и он терпит неудачу таким же образом, но с другой линией (поступает около 8,9 миллионов записей). Так что это не конкретное количество записей или размер таблицы. Я попробую проверить CSV с двумя полями и посмотрю, что произойдет. Я вызову ESRI в понедельник, так или иначе, этот сбой процесса без сообщения об ошибке недопустим и делает даже записи, которые делают это подозрительным.
Дан С

Ответы:


9

Я позвонил в службу поддержки ESRI по этому поводу, и их ответ не был обнадеживающим, но он объяснил проблему. Перефразируя ESRI: проблема в том, что ArcGIS Desktop, будучи 32-битным программным обеспечением, ограничен использованием не более 4 ГБ ОЗУ. Текстовый файл должен быть обработан в ОЗУ перед сохранением в виде таблицы, поэтому во время обработки во время обработки ArcGIS достигал предела ОЗУ и просто останавливался там. Размер файла, который я импортировал, был около 6 ГБ. Очевидно, тот факт, что это не удалось без сообщения об ошибке, является уникальным для меня, я пытался сделать так, чтобы другие люди в моем офисе делали это, и импорт все равно не удался, но он выдал сообщение об ошибке (бесполезное, но по крайней мере то, что пользователь знает, что что-то пошло не так), и представитель ESRI сказал, что это должно дать ошибку.

Моим решением было разделить файл на два файла CSV меньшего размера с помощью текстового редактора (я использовал EditPad Pro), импортировать каждый из них в FGDB как отдельную таблицу, а затем объединить две таблицы FGDB. По какой-то причине это не удалось в первый раз, когда я попробовал, но потом работал. Я могу немного поторопиться с этим, я собираюсь иметь дело с файлами такого размера на постоянной основе.

Я использую ArcGIS 10.0, но ArcGIS 10.1 с пакетом обновления 1 был только что выпущен и добавляет возможность использовать 64-разрядный фоновый геопроцессор, который позволит геопроцессору использовать более 4 ГБ ОЗУ, что может решить эту проблему, но я не могу проверить это.

ОБНОВЛЕНИЕ: Сейчас я использую ArcGIS 10.1 SP1 (с 64-битным фоновым аддоном геообработки), и он успешно импортирует эти гигантские .CSV, по крайней мере те, с которыми я имел дело до сих пор. На машине с 14 ГБ ОЗУ (да, 14) 6 ГБ .CSV с 10,5 миллионами строк успешно импортируется в таблицу FGDB.


1
Мне было бы интересно, если бы вы могли попробовать запустить его в 64-битной сборке GDAL. Могу поспорить, это будет работать нормально.
Раги Язер Бурхум

7

Для загрузки данных чтение большого CSV-файла в память довольно глупо. Только на самом деле нужно читать только 1 строку за раз.

Я бы предложил написать скрипт на Python и использовать csvмодуль для чтения его построчно и вставлять строки в таблицу, используя InsertCursor(или, желательно, так arcpy.da.InsertCursorкак это быстрее, но доступно только в 10.1).

Изменить: Просто прочитайте ваш последний абзац. Похоже, что вы могли бы сделать это довольно легко внутри Python, даже экспортировав результаты обратно в CSV или другой формат.

Если бы вы могли точно описать, что вам нужно делать с каждой строкой и столбцом, это было бы полезно.


4

Вы пытались разбить 5GB CSV-файлы на маленькие.

Существует инструмент для разделения CSV на основе строк или количества файлов.

Разделите файлы и затем попытайтесь импортировать. Но у этого инструмента есть ограничение, я думаю, он будет работать только для таблицы в файле (я так думаю). пожалуйста. попробуй.

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


Я планирую попробовать, если придется, не так уж много CSV, поэтому я, вероятно, просто разделю их вручную с помощью своего текстового редактора. Я все еще хотел бы выяснить, не возникла ли у кого-нибудь еще эта проблема, если ArcGIS будет иметь привычку неправильно понимать большие таблицы и даже не иметь общей любезности выдавать бесполезное сообщение об ошибке, это будет проблемой.
Дан С

Хорошо, я только что попробовал это, и это работает частично. После разделения CSV на две меньшие (вручную, с помощью текстового редактора) они успешно импортированы в две отдельные таблицы FGDB, и все записи находятся там. Но когда я пытаюсь объединить эти две таблицы FGDB в одну, ArcGIS снова запускает процесс, как будто ничего не происходит, и в объединенной таблице пропускается 1,3 миллиона записей.
Дан С

2

Я столкнулся с этой ошибкой (001156) в той же строке большого текстового файла с разделителями каналов (2 712 391), расположенного примерно на четверти пути.
Поэтому я подумал, что с этой строкой что-то не так, но она была идентична остальным строкам.
В итоге я удалил строки из частичного импорта, а затем загрузил данные (Load> Load Data ...) и смог получить все 2M + строки.

Я также использую 10.1 SP1 с 64-битной фоновой геообработкой на 16 ГБ ОЗУ, и это процесс, который будет использовать ОЗУ (еще не все процессы в 64-битной версии включены).
Медленный, клункий обходной путь, но он работает последовательно.
Возможно, вам придется сначала создать пустую таблицу, если вы не добились успеха в какой-либо степени импорта.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.