(57)【要約】【課題】ストリームデータ処理システムのストリームデータのクエリ処理に関するスループットを向上させること。【解決手段】サーバ装置２のスケジューラ３３が、クエリ４３をグループ化するクエリグループへのデータ停滞が発生すると、クエリグループを構成するクエリ４３ごとに、そのクエリ４３の入力流量情報およびレイテンシ情報の内の少なくとも１つの情報を基に、そのクエリの負荷評価値を計算し、クエリグループを構成するクエリ４３を、互いにクエリの負荷評価値の和が略均等になるように、複数のクエリグループへと分割し、分割後の複数のクエリグループを、それぞれ異なるプロセッサ９１に再割り当てする。【選択図】図１
2010204880.tif 000002
【特許請求の範囲】
【請求項１】
入力され続けるストリームデータを受け付け、クエリ演算処理を実行するストリームデータ処理装置によるストリームデータ処理方法であって、
前記ストリームデータ処理装置は、前記ストリームデータを格納する記憶手段と、前記ストリームデータ処理装置を制御するストリーム制御部と、前記ストリームデータに対して前記クエリ演算処理を実行するクエリ実行部と、前記ストリームデータ処理装置の計算機資源を割り当てるスケジューラと、を有し、
前記スケジューラは、
前記クエリ演算処理を定義する１つ以上のクエリをクエリグループとしてグループ化し、そのクエリグループを単位として前記計算機資源のスレッドに割り当てることで、前記クエリ実行部に前記クエリ演算処理を実行させ、
所定クエリグループへのデータ停滞が発生すると、
前記所定クエリグループを構成するクエリごとに、そのクエリの入力流量情報およびレイテンシ情報の内の少なくとも１つの情報を前記記憶手段から読み取り、そのクエリの負荷評価値を計算し、
前記所定クエリグループを構成するクエリを、互いにクエリの負荷評価値の和が略均等になるように、複数のクエリグループへと分割し、
前記分割後の複数のクエリグループを、それぞれ異なる前記計算機資源のスレッドに再割り当てするように、前記ストリーム制御部に指示することを特徴とする
ストリームデータ処理方法。
【請求項２】
前記スケジューラは、前記所定クエリグループへの前記ストリームデータの入力流量が、前記所定クエリグループを構成する各クエリの処理流量の平均値を超えたときに、前記所定クエリグループへのデータ停滞を検知することを特徴とする
請求項１に記載のストリームデータ処理方法。
【請求項３】
前記スケジューラは、前記所定クエリグループへの前記ストリームデータの入力流量が、所定閾値を超えたときに、前記所定クエリグループへのデータ停滞を検知することを特徴とする
請求項１に記載のストリームデータ処理方法。
【請求項４】
前記スケジューラは、前記ストリームデータ処理装置の前記計算機資源のスレッドについて、割当済みのスレッド数が利用可能なスレッド数と等しいときには、前記所定クエリグループを複数のクエリグループへと分割する処理を省略することを特徴とする
請求項１ないし請求項３のいずれか１項に記載のストリームデータ処理方法。
【請求項５】
前記スケジューラは、
前記クエリ演算処理を定義する１つ以上のクエリをクエリグループとしてグループ化するときに、クエリの構成要素であるオペレータをクエリグループとしてグループ化することを特徴とする
請求項１ないし請求項４のいずれか１項に記載のストリームデータ処理方法。
【請求項６】
前記スケジューラは、クエリごとの負荷評価値を計算するときに、そのクエリの入力流量と、そのクエリのレイテンシとの積を、負荷評価値とすることを特徴とする
請求項１ないし請求項５のいずれか１項に記載のストリームデータ処理方法。
【請求項７】
請求項１ないし請求項６のいずれか１項に記載のストリームデータ処理方法を、コンピュータである前記ストリームデータ処理装置に実行させるためのストリームデータ処理プログラム。
【請求項８】
入力され続けるストリームデータを受け付け、クエリ演算処理を実行するストリームデータ処理装置であって、
前記ストリームデータ処理装置は、前記ストリームデータを格納する記憶手段と、前記ストリームデータ処理装置を制御するストリーム制御部と、前記ストリームデータに対して前記クエリ演算処理を実行するクエリ実行部と、前記ストリームデータ処理装置の計算機資源を割り当てるスケジューラと、を有し、
前記スケジューラは、
前記クエリ演算処理を定義する１つ以上のクエリをクエリグループとしてグループ化し、そのクエリグループを単位として前記計算機資源のスレッドに割り当てることで、前記クエリ実行部に前記クエリ演算処理を実行させ、
所定クエリグループへのデータ停滞が発生すると、
前記所定クエリグループを構成するクエリごとに、そのクエリの入力流量情報およびレイテンシ情報の内の少なくとも１つの情報を前記記憶手段から読み取り、そのクエリの負荷評価値を計算し、
前記所定クエリグループを構成するクエリを、互いにクエリの負荷評価値の和が略均等になるように、複数のクエリグループへと分割し、
前記分割後の複数のクエリグループを、それぞれ異なる前記計算機資源のスレッドに再割り当てするように、前記ストリーム制御部に指示することを特徴とする
ストリームデータ処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストリームデータ処理方法、ストリームデータ処理プログラム、および、ストリームデータ処理装置の技術に関する。
【背景技術】
【０００２】
従来、企業情報システムのデータ管理の中心にはデータベース管理システム（以下、ＤＢＭＳとする）が位置づけられていた。ＤＢＭＳは、処理対象のデータをストレージに格納し、格納したデータに対してトランザクション処理に代表される高信頼な処理を実現している。これに対して、時々刻々と到着する大量のデータをリアルタイム処理するデータ処理システムへの要求が高まっている。例えば、株取引を支援するファイナンシャルアプリケーションを考えた場合、株価の変動に如何に迅速に反応できるかがシステムの最重要の課題の一つである。
【０００３】
従来のＤＢＭＳのように株式のデータを一旦記憶装置に格納してから、該格納データに関して検索を行うようなシステムでは、データの格納とそれに続く検索処理が株価変動のスピードに追いつくことができず、ビジネスチャンスを逃してしまうことになりかねない。Ｊａｖａ（登録商標）に代表されるプログラミング言語を用いて、各種のリアルタイムアプリケーションを個別に作りこむアプローチは、開発期間の長期化、開発コストの高騰、該アプリケーションを利用する業務の変化への迅速な対応が難しいなどの問題があり、汎用のリアルタイムデータ処理機構が求められるようになっていた。このようなリアルタイムデータ処理に好適なデータ処理システムとして、特許文献１，２などに記載された、ストリームデータ処理システムが提案されている。
【０００４】
非特許文献１には、ストリームデータ処理システムＳＴＲＥＡＭが開示されている。ストリームデータ処理システムでは、従来のＤＢＭＳとは異なり、まずクエリ（問合せ）をシステムに登録し、データの到来と共に該クエリが継続的に実行される。ここでのストリームデータとは、映像ストリームのような論理的に継続する一つの大きなデータではなく、ファイナンシャルアプリケーションにおける株価配信データ、小売業でのＰＯＳデータ、交通情報システムにおけるプローブカーデータ、計算機システム管理におけるエラーログ、センサやＲＦＩＤなどのユビキタスデバイスから発生するセンシングデータなど、比較的小さな論理的には独立した大量の時系列データである。
【０００５】
ストリームデータは継続してシステムに到着し続けるため、その終わりを待ってから処理を開始するのでは実時間での処理は不可能である。また、システムに到着したデータは、データ処理の負荷に影響されることなく、その到着順を守って処理する必要がある。前記ＳＴＲＥＡＭでは、システムに到来し続けるストリームデータを、最新１０分間などの時間の幅、もしくは最新１０００件などの個数の幅を指定してストリームデータの一部を切り取りながらリアルタイムの処理を実現するため、スライディングウィンドウ（以下単にウィンドウと呼ぶ）と呼ばれる概念を導入している。
【０００６】
非特許文献１には、ウィンドウ指定を含むクエリの記述言語の好適な例として、ＣＱＬ（Continuous Query Language）が開示されている。ＣＱＬは、ＤＢＭＳで広く用いられているＳＱＬ（Structured Query Language）のＦＲＯＭ句に、ストリーム名に続いて括弧を用いることにより、ウィンドウを指定する拡張が施されている。
【０００７】
従来のＤＢＭＳで取り扱うテーブル（表）のような静止化されたデータではなく、切れ目のないストリームデータでは、ウィンドウ指定による、ストリームデータのどの部分を対象とするかの指定なしでは、処理不可能となる。ウィンドウによって切り取られたストリームデータはメモリ上に保持され、クエリ処理に使用される。
【０００８】
代表的なウィンドウの指定方法には、ウィンドウの幅を時間で指定するＲａｎｇｅウィンドウと、ウィンドウの幅をデータ数で指定するＲｏｗウィンドウがある。例えば、Ｒａｎｇｅウィンドウを用いて、［Ｒａｎｇｅ  １０  ｍｉｎｕｔｅｓ］とすると、最新の１０分間分がクエリ処理の対象となり、Ｒｏｗウィンドウを用いて［Ｒｏｗｓ  １０］とすると、最新の１０件がクエリ処理の対象となる。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２００３−２９８６６１号公報
【特許文献２】特開２００６−３３８４３２号公報
【非特許文献】
【００１０】
【非特許文献１】R. Motwani, J. Widom, A. Arasu, B. Babcock, S. Babu, M. Datar, G. Manku, C. Olston, J. Rosenstein, and R. Varma著:「Query Processing, Resource Management, and Approximation in a Data Stream Management System」,section 2(Query Language),In Proc. of the 2003 Conf. on Innovative Data Systems Research (CIDR), January 2003
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ストリームデータ処理システムで扱うストリームデータは、切れ目無く時々刻々と到来するデータ群であるが、ストリームデータ処理システムが１つのデータに対してクエリ処理する速度が単位時間当たりに到来するデータの速度に満たない場合、到来するデータを処理しきれない。負荷の高いクエリ処理がボトルネックとなってしまい、そのクエリ処理の周辺にデータ停滞が発生してしまう。そして、データ停滞が一カ所でも発生すると、そのシステム全体のスループットが低下してしまう。
【００１２】
そこで、本発明は、前記した問題を解決し、ストリームデータ処理システムのストリームデータのクエリ処理に関するスループットを向上させることを、主な目的とする。
【課題を解決するための手段】
【００１３】
前記課題を解決するために、本発明は、入力され続けるストリームデータを受け付け、クエリ演算処理を実行するストリームデータ処理装置によるストリームデータ処理方法であって、
前記ストリームデータ処理装置が、前記ストリームデータを格納する記憶手段と、前記ストリームデータ処理装置を制御するストリーム制御部と、前記ストリームデータに対して前記クエリ演算処理を実行するクエリ実行部と、前記ストリームデータ処理装置の計算機資源を割り当てるスケジューラと、を有し、
前記スケジューラが、
前記クエリ演算処理を定義する１つ以上のクエリをクエリグループとしてグループ化し、そのクエリグループを単位として前記計算機資源のスレッドに割り当てることで、前記クエリ実行部に前記クエリ演算処理を実行させ、
所定クエリグループへのデータ停滞が発生すると、
前記所定クエリグループを構成するクエリごとに、そのクエリの入力流量情報およびレイテンシ情報の内の少なくとも１つの情報を前記記憶手段から読み取り、そのクエリの負荷評価値を計算し、
前記所定クエリグループを構成するクエリを、互いにクエリの負荷評価値の和が略均等になるように、複数のクエリグループへと分割し、
前記分割後の複数のクエリグループを、それぞれ異なる前記計算機資源のスレッドに再割り当てするように、前記ストリーム制御部に指示することを特徴とする。
その他の手段は、後記する。
【発明の効果】
【００１４】
本発明によれば、ストリームデータ処理システムのストリームデータのクエリ処理に関するスループットを向上させることができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の一実施形態に関するストリームデータ処理システムを示す構成図である。
【図２】本発明の一実施形態に関するクエリ処理部３０の詳細を示す説明図である。
【図３】本発明の一実施形態に関するクエリグループ４５の分割処理を示す説明図である。
【図４】本発明の一実施形態に関するクエリグループ管理テーブル３７内の登録情報を示す説明図である。
【図５】本発明の一実施形態に関する１つのクエリ４３を、複数のクエリグループ４５に分割する旨を示す説明図である。
【図６】本発明の一実施形態に関する統計情報テーブル３８を示す構成図である。
【図７】本発明の一実施形態に関する統計情報取得部３４が実行する、統計情報テーブル３８の作成処理を示すフローチャートである。
【図８】本発明の一実施形態に関する流量監視部３２が実行する、データ停滞の監視処理を示すフローチャートである。
【図９】本発明の一実施形態に関するスケジューラ３３が実行する、クエリグループ４５（Ｇｉ）を対象とする分割処理の詳細を示すフローチャートである。
【図１０】本発明の一実施形態に関するスケジューラ３３が実行する、クエリグループ４５（Ｇｉ）の分割位置の決定処理を示すフローチャートである。
【発明を実施するための形態】
【００１６】
以下、図面を用いて、本発明の一実施形態を説明する。
【００１７】
図１は、本実施形態のストリームデータ処理システムを示す構成図である。ストリームデータ処理システムは、１台以上のクライアント装置１と、サーバ装置２と、１つ以上のストリームソース４１と、がネットワーク９を介して接続されて構成される。なお、ネットワーク９は、イーサネット（登録商標）、光ファイバなどで接続されるローカルエリアネットワーク（ＬＡＮ）、もしくはＬＡＮよりも低速なインターネットを含んだワイドエリアネットワーク（ＷＡＮ）でも差し支えない。
【００１８】
ストリームソース４１は、時々刻々と大量のストリームデータを配信（出力）する情報源である。ストリームデータの好適な例としては、ファイナンシャルアプリケーションにおける株価配信情報、小売業でのＰＯＳデータ、交通情報システムにおけるプローブカー情報、計算機システム管理におけるエラーログなどが挙げられる。
ストリームソース４１から配信されるストリームデータの一例を示す。ストリームデータ「Ｓ１」は、３つの整数型の変数（ａ，ｂ，ｃ）と、１つの浮動小数点型の変数（ｘ）とで１つのタプルを構成する。このストリームデータ「Ｓ１」は、以下のように定義される。
register stream S1
(a int, b int, c int, x float)
【００１９】
クライアント装置１は、例えば、パーソナルコンピュータ、ブレード型の計算機システムなどの任意のコンピュータシステムとして構成される。クライアント装置１は、アプリケーション処理部１ａを有する。アプリケーション処理部１ａは、コマンド４２およびクエリ４３を入力として、アプリケーションを実行し、その結果をクエリ処理結果４４として出力する。
【００２０】
サーバ装置２は、１つ以上のプロセッサ９１、主記憶装置９２、入力装置９３、出力装置９４、および、補助記憶装置９５を備えた計算機である。サーバ装置２は、例えば、ブレード型計算機システム、ＰＣサーバなどの任意のコンピュータシステムとして構成される。
なお、プロセッサ９１は、マルチコアを有するハードウェアとして構成されていてもよいし、マルチスレッドをサポートしたハードウェアとして構成されていてもよい。これらのハードウェアを機能させるためのＯＳがプロセッサ９１によって動作する。つまり、サーバ装置２には、複数のスレッドを割り当てるための計算機資源が搭載されている。
なお、スレッド（thread）とは、ＣＰＵを利用してプログラムを実行するときの実行単位である。
【００２１】
ストリーム処理部１０は、主記憶装置９２に展開され、サーバ装置２を構成する各要素と連携して動作する。ストリーム処理部１０は、ストリーム制御部１１により制御される。さらに、ストリーム処理部１０は、インタフェース部１２と、コマンド処理部２０と、クエリ処理部３０とを含めて構成される。
【００２２】
なお、特許文献２には、ストリーム処理部１０のうちの一部の方法について、好適な実施の方法が開示されている。例えば、特許文献２には、クエリ登録の詳細な手順、ストリームデータ処理システム内部のデータの格納方法、格納形式、クエリを受け付けた後の解析方法、最適化方法、システムへの登録方法、ストリームデータ処理システムへのストリームの登録方法、システム内のデータ保持方法について、それぞれ開示されている。
【００２３】
インタフェース部１２は、サーバ装置２の各ハードウェア（入力装置９３、出力装置９４、および、ネットワーク９と接続するための図示しない通信用インターフェスなど）と、サーバ装置２のストリーム処理部１０との間で、データ仲介をするインタフェースである。例えば、インタフェース部１２は、入力装置９３を介して入力されたストリームソース４１を、クエリ処理部３０に送付する。
【００２４】
コマンド処理部２０は、コマンド解析部２１と、コマンド実行部２２と、コマンド管理部２３とを含めて構成される。
コマンド解析部２１は、コマンド４２を構文解析する。
コマンド４２は、ストリーム制御部１１に対して入力される、ストリーム処理部１０の制御情報である。コマンド４２は、サーバ装置２の入力装置９３から入力されてもよいし、クライアント装置１に入力された後にネットワーク９を経由して受信してもよい。
コマンド実行部２２は、コマンド解析部２１が解析したコマンド４２を、コマンド管理部２３に登録する。
【００２５】
クエリ処理部３０は、クエリ解析部３１と、流量監視部３２と、スケジューラ３３と、統計情報取得部３４と、クエリ実行部３５と、クエリリポジトリ３６と、クエリグループ管理テーブル３７と、統計情報テーブル３８と、を含めて構成される。
クエリ解析部３１は、クエリ４３を構文解析してから最適化して実行形式に変換し、クエリリポジトリ３６に格納する。
クエリ４３は、サーバ装置２の入力装置９３から入力されてもよいし、クライアント装置１に入力された後にネットワーク９を経由して受信してもよい。
【００２６】
図２は、クエリ処理部３０の詳細を示す説明図である。
【００２７】
流量監視部３２は、クエリ実行部３５が処理対象とするストリームデータが、クエリ実行部３５のクエリ演算処理の内部または外部でデータ停滞している事象を監視する。具体的には、流量監視部３２は、クエリ演算処理の内部におけるデータ停滞を検知するために、統計情報テーブル３８の情報を参照するとともに、クエリ演算処理の外部におけるデータ停滞を検知するために、クエリ実行部３５内のキュー（後記する入力キュー４６、中間キュー４８）の使用状態を参照する。そして、流量監視部３２は、データ停滞を検知すると、スケジューラ３３に通知する。
【００２８】
スケジューラ３３は、クエリ４３の集合をクエリグループ４５として形成し、そのクエリグループ４５単位でスレッドに割り当てる。スケジューラ３３は、クエリグループ４５の構成結果をクエリグループ管理テーブル３７に書き込む。さらに、スケジューラ３３は、流量監視部３２からのデータ停滞通知を受けると、統計情報取得部３４を参照して、データ停滞している１つのクエリグループ４５を２つのクエリグループ４５へと分割し、その２つのクエリグループ４５それぞれについて、別々のスレッドに割り当てる。
統計情報取得部３４は、クエリ４３ごとの実行時の統計情報をクエリ実行部３５から取得して、統計情報テーブル３８（図６参照）に書き込む。
【００２９】
クエリ実行部３５は、ストリームソース４１から入力されたストリームデータに対して、クエリ４３が示すクエリ演算処理を実行し、その結果をクエリ処理結果４４として出力する。このクエリ処理結果４４は、インタフェース部１２を介して、出力装置９４から出力される。または、クエリ処理結果４４は、ネットワーク９を経由して、クライアント装置１上のアプリケーション処理部１ａからクエリ処理結果４４として出力してもよい。ここで、クエリ実行部３５は、複数のスレッドにより構成され、各スレッドは、割り当てられているクエリグループ４５に属するクエリ４３が示すクエリ演算処理を実行する。スレッドとスレッドとの間は、直列に接続されており、スレッド間でのパイプライン処理による並列処理が行われる。
【００３０】
クエリ実行部３５には、クエリリポジトリ３６からクエリ４３（Ｑ１→Ｑ２→Ｑ３）がロードされ、その前には入力キュー４６が接続され、その後には出力キュー４７が接続される。
入力キュー４６は、インタフェース部１２を介して入力されたストリームデータを格納する。
クエリ４３（Ｑ１→Ｑ２→Ｑ３）は、入力キュー４６に入力されたストリームデータを、Ｑ１→Ｑ２→Ｑ３の順に処理する処理内容を示す。
出力キュー４７は、クエリ４３（Ｑ３）の処理結果を格納する。
【００３１】
クエリリポジトリ３６は、入力されたクエリ４３を格納する。なお、クエリリポジトリ３６は、サーバ装置２上の主記憶装置９２に配置してもよいし、補助記憶装置９５に配置してもよい。
【００３２】
図３は、クエリグループ４５の分割処理を示す説明図である。クエリグループ４５を複数に分割して、各クエリグループ４５を別々のスレッドに割り当て、それらを並列に実行することによって、各クエリグループ４５の並列処理が可能となり、スループットを向上させることができる。
図４は、図３で示すクエリグループ４５を示すクエリグループ管理テーブル３７内の登録情報を示す。図３（ａ）と図４（ａ）、図３（ｂ）と図４（ｂ）、および、図３（ｃ）と図４（ｃ）、はそれぞれ対応する。
以下、図３および図４を参照して、クエリグループ４５の分割処理を説明する。
【００３３】
まず、図３および図４では、クエリ４３の一例として、５つのクエリ（Ｑ１→Ｑ２→Ｑ３→Ｑ４→Ｑ５）を示す。これらのクエリは、前のクエリの実行結果が次のクエリの入力になるように、直列に接続されている。
【００３４】
クエリＱ１は、データストリームＳ１を入力し、ウィンドウ枠[ｒｏｗｓ  １０]で定義された最新１０件の入力データを処理対象とし、ｗｈｅｒｅ句の条件に合致したものを出力することを示す。
register query Q1
select S1.a,S1,b,S1.x from S1[rows 10] where S1.a > 0
【００３５】
クエリＱ２は、クエリＱ１の出力結果を入力し、ｇｒｏｕｐｂｙ句に従い、集約演算ａｖｇを行う。
register query Q2
select Q1.a,Q1.b,avg(Q1.x) from Q1 groupby Q1.a,Q1.b
【００３６】
クエリＱ３は、以下のように定義される。
register query Q3
select Q1.a,Q1.x from Q2
where Q1.x > Q1.a and Q1.x < Q1.b
【００３７】
クエリＱ４は、以下のように定義される。
register query Q4
select max(Q3.x) from Q3
【００３８】
クエリＱ５は、以下のように定義される。
register query Q5
istream(select * from Q4 where S1.x > 1000)
【００３９】
まず、図３（ａ）で示す、クエリグループの分割前の状態では、５つのクエリ４３が１つのクエリグループ４５（Ｇ１）にまとめられて、そのクエリグループ４５（Ｇ１）に対してスレッド「１」が割り当てられている。
図４（ａ）に示すクエリグループ管理テーブル３７は、クエリグループ４５と、そのクエリグループ４５を構成するクエリ４３と、そのクエリグループ４５に割り当てられているスレッドとを対応づけて管理する。
入力されるストリームデータのタプルは、まず、入力キュー４６に格納される。クエリグループ４５（Ｇ１）の先頭クエリ４３（Ｑ１）は、入力キュー４６からタプルを順に読み出して、クエリ演算処理を実行する。クエリ４３（Ｑ１）は、実行結果を次のクエリ４３（Ｑ２）に渡す。そして、クエリグループ４５（Ｇ１）の末尾クエリ４３（Ｑ５）は、クエリ４３（Ｑ４）から入力されるタプルの実行結果を、出力キュー４７へと出力する。
【００４０】
次に、図３（ｂ）で示す、図３（ａ）の状態からの１回目の分割の状態では、５つのクエリ４３（Ｑ１→Ｑ２→Ｑ３→Ｑ４→Ｑ５）を含む１つのクエリグループ４５（Ｇ１）が、クエリ４３（Ｑ１→Ｑ２）を含むクエリグループ４５（Ｇ１１）と、クエリ４３（Ｑ３→Ｑ４→Ｑ５）を含むクエリグループ４５（Ｇ１２）と、に分割されている。そして、分割された２つのクエリグループ４５（Ｇ１１，Ｇ１２）の間には、それらのクエリグループ４５間でのデータの受け渡しを行うための中間キュー４８が設けられる。さらに、分割された２つのクエリグループ４５（Ｇ１１，Ｇ１２）には、それぞれ別々のスレッドが割り当てられることにより、２つのクエリグループ４５間での並列処理が行われるため、スループットが向上する。
【００４１】
次に、図３（ｃ）で示す、図３（ａ）の状態からに対する２回目の分割の状態（つまり、図３（ｂ）からの分割の状態）では、クエリグループ４５（Ｇ１１）が、クエリグループ４５（Ｇ１１ａ）と、クエリグループ４５（Ｇ１１ｂ）とに分割されている。さらに、クエリグループ４５（Ｇ１２）が、クエリグループ４５（Ｇ１２ａ）と、クエリグループ４５（Ｇ１２ｂ）とに分割されている。そして、図３（ｂ）と同様に、クエリグループ４５間でのデータの受け渡しを行うための中間キュー４８が設けられる。これにより、合計４つのクエリグループ４５が作成され、各クエリグループ４５に１つずつのスレッドが割り当てられる（つまり、スレッド数は合計４つである）。
【００４２】
以上、図３および図４を参照して説明したクエリグループ４５の分割処理は、スケジューラ３３によって、実行される。スケジューラ３３は、分割処理を実行するための契機として、例えば、分割対象のクエリグループ４５の負荷増大を検知したときとする。スケジューラ３３は、分割処理における分割後のクエリグループ４５を構成するクエリ４３について、分割後のクエリグループ４５の負荷（処理時間）が略均等になるように、分割処理を実行する。
【００４３】
図５は、１つのクエリ４３を、複数のクエリグループ４５に分割する旨を示す説明図である。図３で説明したように、基本的には、１つのクエリグループ４５には、１つ以上のクエリ４３が属することとする。しかし、１つのクエリ４３の負荷が大きいときなどには、１つのクエリ４３を構成する複数のオペレータを抽出し、そのオペレータを単位としてクエリグループ４５を割り当てることとしてもよい。
図５では、図３のクエリ４３（Ｑ１）が、３つのオペレータによって構成されるため、そのオペレータそれぞれにクエリグループ４５を割り当てる例を示している。
オペレータ「RowWindow」というウィンドウ演算は、クエリ４３（Ｑ１）の「from S1[rows 10]」に対応する。
オペレータ「Filter」という条件指定のフィルタリング演算は、クエリ４３（Ｑ１）の「where S1.a >0」に対応する。
オペレータ「Projection」という射影演算は、クエリ４３（Ｑ１）の「select S1.a,S1.b,S1.x」に対応する。
このように、クエリ４３単位のクエリグループ４５の分割では充分なスループットが得られない場合には、オペレータ単位のクエリグループ４５の定義により、スループットをさらに向上させることができる。
【００４４】
図６は、統計情報テーブル３８を示す構成図である。図６（ａ）は、データの停滞前の状態を示す統計情報テーブル３８を示す。図６（ｂ）は、データの停滞時の状態を示す統計情報テーブル３８を示す。
統計情報テーブル３８は、クエリ４３と、入力流量と、レイテンシと、負荷評価値とを対応づけて管理する。
「入力流量」は、対応するクエリ４３の単位時間当たりのタプルの入力件数であり、単位は［タプル／秒］である。
「レイテンシ」は、対応するクエリ４３に入力されたタプルの、入力されてから出力されるまでの平均時間を示し、単位は［ミリ秒］である。この「レイテンシ」は、タプルの平均時間について、実測値による統計情報を設定してもよいし、クエリ４３のオペレータをプログラム解析した理論見積値としてもよい。なお、クエリ４３の「入力流量」が、そのクエリ４３の最大スループット（「レイテンシ」の逆数）を上回るときには、クエリ４３の処理がおいつかないため、データあふれが発生する。
【００４５】
「負荷評価値」は、対応するクエリ４３の負荷を評価する値であり、例えば、「入力流量」と「レイテンシ」との積で計算できる。一方、負荷評価値の計算式として、例えば、以下の式を用いてもよい。
・負荷評価値＝「入力流量」
・負荷評価値＝「レイテンシ」の実測値
・負荷評価値＝「レイテンシ」の理論見積値
ここで、負荷評価値に着目して、図６（ａ）と図６（ｂ）とを比較すると、図６（ｂ）のほうが負荷評価値が高い。つまり、図６（ｂ）は、データの停滞時の状態になっている。
【００４６】
図７は、統計情報取得部３４が実行する、統計情報テーブル３８の作成処理を示すフローチャートである。このフローチャートは、サーバ装置２のシステム起動時に実行される。
【００４７】
Ｓ１０１において、統計情報テーブル３８を初期化する。具体的には、クエリリポジトリ３６の各クエリ４３を示すレコードを作成し、そのレコード内の列をすべて初期値「０」に設定する。
Ｓ１０２において、パラメータ「システム起動時刻」に、現在時刻を設定する。
【００４８】
Ｓ１０３において、クエリ実行部３５のクエリ４３（Ｑｉ）に対して、タプル（Ｔｊ）の入力が発生したか否かを判定する。Ｓ１０３でＹｅｓならＳ１０４へ進み、ＮｏならＳ１０５へ進む。
Ｓ１０４において、クエリ４３（Ｑｉ）のタプル（Ｔｊ）の入力時刻に、現在時刻を設定する。
Ｓ１０５において、クエリ実行部３５のクエリ４３（Ｑｉ）に対して、タプル（Ｔｊ）の出力が発生したか否かを判定する。Ｓ１０５でＹｅｓならＳ１０６へ進み、ＮｏならＳ１０３へ戻る。
【００４９】
Ｓ１０６において、統計情報テーブル３８にタプル（Ｔｊ）の統計情報を反映する。
具体的には、クエリ４３（Ｑｉ）のデータ入力量に、タプル（Ｔｊ）の分（値＝１）を加算する。クエリ４３（Ｑｉ）の処理時間に、タプル（Ｔｊ）の処理時間（現在時刻−「クエリ４３（Ｑｉ）のタプル（Ｔｊ）の入力時刻」）を加算する。
そして、以下の式により、統計情報テーブル３８のクエリ４３（Ｑｉ）の列の値を更新する。
クエリ４３（Ｑｉ）の入力流量＝クエリ４３（Ｑｉ）のデータ入力量÷（現在時刻−システム起動時刻）
クエリ４３（Ｑｉ）のレイテンシ＝クエリ４３（Ｑｉ）の処理時間÷クエリ４３（Ｑｉ）のデータ入力量
【００５０】
図８は、流量監視部３２が実行する、データ停滞の監視処理を示すフローチャートである。
Ｓ２０１において、クエリグループ管理テーブル３７からクエリグループ４５を１つずつ選択するループを開始する。なお、現在選択されているクエリグループ４５を、クエリグループ４５（Ｇｉ）と表記する。
Ｓ２０２において、クエリグループ４５（Ｇｉ）が分割可能か否かを判定する。ここで、分割可能とは、例えば、クエリグループ４５（Ｇｉ）に２つ以上のクエリ４３が含まれている場合としてもよいし（図３などを参照）、クエリグループ４５（Ｇｉ）に１つのクエリ４３が含まれており、かつ、そのクエリ４３に２つ以上のオペレータが含まれている場合としてもよい（図５などを参照）。Ｓ２０２でＹｅｓならＳ２０３へ進み、ＮｏならＳ２０５へ進む。
Ｓ２０３において、クエリグループ４５（Ｇｉ）に対して、データ停滞が発生しているか否かを判定する。データ停滞の検知手法は、後記する。Ｓ２０３でＹｅｓならＳ２０４へ進み、ＮｏならＳ２０５へ進む。
Ｓ２０４において、クエリグループ４５（Ｇｉ）を対象とする分割処理を起動して（図９の処理を呼び出して）、本フローチャートを終了する。なお、起動した分割処理から、本フローチャートのＳ２０１が再起動される。
Ｓ２０５において、Ｓ２０１からのループ処理を終了する。
Ｓ２０６において、所定時間だけ流量監視部３２の処理を中断（スリープ）した後、Ｓ２０１へ戻る。このように、クエリグループ４５の分割処理を繰り返すことで、必要なだけクエリグループ４５の分割を行い、相応するスループットを得ることができる。
【００５１】
ここで、Ｓ２０３におけるデータ停滞を検知する手法について、２つの手法を例示する。これらの手法のうち、少なくとも１つの手法を活用することで、クエリグループ４５（Ｇｉ）のデータ停滞を検知する。
【００５２】
まず、第１の手法は、統計情報テーブル３８をもとに、データ停滞を検知する手法である。
【００５３】
クエリグループ４５（Ｇｉ）の入力流量Ｘは、クエリグループ４５（Ｇｉ）内の先頭クエリ４３の「入力流量」である。例えば、図６（ａ）では、先頭クエリ４３（Ｑ１）の「入力流量」＝４０が、入力流量Ｘになる。
【００５４】
クエリグループ４５（Ｇｉ）の平均レイテンシＹは、クエリグループ４５（Ｇｉ）内の各クエリ４３を、クエリ４３（Ｑｊ）とすると、「クエリ４３（Ｑｊ）の「レイテンシ」×（クエリ４３（Ｑｊ）の「入力流量」÷入力流量Ｘ」を、クエリ４３（Ｑｊ）ごとに計算し、その総和とする。例えば、図６（ａ）では、以下の計算により、平均レイテンシＹを求める。
１０×（４０÷４０）
＋８×（３０÷４０）
＋１６×（３０÷４０）
＋４×（２５÷４０）
＋２×（２０÷４０）＝３１．５（ミリ秒）。
【００５５】
データ停滞の判定式は、「入力流量Ｘ＞１０００÷平均レイテンシＹ」である。例えば、図６（ａ）では、
（入力流量Ｘ＝４０）＞１０００÷（平均レイテンシＹ＝３１．５）
であり、４０＞３１．７なので、データ停滞発生あり、と判定される。
【００５６】
一方、第２の手法は、入力キュー４６をもとに、データ停滞を検知する手法である。クエリグループ４５（Ｇｉ）の入力位置に存在する入力キュー４６または中間キュー４８内のタプル数を計測し、そのタプル数が、所定閾値を超えている場合に、「データ停滞がある」と判断すればよい。
【００５７】
図９は、スケジューラ３３が実行する、クエリグループ４５（Ｇｉ）を対象とする分割処理の詳細を示すフローチャートである。
【００５８】
Ｓ３０１において、割り当てられるスレッドに余裕があるか否かを判断する。なお、スレッドに余裕があるとは、例えば、利用可能なスレッド数（ＣＰＵ数）が、既に割当済みのスレッド数よりも多いときを指す。Ｓ３０１でＹｅｓならＳ３０２へ進み、Ｎｏなら処理を終了する。
Ｓ３０２において、クエリグループ４５（Ｇｉ）の分割位置を決定するため、図１０の処理を呼び出す。
【００５９】
Ｓ３０３において、クエリグループ４５（Ｇｉ）の分割処理を実行する。具体的には、以下の手順を実行する。
（１）分割前のクエリグループ４５（Ｇｉ）の入力位置に存在するキュー（入力キュー４６または中間キュー４８）からのクエリグループ４５（Ｇｉ）へのデータ入力を停止させる。
（２）分割前のクエリグループ４５（Ｇｉ）が処理中であるデータが、クエリグループ４５（Ｇｉ）の出力位置に存在するキュー（出力キュー４７または中間キュー４８）にすべて出力されるまで、クエリ演算処理の実行を待つ。
（３）Ｓ３０２で決定した分割位置に従って、１つのクエリグループ４５（Ｇｉ）を、２つのクエリグループ４５へと分割する。分割後の第１クエリグループ４５は、クエリグループ４５（Ｇｉ）が含むクエリ４３のうちの分割位置より前側にあるクエリ４３を含む。分割後の第２クエリグループ４５は、クエリグループ４５（Ｇｉ）が含むクエリ４３のうちの分割位置より後側にあるクエリ４３を含む。
（４）分割後の第１クエリグループ４５と第２クエリグループ４５との間を、中間キュー４８で接続する。
（５）第１クエリグループ４５には分割前のクエリグループ４５（Ｇｉ）と同じスレッドを割り当て、第２クエリグループ４５には新しいスレッドを割り当てる。
【００６０】
Ｓ３０４において、分割後のクエリグループ４５を稼動する。そのため、まず、流量監視部３２の処理（図８）を再起動する。次に、統計情報テーブル３８のレコードについて、分割前のクエリグループ４５のレコードを削除するとともに、分割後のクエリグループ４５のレコードを新規生成して、その列の値を０に初期化する。さらに、Ｓ３０３の（１）で停止していた、データ入力を再開させる。
【００６１】
図１０は、スケジューラ３３が実行する、クエリグループ４５（Ｇｉ）の分割位置の決定処理を示すフローチャートである。
【００６２】
Ｓ３１１において、分割基準点Ｗを計算する。具体的には、統計情報テーブル３８からクエリグループ４５（Ｇｉ）を構成する各クエリ４３の「負荷評価値」を取得し、その総和をクエリグループ４５（Ｇｉ）の「負荷評価値」とする。そして、「負荷評価値」を２で割った値を分割基準点Ｗとする。
【００６３】
Ｓ３１２において、クエリグループ４５（Ｇｉ）を構成する各クエリ４３を、先頭から１つずつ順に選択するループを開始する。このループでｊ番目に選択中のクエリ４３を、クエリ４３（Ｑｊ）とする。
Ｓ３１３において、「負荷評価値」の和Ａ，Ｂをそれぞれ計算する。
「負荷評価値」の和Ａ＝クエリグループ４５（Ｇｉ）を構成する先頭のクエリ４３から、クエリ４３（Ｑｊ）までの各クエリ４３における「負荷評価値」の総和
「負荷評価値」の和Ｂ＝クエリグループ４５（Ｇｉ）を構成する先頭のクエリ４３から、クエリ４３（Ｑ（ｊ−１））までの各クエリ４３における「負荷評価値」の総和
【００６４】
Ｓ３１４において、「負荷評価値」の和Ａが分割基準点Ｗより大きいか否かを判定する。Ｓ３１４でＹｅｓならＳ３１５へ進み、ＮｏならＳ３１８へ進む。
Ｓ３１５において、「負荷評価値」の和Ａが、「負荷評価値」の和Ｂよりも分割基準点Ｗに近いか否かを判定する。具体的には、「負荷評価値」の和それぞれと、分割基準点Ｗとの距離を求める。Ｓ３１５でＹｅｓならＳ３１６へ進み、ＮｏならＳ３１７へ進む。
Ｓ３１６において、クエリ４３（Ｑｊ）とクエリ４３（Ｑ（ｊ＋１））との間に、分割点を設定する。
Ｓ３１７において、クエリ４３（Ｑ（ｊ−１））とクエリ４３（Ｑｊ）との間に、分割点を設定する。
Ｓ３１８において、Ｓ３１２からのループを終了する。
【００６５】
以上説明した分割位置の決定処理について、図６（ａ）の統計情報テーブル３８では、
第１クエリグループ４５（Ｑ１，Ｑ２）＝「負荷評価値」の和が「６４０」
第２クエリグループ４５（Ｑ３，Ｑ４，Ｑ５）＝「負荷評価値」の和が「６２０」
という分割位置が、略均等になる。
【００６６】
以上説明した本実施形態によれば、スケジューラ３３は、所定のクエリグループ４５に対するデータの停滞の通知を受け、その所定のクエリグループ４５を処理時間が略均等になる２つのクエリグループ４５へと分割し、それぞれを別々のスレッドに再割り当てする。これにより、入力されたストリームデータは、分割後の各クエリグループ４５によって並列に実行されるため、スループットが向上する。
なお、分割対象のクエリグループ４５は、以前分割されたクエリグループ４５であってもよい。これにより、負荷の高いクエリグループ４５が、１回以上の分割処理によって、適切な粒度のクエリグループ４５へと分割される。
さらに、スケジューラ３３は、クエリグループ４５の分割処理の契機を、そのクエリグループ４５へのデータ停滞の発生時期とすることにより、到来するデータ入力速度に対して充分処理を実行できるクエリグループ４５への分割を抑制し、処理速度、使用資源への影響を最小限に保つことができる。
【符号の説明】
【００６７】
１      クライアント装置
１ａ    アプリケーション処理部
２      サーバ装置（ストリームデータ処理装置）
９      ネットワーク
１０    ストリーム処理部
１１    ストリーム制御部
１２    インタフェース部
２０    コマンド処理部
２１    コマンド解析部
２２    コマンド実行部
２３    コマンド管理部
３０    クエリ処理部
３１    クエリ解析部
３２    流量監視部
３３    スケジューラ
３４    統計情報取得部
３５    クエリ実行部
３６    クエリリポジトリ
３７    クエリグループ管理テーブル
３８    統計情報テーブル
４１    ストリームソース
４２    コマンド
４３    クエリ
４４    クエリ処理結果
４５    クエリグループ
４６    入力キュー
４７    出力キュー
４８    中間キュー
９１    プロセッサ
９２    主記憶装置
９３    入力装置
９４    出力装置
９５    補助記憶装置
【図１】
2010204880.tif 000003
【図２】
2010204880.tif 000004
【図３】
2010204880.tif 000005
【図４】
2010204880.tif 000006
【図５】
2010204880.tif 000007
【図６】
2010204880.tif 000008
【図７】
2010204880.tif 000009
【図８】
2010204880.tif 000010
【図９】
2010204880.tif 000011
【図１０】
2010204880.tif 000012