Arcpyを使用してPythonスクリプトの速度を上げる


8

2014年4月11日更新

機能の削除ツールでスクリプトがハングアップしていたようですので、以下の回答で提案されているように、テーブルの切り捨てに切り替えました。追加ツールから未使用の変数も削除しました。

2014年4月10日更新

このスクリプトを同僚のコンピューターで実行し(彼のコンピューターにはより多くのメモリがあり、ArcGIS 10.0 / Python26が含まれています)、すばやく実行されました。やったー!テクニカルサポートがArcGIS 10.0 CDを見つけたら、インストールしてテストし、コンピューターの速度が向上するかどうかを確認します。明確にするために、同じスクリプトを実行しており、ネットワークドライブとデータベース接続は同じようにマップされており、印刷ステートメントは同じです。それが起こったら、私はここにアップデートを投稿します。

更新を終了

Oracleデータベースで更新を実行する一部のPythonスクリプトの速度を上げる必要があります。スクリプトを開始するためのスケジュールされたタスクとバッチファイルを介して、これらのPythonスクリプトを1年以上実行しました。先週、XPからWindows 7マシンに移行し、ArcGIS 10.0-> 10.1に移行しました。それ以来、スクリプトはひどく遅くなっています。小さなフィーチャクラス(〜20のフィーチャを含む)を使用してこのスクリプトを実行すると、30秒で実行されます。中程度のフィーチャクラス(約80,000レコード)を使用すると、15分で実行されます。すぐに転送できるようにする必要があるフィーチャクラスには、約1,000,000レコードが含まれています。スクリプトは、ファイルが存在するかどうかを確認するための印刷ステートメント(以下のコードのifステートメント)までしか機能しません。このプロセスは、私のXP / ArcGIS 10.0コンピューターで完了するのに35分しかかかりません。

以下は、私がテストしてきた簡略化されたコードです。速度を上げるために私ができることについて誰かが提案をしていますか?ありがとう、パティ

import arcpy, os, sys
from arcpy import env
arcpy.env.overwriteOutput = True
from datetime import datetime
import smtplib
import string
import urllib

#Define variables
inWorkspace = "O:/LANDING_PAD/BOE/example.gdb" 
lpFeatures = inWorkspace + os.sep + "fc1"
outWorkspace =  "Database Connections\\THIS.sde"
arcpy.env.workspace = outWorkspace
workspace = ""
copyFC = outWorkspace + os.sep + "SDE.fc1_1" #The feature class the script will update via delete and append
schema_type = "NO_TEST"
fieldMappings = ""
subtype = ""
t = datetime.now()
print "This script began at: " + str(t)

if arcpy.Exists(lpFeatures) is True and arcpy.Exists(copyFC) is True:
    print "Both files exist. Beginning delete..."
    arcpy.DeleteFeatures_management(copyFC) #(copyFC)

    print "ALL DONE DELETING!"

    arcpy.Append_management(lpFeatures, copyFC, schema_type, fieldMappings, subtype) #Append data from landing pad to db
    print "ALL DONE APPENDING!"
    record_count = arcpy.GetCount_management(lpFeatures)
    print record_count
    r = datetime.now()
    print "This script ended at: " + str(r)

1
私はarcpyを使用していませんが、いくつかのPythonと多くの並列システムをC#で記述しました。作業を小さなチャンクに分割し、それらを並行して処理することは可能ですか?複数のPythonプロセスをディスパッチするか、スレッドを使用してみてください。特にarcpyがスレッドセーフでない場合は、乱雑になる可能性がありますが、やらなければならないことがたくさんあるときに効果があるかもしれません。スタックオーバーフローについても確認すると役立つ場合があります。
jocull 2014

遅いのは、個々のフィーチャをすべて削除し、空のフィーチャクラスに追加するためです。でフィーチャクラス全体を削除Delete_management()してから、CopyFeatures_management()またはで再作成できない理由はありますかFeatureClassToFeatureClass_conversion()
nmpeterson 2014

2
プロファイリング(docs.python.org/2/library/profile.html)を実行して、処理の大部分が発生している場所を特定しましたか?あなたの結果を見るのは面白いでしょう。
アーロン

1
@jocullはい、マルチプロセッシングを使用するものをまとめることを考えましたが、XP / ArcGIS 10.0ではスクリプトが非常に高速で、Windows 7 / 10.1では低速であることに少し行き詰っていました。アーロン、そうです。処理が行われている場所を確認するのはすばらしいでしょう。スクリプトのプロファイリングを調べます。ありがとう、patty
Patty Jula 14

上記の更新を投稿しました。基本的に、スクリプトは私の同僚のマシンで高速に実行されます。
Patty Jula 2014

回答:


7

私は最初にコメントしたかったのですが、(それが不完全かもしれませんが)回答としてラップする方が適切であるように見えました。

私のマシン(SSD搭載のトップハードウェアラップトップ)でコードを実行しましたが、同じマシンのSQL Serverジオデータベースフィーチャクラスにファイルジオデータベースフィーチャクラスを追加したため、約13分かかりました。実行速度が環境によって大きく異なる理由(10.0 >> 10.1)はわかりませんが、速度を上げるために何ができるかについて提案を求めてきたので、速度を上げる可能性があるいくつかのアイデアを以下に示しますスクリプトを実行します。

1).batファイルを実行するのと同等のコマンドラインからスクリプトを実行します(64ビットフレーバーでスクリプトを実行します。ArcGISx6410.264ビットPythonをインストールしています)。

c:\Python27\ArcGISx6410.2\python.exe c:\scripts\appendfc.py

私の経験から、Appendのような長くて重いGP操作を実行するには、64ビットバージョンのPythonを実行する方が一般に高速です。したがって、スクリプトを実行するときに、このバージョンのPythonを確実に実行する必要があります。

2)の使用はお勧めしませんarcpy.DeleteFeatures_management。後者はデータベーストランザクションを使用しないため、テーブルごとの削除よりもパフォーマンスが向上します。

スクリプトは、ファイルが存在するかどうかを確認するために、printステートメントまでしか実行しないと述べました(コード内のステートメントの場合)。リモートのOracle(または実際には任意のDBMS)データベースのテーブルにアクセスするときに、非常に遅いプロセスである可能性がある行ごとに削除し続ける可能性が高くなります。Truncate Tableを使用してスクリプトを実行してみてください。ただし、最初にAppendを指定せずに、削除ステージでのパフォーマンスの違いを確認してください。

3)"Database Connections\\THIS.sde"コードで使用しているようです。ただし、カタログウィンドウの「データベース接続」フォルダーではなく、ファイルシステムまたはUNCパスで接続ファイル自体(.sdeファイル)を参照することをお勧めします。で作成された.sdeファイルにアクセスできますC:\Users\%user%\AppData\Roaming\ESRI\Desktop10.1\ArcCatalog。この.sdeファイルを必要に応じて移動し、Pythonスクリプトがアクセスできるフォルダーに配置できます。

4)arcpy.Append_management関数では、いくつかの空のパラメーターを使用します。理論的には、違いはありませんが、必要がないという理由だけで、これらのパラメーターを指定せずに関数を実行することをお勧めします。舞台裏で何が起こっているのか、それらの空の文字列が特定の時点で評価されるのかどうか、そしてこれがパフォーマンスに影響を与える可能性があるのか​​どうかは決してわかりません。そのまま使用しarcpy.Append_management(lpFeatures, copyFC, schema_type)、値を指定しないパラメーターは指定しないでください。

5)os.sepフィーチャクラスへのパスを構築するときに使用することはお勧めしません。os.path.join(geodatabase,featureclassname)代わりに使用してください。それはよりきれいで読みやすいです。

上記のことを試し、テストとコードレビューを行った後、質問に詳細を追加できます。

ArcGISでPythonスクリプトを高速化する方法についての洞察を得るために読むべきいくつかの良い質問:

ArcGISScriptingおよび大規模な空間データセットのパフォーマンス

バックグラウンドジオプロセシング(64ビット)

SDEへのエクスポート時にArcgis CopyFeaturesツールが非常に遅い

ArcGISツールとして実行されるPythonスクリプトを高速化する方法

ArcSDEデータのジオプロセシングに関する考慮事項


どうもありがとう、あなたは私の金曜日を救った。「はい」という名前のバッチファイルでデータベースを呼び出すことができます"Database Connections\\THIS.sde"。多分これは、バッチファイルがこの変数を使用するPythonスクリプトを単に開始しているためでしょうか?にTHIS database.sdeスペースがあるため、奇妙な名前のデータベースを作成できませんDatabase Connections。改めて感謝します
Patty Jula

よかったよかったです。1.現在、パフォーマンスはどのように賢く見えますか?2.「データベース接続」に興味があります。ArcGIS Desktop GUIからスクリプトを実行していないときは、カタログウィンドウ内でこの「フォルダー」を参照できないと確信していましたが、間違っていました。これを反映するように回答を更新しました。3.「this database.sde」接続ファイルを使用できます。スペースは使用できます。しかし、スペースのあるOr​​acleでデータベースを使用することはできません。
Alex Tereshenkov

パフォーマンスが向上しました。(アドレスポイントの)100万レコードフィーチャクラスを実行するプロセスは、Windows 7 / ArcGIS 10.1マシンで実行されます(フィーチャ削除ツールでフリーズする前)。このプロセス全体を実行するには3時間かかります。このプロセスは、私のXP / 10.0マシンで50分かかりました。このリンクは、回答のポイント1で参照していたものですか?
Patty Jula

@PattyJula、そうです、これです。上にインストールされているバックグラウンド処理ソフトウェアをインストール/使用する必要はありません。スクリプトを実行するときは、64ビットのPythonを使用する必要があります。
Alex Tereshenkov

提案をありがとう。64ビットPythonと64ビットOracleクライアントをインストールしました。XP / ArcGIS 10.0構成で実行した速度でスクリプトがまだ実行されていません。今晩、バッチファイルとPythonスクリプトを実行するタスクをスケジュールします。速度が改善されない場合は、ArcGIS 10.0を実行する別のコンピューターをセットアップする必要があるかもしれません。
Patty Jula 14

1

この例が質問への回答にも役立ち、新しいソフトウェアを使用することを期待しています。上記の回答とコメントに基づいています。

セットアップ:

  1. Windows 7
  2. SQL Server 2012 R2
  3. ArcGIS 10.2.2(サーバーおよびデスクトップ)

負荷は毎晩である必要があります。それは約9300のレコードと234の属性でした。

元のモデルは以下で、SQL Server 2012 R2 / SDEですべて実行されました(ArcCatalogを介して7分&Pythonで3時間):

  1. SDEのフィーチャクラスの行を削除します
  2. SQL ServerのテーブルからXYイベントレイヤーを作成する
  3. SDEのフィーチャクラスに追加

変更方法(ArcCatalogで10秒、Pythonで10秒):•

  1. SDEのGIS Featureクラスの行削除ツールをトランケートツールに置き換え
  2. SQLテーブルをローカルCドライブのFGDBにエクスポートする
  3. ローカルメモリにXYイベントレイヤーを作成する
  4. ローカルCドライブ上のFGDB内のフィーチャクラスからフィーチャクラスへ
  5. 次に、FGDBフィーチャクラスをSDEに追加します。
  6. SQL ServerデータベースがFGDBと同じCドライブにあることに注意してください。ネットワークを介して少し遅くなるかもしれませんが、それでもおそらく私が見ていた3時間ではありません。

元のモデルで少し役に立ったのは、上記で推奨されている#3に従ってデータソースを置き換えることでした。ArcCatalogで実行すると、30秒も短縮されました。Pythonを使用すると、約20分で削られました。したがって、これは速度の変数ですが、私の場合、対処するのに最も価値のある変数ではありません。ほとんどのブログによれば、SQL Serverは「メモリから」(つまりxyイベントレイヤーを作成して)大量のデータをロードすることを好まないようです。SQL / SDEは、実際のオブジェクトをロードすることを好むようです。これが、他の同じ方法で行う読み込みに1分かかる理由を説明していますが、これらは15の属性を持つ1000レコードしかないため、この読み込みを毎晩実行する必要があるまで、モデルの効率に疑問を投げかけることはありませんでした。前述のように、このロードは236の属性を持つ9000レコードです。


0

10.0と10.1の間のパフォーマンスの問題は、SDEライブラリの何かがデスクトップで変更されたことです。以前は100万回投稿していましたが、45分しかかかりませんでしたが、ソフトウェアの更新後は24時間近くかかりました。明らかにデータに問題はなく、ソフトウェアのみが変更されました。

ジオデータベースのバージョンをチェックして、arcpyを実行しているクライアントのバージョンと一致していることを確認します。私たちはこれをESRIに報告し、バグの応答や認識はありませんでした。それはかなり明白であり、問​​題は10.0 SP1以降に始まりました。

また、コピー/貼り付けの別のテストは、追加よりも高速で、10.0と10.1からこれを試してみてください。パフォーマンスは同様です。これは、ジオメトリを追加するときに、以前のバージョンで発生する何らかのバグがあることを証明しています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.