特許 6021120 データをストリーム処理する方法、並びに、そのコンピュータ・システム及びコンピュータ・システム用プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6021120

(24)【登録日】2016年10月14日

(45)【発行日】2016年11月9日

(54)【発明の名称】データをストリーム処理する方法、並びに、そのコンピュータ・システム及びコンピュータ・システム用プログラム

(51)【国際特許分類】

   G06F 17/40 20060101AFI20161027BHJP

【ＦＩ】

   G06F17/40 330A

【請求項の数】20

【全頁数】44

(21)【出願番号】特願2014-197939(P2014-197939)

(22)【出願日】2014年9月29日

(65)【公開番号】特開2016-71479(P2016-71479A)

(43)【公開日】2016年5月9日

【審査請求日】2016年1月12日

【早期審査対象出願】

(73)【特許権者】

【識別番号】390009531

【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレーション

【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ

(74)【代理人】

【識別番号】100108501

【弁理士】

【氏名又は名称】上野 剛史

(74)【代理人】

【識別番号】100112690

【弁理士】

【氏名又は名称】太佐 種一

(72)【発明者】

【氏名】秋山 一人

(72)【発明者】

【氏名】荻原 博也

(72)【発明者】

【氏名】後藤 泰久

【審査官】 大野 朋也

(56)【参考文献】

【文献】 特開２００９−２６６００７（ＪＰ，Ａ）

【文献】 特開２０１１−１２８７３８（ＪＰ，Ａ）

【文献】 国際公開第２０１３／１８６８３１（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １７／４０

(57)【特許請求の範囲】

【請求項1】

データを処理する方法であって、コンピュータ・システムが、
データを受信し、当該受信したデータをリアルタイムにストリーム処理しながら、当該受信したデータ中の欠損の可能性のある部分を検出するステップと、
前記受信したデータに対応し且つ欠損のないマスター・データ得ることに応じて、当該マスター・データと前記欠損の可能性のある部分とを比較し、前記欠損が存在することに応じて、前記マスター・データを使用して前記ストリーム処理で得られた結果を更新するステップと
を実行することを含む、前記方法。

【請求項2】

前記受信したデータを前記ストリーム処理することが、１つの処理単位である１つのオペレーターを複数組み合わせて構成された第１のストリーム処理ラインにおいて実行される、請求項１に記載の方法。

【請求項3】

前記コンピュータ・システムが、
前記ストリーム処理で得られた結果を更新するために使用されるオペレーターの組み合わせを再配置して、当該更新をするために使用する第２のストリーム処理ラインを定義するステップ
をさらに実行することを含む、請求項２に記載の方法。

【請求項4】

前記ストリーム処理で得られた結果を更新するステップが、
前記マスター・データを前記第２のストリーム処理ラインに従って処理し、当該処理により得られた結果で、前記ストリーム処理で得られた結果を更新するステップ
を含む、請求項３に記載の方法。

【請求項5】

前記コンピュータ・システムが、
前記再配置されたオペレーターそれぞれを前記コンピュータ・システム上の複数のプロセッサ・ノード又は複数の仮想プロセッサ・ノード上に配置するステップ
をさらに実行することを含む、請求項３又は４に記載の方法。

【請求項6】

前記オペレーターの組み合わせの再配置が、前記欠損の可能性の確率、前記欠損の種類、前記欠損による処理結果の影響範囲、処理結果の出力の優先順位、前記オペレーターの依存関係、前記更新の為に許容される処理時間、若しくは前記更新の為に使用可能なシステム・リソース、又はそれらの組み合わせに従って決定される、請求項３〜５のいずれか一項に記載の方法。

【請求項7】

前記オペレーターの組み合わせの再配置が、前記更新の為に許容される処理時間若しくは前記更新の為に使用可能なシステム・リソース又はそれらの組み合わせに制限があることに応じて、処理結果の出力の優先順位に従って決定される、請求項３〜５のいずれか一項に記載の方法。

【請求項8】

前記受信したデータ中の欠損の可能性のある部分を検出するステップが、
前記欠損の可能性のあるデータ範囲、前記欠損の可能性の確率、前記欠損の種類、前記欠損による処理結果の影響範囲、前記処理結果の出力の優先順位、前記ストリーム処理が１つの処理単位である１つのオペレーターを複数組み合わせて構成されたストリーム処理ラインにおいて実行される場合のオペレーターの依存関係、前記オペレーターが前記ストリーム処理に要した処理時間、若しくは前記オペレーターが前記ストリーム処理に要したシステム・リソース、又はそれらの組み合わせを出力するステップ
をさらに含む、請求項１〜７のいずれか一項に記載の方法。

【請求項9】

前記データが少なくとも１つのセンサからの測定値であり、
前記受信したデータ中の欠損の可能性のある部分を検出するステップが、
前記測定値を使用して又は前記ストリーム処理によりリアルタイムに算出された集計値を使用して、前記欠損の可能性のある部分を検出するステップ
を含む、請求項１〜８のいずれか一項に記載の方法。

【請求項10】

前記データが少なくとも１つのセンサからの測定値であり、
前記受信したデータ中の欠損の可能性のある部分を検出するステップが、
各測定値の収集間隔を検出するステップ
をさらに含む、
請求項１〜８のいずれか一項に記載の方法。

【請求項11】

前記受信したデータ中の欠損の可能性のある部分を検出するステップが、
前記収集間隔の違いが検出されることに応じて、当該違いが検出された部分のデータを欠損の可能性のある部分として検出するステップ
を含む、請求項１０に記載の方法。

【請求項12】

前記ストリーム処理で得られた結果を更新するステップが、
前記ストリーム処理した結果のうち前記収集間隔の違いによる欠損から生じた結果を、前記マスター・データを処理して得られた結果で更新するステップ
を含む、請求項１１に記載の方法。

【請求項13】

前記受信したデータ中の欠損の可能性のある部分を検出するステップが、
時系列中で値が欠落していること、
値が異常値であること、
値が一定期間変わらないこと、
値の変化率が異常であること、
センサの収集間隔が違うこと、
関連する複数の属性の相関が異常であること、若しくは、
繰り返し行動から得られる値の差を比較することによって得られる値が異常であること
に応じて、又は、
欠損履歴を格納した欠損履歴データを参照して、
前記欠損の可能性のある部分を検出するステップ
を含む、請求項１〜１０のいずれか一項に記載の方法。

【請求項14】

前記ストリーム処理で得られた結果を更新するステップが、
前記欠損が存在することに応じて、当該欠損がある部分から生じた結果を更新するように、前記マスター・データを処理するステップ
を含む、請求項１〜１３のいずれか一項に記載の方法。

【請求項15】

前記ストリーム処理で得られた結果を更新するステップが、
前記更新状況を示すレポートをリアルタイムで更新するステップ
をさらに含む、
請求項１〜１３のいずれか一項に記載の方法。

【請求項16】

前記更新状況を示すレポートが、
前記更新が終了したこと、
前記欠損が存在しなかったこと、又は、
前記更新の終了予定時刻若しくは前記更新の進捗割合
を含む、請求項１５に記載の方法。

【請求項17】

前記ストリーム処理で得られた結果を更新するステップが、
前記更新の為に許容される処理時間内に、前記更新を終了することが出来ない場合には、当該更新処理を中止するステップと、
前記中止した時点で更新されなかった結果にマーク付けするステップと
をさらに含む、請求項１〜１６のいずれか一項に記載の方法。

【請求項18】

欠損データを再処理するコンピュータ・システムであって、
データを受信するデータ受信手段と、
前記受信したデータをリアルタイムにストリーム処理するストリーム処理手段と、
前記ストリーム処理中に、前記受信したデータ中の欠損の可能性のある部分を検出する欠損可能性検出手段と、
前記受信したデータに対応し且つ欠損のないマスター・データ得ることに応じて、当該マスター・データと前記欠損の可能性のある部分とを比較し、前記欠損が存在することを検証する欠損検証手段と、
前記欠損が存在することに応じて、前記マスター・データを使用して前記ストリーム処理で得られた結果を更新する更新手段と
を備えている、前記コンピュータ・システム。

【請求項19】

前記ストリーム処理手段が、前記受信したデータの前記ストリーム処理を、１つの処理単位である１つのオペレーターを複数組み合わせて構成された第１のストリーム処理ラインにおいて実行し、
前記コンピュータ・システムが、
前記ストリーム処理で得られた結果を更新するために使用されるオペレーターの組み合わせを再配置して、当該更新をするために使用する第２のストリーム処理ラインを定義するオペレーター再配置手段
をさらに備えている、請求項１８に記載のコンピュータ・システム。

【請求項20】

データを処理するコンピュータ・システム用プログラムであって、コンピュータ・システムに、請求項１〜１７のいずれか一項に記載の方法の各ステップを実行させる前記コンピュータ・システム用プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データを処理する技法に関する。特には、本発明は、データをストリーム処理する技法に関する。

【背景技術】

【0002】

近年、次々に到来する時刻順のデータ（ストリーム・データともいう）をリアルタイムに処理するデータ処理技法であるストリーム処理（ストリーム・コンピューティングともいう）が活用されるようになってきている。ストリーム処理は、リアルタイム処理とともに、大量データの高速変換処理という、従来ＥＴＬ（Extract/Transform/Load）として扱われてきた処理への活用が期待されている。この場合特に、コアあたりの処理速度が重要な指標となっている。

【0003】

ストリーム・コンピューティングの代表的な応用例は、証券市場からの取引データを分析し、判断し、自動売買を行う「アルゴリズム・トレード・システム」、監視カメラからの画像データを分析し、判断し、異常を検知する「ビデオ監視システム」、などがある。

【0004】

今日の情報ソースの多様化により、ストリーム・データの量は増加の一途を辿っている。また、現代の自動車には、ＥＣＵ（Electronic Control Unit）と呼ばれる自動車制御用コンピュータが多数搭載されており、ＥＣＵは数多くのセンサからのデータを時々刻々と収集している。

【0005】

ストリーム処理を行うためのソフトウェア・プラットフォームとして、例えば、IBM（登録商標） InfoSphere（登録商標） Streamsが利用可能である。IBM（登録商標） InfoSphere（登録商標） Streamsにおける開発環境では、ストリーム・コンピューティング用のプログラミング言語を用いてプログラムを開発する。このプログラミング言語は、ＳＰＬ（Stream Processing Language）と呼ばれ、オペレーターを組み合わせてプログラムを構成する。１つのオペレーターは１つの処理単位に相当し、プログラムは処理の流れに即して構成される。そのために、当該プログラミング言語は、直感的で分かり易く、簡潔なものとなっている（下記非特許文献１を参照）。ＳＰＬについては例えば、下記非特許文献２を参照されたい。

【0006】

下記特許文献１は、３以上の次元を有する計測情報を高精度に確率モデル化し、かつ、ストリーム処理によって確率モデルを逐次更新することを可能にする確率モデル更新システム、確率モデル更新装置、確率モデル更新方法およびプログラムを記載する（段落０００７）。

【0007】

下記特許文献２は、通信異常中に記録するデータの値を通信異常直前に取得した数値としておき、監視端末に記録したデータを通信異常復旧後に取得し、前記監視装置内のデータを修正することを特徴とするテレメータ装置を記載する（請求項２）。

【0008】

下記特許文献３は、欠損を示す属性値を持つＳＮＰサンプルデータである欠損データを除去し、上記欠損データが除去されたテンポラリアナリシスセットデータをアナリシスセットデータとして登録することを記載する（請求項１）。

【0009】

下記特許文献４は、解析すべきレコード内に存在するあるデータ項目の値が欠損値を含んでいる場合、前記データ項目の記号値として欠損値を示す記号値を追加し、前記欠損値を示す前記記号値を生成すべきルールで使用するか否かを個々のデータ項目に対して指示し、さらに前記データベースに格納されたデータを解析することにより、前記選択された複数のデータ項目間の相関を示すルールの候補を複数個生成することを特徴とするデータ分析方法を記載する（請求項１）。

【0010】

下記特許文献５は、欠損のあるセンシングデータを端末に再送させるコマンドを上記端末へ発行するデータ管理システムを記載する（請求項１）。

【0011】

下記特許文献６は、１以上のブロックのデータをオン・デマンドで復元する方法を記載する（請求項１）。

【0012】

下記特許文献７は、災害発生時に、前記転送情報取得部に格納されたストレージのコピー機能の情報から副系にバックアップされたデータの欠損有無を判断することを特徴とするディザスタリカバリ方法を記載する（請求項１）。

【0013】

下記特許文献８は、ファイルシステム要求に関連するストレージボリューム上でデータの破損を検出し、前記破損をリアルタイムで修復し、前記修復中に前記ストレージボリュームがオンラインで、アクティブなままであるようにする方法を記載する（請求項１）。

【0014】

下記特許文献９は、コントローラ部が時間保証機構を持っていればシステム全体としてプラントデータの到達確実性や高速性を保証でき、伝送帯域を効率的に活用できる監視制御装置を提供することを記載する（段落００１０）。

【0015】

下記特許文献１０は、カメラで撮像された動画像データをネットワーク上に蓄積する際、録画終了時の欠損データを修復可能とするネットワーク蓄積型ビデオカメラシステムを記載する（段落０００２）。

【0016】

下記特許文献１１は、画像データ送信中にエラーが発生しても、集中的に連続的に画像が抜けてしまうことなく、画像の抜けを分散させ、全体像を把握しやすくするデータ処理装置を記載する（段落０００５）。

【先行技術文献】

【特許文献】

【0017】

【特許文献1】特開２０１３−３７４７１号公報

【特許文献2】特開２００８−１３４６９０号公報

【特許文献3】特開２００４−２３４１０５号公報

【特許文献4】特開２０００−４００００号公報

【特許文献5】特開２０１０−７２７７６号公報

【特許文献6】特表２００８−５３９５２１号公報

【特許文献7】特開２００６−３３８０６４号公報

【特許文献8】特開２００５−３１６９８１号公報

【特許文献9】特開２００３−２９８２１号公報

【特許文献10】特開２００３−１８５２５号公報

【特許文献11】特開平１１−１５０７２９号公報

【非特許文献】

【0018】

【非特許文献1】小野寺民也 等，「ストリーム・コンピューティング時代を開く基盤ソフトウェアIBM InfoSphereTM Streams」，PROVISION Spring，日本アイ・ビー・エム株式会社，No. 65，2010年５月，＜URL:http://www-06.ibm.com/ibm/jp/provision/no65/pdf/65_article2.pdf＞から入手可能

【非特許文献2】“IBM InfoSphere Streams バージョン2.0 IBM Streams Processing Language 言語仕様”，日本アイ・ビー・エム株式会社，２０１１年７月＜URL:http://pic.dhe.ibm.com/infocenter/streams/v2r0/topic/com.ibm.swg.im.infosphere.streams.product.doc/doc/IBMInfoSphereStreams-SPLLanguageSpecification.pdf＞から入手可能

【発明の概要】

【発明が解決しようとする課題】

【0019】

従来は、大量データの処理方法として、大量データをコンピュータに一旦保存しておいて、そして分析するのが主流であった。この処理方法は、データベースを使用したストック型のデータ技術である。

【0020】

近年、時々刻々と流れてくる大量かつ多様なデータ（ストリーム・データ又はイベントとも呼ばれる）を、保存するのではなく、リアルタイムにサーバで処理するストリーム・コンピューティングが注目を浴びてきている。ストリーム・コンピューティングによって、１秒間に数万〜数百万件のデータを処理できるようになっている。ストリーム・コンピューティングは、並列処理を実現するプログラミング手法の一つであり、ストリーム・プロセッシングを用いることにより、コンピュータ・プログラマーは、チップ上の多数のコア（又は、演算の単位）や、それぞれに接続されたバスやメモリ、Ｉ／Ｏなどを別々に管理する必要が無いという恩恵を受けることが可能である。

【0021】

近年、多くのセンサやデバイスが世界中で利用されている。例えば自動車、道路、及び工場には種々のセンサが組み込まれている。これらセンサやデバイスから送信される種々のデータ（例えば、制御情報、位置情報、移動状況、温度）を逐一収集し、リアルタイムに分析して活用すること（すなわち、ストリーム処理すること）で、企業又は個人に役立つ種々の即時サービスの実現が可能である。

【0022】

そして、ストリーム・コンピューティングの実現により、現実世界に起こる多様な事象や状況の変化をリアルタイムに認識し、それらに対して迅速にアクションを起こしたり、適切なサービスを提供したりすることが可能になる。

【0023】

しかしながら、リアルタイムでデータを受信する場合に、データの一部が転送経路で欠損する場合がある。そのような場合には、リアルタイムでデータの解析をしつつ、欠損の無いデータを用いて、データを再評価する必要がある場合がある。また、そのような再評価を短時間でしかも限られたシステム・リソースで行わなければならないような場合がある。

【0024】

例えば、自動車開発において行われるテスト走行について考えてみる。

【0025】

自動車には、数多くの電子制御ユニット（Electronic Control Unit、ＥＣＵ）が搭載されており、数多くのセンサから種々のデータ（ビッグデータであり、また測定値でもある）を収集している。テスト走行では、リアルタイムで、電子制御ユニットから種々のデータを収集して、分析し、活用している。

【0026】

しかしながら、ストリーム処理を行うためにサーバ・コンピュータが、テスト走行中の自動車から種々のデータをリアルタイムでリモート・システムから受信する場合に、当該データの一部がデータ転送経路において欠損する場合がある。上記サーバ・コンピュータは、データの一部が欠損していても、当該データについてストリーム処理を行い続け、当該データをリアルタイムに分析し、テスト走行の現場にフィードバックする。

【0027】

自動車には、上記種々のデータを格納した記録媒体がある。そこで、自動車テスト走行終了後に、上記記録媒体を取り出して、又は上記記録媒体から上記種々のデータを他の記録媒体にコピーすることによって、欠損のないデータを得ることができる。

【0028】

テスト走行中に、リアルタイムで上記種々のデータの解析をし、そして分析結果（データの一部が欠損しているデータに基づく仮の結果でもある）をモニタすることは、テスト走行において例えば実際の路面状態による運転特性の取得や、車の制御（例えば、エンジン回転数又はギアの設定）やハンドリングなどの様々な運転操作をリアルタイムに指示する為に重要である。そのために、欠損のないデータが揃ってから（すなわち、テスト走行が終了してから）、当該種々のデータ処理をし始めるのでは、走行中の有効なデータ取得ができず、テスト走行中の評価が十分にできなくなる。

【0029】

また、欠損のないデータを数日又は数週間掛けて分析してもよい場合には、上記欠損のないデータの分析に数時間から十時間掛けて行ってもよい。

【0030】

しかしながら、通常は性能評価のために数時間のテスト走行を行い、その結果を受けて車の調整や設定変更、燃料補給などの作業を行った後、再度テスト走行を行うといった繰り返しを何度か行う。例えば１度目のテスト走行があり、その終了直後に車の調整作業などを行った上で２度目のテスト走行テストを行う場合において、１度目のテスト走行の結果を限られた時間で効果的に評価し次の走行で有効に利用する為には、１度目のテスト走行終了後の限られた時間（例えば、１０〜３０分程度）で、当該１度目のテスト走行の結果として上記欠損のないデータを分析する必要がある。

【0031】

そこで、本発明は、欠損を含むデータをリアルタイムにストリーム処理（例えば、集計処理）し、その後、上記ストリーム処理で得られた結果を更新する技法を提供することを目的とする。

【0032】

また、本発明は、上記欠損のないデータを受信した場合に、短時間でしかも限られたシステム・リソースで、当該リアルタイムで得られた結果を更新することを可能にする技法を提供することを目的とする。

【課題を解決するための手段】

【0033】

本発明は、データを処理する技法を提供する。当該技法は、上記データを処理する方法、並びに、上記データを処理する為のコンピュータ・システム、コンピュータ・システム用プログラム及びコンピュータ・システム用プログラム製品を包含しうる。

【0034】

（本発明に従う第１の態様）

【0035】

本発明に従う第１の態様において、データを処理する方法は、コンピュータが、
データを受信し、当該受信したデータをリアルタイムにストリーム処理しながら、当該受信したデータ中の欠損の可能性のある部分を検出するステップと、
上記受信したデータに対応し且つ欠損のないマスター・データと、上記欠損の可能性のある部分とを比較し、上記欠損が存在することに応じて、上記マスター・データを使用して上記ストリーム処理で得られた結果を更新するステップと
を実行することを含む。

【0036】

本発明の一つの実施態様において、上記受信したデータをストリーム処理することが、１つの処理単位である１つのオペレーターを複数組み合わせて構成された第１のストリーム処理ラインにおいて実行されうる。

【0037】

本発明の一つの実施態様において、上記コンピュータ・システムが、
上記ストリーム処理で得られた結果を更新するために使用されるオペレーターの組み合わせを再配置して、当該更新をするために使用する第２のストリーム処理ラインを定義するステップ
をさらに実行することを含みうる。

【0038】

本発明の一つの実施態様において、上記ストリーム処理で得られた結果を更新するステップが、
上記マスター・データを上記第２のストリーム処理ラインに従って処理し、当該処理により得られた結果で、上記ストリーム処理で得られた結果を更新するステップ
を含みうる。

【0039】

本発明の一つの実施態様において、上記コンピュータ・システムが、
上記再配置されたオペレーターそれぞれを上記コンピュータ・システム上の複数のプロセッサ・ノード又は複数の仮想プロセッサ・ノード上に配置するステップ
をさらに実行することを含みうる。

【0040】

本発明の一つの実施態様において、上記オペレーターの組み合わせの再配置が、上記欠損の可能性の確率、上記欠損の種類、上記欠損による処理結果の影響範囲、処理結果の出力の優先順位、上記オペレーターの依存関係、上記更新の為に許容される処理時間、若しくは上記更新の為に使用可能なシステム・リソース、又はそれらの組み合わせに従って決定されうる。

【0041】

本発明の一つの実施態様において、上記オペレーターの組み合わせの再配置が、上記更新の為に許容される処理時間若しくは上記更新の為に使用可能なシステム・リソース又はそれらの組み合わせに制限があることに応じて、処理結果の出力の優先順位に従って決定されうる。

【0042】

本発明の一つの実施態様において、上記受信したデータ中の欠損の可能性のある部分を検出するステップが、
上記欠損の可能性のあるデータ範囲、上記欠損の可能性の確率、上記欠損の種類、上記欠損による処理結果の影響範囲、上記処理結果の出力の優先順位、上記ストリーム処理が１つの処理単位である１つのオペレーターを複数組み合わせて構成されたストリーム処理ラインにおいて実行される場合のオペレーターの依存関係、上記オペレーターが上記ストリーム処理に要した処理時間、若しくは上記オペレーターが上記ストリーム処理に要したシステム・リソース、又はそれらの組み合わせを出力するステップ
をさらに含みうる。

【0043】

本発明の一つの実施態様において、上記データが少なくとも１つのセンサからの測定値であり、
上記受信したデータ中の欠損の可能性のある部分を検出するステップが、
上記測定値を使用して又は上記ストリーム処理によりリアルタイムに算出された集計値を使用して、上記欠損の可能性のある部分を検出するステップ
を含みうる。

【0044】

本発明の一つの実施態様において、上記データが少なくとも１つのセンサからの測定値であり、
上記受信したデータ中の欠損の可能性のある部分を検出するステップが、
各測定値の収集間隔を検出するステップ
をさらに含みうる。

【0045】

本発明の一つの実施態様において、上記受信したデータ中の欠損の可能性のある部分を検出するステップが、
上記収集間隔の違いが検出されることに応じて、当該違いが検出された部分のデータを欠損の可能性のある部分として検出するステップ
を含みうる。

【0046】

本発明の一つの実施態様において、上記ストリーム処理で得られた結果を更新するステップが、
上記ストリーム処理した結果のうち上記収集間隔の違いによる欠損から生じた結果を、上記マスター・データを処理して得られた結果で更新するステップ
を含みうる。

【0047】

本発明の一つの実施態様において、上記受信したデータ中の欠損の可能性のある部分を検出するステップが、
時系列中で値が欠落していること、
値が異常値であること、
値が一定期間変わらないこと、
値の変化率が異常であること、
センサの収集間隔が違うこと、
関連する複数の属性の相関が異常であること、若しくは、
繰り返し行動から得られる値の差を比較することによって得られる値が異常であること
に応じて、又は、
欠損履歴を格納した欠損履歴データを参照して、
上記欠損の可能性のある部分を検出するステップ
を含みうる。

【0048】

本発明の一つの実施態様において、上記ストリーム処理で得られた結果を更新するステップが、
上記欠損が存在することに応じて、当該欠損がある部分から生じた結果を更新するように、上記マスター・データを処理するステップ
を含みうる。

【0049】

本発明の一つの実施態様において、上記ストリーム処理で得られた結果を更新するステップが、
上記更新状況を示すレポートをリアルタイムで更新するステップ
をさらに含みうる。

【0050】

本発明の一つの実施態様において、上記更新状況を示すレポートが、
上記更新が終了したこと、
上記欠損が存在しなかったこと、又は、
上記更新の終了予定時刻若しくは上記更新の進捗割合
を含みうる。

【0051】

本発明の一つの実施態様において、上記ストリーム処理で得られた結果を更新するステップが、
上記更新の為に許容される処理時間内に、上記更新を終了することが出来ない場合には、当該更新処理を中止するステップと、
上記中止した時点で更新されなかった結果にマーク付けするステップと
をさらに含みうる。

【0052】

本発明の一つの実施態様において、上記ストリーム処理で得られた結果を更新するステップは、
上記ストリーム処理で得られた結果と上記欠損のないデータを処理して得られた結果との差分を算出して、上記ストリーム処理で得られた結果を上記算出した差分で修復するステップ
を含みうる。

【0053】

（本発明に従う第２の態様）

【0054】

本発明に従う第２の態様において、欠損データを再処理するコンピュータ・システムは、
データを受信するデータ受信手段と、
上記受信したデータをリアルタイムにストリーム処理するストリーム処理手段と、
上記ストリーム処理中に、上記受信したデータ中の欠損の可能性のある部分を検出する欠損可能性検出手段と、
上記受信したデータに対応し且つ欠損のないマスター・データと、上記欠損の可能性のある部分とを比較し、上記欠損が存在することを検証する欠損検証手段と、
上記欠損が存在することに応じて、上記マスター・データを使用して上記ストリーム処理で得られた結果を更新するストリーム処理結果更新手段と
を備えている。

【0055】

本発明の一つの実施態様において、上記ストリーム処理手段が、上記受信したデータの上記ストリーム処理を、１つの処理単位である１つのオペレーターを複数組み合わせて構成された第１のストリーム処理ラインにおいて実行しうる。

【0056】

本発明の一つの実施態様において、上記コンピュータ・システムが、
上記ストリーム処理で得られた結果を更新するために使用されるオペレーターの組み合わせを再配置して、当該更新をするために使用する第２のストリーム処理ラインを定義するオペレーター再配置手段
をさらに備えうる。

【0057】

本発明の一つの実施態様において、上記ストリーム処理結果更新手段が、上記マスター・データを上記第２のストリーム処理ラインに従って処理し、当該処理により得られた結果で、上記ストリーム処理で得られた結果を更新しうる。

【0058】

本発明の一つの実施態様において、上記コンピュータ・システムが、上記再配置されたオペレーターそれぞれを上記コンピュータ・システム上の複数のプロセッサ・ノード又は複数の仮想プロセッサ・ノード上に配置する配置手段をさらに備えうる。

【0059】

本発明の一つの実施態様において、上記オペレーター再配置手段が、上記オペレーターの組み合わせの再配置を、上記欠損の可能性の確率、上記欠損の種類、上記欠損による処理結果の影響範囲、処理結果の出力の優先順位、上記オペレーターの依存関係、上記更新の為に許容される処理時間、若しくは上記更新の為に使用可能なシステム・リソース、又はそれらの組み合わせに従って決定しうる。

【0060】

本発明の一つの実施態様において、上記オペレーター再配置手段が、上記オペレーターの組み合わせの再配置を、上記更新の為に許容される処理時間若しくは上記更新の為に使用可能なシステム・リソース又はそれらの組み合わせに制限があることに応じて、処理結果の出力の優先順位に従って決定しうる。

【0061】

本発明の一つの実施態様において、上記欠損可能性検出手段が、上記欠損の可能性のあるデータ範囲、上記欠損の可能性の確率、上記欠損の種類、上記欠損による処理結果の影響範囲、上記処理結果の出力の優先順位、若しくは上記ストリーム処理が１つの処理単位である１つのオペレーターを複数組み合わせて構成されたストリーム処理ラインにおいて実行される場合のオペレーターの依存関係、又はそれらの組み合わせをさらに出力しうる。

【0062】

本発明の一つの実施態様において、上記コンピュータ・システムがさらに、上記オペレーターが上記ストリーム処理に要した処理時間、若しくは上記オペレーターが上記ストリーム処理に要したシステム・リソース、又はそれらの組み合わせをさらに出力するストリーム処理時間算出部を備えうる。

【0063】

本発明の一つの実施態様において、上記データが少なくとも１つのセンサからの測定値であり、
上記欠損可能性検出手段が、上記測定値を使用して又は上記ストリーム処理によりリアルタイムに算出された集計値を使用して、上記欠損の可能性のある部分を検出しうる。

【0064】

本発明の一つの実施態様において、上記データが少なくとも１つのセンサからの測定値であり、
上記コンピュータ・システムがさらに、各測定値の収集間隔を検出するデータ収集間隔検出手段を備えうる。

【0065】

本発明の一つの実施態様において、上記欠損可能性検出手段が、上記各測定値の上記収集間隔の違いが検出されることに応じて、当該違いが検出された部分のデータを欠損の可能性のある部分として検出しうる。

【0066】

本発明の一つの実施態様において、上記ストリーム処理結果更新手段が、上記ストリーム処理した結果のうち上記収集間隔の違いによる欠損から生じた結果を、上記マスター・データを処理して得られた結果で更新しうる。

【0067】

本発明の一つの実施態様において、上記欠損可能性検出手段が、
時系列中で値が欠落していること、
値が異常値であること、
値が一定期間変わらないこと、
値の変化率が異常であること、
センサの収集間隔が違うこと、
関連する複数の属性の相関が異常であること、若しくは、
繰り返し行動から得られる値の差を比較することによって得られる値が異常であること
に応じて、又は、
欠損履歴を格納した欠損履歴データを参照して、
上記欠損の可能性のある部分を検出しうる。

【0068】

本発明の一つの実施態様において、上記ストリーム処理結果更新手段が、上記欠損が存在することに応じて、当該欠損がある部分から生じた結果を更新するように、上記マスター・データを処理しうる。

【0069】

本発明の一つの実施態様において、上記ストリーム処理結果更新手段がさらに、上記更新状況を示すレポートをリアルタイムで更新しうる。

【0070】

本発明の一つの実施態様において、上記更新状況を示すレポートが、
上記更新が終了したこと、
上記欠損が存在しなかったこと、又は、
上記更新の終了予定時刻若しくは上記更新の進捗割合
を含みうる。

【0071】

本発明の一つの実施態様において、上記ストリーム処理結果更新手段がさらに、上記更新の為に許容される処理時間内に、上記更新を終了することが出来ない場合には、当該更新処理を中止し、当該中止した時点で更新されなかった結果にマーク付けしうる。

【0072】

本発明の一つの実施態様において、上記ストリーム処理結果更新手段は、上記ストリーム処理で得られた結果と上記欠損のないデータを処理して得られた結果との差分を算出して、上記ストリーム処理で得られた結果を上記算出した差分で修復しうる。

【0073】

（本発明に従う第３の態様）

【0074】

本発明に従う第３の態様において、データを処理する為のコンピュータ・システム用プログラム又はコンピュータ・システム用プログラム製品は、コンピュータ・システムに、本発明に従う上記第１の態様の各ステップを実行させる。

【0075】

本発明の実施態様に従うコンピュータ・システム用プログラムは、一つ又は複数のフレキシブル・ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＤＶＤ、ＢＤ、ハードディスク装置、ＵＳＢに接続可能なメモリ媒体、ＲＯＭ、ＭＲＡＭ、ＲＡＭ等の任意のコンピュータ読み取り可能な記録媒体に格納することができる。当該コンピュータ・システム用プログラムは、上記記録媒体への格納のために、通信回線で接続する他のコンピュータ、例えばサーバ・コンピュータからダウンロードしたり、又は他の記録媒体から複製したりすることができる。また、本発明の実施態様に従うコンピュータ・システム用プログラムは、圧縮し、又は複数に分割して、単一又は複数の記録媒体に格納することもできる。また、様々な形態で、本発明の実施態様に従うコンピュータ・システム用プログラム製品を提供することも勿論可能であることにも留意されたい。本発明の実施態様に従うコンピュータ・システム用プログラム製品は、例えば、上記コンピュータ・システム用プログラムを記録した記憶媒体、又は、上記コンピュータ・システム用プログラムを伝送する伝送媒体を包含しうる。

【0076】

本発明の上記概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの構成要素のコンビネーション又はサブコンビネーションもまた、本発明となりうることに留意すべきである。

【0077】

本発明の実施態様において使用されるコンピュータの各ハードウェア構成要素を、複数のマシンと組み合わせ、それらに機能を配分し実施する等の種々の変更は当業者によって容易に想定され得ることは勿論である。それらの変更は、当然に本発明の思想に包含される概念である。ただし、これらの構成要素は例示であり、そのすべての構成要素が本発明の必須構成要素となるわけではない。

【0078】

また、本発明は、ハードウェア、ソフトウェア、又は、ハードウェア及びソフトウェアの組み合わせとして実現可能である。ハードウェアとソフトウェアとの組み合わせによる実行において、上記コンピュータ・システム用プログラムのインストールされたコンピュータ・システムにおける実行が典型的な例として挙げられる。かかる場合、当該コンピュータ・システム用プログラムが当該コンピュータ・システムのメモリにロードされて実行されることにより、当該コンピュータ・システム用プログラムは、当該コンピュータ・システムを制御し、本発明に係る処理を実行させる。当該コンピュータ・システム用プログラムは、任意の言語、コード、又は、表記によって表現可能な命令群から構成されうる。そのような命令群は、当該コンピュータ・システムが特定の機能を直接的に、又は、１．他の言語、コード若しくは表記への変換及び、２．他の媒体への複製、のいずれか一方若しくは双方が行われた後に、本発明の実施態様に従う処理を実行することを可能にするものである。

【発明の効果】

【0079】

本発明の実施態様に従いデータを処理する技法は、欠損のあるデータをリアルタイムにストリーム処理しながら、当該データ中の欠損の可能性のある部分を検出するので、上記ストリーム処理後に行われる当該ストリーム処理の結果の更新（修復処理）を限られた時間や限られたシステム・リソースにおいて実行することが可能になる。

【0080】

また、本発明の実施態様に従いデータを処理する技法は、リアルタイムにストリーム処理する際に使用するストリーム処理ラインを上記更新に適するように再配置する為に、上記ストリーム処理後に行われる当該ストリーム処理の結果の更新（修復処理）を限られた時間や限られたシステム・リソースにおいて実行することが可能になる。また、上記再配置は自動的に行われる為に、コンピュータ・プログラマーがコードを改めて書くなどの処理が不要になる。

【0081】

また、本発明の実施態様に従いデータを処理する技法は、限られた時間や限られたシステム・リソースにおいて上記更新を可能にすることから、短時間での処理や低いコストで最終処理結果の提供を受けというクライアントのニーズを満たすことが可能になる。

【図面の簡単な説明】

【0082】

【図1A】本発明の実施態様において使用されうるコンピュータ・システム又は本発明の実施態様に従うコンピュータ・システムの一例を示した図である。

【図1B】本発明の実施態様において使用されうるコンピュータ・システム又は本発明の実施態様に従うコンピュータ・システムの一例であって、当該コンピュータ・システム上で１又は複数の仮想マシンを稼働させる場合を示した図である。

【図2A】本発明の実施態様に従い、欠損の可能性のあるデータをリアルタイムにストリーム処理しながら、当該受信したデータ中の欠損の可能性のある部分を検出する処理の為のフローチャートを示す。

【図2B】図２Ａに示すフローチャートのうち、上記受信したデータのデータ収集間隔を検出するステップの処理の為のフローチャートを示す。

【図2C】図２Ａに示すフローチャートのうち、上記受信したデータ中の欠損の可能性のある部分を検出するステップの処理の為のフローチャートを示す。

【図2D】図２Ａに示すフローチャートのうち、集計結果中の欠損の可能性のある部分を検出するステップの処理の為のフローチャートを示す。

【図3A】本発明の実施態様に従い、１つの処理単位であるオペレーターの組み合わせを再配置する処理の為のフローチャートを示す。

【図3B】本発明の実施態様に従い、１つの処理単位であるオペレーターの組み合わせを再配置する処理の為のフローチャートを示す。

【図4】本発明の実施態様に従い、上記受信したデータに対応し且つ欠損のないマスター・データを使用して、上記ストリーム処理で得られた結果を更新する処理の為のフローチャートを示す。

【図5A】本発明の実施態様において使用されうる各種データ構造を示す。

【図5B】本発明の実施態様において使用されうる各種データ構造を示す。

【図5C】本発明の実施態様において使用されうる各種データ構造を示す。

【図6A】本発明の実施態様において、上記受信したデータをリアルタイムにストリーム処理する為に使用されうるストリーム処理ライン（第１のストリーム処理ライン）を示す。

【図6B】本発明の実施態様において、マスター・データを使用して、ストリーム処理で得られた結果を更新する処理する為に使用されうるストリーム処理ライン（第２のストリーム処理ライン）を示す。

【図7A】図１Ａ又は図１Ｂに従うハードウェア構成を好ましくは備えており、本発明の実施態様に従い、上記受信したデータをリアルタイムにストリーム処理しながら、当該受信したデータ中の欠損の可能性のある部分を検出する為のコンピュータ・システムの機能ブロック図の一例を示した図である。

【図7B】図１Ａ又は図１Ｂに従うハードウェア構成を好ましくは備えており、本発明の実施態様に従い、上記ストリーム処理で得られた結果を更新するために使用されるオペレーターの組み合わせを再配置して、当該更新をするために使用するストリーム処理ライン（第２のストリーム処理ライン）を定義する為のコンピュータ・システムの機能ブロック図の一例を示した図である。

【図7C】図１Ａ又は図１Ｂに従うハードウェア構成を好ましくは備えており、本発明の実施態様に従い、上記図マスター・データと、欠損の可能性のある部分とを比較し、上記欠損が存在することに応じて、上記マスター・データを使用して、上記ストリーム処理で得られた結果を更新する為のコンピュータ・システムの機能ブロック図の一例を示した図である。

【発明を実施するための形態】

【0083】

本発明の実施形態を、以下に図面に従って説明する。以下の図を通して、特に断らない限り、同一の符号は同一の対象を指す。本発明の実施形態は、本発明の好適な態様を説明するためのものであり、本発明の範囲をここで示すものに限定する意図はないことを理解されたい。

【0084】

図１Ａは、本発明の実施態様において使用されうるコンピュータ・システム又は本発明の実施態様に従うコンピュータ・システムの一例を示した図である。当該コンピュータ・システムは例えば、１又は複数のコンピュータ、例えばサーバ・コンピュータ（例えば、サーバ機能を備えているコンピュータ）でありうるが、これらに制限されるものではない。

【0085】

コンピュータ・システム（１０１）は、１又は複数のＣＰＵ（１０２）とメイン・メモリ（１０３）とを備えており、これらはバス（１０４）に接続されている。ＣＰＵ（１０２）は例えば、３２ビット又は６４ビットのアーキテクチャに基づくものである。当該ＣＰＵ（１０２）は例えば、インターナショナル・ビジネス・マシーンズ・コーポレーションのＰｏｗｅｒ（商標）シリーズ、インテル社のＸｅｏｎ（登録商標）シリーズ、Ｃｏｒｅ（商標） ｉシリーズ、Ｃｏｒｅ（商標） ２シリーズ、Ｐｅｎｔｉｕｍ（登録商標）シリーズ、Ｃｅｌｅｒｏｎ（登録商標）シリーズ若しくはＡｔｏｍ（商標）シリーズ、又は、ＡＭＤ（Advanced Micro Devices）社のＯｐｔｅｒｏｎ（商標）シリーズ、Ａシリーズ、Ｐｈｅｎｏｍ（商標）シリーズ、Ａｔｈｌｏｎ（商標）シリーズ、Ｔｕｒｉｏｎ（登録商標）シリーズ若しくはＳｅｍｐｒｏｎ（商標）でありうる。

【0086】

バス（１０４）には、ディスプレイ・コントローラ（１０５）を介して、ディスプレイ（１０６）、例えば液晶ディスプレイ（ＬＣＤ）が接続されうる。また、液晶ディスプレイ（ＬＣＤ）は例えば、タッチパネル・ディスプレイ又はフローティング・タッチ・ディスプレイであてもよい。ディスプレイ（１０６）は、コンピュータ・システム（１０１）上で動作中のソフトウェア（例えば、本発明の実施態様に従うコンピュータ・システム用プログラム又は当該コンピュータ・システム（１０１）上で動作中の任意の各種コンピュータ・システム用プログラム（例えば、任意の各種コンピュータ・システム用プログラム））が稼働することによって表示されるオブジェクトを、適当なグラフィック・インタフェースで表示するために使用されうる。また、ディスプレイ（１０６）は例えば、ウェブ・ブラウザ・アプリケーションの画面を出力しうる。

【0087】

バス（１０４）には任意的に、例えばＳＡＴＡ又はＩＤＥコントローラ（１０７）を介して、ディスク（１０８）、例えばハードディスク又はソリッド・ステート・ドライブ（ＳＳＤ）が接続されうる。

【0088】

バス（１０４）には任意的に、例えばＳＡＴＡ又はＩＤＥコントローラ（１０７）を介して、ドライブ（１０９）、例えばＣＤ、ＤＶＤ又はＢＤドライブが接続されうる。

【0089】

バス（１０４）には、周辺装置コントローラ（１１０）を介して、例えばキーボード・マウス・コントローラ又はＵＳＢバスを介して、任意的に、キーボード（１１１）及びマウス（１１２）が接続されうる。

【0090】

ディスク（１０８）には、オペレーティング・システム、例えばメインフレーム用に開発されたオペレーティング・システム（例えば、ｚ／ＯＳ、ｚ／ＶＭ、若しくはｚ／ＶＳＥ）、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）、Ｌｉｎｕｘ（登録商標）ＭａｃＯＳ（登録商標）、及びＡｎｄｒｏｉｄ（登録商標）、並びにＪ２ＥＥなどのＪａｖａ（登録商標）処理環境、Ｊａｖａ（登録商標）アプリケーション、Ｊａｖａ（登録商標）仮想マシン（ＶＭ）、Ｊａｖａ（登録商標）実行時（ＪＩＴ）コンパイラを提供するプログラム、本発明の実施態様に従うコンピュータ・システム用プログラム、及びその他の任意の各種コンピュータ・システム用プログラム、並びにデータが、メイン・メモリ（１０３）にロード可能なように記憶されうる。

【0091】

また、ディスク（１０８）には、ストリーム処理を可能にするソフトウェアが、メイン・メモリ（１０３）にロード可能なように記憶されうる。

【0092】

ディスク（１０８）は、コンピュータ・システム（１０１）内に内蔵されていてもよく、当該コンピュータ・システム（１０１）がアクセス可能なようにケーブルを介して接続されていてもよく、又は、当該コンピュータ・システム（１０１）がアクセス可能なように有線又は無線ネットワークを介して接続されていてもよい。

【0093】

ドライブ（１０９）は、必要に応じて、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又はＢＤからプログラム、例えばオペレーティング・システム、アプリケーション・プログラム又は本発明の実施態様に従うコンピュータ・システム用プログラムをディスク（１０８）にインストールするために使用されうる。

【0094】

通信インタフェース（１１４）は、例えばイーサネット（登録商標）・プロトコルに従う。通信インタフェース（１１４）は、通信コントローラ（１１３）を介してバス（１０４）に接続され、コンピュータ・システム（１０１）を通信回線（１１５）に有線又は無線接続する役割を担い、コンピュータ・システム（１０１）のオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワーク・インタフェース層を提供する。なお、通信回線は例えば、無線ＬＡＮ接続規格に基づく無線ＬＡＮ環境、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎなどのＷｉ-Ｆｉ無線ＬＡＮ環境、又は携帯電話網環境（例えば、３Ｇ、ＬＴＥ又は４Ｇ環境）でありうる。

【0095】

図１Ｂは、本発明の実施態様において使用されうるコンピュータ・システム又は本発明の実施態様に従うコンピュータ・システムの一例であって、当該コンピュータ・システム上で１又は複数の仮想マシンを稼働させる場合を示した図である。当該コンピュータ・システムは例えば、ワークステーション、ラックマウント型サーバ、ブレード型サーバ、ミッドレンジ、メインフレームなどのコンピュータ装置として構成されうる。

【0096】

図１Ｂに示すコンピュータ・システム（１２１）は、ハードウェア・リソース（１２２）として、１又は複数のＣＰＵ（１３１）、メイン・メモリ（１３２）、ストレージ（１３３）、通信コントローラ（１３４）、及び通信インタフェース（１３５）を備えうる。上記１又は複数のＣＰＵ（１３１）、メイン・メモリ（１３２）、ストレージ（１３３）、通信コントローラ（１３４）、及び通信インタフェース（１３５）並びに通信回線（１３６）はそれぞれ、図１Ａに示すコンピュータ・システム（１０１）の１又は複数のＣＰＵ（１０２）、メイン・メモリ（１０３）、ディスク（１０８）、通信コントローラ（１１３）、及び通信インタフェース（１１４）、並びに通信回線（１１５）それぞれに対応しうる。

【0097】

また、コンピュータ・システム（１２１）は、物理ホストマシンとして稼働し、また、仮想化ソフトウェア（例えば、ＶＭＷａｒｅ（登録商標）、Ｈｙｐｅｒ−Ｖ（登録商標）、Ｘｅｎ（登録商標））のハイパーバイザ（仮想化モニタ又は仮想化ＯＳとも呼ばれる）上で、同一の又は異なるＯＳ（例えば、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）、Ｌｉｎｕｘ（登録商標））をゲストＯＳ（１５６）とした１又は複数の仮想マシン１〜ｎ（１２５−１〜１２５−２）（ドメインＵ又はチャイルド・パーティションとも呼ばれる）を稼働させることが可能である。

【0098】

また、コンピュータ・システム（１２１）は、上記ハイパーバイザ上で、管理用仮想マシン（１２４）（ドメイン０又はペアレント・パーティションとも呼ばれる）を稼働させることが可能である。管理用仮想マシン（１２４）は、管理用ＯＳ（１４１）、当該管理用ＯＳ（１４１）上で動作する制御モジュール（１４２）、及び仮想リソース（１４３）を含む。制御モジュール（１４２）は、ハイパーバイザ（１２３）に対しコマンドを発行するモジュールである。また、制御モジュール（１４２）は、ハイパーバイザ（１２３）に対して、ユーザドメインの仮想マシン１〜ｎ（１２５−１〜１２５−２）の作成、及びゲストＯＳ（１５６）の起動の命令を発行し、仮想マシン１〜ｎ（１２５−１〜１２５−２）の動作を制御する。仮想リソース（１４３）は、管理用仮想マシン（１２４）の為に割り当てられたハードウェア・リソース（１２２）である。

【0099】

仮想マシン１〜ｎ（１２５−１〜１２５−２）は、仮想リソース、ゲストＯＳ（１５６）、及び、ゲストＯＳ（１５６）上で動作する種々のアプリケーション１〜ｎ（１５７−１〜１５７−３）を含む。仮想リソースは例えば、仮想ＣＰＵ（１５１）、仮想メモリ（１５２）、仮想ディスク（１５３）、仮想通信コントローラ（１５４）及び仮想通信インタフェース（１５５）を含む。

【0100】

下記図２Ａ〜図２Ｄは、本発明の実施態様に従い、データを処理する為のフローチャートを示す。

【0101】

以下において、コンピュータ・システム（１２１）と記載する場合には、図１Ｂに示すコンピュータ・システム（１２１）の代わりに、図１Ａに示すコンピュータ・システム（１０１）であってもよいことを理解されたい。

【0102】

図２Ａは、本発明の実施態様に従い、欠損の可能性のあるデータをリアルタイムにストリーム処理しながら、当該受信したデータ中の欠損の可能性のある部分を検出する処理の為のフローチャートを示す。

【0103】

ステップ２０１において、コンピュータ・システム（１２１）は、データをリアルタイムにストリーム処理することを開始する。

【0104】

ステップ２０２において、コンピュータ・システム（１２１）は、データを他のシステム（例えば、リモート・システム）から有線又は無線ネットワークを介して受信を開始する。

【0105】

上記受信するデータは、ストリーム・データでありうる。ストリーム・データは次々に到来する時刻順のデータであり、イベントとも呼ばれる。ストリーム・データは、例えばセンサからの生データでありうる。ストリーム・データはまた、ビッグデータでありうる。ストリーム・データは例えば、各種センサからのデータ、又は時々刻々と生成されうるデータでありうる。また、ストリーム・データは例えば、車、飛行機若しくは電車などの乗り物に備え付けられているコンピュータ（例えば、ＥＣＵ）からのデータ、宇宙空間にある宇宙ステーションからのデータ、宇宙から飛来する電波情報、センサやアンテナなどの計測装置からのデータ、スマート・メータ（Smart Meter）からのデータ、モノのインターネット（Internet of Things、ＩｏＴ）のデータ、交通情報データ、証券業界における取引データ、又は通話明細レコード（Call Detail Record；ＣＤＲ）でありうるが、これら具体例に限定されるものでない。

【0106】

上記受信するデータは、コンピュータ・システム（１２１）が当該データを受信したときには、既に何らかの理由（例えば、伝送経路による）によりデータの一部に欠損が生じているものである。

【0107】

ステップ２０３において、コンピュータ・システム（１２１）は、上記受信したデータをリアルタイムにストリーム処理する。

【0108】

当該処理は例えば、集計処理又は集計処理を含む処理でありうる。ストリーム処理は例えば、１つの処理単位である１つのオペレーター（演算子とも呼ばれる）を複数組み合わせて構成されたストリーム処理ライン（以下、第１のストリーム処理ラインという）において実行される。第１のストリーム処理ラインは、予めユーザによって定義された又はストリーム処理ラインを自動的に構築するソフトウェアによって定義された組み合わせに従い、オペレーターを組み合わせたものでありうる。オペレーターは例えば、割り当てられた時間又は割り当てられたシステム・リソースに従って、複数のプロセッサ・ノード又は複数の仮想マシン上に分散されて、デプロイされる。デプロイとは、分散して組み合わされたオペレーターを実行可能なようにすることである（コンパイラによるコンパイラをイメージされたい）。

【0109】

ストリーム処理を行うためのソフトウェア・プラットフォームとして、例えば、IBM（登録商標） InfoSphere（登録商標） Streamsが用いられうる。IBM（登録商標）InfoSphere（登録商標）Streamsは、大量の流入データをストリーム処理するための包括的なプラットフォームである。IBM（登録商標） InfoSphere（登録商標） Streamsは、数千規模のプロセッサ・ノード上に配置された複数のオペレーターをデプロイし、ほぼ無限のキャパシティとミリ秒単位の応答時間を実現可能なスケーラブルな実行環境を提供する。IBM（登録商標） InfoSphere（登録商標） Streamsは、個々の処理を、定義された言語（ＳＰＬ）で記載し、オペレーターとして再利用可能にする。IBM（登録商標） InfoSphere（登録商標） Streamsでは、オペレーターをグループ化し、処理順やリソースの割り当てを容易に行うことが可能であることから、アプリケーション開発やデバッグの向上を可能にする。

【0110】

また、ストリーム処理を行うためのソフトウェア・プラットフォームとして、IBM（登録商標） InfoSphere（登録商標） Streams以外に、Amazon Inc.若しくは日立製作所株式会社から上市されているストリーム処理を可能にする製品、又は、Stanford大学、Berkley、MIT又はA&Tが保有しているストリーム処理を可能にするシステムが使用可能でありうる。

【0111】

また、ステップ２０３において、コンピュータ・システム（１２１）は、例えばオペレーター毎に、上記受信したデータをリアルタイムにストリーム処理するのに要した処理時間を取得又は算出しうる。そして、コンピュータ・システム（１２１）は、当該取得又は算出した処理時間を、例えば当該処理時間を格納する記録媒体に格納しうる。

【0112】

また、ステップ２０３において、コンピュータ・システム（１２１）は、例えばオペレーター毎に、上記受信したデータをリアルタイムにストリーム処理するのに要したシステム・リソースを取得又は算出しうる。そして、コンピュータ・システム（１２１）は、当該取得又は算出したシステム・リソースを、例えば当該システム・リソースを格納する記録媒体に格納しうる。

【0113】

ステップ２０４において、コンピュータ・システム（１２１）は任意的に、データ中の欠損の可能性のある部分を検出する為に、ステップ２０２で受信したデータのデータ収集間隔を検出しうる。データ収集間隔を検出する処理の詳細は、図２Ｂに示すフローチャートに従って、下記において別途説明する。

【0114】

ステップ２０５において、コンピュータ・システム（１２１）は、ステップ２０３に示すようにステップ２０２で受信したデータをリアルタイムにストリーム処理しながら、当該受信したデータ中の欠損の可能性のある部分を検出する。また、コンピュータ・システム（１２１）は、ステップ２０４において検出したデータ収集間隔に基づいて、当該受信したデータ中の欠損の可能性のある部分を検出しうる。また、コンピュータ・システム（１２１）は、当該受信したデータ中の欠損の可能性のある部分を検出するとともに、当該欠損可能性（例えば、％）を、過去に欠損として蓄積した欠損履歴データを参照して取得し又は算出しうる。当該受信したデータ中の欠損の可能性のある部分を検出する処理の詳細は、図２Ｃに示すフローチャートに従って、下記において別途説明する。

【0115】

ステップ２０６において、コンピュータ・システム（１２１）は、ステップ２０３に示すようにステップ２０２で受信したデータをリアルタイムにストリーム処理しながら、ステップ２０３においてストリーム処理された結果（例えば、集計結果）中の欠損の可能性のある部分を検出する。また、コンピュータ・システム（１２１）は、ステップ２０５において検出された欠損の可能性のある部分が処理結果に使用されているか否かを参照しながら、図２Ｄに示す変化率の異常（ステップ２４３）、相関の異常（ステップ２４５）及び集計値との乖離（ステップ２４７）を検出しうる。当該ストリーム処理された結果中の欠損の可能性のある部分を検出する処理の詳細は、図２Ｄに示すフローチャートに従って、下記において別途説明する。

【0116】

コンピュータ・システム（１２１）は、ステップ２０３におけるリアルタイムのストリーム処理、ステップ２０４におけるデータ収集間隔の検出、ステップ２０５におけるデータ中の欠損の可能性のある部分の検出、並びに、ステップ２０６におけるストリーム処理された結果中の欠損の可能性のある部分の検出を、並列に処理しうる。

【0117】

ステップ２０７において、コンピュータ・システム（１２１）は、ステップ２０２で開始したデータの受信が終了したかを判断する。当該判断は例えば、上記他のシステム（例えば、リモート・システム）より計測終了のシグナルが送信されてくることにより、又は、所定の期間、データが送信されてこないことによって行われうる。コンピュータ・システム（１２１）は、上記データの受信が終了することに応じて、処理をステップ２０８に進める。一方、コンピュータ・システム（１２１）は、上記データの受信が終了していないことに応じて、処理をステップ２０３に戻し、当該データの受信が終了するまでステップ２０３〜２０７を繰り返す。

【0118】

ステップ２０８において、コンピュータ・システム（１２１）は、ステップ２０３でリアルタイムにストリーム処理した結果（以下、ストリーム処理結果ともいう）を、レポートとして表示装置の画面上に若しくは印刷物として又はファイルとして出力しうる。また、コンピュータ・システム（１２１）は、当該ストリーム処理結果を、例えばストリーム処理結果を格納する記録媒体に格納しうる。

【0119】

ステップ２０９において、コンピュータ・システム（１２１）は、データをリアルタイムにストリーム処理することを終了する。

【0120】

次に、コンピュータ・システム（１２１）は、１つの処理単位であるオペレーターの組み合わせを再配置する処理の為に、図３Ａ〜図３Ｂに示す処理を開始する。

【0121】

図２Ｂは、図２Ａに示すフローチャートのうち、ステップ２０２で受信したデータのデータ収集間隔を検出するステップ（ステップ２０４）の処理の為のフローチャートを示す。

【0122】

ステップ２１１において、コンピュータ・システム（１２１）は、ステップ２０２で受信したデータのデータ収集間隔を検出する処理を開始する。

【0123】

ステップ２１２において、コンピュータ・システム（１２１）は、データ（測定値でもありうる）を取得する。当該測定値は例えば、センサからの測定値でありうる。

【0124】

ステップ２１３において、コンピュータ・システム（１２１）は、当該取得した測定値が前回の測定値から変化したかを判断する。コンピュータ・システム（１２１）は、当該取得した測定値が前回の測定値から変化していないことに応じて、処理をステップ２１４に進める。一方、コンピュータ・システム（１２１）は、当該取得した測定値が前回の測定値から変化したことに応じて、処理をステップ２１５に進める。

【0125】

ステップ２１４において、コンピュータ・システム（１２１）はさらに、カウンタが最小値であるかを判断する。コンピュータ・システム（１２１）は、カウンタが最小値であることに応じて、処理をステップ２１６に進める。一方、コンピュータ・システム（１２１）は、カウンタが最小値でないことに応じて、処理を終了ステップ２１７に進める。

【0126】

ステップ２１５において、コンピュータ・システム（１２１）は、当該取得した測定値が前回の測定値から変化していないことに応じて、カウンタをインクリメントする。そして、コンピュータ・システム（１２１）は、処理を終了ステップ２１７に進める。

【0127】

ステップ２１６において、コンピュータ・システム（１２１）は、カウンタが最小値であることに応じて、データ収集間隔を更新する。そして、コンピュータ・システム（１２１）は、処理を終了ステップ２１７に進める。

【0128】

また、ステップ２１６において、コンピュータ・システム（１２１）は、上記更新したデータ収集間隔を、例えばデータ収集間隔を格納する記録媒体に格納しうる。

【0129】

ステップ２１７において、コンピュータ・システム（１２１）は、ステップ２０２で受信したデータのデータ収集間隔を検出する処理を終了する。

【0130】

図２Ｃは、図２Ａに示すフローチャートのうち、ステップ２０２で受信したデータ中の欠損の可能性のある部分を検出するステップ（ステップ２０５）の処理の為のフローチャートを示す。

【0131】

ステップ２２１において、コンピュータ・システム（１２１）は、ステップ２０２で受信したデータ中の欠損の可能性のある部分を検出する処理を開始する。コンピュータ・システム（１２１）は、欠損の可能性のある部分を判断する為に用いる欠損履歴データを読み込む。

【0132】

ステップ２２２において、コンピュータ・システム（１２１）は、コンピュータ・システム（１２１）は、データ（測定値でもありうる）を取得する。当該測定値は例えば、センサからの測定値でありうる。

【0133】

ステップ２２３において、コンピュータ・システム（１２１）は、時系列中で値が欠落したデータがあるか（すなわち、有るべきデータが無いか）、又は時系列中で値が異常であるかを判断する。

【0134】

コンピュータ・システム（１２１）は、時系列中で値が欠落したデータがあるかを例えば、ある時系列中でデータが空白であること、又はある時系列中でデータがｎｕｌｌを示すことで判断しうる。

【0135】

コンピュータ・システム（１２１）は、上記データが異常であることを例えば、値が異常に高かったり若しくは低かったり、又は値がゼロやマイナス（例えば、−１）であることで判断しうる。コンピュータ・システム（１２１）は、当該判断を例えば、既に到着しているデータと比べて、又は、過去に欠損として蓄積した欠損履歴データを参照して判断しうる。

【0136】

コンピュータ・システム（１２１）は、時系列中で値が欠落したデータがあること又は上記値が異常であることに応じて、処理をステップ２２４に進める。一方、コンピュータ・システム（１２１）は、時系列中で値が欠落したデータがないこと且つ上記値が異常でないことのいずれも満たすことに応じて、処理をステップ２２５に進める。

【0137】

ステップ２２４において、コンピュータ・システム（１２１）は、時系列中で値が欠落したデータがあること又は上記値が異常であることに応じて、当該欠落したデータがある部分又は当該異常がある部分を欠損の可能性のある部分として、例えば欠損可能性部分を保存する記憶媒体に格納する。そして、コンピュータ・システム（１２１）は、処理をステップ２２９に進める。

【0138】

ステップ２２５において、コンピュータ・システム（１２１）は、上記取得したデータとそれ以前に取得したデータとの間に変化が無いかを判断する。コンピュータ・システム（１２１）は例えば、上記変化が無いかを、値が一定期間変わらないこと（例えば、センサのデータ検出間隔よりも長いこと）又はデータ受信の所定回数以上変わらないことで判断しうる。上記変化が無いということは同じ値が続くことを意味し、かかる場合には当該データを欠損の可能性のある部分として判断されうる。なぜならば、センサ故障により同じ値が送信され続けたり、又は、センサ装置に関連付けられたデバイスや伝送経路の障害により同じ値が送信され続けたりする場合があるからである。

【0139】

コンピュータ・システム（１２１）は、上記変化が無いことに応じて処理をステップ２２６に進める。一方、コンピュータ・システム（１２１）は、上記変化があることに応じて処理をステップ２２９に進める。

【0140】

ステップ２２６において、コンピュータ・システム（１２１）は、上記変化が無いことに応じて、カウンタをインクリメントする。

【0141】

ステップ２２７において、コンピュータ・システム（１２１）は、カウンタが所定値以上であることに応じて、処理をステップ２２８に進める。一方、コンピュータ・システム（１２１）は、カウンタが所定値未満であることに応じて、処理をステップ２２９に進める。

【0142】

ステップ２２８において、コンピュータ・システム（１２１）は、カウンタが所定値以上であることに応じて、当該データのある部分を欠損の可能性のある部分として、例えば欠損可能性部分を保存する記憶媒体に格納する。そして、コンピュータ・システム（１２１）は、処理をステップ２２９に進める。

【0143】

ステップ２２９において、コンピュータ・システム（１２１）は、データの変化率が異常であるか、又はデータ間の相関が異常であるかを判断する。

【0144】

コンピュータ・システム（１２１）は、データの変化率が異常であるかを例えば、データが抜けていること、又は、特定のデバイスや装置の測定値の変化率が正常値と乖離しているかによって判断しうる。特定のデバイスや装置の測定値は例えば、データが車から得られるものであるとすれば、ギアや回転数、速度などでありうるがこれらに限定されるものでない。

【0145】

コンピュータ・システム（１２１）は、データ間の相関が異常であるかを例えば、複数の関連する属性の相関が異常であること（例えば、データが車から得られるものであるとすれば、エンジン回転数と油圧との相関が異常であること）で判断しうる。

【0146】

コンピュータ・システム（１２１）は、データ間の相関が異常であることに応じて、処理をステップ２３０に進める。一方、コンピュータ・システム（１２１）は、データ間の相関が異常でないことに応じて、処理をステップ２３１に進める。

【0147】

ステップ２３０において、コンピュータ・システム（１２１）は、上記データ間の相関が異常であることに応じて、当該データのある部分を欠損の可能性のある部分として、例えば欠損可能性部分を保存する記憶媒体に格納する。そして、コンピュータ・システム（１２１）は、処理をステップ２３１に進める。

【0148】

ステップ２３１において、コンピュータ・システム（１２１）は、上記データ中の欠損の可能性のある部分が存在したかを判断する。コンピュータ・システム（１２１）は、データ中の欠損の可能性のある部分が存在したことに応じて、処理をステップ２３２に進める。一方、コンピュータ・システム（１２１）は、データ中の欠損の可能性のある部分が存在しなかったことに応じて、処理を終了ステップ２３３に進める。

【0149】

ステップ２３２において、コンピュータ・システム（１２１）は、欠損の可能性のある部分として記憶した部分それぞれについて、欠損可能性（例えば、％）を例えば、過去に欠損として蓄積した欠損履歴データを参照して取得し又は算出しうる。コンピュータ・システム（１２１）は、欠損の可能性のある部分として記憶した部分それぞれについて、当該欠損可能性を例えば、ステップ２０２で受信したデータが決められたコース（例えば、自社のテスト走行用のサーキット若しくは自動車競技用のサーキット）でしか行えない走行テスト又は自動車競技である場合には、走行中の値（例えば、ラップ集計、正常周、又はピット周）と比較することによって算出しうる。

【0150】

欠損可能性は、時系列中で値が欠落した部分がある場合又は上記値が異常である場合（ステップ２２３を参照）には、例えば１００％としうる。

【0151】

同様に、欠損可能性は、上記取得したデータとそれ以前に取得したデータとの間に変化が無い場合（ステップ２２５を参照）には、例えばＸ％（１００％と０％との間の数字）としうる。

【0152】

同様に、欠損可能性は、データの変化率が異常であること又はデータ間の相関が異常である場合（ステップ２２９を参照）には、例えばＹ％（１００％と０％との間の数字）としうる。

【0153】

また、ステップ２３２において、コンピュータ・システム（１２１）は、欠損の可能性のある部分として記憶した部分それぞれについて、当該部分があることによって影響する影響範囲を算出しうる。コンピュータ・システム（１２１）は例えば、当該部分があることによってどのレポートのどの解析（例えば、障害、警告、ただの蓄積）のどの属性に影響があるのかを算出しうる。

【0154】

コンピュータ・システム（１２１）は、当該算出した欠損可能性を、例えば欠損可能性を保存する記憶媒体に格納する。そして、コンピュータ・システム（１２１）は、処理を終了ステップ２３３に進める。

【0155】

ステップ２３３において、コンピュータ・システム（１２１）は、ステップ２０２で受信したデータ中の欠損の可能性のある部分を検出する処理を終了する。

【0156】

図２Ｃに示すフローチャートにおいて、欠損の可能性のある部分として記憶する為の判断内容をステップ２２３、２２５及び２２９に示した。しかしながら、当該判断内容はステップ２２３、２２５及び２２９に示した事項に限定されるものでなく、その他の判断内容を適宜追加しうる。その他の判断内容としては、例えばデータが車から得られるものであるとすれば、例えば上記走行テスト又は自動車競技におけるラップ毎の差異、例えばデータが人工衛星や宇宙から得られるものであるとすれば、例えば地球の周回毎の差異でありうる。

【0157】

図２Ｄは、図２Ａに示すフローチャートのうち、集計結果中の欠損の可能性のある部分を検出するステップの処理の為のフローチャートを示す。

【0158】

ステップ２４１において、コンピュータ・システム（１２１）は、ステップ２０３におけるストリーム処理によって得られた結果から、欠損の可能性のある部分を検出する処理を開始する。

【0159】

ステップ２４２において、コンピュータ・システム（１２１）は、ステップ２０３におけるストリーム処理によって得られた結果を取得する。

【0160】

ステップ２４３において、コンピュータ・システム（１２１）は、ステップ２４２で取得した結果において、変化率が異常であるかを判断する。コンピュータ・システム（１２１）は、上記変化率が異常であることに応じて、処理をステップ２４４に進める。一方、コンピュータ・システム（１２１）は、上記変化率が異常でないことに応じて、処理をステップ２４５に進める。

【0161】

ステップ２４４において、コンピュータ・システム（１２１）は、上記変化率が異常であることに応じて、当該データのある部分を欠損の可能性のある部分として、例えば欠損可能性部分を保存する記憶媒体に格納する。そして、コンピュータ・システム（１２１）は、処理をステップ２４５に進める。

【0162】

ステップ２４５において、コンピュータ・システム（１２１）は、ステップ２４２で取得した結果において、当該結果間の相関が異常であるかを判断する。コンピュータ・システム（１２１）は、上記結果間の相関が異常であることに応じて、処理をステップ２４６に進める。一方、コンピュータ・システム（１２１）は、上記結果間の相関が異常でないことに応じて、処理をステップ２４７に進める。

【0163】

ステップ２４６において、コンピュータ・システム（１２１）は、上記結果間の相関が異常であることに応じて、当該異常がある部分を欠損の可能性のある部分として、例えば欠損可能性部分を保存する記憶媒体に格納する。そして、コンピュータ・システム（１２１）は、処理をステップ２４７に進める。

【0164】

ステップ２４７において、コンピュータ・システム（１２１）は、ステップ２０３でリアルタイムにストリーム処理により得られた集計値とステップ２４２で取得した結果とが乖離しているかを判断する。コンピュータ・システム（１２１）は、上記集計値と上記結果とが乖離していることに応じて、処理をステップ２４８に進める。一方、コンピュータ・システム（１２１）は、上記集計値と上記結果とが乖離していないことに応じて、処理をステップ２４９に進める。

【0165】

ステップ２４８において、コンピュータ・システム（１２１）は、上記集計値と上記結果とが乖離していることに応じて、当該乖離している部分を欠損の可能性のある部分として、例えば欠損可能性部分を保存する記憶媒体に格納する。そして、コンピュータ・システム（１２１）は、処理をステップ２４９に進める。

【0166】

ステップ２４９において、コンピュータ・システム（１２１）は、上記集計結果中に欠損の可能性がある部分が存在したかを判断する。コンピュータ・システム（１２１）は、上記集計結果中に欠損の可能性のある部分が存在したことに応じて、処理をステップ２５０に進める。一方、コンピュータ・システム（１２１）は、上記集計結果中に欠損の可能性のある部分が存在しなかったことに応じて、処理を終了ステップ２５１に進める。

【0167】

ステップ２５０において、コンピュータ・システム（１２１）は、欠損の可能性のある部分として記憶した部分それぞれについて、欠損可能性（例えば、％）を、過去に欠損として蓄積した欠損履歴データを参照して算出しうる。当該欠損可能性については、図２Ｃに示すステップ２３２の説明において述べたとおりである。

【0168】

また、ステップ２５０において、コンピュータ・システム（１２１）は、欠損の可能性のある部分として記憶した部分それぞれについて、当該部分があることによって影響する影響範囲を算出しうる。コンピュータ・システム（１２１）は例えば、当該部分があることによってどのレポートのどの解析（例えば、障害、警告、ただの蓄積）のどの属性に影響があるのかを算出しうる。

【0169】

コンピュータ・システム（１２１）は、当該算出した欠損可能性を、例えば欠損可能性を保存する記憶媒体に格納する。そして、コンピュータ・システム（１２１）は、処理を終了ステップ２５１に進める。

【0170】

ステップ２５１において、コンピュータ・システム（１２１）は、ステップ２０３におけるストリーム処理によって得られた結果から、欠損の可能性のある部分を検出する処理を終了する。

【0171】

次に、コンピュータ・システム（１２１）は、ステップ２０２において受信したデータに対応し且つ欠損のないマスター・データを受信することに応じて、図４に示す処理を開始する。

【0172】

図３Ａ及び図３Ｂはそれぞれ、本発明の実施態様に従い、１つの処理単位であるオペレーターの組み合わせを再配置する処理の為のフローチャートを示す。

【0173】

ステップ３０１において、コンピュータ・システム（１２１）は、図２Ａ〜図２Ｄに示すフローチャートの処理が終了することに応じて、図２Ａに示すフローチャートのうちのステップ２０３で使用した第１のストリーム処理ラインにおけるオペレーターの組み合わせを再配置して、第２のストリーム処理ラインを生成する処理を開始する。

【0174】

ステップ３０２において、コンピュータ・システム（１２１）は、ステップ２０３におけるストリーム処理の結果として得られる一つのレコードを読み出す。

【0175】

ステップ３０３において、コンピュータ・システム（１２１）は、ステップ３０２で読み出したレコードに関係する処理を決定する。

【0176】

ステップ３０４において、コンピュータ・システム（１２１）は、ステップ３０３で決定した処理に依存する処理（例えば、ステップ３０３で決定した処理が依存し、ステップ３０３で決定されていない他の処理）があるかを判断する。当該依存する処理とは例えば、ある更新処理の為に、前提として必要な更新処理、又は、ある更新処理を行うことによって、さらに再計算が必要となる処理でありうる。コンピュータ・システム（１２１）は、上記依存する処理があることに応じて処理をステップ３０５に進める。一方、コンピュータ・システム（１２１）は、上記依存する処理がないことに応じて処理をステップ３０６に進める。

【0177】

ステップ３０５において、コンピュータ・システム（１２１）は、上記依存処理があることに応じて、当該依存処理を処理対象として追加する。

【0178】

ステップ３０６において、コンピュータ・システム（１２１）は、図２Ａ〜図２Ｄに示す処理によって出力されたレポート（図２Ａに示すステップ２０８を参照）のうち、図２Ａに示すステップ２０３のストリーム処理で得られた結果を更新する処理（図４に示すフローチャートを参照）において修正されるレポートをステップ３０３で決定された処理及びステップ３０５で追加された処理に基づいて抽出する。また、コンピュータ・システム（１２１）は、当該抽出したレポートに関連付けられた処理に、処理すべき優先度を付すようにしうる。コンピュータ・システム（１２１）は、当該優先度を例えば、当該レポートを必要とするクライアント（ユーザ）からの要求に応じて、上記抽出したレポートに関連付けられたオペレーターに付すようにしうる。代替的には、コンピュータ・システム（１２１）は、当該優先度を例えば、当該レポートを必要とするクライアント（ユーザ）からの要求に応じて、上記抽出したレポートに関連付けられた処理に付すようにしうる。当該抽出したレポートに関連付けられた処理は、コンピュータ・システム（１２１）が単一又は複数のオペレーターを実行することであるので、優先度をオペレーターに付す代わりに、上記処理に優先度を付しても、優先度の高いレポートを優先的に出力されるようにするという同じ目的を達成することが可能であるからである。

【0179】

ステップ３０７において、コンピュータ・システム（１２１）は、未処理のレコードがあるかを判断する。コンピュータ・システム（１２１）は、未処理のレコードがあることに応じて処理をステップ３０２に戻し、ステップ３０２〜３０７を繰り返す。コンピュータ・システム（１２１）は、未処理のレコードがないことに応じて、処理をステップ３０８に進める。

【0180】

ステップ３０８において、コンピュータ・システム（１２１）は、ステップ３０６で抽出されたレポート（例えば、下記図５Ｂに示すレポート構造（５０５））を参照し、図２Ａに示すフローチャートのうちのステップ２０３で使用した第１のストリーム処理ラインを更新して、第２のストリーム処理ラインを構築するために、第１のストリーム処理ラインにおけるオペレーターを再配置する。すなわち、コンピュータ・システム（１２１）は、オペレーターの組み合わせを変更したり、不要なオペレーターを削除したりすることによって、オペレーターを再配置する。コンピュータ・システム（１２１）は、ステップ３０６において抽出されたレポートに関連付けられた処理に優先度が付されている場合には、当該優先度に従うように、上記オペレーターを再配置しうる。従って、上記レポートの中で、優先度の高い結果が優先して処理されるように、上記オペレーターが再配置されうる。

【0181】

ステップ３０９において、コンピュータ・システム（１２１）は、ステップ３０８において再配置されたオペレーターにおいて、重複処理があるかを判断する。コンピュータ・システム（１２１）は、上記重複処理があることに応じて、処理をステップ３１０に進める。一方、コンピュータ・システム（１２１）は、上記重複処理がないことに応じて、処理をステップ３１１に進める。

【0182】

ステップ３１０において、コンピュータ・システム（１２１）は、オペレーターの上記重複処理を解消する。コンピュータ・システム（１２１）は、オペレーターが重複しないように、重複しているオペレーターを削除しうる。

【0183】

ステップ３１１において、コンピュータ・システム（１２１）は、再配置されたオペレーターを実行する為のシステム・リソースを、例えば図２Ａに示すステップ２０３において取得又は算出したシステム・リソースに基づいて算出しうる。

【0184】

ステップ３１２において、コンピュータ・システム（１２１）は、ステップ３１１で算出したシステム・リソースが、与えられたシステム・リソースを超過するかを判断する。コンピュータ・システム（１２１）は、上記算出したシステム・リソースが、与えられたシステム・リソースを超過することに応じて、処理をステップ３１３に進める。一方、コンピュータ・システム（１２１）は、上記算出したシステム・リソースが、与えられたシステム・リソースを超過しないことに応じて、処理をステップ３１６に進める。

【0185】

ステップ３１３において、コンピュータ・システム（１２１）は、上記算出したシステム・リソースが、与えられたシステム・リソースを超過することに応じて、超過した分について、オペレーターの処理に要するシステム・リソースを減らすことができるかを判断する。超過した分について、オペレーターの処理に要するシステム・リソースを減らすことは例えば、オペレーターの一部のモジュールやサブルーチンを削除することや実行しないことを含みうる。コンピュータ・システム（１２１）は、上記システム・リソースを減らすことができることに応じて、処理をステップ３１４に進める。一方、上記システム・リソースを減らすことができないことに応じて、処理をステップ３１５に進める。

【0186】

ステップ３１４において、コンピュータ・システム（１２１）は、ステップ３０６において処理に付された優先度に従って、当該処理に関連付けられ且つ優先度の低いオペレーターに割り当てられるシステム・リソースを減少させるように変更する。

【0187】

ステップ３１５において、コンピュータ・システム（１２１）は、上記システム・リソースを減らすことができないことに応じて、並列処理を当該並列処理の代わりにシリアライズ処理（逐次処理）するように変更する。

【0188】

ステップ３１６において、コンピュータ・システム（１２１）は、図２Ａに示すステップ２０３に示すストリーム処理で得られた結果を更新する為に必要な予定時間を、例えば上記ストリーム処理において実際に要した処理時間に基づいて算出する。

【0189】

ステップ３１７において、コンピュータ・システム（１２１）は、ステップ３１６で算出した予定時間が、与えられた予定時間（例えば、レポートを必要とするクライアント（ユーザ）によって与えられうる）を超過するかを判断する。コンピュータ・システム（１２１）は、上記算出した予定時間が、与えられた予定時間を超過することに応じて、処理をステップ３１８に進める。一方、コンピュータ・システム（１２１）は、上記算出した予定時間が、与えられたシステムを超過しないことに応じて、処理をステップ３１９に進める。

【0190】

ステップ３１８において、コンピュータ・システム（１２１）は、上記算出した予定時間が、与えられた予定時間を超過することに応じて、ステップ３０６において処理に付された優先度に従って、当該処理に関連付けられ且つ優先度の低いオペレーターをシリアライズ処理の後ろへ移動する。

【0191】

ステップ３１９において、コンピュータ・システム（１２１）は、ステップ３１５及びステップ３１８によりステップ３０８で再配置したオペレーターの配置に変更が必要な場合には、当該オペレーターの配置をさらに変更し、そして最終的に配置が決まったオペレーターの組み合わせ（第２のストリーム処理ライン）をデプロイする。すなわち、コンピュータ・システム（１２１）は、最終的に配置が決まったオペレーターの組み合わせを実行可能なようにコンパイルする。コンピュータ・システム（１２１）は、各オペレーターを上記最終的な配置に従って、１又は複数のコアにディスパッチする。

【0192】

ステップ３２０において、コンピュータ・システム（１２１）は、上記ストリーム処理で得られた結果を更新する処理の予定（例えば、開始予定時間及び終了予定時間を含みうる）を表示装置の画面上に若しくは印刷物として又はファイルとして出力しうる。

【0193】

ステップ３２１において、コンピュータ・システム（１２１）は、オペレーターの組み合わせを再配置して、上記第２のストリーム処理ラインを生成する処理を終了する。

【0194】

図４は、本発明の実施態様に従い、図２Ａに示すステップ２０２で受信したデータに対応し且つ欠損のないマスター・データを使用して、図２Ａのステップ２０３に示すストリーム処理で得られた結果を更新する処理の為のフローチャートを示す。

【0195】

ステップ４０１において、コンピュータ・システム（１２１）は、上記マスター・データを使用して、上記ストリーム処理で得られた結果を更新する処理を開始する。

【0196】

ステップ４０２において、コンピュータ・システム（１２１）は、上記マスター・データを受信する。コンピュータ・システム（１２１）は、当該マスター・データを例えば、全データを含むファイル（ファイルの保存形式は任意である）として受信する。当該受信されたマスター・データは、図２Ａに示すステップ２０２で受信したデータに対応し、且つ、欠損の無いことが判っているデータである。例えば、受信したデータが車から得られるものであるとすれば、上記マスター・データは例えば、当該車に備えられた記憶媒体から直接的に取り出したデータでありうる。

【0197】

ステップ４０３において、コンピュータ・システム（１２１）は、ステップ２０２で受信したデータを順次取り出し、当該取り出したデータが欠損の可能性のある部分として格納されたデータであるかを判断する。コンピュータ・システム（１２１）は、上記取り出したデータが欠損の可能性のある部分として格納されたデータであることに応じて、処理をステップ４０４に進める。一方、コンピュータ・システム（１２１）は、上記取り出したデータが欠損の可能性のある部分として格納されたデータでないことに応じて、処理をステップ４１１に進める。

【0198】

ステップ４０４において、コンピュータ・システム（１２１）は、当該欠損の可能性のある部分が本当に欠損している部分であるかを確認する為に、ステップ４０２で受信したマスター・データとステップ４０３で欠損の可能性のある部分のデータとを比較する。

【0199】

ステップ４０５において、コンピュータ・システム（１２１）は、上記比較の結果、上記欠損の可能性のある部分が実際に欠損している部分であるかを判断する。コンピュータ・システム（１２１）は、上記欠損の可能性のある部分が実際に欠損している部分であることに応じて、処理をステップ４０６に進める。一方、コンピュータ・システム（１２１）は、上記欠損の可能性のある部分が実際には欠損している部分でないことに応じて、処理をステップ４０７に進める。

【0200】

ステップ４０６において、コンピュータ・システム（１２１）は、上記欠損の可能性のある部分が実際に欠損している部分であることに応じて、欠損履歴を格納している履歴データを更新して、当該部分に欠損があるという情報を追加する。

【0201】

ステップ４０７において、コンピュータ・システム（１２１）は、上記欠損の可能性のある部分が実際には欠損している部分でないことに応じて、欠損履歴を格納している履歴データを更新して、当該部分に欠損がないという情報を追加する。

【0202】

ステップ４０８において、コンピュータ・システム（１２１）は、ステップ４０２で受信したマスター・データを使用して、図２Ａのステップ２０３に示すストリーム処理で得られた結果を更新する為に、当該マスター・データを図３Ｂに示すステップ３１９においてデプロイされた第２のストリーム処理ラインにディスパッチする。コンピュータ・システム（１２１）は、当該ディスパッチにおいて、上記マスター・データのうち、上記第２のストリーム処理ラインに必要な部分のみを上記第２のストリーム処理ラインにディスパッチしうる。

【0203】

ステップ４０９において、コンピュータ・システム（１２１）は、上記ディスパッチされたマスター・データを上記第２のストリーム処理ラインを使用して処理し、そして当該マスター・データの処理結果を得る。そして、コンピュータ・システム（１２１）は、図２Ａのステップ２０３に示すストリーム処理で得られた結果を、上記マスター・データの処理結果で更新する。

【0204】

ステップ４１０において、コンピュータ・システム（１２１）は、上記更新状況を示す更新処理状況データを更新する。コンピュータ・システム（１２１）は例えば、表示装置の画面上に表示されている更新処理状況を最新の更新状況に更新したり、又は更新状況を格納する更新状況データを更新したりしうる。

【0205】

ステップ４１１において、コンピュータ・システム（１２１）は、次に処理すべき欠損の可能性のあるデータがあるかを判断する。コンピュータ・システム（１２１）は、次に処理すべき欠損の可能性のあるデータがあることに応じて、処理をステップ４０３に戻し、ステップ４０３〜４１１を繰り返す。一方、コンピュータ・システム（１２１）は、次に処理すべき欠損の可能性のあるデータがないことに応じて、処理を終了ステップ４１２に進める。

【0206】

ステップ４１２において、コンピュータ・システム（１２１）は、上記マスター・データを使用して、上記ストリーム処理で得られた結果を更新する処理を終了する。

【0207】

図５Ａ〜図５Ｃはそれぞれ、本発明の実施態様において使用されうる各種データ構造の例を示す。また、当該各種データ構造は、データが上記走行テスト又は自動車競技において競技中の車から得られるデータを処理する場合において、本発明の実施態様において使用されうるデータ構造の例である。

【0208】

図５Ａに示すデータ構造（５０１）は、図２Ａに示すステップ２０２で受信したデータを送信するセンサ又はデバイスから、当該データの収集間隔を動的に蓄積する為に用いられる。データ構造（５０１）は、図２Ａのステップ２０４及びその詳細な図２Ｂに示すフローチャートの処理において用いられる。コンピュータ・システム（１２１）は、図２Ｂに示すステップ２１６においてデータ収集間隔が更新された場合に、当該更新されたデータ収集間隔をデータ構造（５０１）中に格納する。データ構造（５０１）は例えば、ＩＤ（例えば、センサを特定する為の識別子や周期行動を特定する為の識別子）、属性（例えば、センサから得られるデータの種類）、及び間隔（例えば、センサによる収集間隔）を含みうる。データ構造（５０１）は例えば、図７Ａ及び図７Ｂそれぞれに示すデータ収集間隔を格納する記憶媒体（７８２）中に格納される。

【0209】

図５Ａに示すデータ構造（５０２）は、過去の欠損履歴を蓄積する為に用いられる。データ構造（５０２）は、図２Ａに示すステップ２０５及び２０６並びに、それらの詳細な図２Ｃに示すフローチャート及び図２Ｄに示すフローチャートの処理において、欠損の可能性のある部分を検出する為に用いられる。データ構造（５０２）は例えば、欠損可能性の種類（例えば、欠損の原因）、属性（例えば、欠損の可能性のあるデータが属する属性）、値の範囲（例えば、欠損の可能性のある値の範囲）、条件（例えば、欠損の可能性があると判定される条件）、及び欠損の可能性（欠損があると判定されうる確率に、実際に欠損があった確率を加味したもの）を含みうる。データ構造（５０２）は例えば、図７Ａ及び図７Ｂそれぞれに示す欠損履歴を格納する記憶媒体（７８３）中に格納される。

【0210】

図５Ａに示すデータ構造（５０３）は、欠損の可能性のあるデータ又データ群を格納する為に用いられる。データ構造（５０３）は、図２Ａに示すステップ２０５及び２０６並びに、それらの詳細な図２Ｃに示すフローチャート及び図２Ｄに示すフローチャートの処理において用いられる。コンピュータ・システム（１２１）は、図２Ｃに示すステップ２２４、２２８及び２３０、並びに、図２Ｄに示すステップ２４４、２４６及び２４８において、欠損の可能性のある部分が検出された場合に、当該検出された欠損の可能性のある部分をデータ構造（５０３）中に格納する。データ構造（５０３）は例えば、属性（例えば、欠損の可能性あると判断される事象やデバイス）、範囲（例えば、欠損の可能性のある時間帯）、欠損の種類（例えば、欠損の原因）、データ量、欠損の可能性（欠損があると判定されうる確率）を含みうる。データ構造（５０３）は例えば、図７Ａ及び図７Ｃそれぞれに示す欠損可能性部分を格納する記憶媒体（７８４）中に格納される。

【0211】

図５Ｂに示すデータ構造（５０４）は、図２Ａに示すステップ２０３において、ストリーム処理に要したシステム・リソース及び処理時間を格納する為に用いられる。また、データ構造（５０４）は、マスター・データを使用してストリーム処理で得られた結果を更新する為に必要なシステム・リソース及び処理時間を算出する為に用いられる。データ構造（５０４）は例えば、オペレータ群（例えば、オペレーター又はオペレーター群が用いられるある処理）、処理データ数（例えば、オペレータ又はオペレータ群によって処理されたデータ数）、処理属性数（例えば、オペレータ又はオペレータ群によって処理される属性）、割り当てシステム・リソース（例えば、オペレータ又はオペレータ群に割り当てられたシステム・リソース；例えば、コア数、又はメモリ容量）、及び処理時間（ある処理を実行する為に要した処理時間）を含みうる。データ構造（５０４）は例えば、図７Ａ及び図７Ｃそれぞれに示す処理時間結果及びシステム・リソースを格納する記憶媒体（７８５）中に格納される。

【0212】

図５Ｂに示すデータ構造（５０５）は、どの属性のどの処理（データ構造（５０５）中の種類に対応する）が、どのレポートの解析の為に使われているかを示す。データ構造（５０５）は、図３Ａに示すステップ３０６において、修正されるレポートを抽出する為に使用される。データ構造（５０５）は例えば、属性（例えば、欠損の可能性あると判断される事象やデバイス）、種類（例えば、属性のタイプ）、サンプリング間隔（例えば、センサやデバイスからのデータの受信又は送信間隔）、解析（例えば、属性に関連付けられた解析内容）、及びレポート（例えば、報告される解析内容）を含みうる。データ構造（５０５）は例えば、図７Ｂに示すレポートを格納する記憶媒体（７８６）中に格納される。

【0213】

図５Ｂに示すデータ構造（５０６）は、どのレポートのどの解析及び属性の優先度が高いかを示す。データ構造（５０６）は、ステップ３０６において抽出されたレポートに付された優先度を格納する為に使用されうる。また、データ構造（５０６）は、図３Ｂに示すステップ３１５及びステップ３１８において、オペレーターのシステム・リソースを決定する為に使用されうる。データ構造（５０６）は例えば、レポート（例えば、報告される解析内容）、解析（例えば、属性に関連付けられた解析内容）、属性（例えば、レポート中に記載される事象やデバイス）、及び優先順位（例えば、処理すべき優先度）を含みうる。データ構造（５０６）は例えば、図７Ｂに示す処理優先度を格納する記憶媒体（７８７）中に格納される。

【0214】

図５Ｃに示すデータ構造（５０７）は、図２Ａに示すステップ２０３のストリーム処理で得られた結果を更新する更新処理（図４に示すフローチャートを参照）の種類（出力されるデータ）を示す。データ構造（５０７）は例えば、オペレーター群（例えば、オペレーター又はオペレーター群が用いられる或る処理）、出力される属性（例えば、上記更新処理により出力される属性）、出力される属性の種類（例えば、処理により出力される属性のタイプ）、サンプリング間隔（例えば、センサやデバイスからのデータの受信又は送信間隔）、及び依存オペレーター（例えば、あるオペレーターと依存関係を有するオペレーター）を含みうる。データ構造（５０７）は例えば、図７Ｂに示す更新処理を格納する記憶媒体（７８８）中に格納される。

【0215】

図５Ｃに示すデータ構造（５０８）は、図２Ａに示すステップ２０３のストリーム処理で得られた結果を更新する更新処理（図４に示すフローチャートを参照）の更新状況を示す。データ構造（５０８）は、図４に示すステップ４１１において、上記更新状況を示す更新処理状況データを更新する為に使用される。データ構造（５０８）は例えば、（例えば、報告される解析内容）、解析（例えば、属性に関連付けられた解析内容）、属性（例えば、レポート中に記載される事象やデバイス）、更新処理状況（例えば、上記更新の進捗状況）、及び処理予測時間（例えば、上記更新の終了予定時刻）を含みうる。データ構造（５０８）は例えば、図７Ｃに示す更新処理状況を格納する記憶媒体（７９１）中に格納される。

【0216】

図６Ａは、本発明の実施態様において、図２Ａに示すステップ２０２で受信したデータをリアルタイムにストリーム処理する為に使用されうる第１のストリーム処理ライン（６０１）を示す。

【0217】

第１のストリーム処理ライン（６０１）は、オペレーター又はオペレーター群（６１１、６１２、６１３、６１４、６１５、６１６、及び６１７）とそれらの入出力を接続（６２１、６２２、６２３、６２４、６２５、６２６、６２７、及び６２８）することによって、ストリーム処理を可能にする。コンピュータ・システム（１２１）は、第１のストリーム処理ライン（６０１）を用いて、図２Ａに示すステップ２０２で受信したデータをリアルタイムにストリーム処理した結果をファイル（６３１）として出力し、又は、データベース（６３２）に出力しうる。

【0218】

図６Ｂは、本発明の実施態様において、図４Ａに示すステップ４０２で受信したマスター・データを使用して、図２Ａのステップ２０３に示すストリーム処理で得られた結果を更新する処理する為に使用されうる第２のストリーム処理ライン（６０２）を示す。

【0219】

第２のストリーム処理ライン（６０２）は、オペレーター又はオペレーター群（６４１、６４２、６４３、６４４、及び６４６、並びに、６５１、６５２、及び６５３）とそれらの入出力を接続（６６１、６６２、６６３、６６５、６６６、並びに、６６９、及び６７０）することによって、ストリーム処理を可能にする。

【0220】

第２のストリーム処理ライン（６０２）は、図６Ａに示す第１のストリーム処理ライン（６０１）におけるオペレーター又はオペレーター群を再配置することによって得られたものである。当該再配置には、オペレーター又はオペレーター群の削除、追加、若しくは並び替え、又はそれらの組み合わせを含みうる。

【0221】

第２のストリーム処理ライン（６０２）では、更新の為のマスター・データのストリーム処理に必要ないと判断されたオペレーターが、図６Ａに示す第１のストリーム処理ライン（６０１）から削除されている（オペレーター「Acceleration」（６８１）、オペレーター「Direction」（６８２）、オペレーター「Oil Temperature」（６８３）、オペレーター「Throttle」及び「Water Pressure」（６８４）、オペレーター「100ms Interval」（６８５）、オペレーター「Water Analysis」（６８６）、及びオペレーター「DB Append」（６８７）。

【0222】

また、第２のストリーム処理ライン（６０２）では、更新時の為のマスター・データのストリーム処理に必要ないと判断された接続（ストリーム）が削除されている（６６５；図６Ａに示す接続（６２５）を参照されたい）。

【0223】

また、第２のストリーム処理ライン（６０２）では、更新時に要するシステム・リソースの節約の為に、更新の為のマスター・データのストリーム処理において不必要なデータ書き込み処理が除去されている（６８８；図６Ａに示すオペレーター（６１５）、接続（６２７）及びファイル（６３１）を参照されたい）。

【0224】

また、第２のストリーム処理ライン（６０２）では、オペレーター「Data Source」（６５１）が追加されている。オペレーター「Data Source」（６５１）は、並列度の向上の為に追加されたものであり、入力や途中処理を受け持つ。

【0225】

また、第２のストリーム処理ライン（６０２）では、オペレーター「DB Data Source」（６５２）が追加されている。オペレーター「DB Data Source」（６５２）は、集計済みデータの有効部分を利用する為に追加されたものである。

【0226】

また、第２のストリーム処理ライン（６０２）では、オペレーター群「DB Append」（図２Ａのオペレーター群（６１７）を参照）が、オペレーター・タイプを必要に応じて変更する為に、オペレーター群「Db Update」（６５３）に処理が変更されている。第１のストリーム処理ライン（６０１）では、データベース（６３２）中にデータが入っていなかった為にデータの追加（Append）処理となっているが、第２のストリーム処理ライン（６０２）では、第１のストリーム処理ライン（６０１）でデータベース（６３２、図６Ｂのデータベース（６９２）に対応する）中に保存されたデータを更新（Update）する処理であるので、追加（Append）処理が必要で無い為に、更新（Update）処理に変更されている。

【0227】

図７Ａ〜図７Ｃはそれぞれ、図１Ａ又は図１Ｂに従うハードウェア構成を好ましくは備えており、本発明の実施態様に従い、データを処理する為のコンピュータ・システムの機能ブロック図の一例を示した図である。

【0228】

図７Ａは、本発明の実施態様に従い、上記受信したデータをリアルタイムにストリーム処理しながら、当該受信したデータ中の欠損の可能性のある部分を検出する為のコンピュータ・システムの機能ブロック図の一例を示した図である。

【0229】

コンピュータ・システム（７０１）は、図１Ａに従うハードウェア構成（１０１）又は図１Ｂに従うハードウェア構成（１２１）を備えうる。

【0230】

コンピュータ・システム（７０１）は、データ受信手段（７１１）、受信データ・ストリーム処理手段（７１２）、ストリーム処理時間算出部（７１３）、データ収集間隔検出手段（７１４）、及び欠損可能性検出手段（７１５）を備えている。

【0231】

データ受信手段（７１１）は、データ（７７１）、例えばストリーム・データを受信する。

【0232】

また、データ受信手段（７１１）は、図２Ａに示すステップ２０２の処理を実行しうる。

【0233】

受信データ・ストリーム処理手段（７１２）は、データ受信手段（７１１）が受信したデータ（７７１）をリアルタイムにストリーム処理する。また、受信データ・ストリーム処理手段（７１２）は、データ受信手段（７１１）が受信したデータ（７７１）のストリーム処理を、１つの処理単位である１つのオペレーターを複数組み合わせて構成された第１のストリーム処理ライン（７６１を参照）において実行する。

【0234】

また、受信データ・ストリーム処理手段（７１２）は、上記ストリーム処理の結果を、例えば、上記ストリーム処理の結果を格納する記憶媒体（７８１）に格納しうる。

【0235】

また、受信データ・ストリーム処理手段（７１２）は、図２Ａに示すステップ２０３の処理を実行しうる。

【0236】

ストリーム処理時間算出部（７１３）は、上記オペレーターが上記ストリーム処理に要した処理時間、若しくは上記オペレーターが上記ストリーム処理に要したシステム・リソース、又はそれらの組み合わせを出力する。ストリーム処理時間算出部（７１３）は、上記処理時間、上記システム・リソース又はそれらの組み合わせを、例えば上記処理時間及び上記システム・リソースを格納する記憶媒体（７８５）に格納しうる。

【0237】

また、ストリーム処理時間算出部（７１３）は、図２Ａに示すステップ２０３の処理において、オペレーターがストリーム処理に要した処理時間、若しくはオペレーターがストリーム処理に要したシステム・リソースを算出しうる。

【0238】

データ収集間隔検出手段（７１４）は、データ受信手段（７１１）が受信したデータ（７７１）が少なくとも１つのセンサからの測定値である場合に、各測定値の収集間隔を検出する。

【0239】

また、データ収集間隔検出手段（７１４）は、上記収集間隔を、例えば、上記収集間隔を格納する記憶媒体（７８２）に格納しうる。

【0240】

また、データ収集間隔検出手段（７１４）は、図２Ａに示すステップ２０４の処理及び図２Ｂに示す各ステップの処理を実行しうる。

【0241】

欠損可能性検出手段（７１５）は、受信データ・ストリーム処理手段（７１２）がリアルタイムにデータ（７７１）をストリーム処理中に、データ受信手段（７１１）が受信したデータ（７７１）中の欠損の可能性のある部分を検出する。欠損可能性検出手段（７１５）は、欠損の可能性のある部分を検出する為に、過去の欠損履歴を蓄積するデータ（欠損履歴データ）（７８３を参照）を参照しうる。

【0242】

また、欠損可能性検出手段（７１５）は、上記欠損の可能性のあるデータ範囲、上記欠損の可能性の確率、上記欠損の種類、上記欠損による処理結果の影響範囲、上記処理結果の出力の優先順位、上記ストリーム処理が１つの処理単位である１つのオペレーターを複数組み合わせて構成されたストリーム処理ラインにおいて実行される場合のオペレーターの依存関係、上記オペレーターが上記ストリーム処理に要した処理時間、若しくは上記オペレーターが上記ストリーム処理に要したシステム・リソース、又はそれらの組み合わせをさらに出力する。

【0243】

また、欠損可能性検出手段（７１５）は、データ受信手段（７１１）が受信したデータ（７７１）が少なくとも１つのセンサからの測定値である場合に、当該測定値を使用して又は上記ストリーム処理によりリアルタイムに算出された集計値を使用して、上記欠損の可能性のある部分を検出する。

【0244】

また、欠損可能性検出手段（７１５）は、データ受信手段（７１１）が受信したデータ（７７１）が少なくとも１つのセンサからの測定値である場合に、各測定値の上記収集間隔の違いが検出されることに応じて、当該違いが検出された部分のデータを欠損の可能性のある部分として検出する。

【0245】

また、欠損可能性検出手段（７１５）は、時系列中で値が欠落していること、値が異常値であること、値が一定期間変わらないこと、値の変化率が異常であること、センサの収集間隔が違うこと、関連する複数の属性の相関（例えば、相関率）が異常であること、若しくは、繰り返し行動から得られる値の差を比較することによって得られる値が異常であることに応じて、又は、欠損履歴を格納した欠損履歴データ（７８３を参照）を参照して、上記欠損の可能性のある部分を検出する。上記繰り返し行動から得られる値とは例えば、平均値、最大値、最小値、又は累積値でありうるがこれらに限定されるものでない。繰り返し行動から得られる値の差とは例えば、繰り返し行動から得られる値と通常時の値に対する乖離でありうる。

【0246】

また、欠損可能性検出手段（７１５）は、図２Ａに示すステップ２０５の処理及び図２Ｃに示す各ステップの処理、並びに、図２Ａに示すステップ２０６の処理及び図２Ｄに示す各ステップの処理を実行しうる。

【0247】

図７Ｂは、図１Ａ又は図１Ｂに従うハードウェア構成を好ましくは備えており、本発明の実施態様に従い、上記ストリーム処理で得られた結果を更新するために使用されるオペレーターの組み合わせを再配置して、当該更新をするために使用するストリーム処理ライン（第２のストリーム処理ライン）を定義する為のコンピュータ・システムの機能ブロック図の一例を示した図である。

【0248】

コンピュータ・システム（７０２）は、図１Ａに従うハードウェア構成（１０１）又は図１Ｂに従うハードウェア構成（１２１）を備えうる。コンピュータ・システム（７０２）は、コンピュータ・システム（７０１）と同じハードウェアであっても異なるハードウェアであってもよい。

【0249】

コンピュータ・システム（７０２）は、オペレーター再配置手段（７２１）、及びオペレーター群デプロイ手段（７２２）を備えている。

【0250】

オペレーター再配置手段（７２１）は、受信データ・ストリーム処理手段（７１２）によるストリーム処理で得られた結果を更新するために使用されるオペレーターの組み合わせを再配置して、当該更新をするために使用する第２のストリーム処理ラインを定義する。

【0251】

また、オペレーター再配置手段（７２１）は、上記オペレーターの組み合わせの再配置を、上記欠損の可能性の確率、上記欠損の種類、上記欠損による処理結果の影響範囲、処理結果の出力の優先順位、上記オペレーターの依存関係、上記更新の為に許容される処理時間、若しくは上記更新の為に使用可能なシステム・リソース（例えば、コア数、又はメモリ容量）、又はそれらの組み合わせに従って決定する。

【0252】

また、オペレーター再配置手段（７２１）は、上記オペレーターの組み合わせの再配置を、上記更新の為に許容される処理時間若しくは上記更新の為に使用可能なシステム・リソース（７８５を参照）又はそれらの組み合わせに制限があることに応じて、処理結果の出力の優先順位に従って決定する。

【0253】

また、オペレーター再配置手段（７２１）は、上記オペレーターの組み合わせの再配置を、レポート（７８６を参照）、処理優先度（７８７を参照）、更新処理（７８８を参照）、処理時間結果（７８５を参照）、システム・リソース（７８５を参照）、欠損履歴（７８３を参照）、若しくはデータ収集間隔（７８２を参照）及びそれらの組み合わせ従って決定する。

【0254】

また、オペレーター再配置手段（７２１）は、図３Ａ及び図３Ｂに示すステップ３０２〜３１８及び３２０の各処理を実行しうる。

【0255】

オペレーター群デプロイ手段（７２２）は、オペレーター再配置手段（７２１）が再配置したオペレーターの組み合わせ（第２のストリーム処理ライン）をデプロイする。

【0256】

また、オペレーター群デプロイ手段（７２２）は、上記再配置されたオペレーターそれぞれを上記コンピュータ・システム上の複数のプロセッサ・ノード又は複数の仮想プロセッサ・ノード上に配置する配置手段（図示せず）をさらに備えている。

【0257】

また、オペレーター群デプロイ手段（７２２）は、図３Ｂに示すステップ３１９の各処理を実行しうる。

【0258】

図７Ｃは、図１Ａ又は図１Ｂに従うハードウェア構成を好ましくは備えており、本発明の実施態様に従い、上記受信したデータに対応し且つ欠損のないマスター・データと、欠損の可能性のある部分とを比較し、上記欠損が存在することに応じて、上記マスター・データを使用して、上記ストリーム処理で得られた結果を更新する為のコンピュータ・システムの機能ブロック図の一例を示した図である。

【0259】

コンピュータ・システム（７０３）は、図１Ａに従うハードウェア構成（１０１）又は図１Ｂに従うハードウェア構成（１２１）を備えうる。コンピュータ・システム（７０３）は、コンピュータ・システム（７０１）と同じハードウェアであっても異なるハードウェアであってもよい。同様に、コンピュータ・システム（７０３）は、コンピュータ・システム（７０２）と同じハードウェアであっても異なるハードウェアであってもよい。

【0260】

コンピュータ・システム（７０３）は、マスター・データ受信手段（７３１）、欠損検証手段（７３２）、マスターデータ・ディスパッチ手段（７３３）、マスター・データ・ストリーム処理手段（７３４）、ストリーム処理結果更新手段（７３５）、及び更新表示データ送信手段（７３６）を備えている。

【0261】

マスター・データ受信手段（７３１）は、データ受信手段（７１１）が受信したデータに対応し且つ欠損のないマスター・データ（７７２）を受信する。マスター・データ受信手段（７３１）は、マスター・データ（７７２）を、例えば全データを含むファイル（ファイルの保存形式は任意である）として受信する。

【0262】

また、マスター・データ受信手段（７３１）は、図４に示すステップ４０２の処理を実行しうる。

【0263】

マスター・データ受信手段（７３１）は、図７Ａに示すデータ受信手段（７１１）と同じであってもよい。

【0264】

欠損検証手段（７３２）は、マスター・データ受信手段（７３１）が受信したマスター・データ（７７２）と、欠損可能性検出手段（７１５）により検出された上記欠損の可能性のある部分（７８４を参照）とを比較し、上記欠損が存在することを検証する。

【0265】

また、欠損検証手段（７３２）は、上記欠損が存在することに応じて、当該欠損を、例えば欠損履歴を蓄積するデータ（欠損履歴データ）（７８３を参照）に記録する。

【0266】

また、欠損検証手段（７３２）は、図４に示すステップ４０３〜４０７及び４１１の各処理を実行しうる。

【0267】

マスターデータ・ディスパッチ手段（７３３）は、マスター・データ受信手段（７３１）が受信したマスター・データ（７７２）を使用して、受信データ・ストリーム処理手段（７１２）によるストリーム処理で得られた結果を更新する為に、当該マスター・データ（７７２）を、オペレーター群デプロイ手段（７２２）によりデプロイされた第２のストリーム処理ラインにディスパッチする。

【0268】

また、マスターデータ・ディスパッチ手段（７３３）は、図４に示すステップ４０８の処理を実行しうる。

【0269】

マスター・データ・ストリーム処理手段（７３４）は、マスター・データ受信手段（７３１）が受信したマスター・データ（７７２）の処理（原則的にストリーム処理であるが、シリアライズ処理を実行することもありうる）を、第２のストリーム処理ラインを再配置してデプロイされた第２のストリーム処理ライン（７６２を参照）において実行する。マスター・データ・ストリーム処理手段（７３４）は、その処理結果を、例えば当該処理結果を格納する記録媒体（７８９）に格納しうる。

【0270】

また、マスター・データ・ストリーム処理手段（７３４）は、上記欠損が存在することに応じて、当該欠損がある部分から生じた結果を更新するように、上記マスター・データ（７７２）を処理する。

【0271】

また、マスター・データ・ストリーム処理手段（７３４）は、データ受信手段（７１１）が受信したデータをリアルタイムにストリーム処理する。また、受信データ・ストリーム処理手段（７１２）は、データ受信手段（７１１）が受信したデータのストリーム処理を、１つの処理単位である１つのオペレーターを複数組み合わせて構成された第１のストリーム処理ラインにおいて実行する。

【0272】

また、マスター・データ・ストリーム処理手段（７３４）は、図４に示すステップ４０９において、上記ディスパッチされたマスター・データ（７７２）を上記第２のストリーム処理ラインを使用して処理し、当該マスター・データ（７７２）の処理結果を得る処理を実行する。

【0273】

また、マスター・データ・ストリーム処理手段（７３４）は、図７Ａに示す受信データ・ストリーム処理手段（７１２）と同じであってもよい。

【0274】

ストリーム処理結果更新手段（７３５）は、マスター・データ受信手段（７３１）が受信したマスター・データ（７７２）を使用して、受信データ・ストリーム処理手段（７１２）によるストリーム処理で得られた結果（７８１を参照）を更新する。ストリーム処理結果更新手段（７３５）は、マスター・データ・ストリーム処理手段（７３４）により処理された処理結果（７８９を参照）を読み出し、当該読み出した処理結果で、受信データ・ストリーム処理手段（７１２）によるストリーム処理で得られたストリーム処理結果（７８１を参照）を更新する。当該更新は、受信データ・ストリーム処理手段（７１２）によるストリーム処理で得られたストリーム処理結果（７８１を参照）をマスター・データ・ストリーム処理手段（７３４）により処理された処理結果（７８９を参照）で修復するものでもある。

【0275】

また、ストリーム処理結果更新手段（７３５）は、マスター・データ・ストリーム処理手段（７３４）による処理により得られた結果で、受信データ・ストリーム処理手段（７１２）によるストリーム処理で得られた結果を更新する。

【0276】

また、ストリーム処理結果更新手段（７３５）は、受信データ・ストリーム処理手段（７１２）によるストリーム処理で得られた結果と、マスター・データ・ストリーム処理手段（７３４）による処理により得られた結果との差分を算出して、受信データ・ストリーム処理手段（７１２）によるストリーム処理で得られた結果を上記算出した差分で修復しうる。

【0277】

また、ストリーム処理結果更新手段（７３５）は、データ受信手段（７１１）が受信したデータが少なくとも１つのセンサからの測定値である場合に、上記ストリーム処理した結果のうち上記収集間隔の違いによる欠損から生じた結果を、上記マスター・データ（７７２）を処理して得られた結果で更新する。

【0278】

また、ストリーム処理結果更新手段（７３５）は、上記更新した結果を、例えば更新結果を格納する記憶媒体（７９０）に格納しうる。また、ストリーム処理結果更新手段（７３５）は、更新状況を示すレポートを、例えば当該更新状況を示すレポートを格納する記憶媒体（７９１）に格納しうる。

【0279】

また、ストリーム処理結果更新手段（７３５）は、更新状況を示すレポートをリアルタイムで更新する。当該更新状況を示すレポートは例えば、処理毎に、上記更新が終了したこと、上記欠損が存在しなかったこと、又は、上記更新の終了予定時刻若しくは上記更新の進捗割合を含む。

【0280】

また、ストリーム処理結果更新手段（７３５）は、上記更新の為に許容される処理時間内に、上記更新を終了することが出来ない場合には、当該更新処理を中止し、当該中止した時点で更新されなかった結果にマーク付けする。

【0281】

また、ストリーム処理結果更新手段（７３５）は、図４に示すステップ４０９において、図２Ａのステップ２０３に示すストリーム処理で得られた結果を、マスター・データ・ストリーム処理手段（７３４）による処理結果で更新する。

【0282】

また、ストリーム処理結果更新手段（７３５）は、図４に示すステップ４１０の処理を実行しうる。

【0283】

更新表示データ送信手段（７３６）は、ストリーム処理結果更新手段（７３５）により更新された処理結果及び／又は更新処理状況を、当該更新された処理結果及び／又は更新処理状況を要求するクライアント端末（７０４）に送信する。

【0284】

クライアント端末（７０４）は、更新表示データ受信手段（７４１）及び更新表示データ表示手段（７４２）を備えている。

【0285】

更新表示データ受信手段（７４１）は、更新表示データ送信手段（７３６）からの更新された処理結果及び／又は更新処理状況を受信する。

【0286】

更新表示データ表示手段（７４２）は、更新表示データ受信手段（７４１）が受信した更新された処理結果及び／又は更新処理状況を表示装置の画面上に若しくは印刷物として又はファイルとして出力する。

【0287】

（実施例）
自動車の性能評価において、決められたコース（例えば、自社のテスト走行用のサーキット又は自動車競技用のサーキット）でしか行えない走行テストがある。

【0288】

自動車メーカーの開発チームは、上記決められたコースを所定回数周回することにより自動車の性能評価を行う走行テストを予定している。当該走行テストでは、午前に１度目のテスト走行が行われ、当該１度目のテスト走行の終了後間もなく午後には１度目の走行テストの結果により再調整された車で２度目の走行テストが行われる。

【0289】

上記自動車は複数のセンサを備えており、テスト走行中に当該センサからのデータをリアルタイムに、無線ネットワークを介してリモート・コンピュータに送信可能である。ただし、上記決められたコース（特に、上記サーキット）を利用してデータを送信する場合には、上記決められたコースにおける通信は無線で安定していないこと、上記決められたコースに固有の経路（受信装置、格納装置、及び送信装置）で送られること、車が高速で走ること、通信する他の車がいること、他と共有している通信回線であり専用の回線でないことなどの理由によって、データが通信経路上で失われることがある。

【0290】

また、当該リモート・コンピュータは、無線又は有線ネットワークを介して、上記センサから受信したデータを本発明の実施態様に従うコンピュータ・システムに送信可能である。

【0291】

テスト走行をサポートする自動車開発チームは、テスト走行中に、上記コンピュータ・システムからの処理結果をリアルタイムに、当該自動車開発チームが所有するクライアント端末に受信することが可能である。当該自動車開発チームは、テスト走行中の種々の指示をドライバーやエンジニアに与える為に、上記処理結果をリアルタイムに受信することが必要である。

【0292】

午前の１度目のテスト走行が９時に始まったとする。

【0293】

上記自動車はリアルタイムに上記リモート・コンピュータにデータを送信する。また、上記リモート・コンピュータは、当該データを受信することに応じて、当該受信したデータをリアルタイムに上記コンピュータ・システムに送信する。

【0294】

上記コンピュータ・システムは、上記データを受信することに応じて、リアルタイムに当該受信したデータをストリーム処理する。また、上記コンピュータ・システムは、当該ストリーム処理をしながら、図２Ｂ〜図２Ｄに示すフローチャートに従って、当該受信したデータ中の欠損の可能性のある部分を検出し、またストリーム処理されたデータ中の欠損の可能性のある部分を検出する。なお、当該受信したデータは、そのデータの一部が伝送経路で欠損しているとする。

【0295】

また、上記コンピュータ・システムは、上記ストリーム処理の結果（例えば、測定値観測、アラート解析、相関解析や傾向分析を含みうる）を、例えば上記リモート・コンピュータを介して、上記クライアント端末にリアルタイムに送信する。当該ストリーム処理の結果は、上記受信したデータに上記欠損があることから、仮の結果であるといえる。

【0296】

上記自動車開発チームは、上記クライアント端末の表示装置上で上記仮の結果（テスト走行中の結果）を見ながら、種々の指示をドライバーやエンジニアに与えることが可能である。

【0297】

午前のテスト走行が１１時半に終了したとする。

【0298】

上記自動車開発チームは、上記センサからのデータ（マスター・データである）を安全な方法で（例えば、ＵＳＢメモリなどの物理記録媒体を介して）、上記自動車から取り出す。そして、当該取り出したデータは例えば、安定した通常のインターネット回線を介して、上記コンピュータ・システムに送信される。

【0299】

上記コンピュータ・システムは、午前の１度目のテスト走行が終了したことに応じて、図２Ｂ〜図２Ｄに示すフローチャートに従って、上記ストリーム処理で用いたストリーム処理ラインのオペレーターを再配置し、再配置されたオペレーターをデプロイする。

【0300】

午後の２度目のテスト走行が１２時から開始されるとする。

【0301】

上記コンピュータ・システムは、午前の１度目のテスト走行が終了した後の限定された時間（例えば、１０分〜２０分）内に、図４に示すフローチャートに従って、上記マスター・データを使用して、上記ストリーム処理で得られた結果を更新する必要がある。また、上記コンピュータ・システムは、上記更新の為に、午前の１度目のテスト走行２時間分のデータを２時間で解析できるのに十分なシステム・リソースを与えられている。当該限られたシステム・リソースは、午前の１度目のテスト走行２時間分のデータを２時間で解析するには十分であるが、午前の１度目のテスト走行２時間分のデータのマスター・データ（すなわち、２時間分のデータ）を上記限られた時間で解析するには、限定されたシステム・リソースである。

【0302】

上記コンピュータ・システムは、限定された時間内及び限定されたシステム・リソースを用いて、午後の２度目のテスト走行が開始される前に、当該更新された結果を上記自動車開発チームに送信する。当該更新された結果は、欠損のないマスター・データを使用して仮の結果を更新していることから、最終の結果であるといえる。

【0303】

上記自動車開発チームは、午後の２度目のテスト走行が開始される前に、上記最終の結果を受信する。上記自動車開発チームは、上記クライアント端末の表示装置上で上記最終の結果を見て、午後の２度目のテスト走行に対する対策を考える。

【0304】

本発明の実施態様に従うと、上記の通り、上記自動車開発チームは、午前の１度目のテスト走行が終了し且つ午後の２度目のテスト走行が開始される前の限られた時間内に、欠損を含むデータをストリーム処理することによって得られた仮の結果ではなく、欠損のないマスター・データを使用して更新された最終の結果を受け取ることが可能になる。従って、上記自動車開発チームは、当該最終の結果に基づいて、午後の２度目のテスト走行における種々の指示をドライバーやエンジニアに与えることが可能になる。

【0305】

上記実施例では、自動車開発におけるテスト走行を取り上げたが、例えば、飛行機開発におけるテスト飛行、電車（例えば、新幹線やリニアモーターカー）におけるテスト走行においても本願発明の上記実施態様が適用可能なことは当業者に明白である。同様に、サーキットで行われる自動車競技においても本願発明の上記実施態様が適用可能なことは当業者に明白である。

【図1A】

【図1B】

【図2A】

【図2B】

【図2C】

【図2D】

【図3A】

【図3B】

【図4】

【図5A】

【図5B】

【図5C】

【図6A】

【図6B】

【図7A】

【図7B】

【図7C】