JP2022522464A - 分散データソースに存在するデータストリームの連続処理のためのコンピュータ実装方法 - Google Patents

Abstract

分散データソースに存在するデータストリームの連続処理のためのシステム及び方法。この方法は、複数の分散データソースから複数のデータストリームを受信することと、複数のコマンドを使用して、複数のデータストリームのそれぞれを処理することであって、複数のコマンドが、グラフ実行エンジンを使用して、並行して実行される、処理することと、トランスポート層によって、複数のコマンドを使用して、複数のデータストリームのそれぞれを少なくとも１つのデータシンクにトランスポートすることと、を含む。

Description

関連出願の相互参照
本出願は、２０１９年３月１日に出願された米国仮特許出願第６２／８１２，５７３号明細書の利益を主張するものであり、その内容は、本明細書に援用される。

本開示は、概して、移動中のデータの処理に関し、特に、移動中のデータのタグ付けに関する。

ビッグデータから洞察を得るためのアプリケーション及び製品が人気となっている。このようなアプリケーション及び製品は、予測目的でデータの収集、管理、及び分析を行うため、又はリアルタイムの洞察を取り出すために使用される。異なるタイプのデータは、意味のある洞察を提供するために、異なる計算プラットフォームを必要とし得る。洞察は、保存されているデータ、又は移動中のデータから抽出され得る。保存されているデータとは、様々なソースから収集され、その後、事象が生じた後に分析されるデータを指す。データが分析される時点、及びそのデータに対してアクションが起こされる時点は、２つの離れた時点で生じる。これに対して、移動中のデータの分析は、事象が生じるときにリアルタイムで生じる。

移動中のデータのどのような処理も、リアルタイムで行われるべきである。したがって、移動中のデータを処理するためのソリューションを実装する際に、レイテンシーが重要要素である。他の制約は、移動中のデータが、それぞれが独自の形式又は構造を有する、異なるデータソースから収集され得る点である。さらに、複数の異なるソースからのデータは、同時に、且つリアルタイムで処理されるべきである。このような制約により、異なるソースから収集された、大量の移動中のデータを処理できるソリューションは、現在存在しない。具体的には、リアルタイムで、移動中のデータにインデックスを付ける、又はタグを付けることができるソリューションは存在しない。

したがって、上記の課題を克服するソリューションを提供することは有益であるだろう。

本開示の幾つかの例示的実施形態の概要が以下に続く。この概要は、そのような実施形態の基本的理解を提供するために、読み手の利便性のために提供されるものであり、本開示の広さを完全に定義するものではない。本概要は、企図される全ての実施形態の広範囲の概要ではなく、全ての実施形態のうちの主要又は不可欠な要素を識別すること、又は何れかの観点、若しくは全ての観点の範囲を詳述することのどちらも意図していない。その唯一の目的は、後に提示される、より詳細な説明への序章として、簡略化された形で、１又は複数の実施形態の幾つかの概念を提示することである。便宜上、「幾つかの実施形態」又は「特定の実施形態」という用語は、本明細書では、本開示の単一の実施形態又は複数の実施形態を指すために使用され得る。

本明細書に開示される特定の実施形態は、分散データソースに存在するデータストリームの連続処理方法を含む。この方法は、複数の分散データソースから複数のデータストリームを受信することと、複数のコマンドを使用して、複数のデータストリームのそれぞれを処理することであって、複数のコマンドは、グラフ実行エンジンを使用して、並行して実行される、処理することと、トランスポート層によって、複数のコマンドを使用して、複数のデータストリームのそれぞれを少なくとも１つのデータシンクに転送することと、のステップを含む。

加えて、本明細書に開示される特定の実施形態は、分散データソースに存在するデータストリームの連続処理システムを含む。このシステムは、処理回路と、メモリであって、処理回路によって実行されると、複数の分散データソースから複数のデータストリームを受信し、複数のコマンドを使用して、複数のデータストリームのそれぞれを処理し、複数のコマンドは、グラフ実行エンジンを使用して、並行して実行され、トランスポート層によって、複数のコマンドを使用して、複数のデータストリームのそれぞれを少なくとも１つのデータシンクにトランスポートするようにシステムを構成する命令を含む、メモリと、を含む。

本明細書に開示される主題は、本明細書の最後の特許請求の範囲において、具体的に指摘され、明確に請求される。開示される実施形態の上述及び他の目的、特徴、及び利点は、添付の図面と併せて、以下の詳細な説明から明らかとなるだろう。

図１は、様々な実施形態を説明するために利用されるネットワークの図である。

図２は、一実施形態に係るハッシュバケッティングを示す例示的図である。

図３は、一実施形態に係るメタデータ構造を示す例示的図である。

図４は、一実施形態に係るハッシュバケッティング処理を実行する方法を示す例示的フローチャートである。

図５は、様々な実施形態に係る、開示されたコマンドを使用した、連続ストリーミング処理を示す例示的図である。

図６は、一実施形態に係る、グラフ実行を実演する図である。

図７は、開示される実施形態を実行するように構成されたシステムのブロック図である。

図８は、例示的実行グラフである。

本明細書に開示される実施形態が、本明細書の革新的教示の多数の有益な用途の例に過ぎないことに留意することが重要である。一般に、本出願の明細書の記述は、必ずしも、様々な請求された実施形態の何れも限定しない。また、一部の記述は、一部の発明的特徴に当てはまり得るが、他の発明的特徴には当てはまらないことがある。一般に、別段の記載のない限り、一般性を失うことなく、単数の要素は、複数形でもよく、逆の場合も同じである。図面では、幾つかの図を通して、同様の数字は、同様の部分を指す。

図１は、様々な実施形態を説明するために利用される例示的図１００である。図１００は、ネットワーク１２０上で通信する、複数のデータソース１１０－１～１１０－Ｑ（以下、簡潔にするために、個々に、データソース１１０と呼ばれ、まとめて、複数のデータソース１１０と呼ばれる）と、システム１３０と、データストア１４０とを示す。ネットワーク１２０は、無線、セルラー、又は有線ネットワーク、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、メトロエリアネットワーク（ＭＡＮ）、インターネット、ワールドワイドウェブ（ＷＷＷ）、類似のネットワーク、及びそれらの任意の組み合わせでもよいが、これらに限定されない。

ある例示的実施形態では、各データソース１１０は、データレイク、データウェアハウス、ストリーミングデータ、データセット、データベースなどでもよいが、これらに限定されない。データベースは、リレーショナルデータベース、又はＭｏｎｇｏＤＢ（ただし、これに限定されない）などのＮｏＳＱＬタイプのデータベースでもよい。リレーショナルデータベースの例は、Ｏｒａｃｌｅ（登録商標）、Ｓｙｂａｓｅ（登録商標）、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ（登録商標）、Ａｃｃｅｓｓ（登録商標）、Ｉｎｇｒｅｓ（登録商標）などが含まれてもよいが、これらに限定されない。実施形態では、複数のデータソース１１０は、同じ物理構造に存在する論理エンティティでもよい。各データソース１１０に保存されたデータは、構造化データ、非構造化データ、半構造化データ、又はそれらの組み合わせの形式でもよい。

タグ付けを含む（ただし、これに限定されない）処理は、移動中のデータのもの、すなわち、データが複数のデータソース１１０の何れかにセーブされるときの、又は複数のデータソース１１０の１つから、１又は複数の他のデータソース１１０へとデータが転送されるときのリアルタイム処理によるものであってもよい。

システム１３０は、本明細書に開示される様々な実施形態を実行するように構成される。具体的には、システム１３０は、移動中のデータにタグ付けする処理を実装するように構成される。上記の通り、全ての移動中のデータは、リアルタイムで処理されるべきである。実施形態では、タグ付けを可能にするために、システム１３０は、知識リポジトリ１３５に接続されてもよい。知識リポジトリ１３５は、複数のデータソース１１０中のデータのタグ付けに利用される辞書を保持する。例えば、知識リポジトリ１３５は、機密情報にタグ付けするための辞書を含んでもよい。知識リポジトリ１３５は、分散データベースでもよい。機密情報は、不当な開示に対して保護されるあらゆる情報である。現在、組織は、個人情報又は機密情報に対するアクセスを保護することが必要とされている。機密情報の保護は、法的若しくは倫理的理由から、個人のプライバシーに関する問題のため、又は所有権の配慮から必要とされ得る。

システム１３０は、複数のデータソース１１０の何れかにセーブされたコンテンツを迅速にサーチするために利用されてもよい。このために、システム１３０は、異なるデータソース１１０に保存された、異なるタイプのデータを表す、異なって構造化されたメタデータをサポートするために柔軟性のある構造を生成するように構成される。メタデータは、データソース１１０の何れかに保存されたオリジナルのデータを参照する。さらに別の実施形態では、システム１３０は、メタデータの並列処理、より具体的には、異なるデータソースのメタデータの並列マッチングをサポートするように構成される。

以下に詳細に説明するように、システム１３０は、コンテンツアドレス可能ハッシュバケットのための処理（以下、「ハッシュバケッティング」）を実装するように構成される。予め定義されたコマンドセットを使用して、ハッシュ化データに対してリアルタイムでアクションが行われ得る。

システム１３０は、物理マシン、仮想マシン、又はそれらの組み合わせとして実装され得る。物理マシン実施態様を示す、図７に示される一例のブロック略図を以下に説明する。仮想マシンは、ソフトウェアコンテナ、マイクロサービス、ハイパーバイザなどの任意の仮想ソフトウェアエンティティでもよい。

本明細書に開示される実施形態は、図１に示される特定のアーキテクチャに限定されないこと、及び開示される実施形態の範囲から逸脱することなく、他のアーキテクチャが等しく使用されてもよいことに留意されたい。具体的には、システム１３０は、クラウド計算プラットフォーム、データセンタなどに存在してもよい。クラウド計算プラットフォームは、プライベートクラウド、パブリッククラウド、ハイブリッドクラウドなどでもよい。また、ある実施形態では、分散システムとして動作する複数のシステムが存在してもよい。さらに、データストア１４０も同様に分散されてもよい。幾つかの実施態様では、システム１３０は、複数のデータソース１１０の何れかの内部コンポーネント又はインスタンスでもよい。

幾つかの実施形態によれば、修正コンテンツアドレス可能ストレージ（ＣＡＳ）プロセスに基づいたハッシュバケッティング処理が開示される。この処理は、システム１３０によって行われ、１つのデータソース１１０にセーブされた任意の情報をバケット及びバケット内のある特定の場所（レコード）へとマッピングすることを含む。マッピングは、ハッシュ関数を使用して行われる。すなわち、マッピングは、以下のように表現され得る。
Ｄａｔａ＿Ａｄｄｒｅｓｓ＝Ｈ（ｄａｔａｓｅｔ）
ここで、Ｈは、ハッシュ関数であり、「ｄａｔａｓｅｔ」は、マッピングされる情報であり、複数のデータソース１１０の１つに由来し、Ｄａｔａ＿Ａｄｄｒｅｓｓは、バケット内の情報のレコードである。

バケットの数は、予め定義されるが、マッピングに利用されるデータの最上位ビット（ＭＳＢ）の数に応じて拡張可能でもよい。例えば、２最上位バイトを考慮することと、２５６個のバケットの数を、６５５３６個のバケットに拡張され得る。ある実施形態では、任意の２つのバケットのコンテンツは、相互排他的である。すなわち、任意の２つのバケットの共通部分は、空となる。

開示された実施形態によれば、マッピングは、バケット、及びバケット内の（レコード）に対するものである。このために、データセットをバケットにマッピングするための第１ハッシュ関数、及び第１関数によって計算されたハッシュ値をバケット内のレコードにマッピングするための第２ハッシュ関数の２つの異なるハッシュ関数が利用されてもよい：ある例示的実施態様では、第１ハッシュ関数は、ある特定のバケットに対するテラバイト単位のデータを一意に識別するのに十分な１６バイトハッシュ値を生成する１２８ビットのハッシュである。この例示的実施態様では、第２ハッシュ関数は、データセットを各バケット内のレコードにマッピングするために使用される３２ビットの関数である。バケットの数に応じて、単一のバケット内のデータ全体のサイズは、約１／Ｎであるべきであることに留意されたい。Ｎは、バケットの数を指定する整数である。上記の通り、バケットの数「Ｎ」は、予め定義され得る。さらに、第１及び第２ハッシュ関数は変化せず、したがって、これらのハッシュ関数は、それらのオリジナルのデータソース１１０にかかわらず、全てのデータセットに適用されることに留意されたい。

ある実施形態では、ハッシュ化されるデータ中の互いに異なる要素の数を近似するために、生データ近似が利用される。近似は、これらに限定されないが、ＨｙｐｅｒＬｏｇＬｏｇ（ＨＬＬ）、ビットセット、ビットマップなどの技術を使用して行われ得る。

図２は、ある実施形態に係るハッシュバケッティングを示す例示的図２００である。図２００は、多数のＮ個のバケット２１０－１～２１０－Ｎ（以下、簡潔にするために、個々に、１つのバケット２１０と呼ばれ、まとめて、複数のバケット２１０と呼ばれる）を示す。各バケットは、多数のレコード２２０－１～２２０－Ｒ（以下、簡潔にするために、個々に、１つのレコード２２０と呼ばれ、まとめて、複数のレコード２２０と呼ばれ、Ｒは、整数値である）を含む。

各レコード２２０は、バケット中のハッシュ化データの場所（レコード）を複数のデータソース１１０（図１）の１つにおけるオリジナルの場所にマッピングすることを可能にするメタデータを保持する。バケット、レコード、及びメタデータはデータストア１４０内にセーブされ、例えば単一のテーブルに論理的に保持され得ることに留意されたい。

図３は、ある実施形態に係るメタデータ構造３００を示す例示的図である。メタデータ構造３００は、以下の列（又はフィールド）：識別子（ＩＤ）３１０、属性３２０、及びデータ３３０を含む。

ＩＤ列３１０は、１又は複数のデータソース中のオリジナルのデータセットの場所に対する参照を保持する。ＩＤ列３１０の形式は、バケット識別子（ＩＤ）及びＵＲＬを含む。ある例示的構成では、ＵＲＬは、原点データソース中の所与のデータエントリのＵＲＩに関連付けられ得る。例えば、ＵＲＩは、特定の列に対して、リレーショナルデータベースからのデータが記録される際のデータベース、テーブル、及び列名、ファイルシステムからのディレクトリ及びファイル、又はウェブページ、ストリーミングデータなどへのハイパーリンクを含む完全認定経路を指定してもよい。

属性列３２０は、所与のデータセットの全ての属性を保持する。属性のリストには、列のメタデータ（例えば、列名、列のタイプ、列のタイプ名など）、他の列に対する参照、統計値、データセット中の要素の総数、互いに異なる値の数などが含まれてもよいが、これらに限定されない。属性のリストは固定されず、オリジナルのデータのタイプに依存することに留意されたい。例えば、データベース中のデータストレージの属性は、文書又はストリーミングデータの属性とは異なってもよい。

データ列３３０は、例えば、ＨＬＬ値、ビットマップ値、又はその両方である近似されたデータセット値を保持するように構成される。幾つかの実施態様では、近似表現の代わりに、実際の生データがセーブされる。

ある実施形態では、メタデータを保持する全てのレコード２２０が、ＩＤ列の値に基づいて、順番に辞書的にソートされる。リレーショナルデータベースに保存されるメタデータデータセットを保持するレコードの例示的セットが、表１に提供される。

各メタデータにおける値は、典型的には異なる。本明細書に開示されるようなメタデータ及びレコード構造により、バケット中のデータを見つける一定のアクセス時間が可能となることを認識されたい。アクセス時間は、１のオーダーであるＯ（１）と、ＲのオーダーであるＯ（Ｒ）との間であり得、Ｒは、バケット内のレコードの数である。ＩＤ列が、複数のデータソース（１１０、図１）の１つに保存されたオリジナルのデータセットに対する直接的な完全認定経路（又はポインタ）を提供するので、オリジナルのデータに対するアクセス時間も一定である。

ある実施形態では、ハッシュ関数を適用する前に、データセットのビットがスライスされる（すなわち、ビットスライシング動作）。これは、処理時間を加速させるため、及びメモリ及びＣＰＵなどの計算資源を節約するために実行される。ある実施形態では、データセット全体が、複数のサブセットにスライスされる。各サブセットは、ハッシュ関数によって生成されたハッシュ値の限定範囲に関してのみ信頼できる。具体的には、ハッシュ関数は、各サブセットにわたり計算される。例えば、３２ビットのハッシュ関数の場合、１０２４個のサブセットが作成される。さらに、これらのサブセットにわたり計算されたハッシュ値は、パーティションにセーブされる。パーティションの数は、サブセットの数よりも大幅に少ない。例えば、パーティションの数は、１６であり得る。サブセット及びパーティションの数は、２の累乗である任意の数であってもよいことに留意されたい。

パーティションへの分散は、ハッシュの値のＭＳＢに基づく。非限定例として、もしＭＳＢビット（例えば、最初の４ビット）もしハッシュ値ハッシュ値の最初の４ビットが「００００」であれば、ハッシュ値は、パーティション＃０に向けられ、もしハッシュ値の最初の４ビットが「０００１」であれば、ハッシュ値は、パーティション＃１に向けられるなどである。

特定の実施形態では、スライスされたサブセット、それらのそれぞれのハッシュ値、又はその両方に対して、算術演算が行われる。このような演算には、濃度、連結、共通集合、結合、調和などが含まれてもよい。

図４は、ある実施形態に係る、移動中のデータに対してハッシュバケッティング処理を実行する方法の例示的フローチャート４００である。このプロセスは、リアルタイムで行われる。Ｓ４１０では、入力データセットが受信される。入力データセットは、任意のデータソース（例えば、複数のデータソース１１０のうちの１又は複数、図１）から読み出され、取り出され、又は他の方法で受信されてもよい。入力データセットには、例えば、ファイル、ファイルの一部、データベーステーブル、データベーステーブルの１又は複数の列、データエントリ、データオブジェクト（例えば、画像、ビデオファイルなど）などが含まれてもよい。

Ｓ４２０では、データセットをバケットにマッピングするために、第１ハッシュ関数が適用される。ある例示的実施態様では、第１ハッシュ関数は、１２８ビットのハッシュ関数である。

Ｓ４３０では、Ｓ４２０で決定されたバケット内のレコードを識別するために、第２ハッシュ関数が、第１関数によって計算されたハッシュ値に適用される。ある例示的実施態様では、第２ハッシュ関数は、各バケット内のデータを識別するために使用される３２ビットの関数である。さらに、特定の実施形態では、１つのハッシュ関数が、データセットを、決定されたバケット内の各レコードにマッピングするために利用され得ることに留意されたい。

幾つかの実施態様では、データセットは、第２ハッシュ関数を適用する前に、スライスされる。上記の通り、データセットは、複数のサブセットにスライスされる。各サブセットは、ハッシュ関数によって生成されたハッシュ値の限定範囲に関してのみ信頼できる。

ある実施形態では、ハッシュ関数を適用する前に、データセットは、予め定義された数のサブセットにスライスされ、第２ハッシュ関数は、各サブセットにわたり計算される。これらのサブセットにわたり計算されたハッシュ値は、それぞれのハッシュの値に基づいて、パーティションに保存される。

Ｓ４４０では、データセットに関する情報（メタデータ）は、データセットに基づいて生成される。メタデータは、一般的に、各データセットに関連付けられ、データセットのソースのアドレス（例えば、ＵＲＬ又はＵＲＩ）、データセットの形式（例えば、ｔｅｘｔ、ｄｏｃ、ｐｄｆ、ｓｏｕｎｄ、ｖｉｄｅｏ、ｊｐｅｇなど）、このデータセットを生成したソフトウェアのタイプ（例えば、ワードプロセッサ、関係データベース、データストリームなど）を含む。場合によっては、ほとんどのファイルの最初に、データセット内のデータのタイプを識別するのに役立つマジックバイトが存在する。ここでの表形式データセットは、テーブル名、列及び列の名、タイプ、サイズなどの構成である。

ある実施形態では、Ｓ４４０は、入力データセットのメタデータを抽出すること、及びメタデータの構造（列）のコンテンツを決定することを含む。このような列は、ＩＤ、属性、及びデータ列を含む。メタデータの列の例及び定義は、上に記載されている。

Ｓ４５０では、生成されたメタデータは、決定されたバケット内の各レコードに格納される。上記の通り、各バケット内のレコードは、順番にソートされてもよい。

幾つかの実施形態では、本明細書で述べたハッシュバケッティング処理は、これに限定されないが、機密情報を含む情報の効率的且つ高速のタグ付けに利用できる。上記の通り、機密情報は、不当な開示に対して保護される、あらゆる情報である。

機密情報（又はその他のタイプの情報）のタグ付けは、上記のようなハッシュバケッティング処理を使用して実行される。ある実施形態では、知識リポジトリ（例えば、知識リポジトリ１３５、図１）は、例えば機密情報として分類された情報のメタデータを含む。タグ付け処理は、入力データセットをハッシュ化すること、及びハッシュ値をリポジトリ知識のコンテンツとマッチングすることを含んでもよい。マッチが見つかった場合、そのデータセットは、機密情報としてタグ付けされてもよい。メタデータは、入力データセットに対して生成されることに留意されたい。ある例示的実施態様では、機密情報タグは、メタデータの属性の一部として保存されてもよい。マッチングされるデータセットは、移動中のデータであるように構成される。さらに、知識リポジトリが機密情報（又はその他の情報）のメタデータを保持することに留意されたい。メタデータの生成は、本明細書で述べたハッシュバケッティング処理を使用して作成される。

特定の実施形態では、知識リポジトリのコンテンツに対するマッチングは、これらに限定されないが、自然言語処理（ＮＬＰ）、パターンマッチング、機械学習などを含む技術を使用して実行されてもよい。

移動中のデータの処理は、リアルタイムで実行される。複数のデータソースが存在する計算環境は、本質的に分散されており、データストリーム処理を実施する。データソースのタイプ及び計算環境にかかわらず、このような環境において移動中のデータの処理をサポートするために、モジュラー処理アーキテクチャが本明細書に開示される。

モジュラー処理アーキテクチャは、本明細書で定義されるコマンドの実行により実現される。ある例示的実施形態では、コマンドは、以下のインタフェースを使用して定義される。
コマンド＜Ｉ，Ｏ，Ｐ，Ｓ＞
ここで、「Ｉ」は、コマンドに対する入力を表すジェネリックタイプであり、「Ｏ」は、コマンドの出力を表すジェネリックタイプであり、「Ｐ」は、コマンドのパラメータであり、「Ｓ」は、コマンドの順次コール間の中間データの管理を提供する持続的サービスである。

入力及び出力は、外部データソースへの参照として提示され得る。ある実施形態では、コマンドの実行は、ランタイム環境からのそれぞれのインスタンスによるものである。ランタイム環境は、適切なコマンドの属性を割り当ててもよい。本明細書で定義される何れのコマンドも、ステートレスであり、そのため、分散計算に適する。しかし、コマンドは、スタンドアロンプログラム又はアプリケーションとして走ることはできない。

具体的には、コマンドは、ステートレスインスタンスであり、したがって、外部のデータソース及びパラメータに依存する。パラメータ及び持続的サービスに対する参照（すなわち、外部のデータソースへのポインタ）は、通常、明示的に提供される。入力データは、明示的に、データの集まりとして、又は外部データソースに対する完全認定経路としての参照により、コマンドへ送られてもよい。

コマンドは、データの集まりとして、計算結果を出力し、又はそれらの結果を保存するために外部データセットを使用し得る。コマンドは、プロキシとしても機能し得る。プロキシとして機能するコマンドは、Ａｐａｃｈｅ Ｆｌｉｎｋ、Ｓｐａｒｋ、Ｓｔｏｒｍなどの外部計算フレームワークにリクエストをリダイレクトし得る。

幾つかの実施形態によれば、パイプラインのコマンドは、例えば、ソースコマンド、シンクコマンド、及び処理コマンドを含んでもよい。

以下は、ソースコマンドの幾つかの例である：データをストリーミングフレームワーク（例えば、Ａｐａｃｈｅ Ｋａｆｋａ（登録商標））に取り込むこと；ローカルファイルシステムをサポートすること（例えば、順次読み出し、スキャニング、及びフィルタリング）；データストアとしてローカルファイルシステムを備えたＨＢａｓｅをサポートすること（データに対してクエリー、スキャン、及びフィルタリングを行うこと）；及びグラフデータベースをサポートすること（グラフデータベースに対してクエリー及び横断を行うこと）。

以下は、データ変換コマンドの幾つかの例である：サーチコマンド：ソースデータのインデックス作成及びマッピング；サーチ及びクエリーデータ；カスタムフィルタリング及びアグリゲーション；データサンプリング及び基礎統計：ローカルファイルシステムからのサンプルの生成；統計値（例えば、平均（ｍｅａｎ）、中央値、平均（ａｖｅｒａｇｅ）、標準偏差など）の計算；統計モデル；機械学習処理；並びにエージェント及び外部計算フレームワークを実行するためのプロキシコマンド。

以下は、シンクコマンドの幾つかの例である：データをローカルファイルシステムに投げ込むこと；データをＨＤＦＳ／ＨＢａｓｅ／Ｃａｓｓａｎｄｒａに書き込む／投げ込むこと；並びにグラフのノード及びエッジとして、データをグラフデータベースに書き込むこと。

パイプラインコマンドは、２つのモード、すなわち、順次及び非同期的に、実行され得る。パイプラインの次のコマンドが、前のコマンドの実行が終了して初めて実行される場合に、コマンドは、順次実行される。パイプラインの全てのコマンドが、同時に実行されることが可能であり、非同期メッセージング層を使用して互いにデータをやり取りすることができ、及び入力オブジェクトが必要なデータを提供するとすぐに処理を行うことができる場合に、コマンドは非同期的に実行される。メッセージング層は、後で処理を行うことを可能にするためにバッファを使用する任意のシステムであってもよい。これは、処理が、先送りすることができず、配信時に、又はメッセージの喪失時に行われるべきである、同期メッセージングシステムとは対照的である。

ある実施形態では、コマンドは、外部システム及び／又はフレームワークと通信し、それらの間で通信する際に、標準化された入力及び出力オブジェクトを使用する。構造的に、入力及び出力は共に同じであり、したがって、コマンド間で通信される出力に関して、追加の処理は必要ない。パイプラインコマンドは、入力オブジェクトにおけるパラメータとして、他のコマンドへの参照のリストを受理し、その後、これらのコマンドを実行し得る。

図５は、様々な実施形態に係る、コマンド及びグラフ実行エンジンを使用した、移動中データストリームの連続処理を示す例示的図５００を示す。図５に例示される処理は、パターンマイニングコマンド（５０１）、ドメインプロファイリングコマンド（５０２）、及び関係プロファイリングコマンド（５０３）を並行して実行するコマンドフローである。トランスポート層５１０は、データソース５２０からデータを転送する。コマンド５０１、５０２、及び５０３は、トランスポート層５１０によって、処理結果をデータシンク５３０に送る。

ある例示的実施態様では、データソース５２０は、例えば、Ｏｒａｃｌｅ（登録商標）データベースでもよく、データシンク５３０は、例えば、Ｃａｓｓａｎｄｒａ（登録商標）及びＧｒａｐｈ ＤＢでもよい。トランスポート層５１０は、例えば、Ｃａｓｓａｎｄｒａ Ｋａｆｋａ（登録商標）を使用して実現されてもよい。Ｋａｆｋａ（登録商標）は、リアルタイムデータ供給を取り扱うための、統一された、高スループットの、低遅延プラットフォームを提供するように設計されたオープンソースプラットフォームである。

ある実施形態では、コマンドの並列実行をサポートするために、グラフ実行エンジンが実装される。複数の計算ノードにわたってデータが分散される場合に、グラフ実行エンジンが、分散システムにおいて必要とされる。

ある実施形態によれば、グラフ実行エンジンに関する新規の手法が開示される。既存のグラフ実行技術とは対照的に、開示されるグラフ実行エンジンは、複数のグラフノードにわたる、直接的な横断を使用しない。代わりに、グラフ実行エンジンは、実行グラフノード（又は単に「ノード」）ごとに実行ステータスを定義するキューを使用するように構成される。ノードはコマンドであり、一方、実行グラフは、コマンド呼び出しの順序である。ある実施形態では、ノードは、コマンドの環境、入力、及び出力を記述する。図８は、３つのノード８１０－１、８１０－２、及び８１０－３を備えた例示的実行グラフ８００を示し、各ノードは、以下の３つのコマンドを表す：
８１０－１：ｉｎｇｅｓｔＤａｔａＦｒｏｍＤｂ （１）；
８１０－２：ｃａｌｃｕｌａｔｅＢｉｔＳｅｔＡｎｄＨｌｌ （２）；及び
８１０－３：ｓａｖｅＲｅｓｕｌｔＩｎＨｂａｓｅ （３）。
実行の順序は、ノードの順序による：すなわち、８１０－１、８１０－２、及びその後に８１０－３。

ある実施形態では、処理の異なるフェーズを指定するために、各キューは、コード化される（例えば、色分けされる）。例えば、キューは、緑、白、青、灰色、赤、及び黒で色分けされ得る。各キューは、先入れ先出し（ＦＩＦＯ）キューとして実現されてもよい。キューは、対応する処理状態にあるグラフ中のノードに対する参照（ポインタ）を保持する。

ある例示的実施態様では、緑色キューは、ソースとして機能し、黒キューは、シンクとして機能し、灰色キューは、「インプロセス（ｉｎ－ｐｒｏｃｅｓｓ）」状態を表す。白、青、及び赤のキューは、開始ステータスと終了ステータスとの間のノードの異なる処理状態を表す。開始ステータス及び終了ステータスは、それぞれ、緑キュー及び黒キューによって表される。

キューに配置された実行グラフノードは、暗黙的に関連付けられてもよい。各ノードは、同じキュー、又は異なるキューに存在し得る「インノード」及び「アウトノード」のコンテキストを保持し得る。このようなノードは、それらのステータス及び現在のノードの処理の結果に基づいて、あるキューから別のキューへと転送される。アウトノードは、そのエッジにソースとしての現在のノードからのデータを有するノードである。

白キューは、結果の状態に応じて、現在のノードのアウトノードを黒キュー又は赤キューのどちらかに移動させ得る。青キューは、赤キューからのノードを処理するように構成され、結果の状態に応じて、ノードを黒キュー又は赤キューのどちらかに移動させる。赤キューは、現在のノードの未処理インノードを処理し及び青キューへ移動する。ある構成では、各ノード内の処理は、非同期的であってもよい。

図６に例示されるように、本明細書に開示されるグラフ実行は、実行グラフの各ノードを緑キュー６１０から黒キュー６６０に移動させようとする。

グラフ実行エンジンによって行われる処理は、全てのノードを緑キュー６１０に配置する。次いで、グラフ内の全ての開始ノードが、（図示された）白キュー６２０又は（図示されない）青キュー６４０に配置される。白キュー６２０内の全てのノードは、処理されるのを待っている。処理される準備ができているノードは、ノードの処理を開始するために、灰色キュー６３０に移動される。キューがＦＩＦＯキューであるので、キュー内の第１のノードは、処理、すなわち、灰色キュー６３０に転送される。ノードの処理が完了すると、ノードは、黒キュー６６０に転送される。同時に、現在のノードのアウトノードが、緑キュー６１０から白キュー６２０へと移動される。

白キュー６２０におけるノードの処理が完了すると、赤キュー６５０内のノードの処理が実行される。まず、赤キュー６５０内の各ノードに関係する、緑キュー６１０内の全てのインノードが、検出される。このようなノードは、青キュー６４０に転送される。青キュー６４０内のノードは、白キュー６２０内のノードと同じように処理される。次に、ノードは、赤キュー６５０から黒キュー６６０へと移動され得る。

グラフ実行エンジンは、他のタイプのデータ構造を利用することができ、色分けキューに限定されないことを認識されたい。例えば、上述の色分けキューの代わりに、ステートマシンが利用され得る。さらに、グラフ実行エンジンは、ハードウェア論理ハードウェア論理コンポーネントとして実現され得ることを認識されたい。グラフ実行エンジン１３０は、システム１３０又はスタンドアロン要素の一部でもよい。ハードウェア論理コンポーネントの例が提供される。

図７は、ある実施形態に係る、実装されたシステム１３０の例示的ブロック図を示す。システム１３０は、メモリ７１５、ストレージ７２０、及びネットワークインタフェース７３０に接続された処理回路７１０を含む。ある実施形態では、システム１３０のコンポーネントは、バス７４０を介して通信可能に接続されてもよい。

処理回路７１０は、１又は複数のハードウェア論理コンポーネント及び回路として実現されてもよい。例えば、限定されることなく、使用され得るハードウェア論理コンポーネントの実例的タイプに、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、特定用途向け標準製品（ＡＳＳＰ）、システムオンチップシステム（ＳＯＣ）、汎用マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ（ＤＳＰ）など、又は計算、若しくは情報の他の操作を行うことができる、その他のハードウェア論理コンポーネントが含む。

メモリ７１５は、揮発性（例えば、ＲＡＭなど）、不揮発性（例えば、ＲＯＭ、フラッシュメモリなど）、又はそれらの組み合わせでもよい。ある構成では、本明細書に開示される１又は複数の実施形態を実装するためのコンピュータ可読命令が、ストレージ７２０に保存されてもよい。

別の実施形態では、メモリ７１５は、ソフトウェアを保存するように構成される。ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、或いはその他の名称で呼ばれるかにかかわらず、あらゆるタイプの命令を意味すると広く解釈されるものとする。命令は、（例えば、ソースコード形式、バイナリコード形式、実行可能コード形式、又はコードのその他の適切な形式の）コードを含んでもよい。命令は、１又は複数のプロセッサによって実行されると、処理回路６１０に、本明細書に記載される様々な処理を行わせる。具体的には、命令は、実行されると、処理回路７１０に上述のようなハッシュバケッティング処理を行わせる。処理回路７１０は、コマンド及びグラフ実行エンジンも実行するように構成される。

ストレージ７２０は、磁気ストレージ、光学式ストレージなどでもよく、例えば、フラッシュメモリ、又は他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、又は所望の情報を保存するために使用され得るその他の媒体として実現されてもよい。

ネットワークインタフェース７３０は、システム１３０が、少なくとも１つの様々な複数のデータソース（図１、１１０）と通信することを可能にする。

本明細書に記載される実施形態は、図７に示される特定のアーキテクチャに限定されないこと、及び開示される実施形態の範囲から逸脱することなく、他のアーキテクチャが等しく使用されてもよいことを理解されたい。

本明細書に開示される様々な実施形態は、ハードウェア、ファームウェア、ソフトウェア、又はそれらの任意の組み合わせとして実装され得る。また、ソフトウェアは、好ましくは、部分、又は特定のデバイス及び／又はデバイスの組み合わせから構成される、プログラムストレージ装置又はコンピュータ可読媒体上で有形的に具現化されたアプリケーションプログラムとして実装される。アプリケーションプログラムは、任意の適切なアーキテクチャを含むマシンにアップロードされ、そのマシンによって実行されてもよい。好ましくは、マシンは、１又は複数の中央処理装置（ＣＰＵ）、メモリ、及び入出力インタフェースなどのハードウェアを有するコンピュータプラットフォームに実装される。コンピュータプラットフォームは、オペレーティングシステム及びマイクロ命令コードも含んでもよい。本明細書に記載される様々な処理及び機能は、そのようなコンピュータ又はプロセッサが明示的に示されているかどうかにかかわらず、ＣＰＵによって実行され得る、マイクロ命令コードの一部、或いはアプリケーションプログラムの一部のどちらか、又はそれらの任意の組み合わせでもよい。加えて、追加のデータストレージ装置及び印刷装置などの様々な他の周辺装置が、計算プラットフォームに接続されてもよい。さらに、非一時的なコンピュータ可読媒体は、一時的な伝搬信号を除く、任意のコンピュータ可読媒体である。

本明細書では、アイテムのリストの後に続く「少なくとも１つ」という表現は、リストされたアイテムの何れも個々に利用することができ、又はリストされたアイテムの２つ以上の任意の組み合わせを利用することができることを意味する。例えば、システムが、「Ａ、Ｂ、及びＣの少なくとも１つ」を含むと記載される場合、システムは、Ａのみ、Ｂのみ、Ｃのみ、Ａ及びＢの組み合わせ、Ｂ及びＣの組み合わせ、Ａ及びＣの組み合わせ、又はＡ、Ｂ、及びＣの組み合わせを含み得る。

本明細書に記載される全ての例及び条件文言語は、開示される実施形態の原理及び当該分野を前進させるために本発明者によって寄与される概念を読者が理解することを助ける教育上の目的を意図したものであり、このような具体的に記載された例及び条件に限定されないと解釈されるものである。また、開示される実施形態の原理、局面、及び実施形態、並びにそれらの具体的な例を記載する本明細書の全ての記述は、それらの構造的及び機能的均等物の両方を包含することが意図される。加えて、このような均等物は、現在知られている均等物、並びに今後開発される均等物の両方を含むこと、すなわち、構造にかかわらず、同じ機能を行う、開発されたあらゆる要素を含むことが意図される。

Claims (23)

1. 分散データソースに存在するデータストリームの連続処理のためのコンピュータ実装方法であって、
   複数の分散データソースから複数のデータストリームを受信することと、
   複数のコマンドを使用して、前記複数のデータストリームのそれぞれを処理することであって、前記複数のコマンドは、グラフ実行エンジンを使用して、並行して実行される、処理することと、
   トランスポート層によって、前記複数のコマンドを使用して、前記複数のデータストリームのそれぞれを少なくとも１つのデータシンクに転送することと、
   を含む、コンピュータ実装方法。
2. 前記複数のコマンドのそれぞれは、以下のインタフェース：
   コマンド＜Ｉ，Ｏ，Ｐ，Ｓ＞
   を使用して定義され、
   「Ｉ」は、コマンドに対する入力を表すジェネリックタイプであり、「Ｏ」は、前記コマンドの出力を表すジェネリックタイプであり、「Ｐ」は、コマンドのパラメータを含み、「Ｓ」が、前記コマンドの順次コール間の中間データの管理を提供する持続的サービスである、請求項１に記載のコンピュータ実装方法。
3. 各コマンドは、ステートレスインスタンスであり、前記複数のデータソースに依存する、請求項１に記載のコンピュータ実装方法。
4. 前記複数のコマンドは、パイプライン方式で実行される、請求項１に記載のコンピュータ実装方法。
5. パイプライン化コマンドは、順次実行される、請求項４に記載のコンピュータ実装方法。
6. パイプライン化コマンドは、非同期的に実行される、請求項４に記載のコンピュータ実装方法。
7. メッセージング層を使用して、非同期的に実行されるコマンド間でデータを交換することをさらに含む、請求項６に記載のコンピュータ実装方法。
8. コード化キューを前記グラフ実行エンジンによって処理される実行グラフのノードに関連付けることをさらに含み、各ノードは、コマンドと関連付けられ、前記実行グラフは、前記複数のコマンドの実行の順序を決定する、請求項６に記載のコンピュータ実装方法。
9. 各コード化キューは、コマンドの処理状態における異なるステータスを決定し、各キューは、前記実行グラフのノードに対するポインタを保持する、請求項６に記載のコンピュータ実装方法。
10. 前記データストリームが、移動中のデータを含む、請求項１に記載のコンピュータ実装方法。
11. 前記グラフ実行エンジンが、ハードウェア論理コンポーネントである、請求項１に記載のコンピュータ実装方法。
12. 分散データソースに存在するデータストリームの連続処理プロセスを処理回路に実行させる命令を保存する、非一時的なコンピュータ可読媒体であって、前記プロセスが、
    複数の分散データソースから複数のデータストリームを受信することと、
    複数のコマンドを使用して、前記複数のデータストリームのそれぞれを処理することであって、前記複数のコマンドは、グラフ実行エンジンを使用して、並行して実行される、処理することと、
    トランスポート層によって、前記複数のコマンドを使用して、前記複数のデータストリームのそれぞれを少なくとも１つのデータシンクに転送することと、
    を含む、非一時的なコンピュータ可読媒体。
13. 分散データソースに存在するデータストリームの連続処理のためのシステムであって、
    処理回路と、
    メモリであって、前記処理回路によって実行されると、
    複数の分散データソースから複数のデータストリームを受信し、
    複数のコマンドを使用して、前記複数のデータストリームのそれぞれを処理し、前記複数のコマンドは、グラフ実行エンジンを使用して、並行して実行され、
    トランスポート層によって、前記複数のコマンドを使用して、前記複数のデータストリームのそれぞれを少なくとも１つのデータシンクに転送するように前記システムを構成する命令を含む、メモリと、
    を含む、システム。
14. 前記複数のコマンドのそれぞれは、以下のインタフェース：
    コマンド＜Ｉ，Ｏ，Ｐ，Ｓ＞
    を使用して定義され、
    「Ｉ」は、コマンドに対する入力を表すジェネリックタイプであり、「Ｏ」は、前記コマンドの出力を表すジェネリックタイプであり、「Ｐ」は、コマンドのパラメータを含み、「Ｓ」は、前記コマンドの順次コール間の中間データの管理を提供する持続的サービスである、請求項１３に記載のシステム。
15. 各コマンドは、ステートレスインスタンスであり、前記複数のデータソースに依存する、請求項１３に記載のシステム。
16. 前記複数のコマンドは、パイプライン方式で実行される、請求項１３に記載のシステム。
17. パイプライン化コマンドは、順次実行される、請求項１６に記載のシステム。
18. パイプライン化コマンドは、非同期的に実行される、請求項１６に記載のシステム。
19. 前記システムは、
    メッセージング層を使用して、非同期的に実行されるコマンド間でデータを交換する
    ようにさらに構成される、請求項１８に記載のシステム。
20. 前記システムは、
    コード化キューを前記グラフ実行エンジンによって処理される実行グラフのノードに関連付けるようにさらに構成され、各ノードは、コマンドと関連付けられ、前記実行グラフは、前記複数のコマンドの実行の順序を決定する、請求項１８に記載のシステム。
21. 各コード化キューは、コマンドの処理状態における異なるステータスを決定し、各キューが、前記実行グラフのノードに対するポインタを保持する、請求項１８に記載のシステム。
22. 前記データストリームは、移動中のデータを含む、請求項１３に記載のシステム。
23. 前記グラフ実行エンジンは、ハードウェア論理コンポーネントである、請求項１３に記載のシステム。

Images