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

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/466Transaction processing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2453Query optimisation
    • G06F16/24532Query optimisation of parallel queries
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/54Interprogram 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をはじめとする並列データ処理システムが用いられている。当該並列データ処理システムは、例えば、特許文献1に開示されている。
米国特許第7756919号明細書
Hadoopをはじめとする並列データ処理システムにおいては、ストレージ等に格納されたデータセット(例えばファイルシステムに格納されたファイル)の全体を読み込んで処理することを基本としている。例えば、アプリケーション(ジョブ)が処理の対象とするデータに選択性を有する場合(即ち、ストレージ等に格納されたデータセットのうち一部のレコードを処理の対象とする場合)であっても、データセットの全体を読み込む必要があり、データ処理が必ずしも効率的でなく行われ、よってデータ処理に係る時間が長くなる場合がある。また、データセットが巨大化するに従い、データセットの全体を読み込むのに要する時間が長くなり、よってデータ処理に係る時間が長くなる場合がある。
そこで、本発明の目的は、データ処理に係る時間を短縮することにある。
複数の計算ノード(例えば、計算機)において並行してデータ処理を実行する計算機システムにおける1つの計算ノードが有する並列データ処理システムが、複数の第1データを含む第1データ群と複数の第2データを含む第2データ群とを含むデータ群からデータを読み込んで処理を実行する並列データ処理実行部を有する。並列データ処理システムは、例えば、後述する実施例1及び2におけるシステムモジュールでよい。第1データ群における第1データが、第2データ群の第2データに対応していてよい。例えば、第1データ群は第2データ群の索引であってよい。この際、第1データは、第2データの索引鍵の値と、当該索引鍵の値に対応する1以上の第2データへの参照を含んでよい。
並列データ処理実行部は、
(A)第1データ群から、第1データを読み込み、アプリケーションから取得した第1書式情報に基づいて、第1データから第1の値を取得し、
(B)アプリケーションから取得した第1参照情報に基づき、第1の値に対応する1以上の第2データのそれぞれを第2データ群から読み込むための1以上のスレッドを生成し、
(C)(A)〜(B)を、第1データ群の1以上の第1データに対して実行し、
(D)複数の前記スレッドを並行して実行する。
並列データ処理システムは、処理の指示をアプリケーションから受け付ける受付部を更に有していてよい。アプリケーションからの指示は、一般に、手続を規定しているが、並列データ処理実行部は、アプリケーションからの指示を受けて、(A)乃至(D)を実行することにより、アプリケーションからの指示が、手続を規定していても、並列データ処理システムは、手続に依存しない非順序の処理を実行することができる。
本発明によれば、計算ノードはデータ処理に係るデータの読み込みを並行して実行することができるようになる。これにより、データ読み込みのスループットが向上し、故に、データ処理に係る時間が短縮されることが期待される。
図1Aは、実施例1に係るジョブ実行モデルを示す。 図1Bは、実施例2に係るジョブ実行モデルを示す。 図2Aは、実施例1に係る計算ノードの構成を示す。 図2Bは、実施例2に係る計算ノードの構成を示す。 図3Aは、実施例に係る計算機システムの第1の構成例を示す。 図3Bは、実施例に係る計算機システムの第2の構成例を示す。 図4Aは、実施例1に係るマップタスク実行処理の流れを示す。 図4Bは、実施例2に係るタスク実行処理の流れを示す。 図5Aは、実施例1に係る入力データ及び入力データに対する処理を説明するための図である。 図5Bは、実施例1に係る書式及び参照の一例を示す。 図5Cは、スレッド生成及びスレッドの実行を説明する模式図の一例である。 図5Dは、実施例2に係る入力データ及び入力データに対する処理を説明するための第1の図である。 図5Eは、実施例2に係る入力データ及び入力データに対する処理を説明するための第2の図である。 図5Fは、実施例2に係る書式の一例を示す。 図5Gは、実施例2に係る参照方式の一例を示す。 図5Hは、実施例2に係るカタログの一例を示す。 図6Aは、データ取得時のセッションを説明するための模式図の一例である。 図6Bは、変形例に係るデータ取得時のブロック化セッションを説明するための模式図の一例である。 図7Aは、実施例1に係るレコードを取得する計算ノードにおけるレコード取得処理の流れを示す。 図7Bは、実施例1に係るレコードを管理する計算ノードにおけるレコード取得処理の流れを示す。 図7Cは、実施例1に係るデータ読み込み要求管理表及びリモートレコード取得要求管理表の構成を示す。 図7Dは、実施例1の変形例に係るレコードを取得する計算ノードにおけるレコード取得処理の流れを示す。 図7Eは、実施例1の変形例に係るレコードを管理する計算ノードにおけるレコード取得処理の流れを示す。 図7Fは、実施例1の変形例に係るブロック化リモートレコード取得要求管理表の構成を示す。 図8Aは、実施例1に係るノードレベルの資源制約管理表の構成を示す。 図8Bは、実施例1に係るジョブレベルの資源制約管理表の構成を示す。 図8Cは、実施例1に係る統括スーパバイザプロセスにおけるプロセスレベルの資源制約管理表の構成を示す。 図8Dは、実施例1に係る各ノードのスーパバイザプロセスにおけるプロセスレベルの資源制約管理表の構成を示す。 図8Eは、実施例1に係る統括スーパバイザプロセスにおけるタスクレベルの資源制約管理表の構成を示す。 図8Fは、実施例1に係る各ノードのスーパバイザプロセスにおけるタスクレベルの資源制約管理表の構成を示す。 図8Gは、実施例1に係る統括資源制約管理処理の流れを示す。 図8Hは、実施例1に係る各ノードにおける資源制約管理処理の流れを示す。 図9Aは、実施例1に係るタスクの第1の例を示す。 図9Bは、実施例1に係る第1の例に示すタスクにおけるスレッドの生成の一例を示す。 図9Cは、実施例1に係る第1の例に示すタスクにおけるスレッドの生成の一例を示す。 図9Dは、実施例1に係るタスクの第2の例を示す。 図9Eは、実施例1に係る第2の例に示すタスクにおけるスレッドの生成の一例を示す。
以下、図面を参照しながら、幾つかの実施例及び変形例を説明する。なお、以下の説明により本発明が限定されるものではない。
まず、実施例1に係るジョブ実行モデルを説明する。
図1Aは、実施例1に係るジョブ実行モデルを示す。なお、図1Aにおいては、1つの実線の円は1つのプロセス(例えば、マッププロセスやリデュースプロセス)を示す。プロセス内の1つの破線の円は1つのタスクを示す。タスク中の1つの角丸四角は1つのスレッドを示す。
当該ジョブ実行モデルによれば、ジョブはネットワークで接続された複数の計算ノードによって実行される。例えば、複数の計算ノードの全体を統括する計算ノードにおけるスーパバイザプロセス(以下、統括スーパバイザプロセスとする)が、ジョブの実行に参加する全計算ノードにアプリケーションのコードを配布し、統括スーパバイザプロセスが各計算ノードのスーパバイザプロセスに対してマッププロセスやリデュースプロセスなどのプロセスの割り当てを行う。各計算ノードのスーパバイザプロセスは、統括スーパバイザプロセスの指示に基づいて、プロセスを生成する。また、生成されたプロセスは、統括スーパバイザプロセスの指示に基づいて、タスクを生成する。各計算ノードは、このように生成されたプロセス及びタスクを実行することにより、アプリケーションに含まれるマップ演算等を実行して、ジョブを実行する。統括スーパバイザプロセスは、複数の計算ノードにおける複数のスーパバイザプロセスのいずれか1つであってもよいし(即ち、いずれか1つのスーパバイザプロセスが、統括スーパバイザプロセスを兼ねてもよいし)、複数のスーパバイザプロセスとは別に用意された、専用の統括スーパバイザプロセスとして機能する専用のプロセスであってもよい。また、プロセスの割り当ては上記に限らず、統括スーパスーパバイザプロセスが各計算ノードのスーパバイザプロセスに指示を行って行ってもよく、プロセスやタスクの生成は上記に限らず、統括スーパバイザプロセスが直接行ってもよい。
並列データ処理システムは、ジョブ実行モデルに従い、マッププロセスを実行し、ストレージに格納された入力データセット#1(即ち、第1のデータセット)と入力データセット#2(即ち、第2のデータセット)とに含まれるレコードを読み込んで、マップ演算を実行し、その結果レコードをストレージに格納された中間データセットに書き込む。更に、リデュースプロセスを実行し、中間データセットに書き込まれた結果レコードを入力として、リデュース演算を実行し、その結果レコードを出力データセット#1に書き込む。入力データセット、中間データセットならびに出力データセットはそれぞれ複数のレコードの集まりであり、何らかのデータ構造によって構造化されていてもよいし、構造化されていなくてもよい。例えば、入力データセット#2は、1以上のファイルの集合であってもよい。
入力データセット#1はそのレコードが、入力データセット#2のレコードに対応したものであればよい。例えば、入力データセット#1は、入力データセット#2の索引であってもよい。入力データセット#1の各レコードは、入力データセット#2のレコードの所定の索引鍵の値と、当該索引鍵の値に対応する入力データセット#2の1以上のレコードを示す参照を含んでよい。この際、参照は入力データセット#2のレコードを記憶装置上で特定可能な格納位置を含んでもよいし、入力データセット#2を格納するのに設けられたデータ構造上においてレコードを特定可能な唯一性のある索引鍵を含んでもよい。また、入力データセット#1は入力データセット#2の全てのレコードに対応するレコードを有していてもよいし、入力データセット#2の一部のレコードに対応するレコードのみを有していてもよい。また、入力データセット#1は、入力データセット#2の索引でなくてもよい。例えば、入力データセット#1と入力データセット#2は結合可能な関係にあり、入力データセット#1は単なるレコードの集まりであり、入力データセット#2はレコードの集まりであって、データ構造によってある索引鍵によって構造化されており、入力データセット#1のあるレコードのある項目の値に対応するような、索引鍵の値を有する入力データセット#2のレコードを読み込むものであってもよい。また、入力データセット#1と入力データセット#2は、同じデータ構造に属するものであってもよい。例えば、入力データセット#1はB木を構成する内部ノードの集合であり、入力データセット#2は同じB木を構成する葉ノードの集合であってもよい。更に、入力データセット#1はB木を構成するあるレベルのノードの集合であり、入力データセット#2は同じB木を構成する次のレベルの(入力データセット#1から参照される)ノードの集合であってもよい。また、入力データセットは3つ以上から構成されてもよく、例えば、更に、入力データセット#2のレコードに対応した別の入力データセットがあってもよい。
マッププロセスにおいては、マップ演算、分割演算、書式#1、書式#2、参照方式、条件等に従い、各計算ノードのプロセッサによりデータ処理が実行される。マップ演算、分割演算、書式#1、書式#2、参照方式、条件等は、計算ノードに格納されているアプリケーションに含まれるプログラムコードである。マップ演算は、読み込んだレコードに対して適用される処理を規定するプログラムコードであり、例えば、読み込んだレコードからキーとバリューのペアからなる結果レコードを生成するものである。分割演算は、マップ演算を実行したのち、その実行結果を受け渡すリデュースプロセスを決定する際に実行されるプログラムコードであり、例えば、分割演算はマップ演算の結果レコードが含むキーに対するハッシュ演算などを含んでよい。書式#1は、入力データセット#1のレコードを解釈するための書式を規定するプログラムコードである。書式#2は、入力データセット#2のレコードを解釈するための書式を規定するプログラムコードである。参照方式は、入力データセット#1のレコードの参照に従い、入力データセット#2のレコードを取得する方式を規定するプログラムコードである。条件は、入力データセット#1及び/又は入力データセット#2に格納されたレコードのうちマップ演算の対象とするべきレコードの要件を規定するプログラムコードである。当該条件は、その全部もしくは一部が、入力データセット#1ならびに入力データセット#2のいずれかからレコードを読み込む際に実行されてもよいし、その全部もしくは一部が、読み込んだレコードをマップ演算に入力する際に実行されてもよい。なお、プログラムコードは、コンパイル等によって生成されたプロセッサで実行可能な命令であってもよいし、実行処理系等によってプロセッサで実行可能な命令に変換することができる命令であってもよいし、実行処理系等によってプロセッサで実行可能な命令を生成することのできる宣言であってもよい。更に、これらを組み合わせたものであってもよいし、他の情報を更に含んでよい。命令ならびに宣言は、プロセッサ、コンパイラもしくは実行処理系等が解釈可能なバイト列であってもよいし、ソースコート等で記述されていてもよい。
具体的に説明すると、計算ノードのプロセッサは、マッププロセスにおいてタスクを実行し、当該タスクにおいて、入力データセット#1からレコードを読み込み、書式#1を用いてレコードを解釈し、条件に基づいて、当該レコードが要件を満たすかどうかを判定し、要件を満たしたレコードから入力データセット#2への参照を取得する。この際、入力データセット#1は、事前に複数のチャンクに分割されていてもよい。例えば、入力データセット#1は複数のファイルから構成されていてもよく、統括スーパバイザプロセスが各々のファイルに対して別のタスクを割り当て、各タスクは割り当てられたファイルからレコードを読み込むこととしてもよい。もしくは、入力データセット#1は、実行時に複数のチャンクから構成されているかの如く分割可能であってもよい。例えば、入力データセット#1は単一のファイルから構成されており、当該ファイル中の複数の重なりのない領域を示す情報を備えており、統括スーパバイザプロセスがそれぞれの領域を先述のチャンクとして見做して別のタスクを割り当て、各タスクは割り当てられた領域からレコードを読み込むこととしてもよい。領域を示す情報は事前に与えられていてもよく、もしくは、統括スーパバイザプロセスによって実行時に決定されてもよい。また、領域と別の領域の間に重なりがあっても、読み込む際に一方の領域に割り当てられたタスクが重なり部分を読み込まないようにする手段が具備されていてもよい。また、入力データセット#1からレコードを読み込む際に、入力データセット#1が条件に規定された要件を満足するレコードに対して選択的なアクセスを可能とするデータ構造を以って構成されている(例えば、整列されている、もしくはB木等で構成されている)場合には、条件に規定された要件を用いて選択的なアクセスを行ってよい。
次いで、プロセッサは、入力データセット#1のレコードが含む参照に基づいて入力データセット#2からレコードを読み込むためにスレッドを生成する。入力データセット#1のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット#1のレコードが有する参照の各々に対してスレッドを生成してもよい。これらのスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式に基づいて、参照によって入力データセット#2のレコードを読み込む。プロセッサは、書式#2を用いて読み込んだレコードを解釈し、条件に基づいて当該レコードが要件を満たすかどうかを判定する。プロセッサは、要件を満たすレコードに対して、マップ演算を実行し、更に、分割演算を実行することによりマップ演算の実行結果を送るべきリデュースプロセスを決定する。プロセッサは、決定したリデュースプロセスがマップ演算の実行結果を受け取れるように出力する。具体的には、実行結果を中間データセットに格納する。
リデュースプロセスにおいては、リデュース演算等に従い、各計算ノードのプロセッサによりデータ処理が実行される。リデュース演算は計算ノードに格納されているアプリケーションに含まれたプログラムコードである。リデュース演算は、中間データセットのレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算の生成した結果レコード(キーとバリューのペアからなる)をキーに従って集約することにより結果レコードを生成するものである。
具体的には、プロセッサは、中間データセットからマップ演算の実行結果レコードを取得し、当該レコードを入力として、リデュース演算を実行して、その実行結果レコードを出力データセット#1に格納する。
マップ演算、分割演算、書式#1、書式#2、参照方式、条件、リデュース演算はその全てがアプリケーションで規定されている必要はなく、その一部が規定されていればよい。規定されていないものについては、所定の取り扱いを行ってよい。例えば、リデュース演算が規定されていない場合は(即ち、リデュースプロセスが規定されていない場合は)、マッププロセスの出力をジョブの出力と見做してよい。
マッププロセス及び/又はリデュースプロセスでは、更に比較演算に従い、また、マッププロセスでは、更に集約演算に従い、各計算ノードのプロセッサによりデータ処理が実行されてもよい。比較演算、集約演算は、計算ノードに格納されているアプリケーションに含まれるプログラムコードである。比較演算は、マッププロセスにおいて分割演算の結果レコードを中間データセットに書き込む際に、もしくは、リデュースプロセスにおいてリデュース演算の入力レコードを中間データセットから読み込む際に、結果レコード/入力レコードを一旦、整列するために当該レコード間の順序性を規定するためのものである。例えば、比較演算は、マップ演算が生成した結果レコード(キーとバリューのペアからなる)のキーの値の大小を比較するものである。比較演算はアプリケーションによって規定されなくてもよいし、マッププロセスもしくはリデュースプロセスのどちらか一方のために規定されてもよいし、また、両方のプロセスに同じ比較演算が規定されてもよいし、両方のプロセスに異なる比較演算が規定されてもよい。集約演算は、マッププロセスにおいて分割演算の結果レコードを中間データセットに書き込む際に、結果レコードを一旦、集約するためのものである。例えば、集約演算は、マップ演算が生成した結果レコード(キーとバリューのペアからなる)のキーに従って集約することにより結果レコードを生成するものである。集約演算はアプリケーションによって規定されなくてもよい。マッププロセスに対して、比較演算と集約演算が規定されてもよい。この場合、例えば、比較演算に従って整列された結果レコードに対して集約演算が行われてもよい。
マッププロセスでは、複数の異なるデータセットからのレコードを並行して、もしくは逐次的に入力してもよい。例えば、上記の例では、入力データセット#1から参照された入力データセット#2からレコードを読み込み、マップ演算への入力としていたが、更に、別に入力データセット#1−2から参照された入力データセット#2−2からレコードを読み込み、マップ演算への入力としてもよい。この際、書式#1、書式#2、参照方式、条件は、同じものを用いてもよいし、別のものを用いてもよい。
図1Aでは、文献 Jeffrey Dean, Sanjay Ghemawat: MapReduce: Simplified Data Processing on Large Clusters. Proceedings of OSDI 2004, pp. 137-15 (2004) に示されるマッププロセスとリデュースプロセスから構成されるジョブ実行モデルを示していたが、他のジョブ実行モデルであってもよい。例えば、図1Aでは、入力データセットを2段とした例を示すが、入力データセットは、2段以上であってもよい。また、図1Aでは、マッププロセスとリデュースプロセスの2つのステージのプロセスで構成されたジョブ実行モデルを示していたが、3以上のステージのプロセスで構成されたジョブ実行モデルであってもよい。また、図1Aでは、先頭のマッププロセスのみがストレージに格納された入力データセットからレコードを読み込むようにしていたが、例えば、それ以外のステージのプロセスがストレージの入力データセットからレコードを読み込むようにしてもよい。また、図1Aでは、マッププロセスはその結果レコードを一旦中間データセットに書き込み、リデュースプロセスが当該中間データセットから結果レコードを読み込むことにより、マッププロセスからリデュースプロセスへとレコードの受け渡しを行うようにしていたが、マッププロセスを実行する際に、マップ演算の結果レコードを中間データセットに格納せずにネットワークを通じて送信し、リデュースプロセスを実行する際に、当該マップ演算の結果レコードをネットワークを通じて受信してもよい。マッププロセスとリデュースプロセスを並行して実行してもよい。また、リデュースプロセスを実行する際に、リデュース演算の結果レコードを出力データセットに書き込まずに、コンソールやプリンタに出力してもよいし、ネットワークを経由して他の計算機等に送信してもよい。マッププロセスはその結果レコードをネットワークを通じてリデュースプロセスに送信し、リデュースプロセスはネットワークを通じて結果レコードを受信してもよい。このように拡張されたジョブ実行モデルの一例は、文献 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) に開示されている。
次に、実施例2に係るジョブ実行モデルを説明する。
図1Bは、実施例2に係るジョブ実行モデルを示す。なお、図1Bは図1Aと同様に表記されている。実施例2に係るジョブ実行モデルは実施例1に係るジョブ実行モデルを拡張したものであり、実施例1に関して説明した部分は、改めて説明せずとも、実施例2に適用される。
このジョブ実行モデルによれば、ジョブはネットワークで接続された複数の計算ノードによって実行される。図1Bに例示するジョブは、ステージ#1プロセスを実行することにより、入力データセット#1、入力データセット#2、入力データセット#3、及び入力データセット#4からレコードを読み込み、これを入力として、ステージ演算#1を実行し、その実行結果レコードをステージ#2プロセスに送信する。また、ステージ#2プロセスを実行することにより、実行結果レコードを受信し、これを入力としてステージ演算#2を実行し、その実行結果レコードをステージ#3プロセスに送信する。更に、ステージ#3プロセスを実行することにより、実行結果レコードを受信し、これを入力としてステージ演算#3を実行し、その実行結果レコードをステージ#4に送信する。加えて、ステージ#4プロセスを実行することにより、実行結果レコードを受信するとともに、入力データセット#5及び入力データセット#6からレコードを読み込み、これらを入力レコードとしてステージ#4演算を実行し、実行結果レコードを出力データセット#1に格納する。実施例1と同様に、異なるステージのプロセスの間では、中間データセットを経てデータを受け渡してもよいし、ネットワークによってデータを送受信してもよい。また、異なるステージのプロセスは並行して実行してもよい。
入力データセット#1は、入力データセット#2の索引であってもよい。例えば、入力データセット#1の各レコードは、入力データセット#2のレコードの所定の索引鍵の値と、当該索引鍵の値に対応する入力データセット#2の1以上のレコードを示す参照を含んでよい。同様に、入力データセット#3は、入力データセット#4の索引であってよい。入力データセット#3の各レコードは、入力データセット#4のレコードの所定の索引鍵の値と、当該索引鍵の値に対応する入力データセット#4の1以上のレコードを示す参照を含んでよい。また、入力データセット#2のレコードの所定の項目は、入力データセット#3の1以上のレコードを示す参照を含んでよい。即ち、入力データセット#2のあるレコードに対して入力データセット#3の1以上のレコードを対応させることが可能であってよい。実施例1と同様に、参照は参照先の入力データセットのレコードを記憶装置上で特定可能な格納位置を含んでもよいし、参照先の入力データセットを構成するデータ構造においてレコードを特定可能な唯一性のある索引鍵を含んでもよい。また、参照元の入力データセットは参照先の入力データセットの全てのレコードに対応するレコードを有していてもよいし、参照先の入力データセットの一部のレコードに対応するレコードのみを有していてもよい。
入力データセット#5は、入力データセット#6の索引であってもよい。入力データセット#5の各レコードは、入力データセット#6のレコードの所定の索引鍵の値と、当該索引鍵の値に対応する入力データセット#6の1以上のレコードを示す参照を含んでよい。
ステージ#1プロセスにおいては、ステージ演算#1、分割演算#1、書式#1、書式#2、書式#3、書式#4、参照方式#1、参照方式#2、参照方式#3、条件#1、ビルド方式#1等に従い、各計算ノードのプロセッサにより処理が実行される。ステージ演算#1、分割演算#1、書式#1、書式#2、書式#3、書式#4、参照方式#1、参照方式#2、参照方式#3、条件#1、ビルド方式#1等は、計算ノードに格納されているアプリケーションに含まれたプログラムコードである。ステージ演算#1は、読み込んだレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。分割演算#1は、演算結果を受け渡す後続のステージのプロセスを決定する際に実行されるプログラムコードである。例えば、分割演算は入力に対するハッシュ関数などを含んでよい。書式#1、書式#2、書式#3ならびに書式#4は、それぞれ入力データセット#1、入力データセット#2、入力データセット#3ならびに入力データセット#4のレコードを解釈するための書式を規定するプログラムコードである。参照方式#1、参照方式#2ならびに参照方式#3は、それぞれ入力データセット#1、入力データセット#2ならびに入力データセット#3のレコードの参照に従い、入力データセット#2、入力データセット#3ならびに入力データセット#4のレコードを取得する方式を規定するプログラムコードである。条件#1は、ステージ演算#1の対象とするべきレコードの条件を規定する手続きである。条件#1は、その全部もしくは一部が、入力データセット#1、入力データセット#2、入力データセット#3ならびに入力データセット#4のいずれかからレコードを読み込む際に実行されてもよいし、その全部もしくは一部が、読み込んだレコードをマップ演算に入力する際に実行されてもよい。ビルド方式#1は、入力データセット#1、入力データセット#2、入力データセット#3ならびに入力データセット#4から読み込んだレコードからステージ演算#1に入力するレコードを生成する方式を規定するプログラムコードである。
具体的に説明すると、計算ノードのプロセッサは、ステージ#1プロセスにおいてタスクを実行し、当該タスクにおいて、入力データセット#1からレコードを読み込み、書式#1を用いてレコードを解釈し、条件#1に基づいて、当該レコードが要件を満足するかどうかを判定し、要件を満足するレコードから入力データセット#2への参照を取得する。
次いで、プロセッサは、入力データセット#1のレコードが含む参照に基づいて入力データセット#2からレコードを読み込むためにスレッドを生成する。入力データセット#1のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット#1のレコードが有する参照の各々に対してスレッドを生成してもよい。これらスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式#1に基づいて、参照によって入力データセット#2からレコードを読み込む。プロセッサは、書式#2を用いて読み込んだレコードを解釈し、条件#1に基づいて、当該レコードが要件を満足するかどうかを判定する。更にプロセッサは、要件を満足するレコードから入力データセット#3への参照を取得する。ここで、プロセッサは、参照を用いて入力データセット#3を参照して処理を行うスレッドを生成する。複数の参照がある場合には、プロセッサは、複数のスレッドを生成する。これらスレッドは、プロセッサにより並行して実行される。
更に次いで、プロセッサは、入力データセット#2のレコードが含む参照に基づいて入力データセット#3からレコードを読み込むためにスレッドを生成する。入力データセット#2のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット#2のレコードが有する参照の各々に対してスレッドを生成してもよい。これらスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式#2に基づいて、参照によって入力データセット#3からレコードを読み込む。プロセッサは、書式#3を用いて、読み込んだレコードを解釈し、条件#1に基づいて、当該レコードが要件を満足するかどうかを判定する。更にプロセッサは、要件を満足するレコードから入力データセット#4への参照を取得する。
更に次いで、プロセッサは、入力データセット#3のレコードが含む参照に基づいて入力データセット#4からレコードを読み込むためにスレッドを生成する。入力データセット#3のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット#3のレコードが有する参照の各々に対してスレッドを生成してもよい。これらスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式#3に基づいて、参照によって入力データセット#4からレコードを読み込む。プロセッサは、書式#4を用いて読み込んだレコードを解釈し、条件#1に基づいて、当該レコードが要件を満足するかどうかを判定する。プロセッサは、要件を満足するレコードに対して、ビルド方式#1に基づいて、ステージ演算#1に入力するレコードを生成し、当該レコードを入力としてステージ演算#1を実行する。更に、1以上のステージ演算#1の実行結果レコードに対して分割演算#1を行うことにより、実行結果レコードを送るべき後続のステージ#2のプロセスを決定する。プロセッサは、決定した後続のステージのプロセスが実行結果レコードを受け取れるように出力する。具体的には、実行結果を中間データセットに格納するか、ネットワークで後続のステージのプロセスに送る。
ステージ#2プロセスにおいては、ステージ演算#2、分割演算#2に従い、各計算ノードのプロセッサにより処理が実行される。ステージ演算#2、分割演算#2は計算ノードに格納されているアプリケーションに含まれたプログラムコードである。例えば、ステージ演算#2は、中間データセットから取得したレコード又はネットワークで送られたレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。分割演算#2は、実行結果を受け渡す後続のステージ#3のプロセスを決定する際に実行されるプログラムコードである。例えば、分割演算#2は入力に対するハッシュ関数などを含んでよい。
具体的に説明すると、計算ノードのプロセッサは、ステージ#2プロセスにおいてタスクを実行し、当該タスクにおいて、ステージ#1プロセスから受け渡されたレコードを取得し、ステージ演算#2を実行し、更に分割演算#2を行うことにより、ステージ演算#2の実行結果レコードを送るべき後続のステージ#3のプロセスを決定する。プロセッサは、決定した後続のステージのプロセスがステージ演算#2の実行結果レコードを受け取れるように出力する。具体的には、実行結果を中間データセットに格納するか、ネットワークで後続のステージのプロセスに送る。
ステージ#3プロセスにおいては、ステージ演算#3、分割演算#3に従い、各計算ノードのプロセッサにより処理が実行される。ステージ演算#3、分割演算#3は計算ノードに格納されているアプリケーションに含まれたプログラムコードである。例えば、ステージ演算#3は、中間データセットから取得したレコード又はネットワークで送られたレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。分割演算#3は、実行結果を受け渡す後続のステージ#4のプロセスを決定する際に実行されるプログラムコードである。例えば、分割演算#3は入力に対するハッシュ関数などを含んでよい。
具体的に説明すると、計算ノードのプロセッサは、ステージ#3プロセスにおいてタスクを実行し、当該タスクにおいて、ステージ#2プロセスから受け渡されたレコードを取得し、ステージ演算#3を実行し、更に分割演算#3を行うことにより、ステージ演算#3の実行結果レコードを送るべき後続のステージ#4のプロセスを決定する。プロセッサは、決定した後続のステージのプロセスがステージ演算#3の実行結果レコードを受け取れるように出力する。具体的には、実行結果を中間データセットに格納するか、ネットワークで後続のステージのプロセスに送る。
ステージ#4プロセスにおいては、ステージ演算#4、書式#5、書式#6、参照方式#4等に従い、各計算ノードのプロセッサにより処理が実行される。ステージ演算#3、分割演算#3、書式#5、書式#6、参照方式#4は計算ノードに格納されているアプリケーションに含まれたプログラムコードである。例えば、ステージ演算#4は、中間データセットから取得したレコード又はネットワークで送られたレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。書式#5ならびに書式#6は、それぞれ入力データセット#5ならびに入力データセット#6のレコードを解釈するための書式を規定するプログラムコードである。参照方式#4は、入力データセット#5のレコードの参照に従い、入力データセット#6のレコードを取得する方式を規定するプログラムコードである。
更に、具体的に説明すると、計算ノードのプロセッサは、ステージ#4プロセスにおいてタスクを実行し、当該タスクにおいて、入力データセット#5からレコードを読み込み、書式#5を用いてレコードを解釈し、レコードから入力データセット#6への参照を取得する。
次いで、プロセッサは、入力データセット#5のレコードが含む参照に基づいて入力データセット#6からレコードを読み込むためにスレッドを生成する。入力データセット#5のレコードが複数の参照を含む場合には、プロセッサは、複数のスレッドを生成する。例えば、入力データセット#5のレコードが有する参照の各々に対してスレッドを生成してもよい。これらスレッドは、プロセッサにより並行して実行される。更に、プロセッサは、実行するスレッドにおいて、参照方式#4に基づいて、参照によって入力データセット#6からレコードを読み込む。プロセッサは、書式#6を用いて読み込んだレコードを解釈する。また、ステージ演算#3の実行結果であるレコードを取得する。これらのレコードを入力として、ステージ演算#4を実行し、その実行結果レコードを出力データセット#1に格納する。
実施例1と同様に、ステージ演算#1、分割演算#1、書式#1、書式#2、書式#3、書式#4、参照方式#1、参照方式#2、参照方式#3、条件#1、ビルド方式#1、ステージ演算#2、分割演算#2、ステージ演算#3、分割演算#3、ステージ演算#4、書式#5、書式#6、参照方式#4はその全てがアプリケーションで規定されている必要はなく、その一部が規定されていればよい。規定されていないものについては、所定の取り扱いを行ってよい。
実施例1と同様に、各ステージのプロセスでは、更に比較演算、集約演算に従い、各計算ノードのプロセッサによりデータ処理が実行されてもよい。
各ステージのプロセスでは、複数の異なるデータセットからのレコードを並行して、もしくは逐次的に入力してもよい。
以上、実施例1及び2に係るジョブ実行モデルを説明した。ジョブ実行モデルは、それらに限定されない。
実施例1及び2に係るジョブ実行モデルについての共通点は、例えば以下の通りである。
Hadoopをはじめとする並列データ処理システムでは、一般に、記憶空間におけるデータ群は構造化されない。これに対して、実施例1および実施例2によれば、ストレージ(例えば、ファイルシステム)において、複数の第1のレコードで構成される第1のデータセット(例えば、入力データセット#1)は、複数の第2のレコードで構成される第2のデータセット(例えば、入力データセット#2)に対して関連付けられる。具体的には、例えば、第1のデータセットは、第2のデータセットのうちにデータ処理に要する第2のレコードを特定するための索引である。即ち、第1のデータセットは構造化されているが、第2のデータセットは構造化されていなくてもよい。第1のデータセットが構造化されていることにより、それに関連付けられた第2のデータセットは、仮にそれが構造化されていない場合であっても、第2のデータセットのうちにデータ処理に要する第2のレコードを特定してアクセスすることが可能となる。また、別の例を挙げるとすると、第1のデータセットと第2のデータセットはそれぞれのレコードを結合することできる関係である。即ち、第1のデータセットは構造化されておらず、第2のデータセットが構造化されていてもよい。第2のデータセットが構造化されていることにより、それに関連付けられた第1のデータセットのレコードに対応する第2のレコードを選択的に抽出することが可能となる。
この際、実施例1および実施例2によれば、第1のデータセットの書式に関する情報(例えば書式#1)や、第2のデータセットの書式に関する情報(例えば書式#2)や、第1のレコードに基づいて第2のレコードを参照する方式に関する情報(例えば参照方式)をはじめとする情報がアプリケーションにより用意される。当該情報は、例えばプログラムコードである。当該情報は、個々のアプリケーションとは独立して別のプログラム(例えば後述するシステムモジュール等)が有してもよい。しかしながら、アプリケーションが個々にこれを用意することができることにも利点が認められる。例えば、データベース管理システム(DBMS;Database Management System)は、ストレージ空間におけるデータ群(テーブル)をリレーショナルモデルに基づき管理する。書式や参照方式等のカタログ情報は、アプリケーションとは独立に管理される。この場合、例えば、レコードのカラムの型は既にDBMSが用意している型(例えば、整数や文字列等)から選択することとなるが、アプリケーションによってはDBMSが既に備えている型以外の型を以ってカラムを解釈することが望ましい場合がある。アプリケーションが個々に書式や参照方式等の情報を用意することができることは、データ処理システムとしての柔軟性の観点から利点が認められる場合がある。また、DBMSにおいては、一般に、データ集合(テーブル)における全てのレコードは、与えられたカタログ情報に厳密に従っていることを要請される。しかしながら、あるデータ集合に置いて特定の日時以降から記録されるレコードにカラムを追加するような場合にも、原則として、データ集合(テーブル)の全てのレコードにカラムを追加する必要がある。即ち、当該カラムを要しない特定の日付以前のレコードについても、(例えば空の)カラムを追加する必要がある。通常、このような操作には、データ集合(テーブル)を再構成や再編成する処理を要し、データ集合(テーブル)が大規模になるとその処理に係る時間は無視できない。他方で、アプリケーションが書式や参照方式等の情報を用意することができるとすると、アプリケーションによって特定の日付以前のレコードと特定の日付以降のレコードで異なる書式や参照方式等の情報を用意することができる。即ち、データ集合自体を変更することなく、アプリケーションを変更することによって、レコード書式の変更に柔軟にデータ処理を対応させることが可能となり、利点が認められる場合がある。
また、実施例1および実施例2によれば、アプリケーションの規定したデータ処理のジョブ情報に基づき、アプリケーションとは別のプログラム(例えばシステムモジュール)が第1のデータセットから第1のレコードを読み込んで、当該レコードを当該ジョブ情報に基づき解釈し、それに基づきスレッドを生成して実行し、各スレッドにおいて更に第2のデータセットから第2のレコードを読み込み、読み込んだレコードに対してジョブ情報に規定された演算を実行することが可能となる。計算ノードはアプリケーションの規定したジョブ情報に従って、データ処理に係るデータ読み込みを並行して実行することができるようになる。これにより、データ読み込みのスループットが向上し、故に、データ処理に係る時間が短縮されることが期待される。
以下、実施例1及び2を詳細に説明する。実施例2は実施例1を拡張したものであり、実施例1に関して説明した部分は、改めて説明せずとも、実施例2に適用される。
図2Aは、実施例1に係る計算ノードの構成を示す。図2Aは、図1Aに示すジョブ実行モデルに従いデータ処理を行う計算ノードの構成を示す。
計算ノード100は、パーソナルコンピュータ、ワークステーション、サーバ又はメインフレームなどの計算機であってよい。また、計算ノード100は、計算機に装着して用いられる画像処理装置(GPU;Graphical Processing Unit)などを具備する補助演算機器(例えば、画像処理装置(GPU)カード)であってもよいし、計算機や補助演算機器において仮想化ソフトウェアや仮想化ハードウェア等によって構成された仮想的な計算機であってもよい。
計算ノード100は、通信インタフェースと、記憶装置と、それらに接続された演算装置とを有する。通信インタフェースとしては、例えば、NIC(Network interface card)102と、HBA(host bus adapter)103とがある。記憶装置としては、例えば、ストレージ104と、メモリ105とがある。演算装置は、例えばプロセッサ(CPU;Central Processing Unit)101である。制御装置は、プロセッサ以外に、専用の処理(例えば暗号化又は復号化)を行うハードウェア回路を含んでもよい。プロセッサ101、NIC102、HBA103、及びメモリ105は、内部バス106を介して接続されている。ストレージ104は、HBA103に接続されている。
プロセッサ101は、コンピュータプログラムを実行する。NIC102は、ネットワーク200と計算ノード100とを接続する。ネットワーク200を介した通信のプロトコルとしては、例えば、TCP/IP(Transmission Control Protocol/Internet Protocol)が採用されてよい。HBA103は、ストレージ104への入出力を仲介する。
ストレージ104は、1つ以上の不揮発性の記憶媒体を含む。不揮発性の記憶媒体は、例えば、磁気ディスク或いはフラッシュメモリである。ストレージ104は、複数の不揮発性の記憶媒体を備え、更に当該不揮発性の記憶媒体から記憶空間を構成するRAID(Redundant ARRAY of Independent Disks)コントローラを備えてもよい。
メモリ105は、例えば、揮発性の記憶媒体(例えばDRAM(Dynamic Random Access Memory))であり、CPU101によって実行されるプログラムと、プログラムが使用するデータ等を記憶する。
メモリ105は、アプリケーションプログラム(以下、アプリケーション)110、システムモジュール120、プロセスマネージャ131、タスクマネージャ132、スレッドマネージャ133、データ読み書き器140、ネットワークマネージャ150、ストレージマネージャ160、及びOS(Operating System)170を格納する。なお、システムモジュール120、プロセスマネージャ131、タスクマネージャ132、スレッドマネージャ133、データ読み書き器140、ネットワークマネージャ150、ストレージマネージャ160(以下、個々のプログラムモジュールを総じてモジュール群と称する)はアプリケーション110と静的もしくは動的にリンクして実行されるライブライモジュールであってもよく、この場合、アプリケーション110からの指示もしくはモジュール群におけるプログラムモジュール間の相互の指示はモジュール群が開示する呼び出しインタフェースによる。また、モジュール群はアプリケーション110とは別個に動作するプログラムであってもよく、この場合、アプリケーション110からの指示はプロセス間通信や共有メモリ等の手段による。
アプリケーション110は、ストレージ104に格納された入力データセットを読み込んで所定の処理を実行し、出力データセットを書き込むジョブを規定するプログラムであり、計算ノードはアプリケーション110を実行することによって当該ジョブを実行する。アプリケーション110は、当該ジョブを規定する情報(以下、ジョブ情報とする)として、例えば、マップ演算110aと、リデュース演算110bと、分割演算110cと、書式110e(書式#1)と、書式110f(書式#2)と、条件110gとを含む。
マップ演算110aは、読み込んだレコードに対して適用される処理を規定するプログラムコードであり、例えば、読み込んだレコードからキーとバリューのペアからなる結果レコードを生成するものである。分割演算110cは、マップ演算を実行したのち、その実行結果を受け渡すリデュースプロセスを決定する際に実行されるプログラムコードであり、例えば、分割演算はマップ演算の結果レコードが含むキーに対するハッシュ演算などを含んでよい。書式110e(書式#1)は、入力データセット#1のレコードを解釈するための書式を規定するプログラムコードである。書式110f(書式#2)は、入力データセット#2のレコードを解釈するための書式を規定するプログラムコードである。参照方式110hは、入力データセット#1のレコードの参照に従い、入力データセット#2のレコードを取得する方式を規定するプログラムコードである。条件110gは、入力データセット#1及び/又は入力データセット#2に格納されたレコードのうちマップ演算の対象とするべきレコードの要件を規定するプログラムコードである。なお、アプリケーション110は、上述のプログラムコードを全て規定しなくてもよい。規定されていないものについては、所定の取り扱いを行ってよい。例えば、リデュース演算を備えない場合は、リデュースプロセスを実行されず、マッププロセスにおけるマップ演算の実行結果レコードがそのまま出力データセットに格納される。更に、アプリケーション110は比較演算(図示せず)、集約演算(図示せず)を規定してもよい。
システムモジュール120は、アプリケーション110とは独立しているもののアプリケーション110と連携して動作するプログラムモジュールであり、アプリケーション110からのジョブを実行する指示を受けて、アプリケーション110に規定されたジョブ情報に従いジョブを実行する。システムモジュール120は、アプリケーション110からジョブ実行の指示を受け付けるインタフェース部(図示せず)と、マップ関数121と、リデュース関数122と、スーパバイザ関数123とを含むエグゼキューション部とを有する。マップ関数121は、マッププロセスにおいて実行されるプログラムコード(関数)である。リデュース関数122は、リデュースプロセスにおいて実行されるプログラムコード(関数)である。スーパバイザ関数123は、スーパバイザプロセス(統括スーパバイザプロセスを含む)において実行されるプログラムコードである。システムモジュール120は、インタフェース部においてアプリケーション110からのジョブ実行の指示を受け付け、エグゼキューション部においてジョブを実行するのに要するプロセスを生成し、プロセスにおいて各関数を実行し、各関数を実行することによって、更にタスクとスレッドを生成して実行する。
システムモジュール120の詳細を述べる。各計算ノードのCPU101は、システムモジュール120によってスーパバイザプロセスを生成し、当該スーパバイザプロセスにおいてスーパバイザ関数123を実行する。上述のスーパバイザプロセスの生成は、事前に例えば計算ノードを起動することにより自動的に行われてもよいし、ジョブの実行を開始してから必要に応じて行われてもよい。ジョブを実行する複数の計算ノード100のスーパバイザプロセスのいずれかのスーパバイザプロセスは、複数の計算ノード100を統括する処理も行う。なお、複数の計算ノード100を統括するスーパバイザプロセスを統括スーパバイザプロセスという。なお、統括スーパバイザプロセスは、固定的にいずれかの計算ノード100のスーパバイザプロセスとしてもよく、複数の計算ノード100から選択した計算ノード100のスーパバイザプロセスとしてもよい。なお、計算ノード100以外の計算機に、統括スーパバイザプロセスを備えるようにしてもよい。
統括スーパバイザプロセスは、ジョブの実行に参加する全計算ノード100にアプリケーション110のコードを配布して、各スーパバイザプロセスに対してプロセスの割当てを行う。各ノードのスーパバイザプロセスは、統括スーパバイザプロセスの指示に基づいて、プロセスを生成する。統括スーパバイザプロセスは、ジョブ実行に参加する全計算ノードのスーパバイザプロセスの状態を把握する処理を行う。また、各スーパバイザプロセスは、自身の計算ノードにおけるジョブ実行に関わるプロセスの実行状態を把握する処理を行う。
プロセスマネージャ131は、システムモジュールからの指示に基づき、プロセスを実行するのに要するメモリ資源を管理する。即ち、プロセスの生成、削除ならびに実行状態等を管理する。タスクマネージャ132は、システムモジュールからの指示に基づき、タスクを実行するのに要するメモリ資源を管理する。即ち、タスクの生成、削除ならびに実行状態等を管理する。スレッドマネージャ133は、システムモジュールからの指示に基づき、スレッドを実行するのに要するメモリ資源を管理する。即ち、スレッドの生成、削除ならびに実行状態等を管理する。
データ読み書き器140は、システムモジュール120からの指示に基づき、ストレージへのデータの読み書きを行う。データ読み書き器140は例えばファイルシステムであってよい。例えば、データ読み書き器140は、指示されたデータ読み書きを行うのに自身の計算ノード100のストレージ104に対するデータ読み書きを要する場合には、ストレージマネージャ160により、ストレージ104に対してデータ読み書きを実行させ、ネットワーク200を介して接続された他の計算ノード100のストレージ104に対するデータ読み書きを要する場合には、ネットワークマネージャ150により、ネットワーク200を介して接続された他の計算ノード100のストレージ104に対してデータ読み書きを実行させる。この際、データ読み書き器140は、メモリ105のメモリ資源を用いて、読み書きするデータを一時的にキャッシュさせてもよい。
ネットワークマネージャ150は、ネットワークを介して接続された装置(例えば、他の計算ノード100等)とのデータ通信を制御する。ストレージマネージャ160は、自身の計算ノード100のストレージ104との入出力を制御する。OS170は、NIC102、HBA103、ストレージ104等の装置を管理するほか、計算ノード110の全体を管理する。
本明細書においては、プログラムやその一部の名称(例えば、アプリケーション、システムモジュール、プロセス、タスク、スレッド)を主語として発明の実施例ならび変形例を説明する場合がある。この場合においては、プログラムやその一部は、計算ノード100が具備する演算装置(例えばプロセッサ101)によって実行されることによって、定められた処理を、適宜に記憶装置(例えばメモリ105やストレージ104)及び/又は通信インタフェース(例えばNIC102やHBA103)を用いて行うものであるため、発明の実施例ならび変形例を説明する際の主語が演算装置、プロセッサ101もしくは計算ノード100であるとして解釈してもよい。また、プログラムやその一部は、ハードウェアで行われても良く、その場合には、発明の実施例ならび変形例を説明する際の主語がプロセッサ101に代えて又は加えてそのハードウェアであるとして解釈してもよい。システムモジュール120、プロセスマネージャ131、タスクマネージャ132、スレッドマネージャ133、データ読み書き器140、ネットワークマネージャ150、ストレージマネージャ160等のようなコンピュータプログラムは、プログラムソースから計算ノード100にインストールされてよい。プログラムソースは、例えば、計算ノード100が読み取り可能な記憶メディアであってもよいし、計算ノード100に通信可能に接続されている計算機であってもよい。
計算ノード100は、性能や可用性の観点から、CPU101、NIC102、HBA103の少なくとも1つの要素を複数備えていてもよい。また、計算ノード100は、入力デバイス(例えば、キーボード及びポインティングデバイス)(図示しない)と表示デバイス(例えば液晶ディスプレイ)(図示しない)とを有してよい。入力デバイスと表示デバイスは一体になっていてもよい。
図2Bは、実施例2に係る計算ノードの構成を示す。図2Bは、図1Bに示すジョブ実行モデルに従いデータ処理を行う計算ノードの構成を示す。
アプリケーション110は、ジョブ情報として、例えば、1以上のステージ演算110jと、1以上の分割演算110kと、1以上の書式110mと、1以上の条件110nと、1以上の参照方式110oと、1以上のビルド方式110pとを含む。
ステージ演算110jは、ジョブ実行モデルにおける各ステージのプロセスにおいて入力されたレコードに対して適用される処理を規定するプログラムコードであり、例えば、マップ演算であってもよいし、リデュース演算であってもよいし、他の演算であってもよい。図1Bのジョブ実行モデルの場合には、ステージ演算#1〜#4の4つのステージ演算が含まれる。分割演算110kは、実行結果レコードを受け渡す後続のステージのプロセスを決定する際に実行されるプログラムコードである。例えば、分割演算は入力に対するハッシュ演算などを含んでよい。書式110mは、各入力データセットのレコードを解釈するための書式を規定するプログラムコードである。図1Bに示すジョブ実行モデルを実行するアプリケーション110には、入力データセット#1〜#6までのそれぞれに対応する書式110mが格納されている。条件110nは、ステージ演算の対象とするべきレコードの要件を規定するプログラムコードである。参照方式110oは、ある入力データセットのレコードの参照に従い、参照先の入力データセットからレコードを取得する方式を規定するプログラムコードである。ビルド方式110pは、実行結果のレコードの作成方法を示す情報である。なお、アプリケーション110は、上述のプログラムコードを全て規定しなくてもよい。規定されていないものについては、所定の取り扱いを行ってよい。更に、アプリケーション110は比較演算(図示せず)、集約演算(図示せず)を規定してもよい。
システムモジュール120は、一般化ステージ関数124と、スーパバイザ関数122とを含む。一般化ステージ関数124は、図1Bに示す各プロセスにおいて実行されるプログラムコード(関数)である。
図3Aは、実施例に係る計算機システムの第1の構成例を示す。図3Bは、実施例に係る計算機システムの第2の構成例を示す。
計算機システムは、図3Aに示すように、NIC102を介してネットワーク200(例えば、Ethernet(登録商標)によるローカルエリアネットワーク)によって接続された複数の計算ノード100から構成されてもよい。また、計算機システムは、図3Bに示すように、NIC102を介してネットワーク200によって接続され、更に、HBA103を介してネットワーク300(例えば、FibreChannelによるストレージエリアネットワーク)によって1以上のストレージ400と接続される複数の計算ノード100から構成されてもよい。また、ストレージ400は、ネットワーク300ではなくネットワーク200に接続され、共有ファイルアクセス用の通信プロトコル(NFSやCIFS)によって入出力を行うものであってもよい。
ストレージ400は、1つ以上の不揮発性の記憶媒体を含む。不揮発性の記憶媒体は、例えば、磁気ディスク或いはフラッシュメモリである。ストレージ104は、複数の不揮発性の記憶媒体を備え、更に当該不揮発性の記憶媒体から記憶空間を構成するRAID(Redundant ARRAY of Independent Disks)コントローラを備えてもよい。ストレージ400のストレージ資源の全部もしくは一部は、計算ノード100が含むストレージ104と同様に扱ってよい。
図4Aは、実施例1に係るマップタスク実行処理の流れを示す。
このマップタスク実行処理は、図1Aに示すジョブ実行モデルにおけるマッププロセスにおいて実行されるマップタスクにおいて実行される処理を示す。
計算ノード100のプロセッサ101が、入力データセット#1のレコードを読み込んで処理を実行するための1つのスレッドSL1を実行することにより、ステップS10〜ステップS15の処理を実行する。この処理は、プロセッサ101が、主に、マップ関数121を実行することにより実現される。
S10で、プロセッサ101は、入力データセット#1から1つのレコードを取得する。ここで、入力データセット#1は、自身の計算ノード100のストレージ104に格納されている場合もあれば、他の計算ノード100のストレージ104に格納されている場合もある。なお、入力データセット#1からレコードを取得するレコード取得処理については、後述する。
S11で、プロセッサ101は、書式110e(書式#1)に基づいて、取得したレコードに含まれる各項目の内容を解釈し、取得したレコードに対して、条件110gに含まれる入力データセット#1のレコードに対する条件を適用することにより、当該レコードが条件を満足するか否かを判定し、必要であれば、S12に進む一方、必要でなければ、図示しないがS15に進む。S11では条件110gの一部が適用されてもよい。条件110gが規定されていない場合はそのままS12に進んでもよい。
S12で、プロセッサ101は、取得したレコードに、入力データセット#2への参照があるか否かを判断する。この判断の結果が肯定的であれば、S13を行う一方、この判断の結果が否定的であれば、S15を行う。
S13で、プロセッサ101は、取得したレコードの入力データセット#2への1つの参照について、入力データセット#2からレコードを取得して処理を行うためのスレッドSL2を生成する。
S14で、プロセッサ101は、取得したレコードに、更に未処理の入力データセット#2への参照があるか否かを判断する。この判断の結果が肯定的であれば、S13を行う一方、この判断の結果が否定的であれば、S15を行う。これにより、取得したレコードに、入力データセット#2への参照が複数あれば、S13によって、参照の数に応じたスレッドSL2が生成されることとなる。なお、スレッドの生成に必要な資源が不足する場合には、スレッドSL2の生成を一時的に保留してもよい。なお、この際、1つの参照の毎に1つのスレッドSL2を生成してもよいし、複数(例えば所定数)の参照の毎に1つのスレッドSL2を生成してもよい。
S15で、プロセッサ101は、入力データセット#1に更に他のレコードがあるか否かを判断する。この判断の結果が肯定的であれば、S10を行う一方、この判断の結果が否定的であれば、この処理を終了して、この処理を実行したスレッドSL1を停止する。
一方、S13でスレッドSL1により生成されたスレッドSL2は、CPU101によって実行される。プロセッサ101が、スレッドSL2を実行することにより、ステップS16〜ステップS19の処理を実行する。なお、本実施例では、プロセッサ101は、複数のスレッド(スレッドSL1、スレッドSL2等)を並行して実行することができる。計算ノード100は複数のプロセッサ101を備えており、あるプロセッサ101で生成したスレッドSL2が別のプロセッサ101で実行されてもよい。なお、並行実行可能なスレッドの数は、計算ノード100の資源等によって制限がある。
S16で、プロセッサ101は、参照方法110h及びスレッドSL1で取得された参照を用いて、入力データセット#2から1つのレコードを取得する。
S17で、プロセッサ101は、書式110f(書式#2)に基づいて、取得したレコードに含まれる各項目の内容を解釈し、取得したレコードに対して、条件110gに含まれる入力データセット#2のレコードに対する条件を適用することにより、当該レコードが必要であるか否かを判定し、必要であれば、S18に進む一方、必要でなければ、図示しないがS19に進む。S17では条件110gの一部が適用されてもよい。条件110gが規定されていない場合はそのままS18に進んでもよい。
S18で、プロセッサ101は、取得したレコードを、主記憶105の演算キュー180に格納する。
S19で、プロセッサ101は、入力データセット#2の参照で示される範囲に更に他のレコードがあるか否かを判断する。この判断の結果が肯定的であれば、S16を行う一方、この判断の結果が否定的であれば、この処理を終了して、この処理を実行したスレッドSL2を終了させる。
また、プロセッサ101は、S20で、演算キュー180から1つのレコードを取得し、当該レコードに対して、マップ演算110aを適用することにより、レコードに対して所定の処理を実行し、その実行結果を出力する。この際、プロセッサ101はS20をSL2とは別のスレッドにおいて実行してもよい。S20を実行するスレッドは1つであってもよく、複数であってもよい。演算キュー180から一括して複数のレコードを取得してマップ演算110aを適用してもよい。プロセッサ101はスレッドSL2においてS18を実行する代わりに、スレッドSL2においてS17を実行した後にS20を実行してS17の結果のレコードに対してマップ演算を適用してもよい。ここで、実行結果を出力する方法としては、例えば、実行結果を主記憶105に格納するようにしても良く、また、実行結果を後続の処理を実行するリデュースプロセスに渡すようにしてもよい。
なお、図4Aでは、入力データセット#1からレコードを読み込み、その処理を行うスレッドSL1と、入力データセット#2からレコードを読み込み、その処理を行うスレッドSL2を別に設けているが、スレッドSL1がスレッドSL2を生成せずにそのままS16からS19もしくはS20までに相当する処理を行ってもよい。また、所定の数のスレッドSL1を生成して、当該スレッドSL1によって入力データセット#1からレコードを読み込み、その処理を行ってもよい。更には、S15で更にレコードがあると判断した際に、新たにSL1を生成して、S10からS15に相当する処理を行ってもよい。
図4Bは、実施例2に係るタスク実行処理の流れを示す。
このタスク実行処理は、図1Bに示すジョブ実行モデルにおけるステージプロセスにおいて実行されるタスクにおいて実行される処理を示す。
計算ノード100のプロセッサ101が、入力データセット#dのレコードを読み込んで処理を実行するための1つのスレッドSLdを実行することにより、ステップS21〜ステップS26の処理を実行する。ここで、図1Bのステージ#1プロセスを実行するタスク実行処理においては、入力データセット#dは、入力データセット#1であり、入力データセット#dは、入力データセット#2である。また、図1Bのステージ#4プロセスを実行するタスク実行処理においては、入力データセット#dは、入力データセット#5であり、入力データセット#dは、入力データセット#6である。
S21で、プロセッサ101は、入力データセット#dから1つのレコードを取得する。ここで、入力データセット#dは、自身の計算ノード100のストレージ104に格納されている場合もあれば、他の計算ノード100のストレージ104に格納されている場合もある。なお、入力データセット#dからレコードを取得するレコード取得処理については、後述する。
S22で、プロセッサ101は、入力データセット#dのレコードに対応する書式110mに基づいて、取得したレコードに含まれる各項目の内容を解釈し、取得したレコードに対して、条件110nに含まれる入力データセット#dのレコードに対する条件を適用することにより、当該レコードが条件を満足するか否かを判定し、必要であれば、S23に進む一方、必要でなければ、図示しないがS26に進む。S22では条件110nの一部が適用されてもよい。条件110nが規定されていない場合はそのままS23に進んでもよい。
S23で、プロセッサ101は、取得したレコードに、入力データセット#dへの参照があるか否かを判断する。この判断の結果が肯定的であれば、S24を行う一方、この判断の結果が否定的であれば、S26を行う。
S24で、プロセッサ101は、取得したレコードの入力データセット#dへの1つの参照について、入力データセット#dからレコードを取得して処理を行うためのスレッドSLdを生成する。
S25で、プロセッサ101は、取得したレコードに、更に入力データセット#dへの参照があるか否かを判断する。この判断の結果が肯定的であれば、S24を行う一方、この判断の結果が否定的であれば、S26を行う。これにより、取得したレコードに、入力データセット#dへの参照が複数あれば、S24によって、参照の数に応じたスレッドSLdが生成されることとなる。なお、スレッドの生成に必要な資源が不足する場合には、スレッドSLdの生成を一時的に保留してもよい。なお、この際、1つの参照の毎に1つのスレッドSLdを生成してもよいし、複数(例えば所定数)の参照の毎に1つのスレッドSLdを生成してもよい。
S26で、プロセッサ101は、入力データセット#dに更に他のレコードがあるか否かを判断する。この判断の結果が肯定的であれば、S21を行う一方、この判断の結果が否定的であれば、この処理を終了して、この処理を実行したスレッドSLdを終了させる。
一方、S24及び後述するS31でスレッドSLdk-1から生成されたスレッドSLdは、プロセッサ101によって実行される。ここにkは2以上の自然数を表し、例えばk=2の場合にはSLdk−1はSLdを、SLdはSLdを、SLdk+1はSLdを表すものとする。プロセッサ101が、スレッドSLdを実行することにより、ステップS27〜ステップS35の処理を実行する。なお、本実施例では、プロセッサ101は、複数のスレッド(スレッドSLd、スレッドSLd等)を並行して実行することができる。計算ノード100は複数のプロセッサ101を備えており、あるプロセッサ101で生成したスレッドが別のプロセッサ101で実行されてもよい。なお、並行実行可能なスレッドの数は、計算ノード100の資源等によって制限がある。
S27で、プロセッサ101は、入力データセット#SLdk-1のレコードの参照及びこの参照を用いて入力データセット#SLdを参照するための参照方式110oに基づいて、入力データセット#SLdのレコードを取得する。
S28で、プロセッサ101は、書式110f(書式#d)に基づいて、取得したレコードに含まれる各項目の内容を解釈し、取得したレコードに対して、条件110nに含まれる入力データセット#dのレコードに対する条件を適用することにより、当該レコードが必要であるか否かを判定し、必要であれば、S29に進む一方、必要でなければ、図示しないがS35に進む。S28では条件110nの一部が適用されてもよい。条件110nが規定されていない場合はそのままS29に進んでもよい。
S29で、プロセッサ101は、更に入力データセット#dk+1へのアクセスを要するか否かを判断する。この判断の結果が肯定的であれば、S30を行う一方、この判断の結果が否定的であれば、S33に進む。例えば、図1Bのステージ#1プロセスでは、入力レコード#1からレコードを取得し、当該レコード中の参照に従い入力レコード#2からレコードを取得し、更に当該レコード中の参照に従い入力レコード#3からレコードを取得し、更に当該レコード中の参照に従い入力レコード#4からレコードを取得する必要がある。よって、k=2で生成されたスレッドSLd(SLd)で実行されるS29では、入力データセット#3へのアクセスを更に要するため、この判断は肯定的であり、k=3で生成されたスレッドSLd(SLd)で実行されるS29では、入力データセット#4へのアクセスを更に要するため、この判断は肯定的であり、k=4で生成されたスレッドSLd(SLd)で実行されるS29では、更なる入力データセットへのアクセスを要しないため、この判断は否定的となる。
S30で、プロセッサ101は、取得したレコードに、入力データセット#dk+1への参照があるか否かを判断する。この判断の結果が肯定的であれば、S31を行う一方、この判断の結果が否定的であれば、S35を行う。
S31で、プロセッサ101は、取得したレコードの入力データセット#dk+1への1つの参照について、入力データセット#dk+1からレコードを取得して処理を行うためのスレッドSLdk+1を生成する。
S32で、プロセッサ101は、取得したレコードに、更に入力データセット#dk+1への参照があるか否かを判断する。この判断の結果が肯定的であれば、S31を行う一方、この判断の結果が否定的であれば、S35を行う。これにより、取得したレコードに、入力データセット#dk+1への参照が複数あれば、S31によって、参照の数に応じたスレッドSLdk+1が生成されることとなる。なお、スレッドの生成に必要な資源が不足する場合には、スレッドSLdk+1の生成を一時的に保留してもよい。なお、この際、1つの参照の毎に1つのスレッドSLdk+1を生成してもよいし、複数(例えば所定数)の参照の毎に1つのスレッドSLdk+1を生成してもよい。
S33で、プロセッサs101は、取得したレコードと、ビルド方式110pとに基づいて、所定の形式のレコードをビルド(生成)する。
S34で、プロセッサ101は、ビルドしたレコードに対して、ステージ演算110jを適用することにより、所定の処理を実行し、その実行結果を出力する。この際、プロセッサ101はスレッドSLdにおいてS33を実行した後にS34を実行する代わりに、一旦、ビルドしたレコードを、主記憶105の演算キューに格納し、演算キューから1つのレコードを取得し、S34を実行して当該レコードに対して、ステージ演算110jを適用することにより、レコードに対して所定の処理を実行し、その実行結果を出力してもよい。この際、プロセッサ101はS34をSLdとは別のスレッドにおいて実行してもよい。S34を実行するスレッドは1つであってもよく、複数であってもよい。演算キューから一括して複数のレコードを取得してステージ演算110jを適用してもよい。
S35で、CPU101は、入力データセット#dの参照で示される範囲に更に他のレコードがあるか否かを判断する。この判断の結果が肯定的であれば、S27を行う一方、この判断の結果が否定的であれば、この処理を終了して、この処理を実行したスレッドSLdを中止する。
なお、図4Bでは、入力データセット#dk−1からレコードを読み込み、その処理を行うスレッドSLdk−1と、入力データセット#dからレコードを読み込み、その処理を行うスレッドSLdを別に設けているが、スレッドSLdk−1がスレッドSLdを生成せずにそのままS27からS35までに相当する処理を行ってもよい。また、所定の数のスレッドSLdを生成して、当該スレッドSLdによって入力データセット#1からレコードを読み込み、その処理を行ってもよい。更には、S26もしくはS35で更にレコードがあると判断した際に、新たにSLdもしくはSLdを生成して、S21からS26までに相当する処理もしくはS27からS35までに相当する処理を行ってもよい。
図5Aは、実施例1に係る入力データ及び入力データに対する処理を説明するための図である。
入力データセット#2は、「Date & time」、「User」、「Product」、「Comment」を含む1以上のレコードを格納する。
入力データセット#1は、「Product」と、「Reference」との項目を有する1以上のレコードが、年月ごとにまとめられて管理されている。即ち、入力データセット#1は年月によって分割されている。例えば、スーパバイザプロセスは、このまとめられた部分(分割部分)の毎に、マップタスク等を割り当てることにより、並列データ処理を行う。この際、1つのマップタスクが複数の分割部分を担当してもよい。
「Product」には、入力データセット#2におけるレコードの検索に使用する鍵となる項目(「Product」)の値が格納される。「Reference」には、入力データセット#2における当該レコードに対応する年月のレコードであって、当該レコード中の「Product」の値と同一の値を格納するレコード(参照先レコード)の物理的な格納位置を示す参照が格納される。なお、入力データセット#2に、複数の参照先レコードがある場合には、「Reference」には、複数の参照先レコードへの参照が格納される。なお、入力レコード#2はある鍵によってレコードを検索可能な構造(例えば、B木)を有してもよく、当該鍵の値を「Reference」に格納する参照としてもよい。ある1つの参照に複数のレコードが対応することがあってもよい。
入力データセット#1のレコードの書式は、書式#1に記述されている。
また、入力データセット#2のレコードの書式は、書式#2に記述されている。また、入力データセット#1の「Reference」を用いて、入力データセット#2のレコードを参照する方法については、参照方式#1に記述されている。
図1Aに示すジョブ実行モデルにおけるマッププロセスにおいては、プロセッサ101はマップ関数121を実行することにより、入力データセット#1のレコードを読み込み、書式#1により、レコードにおけるProductと、Referenceとを把握する。そして、マップ関数121は、Productの値に基づいて、所定の条件に合致するか否かを判断し、条件を満たすレコードのReferenceを特定する。そして、プロセッサ101はマップ関数121を実行することにより、参照方式#1と、Referenceとに基づいて、入力データセット#2のレコードを取得する。
図5Bは、実施例1に係る書式及び参照を説明するための図である。
書式#1は、入力データセット#1のレコードの書式に関する情報であり、本実施例では、入力データセット#1のレコードを解釈する手続きが記述されている。書式#1には、入力レコード(すなわち、入力データセット#1のレコード)をバイナリ形式で解釈し、入力レコードの各カラムを、Text型、Long型、Int型、Int型として解釈すること、第1(0)のカラムを検索鍵とすることが記述されている。ここでは、カラムの型はJava(登録商標)言語における型宣言を用いて標記しているが、本発明はこれに限定されるものではない。
書式#2は、入力データセット#2のレコードの書式に関する情報であり、本実施例では、入力データセット#2のレコードを解釈する手続きが記述されている。書式#2には、入力レコード(すなわち、入力データセット#2のレコード)をテキスト形式(文字列形式)で解釈することが記述されている。また、レコードにおけるカラム間の区切り文字は、カンマであり、第1(0)のカラムは、DateTime型であり、「Date & Time」と名付け、第2(1)のカラムは、Text型であり、「User」と名付け、第3(2)のカラムは、Text型であり、「Product」と名付け、第4(3)のカラムは、Text型であり、「Comment」と名付け、これらに基づいて入力カラムを解釈することが記述されている。
参照方式#1は、入力データセット#1の「Reference」を用いて、入力データセット#2のレコードを参照する方法についての手続きであり、入力レコード(書式#1に対応するレコード)の第2カラムをオフセットとし、第3カラムを長さとし、第4カラムをノードIDとして、物理参照により参照を行ってレコードを取得することが記述されている。ここで、物理参照は、指定されたノードIDが管理するストレージの指定されたオフセット(番地)を始点として、指定された長さ分のバイト列を、参照先のレコードとすることを意味する。
図5Cは、スレッド生成及びスレッドの実行を説明する模式図の一例である。図5Cの上側には、単一のスレッドによりプロセスを実行する場合の例を示し、図5Cの下側には、実施例1に係るスレッドを動的に生成し、複数スレッドを並行して実行する例を示す。なお、図5Cの表記は、次のルールに従う。
(*)横軸は、時刻を表す。
(*)図中の横に長い角丸四角形は、1つのスレッドによる一連の処理を意味する。角丸四角形の左端はスレッドによる処理を開始する時刻を表し、角丸四角形の右端は当該スレッドによる処理を終了する時刻を表す。
(*)角丸四角形の内部の値は、スレッドに対応した処理に伴って読み込まれるレコードを示す情報(例えば、レコードの先頭のカラムの値)を表す。
ここで、図5Cは、図5Aに示す2012年の2月(2012−Feb)に対応する入力データセット#1の各レコードを取得して、処理を実行する例を示している。
図5Cの上側の図に示すように、単一スレッドにより実行する場合においては、プロセッサは、入力データセット#1の2012年の2月(2012−Feb)に対応する上から2番目のレコード(「Product」の値が「AX Skirt)を読み込み、このレコードの「Reference」の値に基づいて、入力データセット#2の7番目のレコード(「2012−Feb−07 ・・・」)を参照し、入力データセット#1の上から3番目のレコード(「Product」の値が「BB Book」)を読み込み、このレコードの「Reference」の値に基づいて、入力データセット#2の8番目のレコード(「2012−Feb−08 ・・・」)を参照し、さらに、「Reference」の値に基づいて、入力データセット#2の10番目のレコード(「2012−Feb−08 ・・・」)を参照し、さらに、「Reference」の値に基づいて、入力データセット#2の11番目のレコード(「2012−Feb−08 ・・・」)を参照して処理を行っていく。即ち、ストレージからのレコードの読み込みとそれに対する処理は、逐次的に行われていく。
一方、本実施例においては、図5Cの下側の図に示すように、マップ関数121は、先ずスレッド5aにより、入力データセット#1の2012年の2月(2012−Feb)に対応する上から2番目のレコード(「Product」の値が「AX Skirt)を読み込み、このレコードの「Reference」の値に基づいて、入力データセット#2の7番目のレコード「2012−Feb−07 ・・・」)を参照するためのスレッド5bを生成して実行する。
次いで、マップ関数121は、スレッド5aにより、2012−Febに対応する入力データセット#1の上から3番目のレコード(「Product」の値が「AX Skirt)を読み込み、このレコードの「Reference」の4つの値に基づいて、入力データセット#2の8番目のレコード(「2012−Feb−08 ・・・」)を参照するためのスレッド5c、入力データセット#2の10番目のレコード(「2012−Feb−08 ・・・」)を参照するためのスレッド5d、入力データセット#2の11番目(「2012−Feb−08 ・・・」)のレコードを参照するためのスレッド5e、及び入力データセット#2の12番目のレコード(「2012−Feb−09 ・・・」)を参照するためのスレッド5fを順次生成して実行する。
次いで、マップ関数121は、スレッド5aにより、入力データセット#1の2012−Febに対応する上から4番目のレコード(「Product」の値が「BC Bike)を読み込み、このレコードの「Reference」の2つの値に基づいて、入力データセット#2の6番目のレコードを参照するためのスレッド5g、入力データセット#2の9番目のレコードを参照するためのスレッド5hを生成して実行する。
次いで、マップ関数121は、スレッド5aにより、2012−Febに対応する入力データセット#1の上から5番目のレコード(「Product」の値が「BD Flower)を読み込み、このレコードの「Reference」の1つの値に基づいて、入力データセット#2の5番目のレコード(「2012−Feb−03 ・・・」)を参照するためのスレッド5iを生成して実行する。
図5Cの下側図に示すように、スレッドを動的に生成し、当該スレッドにおいてレコードを読み込んで処理を行い、複数のスレッドを並行して実行することにより、単一のスレッドを実行する場合に比して、処理の実行時間を短縮することができる。 図5Dは、実施例2に係る入力データ及び入力データに対する処理を説明するための第1の図である。図5Eは、実施例2に係る入力データ及び入力データに対する処理を説明するための第2の図である。
実施例2に係るジョブ実行プランにおいては、入力データセット#2のレコードの値を用いて、更に、入力データセット#3のレコードを参照する。したがって、図5Dに示すように、アプリケーション110には、入力データセット#2のレコードの値(「User」の値)に基づいて、入力データセット#3を参照するための参照方式#2が更に備えられる。ここで、「User」の値は、当該値に対応する入力データセット#3のレコードの物理的な位置を示す参照ではなく、論理的な位置を示す(その値によって検索可能である)参照である。
図5Eには、入力データセット#3と、入力データセット#4とを示す。
入力データセット#4は、「User」、「Gender」、「Zip」、「Address」を含む1以上のレコードを格納する。
入力データセット#3は、「User」と、「Reference」との項目を有する1以上のレコードが、所定の範囲ごとにまとめられて管理されている。「User」には、入力データセット#4におけるレコードの検索に使用する鍵となる項目の値が格納される。「Reference」には、入力データセット#4における当該レコード中の「Product」の値と同一の値を格納するレコード(参照先レコード)の物理的な格納位置を示す参照が格納される。なお、入力データセット#3に、複数の参照先レコードがある場合には、複数の参照先レコードへの参照が格納される。なお、入力レコード#3はある鍵によってレコードを検索可能な構造(例えば、B木)を有してもよく、当該鍵の値を「User」に格納する参照としてもよい。ある1つの参照に複数のレコードが対応することがあってもよい。
入力データセット#3のレコードの書式は、書式#3に記述されている。また、入力データセット#4のレコードの書式は、書式#4に記述されている。また、入力データセット#3の「Reference」を用いて、入力データセット#4のレコードを参照する方法については、参照方式#3に記述されている。また、取得したレコードに基づいて、後続に出力するレコードを生成する手続きがビルド方式に記述されている。
図1Bに示すジョブ実行モデルにおけるステージ#1プロセスにおいては、プロセッサ101が一般化ステージ関数124を実行することにより、入力データセット#1のレコードを読み込み、書式#1により、レコードにおける「Product」と、「Reference」とを把握する。そして、一般化ステージ関数124は、「Product」の値に基づいて、所定の条件に合致するか否かを判断し、条件を満たすレコードの「Reference」を特定する。そして、一般化ステージ関数124は、参照方式#1と、「Reference」とに基づいて、入力データセット#2のレコードを取得する。
次いで、プロセッサ101が一般化ステージ関数124を実行することにより、書式#2により、読み込んだ入力データセット#2のレコードの「User」、「Product」、「Comment」を把握する。そして、一般化ステージ関数124は、「User」の値と、参照方法#2とに基づいて、入力データセット#3のレコードを取得する。
プロセッサ101が一般化ステージ関数124を実行することにより、書式#3により、取得した入力データセット#3のレコードにおける「Reference」を把握する。そして、一般化ステージ124は、参照方式#3と、「Reference」とに基づいて、入力データセット#4のレコードを取得する。
次いで、プロセッサ101が一般化ステージ関数124を実行することにより、書式#4により、読み込んだ入力データセット#4のレコードの「User」、「Gender」、「Zip」、「Address」を把握する。そして、プロセッサ101が一般化ステージ関数124を実行することにより、ビルド方式に基づいて、「User」,「Product」、「Comment」、「Gender」、「Zip」を含むレコードを構築して出力する。
図5Fは、実施例2に係る書式を説明するための図である。
書式#3は、入力データセット#3のレコードの書式に関する情報であり、本実施例では、入力データセット#3のレコードを解釈する手続きが記述されている。書式#3には、入力レコード(すなわち、入力データセット#3のレコード)をバイナリ形式で解釈し、入力レコードの各カラムを、Text型、Long型、Int型、Int型として解釈すること、第1(0)のカラムを検索鍵とすることが記述されている。
書式#4は、入力データセット#4のレコードの書式に関する情報であり、本実施例では、入力データセット#4のレコードを解釈する手続きが記述されている。書式#4には、入力レコード(すなわち、入力データセット#4のレコード)をテキスト形式(文字列形式)で解釈することが記述されている。また、レコードにおけるカラム間の区切り文字は、カンマであり、第1(0)のカラムは、Text型であり、「User」と名付け、第2(1)のカラムは、Text型であり、「Gender」と名付け、第3(2)のカラムは、Text型であり、「Zip」と名付け、第4(3)のカラムは、Text型であり、「Address」と名付け、これらに基づいて入力カラムを解釈することが記述されている。
図5Gは、実施例2に係る参照方式を説明するための図である。
参照方式#2は、入力データセット#2のレコードの値を用いて、入力データセット#3のレコードを参照する方法についての手続きであり、入力レコード(書式#2に対応するレコード)の第2カラムを参照鍵とし、論理参照により参照を行ってレコードを取得することが記述されている。ここで、論理参照は、指定された鍵の値によって、参照先のデータセットを検索して、参照先のレコードを同定することを意味する。
参照方式#3は、入力データセット#4の「Reference」を用いて、入力データセット#6のレコードを参照する方法についての手続きであり、入力レコード(書式#5に対応するレコード)の第2カラムをオフセットとし、第3カラムを長さとし、第4カラムをノードIDとして、物理参照により参照を行ってレコードを取得することが記述されている。ここで、物理参照は、指定されたノードIDが管理するストレージの指定されたオフセット(番地)を始点として、指定された長さ分のバイト列を、参照先のレコードとすることを意味する。
図5Hは、実施例2に係るカタログの一例を示す。
本実施例においては、書式や、参照方式については、例えば、プログラムコードで記述されている。したがって、この書式や参照方式をユーザが用意することとなると、ユーザ自身がプログラムコードを作成できる必要がある。しかしながら、全てのユーザがプログラムコードを作成できるとは限らない。そこで、本実施例では、ユーザが、アプリケーションにおいて、プログラムコードよりも容易なカタログを記述することにより書式や、参照方式など、ジョブ情報の一部を規定できるようにし、そのカタログに基づいて、並列データ処理システムがデータ処理のジョブを実行するようにする。なお、この際、並列データ処理システムは、カタログを一旦、書式や参照方式に変換してからジョブを実行してもよいし、カタログを以って直接ジョブを実行してもよい。
図5Hに示すカタログは、例えば、XML(Extensible Markup Language)で記述されており、4つのデータ構造体に関する記述部50a〜50dを含む。
記述部50aには、入力データセット#2に対応する「user_comment」のデータセットは、テキストをカラム分割した形式であり、第1(0)カラムをDateTime型で解釈し、これを分割鍵とし、カラム間の区切り文字をカンマとしていることが記述されている。
また、記述部50bには、入力データセット#1に対応する「user_comment.product.index」のデータセットは、「user_comment」に対応した局所的な二次索引としての形式であり、「user_comment」に基づいて、カラムの区切り文字をカンマとした際における第3(2)カラムをText型で解釈し、これを索引鍵とすることが記述されている。なお、記述部50c、50dについても、上記記述部と同様な記述となっている。なお、カタログには必要なジョブ情報の一部を全て明示的に規定する必要はなく、明示的に規定されていないものについてはシステムモジュール等が所定の規定に沿って、並列データ処理を行ってもよい。例えば、この例では、「user_comment.product.index」については明示的に分割鍵を指定していないが、「user_comment.product.index」は局所的な二次索引として規定されていることから、その基となる「user_comment」と同じ分割が行われ、即ち、「user_comment」の分割部分の毎に二次索引としての「user_comment.product.index」が構成してもよい。
図6Aは、実施例1に係るレコード取得を説明するための模式図の一例である。なお、以下、図6A〜図9Cの説明は、実施例1についての説明であるが、実施例1に限らず実施例2にも適用される説明である。
計算ノード100のプロセッサ101がスレッドを実行して、そのスレッドにより、レコードを取得する際に、レコードが自身の計算ノード100のストレージ104に格納されているレコードである場合には、そのストレージ104からレコードを取得する。一方、レコードが他の計算ノード100のストレージ104に格納されている場合には、計算ノード100から他の計算ノード100へ、例えばローカルエリアネットワーク200を介して、レコードを取得するためのレコード取得要求を送信し、計算ノード100は当該レコード取得要求に従い他の計算ノード100がそのストレージ104から取得したレコードを受信することにより、レコードを取得する。この際、計算ノード100と他の計算ノード100との間にはセッションが張られる。複数のスレッドを実行している場合には、スレッド毎に発生されるレコード取得要求毎に、セッションが張られることとなる。この場合には、スレッド数が多くなればなるほど、張られるセッション数が増加することとなり、セッションの管理や制御に係る処理が増大してその効率が低下する。
これに対して、以下に示すように、複数のレコード取得要求をまとめたブロック毎にセッションを張るようにしてもよい。
図6Bは、実施例2に係るデータ取得時のブロック化を説明するための模式図の一例である。
計算ノード100のプロセッサ101は、複数のスレッドにより発生される複数のレコード取得要求を、1つのブロック(ブロック化レコード取得要求)にまとめ、当該ブロックを単位として計算ノード100と、他の計算ノード100との間にセッションを張る。これにより、計算ノード100間に張られるセッション数を低減することができ、処理効率の低下を防止することができる。
図7Aは、実施例1に係るレコードを取得する計算ノードにおけるレコード取得処理の流れを示す。
このレコード取得処理は、図4AのS10、S16、図4BのS21、S27の処理に対応する。
S41で、データ読み書き器140は、システムモジュール120から指示されたレコードの読み込み(取得)が、自身の計算ノード100のストレージ104からのレコードの取得、すなわち、ローカルレコードの取得であるか否かを判断する。この判断の結果が肯定的であれば、S42を行う一方、この判断の結果が否定的であれば、S44を行う。
S42で、データ読み書き器140は、ストレージマネージャ160により、OS170ならびにHBA103を経由して、ストレージ104に対して、レコードの取得に必要なデータを読み込むためのデータ読み込み要求を発行させる。具体的には、ストレージマネージャ160は、データ読み込み要求管理表700(図7C参照)にデータ読み込み要求の情報を格納するとともに、計算ノード100の主記憶105の要求キュー740に対して、データ読み込み要求を追加する。OS170は、要求キュー740からデータ読み込み要求を取得して、HBA103によってストレージ104に発行する。
S43で、データ読み書き器140は、自スレッドを保留状態とし、処理を終了する。
S44で、データ読み書き器140は、ネットワークマネージャ150により、OS170ならびにNIC102を経由して、他の計算ノード100に対して、レコード取得要求メッセージを送信させる。具体的には、ネットワークマネージャ150は、リモートレコード取得要求管理表710(図7C参照)にレコード取得要求メッセージの情報を格納するとともに、計算ノード100の主記憶105の送信キュー720に対して、レコード取得要求メッセージを追加する。
S45で、データ読み書き器140は、自スレッドを保留状態とし、処理を終了する。
一方、計算ノード100のストレージ104は、要求キュー740から発行されたデータ読み込み要求を受信して、当該データ読み込み要求に対応するデータを読み込んで、HBA103に送信する。OS170は、HBA103より読み込んだ当該データを主記憶105の完了キュー750に追加する。
その後、S46で、データ読み書き器140は、完了キュー750からデータ読み込み要求に対応するデータを取得し、当該データからレコードを抽出する。レコード
S47で、データ読み書き器140は、データ読み込み要求管理表700に基づいて、受け取ったレコードを使用するスレッドを特定し、当該スレッドを再開し、レコード取得処理を終了する。
一方、送信キュー720に格納されたレコード取得要求メッセージは、NIC102により送信先の計算ノード100に送信される。また、他の計算ノード100から送信されるレコード取得要求メッセージに対する取得完了メッセージは、NIC102により受信キュー730に格納される。
S48で、ネットワークマネージャ150は、受信キュー730の取得完了メッセージからレコードを抽出し、システムモジュール120に渡す。
S49で、データ読み書き器140は、リモートレコード取得要求管理表710に基づいて、受け取ったレコードを使用するスレッドを特定し、当該スレッドを再開し、レコード取得処理を終了する。
図7Bは、実施例1に係るレコードを管理する計算ノードにおけるレコード取得処理の流れを示す。
レコード取得要求メッセージの送信先の計算ノード100においては、NIC102がレコード取得要求メッセージを取得し、OS170が主記憶105の受信キュー760に格納する。
S50で、送信先の計算ノード100のネットワークマネージャ150は、受信キュー760からレコード取得要求メッセージを取得し、データ読み書き器140に渡す。
S51で、データ読み書き器140は、レコード取得要求メッセージに基づいて、ストレージマネージャ160により、OS170ならびにHBA103を経由して、ストレージ104に対して、レコードの取得に必要なデータを読み込むためのデータ読み込み要求を発行させ、処理を終了する。具体的には、ストレージマネージャ160は、計算ノード100の主記憶105の要求キュー780に対して、データ読み込み要求を追加する。OS170は、HBA103により、要求キュー740からデータ読み込み要求を取得して、ストレージ104に発行する。
ストレージ104は、要求キュー780から発行されたデータ読み込み要求を受信し、当該データ読み込み要求に対応するレコードを読み込んで、HBA103に送信する。OS170は、HBA103による読み込んだ当該レコードを主記憶105の完了キュー790に追加する。
その後、S52で、データ読み書き器140は、完了キュー790からデータ読み込み要求に対応するデータからレコードを抽出する。
S53で、データ読み書き器140は、受け取ったレコードを取得完了メッセージに含め、ネットワークマネージャ150により、レコード取得要求メッセージの送信元の計算ノード100に対して取得完了メッセージを送信し、処理を終了する。具体的には、ネットワークマネージャ150は、計算ノード100の主記憶105の送信キュー760に対して、取得完了メッセージを追加する。
送信キュー760に格納された取得完了メッセージは、NIC102によりレコード取得要求メッセージの送信元の計算ノード100に送信される。この取得完了メッセージは、送信元の計算ノード100において、NIC102により受信キュー730に格納する。
図7Aに図示する処理は、図4AのS10、S16、図4BのS21、S27の処理を行うスレッド(SL1、SL2、SLd、SLd、SLd、SLdk+1等)において実行してもよい。例えば、CPU101がスレッドSL1においてS10のデータ取得処理を実行することにより、CPU101がS41からS45までに相当する手続きを同じスレッドSL1で実行してもよい。また、図7Aに図示する処理は、図4AのS10、S16、図4BのS21、S27の処理を行うスレッド(SL1、SL2、SLd、SLd、SLd、SLdk+1等)とは別のスレッドにおいて実行してもよい。例えば、CPU101がスレッドSL1においてS10のデータ取得処理を実行することにより、CPU101がS41からS45までに相当する手続きを別のスレッドで実行してもよい。この際、S41からS45までに相当する手続き、S46からS47までに相当する手続き、S48からS49までに相当する手続きの別に、それぞれ別のスレッドを設けてもよいし、同じスレッドで行ってもよい。また、それぞれの手続きに複数のスレッドを設けてもよい。また、S46からS47までに相当する手続き、S48からS49までに相当する手続きを駆動するために、更に別のスレッドを設けてもよい。これらの駆動は、完了キュー750ならびに受信キュー730に対してHBA103ならびにNIC102が追加を行うことにより生じる割り込みやシグナル等の手段によって行われてもよい。
図7Bに図示する処理については、S50からS51までに相当する手続き、S52からS53までに相当する手続きの別に、それぞれ別のスレッドを設けてもよいし、同じスレッドで行ってもよい。また、それぞれの手続きに複数のスレッドを設けてもよい。また、S52からS53までに相当する手続きを駆動するために、更に別のスレッドを設けてもよい。これらの駆動は、完了キュー790に対してHBA103が追加を行うことにより生じる割り込みやシグナル等の手段によって行われてもよい。
図7Cは、実施例1に係るデータ読み込み要求管理表及びリモートレコード取得要求管理表の構成を示す。
データ読み込み要求管理表700は、データ読み込み要求毎の情報として、スレッドID701、要求発行時刻702、及びデータ読み込み要求703を有する。データ読み込み要求703は、装置ID704、オフセット番地705、読み込み長706、及びバッファ番地707を有する。各種情報は、下記の通りである。
(*)スレッドID701は、データ読み込み要求を発行させたスレッドを識別するためのIDを示す。
(*)要求発行時刻702は、データ読み込み要求を発行した時刻を示す。
(*)データ読み込み要求703は、データ読み込み要求の内容を示す。
(*)装置ID704は、データ読み込み要求の送信先のストレージ104の装置IDを示す。
(*)オフセット番地705は、データ読み込み要求対象のレコードが格納されるストレージ104におけるアドレス(オフセット番地)を示す。
(*)読み込み長706は、読み込むレコードのデータ長(バイト長)を示す。
(*)バッファ番地707は、データ読み込み要求対象のレコードを格納する主記憶105上の領域(バッファ)のアドレスを示す。
リモートレコード取得要求管理表710は、レコード取得要求毎の情報として、スレッドID711、要求発行時刻712、及びレコード取得要求713を有する。レコード取得要求713は、計算ノードID714、レコード参照715、バッファ番地716を有する。各種情報は、下記の通りである。
(*)スレッドID711は、レコード取得要求を発行させたスレッドを識別するためのIDを示す。
(*)要求発行時刻712は、レコード取得要求を発行した時刻を示す。
(*)レコード取得要求713は、レコード取得要求の内容を示す。
(*)計算ノードID714は、レコード取得要求の送信先の計算ノードのID(計算ノードID)を示す。
(*)レコード参照715は、レコード取得要求の対象となるレコードへの参照情報を示す。
(*)バッファ番地716は、データ読み込み要求対象のレコードを格納する主記憶105上の領域(バッファ)のアドレスを示す。
次に、実施例1の変形例に係るレコード取得処理を説明する。
図7Dは、実施例1の変形例に係るレコードを取得する計算ノードにおけるレコード取得処理の流れを示す。
このレコード取得処理は、図4AのS10、S16、図4BのS21、S27の処理に対応する。
S61で、データ読み書き器140は、システムモジュール120から指示されたレコードの読み込み(取得)が、自身の計算ノード100のストレージ104からのレコードの取得、すなわち、ローカルレコードの取得であるか否かを判断する。この判断の結果が肯定的であれば、S62を行う一方、この判断の結果が否定的であれば、S64を行う。
S62で、データ読み書き器140は、ストレージマネージャ160により、ストレージ140に対して、データ読み込み要求を発行させる。なお、具体的な処理は、図7AにおけるS42と同様である。
S63で、データ読み書き器140は、自スレッドを保留状態とし、処理を終了する。
S64で、データ読み書き器140は、各計算ノード100に対するレコード取得要求メッセージを、主記憶105の各計算ノード100のそれぞれに対応して設けられているブロック化キュー800、810、820の中の、このレコード取得要求メッセージの送信先の計算ノード100に対応するブロック化キューに追加し、当該レコード取得要求メッセージをブロック化リモートレコード取得要求管理表830に追加する。ここで、ブロック化リモードレコード取得要求管理表830においては、同一の計算ノード100を送信先とする複数のレコード取得要求メッセージが1つの要求(ブロック化リモートレコード取得要求)にまとめられる。
S65で、データ読み書き器140は、自スレッドを保留状態とし、処理を終了する。
S66で、ネットワークマネージャ150は、各ブロック化キュー800、810、820のそれぞれから、複数のレコード取得要求メッセージを含むブロック化リモートレコード取得要求を抽出する。
S67で、ネットワークマネージャ150は、ブロック化リモートレコード取得要求メッセージをOS170ならびにNIC102を介して送信し、処理を終了する。具体的には、ネットワークマネージャ150は、ブロック化リモートレコード取得要求メッセージを主記憶105の送信キュー840に格納し、NIC102が送信キュー840からブロック化リモートレコード取得要求メッセージを送信先の計算ノード100に送信する。このように、複数のレコード取得要求を1つのブロック化リモートレコード取得要求メッセージとするとので、通信時に張られるセッション数を低減することができる。
この後、OS170は、NIC102により、他の計算ノード100から送信されるブロック化レコード取得完了メッセージを受信し、受信キュー850に格納する。
S68で、ネットワークマネージャ150は、受信キュー850からブロック化レコード取得完了メッセージを取得し、ブロック化レコード取得完了メッセージから複数のレコードを抽出し、システムモジュール120に渡す。
S69で、データ読み書き器140は、ブロック化リモートレコード取得要求管理表830に基づいて、受け取ったレコードを使用するスレッドを特定し、当該スレッドを再開し、レコード取得処理を終了する。
図7Eは、実施例1の変形例に係るレコードを管理する計算ノードにおけるレコード取得処理の流れを示す。
ブロック化リモートレコード取得要求メッセージの送信先の計算ノード100においては、NIC102がブロック化リモートレコード取得要求メッセージを取得し、主記憶105の受信キュー860に格納する。
S70で、送信先の計算ノード100のネットワークマネージャ150は、受信キュー860からブロック化リモートレコード取得要求メッセージを取得し、ブロック化リモートレコード取得要求メッセージから複数のレコード取得要求を抽出してデータ読み書き器140に渡す。
S71で、データ読み書き器140は、複数のレコード取得要求メッセージに基づいて、ストレージマネージャ160により、HBA103を経由して、ストレージ104に対して、複数のレコードの取得に必要なデータを読み込むための複数のデータ読み込み要求を発行し、処理を終了する。具体的には、ストレージマネージャ160は、計算ノード100の主記憶105の要求キュー880に対して、複数のデータ読み込み要求を追加する。HBA104は、要求キュー780からデータ読み込み要求を取得して、ストレージ104に発行する。
ストレージ104は、要求キュー880から発行されたデータ読み込み要求を受信し、当該データ読み込み要求に対応するレコードを読み込んで、HBA103に送信し、HBA103が読み込んだ当該データを主記憶105の完了キュー890に追加する。
その後、S72で、ストレージマネージャ160は、完了キュー890からデータ読み込み要求に対応する複数のレコードを取得し、当該データからレコードを抽出し、システムモジュール120に渡す。
S73で、データ読み書き器140は、受け取った複数のレコードをブロック化取得完了メッセージに含め、ネットワークマネージャ150により、ブロック化リモートレコード取得要求メッセージの送信元の計算ノード100に対してブロック化取得完了メッセージを送信させ、処理を終了する。具体的には、ネットワークマネージャ150は、計算ノード100の主記憶105の送信キュー870に対して、ブロック化取得完了メッセージを追加する。送信キュー870に格納されたブロック化取得完了メッセージは、NIC102によりブロック化リモートレコード取得要求メッセージの送信元の計算ノード100に送信される。このブロック化取得完了メッセージは、送信元の計算ノード100において、NIC102により受信キュー850に格納される。
図7Dに図示する処理は、図4AのS10、S16、図4BのS21、S27の処理を行うスレッド(SL1、SL2、SLd、SLd、SLd、SLdk+1等)において実行してもよい。例えば、CPU101がスレッドSL1においてS10のデータ取得処理を実行することにより、CPU101がS61からS65までに相当する手続きを同じスレッドSL1で実行してもよい。また、図7Dに図示する処理は、図4AのS10、S16、図4BのS21、S27の処理を行うスレッド(SL1、SL2、SLd、SLd、SLd、SLdk+1等)とは別のスレッドにおいて実行してもよい。例えば、CPU101がスレッドSL1においてS10のデータ取得処理を実行することにより、CPU101がS61からS65までに相当する手続きを別のスレッドで実行してもよい。この際、S61からS65までに相当する手続き、S66からS67までに相当する手続き、S68からS69までに相当する手続きの別に、それぞれ別のスレッドを設けてもよいし、同じスレッドで行ってもよい。また、それぞれの手続きに複数のスレッドを設けてもよい。また、S66からS67までに相当する手続き、S68からS69までに相当する手続きを駆動するために、更に別のスレッドを設けてもよい。これらの駆動は、完了キュー750ならびに受信キュー730に対してHBA103ならびにNIC102が追加を行うことにより生じる割り込みやシグナル等の手段によって行われてもよい。
図7Eに図示する処理については、S70からS71までに相当する手続き、S72からS73までに相当する手続きの別に、それぞれ別のスレッドを設けてもよいし、同じスレッドで行ってもよい。また、それぞれの手続きに複数のスレッドを設けてもよい。例えば、S70で取得したブロック化レコード取得要求メッセージに従い、複数のスレッドを生成し、その各々のスレッドにおいてS71を実行してデータ読み込み要求を実行してもよい。この際、当該メッセージに含まれるレコード取得要求の数と同じ数のスレッドを生成してもよいし、また、所定の数のスレッドを生成してもよい。S72からS73までに相当する手続きを駆動するために、更に別のスレッドを設けてもよい。これらの駆動は、完了キュー790に対してHBA103が追加を行うことにより生じる割り込みやシグナル等の手段によって行われてもよい。
図7Fは、変形例に係るブロック化リモートレコード取得要求管理表の構成を示す。
ブロック化リモートレコード取得要求管理表830は、ブロック化リモートレコード取得要求毎の情報として、要求発行時刻832、要求の数833、及び1以上のレコード取得要求834を有する。レコード取得要求834は、スレッドID831、計算ノードID835、レコード参照836、バッファ番地837、完了フラグ838を有する。各種情報は、下記の通りである。
(*)要求発行時刻832は、ブロック化リモートレコード取得要求を発行した時刻を示す。
(*)要求の数833は、ブリック化リモートレコード取得要求に含まれるレコード取得要求の数を示す。
(*)レコード取得要求834は、レコード取得要求の内容を示す。
(*)スレッドID831は、レコード取得要求を発行したスレッドを識別するためのIDを示す。
(*)計算ノードID835は、レコード取得要求の送信先の計算ノードのID(計算ノードID)を示す。
(*)レコード参照836は、レコード取得要求の対象となるレコードへの参照情報を示す。
(*)バッファ番地837は、レコード取得要求の対象となるレコードを格納する主記憶105上の領域(バッファ)のアドレスを示す。
(*)完了フラグ838は、レコード取得要求に対応するレコードを取得したか否かを示すフラグである。
なお、上記においては、本発明の特徴的な点に焦点を絞って、並列データ処理を行うジョブにおいて、レコード取得する手続きを説明したが、当該手続きには多様な実装形態が考えられる。
データセットからレコードを抽出するためには、データセット中でレコードがどのように配置されているかの情報が不可欠である。例えば、テキストファイルをデータセットとし、そのうちの1行をレコードとして取り扱う場合においては、レコードとレコードは改行コードによって区切られる。当該テキストファイルからレコードを取り出すためには、レコードが改行コードによって区切られているという情報が欠かせない。また、別の例としては、データセットがB木等の構造を有する場合、幾つかのレコードはストレージ上のアクセスの単位であるページの中に適当なデータ構造によって詰め込まれている場合がある。そのような構造からレコードを取り出すためには、当該構造(ページの長さ、ページのヘッダ・フッタ構造、ページ中におけるレコードのヘッダ・フッタ構造等)の情報が欠かせない。更には、データセットが圧縮や暗号化されている場合には、当該データセットからレコードを取得するためには復号のための手続き情報が欠かせない。このようにレコードを取得するためのデータセットの構成に関する情報は、書式等に同様に、ジョブ情報の一部としてアプリケーションによって規定されてもよい。もしくは、データセットの構成に関する情報は、その全てをアプリケーションが明示的に規定しなくてもよい。アプリケーションによって規定されていないデータセットの構成に関しては、システムモジュール等が所定の構成が規定されているものと見做して、ジョブを実行してもよい。この際、システムモジュール等は、データセットに関する情報やデータセットに基づいて、データセットの構成を判断してもよい。例えば、アプリケーションが明示的にデータセットの構成を規定していないものの、データセットがテキストファイルであると判断される場合には、レコードが改行コードによって区切られているものとしてジョブを実行してもよい。なお、この際に、アプリケーションが規定するデータセットの構成に関する情報は、システムモジュールを介して、データ読み書き器に通知されてもよい。
システムモジュール等は、データセットからレコードを抽出する際に、データセットの一部のデータを主記憶等にキャッシュし、ストレージへのアクセスを減らすようにしてもよい。例えば、テキストファイルを走査してレコードを取得する場合、レコードの毎にストレージにアクセスするのではなく、一度に1メガバイト等の単位でテキストファイルからデータを読み込んで主記憶に格納し、そのデータの中からレコードを取り出すようにしてもよい。
図8Aは、実施例1に係るノードレベルの資源制約管理表の構成を示す。
図8Aの上側のノードレベルの資源制約管理表900は、各計算ノード100を統括する統括スーパバイザプロセスにより管理される。
ノードレベルの資源制約管理表900は、計算ノード毎の情報として、計算ノードID901、資源制約902を有する。資源制約902は、スレッド数903と、主記憶割当て904とを有する。各種情報は、下記の通りである。
(*)計算ノードID901は、計算ノードのIDを示す。
(*)資源制約902は、計算ノードID901に対応する計算ノードにおける資源の制約を示す。
(*)スレッド数903は、計算ノードID901に対応する計算ノードにおいて、生成可能な最大のスレッドの数を示す。
(*)主記憶割当て904は、計算ノードID901に対応する計算ノードにおいて、割当て可能な主記憶の最大の記憶量を示す。
図8Aの下側のノードレベルの資源制約管理表910は、各計算ノード100におけるスーパバイザプロセスにより管理される。
ノードレベルの資源制約管理表910は、自身の計算ノードの情報として、計算ノードID911、資源制約912、及び資源利用913を有する。資源制約912は、スレッド数914と、主記憶割当て915とを有する。資源利用913は、スレッド数916と、主記憶割当て917とを有する。各種情報は、下記の通りである。
(*)計算ノードID911は、自身の計算ノードのID(計算ノードID)を示す。
(*)資源制約912は、自身の計算ノードにおける資源の制約を示す。
(*)資源利用913は、自身の計算ノードにおいて利用している資源を示す。
(*)スレッド数914は、自身の計算ノードにおいて、生成可能な最大のスレッドの数を示す。
(*)主記憶割当て915は、自身の計算ノードにおいて、割当て可能な主記憶の最大の記憶量を示す。
(*)スレッド数916は、自身の計算ノードにおいて、実際に生成しているスレッドの数を示す。
(*)主記憶割当て917は、自身の計算ノードにおいて、実際に割当てている主記憶の記憶量を示す。
図8Bは、実施例1に係るジョブレベルの資源制約管理表の構成を示す。
図8Bの上側のジョブレベルの資源制約管理表920は、統括スーパバイザプロセスにより管理される。
ジョブレベルの資源制約管理表920は、ジョブ毎の情報として、ジョブID921、計算ノードID922、資源制約923を有する。資源制約923は、スレッド数924と、主記憶割当て925とを有する。各種情報は、下記の通りである。
(*)ジョブID921は、ジョブのID(ジョブID)を示す。
(*)計算ノードID922は、ジョブID921のジョブを実行する計算ノードのID(計算ノードID)を示す。
(*)資源制約923は、計算ノードID922の計算ノードにおけるジョブID921のジョブに対する資源の制約を示す。
(*)スレッド数924は、計算ノードID922の計算ノードにおけるジョブID921のジョブに対する生成可能な最大のスレッドの数を示す。
(*)主記憶割当て925は、計算ノードID922の計算ノードにおけるジョブID921のジョブに対する割当て可能な主記憶の最大の記憶量を示す。
図8Bの下側のノードレベルの資源制約管理表930は、各計算ノード100におけるスーパバイザプロセスにより管理される。
ノードレベルの資源制約管理表930は、自身の計算ノードにおける各ジョブに対する情報として、ジョブID931、計算ノードID932、資源制約933、及び資源利用934を有する。資源制約933は、スレッド数935と、主記憶割当て936とを有する。資源利用934は、スレッド数937と、主記憶割当て938とを有する。各種情報は、下記の通りである。
(*)ジョブID931は、ジョブのID(ジョブID)を示す。
(*)計算ノードID932は、自身の計算ノードのID(計算ノードID)を示す。
(*)資源制約933は、自身の計算ノード100におけるジョブID931のジョブに対する資源の制約を示す。
(*)資源利用934は、自身の計算ノード100においてジョブID931のジョブに対して利用している資源を示す。
(*)スレッド数935は、自身の計算ノード100におけるジョブID931のジョブに対する、生成可能な最大のスレッドの数を示す。
(*)主記憶割当て936は、自身の計算ノード100におけるジョブID931のジョブに対する、割当て可能な主記憶の最大の記憶量を示す。
(*)スレッド数937は、自身の計算ノード100においてジョブID931のジョブに対して、実際に生成しているスレッドの数を示す。
(*)主記憶割当て938は、自身の計算ノード100においてジョブID931のジョブに対して、実際に割当てている主記憶の記憶量を示す。
図8Cは、実施例1に係る統括するスーパバイザプロセスにおけるプロセスレベルの資源制約管理表の構成を示す。
プロセスレベルの資源制約管理表940は、統括スーパバイザプロセスにより管理される。
プロセスレベルの資源制約管理表940は、プロセス毎の情報として、プロセスID941、ジョブID942、計算ノードID943、資源制約944を有する。資源制約944は、スレッド数945と、主記憶割当て946とを有する。各種情報は、下記の通りである。
(*)プロセスID941は、プロセスのID(プロセスID)を示す。
(*)ジョブID942は、ジョブIDを示す。
(*)計算ノードID943は、ジョブID921のジョブのプロセスID941のプロセスを実行する計算ノードのID(計算ノードID)を示す。
(*)資源制約944は、計算ノードID943の計算ノードにおけるジョブID942のジョブのプロセスID941のプロセスに対する資源の制約を示す。
(*)スレッド数945は、計算ノードID943の計算ノードにおけるジョブID942のジョブのプロセスID941のプロセスに対する生成可能な最大のスレッドの数を示す。
(*)主記憶割当て946は、計算ノードID943の計算ノードにおけるジョブID942のジョブのプロセスID941のプロセスに対する割当て可能な主記憶の最大の記憶量を示す。
図8Dは、実施例1に係る各ノードのスーパバイザプロセスにおけるプロセスレベルの資源制約管理表の構成を示す。
プロセスレベルの資源制約管理表950は、各計算ノード100におけるスーパバイザプロセスにより管理される。
プロセスレベルの資源制約管理表950は、自身の計算ノードにおける各ジョブにおける各プロセスに対する情報として、プロセスID951、ジョブID952、計算ノードID953、資源制約954、及び資源利用955を有する。資源制約954は、スレッド数956と、主記憶割当て957とを有する。資源利用955は、スレッド数958と、主記憶割当て959とを有する。各種情報は、下記の通りである。
(*)プロセスID951は、プロセスのIDを示す。
(*)ジョブID952は、ジョブのIDを示す。
(*)計算ノードID953は、自身の計算ノード100のID(計算ノードID)を示す。
(*)資源制約954は、自身の計算ノード100におけるジョブID952のジョブのプロセスID951のプロセスに対する資源の制約を示す。
(*)資源利用955は、自身の計算ノード100においてジョブID952のジョブのプロセスID951のプロセスに対して利用している資源を示す。
(*)スレッド数956は、自身の計算ノード100におけるジョブID952のジョブのプロセスID951のプロセスに対する、生成可能な最大のスレッドの数を示す。
(*)主記憶割当て957は、自身の計算ノード100におけるジョブID952のジョブのプロセスID951のプロセスに対する、割当て可能な主記憶の最大の記憶量を示す。
(*)スレッド数958は、自身の計算ノード100においてジョブID952のジョブのプロセスID951のプロセスに対して、実際に生成しているスレッドの数を示す。
(*)主記憶割当て959は、自身の計算ノード100においてジョブID952のジョブのプロセスID951のプロセスに対して、実際に割当てている主記憶の記憶量を示す。
図8Eは、実施例1に係る統括スーパバイザプロセスにおけるタスクレベルの資源制約管理表の構成を示す。
タスクレベルの資源制約管理表960は、統括スーパバイザプロセスにより管理される。
タスクレベルの資源制約管理表960は、タスク毎の情報として、タスクID961、プロセスID962、ジョブID963、計算ノードID964、資源制約965を有する。資源制約944は、スレッド数945と、主記憶割当て946とを有する。各種情報は、下記の通りである。
(*)タスクID961は、タスクのID(プロセスID)を示す。
(*)プロセスID962は、プロセスのID(プロセスID)を示す。
(*)ジョブID963は、ジョブIDを示す。
(*)計算ノードID964は、ジョブID963のジョブのプロセスID962のプロセスのタスクID961のタスクを実行する計算ノードのID(計算ノードID)を示す。
(*)資源制約965は、計算ノードID964の計算ノードにおけるジョブID963のジョブのプロセスID962のプロセスのタスクID961のタスクに対する資源の制約を示す。
(*)スレッド数966は、計算ノードID964の計算ノードにおけるジョブID963のジョブのプロセスID962のプロセスのタスクID961のタスクに対する生成可能な最大のスレッドの数を示す。
(*)主記憶割当て967は、計算ノードID964の計算ノードにおけるジョブID963のジョブのプロセスID962のプロセスのタスクID961のタスクに対する割当て可能な主記憶の最大の記憶量を示す。
図8Fは、実施例1に係る各ノードのスーパバイザプロセスにおけるタスクレベルの資源制約管理表の構成を示す。
タスクレベルの資源制約管理表970は、各計算ノード100におけるスーパバイザプロセスにより管理される。
タスクレベルの資源制約管理表970は、自身の計算ノードにおける各ジョブにおける各プロセスの各タスクに対する情報として、タスクID971、プロセスID972、ジョブID973、計算ノードID974、資源制約975、及び資源利用976を有する。資源制約975は、スレッド数977と、主記憶割当て978とを有する。資源利用976は、スレッド数979と、主記憶割当て980とを有する。各種情報は、下記の通りである。
(*)タスクID971は、タスクのIDを示す。
(*)プロセスID972は、プロセスのIDを示す。
(*)ジョブID973は、ジョブのIDを示す。
(*)計算ノードID974は、自身の計算ノード100のID(計算ノードID)を示す。
(*)資源制約975は、自身の計算ノード100におけるジョブID973のジョブのプロセスID972のプロセスのタスクID971のタスクに対する資源の制約を示す。
(*)資源利用976は、自身の計算ノード100においてジョブID973のジョブのプロセスID972のプロセスのタスクID971のタスクに対して利用している資源を示す。
(*)スレッド数977は、自身の計算ノード100におけるジョブID973のジョブのプロセスID972のプロセスのタスクID971のタスクに対する、生成可能な最大のスレッドの数を示す。
(*)主記憶割当て978は、自身の計算ノード100におけるジョブID973のジョブのプロセスID972のプロセスのタスクID971のタスクに対する、割当て可能な主記憶の最大の記憶量を示す。
(*)スレッド数979は、自身の計算ノード100においてジョブID973のジョブのプロセスID972のプロセスのタスクID971のタスクに対して、実際に生成しているスレッドの数を示す。
(*)主記憶割当て980は、自身の計算ノード100においてジョブID973のジョブのプロセスID972のプロセスのタスクID971のタスクに対して、実際に割当てている主記憶の記憶量を示す。
図8Gは、実施例1に係る統括資源制約管理処理の流れを示す。
S81で、各計算ノード100のスーパバイザプロセスを統括する計算ノード100における統括スーパバイザプロセスは、新たにタスクを割り当てる際に、当該新たなタスクに対する資源制約を計算する。なお、ユーザが指定した資源制約としてもよいし、ユーザが指定したポリシーに基づいて資源制約を計算(例えば、比例配分)してもよい。
S82で、統括スーパバイザプロセスは、図8Eに示すようなタスクレベルの資源制約管理表960に、新たなタスクに対するレコードを追加し、当該レコードの資源制約に対して計算した資源制約を格納する。また、統括スーパバイザプロセスは、資源制約の範囲でタスクを実行可能な計算ノード100を選択し、当該計算ノード100に対して、計算ノードに関わる資源制約を送信する。
S83で、統括スーパバイザプロセスは、選択した計算ノード100に対して、タスクを割り当てて、処理を終了する。
S84で、タスクを割当てられた計算ノード100のスーパバイザプロセスは、ステップS82で送信された資源制約を受信し、当該資源制約を図8Fに示すようなタスクレベルの資源制約管理表970に登録する。
S85で、タスクを割当てられた計算ノード100のシステムモジュール120は、割り当てられたタスクを実行する。
図8Hは、実施例1に係る各計算ノードにおける資源制約管理処理の流れを示す。
資源制約管理処理は、例えば、システムモジュール120がタスクを実行することにより、実現される。図8Hの左上の処理(ステップS90〜S94)は、タスクにおいて、スレッドを生成しようとする際に実行される処理である。これは、例えば、図4AのS13、図4BのS24、S31において実行される処理である。
S90で、システムジュール120(具体的には、マップ関数121)は、スレッドを生成するのに十分な資源があるか否かを判断する。ここで、スレッドを生成するのに十分な資源があるか否かについては、タスクレベルの資源制約管理表970、プロセスレベルの資源制約管理表950、ジョブレベルの資源制約管理表930、及びノードレベルの資源制約管理表910のそれぞれを参照し、各レベルにおいて資源制約の範囲内で利用可能な資源が、スレッドを生成するのに十分な資源以上であるか否かにより判断することができる。
そして、この判断の結果が肯定的であれば、S91を行う一方、この判断の結果が否定的であれば、S93を行う。
S91で、システムモジュール120は、スレッドマネージャ133によりスレッドを生成させて、当該スレッドに資源を割当てさせ、割当結果を各資源制約管理表(910、930、950、及び970)の資源利用に反映させる。
S92で、システムモジュール120は、スレッドの実行を開始し、資源制約管理処理を終了する。
S93で、システムモジュール120は、スレッドを生成するために参照するスレッド生成情報をスレッド生成保留管理表990に退避する。
S94で、システムモジュール120は、自スレッドをスレッドの生成を保留している保留状態として処理を終了する。
スレッド生成保留管理表990は、スレッドの生成を保留しているスレッドの情報として、タスクID991、親スレッドID992、子スレッドID993、時刻994、及びスレッド生成情報995を有する。各種情報は、下記の通りである。
(*)タスクID991は、タスクのIDを示す。
(*)親スレッドID992は、他のスレッドを生成する親となるスレッド(親スレッド)のIDを示す。
(*)子スレッドID993は、スレッドから生成される子となるスレッド(子スレッド)のIDを示す。
(*)時刻994は、スレッドの生成を保留した時刻を示す。
(*)スレッド生成情報995は、スレッドを生成する際に必要な情報(例えば、子スレッドで参照するレコードを示す参照を含む情報)である。
図8Hの右上の処理(ステップS95〜S96)は、スレッドにより実行する処理が終了した際に、スレッドを停止させる処理である。
S95で、システムモジュール120は、実行している自スレッドを停止する。
S96で、システムモジュール120は、自スレッドに割り当てられている資源を解放する。すなわち、システムモジュール120は、資源制約管理表910等の資源利用で管理されている資源量(スレッド数、主記憶割当て量)から、自スレッドに割当てられていた資源の量を削除する。これにより、自スレッドに割り当てられていた資源を、他のスレッドに割当てることができるようになる。
図8Hの右下の処理(ステップS97〜S99)は、例えば、資源制約管理表910に基づいて、スレッドを生成するのに十分な資源があることを判定した場合に実行される処理である。この手続きは、例えば、S96によって資源が解放されたことに伴い、割り込みやシグナルなどの手段により、駆動されてもよい。
S97で、システムモジュール120は、スレッド生成保留管理表990に管理されているスレッド生成情報を選択する。選択するスレッド生成情報としては、例えば、最古に保留されたスレッド生成情報であってもよい。
S98で、システムモジュール120は、選択したスレッド生成情報によりスレッドを生成する親スレッドを再開する。
S99で、システムモジュール120は、スレッド生成情報に基づいて、子スレッドの生成を再び実行する。この処理により、スレッドを生成するのに十分な資源がある場合に、生成を保留していたスレッドを生成することができる。
図9Aは、実施例1に係るタスクの第1の例を示す。
図9Aは、マップ・リデュースジョブ#1(図1Aのジョブ実行プランに対応)のマッププロセス#111のマップタスク#1111を示している。ここで、入力データセット#1の#1001のレコードには、入力データセット#2の#2001〜#2010までの10個のレコードに対する参照が含まれているものとする。また、マップタスク#1111は、入力データセット#1の#1001のレコードを取得し、入力データセット#2のレコードを取得するものとする。
計算ノード100が、マップタスク#1111を実行すると、入力データセット#1の#1001のレコードを参照し、当該レコードが所定の条件を満たしているとすると、当該レコードに含まれている参照を用いて、入力データセット#2の#2001〜#2010のレコードを取得する。
図9Bは、第1の例に示すタスクにおけるスレッドの生成の一例を示す。図9Bは、図9Aに示すタスク#1111を実行する際において、図8Hに示す資源制約管理処理を行わない場合におけるスレッドの生成を示している。なお、図9Bの表記は、次のルールに従う。
(*)横軸は、時刻を表す。
(*)図中の横に長い角丸四角形は、1つのスレッドによる一連の処理を意味する。角丸四角形の左端はスレッドによる処理を開始する時刻を表し、角丸四角形の右端は当該スレッドによる処理を終了する時刻を表す。
(*)角丸四角形の内部の値は、スレッドに対応した処理に伴って読み込まれるレコードを示す情報(例えば、レコードID)を表す。
(*)レコードを取得するスレッドについての同時に実行可能なスレッド数は、「8」とする。
図8Hに示す資源制約管理処理を行わない場合においては、入力データセット#1の#1001のレコードを取得して処理を行うスレッド10aが実行されると、スレッド10aにより、#1001のレコードが取得され、当該#1001のレコードに含まれている参照に基づいて、入力データセット#2の#2001のレコードを取得して処理を行うスレッド10bが生成されて実行され、入力データセット#2の#2002のレコードを取得して処理を行うスレッド10cが生成されて実行され、同様にして、スレッド10d、スレッド10e、スレッド10f、スレッド10g、スレッド10hが生成されて実行される。この時点においては、同時に実行可能なスレッド数である「8」と同数のスレッドが実行されることとなる。
この後、更に、スレッド10aにより、入力データセット#2の#2008のレコードを取得して処理を行うスレッド10i、入力データセット#2の#2009のレコードを取得して処理を行うスレッド10j、及び入力データセット#2の#2010のレコードを取得して処理を行うスレッド10kが生成されて実行されることとなる。利用可能な量の主記憶を超えて主記憶の割り当てが行われ、スラッシングが発生してしまい、結果としてこれらスレッドに対する実行時間が長時間となってしまう。
図9Cは、実施例1に係る第1の例に示すタスクにおけるスレッドの生成の一例を示す。図9Cは、図9Aに示すタスク#1111を実行する際において、図8Hに示す資源制約管理処理を行う場合におけるスレッドの生成を示している。なお、図9Cの表記は、図9Bのルールと同様である。
計算ノード100において、入力データセット#1の#1001のレコードを取得して処理を行うスレッド10aが実行されると、スレッド10aにより、#1001のレコードが取得され、当該#1001のレコードに含まれている参照に基づいて、入力データセット#2の#2001のレコードを取得して処理を行うスレッド10bが生成されて実行され、入力データセット#2の#2002のレコードを取得して処理を行うスレッド10cが生成されて実行され、同様にして、スレッド10d、スレッド10e、スレッド10f、スレッド10g、スレッド10hが生成されて実行される。この時点においては、同時に実行可能なスレッド数である「8」と同数のスレッドが実行されることとなる。
この後、資源制約管理処理のステップS90で十分な資源がないと判定されるので、スレッド10aは、新たなスレッドを生成することなく、自スレッドが保留状態となる。そして、スレッド10bの実行が終了した場合には、新たに1つのスレッドが実行可能となるので、ステップS98でスレッド10aの実行が再開されて、ステップS99で入力データセット#2の#2008のレコードを取得して処理を行うスレッド10iが生成される。同様にして、スレッド10cの実行が終了した場合には、スレッド10aの実行が再開されて、入力データセット#2の#2009のレコードを取得して処理を行うスレッド10jが生成されて実行され、スレッド10dの実行が終了した場合には、スレッド10aの実行が再開されて、入力データセット#2の#2010のレコードを取得して処理を行うスレッド10kが生成されて実行される。
この結果、複数のスレッドの実行時に、利用可能な主記憶の量の範囲内で主記憶を割り当てることが可能となり、スラッシングが発生することを防止でき、タスク全体の実行時間を、図9Bに示す場合と比較して、短縮することができる。
次に、複数のタスクが並行して実行される場合におけるスレッドの生成について説明する。
図9Dは、実施例2に係るタスクの第2の例を示す。
図9Dは、マップ・リデュースジョブ#1のマッププロセス#111のマップタスク#1111と、マップ・リデュースジョブ#2のマッププロセス#211のマップタスク#2111とを示している。マップタスク#1111と、マップタスク#2111とは、並行して実行されるものとする。
入力データセット#1の#1001のレコードには、入力データセット#2の#2001〜#2010までの10個のレコードに対する参照が含まれているものとする。また、マップタスク#1111は、入力データセット#1の#1001のレコードを取得し、このレコードに対応する入力データセット#2のデータを取得するものとする。
システムモジュール120は、マップタスク#1111を実行すると、入力データセット#1の#1001のレコードを参照し、当該レコードが所定の条件を満たしているとすると、当該レコードに含まれている参照を用いて、入力データセット#2の#2001〜#2010のレコードを取得する。
また、入力データセット#5の#5001のレコードには、入力データセット#6の#6001〜#6010までの10個のレコードに対する参照が含まれているものとする。また、マップタスク#2111は、入力データセット#5の#5001のレコードを取得し、このレコードに対応する入力データセット#6のレコードを取得するものとする。
システムモジュール120は、マップタスク#2111を実行すると、入力データセット#5の#5001のレコードを参照し、当該レコードが所定の条件を満たしているとすると、当該レコードに含まれている参照を用いて、入力データセット#6の#6001〜#6010のレコードを取得する。
図9Eは、実施例1に係る第2の例に示すタスクにおけるスレッドの生成の一例を示す。図9Eは、図9Dに示すタスク#1111と、タスク#2111とを並行して実行する際において、図8Hに示す資源制約管理処理を行う場合におけるスレッドの生成を示している。ここで、タスク#1111で利用可能な主記憶の領域は、5スレッド分であり、タスク#2111で利用可能な主記憶の領域は、3スレッド分であるとする。なお、図9Eの表記は、図9Bのルールと同様である。
計算ノード100において、入力データセット#1の#1001のレコードを取得して処理を行うスレッド11aが実行されると、スレッド11aにより、#1001のレコードが取得され、当該#1001のレコードに含まれている参照に基づいて、入力データセット#2の#2001のレコードを取得して処理を行うスレッド11bが生成されて実行され、入力データセット#2の#2002のレコードを取得して処理を行うスレッド11cが生成されて実行され、同様にして、スレッド10d、スレッド10eが生成されて実行される。この時点においては、タスク#1111で利用可能な主記憶の5スレッド分の領域が使用されることとなる。
この後、資源制約管理処理のステップS90で十分な資源がないと判定されるので、スレッド11aは、新たなスレッドを生成することなく、自スレッドが保留状態となる。そして、スレッド11bの実行が終了した場合には、新たに1つのスレッドが実行可能となるので、ステップS98でスレッド11aの実行が再開されて、ステップS99で入力データセット#2の#2005のレコードを取得して処理を行うスレッド11fが生成される。同様にして、スレッド11cの実行が終了した場合には、スレッド11aの実行が再開されて、入力データセット#2の#2006のレコードを取得して処理を行うスレッド11gが生成されて実行され、スレッド11dの実行が終了した場合には、スレッド11aの実行が再開されて、入力データセット#2の#2007のレコードを取得して処理を行うスレッド11hが生成され、スレッド11dの実行が終了した場合には、スレッド11aの実行が再開されて、入力データセット#2の#2008のレコードを取得して処理を行うスレッド11iが生成され、スレッド11fの実行が終了した場合には、スレッド11aの実行が再開されて、入力データセット#2の#2009のレコードを取得して処理を行うスレッド11jが生成され、スレッド11gの実行が終了した場合には、スレッド11aの実行が再開されて、入力データセット#2の#2010のレコードを取得して処理を行うスレッド11kが生成される。
一方、入力データセット#5の#5001のレコードを取得して処理を行うスレッド12aが並行して実行されると、スレッド12aにより、#5001のレコードが取得され、当該#5001のレコードに含まれている参照に基づいて、入力データセット#6の#6001のレコードを取得して処理を行うスレッド12bが生成されて実行され、入力データセット#6の#6002のレコードを取得して処理を行うスレッド12cが生成されて実行される。この時点においては、タスク#2111に利用可能な主記憶の3スレッド分の領域が使用されることとなる。
この後、資源制約管理処理のステップS90で十分な資源がないと判定されるので、スレッド12aは、新たなスレッドを生成することなく、自スレッドが保留状態となる。そして、スレッド12bの実行が終了した場合には、新たに1つのスレッドが実行可能となるので、ステップS98でスレッド12aの実行が再開されて、ステップS99で入力データセット#6の#6003のレコードを取得して処理を行うスレッド12dが生成される。同様にして、スレッド12cの実行が終了した場合には、入力データセット#6の#6004のレコードを取得して処理を行うスレッド12eが生成され、スレッド12dの実行が終了した場合には、入力データセット#6の#6005のレコードを取得して処理を行うスレッド12fが生成され、スレッド12eの実行が終了した場合には、入力データセット#6の#6006のレコードを取得して処理を行うスレッド12gが生成され、スレッド12fの実行が終了した場合には、入力データセット#6の#6007のレコードを取得して処理を行うスレッド12hが生成され、スレッド12gの実行が終了した場合には、入力データセット#6の#6008のレコードを取得して処理を行うスレッド12iが生成され、スレッド12hの実行が終了した場合には、入力データセット#6の#6009のレコードを取得して処理を行うスレッド12jが生成され、スレッド12iの実行が終了した場合には、入力データセット#6の#6010のレコードを取得して処理を行うスレッド12kが生成される。このように、複数のタスクを並行して実行させることができる。
この結果、複数のタスクにおいて複数のスレッドの実行時に、各々のタスクで利用可能な主記憶の量の範囲内で主記憶を割り当てることが可能となり、スラッシングが発生することを防止でき、タスク全体の実行時間がスラッシングにより長時間化することを防ぐことができる。
上記では、資源の制約として、スレッド数、主記憶の例を示したが、本発明はこの例に限定されるものではない。例えば、プロセッサ実行時間、ストレージとの入出力スループット、ネットワークの伝送スループット等に関しても、同様に資源の制約を行うことにより、同様の効果を期待することができる。
以上、幾つかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
並列データ処理を実行する際に動的に生成するスレッドとしては、多様な実装形態が考えられ、例えば、プロセスであってもよいし、カーネルレベルのスレッド(ネイティブPOSIXスレッドや軽量プロセス等、オペレーティングシステムのカーネルが管理するスレッド)であってもよいし、ユーザレベルのスレッド(ファイバ等のユーザプログラムやライブラリが管理するスレッド)であってもよいし、他と並行して実行することができるように管理される一定の手続きの集まり(例えば、関数ポインタを適当な構造体で管理するもの)であってもよいし、これらを組み合わせたものであってもよい。
本明細書では、並列データ処理が扱うデータの単位をレコードとしているが、レコードは任意のデータであってよい。例えば、一定個数のカラムの集まりであってもよいし、可変個数のカラムの集まりであってもよいし、単なるテキストであってもよいし、バイト列であってもよいし、画像や音声等のマルチメディアコンテンツであってもよいし、これらの集まりであってもよい。
100…計算ノード、110…アプリケーション、120…システムモジュール

Claims (17)

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