レベル: 中級 杉嵜 百合子 (syuriko@jp.ibm.com), IM & Lotus開発, ソフトウェア開発研究
田原 義則 (taharay@jp.ibm.com), IM & Lotus開発, ソフトウェア開発研究所
2009年 7月 24日 2008年9月に IBM InfoSphere Information Server バージョン 8.1がリリースされました。Information Serverは情報統合のためのスイート製品群であり、IBMの推進する Information On Demand (IOD)を実現するための中核の製品として位置付けられています。本稿では、Information Serverの実行エンジンである通称パラレルエンジンについて紹介するとともに、パラレルエンジンをより効率的に利用する方法について技術的に解説します。前編では、パラレルエンジンの概略とサンプル・ジョブについて、後編ではサンプル・ジョブが解釈・実行される際の詳細とチューニング方法の例を解説します。
前編ではパラレルエンジンの概説とMapReduceジョブの作成方法を紹介してきました。後編では引き続きMapReduceジョブを例とし、パラレルエンジンがどのようにジョブを処理し実行していくかについて解説していきます。
ジョブを実行する仕組みとプロセスモデル
パラレルジョブのコンパイルと実行
前編ではMapReduceジョブを作成し、コンパイル、実行を行いました。それではジョブをコンパイル、実行するときには、内部では何が行われているのでしょうか？この章からは作成したMapReduceジョブを例としてコンパイル・実行したときに何が行われているのかを見ていきましょう。
パラレルジョブを実行するときには、osh.exe (<Install-directory>\Server\PXEngine\bin\osh.exe) (unix では osh) が起動されます。osh.exeはOSH(Orchestrate Shell)と呼ばれるスクリプトファイルを読み込み、実行します。osh.exeが一回に実行する単位をステップといいます。
OSHスクリプトファイルはパラレルジョブをコンパイルすることにより生成されます。1つのジョブは1つのステップに変換され、実行されます。つまりパラレルジョブのコンパイルとはジョブからOSHスクリプトを生成することを意味します。
実行時にはOSHスクリプトと、処理ノードの数や設定を記した構成ファイルから、Score(楽譜)と呼ばれる実行計画が作成されます。Scoreはどの処理ノードに何をするプロセスをいくつ立ち上げるか（プロセスマップ）、どのプロセスがどのプロセスと接続されるか（データフロー）を示す実行計画であり、実行時のシステムの利用効率にとって大変重要です。Scoreはメモリー上に作成されますが、作成されるのが実行時であるため、処理ノードの追加・削除などシステムの構成の変更は、構成ファイルを変更するだけで、元のジョブを変更したりコンパイルし直す必要がありません。
パラレルエンジンはこの実行時に作成されるScoreを参照し、パラレルに複数のプロセスを起動して、ジョブを実行します。図1はジョブ、OSHスクリプト、Scoreの関係を表したものです。
図 1
プロセスモデル
パラレルエンジンのジョブを実行するプログラムは osh.exeです。このosh.exeは実行時には3つの種類のロールを持ったプロセスとして起動されます。パラレルエンジンの用語はオーケストラになぞらえたものが多く、パラレルエンジンのフレームワークは別名"Orchestrate"とも呼ばれています。osh.exeの3つの種類のロールも同様にそれぞれ"Conductor", "Section Leader", "Player" と呼ばれます。
Conductorは複数のノードに渡ってステップの処理全体を制御するプロセスであり、ステップの実行を開始したときに最初に起動されるosh.exeです。OSHスクリプトを解釈し、Scoreを作成します。
Section Leaderはノード内を制御するプロセスであり、Conductorによってrshを介して各ノードに1つずつ生成されます。このとき起動されるのもosh.exeであり、-APT_PMsectionLeaderFlag オプションをつけて起動されます。Section Leaderは起動後 ConductorからScoreを受け取り、Scoreをもとに自分のノード下に必要なPlayerプロセスをforkします。また、PlayerとConductorのコミュニケーションの中継も行います。
Playerは各ステージ(オペレーター)に関連付けられた処理を実際に行うプロセスです。Scoreに描かれるプロセスのマップはPlayerプロセスのものです。
すべてのPlayerプロセスが起動すると、各PlayerプロセスはScoreに書かれたデータフローに従い、データのやり取りを行う他のPlayerとの接続を確立します。Player間の通常の接続方式は同一ハードウェア上では共有メモリ、異なるハードウェア上ではTCPです。設定によって、同一ハードウェア上でFIFOを使うことも出来ます。
すべてのPlayerプロセス間の接続が確立すると、Conductorは処理を開始するよう命令を出し、入力データセットを必要としない上流のPlayerから処理を始め、Playerプロセス間をデータが流れ始めます。
すべてのデータが処理し終わると、各Playerは処理が完了したことをConductorに通知します。
これら Conductor, Section Leader, Playerの関係を示したものが図2です。”C”がConductor、”SL”がSection Leader, “P”がPlayerです。
図 2
ここまでコンパイル時、実行時の処理の流れ、プロセスモデルを説明してきました。ここからは実際のジョブで、OSHスクリプトやScoreがどうなっているかを見ていきましょう。
OSHスクリプトは標準のプロジェクト設定では表示されません。そのため、事前設定として以下の手続きが必要です（図3）。
- アドミニストレーター・クライアント を起動。
- 「プロジェクト管理タブ」を選び、対象プロジェクトを選択。「プロパティ」ボタンを押す。
- 「パラレル」タブの中の「すべてのプロジェクトでパラレル・ジョブの生成OSH を可視にする」チェックボックスを選択。
図 3
この設定後、ジョブ・プロパティに「生成 OSH」タブが追加され、OSHスクリプトが表示されます（図4）。
図 4
MapReduceジョブのOSHスクリプト
それでは、前編で作成したMapReduceジョブのOSHスクリプトを見てみましょう。MapReduceジョブのOSHスクリプトは次のようになっています。
#################################################################
#### STAGE: InputText
## Operator
import
## Operator options
-schema record
{final_delim=end, delim=',', quote=double}
(
word:string[max=32];
)
-file 'C:\\JobSample\\inputtext.txt'
-rejects continue
-reportProgress yes
## General options
[ident('InputText'); jobmon_ident('InputText')]
## Outputs
0> [] 'InputText:Link1.v'
;
#################################################################
#### STAGE: Map
## Operator
generator
## Operator options
-schema record
(
count:int32 {cycle={init=1, incr=0}};
)
## General options
[ident('Map'); jobmon_ident('Map'); par]
## Inputs
0< [] 'InputText:Link1.v'
## Outputs
0> [modify (
count:int32=count;
keep
word;
)] 'Map:Link2.v'
;
#################################################################
#### STAGE: Reduce
## Operator
group
## Operator options
-hash
-key 'word'
-ci
-reduce 'count'
-sum 'count'
## General options
[ident('Reduce'); jobmon_ident('Reduce')]
## Inputs
0< [] 'Map:Link2.v'
## Outputs
0> [modify (
count:not_nullable int32=count;
keep
word;
)] 'Reduce:Link3.v'
;
#################################################################
#### STAGE: CountResult
## Operator
export
## Operator options
-schema record
{final_delim=end, delim=',', quote=none}
(
word:string[max=32];
count:int32;
)
-file 'C:\\JobSample\\output.txt'
-overwrite
-rejects continue
## General options
[ident('CountResult'); jobmon_ident('CountResult')]
## Inputs
0< [] 'Reduce:Link3.v'
;
|
OSHスクリプトでは例外もありますが、通常、ステージはオペレーター、リンクはバーチャルデータセット(*.v)に変換されます。ステージとオペレーターのマッピングは1対1ではなく、設定されたオプションや入力、出力のどちらに使われているかなどによって異なるオペレーターにマッピングされることがあります。
上記のMapReduceジョブでは表1のように変換されています。
表 1
| ステージ名 (ステージ) | 変換されるオペレーター | | InputText (入力のSequential Fileステージ) | import | | Map (Column Generatorステージ) | generator | | Reduce (Aggregator ステージ) | group | | CountResult (出力のSequential Fileステージ) | export |
ステージとオペレーターのマップについて詳しくは「パラレル・ジョブ上級開発者ガイド」の第7章をご覧ください。
入力のSequential Fileステージに対応するブロックは次のようになっています。
#################################################################
#### STAGE: InputText
## Operator
import
## Operator options
-schema record
{final_delim=end, delim=',', quote=double}
(
word:string[max=32];
)
-file 'C:\\JobSample\\inputtext.txt'
-rejects continue
-reportProgress yes
## General options
[ident('InputText'); jobmon_ident('InputText')]
## Outputs
0> [] 'InputText:Link1.v'
;
|
#で始まる行はコメント行です。
OSHスクリプト中で各オペレーターは
operator
-operator-options
[operator-general-options]
Input-datasets
Output-datasets
;
の形式で表現されます。このブロックを集めてひとつのステップが構成されます。
operatorにはオペレーターの名前が入ります。
入力のSequential Fileステージのオペレーターは"import"です。
-operator-options には各オペレーター特有のオプションが指定されます。この部分にはimport オペレーター特有のオプションである -schema, -file, -rejects, -reportProgress のオプションが指定されています。オペレーターのオプションについての詳細は、「パラレル・ジョブ上級開発者ガイド」をご参照ください。
[operator-general-options] には ステージ名、ジョブを"parallel"で動かすか"sequential"で動かすか、結合するかしないか、ノードマップ、ノードプール制約などの設定が書かれます。
Input-datasetsにはそのオペレーターへの入力データセットが
dataset-number < [dataset-options] dataset-name.v
の形式で書かれます。
同様に、Output-datasetsにはそのオペレーターからの出力データセットが
dataset-number >[dataset-options] dataset-name.v
の形式で書かれます。
入力のSequential Fileステージは入力データセットを持たず、出力データセットを1つだけ持ちます。出力データセットは次のようになっています。
## Outputs
0> [] 'InputText:Link1.v'
|
dataset-number は0から始まるシーケンス番号です。データセットが複数ある場合は
0>[dataset-options] dataset-name1.v
1>[dataset-options] dataset-name2.v
のように指定されます。
[dataset-options] にはパーティションの保持の設定、バッファリングの設定などが書かれます。今回の例では何も指定されていません。
通常の方法でジョブを作成した場合、データセット名はステージ名とリンク名から組み合わせた名前となります。同じ名前のデータセットはデータセットを生成するオペレーターとそれを使用するオペレーターで2回、それぞれ出力データセット、入力データセットとして登場します。
'InputText:Link1.v'はimportオペレーター によって出力され、次のgeneratorオペレーターの入力となるため、importの出力データセットとして1回、generatorオペレーターの入力データセットとして1回、計2回指定されています。
オペレーターのタイプ
オペレーターは通常のオペレーターを基本形とし、Combinable operator、Compsite operatorの3つのタイプに分類されます。(generatorオペレーターのようなオペレーターの種類と区別するため、本稿ではオペレーターのタイプを表すときにはoperatorと表記しています）
Combinable operatorは1つのPlayerプロセスで複数のオペレーターを実行するようにできるoperatorです。
パラレルエンジンはPipeline Parallelismによる並列化を行いますが、処理によってはPipeline ParallelismのメリットよりもPlayer間の通信などのオーバーヘッドの方が大きくなってしまうことがあります。Combinable operatorであれば結合してひとつのプロセス上で実行することができます。import、lookup、copy、merge、filterなど多くのオペレーターがCombinable operatorです。
結合されるための必要条件は、
- Combinable operatorであること
- 結合可能モードが「結合」であること（デフォルト値が「結合」である場合も含む）
- オペレーター間の接続がストレート・スルーであること
です。
ストレート・スルー とは、前段と後段のオペレーターの接続が同一ノード内で、1対1になっている状態を言います。（注：ただし、これらの条件がそろっていても必ず結合されることは保証されていません。）
Combinable operatorを結合するかどうかはステージの高度タブの結合可能モードで指定することができます（図5）。
図 5
Composite operatorは一連の処理を行う複数のオペレーターや類似したオペレーターをまとめたものです。
OSHスクリプトではひとつのオペレーターとして表現されていますが、スコアを生成する際に複数のオペレーターに展開されたり、オプションに応じて異なるオペレーターに展開されたりします。export オペレーターやgroup オペレーターはComposite operatorです。exportオペレーターやgroupオペレーター以外では joinオペレーター、lookupオペレーター、transformerオペレーターなどが代表的なComposite operatorです。
MapReduceジョブのScore
これまで説明してきましたように、ScoreはOSHスクリプトと構成ファイルからジョブの実行時に作成されます。ただしScoreはメモリー上に作成されるため、通常の設定ではScoreを確認することができません。Scoreを確認するためには、環境変数 APT_DUMP_SCORE を”真”にセットする必要があります。APT_DUMP_SCOREをセットするとDataStageディレクターなどで生成されたScoreをジョブの実行ログから参照できるようになります。
それでは、MapReduceジョブが2ノードで構成された構成ファイルで実行された際、生成されるScoreを見てみましょう。
main_program: このステップにはデータ・セットがあります。3 datasets:
ds0: {op0[1p] (sequential InputText)
eAny<>eCollectAny
op1[2p] (parallel Map)}
ds1: {op1[2p] (parallel Map)
eOther(APT_HashPartitioner { key={ value=word,
subArgs={ ci }
}
})#>eCollectAny
op2[2p] (parallel APT_HashedGroup2Operator in Reduce)}
ds2: {op2[2p] (parallel APT_HashedGroup2Operator in Reduce)
[pp] >>eCollectAny
op3[1p] (sequential APT_RealFileExportOperator in CountResult)}
これには4 operators:
op0[1p] {(sequential InputText)
ノード上 (
node1[op0,p0]
)}
op1[2p] {(parallel Map)
ノード上 (
node1[op1,p0]
node2[op1,p1]
)}
op2[2p] {(parallel APT_HashedGroup2Operator in Reduce)
ノード上 (
node1[op2,p0]
node2[op2,p1]
)}
op3[1p] {(sequential APT_RealFileExportOperator in CountResult)
ノード上 (
node2[op3,p0]
)}
実行は: 6 processes場所2 nodes.
|
前半の部分ではScore中に現れるデータセットについて記述されます。データセットとは、Job定義中のリンク、OSH中のバーチャルデータセット(*.v)に相当するものです。各データセットは
データセット番号: {producer-operator
partitioner partition-mark collector
consumer-operator}
の形式で表されます。
producer-operatorはそのデータセットを出力するオペレーター、consumer-operatorはそのデータセットを入力とするオペレーターです。
オペレーターは
オペレーター番号[Player processの数] (parallel/sequential オペレーター識別子)
の形式であらわされています。
Player processの数はそのオペレーターが実行されるPayerプロセスの数です。
parallel/sequentialはそのオペレーターがパラレルモードで実行されるかシーケンシャルモードで実行されるかを示します。
オペレーター識別子は、通常のオペレーターの場合はステージ名になります。Composite operatorの場合は、
展開されたオペレーターの名前 in そのオペレーターが含まれるComposite operatorのステージ名
に形式になります。
Composite operatorであるgroupオペレーター(Aggregator ステージ)とexportオペレーター(出力のSequential File ステージ)はそれぞれ展開されてAPT_HashedGroup2Operator とAPT_RealFileExportOperatorになります。
partitioner はそのデータセットに適用されるパーティショナー、collectorはそのデータセットに適用されるコレクターです。
partition-markはデータセットのパーティションの状態を示す記号で、次のような種類があります。
->: 1Playerプロセスから1Playerプロセスの接続
<>: 1Playerプロセスから複数Playerプロセスへの接続
>>: 複数Playerプロセスから1Playerプロセスへの接続
=>: 複数Playerプロセスから複数Playerプロセスへのストレート・スルー接続
#>: 複数Playerプロセスから複数Playerプロセスへのストレート・スルーでない接続
それでは上記の2つ目のデータセットを見てみましょう。
ds1: {op1[2p] (parallel Map)
eOther(APT_HashPartitioner { key={ value=word,
subArgs={ ci }
}
})#>eCollectAny
|
producer であるオペレーターは
consumer であるオペレーターは
op2[2p] (parallel APT_HashedGroup2Operator in Reduce)}
|
ですので、このデータセットはMapとReduce間のリンクに対応するものです。
このデータセットにはパーティショナーに
eOther(APT_HashPartitioner { key={ value=word,
subArgs={ ci }
}
})
|
と書かれています。
MapReduceジョブの設定ではMapとReduceの間のパーティショナーの設定は「自動」となっていましたが、Aggregatorステージでは同じキーを持つレコードは同じPlayerプロセスで処理する必要があります。そのため、APT_HashedGroup2Operatorは自動的にハッシュ・パーティショナーを自分の前のデータセットに挿入するようになっています。
このようにパーティショナーが挿入される場合以外にも、sortオペレーターやbufferオペレーターなどがパラレルエンジンにより自動的に挿入される場合があります。これらの自動的に挿入されたパーティショナーやオペレーターはScoreを見ることで確認することができます。
このデータセットのpartition-mark は
となっており、これは複数ノードから複数ノードへのストレート・スルーでない接続であることを示しています。
はコレクターが 自動（Any） であることを示しています。
Scoreの後半部分は、各オペレーターについての記述になります。
オペレーター番号[Player processの数] {(parallel/sequential オペレーター識別子)
オペレーターの実行されるノード
}
の形式であらわされます。
オペレーター番号, Player processの数, parallel/sequential, オペレーター識別子はデータセットの記述に出てくるものと同様です。オペレーターの実行されるノードは、
ノード名[オペレーター番号, Player process番号]
のリストであらわされます。
MapReduceジョブのScoreで1つめのオペレーター、
op0[1p] {(sequential InputText)
ノード上 (
node1[op0,p0]
)}
|
は1つのプロセス上でシーケンシャルにInputText(Import オペレーター)が実行され、そのノードはnode1であることが示されています。
最後の
実行は: 6 processes場所2 nodes.
|
は、このステップが実行されるのに使われるPlayerプロセスの数とノードの数を表しています。
このScoreをプロセスの観点で図式化すると図6のようになります。
図 6
Scoreを用いた複数ノードでのチューニング
ここまではMapReduceジョブから作成されたOSHスクリプト、Scoreについて解説してきました。この章では、複数処理ノードの環境においてMapReduceジョブをチューニングしていきます。
importオペレーターの並列化
入力のSequential Fileステージは標準の設定では1つの処理ノード上から1つのリーダー(Playerプロセス)のみ起動され、シーケンシャルにファイルは読み取られます。一方、ファイルのフォーマットが固定長レコードの場合は複数Playerから読み取るようにすることが出来ます。
1つのノード上に複数Playerを立ち上げる方法と、複数ノードにそれぞれPlayerを立ち上げる方法があります。1つのノード上に複数Playerを立ち上げるには「ノードごとのリーダー数」を設定します。この方法はSMPに適しています。複数ノードにそれぞれPlayerを立ち上げるには、「複数ノードから読み取り」を"はい"にします。この方法はクラスターシステムに適しています。
今回は「複数ノードから読み取り」を利用してみましょう。
InputText（Sequential Fileステージ)の設定変更
「複数ノードから読み取り」を使用する場合、読み取るファイルのフォーマットは固定長レコードでなければなりません。そこで固定長レコードフォーマットにした図7のような入力ファイル "fixed_inputtext.txt"を用意し、InputTextのファイル名に指定します。ファイルは1行の長さを 引用符（2文字）と改行文字（DOSフォーマットでは2文字）を含めて36にする必要があります。
図 7
固定長レコードのファイルを扱うためには、InputTextの設定を以下のように変更します。
- 「出力」ページ/「プロパティ」タブ - 「複数ノードから読み取り」を "はい" に変更。
- 「出力」ページ/「フォーマット」タブ - 「最終区切り文字」 を "空白"、「レコード区切り文字ストリング」を "DOSフォーマット"、「レコード長」を "36"、「区切り文字」を"空白"に変更。
ジョブの設定を変更後、ジョブを保存し、再度コンパイルしてください。それでは変更後のスコアを見てみましょう。
main_program: このステップにはデータ・セットがあります。3 datasets:
ds0: {op0[2p] (parallel InputText)
eAny=>eCollectAny
op1[2p] (parallel Map)}
ds1: {op1[2p] (parallel Map)
eOther(APT_HashPartitioner { key={ value=word,
subArgs={ ci }
}
})#>eCollectAny
op2[2p] (parallel APT_HashedGroup2Operator in Reduce)}
ds2: {op2[2p] (parallel APT_HashedGroup2Operator in Reduce)
[pp] >>eCollectAny
op3[1p] (sequential APT_RealFileExportOperator in CountResult)}
これには4 operators:
op0[2p] {(parallel InputText)
ノード上 (
node1[op0,p0]
node2[op0,p1]
)}
op1[2p] {(parallel Map)
ノード上 (
node1[op1,p0]
node2[op1,p1]
)}
op2[2p] {(parallel APT_HashedGroup2Operator in Reduce)
ノード上 (
node1[op2,p0]
node2[op2,p1]
)}
op3[1p] {(sequential APT_RealFileExportOperator in CountResult)
ノード上 (
node2[op3,p0]
)}
|
図 8
図 8 はこのScoreをプロセスの観点から図式化したものです。
今回変更した入力のSequential Fileステージ(import オペレーター)は次のようになっています。
op0[2p] {(parallel InputText)
ノード上 (
node1[op0,p0]
node2[op0,p1]
)}
|
プロセス数が1pから2p, 実行モードがsequentialからparallel, 実行されるノードがnode1のみからnode1とnode2に変わっています。このように、標準の設定ではsequentialだったオペレーターを並列化することにより、処理速度を向上させられることがあります。
オペレーターの結合
「オペレーターのタイプ」の章で説明しましたように、オペレーターの中には結合可能なものもあります。MapReduce ジョブに含まれるオペレーターの中で、importオペレーター、generatorオペレーター、（Composite operatorである）exportオペレーターを展開したAPT_RealFileExportOperatorなどはCombinable operatorです。一方 （Composite operatorである）groupオペレーターを展開したAPT_HashedGroup2OperatorはCombinable operatorではありません。
Player間の通信などのオーバーヘッドがPipeline Parallelismのメリットよりも大きくなっているような処理の場合、オペレーターを結合すると、パフォーマンスにメリットがあります。隣り合うimport オペレーターとgeneratorオペレーターはともにCombinable operatorであり、node1とnode2でparallelに動くため、設定や条件によっては結合させることができます。
オペレーターを結合させるにはオペレーター間のデータ・フローがストレート・スルーである必要があります。ストレート・スルーにするためには、接続されている前段、後段のオペレーターが同じ処理ノード上で実行され、かつ、パーティション・タイプが自動 もしくは 同一 である必要があります。
importオペレーター, generatorオペレーター間のデータセットである データセット ds0のパーティショナーは 自動（Any） であり、ともにnode1、node2で実行されるため、この条件を満たしています。実際にimportオペレーター、generatorオペレーター間のデータセットの partition-markは “=>”となっており、ストレートスルー接続であることが示されています。
また、importオペレーター、generatorオペレーターの結合可能モードがともに結合可能である必要もあります。
これらの変更をするため、以下の設定変更を行います。
InputText（Sequential Fileステージ)の設定変更
- 「ステージ」ページ/「高度」タブ - 「結合可能モード」を "結合可能" に変更。
Map （Column Generatorステージ)の設定変更
- 「ステージ」ページ/「高度」タブ - 「結合可能モード」を "結合可能" に変更。
ジョブの設定を変更後、ジョブを保存し、コンパイルしてください。この変更を適用した後のスコアを見てみましょう。
main_program: このステップにはデータ・セットがあります。2 datasets:
ds0: {op0[2p] (parallel APT_CombinedOperatorController:Map)
eOther(APT_HashPartitioner { key={ value=word,
subArgs={ ci }
}
})#>eCollectAny
op1[2p] (parallel APT_HashedGroup2Operator in Reduce)}
ds1: {op1[2p] (parallel APT_HashedGroup2Operator in Reduce)
>>eCollectAny
op2[1p] (sequential APT_RealFileExportOperator in CountResult)}
これには3 operators:
op0[2p] {(parallel APT_CombinedOperatorController:
(InputText)
(Map)
) ノード上 (
node1[op0,p0]
node2[op0,p1]
)}
op1[2p] {(parallel APT_HashedGroup2Operator in Reduce)
ノード上 (
node1[op1,p0]
node2[op1,p1]
)}
op2[1p] {(sequential APT_RealFileExportOperator in CountResult)
ノード上 (
node2[op2,p0]
)}
|
1つ目のオペレーター、
op0[2p] {(parallel APT_CombinedOperatorController:
(InputText)
(Map)
) ノード上 (
node1[op0,p0]
node2[op0,p1]
)}
|
に注目してください。
APT_CombinedOperatorController は結合された複数のオペレーターを制御するオペレーターです。その後ろには結合されたオペレーターのリストが書かれています。上記のAPT_CombinedOperatorControllerにはInputText(importオペレーター)とMap(generatorオペレーター)の2つのオペレーターが結合されていることが示されています（図9)。
図 9
importオペレーターとgeneratorオペレーターが結合され、その間のコミュニケーションが不要になったため、スコアに表示されるデータセットの数が一つ減り、2つになっています。
このように複数のオペレーターを結合することにより、並列に処理するメリットよりもコミュニケーションのオーバーヘッドが大きい場合、不要なコミュニケーションをなくし効率化することができますます。また、処理が軽いオペレーターを集めて1つのプロセスにすることで"
1つのプロセスにすることでCPU全体の負荷を軽くすることができます。
Importオペレーターの並列化や、オペレーターの結合は多くの場合有効なチューニング手段ですが、ジョブや環境、システムの構成などによっては必ずしも効果的な手段とならない場合もあります。ジョブやシステムの構成などに応じて、Scoreを確認しながら、システム全体の効率を改善していくことが重要です。
まとめ
Information Serverの実行エンジンであるパラレルエンジンについて、前編ではパラレルエンジンの概略とサンプル・ジョブについて、後編ではサンプル・ジョブが解釈・実行される際の詳細とチューニング方法の例を解説してきました。簡単なサンプルジョブを例にしての解説ですが、ご参考になれば幸いです。
参考文献
著者について  | | | 杉嵜 百合子は日本アイ・ビー・エムのソフトウェア開発研究所に勤務。Information Serverの開発に関わっています。 |
| | | 田原 義則は日本アイ・ビー・エムのソフトウェア開発研究所に勤務。Information Serverの開発に関わっています。 |
記事の評価
| 
