パラレルストリーミング処理(Parallel Streaming Processing、以下:PSP)は、DataSpider Servistaで大容量データを高速に処理する機構です。
Standalone版では使用できません。
PSPは、以下のような特徴を持っています。
- 超大容量データ処理
PSPは超大容量のデータを処理することができます。理論上、データ容量の制限はありません。
XML Frameworkの大容量データ処理では、処理結果のデータをファイルに出力することでメモリ不足を解決しています。
しかし、XML Frameworkの大容量データ処理を行う場合、次の2点の問題が発生します。
- 物理ディスク容量
処理結果のデータをファイルに出力するため、処理結果のデータ容量以上のディスク空き領域が必要となります。1Gバイト程度であれば問題のない場合が多いですが、1Tバイト程度になるとディスク空き容量の問題が発生します。
- パフォーマンス
処理結果のデータをファイルに出力するため、オンメモリの処理と比較して、パフォーマンスが劣化します。
PSPでは処理結果のデータをファイルに出力せず、すべてオンメモリで処理を行います。
よってPSPでは、上記問題が発生することはありません。
- 分散処理
I/O処理に時間がかかる、または回数が多いアプリケーションではI/O待ちになることが多く、CPU資源を有効に使っていません。PSPでは読み取り、変換、書き込みの各処理をマルチスレッドで動作し処理を分散させるため、1つの処理がI/O待ちになっている状態でも、他のスレッドで変換などの処理を並行で行います。
パラレルストリーミング処理のアーキテクチャ
PSPは以下のアーキテクチャで動作します。読み込み処理、変換処理、書き込み処理をブロック単位で同時に別々のスレッドで処理します。
結果データを生成する(上図では、読み取り処理および変換処理)コンポーネントは、内部的に結果データを格納するブロック(例えば1000行単位)を2つ保持するようになっています。
結果データを生成するコンポーネントは書き込み可能な状態(データが消費されている状態)のブロックを検出すると、書き込み処理を行います。書き込み可能なブロックを検出できない状態(データが消費されていない状態)では、処理がブロックされます。
結果データを利用するコンポーネント(上図では、変換処理および書き込み処理)は、入力元のコンポーネントの結果データに、読み取り可能な状態(データの生成が完了した状態)のブロックを検出すると処理を開始します。読み取り可能なブロックを検出できない状態(データの生成が未完了な状態)では処理がブロックされます。
処理の流れ
「読み取り」-「変換」-「書き込み」の簡単なサンプルで、処理の流れを処理ステップごとに説明します。
各ステップのデータa、データb、データcは、読み取り用データの1ブロックを表します。
ステップ1:処理前
- データa:まだ読み込まれていません。
- データb:まだ読み込まれていません。
- データc:まだ読み込まれていません。
ステップ2:「データa」の読み取り
- データa:読み取り処理で読み込まれ、読み取りコンポーネントのブロックに格納されます。
- データb:まだ読み込まれていません。
- データc:まだ読み込まれていません。
ステップ3:「データb」の読み取りと「データa」の変換
- データa:変換処理で変換され、変換コンポーネントのブロックに格納されます。
- データb:読み取り処理で読み込まれ、読み取りコンポーネントのブロックに格納されます。
- データc:まだ読み込まれていません。
すべての処理が並行で行われます。
ステップ4:「データc」の読み取りと「データb」の変換および「データa」の書き込み
- データa:書き込み処理で実際にデータが書き込まれます。また、変換処理が完了しているので、読み取り処理のブロックから削除されます。
- データb:変換処理で変換され、変換コンポーネントのブロックに格納されます。
- データc:読み取りコンポーネントのブロックが空いたので、読み取り処理で読み込まれ、読み取りコンポーネントのブロックに格納されます。
すべての処理が並行で行われます。
ステップ5:「データc」の変換と「データb」の書き込み
- データa:書き込み処理まで終了しています。
- データb:書き込み処理で実際にデータが書き込まれます。また、変換処理が完了しているので、読み取り処理のブロックから削除されます。
- データc:変換処理で変換され、変換コンポーネントのブロックに格納されます。
すべての処理が並行で行われます。
ステップ6:「データc」の書き込み
- データa:書き込み処理まで終了しています。
- データb:書き込み処理まで終了しています。
- データc:書き込み処理で実際にデータが書き込まれます。また、変換処理が完了しているので、読み取り処理のブロックから削除されます。
すべての処理が並行で行われます。
このように、データをブロック単位に分割し、そのブロック単位を並行して処理することで、超大容量データを高速に処理しています。
パラレルストリーミング処理の使いどころ
PSPの特徴のうち、「分散処理」には、適している処理と適していない処理が存在します。
適している処理
PSPは前述のように、各読み取り処理や書き込み処理、変換処理自体を高速にする機構ではありません。各処理を分散に、並行処理することによってスクリプト全体の処理を高速にしています。
そのため、PSPは以下のような処理に適しています。
- 読み取り処理、変換処理、書き込み処理の各処理時間が一様またはそれに近い場合
下図のように、スクリプト全体に占める処理時間が一様のスクリプトの場合には、PSPによるパフォーマンスの向上が期待できます。
読み取り、変換、書き込みの各処理が各スレッドに分散され、ほとんどブロックされることなく、各処理が並行で処理されます。
読み取りまたは変換、書き込みの各処理の時間プラスαでスクリプト全体の処理完了が期待できます。下図のスクリプトではPSPを行うことにより、約3倍(33%程度の処理時間)のパフォーマンス向上が期待できます。
処理によってはPSPを行わなかった処理と比較し、数倍のパフォーマンスが得られる場合もあります。
PSPが適しているスクリプトパターン
スクリプト全体に占める処理時間の割合を表します。
処理が高速になる要因として、オブジェクト生成数の減少が挙げられます。
PSPの場合、ブロックサイズ(固定)x列分の配列しか持ちません。通常の処理の場合(非PSP)には、全行(可変)x列分の配列を生成します。
また、I/O処理時間の割合が大きいほど、パフォーマンス向上への効果が小さくなります。
ファイル系(ローカルのファイルへのアクセス)はI/O処理時間割合が小さい処理です。DB系やネットワーク越しのファイルアクセスはI/O処理時間割合が大きい処理です。
適していない処理
逆にPSPは次のような処理には適していません。つまり、PSPを行わなかった処理と比較してパフォーマンスの向上が期待できません。
- 読み取り、変換、書き込みのいずれかの処理にほとんどの処理時間が費やされている場合
下図のように、読み取り、変換、書き込みのいずれかの処理にスクリプト処理時間のほとんどが費やされている場合、PSPによるパフォーマンスの向上は期待できません。
PSPは各処理を高速にしているわけではないため、処理を分散し並行で処理を行ったとしても、1つの処理がボトルネックになってしまいます。
下図のスクリプトでは書き込み処理で全体の90%の処理時間を費やしているため、PSPを行ったとしても、スクリプトの処理時間が90%以下になることはありません。逆に、スレッドの同期化などの処理が加わるため、PSPを行ったほうが処理に時間がかかる場合があります。
- 同一のI/Oで読み書きする場合
読み取り、書き込みのI/O処理が同一の場合には、処理を分散して並行で処理を行ったとしても、I/O処理で並行処理が行われない場合があります。
このような場合には、やはりPSPのパフォーマンス向上は期待できません。
PSPが適していないスクリプトパターン
スクリプト全体に占める処理時間の割合を表します。
PSPをスクリプトで使用する方法は、スクリプト作成時に[パラレルストリーミング処理を行う]にチェックを入れてスクリプトを作成します。
PSPスクリプトはプロジェクトエクスプローラ上で「P」マークが付きます。
PSPで使用できるコンポーネントは以下の通りです。
- データベース(RDB)アダプタ
- CSVアダプタ
- Excelアダプタ
- 固定長アダプタ
- 可変長アダプタ
- Dr.Sum EAアダプタ
- Mapper
PSP スクリプトとしてスクリプトを作成すると、ツールパレットには使用できるアダプタ、コンバータのみ表示されるようになります。
PSPスクリプトで使用可能なMapperロジックについては、「Mapperロジック一覧」を参照してください。
パラレルストリーミング処理とスレッド
前項で説明したように、PSPでは複数のスレッドが協調して処理を行います。
PSPスクリプトではスクリプトのスレッドの他に、結果データを生成する(入力元となる)コンポーネントの数だけスレッドが生成されます。結果データを生成しない書き込みコンポーネントに関しては、スクリプトと同じスレッドで動作します。
例えば、「読み取り」-「変換」-「書き込み」のスクリプトでは、生成するスレッド数は「3」となります。
「読み取り」-「変換」-「変換」-「書き込み」のスクリプトでは、生成するスレッド数は「5」となります。
扱えるデータ量について
PSPスクリプト内で扱うことのできるデータ量は理論上制限がありません。
Mapperの数について
PSPスクリプト内で使用できるMapperの数について制限はありません。
スクリプト呼び出しについて
PSPを使用した場合もスクリプト呼び出し方法は通常と同じです。スクリプト間のデータの受け渡しについても通常の受け渡し方法と同様です。