JP6028857B2 - データストリーム処理の並列化プログラム、及びデータストリーム処理の並列化システム - Google Patents
データストリーム処理の並列化プログラム、及びデータストリーム処理の並列化システム Download PDFInfo
- Publication number
- JP6028857B2 JP6028857B2 JP2015517949A JP2015517949A JP6028857B2 JP 6028857 B2 JP6028857 B2 JP 6028857B2 JP 2015517949 A JP2015517949 A JP 2015517949A JP 2015517949 A JP2015517949 A JP 2015517949A JP 6028857 B2 JP6028857 B2 JP 6028857B2
- Authority
- JP
- Japan
- Prior art keywords
- query
- function
- relationship
- properties
- common
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24568—Data stream processing; Continuous queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24532—Query optimisation of parallel queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24553—Query execution of query operations
- G06F16/24554—Unary operations; Data partitioning operations
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computational Linguistics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は、データストリーム処理の並列化プログラム、システム、方法に関する。
近年、ネットワークに接続される様々な情報ソース、機器、センサ等から提供される大量のデータであるビッグデータを収集し活用するサービスの需要が高まってきている。実世界で発生する大量のデータを順次処理できれば、リアルタイムに近い状態で情報を得ることができる。例えば、様々なセンサから常時提供される大量のデータストリームを順次処理できる技術が必要とされている。
このような要求に応える技術として、ビックデータを扱う複合イベント処理が知られている。しかしながら、近年のスマートフォンやタブレット端末の普及は、通信量を飛躍的に増大させている。また、今後、人間だけでなく大量の機器がネットワークにつながるようになると、通信量はますます増加することが予想される。したがって、このような技術のさらなる発展が必要となってきている。
この場合、例えば、データストリームから得られたデータ(イベントの列)を一旦データベースに格納してから、データの抽出や加工を行うことができる。しかしながら、リアルタイムに的確な情報を簡便に得る観点からは、上記のような方策は、ニーズに対する十分な結果が得られないことが多い。したがって、大量のデータストリームをリアルタイムで(または、リアルタイムに近い状態で)処理し分析する技術が必要とされている。そして、このニーズを満足するためには、データストリームを並列的に順次処理する技術が必要とされる。
本明細書では、データストリームは、複数のイベントを含むため、イベント列とも称す。
図1は、データストリーム処理の例を示している。図示されるように、3つの入力ストリーム(110,120,130)に対して、ストリーム処理システム140が、データストリームを順次処理する。そして、このストリーム処理システム140が、2つの出力ストリーム(150,160)を提供する。例えば入力ストリーム110においては、複数のイベント(111,112,113)が、時系列的にストリーム処理システム140に投入される。
ストリーム処理システム140は、複数のクエリ(142,144,146,148,149)を含んでいる。これらのクエリは、静的なデータベースの処理に用いられるクエリと近似したものである。しかしながら、ストリーム処理システム用のクエリは、入力情報に対して常時動作し、必要とされる出力を提供する点で、データベースのためのクエリとは異なる側面を有する。また、あるクエリの出力が別のクエリの入力になっていることも、データベース用のクエリとは異なる。したがって、本明細書で用いる用語「クエリ」は、データベースのクエリとは異なる機能をも有していることに留意すべきである。
また、各クエリは、複数の矢印で示されるように連結されている。これらの矢印は、データの流れ(データストリーム)を示している。そして、ストリーム処理システム140から出力されたストリーム150には、例えば複数の処理結果(151,152)が含まれる。なお、本明細書においては、ストリーム処理システム140に含まれる複数のクエリの結合関係を示すグラフをクエリグラフと呼ぶ。そして、クエリグラフで表されるクエリの集合及び各クエリの関係を含む処理プログラムをデータストリームプログラムと呼ぶ。
データストリームプログラムは、静的なデータベースで用いられるSQL言語と近似したクエリ言語で記述される。データストリームプログラムの言語には、例えばContinuous Query Language (CQL) (例えば、非特許文献1参照) とComplex Event Processing Language(例えば、非特許文献2参照)がある。本明細書では、Complex Event Processing Languageを用いて説明する。
図2(A)においては、2つのクエリQ1及びQ2が中間ストリーム240で連結されている。そして、入力ストリーム210を、クエリQ1及びクエリQ2が処理し、クエリQ2が出力ストリーム270を出力する。そして、クエリQ1は、分散キーとして、A及びBを持ち、クエリQ2は、分散キーとしてBとCを持っている。
なお、分散キーとは、並列分散のために入力ストリームを分割(partitioning)する際に、データの宛先ノードの判定に使用されるハッシュ関数に適用され得る分散キーに対応する。例えば、クエリを構成する集計結果グルーピングオペレータ(group by)に利用されるキーは分散キーとして認識することがある。例えば、クエリQ1のプログラムに"group by A,B"という句が記載された場合、AとBというイベントのプロパティがクエリQ1の分散キーとして認識される。そのように複数のプロパティが分散キーとして認識された場合、その集合を分散キーセットと呼ぶ。また、クエリを構成する結合(join)オペレータにおいて結合用に利用されるキーも分散キーとして認識されることもある。
また、本明細書では、実施形態において説明するように、クエリの入力イベントのプロパティと出力イベントのプロパティとの関係を示す関数も、分散キーとして扱っている点に留意すべきである。なお、プロパティとは、イベントに属するデータの属性を意味する。イベントは、1つ以上のプロパティを持つ。また、プロパティは、分散キーとして用いられる場合がある。
図2(B)は、図2(A)で示されたデータストリームプログラムを、入力ストリーム210を処理するために、並列分散して実行する一例を示している。
入力ストリーム210は、データベースで扱われる表に準じた表記を用いて表現している。入力ストリーム210は、複数のプロパティ({A,B,C}を持っている。また、具体的な複数のイベント(212,214,216,218)が時系列的に並んで、入力ストリーム210を形成している。クエリQ1は、ノード232及びノード234に配備される。ここで、ノードとは、具体的には、例えば物理マシン又は仮想マシンであってもよい。クエリQ1を2つのノード(232,234)によって分散処理する。ポイント220において、入力ストリーム210を、ノード232及びノード234に振り分けるために、適切なハッシュ関数に分散キーセット{A,B}を適用し、ストリーム221とストリーム222に分ける。ストリーム221によって、イベント212aとイベント214aがノード232に順次到着し、処理される。そして、ストリーム222によって、イベント216aとイベント218aがノード234に順次到着し、処理される。なお、ハッシュ関数としては、静的なデータベースで用いられている技術が利用できる。具体的には、ハッシュテーブル等を用いてもよい。この場合には、分散キーセット{A,B}を用いてデータストリーム210を2つのストリーム(221,222)に分離する様々なハッシュ関数が適用可能である。
図2(B)において、さらに、クエリQ2が、ノード252及びノード254に配備される。Q2は分散キーセット{B,C}を持っており、Q1とは異なっている。このため、例えばノード252におけるQ2が処理すべきイベントは、ノード232からのイベント212bと、ノード234からのイベント216bとなる。同様に、ノード254におけるQ2が処理すべきイベントは、ノード232からのイベント214bと、ノード234からのイベント218bとなる。
このため、ノード232においては、Q2の分散キーセット{B,C}と、適切なハッシュ関数に従って、出力をストリーム242とストリーム244に振り分けて、出力のうちの適切なイベントをそれぞれノード252とノード254に送る必要がある。同様に、ノード234においては、Q2の分散キーセット{B,C}と、適切なハッシュ関数に従って、出力をストリーム246とストリーム248に振り分けて、出力のうちの適切なイベントをそれぞれノード252とノード254に送る必要がある。
このように、図2(B)に示した例では、4つのノード(232,234,252,254)を設けて、クエリQ1及びQ2を並列実行したにもかかわらず、4つのノード(232,234,252,254)の間で、4つのストリーム(242,244,246,248)による相互通信が発生してしまうことが分かる。この通信は、ノード間のネットワークリソースを消費することとなる。
複数のクエリを含むクエリプランを受け入れ、複数のクエリを分類し、複数のクエリのそれぞれに対して最適化されたパーティションセットを計算し、複数のクエリの各々の最適化されたパーティションセットを、複数のクエリの少なくとも1つのサブセットに調和させ、複数のクエリの各々のクエリによって用いられるよう、少なくとも1つの調和された最適化されたパーティションセットを選択し、選択された少なくとも1つの調和された最適化されたパーティションセットを、コンピュータ媒体に格納する発明が存在する(例えば、特許文献1参照)。
また、ストリームデータ処理システムにおいて、ストリームデータ処理システムが備える固有のウィンドウオペレータを採用している場合、ウィンドウオペレータの処理を考慮して結果の原因分析を行なう技術が存在する(例えば、特許文献2参照)。
また、複合イベント処理向けのクエリをイベントログから自動的に生成する技術がある。すなわち、イベントログに頻出する属性値の組み合わせのパターンを求め、当該パターンに基づいて頻出イベントを自動的に生成する。この後、ラベルを付した頻出イベントをイベントの発生順に配列した頻出イベント列を生成する。この頻出イベント列に基づいて、インシデントの発生検出に必要なクエリを生成する技術がある(例えば、特許文献3参照)。
Arasu, Arvind, Shivnath Babu, and Jennifer Widom. "CQL: A language for continuous queries over streams and relations." Database Programming Languages. Springer Berlin Heidelberg, 2004. http://link.springer.com/chapter/10.1007/978-3-540-24607-7_1
Interstage Big Data Complex Event Processing Server V1.0.0 Developer's Reference. http://software.fujitsu.com/jp/manual/manualfiles/m120021/j2ul1668/01enz200/j2ul-1668-01enz0-00.pdf
上述のノード間の相互通信によるネットワークのリソースの消費量は、並列分散のためのノードを増やすほど増大することとなり、並列分散処理を適切に実現する上での課題となっている。
大量のデータを含むデータストリームを扱うためには、処理対象に対する適切なプランを見いだすことが必要であるが、従来のように、クエリ等の性質に基づくプランの抽出では、抽出できるプラン(分散グループの適用)は限られている。
そこで、一側面では、本発明は、並列分散されたノード間のデータ通信量の削減を図ることを目的とする。
一実施形態によれば、複数のイベントを有するデータストリームを処理する複数のクエリの部分集合を含む分散グループを、複数のノードに配備するプログラムであって、前記イベントは1つ以上のプロパティを含み、前記データストリーム、及び/又は、前記複数のクエリの各々の定義から、前記複数のクエリの各々の入力イベント及び出力イベントに含まれる複数のプロパティの間の関係を抽出し、クエリの定義に記された分散キーと、前記複数のプロパティの間の関係と、前記関係の確率とに基づいて、前記分散グループに含まれる前記複数のクエリの部分集合に共通に利用し得る共通分散キーを特定し、前記特定された共通分散キーに基づいて、並列分散されたノードの各々に、前記分散グループに所属するべき前記複数のクエリの部分集合を配備する、処理をコンピュータに実行させるデータストリーム処理の並列化プログラムが提供される。
実施形態によれば、データストリーム処理において並列分散されたノード間のデータ通信量の削減を図ることができる。
以下に、図面を用いて本発明の実施形態を詳細に説明する。なお、以下の実施形態は、発明を理解するためのものであり、本発明の範囲を限定するためのものではない点に留意すべきである。また、以下の複数の実施形態は、相互に排他的なものではない。したがって、矛盾が生じない限り、実施形態の各要素を組み合わせることも意図されていることに留意すべきである。また、請求項に記載された方法やプログラムに係る発明は、矛盾のない限り処理の順番を入れ替えてもよく、あるいは、複数の処理を同時に実施してもよい。そして、これらの実施形態も、請求項に記載された発明の技術的範囲に包含されることは言うまでもない。また、同様の構成要素に対しては、複数の図において同様の参照符号を付す場合がある点に留意すべきである。
図3は、分散キーを用いてクエリを分散グループに統合する例の概略を示している。図3(A)は、図2と同様のクエリQ1及びクエリQ2を含むデータストリームプログラムのクエリグラフを示している。図2と異なる点は、クエリQ1及びクエリQ2を統合した分散グループ310が導入されている点である。分散グループ310は、クエリQ1及びクエリQ2の共通の分散キーセットである分散キーセット{B}を持つ。一連のクエリのうちで、共通の分散キーセットを持つクエリが、同一の分散グループに所属し、分散グループは、この共通の分散キーセット(共通分散キーセット)を持っている。
図2では、各ノードに1つのクエリしか考慮していなかった。データストリームの処理において、各クエリ(すなわちクエリQ1及びクエリQ2)で分散キーセットが完全に一致しない場合では、各クエリが配備されているノード間で錯綜した通信が発生していた。
図3(B)は、図2(B)で発生していた上記の錯綜したノード間(クエリ間)の通信を減少させるための方策の一例を示している。図3(B)のように、4つのノード(312,314,316,318)のそれぞれに、分散グループ310に所属するクエリQ1及びクエリQ2が配備されている。なお、分散グループとは、同一のノードに配備できる1つ以上のクエリをひとまとめにした、クエリの部分集合を意味する。
そして、データストリーム210は、適切なハッシュ関数に分散キーセット{B}を適用して、ポイント320において振り分けられる。すなわち、イベント(212c,214c、216c、218c)は、それぞれストリーム(321,322,323,324)を介してノード(312,314,316,318)に与えられる。
この場合、クエリQ1及びクエリQ2の共通の分散キーセットである分散キーセット{B}をハッシュ関数に適用してストリーム210が振り分けられ、分散処理される。このため、例えばノード312内では、ノード内でクエリQ1の出力をクエリQ2に与えればよい。他のノード)(314,316,318)についても同様である。したがって、この場合には、図2(B)に見られたような、ノード間での錯綜した通信(242,244,246、248)は発生しない。そして、各ノードの出力は、最終的に結合され、出力ストリーム270が得られる。
更に図3(A)を参照する。このように、連続したクエリで、共通の分散キーセットが存在する場合には、クエリグラフにおいてこれらを1つの分散グループとしてまとめる。そして、同一の分散グループに含まれる1つ以上のクエリを、1つのノードに配備する。これによって、ノードが並列分散されても、錯綜したノード間の通信の発生は防止される。
なお、分散グループやクエリを並列分散させるノードの数は、クエリの処理の重さ、ノードとして採用できる物理マシンの数、ストリーム量などに依存して決定すればよい。決定された分散処理のノードの数によって、分散グループの分散キーセットを適用すべき適切なハッシュ関数を定義すればよい。また、ハッシュ関数については、データストリームのイベントが、なるべく均等になるように、適切なハッシュ関数を用いてもよい。
図3に示した例は、クエリQ1及びクエリQ2のそれぞれのプログラム内に、分散キーA、B、及びB、Cが明示的に記述されている場合の例を示したものである。
図4は、関数が分散キーとして用いられている例を示している。図4では、クエリQ1及びクエリQ2が、例えば以下のように定義されている場合における例を示している。
Q1:
insert into E2
select A, COUNT(*) as B
from E1
group by A/2;
Q2:
insert into E3
select A, B, COUNT(*) as C
from E2
group by A/3;
ここで、A/2は、Aを2で割って、小数点以下を切り捨てる関数を意味する。A/3は、Aを3で割って、少数点以下を切り捨てる関数を意味する。
Q1:
insert into E2
select A, COUNT(*) as B
from E1
group by A/2;
Q2:
insert into E3
select A, B, COUNT(*) as C
from E2
group by A/3;
ここで、A/2は、Aを2で割って、小数点以下を切り捨てる関数を意味する。A/3は、Aを3で割って、少数点以下を切り捨てる関数を意味する。
図4(A)において、ノード401及びノード402にQ1を配備し、分散キーとして、ポイント410でハッシング(A/2)%2を適用している。そして、ノード401及びノード402で、更にハッシング(A/3)%2を適用している。ここで、K%Nは、N個のハッシュ値を出力するハッシュ関数に分散キーセットKを適用することを意味する。上述の場合には、分散キーセットとして、関数F(A)=A/2及び関数G(A)=A/3が用いられている。
関数F(A)=A/2はステップ関数という数学的な関数の種類に属する。Aの値が2つ増えるたびに、F(A)の値が1つ増えるが、それまでには固定である。関数G(A)=A/3もステップ関数に属した関数であり、Aの値が3つ増えるたびにG(A)が1つ増える。このようにAの値に対して一定の間隔で増え続けるステップ関数には周期性があるとみなして、関数の値が増えるまでのAの間隔を周期長と呼ぶ。この例の場合、関数F(A)の周期長は2である。また、関数G(A)の周期長は3である。
図4(C)は、ステップ関数F(A)とAとの関係を示している。そして、F(A)の周期長βが2であることがわかる。
2つの連続したクエリの分散キーセットとして2つの異なる関数が用いられた場合、2つの関数の値の間に、1対1な関係が存在した場合、2つの関数のうち任意な関数を用いて、2つのクエリを分散グループとしてまとめることができる。例えば2つの関数が連続的な一次関数であった場合はその例に当たる。ただし、2つの関数が上記のような周期性のあるステップ関数であった場合、単純に2つのクエリを分散グループとしてまとめることができない。
図4(A)の場合には、入力イベント列E1をポイント410で、ハッシング関数(A/2)%2で振り分け、ノード401及びノード402で、分散してクエリQ1を実行している。この時点では、クエリQ1が2つのノード401及びノード402で、分散して独立に実行されているため、効率よくクエリQ1の処理が行える。しかしながら、ノード401及びノード402で、更にハッシング(A/3)%2を適用しているため、錯綜した通信421及び通信422が発生していることが分かる。
図4(B)では、この錯綜した通信を無くすために、ノード431及びノード432に、それぞれQ1及びQ2を配備させ、分散キーセットとして、ポイント430において、(A/6)%2で、データストリームE1をハッシングしている。このようにすることにより、ノード431とノード432との間での錯綜した通信を無くすことができる。
以上の例は、2つの連続したクエリであるクエリQ1とクエリQ2に、それぞれ、入出力のプロパティ間に関する関数A/2と関数A/3が用いられている例である。そして、関数A/2の周期長は2であり、関数A/3の周期長は3である。この場合に、周期長2と周期長3の最小公倍数である周期長6の関数A/6が、Q1とQ2の共通分散キーとして用いられている。そして、Q1とQ2が1つの分散グループに割り当てられている。
そして、この分散グループをノード431及びノード432に配備する。入力イベントE1を、ポイント430で、ハッシュ関数(A/6)%2でハッシュすることにより、適切に、入力イベントE1がハッシュされ、ノード431及びノード432との間での錯綜した通信が発生しないようにクエリQ1及びQ2が配備された。
以上のことは、分散キーとして周期性のあるステップ関数が使われていても、共通分散キーを新たに生成することができることを意味している。
なお、上述の説明では、関数とは、クエリの入力イベントのプロパティとクエリの出力イベントのプロパティとの関係として定義した。しかしながら、クエリの定義の仕方によっては、関数がクエリ内に内在している場合もある。この点については、図26を用いて後述する。
図5は、図4(B)の例に用いた関数F(A)=A/2、G(A)=A/3、及びこの2つの関数の各々の周期長の最小公倍数の周期長を持つH(A)=A/6の取り得る値を、Aの値と対応付けて示した図である。H(A)の周期521は、F(A)の周期501、502、503を含み、かつ、G(A)の周期511、512を含んでいる。
したがって、F(A)の周期とG(A)の周期の切れ目が、関数H(A)の周期の切れ目と合致する。この関数H(A)を用いて、入力イベント列E1をハッシングし(例えばH(A)%2)、クエリQ1とクエリQ2とを、同じ分散グループに所属させれば、この分散グループを複数のノードに並列分散しても、ノード間での錯綜した通信は発生しないのである。
図6は、関数を共通分散キーとして用いてもノード間通信が発生する例を示している。図6(A)は、クエリQ1における分散キーとしての関数がF(A)=A/2であり、Q2における分散キーとしての関数がG(A)=(A+1)/3である場合であって、分散グループQ1及びQ2の共通分散キーとして関数H(A)=A/6が用いられた例を示している。
図6(A)に示すように、A=5の場合に、関数F(A)の周期と関数G(A)の周期とにズレが生じている。このため、ノード601からノード602に、通信610が発生している。ポイント630においては、H(A)=A/6を適用して入力イベント列E1(データストリーム)をハッシングしている。
この場合のノード間通信は、データストリームに含まれるイベントがランダムであれば、平均1/6の割合で発生する。このノード間通信の発生割合は、単純にQ1の分散キーとして関数F(A)=A/2を用い、Q2の分散キーとしてG(A)=A/3を用いた場合のノード間通信の割合(2/6)よりも小さい。
また、図6(C)は、クエリQ1における分散キーとしての関数がF(A)=A/2であり、Q2における分散キーとしての関数がG(A)=(A+1)/4である場合であって、分散グループQ1及びQ2の共通分散キーとして関数H(A)=A/4が用いられた例を示している。ポイント640においては、H(A)=A/4を適用して入力イベント列E1をハッシングしている。
図6(C)の場合には、図6(D)に示すように、例えば、A=3の場合に、ノード603からノード604にノード間通信620が発生している。そして、ノード間通信の割合は、平均1/4である。このノード間通信の発生割合は、単純にQ1の分散キーとして関数F(A)=A/2を用い、Q2の分散キーとしてG(A)=A/4を用いた場合のノード間通信の割合(2/4)よりも小さい。
なお、図6(A)の場合には、最小公倍数の周期長を持つ、他の関数を共通分散キーとして用いることにより、ノード間通信を無くすことができる。この点については、図20を用いて後述する。
以上の例は、Q1とQ2における分散キーとしての関数のそれぞれの周期長の最小公倍数の周期長を持つ関数を、分散グループQ1及びQ2に共通分散キーとして適用することによって、ノード間通信の割合を減少させることができる例である。
したがって、ノード間通信が、仮に発生するとしても、その転送コストを減少させることができる。したがって、所定のコスト以下である場合には、その分散グループを採用することが望ましい。例えば、所定のコストは、第2の閾値の一例である。
なお、図6(C)及び図6(D)の例の場合は、関数F(A)と関数G(A)に必ず、ズレが生じているため、共通分散キーとしてどのような新たな関数を用いても、Q1とQ2とで構成される分散グループのノード間通信を無くすことはできない。
上述の実施形態では、例えば2つのクエリのそれぞれに分散キーとして用いることができる関数が存在した例である。以下の実施形態は、上述のように2つの関数の周期長の最小公倍数を周期に持つ関数を単純に見いだすことに困難を伴う場合の例を示す。
図7は2つのクエリに共通の分散キーが単純には見出せない場合の例を示している。
クエリQ1を定義するプログラム701に示すように、Q1は、ウィンドウや集約関数による内部状態がないため、自由分散可能である。すなわち、入力イベントの全てのプロパティが分散キーとなり得る。Q1の入力イベントは、プロパティAを持つ。したがって、Q1の分散キーセットは、{A}である。
クエリQ2定義するプログラム702は、AVG(A)という集約関数が規定されているため、内部状態を持つ。また、GROUP BY Bがあるため、Q2の分散キーセットは{B}である。
以上のように、Q1とQ2には、外見上共通の分散キーが見いだせない。したがって、このままでは、Q1とQ2を同一の分散グループとし、グルーピングして複数のノードに並列分散することができない。
しかしながら、クエリQ1のプログラム中には、"A/2 as B"が存在する。したがって、B=A/2の関係が存在することになる。
図8は、図7と同じクエリQ1及びクエリQ2を用いている。図8を用いて、プロパティ間の関係がクエリプログラムに記述された場合に、その関係を利用して2つのクエリを同じ分散グループとしてまとめる方法を示す。
まず、図8(A)において、クエリQ1の定義から、2つのクエリ間の入力イベント列E1(801)のプロパティであるAと、出力イベントE2(802)のプロパティであるBとの間には、B=F(A)=A/2という関係が成立している。
図8(B)に示すように、イベント列E1(811)及びイベント列E2(812)は、図8(A)と同じである。この場合、クエリQ1とクエリQ2は、同じ分散キーBを持つことになる。言葉を換えて説明すれば、B=A/2という関係があるため、クエリQ1とクエリQ2は、同じ分散キーとしての関数A/2を持つと言うこともできる。
図8(C)は、クエリQ1とクエリQ2を分散グループとして、ノード831とノード832に並列分散させた例を示している。この場合に利用される共通分散キーは、B(すなわちF(A)=A/2)である。したがって、イベント列E1(821)を(A/2)%2(すなわち、B%2)でハッシングして、2つのストリームすなわちストリーム822と、ストリーム823とに振り分ければよい。
このように、Q1とQ2には、外見上共通の分散キーが見いだせない場合であっても、Q1とQ2に係る入力イベントのプロパティ及び出力イベントのプロパティのうち、プロパティの関係を分析することで、共通の分散キーを見出すことができる。
図9は、クエリの入力イベント列E1のプロパティ(すなわち、プロパティAとプロパティB)の間に動的な関係を見出す例を示している。
クエリのプログラムを解析しても、イベントに含まれるプロパティ間の関係が見いだせない場合がある。しかしながら、入力イベント列に含まれるプロパティ間に、完全ではないが、ある程度の関係が内在している場合がある。或いは、長期間にわたっては、特段の関係が存在しない場合であっても、クエリのウィンドウの範囲内であれば、ある程度の関係が存在する場合がある。このような場合、従来では、クエリのウィンドウの範囲を超えた部分では、定常的な関係が存在しないことにより、クエリを分散グループにまとめるためのプランの抽出が困難であった。
図9におけるクエリQ1は、プログラム911に従って動作する。また、クエリQ2は、プログラム912によって動作する。まず、クエリQ1のプログラム801には、内部状態が存在する。すなわち、「FROM E1.win:time(1 min)」は、タイムウィンドウと呼ばれるシンタクスである。このシンタクスは、入力イベント列E1を1分間蓄積し、この蓄積されたイベント列から、所定の処理を施すことを意味する。なお、その他のシンタクスについては、データベースを処理するクエリのシンタクスと同様であるため、説明は省略する。そして、「GROUP BY A」があることから、クエリQ1の分散キーとしては、「A」が抽出される。
クエリQ1は、タイムウィンドウ901を持ち、クエリQ2は、タイムウィンドウ902を持つ。
ここでは、入力イベント列E1をクエリQ1が蓄積したタイムウィンドウ901の複数のイベントに着目する。クエリQ1の入力イベントに含まれるプロパティ(この場合は、A及びB)は、クエリQ1が受動的に受信するデータであるため、クエリQ1が、プロパティAとBとの関係を定義することはできない。しかしながら、タイムウィンドウ901に記憶された複数のイベントのプロパティAとBとの間には、ある確率で、関係を持つ場合がある。あるいは、長期間にわたっては特段の関係が存在しない場合であっても、クエリのタイムウィンドウの範囲内のそれぞれにおいて、それぞれの関係がある確率で存在する場合がある。
タイムウィンドウ901では、プロパティAとBとの間にB=A/2という関係が存在している例を示している。この関係B=A/2は、クエリQ1のプログラム801からは抽出することができない関係である。なお、関数A/2は、Aを2で割った商のあまりを切り捨てる関数を意味する。この関係B=A/2は、1つのBの値に対して複数のAが対応する関係である。この関係を1対N[Nは整数]の関係と表記することとする。
タイムウィンドウ901に蓄積されたイベントは、1対Nの関係を100%満たしている。なお、1対Nの関係が100%を満たさない場合も現実には存在する。そのような場合の例は、図13及び図14において触れる。クエリQ1のプログラム801からは、クエリQ1の分散キーとして「B」が抽出される。
なお、一般に、プロパティXとプロパティYとが、1対Nの関係を有する場合には、1に対応するプロパティ(この例の場合には、X)が、分散キーとしての役割を果たし得る。
図9において、クエリQ2のプログラム912は、同様にタイムウィンドウ902が定義されており、内部状態が存在する。そして、「GROUP BY B」のシンタクスが存在する。このため、クエリQ2の分散キーとして「B」が抽出される。
したがって、このままでは、クエリQ1とクエリQ2の分散キーが異なるために、共通の分散キーは存在しない。よって、クエリQ1とクエリQ2を、分散グループに所属させることはできない。
図10は、イベント列に含まれるプロパティの動的関係を考慮して複数のクエリを有する分散グループを形成する例を示している。図10では、上述したタイムウィンドウ901から得られたB=A/2という関係を利用している。図10(A)は、図9におけるクエリプログラムから得られた、クエリQ1の分散キー「A」と、クエリQ2の分散キー「B」が示されている。そして、クエリQ1とクエリQ2は、分散グループにまとめられていない状態を示している。
図10(B)は、B=A/2の関係を利用し、共通分散キーとして、「B」(すなわち、A/2)を用いて、クエリQ1及びクエリQ2を分散グループに所属させ、この分散グループを、並列分散されたノード1010とノード1020に配備した例を示している。
そして、ポイント1001において、ハッシュ関数B%2が、入力イベント列をハッシュし、ノード1010及びノード1020に振り分けている。ノード1010には、ハッシュされたイベント列1002が与えられる。ノード1020には、ハッシュされたイベント列1003が与えられる。
なお、この場合、イベントに含まれるプロパティ間の動的な関係を利用し、共通分散キーでクエリQ1及びクエリQ2を分散グループに所属させている。そして、その関係が100%成り立たない場合もあり得る。したがって、このような例の場合には、並列分散されたノード1010とノード1020との相互間で通信が発生する場合が、十分想定される。しかしながら、得られた関係が、所定のレベルを超える確率を有する場合には、この相互間の通信は、許容されるレベルに押さえることが可能である。この所定のレベルは、第1の閾値の一例である。
なお、図9及び図10の例では、ある2つのプロパティ間の関係として、具体的な関係すなわちB=A/2が見出せた例である。しかしながら、実際の入力イベントにおいては、プロパティ間に1対Nの関係は見出せるが、具体的な関係を定義する関数を見出せない場合も十分想定される。このような場合であっても、例えばクエリQ1でプロパティBとAとの間に1対N(又は1対1)の関係が見出せさえすれば、プロパティBは、クエリQ1においてイベント列を集約できる能力があることを意味している。したがって、クエリQ1に続くクエリQ2において、分散キーが同じBであるならば、クエリQ1とクエリQ2は、共通分散キーとしてBを持つ分散グループが形成できることを示唆する。したがって、プロパティBとAとに1対Nの関係が所定の確率で見出せれば、その間の関係が具体的に特定できなくてもよいということができる。
また、図9及び図10においては、クエリにタイムウィンドウのシンタクスが存在する例を示した。このシンタクスが存在すれば、所定の時間のイベント列がクエリに保存される。
このようなタイムウィンドウなどの複数のイベントを記憶して処理するシンタクスを一般にスライディングウィンドウと称する。スライディングウィンドウのシンタクスがクエリに存在する場合には、スライディングウィンドウによって蓄積された複数のイベントに含まれる複数のプロパティの間の関係を求めることができる。
なお、スライディングウィンドウを持たないクエリの場合には、例えば、そのクエリに入力されるデータストリームのイベントを適切な間隔でサンプリングし、蓄積してもよい。サンプリング間隔は、図13(B)において更に説明する。或いは、複数のプロパティ間の関係を逐次計算し、計算結果を記憶し、新たなイベントが入力される度に、この計算結果をインクリメンタルに修正してゆく処理を行ってもよい。
図11は、一実施形態の機能ブロック図を示している。データストリーム処理の並列化システム1100は、プロパティ関係抽出部1110と、共通分散キー特定部1150と、テーブル記憶部1160と、クエリ配備部1170とを有する。データストリーム処理の並列化システム1100は、複数のクエリ定義を含むプログラムを入力とし、複数のノードにクエリを配備する能力を有する。なお、データストリーム処理の並列化システム1100は、データストリームのイベントに含まれるプロパティの関係を用いることができる。
プロパティ関係抽出部1110は、更に動的プロパティ関係抽出部1120と、静的プロパティ関係抽出部1130とを有する。
動的プロパティ関係抽出部1120は、データストリームの複数のイベントを用いて、動的に複数のプロパティの間の関係を抽出することができる。ここで、動的とは、動的なデータであるデータストリームの複数のイベントを用いていることを意味する。データストリームから得られたプロパティ間の関係を動的関係と称す。この動的関係は、データストリームに依存して変化し得る。
静的プロパティ関係抽出部1130は、複数のクエリ定義を含むプログラムから、静的に、複数のプロパティの間の関係を抽出することができる。ここで、静的とは、静的なデータである、複数のクエリ定義を含むプログラムを用いていることを意味する。このプログラムから得られたプロパティ間の関係を静的関係と称す。この静的関係は、プログラムが変更されない限り変化しない。
動的プロパティ関係抽出部1120は、更に、入力イベント保存部1122と、関係確率算出部1124と、関係特定部1126とを有する。
入力イベント保存部1122は、あるクエリがスライディングウィンドウを持つ場合には、スライディングウィンドウのシンタクスで定義された量の入力イベントが、そのクエリに保存される。一方、別のクエリがスライディングウィンドウを持たないクエリである場合には、そのクエリの入力イベント列をトラップし、メモリに蓄積してもよい。なお、クエリへの入力イベントは、膨大な数になるため、そのクエリに関する入力イベントの全てをメモリに蓄積することは非現実的である。したがって、そのクエリの入力イベント列をサンプリングして、ファーストインファーストアウトで、所定個数をメモリに蓄積してもよい。
或いは、そのクエリの入力イベントの関係を計算し、計算結果を蓄積し、新たなイベントが入力された時点で、計算結果を更新してインクリメンタルに上書きして蓄積するようにしてもよい。
関係確率算出部1124は、各クエリに関与するイベントに含まれるプロパティ間の関係とその関係の確率を求める。
なお、各クエリの入力イベント列に含まれるプロパティ間の関係を求めることは、その組合せが膨大になることから、現実的でない場合がある。したがって、過去の全てのイベントではなく、スライディングウィンドウにあるイベント列のみを対象としてもよい。また、入力ストリームの各プロパティから、入力ストリームに直接繋がっているクエリの各分散キーに向かったN対1の関係のみを対象としてもよい。
また、あるクエリの入力ストリームをサンプリングする場合、そのクエリの出力先に接続されているクエリの分散キーとなっているプロパティと他のプロパティとの関係の抽出に限定してもよい。
また、サンプリングによってある程度高い確率(例えば、50%)以上のプロパティの組合せが見つかった場合には、その組合せに関して、より短いサンプリング間隔で、イベントを取得してもよい。そして、その関係の確率が閾値(例えば80%)以上のプロパティの組合せが見つかった場合は、関係があると判断してもよい。このように複数段階(2つ以上)に分けられた効率的なサンプリングを採用してもよい。
関係特定部1126は、関係確率算出部1124において見つかった、確率の高い関係に係るプロパティを特定する。特定されたプロパティの組合せは、テーブル記憶部1160に存在するテーブルに保存されてもよい。なお、関係を発見する例、及び関係の確率の計算例については、図14を用いて後述する。この閾値は、第1の閾値の一例である。
静的プロパティ関係抽出部1130は、関数特定部1134を有する。静的プロパティ関係抽出部1130は、複数のクエリを定義するプログラムから、プロパティ間の関係を関数として抽出する。
共通分散キー特定部1150は、分散キー抽出部1152と、共通分散キー生成部154とを有する。
分散キー抽出部1152は、複数のクエリを定義するプログラムから、静的に、分散キーを抽出する。
共通分散キー生成部1154は、第3の関数生成部1155と、関数精度算出部1156とを有する。
第3の関数生成部1155は、上述の関数H(A)が複数存在する場合、クエリ間の通信量の平均値の予測値が一番小さい関数H(A)を生成(選択)する。なお、この第3の関数生成部1155は、静的プロパティ関係抽出部1130の中に存在してもよい。
関数精度算出部1156は、クエリを定義するプログラムから見出された関数の特徴を判断する。関数精度算出部1156は、既に図6において説明したように、2つのクエリに存在する分散キーの役割を果たす関数F(A)の周期長とG(A)の周期長との最小公倍数の周期長を有する関数H(A)について、クエリQ1とクエリQ2を分散グループに所属させて、複数のノードに並列分散させた場合に、ノード内での通信量に対するノード間での通信量の比(或いはノードに入力される通信量に対する他のノードへの通信量の比)の平均値を予測する。なお、この関数精度算出部1156は、静的プロパティ関係抽出部1130の中に存在してもよい。
共通分散キー生成部1154は、分散キー抽出部1152と、プロパティ関係抽出部1110によって作成された関係及び関数を用いて、分散グループに所属する複数のクエリの共通分散キーを生成(選択)する。また、分散グループに属するべきクエリを特定する。
クエリ配備部1170は、共通分散キー特定部1150によって生成された共通分散キーのプランに基づいて、並列分散された複数のクエリに、分散グループに所属するクエリを配備する。
以上のようにして、データストリーム処理の並列化システム1100は、データストリームを適切に処理する複数のノードに適切なクエリを配備することができる。
なお、動的プロパティ関係抽出部1120によって、プロパティの動的関係に変化が発見された場合には、複数のノードの組合せの構成、及び複数のノードの各々に対するクエリの配備計画(プラン)を変更してもよい。このようにすることによって、時間の経過によって変化し得る、プロパティ間の関係の変動にも適切に対応できる。
図12は、テーブル記憶部1160に記憶され得る主要なテーブルの例を示した図である。
分散キーテーブル1210は、各クエリを定義するプログラムから直接導かれる分散キーセットを記憶するテーブルである。なお、本明細書では、分散キーの集合を分散キーセットと称す。なお、説明の簡潔性から、分散キーセットを単に分散キーと呼ぶ場合がある点に留意すべきである。
また、本明細書では、既に述べたように、イベントのプロパティ自体がクエリの分散キーとして抽出される場合に加えて、イベントのプロパティ間に見出された動的な関係、及びクエリプログラムから抽出された関数から分散キーが求められる場合もある。したがって、例えば、後述する各表において、分散キー又は分散キーセットとして明示的に記載された分散キー以外に、関数(式)、多重度、確率などを用いて、分散キーとして機能し得るものが、関係特定部1126、関数特定部1134、共通分散キー生成部1154等で、別途抽出され得る点に留意すべきである。
分散キーテーブル1210は、クエリ1211、入力イベント1212、分散キーセット1213のエントリを有する。
プロパティ関係テーブル1220は、2つのプロパティの関係を記憶するテーブルである。イベント2(1221)には、原則として、クエリの出力イベントが記入される。例外として、クエリの入力イベントが記入される場合がある。この点は、図13(C)及び図16において、例を示す。
イベント2のプロパティ1222には、イベント2(1221)の欄に記載されたイベントのプロパティが記入される。
イベント1(1223)には、クエリの入力イベントが記入される。
イベント1のプロパティセット1224には、イベント1のプロパティセットが記入される。なお、イベント1のプロパティセットには、複数のプロパティが記入される場合がある。たとえば、以下のようなクエリは、イベント1のプロパティセット1224に{A,B}が記入される。
insert into E2
select A+B as C
from E1
関数(式)1225には、イベント2のプロパティ1222とイベント1のプロパティセット1224との間の関係が記入される。その関係が、関数又は式として記述できる場合には、明示的に関数又は式が記入される。
insert into E2
select A+B as C
from E1
関数(式)1225には、イベント2のプロパティ1222とイベント1のプロパティセット1224との間の関係が記入される。その関係が、関数又は式として記述できる場合には、明示的に関数又は式が記入される。
多重度1226には、イベント2のプロパティ1222とイベント1のプロパティセット1224との間の関係の多重度が記入される。多重度には、1対N又は1対1が記入される。
確率1227には、多重度の確率が記入される。この確率は、関係確率算出部1124又は関数精度算出部1156において算出された確率が記入される。
分散グループ一覧1230には、分散グループに所属するクエリが記入される。分散グループ1231には、分散グループを特定するためのグループIDが記入される。所属クエリ1232には、分散グループに所属するクエリが記入される。
分散グループごとの分散キー一覧1240には、分散グループに適用される分散キーが記入される。分散グループ1241には、分散グループIDが記入される。
入力イベント1242には、分散グループの入力イベントが記入される。分散キー1243には、分散グループに適用される分散キーが記入される。なお、この分散キー1243は、複数の分散キー(分散キーセット)を含む場合がある。
関数1244には、プロパティ関係テーブルの関数(式)1225と同じものが記入される。
なお、関数1244が記入されている場合には、この関数は、分散キーの役割を果たす場合がある。
図13は、一実施形態の動作の概要を示すフローチャートである。図13(A)は、一実施形態の動作を示す。
ステップ1302で、プロパティ関係抽出部1110は、イベントに含まれるプロパティの関係を抽出する。このプロパティの関係は、動的関係と静的関係が含まれる。
ステップ1304で、共通分散キー特定部1150は、プロパティの関係を用いて、分散キーを抽出し、更に、分散グループに所属する1つ以上のクエリに適用される共通分散キーを特定する。
ステップ1306で、クエリ配備部1170は、分散グループに所属する1つ以上のクエリを並列分散されたノードに配備する。
図15(B)は、イベント列に含まれるプロパティ間の関係を抽出する動作の概要を示すフローチャートである。この処理は、例えばクエリQ1への入力イベントの到着により割り込みが発生し、開始されてもよい。
ステップ1322で、入力イベント保存部1122は、例えば、クエリQ1の入力イベントのプロパティAとBとを取得する。スライディングウィンドウを持つクエリの場合には、スライディングウィンドウによってそのクエリに蓄積された複数のイベントを処理対象としてもよい。スライディングウィンドウを持たないクエリの場合には、所定のサンプリングレートで、入力イベントをサンプリングし、適切なメモリ(不図示)にサンプリングされた所定数の入力イベントを保存してもよい。
また、サンプリングレートは、定常時は、低い値を設定しておいてもよい。そして、後述するステップ1326で、AとBとのN対1の関係が閾値α1よりも高い確率で発見された場合には、サンプリングレートを低い値から高い値に変更し、閾値α1よりも大きい閾値α2を用いて、図13(B)の処理を再実行してもよい。
ステップ1324で、関係確率算出部1124は、プロパティAとBとの比較テーブルの更新を行う。この比較テーブルの利用に関しては、図14を用いて後述する。このステップにおいて、プロパティAとBとの関係がN対1又は1対1であるかが判断され、かつ、その関係の確率が計算される。
ステップ1326で、関係特定部1126は、プロパティAとBとの関係がN対1(又は1対1)の関係の確率が、所定の閾値α1を超えるか否かが判断される。関係の確率が、所定の閾値α1を超える場合には(はい)、処理が、ステップ1328に移る。関係の確率が、所定の閾値α1以下の場合には(いいえ)、処理は終了する。なお、上述のように、AとBとのN対1の関係が閾値α1よりも高い確率で発見された場合には、サンプリングレートを低い値から高い値に変更し、閾値α1よりも大きい閾値α2を用いて、図13(B)の処理を再実行してもよい。α1又はα2は、所定の第1の閾値の一例である。
プロパティ
ステップ1328で、プロパティ関係テーブルにプロパティA及びB、多重度、確率などを保存する。
ステップ1328で、プロパティ関係テーブルにプロパティA及びB、多重度、確率などを保存する。
図13(C)は、図13(B)のステップ1328における動作において作成されるプロパティ関係テーブルのエントリの一例を示している。イベント2(1361)には、入力イベントであるE1が記入されている。イベント2のプロパティ1262には、プロパティBが記入されている。イベント1(1363)にも入力イベントE1が記入されている。イベント1のプロパティセット1364には、{A}が記入されている。関数1365は、記入されていない。多重度は、イベント2のプロパティ(1362)とイベント1のプロパティセット(1364)との多重度を示しており、1対Nが記入されている。確率1367には、95%が記入されている。
図13(C)は、図9及び図10で説明した例を示している。なお、関数1365には、具体的な関数が記入されていない。この理由は、既に述べたように、プロパティBとAとの多重度が1対Nであることが95%の確率で求められているため、分散グループを作る際に、必ずしも関数を利用する必要はないからである。なお、具体的な関数が求まっている場合には、その関数を記入してもよい。また、多重度は、1対N又は1対1のいずれかであればよい。
図13(C)は、イベント2(1361)及びイベント1(1363)の両者に、入力イベントE1が記入される一例である。この理由は、クエリに入力されるイベントのプロパティの関係を求めた結果が記入されているためである。クエリの入力イベントのプロパティは、そのクエリが受動的に受け入れるプロパティである。したがって、クエリの入力イベントのプロパティは、そのクエリの制御が及ばないプロパティであるということができる。図13(C)では、このような入力イベントのプロパティの間の関係を記述することがその目的である。
図14は、プロパティ間の関係の確率を計算する例を示した図である。イベント列1410は、例えば、スライディングウィンドウによってクエリに蓄積されたイベント列である。このイベント列において、プロパティBとAとの関係が1対Nであるか否かを求める例を以下に示す。
まず、全てのBの値に対して、BとAとの値の組合せパターンが同じ個数(A値の数)を計算する。1つのBに関して、Aの数が所定の閾値以上の値を持つエントリにフラグ1を立てる。残りのエントリにフラグ0を立てる。図14の表1420は、閾値を2とした例である。そして、(フラグ1のエントリのA値の数の合計)/(A値の総合計)=Xを計算する。Xは、プロパティBとAとが1対Nの関係の確率の近似値を示す。図14の例の場合には、85%の確率となる。なお、この場合に用いられる所定の閾値は、たとえば、1つのBに関して、複数のAの値が存在する場合、複数のAの値の各々の数の中央値を採用してもよい。Bに関して、1つのAの値が対応する場合には、フラグ1を立ててもよい。
或いは、全てのBの値に関連するA値の数をカウントする。1つのBに関して、Aの数が多いエントリにラグ1を立て、その他のエントリにフラグ0を立てる。そして、(フラグ1のエントリのA値の数の合計)/(A値の総合計)=Xを計算してもよい。
図15は、クエリを定義するプログラムから(静的に)プロパティの関係を抽出する例を示す。プログラムに書かれたクエリの定義から、関数を抽出する。プログラム1510は、クエリQ1の定義を示している。プログラム1520は、クエリQ2の定義を示している。
プログラム1510には、A/2 AS Bが記載されている。この記載から、たとえば、以下の関係を抽出する。
E2.B=F(E1.A)=E1.A/2
上式の意味は、イベントE2のプロパティBは、イベントE1のプロパティAの関数であり、その関数は、イベントE1に関連するものであり、具体的には関数A/2である。そして、多重度は1対Nである。このようにして抽出したプロパティの関係を、図15のプロパティ関係テーブル1530に登録する。
E2.B=F(E1.A)=E1.A/2
上式の意味は、イベントE2のプロパティBは、イベントE1のプロパティAの関数であり、その関数は、イベントE1に関連するものであり、具体的には関数A/2である。そして、多重度は1対Nである。このようにして抽出したプロパティの関係を、図15のプロパティ関係テーブル1530に登録する。
図16は、クエリから分散キーセットを(静的に)抽出する動作の例を示す図である。このフローは、特定のクエリQ1についてのフローを示しているが、その他のクエリについても同様の動作を行うことができる。
ステップ1632は、ステップ1648と対をなしており、複数のクエリの各々に対して、この2つのステップの間の処理を行うことを意味する。以下、クエリQ1を例として、分散キーとなり得るものが、関数(式)である例を取り上げて説明する。なお、クエリを定義するプログラムから分散キーを抽出する一般的な手法は、例えば、データベースにおいて並列ハッシュ結合の処理において使用されるハッシュ関数に適用され得る分散キーの抽出に準ずる。他に集約結果のグルーピングオペレータ(group by)から分散キーを抽出する方法も一般的な手法である。このため、以下の例では、本実施形態に特有の例を取り上げて説明することとする。
ステップ1634で、静的プロパティ関係抽出部1130は、クエリQ1の全ての分散キーを取得する。図16には、クエリ1を定義するプログラムの例が示されている。この例では、イベント列E1を入力とし、イベント列E2を出力することが分かる。そして、「GROUP BY A/2」のシンタクスから、関数A/2が分散キーとして抽出される。
ステップ1638で、静的プロパティ関係抽出部1130は、抽出された分散キーが、イベントのプロパティそのものであるかを判断する。クエリQ1のプログラムから抽出されるプロパティは、イベントE1のプロパティAである。これに対して、抽出された分散キーは、上述のように関数A/2である。したがって、この場合には、抽出された分散キーは、イベントのプロパティとは異なる。したがって、この例の場合には、「いいえ」となり、ステップ1642に進む。判断が「はい」であれば、ステップ1640に進む。
ステップ1642で、関数精度算出部1156は、分散キーを表す仮想的なプロパティ(例えばK)と、関数(式)、多重度、確率を、プロパティ関係テーブル1610に登録する。
ステップ1644で、仮想的プロパティKを分散キーテーブル1620に登録する。
ここで、仮想的なプロパティKをイベント2のプロパティの欄に登録する意味は、抽出された関数が、複数のプロパティとの関係を示すものであることに起因する。したがって、仮想的なプロパティKを置き、K=A/2という関係を作り、プロパティ関係テーブル1610に登録しておくことが望ましい。その理由について、図26を用いて説明する。
図26は、クエリの正規化(分散キーセットの正規化)の例を示している。図26のクエリ2612は、図16のクエリプログラムと同様の例を示している。
ステップ2602で、関数精度算出部1156は、クエリQ1の分散キーのうち、関数(式)を使用した分散キーを取得する。この場合には、関数(式)A/2が取得される。
ステップ2604で、関数精度算出部1156は、分散キーがプロパティとして存在するように、SELECT句に仮想的なプロパティKを追加し、クエリQ1を2つのクエリプログラム2614に書き換える。
クエリプログラム2614の2番目のクエリを定義するクエリプログラムにおいて、SELECT *, A/2 as Kが存在する。したがって、TempStrという仮想的なストリーム中に、プロパティKが存在する。そして、2番目のクエリから、関数(式)K=A/2が抽出される。この2番目のクエリの次に1番目のクエリが実行される。2番目のクエリは、TempStrが入力イベント列となり、出力イベントOutStrを出力する。このように、クエリを書き換えることで、仮想的なプロパティKを利用することの正当性が証明できる。また、このような仮想的なプロパティを用いることによって、プロパティ関係テーブル及び分散キーテーブルに一貫性を持たせることができる。そして、プロパティ関係テーブル及び分散キーテーブルの取り扱いが統一化できる。
図16に戻る。ステップ1640で、静的プロパティ関係抽出部1130は、分散キーのプロパティを分散キーテーブルに登録する。
以上の動作によって、クエリプログラムから、分散キー、及び分散キーを生成する際に利用可能な関数が抽出され、テーブル記憶部1160に記憶される。
図17は、共通分散キー特定部1150が、分散グループに属する複数のクエリの共通分散キーを抽出する例を示している。図17では、前提として、既に分散グループG1が作成されており、この分散グループG1に後続するクエリQ2がある場合を想定している。そして、分散グループG1にクエリQ2を所属させる動作を示している。加えて、グループG1にQ2が属することとなる場合の共通分散キーセットをRとする。なお、グループG1が未だ作成されていない場合は、グループG1に1つのクエリQ1が所属しているものとする。
ステップ1702で、共通分散キー生成部1154は、グループG1にQ2を所属させたときの分散キー(共通分散キー)を記憶するRを初期化する。したがって、Rは空集合となる。
ステップ1740は、ステップ1712との間でループ処理される。具体的には、共通分散キー生成部1154は、グループG1の入力イベントE1とQ2の入力イベントE2とに関連する全てのプロパティ間の関係について、処理を実行する。
ステップ1704は、ステップ1712と対になっており、必要な処理を複数回繰り返す。具体的には、共通分散キー生成部1154は、グループG1の入力イベントE1とQ2の入力イベントE2に関する全ての関係を網羅的に処理する。
ステップ1706で、共通分散キー生成部1154は、E2.Z=F(E.A, E1.B,..)という関係が存在するかを判断する。ここで、E2.Zとは、イベントE2におけるプロパティZを意味する。また、F(X)は、Xに所定の処理を実行する関数を意味する。この処理では、共通分散キー生成部1154は、静的プロパティ関係抽出部1130において既に作成されたプロパティ関係テーブルを参照する。この判断で、イベントE2のプロパティとイベントE1のプロパティとの間に関係が存在する場合には(はい)、ステップ1708に進む。「いいえ」の場合には、ステップ1712に進む。
ステップ1708で、関数Fの引数{E.A, E1.B,..}が、グループG1の分散キーのサブセットで、かつE2.ZがQ2の分散キーか否かが判断される。この判断が「はい」であれば、ステップ1710に進む。この判断が「いいえ」であれば、ステップ1712に進む。このステップにおいて、判断が「はい」であれば、関数FをグループG1とQ2の共通の分散キーとして利用できる可能性がある。
ステップ1710で、見つかった関係を解析し、その結果を分散キーセットRに追加する。具体的には、例えば、関数としてB=A/2の関係が見つかった場合であって、AがグループG1の分散キーのサブセットであり、かつ、BがQ2の分散キーである場合が挙げられる。この場合には、Bは、グループG1及びQ2の両者の分散キーとなり得る資格を有する。なお、この処理において、更にグループG1に分散キーとしての関数Gが存在する場合の詳細は、図18を用いて説明する。
ステップ1714で、処理結果の分散キーセットRを返す。
図18は、抽出された関数を解析する例(ステップ1710のうち、グループG1においても関数Gが分散キーとして利用されている場合の詳細処理)を示す。
ステップ1802で、抽出された関数Fが単射(すなわち1対1の関数)であるかを判断する。この判断が「はい」であればステップ1804に移る。この判断が「いいえ」の場合(すなわち、関数が1対Nの関係を示す場合)には、ステップ1806に進む。
ステップ1804で、関数Fの引数{E.A, E1.B,..}を、分散キーに追加する。そして、関数F自体は、分散キーとして登録しなくてよい。関数Fが単射であるため、関数の引数がそのまま、共通の分散キーとして利用できるからである。
ステップ1806で、グループG1の分散キーとして、関数Gを利用しているかが判断される。関数Gは、グループG1において、分散キーとして既に利用されている関数であって、関数Fと同じ引数を使用している関数を意味する。この判断が「はい」であれば、ステップ1810に移る。この判断が「いいえ」であれば、ステップ1808に移る。
ステップ1808で、分散キーセットRに関数の引数{E.A, E1.B,..}及び関数Fを追加する。この場合には、例えば、関数がB=A/2であれば、関数の引数であるAと関数A/2を分散キーセットRに追加する。
ステップ1810で、第3の関数生成部1155は、関数Fの周期長と関数Gの周期長との最小公倍数の周期長を持つ新たな関数Hを計算する。なお、関数精度算出部1156において、最小公倍数の周期長を持つ関数Hとその精度が算出されている場合には、精度の大きい関数Hを採用してもよい。なお、関数精度算出部1156は、静的プロパティ関係抽出部1130の中に存在してもよい。なお、本実施形態は、最小公倍数に限定されるものではなく、公倍数であればよい。
ステップ812で、関数Hが見つかったかが判断される。この結果が「いいえ」であれば処理を終了する。この結果が「はい」であれば、ステップ1814に移る。
ステップ1814で、分散キーセットRに、関数の引数{E.A, E1.B,..}及び関数Hを追加する。
図19は、ノード間通信を減少させるための分散キーとして利用できる関数を求める動作の例を示すフローチャートである。この処理は、ステップ1810の処理を詳細化した具体例である。なお、図19は、図18と同様に関数Fと関数Gとを用いている。
ステップ1902で、関数Fと関数Gの両者に周期性があるか否かが判断される。この判断は、具体的には、小数点以下を切り捨てる関数(例えばA/2)が挙げられる。この判断が「はい」であれば、ステップ1904に移る。この判断が「いいえ」であれば、ステップ1920に移る。
ステップ1904で、関数Fの周期長Nと、関数Gの周期長Mとを計算する。
ステップ1906で、NとMとが割り切れるか否かが判断される。割り切れる場合には(はい)、ステップ1912に移る。割り切れない場合には(いいえ)、ステップ1908に移る。
ステップ1908で、NとMとの最小公倍数S=LCM(N,M)を計算する。LCMは、最小公倍数を求める関数を意味する。
ステップ1910で、周期長=Sを切れなくカバーする関数を関数Hとしてプロパティ関係テーブルに設定する。NとMが割り切れない場合には、Nの周期の境とMの周期の境が一致する箇所が存在する。その一致する箇所と、Sの周期の境とを一致させるように関数Sを求める。この具体例については、図20を用いて説明する。
ステップS1912でNとMとの周期にズレがあるかが判断される。この判断が「はい」であればステップ1916に移る。この判断が「いいえ」であれば、ステップ1914に移る。
ステップ1914で、関数Fと関数Gのうち周期長の大きい関数を関数Hとする。そして、関数Hをプロパティ関係テーブルに設定する。
ステップ1916で、NとMとの周期にズレが許容範囲かを判断する。この判断の詳細は、図21(B)を用いて説明する。この許容範囲として、関数Hの周期長に対するズレの幅の割合が、所定の閾値以下であるかを判断してもよい。この所定の閾値は、第2の閾値の一例である。この判断が「はい」であれば、ステップ1918に移る。この判断が「いいえ」であれば、ステップ1920に移る。
ステップ1918で、関数Fと関数Gとのうち周期長の大きい関数を関数Hとする。そして、ズレの幅と関数Hの周期長に対するズレの幅の割合を確率として、プロパティ関係テーブルに設定する。
ステップ1920で、所望の関数Hは存在しないため、処理を終了する。
以上のようにして、関数Fと関数Gとから、ノード間通信を減少させるための分散キーとして利用できる関数Hを求めることができる。
図20は、2つの関数の周期長が割り切れない場合に、ノード間通信を減少させるための分散キーとして利用できる関数Hを求める例を示している。
欄2001は、共通に用いられる引数としてのプロパティAの値を示す。欄2002は、関数F(A)=A/2の取り得る値を示す。欄2003は、関数G(A)=(A+1)/3の取り得る値を示す。関数Fは、周期長2014を持つ。関数Gは、周期長2016を持つ。関数Fと関数Gの取り得る値の共通の境は、Aが1と2の間、及びAが7と8の間に存在する。
関数Fの周期長と関数Gの周期長の最小公倍数の周期長を持つ関数は、複数存在する。例えば、H(A)=(A+L)/6がある。ここで、Lは、任意の整数である。例えば、Lについて、0から+1ずつインクリメントし、関数H(A)の周期の境が関数Fと関数Gの周期の境に一致するときのLの値を探索すればよい。図20の例では、H(A)=(A+4)/6又はH(A)=(A−2)/6のときに、関数H(A)の周期の境が関数Fと関数Gの周期の境に一致する。このようにして探索されたH(A)を分散キーとして用いれば、2つのクエリを1つの分散グループに、適切に所属させることができる。
図21は、2つの関数の周期長が割り切れる関係にある場合の例を示している。図21(A)は、関数F(A)の周期の境と、関数G(A)の周期の境が一致している例を示している。欄2101は、プロパティAの値を示している。欄2102、2103、2104は、それぞれ関数F(A)、G(A)、H(A)の値を示している。この場合には、両関数にズレが無いため、ステップ1914で説明したように、2つの関数のうち、周期長の長い関数と同じ関数を関数H(A)として採用すればよい。
図21(B)は、両関数にズレがある場合の例である。欄2111は、プロパティAの値を示している。欄2112、2113、2114は、それぞれ関数F(A)、G(A)、H(A)の値を示している。両関数の周期長が割り切れるため、ズレが周期的に発生する。この場合には、2つの関数の周期長のうち長い方の周期長の関数と同じ関数を関数H(A)として採用することができる。図21(B)の場合には、2つのクエリを同一の分散グループに所属させて、複数ノードに配備した場合、例えば、Aの値が2のときに、ノード間での転送が発生する。この転送の発生する割合の平均は、H(A)の周期長が4であることから、1/4となる。したがって、H(A)を分散キーとして用いた場合の関数精度は、3/4すなわち、75%となる。この75%が許容できる精度であれば、H(A)を共通分散キーとして採用することができる。この判断には、精度が、所定の閾値を超えるか否かを判断すればよい。この所定の閾値は、第2の閾値の一例である。
なお、本実施形態では、周期性を持つ関数F、G、及びHについて、例示を行ったが、これらの関数は、周期性を有する関数に限られない。関数は、周期性のある関数以外に拡張可能である。以下に、拡張された関数への応用についての例を挙げる。
たとえば、同じ引数を持つクエリQ1が関数Fを分散キーとして持ち、クエリQ2が関数Gを分散キーとして持ち、かつ、関数Fと関数Gが同じ引数を持つ場合を想定する。そして、クエリQ1とクエリQ2とを、同じ分散グループに所属させ、複数のノードに並列分散させる場合を想定する。この場合において、関数Hで、入力イベント列をハッシングした場合に、ノード間での通信の発生割合が許容限度内になるような関数Hを採用すればよい。
図22は、クエリを分散グループに所属させる例を示している。図22(A)に示すように、データストリームとしてのイベント列E1のプロパティは{A,C}である。クエリQ1は、イベント列E1を入力とし、イベント列E2を出力する。クエリQ2は、イベント列E2を入力とし、イベント列E3を出力する。クエリQ3は、イベント列E3を入力とし、イベント列E4を出力する。クエリQ1は、クエリプログラム2201で定義されている。クエリQ2は、クエリプログラム2202で定義されている。クエリQ3は、クエリプログラム2203で定義されている。
図22(B)は、図22(A)に対する分散キーテーブル2210を示している。図22(C)は、図22(A)に対するプロパティ関係テーブル2220を示している。
図23は、クエリを分散グループに所属させる例を示している。図22(A)に示すように、クエリQ1が、既に分散グループG1(2301)に所属している。そして、クエリQ2を分散グループに所属できるか否かを検討している段階が示されている。
図22(B)に戻る。クエリQ1の分散キーセットは、{A,C}であり、クエリQ2の分散キーセットは{B}である。両者には共通した分散キーセットが存在しない。したがって、分散キーテーブル2210のみからは、Q1が所属する分散グループに、Q2を所属させることができない。
そこで、図22(C)のプロパティ関係テーブル2220から、以下の関係が抽出される。
E2.B=F(E1.A)=E1.A/2
このため、クエリQ1は、さらに関数A/2を分散キーとして持つことが分かる。このことはステップ1706における判断が「はい」であることを意味する。しかも、この関数A/2は、Bに等しく、かつQ2の分散キーでもある。このことは、ステップ1708における判断が「はい」である場合に該当する。そして、ステップ1710で、分散キーとして、関数A/2(すなわちB)も分散キーとして認識される。
E2.B=F(E1.A)=E1.A/2
このため、クエリQ1は、さらに関数A/2を分散キーとして持つことが分かる。このことはステップ1706における判断が「はい」であることを意味する。しかも、この関数A/2は、Bに等しく、かつQ2の分散キーでもある。このことは、ステップ1708における判断が「はい」である場合に該当する。そして、ステップ1710で、分散キーとして、関数A/2(すなわちB)も分散キーとして認識される。
したがって、図23(B)に示すように、グループG1に、クエリQ1及びクエリQ2を所属させたことを分散グループ一覧に保存する。
図23(C)は、分散グループごとの分散キー一覧に、分散キーの欄には、Aを記入し、関数の欄には、A/2を記入する。この場合、関数の欄に記入されたA/2も、分散キーとしての役割を果たす。
図24は、更なるクエリQ3を分散グループに所属させる例を示している。この場合は、イベントE3にもプロパティが含まれているため、以下の関係が成り立つ。
E3.B=E2.B=E1.A/2
このことは、同様に、ステップ1706の判断が「はい」であり、ステップ1708の判断も「はい」である。したがって、分散グループごとの分散キー一覧には、図24(B)の情報が追記される。そして、Q1、Q2、及びQ3は、同一の分散部ループに所属させることができる。
E3.B=E2.B=E1.A/2
このことは、同様に、ステップ1706の判断が「はい」であり、ステップ1708の判断も「はい」である。したがって、分散グループごとの分散キー一覧には、図24(B)の情報が追記される。そして、Q1、Q2、及びQ3は、同一の分散部ループに所属させることができる。
図25は、入力イベントのプロパティ間の動的関係を利用して分散グループを作る例を示している。既にQ2とQ3は同じ分散グループ2530に所属している。しかしながら、イベント列E1(2510)に示すように、クエリQ1の分散キーはAである。そして、イベント列E2(2520)に示すように、分散グループ2530の分散キーはBである。この場合、クエリQ1と分散グループ2530の分散キーが異なるため、クエリQ1を分散グループ2530に所属させることができない。
しかしながら、イベント列E1(2540)のプロパティAとBとの間には、関係が存在する。この例の場合には、B=A/2という関係が成り立っている。このことは、Q1の分散キーは、Aのみではなく、Bも分散キーであることを示している。したがって、
Q1と分散グループ2530とは、共通の分散キーBを持つこととなる。したがって、分散グループ2550にQ1、Q2、及びQ3を所属させることができる。
Q1と分散グループ2530とは、共通の分散キーBを持つこととなる。したがって、分散グループ2550にQ1、Q2、及びQ3を所属させることができる。
なお、この場合には、イベントE1のプロパティAとBとの動的な関係を用いたため、その関係の確率は100%とはならない場合が多い。しかしながら、この関係の確率が許容レベル以上であれば、上記のように分散グループ2550を作って、このノードを複数の並列分散されたノードに配備しても、ノード間の通信量は、許容レベル内となることが推定できる。
図26については、図16の説明において詳細を説明した。
図27は、分散グループに所属させる動作の他の例を示す図である。
ステップ2702は、ステップ2720との間で処理を実行する。そして、図27にっしめすフローは、再帰的に実行される点に留意すべきである。このフローでは、未処理のクエリを「残クエリ一覧(R)」に記憶しておく。そして、処理が終了したクエリは、残クエリ一覧(R)から消去する。残クエリ一覧(R)が空となるまで、再帰的な処理が繰り返される。
ステップ2704で、共通分散キー特定部1150は、グループGとグループに接続されたクエリQの両方に共通に利用できる分散キーセットSを計算する。なお、グループGが作られていない場合には、例えばデータストリームの最初に存在するクエリをグループGに所属するとして処理を行ってもよい。
ステップ2706で、共通分散キー特定部1150は、その結果(S)が少なくとも1つの分散キーが存在するかが判断される(すなわち、Sが空でないことを判断する)。この判断が「はい」であればステップ2708に移動する。この判断が「いいえ」であれば、ステップ2720に進んで、ループを繰り返す。
ステップ2708で、共通分散キー特定部1150は、結果Sが、グループGの分散キーセットと同じかが判断される。この判断が「はい」であればステップ2710に進む。この判断が「いいえ」であればステップ2716に進む。
ステップ2710で、共通分散キー特定部1150は、クエリQをグループGに追加する。この場合には、グループGとクエリQが同じ分散キーを持つため、クエリQをグループGに所属させることができる。しかも、グループGの分散キーを変更しなくてもよい。
ステップ2712で、クエリQを経由してグループGに繋がる残クエリ一覧(R)を取得する。
ステップ2714で、共通分散キー特定部1150は、残クエリ一覧(R)のうち、グループGと共通に利用できる分散キーセットを持ったクエリをグループGに追加する。そして、ステップ2702を再帰的に実行する。
ステップ2716で、共通分散キー特定部1150は、計算結果の分散キーセットSを使ったグループG2を作成する。なお、クエリQに繋がる、分散キーセットSを持ったグループが既に作成済みの場合には、グループG2を新たに作成せず、既存のグループにクエリを追加すればよい。
ステップ2718で、共通分散キー特定部1150は、クエリQとグループGの全クエリをグループG2に追加する。そして、グループG2の分散キーセットはSである。
以上の処理を行うことによって、共通分散キー特定部1150は、全てのクエリを、1つ以上の分散グループに所属させることができる。
そして、クエリ配備部は、1つ以上の分散グループが作成された後、複数のノードに作成された分散グループに所属するクエリを配備することができる。
図28は、本発明の実施形態のハードウェア(コンピュータ)の構成例を示している。ハードウェアは、CPU2810、メモリ2815、入力装置2820、出力装置2825、外部記憶装置2830、可搬記録媒体駆動装置2835、ネットワーク接続装置2845が含まれる。そして、それぞれの機器は、バス2850によって接続されている。また、可搬記録媒体駆動装置2835は、可搬記録媒体2840を読み書きすることができる。そして、ネットワーク接続装置2845には、ネットワーク2860が接続されている。
なお、本実施形態の全部又は一部はプログラムによってインプリメントされ得る。このプログラムは、可搬記録媒体2840に格納することができる。可搬記録媒体2840とは、非一時的(non-transitory)な記憶媒体を言う。例示として、可搬記録媒体2840としては、磁気記録媒体、光ディスク、光磁気記録媒体、不揮発性メモリなどがある。磁気記録媒体には、HDD、フレキシブルディスク(FD)、磁気テープ(MT)などがある。光ディスクには、DVD(Digital Versatile Disc)、DVD−RAM、CD−ROM(Compact Disc-Read Only Memory)、CD−R(Recordable)/RW(ReWritable)などがある。また、光磁気記録媒体には、MO(Magneto-Optical disk)などがある。可搬型記録媒体に格納されたプログラムが読み込まれ、CPUによって実行されることにより、本発明の実施形態の全部又は一部が実施され得る。
1100 データストリーム処理の並列化システム
1110 プロパティ関係抽出部
1120 動的プロパティ関係抽出部
1122 入力イベント保存部
1124 関係確率算出部
1126 関係特定部
1130 静的プロパティ関係抽出部
1134 関数特定部
1150 共通分散キー特定部
1152 分散キー抽出部
1154 共通分散キー生成部
1155 第3の関数生成部
1156 関数精度算出部
1160 テーブル記憶部
1170 クエリ配備部
1110 プロパティ関係抽出部
1120 動的プロパティ関係抽出部
1122 入力イベント保存部
1124 関係確率算出部
1126 関係特定部
1130 静的プロパティ関係抽出部
1134 関数特定部
1150 共通分散キー特定部
1152 分散キー抽出部
1154 共通分散キー生成部
1155 第3の関数生成部
1156 関数精度算出部
1160 テーブル記憶部
1170 クエリ配備部
Claims (12)
- 複数のイベントを有するデータストリームを処理する複数のクエリの部分集合を含む分散グループを、複数のノードに配備するプログラムであって、前記イベントは1つ以上のプロパティを含み、
前記データストリーム、及び/又は、前記複数のクエリの各々の定義から、前記複数のクエリの各々の入力イベント及び出力イベントに含まれる複数のプロパティの間の関係を抽出し、
クエリの定義に記された分散キーと、前記複数のプロパティの間の関係と、前記関係の確率とに基づいて、前記分散グループに含まれる前記複数のクエリの部分集合に共通に利用し得る共通分散キーを特定し、
前記特定された共通分散キーに基づいて、並列分散されたノードの各々に、前記分散グループに所属するべき前記複数のクエリの部分集合を配備する、
処理をコンピュータに実行させるデータストリーム処理の並列化プログラム。 - 前記複数のプロパティの間の関係を抽出する処理は、
第1のクエリに入力される複数の入力イベントを保存し、
前記保存された複数の入力イベントに含まれる複数のプロパティの間のうち所定の第1の2つのプロパティが、1対N又は1対1[Nは整数]となる関係の確率が、所定の第1の閾値を超える場合、前記所定の第1の2つのプロパティを特定する処理、を含み、
前記共通分散キーを特定する処理は、前記特定された所定の第1の2つのプロパティ及び前記特定された所定の第1の2つのプロパティの間の関係の確率を、前記共通分散キーを特定するために用いる、
請求項1記載のデータストリーム処理の並列化プログラム。 - 前記複数のプロパティの間の関係を抽出する処理は、
第2のクエリが、分散キーを関数として定義している場合、前記関数と、前記関数に関連する複数のプロパティとを特定する処理を含み、
前記共通分散キーを特定する処理は、前記関数と、前記関数に関連する複数のプロパティとを、前記共通分散キーを特定するために用いる、
請求項1又は2記載のデータストリーム処理の並列化プログラム。 - 前記共通分散キーを特定する処理は、
第1のクエリが定義する第1の関数が第1の周期長を持ち、前記第1のクエリに後続する第2のクエリが定義する第2の関数が第2の周期長を持つ場合であって、前記第1の周期長及び前記第2の周期長の最小公倍数を持つ第3の関数を共通分散キーとして、前記第1のクエリと前記第2のクエリとを同一の分散グループに所属させた場合、前記分散グループに並列配備された複数のノードに入力されるデータストリームの全イベント数に対する、前記複数のノードの間をまたがって通信されるイベント数の割合が、第2の閾値以下となる、前記第3の関数を生成する処理を含み、
前記共通分散キーを特定する処理は、前記第3の関数を、前記共通分散キーを特定するために用いる、
請求項3記載のデータストリーム処理の並列化プログラム。 - 複数のイベントを有するデータストリームを処理する複数のクエリの部分集合を含む分散グループを、複数のノードに配備する方法であって、前記イベントは1つ以上のプロパティを含み、
コンピュータが、
前記データストリーム、及び/又は、前記複数のクエリの各々の定義から、前記複数のクエリの各々の入力イベント及び出力イベントに含まれる複数のプロパティの間の関係を抽出する処理と、
クエリの定義に記された分散キーと、前記複数のプロパティの間の関係と、前記関係の確率とに基づいて、前記分散グループに含まれる前記複数のクエリの部分集合に共通に利用し得る共通分散キーを特定する処理と、
前記特定された共通分散キーに基づいて、並列分散されたノードの各々に、前記分散グループに所属するべき前記複数のクエリの部分集合を配備する処理と、
を実行するデータストリーム処理の並列化方法。 - 前記複数のプロパティの間の関係を抽出する処理は、
第1のクエリに入力される複数の入力イベントを保存する処理と、
前記保存された複数の入力イベントに含まれる複数のプロパティの間のうち所定の第1の2つのプロパティが、1対N又は1対1[Nは整数]となる関係の確率が、所定の第1の閾値を超える場合、前記所定の第1の2つのプロパティを特定する処理と、を含み、
前記共通分散キーを特定する処理は、前記特定された所定の第1の2つのプロパティ及び前記特定された所定の第1の2つのプロパティの間の関係の確率を、前記共通分散キーを特定するために用いる、
請求項5記載のデータストリーム処理の並列化方法。 - 前記複数のプロパティの間の関係を抽出する処理は、
第2のクエリが、分散キーを関数として定義している場合、前記関数と、前記関数に関連する複数のプロパティとを特定する処理を含み、
前記共通分散キーを特定する処理は、前記関数と、前記関数に関連する複数のプロパティとを、前記共通分散キーを特定するために用いる、
請求項5又は6記載のデータストリーム処理の並列化方法。 - 前記共通分散キーを特定する処理は、
第1のクエリが定義する第1の関数が第1の周期長を持ち、前記第1のクエリに後続する第2のクエリが定義する第2の関数が第2の周期長を持つ場合であって、前記第1の周期長及び前記第2の周期長の最小公倍数を持つ第3の関数を共通分散キーとして、前記第1のクエリと前記第2のクエリとを同一の分散グループに所属させた場合、前記分散グループに並列配備された複数のノードに入力されるデータストリームの全イベント数に対する、前記複数のノードの間をまたがって通信されるイベント数の割合が、第2の閾値以下となる、前記第3の関数を生成する処理を含み、
前記共通分散キーを特定する処理は、前記第3の関数を、前記共通分散キーを特定するために用いる、
請求項7記載のデータストリーム処理の並列化方法。 - 複数のイベントを有するデータストリームを処理する複数のクエリの部分集合を含む分散グループを、複数のノードに配備するシステムであって、前記イベントは1つ以上のプロパティを含み、
前記データストリーム、及び/又は、前記複数のクエリの各々の定義から、前記複数のクエリの各々の入力イベント及び出力イベントに含まれる複数のプロパティの間の関係を抽出する、プロパティ関係抽出部と、
クエリの定義に記された分散キーと、前記複数のプロパティの間の関係と、前記関係の確率とに基づいて、前記分散グループに含まれる前記複数のクエリの部分集合に共通に利用し得る共通分散キーを特定する、共通分散キー特定部と、
前記特定された共通分散キーに基づいて、並列分散されたノードの各々に、前記分散グループに所属するべき前記複数のクエリの部分集合を配備する、クエリ配備部と、
を有するデータストリーム処理の並列化システム。 - 前記プロパティ関係抽出部は、
第1のクエリに入力される複数の入力イベントを保存する入力イベント保存部と、
前記保存された複数の入力イベントに含まれる複数のプロパティの間のうち所定の第1の2つのプロパティが、1対N又は1対1[Nは整数]となる関係の確率が、所定の第1の閾値を超える場合、前記所定の第1の2つのプロパティを特定する、関係特定部と、を含み、
前記共通分散キー特定部は、前記特定された所定の第1の2つのプロパティ及び前記特定された所定の第1の2つのプロパティの間の関係の確率を、前記共通分散キーを特定するために用いる、
請求項9記載のデータストリーム処理の並列化システム。 - 前記プロパティ関係抽出部は、
第2のクエリが、分散キーを関数として定義している場合、前記関数と、前記関数に関連する複数のプロパティとを特定する、関数特定部、を含み、
前記共通分散キー特定部は、前記関数と、前記関数に関連する複数のプロパティとを、前記共通分散キーを特定するために用いる、
請求項9又は10記載のデータストリーム処理の並列化システム。 - 前記共通分散キー特定部は、
第1のクエリが定義する第1の関数が第1の周期長を持ち、前記第1のクエリに後続する第2のクエリが定義する第2の関数が第2の周期長を持つ場合であって、前記第1の周期長及び前記第2の周期長の最小公倍数を持つ第3の関数を共通分散キーとして、前記第1のクエリと前記第2のクエリとを同一の分散グループに所属させた場合、前記分散グループに並列配備された複数のノードに入力されるデータストリームの全イベント数に対する、前記複数のノードの間をまたがって通信されるイベント数の割合が、第2の閾値以下となる、前記第3の関数を生成する、第3の関数生成部、を含み、
前記共通分散キー特定部は、前記第3の関数を、前記共通分散キーを特定するために用いる、
請求項11記載のデータストリーム処理の並列化システム。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2013/063983 WO2014188500A1 (ja) | 2013-05-20 | 2013-05-20 | データストリーム処理の並列化プログラム、及びデータストリーム処理の並列化システム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP6028857B2 true JP6028857B2 (ja) | 2016-11-24 |
JPWO2014188500A1 JPWO2014188500A1 (ja) | 2017-02-23 |
Family
ID=51933091
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2015517949A Active JP6028857B2 (ja) | 2013-05-20 | 2013-05-20 | データストリーム処理の並列化プログラム、及びデータストリーム処理の並列化システム |
Country Status (3)
Country | Link |
---|---|
US (1) | US10459921B2 (ja) |
JP (1) | JP6028857B2 (ja) |
WO (1) | WO2014188500A1 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR102141640B1 (ko) * | 2020-04-13 | 2020-08-05 | 주식회사 데이터월드 | 실시간 네트워크 데이터 관리 방법 및 이를 실행하는 서버 |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2017072938A1 (ja) * | 2015-10-30 | 2017-05-04 | 株式会社日立製作所 | 計算機のスケールアウト方法、計算機システム及び記憶媒体 |
WO2017168497A1 (ja) * | 2016-03-28 | 2017-10-05 | 株式会社日立製作所 | 計算機システム及びストリームデータ処理システムの設定方法 |
JP6626198B2 (ja) * | 2016-06-27 | 2019-12-25 | 株式会社日立製作所 | 管理装置、実行環境設定方法、ストリームデータ処理システム |
WO2018053320A1 (en) | 2016-09-15 | 2018-03-22 | Oracle International Corporation | Automatic partitioning of stream data for shapes |
US10580196B1 (en) | 2018-08-10 | 2020-03-03 | Nvidia Corporation | Method for continued bounding volume hierarchy traversal on intersection without shader intervention |
CN109492394B (zh) * | 2018-10-25 | 2024-05-03 | 平安科技(深圳)有限公司 | 异常业务请求的识别方法及终端设备 |
US11194812B2 (en) * | 2018-12-27 | 2021-12-07 | Microsoft Technology Licensing, Llc | Efficient aggregation of sliding time window features |
CN110059068B (zh) * | 2019-04-11 | 2021-04-02 | 厦门网宿有限公司 | 一种分布式存储***中的数据校验方法及数据校验*** |
WO2023127047A1 (ja) * | 2021-12-27 | 2023-07-06 | 日本電気株式会社 | コード変換装置、コード変換方法、及びコンピュータ読み取り可能な記録媒体 |
JP2024075439A (ja) * | 2022-11-22 | 2024-06-03 | 富士通株式会社 | クエリ実行方法およびクエリ実行プログラム |
Family Cites Families (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS5121053B2 (ja) | 1972-06-29 | 1976-06-30 | ||
US5727197A (en) | 1995-11-01 | 1998-03-10 | Filetek, Inc. | Method and apparatus for segmenting a database |
US7743044B1 (en) | 2002-05-28 | 2010-06-22 | Hewlett-Packard Development Company, L.P. | Distributed information retrieval in peer-to-peer networks |
US7663671B2 (en) | 2005-11-22 | 2010-02-16 | Eastman Kodak Company | Location based image classification with map segmentation |
US7496683B2 (en) | 2006-07-27 | 2009-02-24 | International Business Machines Corporation | Maximization of sustained throughput of distributed continuous queries |
US7680765B2 (en) | 2006-12-27 | 2010-03-16 | Microsoft Corporation | Iterate-aggregate query parallelization |
US8156134B2 (en) | 2007-11-15 | 2012-04-10 | International Business Machines Corporation | Using different groups of query graph transform modules to generate execution plans for queries for different database types |
US8060614B2 (en) | 2008-06-19 | 2011-11-15 | Microsoft Corporation | Streaming operator placement for distributed stream processing |
US9418107B2 (en) | 2008-07-30 | 2016-08-16 | At&T Intellectual Property I, L.P. | Method and apparatus for performing query aware partitioning |
US8190598B2 (en) | 2008-10-30 | 2012-05-29 | Hewlett-Packard Development Company, L.P. | Skew-based costing for database queries |
US20100318516A1 (en) | 2009-06-10 | 2010-12-16 | Google Inc. | Productive distribution for result optimization within a hierarchical architecture |
JP5396184B2 (ja) | 2009-07-31 | 2014-01-22 | 株式会社日立製作所 | 計算機システム及び複数計算機によるストリームデータ分散処理方法 |
JP4925143B2 (ja) | 2009-08-12 | 2012-04-25 | 株式会社日立製作所 | ストリームデータ処理システム、ストリームデータ処理方法及びストリームデータ処理プログラム |
JP5395565B2 (ja) * | 2009-08-12 | 2014-01-22 | 株式会社日立製作所 | ストリームデータ処理方法及び装置 |
JP5295062B2 (ja) | 2009-09-29 | 2013-09-18 | 株式会社日立ソリューションズ | 複合イベント処理向けクエリ自動生成装置 |
US20110131198A1 (en) | 2009-11-30 | 2011-06-02 | Theodore Johnson | Method and apparatus for providing a filter join on data streams |
JP4967014B2 (ja) | 2009-12-16 | 2012-07-04 | 株式会社日立製作所 | ストリームデータ処理装置及び方法 |
US9514214B2 (en) | 2013-06-12 | 2016-12-06 | Microsoft Technology Licensing, Llc | Deterministic progressive big data analytics |
JP6442951B2 (ja) | 2014-09-25 | 2018-12-26 | 富士通株式会社 | データ処理方法、データ処理プログラム及びデータ処理装置 |
-
2013
- 2013-05-20 WO PCT/JP2013/063983 patent/WO2014188500A1/ja active Application Filing
- 2013-05-20 JP JP2015517949A patent/JP6028857B2/ja active Active
-
2015
- 2015-11-17 US US14/943,454 patent/US10459921B2/en active Active
Non-Patent Citations (2)
Title |
---|
JPN6013030360; VIEL, Emeric et al: Parallelism Extraction in Data Stream Programs, [online] , 20130302, pp.1〜15 * |
JPN6013030363; IVERT, Annica: 'LINEAR PROGRAMMING OPTIMIZATION OF QUERY ALLOCATION IN A DISTRIBUTED CEP SYSTEM' Bachelor Thesis, Royal Institute of Technology, [online] , 2012, pp.1〜41 * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR102141640B1 (ko) * | 2020-04-13 | 2020-08-05 | 주식회사 데이터월드 | 실시간 네트워크 데이터 관리 방법 및 이를 실행하는 서버 |
Also Published As
Publication number | Publication date |
---|---|
JPWO2014188500A1 (ja) | 2017-02-23 |
WO2014188500A1 (ja) | 2014-11-27 |
US10459921B2 (en) | 2019-10-29 |
US20160070761A1 (en) | 2016-03-10 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6028857B2 (ja) | データストリーム処理の並列化プログラム、及びデータストリーム処理の並列化システム | |
US10628490B2 (en) | Techniques for digital entity correlation | |
Codetta-Raiteri | The conversion of dynamic fault trees to stochastic Petri nets, as a case of graph transformation | |
US9116968B2 (en) | Methods and apparatus related to graph transformation and synchronization | |
US8762604B2 (en) | Managing buffer conditions through sorting | |
US9971798B2 (en) | Managing data profiling operations related to data type | |
US10593080B2 (en) | Graph generating method and apparatus | |
US11861331B1 (en) | Scaling high-level statistical languages to large, distributed datasets | |
WO2016177027A1 (zh) | 批量数据查询方法和装置 | |
CN103793653A (zh) | 一种基于树优化的程序依赖关系分析方法及*** | |
Sun et al. | Non-MapReduce computing for intelligent big data analysis | |
Ediger et al. | Computational graph analytics for massive streaming data | |
Khafagy | Indexed map-reduce join algorithm | |
US11061704B2 (en) | Lightweight and precise value profiling | |
JP6319694B2 (ja) | データキャッシュ方法、ノード装置及びプログラム | |
Saeedan et al. | dsJSON: A Distributed SQL JSON Processor | |
Byambajav et al. | Performance of left outer join on hadoop with right side within single node memory size | |
KR101441000B1 (ko) | 병렬처리 기반 트리플 데이터에 대한 변경 탐지 방법 | |
Sethi et al. | PPS: parallel pincer search for mining frequent itemsets based on spark | |
JP2018081603A (ja) | Kvデータ構造変換装置、kvデータ構造変換方法、および、kvデータ構造変換プログラム | |
Zimniak et al. | On systematic approach to discovering periodic patterns in event logs | |
KR20220122562A (ko) | 서브 그래프 매칭 방법 및 장치 | |
You et al. | Improved EM algorithm for MPT model analysis | |
Yanai et al. | Analysis and Learning Frameworks for Large-Scale Data Mining |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20160920 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20161003 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 6028857 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |