JP5881025B2 - 並列データ処理システム、計算機および並列データ処理方法 - Google Patents

並列データ処理システム、計算機および並列データ処理方法 Download PDF

Info

Publication number
JP5881025B2
JP5881025B2 JP2014518181A JP2014518181A JP5881025B2 JP 5881025 B2 JP5881025 B2 JP 5881025B2 JP 2014518181 A JP2014518181 A JP 2014518181A JP 2014518181 A JP2014518181 A JP 2014518181A JP 5881025 B2 JP5881025 B2 JP 5881025B2
Authority
JP
Japan
Prior art keywords
record
data
data set
thread
input data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014518181A
Other languages
English (en)
Other versions
JPWO2013179451A1 (ja
Inventor
和生 合田
和生 合田
山田　浩之
浩之 山田
喜連川　優
優 喜連川
信男 河村
信男 河村
藤原　真二
真二 藤原
茂木　和彦
和彦 茂木
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
University of Tokyo NUC
Original Assignee
Hitachi Ltd
University of Tokyo NUC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd, University of Tokyo NUC filed Critical Hitachi Ltd
Publication of JPWO2013179451A1 publication Critical patent/JPWO2013179451A1/ja
Application granted granted Critical
Publication of JP5881025B2 publication Critical patent/JP5881025B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G06F16/24532—Query optimisation of parallel queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、並列データ処理技術に関する。
企業等の活動においては、業務等に係る大量のデータを戦略的に利用することが極めて重要になってきている。大量のデータを利用するための情報システムとしては、Hadoopをはじめとする並列データ処理システムが用いられている。当該並列データ処理システムは、例えば、特許文献１に開示されている。
米国特許第７７５６９１９号明細書
Hadoopをはじめとする並列データ処理システムにおいては、ストレージ等に格納されたデータセット（例えばファイルシステムに格納されたファイル）の全体を読み込んで処理することを基本としている。例えば、アプリケーション（ジョブ）が処理の対象とするデータに選択性を有する場合（即ち、ストレージ等に格納されたデータセットのうち一部のレコードを処理の対象とする場合）であっても、データセットの全体を読み込む必要があり、データ処理が必ずしも効率的でなく行われ、よってデータ処理に係る時間が長くなる場合がある。また、データセットが巨大化するに従い、データセットの全体を読み込むのに要する時間が長くなり、よってデータ処理に係る時間が長くなる場合がある。
そこで、本発明の目的は、データ処理に係る時間を短縮することにある。
複数の計算ノード（例えば、計算機）において並行してデータ処理を実行する計算機システムにおける１つの計算ノードが有する並列データ処理システムが、複数の第１データを含む第１データ群と複数の第２データを含む第２データ群とを含むデータ群からデータを読み込んで処理を実行する並列データ処理実行部を有する。並列データ処理システムは、例えば、後述する実施例１及び２におけるシステムモジュールでよい。第１データ群における第１データが、第２データ群の第２データに対応していてよい。例えば、第１データ群は第２データ群の索引であってよい。この際、第１データは、第２データの索引鍵の値と、当該索引鍵の値に対応する１以上の第２データへの参照を含んでよい。
並列データ処理実行部は、
（Ａ）第１データ群から、第１データを読み込み、アプリケーションから取得した第１書式情報に基づいて、第１データから第１の値を取得し、
（Ｂ）アプリケーションから取得した第１参照情報に基づき、第１の値に対応する１以上の第２データのそれぞれを第２データ群から読み込むための１以上のスレッドを生成し、
（Ｃ）（Ａ）〜（Ｂ）を、第１データ群の１以上の第１データに対して実行し、
（Ｄ）複数の前記スレッドを並行して実行する。
並列データ処理システムは、処理の指示をアプリケーションから受け付ける受付部を更に有していてよい。アプリケーションからの指示は、一般に、手続を規定しているが、並列データ処理実行部は、アプリケーションからの指示を受けて、（Ａ）乃至（Ｄ）を実行することにより、アプリケーションからの指示が、手続を規定していても、並列データ処理システムは、手続に依存しない非順序の処理を実行することができる。
本発明によれば、計算ノードはデータ処理に係るデータの読み込みを並行して実行することができるようになる。これにより、データ読み込みのスループットが向上し、故に、データ処理に係る時間が短縮されることが期待される。
図１Ａは、実施例１に係るジョブ実行モデルを示す。 図１Ｂは、実施例２に係るジョブ実行モデルを示す。 図２Ａは、実施例１に係る計算ノードの構成を示す。 図２Ｂは、実施例２に係る計算ノードの構成を示す。 図３Ａは、実施例に係る計算機システムの第１の構成例を示す。 図３Ｂは、実施例に係る計算機システムの第２の構成例を示す。 図４Ａは、実施例１に係るマップタスク実行処理の流れを示す。 図４Ｂは、実施例２に係るタスク実行処理の流れを示す。 図５Ａは、実施例１に係る入力データ及び入力データに対する処理を説明するための図である。 図５Ｂは、実施例１に係る書式及び参照の一例を示す。 図５Ｃは、スレッド生成及びスレッドの実行を説明する模式図の一例である。 図５Ｄは、実施例２に係る入力データ及び入力データに対する処理を説明するための第１の図である。 図５Ｅは、実施例２に係る入力データ及び入力データに対する処理を説明するための第２の図である。 図５Ｆは、実施例２に係る書式の一例を示す。 図５Ｇは、実施例２に係る参照方式の一例を示す。 図５Ｈは、実施例２に係るカタログの一例を示す。 図６Ａは、データ取得時のセッションを説明するための模式図の一例である。 図６Ｂは、変形例に係るデータ取得時のブロック化セッションを説明するための模式図の一例である。 図７Ａは、実施例１に係るレコードを取得する計算ノードにおけるレコード取得処理の流れを示す。 図７Ｂは、実施例１に係るレコードを管理する計算ノードにおけるレコード取得処理の流れを示す。 図７Ｃは、実施例１に係るデータ読み込み要求管理表及びリモートレコード取得要求管理表の構成を示す。 図７Ｄは、実施例１の変形例に係るレコードを取得する計算ノードにおけるレコード取得処理の流れを示す。 図７Ｅは、実施例１の変形例に係るレコードを管理する計算ノードにおけるレコード取得処理の流れを示す。 図７Ｆは、実施例１の変形例に係るブロック化リモートレコード取得要求管理表の構成を示す。 図８Ａは、実施例１に係るノードレベルの資源制約管理表の構成を示す。 図８Ｂは、実施例１に係るジョブレベルの資源制約管理表の構成を示す。 図８Ｃは、実施例１に係る統括スーパバイザプロセスにおけるプロセスレベルの資源制約管理表の構成を示す。 図８Ｄは、実施例１に係る各ノードのスーパバイザプロセスにおけるプロセスレベルの資源制約管理表の構成を示す。 図８Ｅは、実施例１に係る統括スーパバイザプロセスにおけるタスクレベルの資源制約管理表の構成を示す。 図８Ｆは、実施例１に係る各ノードのスーパバイザプロセスにおけるタスクレベルの資源制約管理表の構成を示す。 図８Ｇは、実施例１に係る統括資源制約管理処理の流れを示す。 図８Ｈは、実施例１に係る各ノードにおける資源制約管理処理の流れを示す。 図９Ａは、実施例１に係るタスクの第１の例を示す。 図９Ｂは、実施例１に係る第１の例に示すタスクにおけるスレッドの生成の一例を示す。 図９Ｃは、実施例１に係る第１の例に示すタスクにおけるスレッドの生成の一例を示す。 図９Ｄは、実施例１に係るタスクの第２の例を示す。 図９Ｅは、実施例１に係る第２の例に示すタスクにおけるスレッドの生成の一例を示す。
以下、図面を参照しながら、幾つかの実施例及び変形例を説明する。なお、以下の説明により本発明が限定されるものではない。
まず、実施例１に係るジョブ実行モデルを説明する。
図１Ａは、実施例１に係るジョブ実行モデルを示す。なお、図１Ａにおいては、１つの実線の円は１つのプロセス（例えば、マッププロセスやリデュースプロセス）を示す。プロセス内の１つの破線の円は１つのタスクを示す。タスク中の１つの角丸四角は１つのスレッドを示す。
当該ジョブ実行モデルによれば、ジョブはネットワークで接続された複数の計算ノードによって実行される。例えば、複数の計算ノードの全体を統括する計算ノードにおけるスーパバイザプロセス（以下、統括スーパバイザプロセスとする）が、ジョブの実行に参加する全計算ノードにアプリケーションのコードを配布し、統括スーパバイザプロセスが各計算ノードのスーパバイザプロセスに対してマッププロセスやリデュースプロセスなどのプロセスの割り当てを行う。各計算ノードのスーパバイザプロセスは、統括スーパバイザプロセスの指示に基づいて、プロセスを生成する。また、生成されたプロセスは、統括スーパバイザプロセスの指示に基づいて、タスクを生成する。各計算ノードは、このように生成されたプロセス及びタスクを実行することにより、アプリケーションに含まれるマップ演算等を実行して、ジョブを実行する。統括スーパバイザプロセスは、複数の計算ノードにおける複数のスーパバイザプロセスのいずれか１つであってもよいし（即ち、いずれか１つのスーパバイザプロセスが、統括スーパバイザプロセスを兼ねてもよいし）、複数のスーパバイザプロセスとは別に用意された、専用の統括スーパバイザプロセスとして機能する専用のプロセスであってもよい。また、プロセスの割り当ては上記に限らず、統括スーパスーパバイザプロセスが各計算ノードのスーパバイザプロセスに指示を行って行ってもよく、プロセスやタスクの生成は上記に限らず、統括スーパバイザプロセスが直接行ってもよい。
並列データ処理システムは、ジョブ実行モデルに従い、マッププロセスを実行し、ストレージに格納された入力データセット＃１（即ち、第１のデータセット）と入力データセット＃２（即ち、第２のデータセット）とに含まれるレコードを読み込んで、マップ演算を実行し、その結果レコードをストレージに格納された中間データセットに書き込む。更に、リデュースプロセスを実行し、中間データセットに書き込まれた結果レコードを入力として、リデュース演算を実行し、その結果レコードを出力データセット＃１に書き込む。入力データセット、中間データセットならびに出力データセットはそれぞれ複数のレコードの集まりであり、何らかのデータ構造によって構造化されていてもよいし、構造化されていなくてもよい。例えば、入力データセット＃２は、１以上のファイルの集合であってもよい。
入力データセット＃１はそのレコードが、入力データセット＃２のレコードに対応したものであればよい。例えば、入力データセット＃１は、入力データセット＃２の索引であってもよい。入力データセット＃１の各レコードは、入力データセット＃２のレコードの所定の索引鍵の値と、当該索引鍵の値に対応する入力データセット＃２の１以上のレコードを示す参照を含んでよい。この際、参照は入力データセット＃２のレコードを記憶装置上で特定可能な格納位置を含んでもよいし、入力データセット＃２を格納するのに設けられたデータ構造上においてレコードを特定可能な唯一性のある索引鍵を含んでもよい。また、入力データセット＃１は入力データセット＃２の全てのレコードに対応するレコードを有していてもよいし、入力データセット＃２の一部のレコードに対応するレコードのみを有していてもよい。また、入力データセット＃１は、入力データセット＃２の索引でなくてもよい。例えば、入力データセット＃１と入力データセット＃２は結合可能な関係にあり、入力データセット＃１は単なるレコードの集まりであり、入力データセット＃２はレコードの集まりであって、データ構造によってある索引鍵によって構造化されており、入力データセット＃１のあるレコードのある項目の値に対応するような、索引鍵の値を有する入力データセット＃２のレコードを読み込むものであってもよい。また、入力データセット＃１と入力データセット＃２は、同じデータ構造に属するものであってもよい。例えば、入力データセット＃１はＢ木を構成する内部ノードの集合であり、入力データセット＃２は同じＢ木を構成する葉ノードの集合であってもよい。更に、入力データセット＃１はＢ木を構成するあるレベルのノードの集合であり、入力データセット＃２は同じＢ木を構成する次のレベルの（入力データセット＃１から参照される）ノードの集合であってもよい。また、入力データセットは３つ以上から構成されてもよく、例えば、更に、入力データセット＃２のレコードに対応した別の入力データセットがあってもよい。
マッププロセスにおいては、マップ演算、分割演算、書式＃１、書式＃２、参照方式、条件等に従い、各計算ノードのプロセッサによりデータ処理が実行される。マップ演算、分割演算、書式＃１、書式＃２、参照方式、条件等は、計算ノードに格納されているアプリケーションに含まれるプログラムコードである。マップ演算は、読み込んだレコードに対して適用される処理を規定するプログラムコードであり、例えば、読み込んだレコードからキーとバリューのペアからなる結果レコードを生成するものである。分割演算は、マップ演算を実行したのち、その実行結果を受け渡すリデュースプロセスを決定する際に実行されるプログラムコードであり、例えば、分割演算はマップ演算の結果レコードが含むキーに対するハッシュ演算などを含んでよい。書式＃１は、入力データセット＃１のレコードを解釈するための書式を規定するプログラムコードである。書式＃２は、入力データセット＃２のレコードを解釈するための書式を規定するプログラムコードである。参照方式は、入力データセット＃１のレコードの参照に従い、入力データセット＃２のレコードを取得する方式を規定するプログラムコードである。条件は、入力データセット＃１及び／又は入力データセット＃２に格納されたレコードのうちマップ演算の対象とするべきレコードの要件を規定するプログラムコードである。当該条件は、その全部もしくは一部が、入力データセット＃１ならびに入力データセット＃２のいずれかからレコードを読み込む際に実行されてもよいし、その全部もしくは一部が、読み込んだレコードをマップ演算に入力する際に実行されてもよい。なお、プログラムコードは、コンパイル等によって生成されたプロセッサで実行可能な命令であってもよいし、実行処理系等によってプロセッサで実行可能な命令に変換することができる命令であってもよいし、実行処理系等によってプロセッサで実行可能な命令を生成することのできる宣言であってもよい。更に、これらを組み合わせたものであってもよいし、他の情報を更に含んでよい。命令ならびに宣言は、プロセッサ、コンパイラもしくは実行処理系等が解釈可能なバイト列であってもよいし、ソースコート等で記述されていてもよい。
具体的に説明すると、計算ノードのプロセッサは、マッププロセスにおいてタスクを実行し、当該タスクにおいて、入力データセット＃１からレコードを読み込み、書式＃１を用いてレコードを解釈し、条件に基づいて、当該レコードが要件を満たすかどうかを判定し、要件を満たしたレコードから入力データセット＃２への参照を取得する。この際、入力データセット＃１は、事前に複数のチャンクに分割されていてもよい。例えば、入力データセット＃１は複数のファイルから構成されていてもよく、統括スーパバイザプロセスが各々のファイルに対して別のタスクを割り当て、各タスクは割り当てられたファイルからレコードを読み込むこととしてもよい。もしくは、入力データセット＃１は、実行時に複数のチャンクから構成されているかの如く分割可能であってもよい。例えば、入力データセット＃１は単一のファイルから構成されており、当該ファイル中の複数の重なりのない領域を示す情報を備えており、統括スーパバイザプロセスがそれぞれの領域を先述のチャンクとして見做して別のタスクを割り当て、各タスクは割り当てられた領域からレコードを読み込むこととしてもよい。領域を示す情報は事前に与えられていてもよく、もしくは、統括スーパバイザプロセスによって実行時に決定されてもよい。また、領域と別の領域の間に重なりがあっても、読み込む際に一方の領域に割り当てられたタスクが重なり部分を読み込まないようにする手段が具備されていてもよい。また、入力データセット＃１からレコードを読み込む際に、入力データセット＃１が条件に規定された要件を満足するレコードに対して選択的なアクセスを可能とするデータ構造を以って構成されている（例えば、整列されている、もしくはＢ木等で構成されている）場合には、条件に規定された要件を用いて選択的なアクセスを行ってよい。
次いで、プロセッサは、入力データセット＃１のレコードが含む参照に基づいて入力データセット＃２からレコードを読み込むためにスレッドを生成する。入力データセット＃１のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット＃１のレコードが有する参照の各々に対してスレッドを生成してもよい。これらのスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式に基づいて、参照によって入力データセット＃２のレコードを読み込む。プロセッサは、書式＃２を用いて読み込んだレコードを解釈し、条件に基づいて当該レコードが要件を満たすかどうかを判定する。プロセッサは、要件を満たすレコードに対して、マップ演算を実行し、更に、分割演算を実行することによりマップ演算の実行結果を送るべきリデュースプロセスを決定する。プロセッサは、決定したリデュースプロセスがマップ演算の実行結果を受け取れるように出力する。具体的には、実行結果を中間データセットに格納する。
リデュースプロセスにおいては、リデュース演算等に従い、各計算ノードのプロセッサによりデータ処理が実行される。リデュース演算は計算ノードに格納されているアプリケーションに含まれたプログラムコードである。リデュース演算は、中間データセットのレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算の生成した結果レコード（キーとバリューのペアからなる）をキーに従って集約することにより結果レコードを生成するものである。
具体的には、プロセッサは、中間データセットからマップ演算の実行結果レコードを取得し、当該レコードを入力として、リデュース演算を実行して、その実行結果レコードを出力データセット＃１に格納する。
マップ演算、分割演算、書式＃１、書式＃２、参照方式、条件、リデュース演算はその全てがアプリケーションで規定されている必要はなく、その一部が規定されていればよい。規定されていないものについては、所定の取り扱いを行ってよい。例えば、リデュース演算が規定されていない場合は（即ち、リデュースプロセスが規定されていない場合は）、マッププロセスの出力をジョブの出力と見做してよい。
マッププロセス及び／又はリデュースプロセスでは、更に比較演算に従い、また、マッププロセスでは、更に集約演算に従い、各計算ノードのプロセッサによりデータ処理が実行されてもよい。比較演算、集約演算は、計算ノードに格納されているアプリケーションに含まれるプログラムコードである。比較演算は、マッププロセスにおいて分割演算の結果レコードを中間データセットに書き込む際に、もしくは、リデュースプロセスにおいてリデュース演算の入力レコードを中間データセットから読み込む際に、結果レコード／入力レコードを一旦、整列するために当該レコード間の順序性を規定するためのものである。例えば、比較演算は、マップ演算が生成した結果レコード（キーとバリューのペアからなる）のキーの値の大小を比較するものである。比較演算はアプリケーションによって規定されなくてもよいし、マッププロセスもしくはリデュースプロセスのどちらか一方のために規定されてもよいし、また、両方のプロセスに同じ比較演算が規定されてもよいし、両方のプロセスに異なる比較演算が規定されてもよい。集約演算は、マッププロセスにおいて分割演算の結果レコードを中間データセットに書き込む際に、結果レコードを一旦、集約するためのものである。例えば、集約演算は、マップ演算が生成した結果レコード（キーとバリューのペアからなる）のキーに従って集約することにより結果レコードを生成するものである。集約演算はアプリケーションによって規定されなくてもよい。マッププロセスに対して、比較演算と集約演算が規定されてもよい。この場合、例えば、比較演算に従って整列された結果レコードに対して集約演算が行われてもよい。
マッププロセスでは、複数の異なるデータセットからのレコードを並行して、もしくは逐次的に入力してもよい。例えば、上記の例では、入力データセット＃１から参照された入力データセット＃２からレコードを読み込み、マップ演算への入力としていたが、更に、別に入力データセット＃１−２から参照された入力データセット＃２−２からレコードを読み込み、マップ演算への入力としてもよい。この際、書式＃１、書式＃２、参照方式、条件は、同じものを用いてもよいし、別のものを用いてもよい。
図１Ａでは、文献 Jeffrey Dean, Sanjay Ghemawat: MapReduce: Simplified Data Processing on Large Clusters. Proceedings of OSDI 2004, pp. 137-15 (2004) に示されるマッププロセスとリデュースプロセスから構成されるジョブ実行モデルを示していたが、他のジョブ実行モデルであってもよい。例えば、図１Ａでは、入力データセットを２段とした例を示すが、入力データセットは、２段以上であってもよい。また、図１Ａでは、マッププロセスとリデュースプロセスの２つのステージのプロセスで構成されたジョブ実行モデルを示していたが、３以上のステージのプロセスで構成されたジョブ実行モデルであってもよい。また、図１Ａでは、先頭のマッププロセスのみがストレージに格納された入力データセットからレコードを読み込むようにしていたが、例えば、それ以外のステージのプロセスがストレージの入力データセットからレコードを読み込むようにしてもよい。また、図１Ａでは、マッププロセスはその結果レコードを一旦中間データセットに書き込み、リデュースプロセスが当該中間データセットから結果レコードを読み込むことにより、マッププロセスからリデュースプロセスへとレコードの受け渡しを行うようにしていたが、マッププロセスを実行する際に、マップ演算の結果レコードを中間データセットに格納せずにネットワークを通じて送信し、リデュースプロセスを実行する際に、当該マップ演算の結果レコードをネットワークを通じて受信してもよい。マッププロセスとリデュースプロセスを並行して実行してもよい。また、リデュースプロセスを実行する際に、リデュース演算の結果レコードを出力データセットに書き込まずに、コンソールやプリンタに出力してもよいし、ネットワークを経由して他の計算機等に送信してもよい。マッププロセスはその結果レコードをネットワークを通じてリデュースプロセスに送信し、リデュースプロセスはネットワークを通じて結果レコードを受信してもよい。このように拡張されたジョブ実行モデルの一例は、文献 Michael Isard, Mihai Budiu, Yuan Yu, Andrew Birrell, Dennis Fetterly: Dryad: distributed data-parallel programs from sequential building blocks. Proceedings of EuroSys 2007, pp. 59-72 (2007) や文献 Vinayak R. Borkar, Michael J. Carey, Raman Grover, Nicola Onose, Rares Vernica: Hyracks: A flexible and extensible foundation for data-intensive computing. Proceedings of ICDE 2011, pp. 1151-1162 (2011) に開示されている。
次に、実施例２に係るジョブ実行モデルを説明する。
図１Ｂは、実施例２に係るジョブ実行モデルを示す。なお、図１Ｂは図１Ａと同様に表記されている。実施例２に係るジョブ実行モデルは実施例１に係るジョブ実行モデルを拡張したものであり、実施例１に関して説明した部分は、改めて説明せずとも、実施例２に適用される。
このジョブ実行モデルによれば、ジョブはネットワークで接続された複数の計算ノードによって実行される。図１Ｂに例示するジョブは、ステージ＃１プロセスを実行することにより、入力データセット＃１、入力データセット＃２、入力データセット＃３、及び入力データセット＃４からレコードを読み込み、これを入力として、ステージ演算＃１を実行し、その実行結果レコードをステージ＃２プロセスに送信する。また、ステージ＃２プロセスを実行することにより、実行結果レコードを受信し、これを入力としてステージ演算＃２を実行し、その実行結果レコードをステージ＃３プロセスに送信する。更に、ステージ＃３プロセスを実行することにより、実行結果レコードを受信し、これを入力としてステージ演算＃３を実行し、その実行結果レコードをステージ＃４に送信する。加えて、ステージ＃４プロセスを実行することにより、実行結果レコードを受信するとともに、入力データセット＃５及び入力データセット＃６からレコードを読み込み、これらを入力レコードとしてステージ＃４演算を実行し、実行結果レコードを出力データセット＃１に格納する。実施例１と同様に、異なるステージのプロセスの間では、中間データセットを経てデータを受け渡してもよいし、ネットワークによってデータを送受信してもよい。また、異なるステージのプロセスは並行して実行してもよい。
入力データセット＃１は、入力データセット＃２の索引であってもよい。例えば、入力データセット＃１の各レコードは、入力データセット＃２のレコードの所定の索引鍵の値と、当該索引鍵の値に対応する入力データセット＃２の１以上のレコードを示す参照を含んでよい。同様に、入力データセット＃３は、入力データセット＃４の索引であってよい。入力データセット＃３の各レコードは、入力データセット＃４のレコードの所定の索引鍵の値と、当該索引鍵の値に対応する入力データセット＃４の１以上のレコードを示す参照を含んでよい。また、入力データセット＃２のレコードの所定の項目は、入力データセット＃３の１以上のレコードを示す参照を含んでよい。即ち、入力データセット＃２のあるレコードに対して入力データセット＃３の１以上のレコードを対応させることが可能であってよい。実施例１と同様に、参照は参照先の入力データセットのレコードを記憶装置上で特定可能な格納位置を含んでもよいし、参照先の入力データセットを構成するデータ構造においてレコードを特定可能な唯一性のある索引鍵を含んでもよい。また、参照元の入力データセットは参照先の入力データセットの全てのレコードに対応するレコードを有していてもよいし、参照先の入力データセットの一部のレコードに対応するレコードのみを有していてもよい。
入力データセット＃５は、入力データセット＃６の索引であってもよい。入力データセット＃５の各レコードは、入力データセット＃６のレコードの所定の索引鍵の値と、当該索引鍵の値に対応する入力データセット＃６の１以上のレコードを示す参照を含んでよい。
ステージ＃１プロセスにおいては、ステージ演算＃１、分割演算＃１、書式＃１、書式＃２、書式＃３、書式＃４、参照方式＃１、参照方式＃２、参照方式＃３、条件＃１、ビルド方式＃１等に従い、各計算ノードのプロセッサにより処理が実行される。ステージ演算＃１、分割演算＃１、書式＃１、書式＃２、書式＃３、書式＃４、参照方式＃１、参照方式＃２、参照方式＃３、条件＃１、ビルド方式＃１等は、計算ノードに格納されているアプリケーションに含まれたプログラムコードである。ステージ演算＃１は、読み込んだレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。分割演算＃１は、演算結果を受け渡す後続のステージのプロセスを決定する際に実行されるプログラムコードである。例えば、分割演算は入力に対するハッシュ関数などを含んでよい。書式＃１、書式＃２、書式＃３ならびに書式＃４は、それぞれ入力データセット＃１、入力データセット＃２、入力データセット＃３ならびに入力データセット＃４のレコードを解釈するための書式を規定するプログラムコードである。参照方式＃１、参照方式＃２ならびに参照方式＃３は、それぞれ入力データセット＃１、入力データセット＃２ならびに入力データセット＃３のレコードの参照に従い、入力データセット＃２、入力データセット＃３ならびに入力データセット＃４のレコードを取得する方式を規定するプログラムコードである。条件＃１は、ステージ演算＃１の対象とするべきレコードの条件を規定する手続きである。条件＃１は、その全部もしくは一部が、入力データセット＃１、入力データセット＃２、入力データセット＃３ならびに入力データセット＃４のいずれかからレコードを読み込む際に実行されてもよいし、その全部もしくは一部が、読み込んだレコードをマップ演算に入力する際に実行されてもよい。ビルド方式＃１は、入力データセット＃１、入力データセット＃２、入力データセット＃３ならびに入力データセット＃４から読み込んだレコードからステージ演算＃１に入力するレコードを生成する方式を規定するプログラムコードである。
具体的に説明すると、計算ノードのプロセッサは、ステージ＃１プロセスにおいてタスクを実行し、当該タスクにおいて、入力データセット＃１からレコードを読み込み、書式＃１を用いてレコードを解釈し、条件＃１に基づいて、当該レコードが要件を満足するかどうかを判定し、要件を満足するレコードから入力データセット＃２への参照を取得する。
次いで、プロセッサは、入力データセット＃１のレコードが含む参照に基づいて入力データセット＃２からレコードを読み込むためにスレッドを生成する。入力データセット＃１のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット＃１のレコードが有する参照の各々に対してスレッドを生成してもよい。これらスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式＃１に基づいて、参照によって入力データセット＃２からレコードを読み込む。プロセッサは、書式＃２を用いて読み込んだレコードを解釈し、条件＃１に基づいて、当該レコードが要件を満足するかどうかを判定する。更にプロセッサは、要件を満足するレコードから入力データセット＃３への参照を取得する。ここで、プロセッサは、参照を用いて入力データセット＃３を参照して処理を行うスレッドを生成する。複数の参照がある場合には、プロセッサは、複数のスレッドを生成する。これらスレッドは、プロセッサにより並行して実行される。
更に次いで、プロセッサは、入力データセット＃２のレコードが含む参照に基づいて入力データセット＃３からレコードを読み込むためにスレッドを生成する。入力データセット＃２のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット＃２のレコードが有する参照の各々に対してスレッドを生成してもよい。これらスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式＃２に基づいて、参照によって入力データセット＃３からレコードを読み込む。プロセッサは、書式＃３を用いて、読み込んだレコードを解釈し、条件＃１に基づいて、当該レコードが要件を満足するかどうかを判定する。更にプロセッサは、要件を満足するレコードから入力データセット＃４への参照を取得する。
更に次いで、プロセッサは、入力データセット＃３のレコードが含む参照に基づいて入力データセット＃４からレコードを読み込むためにスレッドを生成する。入力データセット＃３のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット＃３のレコードが有する参照の各々に対してスレッドを生成してもよい。これらスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式＃３に基づいて、参照によって入力データセット＃４からレコードを読み込む。プロセッサは、書式＃４を用いて読み込んだレコードを解釈し、条件＃１に基づいて、当該レコードが要件を満足するかどうかを判定する。プロセッサは、要件を満足するレコードに対して、ビルド方式＃１に基づいて、ステージ演算＃１に入力するレコードを生成し、当該レコードを入力としてステージ演算＃１を実行する。更に、１以上のステージ演算＃１の実行結果レコードに対して分割演算＃１を行うことにより、実行結果レコードを送るべき後続のステージ＃２のプロセスを決定する。プロセッサは、決定した後続のステージのプロセスが実行結果レコードを受け取れるように出力する。具体的には、実行結果を中間データセットに格納するか、ネットワークで後続のステージのプロセスに送る。
ステージ＃２プロセスにおいては、ステージ演算＃２、分割演算＃２に従い、各計算ノードのプロセッサにより処理が実行される。ステージ演算＃２、分割演算＃２は計算ノードに格納されているアプリケーションに含まれたプログラムコードである。例えば、ステージ演算＃２は、中間データセットから取得したレコード又はネットワークで送られたレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。分割演算＃２は、実行結果を受け渡す後続のステージ＃３のプロセスを決定する際に実行されるプログラムコードである。例えば、分割演算＃２は入力に対するハッシュ関数などを含んでよい。
具体的に説明すると、計算ノードのプロセッサは、ステージ＃２プロセスにおいてタスクを実行し、当該タスクにおいて、ステージ＃１プロセスから受け渡されたレコードを取得し、ステージ演算＃２を実行し、更に分割演算＃２を行うことにより、ステージ演算＃２の実行結果レコードを送るべき後続のステージ＃３のプロセスを決定する。プロセッサは、決定した後続のステージのプロセスがステージ演算＃２の実行結果レコードを受け取れるように出力する。具体的には、実行結果を中間データセットに格納するか、ネットワークで後続のステージのプロセスに送る。
ステージ＃３プロセスにおいては、ステージ演算＃３、分割演算＃３に従い、各計算ノードのプロセッサにより処理が実行される。ステージ演算＃３、分割演算＃３は計算ノードに格納されているアプリケーションに含まれたプログラムコードである。例えば、ステージ演算＃３は、中間データセットから取得したレコード又はネットワークで送られたレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。分割演算＃３は、実行結果を受け渡す後続のステージ＃４のプロセスを決定する際に実行されるプログラムコードである。例えば、分割演算＃３は入力に対するハッシュ関数などを含んでよい。
具体的に説明すると、計算ノードのプロセッサは、ステージ＃３プロセスにおいてタスクを実行し、当該タスクにおいて、ステージ＃２プロセスから受け渡されたレコードを取得し、ステージ演算＃３を実行し、更に分割演算＃３を行うことにより、ステージ演算＃３の実行結果レコードを送るべき後続のステージ＃４のプロセスを決定する。プロセッサは、決定した後続のステージのプロセスがステージ演算＃３の実行結果レコードを受け取れるように出力する。具体的には、実行結果を中間データセットに格納するか、ネットワークで後続のステージのプロセスに送る。
ステージ＃４プロセスにおいては、ステージ演算＃４、書式＃５、書式＃６、参照方式＃４等に従い、各計算ノードのプロセッサにより処理が実行される。ステージ演算＃３、分割演算＃３、書式＃５、書式＃６、参照方式＃４は計算ノードに格納されているアプリケーションに含まれたプログラムコードである。例えば、ステージ演算＃４は、中間データセットから取得したレコード又はネットワークで送られたレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。書式＃５ならびに書式＃６は、それぞれ入力データセット＃５ならびに入力データセット＃６のレコードを解釈するための書式を規定するプログラムコードである。参照方式＃４は、入力データセット＃５のレコードの参照に従い、入力データセット＃６のレコードを取得する方式を規定するプログラムコードである。
更に、具体的に説明すると、計算ノードのプロセッサは、ステージ＃４プロセスにおいてタスクを実行し、当該タスクにおいて、入力データセット＃５からレコードを読み込み、書式＃５を用いてレコードを解釈し、レコードから入力データセット＃６への参照を取得する。
次いで、プロセッサは、入力データセット＃５のレコードが含む参照に基づいて入力データセット＃６からレコードを読み込むためにスレッドを生成する。入力データセット＃５のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット＃５のレコードが有する参照の各々に対してスレッドを生成してもよい。これらスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式＃４に基づいて、参照によって入力データセット＃６からレコードを読み込む。プロセッサは、書式＃６を用いて読み込んだレコードを解釈する。また、ステージ演算＃３の実行結果であるレコードを取得する。これらのレコードを入力として、ステージ演算＃４を実行し、その実行結果レコードを出力データセット＃１に格納する。
実施例１と同様に、ステージ演算＃１、分割演算＃１、書式＃１、書式＃２、書式＃３、書式＃４、参照方式＃１、参照方式＃２、参照方式＃３、条件＃１、ビルド方式＃１、ステージ演算＃２、分割演算＃２、ステージ演算＃３、分割演算＃３、ステージ演算＃４、書式＃５、書式＃６、参照方式＃４はその全てがアプリケーションで規定されている必要はなく、その一部が規定されていればよい。規定されていないものについては、所定の取り扱いを行ってよい。
実施例１と同様に、各ステージのプロセスでは、更に比較演算、集約演算に従い、各計算ノードのプロセッサによりデータ処理が実行されてもよい。
各ステージのプロセスでは、複数の異なるデータセットからのレコードを並行して、もしくは逐次的に入力してもよい。
以上、実施例１及び２に係るジョブ実行モデルを説明した。ジョブ実行モデルは、それらに限定されない。
実施例１及び２に係るジョブ実行モデルについての共通点は、例えば以下の通りである。
Hadoopをはじめとする並列データ処理システムでは、一般に、記憶空間におけるデータ群は構造化されない。これに対して、実施例１および実施例２によれば、ストレージ（例えば、ファイルシステム）において、複数の第１のレコードで構成される第１のデータセット（例えば、入力データセット＃１）は、複数の第２のレコードで構成される第２のデータセット（例えば、入力データセット＃２）に対して関連付けられる。具体的には、例えば、第１のデータセットは、第２のデータセットのうちにデータ処理に要する第２のレコードを特定するための索引である。即ち、第１のデータセットは構造化されているが、第２のデータセットは構造化されていなくてもよい。第１のデータセットが構造化されていることにより、それに関連付けられた第２のデータセットは、仮にそれが構造化されていない場合であっても、第２のデータセットのうちにデータ処理に要する第２のレコードを特定してアクセスすることが可能となる。また、別の例を挙げるとすると、第１のデータセットと第２のデータセットはそれぞれのレコードを結合することできる関係である。即ち、第１のデータセットは構造化されておらず、第２のデータセットが構造化されていてもよい。第２のデータセットが構造化されていることにより、それに関連付けられた第１のデータセットのレコードに対応する第２のレコードを選択的に抽出することが可能となる。
この際、実施例１および実施例２によれば、第１のデータセットの書式に関する情報（例えば書式＃１）や、第２のデータセットの書式に関する情報（例えば書式＃２）や、第１のレコードに基づいて第２のレコードを参照する方式に関する情報（例えば参照方式）をはじめとする情報がアプリケーションにより用意される。当該情報は、例えばプログラムコードである。当該情報は、個々のアプリケーションとは独立して別のプログラム（例えば後述するシステムモジュール等）が有してもよい。しかしながら、アプリケーションが個々にこれを用意することができることにも利点が認められる。例えば、データベース管理システム（ＤＢＭＳ；Database Management System）は、ストレージ空間におけるデータ群（テーブル）をリレーショナルモデルに基づき管理する。書式や参照方式等のカタログ情報は、アプリケーションとは独立に管理される。この場合、例えば、レコードのカラムの型は既にＤＢＭＳが用意している型（例えば、整数や文字列等）から選択することとなるが、アプリケーションによってはＤＢＭＳが既に備えている型以外の型を以ってカラムを解釈することが望ましい場合がある。アプリケーションが個々に書式や参照方式等の情報を用意することができることは、データ処理システムとしての柔軟性の観点から利点が認められる場合がある。また、ＤＢＭＳにおいては、一般に、データ集合（テーブル）における全てのレコードは、与えられたカタログ情報に厳密に従っていることを要請される。しかしながら、あるデータ集合に置いて特定の日時以降から記録されるレコードにカラムを追加するような場合にも、原則として、データ集合（テーブル）の全てのレコードにカラムを追加する必要がある。即ち、当該カラムを要しない特定の日付以前のレコードについても、（例えば空の）カラムを追加する必要がある。通常、このような操作には、データ集合（テーブル）を再構成や再編成する処理を要し、データ集合（テーブル）が大規模になるとその処理に係る時間は無視できない。他方で、アプリケーションが書式や参照方式等の情報を用意することができるとすると、アプリケーションによって特定の日付以前のレコードと特定の日付以降のレコードで異なる書式や参照方式等の情報を用意することができる。即ち、データ集合自体を変更することなく、アプリケーションを変更することによって、レコード書式の変更に柔軟にデータ処理を対応させることが可能となり、利点が認められる場合がある。
また、実施例１および実施例２によれば、アプリケーションの規定したデータ処理のジョブ情報に基づき、アプリケーションとは別のプログラム（例えばシステムモジュール）が第１のデータセットから第１のレコードを読み込んで、当該レコードを当該ジョブ情報に基づき解釈し、それに基づきスレッドを生成して実行し、各スレッドにおいて更に第２のデータセットから第２のレコードを読み込み、読み込んだレコードに対してジョブ情報に規定された演算を実行することが可能となる。計算ノードはアプリケーションの規定したジョブ情報に従って、データ処理に係るデータ読み込みを並行して実行することができるようになる。これにより、データ読み込みのスループットが向上し、故に、データ処理に係る時間が短縮されることが期待される。
以下、実施例１及び２を詳細に説明する。実施例２は実施例１を拡張したものであり、実施例１に関して説明した部分は、改めて説明せずとも、実施例２に適用される。
図２Ａは、実施例１に係る計算ノードの構成を示す。図２Ａは、図１Ａに示すジョブ実行モデルに従いデータ処理を行う計算ノードの構成を示す。
計算ノード１００は、パーソナルコンピュータ、ワークステーション、サーバ又はメインフレームなどの計算機であってよい。また、計算ノード１００は、計算機に装着して用いられる画像処理装置（ＧＰＵ；Graphical Processing Unit）などを具備する補助演算機器（例えば、画像処理装置（ＧＰＵ）カード）であってもよいし、計算機や補助演算機器において仮想化ソフトウェアや仮想化ハードウェア等によって構成された仮想的な計算機であってもよい。
計算ノード１００は、通信インタフェースと、記憶装置と、それらに接続された演算装置とを有する。通信インタフェースとしては、例えば、ＮＩＣ（Network interface card）１０２と、ＨＢＡ（host bus adapter）１０３とがある。記憶装置としては、例えば、ストレージ１０４と、メモリ１０５とがある。演算装置は、例えばプロセッサ（ＣＰＵ；Central Processing Unit）１０１である。制御装置は、プロセッサ以外に、専用の処理（例えば暗号化又は復号化）を行うハードウェア回路を含んでもよい。プロセッサ１０１、ＮＩＣ１０２、ＨＢＡ１０３、及びメモリ１０５は、内部バス１０６を介して接続されている。ストレージ１０４は、ＨＢＡ１０３に接続されている。
プロセッサ１０１は、コンピュータプログラムを実行する。ＮＩＣ１０２は、ネットワーク２００と計算ノード１００とを接続する。ネットワーク２００を介した通信のプロトコルとしては、例えば、ＴＣＰ／ＩＰ（Transmission Control Protocol／Internet Protocol）が採用されてよい。ＨＢＡ１０３は、ストレージ１０４への入出力を仲介する。
ストレージ１０４は、１つ以上の不揮発性の記憶媒体を含む。不揮発性の記憶媒体は、例えば、磁気ディスク或いはフラッシュメモリである。ストレージ１０４は、複数の不揮発性の記憶媒体を備え、更に当該不揮発性の記憶媒体から記憶空間を構成するＲＡＩＤ（Redundant ARRAY of Independent Disks）コントローラを備えてもよい。
メモリ１０５は、例えば、揮発性の記憶媒体（例えばＤＲＡＭ（Dynamic Random Access Memory））であり、ＣＰＵ１０１によって実行されるプログラムと、プログラムが使用するデータ等を記憶する。
メモリ１０５は、アプリケーションプログラム（以下、アプリケーション）１１０、システムモジュール１２０、プロセスマネージャ１３１、タスクマネージャ１３２、スレッドマネージャ１３３、データ読み書き器１４０、ネットワークマネージャ１５０、ストレージマネージャ１６０、及びＯＳ（Operating System）１７０を格納する。なお、システムモジュール１２０、プロセスマネージャ１３１、タスクマネージャ１３２、スレッドマネージャ１３３、データ読み書き器１４０、ネットワークマネージャ１５０、ストレージマネージャ１６０（以下、個々のプログラムモジュールを総じてモジュール群と称する）はアプリケーション１１０と静的もしくは動的にリンクして実行されるライブライモジュールであってもよく、この場合、アプリケーション１１０からの指示もしくはモジュール群におけるプログラムモジュール間の相互の指示はモジュール群が開示する呼び出しインタフェースによる。また、モジュール群はアプリケーション１１０とは別個に動作するプログラムであってもよく、この場合、アプリケーション１１０からの指示はプロセス間通信や共有メモリ等の手段による。
アプリケーション１１０は、ストレージ１０４に格納された入力データセットを読み込んで所定の処理を実行し、出力データセットを書き込むジョブを規定するプログラムであり、計算ノードはアプリケーション１１０を実行することによって当該ジョブを実行する。アプリケーション１１０は、当該ジョブを規定する情報（以下、ジョブ情報とする）として、例えば、マップ演算１１０ａと、リデュース演算１１０ｂと、分割演算１１０ｃと、書式１１０ｅ（書式＃１）と、書式１１０ｆ（書式＃２）と、条件１１０ｇとを含む。
マップ演算１１０ａは、読み込んだレコードに対して適用される処理を規定するプログラムコードであり、例えば、読み込んだレコードからキーとバリューのペアからなる結果レコードを生成するものである。分割演算１１０ｃは、マップ演算を実行したのち、その実行結果を受け渡すリデュースプロセスを決定する際に実行されるプログラムコードであり、例えば、分割演算はマップ演算の結果レコードが含むキーに対するハッシュ演算などを含んでよい。書式１１０ｅ（書式＃１）は、入力データセット＃１のレコードを解釈するための書式を規定するプログラムコードである。書式１１０ｆ（書式＃２）は、入力データセット＃２のレコードを解釈するための書式を規定するプログラムコードである。参照方式１１０ｈは、入力データセット＃１のレコードの参照に従い、入力データセット＃２のレコードを取得する方式を規定するプログラムコードである。条件１１０ｇは、入力データセット＃１及び／又は入力データセット＃２に格納されたレコードのうちマップ演算の対象とするべきレコードの要件を規定するプログラムコードである。なお、アプリケーション１１０は、上述のプログラムコードを全て規定しなくてもよい。規定されていないものについては、所定の取り扱いを行ってよい。例えば、リデュース演算を備えない場合は、リデュースプロセスを実行されず、マッププロセスにおけるマップ演算の実行結果レコードがそのまま出力データセットに格納される。更に、アプリケーション１１０は比較演算（図示せず）、集約演算（図示せず）を規定してもよい。
システムモジュール１２０は、アプリケーション１１０とは独立しているもののアプリケーション１１０と連携して動作するプログラムモジュールであり、アプリケーション１１０からのジョブを実行する指示を受けて、アプリケーション１１０に規定されたジョブ情報に従いジョブを実行する。システムモジュール１２０は、アプリケーション１１０からジョブ実行の指示を受け付けるインタフェース部（図示せず）と、マップ関数１２１と、リデュース関数１２２と、スーパバイザ関数１２３とを含むエグゼキューション部とを有する。マップ関数１２１は、マッププロセスにおいて実行されるプログラムコード（関数）である。リデュース関数１２２は、リデュースプロセスにおいて実行されるプログラムコード（関数）である。スーパバイザ関数１２３は、スーパバイザプロセス（統括スーパバイザプロセスを含む）において実行されるプログラムコードである。システムモジュール１２０は、インタフェース部においてアプリケーション１１０からのジョブ実行の指示を受け付け、エグゼキューション部においてジョブを実行するのに要するプロセスを生成し、プロセスにおいて各関数を実行し、各関数を実行することによって、更にタスクとスレッドを生成して実行する。
システムモジュール１２０の詳細を述べる。各計算ノードのＣＰＵ１０１は、システムモジュール１２０によってスーパバイザプロセスを生成し、当該スーパバイザプロセスにおいてスーパバイザ関数１２３を実行する。上述のスーパバイザプロセスの生成は、事前に例えば計算ノードを起動することにより自動的に行われてもよいし、ジョブの実行を開始してから必要に応じて行われてもよい。ジョブを実行する複数の計算ノード１００のスーパバイザプロセスのいずれかのスーパバイザプロセスは、複数の計算ノード１００を統括する処理も行う。なお、複数の計算ノード１００を統括するスーパバイザプロセスを統括スーパバイザプロセスという。なお、統括スーパバイザプロセスは、固定的にいずれかの計算ノード１００のスーパバイザプロセスとしてもよく、複数の計算ノード１００から選択した計算ノード１００のスーパバイザプロセスとしてもよい。なお、計算ノード１００以外の計算機に、統括スーパバイザプロセスを備えるようにしてもよい。
統括スーパバイザプロセスは、ジョブの実行に参加する全計算ノード１００にアプリケーション１１０のコードを配布して、各スーパバイザプロセスに対してプロセスの割当てを行う。各ノードのスーパバイザプロセスは、統括スーパバイザプロセスの指示に基づいて、プロセスを生成する。統括スーパバイザプロセスは、ジョブ実行に参加する全計算ノードのスーパバイザプロセスの状態を把握する処理を行う。また、各スーパバイザプロセスは、自身の計算ノードにおけるジョブ実行に関わるプロセスの実行状態を把握する処理を行う。
プロセスマネージャ１３１は、システムモジュールからの指示に基づき、プロセスを実行するのに要するメモリ資源を管理する。即ち、プロセスの生成、削除ならびに実行状態等を管理する。タスクマネージャ１３２は、システムモジュールからの指示に基づき、タスクを実行するのに要するメモリ資源を管理する。即ち、タスクの生成、削除ならびに実行状態等を管理する。スレッドマネージャ１３３は、システムモジュールからの指示に基づき、スレッドを実行するのに要するメモリ資源を管理する。即ち、スレッドの生成、削除ならびに実行状態等を管理する。
データ読み書き器１４０は、システムモジュール１２０からの指示に基づき、ストレージへのデータの読み書きを行う。データ読み書き器１４０は例えばファイルシステムであってよい。例えば、データ読み書き器１４０は、指示されたデータ読み書きを行うのに自身の計算ノード１００のストレージ１０４に対するデータ読み書きを要する場合には、ストレージマネージャ１６０により、ストレージ１０４に対してデータ読み書きを実行させ、ネットワーク２００を介して接続された他の計算ノード１００のストレージ１０４に対するデータ読み書きを要する場合には、ネットワークマネージャ１５０により、ネットワーク２００を介して接続された他の計算ノード１００のストレージ１０４に対してデータ読み書きを実行させる。この際、データ読み書き器１４０は、メモリ１０５のメモリ資源を用いて、読み書きするデータを一時的にキャッシュさせてもよい。
ネットワークマネージャ１５０は、ネットワークを介して接続された装置（例えば、他の計算ノード１００等）とのデータ通信を制御する。ストレージマネージャ１６０は、自身の計算ノード１００のストレージ１０４との入出力を制御する。ＯＳ１７０は、ＮＩＣ１０２、ＨＢＡ１０３、ストレージ１０４等の装置を管理するほか、計算ノード１１０の全体を管理する。
本明細書においては、プログラムやその一部の名称（例えば、アプリケーション、システムモジュール、プロセス、タスク、スレッド）を主語として発明の実施例ならび変形例を説明する場合がある。この場合においては、プログラムやその一部は、計算ノード１００が具備する演算装置（例えばプロセッサ１０１）によって実行されることによって、定められた処理を、適宜に記憶装置（例えばメモリ１０５やストレージ１０４）及び／又は通信インタフェース（例えばＮＩＣ１０２やＨＢＡ１０３）を用いて行うものであるため、発明の実施例ならび変形例を説明する際の主語が演算装置、プロセッサ１０１もしくは計算ノード１００であるとして解釈してもよい。また、プログラムやその一部は、ハードウェアで行われても良く、その場合には、発明の実施例ならび変形例を説明する際の主語がプロセッサ１０１に代えて又は加えてそのハードウェアであるとして解釈してもよい。システムモジュール１２０、プロセスマネージャ１３１、タスクマネージャ１３２、スレッドマネージャ１３３、データ読み書き器１４０、ネットワークマネージャ１５０、ストレージマネージャ１６０等のようなコンピュータプログラムは、プログラムソースから計算ノード１００にインストールされてよい。プログラムソースは、例えば、計算ノード１００が読み取り可能な記憶メディアであってもよいし、計算ノード１００に通信可能に接続されている計算機であってもよい。
計算ノード１００は、性能や可用性の観点から、ＣＰＵ１０１、ＮＩＣ１０２、ＨＢＡ１０３の少なくとも１つの要素を複数備えていてもよい。また、計算ノード１００は、入力デバイス（例えば、キーボード及びポインティングデバイス）（図示しない）と表示デバイス（例えば液晶ディスプレイ）（図示しない）とを有してよい。入力デバイスと表示デバイスは一体になっていてもよい。
図２Ｂは、実施例２に係る計算ノードの構成を示す。図２Ｂは、図１Ｂに示すジョブ実行モデルに従いデータ処理を行う計算ノードの構成を示す。
アプリケーション１１０は、ジョブ情報として、例えば、１以上のステージ演算１１０ｊと、１以上の分割演算１１０ｋと、１以上の書式１１０ｍと、1以上の条件１１０ｎと、1以上の参照方式１１０ｏと、1以上のビルド方式１１０ｐとを含む。
ステージ演算１１０ｊは、ジョブ実行モデルにおける各ステージのプロセスにおいて入力されたレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。図１Ｂのジョブ実行モデルの場合には、ステージ演算＃１〜＃４の４つのステージ演算が含まれる。分割演算１１０ｋは、実行結果レコードを受け渡す後続のステージのプロセスを決定する際に実行されるプログラムコードである。例えば、分割演算は入力に対するハッシュ演算などを含んでよい。書式１１０ｍは、各入力データセットのレコードを解釈するための書式を規定するプログラムコードである。図１Ｂに示すジョブ実行モデルを実行するアプリケーション１１０には、入力データセット＃１〜＃６までのそれぞれに対応する書式１１０ｍが格納されている。条件１１０ｎは、ステージ演算の対象とするべきレコードの要件を規定するプログラムコードである。参照方式１１０ｏは、ある入力データセットのレコードの参照に従い、参照先の入力データセットからレコードを取得する方式を規定するプログラムコードである。ビルド方式１１０ｐは、実行結果のレコードの作成方法を示す情報である。なお、アプリケーション１１０は、上述のプログラムコードを全て規定しなくてもよい。規定されていないものについては、所定の取り扱いを行ってよい。更に、アプリケーション１１０は比較演算（図示せず）、集約演算（図示せず）を規定してもよい。
システムモジュール１２０は、一般化ステージ関数１２４と、スーパバイザ関数１２２とを含む。一般化ステージ関数１２４は、図１Ｂに示す各プロセスにおいて実行されるプログラムコード（関数）である。
図３Ａは、実施例に係る計算機システムの第１の構成例を示す。図３Ｂは、実施例に係る計算機システムの第２の構成例を示す。
計算機システムは、図３Ａに示すように、ＮＩＣ１０２を介してネットワーク２００（例えば、Ethernet（登録商標）によるローカルエリアネットワーク）によって接続された複数の計算ノード１００から構成されてもよい。また、計算機システムは、図３Ｂに示すように、ＮＩＣ１０２を介してネットワーク２００によって接続され、更に、ＨＢＡ１０３を介してネットワーク３００（例えば、FibreChannelによるストレージエリアネットワーク）によって１以上のストレージ４００と接続される複数の計算ノード１００から構成されてもよい。また、ストレージ４００は、ネットワーク３００ではなくネットワーク２００に接続され、共有ファイルアクセス用の通信プロトコル（ＮＦＳやＣＩＦＳ）によって入出力を行うものであってもよい。
ストレージ４００は、１つ以上の不揮発性の記憶媒体を含む。不揮発性の記憶媒体は、例えば、磁気ディスク或いはフラッシュメモリである。ストレージ１０４は、複数の不揮発性の記憶媒体を備え、更に当該不揮発性の記憶媒体から記憶空間を構成するＲＡＩＤ（Redundant ARRAY of Independent Disks）コントローラを備えてもよい。ストレージ４００のストレージ資源の全部もしくは一部は、計算ノード１００が含むストレージ１０４と同様に扱ってよい。
図４Ａは、実施例１に係るマップタスク実行処理の流れを示す。
このマップタスク実行処理は、図１Ａに示すジョブ実行モデルにおけるマッププロセスにおいて実行されるマップタスクにおいて実行される処理を示す。
計算ノード１００のプロセッサ１０１が、入力データセット＃１のレコードを読み込んで処理を実行するための１つのスレッドＳＬ１を実行することにより、ステップＳ１０〜ステップＳ１５の処理を実行する。この処理は、プロセッサ１０１が、主に、マップ関数１２１を実行することにより実現される。
Ｓ１０で、プロセッサ１０１は、入力データセット＃１から１つのレコードを取得する。ここで、入力データセット＃１は、自身の計算ノード１００のストレージ１０４に格納されている場合もあれば、他の計算ノード１００のストレージ１０４に格納されている場合もある。なお、入力データセット＃１からレコードを取得するレコード取得処理については、後述する。
Ｓ１１で、プロセッサ１０１は、書式１１０ｅ（書式＃１）に基づいて、取得したレコードに含まれる各項目の内容を解釈し、取得したレコードに対して、条件１１０ｇに含まれる入力データセット＃１のレコードに対する条件を適用することにより、当該レコードが条件を満足するか否かを判定し、必要であれば、Ｓ１２に進む一方、必要でなければ、図示しないがＳ１５に進む。Ｓ１１では条件１１０ｇの一部が適用されてもよい。条件１１０ｇが規定されていない場合はそのままＳ１２に進んでもよい。
Ｓ１２で、プロセッサ１０１は、取得したレコードに、入力データセット＃２への参照があるか否かを判断する。この判断の結果が肯定的であれば、Ｓ１３を行う一方、この判断の結果が否定的であれば、Ｓ１５を行う。
Ｓ１３で、プロセッサ１０１は、取得したレコードの入力データセット＃２への１つの参照について、入力データセット＃２からレコードを取得して処理を行うためのスレッドＳＬ２を生成する。
Ｓ１４で、プロセッサ１０１は、取得したレコードに、更に未処理の入力データセット＃２への参照があるか否かを判断する。この判断の結果が肯定的であれば、Ｓ１３を行う一方、この判断の結果が否定的であれば、Ｓ１５を行う。これにより、取得したレコードに、入力データセット＃２への参照が複数あれば、Ｓ１３によって、参照の数に応じたスレッドＳＬ２が生成されることとなる。なお、スレッドの生成に必要な資源が不足する場合には、スレッドＳＬ２の生成を一時的に保留してもよい。なお、この際、１つの参照の毎に１つのスレッドＳＬ２を生成してもよいし、複数（例えば所定数）の参照の毎に１つのスレッドＳＬ２を生成してもよい。
Ｓ１５で、プロセッサ１０１は、入力データセット＃１に更に他のレコードがあるか否かを判断する。この判断の結果が肯定的であれば、Ｓ１０を行う一方、この判断の結果が否定的であれば、この処理を終了して、この処理を実行したスレッドＳＬ１を停止する。
一方、Ｓ１３でスレッドＳＬ１により生成されたスレッドＳＬ２は、ＣＰＵ１０１によって実行される。プロセッサ１０１が、スレッドＳＬ２を実行することにより、ステップＳ１６〜ステップＳ１９の処理を実行する。なお、本実施例では、プロセッサ１０１は、複数のスレッド（スレッドＳＬ１、スレッドＳＬ２等）を並行して実行することができる。計算ノード１００は複数のプロセッサ１０１を備えており、あるプロセッサ１０１で生成したスレッドＳＬ２が別のプロセッサ１０１で実行されてもよい。なお、並行実行可能なスレッドの数は、計算ノード１００の資源等によって制限がある。
Ｓ１６で、プロセッサ１０１は、参照方法１１０ｈ及びスレッドＳＬ１で取得された参照を用いて、入力データセット＃２から１つのレコードを取得する。
Ｓ１７で、プロセッサ１０１は、書式１１０ｆ（書式＃２）に基づいて、取得したレコードに含まれる各項目の内容を解釈し、取得したレコードに対して、条件１１０ｇに含まれる入力データセット＃２のレコードに対する条件を適用することにより、当該レコードが必要であるか否かを判定し、必要であれば、Ｓ１８に進む一方、必要でなければ、図示しないがＳ１９に進む。Ｓ１７では条件１１０ｇの一部が適用されてもよい。条件１１０ｇが規定されていない場合はそのままＳ１８に進んでもよい。
Ｓ１８で、プロセッサ１０１は、取得したレコードを、主記憶１０５の演算キュー１８０に格納する。
Ｓ１９で、プロセッサ１０１は、入力データセット＃２の参照で示される範囲に更に他のレコードがあるか否かを判断する。この判断の結果が肯定的であれば、Ｓ１６を行う一方、この判断の結果が否定的であれば、この処理を終了して、この処理を実行したスレッドＳＬ２を終了させる。
また、プロセッサ１０１は、Ｓ２０で、演算キュー１８０から１つのレコードを取得し、当該レコードに対して、マップ演算１１０ａを適用することにより、レコードに対して所定の処理を実行し、その実行結果を出力する。この際、プロセッサ１０１はＳ２０をＳＬ２とは別のスレッドにおいて実行してもよい。Ｓ２０を実行するスレッドは１つであってもよく、複数であってもよい。演算キュー１８０から一括して複数のレコードを取得してマップ演算１１０ａを適用してもよい。プロセッサ１０１はスレッドＳＬ２においてＳ１８を実行する代わりに、スレッドＳＬ２においてＳ１７を実行した後にＳ２０を実行してＳ１７の結果のレコードに対してマップ演算を適用してもよい。ここで、実行結果を出力する方法としては、例えば、実行結果を主記憶１０５に格納するようにしても良く、また、実行結果を後続の処理を実行するリデュースプロセスに渡すようにしてもよい。
なお、図４Ａでは、入力データセット＃１からレコードを読み込み、その処理を行うスレッドＳＬ１と、入力データセット＃２からレコードを読み込み、その処理を行うスレッドＳＬ２を別に設けているが、スレッドＳＬ１がスレッドＳＬ２を生成せずにそのままＳ１６からＳ１９もしくはＳ２０までに相当する処理を行ってもよい。また、所定の数のスレッドＳＬ１を生成して、当該スレッドＳＬ１によって入力データセット＃１からレコードを読み込み、その処理を行ってもよい。更には、Ｓ１５で更にレコードがあると判断した際に、新たにＳＬ１を生成して、Ｓ１０からＳ１５に相当する処理を行ってもよい。
図４Ｂは、実施例２に係るタスク実行処理の流れを示す。
このタスク実行処理は、図１Ｂに示すジョブ実行モデルにおけるステージプロセスにおいて実行されるタスクにおいて実行される処理を示す。
計算ノード１００のプロセッサ１０１が、入力データセット＃ｄ１のレコードを読み込んで処理を実行するための１つのスレッドＳＬｄ１を実行することにより、ステップＳ２１〜ステップＳ２６の処理を実行する。ここで、図１Ｂのステージ＃１プロセスを実行するタスク実行処理においては、入力データセット＃ｄ１は、入力データセット＃１であり、入力データセット＃ｄ２は、入力データセット＃２である。また、図１Ｂのステージ＃４プロセスを実行するタスク実行処理においては、入力データセット＃ｄ１は、入力データセット＃５であり、入力データセット＃ｄ２は、入力データセット＃６である。
Ｓ２１で、プロセッサ１０１は、入力データセット＃ｄ１から１つのレコードを取得する。ここで、入力データセット＃ｄ１は、自身の計算ノード１００のストレージ１０４に格納されている場合もあれば、他の計算ノード１００のストレージ１０４に格納されている場合もある。なお、入力データセット＃ｄ１からレコードを取得するレコード取得処理については、後述する。
Ｓ２２で、プロセッサ１０１は、入力データセット＃ｄ１のレコードに対応する書式１１０ｍに基づいて、取得したレコードに含まれる各項目の内容を解釈し、取得したレコードに対して、条件１１０ｎに含まれる入力データセット＃ｄ１のレコードに対する条件を適用することにより、当該レコードが条件を満足するか否かを判定し、必要であれば、Ｓ２３に進む一方、必要でなければ、図示しないがＳ２６に進む。Ｓ２２では条件１１０ｎの一部が適用されてもよい。条件１１０ｎが規定されていない場合はそのままＳ２３に進んでもよい。
Ｓ２３で、プロセッサ１０１は、取得したレコードに、入力データセット＃ｄ２への参照があるか否かを判断する。この判断の結果が肯定的であれば、Ｓ２４を行う一方、この判断の結果が否定的であれば、Ｓ２６を行う。
Ｓ２４で、プロセッサ１０１は、取得したレコードの入力データセット＃ｄ２への１つの参照について、入力データセット＃ｄ２からレコードを取得して処理を行うためのスレッドＳＬｄ２を生成する。
Ｓ２５で、プロセッサ１０１は、取得したレコードに、更に入力データセット＃ｄ２への参照があるか否かを判断する。この判断の結果が肯定的であれば、Ｓ２４を行う一方、この判断の結果が否定的であれば、Ｓ２６を行う。これにより、取得したレコードに、入力データセット＃ｄ２への参照が複数あれば、Ｓ２４によって、参照の数に応じたスレッドＳＬｄ２が生成されることとなる。なお、スレッドの生成に必要な資源が不足する場合には、スレッドＳＬｄ２の生成を一時的に保留してもよい。なお、この際、１つの参照の毎に１つのスレッドＳＬｄ２を生成してもよいし、複数（例えば所定数）の参照の毎に１つのスレッドＳＬｄ２を生成してもよい。
Ｓ２６で、プロセッサ１０１は、入力データセット＃ｄ１に更に他のレコードがあるか否かを判断する。この判断の結果が肯定的であれば、Ｓ２１を行う一方、この判断の結果が否定的であれば、この処理を終了して、この処理を実行したスレッドＳＬｄ１を終了させる。
一方、Ｓ２４及び後述するＳ３１でスレッドＳＬｄｋ-1から生成されたスレッドＳＬｄｋは、プロセッサ１０１によって実行される。ここにｋは２以上の自然数を表し、例えばｋ＝２の場合にはＳＬｄｋ−１はＳＬｄ１を、ＳＬｄｋはＳＬｄ２を、ＳＬｄｋ＋１はＳＬｄ３を表すものとする。プロセッサ１０１が、スレッドＳＬｄｋを実行することにより、ステップＳ２７〜ステップＳ３５の処理を実行する。なお、本実施例では、プロセッサ１０１は、複数のスレッド（スレッドＳＬｄ１、スレッドＳＬｄｋ等）を並行して実行することができる。計算ノード１００は複数のプロセッサ１０１を備えており、あるプロセッサ１０１で生成したスレッドが別のプロセッサ１０１で実行されてもよい。なお、並行実行可能なスレッドの数は、計算ノード１００の資源等によって制限がある。
Ｓ２７で、プロセッサ１０１は、入力データセット＃ＳＬｄｋ-1のレコードの参照及びこの参照を用いて入力データセット＃ＳＬｄｋを参照するための参照方式１１０ｏに基づいて、入力データセット＃ＳＬｄｋのレコードを取得する。
Ｓ２８で、プロセッサ１０１は、書式１１０ｆ（書式＃ｄｋ）に基づいて、取得したレコードに含まれる各項目の内容を解釈し、取得したレコードに対して、条件１１０ｎに含まれる入力データセット＃ｄｋのレコードに対する条件を適用することにより、当該レコードが必要であるか否かを判定し、必要であれば、Ｓ２９に進む一方、必要でなければ、図示しないがＳ３５に進む。Ｓ２８では条件１１０ｎの一部が適用されてもよい。条件１１０ｎが規定されていない場合はそのままＳ２９に進んでもよい。
Ｓ２９で、プロセッサ１０１は、更に入力データセット＃ｄｋ＋１へのアクセスを要するか否かを判断する。この判断の結果が肯定的であれば、Ｓ３０を行う一方、この判断の結果が否定的であれば、Ｓ３３に進む。例えば、図１Ｂのステージ＃１プロセスでは、入力レコード＃１からレコードを取得し、当該レコード中の参照に従い入力レコード＃２からレコードを取得し、更に当該レコード中の参照に従い入力レコード＃３からレコードを取得し、更に当該レコード中の参照に従い入力レコード＃４からレコードを取得する必要がある。よって、ｋ＝２で生成されたスレッドＳＬｄｋ（ＳＬｄ２）で実行されるＳ２９では、入力データセット＃３へのアクセスを更に要するため、この判断は肯定的であり、ｋ＝３で生成されたスレッドＳＬｄｋ（ＳＬｄ３）で実行されるＳ２９では、入力データセット＃４へのアクセスを更に要するため、この判断は肯定的であり、ｋ＝４で生成されたスレッドＳＬｄｋ（ＳＬｄ４）で実行されるＳ２９では、更なる入力データセットへのアクセスを要しないため、この判断は否定的となる。
Ｓ３０で、プロセッサ１０１は、取得したレコードに、入力データセット＃ｄｋ＋１への参照があるか否かを判断する。この判断の結果が肯定的であれば、Ｓ３１を行う一方、この判断の結果が否定的であれば、Ｓ３５を行う。
Ｓ３１で、プロセッサ１０１は、取得したレコードの入力データセット＃ｄｋ＋１への１つの参照について、入力データセット＃ｄｋ＋１からレコードを取得して処理を行うためのスレッドＳＬｄｋ＋１を生成する。
Ｓ３２で、プロセッサ１０１は、取得したレコードに、更に入力データセット＃ｄｋ＋１への参照があるか否かを判断する。この判断の結果が肯定的であれば、Ｓ３１を行う一方、この判断の結果が否定的であれば、Ｓ３５を行う。これにより、取得したレコードに、入力データセット＃ｄｋ＋１への参照が複数あれば、Ｓ３１によって、参照の数に応じたスレッドＳＬｄｋ＋１が生成されることとなる。なお、スレッドの生成に必要な資源が不足する場合には、スレッドＳＬｄｋ＋１の生成を一時的に保留してもよい。なお、この際、１つの参照の毎に１つのスレッドＳＬｄｋ＋１を生成してもよいし、複数（例えば所定数）の参照の毎に１つのスレッドＳＬｄｋ＋１を生成してもよい。
Ｓ３３で、プロセッサｓ１０１は、取得したレコードと、ビルド方式１１０ｐとに基づいて、所定の形式のレコードをビルド（生成）する。
Ｓ３４で、プロセッサ１０１は、ビルドしたレコードに対して、ステージ演算１１０ｊを適用することにより、所定の処理を実行し、その実行結果を出力する。この際、プロセッサ１０１はスレッドＳＬｄｋにおいてＳ３３を実行した後にＳ３４を実行する代わりに、一旦、ビルドしたレコードを、主記憶１０５の演算キューに格納し、演算キューから１つのレコードを取得し、Ｓ３４を実行して当該レコードに対して、ステージ演算１１０ｊを適用することにより、レコードに対して所定の処理を実行し、その実行結果を出力してもよい。この際、プロセッサ１０１はＳ３４をＳＬｄｋとは別のスレッドにおいて実行してもよい。Ｓ３４を実行するスレッドは１つであってもよく、複数であってもよい。演算キューから一括して複数のレコードを取得してステージ演算１１０ｊを適用してもよい。
Ｓ３５で、ＣＰＵ１０１は、入力データセット＃ｄｋの参照で示される範囲に更に他のレコードがあるか否かを判断する。この判断の結果が肯定的であれば、Ｓ２７を行う一方、この判断の結果が否定的であれば、この処理を終了して、この処理を実行したスレッドＳＬｄｋを中止する。
なお、図４Ｂでは、入力データセット＃ｄｋ−１からレコードを読み込み、その処理を行うスレッドＳＬｄｋ−１と、入力データセット＃ｄｋからレコードを読み込み、その処理を行うスレッドＳＬｄｋを別に設けているが、スレッドＳＬｄｋ−１がスレッドＳＬｄｋを生成せずにそのままＳ２７からＳ３５までに相当する処理を行ってもよい。また、所定の数のスレッドＳＬｄ１を生成して、当該スレッドＳＬｄ１によって入力データセット＃１からレコードを読み込み、その処理を行ってもよい。更には、Ｓ２６もしくはＳ３５で更にレコードがあると判断した際に、新たにＳＬｄ１もしくはＳＬｄｋを生成して、Ｓ２１からＳ２６までに相当する処理もしくはＳ２７からＳ３５までに相当する処理を行ってもよい。
図５Ａは、実施例１に係る入力データ及び入力データに対する処理を説明するための図である。
入力データセット＃２は、「Ｄａｔｅ ＆ ｔｉｍｅ」、「Ｕｓｅｒ」、「Ｐｒｏｄｕｃｔ」、「Ｃｏｍｍｅｎｔ」を含む１以上のレコードを格納する。
入力データセット＃１は、「Ｐｒｏｄｕｃｔ」と、「Ｒｅｆｅｒｅｎｃｅ」との項目を有する１以上のレコードが、年月ごとにまとめられて管理されている。即ち、入力データセット＃１は年月によって分割されている。例えば、スーパバイザプロセスは、このまとめられた部分（分割部分）の毎に、マップタスク等を割り当てることにより、並列データ処理を行う。この際、１つのマップタスクが複数の分割部分を担当してもよい。
「Ｐｒｏｄｕｃｔ」には、入力データセット＃２におけるレコードの検索に使用する鍵となる項目（「Ｐｒｏｄｕｃｔ」）の値が格納される。「Ｒｅｆｅｒｅｎｃｅ」には、入力データセット＃２における当該レコードに対応する年月のレコードであって、当該レコード中の「Ｐｒｏｄｕｃｔ」の値と同一の値を格納するレコード（参照先レコード）の物理的な格納位置を示す参照が格納される。なお、入力データセット＃２に、複数の参照先レコードがある場合には、「Ｒｅｆｅｒｅｎｃｅ」には、複数の参照先レコードへの参照が格納される。なお、入力レコード＃２はある鍵によってレコードを検索可能な構造（例えば、Ｂ木）を有してもよく、当該鍵の値を「Ｒｅｆｅｒｅｎｃｅ」に格納する参照としてもよい。ある１つの参照に複数のレコードが対応することがあってもよい。
入力データセット＃１のレコードの書式は、書式＃１に記述されている。
また、入力データセット＃２のレコードの書式は、書式＃２に記述されている。また、入力データセット＃１の「Ｒｅｆｅｒｅｎｃｅ」を用いて、入力データセット＃２のレコードを参照する方法については、参照方式＃１に記述されている。
図１Ａに示すジョブ実行モデルにおけるマッププロセスにおいては、プロセッサ１０１はマップ関数１２１を実行することにより、入力データセット＃１のレコードを読み込み、書式＃１により、レコードにおけるＰｒｏｄｕｃｔと、Ｒｅｆｅｒｅｎｃｅとを把握する。そして、マップ関数１２１は、Ｐｒｏｄｕｃｔの値に基づいて、所定の条件に合致するか否かを判断し、条件を満たすレコードのＲｅｆｅｒｅｎｃｅを特定する。そして、プロセッサ１０１はマップ関数１２１を実行することにより、参照方式＃１と、Ｒｅｆｅｒｅｎｃｅとに基づいて、入力データセット＃２のレコードを取得する。
図５Ｂは、実施例１に係る書式及び参照を説明するための図である。
書式＃１は、入力データセット＃１のレコードの書式に関する情報であり、本実施例では、入力データセット＃１のレコードを解釈する手続きが記述されている。書式＃１には、入力レコード（すなわち、入力データセット＃１のレコード）をバイナリ形式で解釈し、入力レコードの各カラムを、Ｔｅｘｔ型、Ｌｏｎｇ型、Ｉｎｔ型、Ｉｎｔ型として解釈すること、第1（０）のカラムを検索鍵とすることが記述されている。ここでは、カラムの型はＪａｖａ（登録商標）言語における型宣言を用いて標記しているが、本発明はこれに限定されるものではない。
書式＃２は、入力データセット＃２のレコードの書式に関する情報であり、本実施例では、入力データセット＃２のレコードを解釈する手続きが記述されている。書式＃２には、入力レコード（すなわち、入力データセット＃２のレコード）をテキスト形式（文字列形式）で解釈することが記述されている。また、レコードにおけるカラム間の区切り文字は、カンマであり、第1（０）のカラムは、ＤａｔｅＴｉｍｅ型であり、「Ｄａｔｅ ＆ Ｔｉｍｅ」と名付け、第２（１）のカラムは、Ｔｅｘｔ型であり、「Ｕｓｅｒ」と名付け、第３（２）のカラムは、Ｔｅｘｔ型であり、「Ｐｒｏｄｕｃｔ」と名付け、第４（３）のカラムは、Ｔｅｘｔ型であり、「Ｃｏｍｍｅｎｔ」と名付け、これらに基づいて入力カラムを解釈することが記述されている。
参照方式＃１は、入力データセット＃１の「Ｒｅｆｅｒｅｎｃｅ」を用いて、入力データセット＃２のレコードを参照する方法についての手続きであり、入力レコード（書式＃1に対応するレコード）の第２カラムをオフセットとし、第３カラムを長さとし、第４カラムをノードＩＤとして、物理参照により参照を行ってレコードを取得することが記述されている。ここで、物理参照は、指定されたノードＩＤが管理するストレージの指定されたオフセット（番地）を始点として、指定された長さ分のバイト列を、参照先のレコードとすることを意味する。
図５Ｃは、スレッド生成及びスレッドの実行を説明する模式図の一例である。図５Ｃの上側には、単一のスレッドによりプロセスを実行する場合の例を示し、図５Ｃの下側には、実施例１に係るスレッドを動的に生成し、複数スレッドを並行して実行する例を示す。なお、図５Ｃの表記は、次のルールに従う。
（＊）横軸は、時刻を表す。
（＊）図中の横に長い角丸四角形は、１つのスレッドによる一連の処理を意味する。角丸四角形の左端はスレッドによる処理を開始する時刻を表し、角丸四角形の右端は当該スレッドによる処理を終了する時刻を表す。
（＊）角丸四角形の内部の値は、スレッドに対応した処理に伴って読み込まれるレコードを示す情報（例えば、レコードの先頭のカラムの値）を表す。
ここで、図５Ｃは、図５Ａに示す２０１２年の２月（２０１２−Ｆｅｂ）に対応する入力データセット＃１の各レコードを取得して、処理を実行する例を示している。
図５Ｃの上側の図に示すように、単一スレッドにより実行する場合においては、プロセッサは、入力データセット＃１の２０１２年の２月（２０１２−Ｆｅｂ）に対応する上から２番目のレコード（「Ｐｒｏｄｕｃｔ」の値が「ＡＸ Ｓｋｉｒｔ）を読み込み、このレコードの「Ｒｅｆｅｒｅｎｃｅ」の値に基づいて、入力データセット＃２の７番目のレコード（「２０１２−Ｆｅｂ−０７ ・・・」）を参照し、入力データセット＃１の上から３番目のレコード（「Ｐｒｏｄｕｃｔ」の値が「ＢＢ Ｂｏｏｋ」）を読み込み、このレコードの「Ｒｅｆｅｒｅｎｃｅ」の値に基づいて、入力データセット＃２の８番目のレコード（「２０１２−Ｆｅｂ−０８ ・・・」）を参照し、さらに、「Ｒｅｆｅｒｅｎｃｅ」の値に基づいて、入力データセット＃２の１０番目のレコード（「２０１２−Ｆｅｂ−０８ ・・・」）を参照し、さらに、「Ｒｅｆｅｒｅｎｃｅ」の値に基づいて、入力データセット＃２の１１番目のレコード（「２０１２−Ｆｅｂ−０８ ・・・」）を参照して処理を行っていく。即ち、ストレージからのレコードの読み込みとそれに対する処理は、逐次的に行われていく。
一方、本実施例においては、図５Ｃの下側の図に示すように、マップ関数１２１は、先ずスレッド５ａにより、入力データセット＃１の２０１２年の２月（２０１２−Ｆｅｂ）に対応する上から２番目のレコード（「Ｐｒｏｄｕｃｔ」の値が「ＡＸ Ｓｋｉｒｔ）を読み込み、このレコードの「Ｒｅｆｅｒｅｎｃｅ」の値に基づいて、入力データセット＃２の７番目のレコード「２０１２−Ｆｅｂ−０７ ・・・」）を参照するためのスレッド５ｂを生成して実行する。
次いで、マップ関数１２１は、スレッド５ａにより、２０１２−Ｆｅｂに対応する入力データセット＃１の上から３番目のレコード（「Ｐｒｏｄｕｃｔ」の値が「ＡＸ Ｓｋｉｒｔ）を読み込み、このレコードの「Ｒｅｆｅｒｅｎｃｅ」の４つの値に基づいて、入力データセット＃２の８番目のレコード（「２０１２−Ｆｅｂ−０８ ・・・」）を参照するためのスレッド５ｃ、入力データセット＃２の１０番目のレコード（「２０１２−Ｆｅｂ−０８ ・・・」）を参照するためのスレッド５ｄ、入力データセット＃２の１１番目（「２０１２−Ｆｅｂ−０８ ・・・」）のレコードを参照するためのスレッド５ｅ、及び入力データセット＃２の１２番目のレコード（「２０１２−Ｆｅｂ−０９ ・・・」）を参照するためのスレッド５ｆを順次生成して実行する。
次いで、マップ関数１２１は、スレッド５ａにより、入力データセット＃１の２０１２−Ｆｅｂに対応する上から４番目のレコード（「Ｐｒｏｄｕｃｔ」の値が「ＢＣ Ｂｉｋｅ）を読み込み、このレコードの「Ｒｅｆｅｒｅｎｃｅ」の２つの値に基づいて、入力データセット＃２の６番目のレコードを参照するためのスレッド５ｇ、入力データセット＃２の９番目のレコードを参照するためのスレッド５ｈを生成して実行する。
次いで、マップ関数１２１は、スレッド５ａにより、２０１２−Ｆｅｂに対応する入力データセット＃１の上から５番目のレコード（「Ｐｒｏｄｕｃｔ」の値が「ＢＤ Ｆｌｏｗｅｒ）を読み込み、このレコードの「Ｒｅｆｅｒｅｎｃｅ」の１つの値に基づいて、入力データセット＃２の５番目のレコード（「２０１２−Ｆｅｂ−０３ ・・・」）を参照するためのスレッド５ｉを生成して実行する。
図５Ｃの下側図に示すように、スレッドを動的に生成し、当該スレッドにおいてレコードを読み込んで処理を行い、複数のスレッドを並行して実行することにより、単一のスレッドを実行する場合に比して、処理の実行時間を短縮することができる。 図５Ｄは、実施例２に係る入力データ及び入力データに対する処理を説明するための第１の図である。図５Ｅは、実施例２に係る入力データ及び入力データに対する処理を説明するための第２の図である。
実施例２に係るジョブ実行プランにおいては、入力データセット＃２のレコードの値を用いて、更に、入力データセット＃３のレコードを参照する。したがって、図５Ｄに示すように、アプリケーション１１０には、入力データセット＃２のレコードの値（「Ｕｓｅｒ」の値）に基づいて、入力データセット＃３を参照するための参照方式＃２が更に備えられる。ここで、「Ｕｓｅｒ」の値は、当該値に対応する入力データセット＃３のレコードの物理的な位置を示す参照ではなく、論理的な位置を示す（その値によって検索可能である）参照である。
図５Ｅには、入力データセット＃３と、入力データセット＃４とを示す。
入力データセット＃４は、「Ｕｓｅｒ」、「Ｇｅｎｄｅｒ」、「Ｚｉｐ」、「Ａｄｄｒｅｓｓ」を含む１以上のレコードを格納する。
入力データセット＃３は、「Ｕｓｅｒ」と、「Ｒｅｆｅｒｅｎｃｅ」との項目を有する１以上のレコードが、所定の範囲ごとにまとめられて管理されている。「Ｕｓｅｒ」には、入力データセット＃４におけるレコードの検索に使用する鍵となる項目の値が格納される。「Ｒｅｆｅｒｅｎｃｅ」には、入力データセット＃４における当該レコード中の「Ｐｒｏｄｕｃｔ」の値と同一の値を格納するレコード（参照先レコード）の物理的な格納位置を示す参照が格納される。なお、入力データセット＃３に、複数の参照先レコードがある場合には、複数の参照先レコードへの参照が格納される。なお、入力レコード＃３はある鍵によってレコードを検索可能な構造（例えば、Ｂ木）を有してもよく、当該鍵の値を「Ｕｓｅｒ」に格納する参照としてもよい。ある１つの参照に複数のレコードが対応することがあってもよい。
入力データセット＃３のレコードの書式は、書式＃３に記述されている。また、入力データセット＃４のレコードの書式は、書式＃４に記述されている。また、入力データセット＃３の「Ｒｅｆｅｒｅｎｃｅ」を用いて、入力データセット＃４のレコードを参照する方法については、参照方式＃３に記述されている。また、取得したレコードに基づいて、後続に出力するレコードを生成する手続きがビルド方式に記述されている。
図１Ｂに示すジョブ実行モデルにおけるステージ＃１プロセスにおいては、プロセッサ１０１が一般化ステージ関数１２４を実行することにより、入力データセット＃１のレコードを読み込み、書式＃１により、レコードにおける「Ｐｒｏｄｕｃｔ」と、「Ｒｅｆｅｒｅｎｃｅ」とを把握する。そして、一般化ステージ関数１２４は、「Ｐｒｏｄｕｃｔ」の値に基づいて、所定の条件に合致するか否かを判断し、条件を満たすレコードの「Ｒｅｆｅｒｅｎｃｅ」を特定する。そして、一般化ステージ関数１２４は、参照方式＃１と、「Ｒｅｆｅｒｅｎｃｅ」とに基づいて、入力データセット＃２のレコードを取得する。
次いで、プロセッサ１０１が一般化ステージ関数１２４を実行することにより、書式＃２により、読み込んだ入力データセット＃２のレコードの「Ｕｓｅｒ」、「Ｐｒｏｄｕｃｔ」、「Ｃｏｍｍｅｎｔ」を把握する。そして、一般化ステージ関数１２４は、「Ｕｓｅｒ」の値と、参照方法＃２とに基づいて、入力データセット＃３のレコードを取得する。
プロセッサ１０１が一般化ステージ関数１２４を実行することにより、書式＃３により、取得した入力データセット＃３のレコードにおける「Ｒｅｆｅｒｅｎｃｅ」を把握する。そして、一般化ステージ１２４は、参照方式＃３と、「Ｒｅｆｅｒｅｎｃｅ」とに基づいて、入力データセット＃４のレコードを取得する。
次いで、プロセッサ１０１が一般化ステージ関数１２４を実行することにより、書式＃４により、読み込んだ入力データセット＃４のレコードの「Ｕｓｅｒ」、「Ｇｅｎｄｅｒ」、「Ｚｉｐ」、「Ａｄｄｒｅｓｓ」を把握する。そして、プロセッサ１０１が一般化ステージ関数１２４を実行することにより、ビルド方式に基づいて、「Ｕｓｅｒ」，「Ｐｒｏｄｕｃｔ」、「Ｃｏｍｍｅｎｔ」、「Ｇｅｎｄｅｒ」、「Ｚｉｐ」を含むレコードを構築して出力する。
図５Ｆは、実施例２に係る書式を説明するための図である。
書式＃３は、入力データセット＃３のレコードの書式に関する情報であり、本実施例では、入力データセット＃３のレコードを解釈する手続きが記述されている。書式＃３には、入力レコード（すなわち、入力データセット＃３のレコード）をバイナリ形式で解釈し、入力レコードの各カラムを、Ｔｅｘｔ型、Ｌｏｎｇ型、Ｉｎｔ型、Ｉｎｔ型として解釈すること、第1（０）のカラムを検索鍵とすることが記述されている。
書式＃４は、入力データセット＃４のレコードの書式に関する情報であり、本実施例では、入力データセット＃４のレコードを解釈する手続きが記述されている。書式＃４には、入力レコード（すなわち、入力データセット＃４のレコード）をテキスト形式（文字列形式）で解釈することが記述されている。また、レコードにおけるカラム間の区切り文字は、カンマであり、第1（０）のカラムは、Ｔｅｘｔ型であり、「Ｕｓｅｒ」と名付け、第２（１）のカラムは、Ｔｅｘｔ型であり、「Ｇｅｎｄｅｒ」と名付け、第３（２）のカラムは、Ｔｅｘｔ型であり、「Ｚｉｐ」と名付け、第４（３）のカラムは、Ｔｅｘｔ型であり、「Ａｄｄｒｅｓｓ」と名付け、これらに基づいて入力カラムを解釈することが記述されている。
図５Ｇは、実施例２に係る参照方式を説明するための図である。
参照方式＃２は、入力データセット＃２のレコードの値を用いて、入力データセット＃３のレコードを参照する方法についての手続きであり、入力レコード（書式＃２に対応するレコード）の第２カラムを参照鍵とし、論理参照により参照を行ってレコードを取得することが記述されている。ここで、論理参照は、指定された鍵の値によって、参照先のデータセットを検索して、参照先のレコードを同定することを意味する。
参照方式＃３は、入力データセット＃４の「Ｒｅｆｅｒｅｎｃｅ」を用いて、入力データセット＃６のレコードを参照する方法についての手続きであり、入力レコード（書式＃５に対応するレコード）の第２カラムをオフセットとし、第３カラムを長さとし、第４カラムをノードＩＤとして、物理参照により参照を行ってレコードを取得することが記述されている。ここで、物理参照は、指定されたノードＩＤが管理するストレージの指定されたオフセット（番地）を始点として、指定された長さ分のバイト列を、参照先のレコードとすることを意味する。
図５Ｈは、実施例２に係るカタログの一例を示す。
本実施例においては、書式や、参照方式については、例えば、プログラムコードで記述されている。したがって、この書式や参照方式をユーザが用意することとなると、ユーザ自身がプログラムコードを作成できる必要がある。しかしながら、全てのユーザがプログラムコードを作成できるとは限らない。そこで、本実施例では、ユーザが、アプリケーションにおいて、プログラムコードよりも容易なカタログを記述することにより書式や、参照方式など、ジョブ情報の一部を規定できるようにし、そのカタログに基づいて、並列データ処理システムがデータ処理のジョブを実行するようにする。なお、この際、並列データ処理システムは、カタログを一旦、書式や参照方式に変換してからジョブを実行してもよいし、カタログを以って直接ジョブを実行してもよい。
図５Ｈに示すカタログは、例えば、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）で記述されており、４つのデータ構造体に関する記述部５０ａ〜５０ｄを含む。
記述部５０ａには、入力データセット＃２に対応する「ｕｓｅｒ＿ｃｏｍｍｅｎｔ」のデータセットは、テキストをカラム分割した形式であり、第１（０）カラムをＤａｔｅＴｉｍｅ型で解釈し、これを分割鍵とし、カラム間の区切り文字をカンマとしていることが記述されている。
また、記述部５０ｂには、入力データセット＃１に対応する「ｕｓｅｒ＿ｃｏｍｍｅｎｔ．ｐｒｏｄｕｃｔ．ｉｎｄｅｘ」のデータセットは、「ｕｓｅｒ＿ｃｏｍｍｅｎｔ」に対応した局所的な二次索引としての形式であり、「ｕｓｅｒ＿ｃｏｍｍｅｎｔ」に基づいて、カラムの区切り文字をカンマとした際における第３（２）カラムをＴｅｘｔ型で解釈し、これを索引鍵とすることが記述されている。なお、記述部５０ｃ、５０ｄについても、上記記述部と同様な記述となっている。なお、カタログには必要なジョブ情報の一部を全て明示的に規定する必要はなく、明示的に規定されていないものについてはシステムモジュール等が所定の規定に沿って、並列データ処理を行ってもよい。例えば、この例では、「ｕｓｅｒ＿ｃｏｍｍｅｎｔ．ｐｒｏｄｕｃｔ．ｉｎｄｅｘ」については明示的に分割鍵を指定していないが、「ｕｓｅｒ＿ｃｏｍｍｅｎｔ．ｐｒｏｄｕｃｔ．ｉｎｄｅｘ」は局所的な二次索引として規定されていることから、その基となる「ｕｓｅｒ＿ｃｏｍｍｅｎｔ」と同じ分割が行われ、即ち、「ｕｓｅｒ＿ｃｏｍｍｅｎｔ」の分割部分の毎に二次索引としての「ｕｓｅｒ＿ｃｏｍｍｅｎｔ．ｐｒｏｄｕｃｔ．ｉｎｄｅｘ」が構成してもよい。
図６Ａは、実施例１に係るレコード取得を説明するための模式図の一例である。なお、以下、図６Ａ〜図９Ｃの説明は、実施例１についての説明であるが、実施例１に限らず実施例２にも適用される説明である。
計算ノード１００のプロセッサ１０１がスレッドを実行して、そのスレッドにより、レコードを取得する際に、レコードが自身の計算ノード１００のストレージ１０４に格納されているレコードである場合には、そのストレージ１０４からレコードを取得する。一方、レコードが他の計算ノード１００のストレージ１０４に格納されている場合には、計算ノード１００から他の計算ノード１００へ、例えばローカルエリアネットワーク２００を介して、レコードを取得するためのレコード取得要求を送信し、計算ノード１００は当該レコード取得要求に従い他の計算ノード１００がそのストレージ１０４から取得したレコードを受信することにより、レコードを取得する。この際、計算ノード１００と他の計算ノード１００との間にはセッションが張られる。複数のスレッドを実行している場合には、スレッド毎に発生されるレコード取得要求毎に、セッションが張られることとなる。この場合には、スレッド数が多くなればなるほど、張られるセッション数が増加することとなり、セッションの管理や制御に係る処理が増大してその効率が低下する。
これに対して、以下に示すように、複数のレコード取得要求をまとめたブロック毎にセッションを張るようにしてもよい。
図６Ｂは、実施例２に係るデータ取得時のブロック化を説明するための模式図の一例である。
計算ノード１００のプロセッサ１０１は、複数のスレッドにより発生される複数のレコード取得要求を、１つのブロック（ブロック化レコード取得要求）にまとめ、当該ブロックを単位として計算ノード１００と、他の計算ノード１００との間にセッションを張る。これにより、計算ノード１００間に張られるセッション数を低減することができ、処理効率の低下を防止することができる。
図７Ａは、実施例１に係るレコードを取得する計算ノードにおけるレコード取得処理の流れを示す。
このレコード取得処理は、図４ＡのＳ１０、Ｓ１６、図４ＢのＳ２１、Ｓ２７の処理に対応する。
Ｓ４１で、データ読み書き器１４０は、システムモジュール１２０から指示されたレコードの読み込み（取得）が、自身の計算ノード１００のストレージ１０４からのレコードの取得、すなわち、ローカルレコードの取得であるか否かを判断する。この判断の結果が肯定的であれば、Ｓ４２を行う一方、この判断の結果が否定的であれば、Ｓ４４を行う。
Ｓ４２で、データ読み書き器１４０は、ストレージマネージャ１６０により、ＯＳ１７０ならびにＨＢＡ１０３を経由して、ストレージ１０４に対して、レコードの取得に必要なデータを読み込むためのデータ読み込み要求を発行させる。具体的には、ストレージマネージャ１６０は、データ読み込み要求管理表７００（図７Ｃ参照）にデータ読み込み要求の情報を格納するとともに、計算ノード１００の主記憶１０５の要求キュー７４０に対して、データ読み込み要求を追加する。ＯＳ１７０は、要求キュー７４０からデータ読み込み要求を取得して、ＨＢＡ１０３によってストレージ１０４に発行する。
Ｓ４３で、データ読み書き器１４０は、自スレッドを保留状態とし、処理を終了する。
Ｓ４４で、データ読み書き器１４０は、ネットワークマネージャ１５０により、ＯＳ１７０ならびにＮＩＣ１０２を経由して、他の計算ノード１００に対して、レコード取得要求メッセージを送信させる。具体的には、ネットワークマネージャ１５０は、リモートレコード取得要求管理表７１０（図７Ｃ参照）にレコード取得要求メッセージの情報を格納するとともに、計算ノード１００の主記憶１０５の送信キュー７２０に対して、レコード取得要求メッセージを追加する。
Ｓ４５で、データ読み書き器１４０は、自スレッドを保留状態とし、処理を終了する。
一方、計算ノード１００のストレージ１０４は、要求キュー７４０から発行されたデータ読み込み要求を受信して、当該データ読み込み要求に対応するデータを読み込んで、ＨＢＡ１０３に送信する。ＯＳ１７０は、ＨＢＡ１０３より読み込んだ当該データを主記憶１０５の完了キュー７５０に追加する。
その後、Ｓ４６で、データ読み書き器１４０は、完了キュー７５０からデータ読み込み要求に対応するデータを取得し、当該データからレコードを抽出する。レコード
Ｓ４７で、データ読み書き器１４０は、データ読み込み要求管理表７００に基づいて、受け取ったレコードを使用するスレッドを特定し、当該スレッドを再開し、レコード取得処理を終了する。
一方、送信キュー７２０に格納されたレコード取得要求メッセージは、ＮＩＣ１０２により送信先の計算ノード１００に送信される。また、他の計算ノード１００から送信されるレコード取得要求メッセージに対する取得完了メッセージは、ＮＩＣ１０２により受信キュー７３０に格納される。
Ｓ４８で、ネットワークマネージャ１５０は、受信キュー７３０の取得完了メッセージからレコードを抽出し、システムモジュール１２０に渡す。
Ｓ４９で、データ読み書き器１４０は、リモートレコード取得要求管理表７１０に基づいて、受け取ったレコードを使用するスレッドを特定し、当該スレッドを再開し、レコード取得処理を終了する。
図７Ｂは、実施例１に係るレコードを管理する計算ノードにおけるレコード取得処理の流れを示す。
レコード取得要求メッセージの送信先の計算ノード１００においては、ＮＩＣ１０２がレコード取得要求メッセージを取得し、ＯＳ１７０が主記憶１０５の受信キュー７６０に格納する。
Ｓ５０で、送信先の計算ノード１００のネットワークマネージャ１５０は、受信キュー７６０からレコード取得要求メッセージを取得し、データ読み書き器１４０に渡す。
Ｓ５１で、データ読み書き器１４０は、レコード取得要求メッセージに基づいて、ストレージマネージャ１６０により、ＯＳ１７０ならびにＨＢＡ１０３を経由して、ストレージ１０４に対して、レコードの取得に必要なデータを読み込むためのデータ読み込み要求を発行させ、処理を終了する。具体的には、ストレージマネージャ１６０は、計算ノード１００の主記憶１０５の要求キュー７８０に対して、データ読み込み要求を追加する。ＯＳ１７０は、ＨＢＡ１０３により、要求キュー７４０からデータ読み込み要求を取得して、ストレージ１０４に発行する。
ストレージ１０４は、要求キュー７８０から発行されたデータ読み込み要求を受信し、当該データ読み込み要求に対応するレコードを読み込んで、ＨＢＡ１０３に送信する。ＯＳ１７０は、ＨＢＡ１０３による読み込んだ当該レコードを主記憶１０５の完了キュー７９０に追加する。
その後、Ｓ５２で、データ読み書き器１４０は、完了キュー７９０からデータ読み込み要求に対応するデータからレコードを抽出する。
Ｓ５３で、データ読み書き器１４０は、受け取ったレコードを取得完了メッセージに含め、ネットワークマネージャ１５０により、レコード取得要求メッセージの送信元の計算ノード１００に対して取得完了メッセージを送信し、処理を終了する。具体的には、ネットワークマネージャ１５０は、計算ノード１００の主記憶１０５の送信キュー７６０に対して、取得完了メッセージを追加する。
送信キュー７６０に格納された取得完了メッセージは、ＮＩＣ１０２によりレコード取得要求メッセージの送信元の計算ノード１００に送信される。この取得完了メッセージは、送信元の計算ノード１００において、ＮＩＣ１０２により受信キュー７３０に格納する。
図７Ａに図示する処理は、図４ＡのＳ１０、Ｓ１６、図４ＢのＳ２１、Ｓ２７の処理を行うスレッド（ＳＬ１、ＳＬ２、ＳＬｄ１、ＳＬｄ２、ＳＬｄｋ、ＳＬｄｋ＋１等）において実行してもよい。例えば、ＣＰＵ１０１がスレッドＳＬ１においてＳ１０のデータ取得処理を実行することにより、ＣＰＵ１０１がＳ４１からＳ４５までに相当する手続きを同じスレッドＳＬ１で実行してもよい。また、図７Ａに図示する処理は、図４ＡのＳ１０、Ｓ１６、図４ＢのＳ２１、Ｓ２７の処理を行うスレッド（ＳＬ１、ＳＬ２、ＳＬｄ１、ＳＬｄ２、ＳＬｄｋ、ＳＬｄｋ＋１等）とは別のスレッドにおいて実行してもよい。例えば、ＣＰＵ１０１がスレッドＳＬ１においてＳ１０のデータ取得処理を実行することにより、ＣＰＵ１０１がＳ４１からＳ４５までに相当する手続きを別のスレッドで実行してもよい。この際、Ｓ４１からＳ４５までに相当する手続き、Ｓ４６からＳ４７までに相当する手続き、Ｓ４８からＳ４９までに相当する手続きの別に、それぞれ別のスレッドを設けてもよいし、同じスレッドで行ってもよい。また、それぞれの手続きに複数のスレッドを設けてもよい。また、Ｓ４６からＳ４７までに相当する手続き、Ｓ４８からＳ４９までに相当する手続きを駆動するために、更に別のスレッドを設けてもよい。これらの駆動は、完了キュー７５０ならびに受信キュー７３０に対してＨＢＡ１０３ならびにＮＩＣ１０２が追加を行うことにより生じる割り込みやシグナル等の手段によって行われてもよい。
図７Ｂに図示する処理については、Ｓ５０からＳ５１までに相当する手続き、Ｓ５２からＳ５３までに相当する手続きの別に、それぞれ別のスレッドを設けてもよいし、同じスレッドで行ってもよい。また、それぞれの手続きに複数のスレッドを設けてもよい。また、Ｓ５２からＳ５３までに相当する手続きを駆動するために、更に別のスレッドを設けてもよい。これらの駆動は、完了キュー７９０に対してＨＢＡ１０３が追加を行うことにより生じる割り込みやシグナル等の手段によって行われてもよい。
図７Ｃは、実施例１に係るデータ読み込み要求管理表及びリモートレコード取得要求管理表の構成を示す。
データ読み込み要求管理表７００は、データ読み込み要求毎の情報として、スレッドＩＤ７０１、要求発行時刻７０２、及びデータ読み込み要求７０３を有する。データ読み込み要求７０３は、装置ＩＤ７０４、オフセット番地７０５、読み込み長７０６、及びバッファ番地７０７を有する。各種情報は、下記の通りである。
（＊）スレッドＩＤ７０１は、データ読み込み要求を発行させたスレッドを識別するためのＩＤを示す。
（＊）要求発行時刻７０２は、データ読み込み要求を発行した時刻を示す。
（＊）データ読み込み要求７０３は、データ読み込み要求の内容を示す。
（＊）装置ＩＤ７０４は、データ読み込み要求の送信先のストレージ１０４の装置ＩＤを示す。
（＊）オフセット番地７０５は、データ読み込み要求対象のレコードが格納されるストレージ１０４におけるアドレス（オフセット番地）を示す。
（＊）読み込み長７０６は、読み込むレコードのデータ長（バイト長）を示す。
（＊）バッファ番地７０７は、データ読み込み要求対象のレコードを格納する主記憶１０５上の領域（バッファ）のアドレスを示す。
リモートレコード取得要求管理表７１０は、レコード取得要求毎の情報として、スレッドＩＤ７１１、要求発行時刻７１２、及びレコード取得要求７１３を有する。レコード取得要求７１３は、計算ノードＩＤ７１４、レコード参照７１５、バッファ番地７１６を有する。各種情報は、下記の通りである。
（＊）スレッドＩＤ７１１は、レコード取得要求を発行させたスレッドを識別するためのＩＤを示す。
（＊）要求発行時刻７１２は、レコード取得要求を発行した時刻を示す。
（＊）レコード取得要求７１３は、レコード取得要求の内容を示す。
（＊）計算ノードＩＤ７１４は、レコード取得要求の送信先の計算ノードのＩＤ（計算ノードＩＤ）を示す。
（＊）レコード参照７１５は、レコード取得要求の対象となるレコードへの参照情報を示す。
（＊）バッファ番地７１６は、データ読み込み要求対象のレコードを格納する主記憶１０５上の領域（バッファ）のアドレスを示す。
次に、実施例１の変形例に係るレコード取得処理を説明する。
図７Ｄは、実施例１の変形例に係るレコードを取得する計算ノードにおけるレコード取得処理の流れを示す。
このレコード取得処理は、図４ＡのＳ１０、Ｓ１６、図４ＢのＳ２１、Ｓ２７の処理に対応する。
Ｓ６１で、データ読み書き器１４０は、システムモジュール１２０から指示されたレコードの読み込み（取得）が、自身の計算ノード１００のストレージ１０４からのレコードの取得、すなわち、ローカルレコードの取得であるか否かを判断する。この判断の結果が肯定的であれば、Ｓ６２を行う一方、この判断の結果が否定的であれば、Ｓ６４を行う。
Ｓ６２で、データ読み書き器１４０は、ストレージマネージャ１６０により、ストレージ１４０に対して、データ読み込み要求を発行させる。なお、具体的な処理は、図７ＡにおけるＳ４２と同様である。
Ｓ６３で、データ読み書き器１４０は、自スレッドを保留状態とし、処理を終了する。
Ｓ６４で、データ読み書き器１４０は、各計算ノード１００に対するレコード取得要求メッセージを、主記憶１０５の各計算ノード１００のそれぞれに対応して設けられているブロック化キュー８００、８１０、８２０の中の、このレコード取得要求メッセージの送信先の計算ノード１００に対応するブロック化キューに追加し、当該レコード取得要求メッセージをブロック化リモートレコード取得要求管理表８３０に追加する。ここで、ブロック化リモードレコード取得要求管理表８３０においては、同一の計算ノード１００を送信先とする複数のレコード取得要求メッセージが１つの要求（ブロック化リモートレコード取得要求）にまとめられる。
Ｓ６５で、データ読み書き器１４０は、自スレッドを保留状態とし、処理を終了する。
Ｓ６６で、ネットワークマネージャ１５０は、各ブロック化キュー８００、８１０、８２０のそれぞれから、複数のレコード取得要求メッセージを含むブロック化リモートレコード取得要求を抽出する。
Ｓ６７で、ネットワークマネージャ１５０は、ブロック化リモートレコード取得要求メッセージをＯＳ１７０ならびにＮＩＣ１０２を介して送信し、処理を終了する。具体的には、ネットワークマネージャ１５０は、ブロック化リモートレコード取得要求メッセージを主記憶１０５の送信キュー８４０に格納し、ＮＩＣ１０２が送信キュー８４０からブロック化リモートレコード取得要求メッセージを送信先の計算ノード１００に送信する。このように、複数のレコード取得要求を１つのブロック化リモートレコード取得要求メッセージとするとので、通信時に張られるセッション数を低減することができる。
この後、ＯＳ１７０は、ＮＩＣ１０２により、他の計算ノード１００から送信されるブロック化レコード取得完了メッセージを受信し、受信キュー８５０に格納する。
Ｓ６８で、ネットワークマネージャ１５０は、受信キュー８５０からブロック化レコード取得完了メッセージを取得し、ブロック化レコード取得完了メッセージから複数のレコードを抽出し、システムモジュール１２０に渡す。
Ｓ６９で、データ読み書き器１４０は、ブロック化リモートレコード取得要求管理表８３０に基づいて、受け取ったレコードを使用するスレッドを特定し、当該スレッドを再開し、レコード取得処理を終了する。
図７Ｅは、実施例１の変形例に係るレコードを管理する計算ノードにおけるレコード取得処理の流れを示す。
ブロック化リモートレコード取得要求メッセージの送信先の計算ノード１００においては、ＮＩＣ１０２がブロック化リモートレコード取得要求メッセージを取得し、主記憶１０５の受信キュー８６０に格納する。
Ｓ７０で、送信先の計算ノード１００のネットワークマネージャ１５０は、受信キュー８６０からブロック化リモートレコード取得要求メッセージを取得し、ブロック化リモートレコード取得要求メッセージから複数のレコード取得要求を抽出してデータ読み書き器１４０に渡す。
Ｓ７１で、データ読み書き器１４０は、複数のレコード取得要求メッセージに基づいて、ストレージマネージャ１６０により、ＨＢＡ１０３を経由して、ストレージ１０４に対して、複数のレコードの取得に必要なデータを読み込むための複数のデータ読み込み要求を発行し、処理を終了する。具体的には、ストレージマネージャ１６０は、計算ノード１００の主記憶１０５の要求キュー８８０に対して、複数のデータ読み込み要求を追加する。ＨＢＡ１０４は、要求キュー７８０からデータ読み込み要求を取得して、ストレージ１０４に発行する。
ストレージ１０４は、要求キュー８８０から発行されたデータ読み込み要求を受信し、当該データ読み込み要求に対応するレコードを読み込んで、ＨＢＡ１０３に送信し、ＨＢＡ１０３が読み込んだ当該データを主記憶１０５の完了キュー８９０に追加する。
その後、Ｓ７２で、ストレージマネージャ１６０は、完了キュー８９０からデータ読み込み要求に対応する複数のレコードを取得し、当該データからレコードを抽出し、システムモジュール１２０に渡す。
Ｓ７３で、データ読み書き器１４０は、受け取った複数のレコードをブロック化取得完了メッセージに含め、ネットワークマネージャ１５０により、ブロック化リモートレコード取得要求メッセージの送信元の計算ノード１００に対してブロック化取得完了メッセージを送信させ、処理を終了する。具体的には、ネットワークマネージャ１５０は、計算ノード１００の主記憶１０５の送信キュー８７０に対して、ブロック化取得完了メッセージを追加する。送信キュー８７０に格納されたブロック化取得完了メッセージは、ＮＩＣ１０２によりブロック化リモートレコード取得要求メッセージの送信元の計算ノード１００に送信される。このブロック化取得完了メッセージは、送信元の計算ノード１００において、ＮＩＣ１０２により受信キュー８５０に格納される。
図７Ｄに図示する処理は、図４ＡのＳ１０、Ｓ１６、図４ＢのＳ２１、Ｓ２７の処理を行うスレッド（ＳＬ１、ＳＬ２、ＳＬｄ１、ＳＬｄ２、ＳＬｄｋ、ＳＬｄｋ＋１等）において実行してもよい。例えば、ＣＰＵ１０１がスレッドＳＬ１においてＳ１０のデータ取得処理を実行することにより、ＣＰＵ１０１がＳ６１からＳ６５までに相当する手続きを同じスレッドＳＬ１で実行してもよい。また、図７Ｄに図示する処理は、図４ＡのＳ１０、Ｓ１６、図４ＢのＳ２１、Ｓ２７の処理を行うスレッド（ＳＬ１、ＳＬ２、ＳＬｄ１、ＳＬｄ２、ＳＬｄｋ、ＳＬｄｋ＋１等）とは別のスレッドにおいて実行してもよい。例えば、ＣＰＵ１０１がスレッドＳＬ１においてＳ１０のデータ取得処理を実行することにより、ＣＰＵ１０１がＳ６１からＳ６５までに相当する手続きを別のスレッドで実行してもよい。この際、Ｓ６１からＳ６５までに相当する手続き、Ｓ６６からＳ６７までに相当する手続き、Ｓ６８からＳ６９までに相当する手続きの別に、それぞれ別のスレッドを設けてもよいし、同じスレッドで行ってもよい。また、それぞれの手続きに複数のスレッドを設けてもよい。また、Ｓ６６からＳ６７までに相当する手続き、Ｓ６８からＳ６９までに相当する手続きを駆動するために、更に別のスレッドを設けてもよい。これらの駆動は、完了キュー７５０ならびに受信キュー７３０に対してＨＢＡ１０３ならびにＮＩＣ１０２が追加を行うことにより生じる割り込みやシグナル等の手段によって行われてもよい。
図７Ｅに図示する処理については、Ｓ７０からＳ７１までに相当する手続き、Ｓ７２からＳ７３までに相当する手続きの別に、それぞれ別のスレッドを設けてもよいし、同じスレッドで行ってもよい。また、それぞれの手続きに複数のスレッドを設けてもよい。例えば、Ｓ７０で取得したブロック化レコード取得要求メッセージに従い、複数のスレッドを生成し、その各々のスレッドにおいてＳ７１を実行してデータ読み込み要求を実行してもよい。この際、当該メッセージに含まれるレコード取得要求の数と同じ数のスレッドを生成してもよいし、また、所定の数のスレッドを生成してもよい。Ｓ７２からＳ７３までに相当する手続きを駆動するために、更に別のスレッドを設けてもよい。これらの駆動は、完了キュー７９０に対してＨＢＡ１０３が追加を行うことにより生じる割り込みやシグナル等の手段によって行われてもよい。
図７Ｆは、変形例に係るブロック化リモートレコード取得要求管理表の構成を示す。
ブロック化リモートレコード取得要求管理表８３０は、ブロック化リモートレコード取得要求毎の情報として、要求発行時刻８３２、要求の数８３３、及び１以上のレコード取得要求８３４を有する。レコード取得要求８３４は、スレッドＩＤ８３１、計算ノードＩＤ８３５、レコード参照８３６、バッファ番地８３７、完了フラグ８３８を有する。各種情報は、下記の通りである。
（＊）要求発行時刻８３２は、ブロック化リモートレコード取得要求を発行した時刻を示す。
（＊）要求の数８３３は、ブリック化リモートレコード取得要求に含まれるレコード取得要求の数を示す。
（＊）レコード取得要求８３４は、レコード取得要求の内容を示す。
（＊）スレッドＩＤ８３１は、レコード取得要求を発行したスレッドを識別するためのＩＤを示す。
（＊）計算ノードＩＤ８３５は、レコード取得要求の送信先の計算ノードのＩＤ（計算ノードＩＤ）を示す。
（＊）レコード参照８３６は、レコード取得要求の対象となるレコードへの参照情報を示す。
（＊）バッファ番地８３７は、レコード取得要求の対象となるレコードを格納する主記憶１０５上の領域（バッファ）のアドレスを示す。
（＊）完了フラグ８３８は、レコード取得要求に対応するレコードを取得したか否かを示すフラグである。
なお、上記においては、本発明の特徴的な点に焦点を絞って、並列データ処理を行うジョブにおいて、レコード取得する手続きを説明したが、当該手続きには多様な実装形態が考えられる。
データセットからレコードを抽出するためには、データセット中でレコードがどのように配置されているかの情報が不可欠である。例えば、テキストファイルをデータセットとし、そのうちの１行をレコードとして取り扱う場合においては、レコードとレコードは改行コードによって区切られる。当該テキストファイルからレコードを取り出すためには、レコードが改行コードによって区切られているという情報が欠かせない。また、別の例としては、データセットがＢ木等の構造を有する場合、幾つかのレコードはストレージ上のアクセスの単位であるページの中に適当なデータ構造によって詰め込まれている場合がある。そのような構造からレコードを取り出すためには、当該構造（ページの長さ、ページのヘッダ・フッタ構造、ページ中におけるレコードのヘッダ・フッタ構造等）の情報が欠かせない。更には、データセットが圧縮や暗号化されている場合には、当該データセットからレコードを取得するためには復号のための手続き情報が欠かせない。このようにレコードを取得するためのデータセットの構成に関する情報は、書式等に同様に、ジョブ情報の一部としてアプリケーションによって規定されてもよい。もしくは、データセットの構成に関する情報は、その全てをアプリケーションが明示的に規定しなくてもよい。アプリケーションによって規定されていないデータセットの構成に関しては、システムモジュール等が所定の構成が規定されているものと見做して、ジョブを実行してもよい。この際、システムモジュール等は、データセットに関する情報やデータセットに基づいて、データセットの構成を判断してもよい。例えば、アプリケーションが明示的にデータセットの構成を規定していないものの、データセットがテキストファイルであると判断される場合には、レコードが改行コードによって区切られているものとしてジョブを実行してもよい。なお、この際に、アプリケーションが規定するデータセットの構成に関する情報は、システムモジュールを介して、データ読み書き器に通知されてもよい。
システムモジュール等は、データセットからレコードを抽出する際に、データセットの一部のデータを主記憶等にキャッシュし、ストレージへのアクセスを減らすようにしてもよい。例えば、テキストファイルを走査してレコードを取得する場合、レコードの毎にストレージにアクセスするのではなく、一度に１メガバイト等の単位でテキストファイルからデータを読み込んで主記憶に格納し、そのデータの中からレコードを取り出すようにしてもよい。
図８Ａは、実施例１に係るノードレベルの資源制約管理表の構成を示す。
図８Ａの上側のノードレベルの資源制約管理表９００は、各計算ノード１００を統括する統括スーパバイザプロセスにより管理される。
ノードレベルの資源制約管理表９００は、計算ノード毎の情報として、計算ノードＩＤ９０１、資源制約９０２を有する。資源制約９０２は、スレッド数９０３と、主記憶割当て９０４とを有する。各種情報は、下記の通りである。
（＊）計算ノードＩＤ９０１は、計算ノードのＩＤを示す。
（＊）資源制約９０２は、計算ノードＩＤ９０１に対応する計算ノードにおける資源の制約を示す。
（＊）スレッド数９０３は、計算ノードＩＤ９０１に対応する計算ノードにおいて、生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９０４は、計算ノードＩＤ９０１に対応する計算ノードにおいて、割当て可能な主記憶の最大の記憶量を示す。
図８Ａの下側のノードレベルの資源制約管理表９１０は、各計算ノード１００におけるスーパバイザプロセスにより管理される。
ノードレベルの資源制約管理表９１０は、自身の計算ノードの情報として、計算ノードＩＤ９１１、資源制約９１２、及び資源利用９１３を有する。資源制約９１２は、スレッド数９１４と、主記憶割当て９１５とを有する。資源利用９１３は、スレッド数９１６と、主記憶割当て９１７とを有する。各種情報は、下記の通りである。
（＊）計算ノードＩＤ９１１は、自身の計算ノードのＩＤ（計算ノードＩＤ）を示す。
（＊）資源制約９１２は、自身の計算ノードにおける資源の制約を示す。
（＊）資源利用９１３は、自身の計算ノードにおいて利用している資源を示す。
（＊）スレッド数９１４は、自身の計算ノードにおいて、生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９１５は、自身の計算ノードにおいて、割当て可能な主記憶の最大の記憶量を示す。
（＊）スレッド数９１６は、自身の計算ノードにおいて、実際に生成しているスレッドの数を示す。
（＊）主記憶割当て９１７は、自身の計算ノードにおいて、実際に割当てている主記憶の記憶量を示す。
図８Ｂは、実施例１に係るジョブレベルの資源制約管理表の構成を示す。
図８Ｂの上側のジョブレベルの資源制約管理表９２０は、統括スーパバイザプロセスにより管理される。
ジョブレベルの資源制約管理表９２０は、ジョブ毎の情報として、ジョブＩＤ９２１、計算ノードＩＤ９２２、資源制約９２３を有する。資源制約９２３は、スレッド数９２４と、主記憶割当て９２５とを有する。各種情報は、下記の通りである。
（＊）ジョブＩＤ９２１は、ジョブのＩＤ（ジョブＩＤ）を示す。
（＊）計算ノードＩＤ９２２は、ジョブＩＤ９２１のジョブを実行する計算ノードのＩＤ（計算ノードＩＤ）を示す。
（＊）資源制約９２３は、計算ノードＩＤ９２２の計算ノードにおけるジョブＩＤ９２１のジョブに対する資源の制約を示す。
（＊）スレッド数９２４は、計算ノードＩＤ９２２の計算ノードにおけるジョブＩＤ９２１のジョブに対する生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９２５は、計算ノードＩＤ９２２の計算ノードにおけるジョブＩＤ９２１のジョブに対する割当て可能な主記憶の最大の記憶量を示す。
図８Ｂの下側のノードレベルの資源制約管理表９３０は、各計算ノード１００におけるスーパバイザプロセスにより管理される。
ノードレベルの資源制約管理表９３０は、自身の計算ノードにおける各ジョブに対する情報として、ジョブＩＤ９３１、計算ノードＩＤ９３２、資源制約９３３、及び資源利用９３４を有する。資源制約９３３は、スレッド数９３５と、主記憶割当て９３６とを有する。資源利用９３４は、スレッド数９３７と、主記憶割当て９３８とを有する。各種情報は、下記の通りである。
（＊）ジョブＩＤ９３１は、ジョブのＩＤ（ジョブＩＤ）を示す。
（＊）計算ノードＩＤ９３２は、自身の計算ノードのＩＤ（計算ノードＩＤ）を示す。
（＊）資源制約９３３は、自身の計算ノード１００におけるジョブＩＤ９３１のジョブに対する資源の制約を示す。
（＊）資源利用９３４は、自身の計算ノード１００においてジョブＩＤ９３１のジョブに対して利用している資源を示す。
（＊）スレッド数９３５は、自身の計算ノード１００におけるジョブＩＤ９３１のジョブに対する、生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９３６は、自身の計算ノード１００におけるジョブＩＤ９３１のジョブに対する、割当て可能な主記憶の最大の記憶量を示す。
（＊）スレッド数９３７は、自身の計算ノード１００においてジョブＩＤ９３１のジョブに対して、実際に生成しているスレッドの数を示す。
（＊）主記憶割当て９３８は、自身の計算ノード１００においてジョブＩＤ９３１のジョブに対して、実際に割当てている主記憶の記憶量を示す。
図８Ｃは、実施例１に係る統括するスーパバイザプロセスにおけるプロセスレベルの資源制約管理表の構成を示す。
プロセスレベルの資源制約管理表９４０は、統括スーパバイザプロセスにより管理される。
プロセスレベルの資源制約管理表９４０は、プロセス毎の情報として、プロセスＩＤ９４１、ジョブＩＤ９４２、計算ノードＩＤ９４３、資源制約９４４を有する。資源制約９４４は、スレッド数９４５と、主記憶割当て９４６とを有する。各種情報は、下記の通りである。
（＊）プロセスＩＤ９４１は、プロセスのＩＤ（プロセスＩＤ）を示す。
（＊）ジョブＩＤ９４２は、ジョブＩＤを示す。
（＊）計算ノードＩＤ９４３は、ジョブＩＤ９２１のジョブのプロセスＩＤ９４１のプロセスを実行する計算ノードのＩＤ（計算ノードＩＤ）を示す。
（＊）資源制約９４４は、計算ノードＩＤ９４３の計算ノードにおけるジョブＩＤ９４２のジョブのプロセスＩＤ９４１のプロセスに対する資源の制約を示す。
（＊）スレッド数９４５は、計算ノードＩＤ９４３の計算ノードにおけるジョブＩＤ９４２のジョブのプロセスＩＤ９４１のプロセスに対する生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９４６は、計算ノードＩＤ９４３の計算ノードにおけるジョブＩＤ９４２のジョブのプロセスＩＤ９４１のプロセスに対する割当て可能な主記憶の最大の記憶量を示す。
図８Ｄは、実施例１に係る各ノードのスーパバイザプロセスにおけるプロセスレベルの資源制約管理表の構成を示す。
プロセスレベルの資源制約管理表９５０は、各計算ノード１００におけるスーパバイザプロセスにより管理される。
プロセスレベルの資源制約管理表９５０は、自身の計算ノードにおける各ジョブにおける各プロセスに対する情報として、プロセスＩＤ９５１、ジョブＩＤ９５２、計算ノードＩＤ９５３、資源制約９５４、及び資源利用９５５を有する。資源制約９５４は、スレッド数９５６と、主記憶割当て９５７とを有する。資源利用９５５は、スレッド数９５８と、主記憶割当て９５９とを有する。各種情報は、下記の通りである。
（＊）プロセスＩＤ９５１は、プロセスのＩＤを示す。
（＊）ジョブＩＤ９５２は、ジョブのＩＤを示す。
（＊）計算ノードＩＤ９５３は、自身の計算ノード１００のＩＤ（計算ノードＩＤ）を示す。
（＊）資源制約９５４は、自身の計算ノード１００におけるジョブＩＤ９５２のジョブのプロセスＩＤ９５１のプロセスに対する資源の制約を示す。
（＊）資源利用９５５は、自身の計算ノード１００においてジョブＩＤ９５２のジョブのプロセスＩＤ９５１のプロセスに対して利用している資源を示す。
（＊）スレッド数９５６は、自身の計算ノード１００におけるジョブＩＤ９５２のジョブのプロセスＩＤ９５１のプロセスに対する、生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９５７は、自身の計算ノード１００におけるジョブＩＤ９５２のジョブのプロセスＩＤ９５１のプロセスに対する、割当て可能な主記憶の最大の記憶量を示す。
（＊）スレッド数９５８は、自身の計算ノード１００においてジョブＩＤ９５２のジョブのプロセスＩＤ９５１のプロセスに対して、実際に生成しているスレッドの数を示す。
（＊）主記憶割当て９５９は、自身の計算ノード１００においてジョブＩＤ９５２のジョブのプロセスＩＤ９５１のプロセスに対して、実際に割当てている主記憶の記憶量を示す。
図８Ｅは、実施例１に係る統括スーパバイザプロセスにおけるタスクレベルの資源制約管理表の構成を示す。
タスクレベルの資源制約管理表９６０は、統括スーパバイザプロセスにより管理される。
タスクレベルの資源制約管理表９６０は、タスク毎の情報として、タスクＩＤ９６１、プロセスＩＤ９６２、ジョブＩＤ９６３、計算ノードＩＤ９６４、資源制約９６５を有する。資源制約９４４は、スレッド数９４５と、主記憶割当て９４６とを有する。各種情報は、下記の通りである。
（＊）タスクＩＤ９６１は、タスクのＩＤ（プロセスＩＤ）を示す。
（＊）プロセスＩＤ９６２は、プロセスのＩＤ（プロセスＩＤ）を示す。
（＊）ジョブＩＤ９６３は、ジョブＩＤを示す。
（＊）計算ノードＩＤ９６４は、ジョブＩＤ９６３のジョブのプロセスＩＤ９６２のプロセスのタスクＩＤ９６１のタスクを実行する計算ノードのＩＤ（計算ノードＩＤ）を示す。
（＊）資源制約９６５は、計算ノードＩＤ９６４の計算ノードにおけるジョブＩＤ９６３のジョブのプロセスＩＤ９６２のプロセスのタスクＩＤ９６１のタスクに対する資源の制約を示す。
（＊）スレッド数９６６は、計算ノードＩＤ９６４の計算ノードにおけるジョブＩＤ９６３のジョブのプロセスＩＤ９６２のプロセスのタスクＩＤ９６１のタスクに対する生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９６７は、計算ノードＩＤ９６４の計算ノードにおけるジョブＩＤ９６３のジョブのプロセスＩＤ９６２のプロセスのタスクＩＤ９６１のタスクに対する割当て可能な主記憶の最大の記憶量を示す。
図８Ｆは、実施例１に係る各ノードのスーパバイザプロセスにおけるタスクレベルの資源制約管理表の構成を示す。
タスクレベルの資源制約管理表９７０は、各計算ノード１００におけるスーパバイザプロセスにより管理される。
タスクレベルの資源制約管理表９７０は、自身の計算ノードにおける各ジョブにおける各プロセスの各タスクに対する情報として、タスクＩＤ９７１、プロセスＩＤ９７２、ジョブＩＤ９７３、計算ノードＩＤ９７４、資源制約９７５、及び資源利用９７６を有する。資源制約９７５は、スレッド数９７７と、主記憶割当て９７８とを有する。資源利用９７６は、スレッド数９７９と、主記憶割当て９８０とを有する。各種情報は、下記の通りである。
（＊）タスクＩＤ９７１は、タスクのＩＤを示す。
（＊）プロセスＩＤ９７２は、プロセスのＩＤを示す。
（＊）ジョブＩＤ９７３は、ジョブのＩＤを示す。
（＊）計算ノードＩＤ９７４は、自身の計算ノード１００のＩＤ（計算ノードＩＤ）を示す。
（＊）資源制約９７５は、自身の計算ノード１００におけるジョブＩＤ９７３のジョブのプロセスＩＤ９７２のプロセスのタスクＩＤ９７１のタスクに対する資源の制約を示す。
（＊）資源利用９７６は、自身の計算ノード１００においてジョブＩＤ９７３のジョブのプロセスＩＤ９７２のプロセスのタスクＩＤ９７１のタスクに対して利用している資源を示す。
（＊）スレッド数９７７は、自身の計算ノード１００におけるジョブＩＤ９７３のジョブのプロセスＩＤ９７２のプロセスのタスクＩＤ９７１のタスクに対する、生成可能な最大のスレッドの数を示す。
（＊）主記憶割当て９７８は、自身の計算ノード１００におけるジョブＩＤ９７３のジョブのプロセスＩＤ９７２のプロセスのタスクＩＤ９７１のタスクに対する、割当て可能な主記憶の最大の記憶量を示す。
（＊）スレッド数９７９は、自身の計算ノード１００においてジョブＩＤ９７３のジョブのプロセスＩＤ９７２のプロセスのタスクＩＤ９７１のタスクに対して、実際に生成しているスレッドの数を示す。
（＊）主記憶割当て９８０は、自身の計算ノード１００においてジョブＩＤ９７３のジョブのプロセスＩＤ９７２のプロセスのタスクＩＤ９７１のタスクに対して、実際に割当てている主記憶の記憶量を示す。
図８Ｇは、実施例１に係る統括資源制約管理処理の流れを示す。
Ｓ８１で、各計算ノード１００のスーパバイザプロセスを統括する計算ノード１００における統括スーパバイザプロセスは、新たにタスクを割り当てる際に、当該新たなタスクに対する資源制約を計算する。なお、ユーザが指定した資源制約としてもよいし、ユーザが指定したポリシーに基づいて資源制約を計算（例えば、比例配分）してもよい。
Ｓ８２で、統括スーパバイザプロセスは、図８Ｅに示すようなタスクレベルの資源制約管理表９６０に、新たなタスクに対するレコードを追加し、当該レコードの資源制約に対して計算した資源制約を格納する。また、統括スーパバイザプロセスは、資源制約の範囲でタスクを実行可能な計算ノード１００を選択し、当該計算ノード１００に対して、計算ノードに関わる資源制約を送信する。
Ｓ８３で、統括スーパバイザプロセスは、選択した計算ノード１００に対して、タスクを割り当てて、処理を終了する。
Ｓ８４で、タスクを割当てられた計算ノード１００のスーパバイザプロセスは、ステップＳ８２で送信された資源制約を受信し、当該資源制約を図８Ｆに示すようなタスクレベルの資源制約管理表９７０に登録する。
Ｓ８５で、タスクを割当てられた計算ノード１００のシステムモジュール１２０は、割り当てられたタスクを実行する。
図８Ｈは、実施例１に係る各計算ノードにおける資源制約管理処理の流れを示す。
資源制約管理処理は、例えば、システムモジュール１２０がタスクを実行することにより、実現される。図８Ｈの左上の処理（ステップＳ９０〜Ｓ９４）は、タスクにおいて、スレッドを生成しようとする際に実行される処理である。これは、例えば、図４ＡのＳ１３、図４ＢのＳ２４、Ｓ３１において実行される処理である。
Ｓ９０で、システムジュール１２０（具体的には、マップ関数１２１）は、スレッドを生成するのに十分な資源があるか否かを判断する。ここで、スレッドを生成するのに十分な資源があるか否かについては、タスクレベルの資源制約管理表９７０、プロセスレベルの資源制約管理表９５０、ジョブレベルの資源制約管理表９３０、及びノードレベルの資源制約管理表９１０のそれぞれを参照し、各レベルにおいて資源制約の範囲内で利用可能な資源が、スレッドを生成するのに十分な資源以上であるか否かにより判断することができる。
そして、この判断の結果が肯定的であれば、Ｓ９１を行う一方、この判断の結果が否定的であれば、Ｓ９３を行う。
Ｓ９１で、システムモジュール１２０は、スレッドマネージャ１３３によりスレッドを生成させて、当該スレッドに資源を割当てさせ、割当結果を各資源制約管理表（９１０、９３０、９５０、及び９７０）の資源利用に反映させる。
Ｓ９２で、システムモジュール１２０は、スレッドの実行を開始し、資源制約管理処理を終了する。
Ｓ９３で、システムモジュール１２０は、スレッドを生成するために参照するスレッド生成情報をスレッド生成保留管理表９９０に退避する。
Ｓ９４で、システムモジュール１２０は、自スレッドをスレッドの生成を保留している保留状態として処理を終了する。
スレッド生成保留管理表９９０は、スレッドの生成を保留しているスレッドの情報として、タスクＩＤ９９１、親スレッドＩＤ９９２、子スレッドＩＤ９９３、時刻９９４、及びスレッド生成情報９９５を有する。各種情報は、下記の通りである。
（＊）タスクＩＤ９９１は、タスクのＩＤを示す。
（＊）親スレッドＩＤ９９２は、他のスレッドを生成する親となるスレッド（親スレッド）のＩＤを示す。
（＊）子スレッドＩＤ９９３は、スレッドから生成される子となるスレッド（子スレッド）のＩＤを示す。
（＊）時刻９９４は、スレッドの生成を保留した時刻を示す。
（＊）スレッド生成情報９９５は、スレッドを生成する際に必要な情報（例えば、子スレッドで参照するレコードを示す参照を含む情報）である。
図８Ｈの右上の処理（ステップＳ９５〜Ｓ９６）は、スレッドにより実行する処理が終了した際に、スレッドを停止させる処理である。
Ｓ９５で、システムモジュール１２０は、実行している自スレッドを停止する。
Ｓ９６で、システムモジュール１２０は、自スレッドに割り当てられている資源を解放する。すなわち、システムモジュール１２０は、資源制約管理表９１０等の資源利用で管理されている資源量（スレッド数、主記憶割当て量）から、自スレッドに割当てられていた資源の量を削除する。これにより、自スレッドに割り当てられていた資源を、他のスレッドに割当てることができるようになる。
図８Ｈの右下の処理（ステップＳ９７〜Ｓ９９）は、例えば、資源制約管理表９１０に基づいて、スレッドを生成するのに十分な資源があることを判定した場合に実行される処理である。この手続きは、例えば、Ｓ９６によって資源が解放されたことに伴い、割り込みやシグナルなどの手段により、駆動されてもよい。
Ｓ９７で、システムモジュール１２０は、スレッド生成保留管理表９９０に管理されているスレッド生成情報を選択する。選択するスレッド生成情報としては、例えば、最古に保留されたスレッド生成情報であってもよい。
Ｓ９８で、システムモジュール１２０は、選択したスレッド生成情報によりスレッドを生成する親スレッドを再開する。
Ｓ９９で、システムモジュール１２０は、スレッド生成情報に基づいて、子スレッドの生成を再び実行する。この処理により、スレッドを生成するのに十分な資源がある場合に、生成を保留していたスレッドを生成することができる。
図９Ａは、実施例１に係るタスクの第１の例を示す。
図９Ａは、マップ・リデュースジョブ＃１（図１Ａのジョブ実行プランに対応）のマッププロセス＃１１１のマップタスク＃１１１１を示している。ここで、入力データセット＃１の＃１００１のレコードには、入力データセット＃２の＃２００１〜＃２０１０までの１０個のレコードに対する参照が含まれているものとする。また、マップタスク＃１１１１は、入力データセット＃１の＃１００１のレコードを取得し、入力データセット＃２のレコードを取得するものとする。
計算ノード１００が、マップタスク＃１１１１を実行すると、入力データセット＃１の＃１００１のレコードを参照し、当該レコードが所定の条件を満たしているとすると、当該レコードに含まれている参照を用いて、入力データセット＃２の＃２００１〜＃２０１０のレコードを取得する。
図９Ｂは、第１の例に示すタスクにおけるスレッドの生成の一例を示す。図９Ｂは、図９Ａに示すタスク＃１１１１を実行する際において、図８Ｈに示す資源制約管理処理を行わない場合におけるスレッドの生成を示している。なお、図９Ｂの表記は、次のルールに従う。
（＊）横軸は、時刻を表す。
（＊）図中の横に長い角丸四角形は、１つのスレッドによる一連の処理を意味する。角丸四角形の左端はスレッドによる処理を開始する時刻を表し、角丸四角形の右端は当該スレッドによる処理を終了する時刻を表す。
（＊）角丸四角形の内部の値は、スレッドに対応した処理に伴って読み込まれるレコードを示す情報（例えば、レコードＩＤ）を表す。
（＊）レコードを取得するスレッドについての同時に実行可能なスレッド数は、「８」とする。
図８Ｈに示す資源制約管理処理を行わない場合においては、入力データセット＃１の＃１００１のレコードを取得して処理を行うスレッド１０ａが実行されると、スレッド１０ａにより、＃１００１のレコードが取得され、当該＃１００１のレコードに含まれている参照に基づいて、入力データセット＃２の＃２００１のレコードを取得して処理を行うスレッド１０ｂが生成されて実行され、入力データセット＃２の＃２００２のレコードを取得して処理を行うスレッド１０ｃが生成されて実行され、同様にして、スレッド１０ｄ、スレッド１０ｅ、スレッド１０ｆ、スレッド１０ｇ、スレッド１０ｈが生成されて実行される。この時点においては、同時に実行可能なスレッド数である「８」と同数のスレッドが実行されることとなる。
この後、更に、スレッド１０ａにより、入力データセット＃２の＃２００８のレコードを取得して処理を行うスレッド１０ｉ、入力データセット＃２の＃２００９のレコードを取得して処理を行うスレッド１０ｊ、及び入力データセット＃２の＃２０１０のレコードを取得して処理を行うスレッド１０ｋが生成されて実行されることとなる。利用可能な量の主記憶を超えて主記憶の割り当てが行われ、スラッシングが発生してしまい、結果としてこれらスレッドに対する実行時間が長時間となってしまう。
図９Ｃは、実施例１に係る第１の例に示すタスクにおけるスレッドの生成の一例を示す。図９Ｃは、図９Ａに示すタスク＃１１１１を実行する際において、図８Ｈに示す資源制約管理処理を行う場合におけるスレッドの生成を示している。なお、図９Ｃの表記は、図９Ｂのルールと同様である。
計算ノード１００において、入力データセット＃１の＃１００１のレコードを取得して処理を行うスレッド１０ａが実行されると、スレッド１０ａにより、＃１００１のレコードが取得され、当該＃１００１のレコードに含まれている参照に基づいて、入力データセット＃２の＃２００１のレコードを取得して処理を行うスレッド１０ｂが生成されて実行され、入力データセット＃２の＃２００２のレコードを取得して処理を行うスレッド１０ｃが生成されて実行され、同様にして、スレッド１０ｄ、スレッド１０ｅ、スレッド１０ｆ、スレッド１０ｇ、スレッド１０ｈが生成されて実行される。この時点においては、同時に実行可能なスレッド数である「８」と同数のスレッドが実行されることとなる。
この後、資源制約管理処理のステップＳ９０で十分な資源がないと判定されるので、スレッド１０ａは、新たなスレッドを生成することなく、自スレッドが保留状態となる。そして、スレッド１０ｂの実行が終了した場合には、新たに１つのスレッドが実行可能となるので、ステップＳ９８でスレッド１０ａの実行が再開されて、ステップＳ９９で入力データセット＃２の＃２００８のレコードを取得して処理を行うスレッド１０ｉが生成される。同様にして、スレッド１０ｃの実行が終了した場合には、スレッド１０ａの実行が再開されて、入力データセット＃２の＃２００９のレコードを取得して処理を行うスレッド１０ｊが生成されて実行され、スレッド１０ｄの実行が終了した場合には、スレッド１０ａの実行が再開されて、入力データセット＃２の＃２０１０のレコードを取得して処理を行うスレッド１０ｋが生成されて実行される。
この結果、複数のスレッドの実行時に、利用可能な主記憶の量の範囲内で主記憶を割り当てることが可能となり、スラッシングが発生することを防止でき、タスク全体の実行時間を、図９Ｂに示す場合と比較して、短縮することができる。
次に、複数のタスクが並行して実行される場合におけるスレッドの生成について説明する。
図９Ｄは、実施例２に係るタスクの第２の例を示す。
図９Ｄは、マップ・リデュースジョブ＃１のマッププロセス＃１１１のマップタスク＃１１１１と、マップ・リデュースジョブ＃２のマッププロセス＃２１１のマップタスク＃２１１１とを示している。マップタスク＃１１１１と、マップタスク＃２１１１とは、並行して実行されるものとする。
入力データセット＃１の＃１００１のレコードには、入力データセット＃２の＃２００１〜＃２０１０までの１０個のレコードに対する参照が含まれているものとする。また、マップタスク＃１１１１は、入力データセット＃１の＃１００１のレコードを取得し、このレコードに対応する入力データセット＃２のデータを取得するものとする。
システムモジュール１２０は、マップタスク＃１１１１を実行すると、入力データセット＃１の＃１００１のレコードを参照し、当該レコードが所定の条件を満たしているとすると、当該レコードに含まれている参照を用いて、入力データセット＃２の＃２００１〜＃２０１０のレコードを取得する。
また、入力データセット＃５の＃５００１のレコードには、入力データセット＃６の＃６００１〜＃６０１０までの１０個のレコードに対する参照が含まれているものとする。また、マップタスク＃２１１１は、入力データセット＃５の＃５００１のレコードを取得し、このレコードに対応する入力データセット＃６のレコードを取得するものとする。
システムモジュール１２０は、マップタスク＃２１１１を実行すると、入力データセット＃５の＃５００１のレコードを参照し、当該レコードが所定の条件を満たしているとすると、当該レコードに含まれている参照を用いて、入力データセット＃６の＃６００１〜＃６０１０のレコードを取得する。
図９Ｅは、実施例１に係る第２の例に示すタスクにおけるスレッドの生成の一例を示す。図９Ｅは、図９Ｄに示すタスク＃１１１１と、タスク＃２１１１とを並行して実行する際において、図８Ｈに示す資源制約管理処理を行う場合におけるスレッドの生成を示している。ここで、タスク＃１１１１で利用可能な主記憶の領域は、５スレッド分であり、タスク＃２１１１で利用可能な主記憶の領域は、３スレッド分であるとする。なお、図９Ｅの表記は、図９Ｂのルールと同様である。
計算ノード１００において、入力データセット＃１の＃１００１のレコードを取得して処理を行うスレッド１１ａが実行されると、スレッド１１ａにより、＃１００１のレコードが取得され、当該＃１００１のレコードに含まれている参照に基づいて、入力データセット＃２の＃２００１のレコードを取得して処理を行うスレッド１１ｂが生成されて実行され、入力データセット＃２の＃２００２のレコードを取得して処理を行うスレッド１１ｃが生成されて実行され、同様にして、スレッド１０ｄ、スレッド１０ｅが生成されて実行される。この時点においては、タスク＃１１１１で利用可能な主記憶の５スレッド分の領域が使用されることとなる。
この後、資源制約管理処理のステップＳ９０で十分な資源がないと判定されるので、スレッド１１ａは、新たなスレッドを生成することなく、自スレッドが保留状態となる。そして、スレッド１１ｂの実行が終了した場合には、新たに１つのスレッドが実行可能となるので、ステップＳ９８でスレッド１１ａの実行が再開されて、ステップＳ９９で入力データセット＃２の＃２００５のレコードを取得して処理を行うスレッド１１ｆが生成される。同様にして、スレッド１１ｃの実行が終了した場合には、スレッド１１ａの実行が再開されて、入力データセット＃２の＃２００６のレコードを取得して処理を行うスレッド１１ｇが生成されて実行され、スレッド１１ｄの実行が終了した場合には、スレッド１１ａの実行が再開されて、入力データセット＃２の＃２００７のレコードを取得して処理を行うスレッド１１ｈが生成され、スレッド１１ｄの実行が終了した場合には、スレッド１１ａの実行が再開されて、入力データセット＃２の＃２００８のレコードを取得して処理を行うスレッド１１ｉが生成され、スレッド１１ｆの実行が終了した場合には、スレッド１１ａの実行が再開されて、入力データセット＃２の＃２００９のレコードを取得して処理を行うスレッド１１ｊが生成され、スレッド１１ｇの実行が終了した場合には、スレッド１１ａの実行が再開されて、入力データセット＃２の＃２０１０のレコードを取得して処理を行うスレッド１１ｋが生成される。
一方、入力データセット＃５の＃５００１のレコードを取得して処理を行うスレッド１２ａが並行して実行されると、スレッド１２ａにより、＃５００１のレコードが取得され、当該＃５００１のレコードに含まれている参照に基づいて、入力データセット＃６の＃６００１のレコードを取得して処理を行うスレッド１２ｂが生成されて実行され、入力データセット＃６の＃６００２のレコードを取得して処理を行うスレッド１２ｃが生成されて実行される。この時点においては、タスク＃２１１１に利用可能な主記憶の３スレッド分の領域が使用されることとなる。
この後、資源制約管理処理のステップＳ９０で十分な資源がないと判定されるので、スレッド１２ａは、新たなスレッドを生成することなく、自スレッドが保留状態となる。そして、スレッド１２ｂの実行が終了した場合には、新たに１つのスレッドが実行可能となるので、ステップＳ９８でスレッド１２ａの実行が再開されて、ステップＳ９９で入力データセット＃６の＃６００３のレコードを取得して処理を行うスレッド１２ｄが生成される。同様にして、スレッド１２ｃの実行が終了した場合には、入力データセット＃６の＃６００４のレコードを取得して処理を行うスレッド１２eが生成され、スレッド１２ｄの実行が終了した場合には、入力データセット＃６の＃６００５のレコードを取得して処理を行うスレッド１２ｆが生成され、スレッド１２ｅの実行が終了した場合には、入力データセット＃６の＃６００６のレコードを取得して処理を行うスレッド１２ｇが生成され、スレッド１２ｆの実行が終了した場合には、入力データセット＃６の＃６００７のレコードを取得して処理を行うスレッド１２ｈが生成され、スレッド１２ｇの実行が終了した場合には、入力データセット＃６の＃６００８のレコードを取得して処理を行うスレッド１２ｉが生成され、スレッド１２ｈの実行が終了した場合には、入力データセット＃６の＃６００９のレコードを取得して処理を行うスレッド１２ｊが生成され、スレッド１２ｉの実行が終了した場合には、入力データセット＃６の＃６０１０のレコードを取得して処理を行うスレッド１２ｋが生成される。このように、複数のタスクを並行して実行させることができる。
この結果、複数のタスクにおいて複数のスレッドの実行時に、各々のタスクで利用可能な主記憶の量の範囲内で主記憶を割り当てることが可能となり、スラッシングが発生することを防止でき、タスク全体の実行時間がスラッシングにより長時間化することを防ぐことができる。
上記では、資源の制約として、スレッド数、主記憶の例を示したが、本発明はこの例に限定されるものではない。例えば、プロセッサ実行時間、ストレージとの入出力スループット、ネットワークの伝送スループット等に関しても、同様に資源の制約を行うことにより、同様の効果を期待することができる。
以上、幾つかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
並列データ処理を実行する際に動的に生成するスレッドとしては、多様な実装形態が考えられ、例えば、プロセスであってもよいし、カーネルレベルのスレッド（ネイティブＰＯＳＩＸスレッドや軽量プロセス等、オペレーティングシステムのカーネルが管理するスレッド）であってもよいし、ユーザレベルのスレッド（ファイバ等のユーザプログラムやライブラリが管理するスレッド）であってもよいし、他と並行して実行することができるように管理される一定の手続きの集まり（例えば、関数ポインタを適当な構造体で管理するもの）であってもよいし、これらを組み合わせたものであってもよい。
本明細書では、並列データ処理が扱うデータの単位をレコードとしているが、レコードは任意のデータであってよい。例えば、一定個数のカラムの集まりであってもよいし、可変個数のカラムの集まりであってもよいし、単なるテキストであってもよいし、バイト列であってもよいし、画像や音声等のマルチメディアコンテンツであってもよいし、これらの集まりであってもよい。
１００…計算ノード、１１０…アプリケーション、１２０…システムモジュール

Claims (17)

  1. 複数の計算機で並行してデータ処理を実行する計算機システムにおける１つの計算機が有する並列データ処理システムであって、
    複数の第１データを含む第１データ群と複数の第２データを含む第２データ群とを含むデータ群からデータを読み込んで処理を実行する並列データ処理実行部
    を有し、
    前記並列データ処理実行部は、
    （Ａ）前記第１データ群から、前記第１データを読み込み、アプリケーションから取得した第１書式情報に基づいて、前記第１データから第１の値を取得し、
    （Ｂ）前記アプリケーションから取得した第１参照情報に基づき、前記第１の値に対応する１以上の前記第２データのそれぞれを前記第２データ群から読み込むための１以上のスレッドを生成し、
    （Ｃ）前記（Ａ）〜前記（Ｂ）を、前記第１データ群の１以上の第１データに対して実行し、
    （Ｄ）複数の前記スレッドを並行して実行する
    並列データ処理システム。
  2. 前記並列データ処理実行部は、
    （Ｅ）前記（Ｄ）でスレッドを実行することにより前記第２データを読み込み、アプリケーションから取得した第２書式情報に基づいて、前記第２データから第２の値を取得する
    請求項１に記載の並列データ処理システム。
  3. 前記並列データ処理実行部は、
    前記第２の値により、前記アプリケーションから取得した第２条件を評価する
    請求項２に記載の並列データ処理システム。
  4. 前記並列データ処理実行部は、
    １つ以上の前記第２データから取得した前記第２の値から、出力データを生成する
    請求項２に記載の並列データ処理システム。
  5. 前記並列データ処理実行部は、
    前記第１の値により、前記アプリケーションから取得した第１条件を評価し、当該第１条件が満たされる場合に前記（Ｂ）を実行する
    請求項１に記載の並列データ処理システム。
  6. 前記第１参照情報は、前記第２データ群において前記第２データが格納されている物理的な位置を特定する情報を含む
    請求項１に記載の並列データ処理システム。
  7. 前記第１参照情報は、前記第２データ群において前記第２データを検索するための情報を含む
    請求項１に記載の並列データ処理システム。
  8. 前記第２データ群の少なくとも一部の第２データは、ネットワークを介して接続される別の計算機の記憶装置に格納されており、
    前記並列データ処理実行部は、
    前記スレッドを実行して、前記ネットワークを介して接続された前記別の計算機から前記第２データを取得する際に、前記別の計算機に対して、取得要求を送信して、前記記憶装置から前記第２データを取得する
    請求項１に記載の並列データ処理システム。
  9. 前記並列データ処理実行部は、
    複数のスレッドの実行により生成される同一の計算機に対する複数の取得要求を１つにまとめたブロック化取得要求を前記別の計算機に送信することにより、複数の前記第２データを取得する
    請求項８に記載の並列データ処理システム。
  10. 前記第１書式情報は、プログラムコードであり、
    前記並列データ処理実行部は、
    ユーザから所定のマークアップ言語で記述される第１書式情報の作成に必要なカタログ情報を受け付け、
    前記カタログ情報に基づいて、前記第１書式情報を作成する
    請求項１に記載の並列データ処理システム。
  11. 前記並列データ処理実行部は、前記並列データ処理実行部を有する計算機におけるスレッドの生成に関する資源制約情報に基づいて、新たなスレッドを生成すると、自身を構成する前記計算ノードにおけるスレッドの実行に利用される資源量が制約を超えると判断した場合には、前記スレッドの生成を保留する
    請求項１に記載の並列データ処理システム。
  12. 前記並列データ処理実行部は、並列データ処理における一部の段階を担当するプロセスにおけるスレッドの生成に関する資源制約情報に基づいて、新たなスレッドを生成すると、前記プロセスにおけるスレッドの実行に利用される資源量が制約を超える場合には、当該スレッドの生成を保留する
    請求項１に記載の並列データ処理システム。
  13. 処理の指示をアプリケーションから受け付ける受付部を更に有し、
    前記アプリケーションからの前記指示は、手続を規定しており、
    前記並列データ処理実行部は、前記指示を受けて、前記（Ａ）乃至（Ｄ）を実行することにより、前記指示が、前記手続を規定していても、前記手続に依存しない非順序の処理を実行する、
    請求項１に記載の並列データ処理システム。
  14. 複数の計算機で並行してデータ処理を実行する計算機システムにおける計算機であって、
    前記計算機システムにおける別の計算機と通信するための通信インタフェースデバイスと、
    前記通信インタフェースデバイスに接続されており、複数の第１データを含む第１データ群と複数の第２データを含む第２データ群とを含むデータ群からデータを読み込んで処理を実行する制御デバイスと
    を有し、
    前記制御デバイスは、
    （Ａ）前記第１データ群から、前記第１データを読み込み、アプリケーションから取得した第１書式情報に基づいて、前記第１データから第１の値を取得し、
    （Ｂ）前記アプリケーションから取得した第１参照情報に基づき、前記第１の値に対応する１以上の前記第２データのそれぞれを前記第２データ群から読み込むための１以上のスレッドを生成し、
    （Ｃ）前記（Ａ）〜前記（Ｂ）を、前記第１データ群の１以上の第１データに対して実行し、
    （Ｄ）複数の前記スレッドを並行して実行する
    計算機。
  15. 複数の計算機で並行してデータ処理を実行する計算機システムでの並列データ処理方法であって、
    （Ａ）複数の第１データを含む第１データ群と複数の第２データを含む第２データ群とを含むデータ群のうちの前記第１データ群から、前記第１データを読み込み、アプリケーションから取得した第１書式情報に基づいて、前記第１データから第１の値を取得し、
    （Ｂ）前記アプリケーションから取得した第１参照情報に基づき、前記第１の値に対応する１以上の前記第２データのそれぞれを前記第２データ群から読み込むための１以上のスレッドを生成し、
    （Ｃ）前記（Ａ）〜前記（Ｂ）を、前記第１データ群の１以上の第１データに対して実行し、
    （Ｄ）複数の前記スレッドを並行して実行する
    並列データ処理方法。
  16. 複数の計算機を有し、
    各計算機が、
    複数の第１データを含む第１データ群と複数の第２データを含む第２データ群とを含むデータ群からデータを読み込んで処理を実行する並列データ処理システム
    を有し、
    各計算機の並列データ処理システムは、
    （Ａ）前記第１データ群から、前記第１データを読み込み、アプリケーションから取得した第１書式情報に基づいて、前記第１データから第１の値を取得し、
    （Ｂ）前記アプリケーションから取得した第１参照情報に基づき、前記第１の値に対応する１以上の前記第２データのそれぞれを前記第２データ群から読み込むための１以上のスレッドを生成し、
    （Ｃ）前記（Ａ）〜前記（Ｂ）を、前記第１データ群の１以上の第１データに対して実行し、
    （Ｄ）複数の前記スレッドを並行して実行する
    計算機システム。
  17. 複数の計算機で並行してデータ処理を実行する計算機システムでの計算機が実行するコンピュータプログラムであって、
    （Ａ）複数の第１データを含む第１データ群と複数の第２データを含む第２データ群とを含むデータ群のうちの前記第１データ群から、前記第１データを読み込み、アプリケーションから取得した第１書式情報に基づいて、前記第１データから第１の値を取得し、
    （Ｂ）前記アプリケーションから取得した第１参照情報に基づき、前記第１の値に対応する１以上の前記第２データのそれぞれを前記第２データ群から読み込むための１以上のスレッドを生成し、
    （Ｃ）前記（Ａ）〜前記（Ｂ）を、前記第１データ群の１以上の第１データに対して実行し、
    （Ｄ）複数の前記スレッドを並行して実行する
    ことを前記計算機に実行させるコンピュータプログラム。
JP2014518181A 2012-05-31 2012-05-31 並列データ処理システム、計算機および並列データ処理方法 Active JP5881025B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/064149 WO2013179451A1 (ja) 2012-05-31 2012-05-31 並列データ処理システム、計算機および並列データ処理方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2016009689A Division JP6097910B2 (ja) 2016-01-21 2016-01-21 並列データ処理システム、計算機および並列データ処理方法

Publications (2)

Publication Number Publication Date
JPWO2013179451A1 JPWO2013179451A1 (ja) 2016-01-14
JP5881025B2 true JP5881025B2 (ja) 2016-03-09

Family

ID=49672705

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014518181A Active JP5881025B2 (ja) 2012-05-31 2012-05-31 並列データ処理システム、計算機および並列データ処理方法

Country Status (4)

Country Link
US (1) US9841989B2 (ja)
EP (1) EP2857975A4 (ja)
JP (1) JP5881025B2 (ja)
WO (1) WO2013179451A1 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9501483B2 (en) 2012-09-18 2016-11-22 Mapr Technologies, Inc. Table format for map reduce system
JP5939123B2 (ja) * 2012-10-09 2016-06-22 富士通株式会社 実行制御プログラム、実行制御方法および情報処理装置
US10114674B2 (en) * 2014-03-06 2018-10-30 International Business Machines Corporation Sorting database collections for parallel processing
WO2015157338A1 (en) * 2014-04-08 2015-10-15 RedPoint Global Inc. Data transformation system and method
CN107329846B (zh) * 2017-07-11 2020-06-12 深圳市信义科技有限公司 基于大数据技术的大指数据比对方法
US10489348B2 (en) 2017-07-17 2019-11-26 Alteryx, Inc. Performing hash joins using parallel processing
US10552452B2 (en) * 2017-10-16 2020-02-04 Alteryx, Inc. Asynchronously processing sequential data blocks
US10558364B2 (en) 2017-10-16 2020-02-11 Alteryx, Inc. Memory allocation in a data analytics system
CN111651489A (zh) * 2020-06-05 2020-09-11 厦门理工学院 一种大数据处理服务器系统

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7756919B1 (en) 2004-06-18 2010-07-13 Google Inc. Large-scale data processing in a distributed and parallel processing enviornment
US7669015B2 (en) * 2006-02-22 2010-02-23 Sun Microsystems Inc. Methods and apparatus to implement parallel transactions
JP5229731B2 (ja) * 2008-10-07 2013-07-03 インターナショナル・ビジネス・マシーンズ・コーポレーション 更新頻度に基づくキャッシュ機構
JP5427640B2 (ja) * 2010-02-22 2014-02-26 日本電信電話株式会社 決定木生成装置、決定木生成方法、及びプログラム
US9170848B1 (en) * 2010-07-27 2015-10-27 Google Inc. Parallel processing of data
EP2629198A4 (en) 2010-10-14 2014-04-16 Nec Corp DISTRIBUTED TREATMENT DEVICE AND DISTRIBUTED TREATMENT SYSTEM
US8782053B2 (en) * 2011-03-06 2014-07-15 Happy Cloud Inc. Data streaming for interactive decision-oriented software applications
US9720708B2 (en) * 2011-08-19 2017-08-01 Advanced Micro Devices, Inc. Data layout transformation for workload distribution

Also Published As

Publication number Publication date
EP2857975A1 (en) 2015-04-08
US9841989B2 (en) 2017-12-12
WO2013179451A1 (ja) 2013-12-05
US20150113535A1 (en) 2015-04-23
JPWO2013179451A1 (ja) 2016-01-14
EP2857975A4 (en) 2016-03-02

Similar Documents

Publication Publication Date Title
JP5881025B2 (ja) 並列データ処理システム、計算機および並列データ処理方法
Abbasi et al. Extending i/o through high performance data services
Sim et al. Analyzethis: an analysis workflow-aware storage system
US10826848B2 (en) Balanced, opportunistic multicore I/O scheduling from non-SMP applications
Skiadopoulos et al. DBOS: a DBMS-oriented Operating System
KR101765725B1 (ko) 대용량 방송용 빅데이터 분산 병렬처리를 위한 동적 디바이스 연결 시스템 및 방법
Tannir Optimizing Hadoop for MapReduce
Aggarwal et al. Small files’ problem in Hadoop: A systematic literature review
Sundarakumar et al. A comprehensive study and review of tuning the performance on database scalability in big data analytics
Shan et al. KubeAdaptor: a docking framework for workflow containerization on Kubernetes
Salehian et al. Comparison of spark resource managers and distributed file systems
Luan et al. Exoshuffle: An extensible shuffle architecture
Fukutomi et al. GPUhd: Augmenting YARN with GPU resource management
JP6097910B2 (ja) 並列データ処理システム、計算機および並列データ処理方法
Al-Kiswany et al. A cross-layer optimized storage system for workflow applications
Zhao et al. Gpu-accelerated cloud computing for data-intensive applications
Pan The performance comparison of hadoop and spark
Ho et al. A mapreduce programming framework using message passing
JP5031538B2 (ja) データ分配方法、データ分配プログラム、及び並列データベースシステム
Kaur et al. Omr: Out-of-core mapreduce for large data sets
Ludwig Research trends in high performance parallel input/output for cluster environments
JP6210501B2 (ja) データベース管理システム、計算機、データベース管理方法
Reddy et al. An efficient traffic-aware partition and aggregation for big data applications using map-reduce
Varma Survey on MapReduce and scheduling algorithms in Hadoop
Wadhwa Scalable Data Management for Object-based Storage Systems

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20151104

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20151127

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20151222

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160121

R150 Certificate of patent or registration of utility model

Ref document number: 5881025

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150