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
  • Довжина імені бази даних Geodatabase: кількість символів, яку дозволяє операційна система у папці
  • Довжина назви класу чи таблиці: 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.
Dan C

Ви відкрили інцидент підтримки з ESRI? Здається, на даний момент ви виявили, що потенційно може бути досить серйозною проблемою. Якщо нічого іншого, співробітники служби підтримки будуть зацікавлені дізнатися про це просто тому, що вони, можливо, вже знають рішення або готові допомогти з тестуванням.
Отримайте просторовий

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

Зараз я спробував з іншим, але також великим (понад 10 мільйонів записів) CSV, і він виходить з ладу тим же шляхом, але за іншою лінією (близько 8,9 мільйона записів потрапляє). Таким чином, схоже, це не конкретна кількість записів або певний розмір таблиці. Я спробую тестовий CSV з двома полями і побачу, що станеться. Я зателефоную ESRI в понеділок будь-яким способом, хоча цей процес, не виконаний без повідомлення про помилку, є неприйнятним і робить навіть записи, які роблять це підозрюваним.
Dan C

Відповіді:


9

Я подзвонив підтримкою ESRI з цього приводу, і їх відповідь не підбадьорював, але це пояснило проблему. Перефразовуючи ESRI: Проблема полягає в тому, що ArcGIS Desktop, будучи 32-бітним програмним забезпеченням, обмежується не більше ніж 4 ГБ оперативної пам’яті. Текстовий файл повинен бути оброблений в оперативній пам’яті перед тим, як зберігати його як таблицю, тому в деякий момент під час обробки ArcGIS досягав межі оперативної пам’яті та просто зупинявся на ній. Файл, який я імпортував, був розміром близько 6 ГБ. Мабуть, той факт, що він не вдався без надання повідомлення про помилку, є унікальним для мене, я намагався, щоб інші люди в моєму кабінеті це робили, і імпорт все ще не вдався, але він дав повідомлення про помилку (недобре, але принаймні щось, що дозволило Користувач знає, що щось пішло не так), і представник ESRI сказав, що це повинно дати помилку.

Моє рішення полягало в тому, щоб розділити файл на два менші CSV за допомогою текстового редактора (я використовував EditPad Pro), імпортувати кожен з них у FGDB як окрему таблицю, а потім об'єднати дві таблиці FGDB. Чомусь це не вдалося перший раз, коли я спробував це, але працював пізніше. Я можу обійтись, щоб перевірити це трохи повніше, я буду постійно працювати з файлами такого розміру.

Я використовую ArcGIS 10.0, але пакет 1 ArcGIS 10.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

Ви намагалися розділити файли CSV 5 Гб на невеликі.

є інструмент для розділення CSV на основі рядків або кількості файлів.

Розділіть файли та спробуйте імпортувати. Але в цьому інструменті є обмеження, я думаю, він буде працювати тільки для таблиці у файлі (я так думаю). pls. спробуйте.

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


Я планую спробувати, що якщо мені доведеться, не так вже й багато CSV-файлів, з якими я маю справу, тому я, мабуть, просто розділю їх вручну зі своїм текстовим редактором. Я все ще хотів би дізнатися, чи є у когось хтось із цією проблемою, якщо ArcGIS збирається нерозуміти великі таблиці та навіть не маючи спільної ввічливості викидати марне повідомлення про помилку, це стане проблемою.
Dan C

Добре, я просто спробував це, і це працює частково. Розбивши CSV на дві менші (вручну, за допомогою текстового редактора), вони успішно імпортували до двох окремих таблиць FGDB, і всі записи є там. Але коли я намагаюся об'єднати ці дві таблиці FGDB в одну, ArcGIS знову проходить процес, як ніби нічого поганого, і тоді в об'єднаній таблиці не вистачає 1,3 мільйона записів.
Dan C

2

Я зіткнувся з цією помилкою (001156) у тому ж рядку великого текстового файлу з обмеженою трубою (2,712,391) рядків приблизно через чверть шляху.
Тому я подумав, що в цьому рядку щось не так, але це було ідентично решті рядків.
Я закінчив видалення рядків з часткового імпорту, а потім завантажував дані (Load> Load Data ...) і зміг отримати всі 2M + рядки.

Я теж використовую 10,1 SP1 w / 64 бітовий фоновий геопроцесор на 16 ГБ оперативної пам’яті, і це процес, який використовуватиме оперативну пам’ять (ще не кожен процес увімкнено в 64-бітних).
Повільний, klunky вирішення, але це працює послідовно.
Можливо, вам доведеться спочатку налаштувати порожню таблицю, якщо ви не маєте успіху з будь-яким ступенем імпорту.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.