JP5887418B2 - ストリームデータ多重処理方法 - Google Patents
ストリームデータ多重処理方法 Download PDFInfo
- Publication number
- JP5887418B2 JP5887418B2 JP2014535316A JP2014535316A JP5887418B2 JP 5887418 B2 JP5887418 B2 JP 5887418B2 JP 2014535316 A JP2014535316 A JP 2014535316A JP 2014535316 A JP2014535316 A JP 2014535316A JP 5887418 B2 JP5887418 B2 JP 5887418B2
- Authority
- JP
- Japan
- Prior art keywords
- processing
- tuple
- query
- stage
- stream data
- 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/90—Details of database functions independent of the retrieved data types
- G06F16/901—Indexing; Data structures therefor; Storage structures
- G06F16/9024—Graphs; Linked lists
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Software Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は、ストリームデータ処理のスケールアップ技術に関する。
株取引の自動化、交通情報処理の高度化、クリックストリームの解析といった、高いレートで継続的に発生する情報をリアルタイムに解析し、重要なイベントの発生に対して瞬時にアクションを起こす要求の高まりを背景に、高レートデータのリアルタイム処理を実現する、ストリームデータ処理が注目されている。ストリームデータ処理は、様々なデータ処理に適用可能な汎用ミドルウェア技術であるため、個別案件ごとにシステムを構築するのでは間に合わないようなビジネス環境の急激な変化にも応えつつ、実世界のデータをリアルタイムにビジネスに反映することを可能とする。
ストリームデータ処理が対象とするストリームとは、タイムスタンプ付きのデータであるタプルが、連続して到来する時系列データである。ストリームデータ処理のユーザが、このストリームに対する監視ルールをクエリとして定義すると、クエリ定義をクエリグラフに変換する。クエリグラフは、オペレータと呼ばれる処理単位をノードとし、同オペレータ間のタプルキューをエッジとする、有向グラフである。入力ストリームを構成する個々のタプルについて、クエリグラフを通過させることで、データフロー的に処理を進める。データフロー型の処理であるため、クエリグラフを多段分割し、複数の計算資源によってパイプライン的に並列処理することで、スループット向上が可能である。
一方で、イベントの発生からアクションを起こすまでの時間、即ちレイテンシについても、ミリ秒〜マイクロ秒オーダの、非常に厳しい要求が課せられる。従って、ストリームデータ処理においては、レイテンシ性能とスループット性能の両立が、重要な技術課題である。
本技術分野の背景技術として、特開2010−204880号公報(特許文献1)がある。この公報には、「ストリームデータ処理システムのストリームデータのクエリ処理に関するスループットを向上させる。サーバ装置のスケジューラが、クエリをグループ化するクエリグループへのデータ停滞が発生すると、クエリグループを構成するクエリごとに、そのクエリの入力流量情報およびレイテンシ情報の内の少なくとも1つの情報を基に、そのクエリの負荷評価値を計算し、クエリグループを構成するクエリを、互いにクエリの負荷評価値の和が略均等になるように、複数のクエリグループへと分割し、分割後の複数のクエリグループを、それぞれ異なるプロセッサに再割り当てする。」と記載されている(特許文献1の要約参照)。
また、特開2008−146503号公報(特許文献2)がある。この公報には、「制御用のプロセッサユニット(PU)と、それぞれがローカルメモリをもつ複数の演算用のサブプロセッサユニット(SPU)と、メインメモリとを含むマルチプロセッサシステムを提供する。複数のSPU上で動作するオペレーティングシステムは、各SPUの計算資源を時分割して複数のタスクに割り当てることにより、複数のタスクが並列に実行されるマルチタスク環境において、タスクの実行結果を別のタスクに与えることにより、負荷の異なる複数のタスクからなる特定処理を実行するためのパイプライン処理系を構築し、当該パイプライン処理系を複数動作させる機能と、メインメモリにコンテキストが退避されて実行可能状態にあるタスクをいずれのタスクも実行していないSPUのローカルメモリにロードして実行させる機能とを含む。」と記載されている(特許文献2の要約参照)。
また、特開2010−108152号公報(特許文献3)がある。この公報には、「再帰的処理を含む一般のデータ処理を低レイテンシで実現できるストリームデータ処理方法及びシステムを提供する。ストリームデータ処理システムは、複数のクエリの実行木から単一のオペレータグラフを構築し、ストリーム化演算の実行が、入力から出力に向かって一方通行で進むように、オペレータの実行順序を決定し、システム外部のデータを入力する外部発火オペレータと時限的にデータを生成する内部発火オペレータの発火時刻を監視し、オペレータ実行制御部は、最も早い発火時刻のオペレータを起点として、決定したオペレータ実行順序に従って、当該時刻のオペレータグラフにおける処理を完結させる処理を繰り返す。」と記載されている(特許文献3の要約参照)。
前項で述べた文献の個々の技術では、レイテンシとスループットの両立の点で課題が残る。特許文献3の方法は、各タプルをクエリグラフの入口から出口まで、一つの計算スレッドで集中処理するため、個々のタプルについて最短パスで処理することになり、レイテンシを抑えることが可能となっている。しかしながら、シングルスレッド実行が前提となるため、マルチCPU、マルチコアといった複数の計算リソースを、スループットの向上に資することが出来ない。
特許文献1の方法は、複数の計算リソースによるパイプライン処理において、各ステージの計算負荷を監視し、負荷が増大したステージは、さらに複数のステージに再分割することで、処理のボトルネックを回避する。但し、パイプライン処理では、完全にボトルネックを回避することが難しい。
図2、図3に示す例を用いて、ここで注目している課題を説明する。図2に示したクエリグラフは、OP1〜OP10の10個のオペレータ201〜210によって構成されている。ここで、各オペレータの計算コストは、オペレータに付与された長方形内の値をとることとする。計算コストの合計、即ち1タプル当りの処理時間は100である。また、本例では4つの計算コアでのクエリ実行を想定する。ここで、このクエリグラフを、図3のようにA〜Dの4つのステージ301〜304に分割する。各ステージの計算コストは、それぞれステージA(301)が21、ステージB(302)が23、ステージC(303)が30、ステージD(304)が26となる。この分割は、各ステージの計算コストが、合計コスト合計の4(コア数)分の1の25に近くなるように、定めたものである。1タプルの処理時間に対する、各ステージの処理時間の割合は310に示す通りである。
ここで、タプル処理時間の1/4の間隔でタプルが到来する場合、各タプルは、各計算コアにおいて、タイムチャート311に示すようなスケジュールで処理されることになる。なお、ステージXにおけるタプルnの処理を、Xnと表記する。また、ステージA、B、C、およびDの処理は、それぞれ計算コア0、1、2、および3上で実行されることとする。タイムチャート311は、計算コア2で実行されるステージCの処理において、タプルnの処理Cnが、その一つ前のタプルn−1のタプルの処理C(n−1)の完了まで待たされる様子を表している。このように、パイプライン処理においては、最も処理時間の長いステージに律速されて、スループット性能、レイテンシ性能ともに向上しない、という課題が存在する。4つのステージの処理時間を、全て1タプルの処理時間の丁度1/4となるように、均等にクエリグラフを分割できれば、この課題は回避されるが、ほとんどのクエリにおいて、そのような条件は成立しない。
特許文献2は、一つの特定処理を、それぞれ処理時間の異なる複数のタスクに分割した場合の、タスクスケジューリング方法を示している。特定処理を、一つのタプルについてのクエリ処理、タスクをステージと読み替えることで、ストリームデータのパイプライン処理にも適用可能となる。本方法に従えば、各計算コアは、一つのステージの処理が終わる度に、一旦その処理コンテキスト(タプルの中間処理状態)をキューイングし、処理が空いた他の計算コアが、キューの先頭から取り出したコンテキストの処理を再開する、といった実行様式になる。この方法では、一つのタプルについての処理が、ステージの終了の都度一旦途切れるため、レイテンシ性能に対するオーバヘッドとなる。
パイプライン型の並列処理に対し、データ分割による並列処理も方法も存在する。株価の処理を例に取れば、同一のクエリを実行するクエリグラフを銘柄別で用意し、入力タプルの銘柄属性の値に応じて、クエリグラフを切り替えるような方法である。ここで、クエリグラフを構成する各オペレータは、実行状態を持っている(例えば、価格の移動平均を計算する場合は、スライディングウィンドウ上の価格の和、および価格データ数の値が、実行状態として保持されており、新しいタプルを入力した際には、これら実行状態を更新する)ため、同じ銘柄属性を持つタプルは、常に同じクエリグラフで処理する必要がある。そのため、仮に特定の銘柄のデータが集中すると、並列化の効果が得られなくなってしまう。また、データ分割処理は、属性毎に独立に計算可能なクエリにしか適用できない。例えば、全銘柄の株価を対象とした株式指数の算出には適用不可である。
上記課題を解決するための本発明の代表的処理方法の特徴を挙げるならば、
クエリ定義をクエリグラフに変換してオペレータ間の実行順序を決定するクエリパーサを備え、かつ複数のクエリ実行スレッドを備えストリーム処理システムにより実行するストリームデータ多重処理方法であって、前記実行順序において連続するオペレータの集合をステージと呼び、各ステージを構成するオペレータの計算コストの合計を、当該ステージの計算コストと呼び、各ステージの計算コストが、全オペレータの合計コストを計算コア数で割った値よりも小さな値となるように、クエリグラフを複数のステージに分割し、各計算コアは、入力ストリームから一つずつタプルを取り出して、クエリグラフの入口から出口まで当該タプルの処理を担当して実行する際に、各ステージの実行に先立って、担当タプルの一つ前のタプルについて当該ステージの処理が完了しているか否かを確認することに特徴がある。
クエリ定義をクエリグラフに変換してオペレータ間の実行順序を決定するクエリパーサを備え、かつ複数のクエリ実行スレッドを備えストリーム処理システムにより実行するストリームデータ多重処理方法であって、前記実行順序において連続するオペレータの集合をステージと呼び、各ステージを構成するオペレータの計算コストの合計を、当該ステージの計算コストと呼び、各ステージの計算コストが、全オペレータの合計コストを計算コア数で割った値よりも小さな値となるように、クエリグラフを複数のステージに分割し、各計算コアは、入力ストリームから一つずつタプルを取り出して、クエリグラフの入口から出口まで当該タプルの処理を担当して実行する際に、各ステージの実行に先立って、担当タプルの一つ前のタプルについて当該ステージの処理が完了しているか否かを確認することに特徴がある。
上記本発明の特徴に従うストリームデータ多重処理方法によれば、クエリグラフを最短パスで処理することで得られる低レイテンシ性能と、計算コア数分の複数スレッドを並列動作させることで得られるスループット向上を両立する。したがって、低レイテンシ化、高スループット化の効果が得られる。
以下、実施例を、図面を用いて説明する。
図1を用いて、本発明の実施例のストリームデータ処理サーバが動作する、計算機環境の一例を説明する。ストリームデータ処理サーバ100は、CPU90、91、92、93、メモリ103、ネットワークインタフェース105、ストレージ106、およびそれらを結合するバス104によって構成される計算機である。メモリ103上に、ストリームデータ処理の論理動作を定義するストリームデータ処理部110を配置する。ストリームデータ処理部110は、CPU90〜93によって解釈実行可能な実行イメージである。
ストリームデータ処理サーバ100は、ネットワークインタフェース105を介して外部ネットワーク150に接続される。外部ネットワーク150に接続されたホスト計算機130上で動作するクエリ登録コマンド実行インタフェース131を介して、ユーザによって定義されたストリームクエリ132を、ストリームデータ処理サーバ100が受取る。すると、ストリームデータ処理部110は、そのクエリ定義に従ってストリームデータ処理を実行可能なクエリグラフを構築する。この後、外部ネットワーク150に接続されたデータ発生器120によって送信されるタプル121を、ストリームデータ処理サーバ100が受取ると、ストリームデータ処理サーバ100は該クエリグラフに従ってこれを処理し、結果タプル141を生成する。この結果タプル141は、ネットワーク150に接続されたデータ受信機140に送信される。ストレージ106は、ストリームデータ処理部110の実行イメージの他、一度受取った前記クエリ132のテキストファイルを保存する。ストリームデータ処理部110は、起動時にストレージ106からこのクエリのファイルをロードし、クエリグラフを構築することも可能である。
図4を用いて、ストリームデータ処理部110の論理構成を説明する。ユーザがストリームクエリ132の登録操作を実行すると、クエリパーサ402が、同クエリ132をクエリグラフ構成情報403に変換する。オペレータ実行順序決定部404は、同構成情報403を処理して、クエリグラフを構成するオペレータ間の実行順序を決定し、オペレータ実行順情報405として出力する。このオペレータ間の実行順序を決定する処理の一実現形態として、特許文献3に記載のアルゴリズムを利用可能である。オペレータ処理コスト算出部406は、該クエリグラフにおける各オペレータの処理時間見積りを計算コストとして算出し、ステージ分割決定部407に入力する。同決定部407は、前記クエリグラフを複数のステージに分割する。
ここでのステージとは、前記のクエリグラフを構成するオペレータ間の実行順序において、連続する一つ以上のオペレータの集合を指す。該クエリグラフにステージ分割結果を付与し、最終的にクエリ実行制御情報408を生成する。図の例では、ステージA、B、C、D、およびEのそれぞれが、{オペレータ1}、{オペレータ2}、{オペレータ3}、{オペレータ4、オペレータ5}および{オペレータ6}の、それぞれのオペレータで構成されている。ステージ分割方法の動作は後述する。以上、クエリ実行制御情報408の生成までが、クエリ登録時の処理となる。
次に、クエリ実行時の動作を説明する。クエリ実行時には、クエリ実行スレッド410〜413が、当該計算機環境における計算リソース数に併せて動作を開始する。本例では、4つのCPUコアが利用可能である環境で、クエリ実行スレッドが4つ起動するケースを想定する。
ここで、本実施例でのストリームデータ多重処理の特徴を述べると、順次到来するタプルの一つ一つに対してデータ処理を実行するスレッドを一つずつバインドして並列に処理を進めるのが特徴である。つまり、複数の計算コアが各々分割されたステージを担当し、順次到来するタプルをその複数コア間で渡していくパイプライン処理とは異なり、一つのタプルについての分割された複数のステージの処理を一つの計算コアが完遂する。このため、タプル入力部450は、入力タプル121を受取ると、タプル通番管理部409に渡す。タプル通番管理部409は、個々のタプルに、1ずつインクリメントする整数の通番を付与して、クエリ実行スレッド410〜413に渡す。同スレッドのうち、実行休止中であるスレッドの一つが、前記タプル121を処理する。
ここでは、タプル121に通番88が付き、スレッド410が同タプルの処理を担当すると仮定する。スレッド410は、この通番88を、ローカルな担当タプル実行状態保持領域420内に、担当タプル通番(図4の符号421)として保持する。また、同タプルの一つ前のタプル、即ち通番87のタプルの処理をスレッド413が担当すると仮定する。
スレッド410は、通番88のタプルについて、ステージAの処理から実行する。その実行に先立って、担当の通番88のタプルの一つ前のタプル、即ちスレッド413が担当する通番87のタプルについて、ステージAの処理が完了しているか否かを確認する。この確認は、ステージA実行済タプル通番フラグ437に格納されている値を、担当通番88と比較することで実現する。本例では、クエリ実行スレッド410〜413の各々は、自らが担当するタプルの各ステージの実行が終了するごとに、クエリ実行状態保持領域430に作られた対応するステージの実行済みタプル通番フラグの値を、担当するタプル(その当該ステージの実行が終了したタプル)の通番から、次の通番に書き換える。スレッド410は、ステージA実行済タプル通番フラグ437の値を確認して、自らが担当するタプルの通番88と一致しない場合、即ち一つ前の通番87のタプルのステージAの処理が完了していない場合には待機する。スレッド413は通番87のタプルについてステージAの処理(即ち、オペレータ1の処理)を完了した段階で、実行済タプル通番フラグ437の値を87から88に変更する。スレッド410によるステージAの実行に先立つ実行済タプル通番フラグ437の確認は、例えば一定周期で繰り返し行い、このフラグ値の変更を認識した段階で、通番88についてのステージAの処理を開始する。
このように、各クエリ実行スレッドが、各ステージの処理を開始する前に、直前のタプルについて、当該ステージの処理が完了しているか否かを、タプル通番フラグ437〜441を介して、クエリ実行スレッド間で確認するプロトコルに従って、多重処理を推進する。ここで、各オペレータ1〜6の実行状態は、クエリ実行状態保持領域430上の、オペレータ実行状態431〜436で管理し、全てのスレッド410〜413で共有するため、このようなプロトコルによる一貫性管理が必要になる。
クエリグラフ中に、時間ウィンドウ演算、遅延演算などの時限発火型のオペレータが存在する場合は、これらオペレータが出力するタプルの処理順序も、併せて考慮する必要がある。例えば、遅延時間を4分とする遅延演算は、タイムスタンプ10:00丁度のタプルを入力したら、その4分後に、そのタプルにタイムスタンプ10:04を付けて出力するオペレータである。即ち、10:00のタプルを入力した時点で、10:04のタプルの出力を予定することになる。その後、10:04まではクエリ実行スレッド410〜413の全てが実行中であり、10:04を若干経過した時刻に、クエリ実行スレッド410が実行休止状態に移行したとする。このとき、クエリ実行スレッド410では、仮に10:04の数マイクロ秒後のタイムスタンプが付いたタプルが入力ストリームに存在していたとしても、遅延演算が予定していたタイムスタンプ10:04のタプルの出力を、先に実行する必要がある。そのため、時限発火オペレータにおいて、次に出力する予定のタプルは、タプル通番管理部409に登録する。タプル通番管理部409は、登録されたタプルと、入力ストリームの先頭のタプルのタイムスタンプを比較して、より過去の方から順に通番を付与して、クエリ実行スレッドに渡す。
次に、図5のフローチャートを用いて、各クエリ実行スレッドの動作を説明する。処理501で、タプル通番管理部409より入力タプルを取得し、処理502で、入力タプルのデータ、および入力タプルに付与されたタプル通番を、担当タプル実行状態保持領域420に格納する。その後、クエリグラフを構成する全ステージについて、処理504〜507を繰り返す。図5のボックス503、508はループ繰り返しを示す。ループの最初の処理504では、実行済タプル通番フラグ437〜441を確認し、当該スレッドが担当するタプルの通番と、値が一致するか否かによって条件分岐する。一致しない場合は、処理504をスピンで繰返し、一致する場合は処理505に進む。
処理505では、実行状態保持領域420に保持しているタプル(群)について、当該ステージに属するオペレータの処理を実行する。処理506では、その結果のタプル(群)を実行状態保持領域420に格納する。ここで、オペレータによっては、一つのタプルを入力して複数のタプルを出力する場合もあるため、実行状態保持領域420で管理されるデータは複数存在し得る。処理507では、担当タプルについて、当該ステージの処理が完了したため、当該ステージのタプル通番フラグを1インクリメントし、次のステージの処理に移る。全てのステージの処理が完了すると、処理509にて、結果タプルをタプル出力部451から出力し、当該担当タプルについての、全クエリグラフの処理を完了する。当該スレッドは再び休止状態に入る。全てのクエリ実行スレッドが、同一のフローに従って動作する。
次に、図6を用いて、ステージ分割決定部407における、ステージの分割方法を説明する。本説明では、図2に示したクエリグラフの例をサンプルとしている。同クエリグラフについて、オペレータ実行順序決定部404が決定するオペレータの実行順序は、OP1〜10の順番になるとする。また、本例では4つの計算コアでのクエリ実行を想定する。まず、クエリグラフの全計算コストを計算コア数で割った値である25に対して、さらにマージンをとった22を、計算コストの閾値とする。前記オペレータ実行順に従って、オペレータの計算コストを加算して行き、前記閾値を超えないようにステージを分割する。
本例では、OP1〜2の計算コストの和が21、OP1〜3の和が24となるため、閾値以下に収まるOP2までを、最初のステージAとする。以降、同様の分割ポリシを適用することで、OP3〜5、OP6〜7、OP8〜9、およびOP10に分けられ、最終的にステージA〜Eの計5ステージ(601〜605)となる。各ステージの計算コストは、それぞれステージA(601)が21、ステージB(602)が18、ステージC(603)が18、ステージD(604)が22、ステージE(605)が21となる。1タプルの処理時間に対する、各ステージの処理時間の割合は610に示す通りである。
ここで、タプル処理時間の1/4の間隔でタプルが到来するケースにおいて、図4に示した構成と、図5に示したフローに従って処理した場合、各タプルは、各計算コアにおいて、タイムチャート611に示すようなスケジュールで処理されることになる。図3のタイムチャート311と異なり、処理の空白期間や待ちは発生しない。詳しく述べると、従来のパイプライン処理によるクエリ処理では、タプルが等間隔で順次到来するという、いわば理想的な入力の状況であっても、図3のタイムチャート311で示したように最も処理時間が長いステージに処理速度が律速され、他のステージをそれぞれ担当する計算コアに処理の空白、つまり無駄時間が生じてしまう。これに対し、本実施例のプロトコルによる処理では、タプルが等間隔で順次到来する入力状態では、図6のタイムチャート611に示すとおり全く空白時間が発生しない。
タプルの到来が不等間隔になった場合に処理待ちが発生するのは、従来のパイプライン処理と本実施例の両者に共通である。但し、図6の実施例のプロトコルにおいて、タプルの到来が不当間隔になった場合に、それにより処理待ちが発生するのは、図6の例では、分割した各ステージの処理コストが図3の例に比べてさほど小さくないからである。先に述べた説明では、全計算コストを計算機コア数4で割った値25に対して計算コストの閾値を22とし、この閾値を超過しない範囲で順次オペレータを統合してステージを決定していた。タプルの到来が不等間隔になったときの空白時間の発生は、この計算コスト閾値の大きさに依存する。全計算コストを計算機コア数で割った値に対するマージンをより大きくし、つまり計算コスト閾値をより小さな値として各計算コアに分担させるステージの分割を細かくし、一つのステージの計算時間を十分小さくとれば、タプルの到来時間がばらつくことによる空白時間の発生は回避可能である。タプルの到来時間のばらつきによる最短到来間隔が分かっていれば、その最短到来間隔よりも各計算コアの分担ステージの処理時間を短くすることで空白時間の発生を完全に回避できる。したがって、本実施例では、タプルが等間隔で順次到来するという限られた条件下のみでなく、到来時間がばらついても、低レイテンシ化、高スループット化の効果が得られる。
本実施例のシステムは、ステージ分割決定部407での計算コア間のステージ分担の決定に用いる計算コスト閾値の設定に関わる係数(コスト閾値決定係数)をユーザに決定させるユーザインタフェースを有する。図7はそのユーザインタフェース画面を示す。ユーザインタフェース画面中の設定領域701には、0より大かつ1.0以下の任意の小数をコスト閾値決定係数として設定可能であり、かつ設定された値が表示される。ステージ分割決定部407は、クエリグラフの全計算コストを計算コア数で割った値に、設定されたコスト閾値決定係数を掛けて計算コスト閾値とする。この計算コスト閾値を超過しない範囲で順次オペレータを統合して、各計算機コアに分担させるステージを決定する。ユーザはストリームデータのタプル到来の状況に応じてコスト閾値決定係数を設定し、これによって各計算コアに分担させるステージ分割の細かさを設定できる。したがって、タプル到来間隔のばらつきの大小に応じたステージ分割が可能であり、実質的に待ちを回避して、各計算コアの計算時間をフルに利用することが可能となる。上記のコスト閾値決定係数を決定させるユーザインタフェースは、ストリーム処理サーバ100のコンソールユニットに実現される。もしくはホスト計算機130に上記ユーザインタフェースを設けても良い。
<変形例1>
上記した実施例では、クエリ実行状態保持領域430に格納されている、各オペレータの実行状態431〜436を、クエリ実行スレッド410〜413間で引き継ぐ際に、CPUコア間のキャッシュコヒーレンス制御のオーバヘッドが、性能劣化要因となる可能性がある。一方、611のタイムチャートでは、連続するタプルの各ステージでの処理の間に、若干の猶予期間がある。そこで変形例1では、それぞれのタプルを担当する計算コアでは、実行中のステージが完了する少し前に、次のステージに属するオペレータの実行状態をその計算コア内のキャッシュにプリフェッチする。例えば、ステージBの処理に関して、計算コア0におけるタプル0についての処理B0の終了後、後続の、計算コア1におけるタプル1についての処理B1が開始するまでには、若干の時間がある。この期間を利用して、実行中のステージの処理を完了する少し前に、次のステージに属するオペレータの実行状態を、計算コアのキャッシュにプリフェッチする。例えば、計算コア1におけるタプル1についてのステージAの処理A1が終了する(即ち、処理B1が開始する)直前に、ステージBに属するオペレータ(OP3〜5)の実行状態をプリフェッチする。
上記した実施例では、クエリ実行状態保持領域430に格納されている、各オペレータの実行状態431〜436を、クエリ実行スレッド410〜413間で引き継ぐ際に、CPUコア間のキャッシュコヒーレンス制御のオーバヘッドが、性能劣化要因となる可能性がある。一方、611のタイムチャートでは、連続するタプルの各ステージでの処理の間に、若干の猶予期間がある。そこで変形例1では、それぞれのタプルを担当する計算コアでは、実行中のステージが完了する少し前に、次のステージに属するオペレータの実行状態をその計算コア内のキャッシュにプリフェッチする。例えば、ステージBの処理に関して、計算コア0におけるタプル0についての処理B0の終了後、後続の、計算コア1におけるタプル1についての処理B1が開始するまでには、若干の時間がある。この期間を利用して、実行中のステージの処理を完了する少し前に、次のステージに属するオペレータの実行状態を、計算コアのキャッシュにプリフェッチする。例えば、計算コア1におけるタプル1についてのステージAの処理A1が終了する(即ち、処理B1が開始する)直前に、ステージBに属するオペレータ(OP3〜5)の実行状態をプリフェッチする。
この変形例1の構成をとることにより、上記の例で計算コア1による処理B1を開始しようとした時点で計算コア1内のキャッシュ上でステージBに属するオペレータの実行状態がダーティのまま残ることが回避される。すなわち、クエリ実行がスレッド間で引き継がれる際のCPU待ちの時間内に行うプリフェッチにより、キャッシュコヒーレンス制御を改めて実施することが回避される。これを有効に行うためには、上記の例でステージBに属するオペレータの実行状態のプリフェッチは、一つ前のタプル0を担当する計算コア0によるステージBの処理B0が完了している可能性が高いタイミングで行うのが良い。とくに、タプルの到来の周期が安定している場合に、次のタプルの到来の予測時刻の直前で先頭のステージAに属するオペレータの実行状態のプリフェッチを行うことが可能であり、キャッシュコヒーレンス制御のオーバヘッド削減の効果を確実に得ることが出来る。
<変形例2>
ストリームデータ処理では、同一タイムスタンプで複数のタプルが到来するようなストリームを処理する場合もある。先の実施例でも問題にしていたタプル到来周期のばらつきが極端に著しい場合であるとも言える。変形例2では、入力ストリームの先頭に、同一タイムスタンプのタプルが連続している場合に、各クエリ実行スレッド410〜413が、当該連続タプルを一括して処理するようにした。
ストリームデータ処理では、同一タイムスタンプで複数のタプルが到来するようなストリームを処理する場合もある。先の実施例でも問題にしていたタプル到来周期のばらつきが極端に著しい場合であるとも言える。変形例2では、入力ストリームの先頭に、同一タイムスタンプのタプルが連続している場合に、各クエリ実行スレッド410〜413が、当該連続タプルを一括して処理するようにした。
この変形例2では、同一のタイムスタンプの複数タプルについて、同じ計算コア内で順次各ステージの処理が行われる。したがって、その計算コア内でキャッシュのヒット率が向上するので、その分だけ1タプル当たりの処理時間の短縮が期待される。ただし、同一タイムスタンプのタプルの数が大きく変動するストリームの場合には各スレッドに分担するタプル数が不揃いになる、つまり処理時間が不揃いになるため、処理の空白や待ちが生じてしまう。同一タイムスタンプのタプルの数が比較的に安定して推移する場合には、処理の空白は軽減され、上記した1タプル当たりの処理時間の短縮によりストリーム処理のスループット向上の効果が得られる。
<変形例3>
上記変形例2で生じる各クエリ実行スレッドの処理時間の不揃いの発生を軽減するため、変形例3ではより詳細な設定を可能する。図8は実施例3の同一計算機コア内の複数タプル一括処理の設定に関するユーザインタフェース画面を示す。ユーザインタフェース画面801の中の設定領域803には一括処理の候補とするタプルと判断するタイムスリット幅の設定値が設定される。領域804には設定領域803への設定のメニューが示されており、チェックマークを入力すると対応する値(図では2.0マイクロセカンド)がタイムスリット幅として設定される。入力ストリームの先頭のタプルに続き、設定されたタイムスリット幅の期間内に後続のタプルが到来したなら、これらタプルは、クエリ実行スレッド410〜413のうち実行停止状態であるいずれか一つが一括して処理するタプルの候補となる。ただし、設定領域805には一括処理をする最大タプル数が設定される。ここでも領域806に示されたメニューのなかから選択された値(図では4)が設定される。この場合には上記期間内に多数のタプルが到来しても一つのスレッドで処理されるタプルの数は4である。なおメニューのなかから「無制限」が選択されて設定された場合には、設定されたタイムスリットの期間内に到来した全てのタプルが一つのスレッドで一括処理される。またメニューのなかから1が選択されて設定された場合には、一括処理のタプル数は1であり、つまり一つのスレッドで連続する複数タプルの一括処理は行わない。
上記変形例2で生じる各クエリ実行スレッドの処理時間の不揃いの発生を軽減するため、変形例3ではより詳細な設定を可能する。図8は実施例3の同一計算機コア内の複数タプル一括処理の設定に関するユーザインタフェース画面を示す。ユーザインタフェース画面801の中の設定領域803には一括処理の候補とするタプルと判断するタイムスリット幅の設定値が設定される。領域804には設定領域803への設定のメニューが示されており、チェックマークを入力すると対応する値(図では2.0マイクロセカンド)がタイムスリット幅として設定される。入力ストリームの先頭のタプルに続き、設定されたタイムスリット幅の期間内に後続のタプルが到来したなら、これらタプルは、クエリ実行スレッド410〜413のうち実行停止状態であるいずれか一つが一括して処理するタプルの候補となる。ただし、設定領域805には一括処理をする最大タプル数が設定される。ここでも領域806に示されたメニューのなかから選択された値(図では4)が設定される。この場合には上記期間内に多数のタプルが到来しても一つのスレッドで処理されるタプルの数は4である。なおメニューのなかから「無制限」が選択されて設定された場合には、設定されたタイムスリットの期間内に到来した全てのタプルが一つのスレッドで一括処理される。またメニューのなかから1が選択されて設定された場合には、一括処理のタプル数は1であり、つまり一つのスレッドで連続する複数タプルの一括処理は行わない。
このように変形例3では連続タプルの一括処理について多様な設定が可能でありユーザが入力ストリームの状況に合わせた柔軟な指定が可能である。このようなユーザインタフェース画面は、ストリームデータ処理サーバ100のコンソールか、ホスト計算機130のいずれかに設けられる。
以上、本発明の実施形態について説明したが、これらは本発明を説明するための例示であり、本発明の適応範囲を例示した形態のみに限定するものではない。また、前述した実施形態のいかなる組み合わせも本発明の実施形態となり得る。
100 ストリームデータ処理サーバ
90〜93 CPU
103 メモリ
104 バス
105 ネットワークインタフェース
106 ストレージ
120 データ発生器
130 ホスト計算機
131 クエリ登録インタフェース
132 ストリームクエリ
140 データ受信器
121、141 タプル
150 ネットワーク
201〜210 オペレータ
301〜304 パイプライン処理におけるステージ
310 パイプライン処理における各ステージの処理時間の比率
601〜605 本発明におけるステージ
610 本発明における各ステージの処理時間の比率
311、611 各計算コアにおける各タプルについての各ステージの処理時間
402 クエリパーサ
403 クエリグラフ構成情報
404 オペレータ実行順序決定部
405 オペレータ実行順情報
406 オペレータ処理コスト算出部
407 ステージ分割決定部
408 クエリ実行制御情報
409 タプル通番管理部
410〜413 クエリ実行スレッド
420 担当タプル実行状態保持領域
430 クエリ実行状態保持領域
431〜436 オペレータ別実行状態
437〜441 ステージ別実行済タプル通番フラグ
450 タプル入力部
451 タプル出力部
501〜509 クエリ実行スレッドのフローチャート
90〜93 CPU
103 メモリ
104 バス
105 ネットワークインタフェース
106 ストレージ
120 データ発生器
130 ホスト計算機
131 クエリ登録インタフェース
132 ストリームクエリ
140 データ受信器
121、141 タプル
150 ネットワーク
201〜210 オペレータ
301〜304 パイプライン処理におけるステージ
310 パイプライン処理における各ステージの処理時間の比率
601〜605 本発明におけるステージ
610 本発明における各ステージの処理時間の比率
311、611 各計算コアにおける各タプルについての各ステージの処理時間
402 クエリパーサ
403 クエリグラフ構成情報
404 オペレータ実行順序決定部
405 オペレータ実行順情報
406 オペレータ処理コスト算出部
407 ステージ分割決定部
408 クエリ実行制御情報
409 タプル通番管理部
410〜413 クエリ実行スレッド
420 担当タプル実行状態保持領域
430 クエリ実行状態保持領域
431〜436 オペレータ別実行状態
437〜441 ステージ別実行済タプル通番フラグ
450 タプル入力部
451 タプル出力部
501〜509 クエリ実行スレッドのフローチャート
Claims (7)
- タイムスタンプが付与されたタプルの系列であるストリームを対象として、ユーザが定義したクエリ定義を、クエリグラフに変換し、前記クエリグラフを構成するオペレータ間の実行順序を決定するクエリパーサを備え、かつ前記クエリグラフを構成するオペレータの集合である複数のステージのいずれをも実行可能にされた複数のクエリ実行スレッドを備えたストリームデータ処理システムによるストリームデータ多重処理方法であって、前記クエリグラフを、各々が連続する複数のオペレータの集合である前記複数のステージに分割し、前記クエリ実行スレッドのうち、実行停止状態にある第1のクエリ実行スレッドが、その時点において前記ストリームの先頭に位置する、第1のタプルを抽出し、前記ストリームにおいて、前記第1のタプルの一つ前に位置していた、第2のタプルについて、前記複数のステージのうちの、最初に実行すべき第1のステージにおける処理が完了しているか否かを確認し、前記処理の完了が確認され次第、前記第1のタプルについて、前記第1のステージの処理を実行し、前記第1のステージの処理が完了次第、前記第2のタプルについて、次に実行すべき第2のステージにおける処理が、完了しているか否かを確認し、処理の完了が確認され次第、前記第1のタプルについて前記第2のステージを実行するという順次処理を、前記第1のクエリ実行スレッドが、前記第1のタプルについて、前記複数ステージの全ての処理が完了するまで継続し、もって前記複数のクエリ実行スレッドが各々抽出したクエリの処理を同時並行で実行することを特徴とするストリームデータ多重処理方法。
- 請求項1に記載のストリームデータ多重処理方法であって、前記クエリグラフを複数のステージに分割する処理は、前記全オペレータの処理コストの合計をクエリ実行スレッド数で割った値以下の値をコスト閾値として設定し、前記オペレータ間の実行順序に従って並べた先頭から、各ステージを構成するオペレータの処理コスト合計が、設定された前記コスト閾値を超過しないように前記クエリグラフを各ステージに分割する手順を含むことを特徴とする、ストリームデータ多重処理方法。
- 請求項2に記載のストリームデータ多重処理方法であって、前記コスト閾値として、前記全オペレータの処理コストの合計をクエリ実行スレッド数で割った値と、0より上かつ1.0以下であってユーザにより選択された係数との積を設定することを特徴とする、ストリームデータ多重処理方法。
- 請求項1に記載のストリームデータ多重処理方法であって、前記クエリグラフが、時間ウィンドウ、遅延オペレータといった、時限発火型のオペレータを含む場合に、前記時限発火型オペレータが生成する、タプルのタイムスタンプと、前記入力ストリームの先頭のタプルのタイムスタンプを比較し、より過去のタイムスタンプを持つタプルから順に処理することを特徴とする、ストリームデータ多重処理方法。
- 請求項1に記載のストリームデータ多重処理方法であって、前記第1のクエリ実行スレッドは、前記第1のステージの処理完了に若干先立って、前記第2のタプルについて、前記第2のステージにおける処理が、完了しているか否かを確認し、前記第2のステージの処理の実行状態等を、キャッシュメモリにプリフェッチすることを特徴とする、ストリームデータ多重処理方法。
- 請求項1に記載のストリームデータ多重処理方法であって、実行停止状態にある前記第1のクエリ実行スレッドは、その時点において前記ストリームの先頭に連続して位置する、同一のタイムスタンプを持つ複数のタプルを抽出し、前記順次処理を、前記第1のクエリ実行スレッドが、前記複数のタプルについて、全てのステージの処理が完了するまで継続する、ことを特徴とする、ストリームデータ多重処理方法。
- 請求項1に記載のストリームデータ多重処理方法であって、実行停止状態にある前記第1のクエリ実行スレッドは、その時点において、前記ストリームの先頭に、ユーザが指定したタイムスタンプ範囲内で連続して位置する、複数のタプルを抽出し、該第1のクエリ実行スレッドが、前記複数のタプルについて、全てのステージの処理が完了するまで前記順次処理を継続することを特徴とする、ストリームデータ多重処理方法。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2012/073568 WO2014041673A1 (ja) | 2012-09-14 | 2012-09-14 | ストリームデータ多重処理方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP5887418B2 true JP5887418B2 (ja) | 2016-03-16 |
JPWO2014041673A1 JPWO2014041673A1 (ja) | 2016-08-12 |
Family
ID=50277826
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014535316A Active JP5887418B2 (ja) | 2012-09-14 | 2012-09-14 | ストリームデータ多重処理方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US9798830B2 (ja) |
JP (1) | JP5887418B2 (ja) |
WO (1) | WO2014041673A1 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20180012691A (ko) * | 2016-07-27 | 2018-02-06 | 웨스턴 디지털 테크놀로지스, 인코포레이티드 | 다중 스트림 저널 리플레이 |
US11467546B2 (en) | 2019-09-04 | 2022-10-11 | Samsung Electronics Co., Ltd. | Semiconductor device and prediction method for resource usage in semiconductor device |
Families Citing this family (68)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9384302B2 (en) | 2013-06-17 | 2016-07-05 | International Business Machines Corporation | Generating differences for tuple attributes |
EP4375833A3 (en) | 2013-12-05 | 2024-07-31 | AB Initio Technology LLC | Managing interfaces for dataflow graphs composed of sub-graphs |
CN103927349B (zh) * | 2014-04-03 | 2018-01-02 | 华中科技大学 | 一种流数据***的负载评估以及过载判定方法 |
US9767217B1 (en) * | 2014-05-28 | 2017-09-19 | Google Inc. | Streaming graph computations in a distributed processing system |
JP6205066B2 (ja) * | 2014-09-04 | 2017-09-27 | 株式会社日立製作所 | ストリームデータ処理方法、ストリームデータ処理装置及び記憶媒体 |
US9948570B2 (en) | 2014-10-27 | 2018-04-17 | Hitachi, Ltd. | Stream data processing method and stream data processing device |
US10657134B2 (en) * | 2015-08-05 | 2020-05-19 | Ab Initio Technology Llc | Selecting queries for execution on a stream of real-time data |
CN106559278B (zh) * | 2015-09-25 | 2020-09-15 | 中兴通讯股份有限公司 | 数据处理状态监控方法和装置 |
US10523724B2 (en) * | 2016-05-10 | 2019-12-31 | International Business Machines Corporation | Dynamic stream operator fission and fusion with platform management hints |
US10552450B2 (en) | 2016-08-05 | 2020-02-04 | International Business Machines Corporation | Distributed graph databases that facilitate streaming data insertion and low latency graph queries |
US11620336B1 (en) | 2016-09-26 | 2023-04-04 | Splunk Inc. | Managing and storing buckets to a remote shared storage system based on a collective bucket size |
US11416528B2 (en) | 2016-09-26 | 2022-08-16 | Splunk Inc. | Query acceleration data store |
US11874691B1 (en) | 2016-09-26 | 2024-01-16 | Splunk Inc. | Managing efficient query execution including mapping of buckets to search nodes |
US11604795B2 (en) | 2016-09-26 | 2023-03-14 | Splunk Inc. | Distributing partial results from an external data system between worker nodes |
US11442935B2 (en) | 2016-09-26 | 2022-09-13 | Splunk Inc. | Determining a record generation estimate of a processing task |
US11106734B1 (en) | 2016-09-26 | 2021-08-31 | Splunk Inc. | Query execution using containerized state-free search nodes in a containerized scalable environment |
US11222066B1 (en) | 2016-09-26 | 2022-01-11 | Splunk Inc. | Processing data using containerized state-free indexing nodes in a containerized scalable environment |
US11663227B2 (en) | 2016-09-26 | 2023-05-30 | Splunk Inc. | Generating a subquery for a distinct data intake and query system |
US11003714B1 (en) | 2016-09-26 | 2021-05-11 | Splunk Inc. | Search node and bucket identification using a search node catalog and a data store catalog |
US11023463B2 (en) | 2016-09-26 | 2021-06-01 | Splunk Inc. | Converting and modifying a subquery for an external data system |
US11314753B2 (en) | 2016-09-26 | 2022-04-26 | Splunk Inc. | Execution of a query received from a data intake and query system |
US11250056B1 (en) | 2016-09-26 | 2022-02-15 | Splunk Inc. | Updating a location marker of an ingestion buffer based on storing buckets in a shared storage system |
US11860940B1 (en) | 2016-09-26 | 2024-01-02 | Splunk Inc. | Identifying buckets for query execution using a catalog of buckets |
US11294941B1 (en) | 2016-09-26 | 2022-04-05 | Splunk Inc. | Message-based data ingestion to a data intake and query system |
US11586627B2 (en) | 2016-09-26 | 2023-02-21 | Splunk Inc. | Partitioning and reducing records at ingest of a worker node |
US11232100B2 (en) | 2016-09-26 | 2022-01-25 | Splunk Inc. | Resource allocation for multiple datasets |
US11562023B1 (en) | 2016-09-26 | 2023-01-24 | Splunk Inc. | Merging buckets in a data intake and query system |
US11567993B1 (en) | 2016-09-26 | 2023-01-31 | Splunk Inc. | Copying buckets from a remote shared storage system to memory associated with a search node for query execution |
US11281706B2 (en) | 2016-09-26 | 2022-03-22 | Splunk Inc. | Multi-layer partition allocation for query execution |
US10984044B1 (en) | 2016-09-26 | 2021-04-20 | Splunk Inc. | Identifying buckets for query execution using a catalog of buckets stored in a remote shared storage system |
US11163758B2 (en) | 2016-09-26 | 2021-11-02 | Splunk Inc. | External dataset capability compensation |
US12013895B2 (en) | 2016-09-26 | 2024-06-18 | Splunk Inc. | Processing data using containerized nodes in a containerized scalable environment |
US11599541B2 (en) | 2016-09-26 | 2023-03-07 | Splunk Inc. | Determining records generated by a processing task of a query |
US11243963B2 (en) | 2016-09-26 | 2022-02-08 | Splunk Inc. | Distributing partial results to worker nodes from an external data system |
US11550847B1 (en) | 2016-09-26 | 2023-01-10 | Splunk Inc. | Hashing bucket identifiers to identify search nodes for efficient query execution |
US11593377B2 (en) | 2016-09-26 | 2023-02-28 | Splunk Inc. | Assigning processing tasks in a data intake and query system |
US11321321B2 (en) | 2016-09-26 | 2022-05-03 | Splunk Inc. | Record expansion and reduction based on a processing task in a data intake and query system |
US11126632B2 (en) | 2016-09-26 | 2021-09-21 | Splunk Inc. | Subquery generation based on search configuration data from an external data system |
US20180089324A1 (en) | 2016-09-26 | 2018-03-29 | Splunk Inc. | Dynamic resource allocation for real-time search |
US10956415B2 (en) | 2016-09-26 | 2021-03-23 | Splunk Inc. | Generating a subquery for an external data system using a configuration file |
US10353965B2 (en) | 2016-09-26 | 2019-07-16 | Splunk Inc. | Data fabric service system architecture |
US11580107B2 (en) | 2016-09-26 | 2023-02-14 | Splunk Inc. | Bucket data distribution for exporting data to worker nodes |
US11269939B1 (en) | 2016-09-26 | 2022-03-08 | Splunk Inc. | Iterative message-based data processing including streaming analytics |
US10834177B2 (en) * | 2017-05-08 | 2020-11-10 | International Business Machines Corporation | System and method for dynamic activation of real-time streaming data overflow paths |
US10644981B2 (en) * | 2017-06-16 | 2020-05-05 | Hewlett Packard Enterprise Development Lp | Scaling processing systems |
US11989194B2 (en) | 2017-07-31 | 2024-05-21 | Splunk Inc. | Addressing memory limits for partition tracking among worker nodes |
US11921672B2 (en) | 2017-07-31 | 2024-03-05 | Splunk Inc. | Query execution at a remote heterogeneous data store of a data fabric service |
US10896182B2 (en) | 2017-09-25 | 2021-01-19 | Splunk Inc. | Multi-partitioning determination for combination operations |
US10860618B2 (en) | 2017-09-25 | 2020-12-08 | Splunk Inc. | Low-latency streaming analytics |
US10997180B2 (en) | 2018-01-31 | 2021-05-04 | Splunk Inc. | Dynamic query processor for streaming and batch queries |
US11334543B1 (en) | 2018-04-30 | 2022-05-17 | Splunk Inc. | Scalable bucket merging for a data intake and query system |
US10733191B2 (en) * | 2018-09-28 | 2020-08-04 | Microsoft Technology Licensing, Llc | Static streaming job startup sequence |
US10776441B1 (en) | 2018-10-01 | 2020-09-15 | Splunk Inc. | Visual programming for iterative publish-subscribe message processing system |
US10775976B1 (en) | 2018-10-01 | 2020-09-15 | Splunk Inc. | Visual previews for programming an iterative publish-subscribe message processing system |
US10761813B1 (en) | 2018-10-01 | 2020-09-01 | Splunk Inc. | Assisted visual programming for iterative publish-subscribe message processing system |
US10936585B1 (en) * | 2018-10-31 | 2021-03-02 | Splunk Inc. | Unified data processing across streaming and indexed data sets |
WO2020220216A1 (en) | 2019-04-29 | 2020-11-05 | Splunk Inc. | Search time estimate in data intake and query system |
US11715051B1 (en) | 2019-04-30 | 2023-08-01 | Splunk Inc. | Service provider instance recommendations using machine-learned classifications and reconciliation |
US11238048B1 (en) | 2019-07-16 | 2022-02-01 | Splunk Inc. | Guided creation interface for streaming data processing pipelines |
US11494380B2 (en) | 2019-10-18 | 2022-11-08 | Splunk Inc. | Management of distributed computing framework components in a data fabric service system |
US11922222B1 (en) | 2020-01-30 | 2024-03-05 | Splunk Inc. | Generating a modified component for a data intake and query system using an isolated execution environment image |
US11614923B2 (en) | 2020-04-30 | 2023-03-28 | Splunk Inc. | Dual textual/graphical programming interfaces for streaming data processing pipelines |
JP2021192189A (ja) | 2020-06-05 | 2021-12-16 | 富士通株式会社 | パイプライン分割位置決定方法及びパイプライン分割位置決定プログラム |
US11704313B1 (en) | 2020-10-19 | 2023-07-18 | Splunk Inc. | Parallel branch operation using intermediary nodes |
US20220245156A1 (en) | 2021-01-29 | 2022-08-04 | Splunk Inc. | Routing data between processing pipelines via a user defined data stream |
US11687487B1 (en) | 2021-03-11 | 2023-06-27 | Splunk Inc. | Text files updates to an active processing pipeline |
US11663219B1 (en) | 2021-04-23 | 2023-05-30 | Splunk Inc. | Determining a set of parameter values for a processing pipeline |
US11989592B1 (en) | 2021-07-30 | 2024-05-21 | Splunk Inc. | Workload coordinator for providing state credentials to processing tasks of a data processing pipeline |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008146503A (ja) * | 2006-12-12 | 2008-06-26 | Sony Computer Entertainment Inc | 分散処理方法、オペレーティングシステムおよびマルチプロセッサシステム |
JP2010108152A (ja) * | 2008-10-29 | 2010-05-13 | Hitachi Ltd | ストリームデータ処理方法、及びそのシステム |
JP2010204880A (ja) * | 2009-03-03 | 2010-09-16 | Hitachi Ltd | ストリームデータ処理方法、ストリームデータ処理プログラム、および、ストリームデータ処理装置 |
JP2011034255A (ja) * | 2009-07-31 | 2011-02-17 | Hitachi Ltd | 計算機システム及び複数計算機によるストリームデータ分散処理方法 |
WO2012046316A1 (ja) * | 2010-10-06 | 2012-04-12 | 株式会社日立製作所 | ストリームデータ処理方法及び装置 |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5212789A (en) * | 1989-10-12 | 1993-05-18 | Bell Communications Research, Inc. | Method and apparatus for updating application databases used in a distributed transaction processing environment |
US6131092A (en) * | 1992-08-07 | 2000-10-10 | Masand; Brij | System and method for identifying matches of query patterns to document text in a document textbase |
US5745746A (en) * | 1996-06-24 | 1998-04-28 | International Business Machines Corporation | Method for localizing execution of subqueries and determining collocation of execution of subqueries in a parallel database |
US6014655A (en) * | 1996-03-13 | 2000-01-11 | Hitachi, Ltd. | Method of retrieving database |
US6081621A (en) * | 1996-10-01 | 2000-06-27 | Canon Kabushiki Kaisha | Positioning templates in optical character recognition systems |
US6094645A (en) * | 1997-11-21 | 2000-07-25 | International Business Machines Corporation | Finding collective baskets and inference rules for internet or intranet mining for large data bases |
US6157923A (en) * | 1998-05-26 | 2000-12-05 | Ensera, Inc. | Query processing based on associated industry codes |
US6915290B2 (en) * | 2001-12-11 | 2005-07-05 | International Business Machines Corporation | Database query optimization apparatus and method that represents queries as graphs |
US7493337B2 (en) * | 2004-03-31 | 2009-02-17 | Microsoft Corporation | Query progress estimation |
JP2010101852A (ja) * | 2008-10-27 | 2010-05-06 | Dainippon Screen Mfg Co Ltd | 水晶振動子製造システム、成膜装置、水晶振動子製造方法および成膜方法 |
US8880493B2 (en) * | 2011-09-28 | 2014-11-04 | Hewlett-Packard Development Company, L.P. | Multi-streams analytics |
-
2012
- 2012-09-14 JP JP2014535316A patent/JP5887418B2/ja active Active
- 2012-09-14 US US14/398,622 patent/US9798830B2/en active Active
- 2012-09-14 WO PCT/JP2012/073568 patent/WO2014041673A1/ja active Application Filing
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008146503A (ja) * | 2006-12-12 | 2008-06-26 | Sony Computer Entertainment Inc | 分散処理方法、オペレーティングシステムおよびマルチプロセッサシステム |
JP2010108152A (ja) * | 2008-10-29 | 2010-05-13 | Hitachi Ltd | ストリームデータ処理方法、及びそのシステム |
JP2010204880A (ja) * | 2009-03-03 | 2010-09-16 | Hitachi Ltd | ストリームデータ処理方法、ストリームデータ処理プログラム、および、ストリームデータ処理装置 |
JP2011034255A (ja) * | 2009-07-31 | 2011-02-17 | Hitachi Ltd | 計算機システム及び複数計算機によるストリームデータ分散処理方法 |
WO2012046316A1 (ja) * | 2010-10-06 | 2012-04-12 | 株式会社日立製作所 | ストリームデータ処理方法及び装置 |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20180012691A (ko) * | 2016-07-27 | 2018-02-06 | 웨스턴 디지털 테크놀로지스, 인코포레이티드 | 다중 스트림 저널 리플레이 |
KR101979088B1 (ko) | 2016-07-27 | 2019-08-28 | 웨스턴 디지털 테크놀로지스, 인코포레이티드 | 다중 스트림 저널 리플레이 |
US10635341B2 (en) | 2016-07-27 | 2020-04-28 | Western Digital Technologies, Inc. | Multi-stream journaled replay |
US11182091B2 (en) | 2016-07-27 | 2021-11-23 | Western Digital Technologies, Inc. | Multi-stream journaled replay |
US11467546B2 (en) | 2019-09-04 | 2022-10-11 | Samsung Electronics Co., Ltd. | Semiconductor device and prediction method for resource usage in semiconductor device |
US11740597B2 (en) | 2019-09-04 | 2023-08-29 | Samsung Electronics Co., Ltd. | Semiconductor device and prediction method for resource usage in semiconductor device |
Also Published As
Publication number | Publication date |
---|---|
JPWO2014041673A1 (ja) | 2016-08-12 |
WO2014041673A1 (ja) | 2014-03-20 |
US20150149507A1 (en) | 2015-05-28 |
US9798830B2 (en) | 2017-10-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP5887418B2 (ja) | ストリームデータ多重処理方法 | |
US10545789B2 (en) | Task scheduling for highly concurrent analytical and transaction workloads | |
US10089142B2 (en) | Dynamic task prioritization for in-memory databases | |
Joao et al. | Utility-based acceleration of multithreaded applications on asymmetric CMPs | |
US8332854B2 (en) | Virtualized thread scheduling for hardware thread optimization based on hardware resource parameter summaries of instruction blocks in execution groups | |
US7487317B1 (en) | Cache-aware scheduling for a chip multithreading processor | |
Phan et al. | An empirical analysis of scheduling techniques for real-time cloud-based data processing | |
US7818747B1 (en) | Cache-aware scheduling for a chip multithreading processor | |
US9244733B2 (en) | Apparatus and method for scheduling kernel execution order | |
US8458136B2 (en) | Scheduling highly parallel jobs having global interdependencies | |
Agrawal et al. | Scheduling parallelizable jobs online to minimize the maximum flow time | |
Suzuki et al. | Real-time ros extension on transparent cpu/gpu coordination mechanism | |
Shao et al. | Stage delay scheduling: Speeding up dag-style data analytics jobs with resource interleaving | |
US20240036921A1 (en) | Cascading of Graph Streaming Processors | |
Wang et al. | Adaptive scheduling of multiprogrammed dynamic-multithreading applications | |
Gottschlag et al. | Mechanism to mitigate avx-induced frequency reduction | |
EP2840513B1 (en) | Dynamic task prioritization for in-memory databases | |
Tang et al. | A network load perception based task scheduler for parallel distributed data processing systems | |
US20210004278A1 (en) | Program execution control method and vehicle control device | |
CN114116015B (zh) | 用于管理硬件命令队列的方法及*** | |
JP2020173622A (ja) | 並列タスクスケジューリング方法 | |
Eyerman et al. | Revisiting symbiotic job scheduling | |
Prokopec | Accelerating by idling: How speculative delays improve performance of message-oriented systems | |
Li et al. | H-pfsp: Efficient hybrid parallel pfsp protected scheduling for mapreduce system | |
De Martini | Analysis of market data with noir: real world application and improvements of a streaming and batch processing framework |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20151221 |
|
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: 20160119 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20160215 |
|
R151 | Written notification of patent or utility model registration |
Ref document number: 5887418 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |