SPSS Modelerの処理のパフォーマンス・チューニングをしたいことがあります。
SPSS Modelerのパフォーマンス・チューニングで重要になるのはSQLプッシュバックという機能です。Modelerのアイコンで作った処理からModelerが自動的にSQL文を生成して実行する処理です。DBは大量データを高速に処理することに長けていますので、なるべくSQLプッシュバックを効くようにすることがチューニングになります。
ただ、SQLプッシュバックが効いても遅い処理もあります。そういう時にはDB側とModeler Server側のどちらが遅いかを切り分けて考える必要があります。その切り分け方についてお話しします。
#1. そもそもSQLプッシュバックが可能かの確認
まず設定をします。
ストリームのオプションで最適化の設定からSQL生成の最適化をチェックします。ついでにすべての最適化を有効にするのがお勧めです。
ログとステータスの設定で
・ ストリーム実行中に SQL を メッセージ・ログに表示する
・ ストリームの準備中に、SQL 生成の詳細をメッセージ ログに表示する
にチェックを入れます。
特に後者が重要です。実際に実行しなくてもModelerがDBに投げようとするSQLが確認できます。
実行したいターミナルノードを選択した状態でメニューのアイコンからプレビュー実行のボタンをクリックします。
すると以下のように全部ノードもしくは一部のノードが紫色に変わります。
以下の場合はHWV53816.COND2N_EのDBインポートノードと条件抽出ノードがSQLに変換できたことがわかります。テーブルノードはModeler側への表示を行う処理なのでModeler側で処理が行われます。
そして生成されたSQL文がストリームのメッセージに記録されます。
#2. SQLプッシュバックとModeler Serverの実行時間の切り分け
上でみたようにテーブルノードより前がすべてSQLプッシュバックできている場合は、すべてプッシュバックできているのでDB側での処理で時間がかかっていることがわかります。
しかしながら以下のように途中でSQLプッシュバックが途切れた場合、「条件抽出ノード」までのDBでのSQL処理と「フィールド作成ノード」以降のModeler Serverでの処理のどちらが遅いのかがわかりません。
こういう場合はやはり実行して計測をする必要があります。
##2-1.経過時間とCPU時間の差を比較する
実行すると経過時間とCPUの時間が出力されます。
このCPUの時間はModeler ServerのCPUを使っていたことを示します。ですので、経過時間よりCPUの時間が短い場合はSQLの実行時間が長いことを示します。
上の例はそもそもすぐに終わっている処理で起動のオーバーヘッドなどの影響が大きくあまり意味がないのですが、例えば
経過時間=500 秒、CPU=2 秒
というような結果の場合、Modeler Server実行時間よりもSQLの実行時間が長いと考えられます。
一方で、例えば
経過時間=500 秒、CPU=450秒
というような結果の場合、SQLの実行時間よりもModeler Serverの実行時間が長いことが想定されます。
ちなみにModeler Serverは並列実行することもあるので、CPU時間の方が経過時間より長くなることもあります。
##2-2.キャッシュをとってから実行する
さらに並列処理の効果も含めて比較しようとすると一度SQLプッシュバックが効くところまでをDBキャッシュをとってから実行するという方法があります。
こうするとSQL実行にかかった時間を省いて、Modeler Serverでの処理にかかった時間を取得できます(一時表から全件SELECTする時間は入ってしまいますが)。
#3. 環境
Modeler18.2.2
Db2 on Cloud