ストリームデータ処理方法、及びシステム
【課題】
時間ウィンドウを含むクエリのメモリ使用量を一定に保ち、かつ全ての入力データを考慮した正確な計算処理を実現するストリームデータを提供する。
【解決手段】
ストリームデータ処理サーバ１１１は、クエリ時間解像度変更部１３０で、時間ウィンドウをより小さい幅のサブウィンドウに区切り、クエリ処理エンジン１４０はストリームデータ受付時にサブウィンドウ単位の集計処理を実行して集約タプルを生成し、時間ウィンドウを含むクエリの計算結果を、この集約タプルに対する集計処理によって計算する。
時間ウィンドウを含むクエリのメモリ使用量を一定に保ち、かつ全ての入力データを考慮した正確な計算処理を実現するストリームデータを提供する。
【解決手段】
ストリームデータ処理サーバ１１１は、クエリ時間解像度変更部１３０で、時間ウィンドウをより小さい幅のサブウィンドウに区切り、クエリ処理エンジン１４０はストリームデータ受付時にサブウィンドウ単位の集計処理を実行して集約タプルを生成し、時間ウィンドウを含むクエリの計算結果を、この集約タプルに対する集計処理によって計算する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、時々刻々と到来するストリームデータをリアルタイムに処理するストリームデータ処理方法、特に時間ウィンドウ利用のクエリのメモリ使用量の上限を定めるストリームデータ処理方法、及びそのシステムに関する。
【背景技術】
【０００２】
従来、企業情報システムのデータ管理の中心にはデータベース管理システム（以下、ＤＢＭＳとする）が位置づけられていた。ＤＢＭＳは、処理対象のデータをストレージに格納し、格納したデータに対してトランザクション処理に代表される高信頼な処理を実現している。これに対して、時々刻々と到着する大量のデータをリアルタイム処理するデータ処理システムに対する要求が高まっている。例えば、株取引を支援する金融アプリケーションを考えた場合、株価の変動にいかに迅速に反応できるかがシステムの最重要の課題の一つである。従来のＤＢＭＳのように株式のデータを一旦記憶装置に格納してから、該格納データに関して検索を行うようなシステムでは、データの格納とそれに続く検索処理が株価変動のスピードに追いつくことができず、ビジネスチャンスを逃してしまうことになりかねない。
【０００３】
このようなリアルタイムデータ処理に好適なデータ処理システムとして、ストリームデータ処理システムが提案されている。例えば非特許文献１にストリームデータ処理システム“ＳＴＲＥＡＭ”が開示されている。
【０００４】
ストリームデータ処理システムでは、従来のＤＢＭＳとは異なり、まずクエリ（問合せ）をシステムに登録し、データの到来と共に該クエリが継続的に実行される。ここでのストリームデータとは、映像ストリームのような論理的に継続する一つの大きなデータではなく、金融アプリケーションにおける株価配信データ、小売業での販売時点情報管理（以下、ＰＯＳとする）データ、交通情報システムにおけるプローブカーデータ、計算機システム管理におけるエラーログ、センサやＲＦＩＤ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）などのユビキタスデバイスから発生するセンシングデータなど、比較的小さな論理的には独立した大量の時系列データである。
【０００５】
ストリームデータは継続してシステムに到着し続けるため、その終わりを待ってから処理を開始するのでは実時間での処理は不可能である。また、システムに到着したデータは、データ処理の負荷に影響されることなく、その到着順を守って処理する必要がある。前述のＳＴＲＥＡＭでは、システムに到来し続けるストリームデータを、最新１０分間などの時間の幅、もしくは最新１０００件などの個数の幅を指定してストリームデータの一部を切り取りながらリアルタイムの処理を実現するため、スライディングウィンドウ（以下単にウィンドウと呼ぶ）と呼ばれる概念を導入している。ウィンドウ指定を含むクエリの記述言語の好適な例としては、非特許文献４に開示されているＣＱＬ（Ｃｏｎｔｉｎｕｏｕｓ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）をあげることができる。ＣＱＬは、ＤＢＭＳで広く用いられているＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）のＦＲＯＭ句に、ストリーム名に続いて括弧を用いることにより、ウィンドウを指定する拡張が施されている。ＳＱＬに関しては、非特許文献２が詳しい。
【０００６】
図１４のクエリ１１０１は非特許文献１の２．１節に示されているＣＱＬによるクエリの例である。該クエリでは、あるＷｅｂプロキシサーバにおいて、ドメインｓｔａｎｆｏｒｄ．ｅｄｕからの現時点から過去１日分のアクセスの総数を計算する。Ｒｅｑｕｅｓｔｓは前記Ｗｅｂプロキシサーバに到来し続けるＷｅｂアクセスデータであり、従来のＤＢＭＳで取り扱うテーブル（表）のような静止化されたデータではなく、切れ目のないストリームデータとなる。そのため、アクセスの総数を計算は、ウィンドウ指定“［Ｒａｎｇｅ １ Ｄａｙ Ｐｒｅｃｅｄｉｎｇ］”による、ストリームデータのどの部分を対象とするかの指定なしでは、不可能となる。ウィンドウによって切り取られたストリームデータはメモリ上に保持され、クエリ処理に使用される。
【０００７】
代表的なウィンドウの指定方法には、ウィンドウの幅を時間で指定するＲａｎｇｅウィンドウ（以下、時間ウィンドウ）と、ウィンドウの幅をデータ数で指定するＲｏｗウィンドウ（以下、行ウィンドウ）がある。例えば、時間ウィンドウを用いて、［Ｒａｎｇｅ １０ ｍｉｎｕｔｅｓ］とすると、最新の１０分間分がクエリ処理の対象となり、行ウィンドウを用いて［Ｒｏｗｓ １０］とすると、最新の１０件がクエリ処理の対象となる。
【０００８】
そこで、非特許文献３では、メモリに載らないストリームデータを磁気ディスクに格納する方法が開示されている。
【０００９】
一方、特許文献１では処理対象のデータ量が増大した際に、サンプリングにより一部のデータを捨てることにより、メモリ使用量を削減する方法を開示している。
【００１０】
【非特許文献１】Ｒ． Ｍｏｔｗａｎｉ，Ｊ． Ｗｉｄｏｍ，Ａ． Ａｒａｓｕ，Ｂ． Ｂａｂｃｏｃｋ，Ｓ． Ｂａｂｕ，Ｍ． Ｄａｔａｒ，Ｇ． Ｍａｎｋｕ，Ｃ． Ｏｌｓｔｏｎ，Ｊ． Ｒｏｓｅｎｓｔｅｉｎ ａｎｄ Ｒ． Ｖａｒｍａ著：“Ｑｕｅｒｙ Ｐｒｏｃｅｓｓｉｎｇ、 Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ、 ａｎｄ Ａｐｐｒｏｘｉｍａｔｉｏｎ ｉｎ ａ Ｄａｔａ Ｓｔｒｅａｍ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ”，Ｉｎ Ｐｒｏｃ． ｏｆ ｔｈｅ ２００３ Ｃｏｎｆ． ｏｎ Ｉｎｎｏｖａｔｉｖｅ Ｄａｔａ Ｓｙｓｔｅｍｓ Ｒｅｓｅａｒｃｈ （ＣＩＤＲ），Ｊａｎｕａｒｙ ２００３、
【非特許文献２】Ｃ． Ｊ． Ｄａｔｅ，Ｈｕｇｈ Ｄａｒｗｅｎ著：“Ａ Ｇｕｉｄｅ ｔｏ ＳＱＬ Ｓｔａｎｄａｒｄ （４ｔｈ Ｅｄｉｔｉｏｎ）”，Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｒｏｆｅｓｓｉｏｎａｌ； ４ ｅｄｉｔｉｏｎ （Ｎｏｖｅｍｂｅｒ ８、 １９９６），ＩＳＢＮ： ０２０１９６４２６０
【非特許文献３】Ｍｏｔｗａｎｉ他：“Ｃａｃｈｉｎｇ Ｑｕｅｕｅｓ ｉｎ Ｍｅｍｏｒｙ Ｂｕｆｆｅｒｓ”、Ｉｎ Ｐｒｏｃ． ｏｆ ＳＯＤＡ ２００４
【非特許文献４】Ａ． Ａｒａｓｕ，Ｓ． Ｂａｂｕ ａｎｄ Ｊ． Ｗｉｄｏｍ著：“Ｔｈｅ ＣＱＬ ｃｏｎｔｉｎｕｏｕｓ ｑｕｅｒｙ ｌａｎｇｕａｇｅ： ｓｅｍａｎｔｉｃ ｆｏｕｎｄａｔｉｏｎｓ ａｎｄ ｑｕｅｒｙ ｅｘｅｃｕｔｉｏｎ”， Ｔｈｅ ＶＬＤＢ Ｊｏｕｒｎａｌ，Ｖｏｌｕｍｅ １５，Ｉｓｓｕｅ ２， ｐｐ． １２１−１４２ （Ｊｕｎｅ ２００６）
【特許文献１】米国公開特許ＵＳ２００７／０２２６２３９号
【特許文献２】特開２００６−３３８４３２号公開公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、非特許文献１や非特許文献２のストリームデータ処理システムは、前述した金融アプリケーションのみならず、カープローブ、Ｗｅｂおよび計算機システムのアクセス監視、通信監視、製造監視など、高レートで発生するデータをリアルタイムに解析する様々なアプリケーションへの適用が期待されている。このようなアプリケーションでは、大量のデータが短い時間内にバースト的に到来することがある。例えば、金融アプリケーションの代表的な例である株式の取引システムにおいては、取引開始時、取引終了間際に大量の売り買いの注文が発生する。前述の時間ウィンドウを用いる場合、時間ウィンドウで指定した時間の幅Ｔに含まれるストリームデータが処理の対象となる。幅Ｔ内に含まれるデータの数はシステムに到来するストリームデータに依存するために、例えば１時間以内に到来する売買要求の数を予測することが困難であるように、予めその大きさを見積もることが難しい。ストリームデータ処理では、高速処理の要求からウィンドウ上のデータをメモリ上に展開するため、時間ウィンドウを利用した場合のメモリ使用量の見積りが困難となる。また、ストリームデータがバースト的に到来した場合、メモリの確保が難しくなりシステムの安定性が損なわれるリスクがある。
【００１２】
さらに、高い性能が要求される金融・通信応用などでは、非特許文献３のような磁気ディスクの利用ではレイテンシ(latency)などの性能要件を満たせないことがある。また、特許文献１の方法では全ての入力データを反映した正確な計算が必要で、サンプリングが許されない応用には適用が困難である。
【００１３】
リアルタイムデータ処理を実現するストリームデータ処理システムで時間ウィンドウを含むクエリを処理する場合には、システムに到来するストリームデータの増加時にもメモリ使用量を一定に保つ必要がある。加えて、金融応用などいくつかのアプリケーションでは、全ての入力データを考慮した近似を含まない正確な計算を実行する必要がある。
【００１４】
以上の要求から、時間ウィンドウを利用したクエリを処理する際に、ストリームデータがバースト的に到来する場合でも、メモリ使用量の上限を規定でき、かつ全てのデータを考慮した正確な計算を実行できる処理方法が必要となる。しかし、このようなストリームデータ処理方法はこれまで実現されていなかった。
【００１５】
本発明の目的は、時間ウィンドウを含むクエリのメモリ使用量を一定に保ち、かつ全ての入力データを考慮した正確な計算処理を実現するストリーム処理方法、及びそのシステムを提供することにある。
【課題を解決するための手段】
【００１６】
上記目的を達成するため、本発明においては、ストリームデータに対しクエリ処理を行うシステムにおけるストリームデータ処理方法であって、クエリが、ある時間間隔内にシステムに到来したストリームデータを処理対象とする時間ウィンドウを含む場合に、時間ウィンドウをより小さい幅のサブウィンドウに区切り、このサブウィンドウ内に含まれるストリームデータを集約した少なくとも一つの集約タプルを生成し、この集約タプルを用いてクエリの処理結果を計算するストリームデータ処理方法、及びそのシステムを提供する。
【００１７】
また、上記目的を達成するため、ストリームデータに対しクエリ処理を行うシステムにおけるストリームデータ処理方法であって、クエリが、ある時間間隔内にシステムに到来したストリームデータを処理対象とする時間ウィンドウを含む場合に、この時間ウィンドウをより小さい幅のサブウィンドウに区切り、受け付けたストリームタプルが新しいサブウィンドウに区分けされる場合に、このサブウィンドウ内に集約タプルを生成し、集約タプルの生存期間の終了時刻を、受け付けたストリームタプルのタイムスタンプにクエリで指定された前記時間ウィンドウの幅を加えた時刻に設定し、受け付けたストリームタプルが既存のサブウィンドウに区分けされる場合に、当該ストリームタプルを用いて集約タプルを更新し、更新した集約タプルの生存期間終了時刻を、受け付けたストリームタプルのタイムスタンプにクエリで指定された時間ウィンドウの幅を加えた時刻に設定し、設定した生存期間終了時刻に、集約タプルを消去するためのフラグをつけたストリームタプルを生成し、これら集約タプルを用いてクエリの処理結果を計算するストリームデータ処理方法、及びそのシステムを提供する。
【発明の効果】
【００１８】
本発明を用いることにより、時間ウィンドウを含むクエリを処理する際に、入力となるストリームデータが増加した場合でも、メモリ使用量の上限を一定に保つことができ、システム安定性確保、および運用管理の容易化に寄与する。
【発明を実施するための最良の形態】
【００１９】
以下、図面に基づき本発明の種々の実施形態を説明する。
【００２０】
本願で開示される発明のうち、代表的な発明の概要は以下の通りである。すなわち、代表的実施態様では時間ウィンドウをより小さい幅のサブウィンドウに区切り、ストリームデータ受付時に該サブウィンドウ単位の集計処理を実行して集約タプルを生成し、この時間ウィンドウを含むクエリの計算結果を、集約タプルに対する集計処理によって計算する。
【００２１】
例えば、幅Ｔの時間ウィンドウに含まれる売上データの総計を計算することを考える。幅Ｔの時間内に、１０件の売上があった場合には時間ウィンドウは１０件分のデータのみを保持すればよいが、１００００件の売上があった場合には１００００件のデータを保持しなければならない。そこで、時間ウィンドウの幅Ｔに対して、サブウィンドウの幅をＴＳ（ＴＳ≦Ｔ）に設定し、ＴＳ時間単位に売上データを集計した集約タプルを生成してオリジナルのデータは破棄していく。これにより、オリジナルのデータの数によらず、ＴＳ時間単位の集約タプルのみをメモリ上に保持すればよく、メモリ使用量を一定化することができる。幅Ｔ全体分の売上の総計を計算する際には、各ＴＳの集約タプルの総和を計算することで、近似を用いない正確な計算結果を得ることができる。
【００２２】
ストリームデータ処理のウィンドウを用いた処理では、個々のストリームタプルは生存期間を持つ。集約タプルの生存終了時刻は、サブウィンドウ内の集計値が最後に更新された時刻、すなわち集約タプルの最終更新時刻から時間ウィンドウの幅Ｔを経過した時刻に設定される。集約タプルの生存終了時刻には、生存終了を示す集約タプルのマイナスタプルを生成し、サブウィンドウの総和を計算時に該マイナスタプルを反映して全体の集計値を再計算する。
【実施例１】
【００２３】
図１に、第一の実施例に係わる、ストリームデータ処理システム（以下、単にシステムと呼ぶ場合がある）の一構成を示す。アプリケーション１（１０２）を実行するクライアント計算機１０１、アプリケーション２（１０４）を実行するクライアント計算機１０３は、ネットワーク１１０を介してストリームデータ処理システムが稼動するストリームデータ処理サーバ１１１に接続されている。ネットワーク１１０は、イーサネット（登録商標）、光ファイバなどで接続されるローカルエリアネットワーク（ＬＡＮ）、もしくはＬＡＮよりも低速なインターネットを含んだワイドエリアネットワーク（ＷＡＮ）でも差し支えない。また、クライアント計算機１０１、１０３はパーソナルコンピュータ（ＰＣ）、ブレード型の計算機システムなどの任意のコンピュータシステムでよい。
【００２４】
ストリームデータ処理サーバ１１１は、インタフェース部を構成する通信インタフェース１４５及びＩ／Ｏインタフェース１１４、処理部を構成する中央処理部（ＣＰＵ）１１３、記憶部であるメモリ１１２が、バス１１６で結合された計算機であり、ブレード型計算機システム、ＰＣサーバなどの任意のコンピュータシステム、データ処理装置でよい。ストリームデータ処理サーバ１１１では、通信インタフェース１４５を介してクライアント計算機１０１、１０３、及び後述するデータソースにアクセスする。
【００２５】
ストリームデータ処理サーバ１１１で、ストリームデータ処理結果、処理の中間結果、システム動作に必要な設定データを不揮発性のストレージに格納する場合には、ストリームデータ処理サーバ１１１に接続した記憶部であるストレージ装置１１５を用いることができる。ストレージ装置１１５は、ストリームデータ処理サーバ１１１のＩ／Ｏインタフェース１１４を介して直接接続される、もしくは通信インタフェース１１５を介してネットワーク接続される。
【００２６】
ストリームデータ処理システムは、ストリームデータ処理サーバ１１１の上で動作する。図１にストリームデータ処理システムの主要構成要素を示す。メモリ１１２内に図示された時間解像度変更方法指示テーブル１３１、クエリ保持テーブル１３２以外のブロックは、ＣＰＵ１１３上で動作する機能を模式的に示している。アプリケーション１、２は、まずストリームデータ処理システムで処理の対象とするストリーム１０５を登録し、該ストリームをどのように処理するかを記述したクエリ１０６を登録する。登録されたクエリはクエリ時間解像度変更部１３０で解析される。クエリ時間解像度変更部１３０は時間解像度書換え方法指示テーブル１３１を参照して、必要に応じてクエリの時間解像度を変更し、クエリをクエリ保持テーブル１３２に登録する。
【００２７】
図１１を用いてクエリ保持テーブルの好適な構成例を説明する。クエリ保持テーブルは、クエリ名（１４０１）、クエリ文字列（１４０２）、クエリ実行形式のアドレス（１４０３）、時間解像度変更方法指示テーブルのエントリ（１４０４）を含む。図１１のクエリＱ１のエントリは、図２のクエリ指定に対して図３の時間解像度変更指定が与えられ、そのエントリが図４の＃１に格納されている場合の例である。本実施例では、時間解像度指定を含むクエリの実行に必要なクエリ保持テーブルが保持すべき最低限の項目のみを示したが、他にも、クエリの登録者、クエリの登録日時、クエリの実行開始時刻、クエリの実行終了時刻、クエリの実行対象のストリームなどの項目を含んでも差し支えない。時間解像度変更処理を用いない場合のストリームデータ処理システムのクエリ登録の手順、ストリームデータ処理システム内部のデータの格納方法、格納形式、クエリを受け付けた後の解析方法、最適化方法、クエリの実行形式の作成方法、システムへの登録方法、ストリームデータ処理システムへのストリームの登録方法、システム内のデータ保持方法については、特開２００６−３３８４３２号公報「ストリームデータ処理システムのクエリ処理方法」に、その好適な実施の方法が開示されている。本発明では、該方法で作成されるクエリ保持テーブルに対して、時間解像度変更方法指示テーブルのエントリが含まれている。本エントリは、図６のフローチャートのステップ６０７でクエリ時間解像度変更部によって挿入され、クエリ処理エンジン１４０に登録される。クエリ保持テーブル１３２は、ストリームデータ処理サーバ１１１のメモリ１１２に保持するのでも、ストリームデータ処理サーバ１１１に接続されているストレージ装置１１５に格納するのでも差し支えない。
【００２８】
ストリームデータ処理システムには、一つ以上のストリームデータソースであるストリームデータソース１（１１７）〜ストリームデータソースＮ（１１８）からネットワーク１１９を介して時々刻々と大量のデータが到来する。このデータをストリームデータと呼ぶ。ストリームデータの好適な例としては、金融アプリケーションにおける株価配信情報、小売業でのＰＯＳデータ、交通情報システムにおけるプローブカー情報、計算機システム管理におけるエラーログなどが挙げられる。ストリームデータ処理システムでは、通信インタフェース１４５を介してデータフローマネージャ１３４が受け付けたストリームデータを、タイムスタンプを付与したストリームタプルに変換して、後述するクエリ処理エンジン１４０上にロードされたクエリ実行形式にフィードする。さらに、本発明ではクエリ実行形式をクエリ処理エンジンにロードする際に、クエリ解像度変更部は時間解像度変更方法指示テーブルを参照し、ロードするクエリに対応するサブウィンドウ幅の設定をサブウィンドウ管理部に、そして集約タプル集計関数を時間解像度変更クエリ結果生成部１４４に設定する。
【００２９】
前述したように、継続して到来する比較的小さな論理的には独立した大量の時系列データであるストリームデータを取り扱うために、ストリームデータ処理システムではウィンドウを用いる。メモリ上にロードされたクエリ実行形式のウィンドウ処理には、ウィンドウマネージャ１４１が適用される。図１のウィンドウマネージャ１４１は、到来するストリームデータに対して、クエリで指定されたウィンドウ演算を適用して、ストリームタプルのシステム内での生存期間を設定する。ストリームデータがウィンドウに挿入された時が生存期間の開始時刻、そしてウィンドウから該ストリームデータが削除される時が生存期間の終了時刻に相当する。本実施例の時間解像度変更クエリ処理では、ウィンドウマネージャ１４１が受け付けたストリームタプルは、サブウィンドウ管理部１４２でサブウィンドウ単位に集計され、集計結果である集約タプルはサブウィンドウ情報管理バッファ１４３に格納される。時刻解像度変更クエリ結果生成部１４４では、サブウィンドウ単位の集計値にさらに集計計算を施すことにより、与えられたクエリに対する処理結果を生成し、データ処理結果出力部１３３を介してアプリケーションに結果１０７を返信する。
【００３０】
以下、上述したそれぞれの処理を具体的に説明する。最初に、クエリの登録処理について図６を用いて説明する。アプリケーションからクエリが与えられると、処理が開始され（ステップ６０１）、クエリ時間解像度変更部１３０は該クエリに対する時間解像度変更の方法が指定されているか否かをチェックする（６０２）。時間解像度変更の方法が指定されている場合（ステップ６０２でＹｅｓが選択された場合）、クエリ時間解像度変更部は指定された項目を時間解像度変更方法指示テーブル１３１に登録すると共にクエリの実行形式を生成してクエリ保持テーブル１３２に登録し（６０７）、クエリ登録処理を終了する（６０８）。本実施例では、処理対象のクエリは図２のクエリＱ１（２０１）であり、図３の３０１が時間解像度の変更の指定である。クエリの処理内容、および時間解像度変更内容の詳細については、後述する。
【００３１】
アプリケーションから与えられたクエリに対する時間解像度変更の方法が指定されていない場合（ステップ６０２でＮｏが選択された場合）には、クエリ時間解像度変更部は時間解像度変更が可能か否かをチェックする（６０５）。不可能と判定された場合（ステップ６０５でＮｏが選択された場合）には、クエリ登録処理を終了する。本フローチャートでは変更が不可能である場合、クエリを登録しないことになっているが、アプリケーションに警告を出すなどして、時間解像度を変更せずに、すなわちメモリの使用量を一定化せずにクエリを実行させることも可能である。時間解像度変更が可能な場合（ステップ６０５でＹｅｓが選択された場合）、クエリ時間解像度変更部は時間解像度変更に必要な項目であるサブウィンドウの幅、解像度変更対象の入力ストリーム、集計対象、カラムを決定して（６０６）、これらの情報を時間解像度変更方法指示テーブル１３１に登録すると共にクエリの実行形式を生成してそのメモリ上のアドレスをクエリ保持テーブル１３２に登録し（６０７）する。最後に、クエリ時間解像度変更部は、前記クエリ実行形式をクエリ処理エンジン１４０に登録すると共に、該クエリに指定されたサブウィンドウ幅をサブウィンドウ管理部１４３に設定し、集約タプル集計関数を時間解像度変更クエリ結果生成部１４４に設定して（６０９）、クエリ登録処理を終了する。ステップ６０５の判定ステップは後述するが、該判定ステップ中で時間ウィンドウが設定されているウィンドウに対する最初の処理を集計処理に設定可能と判定された場合には、前記クエリの実行形式の生成の際に時間ウィンドウが設定されているストリームに対する最初の処理を集計処理に設定する。
【００３２】
サブウィンドウの幅については、その幅を小さく取るとクエリ処理で保持すべき集約タプル数が増加するため、メモリ使用量が増加する。サブウィンドウ幅の決定方法としては、例えばサブウィンドウの数と、各サブウィンドウ中に保持される集計値の数の積を計算し、該計算値とそれぞれの集計値で利用するメモリ量の積を計算し、該計算値が利用可能なメモリ量に収まるようにサブウィンドウ幅を決定する方法が考えられる。
【００３３】
時間解像度変更が可能か否かの判定方法について、図７を用いて説明する。まずクエリの出力結果が集計関数、および集計関数の引数のカラムで構成されているか否かをチェックする（７０２）。集計関数の引数以外のカラムを含む場合（ステップ７０２でＮｏが選択された場合）、時間解像度変更は不可能と判定し（７０４）、判定処理を終了する（７１０）。クエリの出力結果が集計関数、および集計関数の引数のカラムで構成されている場合（ステップ７０２でＹｅｓが選択された場合）、入力ストリームの数をチェックする（７０３）。入力ストリームが１つのみの場合、時間解像度変更可能と判定し（７０６）、判定処理を終了する（７１０）。
【００３４】
入力ストリームが複数存在する場合、時間ウィンドウが設定されているウィンドウに対する最初の処理を集計処理に設定可能か否かをチェックする（７０５）。例えば、該ストリームに対する最初の処理がジョインであり、それに続いてグルーピングおよび集計処理が実行される実行プランを、グルーピングおよび集計処理を先に実行し、その後にジョイン処理を実行する実行プランに変換可能か否かをチェックする。該変換が可能か否かの判定方法、および変換方法は、Ｓ． Ｃｈａｕｄｈｕｒｉ ａｎｄ Ｋ． Ｓｈｉｍ著：“Ｉｎｃｌｕｄｉｎｇ Ｇｒｏｕｐ−Ｂｙ ｉｎ Ｑｕｅｒｙ Ｏｐｔｉｍｉｚａｔｉｏｎ”， Ｉｎ Ｐｒｏｃ． ｏｆ ２０ｔｈ ＶＬＤＢ， ｐｐ． ３５４−３６６， １９９４の３節に開示されている。時間ウィンドウが設定されているウィンドウに対する最初の処理を集計処理に設定不可能な場合、（ステップ７０５でＮｏが選択される場合）、時間解像度変更不可能と判定して（７０４）、判定処理を終了する（７１０）。設定可能の場合（ステップ７０５でＹｅｓが選択された場合）、時間解像度変更が可能と判定して（７０６）、判定処理を終了する（７１０）。以上で、クエリの登録方法の説明を終了し、以降は登録されたクエリの時間解像度変更処理方法について説明する。
【００３５】
図２に示したＱ１は株式売買（ｓｔｏｃｋ）ストリームの最新１分間分を処理対象として銘柄名（ｂｒａｎｄ）毎の売上高を計算し、計算結果を３０秒毎に出力するクエリである。このＱ１の場合、集計グループは銘柄名（ｂｒａｎｄ）毎となる。時間解像度を変更せずにＱ１を処理する場合には、１分間に大量の売買情報がストリームデータとして到来すると、時間ウィンドウにそれらの個別のデータを保持する必要があり、システムのメモリ使用量が増大する。そこで、Ｑ１の株式売買ストリームを対象として、１分間の時間ウィンドウを３０秒毎のサブウィンドウに区切ってサブウィンドウの集計値を計算し、該集計値の更なる集計（再度集計処理）によってクエリＱ１の計算結果を求める方法を以下で説明する。
【００３６】
ユーザ、もしくはアプリケーション（以下、単にアプリケーションとする）が該計算方法をシステムに対して指定する好適な時間解像度変更指示方法を図３の３０１に示す。３０１ではクエリＱ１のストリームｓｔｏｃｋを対象として、時間解像度を３００００ｍｓすなわち３０秒に設定し、売上高ＳＵＭ（ｐｒｉｃｅ）を計算することを表している。
【００３７】
図１３を用いてシステムに時間解像度変更指示が入力された場合の登録処理方法を説明する。時間解像度変更指示が入力され、処理が開始すると（１３０１）、システムは該指示内容をチェックする（１３０２）。解像度変更対象のクエリ、ストリーム、カラム、集計関数がシステム中に存在しない場合（ステップ１３０３でＮｏが選択された場合）、登録エラーを出力し（１３０９）登録処理を終了する（１３１０）。解像度変更対象のクエリ、ストリーム、カラム、集計関数が存在する場合（ステップ１３０３でＹｅｓが選択された場合）、サブウィンドウの幅指定と時間解像度変更対象のクエリの時間ウィンドウの幅の関係をチェックする（１３１１）。サブウィンドウの幅指定が時間ウィンドウの幅よりも小さい場合（ステップ１３１１でＹｅｓが選択された場合）には、次のステップに進む。サブウィンドウの幅指定が時間ウィンドウ幅よりも大きい場合（ステップ１３１１でＮｏが選択された場合）には、サブウィンドウ幅指定を時間ウィンドウ幅にセットして（１３１２）、次のステップに進む。
【００３８】
次に、サブウィンドウの幅指定がシステムの規定範囲内に収まっているか否かをチェックする（１３０４）。システムにおけるサブウィンドウの幅の規定範囲の最小値、最大値をそれぞれＴＭＩＮ、ＴＭＡＸとする。ＴＭＩＮ、ＴＭＡＸは、システムが稼動しているハードウェア、オペレーティングシステム、システムが使用可能なリソース量を考慮して、システム設計者もしくはシステム管理者により決定される。例えば、オペレーティングシステムでの最小時間解像度がＴＯＳＭＩＮの場合、サブウィンドウの幅はＴＯＳＭＩＮよりは小さくできないためＴＭＩＮ≧ＴＯＳＭＩＮである。時間解像度変更指示の幅指定ＴＤＩＳがシステムの規定範囲内におさまっている場合、すなわちＴＭＩＮ≦ＴＤＩＳ≦ＴＭＡＸの場合（ステップ１３０４でＹｅｓが選択された場合）には、指示内容を時間解像度変更方法指示テーブルに登録し（１３０８）、時間解像度変更指示登録処理を終了する（１３１０）。サブウィンドウの幅指定がシステムの規定範囲内に収まっていない場合、すなわちＴＤＩＳ＜ＴＭＩＮ、もしくはＴＤＩＳ＞ＴＭＡＸの場合（ステップ１３０４でＮｏが選択された場合）、システムの時間解像度変更指示モードをチェックする。指示内容チェックモードがｓｔｒｉｃｔの場合（ステップ１３０５でＹｅｓが選択された場合）、登録エラーを出力し（１３０９）登録処理を終了する（１３１０）。指示内容チェックモードがｓｔｒｉｃｔでない場合（ステップ１３０５でＮｏが選択された場合）、クエリ時間解像度変更部（１３０）から警告を出力し（１３０６）、サブウィンドウ幅の指定が規定範囲の最小値より小さい場合（ＴＤＩＳ＜ＴＭＩＮの場合）は幅を規定値の最小値に（ＴＤＩＳ＝ＴＭＩＮに）、サブウィンドウの幅の指定が規定範囲の最大値より大きい場合（ＴＤＩＳ＞ＴＭＡＸの場合）は幅を規定値の最大値に（ＴＤＩＳ＝ＴＭＡＸに）セットし（１３０７）、指示内容を時間解像度変更方法指示テーブルに登録し（１３０８）、時間解像度変更指示登録処理を終了する（１３１０）。
【００３９】
本実施例では、ステップ１３０５で指示内容チェックモードを参照している。指示内容チェックモードは、システム全体を対象として設定する方法でも、またクエリ単位で設定する方法でも差し支えない。またその格納場所は、クエリ保持テーブル１３２でも、システム接続されたストレージ装置１１５でも差し支えない。さらに、指示内容チェックモードの指定自体をシステムの規定値として、すなわちシステム構築時にチェックモードをｓｔｒｉｃｔとするか否かを定め、実行時にはステップ１３０５のチェックを行わない実現方法も可能である。
【００４０】
以上の登録結果は、例えば図４に示す形式で時間解像度変更方法指定テーブル１３１としてシステム中に管理される。時間解像度指示テーブル１３１は、各登録毎に、番号４０１、クエリ名４０２、入力ストリーム名４０３、サブウィンドウ幅４０４、対象集計関数４０５、対象カラム名４０６が管理される。
【００４１】
クエリと時間解像度変更方法が指定された後、システムストリームデータが到来した際の処理シーケンスを、図５を用いて説明する。ストリームデータソース１１７はストリームデータを生成する。生成されたストリームデータ（５０１）は、ネットワーク１１６、通信インタフェース１４５を介して、システムのデータフローマネージャ１３４によって受け付けられる（５０２）。ストリームデータを受け付けたデータフローマネージャ１３４は、ストリームデータからタイムスタンプを保持するストリームタプルを生成し（５０３）、クエリ処理エンジン１４０に送信する。データフローマネージャ１３４は、ストリームデータがシステムに到着した時刻をタイムスタンプとして用いるサーバタイムスタンプモード、およびストリームデータに付与されている時刻情報をタイムスタンプとして用いるアプリケーションタイムスタンプモードのいずれかのモードでの動作が可能である。
【００４２】
クエリ処理エンジン１４０のウィンドウマネージャ１４１がストリームタプルを受け取ると、ウィンドウマネージャ１４１内のサブウィンドウ管理部１４２は、サブウィンドウ単位の集計値を計算し、サブウィンドウ情報管理バッファ１４３に該集計値を追加、更新し（５０４）する。さらに、サブウィンドウ管理部１４２は、前記追加、更新に伴う新しい集計値に関する差分情報（プラスの符号付ストリームタプル）を生成し（５０５）、時間解像度変更クエリ結果生成部１４４に送信する。また、サブウィンドウ管理部１４２は、集約タプルの生存期間が終了する際には、該集約タプルをサブウィンドウ情報管理バッファ１４３から削除し、該削除に伴う差分情報（マイナスの符号付ストリームタプル）を生成し、時間解像度変更クエリ結果生成部１４４に送信する。時間解像度変更クエリ結果生成部１４４は、前記差分情報からクエリの計算結果を生成し（５０６）、データ処理結果出力部１３３に送信する。そしてデータ処理結果出力部１３３ではクエリで指定されたデータ出力方法に従ってクエリ処理結果をアプリケーションに送信する（５０７）。クエリでのデータ出力指定方法については後述する。
【００４３】
以上説明した本実施例の一連の処理シーケンス中で、時間解像度変更の特徴的な処理はウィンドウマネージャ１４１内の処理であるので、図９を用いて前述のＱ１に対して株式売買（ｓｔｏｃｋ）ストリームデータが到来した場合の処理を具体的に説明する。図９は時間経過に伴って、ウィンドウマネージャ１４１内でストリームタプルがどのように処理されていくかを示すシーケンス図である。時間は図の左側の矢印９３１で示すように図の上から下側に進行する。図の縦線９３２、９３３はそれぞれ、サブウィンドウ管理部１４２、および時間解像度変更クエリ結果生成部１４４での処理を示しており、９０１、９０２、９０３、９３４、９４３はそれぞれ、ウィンドウマネージャ１４１に送信されるストリームタプル、サブウィンドウ情報管理バッファ１４３で管理される集約タプル、ウィンドウマネージャ１４１で生成される差分情報、時間解像度変更クエリ結果生成部１４４で保持される集計結果、最終的にアプリケーションに返されるクエリ処理結果の凡例を表している。
【００４４】
９０１に示されているように、ｓｔｏｃｋストリームは銘柄（ｂｒａｎｄ）と売買価格（ｐｒｉｃｅ）を構成要素として保持し、ウィンドウマネージャに送付されるストリームタプルはｂｒａｎｄ、ｐｒｉｃｅとタイムスタンプ（ｔｉｍｅ）を含んでいる。クエリＱ１（２０１）は１分間の時間ウィンドウを持つ。Ｑ１に図３で示される時間解像度変更指定（３０１）を適用した場合のクエリ処理方法を説明する。クエリ処理の開始時刻は１０：０１：００と仮定する。時刻１０：０１：００にストリームタプル｛ａ，１００；１０：０１：００｝が到来する（９０４）。該ストリームタプルを受け付けたウィンドウマネージャは、サブウィンドウ管理部に集約タプル９０５を作成する。本実施例では、集約タプルにクエリの最終結果計算に必要なカラム（今回の場合、ｂｒａｎｄカラムとＳＵＭ（ｐｒｉｃｅ）カラム）に加えて、集約タプルの生存期間終了時刻（ｅｘｐｒｉｒｅ ｔｉｍｅ）、時間解像度のサブウィンドウの区切りを識別するための情報（シーケンス番号：ｓｅｑ．＃）が追加されている。集約タプルの生存終了時刻は、該集約タプルが生成された時刻（生存開始時刻）に、クエリの時間ウィンドウで指定された時間幅を加えることによって計算される。本実施例のクエリＱ１では、時間ウィンドウの幅は１分であるので、集約タプルの生成時刻１０：０１：００の１分後の１０：０２：００が生存期間終了時刻として設定される。サブウィンドウの区切りを識別するための情報の管理方法は、本実施例のようにデータと同じレコードに含めても、もしくはデータから紐付けが可能な別データとして管理するのでも差し支えない。作成された集約タプル９０５はサブウィンドウ情報管理バッファ１４３に登録される。次に、ウィンドウマネージャは本集約タプルの作成に伴う集計値の変化を差分情報として出力する。差分情報の表現方法は各種のバリエーションが考えられるが、本実施例では符号付きのストリームタプルで表現する。集約タプル９０５の場合は、新規に集約タプルが生成されたので、差分情報としてはプラスの符号付きストリームタプル９０６が生成され、時間解像度変更クエリ結果生成部１４４に送信される。時間解像度変更クエリ結果生成部では、サブウィンドウ単位の集約タプルの差分情報を受け取り、クエリ全体での計算結果を生成する。差分情報としてはプラスの符号付きストリームタプル９０６を受け取った時には、それ以前の集計値は存在しないので、クエリ全体の集計値としてストリームタプル９３５を生成する。
【００４５】
クエリＱ１ではＲＳＴＲＥＡＭ ［３０ ＳＥＣＯＮＤ］句指定により、クエリの計算結果はアプリケーションに３０秒間隔で送信する指示がなされている。非特許文献５の６．３節には、ストリームデータ処理システムからの好適なストリームデータ出力方法が開示されている。一つ目はストリームシステム内の前回出力時からの増加分を出力するＩＳＴＲＥＡＭ句、二つ目はストリームシステム内の前回出力時からの減少分を出力するＤＳＴＲＥＡＭ句、そして三つ目がその時点でのストリームシステム内の出力対象全体を出力するＲＳＴＲＥＡＭ句である。本実施例では、ＲＳＴＲＥＡＭ句が指定された場合について説明するが、ＩＳＴＲＥＡＭ句、ＤＳＴＲＥＡＭ句が指定された場合にも本発明の適用は可能である。なお、ＲＳＴＲＥＡＭ句は非特許文献５では出力間隔の指定方法が示されていないが、本実施例ではＲＳＴＲＥＡＭ句を拡張し、出力間隔の指定を可能としている。
【００４６】
Ｑ１の処理では、最初の出力として１０：０１：００にクエリ処理結果｛ａ，１００｝が出力される（９０７）。続いて、時刻１０：０１：０１にストリームタプル９０８が到来する。先に述べたとおり、本実施例では時間解像度は３０秒に設定されているため、本ストリームタプルは先に処理されたストリームタプル９０４と同じサブウィンドウに区分される。そのため、ストリームタプルを受け付けたサブウィンドウ管理部１４２では、ストリームタプル９０４を追加した際に生成したシーケンス番号１０２８１のエントリを更新して集約タプル９０９を作成する。更新処理では、集計値に加えて、その生存終了時刻の更新処理も実施される。この場合、入力となるストリームタプルのタイムスタンプが１０：０１：０１であるので、該時刻にクエリの時間ウィンドウの幅１分間を加えた１０：０２：０１に生存終了時刻が更新される。そしてこの更新に伴う差分情報として、更新前の値１５０を保持するプラスの符号を持つストリームタプル、および更新後の値１００を保持するマイナスの符号を持つストリームタプル９１０を生成し、時間解像度変更クエリ結果生成部１４４に送信する。時間解像度変更クエリ結果生成部１４４では、該差分情報を用いてクエリ処理結果９３６を生成する。前述したように、Ｑ１ではアプリケーションからのクエリ処理結果出力指定がＲＳＴＲＥＡＭ句により３０秒毎のため、このタイミングではアプリケーションには結果は出力されない。時刻１０：０１：１１にストリームタプル９１１が到来した際にも、全く同様の更新処理が実行され、時間解像度変更クエリ結果生成部にクエリ処理結果のストリームタプル９３７が生成される。そして、時刻１０：０１：３０のアプリケーションから指定された結果出力タイミングで、この時点のクエリ処理結果である｛ａ，２２０｝がアプリケーションに送信される。
【００４７】
次に時刻１０：０１：５９にストリームタプル９１５が到来する。本実施例の時間解像度は３０秒であり、最初のサブウィンドウの区切りは１０：０１：００であるため、ストリームタプル９１５は、これまでに到来した三つのストリームタプル９０４、９０８、９１１とは異なるサブウィンドウに区分けされる。そのため、サブウィンドウ管理部１４２では、ストリームタプル９１５に対応する新たなシーケンス番号を持つ新しい集約タプルのエントリを作成し、サブウィンドウ情報管理バッファ１４３に格納する（９１６）。同時に、新しい集約タプル生成に伴う差分情報として、プラスの符号を持つストリームタプル９１７を生成し、時間解像度変更クエリ結果生成部１４４に送信する。時間解像度変更クエリ結果生成部１４４では、受け取った差分情報を利用して集計結果を更新する（９３８）。
【００４８】
時刻１０：０２：００では、時刻１０：０１：３０の時と同様に、この時点のクエリ処理結果である｛ａ，３４０｝がアプリケーションに送信される（９１８）。次に時刻１０：０２：０５に新しいストリームタプル９１９が到来すると、該タプルはその前に到来したストリームタプル９１５とはサブウィンドウの区分けが異なるため、サブウィンドウ情報管理バッファ１４３に新たな集約タプルのエントリ９２０が生成され、該集約タプルの生成に伴う差分情報９２１が生成され、時間解像度変更クエリ結果生成部１４４でクエリ処理結果が更新される（９３９）。
【００４９】
時刻１０：０２：１１には、シーケンス番号が１０２８１の集約タプルの生存期間が終了する。そこで、サブウィンドウ管理部１４２では、サブウィンドウ情報管理バッファ１４３からシーケンス番号１０２８１の集約タプルのエントリを削除する（９２２）とともに、該削除処理に伴う差分情報を時間解像度変更クエリ結果生成部１４４に送信する（９２３）。時間解像度変更クエリ結果生成部１４４では、該差分情報を利用して、集計値を更新する（９４０）。以下、ストリームタプル９２４、９２７が到来した際にも同様の処理が行われ、１０：０２：３０にクエリ処理結果｛ａ，４８０｝がアプリケーションに送信される（９３０）。
【００５０】
本実施例では簡単のために、株式銘柄名（ｂｒａｎｄ）が一種類の場合の処理シーケンスを示したが、複数の株式銘柄が存在する場合には、株式銘柄毎にサブウィンドウで集約タプルを管理することで同様の処理が可能である。すなわち、集約の単位を、クエリＱ１で指定された集計グループである銘柄名（ｂｒａｎｄ）毎とすることができる。
【００５１】
以上の処理をまとめたフローチャートを図８に示す。最初に、サブウィンドウ情報管理バッファ１４３内にその生存期間終了時刻が現時刻以前の集約タプルのエントリが存在するか否かをチェックする（８０２）。存在しない場合（ステップ８０２でＮｏが選択された場合）には、次のステップに進む。これは図９に示した例では、時刻１０：０２：１１以外の場合に相当する。存在する場合（ステップ８０２でＹｅｓが選択された場合）には、該エントリをサブウィンドウ情報管理バッファ１４３から削除し（８０４）、該エントリに対応する差分情報（マイナス符号付きのストリームタプル）をウィンドウマネージャから出力する（８０３）。本処理は、図９で示した例では時刻１０：０２：１１のシーケンス番号１０２８１の集約タプルエントリの削除処理に相当する。
【００５２】
次に、ストリームタプルを受け取った時の処理を説明する。今説明の便宜上、受け取ったストリームタプルをｔとする。ウィンドウマネージャ１４１がタイムスタンプ付きのストリームタプルｔを受け取る（８０５）と、サブウィンドウ管理部１４２はｔのタイムスタンプがサブウィンドウ情報管理バッファ１４３内の最新のシーケンス番号の時刻区切りを越えたか否かをチェックする（８０６）。超えない場合（ステップ８０６でＮｏが選択された場合）には、ストリームタプルｔを用いて最新のシーケンス番号をもつ集約タプルを更新し（８０８）、更新した集約タプルの生存期間終了時刻を“ｔのタイムスタンプ＋時間ウィンドウの幅”に設定し（８０９）、本更新処理に伴う差分情報をウィンドウマネージャ１４１から出力する（８１０）。本処理は図９の例では、ストリームタプル９０８、９１１、９２４、９２７の到来時の処理に相当する。
【００５３】
ｔのタイムスタンプがサブウィンドウ情報管理バッファ１４３内の最新のシーケンス番号の時刻区切りを越える場合（ステップ８０６でＹｅｓが選択される場合）には、サブウィンドウ管理部１４２は新しいシーケンス番号を生成し（８１１）、サブウィンドウ情報管理バッファ１４３内に、該シーケンス番号を持つ新たな集約タプルのエントリを作成して該エントリにストリームタプルｔを格納し（８１２）、作成した集約タプルの生存期間終了時刻を“ｔのタイムスタンプ＋時間ウィンドウの幅”に設定し（８１３）、該集約タプル作成に伴う差分情報をウィンドウマネージャから出力する（８１４）。本処理は図９の例では、ストリームタプル９１５、９１９の到来時の処理に相当する。
【００５４】
時間解像度変更クエリ結果生成部１４４では、ウィンドウマネージャ１４１から出力されたサブウィンドウ単位の集約タプルに関する差分情報を再度集計し、クエリ処理結果を生成する（８１５）。本再集計処理では、クエリで指定された集計、サブウィンドウ単位の集計（集約タプルの生成方法）、時間解像度変更クエリ結果生成部１４４の集計処理の組合せの好適な実施例を図１２の表１２０１に示す。本処理は図９の例では、縦線９３３上のストリームタプル計算に相当する。本実施例の場合、クエリで指定された集計はＳＵＭ（総和）であるので、図１２の表１２０１に示すとおり、サブウィンドウ管理部１４２では到来するストリームタプルのＳＵＭをサブウィンドウ単位に計算し、時間解像度変更クエリ結果生成部でもウィンドウマネージャ１４１から出力された差分情報のＳＵＭを計算している。図８に戻って、時間解像度変更クエリ結果生成部で生成したクエリ処理結果は、クエリで指定されたタイミングでアプリケーションに出力される（８１６）。本処理は図９の例では９０７、９１４、９１８、９３０の出力処理に相当する。
【００５５】
以上説明した実施例では、図８および図９を用いて対象となるクエリとしてＱ１のＳＵＭ（総和）を計算する場合のみを説明したが、図１０に示した、ＭＡＸ（最大値）を含んだクエリＱ２（１００１）、ＭＩＮ（最小値）を含んだクエリＱ３（１００２）、ＣＯＵＮＴ（件数）を含んだクエリＱ４（１００３）、ＡＶＥＲＡＧＥ（平均値）を含んだクエリＱ５（１００４）についても本発明は適用が可能である。
【００５６】
図１２の表１２０１を用いて具体的な計算方法を説明する。図１２では、ｉ番目のサブウィンドウの集約タプルをＴＡｉと表している（＃５の場合のみ二種類の集約タプルを用いるため、ＴＡｉ＿１、ＴＡｉ＿２と表す）。この時、Ｑ２については図１２の＃２に示すように、サブウィンドウ管理部１４２においてサブウィンドウ単位のＭＡＸ（最大値）を計算した集約タプルを生成した後、時間解像度変更クエリ結果生成部１４４において集約タプル間のＭＡＸ（最大値）を計算すればよい。
【００５７】
同様に、Ｑ３については図１２の＃３に示すように、サブウィンドウ単位のＭＩＮ（最小値）を計算した集約タプルを生成した後、集約タプル間のＭＩＮ（最小値)を計算すればよい。Ｑ４については図１２の＃４に示すように、サブウィンドウ単位のＣＯＵＮＴ（件数）を計算した集約タプルを生成した後、該集約タプルのＳＵＭ（総和）を計算すればよい。ＳＵＭ、ＭＩＮ、ＭＡＸの場合は、集約タプルを計算する演算と集約タプルから最終的なクエリの処理結果を生成する際に同種の演算を用いたが、Ｑ４のＣＯＵＮＴ（件数）の場合にはサブウィンドウ単位の集約タプルのＣＯＵＮＴを計算してもサブウィンドウの数が計算されるだけであるので、注意が必要である。
最後に、Ｑ５については図１２の＃５に示すように、集約タプルの全体の総和を集約タプル全体の件数で割ることによって計算すればよい。さらに、これらの基本集計演算を組み合わせたより複雑な集計値、統計値の計算についても、基本集計演算の計算結果を生成した後その計算結果を組み合わせることにより、本願のストリームデータ処理方法の適用が可能である。
【００５８】
また、上述の実施例では図３で時間解像度指定の方法として、時間解像度変更の対象となるクエリ名、入力ストリーム名、サブウィンドウ幅、集計関数、カラム名を全て指定するインタフェースを示したが、システムへの初期設定等により、アプリケーションからの個別指定なしに、図１２に示した変換により時間解像度変更が可能な全ての集計関数に対して時間解像度変更処理を実行することも可能である。この場合には、アプリケーションからの対象集計関数の指定は省略することができる。
【００５９】
さらに、上述した実施例ではクエリがＣＱＬの形式で与えられることを想定したが、手続き型言語、ＧＵＩなどの他の手段で与えられる場合にも本願発明のストリームデータ処理方法は適用が可能である。
【図面の簡単な説明】
【００６０】
【図１】第一の実施例に係わるストリームデータ処理システムの構成を示す図である。
【図２】第一の実施例に係わる、時間解像度変更対象のクエリの一例を示す図である。
【図３】第一の実施例に係わる、クエリ時間解像度変更指定の一例を示す図である。
【図４】第一の実施例に係わる、クエリ時間解像度変更指定内容の格納例を示す図である。
【図５】第一の実施例に係わる、クエリ時間解像度変更処理のシーケンスを示す図である。
【図６】第一の実施例に係わる、クエリ登録処理のフローチャートを示す図である。
【図７】第一の実施例に係わる、時間解像度変更書換え可能性チェックおよび書換え処理のフローチャートを示す図である。
【図８】第一の実施例に係わる、クエリ時間解像度変更処理のフローチャートを示す図である。
【図９】第一の実施例に係わる、クエリ時間解像度変更処理の具体例を示す図である。
【図１０】各実施例に係わる、時間解像度変更が可能なクエリの例を示す図である。
【図１１】第一の実施例に係わる、クエリの格納例を示す図である。
【図１２】各実施例に係わる、集計処理実現方法を示す表を示す図である。
【図１３】第一の実施例に係わる、クエリ時間解像度変更指示登録処理のフローチャートを示す図である。
【図１４】クエリ処理言語ＣＱＬによるクエリ記述例を示す図である。
【符号の説明】
【００６１】
１０１、１０３…クライアント計算機
１０２、１０４…アプリケーション
１１１…ストリームデータ処理サーバ
１１０、１１９…ネットワーク
１１２…メモリ
１３０…クエリ時間解像度変更部
１３１…時間解像度変更方法指示テーブル
１３２…クエリ保持テーブル
１３３…データ処理結果出力部
１３４…データフローマネージャ
１４０…クエリ処理エンジン
１４１…ウィンドウマネージャ
１４２…サブウィンドウ管理部
１４３…サブウィンドウ情報管理バッファ
１４４…時間解像度変更クエリ結果生成部
１１６…バス
１１３…ＣＰＵ
１１４…Ｉ／Ｏインタフェース
１４５…通信インタフェース
１１５…ストレージ
１１７、１１８…ストリームデータソース
９０４、９０８、９１１、９１５、９１９、９２４、９２７…ストリームタプル
９０５、９０９、９１２、９１６、９２０、９２２、９２５、９２８…集約タプル
９０６、９１０、９１３、９１７、９２１、９２３、９２６、９２９…符号付ストリームタプル。
【技術分野】
【０００１】
本発明は、時々刻々と到来するストリームデータをリアルタイムに処理するストリームデータ処理方法、特に時間ウィンドウ利用のクエリのメモリ使用量の上限を定めるストリームデータ処理方法、及びそのシステムに関する。
【背景技術】
【０００２】
従来、企業情報システムのデータ管理の中心にはデータベース管理システム（以下、ＤＢＭＳとする）が位置づけられていた。ＤＢＭＳは、処理対象のデータをストレージに格納し、格納したデータに対してトランザクション処理に代表される高信頼な処理を実現している。これに対して、時々刻々と到着する大量のデータをリアルタイム処理するデータ処理システムに対する要求が高まっている。例えば、株取引を支援する金融アプリケーションを考えた場合、株価の変動にいかに迅速に反応できるかがシステムの最重要の課題の一つである。従来のＤＢＭＳのように株式のデータを一旦記憶装置に格納してから、該格納データに関して検索を行うようなシステムでは、データの格納とそれに続く検索処理が株価変動のスピードに追いつくことができず、ビジネスチャンスを逃してしまうことになりかねない。
【０００３】
このようなリアルタイムデータ処理に好適なデータ処理システムとして、ストリームデータ処理システムが提案されている。例えば非特許文献１にストリームデータ処理システム“ＳＴＲＥＡＭ”が開示されている。
【０００４】
ストリームデータ処理システムでは、従来のＤＢＭＳとは異なり、まずクエリ（問合せ）をシステムに登録し、データの到来と共に該クエリが継続的に実行される。ここでのストリームデータとは、映像ストリームのような論理的に継続する一つの大きなデータではなく、金融アプリケーションにおける株価配信データ、小売業での販売時点情報管理（以下、ＰＯＳとする）データ、交通情報システムにおけるプローブカーデータ、計算機システム管理におけるエラーログ、センサやＲＦＩＤ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）などのユビキタスデバイスから発生するセンシングデータなど、比較的小さな論理的には独立した大量の時系列データである。
【０００５】
ストリームデータは継続してシステムに到着し続けるため、その終わりを待ってから処理を開始するのでは実時間での処理は不可能である。また、システムに到着したデータは、データ処理の負荷に影響されることなく、その到着順を守って処理する必要がある。前述のＳＴＲＥＡＭでは、システムに到来し続けるストリームデータを、最新１０分間などの時間の幅、もしくは最新１０００件などの個数の幅を指定してストリームデータの一部を切り取りながらリアルタイムの処理を実現するため、スライディングウィンドウ（以下単にウィンドウと呼ぶ）と呼ばれる概念を導入している。ウィンドウ指定を含むクエリの記述言語の好適な例としては、非特許文献４に開示されているＣＱＬ（Ｃｏｎｔｉｎｕｏｕｓ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）をあげることができる。ＣＱＬは、ＤＢＭＳで広く用いられているＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）のＦＲＯＭ句に、ストリーム名に続いて括弧を用いることにより、ウィンドウを指定する拡張が施されている。ＳＱＬに関しては、非特許文献２が詳しい。
【０００６】
図１４のクエリ１１０１は非特許文献１の２．１節に示されているＣＱＬによるクエリの例である。該クエリでは、あるＷｅｂプロキシサーバにおいて、ドメインｓｔａｎｆｏｒｄ．ｅｄｕからの現時点から過去１日分のアクセスの総数を計算する。Ｒｅｑｕｅｓｔｓは前記Ｗｅｂプロキシサーバに到来し続けるＷｅｂアクセスデータであり、従来のＤＢＭＳで取り扱うテーブル（表）のような静止化されたデータではなく、切れ目のないストリームデータとなる。そのため、アクセスの総数を計算は、ウィンドウ指定“［Ｒａｎｇｅ １ Ｄａｙ Ｐｒｅｃｅｄｉｎｇ］”による、ストリームデータのどの部分を対象とするかの指定なしでは、不可能となる。ウィンドウによって切り取られたストリームデータはメモリ上に保持され、クエリ処理に使用される。
【０００７】
代表的なウィンドウの指定方法には、ウィンドウの幅を時間で指定するＲａｎｇｅウィンドウ（以下、時間ウィンドウ）と、ウィンドウの幅をデータ数で指定するＲｏｗウィンドウ（以下、行ウィンドウ）がある。例えば、時間ウィンドウを用いて、［Ｒａｎｇｅ １０ ｍｉｎｕｔｅｓ］とすると、最新の１０分間分がクエリ処理の対象となり、行ウィンドウを用いて［Ｒｏｗｓ １０］とすると、最新の１０件がクエリ処理の対象となる。
【０００８】
そこで、非特許文献３では、メモリに載らないストリームデータを磁気ディスクに格納する方法が開示されている。
【０００９】
一方、特許文献１では処理対象のデータ量が増大した際に、サンプリングにより一部のデータを捨てることにより、メモリ使用量を削減する方法を開示している。
【００１０】
【非特許文献１】Ｒ． Ｍｏｔｗａｎｉ，Ｊ． Ｗｉｄｏｍ，Ａ． Ａｒａｓｕ，Ｂ． Ｂａｂｃｏｃｋ，Ｓ． Ｂａｂｕ，Ｍ． Ｄａｔａｒ，Ｇ． Ｍａｎｋｕ，Ｃ． Ｏｌｓｔｏｎ，Ｊ． Ｒｏｓｅｎｓｔｅｉｎ ａｎｄ Ｒ． Ｖａｒｍａ著：“Ｑｕｅｒｙ Ｐｒｏｃｅｓｓｉｎｇ、 Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ、 ａｎｄ Ａｐｐｒｏｘｉｍａｔｉｏｎ ｉｎ ａ Ｄａｔａ Ｓｔｒｅａｍ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ”，Ｉｎ Ｐｒｏｃ． ｏｆ ｔｈｅ ２００３ Ｃｏｎｆ． ｏｎ Ｉｎｎｏｖａｔｉｖｅ Ｄａｔａ Ｓｙｓｔｅｍｓ Ｒｅｓｅａｒｃｈ （ＣＩＤＲ），Ｊａｎｕａｒｙ ２００３、
【非特許文献２】Ｃ． Ｊ． Ｄａｔｅ，Ｈｕｇｈ Ｄａｒｗｅｎ著：“Ａ Ｇｕｉｄｅ ｔｏ ＳＱＬ Ｓｔａｎｄａｒｄ （４ｔｈ Ｅｄｉｔｉｏｎ）”，Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｒｏｆｅｓｓｉｏｎａｌ； ４ ｅｄｉｔｉｏｎ （Ｎｏｖｅｍｂｅｒ ８、 １９９６），ＩＳＢＮ： ０２０１９６４２６０
【非特許文献３】Ｍｏｔｗａｎｉ他：“Ｃａｃｈｉｎｇ Ｑｕｅｕｅｓ ｉｎ Ｍｅｍｏｒｙ Ｂｕｆｆｅｒｓ”、Ｉｎ Ｐｒｏｃ． ｏｆ ＳＯＤＡ ２００４
【非特許文献４】Ａ． Ａｒａｓｕ，Ｓ． Ｂａｂｕ ａｎｄ Ｊ． Ｗｉｄｏｍ著：“Ｔｈｅ ＣＱＬ ｃｏｎｔｉｎｕｏｕｓ ｑｕｅｒｙ ｌａｎｇｕａｇｅ： ｓｅｍａｎｔｉｃ ｆｏｕｎｄａｔｉｏｎｓ ａｎｄ ｑｕｅｒｙ ｅｘｅｃｕｔｉｏｎ”， Ｔｈｅ ＶＬＤＢ Ｊｏｕｒｎａｌ，Ｖｏｌｕｍｅ １５，Ｉｓｓｕｅ ２， ｐｐ． １２１−１４２ （Ｊｕｎｅ ２００６）
【特許文献１】米国公開特許ＵＳ２００７／０２２６２３９号
【特許文献２】特開２００６−３３８４３２号公開公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、非特許文献１や非特許文献２のストリームデータ処理システムは、前述した金融アプリケーションのみならず、カープローブ、Ｗｅｂおよび計算機システムのアクセス監視、通信監視、製造監視など、高レートで発生するデータをリアルタイムに解析する様々なアプリケーションへの適用が期待されている。このようなアプリケーションでは、大量のデータが短い時間内にバースト的に到来することがある。例えば、金融アプリケーションの代表的な例である株式の取引システムにおいては、取引開始時、取引終了間際に大量の売り買いの注文が発生する。前述の時間ウィンドウを用いる場合、時間ウィンドウで指定した時間の幅Ｔに含まれるストリームデータが処理の対象となる。幅Ｔ内に含まれるデータの数はシステムに到来するストリームデータに依存するために、例えば１時間以内に到来する売買要求の数を予測することが困難であるように、予めその大きさを見積もることが難しい。ストリームデータ処理では、高速処理の要求からウィンドウ上のデータをメモリ上に展開するため、時間ウィンドウを利用した場合のメモリ使用量の見積りが困難となる。また、ストリームデータがバースト的に到来した場合、メモリの確保が難しくなりシステムの安定性が損なわれるリスクがある。
【００１２】
さらに、高い性能が要求される金融・通信応用などでは、非特許文献３のような磁気ディスクの利用ではレイテンシ(latency)などの性能要件を満たせないことがある。また、特許文献１の方法では全ての入力データを反映した正確な計算が必要で、サンプリングが許されない応用には適用が困難である。
【００１３】
リアルタイムデータ処理を実現するストリームデータ処理システムで時間ウィンドウを含むクエリを処理する場合には、システムに到来するストリームデータの増加時にもメモリ使用量を一定に保つ必要がある。加えて、金融応用などいくつかのアプリケーションでは、全ての入力データを考慮した近似を含まない正確な計算を実行する必要がある。
【００１４】
以上の要求から、時間ウィンドウを利用したクエリを処理する際に、ストリームデータがバースト的に到来する場合でも、メモリ使用量の上限を規定でき、かつ全てのデータを考慮した正確な計算を実行できる処理方法が必要となる。しかし、このようなストリームデータ処理方法はこれまで実現されていなかった。
【００１５】
本発明の目的は、時間ウィンドウを含むクエリのメモリ使用量を一定に保ち、かつ全ての入力データを考慮した正確な計算処理を実現するストリーム処理方法、及びそのシステムを提供することにある。
【課題を解決するための手段】
【００１６】
上記目的を達成するため、本発明においては、ストリームデータに対しクエリ処理を行うシステムにおけるストリームデータ処理方法であって、クエリが、ある時間間隔内にシステムに到来したストリームデータを処理対象とする時間ウィンドウを含む場合に、時間ウィンドウをより小さい幅のサブウィンドウに区切り、このサブウィンドウ内に含まれるストリームデータを集約した少なくとも一つの集約タプルを生成し、この集約タプルを用いてクエリの処理結果を計算するストリームデータ処理方法、及びそのシステムを提供する。
【００１７】
また、上記目的を達成するため、ストリームデータに対しクエリ処理を行うシステムにおけるストリームデータ処理方法であって、クエリが、ある時間間隔内にシステムに到来したストリームデータを処理対象とする時間ウィンドウを含む場合に、この時間ウィンドウをより小さい幅のサブウィンドウに区切り、受け付けたストリームタプルが新しいサブウィンドウに区分けされる場合に、このサブウィンドウ内に集約タプルを生成し、集約タプルの生存期間の終了時刻を、受け付けたストリームタプルのタイムスタンプにクエリで指定された前記時間ウィンドウの幅を加えた時刻に設定し、受け付けたストリームタプルが既存のサブウィンドウに区分けされる場合に、当該ストリームタプルを用いて集約タプルを更新し、更新した集約タプルの生存期間終了時刻を、受け付けたストリームタプルのタイムスタンプにクエリで指定された時間ウィンドウの幅を加えた時刻に設定し、設定した生存期間終了時刻に、集約タプルを消去するためのフラグをつけたストリームタプルを生成し、これら集約タプルを用いてクエリの処理結果を計算するストリームデータ処理方法、及びそのシステムを提供する。
【発明の効果】
【００１８】
本発明を用いることにより、時間ウィンドウを含むクエリを処理する際に、入力となるストリームデータが増加した場合でも、メモリ使用量の上限を一定に保つことができ、システム安定性確保、および運用管理の容易化に寄与する。
【発明を実施するための最良の形態】
【００１９】
以下、図面に基づき本発明の種々の実施形態を説明する。
【００２０】
本願で開示される発明のうち、代表的な発明の概要は以下の通りである。すなわち、代表的実施態様では時間ウィンドウをより小さい幅のサブウィンドウに区切り、ストリームデータ受付時に該サブウィンドウ単位の集計処理を実行して集約タプルを生成し、この時間ウィンドウを含むクエリの計算結果を、集約タプルに対する集計処理によって計算する。
【００２１】
例えば、幅Ｔの時間ウィンドウに含まれる売上データの総計を計算することを考える。幅Ｔの時間内に、１０件の売上があった場合には時間ウィンドウは１０件分のデータのみを保持すればよいが、１００００件の売上があった場合には１００００件のデータを保持しなければならない。そこで、時間ウィンドウの幅Ｔに対して、サブウィンドウの幅をＴＳ（ＴＳ≦Ｔ）に設定し、ＴＳ時間単位に売上データを集計した集約タプルを生成してオリジナルのデータは破棄していく。これにより、オリジナルのデータの数によらず、ＴＳ時間単位の集約タプルのみをメモリ上に保持すればよく、メモリ使用量を一定化することができる。幅Ｔ全体分の売上の総計を計算する際には、各ＴＳの集約タプルの総和を計算することで、近似を用いない正確な計算結果を得ることができる。
【００２２】
ストリームデータ処理のウィンドウを用いた処理では、個々のストリームタプルは生存期間を持つ。集約タプルの生存終了時刻は、サブウィンドウ内の集計値が最後に更新された時刻、すなわち集約タプルの最終更新時刻から時間ウィンドウの幅Ｔを経過した時刻に設定される。集約タプルの生存終了時刻には、生存終了を示す集約タプルのマイナスタプルを生成し、サブウィンドウの総和を計算時に該マイナスタプルを反映して全体の集計値を再計算する。
【実施例１】
【００２３】
図１に、第一の実施例に係わる、ストリームデータ処理システム（以下、単にシステムと呼ぶ場合がある）の一構成を示す。アプリケーション１（１０２）を実行するクライアント計算機１０１、アプリケーション２（１０４）を実行するクライアント計算機１０３は、ネットワーク１１０を介してストリームデータ処理システムが稼動するストリームデータ処理サーバ１１１に接続されている。ネットワーク１１０は、イーサネット（登録商標）、光ファイバなどで接続されるローカルエリアネットワーク（ＬＡＮ）、もしくはＬＡＮよりも低速なインターネットを含んだワイドエリアネットワーク（ＷＡＮ）でも差し支えない。また、クライアント計算機１０１、１０３はパーソナルコンピュータ（ＰＣ）、ブレード型の計算機システムなどの任意のコンピュータシステムでよい。
【００２４】
ストリームデータ処理サーバ１１１は、インタフェース部を構成する通信インタフェース１４５及びＩ／Ｏインタフェース１１４、処理部を構成する中央処理部（ＣＰＵ）１１３、記憶部であるメモリ１１２が、バス１１６で結合された計算機であり、ブレード型計算機システム、ＰＣサーバなどの任意のコンピュータシステム、データ処理装置でよい。ストリームデータ処理サーバ１１１では、通信インタフェース１４５を介してクライアント計算機１０１、１０３、及び後述するデータソースにアクセスする。
【００２５】
ストリームデータ処理サーバ１１１で、ストリームデータ処理結果、処理の中間結果、システム動作に必要な設定データを不揮発性のストレージに格納する場合には、ストリームデータ処理サーバ１１１に接続した記憶部であるストレージ装置１１５を用いることができる。ストレージ装置１１５は、ストリームデータ処理サーバ１１１のＩ／Ｏインタフェース１１４を介して直接接続される、もしくは通信インタフェース１１５を介してネットワーク接続される。
【００２６】
ストリームデータ処理システムは、ストリームデータ処理サーバ１１１の上で動作する。図１にストリームデータ処理システムの主要構成要素を示す。メモリ１１２内に図示された時間解像度変更方法指示テーブル１３１、クエリ保持テーブル１３２以外のブロックは、ＣＰＵ１１３上で動作する機能を模式的に示している。アプリケーション１、２は、まずストリームデータ処理システムで処理の対象とするストリーム１０５を登録し、該ストリームをどのように処理するかを記述したクエリ１０６を登録する。登録されたクエリはクエリ時間解像度変更部１３０で解析される。クエリ時間解像度変更部１３０は時間解像度書換え方法指示テーブル１３１を参照して、必要に応じてクエリの時間解像度を変更し、クエリをクエリ保持テーブル１３２に登録する。
【００２７】
図１１を用いてクエリ保持テーブルの好適な構成例を説明する。クエリ保持テーブルは、クエリ名（１４０１）、クエリ文字列（１４０２）、クエリ実行形式のアドレス（１４０３）、時間解像度変更方法指示テーブルのエントリ（１４０４）を含む。図１１のクエリＱ１のエントリは、図２のクエリ指定に対して図３の時間解像度変更指定が与えられ、そのエントリが図４の＃１に格納されている場合の例である。本実施例では、時間解像度指定を含むクエリの実行に必要なクエリ保持テーブルが保持すべき最低限の項目のみを示したが、他にも、クエリの登録者、クエリの登録日時、クエリの実行開始時刻、クエリの実行終了時刻、クエリの実行対象のストリームなどの項目を含んでも差し支えない。時間解像度変更処理を用いない場合のストリームデータ処理システムのクエリ登録の手順、ストリームデータ処理システム内部のデータの格納方法、格納形式、クエリを受け付けた後の解析方法、最適化方法、クエリの実行形式の作成方法、システムへの登録方法、ストリームデータ処理システムへのストリームの登録方法、システム内のデータ保持方法については、特開２００６−３３８４３２号公報「ストリームデータ処理システムのクエリ処理方法」に、その好適な実施の方法が開示されている。本発明では、該方法で作成されるクエリ保持テーブルに対して、時間解像度変更方法指示テーブルのエントリが含まれている。本エントリは、図６のフローチャートのステップ６０７でクエリ時間解像度変更部によって挿入され、クエリ処理エンジン１４０に登録される。クエリ保持テーブル１３２は、ストリームデータ処理サーバ１１１のメモリ１１２に保持するのでも、ストリームデータ処理サーバ１１１に接続されているストレージ装置１１５に格納するのでも差し支えない。
【００２８】
ストリームデータ処理システムには、一つ以上のストリームデータソースであるストリームデータソース１（１１７）〜ストリームデータソースＮ（１１８）からネットワーク１１９を介して時々刻々と大量のデータが到来する。このデータをストリームデータと呼ぶ。ストリームデータの好適な例としては、金融アプリケーションにおける株価配信情報、小売業でのＰＯＳデータ、交通情報システムにおけるプローブカー情報、計算機システム管理におけるエラーログなどが挙げられる。ストリームデータ処理システムでは、通信インタフェース１４５を介してデータフローマネージャ１３４が受け付けたストリームデータを、タイムスタンプを付与したストリームタプルに変換して、後述するクエリ処理エンジン１４０上にロードされたクエリ実行形式にフィードする。さらに、本発明ではクエリ実行形式をクエリ処理エンジンにロードする際に、クエリ解像度変更部は時間解像度変更方法指示テーブルを参照し、ロードするクエリに対応するサブウィンドウ幅の設定をサブウィンドウ管理部に、そして集約タプル集計関数を時間解像度変更クエリ結果生成部１４４に設定する。
【００２９】
前述したように、継続して到来する比較的小さな論理的には独立した大量の時系列データであるストリームデータを取り扱うために、ストリームデータ処理システムではウィンドウを用いる。メモリ上にロードされたクエリ実行形式のウィンドウ処理には、ウィンドウマネージャ１４１が適用される。図１のウィンドウマネージャ１４１は、到来するストリームデータに対して、クエリで指定されたウィンドウ演算を適用して、ストリームタプルのシステム内での生存期間を設定する。ストリームデータがウィンドウに挿入された時が生存期間の開始時刻、そしてウィンドウから該ストリームデータが削除される時が生存期間の終了時刻に相当する。本実施例の時間解像度変更クエリ処理では、ウィンドウマネージャ１４１が受け付けたストリームタプルは、サブウィンドウ管理部１４２でサブウィンドウ単位に集計され、集計結果である集約タプルはサブウィンドウ情報管理バッファ１４３に格納される。時刻解像度変更クエリ結果生成部１４４では、サブウィンドウ単位の集計値にさらに集計計算を施すことにより、与えられたクエリに対する処理結果を生成し、データ処理結果出力部１３３を介してアプリケーションに結果１０７を返信する。
【００３０】
以下、上述したそれぞれの処理を具体的に説明する。最初に、クエリの登録処理について図６を用いて説明する。アプリケーションからクエリが与えられると、処理が開始され（ステップ６０１）、クエリ時間解像度変更部１３０は該クエリに対する時間解像度変更の方法が指定されているか否かをチェックする（６０２）。時間解像度変更の方法が指定されている場合（ステップ６０２でＹｅｓが選択された場合）、クエリ時間解像度変更部は指定された項目を時間解像度変更方法指示テーブル１３１に登録すると共にクエリの実行形式を生成してクエリ保持テーブル１３２に登録し（６０７）、クエリ登録処理を終了する（６０８）。本実施例では、処理対象のクエリは図２のクエリＱ１（２０１）であり、図３の３０１が時間解像度の変更の指定である。クエリの処理内容、および時間解像度変更内容の詳細については、後述する。
【００３１】
アプリケーションから与えられたクエリに対する時間解像度変更の方法が指定されていない場合（ステップ６０２でＮｏが選択された場合）には、クエリ時間解像度変更部は時間解像度変更が可能か否かをチェックする（６０５）。不可能と判定された場合（ステップ６０５でＮｏが選択された場合）には、クエリ登録処理を終了する。本フローチャートでは変更が不可能である場合、クエリを登録しないことになっているが、アプリケーションに警告を出すなどして、時間解像度を変更せずに、すなわちメモリの使用量を一定化せずにクエリを実行させることも可能である。時間解像度変更が可能な場合（ステップ６０５でＹｅｓが選択された場合）、クエリ時間解像度変更部は時間解像度変更に必要な項目であるサブウィンドウの幅、解像度変更対象の入力ストリーム、集計対象、カラムを決定して（６０６）、これらの情報を時間解像度変更方法指示テーブル１３１に登録すると共にクエリの実行形式を生成してそのメモリ上のアドレスをクエリ保持テーブル１３２に登録し（６０７）する。最後に、クエリ時間解像度変更部は、前記クエリ実行形式をクエリ処理エンジン１４０に登録すると共に、該クエリに指定されたサブウィンドウ幅をサブウィンドウ管理部１４３に設定し、集約タプル集計関数を時間解像度変更クエリ結果生成部１４４に設定して（６０９）、クエリ登録処理を終了する。ステップ６０５の判定ステップは後述するが、該判定ステップ中で時間ウィンドウが設定されているウィンドウに対する最初の処理を集計処理に設定可能と判定された場合には、前記クエリの実行形式の生成の際に時間ウィンドウが設定されているストリームに対する最初の処理を集計処理に設定する。
【００３２】
サブウィンドウの幅については、その幅を小さく取るとクエリ処理で保持すべき集約タプル数が増加するため、メモリ使用量が増加する。サブウィンドウ幅の決定方法としては、例えばサブウィンドウの数と、各サブウィンドウ中に保持される集計値の数の積を計算し、該計算値とそれぞれの集計値で利用するメモリ量の積を計算し、該計算値が利用可能なメモリ量に収まるようにサブウィンドウ幅を決定する方法が考えられる。
【００３３】
時間解像度変更が可能か否かの判定方法について、図７を用いて説明する。まずクエリの出力結果が集計関数、および集計関数の引数のカラムで構成されているか否かをチェックする（７０２）。集計関数の引数以外のカラムを含む場合（ステップ７０２でＮｏが選択された場合）、時間解像度変更は不可能と判定し（７０４）、判定処理を終了する（７１０）。クエリの出力結果が集計関数、および集計関数の引数のカラムで構成されている場合（ステップ７０２でＹｅｓが選択された場合）、入力ストリームの数をチェックする（７０３）。入力ストリームが１つのみの場合、時間解像度変更可能と判定し（７０６）、判定処理を終了する（７１０）。
【００３４】
入力ストリームが複数存在する場合、時間ウィンドウが設定されているウィンドウに対する最初の処理を集計処理に設定可能か否かをチェックする（７０５）。例えば、該ストリームに対する最初の処理がジョインであり、それに続いてグルーピングおよび集計処理が実行される実行プランを、グルーピングおよび集計処理を先に実行し、その後にジョイン処理を実行する実行プランに変換可能か否かをチェックする。該変換が可能か否かの判定方法、および変換方法は、Ｓ． Ｃｈａｕｄｈｕｒｉ ａｎｄ Ｋ． Ｓｈｉｍ著：“Ｉｎｃｌｕｄｉｎｇ Ｇｒｏｕｐ−Ｂｙ ｉｎ Ｑｕｅｒｙ Ｏｐｔｉｍｉｚａｔｉｏｎ”， Ｉｎ Ｐｒｏｃ． ｏｆ ２０ｔｈ ＶＬＤＢ， ｐｐ． ３５４−３６６， １９９４の３節に開示されている。時間ウィンドウが設定されているウィンドウに対する最初の処理を集計処理に設定不可能な場合、（ステップ７０５でＮｏが選択される場合）、時間解像度変更不可能と判定して（７０４）、判定処理を終了する（７１０）。設定可能の場合（ステップ７０５でＹｅｓが選択された場合）、時間解像度変更が可能と判定して（７０６）、判定処理を終了する（７１０）。以上で、クエリの登録方法の説明を終了し、以降は登録されたクエリの時間解像度変更処理方法について説明する。
【００３５】
図２に示したＱ１は株式売買（ｓｔｏｃｋ）ストリームの最新１分間分を処理対象として銘柄名（ｂｒａｎｄ）毎の売上高を計算し、計算結果を３０秒毎に出力するクエリである。このＱ１の場合、集計グループは銘柄名（ｂｒａｎｄ）毎となる。時間解像度を変更せずにＱ１を処理する場合には、１分間に大量の売買情報がストリームデータとして到来すると、時間ウィンドウにそれらの個別のデータを保持する必要があり、システムのメモリ使用量が増大する。そこで、Ｑ１の株式売買ストリームを対象として、１分間の時間ウィンドウを３０秒毎のサブウィンドウに区切ってサブウィンドウの集計値を計算し、該集計値の更なる集計（再度集計処理）によってクエリＱ１の計算結果を求める方法を以下で説明する。
【００３６】
ユーザ、もしくはアプリケーション（以下、単にアプリケーションとする）が該計算方法をシステムに対して指定する好適な時間解像度変更指示方法を図３の３０１に示す。３０１ではクエリＱ１のストリームｓｔｏｃｋを対象として、時間解像度を３００００ｍｓすなわち３０秒に設定し、売上高ＳＵＭ（ｐｒｉｃｅ）を計算することを表している。
【００３７】
図１３を用いてシステムに時間解像度変更指示が入力された場合の登録処理方法を説明する。時間解像度変更指示が入力され、処理が開始すると（１３０１）、システムは該指示内容をチェックする（１３０２）。解像度変更対象のクエリ、ストリーム、カラム、集計関数がシステム中に存在しない場合（ステップ１３０３でＮｏが選択された場合）、登録エラーを出力し（１３０９）登録処理を終了する（１３１０）。解像度変更対象のクエリ、ストリーム、カラム、集計関数が存在する場合（ステップ１３０３でＹｅｓが選択された場合）、サブウィンドウの幅指定と時間解像度変更対象のクエリの時間ウィンドウの幅の関係をチェックする（１３１１）。サブウィンドウの幅指定が時間ウィンドウの幅よりも小さい場合（ステップ１３１１でＹｅｓが選択された場合）には、次のステップに進む。サブウィンドウの幅指定が時間ウィンドウ幅よりも大きい場合（ステップ１３１１でＮｏが選択された場合）には、サブウィンドウ幅指定を時間ウィンドウ幅にセットして（１３１２）、次のステップに進む。
【００３８】
次に、サブウィンドウの幅指定がシステムの規定範囲内に収まっているか否かをチェックする（１３０４）。システムにおけるサブウィンドウの幅の規定範囲の最小値、最大値をそれぞれＴＭＩＮ、ＴＭＡＸとする。ＴＭＩＮ、ＴＭＡＸは、システムが稼動しているハードウェア、オペレーティングシステム、システムが使用可能なリソース量を考慮して、システム設計者もしくはシステム管理者により決定される。例えば、オペレーティングシステムでの最小時間解像度がＴＯＳＭＩＮの場合、サブウィンドウの幅はＴＯＳＭＩＮよりは小さくできないためＴＭＩＮ≧ＴＯＳＭＩＮである。時間解像度変更指示の幅指定ＴＤＩＳがシステムの規定範囲内におさまっている場合、すなわちＴＭＩＮ≦ＴＤＩＳ≦ＴＭＡＸの場合（ステップ１３０４でＹｅｓが選択された場合）には、指示内容を時間解像度変更方法指示テーブルに登録し（１３０８）、時間解像度変更指示登録処理を終了する（１３１０）。サブウィンドウの幅指定がシステムの規定範囲内に収まっていない場合、すなわちＴＤＩＳ＜ＴＭＩＮ、もしくはＴＤＩＳ＞ＴＭＡＸの場合（ステップ１３０４でＮｏが選択された場合）、システムの時間解像度変更指示モードをチェックする。指示内容チェックモードがｓｔｒｉｃｔの場合（ステップ１３０５でＹｅｓが選択された場合）、登録エラーを出力し（１３０９）登録処理を終了する（１３１０）。指示内容チェックモードがｓｔｒｉｃｔでない場合（ステップ１３０５でＮｏが選択された場合）、クエリ時間解像度変更部（１３０）から警告を出力し（１３０６）、サブウィンドウ幅の指定が規定範囲の最小値より小さい場合（ＴＤＩＳ＜ＴＭＩＮの場合）は幅を規定値の最小値に（ＴＤＩＳ＝ＴＭＩＮに）、サブウィンドウの幅の指定が規定範囲の最大値より大きい場合（ＴＤＩＳ＞ＴＭＡＸの場合）は幅を規定値の最大値に（ＴＤＩＳ＝ＴＭＡＸに）セットし（１３０７）、指示内容を時間解像度変更方法指示テーブルに登録し（１３０８）、時間解像度変更指示登録処理を終了する（１３１０）。
【００３９】
本実施例では、ステップ１３０５で指示内容チェックモードを参照している。指示内容チェックモードは、システム全体を対象として設定する方法でも、またクエリ単位で設定する方法でも差し支えない。またその格納場所は、クエリ保持テーブル１３２でも、システム接続されたストレージ装置１１５でも差し支えない。さらに、指示内容チェックモードの指定自体をシステムの規定値として、すなわちシステム構築時にチェックモードをｓｔｒｉｃｔとするか否かを定め、実行時にはステップ１３０５のチェックを行わない実現方法も可能である。
【００４０】
以上の登録結果は、例えば図４に示す形式で時間解像度変更方法指定テーブル１３１としてシステム中に管理される。時間解像度指示テーブル１３１は、各登録毎に、番号４０１、クエリ名４０２、入力ストリーム名４０３、サブウィンドウ幅４０４、対象集計関数４０５、対象カラム名４０６が管理される。
【００４１】
クエリと時間解像度変更方法が指定された後、システムストリームデータが到来した際の処理シーケンスを、図５を用いて説明する。ストリームデータソース１１７はストリームデータを生成する。生成されたストリームデータ（５０１）は、ネットワーク１１６、通信インタフェース１４５を介して、システムのデータフローマネージャ１３４によって受け付けられる（５０２）。ストリームデータを受け付けたデータフローマネージャ１３４は、ストリームデータからタイムスタンプを保持するストリームタプルを生成し（５０３）、クエリ処理エンジン１４０に送信する。データフローマネージャ１３４は、ストリームデータがシステムに到着した時刻をタイムスタンプとして用いるサーバタイムスタンプモード、およびストリームデータに付与されている時刻情報をタイムスタンプとして用いるアプリケーションタイムスタンプモードのいずれかのモードでの動作が可能である。
【００４２】
クエリ処理エンジン１４０のウィンドウマネージャ１４１がストリームタプルを受け取ると、ウィンドウマネージャ１４１内のサブウィンドウ管理部１４２は、サブウィンドウ単位の集計値を計算し、サブウィンドウ情報管理バッファ１４３に該集計値を追加、更新し（５０４）する。さらに、サブウィンドウ管理部１４２は、前記追加、更新に伴う新しい集計値に関する差分情報（プラスの符号付ストリームタプル）を生成し（５０５）、時間解像度変更クエリ結果生成部１４４に送信する。また、サブウィンドウ管理部１４２は、集約タプルの生存期間が終了する際には、該集約タプルをサブウィンドウ情報管理バッファ１４３から削除し、該削除に伴う差分情報（マイナスの符号付ストリームタプル）を生成し、時間解像度変更クエリ結果生成部１４４に送信する。時間解像度変更クエリ結果生成部１４４は、前記差分情報からクエリの計算結果を生成し（５０６）、データ処理結果出力部１３３に送信する。そしてデータ処理結果出力部１３３ではクエリで指定されたデータ出力方法に従ってクエリ処理結果をアプリケーションに送信する（５０７）。クエリでのデータ出力指定方法については後述する。
【００４３】
以上説明した本実施例の一連の処理シーケンス中で、時間解像度変更の特徴的な処理はウィンドウマネージャ１４１内の処理であるので、図９を用いて前述のＱ１に対して株式売買（ｓｔｏｃｋ）ストリームデータが到来した場合の処理を具体的に説明する。図９は時間経過に伴って、ウィンドウマネージャ１４１内でストリームタプルがどのように処理されていくかを示すシーケンス図である。時間は図の左側の矢印９３１で示すように図の上から下側に進行する。図の縦線９３２、９３３はそれぞれ、サブウィンドウ管理部１４２、および時間解像度変更クエリ結果生成部１４４での処理を示しており、９０１、９０２、９０３、９３４、９４３はそれぞれ、ウィンドウマネージャ１４１に送信されるストリームタプル、サブウィンドウ情報管理バッファ１４３で管理される集約タプル、ウィンドウマネージャ１４１で生成される差分情報、時間解像度変更クエリ結果生成部１４４で保持される集計結果、最終的にアプリケーションに返されるクエリ処理結果の凡例を表している。
【００４４】
９０１に示されているように、ｓｔｏｃｋストリームは銘柄（ｂｒａｎｄ）と売買価格（ｐｒｉｃｅ）を構成要素として保持し、ウィンドウマネージャに送付されるストリームタプルはｂｒａｎｄ、ｐｒｉｃｅとタイムスタンプ（ｔｉｍｅ）を含んでいる。クエリＱ１（２０１）は１分間の時間ウィンドウを持つ。Ｑ１に図３で示される時間解像度変更指定（３０１）を適用した場合のクエリ処理方法を説明する。クエリ処理の開始時刻は１０：０１：００と仮定する。時刻１０：０１：００にストリームタプル｛ａ，１００；１０：０１：００｝が到来する（９０４）。該ストリームタプルを受け付けたウィンドウマネージャは、サブウィンドウ管理部に集約タプル９０５を作成する。本実施例では、集約タプルにクエリの最終結果計算に必要なカラム（今回の場合、ｂｒａｎｄカラムとＳＵＭ（ｐｒｉｃｅ）カラム）に加えて、集約タプルの生存期間終了時刻（ｅｘｐｒｉｒｅ ｔｉｍｅ）、時間解像度のサブウィンドウの区切りを識別するための情報（シーケンス番号：ｓｅｑ．＃）が追加されている。集約タプルの生存終了時刻は、該集約タプルが生成された時刻（生存開始時刻）に、クエリの時間ウィンドウで指定された時間幅を加えることによって計算される。本実施例のクエリＱ１では、時間ウィンドウの幅は１分であるので、集約タプルの生成時刻１０：０１：００の１分後の１０：０２：００が生存期間終了時刻として設定される。サブウィンドウの区切りを識別するための情報の管理方法は、本実施例のようにデータと同じレコードに含めても、もしくはデータから紐付けが可能な別データとして管理するのでも差し支えない。作成された集約タプル９０５はサブウィンドウ情報管理バッファ１４３に登録される。次に、ウィンドウマネージャは本集約タプルの作成に伴う集計値の変化を差分情報として出力する。差分情報の表現方法は各種のバリエーションが考えられるが、本実施例では符号付きのストリームタプルで表現する。集約タプル９０５の場合は、新規に集約タプルが生成されたので、差分情報としてはプラスの符号付きストリームタプル９０６が生成され、時間解像度変更クエリ結果生成部１４４に送信される。時間解像度変更クエリ結果生成部では、サブウィンドウ単位の集約タプルの差分情報を受け取り、クエリ全体での計算結果を生成する。差分情報としてはプラスの符号付きストリームタプル９０６を受け取った時には、それ以前の集計値は存在しないので、クエリ全体の集計値としてストリームタプル９３５を生成する。
【００４５】
クエリＱ１ではＲＳＴＲＥＡＭ ［３０ ＳＥＣＯＮＤ］句指定により、クエリの計算結果はアプリケーションに３０秒間隔で送信する指示がなされている。非特許文献５の６．３節には、ストリームデータ処理システムからの好適なストリームデータ出力方法が開示されている。一つ目はストリームシステム内の前回出力時からの増加分を出力するＩＳＴＲＥＡＭ句、二つ目はストリームシステム内の前回出力時からの減少分を出力するＤＳＴＲＥＡＭ句、そして三つ目がその時点でのストリームシステム内の出力対象全体を出力するＲＳＴＲＥＡＭ句である。本実施例では、ＲＳＴＲＥＡＭ句が指定された場合について説明するが、ＩＳＴＲＥＡＭ句、ＤＳＴＲＥＡＭ句が指定された場合にも本発明の適用は可能である。なお、ＲＳＴＲＥＡＭ句は非特許文献５では出力間隔の指定方法が示されていないが、本実施例ではＲＳＴＲＥＡＭ句を拡張し、出力間隔の指定を可能としている。
【００４６】
Ｑ１の処理では、最初の出力として１０：０１：００にクエリ処理結果｛ａ，１００｝が出力される（９０７）。続いて、時刻１０：０１：０１にストリームタプル９０８が到来する。先に述べたとおり、本実施例では時間解像度は３０秒に設定されているため、本ストリームタプルは先に処理されたストリームタプル９０４と同じサブウィンドウに区分される。そのため、ストリームタプルを受け付けたサブウィンドウ管理部１４２では、ストリームタプル９０４を追加した際に生成したシーケンス番号１０２８１のエントリを更新して集約タプル９０９を作成する。更新処理では、集計値に加えて、その生存終了時刻の更新処理も実施される。この場合、入力となるストリームタプルのタイムスタンプが１０：０１：０１であるので、該時刻にクエリの時間ウィンドウの幅１分間を加えた１０：０２：０１に生存終了時刻が更新される。そしてこの更新に伴う差分情報として、更新前の値１５０を保持するプラスの符号を持つストリームタプル、および更新後の値１００を保持するマイナスの符号を持つストリームタプル９１０を生成し、時間解像度変更クエリ結果生成部１４４に送信する。時間解像度変更クエリ結果生成部１４４では、該差分情報を用いてクエリ処理結果９３６を生成する。前述したように、Ｑ１ではアプリケーションからのクエリ処理結果出力指定がＲＳＴＲＥＡＭ句により３０秒毎のため、このタイミングではアプリケーションには結果は出力されない。時刻１０：０１：１１にストリームタプル９１１が到来した際にも、全く同様の更新処理が実行され、時間解像度変更クエリ結果生成部にクエリ処理結果のストリームタプル９３７が生成される。そして、時刻１０：０１：３０のアプリケーションから指定された結果出力タイミングで、この時点のクエリ処理結果である｛ａ，２２０｝がアプリケーションに送信される。
【００４７】
次に時刻１０：０１：５９にストリームタプル９１５が到来する。本実施例の時間解像度は３０秒であり、最初のサブウィンドウの区切りは１０：０１：００であるため、ストリームタプル９１５は、これまでに到来した三つのストリームタプル９０４、９０８、９１１とは異なるサブウィンドウに区分けされる。そのため、サブウィンドウ管理部１４２では、ストリームタプル９１５に対応する新たなシーケンス番号を持つ新しい集約タプルのエントリを作成し、サブウィンドウ情報管理バッファ１４３に格納する（９１６）。同時に、新しい集約タプル生成に伴う差分情報として、プラスの符号を持つストリームタプル９１７を生成し、時間解像度変更クエリ結果生成部１４４に送信する。時間解像度変更クエリ結果生成部１４４では、受け取った差分情報を利用して集計結果を更新する（９３８）。
【００４８】
時刻１０：０２：００では、時刻１０：０１：３０の時と同様に、この時点のクエリ処理結果である｛ａ，３４０｝がアプリケーションに送信される（９１８）。次に時刻１０：０２：０５に新しいストリームタプル９１９が到来すると、該タプルはその前に到来したストリームタプル９１５とはサブウィンドウの区分けが異なるため、サブウィンドウ情報管理バッファ１４３に新たな集約タプルのエントリ９２０が生成され、該集約タプルの生成に伴う差分情報９２１が生成され、時間解像度変更クエリ結果生成部１４４でクエリ処理結果が更新される（９３９）。
【００４９】
時刻１０：０２：１１には、シーケンス番号が１０２８１の集約タプルの生存期間が終了する。そこで、サブウィンドウ管理部１４２では、サブウィンドウ情報管理バッファ１４３からシーケンス番号１０２８１の集約タプルのエントリを削除する（９２２）とともに、該削除処理に伴う差分情報を時間解像度変更クエリ結果生成部１４４に送信する（９２３）。時間解像度変更クエリ結果生成部１４４では、該差分情報を利用して、集計値を更新する（９４０）。以下、ストリームタプル９２４、９２７が到来した際にも同様の処理が行われ、１０：０２：３０にクエリ処理結果｛ａ，４８０｝がアプリケーションに送信される（９３０）。
【００５０】
本実施例では簡単のために、株式銘柄名（ｂｒａｎｄ）が一種類の場合の処理シーケンスを示したが、複数の株式銘柄が存在する場合には、株式銘柄毎にサブウィンドウで集約タプルを管理することで同様の処理が可能である。すなわち、集約の単位を、クエリＱ１で指定された集計グループである銘柄名（ｂｒａｎｄ）毎とすることができる。
【００５１】
以上の処理をまとめたフローチャートを図８に示す。最初に、サブウィンドウ情報管理バッファ１４３内にその生存期間終了時刻が現時刻以前の集約タプルのエントリが存在するか否かをチェックする（８０２）。存在しない場合（ステップ８０２でＮｏが選択された場合）には、次のステップに進む。これは図９に示した例では、時刻１０：０２：１１以外の場合に相当する。存在する場合（ステップ８０２でＹｅｓが選択された場合）には、該エントリをサブウィンドウ情報管理バッファ１４３から削除し（８０４）、該エントリに対応する差分情報（マイナス符号付きのストリームタプル）をウィンドウマネージャから出力する（８０３）。本処理は、図９で示した例では時刻１０：０２：１１のシーケンス番号１０２８１の集約タプルエントリの削除処理に相当する。
【００５２】
次に、ストリームタプルを受け取った時の処理を説明する。今説明の便宜上、受け取ったストリームタプルをｔとする。ウィンドウマネージャ１４１がタイムスタンプ付きのストリームタプルｔを受け取る（８０５）と、サブウィンドウ管理部１４２はｔのタイムスタンプがサブウィンドウ情報管理バッファ１４３内の最新のシーケンス番号の時刻区切りを越えたか否かをチェックする（８０６）。超えない場合（ステップ８０６でＮｏが選択された場合）には、ストリームタプルｔを用いて最新のシーケンス番号をもつ集約タプルを更新し（８０８）、更新した集約タプルの生存期間終了時刻を“ｔのタイムスタンプ＋時間ウィンドウの幅”に設定し（８０９）、本更新処理に伴う差分情報をウィンドウマネージャ１４１から出力する（８１０）。本処理は図９の例では、ストリームタプル９０８、９１１、９２４、９２７の到来時の処理に相当する。
【００５３】
ｔのタイムスタンプがサブウィンドウ情報管理バッファ１４３内の最新のシーケンス番号の時刻区切りを越える場合（ステップ８０６でＹｅｓが選択される場合）には、サブウィンドウ管理部１４２は新しいシーケンス番号を生成し（８１１）、サブウィンドウ情報管理バッファ１４３内に、該シーケンス番号を持つ新たな集約タプルのエントリを作成して該エントリにストリームタプルｔを格納し（８１２）、作成した集約タプルの生存期間終了時刻を“ｔのタイムスタンプ＋時間ウィンドウの幅”に設定し（８１３）、該集約タプル作成に伴う差分情報をウィンドウマネージャから出力する（８１４）。本処理は図９の例では、ストリームタプル９１５、９１９の到来時の処理に相当する。
【００５４】
時間解像度変更クエリ結果生成部１４４では、ウィンドウマネージャ１４１から出力されたサブウィンドウ単位の集約タプルに関する差分情報を再度集計し、クエリ処理結果を生成する（８１５）。本再集計処理では、クエリで指定された集計、サブウィンドウ単位の集計（集約タプルの生成方法）、時間解像度変更クエリ結果生成部１４４の集計処理の組合せの好適な実施例を図１２の表１２０１に示す。本処理は図９の例では、縦線９３３上のストリームタプル計算に相当する。本実施例の場合、クエリで指定された集計はＳＵＭ（総和）であるので、図１２の表１２０１に示すとおり、サブウィンドウ管理部１４２では到来するストリームタプルのＳＵＭをサブウィンドウ単位に計算し、時間解像度変更クエリ結果生成部でもウィンドウマネージャ１４１から出力された差分情報のＳＵＭを計算している。図８に戻って、時間解像度変更クエリ結果生成部で生成したクエリ処理結果は、クエリで指定されたタイミングでアプリケーションに出力される（８１６）。本処理は図９の例では９０７、９１４、９１８、９３０の出力処理に相当する。
【００５５】
以上説明した実施例では、図８および図９を用いて対象となるクエリとしてＱ１のＳＵＭ（総和）を計算する場合のみを説明したが、図１０に示した、ＭＡＸ（最大値）を含んだクエリＱ２（１００１）、ＭＩＮ（最小値）を含んだクエリＱ３（１００２）、ＣＯＵＮＴ（件数）を含んだクエリＱ４（１００３）、ＡＶＥＲＡＧＥ（平均値）を含んだクエリＱ５（１００４）についても本発明は適用が可能である。
【００５６】
図１２の表１２０１を用いて具体的な計算方法を説明する。図１２では、ｉ番目のサブウィンドウの集約タプルをＴＡｉと表している（＃５の場合のみ二種類の集約タプルを用いるため、ＴＡｉ＿１、ＴＡｉ＿２と表す）。この時、Ｑ２については図１２の＃２に示すように、サブウィンドウ管理部１４２においてサブウィンドウ単位のＭＡＸ（最大値）を計算した集約タプルを生成した後、時間解像度変更クエリ結果生成部１４４において集約タプル間のＭＡＸ（最大値）を計算すればよい。
【００５７】
同様に、Ｑ３については図１２の＃３に示すように、サブウィンドウ単位のＭＩＮ（最小値）を計算した集約タプルを生成した後、集約タプル間のＭＩＮ（最小値)を計算すればよい。Ｑ４については図１２の＃４に示すように、サブウィンドウ単位のＣＯＵＮＴ（件数）を計算した集約タプルを生成した後、該集約タプルのＳＵＭ（総和）を計算すればよい。ＳＵＭ、ＭＩＮ、ＭＡＸの場合は、集約タプルを計算する演算と集約タプルから最終的なクエリの処理結果を生成する際に同種の演算を用いたが、Ｑ４のＣＯＵＮＴ（件数）の場合にはサブウィンドウ単位の集約タプルのＣＯＵＮＴを計算してもサブウィンドウの数が計算されるだけであるので、注意が必要である。
最後に、Ｑ５については図１２の＃５に示すように、集約タプルの全体の総和を集約タプル全体の件数で割ることによって計算すればよい。さらに、これらの基本集計演算を組み合わせたより複雑な集計値、統計値の計算についても、基本集計演算の計算結果を生成した後その計算結果を組み合わせることにより、本願のストリームデータ処理方法の適用が可能である。
【００５８】
また、上述の実施例では図３で時間解像度指定の方法として、時間解像度変更の対象となるクエリ名、入力ストリーム名、サブウィンドウ幅、集計関数、カラム名を全て指定するインタフェースを示したが、システムへの初期設定等により、アプリケーションからの個別指定なしに、図１２に示した変換により時間解像度変更が可能な全ての集計関数に対して時間解像度変更処理を実行することも可能である。この場合には、アプリケーションからの対象集計関数の指定は省略することができる。
【００５９】
さらに、上述した実施例ではクエリがＣＱＬの形式で与えられることを想定したが、手続き型言語、ＧＵＩなどの他の手段で与えられる場合にも本願発明のストリームデータ処理方法は適用が可能である。
【図面の簡単な説明】
【００６０】
【図１】第一の実施例に係わるストリームデータ処理システムの構成を示す図である。
【図２】第一の実施例に係わる、時間解像度変更対象のクエリの一例を示す図である。
【図３】第一の実施例に係わる、クエリ時間解像度変更指定の一例を示す図である。
【図４】第一の実施例に係わる、クエリ時間解像度変更指定内容の格納例を示す図である。
【図５】第一の実施例に係わる、クエリ時間解像度変更処理のシーケンスを示す図である。
【図６】第一の実施例に係わる、クエリ登録処理のフローチャートを示す図である。
【図７】第一の実施例に係わる、時間解像度変更書換え可能性チェックおよび書換え処理のフローチャートを示す図である。
【図８】第一の実施例に係わる、クエリ時間解像度変更処理のフローチャートを示す図である。
【図９】第一の実施例に係わる、クエリ時間解像度変更処理の具体例を示す図である。
【図１０】各実施例に係わる、時間解像度変更が可能なクエリの例を示す図である。
【図１１】第一の実施例に係わる、クエリの格納例を示す図である。
【図１２】各実施例に係わる、集計処理実現方法を示す表を示す図である。
【図１３】第一の実施例に係わる、クエリ時間解像度変更指示登録処理のフローチャートを示す図である。
【図１４】クエリ処理言語ＣＱＬによるクエリ記述例を示す図である。
【符号の説明】
【００６１】
１０１、１０３…クライアント計算機
１０２、１０４…アプリケーション
１１１…ストリームデータ処理サーバ
１１０、１１９…ネットワーク
１１２…メモリ
１３０…クエリ時間解像度変更部
１３１…時間解像度変更方法指示テーブル
１３２…クエリ保持テーブル
１３３…データ処理結果出力部
１３４…データフローマネージャ
１４０…クエリ処理エンジン
１４１…ウィンドウマネージャ
１４２…サブウィンドウ管理部
１４３…サブウィンドウ情報管理バッファ
１４４…時間解像度変更クエリ結果生成部
１１６…バス
１１３…ＣＰＵ
１１４…Ｉ／Ｏインタフェース
１４５…通信インタフェース
１１５…ストレージ
１１７、１１８…ストリームデータソース
９０４、９０８、９１１、９１５、９１９、９２４、９２７…ストリームタプル
９０５、９０９、９１２、９１６、９２０、９２２、９２５、９２８…集約タプル
９０６、９１０、９１３、９１７、９２１、９２３、９２６、９２９…符号付ストリームタプル。
【特許請求の範囲】
【請求項１】
ストリームデータに対しクエリ処理を行うシステムにおけるストリームデータ処理方法であって、
前記クエリが、ある時間間隔内に前記システムに到来した前記ストリームデータを処理対象とする時間ウィンドウを含む場合に、前記時間ウィンドウをより小さい幅のサブウィンドウに区切り、
前記サブウィンドウ内に含まれる前記ストリームデータを集約した少なくとも一つの集約タプルを生成し、
前記集約タプルを用いて前記クエリの処理結果を計算する、ことを特徴とするストリームデータ処理方法。
【請求項２】
前記集約タプルの集約単位が、前記クエリで指定された集計グループごとであることを特徴とする請求項１記載のストリームデータ処理方法。
【請求項３】
前記集約タプルに対して再度集計処理を実行して、前記クエリの処理結果を計算することを特徴とする請求項１記載のストリームデータ処理方法。
【請求項４】
ストリームデータに対しクエリ処理を行うシステムにおけるストリームデータ処理方法であって、
前記クエリが、ある時間間隔内に前記システムに到来した前記ストリームデータを処理対象とする時間ウィンドウを含む場合に、前記時間ウィンドウをより小さい幅のサブウィンドウに区切り、
受け付けたストリームタプルが新しい前記サブウィンドウに区分けされる場合に、前記サブウィンドウ内に集約タプルを生成し、前記集約タプルの生存期間の終了時刻を、受け付けた前記ストリームタプルのタイムスタンプに前記クエリで指定された前記時間ウィンドウの幅を加えた時刻に設定し、
受け付けたストリームタプルが既存の前記サブウィンドウに区分けされる場合に、当該ストリームタプルを用いて前記集約タプルを更新し、更新した前記集約タプルの生存期間終了時刻を、受け付けた前記ストリームタプルのタイムスタンプに前記クエリで指定された前記時間ウィンドウの幅を加えた時刻に設定し、
設定した前記生存期間終了時刻に、前記集約タプルを消去するためのフラグをつけたストリームタプルを生成し、
前記集約タプルを用いて前記クエリの処理結果を計算する、ことを特徴とするストリームデータ処理方法。
【請求項５】
前記集約の単位が前記クエリで指定された集計グループごとであることを特徴とする請求項４記載のストリームデータ処理方法。
【請求項６】
前記集約タプルに対して再度集計処理を実行して、前記クエリの処理結果を計算することを特徴とする請求項４記載のストリームデータ処理方法。
【請求項７】
ストリームデータに対しクエリ処理を行うストリームデータ処理システムであって、
前記ストリームデータが入力されるネットワークインタフェース部と、前記ストリームデータに対するクエリ処理する処理部と、前記クエリを保持する記憶部とを備え、
前記処理部は、前記クエリが、ある時間間隔内に前記システムに到来した前記ストリームデータを処理対象とする時間ウィンドウを含む場合に、前記時間ウィンドウをより小さい幅のサブウィンドウに区切り、前記サブウィンドウ内に含まれる前記ストリームデータを集約した少なくとも一つの集約タプルを生成し、前記クエリの処理結果を前記集約タプルを用いて計算する、
ことを特徴とするストリームデータ処理システム。
【請求項８】
前記処理部における前記集約の単位が前記クエリで指定された集計グループごとであることを特徴とする請求項７記載のストリームデータ処理システム。
【請求項９】
前記処理部は、前記サブウィンドウ内の集約結果である前記集約タプルに対して再度集計処理を実行して、前記クエリ処理結果を計算することを特徴とする請求項７記載のストリームデータ処理システム。
【請求項１０】
前記処理部は、受け付けたストリームタプルが新しい前記サブウィンドウに区分けされる場合に、前記サブウィンドウ内に前記集約タプルを生成し、該集約タプルの生存期間の終了時刻を、受け付けた前記ストリームタプルのタイムスタンプに前記クエリで指定された時間ウィンドウの幅を加えた時刻に設定し、
受け付けたストリームタプルが既存の前記サブウィンドウに区分けされる場合に、該ストリームタプルを用いて前記集約タプルを更新し、更新した前記集約タプルの生存期間終了時刻を、受け付けた前記ストリームタプルのタイムスタンプに前記クエリで指定された時間ウィンドウの幅を加えた時刻に設定し、
設定した前記生存期間終了時刻に、前記集約タプルを消去するためのフラグをつけたストリームタプルを生成することを特徴とする請求項７記載のストリームデータ処理システム。
【請求項１１】
前記処理部は、前記クエリの登録処理開始時に、前記時間ウィンドウを前記サブウィンドウに区切ることが可能か否かを判定する時間解像度変更可能性判定を実行することを特徴とする請求項７記載のストリームデータ処理システム。
【請求項１２】
前記処理部は、前記時間解像度変更可能性判定を、前記クエリ処理結果が集計関数で構成されているか否かで判定することを特徴とする請求項１１記載のストリームデータ処理システム。
【請求項１３】
前記集計関数は、総和、最大値、最小値、件数、平均のいずれかであることを特徴とする請求項１２記載のストリームデータ処理システム。
【請求項１４】
前記処理部における前記集約の単位が前記クエリで指定された集計グループごとであることを特徴とする請求項１０記載のストリームデータ処理システム。
【請求項１５】
前記処理部は、前記サブウィンドウ内の集約結果である前記集約タプルに対して再度集計処理を実行して、前記クエリの処理結果を計算することを特徴とする請求項１０記載のストリームデータ処理システム。
【請求項１】
ストリームデータに対しクエリ処理を行うシステムにおけるストリームデータ処理方法であって、
前記クエリが、ある時間間隔内に前記システムに到来した前記ストリームデータを処理対象とする時間ウィンドウを含む場合に、前記時間ウィンドウをより小さい幅のサブウィンドウに区切り、
前記サブウィンドウ内に含まれる前記ストリームデータを集約した少なくとも一つの集約タプルを生成し、
前記集約タプルを用いて前記クエリの処理結果を計算する、ことを特徴とするストリームデータ処理方法。
【請求項２】
前記集約タプルの集約単位が、前記クエリで指定された集計グループごとであることを特徴とする請求項１記載のストリームデータ処理方法。
【請求項３】
前記集約タプルに対して再度集計処理を実行して、前記クエリの処理結果を計算することを特徴とする請求項１記載のストリームデータ処理方法。
【請求項４】
ストリームデータに対しクエリ処理を行うシステムにおけるストリームデータ処理方法であって、
前記クエリが、ある時間間隔内に前記システムに到来した前記ストリームデータを処理対象とする時間ウィンドウを含む場合に、前記時間ウィンドウをより小さい幅のサブウィンドウに区切り、
受け付けたストリームタプルが新しい前記サブウィンドウに区分けされる場合に、前記サブウィンドウ内に集約タプルを生成し、前記集約タプルの生存期間の終了時刻を、受け付けた前記ストリームタプルのタイムスタンプに前記クエリで指定された前記時間ウィンドウの幅を加えた時刻に設定し、
受け付けたストリームタプルが既存の前記サブウィンドウに区分けされる場合に、当該ストリームタプルを用いて前記集約タプルを更新し、更新した前記集約タプルの生存期間終了時刻を、受け付けた前記ストリームタプルのタイムスタンプに前記クエリで指定された前記時間ウィンドウの幅を加えた時刻に設定し、
設定した前記生存期間終了時刻に、前記集約タプルを消去するためのフラグをつけたストリームタプルを生成し、
前記集約タプルを用いて前記クエリの処理結果を計算する、ことを特徴とするストリームデータ処理方法。
【請求項５】
前記集約の単位が前記クエリで指定された集計グループごとであることを特徴とする請求項４記載のストリームデータ処理方法。
【請求項６】
前記集約タプルに対して再度集計処理を実行して、前記クエリの処理結果を計算することを特徴とする請求項４記載のストリームデータ処理方法。
【請求項７】
ストリームデータに対しクエリ処理を行うストリームデータ処理システムであって、
前記ストリームデータが入力されるネットワークインタフェース部と、前記ストリームデータに対するクエリ処理する処理部と、前記クエリを保持する記憶部とを備え、
前記処理部は、前記クエリが、ある時間間隔内に前記システムに到来した前記ストリームデータを処理対象とする時間ウィンドウを含む場合に、前記時間ウィンドウをより小さい幅のサブウィンドウに区切り、前記サブウィンドウ内に含まれる前記ストリームデータを集約した少なくとも一つの集約タプルを生成し、前記クエリの処理結果を前記集約タプルを用いて計算する、
ことを特徴とするストリームデータ処理システム。
【請求項８】
前記処理部における前記集約の単位が前記クエリで指定された集計グループごとであることを特徴とする請求項７記載のストリームデータ処理システム。
【請求項９】
前記処理部は、前記サブウィンドウ内の集約結果である前記集約タプルに対して再度集計処理を実行して、前記クエリ処理結果を計算することを特徴とする請求項７記載のストリームデータ処理システム。
【請求項１０】
前記処理部は、受け付けたストリームタプルが新しい前記サブウィンドウに区分けされる場合に、前記サブウィンドウ内に前記集約タプルを生成し、該集約タプルの生存期間の終了時刻を、受け付けた前記ストリームタプルのタイムスタンプに前記クエリで指定された時間ウィンドウの幅を加えた時刻に設定し、
受け付けたストリームタプルが既存の前記サブウィンドウに区分けされる場合に、該ストリームタプルを用いて前記集約タプルを更新し、更新した前記集約タプルの生存期間終了時刻を、受け付けた前記ストリームタプルのタイムスタンプに前記クエリで指定された時間ウィンドウの幅を加えた時刻に設定し、
設定した前記生存期間終了時刻に、前記集約タプルを消去するためのフラグをつけたストリームタプルを生成することを特徴とする請求項７記載のストリームデータ処理システム。
【請求項１１】
前記処理部は、前記クエリの登録処理開始時に、前記時間ウィンドウを前記サブウィンドウに区切ることが可能か否かを判定する時間解像度変更可能性判定を実行することを特徴とする請求項７記載のストリームデータ処理システム。
【請求項１２】
前記処理部は、前記時間解像度変更可能性判定を、前記クエリ処理結果が集計関数で構成されているか否かで判定することを特徴とする請求項１１記載のストリームデータ処理システム。
【請求項１３】
前記集計関数は、総和、最大値、最小値、件数、平均のいずれかであることを特徴とする請求項１２記載のストリームデータ処理システム。
【請求項１４】
前記処理部における前記集約の単位が前記クエリで指定された集計グループごとであることを特徴とする請求項１０記載のストリームデータ処理システム。
【請求項１５】
前記処理部は、前記サブウィンドウ内の集約結果である前記集約タプルに対して再度集計処理を実行して、前記クエリの処理結果を計算することを特徴とする請求項１０記載のストリームデータ処理システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１０−１０８０７３（Ｐ２０１０−１０８０７３Ａ）
【公開日】平成２２年５月１３日（２０１０．５．１３）
【国際特許分類】
【出願番号】特願２００８−２７６９７７（Ｐ２００８−２７６９７７）
【出願日】平成２０年１０月２８日（２００８．１０．２８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２２年５月１３日（２０１０．５．１３）
【国際特許分類】
【出願日】平成２０年１０月２８日（２００８．１０．２８）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]