JP2016004328A - タスク割当プログラム、タスク割当方法およびタスク割当装置 - Google Patents

Abstract

【課題】ジョブ全体の完了時間を短縮することを課題とする。【解決手段】タスク割当装置は、入力データを分割して得られた第１の分割データ群に含まれる各分割データを、Map処理を行う複数のノードに分配する処理を実行させる。タスク割当装置は、第１の分割データ群のうちの一部の分割データ群についてのMap処理が完了すると、第１の分割データ群の全てのMap処理の完了後に実行されるReduce処理を行う複数のノードへの分配データの生成ルールを、一部の分割データ群についてのMap処理結果について適用して、分配データの各データ量を推定する。タスク割当装置は、推定した各データ量に基づいて、少なくとも一部の分配データについての割り当て先ノードの選択制御を第１の分割データ群の全てのMap処理の完了前に開始する。【選択図】図２

Description

本発明は、タスク割当プログラム、タスク割当方法およびタスク割当装置に関する。

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

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

MapReduceによる分散処理においては、マスタサーバが、ハッシュ関数等を用いて、複数のスレーブサーバに対してMap処理やReduce処理のタスクを割り当てるとともに、分割したデータを各スレーブサーバに送信する。そして、各スレーブサーバが、割り当てられたタスクを実行する。

スレーブサーバに対するタスクの割り当ては、ハッシュ関数等を用いることにより、均等に行われる。その一方で、各Reduceタスクに対応する処理量は、Reduceタスクに対応するキー等に関連づけられたReduce対象のデータ量等により均等になるとは限らない。

例えば、ハッシュ関数の種類等によっては、１つのスレーブサーバに複数の振分キーが集中する。また、各スレーブサーバに振分キーが均等に振り分けられたとしても、Reduceタスクごとに処理量が異なる。これらのことから、各スレーブサーバでの処理完了時間が異なるので、複数タスクからなるジョブ全体の完了が最も処理が遅いスレーブサーバの処理完了に左右されることとなる。このため、全Reduceタスクをスレーブサーバに割り当てた後、各Reduceタスクに対応する処理量が均等となるように、データ量を調整する技術が知られている。

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

しかしながら、各Reduceタスクの処理量が不均一となることは、入力データやMap処理の結果など様々な影響により異なるので、上記技術のような調整処理を行うことが、ジョブ全体の完了時間を早くするものとは限らない。

例えば、Reduceタスクの処理量を調整するには、全Map処理の完了を待ってから調整することになるので、各スレーブサーバでのReduce処理の実行開始が遅れることになり、却ってジョブ全体の処理時間が長くなる場合もある。

１つの側面では、ジョブ全体の完了時間を短縮することができるタスク割当プログラム、タスク割当方法およびタスク割当装置を提供することを目的とする。

第１の案では、タスク割当プログラムは、コンピュータに、入力データを分割して得られた第１の分割データ群に含まれる各分割データを、Map処理を行う複数のノードに分配する処理を実行させる。タスク割当プログラムは、コンピュータに、前記第１の分割データ群のうちの一部の分割データ群についてのMap処理が完了すると、前記第１の分割データ群の全てのMap処理の完了後に実行されるReduce処理を行う複数のノードへの分配データの生成ルールを、前記一部の分割データ群についてのMap処理結果について適用して、分配データの各データ量を推定する処理を実行させる。タスク割当プログラムは、コンピュータに、推定した前記各データ量に基づいて、少なくとも一部の分配データについての割り当て先ノードの選択制御を前記第１の分割データ群の全てのMap処理の完了前に開始する処理を実行させる。

１実施形態によれば、ジョブ全体の完了時間を短縮することができる。

図１は、実施例１に係る分散処理システムの全体構成例を示す図である。 図２は、実施例２に係るマスタサーバの機能構成を示す機能ブロック図である。 図３は、ジョブリストＤＢに記憶される情報の例を示す図である。 図４は、タスクリストＤＢに記憶される情報の例を示す図である。 図５は、クラスタプロファイルＤＢに記憶される情報の例を示す図である。 図６は、Map処理の完了通知の例を示す図である。 図７は、実施例２に係るスレーブサーバの機能構成を示す機能ブロック図である。 図８は、Map処理を説明する図である。 図９は、Shuffle処理を説明する図である。 図１０は、Reduce処理を説明する図である。 図１１は、Reduce処理の割当変更を説明する図である。 図１２は、実施例２に係るマスタサーバが実行する処理の流れを示すフローチャートである。 図１３は、実施例２に係るスレーブサーバが実行する処理の流れを示すフローチャートである。 図１４は、タスクの進行イメージと閾値との関係を説明する図である。 図１５は、サーバのハードウェア構成例を示す図である。

以下に、本願の開示するタスク割当プログラム、タスク割当方法およびタスク割当装置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。なお、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。

［全体構成］
図１は、実施例１に係る分散処理システムの全体構成例を示す図である。図１に示すように、この分散処理システムは、入出力ＤＢ（DataBase）サーバ２、マスタサーバ１０、複数のスレーブサーバ３０がネットワーク１を介して互いに通信可能に接続される。

この分散処理システムでは、Hadoop（登録商標）などの分散処理フレームワークを使用した分散処理アプリケーションが各計算機で実行されており、データ基盤としてＨＤＦＳなどを使用する。

入出力ＤＢサーバ２は、分散処理対象のデータのメタ情報等を記憶するデータベースサーバである。例えば、入出力ＤＢサーバ２が記憶するメタ情報は、どのデータがどのスレーブサーバ３０に格納されているかを特定するのに使用される。

マスタサーバ１０は、分散処理システムを統括的に管理するサーバである。例えば、マスタサーバ１０は、入出力ＤＢサーバ２が記憶するメタ情報から、どのデータがいずれのスレーブサーバ３０に格納されているのかを特定する。また、マスタサーバ１０は、各スレーブサーバ３０に割当てるタスクやジョブなどを管理し、Map処理やReduce処理などのタスクをスレーブサーバ３０に割当てる。なお、マスタサーバ１０は、タスク割当装置の一例である。

各スレーブサーバ３０は、分散処理アプリケーションを実装し、Map処理やReduce処理を実行して、ＨＤＦＳで管理されるデータを分散処理するサーバである。例えば、スレーブサーバ３０は、複数のプロセッサ、複数のディスクを有する。また、各スレーブサーバ３０は、一意に識別される識別子が割り与えられる。なお、スレーブサーバ３０は、ノードの一例である。

このスレーブサーバ３０は、入出力ＤＢサーバ２から取得したデータに対して、マスタサーバ１０から割当てられたMap処理のタスクを実行する。また、スレーブサーバ３０は、各スレーブサーバのMap処理結果を用いて、Shuffle＆Sort処理を実行し、マスタサーバ１０から割り当てられたReduce処理のタスクを実行する。

ここで、各処理について説明する。Map処理は、ユーザが定義したMap関数を実行する処理である。例えば、Map処理は、入力データから中間結果として「Key、Value」のペアを出力する。Shuffle＆Sort処理は、Map処理の結果を「Key」でソートし、同じ「Key」を有する「Key、Value」のペアをマージする。Reduce処理は、ユーザが定義したReduce関数を実行する処理である。例えば、Reduce処理は、Shuffle＆Sort処理の結果から、同じ「Key」の「Value」に対して重ね合わせ処理を実行して、新しい形式の「Key、Value」のペアを生成する。

このような状態において、マスタサーバ１０は、入力データを分割して得られた第１の分割データ群に含まれる各分割データを、Map処理を行う複数のスレーブサーバ３０に分配する。そして、マスタサーバ１０は、第１の分割データ群のうちの一部の分割データ群についてのMap処理が完了すると、第１の分割データ群の全てのMap処理の完了後に実行されるReduce処理を行う複数のノードへの分配データの生成ルールを、一部の分割データ群についてのMap処理結果について適用して、分配データの各データ量を推定する。その後、マスタサーバ１０は、推定した各データ量に基づいて、少なくとも一部の分配データについての割り当て先ノードの選択制御を第１の分割データ群の全てのMap処理の完了前に開始する。

例えば、マスタサーバ１０は、MapReduceによる分散処理の実行を開始すると、予め指定された振分キーに関するハッシュ関数等を用いて、各スレーブサーバ３０に対してMap処理のタスクを割当てる。続いて、マスタサーバ１０は、予め指定された振分キーに関するハッシュ関数等を用いて、各スレーブサーバ３０に対してReduce処理のタスクを割当てる。

このとき、マスタサーバ１０は、Reduce処理のタスクの割当てを抑制する。そして、マスタサーバ１０は、所定数のMap処理が完了すると、この所定数のMap処理結果を用いてReduceタスクの処理量を見積もる。そして、マスタサーバ１０は、処理量が多いRedecu処理のタスクを高スペックのスレーブサーバ３０に割当てるように、Reduce処理のタスクの割当てを開始する。

この結果、マスタサーバ１０は、処理量が多いReduce処理を高スペックのスレーブサーバ３０に割当てることができ、各Reduce処理の処理時間を均等化することができる。したがって、マスタサーバ１０は、Reduce処理の処理完了が極端に遅くなることを抑制でき、ジョブ全体の完了時間を短縮することができる。

実施例１では、Reduce処理タスクの割当を抑制してから、Map処理によりReduce処理量を予測し、予測結果にしたがってReduce処理の割当を実行する例を説明したが、これに限定されるものではない。

一般的に、MapReduceによる分散処理では、データが入力されて処理が開始されると、ハッシュ関数によって、Map処理の割当およびReduce処理の割当が自動的に実行されることがある。このような場合でも、実施例２に係るマスタサーバ１０は、Reduce処理の再割当を実行することができる。そこで、実施例２では、Reduce処理の再割当について説明する。なお、全体構成は、図１と同様とする。

［マスタサーバの構成］
図２は、実施例２に係るマスタサーバの機能構成を示す機能ブロック図である。図２に示すように、マスタサーバ１０は、通信制御部１１と、記憶部１２と、制御部１３とを有する。

通信制御部１１は、スレーブサーバ３０などの他装置と通信を実行する処理部であり、例えばネットワークインタフェースカードなどである。例えば、通信制御部１１は、各スレーブサーバ３０に、Map処理タスクやReduce処理タスクを送信する。また、通信制御部１１は、Map処理結果等を各スレーブサーバ３０から受信する。

記憶部１２は、ジョブリストＤＢ１２ａ、タスクリストＤＢ１２ｂ、クラスタプロファイルＤＢ１２ｃを有する記憶装置であり、例えばメモリやハードディスクなどである。また、記憶部１２は、制御部１３が実行するプログラムなどを記憶する。

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

ここで記憶される「JobID」は、ジョブを識別する識別子である。「総Mapタスク数」は、ジョブに含まれるMap処理タスクの総数である。「総Reduceタスク数」は、ジョブに含まれるReduce処理タスクの総数である。「Reduce割当許可」は、Reduce処理タスクが割当可能な状態か否かを示し、可能な場合は「true」が設定され、可能ではない場合は「false」が設定され、ジョブの新規追加時も「false」が設定される。なお、「JobID、総Mapタスク数、総Reduceタスク数」は、管理者等によって設定更新される。

図３の例では、「JobID」が「Job001」のジョブは、４つのMap処理タスクと２つのReduce処理タスクで構成され、現在はまだ割当することができない状態であることを示す。同様に、「JobID」が「Job002」のジョブは、４つのMap処理タスクと２つのReduce処理タスクで構成され、現在はまだ割当することができない状態であることを示す。

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

ここで記憶される「JobID」は、ジョブを識別する識別子である。「TaskID」は、タスクを識別する識別子である。「種別」は、Map処理やReduce処理を示す情報である。「データのあるスレーブID」は、Map処理対象のデータを保持するスレーブサーバ３０を識別する識別子であり、例えばホスト名などである。「状態」は、該当タスクが処理完了（Done）状態、実行中（Running）、割り当て前（Not assigned）のいずれであるかを示す。「Reduceの項番」は、該当Reduceの実行順を示す。

「割当スレーブID」は、ハッシュ関数を用いて、タスクが割当てられたスレーブサーバ３０を識別する識別子であり、例えばホスト名などである。「必要スロット数」は、タスクを実行するのに使用するスロット数である。「処理データ量（単位はＧＢ）」は、該当Reduce処理タスクのデータ量である。「再割当スレーブID」は、ハッシュ関数を用いた割り当て後にReduce処理タスクの割り当てが変更されたスレーブサーバ３０を識別する識別子である。

図４の場合、「JobID」が「Job001」であるジョブで、１スロットを用いるMap処理タスク「Map000」が「Node１」のスレーブサーバ３０に割当てられる。そして、この「Node１」のスレーブサーバ３０は、「Node１」のスレーブサーバ３０と「Node２」のスレーブサーバ３０とからデータを取得して、Map処理を実行し、実行が完了していることを示す。また、このMap処理タスク「Map000」の処理データ量が300ＧＢであることを示す。

また、「JobID」が「Job001」であるジョブで、１スロットを用いてReduce処理の２番目に実行されるReduce処理タスク「Reduce002」が、ハッシュ関数によって「Node4」のスレーブサーバ３０に割当てられる。しかし、その後、Reduce処理タスク「Reduce002」は、「Node10」のスレーブサーバ３０に再割当てされていることを示す。

なお、JobID、TaskID、種別、Reduce項番については、ジョブリストＤＢ１２ａに記憶される情報にしたがって生成される。データのあるスレーブIDは、入出力ＤＢサーバ２が記憶するメタ情報等により特定することができる。状態は、タスクの割り当て状況やスレーブサーバ３０からの処理結果等によって更新される。割当スレーブIDは、タスクを割当時点で更新される。必要スロット数は、１タスクについて１スロットなどのように予め指定することができる。Reduce処理の処理データ量は、Map処理の終了結果から予測することができる。

クラスタプロファイルＤＢ１２ｃは、各スレーブサーバのスペックを記憶するデータベースである。図５は、クラスタプロファイルＤＢ１２ｃに記憶される情報の例を示す図である。図５に示すように、クラスタプロファイルＤＢ１２ｃは、「スレーブID、CPU、メモリ、HDD、割当状態」を記憶する。なお、「スレーブID、COU、メモリ、HDD」は、管理者等によって設定される値であり、「割当状態」は、制御部１３によって更新される情報である。

ここで記憶される「スレーブID」は、スレーブサーバ３０を一意に識別する識別子である。「CPU」は、スレーブサーバ３０が有するプロセッサの数を示し、「メモリ」は、スレーブサーバ３０が有するメモリ容量を示し、「HDD」は、スレーブサーバ３０が有するハードディスク容量を示す。「割当状態」は、Reduce処理タスクが割り当て済みか否かを示す情報であり、割り当て前はNot assignedが設定され、割当済みはassignedが設定される。

図５の場合、「Node9」のスレーブサーバ３０は、プロセッサが２コアでメモリ容量が２ＧＢでＨＤＤ容量が１００ＧＢであり、Reduce処理タスクが割当て済みであることを示す。また、「Node10」のスレーブサーバ３０は、プロセッサが８コアでメモリ容量が１６ＧＢでＨＤＤ容量が１ＴＢであり、Reduce処理タスクが割当て前であることを示す。

制御部１３は、マスタサーバ１０全体の処理を司る処理部であり。Map割当部１４、Reduce割当部１５、予測部１６、再割当部１７を有する。制御部１３は、例えばプロセッサなどの電子回路であり、Map割当部１４、Reduce割当部１５、予測部１６、再割当部１７は、電子回路の一例や制御部１３が実行するプロセスの一例である。

Map割当部１４は、予め指定された振分キーに関するハッシュ関数等を用いて、各ジョブにおけるMap処理のタスクであるMap処理タスクを１つ以上のスレーブサーバ３０に割当てる処理部である。そして、Map割当部１４は、図４に示した「割当スレーブID」や「状態」等を更新する。

一例を挙げると、Map割当部１４は、スレーブサーバ３０等からMap処理タスクの割当要求を受信した場合に、タスクリストＤＢ１２ｂを参照して「状態」が「Not assigned」のMap処理タスクを特定する。続いて、Map割当部１４は、割当要求を送信したスレーブサーバ３０のＩＤが「データのあるスレーブＩＤ」に含まれるMap処理タスクがあればそのMap処理タスクを優先して選ぶ。Map割当部１４は、そのようなMap処理タスクがなければ任意の方法でMap処理タスクを選び、割当対象のMap処理タスクとする。その後、Map割当部１４は、割当要求を送信したスレーブサーバ３０のIDを、割当対象のMap処理タスクの「割当スレーブID」に格納する。

その後、Map割当部１４は、特定した割当先のスレーブサーバ３０に、TaskID、データのあるスレーブID、必要スロット数等を通知して、Map処理タスクを割当てる。また、Map割当部１４は、割当てたMap処理タスクの「状態」を「Not assigned」から「Running」に更新する。

Reduce割当部１５は、予め指定された振分キーに関するハッシュ関数等を用いて、各ジョブにおけるReduce処理のタスクであるReduce処理タスクを１つ以上のスレーブサーバ３０に割り当てる。

例えば、Reduce割当部１５は、スレーブサーバ３０等からReduce処理タスクの割当要求を受信した場合に、タスクリストＤＢ１２ｂを参照して「状態」が「Not assigned」のReduce処理タスクを特定する。続いて、Reduce割当部１５は、ハッシュ関数等を用いて割当先のスレーブサーバを特定する。その後、Reduce割当部１５は、特定した割当先のスレーブサーバ３０のIDを、割当対象のReduce処理タスクの「割当スレーブID」に格納する。さらに、Reduce割当部１５は、クラスタプロファイルＤＢ１２ｃにおいて割当先のスレーブサーバ３０に対応する割当状態を「Not assigned」から「assigned」に更新する。

その後、Reduce割当部１５は、特定した割当先のスレーブサーバ３０に、TaskID、必要スロット数、処理データ量、フラグ等を通知して、Reduce処理タスクを割当てる。また、Reduce割当部１５は、割当てたReduce処理タスクの「状態」を「Not assigned」から「Running」に更新する。なお、Reduce割当部１５は、Reduce処理タスクの完了通知を受信した場合、該当Reduce処理タスクの「状態」を「Running」から「Done」に更新する。

予測部１６は、一部のMap処理タスクの処理結果から処理データ量が多いReduce処理を予測する処理部である。具体的には、予測部１６は、全Map処理タスクのうち所定数のMap処理タスクが完了すると、処理が完了したMap処理タスクの処理データ量やMap処理の処理データ量から得られるReduce処理のデータ量から、処理データ量が多いReduce処理を予測する。

例えば、予測部１６は、スレーブサーバ３０から通知されるMap処理の完了通知から、Map処理のデータ量を取得する。そして、予測部１６は、Map処理の処理データ量が所定量を超えるMap処理を特定した後、ジョブリストＤＢ１２ａやタスクリストＤＢ１２ｂ等を参照して、特定したMap処理を用いるReduce処理を特定する。その後、予測部１６は、特定したReduce処理を、処理量が閾値を超えるReduce処理として再割当部１７に通知する。

図４の例では、予測部１６は、処理データ量が閾値（１０００）以上のMap処理タスクとして「Map001」と「Map002」とを特定する。その後、予測部１６は、Map処理タスク「Map001」および「Map002」と同じJobID「Job001」を有するReduce処理タスク「Reduce001」と「Reduce002」とを特定する。そして、予測部１６は、Reduce処理タスク「Reduce001」と「Reduce002」とを、処理量が閾値を超えるReduce処理として再割当部１７に通知する。

また、別例としては、予測部１６は、Map処理の処理結果からReduce処理のデータ量を推定することもできる。図６は、Map処理の完了通知の例を示す図である。図６に示す完了通知は、各スレーブサーバ３０がマスタサーバ１０に送信する完了通知である。図６に示すように、完了通知は、「通知種別、JobID、完了Map TaskID、Mapタスクを実行したスレーブID」から構成されるMap完了内容と、「通知種別、JobID、完了Map TaskID、Reduce TaskID、データ量」から構成されるMap完了内容とを含む。

ここで記憶される「通知種別」は、Map処理の完了通知かReduce情報かを示す情報であり、Map処理の完了通知の場合には「Map完了」が設定され、Reduce情報の場合には「Reduceデータ量」が設定される。「JobID」には、Map処理が属するジョブの識別子が設定される。「完了Map TaskID」は、完了したMap処理タスクを特定する識別子が設定される。「Mapタスクを実行したスレーブID」は、当該Map処理タスクを実行し、完了通知を送信したスレーブサーバの識別子が設定される。「Reduce TaskID」は、当該Map処理の実行結果からデータ量が判明したReduce処理タスクを特定する識別子が設定される。「データ量（単位はＧＢ）」は、当該Map処理の実行結果から判明したReduce処理タスクデータ量設定される。

図６の例は、「JobID」が「Job013」のジョブにおける「Map135」のMap処理タスクの完了結果を示している。このMap処理タスク「Map135」は、スレーブサーバ「Node１」で実行されたタスクである。また、このMap処理タスク「Map135」によって、「JobID」が「Job013」のジョブにおけるReduce処理が「Reduce131」、「Reduce132」、「Reduce133」の３つあることが判明したことを示す。さらに、このMap処理タスク「Map135」によって、Reduce処理タスク「Reduce131」のデータ量が「1000」、Reduce処理タスク「Reduce132」のデータ量が「1200」、Reduce処理タスク「Reduce133」のデータ量が「8000」であることが判明したことを示す。

予測部１６は、このようにしてMap処理タスクの完了通知からReduce処理タスクのデータ量を取得して加算していく。そして、予測部１６は、加算した結果が「10000」を超える場合に、処理データ量が多いReduce処理が発生すると予測する。

ここで、予測部１６がReduce処理の合計を見積もる契機を様々に設定することができる。つまり、どの程度のMap処理タスクが完了した時点で、処理データ量が閾値を超えるか否かを判定するのかを任意に設定することができる。

例えば、予測部１６は、全Map処理タスクのうち予め指定した割合のMap処理が完了した時点で判定することができる。また、予測部１６は、最初のMap処理タスクが終了してから予め指定した時間が過ぎた時点で判定することができる。また、予測部１６は、上記２つの時点のいずれか早い時点で判定することもできる。

なお、最初のMap処理タスクについても、ランダムに指定することもできる。このように、Map処理タスクのタスク数等に基づいて予測タイミングを任意に変更することができるので、入力データによってカスタマイズすることができる。

再割当部１７は、予測部１６によって処理量が閾値以上と予測されたReduce処理に対して、スレーブサーバ３０の再割当を実行する処理部である。具体的には、再割当部１７は、処理量が多いReduce処理タスクに対して、ハッシュ関数によってスペックの低いスレーブサーバ３０が割り当てられた場合に、当該Reduce処理タスクをスペックの高いスレーブサーバ３０に割当直す。

例えば、再割当部１７は、通知された処理量の多いReduce処理が既に割り振られているスレーブサーバ３０をタスクリストＤＢ１２ｂから特定し、特定したスレーブサーバ３０のスペックをクラスタプロファイル１２ｃから特定する。そして、再割当部１７は、特定したスペックが、条件「CPUが3core以上、かつ、メモリが10GB以上、かつ、HDDが30GB以上」を満たすかを判定する。なお、この条件も任意に設定変更することができる。

ここで、再割当部１７は、割当済みのスレーブサーバのスペックが条件を満たす場合、ハッシュ関数による割り当てを維持する。一方、再割当部１７は、割当済みのスレーブサーバのスペックが条件を満たさない場合、クラスタプロファイル１２ｃを参照して、割当状態が「Not assigned」のスレーブサーバ３０のうち条件を満たすスレーブサーバ３０を検索する。そして、再割当部１７は、検索したスレーブサーバ３０に対応する割当状態を「assigned」に変更するとともに、該当Reduce処理タスクに対応する「再割当スレーブID」に、検出したスレーブサーバ３０のスレーブIDを設定する。このようにして、再割当部１７は、Reduce処理タスクの再割当を実行する。

図４の例では、再割当部１７は、予測部１６から「Reduce001」および「Reduce002」のReduce処理タスクの処理量が多いとの通知を受信する。そして、再割当部１７は、クラスタプロファイル１２ｃを参照して、割当済みのNode2とNode4が低スペックであり、再割当を要すると判断する。すると、再割当部１７は、クラスタプロファイル１２ｃを参照して、高スペックのNode10とNode11が未割当であることを確認して、これらのスレーブサーバに通知されたReduce処理タスクを割当てる。ここでは、再割当部１７は、「Reduce001」に対してNode11を再度割当て、「Reduce002」に対してNode10を再度割当てて、タスクリストＤＢ１２ｂを更新する。ここで、再割当部１７は、よりデータ量が多いタスクをより高スペックのサーバに割当てる。

なお、再割当部１７は、「Not assigned」のスレーブサーバ３０がない場合には、「assigned」のスレーブサーバ３０に割当てられているReduce処理と、処理量が多いReduce処理とを交換するように、割当の変更を実行することもできる。

［スレーブサーバの構成］
図７は、実施例２に係るスレーブサーバの機能構成を示す機能ブロック図である。図７に示すように、スレーブサーバ３０は、通信制御部３１と、記憶部３２と、制御部３３とを有する。

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

記憶部３２は、一時ファイルＤＢ３２ａと入出力ファイルＤＢ３２ｂとを有する記憶装置であり、例えばメモリやハードディスクなどである。また、記憶部３２は、制御部３３が実行するプログラムなどを記憶する。

一時ファイルＤＢ３２ａは、Map処理、Shuffle処理、Reduce処理等で生成される中間データ、他のスレーブサーバ３０等から読み出されたデータや各処理部が処理を実行する際に使用するデータを一時的に記憶するデータベースである。入出力ファイルＤＢ３２ｂは、Map処理の入力およびReduce処理の出力を記憶するデータベースであり、入出力ＤＢサーバ２と連携したデータベースである。

制御部３３は、スレーブサーバ３０全体の処理を司る処理部であり、例えばプロセッサなどである。この制御部３３は、Map処理部３４、Map結果送信部３５、Shuffle処理部３６、Reduce処理部３７を有する。また、Map処理部３４、Map結果送信部３５、Shuffle処理部３６、Reduce処理部３７は、電子回路の一例またはプロセッサが実行するプロセスの一例である。

Map処理部３４は、Map処理タスクを実行する処理部である。具体的には、Map処理部３４は、ハートビートを用いて、マスタサーバ１０にMap処理タスクの割当を要求する。このとき、Map処理部３４は、スレーブサーバ３０の空きスロット数も通知する。そして、Map処理部３４は、マスタサーバ１０から、「TaskID、データのあるスレーブID、必要スロット数」などを含むMap割当情報を受信する。

その後、Map処理部３４は、受信したMap割当情報にしたがって、「データのあるスレーブID」で特定されるスレーブサーバ３０が処理を行っているスレーブサーバであれば、入出力ＤＢ３２ｂからデータを取得する。そうでなければ、Map処理部３４は、「データのあるスレーブＩＤ」で特定されるスレーブサーバ３０からデータを取得して一時ファイルＤＢ３２ａ等に保存し、「必要スロット数」で指定されるスロット数を用いてMap処理を実行する。そして、Map処理部３４は、Map処理結果を一時ファイルＤＢ３２ａ等に格納する。ここで、生成されるMap処理結果は、例えば図６に示すように、Reduce処理のタスクIDやデータ量などが含まれる。

Map結果送信部３５は、Map処理部３４が実行したMap処理の結果をマスタサーバ１０に送信する処理部である。例えば、Map結果送信部３５は、Map処理部３４からMap処理が終了したことが通知されると、一時ファイルＤＢ３２ａなどからMap処理結果の一部を読み出す。そして、Map結果送信部３５は、図６に示した完了通知を生成してマスタサーバ１０に送信する。

Shuffle処理部３６は、Map処理の結果を「Key」でソートし、同じ「Key」を有する「Key、Value」ペアをマージして、Reduce処理の処理対象を生成する処理部である。具体的には、Shuffle処理部３６は、マスタサーバ１０からMap処理が終了したことを通知されると、当該Map処理が属するジョブのReduce処理を実行する準備として、各スレーブサーバ３０から該当するMap処理結果を取得する。そして、Shuffle処理部３６は、Map処理の結果を予め指定された「Key」でソートし、同じ「Key」を有する処理結果をマージして、一時ファイルＤＢ３２ａに格納する。

例えば、Shuffle処理部３６は、「JobID」が「Job001」のMap処理タスクである「Map000、Map001、Map002、Map003」が終了したこと、つまり、「JobID」が「Job001」のReduce処理タスクの実行開始をマスタサーバ１０から受信する。すると、Shuffle処理部３６は、Node1、Node2、Node3、Node4からMap処理結果を取得する。続いて、Shuffle処理部３６は、Map処理結果のソートおよびマージを実行し、その結果を一時ファイルＤＢ３２ａ等に格納する。

Reduce処理部３７は、マスタサーバ１０から割当てられたReduce処理タスクを受信し、Reduce処理タスクを実行する処理部である。例えば、Reduce処理部３７は、「JobID、TaskID、必要スロット数、処理データ量」などから構成されるReduce処理タスクの情報を受信する。そして、Reduce処理部３７は、受信した情報を一時ファイルＤＢ３２ａ等に格納する。その後、Reduce処理部３７は、各スレーブサーバ３０から該当データを取得して、Reduce処理を実行し、その結果を入出力ファイルＤＢ３２ｂに格納する。なお、Reduce処理部３７は、Reduce処理の結果をマスタサーバ１０に送信してもよい。

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

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

（Shuffle処理）
次に、スレーブサーバ３０が実行する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」を生成する。

［割当変更例］
図１１は、Reduce処理の割当変更を説明する図である。図１１の例では、Job001のジョブに関するMap処理とReduce処理とを例にして説明するが、他のジョブのMap処理等も実行されているものとする。なお、ここでは、Node1からNode4は低スペックのスレーブサーバであるとする。

図１１の左図に示すように、マスタサーバ１０は、Map処理タスクについてハッシュ関数を用いて、「Map000」をNode1に割当て、「Map001」をNode2に割当て、「Map002」をNode3に割当て、「Map003」をNode4に割当て。同様に、マスタサーバ１０は、Reduce処理タスクについてハッシュ関数を用いて、「Reduce001」をNode2に割当て、「Reduce002」をNode2に割当てる。

この状態で、マスタサーバ１０は、Job001のジョブ以外のジョブのMap処理が実行中に、Job001の「Map000」から「Map003」の処理が完了すると、各Map処理タスクの処理データ量を取得する。ここで、マスタサーバ１０は、「Map001」の処理データ量が閾値（1000GB）を超える「2000GB」であり、「Map003」の処理データ量が閾値（1000GB）を超える「3000GB」であることを検出する。このため、マスタサーバ１０は、Job001に対応するReduce処理を再割当対象に決定する。

すると、マスタサーバ１０は、クラスタプロファイル１２ｃを参照して、割当状態が「Not assigned」かつ高スペックのサーバとして、Node10とNode11を特定する。そして、図１１の右図に示すように、マスタサーバ１０は、Job001に対応するReduce処理の「Reduce001」をNode11に割当て、「Reduce002」をNode10に割当てる。

つまり、マスタサーバ１０は、「Reduce001」を実行するスレーブサーバ３０を、ハッシュ関数によって割り当てられたNode2からNode11に変更する。同様に、マスタサーバ１０は、「Reduce002」を実行するスレーブサーバ３０を、ハッシュ関数によって割り当てられたNode4からNode10に変更する。このようにして、マスタサーバ１０は、処理量の多いReduce処理タスクの再割当を実行する。

［マスタサーバの処理］
図１２は、実施例２に係るマスタサーバが実行する処理の流れを示すフローチャートである。図１２に示すように、マスタサーバ１０のMap割当部１４は、ジョブが投入されると（Ｓ１０１：Ｙｅｓ）、各スレーブサーバから空きスロット数を受信する（Ｓ１０２）。

そして、Map割当部１４は、予め指定された振分キーに関するハッシュ関数を用いて、Map処理タスクの各スレーブサーバに割当てる（Ｓ１０３）。ここで、Map割当部１４は、割当結果にしたがって、タスクリストＤＢ１２ｂを更新する。

続いて、Reduce割当部１５は、予め指定された振分キーに関するハッシュ関数を用いて、Reduce処理タスクの各スレーブサーバに割当てる（Ｓ１０４）。ここで、Reduce割当部１５は、割当結果にしたがって、タスクリストＤＢ１２ｂおよびクラスタプロファイル１２ｃを更新する。

その後、予測部１６は、Map処理タスクの完了通知を受信すると（Ｓ１０５：Ｙｅｓ）、タスクリストＤＢ１２ｂを更新する（Ｓ１０６）。具体的には、予測部１６は、処理が完了したMap処理タスクの状態を「Running」から「Done」に変更する。

そして、予測部１６は、現時点で全Map処理タスクのうちどのくらいのMap処理タスクが完了しているかを示すタスク完了率（Ｔｋ）を算出し（Ｓ１０７）、タスク完了率（Ｔｋ）が閾値（α）を超えるかを判定する（Ｓ１０８）。

ここで、タスク完了率（Ｔｋ）が閾値（α）以下の場合（Ｓ１０８：Ｎｏ）、予測部１６は、Ｓ１０５に戻って次のMap処理タスクの完了を待ち、以降の処理を繰り返す。一方、予測部１６は、タスク完了率（Ｔｋ）が閾値（α）を超える場合（Ｓ１０８：Ｙｅｓ）、終了済みのMap処理タスクの完了結果から各Reduce処理タスクの処理データ量を予測する（Ｓ１０９）。

そして、予測部１６は、推定した各Reduce処理タスクの処理データ量から、処理データ量が最も多いReduce処理タスクを特定する（Ｓ１１０）。続いて、予測部１６は、特定したReduce処理タスクの処理データ量（Ｄｉ）が閾値（β）を超えるかを判定する（Ｓ１１１）。

ここで、予測部１６は、Reduce処理タスクの処理データ量（Ｄｉ）が閾値（β）未満の場合（Ｓ１１１：Ｎｏ）、ハッシュ関数によるReduce処理タスクの割当を維持する（Ｓ１１２）。すなわち、予測部１６は、Reduce処理タスクの再割当を実行しない。

一方、予測部１６は、Reduce処理タスクの処理データ量（Ｄｉ）が閾値（β）を超える場合（Ｓ１１１：Ｙｅｓ）、該当Reduce処理タスクを、高スペックのスレーブサーバに割当てる（Ｓ１１３）。そして、予測部１６は、割当結果にしたがって、クラスタプロファイル１２ｃおよびタスクリストＤＢ１２ｂを更新する（Ｓ１１４）。すなわち、予測部１６は、Reduce処理タスクの再割当を実行する。

［スレーブサーバの処理］
図１３は、実施例２に係るスレーブサーバが実行する処理の流れを示すフローチャートである。図１３に示すように、スレーブサーバ３０は、マスタサーバ１０に、ハートビートでタスク要求を送信する（Ｓ２０１）。

続いて、スレーブサーバ３０は、タスク要求の応答としてジョブ情報とタスク情報を取得し（Ｓ２０２）、取得したタスク情報がMap処理タスクの情報か否かを判定する（Ｓ２０３）。

そして、スレーブサーバ３０のMap処理部３４は、取得したタスク情報がMap処理タスクの情報であると判定された場合（Ｓ２０３：Map）、入力データを読み込み（Ｓ２０４）、Map処理タスクを起動する（Ｓ２０５）。

例えば、Map処理部３４は、取得したMap処理タスクの情報における「データのあるスレーブID」で特定されるスレーブサーバ３０から入力データを取得し、取得したMap処理タスクの情報によって割当てられたMap処理タスクを起動する。

その後、Map処理部３４は、一時ファイルＤＢ３２ａに、Reduce処理タスクごとに分けて処理結果を保存し（Ｓ２０６）、Map処理タスクが終了するまで待機する（Ｓ２０７）。そして、Map結果送信部３５は、ハートビートを利用してMap処理タスクの完了とReduce向けデータ量をマスタサーバ１０に送信する（Ｓ２０８）。

一方、Reduce処理部３７が取得したタスク情報が、Reduce処理タスクの情報であると判定された場合（Ｓ２０３：Reduce）、Shuffle処理部３６は、各スレーブサーバ３０からMap処理結果を取得して、Shuffle処理を実行する（Ｓ２０９）。

Reduce処理部３７は、取得したReduce処理タスクを実行して（Ｓ２１０）、タスクが終了するまで待機し（Ｓ２１１）、タスクが完了すると、ハートビート等で完了通知をマスタサーバ１０に送信する（Ｓ２１２）。

このように、マスタサーバ１０は、Map処理の進行状況を監視し、すべてのMap処理の完了を待たずに、一部のMap処理の完了結果からデータが集中しそうなReduceを予測する。そして、マスタサーバ１０は、ある特定のスレーブサーバ３０にキーあるいはデータが集中すると予想される場合、マシンパワーが高いスレーブサーバ３０へデータを転送することで回避する。

一般的に、Map処理の完了と転送を待っていると、ハッシュ関数に基づいて、ある特定のスレーブサーバ３０のReduce処理にデータが集中して割当てられる場合がある。しかし、マスタサーバ１０は、一部のMap処理の結果からReduce処理の処理量を予測することで、スペックの低いスレーブサーバの処理量が増大することを回避する。

つまり、マスタサーバ１０は、予めMap処理後の出力結果の容量を監視する仕組みを取り入れることによって、マシンパワーが高いスレーブサーバ３０に、処理量の多いReduce処理を割り振る。この結果、スレーブサーバ３０のマシンリソースを最大限に利用でき、全体の処理時間を短縮することができる。

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

［タスク完了率］
図１４は、タスクの進行イメージと閾値との関係を説明する図である。図１４に示すように、MapReduceは、Map処理、Shuffle＆Sort処理、Reduce処理の３つのフェーズによって構成される。

Map処理は、割り与えられたスレーブサーバ３０上で各々のタイミングで実行される。同様に、Shuffle＆Sort処理も割り与えられたスレーブサーバ３０上で各々のタイミングで実行される。しかし、Reduce処理は、全Map処理および全Shuffle＆Sort処理の完了を待ってから、各スレーブサーバ３０が同時に実行を開始する。そのため、MapReduceは、一つのジョブを複数のタスクへ分けて、さらにこのタスクを並列処理するため、ジョブネットのように途中でショブ間において処理の待ち合わせの過程がないことが特長である。

マスタサーバ１０は、一部のMap処理タスクの完了結果をどの程度とするかは、任意に設定することができる。例えば、図１４の例では、６タスクの中で３タスクの完了を待つ場合（Ａ）、タスク完了率は５０%であり、すべてのMap処理タスクが完了する場合（Ｃ）は、タスク完了率は１００％となる。

マスタサーバ１０は、タスク完了率が１００％に近いほど予想精度が高まるが、再割当を開始するタイミングが遅くなるので、Reduce処理が開始される可能性もある。一方、マスタサーバ１０は、タスク完了率が０％に近いほど予想精度は低下するが、再割当を開始するタイミングが早くなるので、Reduce処理前に確実に再割当を実行できる。このため、マスタサーバ１０は、システム、ジョブ数、ジョブ種別に適したタスク完了率の閾値を、０％から１００％の範囲で任意に設定することができる。

［Map処理タスクの選択］
マスタサーバ１０は、実行が完了した一部のMap処理タスクの中から、Reduce処理の処理データ量の予測に使用するMap処理タスクを任意の手法で選択することができる。一例を挙げると、マスタサーバ１０は、実行が完了した順に、所定数のMap処理タスクを選択することもできる。また、マスタサーバ１０は、実行が完了したタスクの中から、ランダムに選択することもでき、特定の関数等によって算出された順番で選択することもできる。

また、マスタサーバ１０は、データ転送時間が長いタスクから順に選択することもできる。具体的には、マスタサーバ１０は、各スレーブサーバ間の通信速度と、転送対象のMap処理のデータ量とから、Map処理結果の転送時間を算出する。そして、マスタサーバ１０は、転送時間が長い順に所定数のMap処理結果を選択することもできる。

つまり、マスタサーバ１０は、処理完了後のMap処理結果について、スレーブサーバ間の通信速度とデータ転送量とから、Map処理結果の転送元スレーブサーバと転送先スレーブサーバとのデータ転送時間を算出する。そして、マスタサーバ１０は、データ転送時間が閾値以上となるMap処理タスクを用いて、Reduce処理の処理データ量を予測することができる。

［サーバリソース］
実施例２では、マスタサーバ１０は、スペックの高いスレーブサーバ３０に、処理量の多いReduce処理を割当てる例を説明したが、これに限定されるものではない。例えば、マスタサーバ１０は、空きリソースが多いスレーブサーバ３０に、処理量の多いReduce処理を割当てることもできる。

具体的には、マスタサーバ１０は、各スレーブサーバ３０からＣＰＵ使用率、メモリ使用率、ハードディスクのスループットを定期的に取得して平均値を算出する。そして、マスタサーバ１０は、予測開始時点で空きリソースが多いスレーブサーバ３０を、再割当先として選択することができる。なお、マスタサーバ１０は、平均値ではなく、予測開始時点での空きリソースが多いスレーブサーバ３０を再割当先として選択することができる。

［割当］
例えば、マスタサーバ１０は、データ量が多いReduce処理の数よりも高スペックなスレーブサーバの数の方が多い場合、各Reduce処理を各スレーブサーバに割当てるとともに、データ量が少ないReduce処理も高スペックなスレーブサーバに割当てることができる。一方、マスタサーバ１０は、データ量が多いReduce処理の数よりも高スペックなスレーブサーバの数の方が少ない場合、最もデータ量が多い各Reduce処理を高スペックなスレーブサーバに割当て、それ以外は低スペックなスレーブサーバに割当てる。

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

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

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

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

プロセッサ装置１０４が有する複数のＣＰＵ１０５は、図２や図７に示した各処理部と同様の処理を実行するプログラムをＨＤＤ１０３等から読み出してメモリ１０２に展開することで、図２や図７等で説明した各機能を実行するプロセスを動作させる。すなわち、このプロセスは、マスタサーバ１０が有するMap割当部１４、Reduce割当部１５、予測部１６、再割当部１７と同様の機能を実行する。また、このプロセスは、スレーブサーバ３０が有するMap処理部３４、Map結果送信部３５、Shuffle処理部３６、Reduce処理部３７と同様の機能を実行する。

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

１０ マスタサーバ
１１ 通信制御部
１２ 記憶部
１２ａ ジョブリストＤＢ
１２ｂ タスクリストＤＢ
１２ｃ クラスタプロファイルＤＢ
１３ 制御部
１４ Map割当部
１５ Reduce割当部
１６ 予測部
１７ 再割当部
３０ スレーブサーバ
３１ 通信制御部
３２ 記憶部
３２ａ 一時ファイルＤＢ
３２ｂ 入出力ファイルＤＢ
３３ 制御部
３４ Map処理部
３５ Map結果送信部
３６ Shuffle処理部
３７ Reduce処理部

Claims (7)

1. コンピュータに、
   入力データを分割して得られた第１の分割データ群に含まれる各分割データを、Map処理を行う複数のノードに分配し、
   前記第１の分割データ群のうちの一部の分割データ群についてのMap処理が完了すると、前記第１の分割データ群の全てのMap処理の完了後に実行されるReduce処理を行う複数のノードへの分配データの生成ルールを、前記一部の分割データ群についてのMap処理結果について適用して、分配データの各データ量を推定し、
   推定した前記各データ量に基づいて、少なくとも一部の分配データについての割り当て先ノードの選択制御を前記第１の分割データ群の全てのMap処理の完了前に開始する
   処理を実行させることを特徴とするタスク割当プログラム。
2. 前記推定する処理は、完了したMap処理のうち、完了した順に、所定数のMap処理結果を選択し、選択した前記所定数のMap処理の処理結果から前記分配データの各データ量を推定することを特徴とする請求項１に記載のタスク割当プログラム。
3. 前記推定する処理は、前記複数のノード間の通信速度と、推定した前記各データ量とに基づいて、前記分配データの転送時間が長い順に所定数のMap処理結果を選択し、選択した前記所定数のMap処理の処理結果から前記分配データの各データ量を推定することを特徴とする請求項１に記載のタスク割当プログラム。
4. 前記開始する処理は、推定した前記各データ量のうち閾値を超えるデータ量を有する前記分配データを、前記複数のノードのうちプロセッサ数、メモリ容量、ハードディスク容量の少なくとも１つから特定されるハードウェアスペックが閾値を超えるノードに割当てることを特徴とする請求項１に記載のタスク割当プログラム。
5. 前記開始する処理は、推定した前記各データ量のうち閾値を超えるデータ量を有する前記分配データを、前記複数のノードのうちプロセッサ使用率、メモリ使用率、ハードディスクのスループットの少なくとも１つから特定される空リソース量が閾値を超えるノードに割当てることを特徴とする請求項１に記載のタスク割当プログラム。
6. コンピュータが、
   入力データを分割して得られた第１の分割データ群に含まれる各分割データを、Map処理を行う複数のノードに分配し、
   前記第１の分割データ群のうちの一部の分割データ群についてのMap処理が完了すると、前記第１の分割データ群の全てのMap処理の完了後に実行されるReduce処理を行う複数のノードへの分配データの生成ルールを、前記一部の分割データ群についてのMap処理結果について適用して、分配データの各データ量を推定し、
   推定した前記各データ量に基づいて、少なくとも一部の分配データについての割り当て先ノードの選択制御を前記第１の分割データ群の全てのMap処理の完了前に開始する
   処理を含むことを特徴とするタスク割当方法。
7. 入力データを分割して得られた第１の分割データ群に含まれる各分割データを、Map処理を行う複数のノードに分配する分配部と、
   前記第１の分割データ群のうちの一部の分割データ群についてのMap処理が完了すると、前記第１の分割データ群の全てのMap処理の完了後に実行されるReduce処理を行う複数のノードへの分配データの生成ルールを、前記一部の分割データ群についてのMap処理結果について適用して、分配データの各データ量を推定する推定部と、
   推定した前記各データ量に基づいて、少なくとも一部の分配データについての割り当て先ノードの選択制御を前記第１の分割データ群の全てのMap処理の完了前に開始する選択実行部と
   有することを特徴とするタスク割当装置。

Images