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

Abstract

【課題】処理時間の長期化を抑制することを課題とする。
【解決手段】スレーブノードは、複数のノードに分散処理される処理対象データの部位ごとのデータ分布であるデータ分布情報を取得する。そして、スレーブノードは、処理対象データが分割された分割データに対する分散処理の処理状況を監視する。その後、監視するスレーブノードは、分散処理の処理状況とデータ分布情報とに基づいて、処理対象とする分割データの処理順序を変更する。
【選択図】図１１

Description

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

クラウドコンピューティングの普及に伴い、クラウド上に保存される大量のデータを複数のサーバで分散して処理を実行する分散処理システムが利用されている。例えば、分散処理システムとしては、HDFS（Hadoop Distributed File System）とMapReduce処理とを基盤技術とするHadoop（登録商標）が知られている。

HDFSは、複数のサーバにデータを分散格納するファイルシステムである。MapReduceは、HDFS上のデータをタスクと呼ばれる単位で分散処理する仕組みであり、Map処理、Shuffleソート処理、Reduce処理を実行する。

MapReduceによる分散処理においては、複数のスレーブノードにMap処理やReduce処理のタスクが割り当てられて、各スレーブノードで分散して処理が実行される。例えば、マスタノードのジョブトラッカーが、複数のスレーブノードに対してMap処理のタスクを割り当てて、各スレーブノードのタスクトラッカーが、割り当てられたMapタスクを実行する。

また、各スレーブノードで実行されるPatitionerは、Mapタスクの中で、キーのハッシュ値を計算し、その計算で得られた値によって振分先のReduceタスクを決定する。このようにスレーブノードに対するReduceタスクの割り当ては、ハッシュ関数等を用いることにより均等に行われ、最も処理の遅いスレーブノードの処理完了時間がジョブ全体の完了時間となる。

近年では、各スレーブノードに割り当てるReduceタスクを調整する技術として、例えば、入力データのサンプリング等によりキーの出現数を調査し、処理量の異なるReduceタスクを事前に割り当てる技術が知られている。

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

しかしながら、上記技術では、各ノードの最終的に割り当てられるデータ量を均等としたとしても、ある瞬間においては処理が偏ることがあり、結果として処理全体の長期化に繋がる。

例えば、MapReduce処理においては、キーに応じて各スレーブノードにReduceタスクを割当てるが、入力データの部位によりキーの出願分布が異なる場合がある。この場合、全体としては各スレーブノードに同じデータ量が割与えられたとしても、ある瞬間では特定のスレーブノードにデータ量が偏るので、特定のスレーブノードの処理負荷が高くなり、処理速度が低下する。また、各スレーブノードを仮想マシンで実現する場合、他の仮想マシンがプロセッサ資源やネットワークを使用することで、Reduce処理を実行する仮想マシンの処理速度が低下する場合がある。これらの結果として、各スレーブノードに同じデータ量が割与えられたにも関わらす、特定のスレーブノードの処理完了時間が遅くなり、ジョブ全体の完了時間も遅くなる。

１つの側面では、処理時間の長期化を抑制することができる分散処理プログラム、分散処理方法および分散処理装置を提供することを目的とする。

第１の案では、分散処理プログラムは、コンピュータに、複数のノードに分散処理される処理対象データの部位ごとのデータ分布であるデータ分布情報を取得する処理を実行させる。分散処理プログラムは、コンピュータに、前記処理対象データが分割された分割データに対する前記分散処理の処理状況を監視する処理を実行させる。分散処理プログラムは、コンピュータに、前記分散処理の処理状況と前記データ分布情報とに基づいて、処理対象とする前記分割データの処理順序を変更する処理を実行させる。

一実施形態によれば、処理時間の長期化を抑制することができる。

図１は、実施例１に係る分散処理システムの全体構成例を示す図である。 図２は、Hadoopの仕組みを説明する図である。 図３は、Map処理を説明する図である。 図４は、Shuffle処理を説明する図である。 図５は、Reduce処理を説明する図である。 図６は、マスタノードの機能構成を示す機能ブロック図である。 図７は、ジョブリストＤＢに記憶される情報の例を示す図である。 図８は、タスクリストＤＢに記憶される情報の例を示す図である。 図９は、推定結果ＤＢに記憶される情報の例を示す図である。 図１０は、推定処理を説明する図である。 図１１は、スレーブノードの機能構成を示す機能ブロック図である。 図１２は、割当確定テーブルに記憶される情報の例を示す図である。 図１３は、割当変更の例を説明する図である。 図１４は、分散処理システムが実行する処理の流れを示すフローチャートである。 図１５は、処理の長期化を説明する図である。 図１６は、閾値の変形例を説明する図である。 図１７は、装置のハードウェア構成例を示す図である。

以下に、本願の開示する分散処理プログラム、分散処理方法および分散処理装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。

［全体構成］
図１は、実施例１に係る分散処理システムの全体構成例を示す図である。図１に示すように、この分散処理システムは、マスタノード３０、複数のスレーブノード５０がネットワーク１を介して互いに通信可能に接続される。この分散処理システムでは、Hadoop（登録商標）などの分散処理フレームワークを使用した分散処理アプリケーションが各サーバで実行されており、データ基盤としてＨＤＦＳなどを使用する。

マスタノード３０は、分散処理システムを統括的に管理するサーバであり、MapReduce処理におけるジョブトラッカーとして機能する。例えば、マスタノード３０は、メタ情報などを用いて、どのデータがいずれのスレーブノード５０に格納されているのかを特定する。また、マスタノード３０は、各スレーブノード５０に割当てるタスクやジョブなどを管理し、Map処理やReduce処理などのタスクをスレーブノード５０に割当てる。

各スレーブノード５０は、Map処理およびReduce処理を実行するサーバであり、MapReduce処理におけるデータノードやタスクトラッカー、ジョブクライアント、Mapper、Reducerとして機能する。また、各スレーブノード５０は、マスタノード３０によって割り当てられたMapタスクを実行し、Mapタスクの中でキーのハッシュ値を計算し、その計算で得られた値によって振分先のReduceタスクを決定する。その後、各スレーブノード５０は、マスタノード３０に割り当てられたReduceタスクを実行する。

ここで、各スレーブノード５０が実行するMapタスク、Reduceタスクについて説明する。図２は、Hadoopの仕組みを説明する図である。

図２に示すように、MapReduce処理は、MapタスクとReduceタスクから構成されMapタスクは、Map処理から構成され、ReduceタスクはShuffle処理とReduce処理とから構成される。マスタノード３０は、MapタスクキューとReduceタスクキューを有し、スレーブノード５０に対して、MapタスクやReduceタスクの割り当てを行う。

各スレーブノード５０は、少なくとも１つのMapスロットと少なくとも１つのReduceスロットを有する。各スレーブノード５０は、１つのMapスロット内でMapアプリとPartitonerを実行する。Mapアプリは、ユーザが所望する処理を実行するアプリケーションであり、Partitonerは、Mapアプリの実行結果によって振分先のReduceタスクを決定する。

さらに、各スレーブノード５０は、１つのReduceスロット内でSort処理とReduceアプリとを実行する。Sort処理は、割り当てられたReduceタスクに使用するデータを各スレーブノード５０から取得してソートし、ソートした結果をReduceアプリに入力する。Reduceアプリは、ユーザが所望する処理を実行するアプリケーションである。このようにして各スレーブノード５０が実行した結果を収集して出力結果が得られる。

ここで、Map処理、Shffule処理、Reduce処理の一例を説明する。なお、ここで示す処理や入力データはあくまで一例であり、処理を限定するものではない。

（Map処理）
図３は、Map処理を説明する図である。図３に示すように、各スレーブノード５０は、入力データとして「Hello Apple！」と「Apple is red」を受信し、それぞれの入力データに対してMap処理を実行して、「キー、Value」のペアを出力する。

図３の例では、スレーブノード５０は、「Hello Apple！」に対してMap処理を実行して、入力データの各要素の数を計数し、要素を「キー」、計数結果を「Value」とする「キー、Value」のペアを出力する。具体的には、スレーブノード５０は、入力データ「Hello Apple！」から「Hello、1」、「Apple、1」、「！、1」を生成する。同様に、スレーブノード５０は、入力データ「Apple is red」から「Apple、1」、「is、1」、「red、1」を生成する。

（Shuffle処理）
図４は、Shuffle処理を説明する図である。図４に示すように、各スレーブノード５０は、各スレーブノードからMap処理結果を取得してShuffle処理を実行する。

図４の例では、スレーブノード（Ａ）、（Ｂ）、（Ｃ）・・・が同じジョブ（例えば、JobID＝20）に属するMapタスクを実行し、スレーブノード（Ｄ）と（Ｚ）とが、JobID＝20に属するReduceタスクを実行する。

例えば、スレーブノード（Ａ）がMap処理１を実行して「Apple、1」、「is、3」を生成し、スレーブノード（Ｂ）がMap処理２を実行して「Apple、2」、「Hello、4」を生成し、スレーブノード（Ｃ）がMap処理３を実行して「Hello、3」、「red、5」を生成する。スレーブノード（Ｘ）がMap処理１０００を実行して「Hello、1000」、「is、1002」を生成する。

続いて、スレーブノード（Ｄ）およびスレーブノード（Ｚ）は、割当てられたReduceタスクで使用する各スレーブノードのMap処理結果を取得して、ソートおよびマージを実行する。具体的には、スレーブノード（Ｄ）には、「Apple」と「Hello」についてのReduceタスクが割当てられて、スレーブノード（Ｚ）には、「is」と「red」についてのReduceタスクが割当てられたとする。

この場合、スレーブノード（Ｄ）は、スレーブノード（Ａ）からMap処理１の結果「Apple、1」を取得し、スレーブノード（Ｂ）からMap処理２の結果「Apple、2」および「Hello、4」を取得する。また、スレーブノード（Ｄ）は、スレーブノード（Ｃ）からMap処理３の結果「Hello、3」を取得し、スレーブノード（Ｘ）からMap処理１０００の結果「Hello、1000」を取得する。そして、スレーブノード（Ｄ）は、これらの結果をソートおよびマージして、「Apple、［1,2］」および「Hello、［3,4,1000］」を生成する。

同様に、スレーブノード（Ｚ）は、スレーブノード（Ａ）からMap処理１の結果「is、3」を取得し、スレーブノード（Ｃ）からMap処理３の結果「red、5」を取得し、スレーブノード（Ｘ）からMap処理１０００の結果「is、1002」を取得する。そして、スレーブノード（Ｚ）は、これらの結果をソートおよびマージして、「is、［3,1002］」および「red、［5］」を生成する。

（Reduce処理）
次に、スレーブノード５０が実行するReduce処理について説明する。図５は、Reduce処理を説明する図である。図５に示すように、各スレーブノード５０は、各スレーブノードのMap処理結果から生成したShuffle結果を用いて、Reduce処理を実行する。具体的には、Shuffle処理の説明と同様、スレーブノード（Ｄ）には、「Apple」と「Hello」についてのReduceタスクが割当てられ、スレーブノード（Ｚ）には、「is」と「red」についてのReduceタスクが割当てられたとする。

この例では、スレーブノード（Ｄ）は、Shuffle処理の結果である「Apple、［1,2］」および「Hello、［3,4,1000］」から値を合算し、Reduce処理結果として「Apple、3」および「Hello、1007」を生成する。同様に、スレーブノード（Ｚ）は、Shuffle処理の結果である「is、［3,1002］」および「red、［5］」から値を合算し、Reduce処理結果として「is、1005」および「red、5」を生成する。

このような分散処理システムにおいて、各スレーブノード５０は、MapReduce処理の各Reduce処理に割り当てられるキーについて、各スレーブノード５０に分散処理される処理対象データの部位ごとの出現数を示すデータ分布状況を取得する。そして、各スレーブノード５０は、各Reduce処理に転送されるMap処理の処理結果が格納される、各Reduce処理の各バッファのデータ量を監視する。その後、各スレーブノード５０は、バッファの記憶量が少ないReduceに割り当てられるキーの出現数が多い部位の分割データを優先的にMap処理に配信するように、マスタノード３０に要求する。

つまり、各スレーブノード５０は、入力データの部位毎のキー分布状況に基づいて、負荷が小さいReduceが担当するキーを多く含む部位を優先的にMap処理することができる。この結果、空いているReduce処理をなくして、Reduce処理を均等化し、処理時間の長期化を抑制することができる。

［マスタノードの機能構成］
図６は、マスタノードの機能構成を示す機能ブロック図である。図６に示すように、マスタノード３０は、通信制御部３１、記憶部３２、制御部４０を有する。

通信制御部３１は、各スレーブノード５０との通信を制御する処理部であり、例えばネットワークインタフェースカードなどである。この通信制御部３１は、各スレーブノード５０に対して、MapタスクやReduceタスクの割当状況を送信する。また、通信制御部３１は、各スレーブノード５０から、MapタスクやReduceタスクの処理結果を受信する。また、通信制御部３１は、各スレーブノード５０から、Mapタスクへ入力するデータの割当変更要求などを受信する。

記憶部３２は、制御部４０が実行するプログラムや各種データを記憶する記憶部であり、例えばハードディスクやメモリなどである。この記憶部３２は、ジョブリストＤＢ３３、タスクリストＤＢ３４、推定結果ＤＢ３５を記憶する。また、記憶部３２は、MapReduce処理で使用される一般的な各種情報を記憶する。また、記憶部３２は、MapReduce処理対象の入力データを記憶する。

ジョブリストＤＢ３３は、分散処理対象のジョブ情報を記憶するデータベースである。図７は、ジョブリストＤＢに記憶される情報の例を示す図である。図７に示すように、ジョブリストＤＢ３３は、「JobID、総Mapタスク数、総Reduceタスク数」を対応付けて記憶する。

ここで記憶される「JobID」は、ジョブを識別する識別子である。「総Mapタスク数」は、ジョブに含まれるMap処理タスクの総数である。「総Reduceタスク数」は、ジョブに含まれるReduce処理タスクの総数である。なお、「JobID、総Mapタスク数、総Reduceタスク数」は、管理者等によって設定更新される。

図７の例では、「JobID」が「Job001」のジョブは、６つのMap処理タスクと４つのReduce処理タスクで構成されることを示す。同様に、「JobID」が「Job002」のジョブは、４つのMap処理タスクと２つのReduce処理タスクで構成されることを示す。

タスクリストＤＢ３４は、Map処理タスクやReduce処理タスクに関する情報を記憶するデータベースである。図８は、タスクリストＤＢに記憶される情報の例を示す図である。図８に示すように、タスクリストＤＢ３４は、「JobID、TaskID、種別、状態、割り当てスレーブID、必要スロット数」などを記憶する。

ここで記憶される「JobID」は、ジョブを識別する識別子である。「TaskID」は、タスクを識別する識別子である。「種別」は、Map処理やReduce処理を示す情報である。「状態」は、該当タスクが処理完了（Done）状態、実行中（Running）、割り当て前（Not assigned）のいずれであるかを示す。「割り当てスレーブID」は、タスクが割当てられたスレーブノードを識別する識別子であり、例えばホスト名などである。「必要スロット数」は、タスクを実行するのに使用するスロット数である。

図８の場合、「JobID」が「Job001」であるジョブで、１スロットを用いるMap処理タスク「Map000」が「Node１」のスレーブノード５０に割当てられる。そして、この「Node１」のスレーブノード５０は、Map処理を実行し、実行が完了していることを示す。また、「JobID」が「Job001」であるジョブで、１スロットを用いて実行されるReduce処理タスク「R2」が、Partionerによる割り当て前であることを示す。

なお、JobID、TaskID、種別については、ジョブリストＤＢ３３に記憶される情報にしたがって生成される。データのあるスレーブIDは、メタ情報等により特定することができる。状態は、タスクの割り当て状況やスレーブノード５０からの処理結果等によって更新される。割当スレーブIDは、タスクの割当時点で更新される。必要スロット数は、１タスクについて１スロットなどのように予め指定することができる。なお、これらの情報以外にも、処理の実行状況に基づいて、例えばデータが格納されるスレーブノードの情報や各タスクの処理データ量などを記憶させることもできる。

推定結果ＤＢ３５は、MapReduce処理の各Reduce処理に割り当てられるキーについて、分散処理される処理対象の部位ごとの出現数を示すデータ分布状況の推定結果を記憶するデータベースである。つまり、推定結果ＤＢ３５は、入力データの各部位におけるキーの出現数の推定結果を記憶する。

図９は、推定結果ＤＢに記憶される情報の例を示す図である。図９に示すように、推定結果ＤＢ３５は、Reducerごとに、入力データの各領域におけるキーの出現数を示すヒストグラムを記憶する。すなわち、推定結果ＤＢ３５は、各Reducerについて、領域ごとに発生するデータ転送量を記憶する。なお、Reducerは、Reduceタスクを実行するアプリケーションの一例であり、ここでは一例として、各スレーブノードが１つのReducerであり、ReducerとReduceタスクとが対応付けられている例で説明する。また、これに限定されず、１つのReducerが複数のReduceタスクを実行することもできる。

一例を挙げると、推定結果ＤＢ３５は、キー「ＡＡＡ」が割与えられたReducer「ID＝R1」について、入力データの領域１における出現数、領域２における出現数、領域３における出現数、領域４における出現数を記憶する。なお、ここでは、ヒストグラムで記憶する例を説明したが、これに限定されるものではなく、例えばテーブル形式で記憶することもできる。

制御部４０は、マスタノード３０全体の処理を司る処理部であり、推定部４１、Map割当部４２、Reduce割当部４３、割当変更部４４を有する。制御部４０は、例えばプロセッサなどの電子回路であり、推定部４１、Map割当部４２、Reduce割当部４３、割当変更部４４は、電子回路の一例や制御部４０が実行するプロセスの一例である。

推定部４１は、MapReduce処理の各Reduce処理に割り当てられるキーについて、分散処理される処理対象の部位ごとの出現数を示すデータ分布状況を推定する処理部である。具体的には、推定部４１は、入力データの各部位におけるキーの出現数を計数する。そして、推定部４１は、各キーの出現数を用いて、各Reducer対して領域ごとに発生するデータ転送量を推定する。その後、推定部４１は、推定結果を推定結果ＤＢ３５に格納するとともに、各スレーブノード５０に配信する。

図１０は、推定処理を説明する図である。図１０に示すように、推定部４１は、入力データを４つの領域に分けて、各領域について、キー「ＡＡＡ」、キー「ＢＢＢ」、キー「ＣＣＣ」・・・などの各キーの出現数を計数する。そして、推定部４１は、キー「ＡＡＡ」が割与えられたReducer「ID＝R1」について、入力データの領域１における出現数、領域２における出現数、領域３における出現数、領域４における出現数を対応付ける。同様に、推定部４１は、キー「ＢＢＢ」が割与えられたReducer「R2」、キー「ＣＣＣ」が割与えられたReducer「R3」、キー「ＤＤＤ」が割与えられたReducer「R4」について、入力データの各領域における出現数を対応付ける。このようにして、推定部４１は、各Mapperから各Reducerに対して、入力データのどの領域ではどのくらいのデータ転送が発生するかを推定する。

Map割当部４２は、各ジョブにおけるMap処理のタスクであるMapタスクをスレーブノード５０のMapスロットに割当てる処理部である。そして、Map割当部４２は、図８に示した「割り当てスレーブID」や「状態」等を更新する。

一例を挙げると、Map割当部４２は、スレーブノード５０等からMapタスクの割当要求を受信した場合に、タスクリストＤＢ３４を参照して「状態」が「Not assigned」のMapタスクを特定する。続いて、Map割当部４２は、任意の方法でMapタスクを選び、割当対象のMapタスクとする。その後、Map割当部４２は、割当要求を送信したスレーブノード５０のIDを、割当対象のMapタスクの「割当スレーブID」に格納する。

その後、Map割当部４２は、特定した割当先のスレーブノード５０に、TaskIDや必要スロット数等を通知して、Mapタスクを割当てる。また、Map割当部４２は、割当てたMapタスクの「状態」を「Not assigned」から「Running」に更新する。

Reduce割当部４３は、Reduceタスクをスレーブノード５０のReduceスロットに割り当てる処理部である。具体的には、Reduce割当部４３は、予め指定されるReduceタスクの割当ルール等にしたがって、各ReduceタスクをReduceスロットに割り当てる。割り当てに伴って、Reduce割当部４３は、タスクリストＤＢ３４を随時更新する。つまり、Reduce割当部４３は、Reduceタスク（ReduceID）とスレーブノード５０（Reducer）との対応付けを実行し、ハッシュ値ではなく主キーによる割り当てを実行する。

一例を挙げると、Reduce割当部４３は、Reduceタスクを特定するReduceIDが小さい順にReduceタスクをReduceスロットに割り当てる。このとき、例えば、Reduce割当部４３は、任意のReduceスロットに割り当ててもよく、Map処理が終わっているReduceスロットを優先して割当ててもよい。なお、Reduce割当部４３は、Mapタスクが全体の所定値（例えば８０％）以上終了すると、各スレーブノード５０にReduceタスクの処理開始を指示する。

割当変更部４４は、各スレーブノードに対して、入力データの割当や割当の変更を実行する処理部である。つまり、割当変更部４４は、各Mapperに対する入力データの割当を実行する。例えば、割当変更部４４は、タスクリストＤＢ３４を参照して、Mapタスクが割り当てられているスレーブノード５０を特定する。そして、割当変更部４４は、特定した各スレーブノード５０に、処理対象の入力データまたは処理対象の入力データの格納先を配信する。

このとき、割当変更部４４は、任意の手法で割り当てを変更することができる。例えば、割当変更部４４は、Mapper#1であるNode１には、入力データの領域１、領域２、領域３、領域４の順に割当て、Mapper#2であるNode２には、入力データの領域３、領域４、領域２、領域１の順に割当てることができる。また、割当変更部４４は、割当てた各領域のデータを所定数ずつ処理させるように指示することもでき、割当てた領域のデータについてのMap処理が終了した後に次の領域のデータを処理するように指示することもできる。

さらに、割当変更部４４は、Mapperであるスレーブノード５０からの要求にしたがって、割当を変更する処理を実行する。例えば、割当変更部４４は、Mapper#1であるNode1から、データ転送量が少ないReducerであるReducer#3（ReduceID＝R3）を含む割当変更要求を受信した場合、推定結果ＤＢ３５におけるReducer#3（ReduceID＝R3）の推定結果を参照する。そして、割当変更部４４は、Reducer#3（ReduceID＝R3）については入力データの領域２にキーが多く含まれていることを特定する。

この結果、割当変更部４４は、要求元のMapper#1に対して、領域２のデータを優先的に割り当てるように、割当を変更する。例えば、割当変更部４４は、一定時間は領域２のデータのみを割当てることもできる。また、割当変更部４４は、各領域の割当比率について領域２の割当比率を他の領域よりも高くすることで、Mapper#1に対して領域２のデータを他よりも多く割当てることもできる。

［スレーブノードの構成］
図１１は、スレーブノードの機能構成を示す機能ブロック図である。図１１に示すように、スレーブノード５０は、通信制御部５１と、記憶部５２と、制御部６０とを有する。

通信制御部５１は、マスタノード３０や他のスレーブノード５０などとの通信を実行する処理部であり、例えばネットワークインタフェースカードなどである。例えば、通信制御部５１は、マスタノード３０から各種タスクの割当などを受信し、各種タスクの完了通知を送信する。また、通信制御部５１は、各種タスク処理の実行に伴って、該当する入力データが分割された分割データを受信する。

記憶部５２は、制御部６０が実行するプログラムや各種データを記憶する記憶部であり、例えばハードディスクやメモリなどである。この記憶部５２は、推定結果ＤＢ５３、割当ＤＢ５４を記憶する。また、記憶部５２は、各種処理の実行時にデータを一時的に記憶する。さらに、記憶部５２は、Map処理の入力およびReduce処理の出力を記憶する。

推定結果ＤＢ５３は、MapReduce処理の各Reduce処理に割り当てられるキーについて、分散処理される処理対象の部位ごとの出現数を示すデータ分布状況の推定結果を記憶するデータベースである。具体的には、推定結果ＤＢ５３は、マスタノード３０から配信された推定結果を記憶する。

割当ＤＢ５４は、Reduceタスクとキーの対応付けを記憶するデータベースである。具体的には、割当ＤＢ５４は、通常の各Reduceタスクと処理対象のキーの対応付け、および、スペアReduceタスクと処理対象のキーの対応付けを記憶する。図１２は、割当確定テーブルに記憶される情報の例を示す図である。図１２に示すように、割当ＤＢ５４は、「ReduceID、処理するキー」を対応付けて記憶する。

ここで記憶される「ReduceID」は、主キーを処理するReducerを特定する情報であり、Reduceタスクを実行するスレーブノードに割与えられる。「処理するキー」は、Reducerが処理対象とするキーであり、Reduceタスクで処理対象となるキーである。図１２の場合、ReduceID＝R1のReducerの処理対象のキーが「ＡＡＡ」であることを示す。

制御部６０は、スレーブノード５０全体の処理を司る処理部であり、取得部６１、Map処理部６２、Reduce処理部７０を有する。制御部６０は、例えばプロセッサなどの電子回路であり、取得部６１、Map処理部６２、Reduce処理部７０は、電子回路の一例や制御部６０が実行するプロセスの一例である。

取得部６１は、マスタノード３０から各種情報を取得する処理部である。例えば、取得部６１は、MapReduce処理の開始タイミングや予め設定されたタイミングで、マスタノード３０からプッシュ式で送信された推定結果や割り当て情報を受信し、それぞれ推定結果ＤＢ５３と割当ＤＢ５４に格納する。

Map処理部６２は、Mapタスク実行部６３とバッファ群６４と監視部６５を有し、これらによって、マスタノード３０から割り当てられたMapタスクを実行する。

Mapタスク実行部６３は、ユーザが指定した処理に対応するMapアプリケーションを実行する処理部である。つまり、Mapタスク実行部６３は、一般的なMap処理におけるMapタスクを実行する。

例えば、Mapタスク実行部６３は、ハートビートなどを用いて、マスタノード３０にMapタスクの割当を要求する。このとき、Mapタスク実行部６３は、スレーブノード５０の空きスロット数も通知する。そして、Mapタスク実行部６３は、マスタノード３０から、「TaskID、必要スロット数」などを含むMap割当情報を受信する。

その後、Mapタスク実行部６３は、受信したMap割当情報にしたがって、マスタノード３０から処理対象のデータを受信して、必要なスロットを用いて該当するMapタスクを実行する。また、Mapタスク実行部６３は、バッファ群６４が有する複数のバッファ６４ａのうち、該当するバッファにMap処理結果を格納する。例えば、Mapタスク実行部６３は、キー「ＡＡＡ」が含まれる入力データに対してMapタスクを実行した場合、キー「ＡＡＡ」と対応付けられるReducer向けのデータを記憶するバッファに、Mapタスクの処理結果を格納する。

バッファ群６４は、キーが割当てられたReducerごとのバッファ６４ａを有し、Reducerに対して出力されるMap処理結果を保持する。各バッファ６４ａは、ReduceID＝R1、R2、R3、R4ごとに設けられ、Mapタスク実行部６３によってデータが格納される。また、各バッファ６４ａに格納されるデータは、各Reducerによって読み出される。

監視部６５は、バッファ群６４の各バッファ６４ａに記憶されるバッファ量を監視する処理部である。具体的には、監視部６５は、各バッファ６４ａのバッファ量を定期的に監視し、バッファ量の偏りを監視する。つまり、監視部６５は、閾値を超える極端にデータ量が多いバッファや閾値を下回る極端にデータ量が少ないバッファを検出する。

例えば、監視部６５は、ReduceID＝R1が対応付けられたバッファ、ReduceID＝R2が対応付けられたバッファ、ReduceID＝R3が対応付けられたバッファ、ReduceID＝R4が対応付けられたバッファの各バッファ量を監視する。そして、閾値以上のデータ量が格納されるバッファを検出すると、その時点で最もバッファ量が少ないバッファを特定し、特定したバッファに対応付けられるReduceIDを特定する。その後、監視部６５は、特定したReduceIDを含む割当変更要求をマスタノード３０に送信する。

また、別の例としては、監視部６５は、各バッファ量を監視し、閾値未満のバッファ量が格納されるバッファを検出すると、検出したバッファに対応付けられるReduceIDを特定する。その後、監視部６５は、特定したReduceIDを含む割当変更要求をマスタノード３０に送信する。

このように、監視部６５は、処理量が少ないReducer、すなわち処理を実行していないReducerを検出すると、当該Reducerが処理対象とするデータを優先的に割り当てるように、割当変更要求をマスタノード３０に送信する。

ここで、割当変更の例を説明する。図１３は、割当変更の例を説明する図である。図１３に示すように、監視部６５は、RedeuceIDがR1のReducerのバッファに記憶されるデータ量とIDがR3のReducerのバッファに記憶されるデータ量とが、閾値未満であることを検出する。すると、監視部６５は、よりデータ量が少ないReducerのID＝R3を含む割当変更要求をマスタノード３０に送信する。

別例としては、監視部６５は、データ量が少ないReducerのID＝R3を検出すると、推定結果ＤＢ５３におけるID＝R3の推定結果を参照する。そして、監視部６５は、ID＝R3の推定結果において、ID＝R3のReducerが処理するデータが領域２に最も多く含まれていることを特定する。すると、監視部６５は、マスタノード３０に対して、領域２のデータの割当を多くする要求を送信することもできる。

Reduce処理部７０は、Shuffle処理部７１とReduceタスク実行部７２を有し、これらによってReduceタスクを実行する処理部である。このReduce処理部７０は、マスタノード３０から割り当てられたReduceタスクを実行する。

Shuffle処理部７１は、Map処理の結果をキーでソートし、同じキーを有するレコード（データ）をマージして、Reduceタスクの処理対象を生成する処理部である。具体的には、Shuffle処理部７１は、マスタノード３０からReduce処理の開始が通知されると、当該Map処理が属するジョブのReduceタスクを実行する準備として、各スレーブノード５０のバッファ群６４から該当するMap処理結果を取得する。そして、Shuffle処理部７１は、Map処理の結果を予め指定されたキーでソートし、同じキーを有する処理結果をマージして記憶部５２に格納する。

例えば、Shuffle処理部７１は、「JobID」が「Job001」のMapタスクである「Map000、Map001、Map002、Map003」が終了したこと、つまり、「JobID」が「Job001」のReduce処理タスクの実行開始をマスタノード３０から受信する。すると、Shuffle処理部７１は、Node1、Node2、Node3、Node4等からMap処理結果を取得する。続いて、Shuffle処理部７１は、Map処理結果のソートおよびマージを実行して記憶部５２等に格納する。

Reduceタスク実行部７２は、ユーザが指定した処理に対応するReduceアプリケーションを実行する処理部である。具体的には、Reduceタスク実行部７２は、マスタノード３０から割当てられたReduceタスクを実行する。

例えば、Reduceタスク実行部７２は、「JobID、TaskID、必要スロット数」などから構成されるReduceタスクの情報を受信する。そして、Reduceタスク実行部７２は、受信した情報を記憶部５２等に格納する。その後、Reduceタスク実行部７２は、各スレーブノード５０から該当データを取得してReduceアプリケーションを実行し、その結果を記憶部５２に格納する。なお、Reduceタスク実行部７２は、Reduceタスクの結果をマスタノード３０に送信してもよい。

［処理の流れ］
図１４は、分散処理システムが実行する処理の流れを示すフローチャートである。図１４に示すように、マスタノード３０の推定部４１は、管理者等から処理開始が指示されると（Ｓ１０１：Ｙｅｓ）、入力データを読み込む（Ｓ１０２）。そして、推定部４１は、入力データをサンプリングし（Ｓ１０３）、各Reducerへのデータ転送量を推定する（Ｓ１０４）。このとき、推定部４１は、推定結果を推定結果ＤＢ３５に格納し、各スレーブノード５０に配信する。その後、Map割当部４２が各スレーブノード５０にMapタスクを割当て、Reduce割当部４３が各スレーブノード５０にReduceタスクを割当て、Map割当部４２が各スレーブノード５０にMap処理の開始を指示する（Ｓ１０５）。なお、Reduceタスクの割当は、このタイミングに限定されず、例えば所定数以上のMapタスクが完了した時点で割り当てることもできる。

続いて、各スレーブノード５０のMapタスク実行部６３は、Map処理を開始する（Ｓ１０６）。なお、Mapタスク実行部６３は、Mapタスクを実行すると、実行結果をマスタノード３０に送信する。

そして、マスタノード３０のReduce割当部４３は、Mapタスクが所定数以上終了すると（Ｓ１０７：Ｙｅｓ）、各スレーブノード５０にReduce処理の開始を指示する（Ｓ１０８）。

続いて、各スレーブノード５０のReduce処理部７０は、Shuffle処理及びReduce処理を開始する（Ｓ１０９）。なお、Reduce処理部７０は、Reduceタスクを実行すると、実行結果をマスタノード３０に送信することもできる。

すると、各スレーブノード５０の監視部６５は、Reducerに割当てられる各バッファ６４ａの監視を開始する（Ｓ１１０）。そして、監視部６５は、いずれかのバッファ６４ａにおいて閾値以上のバッファ量を検出した場合（Ｓ１１１：Ｙｅｓ）、割当変更要求をマスタノード３０に送信する（Ｓ１１２）。例えば、監視部６５は、現在処理中のチャンクを保持したまま、閾値以上のバッファ量になったノード以外で処理を行っているReducer用のデータを多く持っている部分を、Reducer名を引数にしてマスタノード３０に依頼する。

そして、マスタノード３０の割当変更部４４は、要求元のスレーブノード５０に対して、入力データの配信を変更する（Ｓ１１３）。例えば、割当変更部４４は、推定結果ＤＢ３５に記憶されるヒストグラムを参照し、通知されたReducerへのデータ数が多い領域から処理されるように、適切なデータを割り当てる。その後、スレーブノード５０のMapタスク実行部６３は、新たに割当てられて配信される入力データに対してMap処理を再開する（Ｓ１１４）。

その後、Map処理が終了するまで（Ｓ１１５：Ｎｏ）、Ｓ１１１以降が繰り返され、Reduce処理が終了すると（Ｓ１１５：Ｙｅｓ）、Reduce処理が完了するまで、Reduce処理が実行される（Ｓ１１６）。そして、Reduce処理が完了すると（Ｓ１１６：Ｙｅｓ）、MapReduce処理が終了する。なお、Ｓ１１１において、いずれのバッファ６４ａにおいても閾値以上のバッファ量が検出されない場合（Ｓ１１１：Ｎｏ）、Ｓ１１５以降が実行される。

［効果］
このように、実施例１に係る分散処理システムは、入力データ待ちが発生するReducerを検出し、そのReducerのキーを多く含む部位を優先的にMap処理させることができる。したがって、Reducerが待機する時間を削減し、処理を均等化することができるので、処理の長期化を抑制できる。

図１５は、処理の長期化を説明する図である。図１５に示すように、入力データの場所によってキーの分布が異なる。例えば、ある小説家が書いた複数の小説から登場単語の数を計数するMapReduce処理を実行する場合、当該小説家の初期の作品と晩年の作品とでは、語彙力の違いなどにより、使用される単語も異なってくる。

このため、単純に、入力データ全体のキー出現数等によって、Reducerへのキー割り振りを均等化したとしても、MapperからReducerへの転送データ量に偏りが生じすることがある。例えば、図１５において網掛けの部分が、処理データがない時を示している。さらには、外乱などにより、Reducerの処理遅延も発生する。例えば、各スレーブノードを仮想マシンで実現した場合、他の仮想マシンがプロセッサ資源やネットワークを使ってしまう事でReduceが時間当たりに処理できる量が減ってしまう事がある。また、Java（登録商標）のガベージコレクションのような突発的な高負荷の影響により、Reducerの負荷が高くなることもある。

この結果、図１５に示すように、均等に負荷分散させたはずのReducerにおいて、処理すべきデータが入力されず、待機しているReducerが発生する。その一方で、外乱やキーの出現数等により、処理負荷が高くてデータを取得できないReducerも発生する。このように、瞬間を見ると、データ量が不均一であり、結果として、処理の長期化が発生する。

これに対して、実施例１に係る分散処理システムでは、Mapperであるスレーブノード５０が、Reducerのバッファ量を監視し、バッファ量が少ないReducer、すなわち処理すべきデータが少ないReducerを検出することができる。そして、スレーブノード５０は、処理すべきデータが少ないReducerが処理対象とするキーを多く有する入力データの優先的な配信を、マスタノード３０に要求することができる。この結果、瞬間瞬間で、Reducerの処理を負荷分散することができるので、処理データ量を均一化し、処理の長期化を抑制することができる。

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

［閾値の設定］
上記実施例では、バッファ量の閾値として１つの閾値を設定する例を説明したが、これに限定されるものではなく、複数の閾値を設定することもできる。図１６は、閾値の変形例を説明する図である。図１６に示すように、スレーブノード５０の監視部６５は、各バッファ６４ａのバッファ量の閾値として上限値と下限値とを設定する。

そして、監視部６５は、上限値を超えるバッファ量が検出された場合、その時点で最もバッファ量が少ないReducerへの割当を増やす割当変更要求をマスタノード３０に送信する。また、監視部６５は、上限値を超えるバッファ量が検出されない場合でも、下限値を下回るバッファ量が検出された場合、当該バッファ量のバッファに対応するReducerへの割当を増やす割当変更要求をマスタノード３０に送信する。つまり、スレーブノード５０は、特定のReducerにおける処理状況が遅延した場合だけでなく、積極的に、MapReduceの処理時間を短くするために、処理量の少ないReducerへの割当を増やすこともできる。

［中央管理］
上記実施例では、各スレーブノード５０がバッファ量を監視する例を説明したが、これに限定されるものではなく、マスタノード３０が各スレーブノード５０の各バッファ量を監視することもできる。例えば、マスタノード３０は、定期的に、各スレーブノード５０から各バッファ量を取得する。そして、マスタノード３０は、各スレーブノード５０に対して、上限値や下限値などの閾値を超えるバッファ量が検出された場合、上記処理と同様に、割当変更を実行する。このように、マスタノード３０が集中管理することにより、各スレーブノード５０のバッファ監視による処理負荷を低減することができる。

［分散処理］
上記実施例では、分散処理としてMapReduce処理を例にして説明したが、これに限定されるものではなく、例えば前処理と前処理の結果を用いて後処理を実行する様々な分散処理に適用することができる。

［入力データ］
上記実施例では、マスタノード３０が入力データを保持し、各スレーブノード５０に配信する例を説明したが、これに限定されるものではない。例えば、各スレーブノード５０が入力データを分散して保持することもできる。例えば、マスタノード３０は、Map処理対象のデータを保持するスレーブノードを識別する識別子としてホスト名などを設定した「データのあるスレーブID」を、タスクリストのJobIDにさらに対応付けて記憶する。

そして、マスタノード３０は、Mapperである各スレーブノード５０に対して、処理対象のデータを保持するスレーブノードのID（スレーブID）を通知する。このようにして、スレーブノード５０は、該当スレーブノードからデータを取得して、Map処理を実行する。また、マスタノード３０は、割当変更要求を受信した場合、処理量を増やすために、該当キーを多く含む部位の入力データを保持するスレーブノードのスレーブIDを通知することで、該当Reducerの処理量を増やすことができる。

［システム］
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともできる。あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

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

［ハードウェア］
次に、各サーバのハードウェア構成例を説明するが、各装置は同様の構成を有するので、ここでは一例を説明する。図１７は、装置のハードウェア構成例を示す図である。図１７に示すように、装置１００は、通信インタフェース１０１、メモリ１０２、複数のＨＤＤ（ハードディスクドライブ）１０３、プロセッサ装置１０４を有する。

通信インタフェース１０１は、各機能部の説明時に示した通信制御部に該当し、例えばネットワークインタフェースカードなどである。複数のＨＤＤ１０３は、各機能部の説明時に示した処理部を動作させるプログラムやＤＢ等を記憶する。

プロセッサ装置１０４が有する複数のＣＰＵ（Central Processing Unit）１０５は、各機能部の説明時に示した各処理部と同様の処理を実行するプログラムをＨＤＤ１０３等から読み出してメモリ１０２に展開することで、図６や図１１等で説明した各機能を実行するプロセスを動作させる。すなわち、このプロセスは、マスタノード３０が有する推定部４１、Map割当部４２、Reduce割当部４３、割当変更部４４と同様の機能を実行する。また、このプロセスは、スレーブノード５０が有する取得部６１、Map処理部６２、Reduce処理部７０と同様の機能を実行する。

このように装置１００は、プログラムを読み出して実行することで、分散処理制御方法またはタスク実行方法を実行する情報処理装置として動作する。また、装置１００は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、装置１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。

３０ マスタノード
３１ 通信制御部
３２ 記憶部
３３ ジョブリストＤＢ
３４ タスクリストＤＢ
３５ 推定結果ＤＢ
４０ 制御部
４１ 推定部
４２ Map割当部
４３ Reduce割当部
４４ 割当変更部
５０ スレーブノード
５１ 通信制御部
５２ 記憶部
５３ 推定結果ＤＢ
５４ 割当ＤＢ
６０ 制御部
６１ 取得部
６２ Map処理部
６３ Mapタスク実行部
６４ バッファ群
６４ａ バッファ
６５ 監視部
７０ Reduce処理部
７１ Shuffle処理部
７２ Reduceタスク実行部

Claims (7)

1. コンピュータに、
   複数のノードに分散処理される処理対象データの部位ごとのデータ分布であるデータ分布情報を取得する処理と、
   前記処理対象データが分割された分割データに対する前記分散処理の処理状況を監視する処理と、
   前記分散処理の処理状況と前記データ分布情報とに基づいて、処理対象とする前記分割データの処理順序を変更する処理と
   を実行させることを特徴とする分散処理プログラム。
2. 前記取得する処理は、第１の処理と前記第１の処理の処理結果を用いて実行される第２の処理を有する前記分散処理において、各第２の処理に割り当てられるキーについて前記処理対象の部位ごとの出現数を示す前記データ分布状況を取得し、
   前記変更する処理は、処理量の少ないキーの出現数が多い前記部位の前記分割データが優先的に割当てられるように、前記分割データを割当てるノードに要求することを特徴とする請求項１に記載の分散処理プログラム。
3. 前記監視する処理は、前記第１の処理の処理結果が格納される、前記各第２の処理の各バッファのデータ量を監視し、
   前記変更する処理は、該バッファ量が閾値を下回る前記第２の処理に割り当てられる前記キーの出現数が多い前記部位の前記分割データが優先的に割り当てられるように、前記ノードに要求することを特徴とする請求項２に記載の分散処理プログラム。
4. 前記変更する処理は、前記各第２の処理の各バッファのデータ量の偏りが検出された場合、前記バッファ量が最も少ない前記第２の処理に割り当てられる前記キーの出現数が多い前記部位の前記分割データが優先的に割当てられるように、前記ノードに要求することを特徴とする請求項２に記載の分散処理プログラム。
5. 前記取得する処理は、前記分散処理であるMapReduce処理における各Reduce処理に割り当てられるキーについて、前記処理対象の部位ごとの出現数を示す前記データ分布状況を取得し、
   前記監視する処理は、前記各Reduce処理に転送されるMap処理の処理結果が格納される、前記各Reduce処理の各バッファのデータ量を監視し、
   前記変更する処理は、バッファのデータ量が少ないReduceに割り当てられるキーの出現数が多い前記部位の前記分割データが前記Map処理に割当てられるように、前記分割データを配信するノードに要求することを特徴とする請求項１に記載の分散処理プログラム。
6. コンピュータが、
   複数のノードに分散処理される処理対象データの部位ごとのデータ分布であるデータ分布情報を取得する処理と、
   前記処理対象データが分割された分割データに対する前記分散処理の処理状況を監視する処理と、
   前記分散処理の処理状況と前記データ分布情報とに基づいて、処理対象とする前記分割データの処理順序を変更する処理と
   を含むことを特徴とする分散処理方法。
7. 複数のノードに分散処理される処理対象データの部位ごとのデータ分布であるデータ分布情報を取得する取得部と、
   前記処理対象データが分割された分割データに対する前記分散処理の処理状況を監視する監視部と、
   前記分散処理の処理状況と前記データ分布情報とに基づいて、処理対象とする前記分割データの処理順序を変更する変更部と
   を有することを特徴とする分散処理装置。

Images