JP5887418B2 - ストリームデータ多重処理方法 - Google Patents

Description

本発明は、ストリームデータ処理のスケールアップ技術に関する。

株取引の自動化、交通情報処理の高度化、クリックストリームの解析といった、高いレートで継続的に発生する情報をリアルタイムに解析し、重要なイベントの発生に対して瞬時にアクションを起こす要求の高まりを背景に、高レートデータのリアルタイム処理を実現する、ストリームデータ処理が注目されている。ストリームデータ処理は、様々なデータ処理に適用可能な汎用ミドルウェア技術であるため、個別案件ごとにシステムを構築するのでは間に合わないようなビジネス環境の急激な変化にも応えつつ、実世界のデータをリアルタイムにビジネスに反映することを可能とする。

ストリームデータ処理が対象とするストリームとは、タイムスタンプ付きのデータであるタプルが、連続して到来する時系列データである。ストリームデータ処理のユーザが、このストリームに対する監視ルールをクエリとして定義すると、クエリ定義をクエリグラフに変換する。クエリグラフは、オペレータと呼ばれる処理単位をノードとし、同オペレータ間のタプルキューをエッジとする、有向グラフである。入力ストリームを構成する個々のタプルについて、クエリグラフを通過させることで、データフロー的に処理を進める。データフロー型の処理であるため、クエリグラフを多段分割し、複数の計算資源によってパイプライン的に並列処理することで、スループット向上が可能である。

一方で、イベントの発生からアクションを起こすまでの時間、即ちレイテンシについても、ミリ秒〜マイクロ秒オーダの、非常に厳しい要求が課せられる。従って、ストリームデータ処理においては、レイテンシ性能とスループット性能の両立が、重要な技術課題である。

本技術分野の背景技術として、特開２０１０−２０４８８０号公報（特許文献１）がある。この公報には、「ストリームデータ処理システムのストリームデータのクエリ処理に関するスループットを向上させる。サーバ装置のスケジューラが、クエリをグループ化するクエリグループへのデータ停滞が発生すると、クエリグループを構成するクエリごとに、そのクエリの入力流量情報およびレイテンシ情報の内の少なくとも１つの情報を基に、そのクエリの負荷評価値を計算し、クエリグループを構成するクエリを、互いにクエリの負荷評価値の和が略均等になるように、複数のクエリグループへと分割し、分割後の複数のクエリグループを、それぞれ異なるプロセッサに再割り当てする。」と記載されている（特許文献１の要約参照）。

また、特開２００８−１４６５０３号公報（特許文献２）がある。この公報には、「制御用のプロセッサユニット（ＰＵ）と、それぞれがローカルメモリをもつ複数の演算用のサブプロセッサユニット（ＳＰＵ）と、メインメモリとを含むマルチプロセッサシステムを提供する。複数のＳＰＵ上で動作するオペレーティングシステムは、各ＳＰＵの計算資源を時分割して複数のタスクに割り当てることにより、複数のタスクが並列に実行されるマルチタスク環境において、タスクの実行結果を別のタスクに与えることにより、負荷の異なる複数のタスクからなる特定処理を実行するためのパイプライン処理系を構築し、当該パイプライン処理系を複数動作させる機能と、メインメモリにコンテキストが退避されて実行可能状態にあるタスクをいずれのタスクも実行していないＳＰＵのローカルメモリにロードして実行させる機能とを含む。」と記載されている（特許文献２の要約参照）。

また、特開２０１０−１０８１５２号公報（特許文献３）がある。この公報には、「再帰的処理を含む一般のデータ処理を低レイテンシで実現できるストリームデータ処理方法及びシステムを提供する。ストリームデータ処理システムは、複数のクエリの実行木から単一のオペレータグラフを構築し、ストリーム化演算の実行が、入力から出力に向かって一方通行で進むように、オペレータの実行順序を決定し、システム外部のデータを入力する外部発火オペレータと時限的にデータを生成する内部発火オペレータの発火時刻を監視し、オペレータ実行制御部は、最も早い発火時刻のオペレータを起点として、決定したオペレータ実行順序に従って、当該時刻のオペレータグラフにおける処理を完結させる処理を繰り返す。」と記載されている（特許文献３の要約参照）。

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

前項で述べた文献の個々の技術では、レイテンシとスループットの両立の点で課題が残る。特許文献３の方法は、各タプルをクエリグラフの入口から出口まで、一つの計算スレッドで集中処理するため、個々のタプルについて最短パスで処理することになり、レイテンシを抑えることが可能となっている。しかしながら、シングルスレッド実行が前提となるため、マルチＣＰＵ、マルチコアといった複数の計算リソースを、スループットの向上に資することが出来ない。

特許文献１の方法は、複数の計算リソースによるパイプライン処理において、各ステージの計算負荷を監視し、負荷が増大したステージは、さらに複数のステージに再分割することで、処理のボトルネックを回避する。但し、パイプライン処理では、完全にボトルネックを回避することが難しい。

図２、図３に示す例を用いて、ここで注目している課題を説明する。図２に示したクエリグラフは、ＯＰ１〜ＯＰ１０の１０個のオペレータ２０１〜２１０によって構成されている。ここで、各オペレータの計算コストは、オペレータに付与された長方形内の値をとることとする。計算コストの合計、即ち１タプル当りの処理時間は１００である。また、本例では４つの計算コアでのクエリ実行を想定する。ここで、このクエリグラフを、図３のようにＡ〜Ｄの４つのステージ３０１〜３０４に分割する。各ステージの計算コストは、それぞれステージＡ（３０１）が２１、ステージＢ（３０２）が２３、ステージＣ（３０３）が３０、ステージＤ（３０４）が２６となる。この分割は、各ステージの計算コストが、合計コスト合計の４（コア数）分の１の２５に近くなるように、定めたものである。１タプルの処理時間に対する、各ステージの処理時間の割合は３１０に示す通りである。

ここで、タプル処理時間の１／４の間隔でタプルが到来する場合、各タプルは、各計算コアにおいて、タイムチャート３１１に示すようなスケジュールで処理されることになる。なお、ステージＸにおけるタプルｎの処理を、Ｘｎと表記する。また、ステージＡ、Ｂ、Ｃ、およびＤの処理は、それぞれ計算コア０、１、２、および３上で実行されることとする。タイムチャート３１１は、計算コア２で実行されるステージＣの処理において、タプルｎの処理Ｃｎが、その一つ前のタプルｎ−１のタプルの処理Ｃ（ｎ−１）の完了まで待たされる様子を表している。このように、パイプライン処理においては、最も処理時間の長いステージに律速されて、スループット性能、レイテンシ性能ともに向上しない、という課題が存在する。４つのステージの処理時間を、全て１タプルの処理時間の丁度１／４となるように、均等にクエリグラフを分割できれば、この課題は回避されるが、ほとんどのクエリにおいて、そのような条件は成立しない。

特許文献２は、一つの特定処理を、それぞれ処理時間の異なる複数のタスクに分割した場合の、タスクスケジューリング方法を示している。特定処理を、一つのタプルについてのクエリ処理、タスクをステージと読み替えることで、ストリームデータのパイプライン処理にも適用可能となる。本方法に従えば、各計算コアは、一つのステージの処理が終わる度に、一旦その処理コンテキスト（タプルの中間処理状態）をキューイングし、処理が空いた他の計算コアが、キューの先頭から取り出したコンテキストの処理を再開する、といった実行様式になる。この方法では、一つのタプルについての処理が、ステージの終了の都度一旦途切れるため、レイテンシ性能に対するオーバヘッドとなる。

パイプライン型の並列処理に対し、データ分割による並列処理も方法も存在する。株価の処理を例に取れば、同一のクエリを実行するクエリグラフを銘柄別で用意し、入力タプルの銘柄属性の値に応じて、クエリグラフを切り替えるような方法である。ここで、クエリグラフを構成する各オペレータは、実行状態を持っている（例えば、価格の移動平均を計算する場合は、スライディングウィンドウ上の価格の和、および価格データ数の値が、実行状態として保持されており、新しいタプルを入力した際には、これら実行状態を更新する）ため、同じ銘柄属性を持つタプルは、常に同じクエリグラフで処理する必要がある。そのため、仮に特定の銘柄のデータが集中すると、並列化の効果が得られなくなってしまう。また、データ分割処理は、属性毎に独立に計算可能なクエリにしか適用できない。例えば、全銘柄の株価を対象とした株式指数の算出には適用不可である。

上記課題を解決するための本発明の代表的処理方法の特徴を挙げるならば、
クエリ定義をクエリグラフに変換してオペレータ間の実行順序を決定するクエリパーサを備え、かつ複数のクエリ実行スレッドを備えストリーム処理システムにより実行するストリームデータ多重処理方法であって、前記実行順序において連続するオペレータの集合をステージと呼び、各ステージを構成するオペレータの計算コストの合計を、当該ステージの計算コストと呼び、各ステージの計算コストが、全オペレータの合計コストを計算コア数で割った値よりも小さな値となるように、クエリグラフを複数のステージに分割し、各計算コアは、入力ストリームから一つずつタプルを取り出して、クエリグラフの入口から出口まで当該タプルの処理を担当して実行する際に、各ステージの実行に先立って、担当タプルの一つ前のタプルについて当該ステージの処理が完了しているか否かを確認することに特徴がある。

上記本発明の特徴に従うストリームデータ多重処理方法によれば、クエリグラフを最短パスで処理することで得られる低レイテンシ性能と、計算コア数分の複数スレッドを並列動作させることで得られるスループット向上を両立する。したがって、低レイテンシ化、高スループット化の効果が得られる。

本発明の実施例のストリームデータ処理サーバが動作する計算機環境を示す図である。 クエリグラフの例である。 従来のストリームデータ処理の多重化方法における動作を示す図である。 上記実施例におけるストリームデータ処理サーバの構成を示す図である。 上記実施例におけるストリームデータ処理サーバのクエリ実行スレッドの動作を説明するフローチャートである。 上記実施例のストリームデータ処理の多重化方法における動作を示す図である。 上記実施例のステージ分割決定部で用いるコスト閾値を設定するユーザインタフェース画面を示す図である。 本発明の実施態様の変形例３における複数タプル一括処理に関する設定をするユーザインタフェース画面を示す図である。

以下、実施例を、図面を用いて説明する。

図１を用いて、本発明の実施例のストリームデータ処理サーバが動作する、計算機環境の一例を説明する。ストリームデータ処理サーバ１００は、ＣＰＵ９０、９１、９２、９３、メモリ１０３、ネットワークインタフェース１０５、ストレージ１０６、およびそれらを結合するバス１０４によって構成される計算機である。メモリ１０３上に、ストリームデータ処理の論理動作を定義するストリームデータ処理部１１０を配置する。ストリームデータ処理部１１０は、ＣＰＵ９０〜９３によって解釈実行可能な実行イメージである。

ストリームデータ処理サーバ１００は、ネットワークインタフェース１０５を介して外部ネットワーク１５０に接続される。外部ネットワーク１５０に接続されたホスト計算機１３０上で動作するクエリ登録コマンド実行インタフェース１３１を介して、ユーザによって定義されたストリームクエリ１３２を、ストリームデータ処理サーバ１００が受取る。すると、ストリームデータ処理部１１０は、そのクエリ定義に従ってストリームデータ処理を実行可能なクエリグラフを構築する。この後、外部ネットワーク１５０に接続されたデータ発生器１２０によって送信されるタプル１２１を、ストリームデータ処理サーバ１００が受取ると、ストリームデータ処理サーバ１００は該クエリグラフに従ってこれを処理し、結果タプル１４１を生成する。この結果タプル１４１は、ネットワーク１５０に接続されたデータ受信機１４０に送信される。ストレージ１０６は、ストリームデータ処理部１１０の実行イメージの他、一度受取った前記クエリ１３２のテキストファイルを保存する。ストリームデータ処理部１１０は、起動時にストレージ１０６からこのクエリのファイルをロードし、クエリグラフを構築することも可能である。

図４を用いて、ストリームデータ処理部１１０の論理構成を説明する。ユーザがストリームクエリ１３２の登録操作を実行すると、クエリパーサ４０２が、同クエリ１３２をクエリグラフ構成情報４０３に変換する。オペレータ実行順序決定部４０４は、同構成情報４０３を処理して、クエリグラフを構成するオペレータ間の実行順序を決定し、オペレータ実行順情報４０５として出力する。このオペレータ間の実行順序を決定する処理の一実現形態として、特許文献３に記載のアルゴリズムを利用可能である。オペレータ処理コスト算出部４０６は、該クエリグラフにおける各オペレータの処理時間見積りを計算コストとして算出し、ステージ分割決定部４０７に入力する。同決定部４０７は、前記クエリグラフを複数のステージに分割する。

ここでのステージとは、前記のクエリグラフを構成するオペレータ間の実行順序において、連続する一つ以上のオペレータの集合を指す。該クエリグラフにステージ分割結果を付与し、最終的にクエリ実行制御情報４０８を生成する。図の例では、ステージＡ、Ｂ、Ｃ、Ｄ、およびＥのそれぞれが、｛オペレータ１｝、｛オペレータ２｝、｛オペレータ３｝、｛オペレータ４、オペレータ５｝および｛オペレータ６｝の、それぞれのオペレータで構成されている。ステージ分割方法の動作は後述する。以上、クエリ実行制御情報４０８の生成までが、クエリ登録時の処理となる。

次に、クエリ実行時の動作を説明する。クエリ実行時には、クエリ実行スレッド４１０〜４１３が、当該計算機環境における計算リソース数に併せて動作を開始する。本例では、４つのＣＰＵコアが利用可能である環境で、クエリ実行スレッドが４つ起動するケースを想定する。

ここで、本実施例でのストリームデータ多重処理の特徴を述べると、順次到来するタプルの一つ一つに対してデータ処理を実行するスレッドを一つずつバインドして並列に処理を進めるのが特徴である。つまり、複数の計算コアが各々分割されたステージを担当し、順次到来するタプルをその複数コア間で渡していくパイプライン処理とは異なり、一つのタプルについての分割された複数のステージの処理を一つの計算コアが完遂する。このため、タプル入力部４５０は、入力タプル１２１を受取ると、タプル通番管理部４０９に渡す。タプル通番管理部４０９は、個々のタプルに、１ずつインクリメントする整数の通番を付与して、クエリ実行スレッド４１０〜４１３に渡す。同スレッドのうち、実行休止中であるスレッドの一つが、前記タプル１２１を処理する。

ここでは、タプル１２１に通番８８が付き、スレッド４１０が同タプルの処理を担当すると仮定する。スレッド４１０は、この通番８８を、ローカルな担当タプル実行状態保持領域４２０内に、担当タプル通番（図４の符号４２１）として保持する。また、同タプルの一つ前のタプル、即ち通番８７のタプルの処理をスレッド４１３が担当すると仮定する。

スレッド４１０は、通番８８のタプルについて、ステージＡの処理から実行する。その実行に先立って、担当の通番８８のタプルの一つ前のタプル、即ちスレッド４１３が担当する通番８７のタプルについて、ステージＡの処理が完了しているか否かを確認する。この確認は、ステージＡ実行済タプル通番フラグ４３７に格納されている値を、担当通番８８と比較することで実現する。本例では、クエリ実行スレッド４１０〜４１３の各々は、自らが担当するタプルの各ステージの実行が終了するごとに、クエリ実行状態保持領域４３０に作られた対応するステージの実行済みタプル通番フラグの値を、担当するタプル（その当該ステージの実行が終了したタプル）の通番から、次の通番に書き換える。スレッド４１０は、ステージＡ実行済タプル通番フラグ４３７の値を確認して、自らが担当するタプルの通番８８と一致しない場合、即ち一つ前の通番８７のタプルのステージＡの処理が完了していない場合には待機する。スレッド４１３は通番８７のタプルについてステージＡの処理（即ち、オペレータ１の処理）を完了した段階で、実行済タプル通番フラグ４３７の値を８７から８８に変更する。スレッド４１０によるステージＡの実行に先立つ実行済タプル通番フラグ４３７の確認は、例えば一定周期で繰り返し行い、このフラグ値の変更を認識した段階で、通番８８についてのステージＡの処理を開始する。

このように、各クエリ実行スレッドが、各ステージの処理を開始する前に、直前のタプルについて、当該ステージの処理が完了しているか否かを、タプル通番フラグ４３７〜４４１を介して、クエリ実行スレッド間で確認するプロトコルに従って、多重処理を推進する。ここで、各オペレータ１〜６の実行状態は、クエリ実行状態保持領域４３０上の、オペレータ実行状態４３１〜４３６で管理し、全てのスレッド４１０〜４１３で共有するため、このようなプロトコルによる一貫性管理が必要になる。

クエリグラフ中に、時間ウィンドウ演算、遅延演算などの時限発火型のオペレータが存在する場合は、これらオペレータが出力するタプルの処理順序も、併せて考慮する必要がある。例えば、遅延時間を４分とする遅延演算は、タイムスタンプ１０：００丁度のタプルを入力したら、その４分後に、そのタプルにタイムスタンプ１０：０４を付けて出力するオペレータである。即ち、１０：００のタプルを入力した時点で、１０：０４のタプルの出力を予定することになる。その後、１０：０４まではクエリ実行スレッド４１０〜４１３の全てが実行中であり、１０：０４を若干経過した時刻に、クエリ実行スレッド４１０が実行休止状態に移行したとする。このとき、クエリ実行スレッド４１０では、仮に１０：０４の数マイクロ秒後のタイムスタンプが付いたタプルが入力ストリームに存在していたとしても、遅延演算が予定していたタイムスタンプ１０：０４のタプルの出力を、先に実行する必要がある。そのため、時限発火オペレータにおいて、次に出力する予定のタプルは、タプル通番管理部４０９に登録する。タプル通番管理部４０９は、登録されたタプルと、入力ストリームの先頭のタプルのタイムスタンプを比較して、より過去の方から順に通番を付与して、クエリ実行スレッドに渡す。

次に、図５のフローチャートを用いて、各クエリ実行スレッドの動作を説明する。処理５０１で、タプル通番管理部４０９より入力タプルを取得し、処理５０２で、入力タプルのデータ、および入力タプルに付与されたタプル通番を、担当タプル実行状態保持領域４２０に格納する。その後、クエリグラフを構成する全ステージについて、処理５０４〜５０７を繰り返す。図５のボックス５０３、５０８はループ繰り返しを示す。ループの最初の処理５０４では、実行済タプル通番フラグ４３７〜４４１を確認し、当該スレッドが担当するタプルの通番と、値が一致するか否かによって条件分岐する。一致しない場合は、処理５０４をスピンで繰返し、一致する場合は処理５０５に進む。

処理５０５では、実行状態保持領域４２０に保持しているタプル（群）について、当該ステージに属するオペレータの処理を実行する。処理５０６では、その結果のタプル（群）を実行状態保持領域４２０に格納する。ここで、オペレータによっては、一つのタプルを入力して複数のタプルを出力する場合もあるため、実行状態保持領域４２０で管理されるデータは複数存在し得る。処理５０７では、担当タプルについて、当該ステージの処理が完了したため、当該ステージのタプル通番フラグを１インクリメントし、次のステージの処理に移る。全てのステージの処理が完了すると、処理５０９にて、結果タプルをタプル出力部４５１から出力し、当該担当タプルについての、全クエリグラフの処理を完了する。当該スレッドは再び休止状態に入る。全てのクエリ実行スレッドが、同一のフローに従って動作する。

次に、図６を用いて、ステージ分割決定部４０７における、ステージの分割方法を説明する。本説明では、図２に示したクエリグラフの例をサンプルとしている。同クエリグラフについて、オペレータ実行順序決定部４０４が決定するオペレータの実行順序は、ＯＰ１〜１０の順番になるとする。また、本例では４つの計算コアでのクエリ実行を想定する。まず、クエリグラフの全計算コストを計算コア数で割った値である２５に対して、さらにマージンをとった２２を、計算コストの閾値とする。前記オペレータ実行順に従って、オペレータの計算コストを加算して行き、前記閾値を超えないようにステージを分割する。

本例では、ＯＰ１〜２の計算コストの和が２１、ＯＰ１〜３の和が２４となるため、閾値以下に収まるＯＰ２までを、最初のステージＡとする。以降、同様の分割ポリシを適用することで、ＯＰ３〜５、ＯＰ６〜７、ＯＰ８〜９、およびＯＰ１０に分けられ、最終的にステージＡ〜Ｅの計５ステージ（６０１〜６０５）となる。各ステージの計算コストは、それぞれステージＡ（６０１）が２１、ステージＢ（６０２）が１８、ステージＣ（６０３）が１８、ステージＤ（６０４）が２２、ステージＥ（６０５）が２１となる。１タプルの処理時間に対する、各ステージの処理時間の割合は６１０に示す通りである。

ここで、タプル処理時間の１／４の間隔でタプルが到来するケースにおいて、図４に示した構成と、図５に示したフローに従って処理した場合、各タプルは、各計算コアにおいて、タイムチャート６１１に示すようなスケジュールで処理されることになる。図３のタイムチャート３１１と異なり、処理の空白期間や待ちは発生しない。詳しく述べると、従来のパイプライン処理によるクエリ処理では、タプルが等間隔で順次到来するという、いわば理想的な入力の状況であっても、図３のタイムチャート３１１で示したように最も処理時間が長いステージに処理速度が律速され、他のステージをそれぞれ担当する計算コアに処理の空白、つまり無駄時間が生じてしまう。これに対し、本実施例のプロトコルによる処理では、タプルが等間隔で順次到来する入力状態では、図６のタイムチャート６１１に示すとおり全く空白時間が発生しない。

タプルの到来が不等間隔になった場合に処理待ちが発生するのは、従来のパイプライン処理と本実施例の両者に共通である。但し、図６の実施例のプロトコルにおいて、タプルの到来が不当間隔になった場合に、それにより処理待ちが発生するのは、図６の例では、分割した各ステージの処理コストが図３の例に比べてさほど小さくないからである。先に述べた説明では、全計算コストを計算機コア数４で割った値２５に対して計算コストの閾値を２２とし、この閾値を超過しない範囲で順次オペレータを統合してステージを決定していた。タプルの到来が不等間隔になったときの空白時間の発生は、この計算コスト閾値の大きさに依存する。全計算コストを計算機コア数で割った値に対するマージンをより大きくし、つまり計算コスト閾値をより小さな値として各計算コアに分担させるステージの分割を細かくし、一つのステージの計算時間を十分小さくとれば、タプルの到来時間がばらつくことによる空白時間の発生は回避可能である。タプルの到来時間のばらつきによる最短到来間隔が分かっていれば、その最短到来間隔よりも各計算コアの分担ステージの処理時間を短くすることで空白時間の発生を完全に回避できる。したがって、本実施例では、タプルが等間隔で順次到来するという限られた条件下のみでなく、到来時間がばらついても、低レイテンシ化、高スループット化の効果が得られる。

本実施例のシステムは、ステージ分割決定部４０７での計算コア間のステージ分担の決定に用いる計算コスト閾値の設定に関わる係数（コスト閾値決定係数）をユーザに決定させるユーザインタフェースを有する。図７はそのユーザインタフェース画面を示す。ユーザインタフェース画面中の設定領域７０１には、０より大かつ１．０以下の任意の小数をコスト閾値決定係数として設定可能であり、かつ設定された値が表示される。ステージ分割決定部４０７は、クエリグラフの全計算コストを計算コア数で割った値に、設定されたコスト閾値決定係数を掛けて計算コスト閾値とする。この計算コスト閾値を超過しない範囲で順次オペレータを統合して、各計算機コアに分担させるステージを決定する。ユーザはストリームデータのタプル到来の状況に応じてコスト閾値決定係数を設定し、これによって各計算コアに分担させるステージ分割の細かさを設定できる。したがって、タプル到来間隔のばらつきの大小に応じたステージ分割が可能であり、実質的に待ちを回避して、各計算コアの計算時間をフルに利用することが可能となる。上記のコスト閾値決定係数を決定させるユーザインタフェースは、ストリーム処理サーバ１００のコンソールユニットに実現される。もしくはホスト計算機１３０に上記ユーザインタフェースを設けても良い。

＜変形例１＞
上記した実施例では、クエリ実行状態保持領域４３０に格納されている、各オペレータの実行状態４３１〜４３６を、クエリ実行スレッド４１０〜４１３間で引き継ぐ際に、ＣＰＵコア間のキャッシュコヒーレンス制御のオーバヘッドが、性能劣化要因となる可能性がある。一方、６１１のタイムチャートでは、連続するタプルの各ステージでの処理の間に、若干の猶予期間がある。そこで変形例１では、それぞれのタプルを担当する計算コアでは、実行中のステージが完了する少し前に、次のステージに属するオペレータの実行状態をその計算コア内のキャッシュにプリフェッチする。例えば、ステージＢの処理に関して、計算コア０におけるタプル０についての処理Ｂ０の終了後、後続の、計算コア１におけるタプル１についての処理Ｂ１が開始するまでには、若干の時間がある。この期間を利用して、実行中のステージの処理を完了する少し前に、次のステージに属するオペレータの実行状態を、計算コアのキャッシュにプリフェッチする。例えば、計算コア１におけるタプル１についてのステージＡの処理Ａ１が終了する（即ち、処理Ｂ１が開始する）直前に、ステージＢに属するオペレータ（ＯＰ３〜５）の実行状態をプリフェッチする。

この変形例１の構成をとることにより、上記の例で計算コア１による処理Ｂ１を開始しようとした時点で計算コア１内のキャッシュ上でステージＢに属するオペレータの実行状態がダーティのまま残ることが回避される。すなわち、クエリ実行がスレッド間で引き継がれる際のＣＰＵ待ちの時間内に行うプリフェッチにより、キャッシュコヒーレンス制御を改めて実施することが回避される。これを有効に行うためには、上記の例でステージＢに属するオペレータの実行状態のプリフェッチは、一つ前のタプル０を担当する計算コア０によるステージＢの処理Ｂ０が完了している可能性が高いタイミングで行うのが良い。とくに、タプルの到来の周期が安定している場合に、次のタプルの到来の予測時刻の直前で先頭のステージＡに属するオペレータの実行状態のプリフェッチを行うことが可能であり、キャッシュコヒーレンス制御のオーバヘッド削減の効果を確実に得ることが出来る。

＜変形例２＞
ストリームデータ処理では、同一タイムスタンプで複数のタプルが到来するようなストリームを処理する場合もある。先の実施例でも問題にしていたタプル到来周期のばらつきが極端に著しい場合であるとも言える。変形例２では、入力ストリームの先頭に、同一タイムスタンプのタプルが連続している場合に、各クエリ実行スレッド４１０〜４１３が、当該連続タプルを一括して処理するようにした。

この変形例２では、同一のタイムスタンプの複数タプルについて、同じ計算コア内で順次各ステージの処理が行われる。したがって、その計算コア内でキャッシュのヒット率が向上するので、その分だけ１タプル当たりの処理時間の短縮が期待される。ただし、同一タイムスタンプのタプルの数が大きく変動するストリームの場合には各スレッドに分担するタプル数が不揃いになる、つまり処理時間が不揃いになるため、処理の空白や待ちが生じてしまう。同一タイムスタンプのタプルの数が比較的に安定して推移する場合には、処理の空白は軽減され、上記した１タプル当たりの処理時間の短縮によりストリーム処理のスループット向上の効果が得られる。

＜変形例３＞
上記変形例２で生じる各クエリ実行スレッドの処理時間の不揃いの発生を軽減するため、変形例３ではより詳細な設定を可能する。図８は実施例３の同一計算機コア内の複数タプル一括処理の設定に関するユーザインタフェース画面を示す。ユーザインタフェース画面８０１の中の設定領域８０３には一括処理の候補とするタプルと判断するタイムスリット幅の設定値が設定される。領域８０４には設定領域８０３への設定のメニューが示されており、チェックマークを入力すると対応する値（図では２．０マイクロセカンド）がタイムスリット幅として設定される。入力ストリームの先頭のタプルに続き、設定されたタイムスリット幅の期間内に後続のタプルが到来したなら、これらタプルは、クエリ実行スレッド４１０〜４１３のうち実行停止状態であるいずれか一つが一括して処理するタプルの候補となる。ただし、設定領域８０５には一括処理をする最大タプル数が設定される。ここでも領域８０６に示されたメニューのなかから選択された値（図では４）が設定される。この場合には上記期間内に多数のタプルが到来しても一つのスレッドで処理されるタプルの数は４である。なおメニューのなかから「無制限」が選択されて設定された場合には、設定されたタイムスリットの期間内に到来した全てのタプルが一つのスレッドで一括処理される。またメニューのなかから１が選択されて設定された場合には、一括処理のタプル数は１であり、つまり一つのスレッドで連続する複数タプルの一括処理は行わない。

このように変形例３では連続タプルの一括処理について多様な設定が可能でありユーザが入力ストリームの状況に合わせた柔軟な指定が可能である。このようなユーザインタフェース画面は、ストリームデータ処理サーバ１００のコンソールか、ホスト計算機１３０のいずれかに設けられる。

以上、本発明の実施形態について説明したが、これらは本発明を説明するための例示であり、本発明の適応範囲を例示した形態のみに限定するものではない。また、前述した実施形態のいかなる組み合わせも本発明の実施形態となり得る。

１００ ストリームデータ処理サーバ
９０〜９３ ＣＰＵ
１０３ メモリ
１０４ バス
１０５ ネットワークインタフェース
１０６ ストレージ
１２０ データ発生器
１３０ ホスト計算機
１３１ クエリ登録インタフェース
１３２ ストリームクエリ
１４０ データ受信器
１２１、１４１ タプル
１５０ ネットワーク
２０１〜２１０ オペレータ
３０１〜３０４ パイプライン処理におけるステージ
３１０ パイプライン処理における各ステージの処理時間の比率
６０１〜６０５ 本発明におけるステージ
６１０ 本発明における各ステージの処理時間の比率
３１１、６１１ 各計算コアにおける各タプルについての各ステージの処理時間
４０２ クエリパーサ
４０３ クエリグラフ構成情報
４０４ オペレータ実行順序決定部
４０５ オペレータ実行順情報
４０６ オペレータ処理コスト算出部
４０７ ステージ分割決定部
４０８ クエリ実行制御情報
４０９ タプル通番管理部
４１０〜４１３ クエリ実行スレッド
４２０ 担当タプル実行状態保持領域
４３０ クエリ実行状態保持領域
４３１〜４３６ オペレータ別実行状態
４３７〜４４１ ステージ別実行済タプル通番フラグ
４５０ タプル入力部
４５１ タプル出力部
５０１〜５０９ クエリ実行スレッドのフローチャート

Claims (7)

1. タイムスタンプが付与されたタプルの系列であるストリームを対象として、ユーザが定義したクエリ定義を、クエリグラフに変換し、前記クエリグラフを構成するオペレータ間の実行順序を決定するクエリパーサを備え、かつ前記クエリグラフを構成するオペレータの集合である複数のステージのいずれをも実行可能にされた複数のクエリ実行スレッドを備えたストリームデータ処理システムによるストリームデータ多重処理方法であって、前記クエリグラフを、各々が連続する複数のオペレータの集合である前記複数のステージに分割し、前記クエリ実行スレッドのうち、実行停止状態にある第１のクエリ実行スレッドが、その時点において前記ストリームの先頭に位置する、第１のタプルを抽出し、前記ストリームにおいて、前記第１のタプルの一つ前に位置していた、第２のタプルについて、前記複数のステージのうちの、最初に実行すべき第１のステージにおける処理が完了しているか否かを確認し、前記処理の完了が確認され次第、前記第１のタプルについて、前記第１のステージの処理を実行し、前記第１のステージの処理が完了次第、前記第２のタプルについて、次に実行すべき第２のステージにおける処理が、完了しているか否かを確認し、処理の完了が確認され次第、前記第１のタプルについて前記第２のステージを実行するという順次処理を、前記第１のクエリ実行スレッドが、前記第１のタプルについて、前記複数ステージの全ての処理が完了するまで継続し、もって前記複数のクエリ実行スレッドが各々抽出したクエリの処理を同時並行で実行することを特徴とするストリームデータ多重処理方法。
2. 請求項１に記載のストリームデータ多重処理方法であって、前記クエリグラフを複数のステージに分割する処理は、前記全オペレータの処理コストの合計をクエリ実行スレッド数で割った値以下の値をコスト閾値として設定し、前記オペレータ間の実行順序に従って並べた先頭から、各ステージを構成するオペレータの処理コスト合計が、設定された前記コスト閾値を超過しないように前記クエリグラフを各ステージに分割する手順を含むことを特徴とする、ストリームデータ多重処理方法。
3. 請求項２に記載のストリームデータ多重処理方法であって、前記コスト閾値として、前記全オペレータの処理コストの合計をクエリ実行スレッド数で割った値と、０より上かつ１．０以下であってユーザにより選択された係数との積を設定することを特徴とする、ストリームデータ多重処理方法。
4. 請求項１に記載のストリームデータ多重処理方法であって、前記クエリグラフが、時間ウィンドウ、遅延オペレータといった、時限発火型のオペレータを含む場合に、前記時限発火型オペレータが生成する、タプルのタイムスタンプと、前記入力ストリームの先頭のタプルのタイムスタンプを比較し、より過去のタイムスタンプを持つタプルから順に処理することを特徴とする、ストリームデータ多重処理方法。
5. 請求項１に記載のストリームデータ多重処理方法であって、前記第１のクエリ実行スレッドは、前記第１のステージの処理完了に若干先立って、前記第２のタプルについて、前記第２のステージにおける処理が、完了しているか否かを確認し、前記第２のステージの処理の実行状態等を、キャッシュメモリにプリフェッチすることを特徴とする、ストリームデータ多重処理方法。
6. 請求項１に記載のストリームデータ多重処理方法であって、実行停止状態にある前記第１のクエリ実行スレッドは、その時点において前記ストリームの先頭に連続して位置する、同一のタイムスタンプを持つ複数のタプルを抽出し、前記順次処理を、前記第１のクエリ実行スレッドが、前記複数のタプルについて、全てのステージの処理が完了するまで継続する、ことを特徴とする、ストリームデータ多重処理方法。
7. 請求項１に記載のストリームデータ多重処理方法であって、実行停止状態にある前記第１のクエリ実行スレッドは、その時点において、前記ストリームの先頭に、ユーザが指定したタイムスタンプ範囲内で連続して位置する、複数のタプルを抽出し、該第１のクエリ実行スレッドが、前記複数のタプルについて、全てのステージの処理が完了するまで前記順次処理を継続することを特徴とする、ストリームデータ多重処理方法。

Images