JP2014526743A - イベントデータを取得するスケールアウトシステム - Google Patents

Abstract

イベントを生成すること。方法は、異なるソースに特有の複数の異なるプロトコルを用いて、異なるソースと通信することによって、複数の異なるソースからデータを取得することを含む。本方法は、取得したデータに基づいて、イベントが起こるべきであると決定することをさらに含む。本方法は、イベントを生じさせることをさらに含む。生じたイベントは、イベントを生じさせるデータソースからのデータの特定の形にかかわりなく、消費者による一貫したイベント評価のために規格化される。

Description

本願発明の一実施例は、例えば、イベントデータを取得するスケールアウトシステムに関する。

[0001]コンピュータおよびコンピューティングシステムは、現代生活のほとんど全ての側面に影響を及ぼした。コンピュータは、仕事、レクリエーション、保健医療、輸送、娯楽、家庭経営などに広く関係している。

[0002]さらに、ネットワーク接続を介して他のコンピューティングシステムに相互接続されるコンピューティングシステム能力によって、コンピューティングシステムの機能性を強化することができる。ネットワーク接続は、有線もしくは無線イーサネット（登録商標）、セルラ接続、またはシリアル、パラレル、ＵＳＢ、もしくは他の接続によるコンピュータ同士の接続を含むことができるが、これに限定されない。接続によって、コンピューティングシステムが、他のコンピューティングシステムのサービスにアクセスして、他のコンピューティングシステムからアプリケーションデータを迅速かつ効率的に受け取ることが可能になる。

[0003]多くのコンピュータは、コンピュータとの直接的なユーザインタラクションにより用いられることを意図している。このように、コンピュータは、ユーザインタラクションを容易にするために、入力ハードウェアおよびソフトウェアユーザインターフェースを有する。例えば、最新の汎用コンピュータは、ユーザがコンピュータにデータを入力するためのキーボード、マウス、タッチパッド、カメラなどを含むことができる。さらに、様々なソフトウェアユーザインターフェースを利用することができる。

[0004]ソフトウェアユーザインターフェースの例としては、グラフィカルユーザインターフェース、ユーザインターフェースに基づくテキストコマンドライン、ファンクションキー、またはホットキーユーザインターフェースなどが挙げられる。

[0005]ＲＳＳまたはＡｔｏｍフォーマットで利用可能な現在の世界または金融のニュースなど多種多様のソースから情報を集めて、統合、配布または保管のための発行／購読インフラストラクチャにこの情報を送ることを意図するアプリケーションを書いている開発者を仮定する。発行／購読インフラストラクチャは、ワシントン州レドモンドのマイクロソフトから入手可能なＷｉｎｄｏｗｓ（登録商標） Ａｚｕｒｅ Ｓｅｒｖｉｃｅ Ｂｕｓによって提供されるが、また様々な他のメッセージシステムにおいても類似の形式で存在しており、メッセージ／イベントを一時的記憶装置に格納し、１人または複数の購読者にそれらのメッセージ／イベントを取り出させ消費させることを可能にする。

[0006]本願の請求に係る発明の主題は、何らかの欠点を解決する、あるいは、上述したそのような環境においてのみ動作する実施形態に限定されない。むしろ、「背景技術」は、本明細書に記載された、いくつかの実施形態を実施することができる１つの典型的な技術領域を示すために提供するにすぎない。

本願発明の一実施例は、例えば、イベントデータを取得するスケールアウトシステムに関する。

[0007]本明細書に示す一実施形態は、イベントを生成する方法に関する。本方法は、異なるソースに特有の複数の異なるプロトコルを用いて、異なるソースと通信することによって、複数の異なるソースからデータを取得することを含む。本方法は、取得したデータに基づいて、イベントが起こるべきであると決定することをさらに含む。本方法は、イベントを生じさせることをさらに含む。生じたイベントは、イベントを生じさせるデータソースからのデータの特定の形にかかわりなく、消費者による一貫したイベント評価のために規格化される。

[0008]「発明の概要」では、発明を実施するための形態においてさらに後述する概念のうちから選択したものを、簡略化した形式で導入する。「発明の概要」は、請求に係る発明の主題の主な特徴または本質的な特徴を識別することを意図するものではなく、また、請求に係る発明の主題の範囲を決定する際の助けとして用いられることを意図するものでもない。

[0009]付加的な特徴および利点は、後に続く「発明を実施するための形態」に記載され、「発明を実施するための形態」から部分的には明らかになる、あるいは、本明細書の教示を実施することによって学ぶことができる。本発明の特徴および利点は、添付した「特許請求の範囲」において特に示される機器および組合せによって、理解され、取得され得る。本発明の特徴は、以下の「発明を実施するための形態」および添付した「特許請求の範囲」からより完全に明らかになる、あるいは、以下に記載する本発明の実施によって学ぶことができる。

[0010]上述した利点および特徴、ならびに他の利点および特徴を取得できる方法を記載するために、添付の図面に示す特定の実施形態を参照することにより、先に簡潔に述べた発明の主題についてより詳細に説明する。これらの図面は、典型的な実施形態のみを表しており、したがって、範囲を限定するものと考えるべきではないことを理解し、実施形態について、以下の添付の図面を用いて、さらに具体的かつ詳細に記載し説明する。

[0011]イベントデータ収集システムの一例を示す図である。 [0012]イベントデータ収集および配布システムを示す図である。 [0013]イベントを生成する方法を示す図である。

[0014]本明細書に記載されるいくつかの実施形態は、多種多様な多数のソースからイベントデータを収集し規格化することができるスケールアウト収集インフラストラクチャを実現することができる。例えば、データは、多くの異なるソースから、それらのソースの各々に適切なプロトコルを用いて取得することができる。データは、イベントのデータがどこから取得されたか、そしてそのデータがどういうフォーマットで取得されたかについて無関係な一貫したイベントフォーマットに規格化することができる。これによって、これらのイベントを発行／購読インフラストラクチャに送ることが可能になり、収集したイベントを消費者が同一の方法で扱うことが可能になる。

[0015]いくつかの実施形態は、分散した記憶装置全体にわたって、ソース記述の分割されたプールを管理し、一般的なスケジューラフレームワークを用いて、記述されたソースからイベントを収集する際のスケジューリングを行うための機構を実現することができる。

[0016]いくつかの実施形態は、分割された所有権と予定されたメッセージの使用との組合せに基づいて、収集ジョブの所有権を収集作業者に割り当て、また再割り当てするための機構を実現することができる。

[0017]いくつかの実施形態は、消費する視聴者のニーズに基づいて、ソースを起動させ、また停止させるための機構を実現することができる。
[0018]いくつかの実施形態は、一時的および永続的なエラーとソースのブラックリストへの掲載とを扱うための機構を実現することができる。

[0019]基礎として、１つの実施形態のシステムは、ワシントン州レドモンドのマイクロソフトから入手可能なＷｉｎｄｏｗｓ（登録商標） Ａｚｕｒｅ Ｓｅｒｖｉｃｅ Ｂｕｓによって提供される発行／購読インフラストラクチャを使用しているが、様々な他のメッセージシステムにおいても類似の形式で存在する。インフラストラクチャは、提案された方法の記載した実現を容易にする２つの能力、すなわちトピックおよびキューを提供する。

[0020]キューは、メッセージがシーケンシャルな順序で追加され（キューに登録され）、そしてメッセージが追加された順序と同じ順序で削除される（キューから除かれる）ことを可能にする、メッセージのための記憶構造である。いかなる数のクライアントであっても、同時に並行してメッセージを追加し、削除することができる。そして、キューに登録する側の負荷の平準化およびキューから削除する側のレシーバ全体の処理負荷の平衡化を可能にする。また、メッセージがキューから削除されたときには、エンティティがメッセージのロックを取得することが可能になる。そして、読み出されたメッセージの処理が失敗する場合に備えて、メッセージがいつキューから実際に削除されるか、あるいは、それをキューに復元することができるかどうかについて、消費するクライアントの明示的制御を可能にする。

[0021]トピックは、キューの全ての特性を有する記憶構造であるが、しかし、キューに登録されたメッセージのシーケンスに関する分離されてフィルタ処理されたビューを各々許容する、複数の並存する「購読」を可能にする。トピックの各購読によって、キューに登録された各メッセージのコピーが生成されるが、ただし、購読の関連する１つまたは複数のフィルタ条件はメッセージに明らかにマッチする。その結果、各購読が全てのメッセージにマッチする単純な「パススルー」条件をもつ１０の購読を有するトピックに登録されたメッセージは、合計１０のメッセージ、すなわち各購読について１つのメッセージを生成する。購読は、キューのように、レシーバ全体の処理負荷の平衡化をもたらす複数の同時に並存する消費者を有することができる。

[0022]別の基礎的な概念は「イベント」のそれであって、基礎となる発行／購読インフラストラクチャについて言えば、それはまさにメッセージである。一実施形態の文脈では、イベントは、メッセージ本文およびメッセージ属性の使用を管理する一組の単純な制約条件に従う。イベントのメッセージ本文は、一般的には不透明なデータブロックとして流れ、一実施形態によって考慮されるいかなるイベントデータも、一般的にはメッセージ属性において流れる。そして、それはイベントを表現するメッセージの部分である一組のキー／バリューペアである。

[0023]次に図１を参照すると、一実施形態のアーキテクチャの目的は、大規模で多種多様の異なるソース１１６からイベントデータを取得し、さらなる処理のための発行／購読インフラストラクチャに、これらのイベントを生成することである。この処理は、イベントの分析、リアルタイム検索、またはプルもしくはプッシュ通知メカニズムによる、関心のある購読者に対するイベントの再分配のいくつかの形式を含むことができる。

[0024]一実施形態のアーキテクチャは、収集エンジン１１８と、収集アダプタおよびイベント規格化のためのモデルと、収集ソース１１６に関するメタデータを保持するための分割された記憶装置１３８と、通常の分割およびスケジューリングモデルと、さらなるデータベースルックアップを必要とせずに、ユーザ主導による収集ソース１１６の状態の変更を、実行中のシステムに、どのように流すかに関する方法と、を定義する。

[0025]具体的な実装では、収集は、多種多様の公的および私的なネットワーク化されたサービスからソースイベントに具体的な収集アダプタをサポートすることができ、これらのサービスは、ＲＳＳ、ＡｔｏｍおよびＯＤａｔａフィード、これに限定されないがＩＭＡＰおよびＰＯＰ３プロトコルをサポートすることを含む電子メールのメールボックス、ツイッタータイムラインまたはフェイスブックウォールのようなソーシャルネットワーク情報ソース１１６、および、Ｗｉｎｄｏｗｓ（登録商標） Ａｚｕｒｅ Ｓｅｒｖｉｃｅ ＢｕｓまたはアマゾンのＳｉｍｐｌｅ Ｑｕｅｕｅ Ｓｅｒｖｉｃｅのような外部の発行／購読インフラストラクチャ上の購読を含む。

イベントの規格化
[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]本発明は、その趣旨または特徴を逸脱せずに、他の具体的な形式で実施することができる。記載された実施形態は、あらゆる点で例示的なものにすぎず、限定的なものではないとみなされるべきである。本発明の範囲は、したがって、上記の記載ではなく、添付した特許請求の範囲によって示される。特許請求の範囲と等価な意味および範囲内に入る全ての変更は、それらの範囲内に包含されるべきである。

Claims (7)

1. イベント(events)を生成する(emitting)方法であって、
   異なるソースに特有の(specific)複数の異なるプロトコルを用いて、前記異なるソースと通信することによって、複数の前記異なるソースからデータを取得する(acquiring)ステップと、
   前記取得したデータに基づいて、イベントが起こるべきであると決定するステップと、
   イベントを生じさせるステップであって、前記生じたイベントは、前記イベントを生じさせる(resulting in)前記データソースからの前記データの特定の(specific)形(shape)にかかわりなく、消費者による一貫した(consistent)イベント評価(evaluation)のために規格化される(normalized)、ステップと
   を含む方法。
2. 前記イベントは、キーバリュー(key value)ペア(pairs)を含み、前記イベントを規格化するステップは、前記取得したデータのキーに対応する前記取得したデータから、前記規格化されたイベントの合致する(matching)キーへ、バリューを意味的に(semantically)マッピングする(mapping)ステップを含む、請求項１に記載の方法。
3. 意味的にマッピングするステップは、明示的な(explicit)意味的な(semantic)マッピングを実行するステップを含む、請求項２に記載の方法。
4. 明示的な意味的なマッピングを実行するステップは、前記取得したデータと前記イベントとの間でキーラベル(key labels)を合致させる(matching)ことを含む、請求項３に記載の方法。
5. 明示的な意味的なマッピングを実行するステップは、前記取得したデータのキーバリューペアの記述(description)を参照する(referencing)ステップを含む、請求項３に記載の方法。
6. 意味的にマッピングするステップは、暗黙的な(implicit)意味的な(semantic)マッピングを実行するステップを含む、請求項２に記載の方法。
7. 取得するステップは、イベントを規格化する(normalizing events)のを容易にする(facilitate)ために、前記ソースからメタデータ(metadata)を取得し、格納するステップを含む、請求項１に記載の方法。

Images