JP2012003394A - データ処理の障害回復方法、システムおよびプログラム - Google Patents

Abstract

【課題】ストリームデータ処理の障害発生後の実行状態再現において、バックアップデータ取得に必要な記憶容量を最小限にとどめた上で、全てのウィンドウ演算の利用を実現する。
【解決手段】クエリ解析部６０６は、クエリに対応するストリームデータ処理を行うオペレータ中、ウィンドウなどの実行状態を保持するオペレータと、その回復ポイントを解析する。バックアップデータ取得時に、バックアップデータ管理部６５２は、解析された回復ポイントのスナップショット取得に必要な容量を管理し、各々の回復ポイントまでの入力データのバックアップに必要な記憶領域６５５の記憶容量と、それで再現できないウィンドウに対してスナップショットを取得した場合に必要な記憶領域６５４の記憶容量を算出し、これらに必要な記憶容量の合計値が最も小さくなる回復ポイントを選択して、実行状態の記録を行う。
【選択図】図６

Description

本発明は、データ処理の障害回復技術に関し、特に、ストリームデータ処理における障害回復に必要な再現データの保存技術に関する。

自動株取引、高度な交通情報処理、多地点から得たセンサ情報の解析といった、継続的に発生する多量のデータをリアルタイムに解析し即座に対応ために、ストリームデータ処理が注目されている。ストリームデータ処理は、様々な形式のデータのリアルタイム処理に適用可能な汎用ミドルウェア技術であるため、個別案件ごとにシステムを構築するのでは間に合わないようなビジネス環境の急激な変化にも応えつつ、実世界のデータをリアルタイムにビジネスに反映することを可能とする。このストリームデータ処理の原理、実現方式は非特許文献１に開示されている。

ストリームデータ処理は、前述のように多量のデータのリアルタイム処理であるため、処理結果の出力データも多量かつ継続的に発生することになる。従って、障害が発生してから復旧までに要する時間は、可能な限り短くすることが求められる。このとき、復旧されたサーバの実行状態は初期状態であるため、障害発生前の実行状態を復旧後のサーバにも再現する、実行状態再現が必要とされている。

実行状態再現の一つ目の方法として、正常動作中から入力ストリームをバックアップしておき、復旧時にはバックアップデータを待機系サーバで再実行して現用系サーバの実行状態に追付かせる、Ｕｐｓｔｒｅａｍ Ｂａｃｋｕｐ方式が非特許文献２に開示されている。処理時間が長くなるほど、バックアップに必要なディスクやメモリなどの記憶容量は増大するが、次の理由で容量は一定以内に収まることが仮定できる。

ストリームデータ処理では、データ系列から直近の一部分を切り出すウィンドウ演算を利用することが可能である。ウィンドウ演算の定義は非特許文献３に開示されている。例えば、時間幅１分のウィンドウ演算によって切り出したデータに対して平均を算出する集約演算を適用すると、１分間の移動平均を算出する動作となる。この例においては、１分間データを流し続けるとウィンドウ内のデータが刷新されることになるため、初期状態から開始する復旧時においても直近１分間のデータを処理することで、障害発生前と同じ実行状態になる。このように、Ｕｐｓｔｒｅａｍ Ｂａｃｋｕｐ方式においては、保持しておくべきデータの範囲が処理の進行に伴って未来に進むことを前提とすることで、バックアップのための記憶容量が一定以内に収まることを仮定できる。

実行状態再現の二つ目の方法として、次のようなものが存在する。まず、運用中のサーバを定期的に一時停止して実行状態を静止化し、その実行状態を複製（スナップショット）として保存する。そして、障害が発生し、復旧した時に保存したスナップショットから実行状態を再現する。静止化してスナップショットを保存する方法は、データベースやトランザクションシステムで広く利用されている方法である。インメモリデータベースにおける静止化を利用した再現方法が、特許文献１に開示されている。

特開２００９−１５７７８５号公報

Ｂ．Ｂａｂｃｏｃｋ、Ｓ．Ｂａｂｕ、Ｍ．Ｄａｔａｒ、Ｒ．Ｍｏｔｗａｎｉ ａｎｄ Ｊ．Ｗｉｄｏｍ、"Ｍｏｄｅｌｓ ａｎｄ ｉｓｓｕｅｓ ｉｎ ｄａｔａ ｓｔｒｅａｍ ｓｙｓｔｅｍｓ"、Ｉｎ Ｐｒｏｃ． ｏｆ ＰＯＤＳ ２００２、 ｐｐ．１−１６．（２００２） Ｊ．Ｈ．Ｈｗａｎｇ、Ｍ．Ｂａｌａｚｉｎｓｋａ、Ａ．Ｒａｓｉｎ、Ｕ．Ｃｅｔｉｎｔｅｍｅｌ、Ｍ．Ｓｔｏｎｅｂｒａｋｅｒ ａｎｄ Ｓ．Ｂ．Ｚｄｏｎｉｋ、"Ｈｉｇｈ−Ａｖａｉｌａｂｉｌｉｔｙ Ａｌｇｏｒｉｔｈｍｓ ｆｏｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｔｒｅａｍ Ｐｒｏｃｅｓｓｉｎｇ"、Ｉｎ Ｐｒｏｃ． ｏｆ ＩＣＤＥ ２００５、 ｐｐ．７７９−７９０．（２００５） Ａ．Ａｒａｓｕ、Ｓ．Ｂａｂｕ ａｎｄ Ｊ． Ｗｉｄｏｍ. "Ｔｈｅ ＣＱＬ Ｃｏｎｔｉｎｕｏｕｓ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ： Sｅｍａｎｔｉｃ Ｆｏｕｎｄａｔｉｏｎｓ ａｎｄ Ｑｕｅｒｙ Ｅｘｅｃｕｔｉｏｎ"、（２００５）

前述のＵｐｓｔｒｅａｍ Ｂａｃｋｕｐ方式による実行状態再現において次のようの問題がある。ストリームデータ処理システムが処理するウィンドウ演算としては、前述の時間ウィンドウ（Ｒａｎｇｅウィンドウ）以外にも、個数ウィンドウ（Ｒｏｗｓウィンドウ）、グループ別個数ウィンドウ（Ｐａｒｔｉｔｉｏｎウィンドウ）、永続ウィンドウ（Ｕｎｂｏｕｎｄｅｄウィンドウ）などが存在する。時間ウィンドウとは異なり、これらのウィンドウでは時間の経過のみではウィンドウが刷新されない可能性がある。例えば、証券取引の分析において銘柄毎に直近１００件の出来高統計を算出する処理は、グループ別個数ウィンドウの利用により容易に定義できる。このとき、取引が低調な銘柄が存在すると、その銘柄の取引データがウィンドウに残り続けることになる。また、分析開始から全取引の集計を算出するといった処理は、永続ウィンドウを利用することで容易に定義できるが、同ウィンドウには処理開始以降の全てのデータが残り、全く刷新されない。

このようなケースにＵｐｓｔｒｅａｍ Ｂａｃｋｕｐ方式を適用すると、保持しておくべきデータ範囲の起点が進行しないため、データの保持に必要な記憶容量が際限なく増大し、いずれオーバフローすることになる。

一方で、スナップショットを利用する実行状態再現方式では、全てのウィンドウ演算を利用可能である。但し、動作中のサーバを静止化する期間、結果の出力が停止するため、アプリケーションに対して処理の停止として影響を与えてしまうことになる。実行状態に「過去数分間に送られた全データ」といった非常にサイズの大きなものが複数含まれていた場合、スナップショットの取得に非常に大きな記憶容量を必要とする。

本発明の解決すべき課題は、ストリームデータ処理の実行状態再現において、バックアップデータ取得に必要な記憶容量を最小限にとどめた上で、時間ウィンドウに限らず全てのウィンドウ演算の利用を実現することである。

すなわち、本発明の目的は、上記の課題を解決できるデータ処理障害回復方法、システムおよびプログラムを提供することにある。

上記の目的を達成するため、本発明においては、計算機を用いたストリームデータ処理の障害回復方法であって、計算機は、ストリームデータ処理を構成するオペレータ中、実行状態を保持するオペレータ各々の回復ポイントに基づき、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得しストリームデータの容量と複製データの容量の合計値が最少となる回復ポイントを算出し、算出した回復ポイントにおいてストリームデータと複製データを記録するストリームデータ処理の障害回復方法を提供する。

また、上記の目的を達成するため、本発明においては、処理部と記憶部とを備えた計算機により実行されるストリームデータ処理の障害回復システムであって、計算機の処理部は、クエリに対応するストリームデータ処理を行うオペレータ中、実行状態を保持するオペレータと、その回復ポイントを解析するクエリ解析部と、クエリ解析部が解析した、各々の回復ポイントに基づき、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得し、各回復ポイントにおける、ストリームデータの容量と複製データの容量との合計値が最少となる回復ポイントを決定するバックアップデータ管理部とを備え、決定した回復ポイントにおいてストリームデータ処理の実行状態を記憶部に記録する障害回復システムを提供する。

更に、上記の目的を達成するため、本発明においては、クエリに基づきストリームデータ処理を実行する計算機の処理部で実行される障害回復プログラムであって、処理部を、クエリに対応するストリームデータ処理を行うオペレータ中、実行状態を保持するオペレータと、その回復ポイントを解析し、解析した、各々の回復ポイントに基づき、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得し、各回復ポイントにおける、ストリームデータの容量と複製データの容量との合計値が最少となる回復ポイントを決定し、決定した回復ポイントにおいてストリームデータ処理の実行状態を記録するよう動作させる障害回復プログラムを提供する。

また更に、本発明の好適なデータ処理の障害回復方式においては、前述の課題を解決するために以下の手順で実行状態を再現する。

（１）ストリームデータ処理の中に含まれる全てのウィンドウ等の実行状態を保持するオペレータは、時間・個数・グループ別などの種類を問わず、それぞれが現在の状態を再現するために必要な最も古いデータが入力された時刻をＵｐｓｔｒｅａｍ Ｂａｃｋｕｐ方式で再現可能な回復ポイントとして管理する。

（２）全てのウィンドウ等の実行状態を保持するオペレータの回復ポイント各々について、その回復ポイントより以降の回復ポイントを持つウィンドウ等の実行状態を保持するオペレータについては、バックアップデータを保持するＵｐｓｔｒｅａｍ Ｂａｃｋｕｐ方式、その回復ポイントより前の回復ポイントを持つウィンドウ等の実行状態を保持するオペレータについては複製（スナップショット）を取得する方式で、実行状態を再現するために必要な記憶領域の大きさを計算し管理する。

（３）計算した全ての回復ポイントにおける実行状態再現に必要な記憶領域の総和の中で、容量がもっとも小さい回復ポイントを選択する。そして、その回復ポイント以降のストリームデータのバックアップデータを保持すると同時に、その回復ポイントより前の回復ポイントを持つウィンドウの複製（スナップショット）を取得する。

（４）障害回復のための実行状態再現時において、まず当該回復ポイントからデータを流し込み、その部分の処理が終わったら複製（スナップショット）のあるウィンドウはスナップショットからデータを上書きし、その後にバックアップデータ取得後のストリームの処理を始める。

本発明により、ストリームデータ処理の実行状態再現において、バックアップデータ取得に必要な記憶容量を最小限にとどめた上で、時間ウィンドウに限らず全ての実行状態を保持するオペレータが利用可能となる。より具体的には、実行状態を保持するオペレータンごとにスナップショットを取得すべきかＵｐｓｔｒｅａｍ Ｂａｃｋｕｐ方式により再現するかを比較し、より記憶領域が小さくなる方を選択することが可能となる。

第１の実施例のストリームデータ処理サーバが利用される計算機環境の構成を示す図である。 第１の実施例のストリームデータ処理サーバの構成の一例を示す図である。 第１の実施例に係る、データ処理定義の一例を示す図である。 図３に示すデータ処理定義をクエリグラフに変換した結果を示す図である。 第１の実施例に係る、図４に示すクエリグラフの例における、実行状態の例を示す図である。 第１の実施例に係る、ストリームデータ処理における実行状態記録方式の例を示す図である。 第１の実施例に係る、バックアップ要求がされた際の動作を示すフローチャートを示す図である。 第１の実施例に係る、スナップショット対象の選定がされる際の動作を示すフローチャートを示す図である。 第１の実施例に係る、バックアップデータ取得時刻における各オペレータの実行状態と記憶量、回復ポイントを例示する図である。 第１の実施例に係る、ストリームデータ処理システム起動直後からバックアップデータ取得時刻までの入力データと各オペレータの回復ポイント時のデータ量を例示する図である。 第１の実施例に係る、各オペレータの回復ポイント選択時のバックアップに必要な記憶容量の一覧を例示する図である。 第１の実施例に係る、選択された回復ポイントと入力データから実行状態を再現するオペレータとスナップショットから実行状態を再現するオペレータのリストを例示する図である。 第１の実施例に係る、再現用のバックアップデータを例示する図である。 第１の実施例に係る、再現用のバックアップデータを例示する図である。 第１の実施例に係る、ストリームデータ処理システムにより復旧要求がされた場合の動作を示すフローチャートを示す図である。 第１の実施例に係る、復旧要求時にストリームデータ処理システムの実行状態をバックアップデータから再現する動作を示すフローチャートを示す図である。 第１の実施例に係る、初期状態のストリームデータ処理システムに対して入力データのバックアップを処理させる動作を例示する図である。 第１の実施例に係る、入力データのバックアップを処理した後の実行状態を例示する図である。 第１の実施例に係る、入力データのバックアップ後にスナップショットをコピーする動作を例示する図である。 第１の実施例に係る、バックアップデータ取得におけるパラメータを設定するＧＵＩを例示する図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。また、後で説明するように、本明細書において、オペレータには、Ｓｃａｎオペレータ、フィルタオペレータ等に加え、各種のウィンドウ演算も含まるので、留意されたい。

まず、図１および図２を用いて、第１の実施例に係る、ストリームデータ処理システムの基本構成を説明する。

図１に示すように、ネットワーク１０４にストリームデータ処理サーバ１００と計算機１０１、１０２、１０３が接続されている。ストリームデータ処理サーバ１００は、ネットワーク１０４を介して、データソース１０７が動作する計算機１０２からデータ１０８を受け取り、処理結果のデータ１１０を計算機１０３上の結果利用アプリケーション１０９に送信する。また、計算機１０１上では、クエリ登録コマンド実行インタフェース１０５が動作する。

図２に示すように、ストリームデータ処理サーバ１００は、計算機２００および２１０から構成され、計算機２００および２１０は、記憶部であるメモリ２０２および２１２、処理部である中央処理部（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：ＣＰＵ）２０１および２１１、ネットワークインタフェース（Ｉｎｔｅｒｆａｃｅ：Ｉ／Ｆ）２０４および２１４、記憶部であるストレージ２０３および２１３、およびそれらを結合するバス２０５および２１５によって構成される。メモリ２０２上に、ストリームデータ処理の論理動作を定義する、ストリームデータ処理システム２０６を配置する。ストリームデータ処理システム２０６は、後で詳述するようにＣＰＵ２０１によって解釈実行可能な実行イメージである。

図２に示すように、ストリームデータ処理サーバ１００を構成する計算機２００および２１０は、ネットワークＩ／Ｆ２０４および２１４を介して外部のネットワーク１０４に接続される。

ネットワーク１０４に接続された計算機１０１上で動作する、クエリ登録コマンド実行インタフェース１０５を介して、ユーザによって定義されたクエリ１０６を、ストリームデータ処理サーバ１００を構成する計算機２００が受取ると、ストリームデータ処理システム２０６は、この定義に従ってストリームデータ処理を実行可能なクエリグラフを自身の内部に構成する。この後、ネットワーク１０４に接続された計算機１０２上で動作するデータソース１０７によって送信されるデータ１０８を、ストリームデータ処理サーバ１００を構成する計算機２００が受取ると、このクエリグラフに従って処理し、結果データ１１０を生成し、計算機１０３上で動作する結果利用アプリケーション１０９に送信する。ストレージ２０３は、ストリームデータ処理システム２０６の他、一度受取ったクエリ１０６を保存する。ストリームデータ処理システム２０６は、起動時にストレージ２０３からこの定義をロードし、クエリグラフを構成することも可能である。

計算機２１０を構成するメモリ２１２には、ストリームデータ処理システム２０６に不具合が発生した際の復旧用にバックアップ用ストレージシステム（ＢＳＳ）２１６が記憶されている。また、計算機２１０を構成するメモリ２１２およびストレージ２１３のいずれかもしくは双方は、ストリームデータ処理システム２０６に不具合が発生した際に復旧させるために必要な再現用データ２１７および２１８を保持している。

なお、ここで説明した本実施例のストリームデータ処理サーバの構成は一例であり、計算機２００と２１０は一台の計算機であって、処理部であるＣＰＵ２０１および２１１は、同一計算機上の二つのプロセッサであっても構わない。あるいは、一つのマルチコアＣＰＵにおける二つの計算コアであっても構わない。また、メモリ２０２および２１２、ネットワークＩ／Ｆ２０４および２１４、ストレージ２０３および２１３は、それぞれが一つであって、一つの計算機に接続されるのであっても、あるいは二つの計算機に接続されて共有されるのであっても構わない。本明細書において、計算機とはいずれの場合も含み、処理部、更に記憶部も同様である。

次に、図３および図４を用いて、本実施例のストリームデータ処理におけるクエリとクエリグラフの一例を説明する。

図３に示すように、クエリ３００は、２つの入力ストリームｓａおよびｓｂ、３つのクエリｑ１、ｑ２およびｑ３を定義するクエリである。

図４に示す通り、ストリームデータ処理システムは、クエリ３００の定義を受取ると、自身の実行領域中に確保したクエリ実行ワークエリア４２０上に、オペレータ４００〜４１０によって構成される、クエリグラフを生成する。このオペレータには、スキャン（Ｓｃａｎ）オペレータ４００、４０３、フィルタ（Ｆｉｌｔｅｒ）オペレータ４０２、４０５、結合オペレータ４０６、ストリーム化演算オペレータ４０７などに加え、各種のウィンドウ（Ｗｉｎｄｏｗ）４０１、４０４、４０８等も含まれる。オペレータ４００は入力ストリームｓａをデータソースから受取るＳｃａｎオペレータ、オペレータ４０３は入力ストリームｓｂをデータソースから受取るＳｃａｎオペレータである。ストリームｓａおよびｓｂは共に、文字列型のカラムｉｄと、整数型のカラムｖａlの二つのカラムから構成されるデータの系列である。

オペレータ４０１、４０２、４０４、４０５、４０６および４０７は、クエリｑ１に対応する部分クエリグラフを構成するオペレータ群である。オペレータ４０１は、ストリームｓａに対して施されるグループ別個数ウィンドウ（ＰＡＲＴＩＴＩＯＮ ＢＹ ｉｄ ＲＯＷＳ ２）であり、カラムｉｄ別に最新２個のデータを切り出す。オペレータ４０４は、ストリームｓｂに対して施される時間ウィンドウ（ＲＡＮＧＥ ５ ＭＩＮＵＴＥＳ）であり、直近５分以内のデータを切り出す。オペレータ４０２は、ウィンドウ４０１で切り出したデータに対して施されるフィルタオペレータ（ｓａ．ｖａｌ ＞ １００）であり、カラムｖａｌの値が１００より大きいデータのみを通過させる。オペレータ４０５は、ウィンドウ４０４で切り出したデータに対して施されるフィルタオペレータ（ｓｂ．ｖａｌ ＜＞ −１）であり、カラムｖａｌの値が−１以外のデータを通過させる。オペレータ４０６は、結合オペレータ（ｓａ．ｉｄ ＝ ｓｂ．ｉｄ）であり、オペレータ４０２および４０５を通過したデータにおいて、カラムｉｄが一致する組合せを生成する。オペレータ４０７は、クエリの結果を正規化するストリーム化演算である。

オペレータ４０８および４０９は、クエリｑ２に対応する部分クエリグラフを構成するオペレータ群である。オペレータ４０８は、永続ウィンドウ（ＵＮＢＯＵＮＤＥＤ）であり、クエリｑ１の結果データを全て保持する。オペレータ４０９は集約オペレータであり、カラムｉｄ別にｓａ．ｖａｌとｓｂ．ｖａｌの最大値を算出する。また、オペレータ４１０は、クエリｑ３に対応する部分クエリグラフを構成するストリーム化演算オペレータである。

一時保持領域（Ｔｅｍｐｏｒａｌ Ｓｔｏｒｅ）４１１および４１２は、それぞれ結合オペレータ４０６および集約オペレータ４０９の実行状態を保持する領域である。一時保持領域４１１は、オペレータ４０６の左入力と右入力それぞれにおける、生存中のデータを保持する。これらは、反対側の入力に到来したデータの結合相手となる。一時保持領域４１２は、グループ別に集約結果のデータを一つずつ保持する。

前述したように、一時保存領域を持つ結合オペレータ、集約オペレータ以外に、ウィンドウ演算も、実行状態を保持するオペレータである。ウィンドウ演算は、個々の入力データに対して生存期間を定義し、生存中のデータを保持する。これら以外の、フィルタオペレータ、射影オペレータ、ストリーム化演算、Ｓｃａｎオペレータ等のオペレータについては、実行状態を保持する必要はない。

次に、図５を用いて、図４のクエリグラフの例における実行状態の一例を説明する。ウィンドウ演算Ｗ１ ４０１にデータ５０１〜５０６を保持し、ウィンドウ演算Ｗ２ ４０４にデータ５１１〜５１７を保持している状態を表している。各データの長楕円はデータのタイムスタンプを表し、左側の四角はカラムｉｄの値を、右側の四角はカラムｖａｌの値を表している。グループ別ウィンドウ４０１は、カラムｉｄ別に、最大２個のデータを保持している。時間ウィンドウ４０４は、タイムスタンプが９：５５〜９：５９までのデータを保持している。

一時保持領域Ｗ３ ４１１は、左入力における生存中のデータ５０１、５０３、５０４、５０５、および右入力における生存中のデータ５１２、５１３、５１４、５１６、５１７を保持している。それぞれ、ウィンドウ演算４０１に保持しているデータ集合のうち、フィルタ条件ｓａ．ｖａｌ＞１００を満たすデータの集合、およびウィンドウ演算４０４に保持しているデータ集合のうち、フィルタ条件ｓｂ．ｖａｌ＜＞−１を満たすデータの集合である。また、結合条件がカラムｉｄに関する等号条件であるため、カラムｉｄの値をキーとして索引付けしており、カラムｉｄの値別にグループ分けして保持している。

ウィンドウ演算Ｗ４ ４０８は、一時保持領域４１１に保持する、左入力のデータ集合と右入力のデータ集合の直積において、結合条件ｓａ．ｉｄ＝ｓｂ．ｉｄを満たす組合せデータ５２１〜５３１を保持している。これらのデータのタイムスタンプは、組合せた左右データのうち遅い方のタイムスタンプをとる。ウィンドウ演算４０８は永続ウィンドウであるため、処理を開始した時刻から全てのデータを保持している。そのため、組合せデータ５２１のように非常に古いデータもウィンドウ内に存在する。

一時保持領域Ｗ５ ４１２は、ウィンドウ演算４０８に保持しているデータをカラムｉｄ別にグループ分けして集約したデータを、各グループにつき一つずつ保持している。カラムｉｄがａ、ｂおよびｃそれぞれについて、データ５４１、５４２、および５４３を保持している。ここで一時保持領域Ｗ５ ４１２には、カラムｉｄ別に各グループの平均値、最大値、最小値等を保持するよう設定することが可能である。図５の場合、一時保持領域Ｗ５ ４１２には最大値が保持されるよう設定されている。

続いて、図６を用いて本実施例のストリームデータ処理を実現するソフトウェアのブロック構成の一例を説明する。なお、同図において、太線のブロックはＣＰＵで実行される各種のソフトウェア機能を、細線のブロックはソフトウェアの実行の際、メモリ上に形成される各種のデータの保存領域を模式的に示している。

同図において、ストリームデータ処理システム２０６は、それぞれ、入力データ１０８を受信する入力データ受信部６０１、クエリグラフとオペレータの実行状態を保持するクエリ実行ワークエリア４２０、クエリ実行ワークエリア４２０のデータに基づいてクエリを実行するクエリ実行部６０２、クエリ実行結果１１０を出力する出力データ送信部６０５を備える。クエリ実行ワークエリア４２０には、それぞれ、オペレータ毎の実行状態を保持するオペレータ実行状態保持領域６２１〜６２３および各オペレータ実行状態保持領域６２１〜６２３に対して各オペレータにおいてその内部状態に使用されている最古の入力データの時刻を示す回復ポイントとそれらをスナップショットとして記録したときの記憶量を記録したオペレータ回復ポイント記憶領域６２４〜６２６を確保する。

さらに、ストリームデータ処理システム２０６は、クエリ１０６を解析してクエリ実行ワークエリア上にクエリグラフを生成するクエリ解析部６０６を備える。クエリ解析部６０６は、クエリグラフ上のオペレータ群において、実行状態のスナップショットを取得するオペレータを選定する、スナップショット対象選定部６０７を含む。スナップショット対象選定部６０７で選定したオペレータ群は、スナップショット対象リスト記憶領域６０８に記憶する。

加えて、ストリームデータ処理システム２０６は、入力データ受信部６０１で受信した入力データ１０８の複製をバックアップ用ストレージシステム２１６に送信する、もしくはバックアップ用ストレージシステム２１６から送られた復旧用の複製入力データを受信し入力データ受信部６０１に送信する複製データ通信部６０９、復旧用のデータをバックアップ用ストレージシステム２１６から送信するよう要求する復旧要求送信部６１０、バックアップ用ストレージシステム２１６から送信されたバックアップ要求を受信するバックアップ通知受信部６１１、オペレータの実行状態とスナップショット対象リストを一時的に保存するコピーバッファ領域６１２、バックアップ用ストレージシステム２１６に対しオペレータの実行状態およびスナップショット対象リストを送受信するワークエリアデータ通信部６１３を備える。

ここで、クエリ実行部６０２は、各オペレータ実行状態保持領域６２１〜６２３の保持内容をスナップショット対象リスト記憶領域６０８に従いコピーバッファ領域６１２にコピーする実行状態書出部６０３と、コピーバッファ領域６１２にある保持内容を各オペレータ実行状態保持領域６２１〜６２３の保持内容にコピーする実行状態書込部６０４を備える。

一方、バックアップ用ストレージシステム２１６はストレージデータ処理システム２０６と入力データ１０８の複製を授受する複製データ通信部６５７、ストレージデータ処理システム２０６から送られた復旧要求を受信する復旧要求受信部６５８、バックアップ処理をストレージデータ処理システム２０６に要求するバックアップ通知送信部６５９、オペレータの実行状態とスナップショット対象リストを一時的に保存するコピーバッファ領域６６０、ストレージデータ処理システム２０６に対しオペレータの実行状態およびスナップショット対象リストを送受信するワークエリアデータ通信部６６１を備える。

さらに、バックアップ用ストレージシステム２１６は複製された入力データを保存しておく入力データ記憶領域６５５、スナップショットの対象リストを記憶するスナップショット対象リスト記憶領域６５６、スナップショットを記憶するスナップショット記憶領域６５４を備える。ここで、スナップショット記憶領域６５４はオペレータ実行状態記憶領域６７１〜６７３を備える。

加えて、バックアップ用ストレージシステム２１６はバックアップデータ管理部６５２を備える。バックアップデータ管理部６５２は入力データ記憶領域６５５の容量を監視する入力データ容量管理部６５３を備える。

次に、図７、図８において、本実施例におけるバックアップ用データの更新処理フローの一例を示す。

まず、図７はバックアップ用ストレージシステム２１６からバックアップ要求を送信し、バックアップ用データがストリームデータ処理システム２０６から送信され、バックアップ用ストレージシステム２１６の保持するバックアップ用データを更新する際のフローである。

処理７００では入力データ容量管理部６５３が「入力データ容量が規定値に達した」、「前のバックアップから一定時間が経過した」、等を理由にバックアップ要求をバックアップ通知送信部６５９に送信する。続いて処理７０１ではバックアップ通知送信部６５９がバックアップ要求をストリームデータ処理システム２０６に送信する。次いで処理７０２ではバックアップ通知受信部６１１でバックアップ要求を受信したストリームデータ処理システム２０６がスナップショット対象選定部６０７で、実行状態を保持するオペレータの中から、スナップショット対象のオペレータを選定する。処理７０３でストリームデータ処理システム２０６が選定されたオペレータのスナップショットと回復ポイントデータをバックアップ用ストレージシステム２１６に送信する。最後に処理７０４ではバックアップ用ストレージシステム２１６でスナップショットを保存するとともに、送られた回復ポイント以前の複製された入力データを削除する。

続いて、図８は上述の処理７０２の詳細である。まず、処理８００、８０１、８１２、８１３でオペレータ通番Ｉが対象オペレータの数に達するまで処理８０２〜８１１の処理を繰り返す。まず処理８１６で、オペレータ通番Ｉのオペレータが実行状態を保持しているかをチェックし、保持している場合、処理８０２ではオペレータ通番Ｉの回復ポイントＩをオペレータ回復ポイント記憶領域から読み出す。続いて、処理８０３では回復ポイントＩ以降の入力データの記憶容量を、入力データ容量管理部６５３に問い合わせそれを必要記憶容量Ｉの初期値とする。

次いで、処理８０４、８０５、８１０、８１１でオペレータ通番Ｊが対象オペレータの数に達するまで処理８０６〜８０９の処理を繰り返す。まず、処理８１７では、オペレータ通番Ｊが実行状態を保持しているかをチェックし、保持している場合、処理８０６でオペレータ通番Ｊの回復ポイントＪをオペレータ回復ポイント記憶領域から読み出す。処理８０７でオペレータ通番Ｉの回復ポイントＩとオペレータ通番Ｊの回復ポイントＪを比較し、回復ポイントＩの方が回復ポイントJより現在時刻に近い場合は処理８１０に進み、そうでない場合は処理８０８に進む。処理８０８ではオペレータ通番Jを回復ポイントＩ選択時のスナップショット対象に指定する。続いて処理８０９ではオペレータ通番Ｊのスナップショットの記憶量を必要記憶量Ｉに加算する。全てのオペレータ通番Ｊに対して処理８０６〜８０９を繰り返す。そして、これを全てのオペレータ通番Ｉに対して繰り返す。

処理８１４において全てのオペレータ通番に対して最も小さい必要記憶容量を選択し、その回復ポイントＫを決定する。続いて回復ポイントＫ時のスナップショット対象を スナップショット対象リスト記憶領域６０８に記憶する。

続いて図９、図１０、図１１、図１２、図１３Ａ、図１３Ｂを用いて、本実施例におけるスナップショット対象の選定の具体的な動作例を示す。

まず、図９は、図４で示した４００〜４１２で構成されるクエリグラフ、図５で示した各オペレータの持つウィンドウの実行状態をもとに、それぞれのウィンドウの実行状態にスナップショット取得時の記憶量と回復ポイントを加えて図示したものである。図９において、記憶量はストリームデータのデータ数を示しているが、これに限定するものでなく、各データを記憶するメモリの記憶容量などであって良いことはいうまでもない。

この例では、ストリームデータ処理システムが時刻６：３０から処理を実行し、現在時刻９５０が１０：００のときにバックアップ処理を実施するものとする。このとき、ウィンドウＷ１ ４０１においてデータは５０１〜５０６の６つ存在し、最も時刻の古いデータは「時刻９：４８、ＩＤ＝ｂ、ＶＡＬ＝９７」のデータ５０２である。そのため、ウィンドウＷ１ ４０１のスナップショットに必要な記憶量９０１は６、回復ポイント９０２は９：４８となる。同様にＷ２ ４０４の記憶量９１１は６、回復ポイント９１２は９：５５、Ｗ３ ４１１の記憶量９２１は９、回復ポイント９２２は９：５０となる。Ｗ４ ４０８は永続ウィンドウであるためストリームデータ処理システムが起動してからＷ４に送られたデータすべてを記録している。

そのため、記憶量９３１は１００と大きく、回復ポイント９３２も最古のデータである５２１と合わせて６：３０と非常に前の時刻となっている。Ｗ５ ４１２ではそれぞれのＩＤの最大値を記録しているため、記憶量９４１は３と小さいが、そのＩＤ＝ｂの最大値データ５４２の由来となるデータは６：４５に入力されたデータ５２２であるため、回復ポイント９４２は５２２と同じ６：４５となる。このように各オペレータの持つウィンドウの実行状態の記憶量、回復ポイントが決められる。

続いて図１０は入力データ記憶領域６５５に記録された入力データ１０８のバックアップと、図９で示した各オペレータにおける実行状態の回復ポイント以降のデータ数を示している。

データ群ｓａ１００１はＳｃａｎ４００に入力されるデータ群でデータ５０１〜５０６およびデータ１０２０〜１０２３等から構成されている。データ群ｓｂ１００２はＳｃａｎ４３０に入力されるデータ群でデータ５１１〜５１７およびデータ１０３０〜１０３５から構成されている。これを各回復ポイントで記録する場合、Ｗ４ ４０８の回復ポイント９３２である６：３０から保存する場合、記憶するデータ数１０１０は１０００となる。同様にＷ５ ４１２の回復ポイント９４２である６：４５から保存する場合、記憶するデータ数１０１１は９００となり、Ｗ１４０１の回復ポイント９０２である９：４８の場合はデータ数１０１２が１７、Ｗ３ ４１１の回復ポイント９２２の９：５０の場合、データ数１０１３は１４、Ｗ２ ４０４の回復ポイント９１２の９：５５の場合はデータ数１０１４が９となる。

図１１ではこれらの情報を用いて処理８００〜８１３を行った結果をまとめたものを示した。Ｗ１の回復ポイント９０２である９：４８を選択した場合は、Ｗ２の回復ポイントが９：５５、Ｗ３の回復ポイントが９：５０であるため、Ｗ１、Ｗ２、Ｗ３は入力データのバックアップから実行状態を再現できる。一方、Ｗ４とＷ５の回復ポイントはＷ１より古いため、入力データのバックアップから再現できない。そこで、Ｗ４とＷ５はスナップショットが必要となる。

その結果、この場合の必要記憶容量１１０１はＷ１の回復ポイント９０２での入力データバックアップのデータ数１０１２である１７とＷ４とＷ５のスナップショットの記憶量９３１、９４１の合計である１２０となる。同様の処理をするとＷ２の回復ポイント選択時の必要記憶容量１１０２は１２７、Ｗ３の必要記憶容量１１０３は１２３、Ｗ４の必要記憶容量１１０３は１０００、Ｗ５の必要記憶容量１１０４は１０００となる。

図１２では処理８１４、８１５により必要記憶容量の最も少ないＷ１の回復ポイントが選択された時の回復ポイントとスナップショットで再現するオペレータのリストである。

このときの回復ポイント１２０１はＷ１の回復ポイントである９：４８、入力データのバックアップから再現するオペレータ１２０２はＷ１、Ｗ２、Ｗ３、スナップショットから再現するオペレータ１２０３はＷ４、Ｗ５となる。

図１３Ａ、図１３Ｂそれぞれが、本具体例における、記録される入力データのバックアップ１３００とスナップショット１３１０を示している。入力データのバックアップ１３００は回復ポイントである９：４８以降のデータ、スナップショット１３１０はＷ４とＷ５の実行状態を記録している。

続いて図１４を用いて、本実施例における、入力データのバックアップとスナップショットから初期状態のストリームデータ処理システムに実行状態を再現する手順のフローチャートを示す。

処理１４００においてストリームデータ処理システム２０６の復旧要求送信部６１０がバックアップ用ストレージシステム２１６に復旧要求を送信する。それを受けて処理１４０１においてバックアップ用ストレージシステム２１６が入力データのバックアップとスナップショットをストリームデータ処理システム２０６に送信する。処理１４０２において入力データのバックアップとスナップショットを送られたストリームデータ処理システム２０６は障害前の実行状態を復旧する。最後に処理１４０３において障害後の入力データから処理を継続する。

図１５に図１４の処理１４０２の詳細を示した。最初に処理１５００において回復ポイントからバックアップデータ取得時刻までの入力データのバックアップを初期状態のストリームデータ処理システム２０６で処理する。続いて処理１５０１〜１５０４においてスナップショットを取得しているオペレータ全てにスナップショットの実行状態をコピーする。最後にバックアップデータ取得後から障害発生直前までの入力データのバックアップをストリームデータ処理システム２０６で処理する。

図１６、図１７、図１８を用いて、図１３で取得したスナップショットから初期状態のストリームデータ処理システムに対して図１５のフローチャートに示した手順でバックアップデータ取得時の実行状態を再現する例を示す。

図１６では初期状態のストリームデータ処理システムに対し処理１５００の回復ポイントからバックアップデータ取得時までの入力データのバックアップ１３００を入力している。

図１７がその結果である。この場合、入力データのバックアップから実行状態の再現できるＷ１ ４０１、Ｗ２ ４０４、Ｗ３ ４１１の３つはバックアップデータ取得時刻１７５０である１０：００の実行状態が再現されている。一方、Ｗ４ ４０８は本来６：３０からのデータを保存していたため９：４８のデータからではデータ量が足りず、Ｗ５ ４１２は６：３０からのデータの最大値を記憶していたため、９：４８からの最大値であるデータ１７０１〜１７０３は本来のものと値が異なっている。

図１８で図１７の状態に対し処理１５０１〜１５０４を行う例を示す。入力データのバックアップ１３００から再現できないＷ４ ４０８、Ｗ５ ４１２の実行状態についてスナップショット１３１０から実行状態をコピーする。その結果、Ｗ４ ４０８、Ｗ５ ４１２を含め全てのオペレータに対し図９と同様のバックアップデータ取得時の実行状態が再現される。

この後は処理１５０５にあるようにバックアップデータ取得後の入力データのバックアップを処理すれば障害直前の実行状態が再現される。

ここまでで、スナップショットの取得の処理は一定間隔、または入力データのバックアップの容量が一定値に達した場合に自動で行われてもかまわない。

また、図１９に示すように（Ｇｒａｐｈｉｃ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ：ＧＵＩ）１９００を用いて、バックアップデータ取得化の最適化機能の使用の有無１９０１、一定間隔の時刻１９０２、バックアップデータの容量の限界値１９０３などを設定できるよう構成しても良い。なお、１０９４はユーザが、所望する任意の時間に、直ちに最適化を実行するために用いる「最適化実施」ボタンを示す。

以上の詳述した本発明の処理手順により、最小限の記憶領域でストリームデータ処理システムの実行状態を再現する手段が実現できる。

本発明は、ストリームデータ処理における障害回復技術に関し、特に、障害回復に必要な再現データの保存技術として有用である。

１００…ストリーム処理サーバ
１０１、１０２、１０３、２００、２１０…計算機
１０４…ネットワーク
２０１、２１１…ＣＰＵ
２０２、２１２…メモリ
２０３、２１３…ストレージ装置
２０４、２１４…ネットワークＩ／Ｆ
２０５、２１５…計算機内部バス
２０６…ストリームデータ処理システム
２１６…バックアップ用ストレージシステム（ＢＳＳ）
２１７、２１８…再現用バックアップデータ
４００〜４１０…オペレータ
４１１、４１２…一時保持領域
６０１…入力データ受信部
６０２…クエリ実行部
６０５…出力データ送信部
６０６…クエリ解析部
６０８、６５６…スナップショット対象リスト記憶領域
６０９、６５７…複製データ通信部
６１０…復旧要求送信部
６１１…バックアップ通知受信部
６１２、６６０…コピーバッファ領域
６１３、６６１…ワークエリアデータ通信部
６５２…バックアップデータ管理部
６５５…入力データ記憶領域
６５８…復旧要求受信部
６５９…バックアップ通知送信部
６２１、６２２、６２３…オペレータ実行状態保持領域
６２４、６２５、６２６…オペレータ回復ポイント記録領域
６７１、６７２、６７３…オペレータ実行状態記憶領域
５０１〜５０６、５１１〜５１７、５２１〜５３１、５４１〜５４３、１０２０〜１０２３、１０３０〜１０３５、１７０１〜１７０３…データ
９０１、９１１、９２１、９３１、９４１…スナップショット記憶量
９０２、９１２、９２２、９３２、９４２…回復ポイント
１３００…入力データバックアップ
１３０１…スナップショットデータ
１９００…バックアップ方式設定ＧＵＩ。

Claims (15)

1. 計算機を用いたストリームデータ処理の障害回復方法であって、
   前記計算機は、
   ストリームデータ処理を構成するオペレータ中、実行状態を保持するオペレータ各々の回復ポイントに基づき、当該回復ポイントより以降の回復ポイントを持つ前記実行状態を保持するオペレータの、最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ前記実行状態を保持するオペレータの複製データの容量を取得し、前記ストリームデータの容量と前記複製データの容量の合計値が最少となる前記回復ポイントを算出し、算出した前記回復ポイントにおいて前記ストリームデータと前記複製データを記録する、
   ことを特徴とするストリームデータ処理の障害回復方法。
2. 請求項１に記載のデータ処理の障害回復方法であって、
   前記容量の指標が前記ストリームデータのデータ数である、
   ことを特徴とするデータ処理の障害回復方法。
3. 請求項１に記載のデータ処理の障害回復方法であって、
   前記計算機は、
   前記実行状態の記録を、任意の時間に実行する、一定時間ごとに実行する、あるいは前回の記録から一定量の入力データが与えられたときに実行する、
   ことを特徴とするデータ処理の障害回復方法。
4. 請求項１に記載のデータ処理の障害回復方法であって、
   前記実行状態を保持するオペレータが、時間ウィンドウ、個数ウィンドウ、あるいは永続ウィンドウである、
   ことを特徴とするデータ処理の障害回復方法。
5. 請求項１に記載のデータ処理の障害回復方法であって、
   前記計算機は、
   障害回復のための実行状態再現時において、算出した前記回復ポイントから前記ストリームデータを流し込み、その後、前記複製データを記録した、前記実行状態を保持するオペレータに前記複製データを上書きし、その後、バックアックデータ取得後のストリームデータ処理を行う、
   ことを特徴とするデータ処理の障害回復方法。
6. 処理部と記憶部とを備えた計算機により実行されるストリームデータ処理の障害回復システムであって、
   前記計算機の処理部は、
   クエリに対応するストリームデータ処理を行うオペレータ中、実行状態を保持するオペレータと、回復ポイントを解析するクエリ解析部と、
   前記クエリ解析部が解析した、各々の前記回復ポイントに対し、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得し、前記回復ポイント各々における、前記ストリームデータの容量と、前記複製データの容量との合計値が最少となる回復ポイントを決定するバックアップデータ管理部とを備え、
   前記バックアップデータ管理部が決定した回復ポイントにおいてストリームデータ処理の実行状態を前記記憶部に記録する、
   ことを特徴とずる障害回復システム。
7. 請求項６に記載のデータ処理の障害回復システムであって、
   前記容量の指標が前記ストリームデータのデータ数である、
   ことを特徴とするデータ処理の障害回復システム。
8. 請求項６に記載のデータ処理の障害回復システムであって、
   前記処理部は、
   前記実行状態の記録を、任意の時間に実行する、一定時間ごとに実行する、あるいは前回の記録から一定量の入力データが与えられたときに実行する、
   ことを特徴とするデータ処理の障害回復システム。
9. 請求項６に記載のデータ処理の障害回復システムであって、
   前記実行状態を保持するオペレータが、時間ウィンドウ、個数ウィンドウ、あるいは永続ウィンドウである、
   ことを特徴とするデータ処理の障害回復システム。
10. 請求項６に記載のデータ処理の障害回復システムであって、
    前記処理部は、
    障害回復のための実行状態再現時において、算出した前記回復ポイントから前記ストリームデータを流し込み、その後、前記複製データを記録した、前記実行状態を保持するオペレータに前記複製データを上書きし、その後、バックアックデータ取得後のストリームデータ処理を行う、
    ことを特徴とするデータ処理の障害回復システム。
11. クエリに基づきストリームデータ処理を実行する計算機の処理部で実行されるデータ処理の障害回復プログラムであって、
    前記処理部を、
    クエリに対応するストリームデータ処理を行うオペレータ中、実行状態を保持するオペレータと、回復ポイントを解析し、
    解析した前記回復ポイント各々に対し、当該回復ポイントより以降の回復ポイントを持つ実行状態を保持するオペレータの最古の時刻からのストリームデータの容量と、当該回復ポイントより前の回復ポイントを持つ実行状態を保持するオペレータの複製データの容量を取得し、
    前記回復ポイント各々における、前記ストリームデータの容量と、前記複製データの容量との合計値が最少となる回復ポイントを決定し、
    決定した回復ポイントにおいてストリームデータ処理の実行状態を記録する、
    よう動作させる、
    ことを特徴とずるデータ処理の障害回復プログラム。
12. 請求項１１に記載のデータ処理の障害回復プログラムであって、
    前記容量の指標が前記ストリームデータのデータ数である、
    ことを特徴とするデータ処理の障害回復プログラム。
13. 請求項１１に記載のデータ処理の障害回復プログラムであって、
    前記処理部を、
    前記実行状態の記録を、任意の時間に実行する、一定時間ごとに実行する、あるいは前回の記録から一定量の入力データが与えられたときに実行させる、
    よう動作させる、
    ことを特徴とするデータ処理の障害回復プログラム。
14. 請求項１１に記載のデータ処理の障害回復プログラムであって、
    前記実行状態を保持するオペレータが、時間ウィンドウ、個数ウィンドウ、あるいは永続ウィンドウである、
    ことを特徴とするデータ処理の障害回復プログラム。
15. 請求項１１に記載のデータ処理の障害回復プログラムであって、
    前記処理部を、
    障害回復のための実行状態再現時において、算出した前記回復ポイントから前記ストリームデータを流し込み、その後、前記複製データを記録した、前記実行状態を保持するオペレータに前記複製データを上書きし、その後、バックアックデータ取得後のストリームデータ処理を行う、
    よう動作させることを特徴とするデータ処理の障害回復プログラム。

Images