JP2016527575A - 複数のソースからのメッセージ情報を弾性的に処理する装置、システムおよび方法 - Google Patents

Abstract

メッセージ処理システムの待ち時間を都合が良ければ改善し、複数のメッセージソースから受信されたメッセージストリームから生成された統合メッセージストリームの正確さを向上する弾性的メッセージ追跡装置および方法が提供される。全てのメッセージストリームの実際の待ち時間が所定の待ち時間値よりも低い状況において、弾性的メッセージ追跡装置および方法は該待ち時間を低減する。【選択図】図４

Description

優先権に係る出願
本願は、２０１３年５月３１日に出願された米国特許仮出願第６１／８２９，５４５号の優先権の利益を享受する。その出願の内容は、参照により本明細書に組み入れられる。

本願は監視システムの技術分野に関し、特に複数のメッセージソースからのメッセージの追跡に関する。

ひとつの例示的なタイプの監視システムはマーケット監視システムを含む。マーケット監視システムは典型的には異なる多くのデータソースからデータを取得する。典型的には、それらのソースからの入来データメッセージフィードはお互いに同期していない。関心イベントに至るまでの一連のアクションの正確な情勢を構築するためには、入来データフィードのそれぞれのメッセージは統合データフィードを生成するよう正しい順序で並べられなければならない。

追加的なデータが想定されずその日の全てのメッセージが完全に受信された時点であるその日の終わりにおいては、メッセージを容易に正しく並べ替えることができる。しかしながら、依然として入来メッセージが存在する状態では、特定のタイムスタンプを持つ全てのメッセージが受信されたかについては定かではないので、実時間に近い処理についてメッセージを並べ替えることはより複雑である。

入来マーケットデータフィードに関して、データメッセージの並び替えの複雑さに影響を与えうる多くの問題が共通して見られる。そのような問題は以下を含む。
（ｉ）タイムスタンプの欠如−いくつかのメッセージがタイムスタンプを有さない場合がある。
（ｉｉ）タイムスタンプの粒度がばらばら−いくつかのメッセージは他のものと比べた場合に異なる粒度のタイムスタンプを有しうる。例えば、注文および取引タイムスタンプはマイクロ秒精度を有し、一方取引取消は秒精度のみを有する。
（ｉｉｉ）時間的順序が正しくない−いくつかのデータフィードは時間的に並べられ、メッセージは見た目ランダムな時間順序で到着しうる。ある場合では、いくつかのメッセージは分単位で「遅れ」うる。
（ｉｖ）論理的順序が正しくない−メッセージは論理的な並びから外れて到着しうる。例えば、取引に先行すべき両方の注文メッセージの前にその取引メッセージが到着する。
（ｖ）データフィードの待ち時間−各データフィードにおける待ち時間は以下のような種々のソースから導入されうる。
（ａ）（取引エンジンから処理宛先への）伝送待ち時間。
（ｂ）過大なシステム負荷、特にピーク期間中のもの。
（ｃ）データ前処理または変換動作、特にデータの並べ直しを含むもの。
（ｄ）ひとつ以上のデータフィードが中断されることによりそのフィードが利用不可となる一方、他のデータフィードは利用可能のまま維持されること。

したがって、メッセージの順序の正確さとメッセージ処理待ち時間、すなわちデータメッセージがどれほど実時間に近く処理されるか、との間にはトレードオフが存在する。

いくつかのマーケット監視システムは、トランザクションストリームをビジネスルールに対して評価することにより、取引データ中の関心パターンを特定する。典型的には、ルールはイベント駆動型である。トランザクションイベント（例えば、注文エントリ、注文修正、取引など）は既存のマーケット情勢のコンテキストにおいて調べられ、その取引イベントが関心対象であるかが判定される。特定のイベントの時点におけるマーケットの状態のスナップショットが正確であることを確実にするため、入来トランザクションは正しい時間的および論理的順序で処理されなければならない。

例えば、証券の異常な値動きや取引量が値に影響するニュースの発表の直前に起こった場合、それはインサイダ取引を示しうる。インサイダ取引警告のトリガイベントはそのニュースの発表の出現であり得る。ニュース発表の時点で、そのニュースの発表に至るまでの期間中のその証券についてのトランザクションが異常なパターンについて調べられる。しかしながら、そのニュースの発表の前に起こったトランザクションがデータフィードの中で誤って並べられた結果、それがそのニュースの発表の後に現れることとなった場合、そのトランザクションは警告を生成しないであろう。言い換えると、そのニュース発表トリガイベントが起こった時点で警告ルールが評価されるときには、警告をトリガすべき該トランザクションは存在しないであろう。

マーケット監視システムは「後方追跡（ｂａｃｋ ｔｒａｃｋ）」しないし、順序が乱れたトランザクションが受信されたときにトリガ条件を再評価することもない。例えば、その順序が乱れたトランザクションによってどのトリガ条件が影響を受けるかを特定するのは困難である。さらに、一般的にデータが時間的に誤って並べられている場合、順序が乱れたトランザクションが受信されるたびに戻ってルールを再評価することは、通常法外に計算コストが高い。

マーケット監視システムが異なるデータソースからの複数のデータフィードを含むマーケットにおけるメッセージの決定論および順序通りの処理を改善することができれば、有利であり得る。ひとつのアプローチは、全ての成分データフィードが各データフィード内ですでに時間的に正しく並べられていると仮定することであろう。上流のデータフィードが時間的順序にない場合、監視システムがデータフィードを読んで異なるデータフィードからのメッセージをインターリーブする前にデータフィードを並べ直すことを確実にするための中間処理が挿入されうる。

例えば、規則的に生成される（例えば周期的な）タイミング信号（本願の非限定的な例示的実施の形態において「メトロノームフィード」と称される場合がある）を使用して、データフィードからのメッセージの処理に所定量の待ち時間を導入し、より正確なデータメッセージ監視または追跡を生成することができる。規則的に生成されるタイミング期間または周波数は、規則的に生成されるタイミングフィードのタイミングメッセージ（本願の例示的実施の形態において「鼓動（ｈｅａｒｔ ｂｅａｔ）」メッセージと称される場合がある）の間の間隔を決める。規則的に生成されるタイミングフィードは、設定可能な期間だけ実時間から遅れるインクリメントされるタイムスタンプのフィードを含みうる。メッセージ追跡はメトロノーム時刻までのメッセージのみを処理する。これはフィードを遅らせる。

これは図１に示される例で説明される。図１では、メッセージは規則的に生成されるタイミングフィードの順序で読まれる。規則的に生成されるタイミングラグまたは遅延期間は、マーケットで使用されるデータフィードにおいて想定されるラグに基づいて設定されてもよい。追跡の正確さはラグ期間が大きいほど向上する。上流処理が要求されたメッセージを送信しなければならない期間が長いほど、そのメッセージが順序から外れて読まれることとならない確率は高くなる。

図２は、より低い待ち時間設定のもと、メッセージが順序から外れて読まれる例を示す。規則的に生成されるタイミングラグ期間がより短い場合、あるフィードの遅延（理由が何であれ）によりメッセージが順序から外れて処理されるリスクが高まる。したがって、任意に低いラグ期間は監視システムがイベントに関するパターンを検出して監視アナリストや他の監視者に警告するのを妨げうるので、設定されるタイミングフィードラグを任意に低くすることは通常薦められない。したがって、正確な順序付け（例えば、パターンを正確に検出できるような）と最大の処理待ち時間との間のもっともなトレードオフであると考えられるものにしたがって、ラグ期間を設定（構成）してもよい。しかしながら、上述の通り、そのようなラグを設定すると全てのデータメッセージフィードに対して固定の処理待ち時間が導入される。

タイミングフィードベースのアプローチでマーケットにおいて処理することは「ぎくしゃく（ｊｅｒｋｙ）」するものでありうる。不可避の中断および引き続く処理バーストが生じうるからであり、これは、監視装置が規則的に生成されるタイミングフィード上で次に利用可能なメッセージを待ち、それが読むことを許されている全てのメッセージを処理し、次に規則的に生成されるタイミングフィード上で次に利用可能なメッセージを待つからである。規則的に生成されるタイミング期間はマーケット内の処理のぎくしゃく度合いを決定する。規則的に生成されるタイミング期間は、マーケット内の時間進行の最大粒度を決定するのに使用されうる。しかしながら、規則的に生成されるタイミング期間が短い（例えば、１ｍｓ）と、メモリディスク書き込み動作で消費される入出力動作の数のためにストレージサブシステムに対して不必要に大きな負荷がかかりうる。監視対象のデータがストレージメモリに書き込まれることなくストリームされるシステムでは、規則的に生成されるタイミング期間が短いとネットワーク過負荷の問題が生じうる。

メッセージ処理システムの待ち時間を都合が良ければ改善し、複数のデータメッセージソースから受信されたデータメッセージストリームから生成された統合データメッセージストリームの正確さを向上する弾性的メッセージ追跡装置および方法が提供される。全てのデータメッセージストリームの実際の待ち時間が所定の待ち時間値よりも低い状況において、弾性的データメッセージ追跡装置および方法は該待ち時間を低減する。

電子データメッセージ処理装置は、複数のデータメッセージソースからデータメッセージを受信するデータメッセージフィードポートと接続された処理回路を含む。各データメッセージソースは対応する時系列のデータメッセージを生成する。複数のメッセージフィードポートで受信されたひとつ以上のデータメッセージはその対応する時系列から外れて受信される。処理回路は、入来データメッセージフィードポートにおいて受信されたデータメッセージを、データメッセージ処理待ち時間に基づいて処理する。複数のデータメッセージフィードポートから受信されたデータメッセージに統合時系列を提供するようデータメッセージ処理待ち時間が選択的に改められる。合成データメッセージストリームのデータメッセージが統合時系列でひとつ以上の宛先ポートに送信されるように合成データメッセージストリームが生成される。

例示的実施の形態では、処理回路は状態パラメータを検出し、状態パラメータが変わるまでに受信したデータメッセージを時系列にあるとして処理し、状態パラメータが変わった後に受信したデータメッセージを時系列から外れるとして処理する。データメッセージ処理待ち時間は検出された状態に基づいて改められる。

電子データメッセージ処理装置における現在の実際の時刻とは別の基準時刻を使用して合成データメッセージストリームのデータメッセージが処理されてもよい。基準時刻と現在の実際の時刻との差は電子メッセージ処理システムの現在の待ち時間に関連付けられる。基準時刻は処理されたメッセージの進行に基づき変更される。

例示的な実施の形態では、時間的メッセージ系列から外れたメッセージが処理された場合に基準時刻が維持される。

別の例示的な実施の形態では、データメッセージフィードポートのうちのひとつが非アクティブ状態にあると判定された場合、データメッセージフィードポートのうちのひとつが所定の回復期間内にアクティブ状態になると判定された場合には合成データメッセージストリームのデータメッセージが時間的順序で処理される。しかしながら、データメッセージフィードポートのうちのひとつが所定の回復期間外でアクティブ状態になると判定された場合には合成データメッセージストリームのデータメッセージが時間的順序から外れて処理される。非アクティブなデータメッセージフィードポートの判定に基づいて、該データメッセージフィードポートが非アクティブ状態にある間は基準時刻の進行が止められてもよい。

例示的な実施の形態は、データメッセージフィードポートのそれぞれで現在受信されている次のデータメッセージであって現時点で最も低いデータメッセージ時刻を有する次のデータメッセージのメッセージ時刻と基準時刻とを比較してもよい。データメッセージ時刻が基準時刻より小さい場合、該データメッセージを処理し該データメッセージフィードポートにおける次のデータメッセージを読む。あるいはまた、データメッセージ時刻が基準時刻より大きい場合、基準時刻をデータメッセージ時刻に合わせる。

例示的な実施の形態は、合成データメッセージストリームのデータメッセージを処理してひとつ以上の所定のパターンを検出し、該パターンに応じてひとつ以上の対応する警告データメッセージを生成してもよい。

例示的な実施の形態は、合成データメッセージストリームの受信されたがまだ処理されていないデータメッセージを、以前に処理されたデータメッセージの内容に基づいて処理してもよい。

取引向けの例示的な実施の形態では、データメッセージのうちのいくつかが電子的取引交換からのトランザクションパラメータに関係する場合、該トランザクションパラメータに基づいて、電子的取引交換のひとつ以上のオーダブック。統合時系列から外れた検出データメッセージを使用して、オーダブックが更新されてもよい。各受信データメッセージはタイムスタンプを含んでもよい。順番通りでない状態で受信されたひとつ以上のデータメッセージは、データメッセージのタイムスタンプに基づいて並べ直されてもよい。

例示的な実施の形態では、データメッセージフィードポートで受信された状態のデータメッセージは正規化されたデータフォーマットに変換される。

例示的なタイミング図である。

他の例示的なタイミング図である。

複数のソースからのメッセージ情報を弾性的に追跡し報告するための非限定的な例示的手順を説明するフローチャートである。（独立方法請求項をトラックするために生成される）

複数のソースからのメッセージ情報を弾性的に追跡し報告するメッセージ処理システムの非限定的な例示的実施の形態を示す。

例示的なデータフィード状態活動図である。

最大の待ち時間における追跡の例を示す図である。

最大の待ち時間における例示的な弾性的追跡プロセッサ可視化である。

非限定的な例示的弾性的追跡プロセッサの機能ブロック図である。

以下の記載では、説明を目的とし、限定を目的とせず、記載の技術の理解を提供するために、特定のノード、機能エンティティ、技術、プロトコル等の具体的な詳細が説明される。他の実施の形態を、以下の詳細説明から離れて実施できることは当業者には明らかであろう。他の例では、周知の方法、デバイス、技術等の詳細説明は、不必要な詳細説明で説明を曖昧にしないために省略されている。個々の機能ブロックが図に示される。これらのブロックの機能は、個別のハードウエア回路を使用して、適切なプログラム化マイクロプロセッサあるいは汎用コンピュータと協働するソフトウエアプログラムおよびデータを使用して、特定用途集積回路（ＡＳＩＣ）を使用して、および／または１つ以上のデジタル信号プロセッサ（ＤＳＰ）を使用して、実現可能であることを当業者は理解するであろう。ソフトウエアプログラムインストラクションおよびデータは、コンピュータ可読保持媒体に保持されてもよく、このインストラクションがコンピュータあるいは他の適切なプロセッサ制御によって実行されると、コンピュータあるいはプロセッサは機能を実行する。以下でデータベースはテーブルとして示されている場合があるが、他のフォーマット（リレーショナルデータベース、オブジェクトベースモデル、および／または分散データベースを含む）を、データを保持し操作するために使用することができる。

処理ステップ、アルゴリズムあるいはその類が特定の順序で記載またはクレームされている場合があるが、このような処理は、異なる順序で動作するように構成設定することができる。換言すれば、明示されるかクレームされるいかなるシーケンスあるいはステップの順序も、そのステップがその順序で実行される必要性を示すものでは必ずしもない。本明細書で記載される処理のステップは、取り得る任意の順序で実行されうる。また、いくつかのステップは、非同時的に発生するように記載されているあるいは暗示されているが（例えば、あるステップは、他のステップの後に記載されているからである）、同時に実行されうる。さらに、図面における図示による処理の説明は、図示される処理が他の変形や変更について排他的であることを暗示しているのではなく、また、図示される処理あるいはその任意のステップが本発明に必要であることを暗示しているのではなく、また、図示される処理が好ましいことを暗示しているのでもない。処理の説明はその処理を行う装置の説明である。処理を行う装置は、その処理を行うのに適切な例えばひとつ以上のプロセッサと入力デバイスと出力デバイスとを含んでもよい。

「データメッセージ信号」という用語は本明細書において、電気的形態、電子的形態、電磁気的形態、磁気的形態または光学的形態である位置や領域から他へ情報を送る任意の信号を包含するために使用される。データメッセージ信号はある位置や領域から他へ、電気的または磁気的導体により、光学導波管により、無線（ＲＦ、赤外等）で、他の信号伝送機構により、伝送されてもよい。一般に、データメッセージ信号の広いカテゴリは、アナログ信号およびデジタル信号の両方を含む。アナログ信号は、連続的に変化可能な物理量、例えば電圧の形態の情報を含む。デジタル信号は、物理特性の離散値の形態の情報を含む。これもまた例えば電圧でありうる。

コンテキストがそうでないと示す場合を除き、「回路（ｃｉｒｃｕｉｔｒｙ）」および「回路（ｃｉｒｃｕｉｔ）」という用語は本明細書では、ひとつ以上の電子部品が一緒に動作するか関連する態様で動作するのに十分な電気的接続を有する構成を指すために使用される。ある例では、回路のあるアイテムはひとつより多い回路を含んでもよい。プロセッサを含む回路のアイテムは、ハードウエアおよびソフトウエアコンポーネントを含む場合がある。ソフトウエアはプロセッサの動作を制御するかまたは動作中にプロセッサによってアクセスされる、保持されたまたは伝送されたデータを指す。ハードウエアは、データを保持し、伝送し、データで動作するコンポーネントを指す。しかしながら、いくつかのコンポーネントはソフトウエアおよびハードウエアの両方の特性を共有するので、ソフトウエアとハードウエアとの区別は必ずしもはっきりしない。所与のプロセッサで実現されるソフトウエアコンポーネントは多くの場合、回路の動作を大幅に変更することなく等価なハードウエアコンポーネントにより置き換えられ得る。また同様に、所与のハードウエアコンポーネントはソフトウエアにより制御される等価なプロセッサ動作により置き換えられ得る。

回路はその構成や他の特性に基づき構造的に記述されてもよい。例えば、制御動作を行うよう構成された回路は制御回路と称される場合があり、処理動作を行うよう構成された回路は処理回路と称される場合がある。

一般に、インタフェースやプロセッサやサーバやメモリや検出器やユーザインタフェースや他のアイテムはシステムに含まれてもよい。このシステムでは、それらは自動的に動作するか一部自動的に動作する。システムという用語および装置という用語は両方とも、一緒に動作を行うことができる２つ以上のパーツまたはコンポーネントの組み合わせを指す。システムおよび装置は、設定された動作により特徴付けられてもよい。

様々な形式のコンピュータ可読媒体は、プロセッサにデータ（例えば、インストラクションのシーケンス）を運ぶ際に含まれうる。例えば、データは、（ｉ）ＲＡＭからプロセッサへ送信されてもよく、（ｉｉ）任意のタイプの送信媒体（例えば、有線、無線、光等）を介して運ばれてもよく、（ｉｉｉ）イーサネット（登録商標）（あるいはＩＥＥＥ８０２．３）、ＳＡＰ、ＡＴＰ、ブルートゥース（登録商標）、ＴＣＰ／ＩＰ、ＴＤＭＡ、ＣＤＭＡ、３Ｇ等のような、多くのフォーマット、規格あるいはプロトコルに従ってフォーマットおよび／または送信されてもよく、および／または（ｉｖ）様々な方法の任意のものでプライバシーを確保するためにあるいは流出を防止するために暗号化されてもよい。

以下で説明される技術は任意のタイプの電子監視システムで使用されてもよい。本技術の一例としてのアプリケーションは、取引交換のためのマーケット監視システムである。取引交換のためのマーケット監視システムのコンテキストで詳細な例示的実施の形態が説明されるが、本技術はこれに限られない。

マーケット監視システムの非限定的例示的実施の形態はマーケットデータフィードの実時間監視を提供する弾性的トラッカ装置を含む。例えば金融商品エンジンや証券取引エンジンからのマーケットデータフィードなどのひとつ以上のデータフィードに接続することで、例示的なマーケット監視システムは生きたマーケットデータや実時間の警告や過去データ追跡や過去データの報告を提供する。

図３は、複数のデータメッセージソースからのデータメッセージ情報を弾性的に追跡するための非限定的な例示的手順を説明するフローチャートである。第１ステップＳ１は、メッセージフィードポートにおいて、複数の対応するメッセージソースからデータメッセージ信号（または単にデータメッセージ）を受信することを含む。各メッセージソースは時系列のデータメッセージを生成している。メッセージフィードポートで受信されたひとつ以上のデータメッセージはその対応する時間的メッセージ順序から外れて受信される。処理回路は、入来データメッセージフィードポートにおいて受信されたデータメッセージを、データメッセージ処理待ち時間に基づいて処理する（ステップＳ２）。複数のデータメッセージフィードポートから受信されたデータメッセージに統合時系列を提供するようデータメッセージ処理待ち時間が選択的に改められる（ステップＳ３）。合成データメッセージストリームのデータメッセージが統合時系列でひとつ以上の宛先ポートに送信されるように合成データメッセージストリームが生成される（ステップＳ４）。

図４は、複数のソースからのメッセージ情報を弾性的に追跡し報告する監視システムの非限定的な例示的実施の形態を示す。監視システム１０は、ゲートウェイ１２と、監視エンジン１４と、ユーザデバイス、例えばワークステーション１６ａ、…、１６ｎと、を含む。ゲートウェイ１２および監視エンジン１４は、例えばＬｉｎｕｘ（登録商標）サーバ環境で動作してもよい。それぞれは少なくともプロセッサと、メモリと、を備え、スケーラビリティおよび堅牢性を提供する。ユーザデバイス１６ａ、…、１６ｎはローカルＷｉｎｄｏｗｓ（登録商標）アプリケーションおよびクライアントアプリケーションを実行するパーソナルコンピューティングデバイスを含んでもよい。クラウドコンピューティングやクラウドストレージやクラウドサービスなどの他のデータ処理およびストレージ環境が使用されてもよい。

複数のデータフィードソース１８はゲートウェイ１２のひとつ以上の入力ポートにデータストリームを提供する。データフィード取得プロセッサ２２は、例えば取引交換システムの取引エンジンからのデータフィードやニュース収集者からのデータフィードなどの複数のデータフィードソース１８からのデータフィードを、取得する。異なるデータフィードが取得された場合、データメッセージは生のデータフォーマットでフィードごとにデータベース２４に格納されてもよい。ひとつ以上のデータフォーマットコンバータ２６は、フィードごとに該生データを共通データフォーマットのデータに変換し、変換されたデータをひとつ以上のデータベース、例えば３０、４０、４２に格納する。監視エンジン１４は、ひとつ以上のデータベースを用いて報告を生成し警告を検出する複数のコンピュータサーバ３４、３６および３８を含む。ワークステーション１６ａ、…、１６ｎのクライアントアプリケーションは、例えばアナリストなどのユーザがマーケットデータを監視し、上級の報告および可視化へと掘り下げることを可能とする。

好適ではあるが例示的な実施の形態では、異なるデータフィードからの堅牢なデータ取得および素早い構築を可能とするために、ゲートウェイ１２はモジュラデータ処理アーキテクチャを使用して構築される。監視システム１０は、例えば実時間フィード１８や日ごとのフラットファイルや周期的フラットファイル（両方とも静的ファイル２０として参照される）やネットワークリンクなどを含む外部システムおよびデータと接続する複数のインタフェースを含む。上記のコンテキストにおいて、フラットファイルは構造的な関係を伴わないレコードを含むデータファイルであり、基本的なフォーマットのみを含んでもよく、少数の固定数のフィールドを有してもよく、ファイルフォーマットの集合を有しても有さなくてもよい。実時間データフィードは日が進むにつれてライブかつ徐々に取得される。日ごとのフラットファイルは種々のフォーマットで受信されてもよく、典型的には１日１回配信される。周期的なフラットファイルは種々のファイルフォーマットで入来し、周期的かつ必要に応じて更新される。ネットワークリンクは監視エンジンコンピュータサーバ３４、３６および３８へのアクセスを容易にする。各ネットワークリンクは処理回路を使用して実現される。

ある例示的な実施の形態では、データフィード取得プロセッサ２２はフィードデータをディスクや他の保持媒体に格納する。データフォーマットコンバータ２６は生のフィードデータを処理し、好適にはデータフィードメッセージを正規化されたファイルフォーマットに変換する。ある例示的な実施の形態では、正規化されたファイルフォーマットは、例えば取引関係データなどの特定のタイプのデータの格納に対して最適化される。ある例示的な実施の形態では、正規化されたファイルフォーマットのデータは、統合データベース３０に出力され、そこで保持される。該データベース３０は高性能スケーラブルデータベースであってもよい。クライアントアプリケーションに対する最適化を含むファイルであって実時間のワークステーション／クライアント接続のために使用される基礎的なデータ構造であってもよいファイル（例えば、ＲＥＭＳ、ＤＡＹＴＯＴ、ＮＥＷＳ）を保持するためのオプションの副データベース４２が設けられる。

データフォーマットコンバータ２６は、データフィードからのデータメッセージを処理し、必要であれば下流での処理で使用される前にそれを時間的順序に並べ直すよう構成される。

監視エンジン１４は、警告処理サーバ３８と、実時間および１日の終わりサーバと、を含む。警告処理サーバ３８は統合データベース３０に保持される変換ファイルを読み出し、警告を生成および処理する。該サーバ３８は警告データベース４０に該警告を格納してもよい。報告サーバ３４、主および副データベース３０および４２、および警告データベースからの情報は、データアクセスインタフェース４４を介して、クライアントワークステーション１６ａ、…、１６ｎへと提供され、および／またはそれらによりアクセス可能である。

データベースデーモンは典型的には種々のユーティリティ機能を実行するネットワークプログラムであり、ワークステーション１６ａ、…、１６ｎのクライアントアプリケーションが統合データベース３０にアクセスすることを可能とする。これにより、例示的なクライアントアプリケーションプログラムスイート（例えば、コンピュータプログラムベースのツールの集合）は便利な監視監督機能および／または特徴を提供することができる。そのような機能および／または特徴は、例えば警告ダッシュボードや警告生成やデータ可視化やマーケットリプレイや警告の完全な報告やニュースおよび取引活動を含む。加えて、フィードが中断した場合やリンクが失敗した場合にスムーズに復帰することを確実にするための初期化および再起動のための制御ソフトウエアが、好適には、クライアントワークステーション１６ａ、…、１６ｎに提供される。

好適には、システム１０は、リンク停止やシステム停止が起こった場合でも堅牢なデータバックアップおよび回復を提供するための、データ冗長化およびフェールセーフ性能を含む。例えば、２つの物理的なサーバロールアウトが提供され、一方は主サイトとして、他方は副サイトとして提供されてもよい。主サイトで障害が起きた場合には、クライアントワークステーションは副サイトに接続してデータ解析を続けてもよい。

任意の時点で、統合データベース３０に保持される変換ファイルの異なるもの同士は、以下の例示的な理由のうちのひとつ以上により、時間的に同期から外れている可能性がある。
１．取引プラットフォームからリスナへのトランザクションメッセージの伝送において発生した待ち時間、
２．種々の入力フィードで異なる待ち時間、
３．コンバータの並べ替えロジックにより導入された遅延、および／または
４．過度のコンバータ負荷、特にピーク期間中のそれ、により生じた待ち時間。

イベントを正確かつ信頼性高く監視するためには、関連する一連のアクションの正確かつ信頼性の高い情勢が確立されなければならない。関心イベントに至るまでの一連のアクションの正確な情勢を確立するためには、入来データフィードのそれぞれのメッセージは合成データフィードを生成するよう正しい時系列でインターリーブかつ処理（例えば、追跡）されなければならない。時系列という用語は、時間的順序および論理的順序の両方を包含する。これはひとつ以上の追跡プロセッサにより取り扱われる。

ひとつの例示的な実施の形態は図５で説明される監視システムに示される。取得プロセッサ２２ａ、ｂ、…、ｎは例えば取引フィードや他の任意のタイプのデータフィードなどのデータフィードから実時間データを取得することを担当する。各取得プロセッサ２２ａ、ｂ、…、ｎは、それとデータフィードとの接続が成功した場合、生のデータファイルを生成する。例示的な取引アプリケーションでは、これは取引日か非取引日かに関わらず生じる。フィードからのメッセージが到着すると、そのメッセージは現在の日付の生データファイルに追加される。各取得プロセッサ２２ａ、ｂ、…、ｎは予め定義されたスケジュールにしたがって起動および停止される。各取得プロセッサ２２ａ、ｂ、…、ｎは、予定されていないスケジュールの時間変更や障害シナリオを軽減するために手動で制御されてもよい。上述の通り、各データフォーマットコンバータ２６ａ、ｂ、…、ｎは、データメッセージが順序から外れて受信された場合、メッセージのタイムスタンプにしたがいデータフィードのデータメッセージを並べ直す。

データが各フォーマットされたファイル内で正しく並べられると、それらのファイルは時間順で一緒に処理（追跡）されなければならない。合成データメッセージストリームの統合時系列、例えば取引交換のマーケット監視システムアプリケーションにおけるマーケットの「情勢」的なもの、を生成するためである。警告処理サーバ３８はひとつ以上の弾性的追跡プロセッサ５０を含む。弾性的追跡プロセッサ５０は、データフォーマットコンバータ２６ａ、２６ｂ、…、２６ｎによって提供されるファイル３０ａ、３０ｂ、…、３０ｎからのフィードストリーム１、２、…、ｎをインターリーブして合成データメッセージストリームを生成する。この非限定的な取引の例では、合成データメッセージストリームはオーダブックメモリ５２に提供される。オーダブックメモリ５２では、異なる金融商品の取引ごとに異なるオーダブックが維持される。合成データフィードのデータメッセージを処理することにより、弾性的追跡プロセッサ５０は例えばマーケットの各アクションおよびトランザクションを監視するために使用されてもよい。弾性的追跡プロセッサ５０は追跡対象マーケットで取引される各金融商品についてのオーダブックを維持し、合成データフィードに利用可能な処理すべきメッセージが現れるとすぐにオーダブックを更新してもよい。

合成データメッセージフィードを使用して、例えば関心のある性質や疑わしい性質の異なる複数のパターンなどの種々の予め設定されたパターンを検出してもよい。合成データメッセージストリームはひとつ以上の警告プロセッサ５４に提供される。ひとつ以上の警告プロセッサ５４は警告規則メモリ３２に保持される警告規則にしたがって合成データメッセージストリームを解析する。警告プロセッサ５４が合成データメッセージストリームにひとつ以上のパターンを検出すると、対応する警告メッセージ４０が生成され、外部インタフェース４４を介してクライアント１６ａ、…、１６ｎに出力されてもよい。外部インタフェースは警告を含むデータメッセージを、ユニキャストによりクライアントへ送信してもよく、またはマルチキャストやブロードキャストによりいくつかのクライアントに送信してもよい。

ある例示的な実施の形態では、弾性的追跡プロセッサ５０は、対応するオーダブックにトランザクションを入れて取引交換システムにおいて通常なされるように処理することにより、受信された順序から外れたトランザクションを取り扱う。

弾性的追跡プロセッサ５０は、例えば金融マーケットデータフィードなどの複数のデータフィードからのデータの合成データメッセージストリームへの実時間に近いマージという課題を解決する弾性を提供する。ここで合成データメッセージストリームの時間的順序および論理的順序の両方は正しいものである。弾性的追跡プロセッサ５０のひとつの有利な特徴は、不利なデータフィード条件への適合性および応答性である。例えば、弾性的追跡プロセッサ５０の処理待ち時間は、最も遅いデータフィードに照らして最適な動作点に維持される。最適な状況下では、弾性的追跡プロセッサ５０はメッセージをできる限り速く処理する。ひとつ以上のデータフィードが利用不可になった場合、弾性的追跡プロセッサ５０は処理待ち時間を徐々に導入することにより、合成フィードが正しく並べられる状態が維持されることを確実にする。弾性的追跡プロセッサ５０はデータフィードが復活すると、導入された待ち時間を除去する。これは、追跡プロセッサ５０の弾性的特徴の一例である。

弾性的追跡プロセッサ５０は、実時間処理の停止が許可される最大期間をデータフィード停止期間が超えない限り、合成データメッセージストリームの正しい時系列を維持する。ここで図１および図２を参照すると役に立つであろう。フィード停止許容値は、あるデータフィードは他のものより重要であるという現実を反映するべく、フィード毎に設定されてもよい。例えば、主たるマーケットの注文および取引を含むデータフィードが利用不可であるか遅れている場合、他のデータフィードを処理し続けることに意味はないであろう。

弾性的追跡プロセッサ５０は、全ての入来データフィードからのメッセージを読んでそれらを正しい順序で処理することにより、本例（または他のアプリケーションにおける他の複数入力状況）において監視されているマーケットの融合的なまたは包括的な情勢を作り上げる。弾性的追跡プロセッサ５０は以下のタスクを実行する。これは例としてのマーケット監視システムにおいてマーケット活動を「追跡」すると総称される。まず、弾性的追跡プロセッサ５０はデータフィードからのメッセージを読み、利用可能なメッセージのリストから次に処理するのが適当なメッセージを決定し、以前のトランザクションのコンテキストにおいて入来メッセージを処理する。これは例えば取引交換の例では、現在のトランザクションの結果としてマーケットのオーダブックの状態を更新することである。

警告プロセッサ５４は追跡されているか監視されている現在のトランザクションのタイムスタンプに基づいて、マーケットにおける現在時刻を維持する。この現在時刻は「マーケット時刻」と称される。マーケット時刻は、例えば実時間でないデータなどの過去のデータで警告規則が実行されている場合において特に、現在のシステム時刻とは異なりうる。マーケット時刻は、例えば現在のトランザクションが時間的に順序から外れている場合、現在のトランザクションのタイムスタンプとは異なる。マーケット時刻は、実際の経過システム時刻より速く進む場合もあれば、遅く進む場合もある。マーケット時刻が進む速さは、入来データフィードからのメッセージ配信レートおよびそのメッセージを処理するためのシステムリソースの可用性に依存する。

メモリ３２に保持される警告規則は例えば警告プロセッサ５４により実行され、１日のうちの特定の時刻に、または所定間隔で、トリガされる。これらの規則はマーケット時刻のコンテキストで評価される。例えば、「１３：００に」は、マーケット時刻が１３：００になったときにその規則が評価されるべきであることを意味してもよい。実際のシステム時刻は１３：００でなくてもよい。他の例では、「１０分ごとに」は、マーケット時刻で１０分が経過するたびにその規則が評価されるべきであることを意味してもよい。実際のシステム時刻の変化は１０分以上または以下であってもよい。

弾性的追跡プロセッサ５０は時刻は前方にのみ進むことを前提とする。入来メッセージが時系列から外れる場合、その順序から外れたメッセージを処理する際に、追跡プロセッサ５０は後ろ向きに追跡して時間的に後方に移動することはない。順序から外れたメッセージを使用してオーダブック５２が更新されるが、マーケット時刻は「後ろ向きに」動くよう更新されることはない。これは、その順序から外れたメッセージがトリガ条件を含む場合、その条件は現在のマーケット時刻のコンテキストで評価されるのであり、順序から外れたメッセージのタイムスタンプで評価されるのではないことを意味する。また、これは、その順序から外れたメッセージの時点で存在する他のメッセージやフィードからのトリガ条件は追加的なデータのコンテキストで再評価されないことを意味する。これにより、非決定論的な実時間警告挙動が生じうる。全てのメッセージが正しい時系列で読まれるよう利用可能となる後の時点で同じデータ集合について警告プロセッサ５４により警告規則が再実行された場合、異なる、「欠けていた」、または追加的な警告が生成されるかもしれない。

追跡プロセッサ５０は、データフィードが一時的に利用不可となり後に回復する状況を扱うことができる。「フィード回復ウィンドウ」は、影響を受けたデータフィードが回復するのを「待つ」間処理を一時停止した状態で経過することが許される期間である。影響を受けたデータフィードがウィンドウ内で回復した場合、処理は、（まるで一時的な利用不可が起こらなかったかのように）正しく並べられたメッセージで続けられる。影響を受けたデータフィードがこの期間内に回復しなかった場合、処理は他の利用可能なデータフィードにおいて続けられる。影響を受けたフィードが回復した場合にメッセージは順序から外れて処理される。「フィード回復ウィンドウ」はｆｅｅｄ−ｉｄｌｅ−ｔｉｍｅｏｕｔと称され、入来データフィードごとに異なるように設定可能である。

図６の例示的なコンピュータフロー図に示されるように、データフィードは以下の状態のうちのひとつをとってもよい。

非アクティブフィードはマーケット時刻が進むのをブロックする。ひとつ以上のフィードが非アクティブである場合、マーケット全体が支配的なマーケット時刻においてブロックされる。全ての非アクティブフィードが他の状態に遷移するまで、メッセージ時刻がマーケット時刻よりも小さい場合にのみそのメッセージを処理する。メッセージは現在のマーケット時刻を超えて処理されてはならない。ｆｅｅｄ−ｉｄｌｅ−ｔｉｍｅｏｕｔに達するまでは、メッセージが前に終わったところから続けられることが期待されており、そのようなメッセージは順序通りに処理されなければならないからである。

好適ではあるが例示的な実施の形態では、メッセージは一度にひとつずつ読まれ、処理される。各データフィードは、以下の事項に基づいて状態を維持する入力ストリームとして受信される。（１）次のメッセージが利用可能か否か、（２）（メッセージが利用可能な場合）フィード上の次の利用可能なメッセージのタイムスタンプ、および（３）それがフィード上でどこにあるか（バイトまたはメッセージｎ）。本例示的な実施の形態では、状態は、単一のメッセージの先読みバッファとして維持される。メッセージがない場合、時刻は好適には（必須ではないが）利用可能な最小の時間分解幅の単位で進む。

使用可能な設定パラメータの例示的なリストは以下の通りである。システム時刻への参照は、オペレーティングシステムとマーケットとのタイムゾーンの違いを説明する。
設定パラメータ

例示的な弾性的追跡動作を実行する際に弾性的追跡プロセッサ５０により実行されてもよい例示的な手順の集合は以下の通りである。追跡プロセッサ５０はシステム時刻を使用してフィード回復ウィンドウ内でどの程度時間が経過したかを計算する。
１．ゼロの開始状態を仮定する。すなわち、リードバッファにはメッセージはない。監視されるデータフィードから最初のメッセージを読む。利用可能なメッセージを有さないフィードは、バックグラウンドにおいて＜ｆｅｅｄ−ｐｏｌｌ−ｆｒｅｑ＞で新たなメッセージについてポーリングされる。
２．全てのデータフィードが利用可能なメッセージを有する場合の次のメッセージループ：
ａ．前にメッセージを有さなかったフィードが今は利用可能なメッセージを有する場合、そのフィードについてのタイマを止める。
ｂ．最も低いメッセージ時刻（ｔ）を伴うメッセージを処理する。２以上のフィードが同じメッセージ時刻を有する場合、最も低い＜ｆｅｅｄ−ｐｒｅｃｅｄｅｎｃｅ＞からのメッセージが使用される。
ｃ．このフィードから次のメッセージを読み出してバッファに入れる。
ｄ．（メッセージ時刻（ｔ）＞マーケット時刻）の場合、マーケット時刻はｔへと移る。
３．ひとつ以上のフィードが利用可能なメッセージを有さない場合の次のメッセージループ：
ａ．前にメッセージを有さなかったフィードが今は利用可能なメッセージを有する場合、そのフィードについてのタイマを止める。
ｂ．（利用可能なメッセージを有するフィードのそれぞれの次のメッセージから）最も低いメッセージ時刻（ｔ）を取得する。２以上のフィードが同じメッセージ時刻を有する場合、最も高い優先性を有するフィードからのメッセージが使用される。
ｃ．（メッセージ時刻（ｔ）≦マーケット時刻）の場合、このメッセージを処理し、このフィードから次のメッセージを読み出しバッファに入れる。
ｄ．（メッセージ時刻（ｔ）＞マーケット時刻）の場合、これは、メッセージ時刻≦マーケット時刻の状況で全てのメッセージが読まれたことを暗示する。ｆｅｅｄ ｉｄｌｅ ｔｉｍｅｏｕｔは、最後のメッセージがフィードから処理された時刻（メッセージ処理時刻）に対するものである。しかしながら、次のメッセージを処理するか否かはメッセージ時刻に対するものである。利用可能なメッセージを有さない各フィードについて、
ｉ．０：０：０．０００からタイマを開始する。このタイマは０で開始されなければならない。ｆｅｅｄ−ｉｄｌｅ−ｔｉｍｅｏｕｔは常にゼロベースであり、このタイマから到達されるものであるからである。ｍａｒｋｅｔ−ｔｉｍｅ＠ｔｉｍｅｒ−ｓｔａｒｔ＠ｆｅｅｄを記録する。
ｉｉ．フィードごとの処理が許可される直近時刻（ｐｒｏｃｅｓｓ−ｔｉｍｅ＠ｆｅｅｄ）を計算する。
if ( timer < <feed-idle-timeout> )
{
process-time@feed = market-time@timer-start@feed
}
else
{
process-time@feed = system-time - <feed-latency>
}
＜ｆｅｅｄ−ｉｄｌｅ−ｔｉｍｅｏｕｔ＞までは、メッセージが前に終わったところから続けられることが期待されていてもよく、したがって、現在のマーケット時刻を超えて処理しない。＜ｆｅｅｄ−ｉｄｌｅ−ｔｉｍｅｏｕｔ＞に到達した後は、メッセージは＜ｆｅｅｄ−ｌａｔｅｎｃｙ＞だけ実際の時刻で遅れるであろう。システム時刻は実際の時刻の近似として使用される。処理が許可される直近時刻（ｐｒｏｃｅｓｓ−ｔｉｍｅ）は全てのフィード毎処理時刻のなかで最も小さいものである。process-time=MINIMUM(all process-time@feed)。
ｉｉｉ．message-time (t) ≧ process-timeの場合、
１．このメッセージを処理し、このフィードから次のメッセージを読み出してバッファに入れる。
２．（ｔ＞マーケット時刻）の場合、マーケット時刻はｔへと移る。
ｉｖ．それ以外の場合（すなわちmessage-time (t) < process-time）、MINIMUM(poll-freq)だけ待機し、再度チェックする。

図７は、最大の待ち時間における例示的な弾性的追跡プロセッサ可視化である。１−４で示される４つのフィードがある。それぞれはファイル名識別子と、Ｉ−情報、Ｔ−取引、Ｏ−注文およびＣ−制御などのフィード内容のインジケータと、を有する。各フィードについて、フィードで消費された最後のメッセージはフィード時刻の左側に示され、そのフィードで消費されるのを待っている次のメッセージはフィード時刻の右側に示される。フィード３について、消費されるべき係属中のメッセージはない。各フィードについて、フィード１のメッセージ時刻０：００：００．０００および１０：２１：１７．３８７などの「メッセージ時刻」があり、それに伴う８や４２１はファイルにおけるメッセージの位置、すなわちファイルオフセットである。フィード１の［０］や［１］などの、対応するメッセージ時刻に続く括弧付きの数字は、メッセージを特定する数字であるメッセージトランザクションＩＤである。「マーケット時刻」は１０：２０：２０．０９８であり、それは（信頼の置けるフィードからの）最新のメッセージ時刻である。「実際の時刻」は１０：２０：２５．０９８であり、水平軸に記録される。「マーケット待ち時間」は０：００：０５．００である。「追跡待ち時間」は０：００：０５．００であり、これは係属中のメッセージがある場合のマーケット待ち時間と同じである。フィードアイドル時間は示されていないが、トラッカ設定ファイルで設定される値である。

他の弾性的追跡の例示的な実施の形態が以下に説明される。ひとつ以上のフィードが非アクティブの場合またはタイムアウトした場合、代替的な次のメッセージループが使用される。これはある点では効率を向上させうる。データフィード状態は以下のように維持される。まず、フィードがアクティブから非アクティブへと遷移した場合、０：０：０．０００からタイマを開始する。このタイマは０で開始されなければならない。ｆｅｅｄ−ｉｄｌｅ−ｔｉｍｅｏｕｔは常にゼロベースであり、このタイマから到達されるものであるからである。このタイマがｆｅｅｄ−ｉｄｌｅ−ｔｉｍｅｏｕｔに達した場合、フィードは非アクティブからタイムアウトへと遷移する。次に、フィードが非アクティブからタイムアウトへと遷移した場合、タイマを止める−それはもう必要ではない。前にメッセージを有さなかったフィードが今は利用可能なメッセージを有する場合、フィードはアクティブへと遷移して戻る。
ひとつ以上のフィードが非アクティブ状態またはタイムアウト状態にある場合の次のメッセージループ：
１．（利用可能なメッセージを有するフィードのそれぞれの次のメッセージから）最も低いメッセージ時刻（ｔ）を取得する。２以上のフィードが同じメッセージ時刻を有する場合、最も高い優先性を有するフィードからのメッセージが使用される。
２．（メッセージ時刻（ｔ）≦マーケット時刻）の場合、このメッセージを処理し、このフィードから次のメッセージを読み出しバッファに入れる。
３．（メッセージ時刻（ｔ）＞マーケット時刻）の場合：メッセージ時刻≦マーケット時刻の状況で全てのメッセージを読んだことを暗示する。
if (ひとつ以上のフィードが「非アクティブ」状態にある)
{
wait {{minimum(feed-poll-freq)}}
}
else
{
//メッセージを有さない全てのフィードが今や「タイムアウト」状態にあることを暗示する。
if ( message time < system-time - maximum(全てのタイムアウトしたフィードの<feed-latency>) )
{
process-message
}
else
{
wait minimum(feed-poll-freq)
}
}
ａ．＜ｆｅｅｄ−ｉｄｌｅ−ｔｉｍｅｏｕｔ＞までは、メッセージは前に終わったところから続くことが期待されている。したがって、処理は現在のマーケット時刻を超えて続かない。この時点で全てのフィードがブロックされる。
ｂ．＜ｆｅｅｄ−ｉｄｌｅ−ｔｉｍｅｏｕｔ＞に到達した後は、メッセージは＜ｆｅｅｄ−ｌａｔｅｎｃｙ＞だけ実際の時刻で遅れるであろう。システム時刻を実際の時刻の近似として使用する。
フィード毎の最大待ち時間（グローバルな最大待ち時間の代わりに）により、絶えずメッセージが流れてくるフィードよりも低い待ち時間がメッセージを欠いているフィードに設定されている場合に、全体の待ち時間が低減される。
以下の状況を想定する：
フィードＡ：大きなラグ（例えばコンバータの非効率性による）を伴う多くのメッセージ（すなわち、メッセージは常に利用可能である）
フィードＢ：小さなラグの非常に少数のメッセージ。
全てのフィードがメッセージを有する場合、トラッカ待ち時間＝最も遅いフィードの待ち時間。ひとつ以上のフィードがメッセージを有さない場合、トラッカ待ち時間はそれが（max(feed-idle-timeout), max(feed-latency)）の最大に到達する時点まで増大する。ｆｅｅｄ−ｉｄｌｅ−ｔｉｍｅｏｕｔに到達すると、トラッカタイマはシステム時刻に対して早められる。ｆｅｅｄ−ｉｄｌｅ−ｔｉｍｅｏｕｔがメッセージを欠いている全てのフィードにおいて到達されると、トラッカタイマはmax (feed-latency on missing feeds)だけシステム時刻から遅れるであろう。

システム時刻への依存性を低減した他の弾性的追跡の実施の形態が説明される。
１．ゼロの開始状態を仮定する。すなわち、リードバッファにはメッセージはない。何が利用可能かを知るべく、全てのフィードから最初のメッセージを読み出す。利用可能なメッセージを有さないフィードは、バックグラウンドにおいて＜ｆｅｅｄ−ｐｏｌｌ−ｆｒｅｑ＞で新たなメッセージについてポーリングされる。
２．全てのフィードが利用可能なメッセージを有する場合の次のメッセージループ：
ａ．前にメッセージを有さなかったフィードが今は利用可能なメッセージを有する場合、そのフィードについてのタイマを止める。
ｂ．最も低いメッセージ時刻（ｔ）を伴うメッセージを処理する。２以上のフィードが同じメッセージ時刻を有する場合、最も低い＜ｆｅｅｄ−ｐｒｅｃｅｄｅｎｃｅ＞からのメッセージが使用される。
ｃ．このフィードから次のメッセージを読み出してバッファに入れる。
ｄ．（メッセージ時刻（ｔ）＞マーケット時刻）の場合、マーケット時刻はｔへと移る。
３．ひとつ以上のフィードが利用可能なメッセージを有さない場合の次のメッセージループ：
ａ．前にメッセージを有さなかったフィードが今は利用可能なメッセージを有する場合、そのフィードについてのタイマを止める。
ｂ．（利用可能なメッセージを有するフィードのそれぞれの次のメッセージ）から最も低いメッセージ時刻（ｔ）を取得する。２以上のフィードが同じメッセージ時刻を有する場合、最も高い優先性を有するフィードからのメッセージが使用される。
ｃ．（メッセージ時刻（ｔ）≦マーケット時刻）の場合、このメッセージを処理し、このフィードから次のメッセージを読み出しバッファに入れる。
ｄ．（メッセージ時刻（ｔ）＞マーケット時刻）の場合。
これは、メッセージ時刻≦マーケット時刻の状況で全てのメッセージを読んだことを暗示する。タイマは、最後のメッセージがフィードから処理された時刻（メッセージ処理時刻）に対するものである。しかしながら、次のメッセージを処理することを選択するか否かはメッセージ時刻に対するものである。
利用可能なメッセージを有さない各フィードについて、
（Ｉ）０：０：０．０００からタイマを開始する。このタイマは０で開始されなければならない。ｆｅｅｄ−ｉｄｌｅ−ｔｉｍｅｏｕｔは常にゼロベースであり、このタイマから到達されるものであるからである。
１．ｍａｒｋｅｔ−ｔｉｍｅ＠ｔｉｍｅｒ−ｓｔａｒｔ＠ｆｅｅｄを記録する。process-time@feedはこの値に対して計算される。この値はタイマが止まるまでリセットされない。
２．ｓｙｓｔｅｍ−ｔｉｍｅ＠ｔｉｍｅｒ−ｓｔａｒｔ＠ｆｅｅｄを記録する。この値はデルタタイマを計算するためだけに使用される。
（ＩＩ）フィードごとの処理が許可される直近時刻（ｐｒｏｃｅｓｓ−ｔｉｍｅ＠ｆｅｅｄ）を計算する。
if ( timer < <feed-idle-timeout> )
{
process-time@feed = market-time@timer-start@feed
}
else if ( timer > <feed-latency> - latency-fudge )
{
process-time@feed = market-time@timer-start@feed
}
else
{
process-time@feed = market-time@timer-start@feed + timer + latency-fudge - <feed-latency>
}
＜ｆｅｅｄ−ｉｄｌｅ−ｔｉｍｅｏｕｔ＞までは、メッセージが前に終わったところから続くことを期待してもよく、したがって、現在のマーケット時刻を超えて処理しない。
＜ｆｅｅｄ−ｉｄｌｅ−ｔｉｍｅｏｕｔ＞に到達した後は、メッセージは＜ｆｅｅｄ−ｌａｔｅｎｃｙ＞だけ実際の時刻で遅れるべきである。実際の時刻への直接のアクセスはないので、実際の時刻の良い近似は(market-time@timer-start@feed + timer)である。先読みバッファによると、実際の時刻はフィードにフラッシュされた直近のメッセージによって決定されうる。
latency-fudgeは、フィードにおける前の待機によって導入された待ち時間を補償するために使用される。market-time@timer-start@feedは既に実際の時刻で遅れているかもしれない。マーケット時刻がタイマ時刻より少量だけ移動した場合、そのフィードが既に遅れていることを知る。latency-fudge = maximum(dt - dm, 0)。
delta-market-time (dm) = market-time - market-time＼@preceding-timer-start@(any feed)
delta-timer (dt) = system-time - system-time＼@preceding-timer-start@(any feed)
if ( dt > dm )
{
latency-fudge = dt - dm
}
else
{
latency-fudge = 0
}
処理が許可される直近時刻（ｐｒｏｃｅｓｓ−ｔｉｍｅ）は全てのフィード毎処理時刻のなかで最も小さいものである。process-time = MINIMUM(全てのprocess-time@feed)。
If message-time (t) ≧ process-time:
３．このメッセージを処理し、このフィードから次のメッセージを読み出してバッファに入れる。
４．（ｔ＞マーケット時刻）の場合、マーケット時刻はｔへと移る。
それ以外の場合（すなわちmessage-time (t) < process-time）、MINIMUM(poll-freq) だけ待機し、再度チェックする。
本例示的な実施の形態の最大待ち時間は：
max latency = max(feed idle of missing feeds) + max(latency of missing feeds) + latency @ timer start。

フィードアイドルが経過した後は、max latency = max(latency of missing feeds) + latency @ timer start。タイマ開始の初回では、我々は、実際のシステム時刻を参照することなしにフィードが実時間からどれほど遅れているかを確立することができない。

システム時刻は基準時刻の類義語として使用される。基準時刻は全ての共有コンポーネントによって使用される現在時刻である。単純化すると、これは世界が知る現在時刻である。しかしながら、異なるデータフィードソースのシステム時刻は同期していない場合がある。各データフィードメッセージのタイムスタンプは各データフィードソースのシステム時刻に関して正しいかもしれないが、異なるソースの異なるシステム時刻が同期エラーを招く可能性がある。例えば、第１ソースから受信した第１データフィードメッセージが、第２データフィードソースから受信した第２データフィードメッセージと同等のタイムスタンプを有しつつも、その第１データフィードメッセージは同じ実際の時刻に関しないものである可能性がある。

ある例示的な実施の形態では、共有コンポーネントを同期させるために、「基準時刻」が共有コンポーネントに報知される。ある例示的な実施の形態では、ＮＴＰ（ネットワークタイムプロトコル）を使用して、生成に使用される全てのシステムクロックを（好ましくは同じ上流サーバに対して）同期させる。これにより、全てのサーバについてシステム時刻が同じに維持される。

外部ソースから基準時刻を受信することにはいくつかの利点がある。例えば、テスト目的で、基準時刻の異なるソースを提供して所定の条件をシミュレートできることは有用である。テスト目的で、基準時刻は実際の時刻より速く動くか遅く動くことができる。

異なるデータフィードメッセージを並べ替えるタスクをより扱いやすいかたまりに分けるべく、弾性的トラッカは全ての入力データフィードは既に正しく並べられているという前提の下で動作してもよい。しかしながら、この前提は常に正しいとは限らない。したがって、ある例示的な実施の形態では、弾性的トラッカは、データフィードメッセージが順序が乱れた状態で処理される可能性を最小化するために、入来データフィードを並べ直す。入来データフィードの並べ直しは、各データフィードについて、先読みバッファに入来データフィードメッセージを格納し、各メッセージのタイムスタンプにしたがって先読みバッファ内の並びを直すことによってなされうる。

図８は、監視システムアプリケーションのコンテキストにおける、非限定的な例示的弾性的追跡プロセッサの機能ブロック図である。監視コンピュータサーバは、ひとつ以上のデータプロセッサと、ひとつ以上の外部データフィードソースと通信するインタフェースと、を含む。インタフェースは、データフィードソースから、電子的なデータフィードメッセージを受信する。典型的には、電子的データメッセージはデータメッセージのストリームとして受信される。しかしながら、あるソースから日ごとバッチまたは準定期的なバッチのデータが配信されてもよい。データフィードソースのうちのひとつは監視対象の電子的マーケット（例えば、自動電子交換）であってもよく、受信されたデータフィードは電子的マーケットからのマーケットデータを関連付ける。監視コンピュータサーバはさらに、コンピュータハードドライブやＳＳＤなどの持続性データストレージと、データストレージのためのひとつ以上のコンピュータメモリ（例えば、ＲＡＭメモリ）と、を備える。データフィードは持続性ストレージ、メモリ、または持続性ストレージおよびメモリの両方、に保持される。監視システムはひとつ以上のオーダブックをメモリに維持してもよい。各オーダブックは電子的マーケットで取り引きされる商品に対応する。

異なるデータフィードの受信されたデータメッセージが時間的および論理的順序で並んでいない場合、実時間に近い形でマーケットの真の情勢を生成することはできない。データフィードは弾性的マーケットトラッカによって処理される。該トラッカは、異なるデータフィードをインターリーブし、異なるデータフィードのデータメッセージのタイムスタンプにしたがい、正しい順序のデータメッセージの統合されたデータフィードを生成する。各データフィードに対応するデータメッセージをバッファするためにリードバッファが維持されてもよい。例はＦＩＦＯバッファやセグメント化されたコンピュータメモリを含むがそれに限定されない。弾性的トラッカがどのデータメッセージが処理対象であり、そのデータメッセージがいつ処理可能かを決定するとき、バッファは利用可能なメッセージについてのクエリを受ける。弾性的マーケットトラッカは例えば上述の「弾性的」トラッカ方法のうちのひとつを使用してデータメッセージを追跡または処理し、処理されたデータメッセージのストリームを出力する。処理されたデータメッセージのストリームは持続性ストレージまたはメモリに格納される。ある実施の形態では、インターリーブされたデータメッセージは、ひとつ以上のクライアントコンピュータと通信するよう構成された外部インタフェースを介して、ひとつ以上のクライアントコンピュータにストリームされる。マーケットトラッカは、データメッセージに関するアクションに基づいて、メモリに保持される対応するオーダブックを更新する。監視コンピュータサーバは、統合データフィードから所定のパターンを検出するかまたはオーダブックからイベントを検出する警告エンジンを含んでもよい。警告エンジンは、パターンを検出すると、警告を生成し、外部インタフェースを介してクライアントコンピュータのうちのひとつ以上に警告を送信する。

ある例示的な実施の形態では、監視コンピュータサーバは、クライアントコンピュータから受信されたクエリ／要求を取り扱う要求コンピュータエンジンを備える。要求エンジンは監視コンピュータサーバ内に保持される情報を集め、応答を生成し、クライアントコンピュータに出力する。

本願で説明された柔軟な追跡技術は多くの技術的利点を有する。第１に、異なるフィードのメッセージが正しいメッセージの時間的順序で処理されることを確実にしつつ、追跡プロセッサがメッセージを待ちながらアイドルで過ごす時間をかなり低減する。これにより、マーケットで最も遅いフィードに拘束された状態で都合が良いときに処理待ち時間を低減することができる。第２に、許されるフィード待ち時間はフィード毎に設定可能である。第３に、いくつかのフィードは順序から外れて処理可能であるので、これらのフィードのメッセージを待つためにマーケットの残りを止める必要はない。例はニュースフィードを含む。第４に、本技術は、メトロノームベースのソリューションの限界であった不定期な／ぎくしゃくした処理を除去する。第５に、メトロノームベースのソリューションにとって生来的である動作の複雑さが低減される。１日の内での再起動が要求される場合、メトロノームベースのソリューションは固定の順序で再起動されなければならない。メッセージが正しい時間的順序で処理されることを確保するために、コンポーネントの再起動の間に待ち期間が必要である。また、メトロノームフィードなどの外部コンポーネントの必要性はビルトインコンポーネントによって置き換えられる。

追跡プロセッサは正確な時刻を使用して動作し、時間の進行の小さな逸脱にも敏感である。追跡プロセッサはメッセージの相対的並べ替えについて入来データフィードの非常に小さな粒度もサポート可能である点で有利である。上流のタイムスタンプコンポーネント（例えば、取引交換エンジン）は、特化した高精度実時間クロックを有するハードウエアに配置されうる。その精度は、追跡プロセッサが正確さで劣るハードウエアを使用して実現される場合でも、相対的並べ替えのために使用されうる。

システムのタイムゾーンとマーケットのタイムゾーンとが異なる場合、ネットワークタイムプロトコル（ＮＴＰ）の同期が特定のマスタクロックと共に使用されてもよい。ある例示的な実施の形態では、システム時刻はシステムに入力されるパラメータであってもよい。この場合、システム時刻はテストシステムにおいてかなり異なることが可能となる。実時間日のシミュレーションはその日の異なる時刻に実行されてもよい。テストは、実時間日が通常時間よりも速くまたは遅く再生されることを要求しうる。

システム時刻が追跡プロセッサへの入力として使用される場合、それは全ての従属コンポーネントにとって利用可能なフィード入力として到着することが好ましい。ある例示的な実施の形態では、現在のシステム時刻はシステムメッセージバス上のすべての共有コンポーネントに報知されてもよい。しかしながら、この例示的なアプローチには、報知を伝送したり読んだり処理したりするのに要する時間に起因して、非常に小さな時間単位に関して限界が存在しうる。

他の利点は、フィード回復ウィンドウを使用することで、例えばデータ伝送セッションが落ち、続けて再接続して続くといった、フィードが一時的に損なわれて次に回復する状況に対応可能であることである。回復ウィンドウ内に回復するフィードは順序通りに処理されうる。回復ウィンドウが満了すると、全体のマーケット待ち時間は全ての設定フィードのなかで最大の待ち時間へと縮まる。

フィードがデッドである場合、追跡プロセッサはこのフィードが存在しないかのように振る舞ってもよい。すなわち、追跡プロセッサはこのフィードの係属中のメッセージを落とし、新しいメッセージについてこのフィードをポーリングするのを止める。

他の利点は、弾性的追跡プロセッサが入力データフィードからのメッセージを一度にひとつずつ読んでもよいことである。メッセージが厳格な非降順にあると仮定することにより、このトラッカアルゴリズムに入る前にフィードの読みをバッファしてそれらを並べ直す必要はない。バッファすることはリソースインテンシブな処理であり得るので、入来フィードごとに実行される方が良い場合がある。このアプローチはバッファすることをより扱いやすいかたまりへと分離する。これにより、各コンポーネントに関連する複雑さが低減され、望まれるか必要であれば複数のサーバに亘って処理負荷を分散させることを可能とする。

各入来データフィードは、フィード全体において厳格な非降順の時間的順序にあるメッセージを含んでもよい。追跡プロセッサはメッセージ時刻を使用してデータフィード間でメッセージを並べ替えるが、追跡プロセッサはあるデータフィード内ではメッセージを並べ直さないことが好適である。しかしながら、あるデータフィード内で時間的に正しく並べられていないメッセージが並べ直される場合、追跡プロセッサがデータフィードを読む前にメッセージをバッファして並べ直すための中間処理が挿入されうる。あるデータフィード内で時間的に後方にジャンプするメッセージは順序から外れて処理されうる。上述の通り、マーケット時刻は前進するのみであり、後ろ向きには動かない。しかしながら、下流のコンポーネントは、後方にジャンプするタイムスタンプを伴うメッセージについて準備されているべきである。追跡プロセッサの弾性範囲の外にあるメッセージが到着した場合、その特定のトランザクションのタイムスタンプはマーケット時刻から遅れているであろう。

上記の説明は多くの詳細を含むが、それらは限定として解釈されるべきではなく、ある現在好適な実施の形態の説明を単に提供するものとして解釈されるべきである。本明細書で説明される実施の形態は独立した実施の形態として考えられてもよく、または非限定的な例を説明するために任意の組み合わせで考えられてもよい。非限定的な例示的実施の形態の技術がウェブサービスプロバイダの分散ストレージサービスのコンテキストで説明されたが、説明された技術的思想は他の分散処理およびストレージのシステムおよびサービスに適用可能である。なお、本技術は当業者には明らかであろう他の実施の形態を完全に含む。単数形での要素への参照はそのように明示されない限り「ひとつのみ」を意味することを意図するものではなく、むしろ「ひとつ以上」を意味する。上述の実施の形態の要素に対する構造的および機能的等価物のうち当業者に既知のものは全て、明示的に本明細書に参照により組み入れられており、本明細書に包含されることが意図されている。さらに、本明細書に包含されるために、デバイスや方法が、説明された技術により解決されるべきおのおの全ての課題を指向する必要はない。

Claims (28)

1. データメッセージフィードポートと接続され、複数のデータメッセージソースからデータメッセージを受信するよう構成された処理回路であって、各データメッセージソースは対応する時系列のデータメッセージを生成しており、前記複数のメッセージフィードポートで受信されたひとつ以上のデータメッセージはその対応する時系列から外れて受信される処理回路を備える電子データメッセージ処理装置であって、
   前記処理回路は、
   前記入来データメッセージフィードポートにおいて受信されたデータメッセージを、データメッセージ処理待ち時間に基づいて処理し、
   前記複数のデータメッセージフィードポートから受信された前記データメッセージに統合時系列を提供するよう前記データメッセージ処理待ち時間を選択的に改め、
   合成データメッセージストリームの前記データメッセージが前記統合時系列でひとつ以上の宛先ポートに送信されるように前記合成データメッセージストリームを生成する、
   よう構成される電子データメッセージ処理装置。
2. 前記処理回路はさらに、
   状態パラメータを検出し、
   前記状態パラメータが変わるまでに受信したデータメッセージを時系列にあるとして処理し、
   前記状態パラメータが変わった後に受信したデータメッセージを時系列から外れるとして処理し、
   前記状態パラメータが変わった後に受信した前記データメッセージを並べ替え、かつ、前記状態パラメータが変わった後に受信した前記データメッセージを含む前記合成データメッセージストリームに前記統合時系列を提供するために、前記処理待ち時間を改める、
   よう構成される請求項１に記載の電子データメッセージ処理装置。
3. 前記処理回路はさらに、前記電子データメッセージ処理装置における現在の実際の時刻とは別の基準時刻を使用して前記合成データメッセージストリームの前記データメッセージを処理するよう構成され、
   前記基準時刻と前記現在の実際の時刻との差は前記データメッセージ処理待ち時間に関連付けられており、
   前記処理回路は前記基準時刻を変更するよう構成される請求項２に記載の電子データメッセージ処理装置。
4. 前記処理回路はさらに、前記合成データメッセージストリームの前記データメッセージを処理し、前記基準時刻を使用して時系列から外れたデータメッセージを検出するよう構成される請求項３に記載の電子データメッセージ処理装置。
5. 前記処理回路はさらに、時間的メッセージ系列から外れたメッセージが処理された場合に前記基準時刻を維持するよう構成される請求項３に記載の電子データメッセージ処理装置。
6. 前記処理回路は前記データメッセージフィードポートのそれぞれで現在受信されている次のデータメッセージであって現時点で最も低いデータメッセージ時刻を有する次のデータメッセージのメッセージ時刻と前記基準時刻とを比較するよう構成され、
   （ａ）前記データメッセージ時刻が前記基準時刻より小さい場合、前記処理回路は該データメッセージを処理し該データメッセージフィードポートにおける次のデータメッセージを読むよう構成され、
   （ｂ）前記データメッセージ時刻が前記基準時刻より大きい場合、前記処理回路は前記基準時刻を前記データメッセージ時刻に合わせるよう構成される請求項３に記載の電子データメッセージ処理装置。
7. 前記データメッセージフィードポートのうちのひとつが非アクティブ状態にあると判定された場合、前記処理回路は、（ａ）前記データメッセージフィードポートのうちの前記ひとつが所定の回復期間内にアクティブ状態になると判定された場合には前記合成データメッセージストリームの前記データメッセージを時間的順序で処理し、（ｂ）前記データメッセージフィードポートのうちの前記ひとつが前記所定の回復期間外でアクティブ状態になると判定された場合には前記合成データメッセージストリームの前記データメッセージを時間的順序から外れて処理するよう構成される請求項３に記載の電子データメッセージ処理装置。
8. 前記非アクティブなデータメッセージフィードポートの前記判定に基づいて、前記処理回路は、該データメッセージフィードポートが前記非アクティブ状態にある間は前記基準時刻の進行を止めるよう構成される請求項７に記載の電子データメッセージ処理装置。
9. 前記処理回路は、前記合成データメッセージストリームの前記データメッセージを処理してひとつ以上の所定のパターンを検出し、該パターンに応じてひとつ以上の対応する警告データメッセージを生成するよう構成される請求項１に記載の電子データメッセージ処理装置。
10. 前記処理回路は、前記合成データメッセージストリームの受信されたがまだ処理されていないデータメッセージを、以前に処理されたデータメッセージの内容に基づいて処理するよう構成される請求項１に記載の電子データメッセージ処理装置。
11. 前記データメッセージのうちの少なくともいくつかは電子的取引交換からのトランザクションパラメータに関係し、
    前記処理回路は、該トランザクションパラメータに基づいて、前記電子的取引交換のひとつ以上のオーダブックを更新するよう構成される請求項１に記載の電子データメッセージ処理装置。
12. 前記処理回路はさらに、前記統合時系列から外れた検出データメッセージを使用して前記ひとつ以上のオーダブックを更新するよう構成される請求項１１に記載の電子データメッセージ処理装置。
13. 前記処理回路は、前記データメッセージフィードポートで受信された状態のデータメッセージを取得し、前記取得されたデータメッセージ内の前記データを正規化されたデータフォーマットに変換するよう構成される請求項１に記載の電子データメッセージ処理装置。
14. 各受信データメッセージはタイムスタンプを含み、
    前記処理回路は、順番通りでない状態で受信されたひとつ以上のデータメッセージを、前記データメッセージのタイムスタンプに基づいて並べ直すよう構成される請求項１に記載の電子データメッセージ処理装置。
15. データメッセージフィードポートに接続された処理回路を有する電子データメッセージ処理装置で実行される方法であって、
    前記データメッセージフィードポートにおいて複数のデータメッセージソースからデータメッセージを受信することであって、各データメッセージソースは対応する時系列のデータメッセージを生成しており、前記複数のメッセージフィードポートで受信されたひとつ以上のデータメッセージはその対応する時系列から外れて受信されることと、
    前記処理回路によって、前記入来データメッセージフィードポートにおいて受信されたデータメッセージを、データメッセージ処理待ち時間に基づいて処理することと、
    前記複数のデータメッセージフィードポートから受信された前記データメッセージに統合時系列を提供するよう前記データメッセージ処理待ち時間を選択的に改めることと、
    合成データメッセージストリームの前記データメッセージが前記統合時系列でひとつ以上の宛先ポートに送信されるように前記合成データメッセージストリームを生成することと、を含む方法。
16. 状態パラメータを検出することと、
    前記状態パラメータが変わるまでに受信したデータメッセージを時系列にあるとして処理することと、
    前記状態パラメータが変わった後に受信したデータメッセージを時系列から外れるとして処理することと、
    前記状態パラメータが変わった後に受信した前記データメッセージを含む前記合成データメッセージストリームに前記統合時系列を提供するよう前記状態パラメータが変わった後に受信した前記データメッセージを並べ替えるために、前記処理待ち時間を改めることと、をさらに含む請求項１５に記載の方法。
17. 前記電子データメッセージ処理装置における現在の実際の時刻とは別の基準時刻を使用して前記合成データメッセージストリームの前記データメッセージを処理することをさらに含み、
    前記基準時刻と前記現在の実際の時刻との差は前記データメッセージ処理待ち時間に関連付けられており、
    前記処理回路は前記基準時刻を変更するよう構成される請求項１５に記載の方法。
18. 前記合成データメッセージストリームの前記データメッセージを処理することと、
    前記基準時刻を使用して時系列から外れたデータメッセージを検出することと、をさらに含む請求項１７に記載の方法。
19. 時間的メッセージ系列から外れたメッセージが処理された場合に前記基準時刻を維持することをさらに含む請求項１７に記載の方法。
20. 前記データメッセージフィードポートのうちのひとつが非アクティブ状態にあると判定された場合、前記方法はさらに、
    （ａ）前記データメッセージフィードポートのうちの前記ひとつが所定の回復期間内にアクティブ状態になると判定された場合には前記合成データメッセージストリームの前記データメッセージを時間的順序で処理することと、
    （ｂ）前記データメッセージフィードポートのうちの前記ひとつが前記所定の回復期間外でアクティブ状態になると判定された場合には前記合成データメッセージストリームの前記データメッセージを時間的順序から外れて処理することと、を含む請求項１７に記載の方法。
21. 前記非アクティブなデータメッセージフィードポートの前記判定に基づいて、該データメッセージフィードポートが前記非アクティブ状態にある間は前記基準時刻の進行を止めることをさらに含む請求項２０に記載の方法。
22. 前記データメッセージフィードポートのそれぞれで現在受信されている次のデータメッセージであって現時点で最も低いデータメッセージ時刻を有する次のデータメッセージのメッセージ時刻と前記基準時刻とを比較することと、
    （ａ）前記データメッセージ時刻が前記基準時刻より小さい場合、該データメッセージを処理し該データメッセージフィードポートにおける次のデータメッセージを読むことと、
    （ｂ）前記データメッセージ時刻が前記基準時刻より大きい場合、前記基準時刻を前記データメッセージ時刻に合わせることと、をさらに含む請求項２１に記載の方法。
23. 前記合成データメッセージストリームの前記データメッセージを処理してひとつ以上の所定のパターンを検出し、該パターンに応じてひとつ以上の対応する警告データメッセージを生成することをさらに含む請求項１５に記載の電子データメッセージ処理装置。
24. 前記合成データメッセージストリームの受信されたがまだ処理されていないデータメッセージを、以前に処理されたデータメッセージの内容に基づいて処理することをさらに含む請求項１５に記載の電子データメッセージ処理装置。
25. 前記データメッセージのうちの少なくともいくつかは電子的取引交換からのトランザクションパラメータに関係し、
    前記方法はさらに、該トランザクションパラメータに基づいて、前記電子的取引交換のひとつ以上のオーダブックを更新することをさらに含む請求項１５に記載の電子データメッセージ処理装置。
26. 前記統合時系列から外れた検出データメッセージを使用して前記ひとつ以上のオーダブックを更新することをさらに含む請求項２５に記載の電子データメッセージ処理装置。
27. 前記データメッセージフィードポートで受信された状態のデータメッセージを取得し、前記取得されたデータメッセージ内の前記データを正規化されたデータフォーマットに変換することをさらに含む請求項１に記載の電子データメッセージ処理装置。
28. 各受信データメッセージはタイムスタンプを含み、
    前記方法はさらに、前記データメッセージフィードポートのそれぞれにおいて順番通りでない状態で受信されたひとつ以上のデータメッセージを、前記データメッセージのタイムスタンプに基づいて並べ直すことをさらに含む請求項１５に記載の電子データメッセージ処理装置。

Images