JP2019525293A - リアルタイムデータ収集において使用するための階層データコレクタおよび関連技法 - Google Patents

Abstract

多数の相互接続されたエンドポイントを有する分散型コンピューティングシステムにおいて使用するための、分散型リアルタイムデータ収集、処理および対処システム、および関連技法について説明する。分散型リアルタイムデータ収集、処理および対処システムおよび技法は、階層データコレクタおよび動作の方法を利用する。【選択図】図４

Description

本明細書で説明する概念は一般に、監視および／または制御のためにコンピューティングデバイスの大きなシステムからデータを収集する１つの例示的なアプリケーションを用いた、分散型リアルタイムデータ収集、処理および対処の方法に関する。

世界中に分散されたコンピューティングデバイスの大きなシステムからのデータ収集は、一般的なタスクであるが、今日、大規模で迅速かつ確実に行うことは、驚くほど困難な問題である。たとえば、ソフトウェアアズアサービス（ＳａａＳ）ベンダーは、彼らがそのクライアントに提供している現在の可用性、性能、およびコストを理解し、現状に対応するその世界的なロードバランスシステムにおいて活動をトリガするために、その世界的なインフラストラクチャのリアルタイム状況を瞬時に分析することを望む場合がある。別の例では、モノのインターネット（ＩｏＴ）ベンダーは、世界的な気象パターンがどのように変化したかを理解し、次いで、たとえば、竜巻警告システムにおいて活動をトリガするために、すべてのその気象センサからのデータを瞬時に分析することを望む場合がある。これらのようなアプリケーションでは、１）データを瞬時に収集し、２）リアルタイムの確実性でそのデータを分析し、３）活動を迅速にトリガし得る、１つの簡潔なパッケージの形で結果を提供することが望ましい。その上、この解決策はスケーリング可能である。より多くのコンピューティングデバイス、センサ、サーバ、およびデータが追加されるにつれて、データの完全性およびシステムの動作が損なわれなければ有益である。解決策はやはり低コストであるべきである。

市場のデータ収集システムは、今日、多くの場合、２つの範疇、すなわち、（１）「中央データベース」手法、および（２）「分散型ロギング」手法のうちの１つに該当する手法を利用する。図１を参照すると、中央データベース手法に基づく監視システム１００は、中心位置（たとえば、ニューヨーク市）内にデータベース１０２を含む。モニタ１０４は、データベース１０２からデータを取り出すための１つまたは複数のコンピューティングデバイスを含んでよく、「ネットワークオペレーションセンターモニタ」または「ＮＯＣモニタ」と呼ばれることがある。ＮＯＣモニタ１０４は、データベース１０２にアクセスして、データベース１０２内に収集されたデータに基づいて異変を発見することができる。システム１００の部分であり、ローカルにまたは遠隔に位置し得る、個々のコンピューティングデバイスは、生データをデータベース１０２内にプッシュすること（または、データベース１０２からプルすること）ができる。いくつかのシステムにおいて、データは個々の機械からデータベース内にプルされ得るか、またはＮＯＣモニタ１０４はデータをデータベース１０２内にプルし得る。

中央データベース手法は、（たとえば、数百の世界的に分散されたシステムを監視する）比較的小さなシステムとうまく動作するが、この手法にはいくつかの欠点がある。たとえば、様々な領域（たとえば、アジア、欧州、およびアフリカ）内に位置する機械は、遠く離れている場合がある中央データベースに通信することを要求される場合がある。（たとえば、距離に伴ってより多くみられる、ネットワーク区分化または他の接続性問題点により）ネットワーク接続性問題が生じた場合、これらの遠隔機械は、中央データベースと通信する能力を失う。この問題は、コンピューティングデバイスの区分へのセグメント化、および損なわれた接続性または限定された帯域幅をもたらし得る。この現象は、「ネットワーク区分化問題」と呼ばれることがある。

いくつかの旧来のシステムによって使用される「ネットワーク区分化問題」の部分を軽減するための１つの方法は、各遠隔領域内（たとえば、遠隔システムと中央データベースとの間の地理的領域内に配置し得るデータセンター１０６、１０８、および／または１１０）内にプロキシをインストールすることである。プロキシは、中央データベース１０２に送信するためにデータをアグリゲートおよびキャッシュすることを試みる。この解決策は、ネットワーク区分化に対してある程度の弾力性を提供し得る（データは、ネットワークが分割されるときにプロキシによって記憶され、サービスが復活したときに中央データベース内に再送信される）。このキャッシング機能性は、データ損失から保護する。しかしながら、基本的な問題、すなわち、センター１０６、１０８、１１０と中央データベース１０２との間の接続性の損失が依然として存在し得る。システムのサブセットからデータが利用可能でない場合、いずれの事象に関しても、それらの区分化されたシステムから何の活動もトリガされ得ない。一例として、企業は、インドにおいてインド内のエンドユーザにビデオをサーブする機械のセットと、合衆国において「中央データベース」監視システムとを有する。この例では、ネットワークを区分化し、「中央データベース」監視システムがインドにおける機械を確認することを妨げる接続性問題がインドと合衆国との間に存在し得る。インドのサーバは、インドのエンドユーザにビデオをサーブすることができる。しかしながら、インドにおいて何らかの問題（たとえば、サーバのうちの１つがハードウェア故障を有する）が生じた場合、監視システムは、その問題を知らないことになる。通常、監視システムは、活動を迅速にトリガして、そのような不健全な機械をサービスから取り除くことができるが、中央データベースがその問題点を知らない場合、監視システムは、不健全な機械を取り除くことができない。

中央データベース手法に伴う別の問題は、「スケール問題」、すなわち、システムのサイズおよび範囲の増大である。個々のシステムのサイズは限定されているため、すべてのデータが中央データベース１０２内に記憶されている場合、そのようなシステムをスケーリングして、大きな分散型データセット（たとえば、数十万のエンドポイントから収集された数百のデータポイント）に対応することは困難な可能性がある。

さらに別の問題は、「データセット問題」と呼ばれ、これは、分散されたデータを相関させて分析するシステムの能力に関する。たとえば、気象アプリケーションは、すべての郵便番号範囲内の温度を収集し、温度がしきい値を上回るときに（たとえば、温度が凍結に関する氷点下警告を下回る場合に）行うべき活動を規定することができる。しかしながら、利益は、データが、露点、気圧の変化など、他のデータポイントと相関されるときに達成され得る。相関されて分析されたデータセットが大きくなるにつれて、データを処理するためにより多くのインフラストラクチャが必要とされ得ることを当業者は理解されよう。中央データベース手法を使用するシステムは、大きな分散型データセットを処理し、データに基づいて自動化された活動を行うためのシステム能力の点で制限され得る。

別の問題は「対応時間問題」であり得る。キャリアグレードネットワークでは、９９．９９９％のシステム可用性基準が要求され得る。この要件を満たすために、故障は迅速に検出されて修正されなければならない。そのような先行技術の監視システムにおける１つの問題は、データが収集され、相関され、分析され、次いで、結果がディスプレイを介して、その問題を修正するように対応しなければならない技術者（一般に、「警告」と呼ばれる）に提示されるということである。これは、したがって、システムの制御ループ内に人間の関与を必要とする。しかしながら、技術者が大きなシステムを監視する平均的な対応時間は、通常、数分程度であり、これは、１つの問題に対する通常の対応時間は、９９．９９９％の可用性を損なう可能性があることを意味する。

ネットワーク区分化問題と同様に、対応時間問題にはワークアラウンドも存在する。次に、図２を参照すると、１つのワークアラウンドは、ＮＯＣモニタ２０６、２０８によって作成される警告２０２、２０４を消費し、警告２０２、２０４を処理するための自動化された応答を実行するスクリプティング（ｓｃｒｉｐｔｉｎｇ）サブシステムの構築を必要とする。これらの自動化された応答は、さもなければ、それらの警告に対応するＮＯＣ技術者によって実行されている場合がある単純な活動であり得る。

警告自動化はＮＯＣモニタ２０６、２０８とインターフェースをとる。ＮＯＣモニタ２０６、２０８が、エラーが発生したことを認識すると、警告が作成され得、次いで、スクリプティングシステムが、たとえば、遠隔システムに遠隔に接続して、その状態に対処することができる。したがって、警告システムによって検出されたエラー状態のサブセットは、ＮＯＣ技術者２１０、２１２ではなく、警告自動化によって対処され得る。これは、対応時間を削減するように機能するが、「ネットワーク区分化問題」によって妨げられる場合がある。たとえば、接続性または帯域幅における限定によるネットワーク区分化（すなわち、断片）が存在するとき、この問題は遠隔機械に対する中央データベースのアクセスをブロックする場合がある。加えて、この手法は、比較的長い制御ループを要求し得る。システムの複雑性とともにエラーが増大する確率を仮定すると、このような長い制御ループを確実に維持することは困難であり得る。

これらのエラーの除去に努めるために、そのような警告自動化システムは、多くの場合、その独自の監視システムを要求し、これはシステム複雑性を増し得る。その上、制御ループが故障するとき、多くの場合、人間の介入（たとえば、ＮＯＣ）が必要とされ、これはレイテンシを追加し得る。

対応時間問題に対する別のワークアラウンドは、遠隔システム２１４に近いハードウェアロードバランサに健全性検査を統合することである。これは、制御ループを中央システムから遠くに分散し、その場合、ロードバランサ２１４がローカルなエラー状態に迅速に対応し得る。この手法では、クライアント２１６は、ロードバランサ２１４を通してシステムにアクセスすることができる。ロードバランサ２１４は、個々のサーバ（たとえば、サーバ２１８、２２０）に対して１つまたは複数の「健全性テスト」を実行することができる。サーバ２１８、２２０が「健全である」と見なされる場合、たとえば、エラーがなく、入ってくるジョブを処理することが可能である場合、ロードバランサは、クライアントを健全なサーバに導く。サーバが多くの分散型データセンターにわたって拡散されている場合、ロードバランサが検査しなければならない一連の多様なエラー状態は、ロードバランサの能力を上回る可能性がある。その上、両方の診断問題（すなわち、ロードバランサとエラー状態を検査するＮＯＣモニタの両方）において異なるビューを有する複数のシステムの使用は、非一貫性をもたらし、トリアージおよび／または回復を複雑化させる。

そのような非一貫性からもたらされる問題の一例として、サーバ２１８、２２０がエラーを有する場合、ＮＯＣモニタ２０６、２０８は、（実際にはロードバランサが検出しなかったとき）ロードバランサがその状態を検出したと仮定し、エラー状態を見逃すことを可能にし得る。

要約すれば、中央データベースを有する監視システムを使用する分散型システムは、少なくとも４つの問題、すなわち、（１）「ネットワーク区分化問題」、（２）「データセット問題」、（３）「スケール問題」、および（４）「対応時間問題」を受ける場合がある。したがって、そのようなシステムは、そこからデータを収集するための多くのエンドポイントを有する分散型システム（すなわち、システム上でまたはシステムにわたって通信するコンピューティングデバイス）と使用するのに適さない可能性がある。

第２のタイプの先行技術システムは、中央データベースに対するすべてのデータを収集する代わりに、ログと呼ばれるテキストファイル（または、他のタイプのファイル）内にデータを記憶する方法を利用する。ログファイル内にすべての統計を記憶した状態で、システムは、次いで、バッチ処理され得る。たとえば、ログファイルは、処理システム、たとえば、Ｈａｄｏｏｐと呼ばれるプラットフォームなど、いわゆる、「ビッグデータ」システムに送られてよい。ビッグデータシステムは、水平にスケーリングする方法で、マップリデュース処理を実行して、データを分析し、その結果を記憶する。次いで、多くの異なるクライアントは、これらの計算された結果にアクセスすることができる。これらの分析結果は、システム警告として実現され、ＮＯＣ技術者は、次いで、警告を確かめ、基礎的なエラー状態に対応することができる。

そのような手法は、Ｈａｄｏｏｐクラスタ内により多くの機械を単に追加することによって、（たとえば、監視アプリケーション内の数千程度のサーバ上に）多くのエンドポイントを有するシステムに申し分なくスケーリングする。この手法は、「スケール」問題を解決する（たとえば、Ｈａｄｏｏｐスケールなどの「ビッグデータ」システムは、設計により水平にスケーリングする）が、この手法は、他の問題をもたらし得る。

１つのそのような問題は「コスト問題」である。この機構によるデータ分析をキューアップするために、すべてのデータはファイル内に記憶されなければならない。したがって、ログファイル内に記憶されたデータの量は迅速に増え、そのようなシステムでは、ログファイルが大きくなるほど、データを搬送、記憶、および分析するために余計にコストがかかる。大きなまたは比較的複雑なアプリケーションの場合、これは、大規模なデータファイルをもたらし、コストは相当になり得る。さらに、ログ手法は、上記で説明した「対応時間問題」を依然として有し得る。

これらの問題に鑑みて、システムが１）データを瞬時に収集し、２）リアルタイムの確実性でそのデータを分析し、３）活動を迅速にトリガし得る、１つの簡潔なパッケージの形で結果を提供することが有益であろう。システムが（１）「ネットワーク区分化問題」、（２）「データセット問題」、３）「スケール問題」、および（４）「対応時間問題」、および（５）「コスト問題」をすべて１つのディスクリートシステムにおいて解決または軽減することが有益であろう。

一実施形態では、多数のエンドポイントを有する分散型処理システムにおいて使用するためのリアルタイムデータ収集および分析方法は、ローカルスコープティアに割り当てられた第１の複数のエンドポイントであって、ローカルスコープティア内の各エンドポイントが、複数の別個の位置のうちの１つに関連付けられる、第１の複数のエンドポイントを含む。ローカルスコープティア内の各エンドポイントは、ローカルスコープ階層データコレクタ（ＨＤＣ）が存在するエンドポイントにローカルな情報を収集するように構成されたローカルスコープＨＤＣと、処理済みデータのコンシューマとを含み得る、第１の複数のエンドポイントを含み得る。

システムは、Ｎティアであり、これは、任意の数のティアを有し得ることを意味するが、一実施形態では、システムは、グローバルスコープティアに割り当てられた第１の複数のエンドポイントであって、グローバルスコープティア内の各エンドポイントが、グローバルスコープ階層データコレクタ（ＨＤＣ）が存在するエンドポイントにローカルな情報を収集し、ローカルスコープティア内の任意のエンドポイントからの情報も収集するように構成されたグローバルスコープＨＤＣと、処理済みデータのグローバルスコープコンシューマとを含む、第１の複数のエンドポイントをも含み得る。

システムは、ユニバーサルスコープティアに割り当てられた、少なくとも１つのエンドポイントであって、ユニバーサルスコープティア内の少なくとも１つのエンドポイントの各々が、ユニバーサルスコープ階層データコレクタ（ＨＤＣ）が存在するエンドポイントにローカルな情報を収集し、グローバルスコープティア内の任意のエンドポイントおよびローカルスコープティア内の任意のエンドポイントからの情報も収集するように構成されたユニバーサルスコープＨＤＣと、処理済みデータのユニバーサルスコープコンシューマとを含む、少なくとも１つのエンドポイントをも含み得る。

別の実施形態では、多数のエンドポイントを有する分散型処理システムにおいて使用するためのリアルタイムデータ収集および分析方法は、ローカルスコープティア、グローバルスコープティア、およびユニバーサルスコープティアのうちの１つにエンドポイントを割り当てることであって、少なくともローカルスコープティア内の各エンドポイントが、複数の異なる位置のうちの１つに関連付けられる、割り当てることと、エンドポイントの各々の中に階層データコレクタ（ＨＤＣ）を提供し、ＨＤＣを介して各エンドポイント内にデータを収集することであって、ローカルティアにおける各ＨＤＣが、ＨＤＣが存在するエンドポイントに関するデータを収集し、グローバルスコープティアにおける各ＨＤＣが、ＨＤＣが存在するエンドポイントに関するデータを収集し、ローカルスコープティア内の１つまたは複数のエンドポイントからのデータを収集する、収集することと、ローカルスコープティアにおけるエンドポイントの各々の中にコンシューマを提供することと、グローバルスコープティアにおけるエンドポイントの各々の中にコンシューマを提供することとを含む。

中央データベースを有する処理システムのブロック図である。 ログファイルの処理を含む処理システムのブロック図である。 階層データコレクタ（ＨＤＣ）システムのブロック図である。 ローカルスコープティア、グローバルスコープティア、およびユニバーサルスコープティアを含むＨＤＣシステムのブロック図である。 コンシューマとして外部ロードバランサを含むＨＤＣシステムのブロック図である。 ＨＤＣプロセス、データテーブル、およびＣテーブルを含む、処理機のブロック図である。

図面内の同様の参照番号は同様の要素を示す。

本明細書で説明する、概念、システムおよび技法の一態様によれば、分析されたデータの収集、トランスポート、分析、消費、およびデータによってトリガされる後続の外部活動が、そのような動作が別個の目標を有する別個のエンドポイントにおいて実行されるのではなく、システム内のエンドポイント（すなわち、機械／コンピューティングデバイス）間に分散される方法およびシステムについて説明する。すべてのエンドポイント間に要素を分散することによって、増大された弾性およびスケーラビリティを有するシステムが提供される。

本明細書で説明するデータ処理システムは、エンドポイントがティアに割り当てられ、各エンドポイントが、関連する階層データコレクタ（ＨＤＣ）とコンシューマ（すなわち、ロードバランサ）とを有する、階層データ収集方式を使用し得る。本明細書で説明するＨＤＣ手法は、「中央データベース」および「ロギングシステム」の先行技術によって要求される上述の「データセット」、「スケール」、「対応時間」、および「コスト」の問題ワークアラウンドなど、ワークアラウンドの必要性を回避することができる。

これらの概念、システム、および技法のさらなる態様によれば、システムは、分散型システム内の複数のエンドポイント間に分散された階層データコレクタと、分散型システム内の複数のエンドポイント間に分散されたコンシューマと、分散型システム内の複数のエンドポイント間に分散されたトランスポートモジュールと、分散型システム内の複数のエンドポイント間に分散されたデータ分析ユニットとを含む。

この構成を備えた、大きい分散型システムにおいて使用するためのリアルタイムデータ処理システムが提供される。データ処理システムは、分散型処理システム内のエンドポイントがリソース割り当てのために利用可能であるかどうかを表示し得るか、またはエンドポイントまたはさらにエンドポイントのクラスタの全体状況を表示し得る。

いくつかの実施形態では、リアルタイム分散型データ処理システムは、データ分析のために自律的に動作し、分析されたデータへのビュー（たとえば、監視デバイスおよび／またはグラフィカルユーザインターフェース）、または活動を引き出すプログラム、スクリプト、または他のシステムなど、他のコンシューマをコンシューマに提供する。

実施形態では、リアルタイム分散型データ処理システムコンシューマは、システム監視アプリケーション内でＮＯＣ技術者に提供される処理済みデータのビューに対応する。しかしながら、リアルタイム分散型データ処理システムは、ＮＯＣにビューを提供することに限定されない。いくつかの実施形態では、リアルタイム分散型データ処理システムコンシューマは、たとえば、ウェブサイトを通してビューをカスタマに提供することもできる。リアルタイム分散型データ処理システムのコンシューマ

いくつかの実施形態では、システムは、サービスプロバイダにビューを提供することもできる。したがって、たとえば、特定の機械またはクラスタで何かがおかしいとき、情報または通知がサービスプロバイダに提供され得る。

バックエンドとして、リアルタイム分散型データ処理システムが適用され得るアプリケーションは多数である。

本明細書で説明する概念によれば、階層データコレクタ（ＨＤＣ）は、（１）エンドポイントに可能な限り近くでデータを処理または分析すること、（２）たとえば、制御ループから人間の介入を除去するために、分析された実施可能なデータをコンシューマに提供すること、（３）システムを区分化する基盤内に接続性問題が存在した場合、アイランドが自律的に機能し得るように、制御ループを可能な限りエンドポイントの近くに維持すること、および／または（４）一貫性のある分散型システムとして分析および活動を統合すること、ができる。

たとえば、１つの位置（たとえば、ニューヨーク）内にエンドポイントの１つまたは複数のクラスタが存在し、第２の異なる位置（たとえば、東京内）にエンドポイントのクラスタが存在する場合、これらのクラスタは独立して動作し得る。１つが故障した場合、中央処理サイトにデータを送る必要は存在し得ない。むしろ、クラスタは、データを収集、トランスポート、および処理し、その結果に関して活動を実行するように自律的に機能することができる。したがって、システムは、可能な限り、その決定が関係するエンドポイントの近くで意思決定が実行されることを可能にする。

したがって、システム監視における一実施形態では、ＮＯＣ内の技術者がエラーを確かめ、活動を行うのではなく、ＨＤＣが、トリアージループから技術者を除去し、人間の介入の必要を回避し、たとえば、サーバをＤＮＳ回転から除去することによって、可能な限りエンドポイントの近くで問題を解決するように他のサブシステムをトリガする。

ＨＤＣアーキテクチャでは、エンドポイントのクラスタは、「ＰＯＤ」と呼ばれることがある。したがって、ＮＹ内のエンドポイントは、１つの特定のｐｏｄと見なされてよく、東京内のエンドポイントは別のｐｏｄと見なされることになる。

ＨＤＣ手法では、ＨＤＣプロセスは、各ｐｏｄ内の各エンドポイント上で実行し得る。ローカルスコープレベルで、ＨＤＣは、エンドポイントから収集されるために利用可能であるデータ（たとえば、センサからのデータ、アプリケーション、ネットワーク自体、エンドユーザからのデータ：潜在的に、データの数百または数千の異なる収集物）について知らされる。ライブデータセットを小さく追跡可能に維持するために、いくつかの実施形態では、ＨＤＣはポーリングオンリー方式（ｐｏｌｌ−ｏｎｌｙ ｓｃｈｅｍｅ）を使用することができる。ＨＤＣは、データをアクティブに要求し、次いで、ＨＤＣがタスクを達成するために必要とするライブデータを収集および記憶することができる。さらに、いくつかの実施形態では、ＨＤＣは、特定の質問に回答するか、またはタスクを実行するために要求される最低限の量のデータだけを要求（または、ポーリング）することができる。たとえば、一定の間隔でディスク統計をプッシュまたはポーリングするのではなく、ローカルスコープＨＤＣは、親ＨＤＣまたはコンシューマがディスクに関する質問をしたときのみ、ディスク統計をポーリングすることができる。これは、ＨＤＣシステムにおいてトランスポートされるデータの量を削減し得る。これはでデータに関して要求されるロードおよび処理を削減するだけでなく、データセットを小さく維持することによって、ＨＤＣがデータを相関させる（および、したがって、「このＰＯＤは、システムの平均を上回る２つの標準偏差の割合でパケット損失を受けているか？」または「現在のセンサデータに基づくこの特定の位置におけるこの特定の瞬間の雨の確率は何であるか？」など、複雑な条件付き質問をリアルタイムで組織立てる）ように追跡可能である。

いくつかの実施形態では、そのような質問を組織立てるために、構造化クエリ言語（ＳＱＬ）（米国国家規格協会（ＡＮＳＩ）標準）を使用することができる。たとえば、質問は、「あなたはフルディスクを有しているか？」であり得る。加えて、そのような質問は、アドホックである（たとえば、技術者が質問を対話型インターフェースに入力する）か、または（後でＣテーブル内でより詳細にカバーされる）一定の間隔でポーリングするようにシステム自体の中にプログラムされるか、のいずれかであり得る。いずれの場合も、ＨＤＣは、ＨＤＣエンドポイント階層を下方にトラバースして、質問に回答するために必要なデータを収集し、ツリーを上方へとトラバースして戻るにつれて、そのデータをアグリゲート、削減、および分析することによって、これらの質問に対する回答を得ることを円滑にする。たとえば、複数のエンドポイント上のディスクが９０％を上回る程度にフルであるかどうかを質問する１つの単純なＳＱＬクエリは、次のＳＱＬクエリを使用することができる：
ＳＥＬＥＣＴ ｉｐ，ｄｅｖｉｃｅ，ｐａｔｈ，
ｂｌｏｃｋｓ＿ｆｒｅｅ＊１００／ｂｌｏｃｋｓ ａｓ ｐｃｎｔ＿ｆｒｅｅ
ＦＲＯＭ ｍｏｕｎｔｓ
ＷＨＥＲＥＡＳ ｂｌｏｃｋｓ＞０
ＨＡＶＩＮＧ ｐｃｎｔ＿ｆｒｅｅ＜１０；

質問「あなたはフルディスクを有しているか？」に対する応答が、「はい」である場合（すなわち、ＳＱＬタプルが戻された場合）、コンシューマがポーリングするためにこの情報が利用可能にされてよく、コンシューマはこの情報の活動を行うことができる。次いで、ＨＤＣ階層内で「より上位の」他のＨＤＣがポーリングするために、この決定の結果が利用可能にされ得る。そのようなＨＤＣは、次いで、システム監視の例では、エラー状態をＮＯＣ技術者に通信し、そのエラー状態をウェブインターフェイス内でカスタマに表示するか、またはさらなる分析のために別のシステム内に記憶することができる。

一例としてＳＱＬが使用されているが、システムは、質問を他のクエリ言語で組織立てることができるクエリインターフェースを含んでよい。言い換えれば、システムは、ＨＤＣおよびＨＤＣ階層内の他の機械に問い合わせるために使用され得る代替のまたは追加のクエリインターフェースまたはクエリ言語を含んでよい。

したがって、ＨＤＣ手法では、比較的小さなデータになるまでセグメント化することが望ましい（上記の例と同様に、ディスクに関する生データは単純な「はい」になるまで分析されたか、またはディスクがフルであるかどうかにするは応答ない）。これは、より複雑な決定を行うために、非常に小さなデータセットを階層内のより上位のＨＤＣにトランスポートさせる。たとえば、ロードバランサなどのローカルスコープＨＤＣコンシューマは、その機械上のストレージディスクがフルである場合、機械をサービスから除去することができる。階層内のより上位のＨＤＣがポーリングするために、そのローカルスコープＨＤＣ決定の結果が利用可能にされ得る。グローバルスコープＨＤＣは、次いで、それらの結果を確かめ、多くの機械がフルストレージディスクを有することに留意することができ、したがって、グローバルスコープＨＤＣは、その状況を修正するためのデータパージなど、より高次の活動をトリガすることができる。そのグローバルスコープＨＤＣ決定の結果は、ユニバーサルスコープＨＤＣに利用可能にされ、ユニバーサルスコープＨＤＣは、データ内の変更などに関してカスタマに通知するためにさらに高次の活動をトリガすることができる。この例では、データのソースの近くで分析が実行され、十分なデータが利用可能になるとすぐに活動がトリガされ、より複雑な活動を実行するために、分析されたデータ（結果）が階層内のより上位のエンドポイントに利用可能にされる。

その上、たとえば、技術者が意思決定の基礎をなすデータの詳細を調査することを望む場合、すべてのこれらの決定の裏にある、基礎的なデータが階層内の上部においてオンデマンドでポーリングするために依然として利用可能にされる。

一実施形態では、本明細書で説明するＨＤＣ手法は、ＳＱＬをリアルタイムで使用する。エンドポイントは、互いと通信し、階層を下方に、クエリからの結果を再帰的にアグリゲートし、分析する。

ＨＤＣリアルタイム分散型データ処理システムの利点は、以下を含むが、これらに限定されない：（１）（数千のデータポイントを有する数十万のエンドポイントに対する）スケーラビリティ、（２）高い可用性（基盤故障によりセグメントに区分化された場合、アイランドは自律的に機能し得る）、（３）より少ない人間の介入を可能にする、コンシューマに近い小さな制御ループ、（４）分析が分散されると仮定して、より複雑なデータの相関、（５）そのシステムが１つの調整された決定的システムであると仮定して、より良好な一貫性、および（６）そのシステムがその瞬間にそのコンシューマを満足させるために必要な裸の最低限のデータのみをトランスポートおよび分析すると仮定して、より低いコスト。

本明細書で説明するＨＤＣ技法は、したがって、以下を含むが、これらに限定されない、多種多様なアプリケーションにおける使用法を見出す：（１）ウェブまたはインターネットアプリケーションの基礎となるシステムなど、分散型アプリケーション、（２）ＩｏＴアプリケーション（サーモスタット、火災警報器、セキュリティ、健康支援、産業自動化などに限定されないが、これらなど、任意のインターネットインターフェースセンサ）、または（３）大量の分散データ（たとえば、住宅、建物、国、大陸などの中のすべてのデータ）を収集および分析することが有益であり、収集されたデータに基づいて、コストの低い様式でリアルタイムに決定を行う、任意のシステム。

図３を参照すると、階層データコレクタ（ＨＤＣ）アーキテクチャを有するリアルタイム分散型データ処理システム３００が、複数の（Ｎ個の）ティアを含んでいる。

ＨＤＣは、複数のティア内に位置するエンドポイントにデータ処理を拡散する。一実施形態では、ＨＤＣシステムは、３個のティア、すなわち、（１）ローカルスコープティア、（２）グローバルスコープティア、および（３）ユニバーサルスコープティアを利用する。したがって、実施形態では、この手法は、１つの「中央データベース」または「ロギング」バッチ処理手法を使用しないことを諒解されたい。

上述したように、ＨＤＣ手法の原理は、（１）データセットを小さく維持する、（２）分散処理、（３）１つの故障点も有さない、（４）システム断片が自律的に動作することを可能にする、（５）速度、および（６）低コスト、を含む。また、そのデータが使用される場所に可能な限り近くでデータを分析し、その活動が必要とされる場所に可能な限り近くで活動を実行し、最小データのみを使用し（すなわち、必要に応じたデータのみを要求し）、ますます複雑な分析において使用するために、階層内のより上位のエンドポイントに結果を利用可能にすることが重要である。

履歴情報が利用可能である場合、その情報は、ＨＤＣプロセス内またはその外部の１つまたは複数のシステムによって収集され得る。履歴データは、非常に大きい可能性があり、したがって、履歴データの処理は、これらの目標と対照をなし得る。現在のシステムの１つまたは複数の実施形態によって現在のデータのみを処理することは、したがって、速度を高め、システムのコストを削減する。

ＨＤＣシステム３００では、分析および対応動作は、システム３００の任意のまたはすべてのティア内のエンドポイントによって実行され得る。分析されたデータは、異なるティア内のエンドポイント間でトランスポートされ得る（たとえば、通信され得る）。ＨＤＣシステム３００内のエンドポイントは、任意のコンシューマと通信して、追加の活動を実行することもできる。システム監視のアプリケーションでは、そのようなコンシューマは、必要なとき、トリアージを実行し、不健全なシステムをサービスから除去することができるロードバランサ３０２であり得る。

次に図４を参照すると、ＨＤＣシステムは、複数の機能を並行して実行することが可能なコンピューティングアーキテクチャ４００内のいくつかのまたはすべてのエンドポイント上で実行しているＨＤＣプロセス４０２として実装され得る。一実施形態では、ＨＤＣシステムは、Ｃ＋＋プログラミング言語で実装され、１つまたは複数のプロセッサによって実行される、マルチスレッドの、非ブロッキングプロセスとして提供され得る。当然、ＨＤＣプロセス４０２は、任意のプログラミング言語で、または任意のタイプのソフトウェア、ファームウェア、スクリプトなどによって、実装され得る。

図４の例示的なシステムは、このアプリケーションのために、ローカルスコープティア、グローバルスコープティア、およびユニバーサルスコープティアとして識別されている、３つのレベルまたは論理ティアを示す。一般的な概要では、ユニバーサルスコープティアにおけるエンドポイントは、分析され要約されたたいていのデータに関心を有するコンシューマとインターフェースをとる。システム監視のアプリケーションでは、コンシューマはＮＯＣ技術者であり得るが、他の実施形態では、コンシューマは、エンドユーザ、別のシステム、活動を実行するプログラムなどであり得る。この例示的な実施形態では、ユニバーサルスコープティアにおいて１個のエンドポイントのみが示されているが、他の実施形態では、ユニバーサルスコープティアにおいて複数のエンドポイントを有することが望ましい場合がある。

各エンドポイントは、ティアが割り当てられるか、またはさもなければ、ティアと関連付けられる。各エンドポイントは、少なくとも階層データコレクタ（ＨＤＣ）を含む。実施形態では、各ティアにおけるエンドポイントは、ＨＤＣとコンシューマとを含む。たとえば、ローカルスコープティアにおけるエンドポイントは、ローカルスコープコンシューマを含み得る。いくつかの実施形態では、コンシューマは、個々のエンドポイントの外部にあってよい。たとえば、ローカルロードバランサなどのコンシューマは、エンドポイントの外部、たとえば、ｐｏｄレベル（図４Ａを参照されたい）に提供され得る。

システム監視のアプリケーションでは、グローバルエンドポイントは、グローバルサーバロードバランサ（ＧＳＬＢ）などのコンシューマに関連付けられ得る。ユニバーサルスコープティアに関しても同じことが当てはまる場合がある。各エンドポイントは、ポーリングのために利用可能な複数の異なるデータテーブルを有し、たとえば、１つまたは複数のデータテーブル、１つまたは複数のＣテーブル、および他のテーブルタイプについて、下でより詳細に説明される。あえて言うなら、クエリ（たとえば、ＳＱＬクエリ）に応答して、ＨＤＣは、クエリに回答するために必要な量のデータのみを（たとえば、図５のテーブル１、テーブル２などから）取り出す。すなわち、クエリに応答して、削減された、理想的には最低限の量のデータがＨＤＣに戻される。質問に回答するために、削減されたまたは最低限のデータセットのみが使用されるため、エンドポイント自体の中に受けるオーバヘッドの量は比較的に低い。この手法は「コスト問題」に対処するが、これは、削減された、または最低限の処理が必要とされるためである。さらに、クエリに応答して戻されているデータセットは比較的に小さいため、「スケール問題」にも対処される。またさらに、少量のデータを利用することによって、相関が実行され得、すなわち、システムは、より複雑な分析（たとえば、複数の変数を必要とするクエリ）を実行することができる。

実施形態では、エンドポイントは、データのテーブルをＨＤＣに利用可能にする。ＨＤＣコレクタと呼ばれるサブルーチンに対してプラグインインターフェースを使用する「データテーブル」を含むが、これらに限定されない、データがテーブル内にポピュレートされる多くの方法が存在する。いくつかの実施形態では、コレクタは、データ収集を円滑にし、データがシステムにおいて利用可能であることをＨＤＣが知ることを可能にする。

たとえば、ＨＤＣプロセスがエンドポイント上で開始するとき、ＨＤＣプロセスは、ＨＤＣプロセスに利用可能なすべてのコレクタプラグインを起動させることができ、ひいては、プラグインは、ＨＤＣに対してプラグインが何のデータをポピュレートすることができるかをオンデマンドで通信する。たとえば、ボーダゲートウェイプロトコル（ＢＧＰ）と呼ばれるインターネットルーチンの形で情報を収集するコレクタの場合、スタートアップ時に、ＢＧＰコレクタは、以下の情報を収集するようにそのローカルスコープＨＤＣに命令することができる：

実施形態では、実際のＢＧＰデータはポピュレートされない。このとき、コンシューマが、（以下のコード：「ＳＥＬＥＣＴ ｐｒｅｆｉｘ ＦＲＯＭ ｂｇｐｒｏｕｔｅｓ」を使用することができる）ユニバーサルスコープＨＤＣに対して、ＳＱＬ内で「すべてのＢＧＰルートを示してください」などの質問をした場合、ユニバーサルスコープＨＤＣは、階層内の各レベルがそのレベルにおいてデータをアグリゲートするＨＤＣツリーの再帰をインスタンス化することができる。たとえば、ユニバーサルスコープＨＤＣは、データに関してそのｂｇｐｒｏｕｔｅｓコレクタに尋ね、次いで、ＨＤＣ階層ツリーを下方に探求し、その子（グローバルスコープＨＤＣ）からｂｇｐｒｏｕｔｅｓデータを要求し、次に、その子（グローバルスコープＨＤＣ）は、データに関してそのｂｇｐｒｏｕｔｅｓコレクタに尋ね、次いで、ＨＤ階層ツリーを下方に探求し、その子（ローカルスコープＨＤＣ）からｂｇｐｒｏｕｔｅｓデータを要求し、その子（ローカルスコープＨＤＣ）は、ひいえた、データに関してそのｂｇｐｒｏｕｔｅｓコレクタに質問する、などである。この階層内のコレクタは、そのローカルスコープＢＧＰルータに連絡し、ルートを照合し、結果をｂｇｐｒｏｕｔｅｓデータテーブルにポピュレートすることができる。ｂｇｐｒｏｕｔｅｓデータテーブルの一例は以下の通りである：

実施形態では、階層内のＨＤＣは、データを集めるようにローカルＢＧＰコレクタに求める。ＨＤＣは、次いで、結果をｂｇｐｒｏｕｔｅｓデータテーブル内にポピュレートする。階層内の各ＨＤＣは、結果をアグリゲートして、その親までツリーを再帰的に戻ることができる。たとえば、ローカルスコープＨＤＣは、ｂｇｐｒｏｕｔｅｓテーブルをグローバルスコープＨＤＣに戻すことができ、グローバルスコープＨＤＣは、そのｂｇｐｒｏｕｔｅｓテーブルをローカルスコープテーブルでアグリゲートし、次いで、そのテーブルをユニバーサルスコープＨＤＣに渡し、ユニバーサルスコープＨＤＣは、そのｂｇｐｒｏｕｔｅｓテーブルをグローバルスコープテーブルでアグリゲートする。実施形態では、ユニバーサルスコープＨＤＣは、システム全体内のすべてのノードからのＢＧＰデータを１つの簡潔なｂｇｐｒｏｕｔｅｓテーブル内に戻すことができる。要約すれば、ＨＤＣコレクタは、事前に規定されたデータタイプを用いたテーブルの形式でそのデータを表す任意の方法で任意のデータを集めることができる。

より上位のティアにおけるＨＤＣは、より下位の階層ティア内の子からのデータにアクセスすることができる。このいわゆる、探求およびアグリゲート機能は、「分岐テーブル」と呼ばれるテーブルによって実現され得る。上記のｂｇｐｒｏｕｔｅｓの例では、グローバルスコープＨＤＣは、そのコレクタを介してそのｂｇｐｒｏｕｔｅｓデータテーブルをポピュレートし、次いで、その子からのｂｇｐｒｏｕｔｅｓデータを得るために下方に探求することができる。これは、すべての子のｂｇｐｒｏｕｔｅｓ「データテーブル」に問い合わせる内部機能を実行する、「ｂｇｐｒｏｕｔｅｓ＿ｂｒａｎｃｈ」と名付けられた特別なテーブルに問い合わせることによって行われ得る。ＨＤＣは、次いで、このｂｇｐｒｏｕｔｅｓ＿ｂｒａｎｃｈ分岐テーブルを介して子エンドポイントからのデータを組み合わせ、そのデータをそのローカルｂｇｐｒｏｕｔｅｓ「データテーブル」と組み合わせる。前に述べたように、この機能は、再帰的であり、すなわち、いずれのティアＮもクエリを下方に探求し、この「分岐テーブル」インターフェースを介して、Ｎ＋１ティアからのデータをアグリゲートすることができる。

データテーブルおよび分岐テーブルに加えて、連続的なクエリテーブル（「Ｃテーブル」）が存在し得る。図５をやはり参照すると、ＨＤＣプロセス４０２を実行している各機械５００は、その機械５００が有するテーブルに対してＳＱＬクエリを実行することによって自らに質問することができる（たとえば、「私にはディスクエラーがあるか？」）。そのような自問に対するステートフルな回答は、これらのＨＤＣエンドポイント上の、いわゆる「連続的なクエリテーブル」（または、より単純に「Ｃテーブル」）内に記憶される。この自問は、ＨＤＣがデータを削減し、階層内のより上位のＨＤＣにこれらの結果を利用可能にする、１つの方法である。したがって、Ｃテーブル５０２は、ＨＤＣの自問に応答して、連続的に更新され得る。

したがって、データテーブル５０４は、ＨＤＣが関連付けられた機械上に記憶されるか、またはさもなければ、その機械上で利用可能なデータをその中に記憶させること（またはさもなければ、そのデータに関連付けさせること）が可能であり、Ｃテーブル５０２は、ＨＤＣ自問からのデータをその中に記憶させ（またはさもなければ、そのデータに関連付けさせ）、したがって、Ｃテーブル５０２は、質問またはクエリに対する「リアルタイム」回答をその中に記憶させる。特定の状態セットが満たされる（言い換えれば、Ｃテーブルがステートフルである）ときのみ、エントリ（たとえば、行）がＣテーブル５０２に追加され得ることを諒解されたい。したがって、テーブル内に記憶された情報は、他のテーブル内に記憶された情報から導出されるため、Ｃテーブル５０２は「導出された」テーブルと呼ばれることがある。

ローカルティアＨＤＣは、（監視のアプリケーションでは）：「私にはディスクエラーがあるか？」、「私にはメモリエラーがあるか？」、「私は過負荷であるか？」、「私のインターフェースは破損しているか？」、または、たとえば、気象観測のアプリケーションでは、「露点は低いか？」、「氷点下であるか？」、「風速はハリケーンレベルであるか？」など、複数のクエリを提示することができる。これらの質問の結果はＣテーブル内に記憶される。システムは、任意の数のＣテーブルを作成することができる。したがって、１つまたは複数のＣテーブルが存在し得る。たとえば、システム監視のアプリケーションでは、警告が機械によって発せられた警告に対応する「警告Ｃテーブル」が存在し得る。気象のアプリケーションでは、分析されたステートフルな気象基準の「ｌｏｃａｌ＿ｗｅａｔｈｅｒ＿ｃｏｎｄｉｔｉｏｎｓ」Ｃテーブルが存在し得る。任意のエンドポイントにおいて要求または所望される任意のＣテーブルが作成され得る。

システムはまた、再帰動作を採用し得る。たとえば、再帰動作は、そのサイズを削減するためにデータを連続的に処理することを必要とし得る。一態様では、ＨＤＣは、Ｃテーブルに問い合せ、次いで、前のＣテーブルクエリに対する応答に基づいて追加のＣテーブルを生成することによって、これを行う。

Ｃテーブルは、分析された要約情報を含み得る。これは、コンシューマが、データセットを変更することに応答して、非常に知的な決定を行うことを可能にすることになる。監視の例では、ローカルロードバランサは、システムをサービスから除去するためにＨＤＣデータを消費することができる。気象のアプリケーションでは、モバイルフォンアプリケーションは、潜在的な厳しい気象状態についてユーザに警告するためにＨＤＣデータを消費することができる。

任意のティアにおいて任意のタイプのテーブルが存在し得る。同様のデータ（同じスキーマ）を提供するテーブルは、同じ名称を共有し、問い合わされたとき、ティアを上方にアグリゲートされる。これらのテーブルはまた、１個のティアまたは１個のエンドポイントにおいてのみ存在する個々のテーブルと組み合わされるか、または相関され得る。言い換えれば、テーブルの組合せ、タイプ、および配置には何の制限も存在しない。たとえば、気象アプリケーションでは、数千のローカルスコープＨＤＣコレクタは、「温度」と呼ばれるテーブル内に動的温度データを提供することができ、少数のグローバルスコープＨＤＣコレクタは、「ｃｉｔｉｅｓ＿ｌａｔｌｏｎ」と呼ばれるテーブル内に都市の緯度および経度などの統計データを提供することができる。ユニバーサルスコープＨＤＣティアにおいてより高次の質問がされるとき、ローカル「温度」テーブルからデータが階層の形でローカルスコープからグローバルスコープにアグリゲートされ、次いで、そのデータがグローバルスコープ「ｃｉｔｉｅｓ＿ｌａｔｌｏｎ」テーブルと相関され組み合わされて、都市単位の温度を示す分析をユニバーサルスコープコンシューマに示す。たとえば、システム監視のアプリケーションでは、グローバルスコープＨＤＣは、システム内のすべての機械の物理的位置に関する情報を提供するそのティアに独自のコレクタを有してもよく、この情報は、「ｍａｃｈｉｎｅ＿ｌｏｃａｔｉｏｎｓ」と呼ばれるテーブル内に記憶され得る。たとえば、グローバルスコープＨＤＣコレクタは、１つの特定の機械がアジアにあり、別の機械が欧州にあり、別の機械がオーストラリアにある、等々を明記するデータを提供することができる。次いで、グローバルロードバランサなどのＨＤＣコンシューマは、アジアにおけるクライアント要求に応答して、グローバルスコープＨＤＣに「アジアにおいてどの機械が健全であるか」を尋ねることができる。ＨＤＣは、グローバルスコープにおける「ｍａｃｈｉｎｅ＿ｌｏｃａｔｉｏｎｓ」テーブルをローカルスコープからの、アグリゲートされた「ｍａｃｈｉｎｅ＿ｈｅａｌｔｈ」テーブルと組み合わせて、ロードバランサに回答を提供することができる。要約すると、任意のタイプの任意のテーブルが、任意のティアから、一度または再帰的のいずれかに、アグリゲートされてよく、組み合わされてよく、または相関されてよい。

コンシューマは、任意のティアにおいて任意のタイプのＨＤＣテーブルに対して質問（ＳＱＬクエリ）を提示することができる。たとえば、システム監視のアプリケーションでは、ロードバランサなどのＨＤＣコンシューマは、質問「ユーザ要求に応答して、この位置においてどの機械を割り当てることができるか？」をローカルスコープＨＤＣに提示することができる。したがって、ＨＤＣは、ローカルロードバランサが決定を行うことを可能にするポイントまでデータを処理することができる。同様に、グローバルサーバロードバランサ（ＧＳＬＢ）などのＨＤＣコンシューマは、「欧州のトラフィック急増に対処するために、機械のどの領域的収集が割り当てられるべきか？」など、より高次の質問をグローバルスコープＨＤＣに提示することができる。このようにして、ＨＤＣは、ＧＳＬＢが決定を行うことを可能にするポイントまでデータを処理することができる。したがって、ＨＤＣは任意の数のＮティアを有し得るため、そのような質問および意思決定は、Ｎティア内で実行され得る。

前に述べたように、任意のティアにおける各エンドポイントは、Ｃテーブルおよびデータテーブルを含むが、これらに限定されない、任意のタイプのテーブルを含み得る。さらに、異なるティアにおいて利用可能なテーブルは異なり得る。任意のティアにおいて、ＨＤＣは、連続的に自問し、Ｃテーブルを構築し、Ｃテーブルからデータ／回答をプルして、その独自の質問に回答することができる。より高次の各スコープＨＤＣは、より下位のティアから受信した回答に応答して追加のＣテーブルを構築することもできる。いくつかの実施形態では、ローカルスコープティア内で収集されたデータは、そのティアに関するデータに関連し得ることを諒解されたい。しかしながら、グローバルスコープティアまたはユニバーサルスコープティアなど、すべてのより上位のティアにおいて、ＨＤＣがティアの全域でデータを調べることが可能である。さらに、任意のより上位のスコープティアにおけるＨＤＣは、より下位のティアにおけるＨＤＣに遠隔で問い合わせ、データをプルして、その独自の質問に回答することができる。ＨＤＣは階層的であるため（図３および図４を参照されたい）、ＨＤＣは、その独自のテーブルからの、ならびに階層のより下位のレベルに存在するテーブルからのデータ（たとえば、データテーブルを含む任意の形のテーブルからのデータまたは他のＣテーブルからのデータ）をプルすることができる。一実施形態では、ＨＤＣは、ＨＤＣがＨＤＣの階層内のどこにフィットするかを知っており、したがって、ＨＤＣは、システム内の他のＨＤＣプロセスに問い合わせることができる。実施形態では、ＨＤＣプロセスの作成の間に、ＨＤＣプロセスの場所を階層内に規定する設定が設定され得る。

各ティアにおいて、特定のエンドポイント上で実行しているＬＢおよび／またはＨＤＣプロセスの可視度に少なくとも部分的に応じて、異なる範囲のデータが利用可能であることを諒解されたい。したがって、グローバルスコープティアにおいて利用可能なデータの範囲は、ローカルスコープティアにおいて利用可能なデータのセットよりも大きい場合がある。したがって、グローバルスコープティアにおける機械は、より下位のティアにおける機械内のデータを含み得るグローバル視野を有すると言われる場合があり、ローカルスコープティアにおける機械は、その機械にローカルなデータに対する視野を有する。

上述のように、任意のティアにおけるＨＤＣは、自らに質問し（すなわち、自問し）、Ｃテーブルを生成することができる。しかしながら、ＨＤＣの１つのティアにおいて尋ねた質問のタイプは、ＨＤＣの別のティアにおいて尋ねた質問のタイプとは異なり得る。たとえば、システム監視のアプリケーションでは、ローカルスコープＨＤＣに「特定の機械にディスクエラーまたはメモリエラーがあるか？」尋ねるのではなく、グローバルスコープにおいて「私の下の階層内のどのｐｏｄが使用され得るか？」などの質問をすることができる。そのような質問に対する回答は、たとえば、グローバルティア内に記憶されることになる、「ｐｏｄ＿ａｖａｉｌａｂｉｌｉｔｙ」と名付けられたグローバルスコープＣテーブル内に記憶され得る。

したがって、収集されたグローバル情報は、下のティア内のエンドポイントに関する情報を含み得る。他のエンドポイント（たとえば、ローカルティアにおけるエンドポイント）に関してグローバルスコープＨＤＣによって収集された情報は、分岐テーブルと呼ばれるテーブル内に記憶されてもよい。いくつかの実施形態では、分岐テーブルは、ローカルスコープティアの上のすべてのティアにおけるエンドポイントからの情報をその中に記憶させている場合がある。

任意のより上位のティアにおけるＨＤＣテーブルは、分岐テーブル機構を介して、その独自のティアにおけるデータ（たとえば、データテーブル、Ｃテーブルなど）、ならびにそのティアの下のティアからのテーブルを再帰的にアグリゲートし得ることを諒解されたい。

図４Ａを手短に参照すると、ロードバランサなどのコンシューマが各機械内にローカルに提供され得る。いくつかの実施形態では、ロードバランサコンシューマ４１０が個々の機械の外部に提供され得る。たとえば、いくつかの実施形態では、ローカルロードバランサの形のコンシューマが各クラスタ内に提供され得る。しかしながら、他の実施形態では、ローカルロードバランサは、各クラスタの外部であってよい。ロードバランサは、機械が特定のタスクの要件を満たすことができるかどうか、すなわち、機械が特定の処理ジョブ（たとえば、ロードバランサによって割り当てられた処理ジョブ）を受け入れることができるかどうかに関する特定の決定を行うことができる。したがって、ロードバランサ４１０が、１つのリソースは幾分破損しており、別のリソースはひどく破損しており、別のリソースは健全であると理解した場合、ロードバランサ４１０は、破損したリソースのうちの１つではなく、健全なリソースに処理ジョブを割り当てることができる。ローカルロードバランサは、人間の介入なしにその独自の決定を自律的に行うことができる。故障状態は、システムからリソースを自動的に除去し得る。一実施形態では、その独自のロードバランサを有する各クラスタが提供されてよく、各ロードバランサは他のロードバランサと通信する。

図４を再び参照すると、ＨＤＣはＣテーブルを利用して、追加の質問を生成することができることをやはり理解されたい。たとえば、システム監視のアプリケーションでは、エンドポイントが警告Ｃテーブルおよび健全性Ｃテーブルを含む場合、ＨＤＣは、Ｃテーブル内に記憶されたデータを使用して追加の質問を作成することができる。

最高レベル（すなわち、いわゆる、図４の例示された実施形態におけるユニバーサルスコープティア）において、ＨＤＣは、下のティア内のＨＤＣと同様の様式で動作する。ユニバーサルティアにおいて、ＨＤＣは、ネットワークオペレーションセンタ（ＮＯＣ）または任意の数のデータセンター内に常駐し得、自ら分散され得る。一実施形態では、ユニバーサルスコープティアにおけるＨＤＣは、その下のノードのみを知っている。

ＨＤＣ技法は、本質的に分散された任意の数の異なるデータセットに関して使用されることを諒解されたい。ＨＤＣ手法は、たとえば、ＩｏＴアプリケーション（たとえば、住宅監視センサ、リアルタイム製造プロセスにおける工場内の監視センサなど）において使用され得る。たとえば、ＨＤＣは、住宅内のセンサのシステムからデータを収集し、そのデータを分析し、次いで、コンシューマを介して結果をクラウド内に記憶するために適用され得る。別のＨＤＣシステムは、リアルタイム温度データを収集および分析し、温度が所定の温度よりも高いかどうかを判定することができる。そうである場合、コンシューマは、住宅内の空調をオンにするためのコマンドをトリガすることができる。

そのような要求はポーリングベースであることを諒解されたい。したがって、ポーリングが入り、質問をＨＤＣに提示したとき、ＨＤＣは、データをプルし、データが有効である時間量を提供する。機械は、次いで、割り振られた時間内でデータを適切に処理する。したがって、本質的なレイテンシは存在しない。１つの例示的な実施形態では、システムの目標は、３０秒以下で課題点を検出することである。

本明細書で説明したのは、たとえば、図４に示した処理システムなど、処理システムの部分として提供され得る処理装置によって実行される処理であることを諒解されたい。処理のいくつかは、経験的手順またはデータベースを介して実行されてよく、他の処理は、コンピュータソフトウェア命令またはプロセッサ上で実行している命令のグループを利用して実行されてよい。したがって、本明細書で説明したプロセスのいくつかは、コンピュータプロセッサによって実行されるコンピュータソフトウェアを介して実装され得、他のプロセスは、異なる様式で、たとえば、経験的手順を介して実装され得る。

代替として、処理のいくつかは、デジタル信号プロセッサ（ＤＳＰ）回路または特定用途向け集積回路（ＡＳＩＣ）など、機能的に等価の回路によって実行され得る。本明細書で説明したプロセスは、任意の特定のプログラミング言語のシンタックスを示さない。むしろ、本明細書で説明した処理は、特定の装置の要求される処理を実行する目的で、プロセスを実行するために、もしくは回路を製作するために、またはコンピュータソフトウェアを生成するために当業者が必要とする機能情報を例示する。コンピュータソフトウェアが使用され得る場合、ループおよび変数の初期化および一時変数の使用など、多くのルーチンプログラム要素は示されていないことに留意されたい。本明細書で別段に示されていない限り、説明したプロセスの特定の順序は、単なる例示であり、本発明の趣旨から逸脱せずに、変更され得ることを当業者は諒解されたい。

本明細書で説明したシステムおよび方法は、ハードウェア、ソフトウェア、または組合せで実装され得る。ソフトウェアは、１つまたは複数のプロセッサによって実行されると、プロセッサにシステムおよび方法を実装する動作を実行させる、１つまたは複数のコンピュータ可読媒体上に記憶されたソフトウェア命令を含み得る。

本発明の好ましい実施形態を説明してきたが、これらの概念を組み込んだ他の実施形態が使用され得ることが当業者には現在明らかであろう。したがって、本発明は、説明した実施形態に限定されるべきでなく、続く請求項の趣旨および範囲によってのみ限定されるべきである。

Claims (15)

1. 多数のエンドポイントを有する分散型システムにおいて使用するための分散型リアルタイムデータ収集、処理および対処システムであって、
   ローカルスコープティアに割り当てられた第１の複数のエンドポイントであって、前記ローカルスコープティア内の各エンドポイントが、複数の異なる位置のうちの１つに関連付けられ、前記ローカルスコープティア内の各エンドポイントが、
   ローカルスコープ階層データコレクタ（ＨＤＣ）が存在する前記エンドポイントにローカルな情報を収集するように構成された前記ローカルスコープＨＤＣと、
   活動を実行することが可能な、処理済みデータのローカルコンシューマと
   を含む、第１の複数のエンドポイントと、
   グローバルスコープティアに割り当てられた第１の複数のエンドポイントであって、前記グローバルスコープティア内の各エンドポイントが、
   グローバルスコープ階層データコレクタ（ＨＤＣ）が存在する前記エンドポイントにローカルな情報を収集し、前記ローカルスコープティアよりも下の任意のエンドポイントからの情報も収集するように構成された前記グローバルスコープＨＤＣと、
   前記処理済みデータのグローバルスコープコンシューマと
   を含む、第１の複数のエンドポイントと、
   ユニバーサルスコープティアに割り当てられた、少なくとも１つのエンドポイントであって、前記ユニバーサルスコープティア内の前記少なくとも１つのエンドポイントの各々が、
   ユニバーサルスコープ階層データコレクタ（ＨＤＣ）が存在する前記エンドポイントにローカルな情報を収集し、前記グローバルスコープティア内の任意のエンドポイントおよび前記ローカルスコープティア内の任意のエンドポイントからの情報も収集するように構成された前記ユニバーサルスコープＨＤＣと、
   前記処理済みデータのユニバーサルスコープコンシューマと
   を含む、少なくとも１つのエンドポイントと
   を含む、分散型リアルタイムデータ収集、処理および対処システム。
2. 前記ローカルスコープティア内の各エンドポイントが、前記処理済みデータのローカルスコープコンシューマを含む、請求項１に記載の分散型リアルタイムデータ収集、処理および対処システム。
3. 前記グローバルスコープティア内の各エンドポイントが、前記処理済みデータのグローバルスコープコンシューマを含む、請求項１に記載の分散型リアルタイムデータ収集、処理および対処システム。
4. 前記ローカルスコープティア、前記グローバルスコープティア、および前記ユニバーサルスコープティア内の各エンドポイントが、少なくとも１つのデータテーブルを含む、請求項１に記載の分散型リアルタイムデータ収集、処理および対処システム。
5. 各ローカルスコープＨＤＣ、グローバルスコープＨＤＣ、およびユニバーサルスコープＨＤＣが、Ｃテーブルを生成するための手段を含む、請求項１に記載の分散型リアルタイムデータ収集、処理および対処システム。
6. 前記ローカルスコープティア、前記グローバルスコープティア、および前記ユニバーサルスコープティア内の各エンドポイントが、
   その中に情報を記憶した、少なくとも１つのデータテーブルと、
   少なくとも１つの他のテーブル内に記憶された情報から導出された情報をその中に記憶した、少なくともＣテーブル
   の少なくとも１つを含む、請求項５に記載の分散型リアルタイムデータ収集、処理および対処システム。
7. 前記グローバルスコープティアおよび前記ユニバーサルスコープティア内の各エンドポイントが、少なくとも１つの分岐テーブルを含む、請求項５に記載の分散型リアルタイムデータ収集、処理および対処システム。
8. 多数のエンドポイントを有する分岐型処理システムにおいて使用するための分散型リアルタイムデータ収集、処理および対処方法であって、
   ローカルスコープティア、グローバルスコープティア、およびユニバーサルスコープティアのうちの１つにエンドポイントを割り当てることであって、少なくとも前記ローカルティア内の各エンドポイントが、複数の異なる位置のうちの１つに関連付けられる、割り当てることと、
   前記各エンドポイント内に階層データコレクタ（ＨＤＣ）を提供し、前記ＨＤＣを介して各エンドポイント内のデータを収集することであって、前記ローカルスコープティアにおける各ＨＤＣが、前記ＨＤＣが存在する前記エンドポイントに関するデータを収集し、前記グローバルスコープティアにおける各ＨＤＣが、前記ＨＤＣが存在する前記エンドポイントに関するデータを収集し、前記ローカルスコープティア内の１つまたは複数のエンドポイントからのデータを収集する、収集することと、
   前記ローカルティアにおける前記エンドポイントの各々の中に処理済みデータのローカルスコープコンシューマを提供することと、
   前記グローバルスコープティアにおける前記エンドポイントの各々の中に前記処理済みデータのグローバルスコープコンシューマを提供することと
   を含む、
   分散型リアルタイムデータ収集、処理および対処方法。
9. 前記ローカルスコープティア、前記グローバルスコープティア、および前記ユニバーサルスコープティアのうちの１つまたは複数における１つまたは複数のエンドポイント内に記憶された１つまたは複数のテーブルに記憶された情報に基づいて、外部エンティティに関する活動を自律的に実行すること
   をさらに含む、請求項８に記載の分散型リアルタイムデータ収集、処理および対処方法。
10. 前記ローカルスコープティアにおけるＨＤＣシステム、前記グローバルスコープティアにおけるＨＤＣシステム、および前記ユニバーサルスコープティアにおけるＨＤＣのうちの少なくとも２つの間でデータをトランスポートすることをさらに含む、請求項９に記載の分散型リアルタイムデータ収集、処理および対処方法。
11. データ分析動作がすべてのティア内のすべてのエンドポイント間で分散されるように、前記ローカルスコープティア、前記グローバルスコープティア、および前記ユニバーサルスコープティアの各々の中のすべての前記エンドポイント間で前記データ分析動作を実行することをさらに含む、請求項１０に記載の分散型リアルタイムデータ収集、処理および対処方法。
12. 外部エンティティに関する活動を実行するための処理済みデータのコンシューマをさらに含む、請求項１０に記載の分散型リアルタイムデータ収集、処理および対処方法。
13. 前記ローカルスコープティア、前記グローバルスコープティア、および前記ユニバーサルスコープティアの各々における外部エンティティに関する活動がすべてのティアにおける任意のエンドポイント間で分散されるように、前記外部エンティティに関する活動を実行するコンシューマをさらに含む、請求項１０に記載の分散型リアルタイムデータ収集、処理および対処方法。
14. モノのインターネット（ＩｏＴ）アプリケーションならびにソフトウェアアズアサービス（ＳａａＳ）アプリケーションにおいて前記方法を使用することをさらに含む、請求項８に記載の分散型リアルタイムデータ収集、処理および対処方法。
15. リアルタイム製造プロセスにおいて工場内のセンサからのデータに基づいて、活動を収集、分析、および実行するために前記方法を使用することをさらに含む、請求項１３に記載の分散型リアルタイムデータ収集、処理および対処方法。

Images