JP6620609B2 - 分散処理実行管理プログラム、分散処理実行管理方法および分散処理実行管理装置 - Google Patents

Description

本発明は、分散処理実行管理プログラム、分散処理実行管理方法および分散処理実行管理装置に関する。

近年、ビッグデータに対する機械学習が注目されている。このようなビッグデータに対する機械学習では、複数サーバによる分散処理により処理の高速化が行われる。この複数サーバによる分散処理には、例えば、インメモリ上で高速な処理を実現するApache Spark（以下、「Spark」とも称する。）などのソフトウェアが使用される。

特開２０１２−０２２５５８号公報 特開２０１３−０７３３０１号公報

機械学習は、学習フェーズと予測フェーズの二つからなる。学習フェーズでは、データを入力として予測モデルを出力する。予測フェーズでは、学習フェーズで出力された予測モデルと、入力データを基に予測する。機械学習では、予測モデルによる予測結果の予測精度が重要である。そこで、機械学習では、予測結果の予測精度を高めるため、予測モデルの変更可能な各種の処理パラメータを変えて、予測モデルの作成と予測を繰り返して、予測精度が高くなる処理パラメータの組み合わせを求める。機械学習では、予測精度の高い予測モデルを得るには、探索する処理パラメータの組み合わせの数が多いほど良い。

ところで、機械学習では、分散処理に使用可能な時間に制限がある場合がある。例えば、予測モデルの使用の開始時間が予め決まっており、分散処理に制限時間がある場合がある。この場合、制限時間までに得られた予測モデルの中から最も高い予測精度を持つ予測モデルを求める。機械学習は、制限時間内に、探索されたパラメータの組み合わせの数に応じて予測モデルの予測精度が向上する。このため、機械学習を複数サーバによって分散処理する場合、分散処理の処理効率が予測精度に影響する。機械学習のような最適化問題では、分散処理される処理の中には、最終的な予測精度に大きな影響を与えない処理も存在する。分散処理の処理効率を高めるには、このように予測精度に大きな影響を与えない処理を中断できることが望ましい。

しかしながら、Spark等の従来の分散処理のワークフレームは、実行中はそれぞれの分散処理の処理結果を管理はしておらず、また、処理の中断を判断させると、却って、並列処理の速度が落ち、分散処理の処理効率が低下する場合がある。

なお、ここでは、機械学習の分散処理を例に問題を説明した。しかし、このような問題は、従来の分散処理のワークフレームによる分散処理全般に発生する問題である。

一つの側面では、分散処理の処理効率を向上させることができる分散処理実行管理プログラム、分散処理実行管理方法および分散処理実行管理装置を提供することを目的とする。

第１の案では、分散処理実行管理プログラムは、コンピュータに、処理対象ジョブを分散して部分処理する複数のノードそれぞれから、部分処理の処理結果を収集する処理を実行させる。分散処理実行管理プログラムは、コンピュータに、収集された部分処理の処理結果に基づき、部分処理に対応する全体処理の処理結果である全体処理結果を推定する処理を実行させる。分散処理実行管理プログラムは、コンピュータに、推定された全体処理結果に応じて、全体処理に対応する他の部分処理の実行継続可否を判断する処理を実行させる。

本発明の一の実施態様によれば、分散処理の処理効率を向上させることができるという効果を奏する。

図１は、分散処理システムの概略的な構成の一例を示す図である。 図２は、マスタ部およびワーカ部の概略的なソフトウェア構成の一例を示す図である。 図３は、機械学習の概略的な流れを模式的に示した図である。 図４は、従来のSparkによる機械学習の分散処理の一例を模式的に示した図である。 図５は、実施例に係る機械学習の分散処理の一例を模式的に示した図である。 図６は、実施例に係る分散処理システムによる機械学習の概略的な流れを模式的に示した図である。 図７は、K-cross-validationによる予測モデルの検証の概略的な流れを模式的に示した図である。 図８は、予測モデルを検証するジョブの流れを模式的に示した図である。 図９は、機械学習の概略的な流れを模式的に示した図である。 図１０は、分散処理の手順の一例を示すフローチャートである。 図１１は、検証処理の手順の一例を示すフローチャートである。 図１２は、予測モデル検証処理の手順の一例を示すフローチャートである。 図１３は、管理処理の手順の一例を示すフローチャートである。 図１４は、分散処理実行管理プログラムを実行するコンピュータの構成の一例を示す説明図である。

以下に、本発明にかかる分散処理実行管理プログラム、分散処理実行管理方法および分散処理実行管理装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

実施例１に係る分散処理システムについて説明する。図１は、分散処理システムの概略的な構成の一例を示す図である。

分散処理システム１は、管理サーバ１０と、複数のノード１１−１，・・・，１１−ｎ（ｎは所定の自然数）とを有する。複数のノード１１−１，・・・，１１−ｎを、ノード１１と総称する。管理サーバ１０とノード１１との間は、ネットワークＮを介して通信可能に接続される。かかるネットワークＮの一態様としては、有線または無線を問わず、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の通信網が挙げられる。

管理サーバ１０は、分散処理を管理する装置である。管理サーバ１０は、例えば、パーソナルコンピュータやサーバコンピュータなどのコンピュータである。管理サーバ１０は、１台のコンピュータとして実装してもよく、また、複数台のコンピュータにより実装してもよい。また、管理サーバ１０は、コンピュータを仮想化した仮想マシンであってもよい。なお、本実施例では、管理サーバ１０を１台のコンピュータとした場合を例として説明する。図１の例は、機能的な構成を図示しているため、図示を省略しているが、管理サーバ１０は、コンピュータを構成する各種のハードウェアを有する。例えば、管理サーバ１０は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）などの記憶部や、ＲＡＭ（Random Access Memory）などのメモリ、ＣＰＵ（Central Processing Unit）などの装置を制御する制御部を有する。管理サーバ１０は、記憶部に記憶された各種のプログラムが制御部で動作することにより各種の処理部として機能する。管理サーバ１０は、マスタ部２０と、管理部２１とを有する。

マスタ部２０は、分散処理を管理する。例えば、マスタ部２０は、分散処理に関する全体情報を管理しており、各ノード１１に対して分散処理のタスク割り当て、タスクの実行を指示する。管理部２１は、各ノード１１から実行された処理の処理結果を収集し、分散処理の実行継続可否を判断する。管理部２１の詳細は後述する。

ノード１１は、割り当てられた分散処理を実行する装置である。ノード１１は、例えば、パーソナルコンピュータやサーバコンピュータなどのコンピュータである。各ノード１１も、１台のコンピュータとして実装してもよく、また、複数台のコンピュータにより実装してもよい。また、ノード１１は、コンピュータを仮想化した仮想マシンであってもよい。なお、本実施例では、各ノード１１を１台のコンピュータとした場合を例として説明する。図１の例は、機能的な構成を図示しているため、図示を省略しているが、各ノード１１は、コンピュータを構成する各種のハードウェアを有する。例えば、各ノード１１は、ＨＤＤ、ＳＳＤなどの記憶部や、ＲＡＭなどのメモリ、ＣＰＵなどの装置を制御する制御部を有する。ノード１１は、記憶部に記憶された各種のプログラムが制御部で動作することにより各種の処理部として機能する。ノード１１は、ワーカ部３０を有する。

ワーカ部３０は、分散処理を実行する。例えば、ワーカ部３０は、マスタ部２０から実行が指示されたタスクの処理を実行する。

ここで、分散処理を実現するマスタ部２０およびワーカ部３０のソフトウェア的な構成を説明する。図２は、マスタ部およびワーカ部の概略的なソフトウェア構成の一例を示す図である。図２に示すようにマスタ部２０およびワーカ部３０は、処理系、資源管理、分散ファイルシステムの３層に機能的に分かれる。

分散ファイルシステムは、分散処理の対象となるデータの保管・管理を行う。ビッグデータを分散処理する場合、分散処理の対象となるビッグデータは、例えば、テラバイトやペタバイトといった膨大な量のデータとなる。このようなビッグデータは、管理サーバ１０や各ノード１１のＨＤＤ、ＳＳＤなどの記憶部に分散して記憶される。分散ファイルシステムは、管理サーバ１０や各ノード１１に分散して記憶された各データを管理し、１つのシームレスなファイルシステムとして、データ・ファイルに対するアクセスおよび保管操作を可能とする。分散ファイルシステムとしては、例えば、HDFS（Hadoop Distributed File System）が挙げられるが、これに限定されるものではない。HDFSの場合、マスタ部２０では、Name Nodeが動作する。ワーカ部３０では、Data Nodeが動作する。

資源管理では、各ノード１１のＣＰＵやメモリ、ディスク帯域幅、ネットワーク帯域幅などの資源の割り当て管理やスケジューリングを行う。資源管理としては、例えば、YARN（Yet Another Resource Negotiator）が挙げられるが、これに限定されるものではない。YARNの場合、マスタ部２０では、Resource Managerが動作する。ワーカ部３０では、Node Managerが動作する。

処理系は、分散処理の実行、管理を行う。処理系としては、例えば、Sparkが挙げられるが、これに限定されるものではない。本実施例では、分散処理を実行、管理するソフトウェアとして、Sparkを用いて説明する。ただし、本実施例に係る技術は、Sparkに特有の手法ではなく、一般の並列分散処理の仕組みにも適用可能である。Sparkの場合、マスタ部２０では、Driverが動作する。ワーカ部３０では、Executorが動作する。

ところで、機械学習では、予測結果の予測精度を高めるため、予測モデルの変更可能な各種の処理パラメータを変えて、予測モデルの作成と予測を繰り返して、予測精度が高くなる処理パラメータの組み合わせを求める。予測モデルの変更可能な各種の処理パラメータには、例えば、学習アルゴリズム、学習アルゴリズムのハイパーパラメータ、学習に用いるライブラリなどがある。機械学習では、各処理パラメータについて探索する組み合わせの範囲を事前に指定する。各処理パラメータの探索する範囲は、管理者等のユーザが指定してもよく、以前の学習の結果などから演算等によって導出してもよい。機械学習では、指定された範囲で各処理パラメータの組み合わせを変えながら順番に、あるいは同時に学習と予測を行い、より高い予測精度を得る組み合わせを探索する。そして、機械学習では、探索の結果、最も高い予測精度が得られた予測モデルを正式に採用する。

Sparkは、インメモリ上で高速な処理を実現している。Sparkは、Sparkの出現以前にビッグデータの処理方法としてデファクトスタンダードであった、MapReduceが苦手としているジョブの繰り返し処理を高速化できる。このため、Sparkは、機械学習と親和性が高い。機械学習では、Sparkを使うことで一回の試行の処理時間が、MapReduceと比べて短縮し、試行可能な回数は向上する。

図３は、機械学習の概略的な流れを模式的に示した図である。機械学習では、予測精度の高い予測モデルを得るには、探索する処理パラメータの組み合わせの数が多いほど良い。一方、機械学習では、処理に使用可能な時間として制限時間が定まっている場合がある。例えば、機械学習では、予測モデルの使用の開始時間が予め決まっている場合がある。このため、機械学習では、Sparkによって処理の高速化を実現されるものの、実行できる試行回数が十分ではない場合がある。この場合、機械学習では、開始時間までに得られた予測モデルの中から最も高い予測精度を持つ予測モデルを求める。

図３の例では、予測モデルの探索に制限時間が定まっている。図３（Ａ）の例は、組み合わせ１から組み合わせ５と順に予測モデルの探索の処理が実行され、組み合わせ５の途中で制限時間を超える。組み合わせ１の予測モデルは、予測精度が７０％である。組み合わせ２の予測モデルは、予測精度が８０％である。組み合わせ３の予測モデルは、予測精度が５０％である。組み合わせ４の予測モデルは、予測精度が６０％である。図３（Ａ）の例では、予測精度が８０％である組み合わせ２の予測モデルが、最も高い予測精度を持つ予測モデルとして求まる。

機械学習のような最適化問題では、分散処理される処理の中には、最終的な予測精度に大きな影響を与えない処理も存在する。例えば、組み合わせ３の予測モデルは、予測精度が５０％と予測精度が低く、最終的な予測モデルとしては選択されない。分散処理の処理効率を高めるには、このように予測精度に大きな影響を与えない処理を中断できることが望ましい。

しかしながら、Spark等の従来の分散処理のワークフレームは、実行中は処理パラメータの組み合わせそれぞれの分散処理の途中の処理結果を管理していない。また、従来の分散処理のワークフレームは、処理の中断を判断させると、却って、並列処理の速度が落ち、分散処理の処理効率が低下する場合がある。例えば、従来の分散処理のワークフレームは、処理の中断を判断させ、ワークフレームの処理を強制的に打ち切った場合、処理を再度実行するために初期オーバヘッドがかかる。図３（Ｂ）の例は、組み合わせ１、組み合わせ２、組み合わせ３と順に予測モデルの探索の処理を実行し、組み合わせ３の処理の途中で予測精度が低いことが推定されたために組み合わせ３の処理を強制的に打ち切っている。この場合、従来の分散処理のワークフレームでは、組み合わせ３の処理を強制的に打ち切った後、組み合わせ３の処理を実行する際に初期オーバヘッドがかかる。初期オーバヘッドには、例えば、並列処理の起動や、過去に試した組み合わせを避けるための処理がある。図３（Ｂ）の例は、組み合わせ４から処理を再度実行し、組み合わせ５の処理の完了後に制限時間を超えている。組み合わせ１の予測モデルは、予測精度が７０％である。組み合わせ２の予測モデルは、予測精度が８０％である。組み合わせ４の予測モデルは、予測精度が６０％である。組み合わせ５の予測モデルは、予測精度が８５％である。図３（Ｂ）の例では、予測精度が８５％である組み合わせ５の予測モデルが、最も高い精度を持つ予測モデルとして求まる。

初期オーバヘッドを減らす工夫として、例えば、定期的に結果をチェックポイントとして記憶し、再実行の際はチェックポインントの結果を見て一度探索した処理を避ける方法も考えられる。しかし、チェックポイントとチェックポイントの間の処理は、再実行せざるをえない。また、従来の分散処理のワークフレームは、処理を強制的に終了すると、処理を再度実行するため並列処理を起動するためのオーバヘッドを避けることができない。

そこで、本実施例に係る分散処理システム１では、図１に示すように、管理部２１を設けている。本実施例に係る分散処理システム１では、分散処理の実行中に、ある処理パラメータの組み合わせの処理を継続するか否かを実行中に管理部２１で判断し、分散処理の一部を選択して中止できるようにしている。管理部２１は、マスタ部２０およびワーカ部３０による分散処理を止めることなく、実行中の結果を見て処理を継続するのか次の処理パラメータの組み合わせの処理を試行するべきかを判断する。

以下、具体的な方法の一例をより詳細に説明する。以下では、分散処理を行う代表的なソフトウェアとしてSparkを用いて説明する。ただし、本実施例に係る技術は、Sparkに特有の手法ではなく、一般の並列分散処理の仕組みにも適用可能である。

Sparkは、処理の粒度の単位として、アプリケーション＞ジョブ＞ステージ＞タスクがある。それぞれ下位の処理が１または複数集まって上位の処理を構成する。例えば、機械学習の処理は、アプリケーションに対応する。処理パラメータの組み合わせごとの探索の処理は、１または複数のジョブの集合による処理として示すことができる。Sparkは、マスタ・ワーカ型の分散処理システムである。マスタ部２０を構成するDriverが、各ワーカ部３０を構成するExecutorにタスクの実行を指示する。Driverは、ジョブの結果が出るごとに、Executorから結果を取得し、次のジョブの実行を実施する。

図４は、従来のSparkによる機械学習の分散処理の一例を模式的に示した図である。Sparkによる機械学習の分散処理では、ジョブが１つ以上のステージに分けて実行される。ジョブは、Executor間でデータの共有を行う処理の切れ目でステージに分割される。ステージは、１または複数のタスクで構成され、ステージを構成するタスクが全て終わるとステージの実行が完了したとみなされる。図４の例では、３つのステージ（１０個のタスク）によって一つの組み合わせによるモデル探索の処理を実現している。Executorは、タスクやステージの単位ではなくジョブの単位でDriverに処理結果を返す。Sparkによる機械学習の分散処理では、図４に示すジョブが処理パラメータの組み合わせ毎に繰り返し実行される。

Driverは、ジョブの処理を中止させる仕組みを持つ。例えば、Driverは、実行中のジョブの処理を中止する制御命令を有する。しかし、Driverは、ジョブの処理実行中に、実行中のジョブのタスクやステージの途中実行結果などの実行状況の情報を得る手段がない。このため、例えば、Executorは、ジョブの中断を判断するのに充分な情報がタスクやステージの結果としてExecutorの中に存在しても、ジョブの単位でしかDriverに処理結果を返さない。Driverは、ジョブの処理の途中では実行状況の情報が得られないため、ジョブの処理の途中で中止を判断することができない。

Sparkがタスクやステージの単位ではなくジョブの単位でExecutorからDriverに処理結果を返す理由は、細かい処理の単位でDriverに処理結果を返すと、実行効率が低下するためである。Sparkによる分散処理では、ExecutorからDriverに処理結果を返すと全体の処理の制御がDriverに移る。Executorは、Driverに処理の制御が移ると、Driverから指示があるまで分散処理がアイドル状態となる。すなわち、分散処理の実行が一旦止まる。Sparkでは、実行効率を高めるために、大きな粒度であるジョブ単位でExecutorに処理の制御を与えている。

機械学習では、例えば、処理パラメータの一つの組み合わせによる予測モデルの検証を一つのジョブとして実行する。バッチの最中に処理を途中で止めるべきか判断する情報をDriverに返すには、タスクやステージの処理結果をDriverに返さなくてはならない。この場合、タスクやステージの処理が完了するごとに、Driverに制御が移ることになり、予測モデルの検証の効率が落ち、全体として検証できる組み合わせの数が減る問題が発生する。このため、Executorは、タスクやステージの単位ではなくジョブの単位でDriverに処理結果を返す。

本実施例に係る分散処理システム１では、制御をDriverに返さずにジョブの実行を途中で停止するかを判断するため、図１に示すように、管理サーバ１０に管理部２１を設けている。

図５は、実施例に係る機械学習の分散処理の一例を模式的に示した図である。本実施例に係る各ノード１１のExecutorは、処理を中止するべきか継続するべきかの判断基準となるタスクの処理結果が求まると、処理結果を示す処理結果情報を管理部２１に送信する。図５の例では、各ステージの最終のタスクが処理結果を示す処理結果情報を管理部２１に送信する。管理部２１は、各ノード１１から送信された処理結果情報に基づき、分散処理の実行継続可否を判断する。管理部２１は、分散処理の継続が不要と判断した場合、ジョブの処理中止を指示する指示情報をDriverに送る。

本実施例に係る管理部２１の構成についてより詳細に説明する。図１に示すように、管理部２１は、収集部４０と、推定部４１と、判断部４２とを有する。

収集部４０は、各種の情報を収集する。例えば、収集部４０は、処理対象ジョブを分散して部分処理する複数のノード１１それぞれから、部分処理の処理結果を収集する。例えば、収集部４０は、処理対象ジョブを分散して実行する複数のノード１１から、処理対象ジョブの部分処理であるタスクやステージの処理結果を収集する。処理結果は、複数のノード１１でそれぞれ処理されて保持された処理結果であってもよく、複数のノード１１でそれぞれ実行されるプロセスにより生成された処理結果であってもよい。図５に示すように、ステージは、１つのExecutorで処理される場合もあり、複数のExecutorで処理される場合もある。収集部４０は、それぞれのノードのExecutorで処理された処理結果、または、複数のノード１１のExecutorでそれぞれ処理された処理結果を収集する。

推定部４１は、各種の推定を行う。例えば、推定部４１は、収集部４０により収集された部分処理の処理結果に基づき、部分処理に対応する全体処理の処理結果である全体処理結果を推定する。例えば、推定部４１は、収集された部分処理の処理結果に基づき、部分処理に対応するジョブの予測モデルの予測精度を推定する。例えば、推定部４１は、収集されたジョブの部分処理での予測精度の平均を求め、予測精度の平均を全体処理結果の予測精度と推定する。なお、推定部４１は、予測精度を１つ得た段階から平均を求めてもよく、予測精度を所定個収集した段階から平均を求めてもよい。全体処理結果の予測方法は、平均に限定されない。例えば、推定部４１は、収集された部分処理の処理結果から、既知の予測モデルを用いて全体処理結果を推定してもよい。

判断部４２は、各種の判断を行う。例えば、判断部４２は、推定部４１により推定された全体処理結果に応じて、全体処理に対応する他の部分処理の実行継続可否を判断する。例えば、判断部４２は、推定部４１により推定された全体処理結果が、ジョブを中止するべきかの判断基準を満たす場合、ジョブの残りの処理を不要と判断する。判断基準は、固定で設定されていてもよく、管理者等のユーザから事前に指定されてもよく、以前の処理結果を用いて動的に定めてもよい。

ジョブを中止するべきかの判断基準には、２つの状況が考えられる。１つ目は、要求される性能条件を満たすことが推定される場合である。例えば、部分処理の結果から予測モデルが十分な予測精度が得られることが推定される場合である。２つ目は、要求される性能条件を満たさないことが推定される場合である。例えば、部分処理の結果から予測モデルの予測精度が低いことが推定される場合である。

そこで、判断部４２は、推定部４１により推定された全体処理結果が、要求される所定の性能条件を満たすことが推定される場合、または、性能条件を満たさないことが推定される場合、前記全体処理に対応する他の部分処理の実行を不要と判断する。例えば、判断部４２は、推定部４１により推定された予測精度が、第１の予測精度を満たす場合、または、第１の予測精度より低い第２の予測精度を満たさない場合、予測精度を推定したジョブの残りの部分処理の実行を不要と判断する。例えば、第１の予測精度は、８５％とする。第２の予測精度は、５０％とする。第１の予測精度および第２の予測精度は、固定で設定されていてもよく、管理者等のユーザから事前に指定されてもよく、以前の処理結果を用いて動的に定めてもよい。例えば、第１の予測精度は、初期値を８５％とするが、予測精度が８５％を超えた予測モデルがある場合、当該予測モデルの予測精度に更新してもよい。第２の予測精度は、初期値を５０％とするが、予測モデルの予測精度が収集された場合、収集された予測精度の最大値から所定値（例えば、１５％）低い値に更新してもよい。

判断部４２は、ジョブの残りの部分処理の実行を不要と判断した場合、マスタ部２０に対してジョブの処理中止を指示する指示情報を送る。

マスタ部２０を構成するDriverは、ジョブの処理中止を指示する指示情報を受け付けると、処理中止を指示されたジョブを中止して次のジョブの実行をExecutorに指示する。

ビッグデータの分散処理では、データの内容が事前に分からない。このため、従来の分散処理のワークフレームでは、一度全てを処理しなければ全貌が分からなかった。本実施例では、管理部２１が、ジョブごとに、ジョブが処理対象とするデータ全ての処理の終了を待つことなく実行中に得られる情報を用いて処理の中断を判断することで、効率的な処理を実現できる。

なお、本実施例では、管理部２１を管理サーバ１０に設けた場合を例に説明したが、これに限定されない。管理部２１は、各ノード１１のExecutorから実行結果を受け取り、管理サーバ１０のマスタ部２０に指示情報を送信できれば、何れの装置で動作してもよい。例えば、管理部２１は、何れのノード１１、または、管理サーバ１０およびノード１１とは異なるサーバに設けてもよい。この場合、各ノード１１のExecutorには、実行結果を送信するために管理部２１の実行場所を示す情報を通知する。例えば、マスタ部２０は、Sparkの起動前に静的な設定情報としてコマンドラインや設定ファイルを経由して各ノード１１のExecutorに管理部２１の動作場所を通知する。なお、管理部２１の動作場所が固定であり、各ノード１１のExecutorが管理部２１の動作場所に固定で実行結果を送信する場合、マスタ部２０は、各ノード１１のExecutorへ管理部２１の動作場所を通知しなくてもよい。

図６は、実施例に係る分散処理システムによる機械学習の概略的な流れを模式的に示した図である。図６の例では、図３と同様に、予測モデルの探索に制限時間が定まっている。図６の例は、組み合わせ１から組み合わせ６と順に予測モデルの探索の処理が実行されている。各ノード１１のExecutorは、処理を中止するべきか継続するべきかの判断基準となるタスクの処理結果が求まると、処理結果を示す処理結果情報を管理部２１に通知する。

管理部２１は、通知された処理結果情報から予測される組み合わせの試行結果が充分な予測精度に達しないと判断した場合、マスタ部２０に対してジョブの処理中止を指示する指示情報を送る。マスタ部２０は、処理中止を指示する指示情報を受け付けると、次の組み合わせによる試行を開始する。図６の例は、組み合わせ１、組み合わせ２、組み合わせ３と順に予測モデルの探索の処理を実行し、組み合わせ３の処理の途中で予測精度が低いことが推定されたために組み合わせ３の処理を中止している。そして、図６の例は、組み合わせ４、組み合わせ５、組み合わせ６と順に予測モデルの探索の処理を実行し、組み合わせ６の処理の完了後に制限時間を超えている。組み合わせ１の予測モデルは、予測精度が７０％である。組み合わせ２の予測モデルは、予測精度が８０％である。組み合わせ４の予測モデルは、予測精度が６０％である。組み合わせ５の予測モデルは、予測精度が８５％である。組み合わせ６の予測モデルは、予測精度が９０％である。図６の例では、予測精度が９０％である組み合わせ６の予測モデルが、最も高い予測精度を持つ予測モデルとして求まる。

このように、実施例に係る分散処理システム１は、処理を中止するべきか継続するべきかを判断するために制御がDriverに戻ることはないため、分散処理の処理効率を向上させることができる。これにより、分散処理システム１は、制限時間内に試行できる組み合わせの数を増やすことができる。なお、本実施例では、Sparkを例にジョブの中止の実現方法を説明したが、類似する他のシステムにも同様に適用できる。

次に、ジョブの処理を中止する方法の具体的な一例を説明する。機械学習の分散処理では、処理パラメータの組み合わせごとに、予測モデルの検証がジョブとして実行される。予測モデルの検証では、K-cross-validationにより検証が行われ、検証結果として予測モデルの予測精度が得られる。

K-cross-validationでは、処理対象のデータをＫ個に分割し、訓練用データと検証用データのパターンを作成する。例えば、K-cross-validationでは、分割されたＫ個の分割データの何れか１個を検証用データとし、残りのＫ−１個の分割データを訓練用データとしたパターンを、検証用データとする分割データを変えて複数パターン作成する。本実施例では、Ｋ個の分割データをそれぞれ検証用データとし、残りのＫ−１個の分割データを訓練用データとしたＫ個のパターンを作成する。

予測モデルの検証では、作成したＫ個のパターンの訓練用データと検証用データでそれぞれ予測モデルを作成して検証し、得られたＫ個の予測モデルの予測精度を統合することで組み合わせの検証とする。統合の方法としては平均値や最大値など複数の方法がある。

図７は、K-cross-validationによる予測モデルの検証の概略的な流れを模式的に示した図である。図７では、Ｋ＝４、すなわち、4-fold- cross-validationを例に説明する。図７に示す予測モデルの検証では、４個のパターン1-f、2-f、3-f、4-fについて、それぞれ予測モデルを作成（train）して検証（predict）を順に行う。例えば、パターン1-f、2-f、3-f、4-fと順番に処理する際に、図７に示すように、パターン1-fの処理で９６％と機械学習では充分に高い予測精度が得られたものとする。このように高い予測精度が得られた場合、予測モデルの予測精度が充分であると判断して、パターン2-f、3-f、4-fの処理をスキップすれば、処理時間は、１/４になる。

一方、例えば、パターン1-f、2-f、3-f、4-fと順番に処理していく際に、パターン1-fの処理で、例えば５０％と機械学習では低い予測精度が得られたものとする。予測モデルの検証では、このように充分に低い予測精度が得られた場合、残りの処理に時間をかけても予測精度の向上が見込めないため、パターン2-f、3-f、4-fの処理をスキップすれば、処理時間は、１/４になる。

図８は、予測モデルを検証するジョブの流れを模式的に示した図である。図８では、１つのジョブにおいて、２個のパターンａ、ｂの予測モデルの作成と検証を３つのノード１１により順に分散処理する場合を例に説明する。図８の（Ａ）は、従来の分散処理により、パターンａ、ｂの予測モデルの作成と検証が順に行われた場合を示している。図８の（Ａ）では、次のジョブが開始されるタイミングは、パターンａ、ｂの処理が完了した時刻ｔ１となる。

図８の（Ｂ）は、本実施例の分散処理により、パターンａ、ｂの予測モデルの作成と検証が順に行われた場合を示している。各ノード１１は、予測モデルを検証した結果の予測精度を処理結果として管理部２１に通知する。図８の（Ｂ）の例は、管理部２１が、各ノード１１から通知されたパターンａでの予測精度からジョブの残りの部分処理の実行を不要と判断してマスタ部２０に対してジョブの処理中止を指示した場合を示している。マスタ部２０を構成するDriverは、ジョブの処理中止が指示されると、ジョブを中止して次のジョブの実行をExecutorに指示する。図８の（Ｂ）の例は、一部のノード１１では、パターンｂの予測モデルの作成の処理を開始しているが、処理を中止して次のジョブを実行する。図８の（Ｂ）では、次のジョブが開始されるタイミングは、パターンａの処理が完了した時刻ｔ２となる。

図９は、機械学習の概略的な流れを模式的に示した図である。図９では、一つの処理パラメータの組み合わせで、１０個のパターンについて予測モデルの作成と検証を分散処理する場合を例に説明する。図９の（Ａ）は、従来の分散処理により、組み合わせ１、組み合わせ２でそれぞれ１０個のパターンの予測モデルの作成と検証が全て行われた場合を示している。組み合わせ１では、予測精度の最大が８０％である。組み合わせ２は、予測精度の最大が８５％である。図９の（Ａ）の例では、予測精度の最大が８５％である組み合わせ２の予測モデルが、最も高い予測精度を持つ予測モデルとして求まる。

図９の（Ｂ）は、本実施例の分散処理により、組み合わせ１〜組み合わせ４でそれぞれ予測モデルの作成と検証が全て行われた場合を示している。組み合わせ１では、１０個のうち４個目のパターンでジョブが中止されており、予測精度の最大が７５％である。組み合わせ２は、１０個のうち７個目のパターンでジョブが中止されており、予測精度の最大が８３％である。組み合わせ３は、１０個のうち２個目のパターンでジョブが中止されており、予測精度の最大が８９％である。組み合わせ４は、１０個のうち５個目のパターンでジョブが中止されており、予測精度の最大が９２％である。図９の（Ｂ）の例では、予測精度の最大が９２％である組み合わせ４の予測モデルが、最も高い予測精度を持つ予測モデルとして求まる。このように、本実施例に係る分散処理システム１は、分散処理の処理効率が向上し、多くの処理パラメータの組み合わせを探索できるため、機械学習の予測精度が向上する。

次に、本実施例に係る分散処理システム１の各装置が実行する処理の流れについて説明する。最初に、管理サーバ１０が機械学習の分散処理を実行する流れについて説明する。図１０は、分散処理の手順の一例を示すフローチャートである。この分散処理は、所定のタイミング、例えば、予め指定された期間毎のタイミングや、指定された時刻のタイミング、不図示の操作画面から処理開始の指示を受け付けたタイミングで実行される。

図１０に示すように、マスタ部２０は、予測モデルの変更可能な各種の処理パラメータについて探索する組み合わせの範囲の情報を取得する（Ｓ１０）。探索する組み合わせの範囲の情報は、管理者等のユーザから指定を受け付けることにより取得してもよい。また、探索する組み合わせの範囲の情報は、別なソフトウェアによって以前の学習の結果などから演算等によって導出されたものを取得してもよい。

マスタ部２０は、指定された各種の処理パラメータの範囲から、未選択の処理パラメータの組み合わせを選択する（Ｓ１１）。なお、マスタ部２０は、処理済みの処理パラメータの組み合わせでの処理結果を用いて予測を行って、より高い予測精度が得られると予測される組み合わせを優先的に選択してもよい。

マスタ部２０は、選択した処理パラメータの組み合わせの予測モデルを検証する検証処理を実行する（Ｓ１２）。検証処理の詳細は、後述する。

マスタ部２０は、分散処理の処理時間が制限時間以上となったか否かを判定する（Ｓ１３）。分散処理の処理時間が制限時間以上となっていない場合（Ｓ１３否定）、マスタ部２０は、各種の処理パラメータの指定された範囲の全ての組み合わせの選択が終了したか否かを判定する（Ｓ１４）。全ての組み合わせの選択が終了していない場合（Ｓ１４否定）、上述のＳ１１へ移行する。

一方、分散処理の処理時間が制限時間以上となった場合（Ｓ１３肯定）、マスタ部２０は、現時点まで学習処理された、処理パラメータの組み合わせの中から、最も予測精度の良い処理パラメータの組み合わせを学習結果として出力し（Ｓ１５）、処理を終了する。

また、全ての組み合わせの選択が終了した場合（Ｓ１４肯定）、上述のＳ１５へ移行する。

図１１は、検証処理の手順の一例を示すフローチャートである。この検証処理は、例えば、分散処理のＳ１２から実行される。

マスタ部２０は、処理対象のデータを分割する分割数Ｋを管理部２１へ通知する（Ｓ２０）。マスタ部２０は、処理対象のデータをＫ個に分割し、Ｋ個の訓練用データと検証用データのパターンの作成を各ノード１１のワーカ部３０へ指示する（Ｓ２１）。マスタ部２０は、各パターンによる予測モデルの検証を各ノード１１のワーカ部３０へ指示する（Ｓ２２）。

マスタ部２０は、管理部２１からジョブの処理中止が指示されたか否かを判定する（Ｓ２３）。ジョブの処理中止が指示された場合（Ｓ２３肯定）、マスタ部２０は、現在の処理中のジョブの処理中止を各ノード１１のワーカ部３０へ指示する（Ｓ２４）。マスタ部２０は、現時点まで処理済みのパターンでの予測精度の算出を各ノード１１のワーカ部３０へ指示し（Ｓ２５）、分散処理のＳ１３へ移行する。

一方、ジョブの処理中止が指示されていない場合（Ｓ２３否定）、各ノード１１のワーカ部３０から検証の処理結果を受信したか否かを判定する（Ｓ２６）。各ノード１１のワーカ部３０から処理結果を受信していない場合（Ｓ２６否定）、上述のＳ２３へ移行する。

一方、各ノード１１のワーカ部３０から処理結果が得られた場合（Ｓ２６肯定）、マスタ部２０は、Ｋ個のパターンでの予測精度の算出を各ノード１１のワーカ部３０へ指示し（Ｓ２７）、分散処理のＳ１３へ移行する。

次に、ノード１１が、選択された処理パラメータの組み合わせでの予測モデルの検証を実行する流れについて説明する。図１２は、予測モデル検証処理の手順の一例を示すフローチャートである。この予測モデル検証処理は、所定のタイミング、例えば、マスタ部２０から予測モデルの検証が指示されたタイミングで実行される。

ワーカ部３０は、Ｋ個の訓練用データと検証用データのパターンのうち、未選択のパターンを１つ選択する（Ｓ３０）。ワーカ部３０は、選択したパターンの訓練用データを用いて、選択された処理パラメータの組み合わせでの予測モデルの学習を実行する（Ｓ３１）。ワーカ部３０は、選択したパターンの検証用データを用いて、学習した予測モデルの予測精度を算出する（Ｓ３２）。ワーカ部３０は、算出された予測精度を管理部２１へ通知する（Ｓ３３）。

ワーカ部３０は、マスタ部２０から処理中止が指示されたか否かを判定する（Ｓ３４）。マスタ部２０から処理中止が指示された場合（Ｓ３４肯定）、処理を終了する。

一方、マスタ部２０から処理中止が指示されていない場合（Ｓ３４否定）、ワーカ部３０は、Ｋ個のパターンの選択が完了したか否かを判定する（Ｓ３５）。Ｋ個のパターンの選択が完了していない場合（Ｓ３５否定）、上述のＳ３０へ移行する。

一方、Ｋ個のパターンの選択が完了した場合（Ｓ３５肯定）、ワーカ部３０は、検証の処理結果をマスタ部２０へ送信し（Ｓ３６）、処理を終了する。例えば、ワーカ部３０は、各パターンの予測精度を検証の処理結果としてマスタ部２０へ送信する。

次に、管理サーバ１０が分散処理の実行の管理する流れについて説明する。図１３は、管理処理の手順の一例を示すフローチャートである。この管理処理は、所定のタイミング、例えば、分散処理が実行された予め指定された期間毎のタイミングや、処理対象のデータを分割する分割数Ｋが通知されたタイミングで実行される。

収集部４０は、ノード１１から、予測精度を受信したか否かを判定する（Ｓ４０）。予測精度を受信していない場合（Ｓ４０否定）、収集部４０は、分散処理が終了したか否かを判定する（Ｓ４１）。分散処理が終了していない場合（Ｓ４１否定）、Ｓ４０へ移行する。一方、分散処理が終了した場合（Ｓ４１肯定）、処理を終了する。

予測精度を受信した場合（Ｓ４０肯定）、推定部４１は、受信した予測精度に基づき、予測精度を受信したジョブの全体処理結果の予測精度を推定する（Ｓ４２）。

判断部４２は、推定された予測精度に応じて、ジョブの残りの処理を継続するか否かを判定する（Ｓ４３）。ジョブの残りの処理を継続する場合（Ｓ４３肯定）、上述のＳ４０へ移行する。

一方、ジョブの残りの処理を継続しない場合（Ｓ４３否定）、判断部４２は、マスタ部２０に対してジョブの処理中止を指示する指示情報を送り（Ｓ４４）、上述のＳ４０へ移行する。

以上のように、管理部２１は、処理対象ジョブを分散して部分処理する複数のノード１１それぞれから、部分処理の処理結果を収集する。管理部２１は、収集された部分処理の処理結果に基づき、部分処理に対応する全体処理の処理結果である全体処理結果を推定する。管理部２１は、推定された全体処理結果に応じて、全体処理に対応する他の部分処理の実行継続可否を判断する。これにより、管理部２１は、分散処理の処理効率を向上させることができる。

また、管理部２１は、複数のノード１１により保持された部分処理の処理結果、または、複数のノード１１でそれぞれ実行されるプロセスにより生成される、部分処理の処理結果を収集する。これにより、管理部２１は、処理対象ジョブの処理が完了していなくても、収集された処理結果から処理対象ジョブの全体処理結果を推定できる。

また、管理部２１は、要求される所定の性能条件を満たすことが推定される場合、または、性能条件を満たさないことが推定される場合、全体処理に対応する他の部分処理の実行を不要と判断する。これにより、管理部２１は、分散処理の最終的な結果に大きな影響を与えない処理を中止させることができ、分散処理の処理効率を向上させることができる。

また、管理部２１は、機械学習での予測モデルの処理パラメータの組み合わせごとにジョブを分けて複数のノード１１で分散して部分処理される当該部分処理の処理結果を複数のノード１１それぞれから収集する。管理部２１は、収集された部分処理の処理結果に基づき、部分処理に対応するジョブの予測モデルでの予測精度を推定する。管理部２１は、推定された予測精度が、第１の予測精度を満たす場合、または、第１の予測精度より低い第２の予測精度を満たさない場合、予測精度を推定したジョブの残りの部分処理の実行を不要と判断する。これにより、管理部２１は、機械学習において、最終的な予測精度に大きな影響を与えない処理を中止させることができ、機械学習の分散処理の処理効率を向上させることができる。

さて、これまで開示の装置に関する実施例について説明したが、開示の技術は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的状態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。例えば、管理部２１の収集部４０、推定部４１および判断部４２の各処理部が適宜統合されても良い。さらに、各処理部にて行なわれる各処理機能は、その全部又は任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

［分散処理実行管理プログラム］
また、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することもできる。そこで、以下では、上記の実施例と同様の機能を有するプログラムを実行するコンピュータシステムの一例を説明する。最初に、ドライバに対する注意喚起の制御を行う分散処理実行管理プログラムについて説明する。図１４は、分散処理実行管理プログラムを実行するコンピュータの構成の一例を示す説明図である。

図１４に示すように、コンピュータ４００は、ＣＰＵ（Central Processing Unit）４１０、ＨＤＤ（Hard Disk Drive）４２０、ＲＡＭ（Random Access Memory）４４０を有する。これら４００〜４４０の各部は、バス５００を介して接続される。

ＨＤＤ４２０には上記の収集部４０、推定部４１および判断部４２と同様の機能を発揮する分散処理実行管理プログラム４２０ａが予め記憶される。なお、分散処理実行管理プログラム４２０ａについては、適宜分離しても良い。

また、ＨＤＤ４２０は、各種情報を記憶する。例えば、ＨＤＤ４２０は、ＯＳや発注量の決定に用いる各種データを記憶する。

そして、ＣＰＵ４１０が、分散処理実行管理プログラム４２０ａをＨＤＤ４２０から読み出して実行することで、実施例の各処理部と同様の動作を実行する。すなわち、分散処理実行管理プログラム４２０ａは、収集部４０、推定部４１および判断部４２と同様の動作を実行する。

なお、上記した分散処理実行管理プログラム４２０ａについては、必ずしも最初からＨＤＤ４２０に記憶させることを要しない。

また、例えば、分散処理実行管理プログラム４２０ａは、コンピュータ４００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に記憶させても良い。そして、コンピュータ４００がこれらからプログラムを読み出して実行するようにしても良い。

さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ４００に接続される「他のコンピュータ（又はサーバ）」などにプログラムを記憶させておく。そして、コンピュータ４００がこれらからプログラムを読み出して実行するようにしても良い。

１ 分散処理システム
１０ 管理サーバ
１１ ノード
２０ マスタ部
２１ 管理部
３０ ワーカ部
４０ 収集部
４１ 推定部
４２ 判断部

Claims (6)

1. コンピュータに、
   処理対象ジョブを分散して部分処理する複数のノードそれぞれから、前記部分処理の処理結果を収集し、
   収集された前記部分処理の処理結果に基づき、前記部分処理に対応する全体処理の処理結果である全体処理結果を推定し、
   推定された全体処理結果に応じて、前記全体処理に対応する他の部分処理の実行継続可否を判断する、
   処理を実行させることを特徴とする分散処理実行管理プログラム。
2. 前記収集する処理は、前記複数のノードにより保持された前記部分処理の処理結果、または、前記複数のノードでそれぞれ実行されるプロセスにより生成される、前記部分処理の処理結果を収集する
   ことを特徴とする請求項１に記載の分散処理実行管理プログラム。
3. 前記判断する処理は、要求される所定の性能条件を満たすことが推定される場合、または、前記性能条件を満たさないことが推定される場合、前記全体処理に対応する他の部分処理の実行を不要と判断する
   ことを特徴とする請求項１または２に記載の分散処理実行管理プログラム。
4. 前記収集する処理は、機械学習での予測モデルの処理パラメータの組み合わせごとにジョブを分けて前記複数のノードで分散して部分処理される当該部分処理の処理結果を前記複数のノードそれぞれから収集し、
   前記推定する処理は、収集された前記部分処理の処理結果に基づき、前記部分処理に対応するジョブの予測モデルでの予測精度を推定し、
   前記判断する処理は、推定された予測精度が、第１の予測精度を満たす場合、または、前記第１の予測精度より低い第２の予測精度を満たさない場合、予測精度を推定したジョブの残りの部分処理の実行を不要と判断する
   ことを特徴とする請求項１〜３の何れか１つに記載の分散処理実行管理プログラム。
5. コンピュータが、
   処理対象ジョブを分散して部分処理する複数のノードそれぞれから、前記部分処理の処理結果を収集し、
   収集された前記部分処理の処理結果に基づき、前記部分処理に対応する全体処理の処理結果である全体処理結果を推定し、
   推定された全体処理結果に応じて、前記全体処理に対応する他の部分処理の実行継続可否を判断する、
   処理を実行することを特徴とする分散処理実行管理方法。
6. 処理対象ジョブを分散して部分処理する複数のノードそれぞれから、前記部分処理の処理結果を収集する収集部と、
   前記収集部により収集された前記部分処理の処理結果に基づき、前記部分処理に対応する全体処理の処理結果である全体処理結果を推定する推定部と、
   前記推定部により推定された全体処理結果に応じて、前記全体処理に対応する他の部分処理の実行継続可否を判断する判断部と、
   を有することを特徴とする分散処理実行管理装置。

Images