JP5439014B2 - データ処理システム、その処理方法、及び計算機 - Google Patents

Description

本発明は、データ処理システム、特にストリームデータをリアルタイムに処理するデータ処理技術に関する。

従来、企業情報システムのデータ管理には、主に、データベース管理システム（Data Base Management System、以下、ＤＢＭＳ）が用いられてきた。ＤＢＭＳは、処理対象のデータをディスク装置に格納し、格納したデータに対して処理を実行する。これに対して、時々刻々と到着するデータ（タプル）をリアルタイムに処理するデータ処理システムに対する要求が高まっている。例えば、株取引を支援する金融アプリケーションでは、株価の変動に対し、いかに迅速に反応できるかがシステムの重要な課題の一つである。従来のＤＢＭＳのように株式のデータを一旦ディスク装置に格納してから、該データに関して検索を行うシステムでは、データの格納とそれに続く検索処理が株価変動のスピードに追いつくことができず、ビジネスチャンスを逃してしまうことになりかねない。

このようなリアルタイムデータ処理に好適なデータ処理システムとして、ストリームデータ処理システムが提案されている。例えば、非特許文献１にストリームデータ処理システムＳＴＲＥＡＭが開示されている。

ストリームデータ処理システムでは、従来のＤＢＭＳとは異なり、予めデータ処理の方法を規定するクエリをシステムに登録し、到着したデータをサーバ装置の揮発メモリに格納して、データ処理を実行する。ここでのストリームデータとは、時々刻々と変化する株価のデータ、小売業でのＰＯＳデータ、計算機システム管理におけるエラーログ、センサやＲＦＩＤ(Radio Frequency Identification)などから発生するセンシングデータなどの、時系列データである。

ＳＴＲＥＡＭでは、システムに到来し続けるストリームデータを、最新１０分間などの時間の幅、もしくは最新１０００件などの個数の幅を指定して、ストリームデータの一部を切り取りながらデータ処理を行う。ストリームデータの一部を切り取るために、ウィンドウと呼ばれる概念が導入されている。ウィンドウの指定を含むクエリの記述言語の好適な例としては、非特許文献１に開示されているコンティニュアス・クエリー言語（Continuous Query Language：以下ＣＱＬ）をあげることができる。

ストリームデータ処理システムに障害が発生した場合、サーバ装置の揮発メモリに格納されているデータが消失する可能性がある。そのため、ストリームデータ処理システムの障害復旧においては、この揮発メモリに格納されているデータを含めて回復する必要がある。

ストリームデータ処理システムの障害復旧の方式には、各種の方式が提案されているが、その一つとして、入力ストリームを再投入して、データ処理を再開する方式がある。この方式では、システムの障害に備えて入力ストリームをバックアップしておき、障害発生後に、入力ストリームを再投入することで、システムを復旧する。ストリームデータ処理システムの障害復旧については、非特許文献２に各種の方式が開示されている。

また、特許文献１には、ストリームデータを不揮発性メモリにアーカイブしておき、ストリームデータ処理の高信頼化を図る手法が開示されている。

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

Ｒ．Ｍｏｔｗａｎｉ，Ｊ．Ｗｉｄｏｍ，Ａ．Ａｒａｓｕ，Ｂ．Ｂａｂｃｏｃｋ，Ｓ．Ｂａｂｕ，Ｍ．Ｄａｔａｒ，Ｇ．Ｍａｎｋｕ，Ｃ．Ｏｌｓｔｏｎ，Ｊ．Ｒｏｓｅｎｓｔｅｉｎ ａｎｄ Ｒ．Ｖａｒｍａ著："Ｑｕｅｒｙ Ｐｒｏｃｅｓｓｉｎｇ， Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ，ａｎｄ Ａｐｐｒｏｘｉｍａｔｉｏｎ ｉｎ ａ Ｄａｔａ ＳＴＲＥＡＭ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ"（ＣＩＤＲ２００３） Ｊｅｏｎｇ-Ｈｙｏｎ Ｈｗａｎｇ、Ｍａｇｄａｌｅｎａ Ｂａｌａｚｉｎｓｋａ、Ａｌｅｘａｎｄｅｒ Ｒａｓｉｎ、Ｕｇｕｒ Ｃｅｔｉｎｔｅｍｅｌ、Ｍｉｃｈａｅｌ Ｓｔｏｎｅｂｒａｋｅｒ、Ｓｔａｎ Ｚｄｏｎｉｋ、"Ｈｉｇｈ-Ａｖａｉｌａｂｉｌｉｔｙ Ａｌｇｏｒｉｔｈｍｓ ｆｏｒ Ｄｉｓｔｒｉｂｕｔｅｄ ＳＴＲＥＡＭ Ｐｒｏｃｅｓｓｉｎｇ"（ＩＣＤＥ２００５）

ストリームデータ処理システムの障害復旧においては、障害が発生しなければ出力されたタプルが、障害により出力されなくなる出力タプルの欠落、が発生しないことが望ましい。

入力ストリームを再投入して、データ処理を再開する方式では、再投入する入力ストリームが少ないと、出力タプルの欠落が発生する可能性がある。そこで、出力タプルの欠落を回避するには、十分な量の入力ストリームを再投入する必要があるが、これまで、出力タプルの欠落を回避するために必要な、入力ストリームの再投入の量を決定する方法ついて開示をしたものはなかった。

本発明の目的は、ストリームデータ処理システムの障害復旧において、出力タプルの欠落を防止することが可能なストリームデータ処理システム、計算機、及び処理方法を提供することである。

また、本発明の他の目的は、入力ストリームを再投入して、データ処理を再開する場合に、出力タプルの欠落の回避に必要な、入力ストリームの再投入の量を適宜決定するストリームデータ処理システム、計算機、及び処理方法を提供することにある。

上記の目的を達成するため、本発明においては、タイムスタンプが付与されたストリームデータであるタプルを処理するストリームデータ処理システムを、第１のタプルを受信するストリームデータ受信部と、受信した第１のタプルに対するデータ処理を実行して第２のタプルを生成するクエリ実行部と、このクエリ実行部によって生成した第２のタプルを送信するストリームデータ送信部と、第２のタプルの生成に用いられた第１のタプルのうち最古のタプル、又はそれ以前のタプルを特定する情報であるストリームデータ処理システムの回復ポイントを決定する回復ポイント管理部を備えた構成とする。

また、上記の目的を達成するため、本発明においては、クエリ実行部は、生成した第２のタプルに対して、第２のタプルの生成に用いられた第１のタプルのうち最古のタプル、又はそれ以前のタプルを特定する情報であるタプルの回復ポイントの属性値を付与し、回復ポイント管理部は、ストリームデータ処理システムが管理する全てのタプルの回復ポイントの属性値から最古のものを検索してシステムの回復ポイントを決定する構成とする。

本願明細書で開示される発明のうち、代表的な発明の概要は以下の通りである。

ストリームデータ処理システムが管理しているタプルの生成に用いられたタプルのうち、最古のタプル、あるいは、それ以前のタプル、を特定する情報であるストリームデータ処理システムの回復ポイントを決定する回復ポイント管理部、を設ける。

また、タプルに対して、該タプルの生成に用いられたタプルのうち、最古のタプル、あるいは、それ以前のタプル、を特定する情報であるタプルの回復ポイントの属性値を付与し、回復ポイント管理部は、全てのタプルの回復ポイントから、最古の回復ポイントを検索し、上述のストリームデータ処理システムの回復ポイントを決定する。

さらに、クエリ実行部に対して、クエリ実行部がデータ処理の対象とするタプルの回復ポイントのうち、最古の回復ポイントのタプル、あるいは、それ以前のタプルを特定する情報であるクエリ実行部の回復ポイントの属性値を付与し、クエリ実行部は、生成する第２のタプルの回復ポイントとして、上述のクエリ実行部の回復ポイントの属性値を設定し、回復ポイント管理部は、全てのクエリ実行部の回復ポイントから、最も古い回復ポイントを検索し、上述のストリームデータ処理システムの回復ポイントを決定する。

本発明を用いることにより、ストリームデータ処理システムにおいて、出力タプルの欠落を回避でき、データ処理の信頼性の向上を図ることができる。

第１の実施例のストリームデータ処理システムの構成を示す図である。 ストリームデータ処理システムに登録する情報を説明する図である。 ストリームデータ処理システムに登録する情報を説明する図である。 ストリームデータ処理システムに登録する情報を説明する図である。 ストリームデータ処理システムの動作を説明する図である。 ストリームデータ処理システムの動作を説明する図である。 ストリームデータ処理システムの動作を説明する図である。 第１の実施例のシステムの動作を説明する図である。 第１の実施例のシステムの動作を説明する図である。 第１の実施例のシステムの動作を説明する図である。 第１の実施例のシステムの動作を説明する図である。 第１の実施例に係わる、データ管理部の動作を示すフローチャートである。 第１の実施例に係わる、バックアップ制御部の動作を示すフローチャート図である。 第１の実施例に係わる、ストリームバックアップファイルの格納内容を例示する図である。 第１の実施例に係わる、制御部の動作を示すフローチャート図である。 第１の実施例に係わる、クエリ実行部の動作を示すフローチャート図である。 第１の実施例に係わる、タプル管理テーブルの格納内容を例示する図である。 第１の実施例に係わる、クエリ回復ポイント管理テーブルの格納内容を例示する図である。 第１の実施例に係わる、回復ポイント管理部の動作を示すフローチャート図である。 第１の実施例に係わる、クエリ実行部の動作を示すフローチャート図である。 第１の実施例に係わる、回復ポイント受信部の動作を示すフローチャート図である。 第１の実施例に係わる、バックアップ制御部の動作を示すフローチャート図である。 第１の実施例に係わる、ハートビート送信部の動作を示すフローチャート図である。 第１の実施例に係わる、データ管理部の動作を示すフローチャート図である。 第２の実施例に係わる、ストリームデータ処理を２台の計算機で２重化する場合のシステム構成図である。 第２の実施例に係わる、ストリームデータ処理を２台の計算機で２重化する場合のストリームデータ処理システムの一具体例を示す図である。 第２の実施例に係わる、判断部の動作を示すフローチャート図である。 第１の実施例に係わる、チェックポイントファイルの格納内容を例示する図である。 第２の実施例に係わる、ステータスファイルの格納内容を例示する図である。 第２の実施例に係わる、回復ポイント管理テーブルの格納内容を例示する図である。 第１の実施例に係わる、出力先設定ファイルの格納内容を例示する図である。 第３の実施例に係わる、ストリームデータ処理システムの構成を示す図である。 第３の実施例に係わる、障害復旧判断部の動作を示すフローチャート図である。 第１の実施例の変形例に係わる、回復ポイント管理部の動作を示すフローチャート図である。 第二の計算機１１１でストリームデータをバックアップする第４の実施例のシステムを示す図である。 第４の実施例に係わる、ストリームデータ送信部１０２からタプルを受信した場合の、ストリームデータ受信部１１２の動作を示すフローチャート図である。 第４の実施例に係わる、ストリームデータ受信部１１２が起動した際の、動作を示すフローチャート図である。

以下、本発明の各実施例を図面に従い説明する。なお、以下の説明にあっては、種々の実施例をストリームデータ処理システム、処理方法、処理を実行する計算機として説明するが、本発明はこれらのシステム、方法、及び計算機で実行されプログラムの発明でもある点に留意されたい。以下の説明において、特に説明をしないが、各計算機で実行されるプログラムは、計算機の記憶部に予め記憶されるか、図示説明が省略される入力装置と、適当な可搬記憶媒体を使って計算機に導入したり、ネットワークを介して適宜ダウンロードして計算機内に導入することも可能であることは言うまでもない。また、主にプログラムを称して「クエリ実行部」のように「部」を用いたが、これは「クエリ実行機能」、或いは「クエリ実行手段」等「機能」や「手段」を使って表現しても良い。

図１に、ストリームデータ処理システムの好適な第１の実現例を示す。図１のストリームデータ処理システムは、第一の計算機１００と第二の計算機１１１から構成され、第一の計算機１００と第二の計算機１１１はネットワーク１３０によって接続される。又、１３１はストリームデータソースを示している。第一の計算機の１０７、第二の計算機の１２２は共に処理部である中央処理部（Central Processing Unit：以下、ＣＰＵ）を示し、１１０、１２５は共に記憶部であるディスク装置（Ｄｉｓｋ Drive：以下、Ｄｉｓｋ）を示す。

第一の計算機の数番１０１から１０５で示す各部、および、オペレーティングシステム１０６は、第一の計算機１００のメモリに格納され、ＣＰＵ１０７によって実行されるプログラムである。上述の通り、これらのプログラムは可搬型記憶媒体や、ネットワークを介して導入することができることはいうまでもない。以下のプログラムも全て同様である。

第二の計算機の数番１１２から１２０の各部、および、オペレーティングシステム１２１は、第二の計算機１１１のメモリに格納され、ＣＰＵ１２２によって実行されるプログラムである。

第一の計算機の数番１０１から１０５の各部、および、第二の計算機の数番１１２から１２０の各部の動作の概要は以下の通りである。

データ管理部１０１は、ストリームデータソース１３１から時系列データを受信し、その時系列データをタプルとして、バックアップ制御部１０３と、ストリームデータ送信部１０２に送信するプログラムである。また、データ管理部１０１は、ハートビート受信部１０５から、第二の計算機が復旧した旨の通知を受けた場合に、チェックポイントファイル１０９から、最新の回復ポイントの情報を読み出し、その回復ポイント以降のタプルをストリームデータ送信部１０２に送信するプログラムである。なお、このストリームデータ送信部１０２をタプル送信部と呼ぶ場合がある点留意されたい。

バックアップ制御部１０３は、データ管理部１０１から受信したタプルを、ストリームバックアップファイル１０８に格納するプログラムである。また、バックアップ制御部１０３は、回復ポイント受信部１０４から、回復ポイントの情報を受信した場合に、その回復ポイント以前のタプルをストリームバックアップファイル１０８から削除するプログラムである。

ストリームデータ送信部１０２は、データ管理部１０１から受信したタプルを、第二の計算機１１１のストリームデータ受信部１１２に送信するプログラムである。

回復ポイント受信部１０４は、第二の計算機１１１の回復ポイント送信部１１５から回復ポイントの情報を受信し、その回復ポイントの情報をチェックポイントファイル１０９に格納し、回復ポイントの情報をバックアップ制御部１０３に通知するプログラムである。

ハートビート受信部１０５は、一定の時間、ハートビート送信部１１７からの通信ができない場合に、第二の計算機に障害が発生したと判断し、第二の計算機に障害が発生したと判断した後に、ハートビート送信部１１７から通信を受信した場合に、第二の計算機が復旧したと判断し、第二の計算機が復旧したことを、データ管理部１０１に通知するプログラムである
ストリームデータ受信部１１２は、ストリームデータ送信部１０２から受信したタプルを制御部１１３に送信するプログラムである。

制御部１１３は、ストリームデータ送信部１１２またはクエリ実行部１１６から受信したタプルを、クエリ実行部１１６またはストリームデータ送信部１１８に送信するプログラムである。

クエリ実行部１１６は、制御部１１３からタプルを受信し、予め設定されたデータ処理であるクエリを実行し、生成したタプルを制御部１１３に送信するプログラムである。

回復ポイント管理部１１９は、クエリ実行部１１６と通信し、ストリームデータ処理システムの回復ポイントを決定するプログラムである。

タイマ１２０は、一定の時間間隔で、回復ポイント管理部１１９と、ハートビート送信部１１７に通知をするプログラムである。

回復ポイント送信部１１５は、回復ポイント管理部１１９から受信した回復ポイントの情報を、回復ポイント受信部１０４に送信するプログラムである。

ハートビート送信部１１７は、第一の計算機のハートビート受信部１０５と通信をするプログラムである。

ストリームデータ送信部１１８は、制御部１１３から受信したタプルを送信するプログラムである。

なお、図１では二台の計算機を用いる構成図を示したが、後で他の実施例として説明するように、１０１から１０５の各部、１１２から１２０の各部を一台の計算機で動作させることも可能である。

図２、図３、図４は、第二計算機のクエリ定義ファイル１２４とクエリ管理テーブル１１４に格納される内容を例示する図である。図２は、入力ストリームのデータ形式を定義する文であり、ストリームデータ受信部１１２が受信する入力ストリームの名称が「ＳＴＯＣＫ」であり、入力ストリームのタプルが、時刻（ｔｉｍｅ＿ｓｔａｍｐ）と整数型の価格（ｐｒｉｃｅ）から構成されることを示している。

図３は、クエリＱ１を定義する文であり、クエリＱ１は、ＳＴＯＣＫストリームの４つのタプルから（ＳＴＯＣＫ［ｒｏｗｓ４］）、価格の最小値（ＭＩＮ（ＳＴＯＣＫ．ｐｒｉｃｅ））と、価格の最大値（ＭＡＸ（ＳＴＯＣＫ．ｐｒｉｃｅ））を計算して出力することを示している。

図４は、クエリＱ２を定義する文であり、クエリＱ２は、クエリＱ１から受け取った３つのタプル（Ｑ１［ｒｏｗｓ３］）から、最小値の平均値（ＡＶＧ（Ｑ１．ｍｉｎｕｍｕｍ））と、最大値の平均値（ＡＶＧ（Ｑ１．ｍａｘｉｍｕｍ））を計算することを示している。

図５、図６、図７を用いて、クエリＱ１とクエリＱ２の動作を説明する。図５は、クエリＱ１が１０時０秒から１０時３秒のタプルを管理し、クエリＱ２が１０時１秒から１０時３秒のタプルを管理している状況で、１０時４秒のタプルが新たに入力される例を示している。なお、各クエリに入力されるタプルを入力タプル、受信タプル、あるいは第１のタプルと呼び、各クエリが出力するタプルを出力タプル、生成タプル、あるいは第２のタプルと呼ぶ場合がある。クエリＱ１の出力タプルは、クエリＱ２の入力タプルとなることは言うまでもない。

さて、図６に示すように、クエリＱ１は、１０時０秒の入力タプルを破棄し、１０時１秒から１０時４秒の、４つの入力タプルの最小値（５０１）と最大値（５０４）を記載した出力タプルを生成する。

クエリＱ１が生成したタプルを受け取ったクエリＱ２は、図６に示すように、１０時1秒の入力タプルを破棄し、１０時２秒から１０時４秒の入力タプルを管理する。

さらに、図７に示すように、クエリＱ２は、１０時２秒から１０時４秒の入力タプルで、最小値の平均値（５００）と、最大値の平均値（５０３）を計算し、出力タプルを生成する。

ここで、図７の状況において、計算機２がダウンし、クエリＱ１とクエリＱ２が管理しているタプルの情報が消失するケースを想定する。

このケースにおいて、図７の第二の計算機が管理する最古のタプル（１０時１秒の入力タプル）から、入力ストリームを再投入した場合、タプルの欠落が発生する。なぜなら、図７において、クエリＱ２は、１０時０秒の入力タプルを用いて生成された１０時３秒の生成タプルを管理しており、１０時１秒のタプルから入力ストリームを再投入したのでは、クエリＱ２の１０時３秒のタプルは復旧できないからである。

以上に説明したように、ストリームデータ処理では、前段のクエリで生成された生成タプルが、後段のクエリで利用されるため、あるタプルが前段のクエリで破棄されても、そのタプルを用いて生成されたタプルが後段のクエリに残る。そのため、出力タプルの欠落を回避するには、第二の計算機が管理するタプルの生成に関与したタプルのうち、最古のタプル、あるいは、それ以前のタプルに遡って、入力ストリームを再投入する必要がある。

図８、図９、図１０を用いて、第１の実施例の概要を説明する。本実施例では、クエリ実行部１１６にクエリ実行部の回復ポイント８０１の属性を付与し、更に各タプルにタプルの回復ポイント８０２の属性を付与する。クエリ実行部の回復ポイント８０１は、該クエリ実行部がデータ処理の対象とする入力タプルの回復ポイントのうち最古のタプル、またはそれ以前のタプルを特定する情報である。また、出力タプルの回復ポイントは、該タプルの生成に用いられた入力タプルのうち最古のタプル、またはそれ以前のタプルを特定する情報である。

図８は、図９と図１０で用いるクエリの凡例を示す図である。図８に示すように、クエリを示す四角の右上に、クエリ実行部の回復ポイント８０１の属性値を表記する。また、タプルの最下段に、タプルの回復ポイントの属性値８０２を表記する。

本実施例では、クエリ実行部１１６は、生成するタプルに対して、該クエリ実行部の回復ポイント８０１を、生成するタプルの回復ポイント８０２に設定する。図９の例では、クエリＱ２が管理するタプルの回復ポイント８０２として、クエリＱ１の回復ポイント８０１（９時５５分）を設定している。

クエリ実行部１１６は、クエリ実行部の回復ポイント８０１を定期的に更新する。図１０において、クエリＱ１は、クエリ実行部の回復ポイント８０１を、９時５５分から１０時０秒に更新している。これは、クエリＱ１が管理する全てのタプルの回復ポイント８０２を検索し、そのうち最古の値を設定することで行う。また、クエリＱ２は、クエリ実行部の回復ポイント８０１を９時５０分から９時５５分に更新している。これは、クエリＱ２が管理するタプルの回復ポイント８０２を検索し、そのうち最古の値を設定することで行う。

本実施例では、クエリ実行部の回復ポイント８０１のうち、最古の回復ポイントを、ストリーム処理システムの回復ポイントとする。図１０の例では、クエリ２の回復ポイント８０１の９時５５分がストリームデータ処理システムの回復ポイントになる。

この回復ポイントは、該ストリームデータ処理システムが管理しているタプルの生成に用いられたタプルのうち、最古のタプル、あるいは、それ以前のタプル、を特定する情報である。この回復ポイントから、入力ストリームを再投入すれば、出力タプルの欠落なく、ストリームデータ処理システムを復旧できる。

以上に述べたように、本実施例では各種の回復ポイントを定期的に更新する。この定期的な更新により、タプルの回復ポイント８０２、クエリ実行部の回復ポイント８０１、および、ストリームデータ処理システムの回復ポイントが特定するタプルは、前回決定したストリームデータ処理システムの回復ポイントが特定するタプル以降のタプルに限定される。

すなわち、タプルの回復ポイント８０２は、該タプルの生成に用いられたタプルのうち最古のタプル、またはそれ以前のタプルを特定する情報であるが、前回決定したストリームデータ処理システムの回復ポイントが特定するタプルよりは新しいタプルを特定する情報である。また、クエリ実行部の回復ポイント８０１は、該クエリ実行部がデータ処理の対象とするタプルの回復ポイントのうち最古のタプル、またはそれ以前のタプルを特定する情報であるが、前回決定したストリームデータ処理システムの回復ポイントが特定するタプルよりは新しいタプルを特定する情報である。さらに、ストリームデータ処理システムの回復ポイントは、該ストリームデータ処理システムが管理しているタプルの生成に用いられたタプルのうち最古のタプル、またはそれ以前のタプルを特定する情報であるが、前回決定したストリームデータ処理システムの回復ポイントが特定するタプルよりは新しいタプルを特定する情報である。

なお、図１１に示すように、ストリームデータ処理システムでは、入力するタプルにストリームデータの識別子１１０１を付与して、複数のストリームデータを処理することも可能である。この場合、クエリ実行部の回復ポイント８０１、タプルの回復ポイント８０２、および、ストリームデータの回復ポイントは、ストリームデータの識別子ごとに管理する。

すなわち、識別子１のストリームデータと、識別子２のストリームデータを処理する場合、クエリ実行部１１６に対して、識別子１のクエリ実行部の回復ポイント８０１と、識別子２のクエリ実行部の回復ポイント８０１を付与する。また、タプルに対して、識別子１のタプルの回復ポイント８０２と、識別子２のタプルの回復ポイント８０２を付与する。そして、ストリームデータ処理システムの識別子１の回復ポイントと、ストリームデータ処理システムの識別子２の回復ポイントを管理する。

複数のストリームデータを入力する場合でも、回復ポイントの管理方法は、一つのストリームデータを入力する場合と同様である。そのため、以降では、一つのストリームデータを入力する場合を例にとり、図面を用いて本実施例の動作を説明する。

図１２は、図１の第一の計算機１００のＣＰＵ１０７で実行されるプログラムの一つであるデータ管理部１０１の動作を示すフローチャートである。データ管理部１０１は、ストリームデータソース１３１からデータを受信すると動作を開始する。ここで、ストリームデータソース１３１とは、株の売買を仲介する計算機や、小売業でのＰＯＳデータを管理する計算機であり、データ管理部１０１は、データソース１３１から、株価や商品売り上げなどの時系列データを受信する（１２０３）。データ管理部１０１は、ストリームデータソース１３１から時系列データを受信すると、その時系列データをタプルとして、バックアップ制御部１０３にと、ストリームデータ送信部１０２に送信（１２０１、１２０２）する機能を持つ。

図１３はバックアップ制御部１０３の動作を示すフローチャートである。バックアップ制御部１０３は、データ管理部１０１からタプルを受信する（１３０２）と動作を開始する。バックアップ制御部１０３は、受信したタプルをストリームバックアップファイル１０８に格納する（１３０１）。図１４は、ストリームバックアップファイル１０８に記載されるタプルの例である。図１４に示すように、ストリームバックアップファイル１０８には、時刻１４０１とデータ１４０２が時系列順に格納される。

ストリームデータ送信部１０２は、データ管理部１０１から受信したタプルをストリームデータ受信部１１２に送信する。第二の計算機１１１のストリームデータ受信部１１２は、受信したデータを制御部１１３に送信する。

図１５は、第二の計算機１１１の制御部１１３の動作を示すフローチャートである。ＣＰＵ１２２で実行されるプログラムである制御部１１３は、ストリームデータ受信部１１２、または、クエリ実行部１１６からタプルを受信する（１５０５）ことで動作を開始する。そして、最後のクエリ実行部１１６からタプルを受信したか否かを判定する（１５０１）。ここで、図３、図４に示したように、クエリ（ＱＵＥＲＹ Ｑ１、Ｑ２、・・・）には順序関係が定義されており、制御部１１３は、クエリ管理テーブル１１４を参照して、最後のクエリ実行部１１６を判別する。

判断１５０１の判断結果が「Ｎｏ」の場合、処理１５０２において、次のクエリ実行部１１６にタプルを送信する（１５０２）。処理１５０２においても、制御部１１３は、クエリ管理テーブル１１４を参照して、クエリの順序関係を判別している。

判断１５０１の判断結果が「Ｙｅｓ」の場合、タプルに付与されているタプルの回復ポイントの属性を削除し（１５０３）、ストリームデータ送信部１１８にタプルを送信する（１５０４）。

図１６は、クエリ実行部１１６の動作を示すフローチャートである。クエリ実行部１１６は、定義されたクエリごとに存在し、上述の通り予めどのクエリを実行するかが決められている。

クエリ実行部１１６は、制御部１１３から入力タプルを受信することで動作を開始する（１６０８）。そして、受信したタプルに回復ポイントの属性が付与されているか否かを判断する（１６０１）。判断１６０１の結果が「Ｎｏ」の場合、処理１６０７でタプルの回復ポイントとして、タプルの時刻を設定する（１６０７）。タプル管理テーブル１２７に受信したタプルを格納し、不要なタプルをタプル管理テーブル１２７から破棄する（１６０２）。

図１７は、タプル管理テーブル１２７に格納されるタプルの例である。タプル管理テーブル１２７には、タプルの時刻１７０１と、タプルのデータ１７０２と、タプルの回復ポイント１７０３が格納される。

ここで、クエリ実行部１１６で実行するクエリが、図３に示した、４つのタプルの最小値と最大値を算出するクエリであるとする。このケースで、１０時４秒のタプルを受信した場合、１０時０秒のタプルは不要になるため、クエリ実行部１１６は上述の通り、これを破棄し、１０時４秒のタプルを、タプル管理テーブル１２７に新たに追加する。

続いて、クエリを実行する（１６０３）。ここで、各クエリ実行部１１６には、予め、「４個のタプルの最小値と最大値を算出する」や「３つのタプルの、最小値の平均と最大値の平均を算出する」など処理内容が割り当てられており、これに従ってクエリを実行する。

そして、クエリを実行した結果生成された出力タプルがあるか否かを判断する（１６０４）。判断１６０４の結果が「Ｙｅｓ」の場合、出力タプルの回復ポイントの値として、クエリ実行部１１６自身の回復ポイントの値を設定する（１６０５）。なお、クエリ実行部の回復ポイントは、クエリ回復ポイント管理テーブル１２６に記載されている。図１８は、クエリ回復ポイント管理テーブル１２６の格納内容を例示する図である。クエリ回復ポイント管理テーブル１２６には、該当のクエリ実行部の回復ポイント１８０１がクエリ実行部１１６の数に対応するだけ格納される。クエリ実行部１１６は、クエリを実行した結果生成された出力タプルを制御部１１３に送信する（１６０６）。

図１９は、本実施例において、第二の計算機１１１のＣＰＵ１２２で実行される回復ポイント管理部１１９の動作を示すフローチャートである。回復ポイント管理部１１９は、タイマ１２０からの通知により動作を開始する（１９０６）。タイマ１２０は、５分などの予め定められた時間間隔で、回復ポイント管理部１１９に通知をするように設定されている。

回復ポイント管理部１１９は、全てのクエリ実行部１１６に対して、回復ポイントの更新を指示し（１９０１）。全てのクエリ実行部１１６からの応答を待ち合わせる（１９０２）。

図２０は、回復ポイント管理部１１９から更新指示を受けたクエリ実行部１１６の動作を示すフローチャートである。回復ポイントの更新指示を受信すると（２００４）、タプル管理テーブル１２７に格納されているタプルの回復ポイントを検索し、最古の回復ポイントを検出する（２００１）。続いて、処理２００１で検出した回復ポイントを、クエリ回復ポイント管理テーブル１２７に格納して更新し（２００２）。このクエリ実行部の回復ポイントを、回復ポイント管理部１１９に送信する（２００３）。

図１９の処理フローに戻り、回復ポイント管理部１１９は、全てのクエリ実行部１１６の回復ポイントから最古の回復ポイントを検索し、ストリーム処理システムの回復ポイントを決定する（１９０３）。続いて、ストリームデータ処理システムの回復ポイントをＤｉｓｋ１２５のチェックポイントファイル１２３に格納する（１９０４）。図２８はチェックポイントファイル１２３の格納内容を示す例である。チェックポイントファイル１２３には、ストリームデータ処理システムの回復ポイント２８０１が格納される。チェックポイントファイル１２３は上書き形式で回復ポイントが格納されるため、最近の回復ポイントの情報が格納されている。

なお、チェックポイントファイル１２３の格納領域に関しては、予め出力先設定ファイル１２８に記載されている。図３１は、出力先設定ファイル１２８の記載内容を例示する図である。図３1は、チェックポイントファイル１２３が、Ｃドライブのファイル名が「ＣｈｅｃｋＰｏｉｎｔ」であることを示している。回復ポイント管理部１１９は、出力先設定ファイル１２８から、チェックポイントファイルを特定し、該ファイルにストリームデータ処理システムの回復ポイント２８０１を格納する（１９０４）。回復ポイント管理部１１９は、処理１９０５において、ストリームデータ処理システムの回復ポイントを回復ポイント送信部１１５に送信する（１９０５）。

なお、回復ポイント管理部１１９は、以上説明した図１９のフローチャートによる動作に変え、図３４のフローチャートのように動作する変形例も考えられる。すなわち、回復ポイント管理部１１９は、タイマ１２０から通知を受信すると、全てのタプル管理テーブル１２７を調べる（３４０１）。さらに、回復ポイント管理部１１９は、全てのタプルの回復ポイントから、最古の回復ポイントを検索し、この最古の回復ポイントをストリームデータ処理システムの回復ポイントとする（３４０２）。このように、回復ポイント管理部１１９が、クエリ実行部１１６自身の回復ポイントを使用せず、全てのタプルの回復ポイントから、ストリームデータ処理システムの回復ポイントを決定することも可能である。

この場合も、図３４の処理フローに示すように、ストリームデータ処理システムの回復ポイントを受信した回復ポイント送信部１１５は、ストリームデータ処理システムの回復ポイントを回復ポイント受信部１０４に送信する（１９０５）。

図２１は、第一の計算機１００の回復ポイント受信部１０４の動作を示すフローチャートである。回復ポイント受信部１０４は、ストリームデータ処理システムの回復ポイントを受信する（２１０３）ことで動作を開始する。回復ポイント受信部１０４は、受信した回復ポイントの情報を、Ｄｉｓｋ１１０のチェックポイントファイル１０９に格納する（２１０１）。格納形式は、Ｄｉｓｋ１２５のチェックポイントファイル１２３と同様である。ストリーム処理システムの回復ポイントをバックアップ制御部１０３に送信する（２１０２）。

なお、チェックポイントファイル１２３の格納領域に関しては、予め出力先設定ファイル１２９に記載されている。図３１は、出力先設定ファイル１２９の記載内容を例示する図である。図３１は、チェックポイントファイル１２３が、Ｃドライブのファイル名が「ＣｈｅｃｋＰｏｉｎｔ」であることを示している。回復ポイント受信部１０４は、この出力先設定ファイル１２９から、チェックポイントファイルを特定し、該ファイルにストリームデータ処理システムの回復ポイント２８０１を格納する。

図２２は、ストリーム処理システムの回復ポイントを受信した場合の、バックアップ制御部１０３の動作を示すフローチャートである。バックアップ制御部１０３は、回復ポイントを受信すると（２２０２）、ストリーム処理システムの回復ポイント以前のタプルを、ストリームバックアップファイル１０８から削除する（２２０１）。

図２３は、第二の計算機１１１のハートビート送信部１１７の動作を示すフローチャートである。ハートビート送信部１１７は、タイマ１２０からの通知で動作を開始する。タイマ１２０は、１秒などの予め定められた時間間隔で、ハートビート送信部１１７に通知をするように設定されている。ハートビート送信部１１７は、タイマ１２０から通知を受信する（２３０２）と、ハートビート通知を、第一の計算機１００のハートビート受信部１０４に送信する（２３０１）。

ハートビート受信部１０５は、５秒などの予め定められた時間、ハートビート通知を受信できない場合に、第二の計算機１１１に障害が発生したと判断する。ハートビート受信部１０５は、第二の計算機１１１に障害が発生したと判断した後、ハートビート通知を受信した場合、第二の計算機１１１が復旧したと判断し、データ管理部１０１に対して、障害復旧の通知を送信する。

図２４は、第二の計算機１１１の障害復旧の通知を受信した場合のデータ管理部１０１の動作を示すフローチャートである。データ管理部１０１は、障害復旧の通知を受信する（２４０３）、チャックポイントファイル１０９から、ストリーム処理システムの回復ポイントを読み出す（２４０１）。なお、図２８に示したように、チェックポイントファイル１０９には、最近の回復ポイントが格納されており、データ管理部１０１は、この最近の回復ポイントを読み出す。

さらに、データ管理部１０１は、ストリーム処理システムの回復ポイント以降のタプルを、ストリームバックアップファイル１０８から読み込み、ストリームデータ送信部１０２に送信する（２４０２）。

以上説明した実施例１の構成により、ストリームデータ処理システムの障害復旧の際、データ処理の再開に必要な出力タプルの欠落を起こすことなく、入力ストリームの再投入を行うことができる。

図２５は、第２の実施例に係わるストリームデータ処理システム、即ち、ストリームデータ処理を二台の計算機で二重化して実行するシステムの構成図である。第一の計算機１００のストリームデータ送信部１０２は、第二の計算機１１１と第三の計算機２５０１に対して、同一のタプルを送信する。図２５において、第二の計算機１１１と第三の計算機２５０１が実行するストリームデータ処理は、図１の１１２から１２０の各部によって実行される処理をまとめて示した。

図２５に示した第２の実施例のシステムでは、第二の計算機１１１と第三の計算機２５０１のうち、一方の計算機に障害が発生しても、もう一方の計算機が正常に動作している限り、ストリームデータ処理は継続される。

図２５において、第三の計算機２５０１に障害が発生したケースを想定する。この場合、第二の計算機１１１のストリームデータ処理だけが動作する片系運転となり、システムの耐障害性が低下する。そのため、第三の計算機２５０１のストリームデータ処理を復旧する必要がある。

第三の計算機２５０１のストリームデータ処理を復旧する方法としては、ストリームデータ送信部１０２から送信されるタプルを用いてストリームデータ処理を行う方法がある。

第二の計算機１１１には障害が発生していないため、第二の計算機１１１のストリームデータ処理は、途切れなく実行されている。一方、第三の計算機２５０１には障害が発生したため、一旦、揮発メモリに格納されていたタプルの情報が消失している。そのため、第三の計算機が復旧した直後は、第二の計算機１１１が管理するタプルの情報と、第三の計算機２５０１が管理するタプルの情報は異なり、二つの計算機で実行されるストリームデータ処理の処理結果が異なる。この二つの計算機で実行されるストリームデータ処理の処理結果が異なる期間を、ウォームアップ期間と呼ぶこととする。

このウォームアップ期間において、第三の計算機２５０１のストリームデータ処理を使用すると、障害が発生しなければ出力されたタプルが障害により出力されなくなる、出力タプルの欠落が発生する。そのため、ウォームアップ期間が終了するまでは、第三の計算機２５０１のストリームデータ処理が使用できない。

以降では、ストリームデータ処理を二つの計算機で二重化して実行する第２の実施例のシステムにおいて、回復ポイントを用いて、出力タプルの欠落を回避する方法を説明する。

図２６は、ストリームデータ処理を二台の計算機で二重化して実行する第２の実施例のシステムの一具体例を示す図である。図１のシステム構成図と同一番号のブロックは、図１のブロックと同一のものを示す。第二の計算機１１１の各部の動作はこれまでに説明した動作と同一である。但し、本実施例の構成においては、回復ポイント送信部１１５は、ストリームデータ処理システムの回復ポイントに関する情報を、第三の計算機２５０１の回復ポイント受信部２６０１に送信する。

第三の計算機２５０１の各部の動作はこれまでに説明した第二の計算機１１１の動作と同一である。但し、第三の計算機２５０１には、回復ポイント受信部２６０１と開始ポイント管理部２６０２と判断部２６０３が別途に動作する。これらは、先に説明した機能ブロック同様、計算機２５０１のメモリに格納され、ＣＰＵ１２２によって実行されるプログラムである。

開始ポイント管理部２６０２は、第三の計算機に障害が発生した後、再び第三の計算機がストリームデータ処理を開始した場合、最初に受信したタプルを特定する情報である開始ポイントを開始ポイント管理テーブル２６０４に格納するプログラムである。

判断部２６０３は、回復ポイント受信部２６０１から受信した回復ポイントの情報と、回復ポイント管理部２６０２から受信した回復ポイントの情報を比較し、第三の計算機のストリームデータ処理システムが使用可能な状態になったか否かを判定するプログラムである。

第三の計算機２５０１に障害が発生した後、再び第三の計算機がストリームデータ処理を開始した場合、開始ポイント管理部２６０２は、最初に受信したタプルを特定する情報である開始ポイントを開始ポイント管理テーブル２６０４に格納する。図３０は、回復ポイント管理テーブル２６０５の格納内容を例示する図である。回復ポイント管理テーブル２６０５には、最初に受信したタプルのタイムスタンプ３００１が格納される。

回復ポイント受信部２５０１は、第二の計算機１１１から回復ポイントの情報を受信すると、その情報を判断部２６０３に通知する。

図２７は第三の計算機２５０１の実行プログラムである判断部２６０３の動作を示すフローチャートである。判断部２６０３は、回復ポイント受信部２６０１から回復ポイントの情報を受信する（２７０４）ことで動作を開始する。判断部２６０３は、開始ポイント管理部２６０２に開始ポイントを送信する指示を送信し、開始ポイント管理部２６０２から開始ポイントの情報を受信する（２７０１）。続いて、判断部２６０３は、開始ポイントと回復ポイントを比較し、開始ポイントより回復ポイントの方が新しいか否かを判断する（２７０２）。判断の結果が「Ｙｅｓ」の場合、第三の計算機２５０１のストリームデータ処理システムが使用可能な状態になったことを、Ｄｉｓｋ１２５のステータスファイル２６０４に格納する（２７０３）。

図２９は、ステータスファイル２６０４に格納する内容を例示する図である。ステータスファイル２６０４には、判断部２６０３が第三の計算機が使用可能になったと判断した時刻２９０１と、「使用可能」の文字列が格納される。

図３２は、図１のストリームデータ処理システムを一台の計算機で動作させた第３の実施例のシステムを示す図である。一台の計算機１００で動作させた場合、ネットワーク１３０、ハートビート受信部１０５、ハートビート送信部１１７は動作しないが、障害復旧判断部３２０１が動作する点で、第１の実施例と異なっている。障害復旧判断部３２０１は、メモリに格納され、ＣＰＵ１２２によって実行されるプログラムである。Ｄｉｓｋ１１０、１２５は一台のディスク装置で構成できることは言うまでもない。

図３３は、ＣＰＵ１２２で実行されるプログラムである障害復旧判断部３２０１の動作を示すフローチャートである。障害復旧判断部３２０１は、計算機１００が起動したことで、動作を開始する。障害復旧判断部３２０１は、動作を開始すると、処理３２０１において、チェックポイントファイル１０９からストリームデータ処理システムの回復ポイントを読み出す（３３０１）。次に、ストリーム処理システムの回復ポイント以降のタプルがストリームバックアップファイル１０８に格納されているか否かを判定する（３３０２）。ストリーム処理システムの回復ポイント以降のタプルがストリームバックアップファイル１０８に格納されている場合、障害復旧判断部３２０１は、データ管理部１０１に対して、障害復旧の通知をする（３３０３）。

図３５は第二の計算機１１１でストリームデータをバックアップする第４の実施例のシステムを示す図である。第二の計算機１１１でストリームデータをバックアップする場合、第二の計算機１１１のＤｉｓｋ１２５に、ストリームバックアップファイル３５０１が格納される。

第一の計算機１００では、回復ポイント受信部１０４とハートビート受信部１０５は動作しない。また、第二の計算機１１１では、ハートビート送信部１１７は動作しない。

実施例１と実施例４では、ストリームデータ受信部１１２の動作と、回復ポイント管理部１１５の動作、が異なる。以下、実施例４における、ストリームデータ受信部１１２の動作と、回復ポイント管理部１１５の動作を説明する。

図３６は、ストリームデータ送信部１０２からタプルを受信した場合の、ストリームデータ受信部１１２の動作を示すフローチャートである。ストリームデータ受信部１１２は、処理３６０２において、受信したタプルを、ストリームバックアップファイル３５０１にバックアップする。また、処理３６０３において、受信したタプルを、制御部１１３に送信する。

回復ポイント送信部１１５は、回復ポイント管理部１１９から受信した回復ポイントの情報を、ストリームデータ受信部１１２に送信する。回復ポイントの情報を受信した場合、ストリームデータ受信部１１２は、ストリームバックアップファイル３５０１から、回復ポイント以前のタプルを削除する。

図３７は、ストリームデータ受信部１１２が起動した際の、動作を示すフローチャートである。図３７の動作は、ストリームデータ受信部１１２がタプルを受信する前に行う動作である。ストリームデータ受信部１１２は、判断３７０１において、チェックポイントファイル１２３に、回復ポイントの情報が格納されているか否かを判断する。回復ポイントの情報が格納されている場合、処理３７０２において、ストリームデータバックアップファイル１２９に格納されている、回復ポイント以降のタプルを、制御部１１３に送信する。

本実施例によれば、第二の計算機だけで障害復旧ができるため、第一の計算機からバックアップしたタプルを送信する必要がなく、また計算機を結ぶネットワークに負荷をかけることもないという効果がある。

本発明は、ストリームデータを処理するデータ処理システム、特にタイムスタンプが付与されたデータであるタプルをリアルタイムに処理するデータ処理技術に有用である。

１００…計算機
１０１…データ管理部
１０２…ストリームデータ（タプル）送信部
１０３…バックアップ制御部
１０４…回復ポイント受信部
１０５…ハートビート受信部
１０６…オペレーティングシステム
１０７…ＣＰＵ
１０８…ストリームバックアップファイル
１０９…チェックポイントファイル
１１０…Ｄｉｓｋ
１１１…計算機
１１２…ストリームデータ受信部
１１３…制御部
１１４…クエリ管理テーブル
１１５…回復ポイント送信部
１１７…ハートビート送信部
１１８…ストリームデータ送信部
１１９…回復ポイント管理部
１２０…タイマ
１２１…オペレーティングシステム
１２２…ＣＰＵ
１２３…チェックポイントファイル
１２４…クエリ定義ファイル
１２５…Ｄｉｓｋ
１２６…クエリ回復ポイント管理テーブル
１２７…タプル管理テーブル
１２８…出力先設定ファイル
１２９…出力先設定ファイル
１３０…ネットワーク
１３１…ストリームデータソース。

Claims (14)

1. タイムスタンプが付与されたストリームデータであるタプルを処理するストリームデータ処理システムであって、
   第１のタプルを受信するストリームデータ受信部と、
   前記第１のタプルに対するデータ処理を実行して第２のタプルを生成するクエリ実行部と、
   前記クエリ実行部によって生成された前記第２のタプルを送信するストリームデータ送信部と、
   前記第２のタプルの生成に用いられた前記第１のタプルのうち最古のタプル、又はそれ以前のタプルを特定する情報であるシステムの回復ポイントを決定する回復ポイント管理部と、
   を備え、
   前記クエリ実行部は、生成した前記第２のタプルに対して、前記第２のタプルの生成に用いられた前記第１のタプルのうち最古のタプル、又はそれ以前のタプルを特定する情報であるタプルの回復ポイントの属性値を付与し、
   前記回復ポイント管理部は、前記システムが管理する全ての前記タプルの回復ポイントの属性値から最古の回復ポイントを検索し、前記システムの回復ポイントを決定する、
   ことを特徴とするストリームデータ処理システム。
2. 請求項１記載のストリームデータ処理システムであって、
   前記ストリームデータ受信部または前記クエリ実行部から前記タプルを受信し、前記クエリ実行部または前記ストリームデータ送信部に、受信した前記タプルを送信する制御部を更に備え、
   前記制御部は、前記ストリームデータ受信部から受信した前記第１のタプルに対して、前記第１のタプルを特定する情報を、タプルの回復ポイントの属性値として設定し、
   前記クエリ実行部は、前記クエリ実行部がデータ処理の対象とする前記タプルの回復ポイントのうち最古のタプル、又はそれ以前のタプルを特定する情報を、前記クエリ実行部の回復ポイントの属性値として設定し、生成する前記第２のタプルの回復ポイントの属性値として、前記クエリ実行部の前記回復ポイントの属性値を設定し、
   前記回復ポイント管理部は、全ての前記クエリ実行部の前記回復ポイントの属性値から、最古の回復ポイントを検索し、前記システムの回復ポイントを決定する、
   ことを特徴とするストリームデータ処理システム。
3. 請求項２記載のストリームデータ処理システムであって、
   前記回復ポイント管理部は、前記クエリ実行部に対して、前記クエリ実行部の回復ポイントの更新を指示し、
   更新指示を受けた前記クエリ実行部は、前記クエリ実行部の回復ポイントの属性値を、前記クエリ実行部が管理している前記タプルの回復ポイントのうち、最古の回復ポイントに更新し、
   前記回復ポイント管理部は、全ての前記クエリ実行部の回復ポイントから、最古の回復ポイントを検索して、前記システムの回復ポイントを決定し、決定した前記システムの回復ポイントを記憶する、
   ことを特徴とするストリームデータ処理システム。
4. 請求項２記載のストリームデータ処理システムであって、
   ネットワークを介して接続される第一の計算機と第二の計算機とを備え、
   前記第一の計算機は、
   記憶部と、
   前記第1のタプルの送信を指示するデータ管理部と、
   前記第１のタプルを送信するタプル送信部と、
   送信した前記第１のタプルを前記記憶部に格納するバックアップ制御部と、
   前記第二の計算機から回復ポイントの情報を受信する回復ポイント受信部を備え、
   前記第二の計算機は、前記ストリームデータ受信部と、前記制御部と、前記クエリ実行部と、前記回復ポイント管理部と、更に前記システムの回復ポイントの情報を前記回復ポイント受信部に送信する回復ポイント送信部を備え、
   前記回復ポイント受信部は、受信した前記回復ポイントの情報を、前記バックアップ制御部に通知し、
   前記バックアップ制御部は、受信した前記システムの回復ポイント以前のタプルを前記記憶部から消去する、
   ことを特徴とするストリームデータ処理システム。
5. 請求項４記載のストリームデータ処理システムであって、
   前記第二の計算機は、前記第一の計算機に一定の時間間隔で通信を行うハートビート送信部を備え、
   前記第一の計算機では、前記第二の計算機からの通信を受信するハートビート受信部を備え、
   前記第一の計算機の前記ハートビート受信部は、予め定められた時間、前記第一の計算機から通信を受信できない場合に、前記第二の計算機に障害が発生したと判断し、前記第二の計算機に障害が発生した後に、再び前記第二の計算機から通信を受信した場合に、前記第二の計算機が復旧したと判断し、前記第二の計算機が復旧したことを前記データ管理部に通知し、
   前記データ管理部は、前記第二の計算機が復旧したとの通知を受けた場合、最近に受信した前記システムの回復ポイントが特定するタプルから、前記第二の計算機に送信することを指示する、
   ことを特徴とするストリームデータ処理システム。
6. 請求項２記載のストリームデータ処理システムであって、
   第一の計算機を備え、
   前記第一の計算機は、
   記憶部と、
   前記第1のタプルの送信を指示するデータ管理部と、
   前記第１のタプルを前記ストリームデータ受信部に送信するストリームデータ送信部と、
   送信した前記第１のタプルを前記記憶部に格納するバックアップ制御部とを備える、
   ことを特徴とするストリームデータ処理システム。
7. 請求項２記載のストリームデータ処理システムであって、
   ネットワークを介して接続される第一の計算機と第二の計算機と第三の計算機とを備え、前記第一の計算機は、
   前記第1のタプルの送信を指示するデータ管理部と、
   前記第１のタプルを前記第二の計算機と前記第三の計算機に送信するストリームデータ送信部とを備え、
   前記第二の計算機は、前記ストリームデータ受信部と、前記制御部と、前記クエリ実行部と、前記回復ポイント管理部とを備え、更に
   前記システムの回復ポイントの情報を前記第三の計算機に送信する回復ポイント送信部を有し、
   前記第三の計算機は、前記ストリームデータ受信部と、前記制御部と、前記クエリ実行部と、前記回復ポイント管理部とを備え、更に
   前記第三の計算機は、前記第三の計算機がストリームデータ処理を開始してから、
   最初に受信した前記第1のタプルを特定する情報である開始ポイントを管理する開始ポイント管理部と、前記第二の計算機から前記回復ポイントに関する情報を受信する回復ポイント受信部と、前記第三の計算機の使用可否を判断する判断部と有し、
   前記判断部は、前記第二の計算機から受信した前記回復ポイントに関する情報と前記第1のタプルを特定する情報である開始ポイントとを比較し、当該開始ポイントより前記第二の計算機から受信した前記回復ポイントの方が新しい場合に、前記第三の計算機が使用可能な状態になったと判断する、
   ことを特徴とするストリームデータ処理システム。
8. 請求項２記載のストリームデータ処理システムであって、
   前記制御部が、前記ストリームデータ受信部から受信した前記第１のタプルに対して設定する前記タプルの回復ポイントの属性値は、前記第１のタプルのタイムスタンプである、
   ことを特徴とするストリームデータ処理システム。
9. 請求項２記載のストリームデータ処理システムであって、
   前記ストリームデータ受信部が受信する前記第１のタプルには、受信するストリームデータを識別するストリームデータ識別子が付与されており、
   前記制御部は、前記ストリームデータ受信部から受信した前記第１のタプルに対して、前記第１のタプルのタイムスタンプを前記タプルの回復ポイントの属性値として設定し、
   前記クエリ実行部は、生成する前記第２のタプルの回復ポイントとして、前記クエリ実行部の回復ポイントの属性値を前記ストリームデータ識別子ごとに設定し、
   前記回復ポイント管理部は、前記ストリームデータ識別子ごとに最古の回復ポイントを検索し、前記システムの回復ポイントを決定する、
   ことを特徴とするストリームデータ処理システム。
10. 請求項２記載のストリームデータ処理システムであって、
    ネットワークを介して接続される第一の計算機と第二の計算機とを備え、
    前記第一の計算機は、
    前記第1のタプルの送信を指示するデータ管理部と、
    前記第１のタプルを送信するタプル送信部を備え、
    前記第二の計算機は、記憶部と、前記ストリームデータ受信部と、前記制御部と、前記クエリ実行部と、前記回復ポイント管理部と、更に前記システムの回復ポイントの情報を前記ストリームデータ受信部に送信する回復ポイント送信部を備え、
    前記ストリームデータ受信部は、受信した前記第１のタプルを前記記憶部に格納し、更に前記ストリームデータ受信部は、受信した前記システムの回復ポイント以前の前記タプルを前記記憶部から消去する、
    ことを特徴とするストリームデータ処理システム。
11. タイムスタンプが付与されたデータである第１のタプルを受信し、前記第１のタプルに対するデータ処理であるクエリを実行して第２のタプルを生成する処理部を備えたストリーム処理システムのデータ処理方法であって、
    前記処理部は、前記システムが管理している前記第２のタプルの生成に用いられた前記第１のタプルのうち最古のタプル、又はそれ以前のものを特定する情報であるタプルの回復ポイントを、属性値として前記第２のタプルに付与しておき、
    前記システムが管理する全ての前記タプルの回復ポイントから、最も古い回復ポイントを検索することにより前記システムの回復ポイントを決定する、
    ことを特徴とするストリームデータ処理方法。
12. 請求項１１記載のストリームデータ処理方法であって、
    前記処理部は、
    前記処理部が実行する前記クエリに対し、前記クエリが処理の対象とする前記第２のタプルの前記回復ポイントのうち最古のタプル、又はそれ以前のタプルを特定する情報であるクエリの回復ポイントを属性値として付与し、
    前記クエリが生成する前記第２のタプルに対して、付与された前記クエリの回復ポイントを、前記タプルの回復ポイントに設定し、
    全ての前記クエリの回復ポイントから最古の回復ポイントを検索して、前記システムの回復ポイントを決定する、
    ことを特徴とするストリームデータ処理方法。
13. タイムスタンプが付与されたデータである第１のタプルを受信し、前記第１のタプルに対するデータ処理であるクエリを実行して第２のタプルを生成する処理部と記憶部とを備えたシステムの計算機であって、
    前記処理部は、
    前記第１のタプルを受信するストリームデータ受信部と、
    前記第１のタプルに対するデータ処理を実行して第２のタプルを生成するクエリ実行部と、
    前記クエリ実行部によって生成された前記第２のタプルを送信するストリームデータ送信部と、
    前記第２のタプルの生成に用いられた前記第１のタプルのうち最古のタプル、又はそれ以前のタプルを特定する情報であるシステムの回復ポイントを決定する回復ポイント管理部と、
    を備え、
    前記クエリ実行部は、生成した前記第２のタプルに対して、前記第２のタプルの生成に用いられた前記第１のタプルのうち最古のタプル、又はそれ以前のタプルを特定する情報であるタプルの回復ポイントの属性値を付与し、
    前記回復ポイント管理部は、前記システムが管理する全ての前記タプルの回復ポイントの属性値から最古の回復ポイントを検索し、前記システムの回復ポイントを決定する、
    ことを特徴とする計算機。
14. 請求項１３記載の計算機であって、
    前記処理部は、
    前記ストリームデータ受信部または前記クエリ実行部から前記タプルを受信し、前記クエリ実行部または前記ストリームデータ送信部に、受信した前記タプルを送信する制御部を更に備え、
    前記制御部は、前記ストリームデータ受信部から受信した前記第１のタプルに対して、前記第１のタプルを特定する情報を、タプルの回復ポイントの属性値として設定し、
    前記クエリ実行部は、前記クエリ実行部がデータ処理の対象とする前記タプルの回復ポイントのうち最古のタプル、又はそれ以前のタプルを特定する情報を、前記クエリ実行部の回復ポイントの属性値として設定し、生成する前記第２のタプルの回復ポイントの属性値として、前記クエリ実行部の前記回復ポイントの属性値を設定し、
    前記回復ポイント管理部は、全ての前記クエリ実行部の前記回復ポイントの属性値から、最古の回復ポイントを検索し、前記システムの回復ポイントを決定する、
    ことを特徴とする計算機。

Images