Производительность ArcGISScripting и большие наборы пространственных данных

В настоящее время я пишу скрипт на Python с использованием модуля arcgisscripting для обработки достаточно большого набора данных (всего ~ 10000 записей), нормализованного для небольшого числа таблиц, всего 8. Процесс состоит из создания элемента, основанного на кортежах координат (x, y), и создания графика (узлов и линий) с использованием отношений в других 7 таблицах для руководства. Конечным результатом является персональная база геоданных (pgdb / fgdb) с узлами и ребрами пространственных наборов данных, которые визуально представляют отношения.

Первоначально я пытался использовать запросы новых таблиц базы геоданных и наборов записей SearchCursor для заполнения таблиц ссылок (InsertCursor) для возникающих отношений «многие ко многим». Это работало очень хорошо, за исключением 15-20 минут времени обработки.

Используя модуль cProfiler в Python, было очевидно, что «перебивание» персональной базы геоданных при выполнении поисковых запросов для заполнения таблиц ссылок запросами курсоров (курсоры поиска и вставки) вызывало ужасающую производительность.

После небольшого рефакторинга мне удалось сократить время обработки до 2,5 минут. Компромиссным решением было частичное построение схемы базы геоданных в коде и ограничение запросов на курсоры с разбивкой по дуге для InsertCursors после того, как все отношения были сопоставлены.

Мой вопрос касается производительности.

• Какие методы использовали люди для поддержания разумного времени вычислений при работе с большим набором данных?
  

• Есть ли какие-либо рекомендуемые ESRI методы, которые я пропустил при поиске оптимизации?

  Я понимаю накладные расходы, возникающие при создании курсора с заданным набором символов, особенно если он из личной базы геоданных, хотя после длительного поиска ответов, связанных с производительностью, с этого сайта и Google, у меня сложилось впечатление, что производительность не находится на переднем крае усилий людей ,
  

• Будучи пользователем продуктов ESRI, можно ли ожидать и оправдывать эти задержки производительности?
  

ОБНОВИТЬ

После некоторой работы с этим продуктом я собрал список методов оптимизации, которые позволили преобразовать пространственную информацию из собственного формата в базу геоданных. Это было разработано для персональной и файловой базы геоданных. Tidbits:

1. Читайте ваши данные и рационализируйте их в памяти. Это сократит ваше время пополам.
   

2. Создать классы пространственных объектов и таблицы в памяти. Используйте функциональную клавиатуру набора данных 'in_memory', чтобы использовать свою память в качестве оперативного диска, выполнять там свои функции и затем записывать на диск
   

3. Для записи на диск используйте CopyFeatureclass для классов объектов и CopyRow для таблиц.

Эти три вещи заняли сценарий, который преобразовал более 100 000 объектов в базу геоданных за 30 минут до 30-40 секунд, включая классы отношений. Их не следует использовать легкомысленно, большинство из вышеперечисленных методов используют много памяти, что может вызвать проблемы, если вы не обращаете внимания.

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

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ : Я работал в ESRI в команде GeoDatabase в течение нескольких лет и отвечал за поддержку различных частей кода GeoDatabase (управление версиями, курсоры, EditSessions, история, классы отношений и т. Д. И т. Д.).

Я думаю, что основной источник проблем с производительностью в коде ESRI - не понимание последствий использования различных объектов, в частности, «маленьких» деталей различных абстракций GeoDatabase! Поэтому очень часто разговор переключается на язык, используемый в качестве виновника проблем с производительностью. В некоторых случаях это может быть. Но не все время. Давайте начнем с языковой дискуссии и вернемся назад.

1.- Язык программирования, который вы выбираете, имеет значение только тогда, когда вы делаете что-то сложное, в тесном цикле. В большинстве случаев это не так.

Большой слон в комнате - то, что в основе всего кода ESRI, у вас есть ArcObjects - и ArcObjects написан на C ++ с использованием COM . За связь с этим кодом взимается плата. Это верно для C #, VB.NET, Python или чего-либо еще, что вы используете.

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

Затем вы платите цену за каждое последующее взаимодействие с ArcObjects.

Лично я склонен писать код для своих клиентов на C #, потому что он прост и достаточно быстр. Однако каждый раз, когда я хочу переместить данные или выполнить некоторую обработку больших объемов данных, которая уже реализована в геообработке, я просто инициализирую подсистему сценариев и передаю свои параметры. Зачем?

• Это уже реализовано. Так зачем изобретать велосипед?
• Это на самом деле может быть быстрее . "Быстрее, чем писать это на C #?" Да! Если я реализую, скажем, загрузку данных вручную, это означает, что я плачу за переключение контекста .NET в тесном цикле. Каждый GetValue, Insert, ShapeCopy имеет свою стоимость. Если я сделаю один вызов в GP, весь процесс загрузки данных будет происходить в реальной реализации GP - в C ++ в среде COM. Я не плачу за переключение контекста, потому что его нет - и, следовательно, это быстрее.

Ах да, так что тогда решение, если использовать множество функций геообработки. На самом деле, вы должны быть осторожны.

2. GP - это черный ящик, который копирует данные (потенциально без необходимости)

Это обоюдоострый меч. Это черный ящик, который совершает магию внутри и выдает результаты, но эти результаты очень часто дублируются. 100 000 строк могут быть легко преобразованы в 1 000 000 строк на диске после того, как вы проведете свои данные с помощью 9 различных функций. Использование только функций GP похоже на создание линейной модели GP, и хорошо ...

3. Объединение слишком большого количества функций GP для больших наборов данных крайне неэффективно. Модель GP (потенциально) эквивалентна выполнению запроса действительно очень тупым способом

Не поймите меня неправильно. Я люблю модели GP - это избавляет меня от написания кода все время. Но я также знаю, что это не самый эффективный способ обработки больших наборов данных.

Вы когда-нибудь слышали о Планировщике запросов ? Его задача - посмотреть на оператор SQL, который вы хотите выполнить, сгенерировать план выполнения в форме ориентированного графа, который выглядит во многом как модель GP , посмотреть статистику, хранящуюся в БД, и выбрать наиболее оптимальный порядок их выполнения . GP просто выполняет их в том порядке, в котором вы их размещаете, потому что у него нет статистики, чтобы делать что-то более разумно - вы - планировщик запросов . И угадайте, что? Порядок, в котором вы выполняете вещи, очень зависит от вашего набора данных. Порядок, в котором вы исполняете вещи, может иметь значение между днями и секундами, и вам решать.

«Отлично», говорите вы, я не буду писать сценарии сам и буду осторожен с тем, как пишу вещи. Но понимаете ли вы абстракции GeoDatabase?

4. Непонимание абстракций GeoDatabase может легко укусить вас

Вместо того, чтобы указывать на каждую вещь, которая может создать вам проблему, позвольте мне указать на несколько распространенных ошибок, которые я вижу постоянно, и некоторые рекомендации.

• Понимание различий между Истинным / Ложным для рециркуляции курсоров . Этот крошечный флажок, установленный в true, может на несколько порядков быстрее работать.
• Поместите вашу таблицу в LoadOnlyMode для загрузки данных. Зачем обновлять индекс при каждой вставке?
• Поймите, что, хотя IWorkspaceEdit :: StartEditing выглядит одинаково во всех рабочих пространствах, они очень разные звери в каждом источнике данных. На Enterprise GDB у вас может быть управление версиями или поддержка транзакций. На шейп-файлах это должно быть реализовано совсем другим способом. Как бы вы реализовали Undo / Redo? Вам даже нужно включить его (да, это может иметь значение в использовании памяти).
• Разница между пакетными операциями или операциями с одной строкой. Пример GetRow против GetRows - это разница между выполнением запроса для получения одной строки или выполнением одного запроса для извлечения нескольких строк. Тесная петля с вызовом GetRow означает ужасную производительность, и это виновник # 1 проблем с производительностью
• Используйте UpdateSearchedRows
• Понять разницу между CreateRow и CreateRowBuffer . Огромная разница во времени выполнения вставки.
• Поймите, что IRow :: Store и IFeature :: Store запускают сверхтяжелые полиморфные операции. Это, вероятно, причина № 2 виновника действительно низкой производительности. Он не просто сохраняет строку, это метод, который гарантирует, что ваша геометрическая сеть в порядке, что ArcMap Editor получает уведомление об изменении строки, которая уведомляет все классы отношений, которые имеют отношение к этой строке, чтобы подтвердить убедитесь, что количество элементов допустимо и т. д. Вы не должны вставлять новые строки с этим, вы должны использовать InsertCursor !
• Вы хотите (нуждаетесь) сделать эти вставки в EditSession? Это имеет огромное значение, если вы делаете или нет. Некоторые операции требуют этого (и замедляют работу), но когда вам это не нужно, пропустите функции отмены / возврата.
• Курсоры дорогие ресурсы. После того, как вы справитесь с ним, вам гарантируется, что вы будете иметь Последовательность и Изоляцию, и это будет стоить.
• Кэшируйте другие ресурсы, такие как соединения с базой данных (не создавайте и не уничтожайте вашу ссылку на рабочую область) и дескрипторы таблиц (каждый раз, когда вы открываете или закрываете одну из них - необходимо прочитать несколько таблиц метаданных).
• Помещение FeatureClasses внутри или вне FeatureDataset имеет огромное значение в производительности. Это не подразумевается как организационная особенность!

5. И последнее, и не в последнюю очередь ...

Понимать разницу между операциями, связанными с вводом / выводом

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

Мои два цента.

Как правило, для вычислений производительности я стараюсь избегать использования каких-либо вещей, связанных с ESRI. Для вашего примера я бы предложил выполнить этот процесс поэтапно, первый шаг - чтение данных в обычные объекты Python, выполнение вычислений, а затем последний шаг - преобразование в окончательный пространственный формат ESRI. Для ~ 10 тыс. Записей вы, вероятно, могли бы избежать хранения всего в памяти для обработки, что дало бы определенный выигрыш в производительности.

В зависимости от имеющегося у вас аппаратного обеспечения вы можете также рассмотреть вариант, отображаемый в примере геокодера ESRI; это дает вам основу для разбиения большого набора данных и запуска нескольких экземпляров python, что дает вам почти многопоточный подход. Я видел, как производительность геокодирования возросла с 180 000 в час в одном экземпляре Python до более чем одного миллиона благодаря ускорению 8 параллельных процессов на моей машине.

Я видел, что как можно больше отдаляя себя, сохраняя работу с данными в базе данных, функциональную работу в моих таблицах и просто используя явную ГИС в области ESRI, значительно повышается производительность.

Вы можете найти эти другие сообщения на форуме интересными, поскольку они находятся в контексте оптимизации, но для растровых данных и в целом:

Компилирование скриптов Python, использующих инструменты геообработки ArcGIS?

Время обработки с использованием инструментов панели инструментов ArcGIS Hydrology в автономном скрипте Python против ArcCatalog?

настройка gp.scratchworkspace сильно повлияла на меня в некотором коде на python, который я написал для разграничения водораздела.

Не могли бы вы опубликовать несколько примеров кода, которые демонстрируют номера 1 и 2 в вашем ОБНОВЛЕНИИ к вашему первоначальному вопросу? Мне было бы интересно увидеть механизм этого (хотя я предполагаю, что вы имеете дело с данными класса пространственных объектов только здесь)

спасибо том