知財求人 - 知財ポータルサイト「IP Force」
▶ ベイジン バイドゥ ネットコム サイエンス アンド テクノロジー カンパニー リミテッドの特許一覧
特許7197620ＤＡＧインタラクションに基づくストリーミングコンピューティング方法及び装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-12-19
(45)【発行日】2022-12-27
(54)【発明の名称】ＤＡＧインタラクションに基づくストリーミングコンピューティング方法及び装置
(51)【国際特許分類】
G06F 9/48 20060101AFI20221220BHJP
【ＦＩ】
G06F9/48 370
【請求項の数】
19
【外国語出願】
(21)【出願番号】P 2021037990
(22)【出願日】2021-03-10
(65)【公開番号】P2022013649
(43)【公開日】2022-01-18
【審査請求日】2021-03-10
(31)【優先権主張番号】202010622403.5
(32)【優先日】2020-06-30
(33)【優先権主張国・地域又は機関】CN
(73)【特許権者】
【識別番号】514322098
【氏名又は名称】ベイジン バイドゥ ネットコム サイエンス テクノロジー カンパニー リミテッド
【氏名又は名称原語表記】Ｂｅｉｊｉｎｇ Ｂａｉｄｕ Ｎｅｔｃｏｍ Ｓｃｉｅｎｃｅ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ．
【住所又は居所原語表記】２／Ｆ Ｂａｉｄｕ Ｃａｍｐｕｓ， Ｎｏ．１０， Ｓｈａｎｇｄｉ １０ｔｈ Ｓｔｒｅｅｔ， Ｈａｉｄｉａｎ Ｄｉｓｔｒｉｃｔ， Ｂｅｉｊｉｎｇ １０００８５， Ｃｈｉｎａ
(74)【代理人】
【識別番号】100118902
【弁理士】
【氏名又は名称】山本 修
(74)【代理人】
【識別番号】100106208
【弁理士】
【氏名又は名称】宮前 徹
(74)【代理人】
【識別番号】100196508
【弁理士】
【氏名又は名称】松尾 淳一
(74)【代理人】
【識別番号】100138759
【弁理士】
【氏名又は名称】大房 直樹
(72)【発明者】
【氏名】ウェイシュー・チェン
(72)【発明者】
【氏名】チン・イェ
【審査官】田中 幸雄
(56)【参考文献】
【文献】中国特許出願公開第１０９７１０２１５（ＣＮ，Ａ）
【文献】中国特許出願公開第１１１３０９７５２（ＣＮ，Ａ）
【文献】中国特許出願公開第１０９７２６２１６（ＣＮ，Ａ）
【文献】岩田吉広ほか，汎用８ｂｉｔマイコンによる音声ナビゲーション，松下テクニカルジャーナル，日本，松下電器産業株式会社，2005年08月18日，第５１巻 第４号，４４－４８ページ
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ ９／４８
(57)【特許請求の範囲】
【請求項1】
有向非巡回グラフＤＡＧインタラクションに基づくストリーミングコンピューティング方法であって、ジョブ生成部によって、第１のタイプのセットに属するＤＡＧノードからなる第１のＤＡＧノードグラフに基づいて、第１のＤＡＧジョブストリーム記述情報を生成するステップと、
ジョブ処理部によって、第１のタイプのセットに属するＤＡＧノードをＦｌｉｎｋエンジンに適した第２のタイプのセットに属するＤＡＧノードに適合させることによって、前記第１のＤＡＧジョブストリーム記述情報を第２のＤＡＧジョブストリーム記述情報に変換するステップと、
ジョブ提出部のｔｗｉｌｌモジュールによって、前記第２のＤＡＧジョブストリーム記述情報を、前記第２のＤＡＧジョブストリーム記述情報と、前記第２のＤＡＧジョブストリーム記述情報内のノードの演算論理とを含むＤＡＧ実行パッケージとしてカプセル化するステップと、
前記ｔｗｉｌｌモジュールによって、ジョブ実行クラスタに前記ＤＡＧ実行パッケージを送信するステップと、を含むストリーミングコンピューティング方法。
【請求項2】
第１のタイプのセットに属する前記ＤＡＧノードは、少なくとも、データソース側ノード、データ変換ノード、データ関連付けノード、データ集約ノード、及びシンクノードを含み、第１のタイプのセットに属するＤＡＧノードをＦｌｉｎｋエンジンに適した第２のタイプのセットに属するＤＡＧノードに適合させる前記ステップは、
第１のタイプのセットに属する前記ＤＡＧノードのうちの異なるタイプのノードをそれぞれ同じデータ構造で対応するＦｌｉｎｋ演算子に適合させるステップを含む請求項１に記載の方法。
【請求項3】
第１のタイプのセットに属する前記ＤＡＧノードのうちのデータソース側ノードを対応するＦｌｉｎｋ演算子に適合させるステップは、前記データソース側ノードの構成情報及び記述情報をロードするステップと、
前記構成情報及び記述情報に基づいてデータソース側ノードオブジェクトを初期化するステップと、
初期化されたノードオブジェクトに基づいて１つのＦｌｉｎｋストリームオブジェクトを割り当てるステップと、を含む請求項２に記載の方法。
【請求項4】
第１のタイプのセットに属する前記ＤＡＧノードのうちのデータ変換ノードを対応するＦｌｉｎｋ演算子に適合させるステップは、前記データ変換ノードの構成情報及び記述情報をロードするステップと、
データ変換論理を持つデータ変換ノードオブジェクトを初期化するステップと、
対応するＦｌｉｎｋ演算子の中に前記データ変換論理をカプセル化するステップと、
前記データ変換ノードのコード論理に従って、前記対応するＦｌｉｎｋ演算子をデータ変換するステップと、
データ変換されたＦｌｉｎｋ演算子を前記データ変換ノードの下流ノードに伝達するステップと、を含む、請求項２又は３に記載の方法。
【請求項5】
第１のタイプのセットに属する前記ＤＡＧノードのうちのデータ関連付けノードを対応するＦｌｉｎｋ演算子に適合させるステップは、前記データ関連付けノードの構成情報及び記述情報をロードするステップと、
データ関連付けノードオブジェクトを初期化するステップと、
前記データ関連付けノードに関連するデータストリームに関連付け操作を行う関連付けキーを見つけるステップと、
前記関連付けキーに従って、データストリーム内のデータをマージすることによりＦｌｉｎｋ演算子を生成するステップと、を含む請求項２又は３に記載の方法。
【請求項6】
第１のタイプのセットに属する前記ＤＡＧノードのうちのデータ集約ノードを対応するＦｌｉｎｋ演算子に適合させるステップは、前記データ集約ノードの構成情報及び記述情報をロードするステップと、
データ集約ノードオブジェクトを初期化するステップと、
前記データ集約ノードに関連するデータストリームに集約操作を行う集約キーを見つけるステップと、
前記集約キーに従って、データストリーム内のデータを集約することによりＦｌｉｎｋ演算子を生成するステップと、を含む、請求項２又は３に記載の方法。
【請求項7】
第１のタイプのセットに属する前記ＤＡＧノードのうちのシンクノードを対応するＦｌｉｎｋ演算子に適合させるステップは、前記シンクノードの構成情報及び記述情報をロードするステップと、
シンクノードオブジェクトを初期化するステップと、
前記シンクノードオブジェクトを実行可能なオブジェクトとしてカプセル化し、スレッドプールに入れるステップと、
ＤＡＧノードのトラバースが完了した後、前記スレッドプール内の前記シンクノードオブジェクトをトリガするステップと、
前記シンクノードオブジェクトにデータを書き込むステップと、を含む請求項２又は３に記載の方法。
【請求項8】
前記第１のＤＡＧジョブストリーム記述情報と前記第２のＤＡＧジョブストリーム記述情報は、ｊｓｏｎ形式を採用する、請求項１に記載の方法。
【請求項9】
前記第１のＤＡＧジョブストリーム記述情報と前記第２のＤＡＧジョブストリーム記述情報は、同じデータのカプセル化を採用する、請求項１に記載の方法。
【請求項10】
ＤＡＧジョブストリームの実行のための指標情報をジョブ実行クラスタから受信し、ｃｏｕｎｔｅｒ及びｇａｕｇｅによって指標計算を行い、計算された指標情報を記憶するステップをさらに含む、請求項１に記載の方法。
【請求項11】
ＤＡＧジョブストリームの実行のための循環情報を述べるメタデータをジョブ実行クラスタから受信して記憶するステップをさらに含む、請求項１に記載の方法。
【請求項12】
前記第１のＤＡＧノードグラフは、第１のタイプのセットに属する前記ＤＡＧノードをユーザがドラッグすることによって形成される、請求項１に記載の方法。
【請求項13】
前記第２のＤＡＧジョブストリーム記述情報内のすべての異なるノードタイプに対して、１つのＤＡＧ実行パッケージのみを生成するステップをさらに含む、請求項１に記載の方法。
【請求項14】
有向非巡回グラフＤＡＧインタラクションに基づくストリーミングコンピューティング装置であって、第１のタイプのセットに属するＤＡＧノードからなる第１のＤＡＧノードグラフに基づいて、第１のＤＡＧジョブストリーム記述情報を生成するように構成されるジョブ生成部と、
第１のタイプのセットに属するＤＡＧノードをＦｌｉｎｋエンジンに適した第２のタイプのセットに属するＤＡＧノードに適合させることによって、前記第１のＤＡＧジョブストリーム記述情報を第２のＤＡＧジョブストリーム記述情報に変換するように構成されるジョブ処理部と、
前記第２のＤＡＧジョブストリーム記述情報を、第２のＤＡＧジョブストリーム記述情報と、第２のＤＡＧジョブストリーム記述情報内のノードの演算理論とを含むＤＡＧ実行パッケージとしてカプセル化し、ジョブ実行クラスタに前記ＤＡＧ実行パッケージを送信するように構成されるｔｗｉｌｌモジュールを備えるジョブ提出部と、
を備えることを特徴とする、ストリーミングコンピューティング装置。
【請求項15】
前記ジョブ実行クラスタは、前記ジョブ提出部に対して遠隔的に配置される、請求項１４に記載の装置。
【請求項16】
前記ジョブ生成部、前記ジョブ処理部、及び前記ジョブ提出部は、メッセージキューを介して互いにデカップリングされる、請求項１４に記載の装置。
【請求項17】
プロセッサと、前記プロセッサによって実行されると、請求項１～１３のいずれかに１項記載の方法を前記プロセッサに実行させる命令を含むプログラムを記憶したメモリと、を備える電子機器。
【請求項18】
電子機器のプロセッサによって実行されると、請求項１～１３のいずれか１項に記載の方法を前記電子機器に実行させる命令を含むプログラムを記憶したコンピュータ読み取り可能な記憶媒体。
【請求項19】
電子機器のプロセッサによって実行されると、請求項１～１３のいずれか１項に記載の方法を前記電子機器に実行させる命令を含むコンピュータ読み取り可能な記憶媒体に記憶されるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、データ処理及びクラウドコンピューティングに関し、具体的には、ＤＡＧインタラクションに基づくストリーミングコンピューティング方法及び装置に関する。
【背景技術】
【0002】
ストリーミングコンピューティングはバッチコンピューティングとは異なるコンピューティング方法であり、大規模な連続データを絶えずに変化している運動過程においてリアルタイムで分析し、有用な情報を抽出し、コンピューティング結果を下流ノードに迅速に伝達することができる。ユーザはバッチ間隔（ｂａｔｃｈ ｉｎｔｅｒｖａｌ）、チェックポイント（ｃｈｅｃｋｐｏｉｎｔ）などの情報を設定することにより、ジョブストリームの実行のためのＤＡＧをドラッグで構成した後、ＳｐａｒｋＳｔｒｅａｍｉｎｇマイクロバッチ（ｍｉｃｒｏｂａｔｃｈ）の思想に従ってＤＡＧグラフを処理し、実行可能なプログラム理論に変換し、次に、コンピューティングクラスタに提出して実行する。さらに、現在のリアルタイムジョブストリームコンピューティングスキームでは、ＤＡＧ内の各ノードは分散管理されており、つまり、各ノードは、ノードによって記述されたフィールド情報によって区別される独自のカプセル化理論を含んでいる。
しかしながら、データ量が増加し、コンピューティング精度やリアルタイム性の要求が高まるにつれ、このような構成では徐々に問題が生じてきている。一方、ＳｐａｒｋＳｔｒｅａｍｉｎｇはストリームをバッチの特例と見なし、時間間隔の底層論理に依存しているので、実際には、ほぼリアルタイムのコンピューティングフレームワークである。一部のストリーミングコンピューティングの業務を解決できるが、データ量が多く、高いリアルタイム性や精度が要求されるコンピューティングシナリオ、たとえばｅｖｅｎｔ ｌｅｖｅｌのシナリオやステートフルコンピューティングシナリオでは、ＳｐａｒｋＳｔｒｅａｍｉｎｇのコンピューティング精度と性能が低下し、また、コンピューティングが複数のマシンに分散し、データ転送に遅延があるシナリオでは、ＳｐａｒｋＳｔｒｅａｍｉｎｇの実行シナリオは顧客の要求を満たすことができない。他方、ＤＡＧの各ノードのプログラムはすべて異なるコンピューティング理論にカプセル化されているので、複雑な業務理論では、ジョブストリーム及びそのノードの初期化と関連するクラスのロードのため、大きなネットワークと時間のオーバーヘッドが発生し、システムの性能に影響を与える。
しかしながら、データ量が増加し、コンピューティング精度やリアルタイム性の要求が高まるにつれ、このような構成では徐々に問題が生じてきている。一方、ＳｐａｒｋＳｔｒｅａｍｉｎｇはストリームをバッチの特例と見なし、時間間隔の底層論理に依存しているので、実際には、ほぼリアルタイムのコンピューティングフレームワークである。一部のストリーミングコンピューティングの業務を解決できるが、データ量が多く、高いリアルタイム性や精度が要求されるコンピューティングシナリオ、たとえばｅｖｅｎｔ ｌｅｖｅｌのシナリオやステートフルコンピューティングシナリオでは、ＳｐａｒｋＳｔｒｅａｍｉｎｇのコンピューティング精度と性能が低下し、また、コンピューティングが複数のマシンに分散し、データ転送に遅延があるシナリオでは、ＳｐａｒｋＳｔｒｅａｍｉｎｇの実行シナリオは顧客の要求を満たすことができない。他方、ＤＡＧの各ノードのプログラムはすべて異なるコンピューティング理論にカプセル化されているので、複雑な業務理論では、ジョブストリーム及びそのノードの初期化と関連するクラスのロードのため、大きなネットワークと時間のオーバーヘッドが発生し、システムの性能に影響を与える。
【発明の概要】
【0003】
本開示の一態様によれば、
第１のタイプのセットに属するＤＡＧノードからなる第１のＤＡＧノードグラフに基づいて、第１のＤＡＧジョブストリーム記述情報を生成するステップと、
第１のタイプのセットに属するＤＡＧノードをＦｌｉｎｋエンジンに適した第２のタイプのセットに属するＤＡＧノードに適合させることによって、前記第１のＤＡＧジョブストリーム記述情報を第２のＤＡＧジョブストリーム記述情報に変換するステップと、
前記第２のＤＡＧジョブストリーム記述情報を、第２のＤＡＧジョブストリーム記述情報と、第２のＤＡＧジョブストリーム記述情報内のノードの演算論理とを含むＤＡＧ実行パッケージとしてカプセル化するステップと、
ジョブ実行クラスタに前記ＤＡＧ実行パッケージを送信するステップと、を含む有向非巡回グラフＤＡＧインタラクションに基づくストリーミングコンピューティング方法を提供する。
本開示の別の態様によれば、
第１のタイプのセットに属するＤＡＧノードからなる第１のＤＡＧノードグラフに基づいて、第１のＤＡＧジョブストリーム記述情報を生成するように構成されるジョブ生成部と、
第１のタイプのセットに属するＤＡＧノードをＦｌｉｎｋエンジンに適した第２のタイプのセットに属するＤＡＧノードに適合させることによって、前記第１のＤＡＧジョブストリーム記述情報を第２のＤＡＧジョブストリーム記述情報に変換するように構成されるジョブ処理部と、
前記第２のＤＡＧジョブストリーム記述情報を、第２のＤＡＧジョブストリーム記述情報と、第２のＤＡＧジョブストリーム記述情報内のノードの演算理論とを含むＤＡＧ実行パッケージとしてカプセル化し、ジョブ実行クラスタに前記ＤＡＧ実行パッケージを送信するように構成されるジョブ提出部と、を備えることを特徴とする、有向非巡回グラフＤＡＧインタラクションに基づくストリーミングコンピューティング装置をさらに提供する。
本開示の別の態様によれば、
プロセッサと、前記プロセッサによって実行されると、上記有向非巡回グラフＤＡＧインタラクションに基づくストリーミングコンピューティング方法を前記プロセッサに実行させる命令を含むプログラムを記憶したメモリと、を備える電子機器をさらに提供する。
本開示の別の態様によれば、
電子機器のプロセッサによって実行されると、上記ストリーミングコンピューティング方法を前記電子機器に実行させる命令を含むプログラムを記憶したコンピュータ読み取り可能な記憶媒体をさらに提供する。
本開示の別の態様によれば、
電子機器のプロセッサによって実行されると、上記ストリーミングコンピューティング方法を前記電子機器に実行させる命令を含むコンピュータ読み取り可能な記憶媒体に記憶されるコンピュータプログラム。
本開示の一態様によれば、有向非巡回グラフＤＡＧインタラクションに基づくストリーミングコンピューティング方法は、ストリーミングコンピューティングの処理効率を改善することができる。
第１のタイプのセットに属するＤＡＧノードからなる第１のＤＡＧノードグラフに基づいて、第１のＤＡＧジョブストリーム記述情報を生成するステップと、
第１のタイプのセットに属するＤＡＧノードをＦｌｉｎｋエンジンに適した第２のタイプのセットに属するＤＡＧノードに適合させることによって、前記第１のＤＡＧジョブストリーム記述情報を第２のＤＡＧジョブストリーム記述情報に変換するステップと、
前記第２のＤＡＧジョブストリーム記述情報を、第２のＤＡＧジョブストリーム記述情報と、第２のＤＡＧジョブストリーム記述情報内のノードの演算論理とを含むＤＡＧ実行パッケージとしてカプセル化するステップと、
ジョブ実行クラスタに前記ＤＡＧ実行パッケージを送信するステップと、を含む有向非巡回グラフＤＡＧインタラクションに基づくストリーミングコンピューティング方法を提供する。
本開示の別の態様によれば、
第１のタイプのセットに属するＤＡＧノードからなる第１のＤＡＧノードグラフに基づいて、第１のＤＡＧジョブストリーム記述情報を生成するように構成されるジョブ生成部と、
第１のタイプのセットに属するＤＡＧノードをＦｌｉｎｋエンジンに適した第２のタイプのセットに属するＤＡＧノードに適合させることによって、前記第１のＤＡＧジョブストリーム記述情報を第２のＤＡＧジョブストリーム記述情報に変換するように構成されるジョブ処理部と、
前記第２のＤＡＧジョブストリーム記述情報を、第２のＤＡＧジョブストリーム記述情報と、第２のＤＡＧジョブストリーム記述情報内のノードの演算理論とを含むＤＡＧ実行パッケージとしてカプセル化し、ジョブ実行クラスタに前記ＤＡＧ実行パッケージを送信するように構成されるジョブ提出部と、を備えることを特徴とする、有向非巡回グラフＤＡＧインタラクションに基づくストリーミングコンピューティング装置をさらに提供する。
本開示の別の態様によれば、
プロセッサと、前記プロセッサによって実行されると、上記有向非巡回グラフＤＡＧインタラクションに基づくストリーミングコンピューティング方法を前記プロセッサに実行させる命令を含むプログラムを記憶したメモリと、を備える電子機器をさらに提供する。
本開示の別の態様によれば、
電子機器のプロセッサによって実行されると、上記ストリーミングコンピューティング方法を前記電子機器に実行させる命令を含むプログラムを記憶したコンピュータ読み取り可能な記憶媒体をさらに提供する。
本開示の別の態様によれば、
電子機器のプロセッサによって実行されると、上記ストリーミングコンピューティング方法を前記電子機器に実行させる命令を含むコンピュータ読み取り可能な記憶媒体に記憶されるコンピュータプログラム。
本開示の一態様によれば、有向非巡回グラフＤＡＧインタラクションに基づくストリーミングコンピューティング方法は、ストリーミングコンピューティングの処理効率を改善することができる。
【図面の簡単な説明】
【0004】
図面は、実施例を例示的に示し、明細書の一部を構成し、明細書の記載と共に実施例の例示的な実施形態を説明する。示される実施例は、例示のみを目的としており、特許請求の範囲を限定するものではない。すべての図面において、同一の符号は、類似するが必ずしも同一ではない要素を指す。
【図1】本開示の実施例による、ＤＡＧインタラクションに基づくストリーミングコンピューティングのための例示的な方法のフローチャートである。
【図2】本開示の実施例による、ＤＡＧインタラクションに基づくストリーミングコンピューティングのための例示的なシステムアーキテクチャである。
【図3A】本開示の実施例による例示的な業務データストリーム図である。
【図3B】本開示の実施例による例示的な業務データストリーム図である。
【図3C】本開示の実施例による例示的な業務データストリーム図である。
【図4】本開示の実施例による、例示的な底層メタデータストリーム図である。
【図5】本開示の実施例による、例示的なジョブ提出段階の動作及びデータストリームの模式図である。
【図6】本開示の実施例による、例示的なジョブ遠隔提出方法のフローチャートである。
【図7】本開示の実施例による、例示的なジョブローカル提出方法のフローチャートである。
【図8】本開示の実施例による、ＤＡＧインタラクションに基づくストリーミングコンピューティングのための装置のブロック図である。
【図9】本開示の実施例による、ＤＡＧインタラクションに基づくストリーミングコンピューティングのための例示的なコンピューティング装置の模式図である。
【発明を実施するための形態】
【0005】
以下では、図面を参照しながら本開示の例示的な実施例を説明するが、この説明には、理解を容易にするために本開示の実施例の様々な詳細が含まれるが、これらは単に例示的なものであると考えるべきである。したがって、当業者が理解できるように、本開示の範囲及び精神を逸脱することなく、ここで記載される実施例に様々な変更及び修正を加えることができる。同様に、以下の説明では、周知の機能及び構造については、明確化及び簡明化のために説明を省略する。
本開示において、特に説明されない限り、「第１」、「第２」等の用語で様々な要素を説明する場合に、これらの要素の位置関係、時系列関係、又は重要性関係を限定することを意図しておらず、このような用語は、１つの要素を別の要素から区別することにのみ使用される。いくつかの例では、第１の要素及び第２の要素は、この要素の同じ実例を指すことができ、いくつかの場合では、文脈の記述から、それらは異なる実例を指すこともできる。文脈によって特に明示的に示されない限り、要素の数が特に限定されない場合、この要素は１つでも複数でもよい。さらに、本開示で使用される用語「及び／又は」は、リストされた項目の任意の１つ及び可能な組み合わせのすべてを包含する。
本開示は、パブリッククラウドシナリオにおける企業向けのフロントエンド可視化プログラミングプラットフォームを対象としており、ユーザ側のゼロコードのソリューションを実現し、大量のデータに対するリアルタイムなストリーミング処理を実現し、分散による影響を低減し、コンピューティング精度を向上させることができる。具体的には、本開示は、有向非巡回グラフ（Ｄｉｒｅｃｔｅｄ Ａｃｙｃｌｉｃ Ｇｒａｐｈ、ＤＡＧ）可視化インタラクションに基づくストリーミングコンピューティング方式に関する。
現在、ストリーミングコンピューティングの主要な処理フレームワークは次のとおりである。
(1)Ｓｔｏｒｍ：Ｔｗｉｔｔｅｒ社のオープンソースの一種の分散型リアルタイムビッグデータ処理フレームワークであり、本当のストリーミング処理であり、低遅延、高スループットのコンピューティング特性があるが、状態管理機能がなく、各データがコンピューティングをトリガするので、コンピューティング性能が制限される。
(2)ＳｐａｒｋＳｔｒｅａｍｉｎｇ：ＳｐａｒｋはＵＣ Ｂｅｒｋｅｌｅｙ ＡＭＰ ｌａｂオープンソースのクラスＨａｄｏｏｐ ＭａｐＲｅｄｕｃｅの汎用並列フレームワークであり、弾性分散データセット（Ｒｅｓｉｌｉｅｎｔ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａｓｅｔｓ、ＲＤＤ）を底層のデータ構造とする。ＳｐａｒｋＳｔｒｅａｍｉｎｇはＳｐａｒｋＲＤＤに基づくストリーミングコンピューティングフレームワークであり、マイクロバッチ（ｍｉｃｒｏ ｂａｔｃｈ）の思想を採用して、アンバウンドデータセットをｂａｔｃｈ ｉｎｔｅｒｖａｌを通じて時間次元でバウンドデータに分割して、それを底層ＲＤＤのコンピューティングに変換するものであり、高性能、高スループットのコンピューティング特徴を持っている。しかしながら、ＳｐａｒｋＳｔｒｅａｍｉｎｇのコンピューティングモデルは依然としてオフラインコンピューティングフレームワークに依存しているため、リアルタイム性能があまり高くない場面もある。
(3)Ｆｌｉｎｋ：Ｆｌｉｎｋは現在ストリーミングコンピューティングで比較的人気のある分散エンジンであり、アンバウンドデータストリームとバウンドデータストリームでステートフルコンピューティングを行うことができる。Ｆｌｉｎｋの技術理念では、データはデフォルトでアンバウンドストリームであるとされているが、ウィンドウを追加することでバウンドストリームのコンピューティングが可能になる。ＦｌｉｎｋはＳｐａｒｋとＳｔｏｒｍのいくつかのコンピューティング特徴に加えて、ｅｖｅｎｔ ｔｉｍｅをサポートしてウィンドウ時間を制御し、順序の乱れた時間でのデータフォールトトレランス処理をサポートし、コンピューティングに関してはｅｘａｃｔｌｙ－ｏｎｃｅセマンティクスを保証し、高性能、高スループット、低遅延の特徴を持っている。Ｆｌｉｎｋのコンピューティングフレームワークは非常に人気があるが、Ｆｌｉｎｋ ＡＰＩを介して開発する過程では、問題抽象化を行う必要があり、その各ステップのコンピューティング理論をＡＰＩを介してＦｌｉｎｋの底層演算子のコンピューティング理論に変換する必要があるので、開発者への要求が高く、コード理論も非常に煩雑であり、開発効率をある程度で低下させる。
具体的には、ストリーミングコンピューティングにおいて、Ｆｌｉｎｋはバッチコンピューティングをストリーミングコンピューティングの特例と見なし、遅延に対するフォールトトレランスとデフォールトメカニズムが内部に存在するため、データ量が大きく、シナリオ分布が複雑なリアルタイムコンピューティングシナリオにより適している。
以下、図１を参照しながら本開示の例示的な方法を説明する。
ステップＳ１１では、ＤＡＧノードグラフに基づいてＤＡＧジョブストリーム記述情報を生成する。ここでは、便宜上、区別のために、ここでのＤＡＧノードグラフを第１のＤＡＧノードグラフと呼び、第１のＤＡＧノードグラフに対して生成されるＤＡＧジョブストリーム記述情報を第１のＤＡＧジョブストリーム記述情報と呼ぶことができる。説明の便宜上、「第１のタイプのセット」という用語は、第１のＤＡＧノードグラフ内のノードが属し得るタイプを含むために使用される。
次に、ステップＳ１２では、第１のタイプのセットに属するＤＡＧノードを、Ｆｌｉｎｋエンジンに適した第２のタイプのセットに属するＤＡＧノードに適合させることによって、前記第１のＤＡＧジョブストリーム記述情報を第２のＤＡＧジョブストリーム記述情報に変換する。第２のＤＡＧジョブストリーム記述情報は、Ｆｌｉｎｋによる実行に適したＤＡＧ情報であるため、第２のタイプのセットに属するＤＡＧノードは、Ｆｌｉｎｋに適したノードタイプとなる。
ステップＳ１３では、第２のＤＡＧジョブストリーム記述情報を、前記第２のＤＡＧジョブストリーム記述情報と、前記第２のＤＡＧジョブストリーム記述情報内のノードの演算理論とを含むＤＡＧ実行パッケージとしてカプセル化する。具体的には、ステップＳ１２で生成されたＦｌｉｎｋに適した第２のジョブストリーム情報をさらに処理して、提出実行用のプログラムパッケージを生成してもよい。前記第２のＤＡＧジョブストリーム記述情報をＤＡＧ実行パッケージとしてカプセル化することにより、提出実行用のプログラムパッケージを生成する手順を実現することができる。
Ｓ１４では、ジョブ実行クラスタにプログラムパッケージを提出する。ストリーミングコンピューティングは、ジョブ実行クラスタで実行できる。
以上の方法のステップにより、ストリーミングコンピューティングの処理効率を効果的に改善することができる。
以下、本開示による例示的な方法のいくつかの変形を説明する。
第１のタイプのセットに属するＤＡＧノードは、少なくともデータソースタイプ（Ｓｏｕｒｃｅ）、データ変換タイプ（Ｔｒａｎｓｆｏｒｍ）、データ分析タイプ（Ａｎａｌｙｔｉｃ）、シンクタイプ（Ｓｉｎｋ）を含む。いくつかの実施例によれば、第１のタイプのセットに属する前記ＤＡＧノードは、少なくともデータソースタイプ、データ変換タイプ、データ関連付けタイプ（Ｊｏｉｎ）ノード、データ集約タイプ（Ａｇｇｒｅｇａｔｏｒ）、及びシンクタイプを含み、データ関連付けタイプノード及びデータ集約タイプノードは、データ分析タイプノードの２つの異なるタイプに属する。以下、図３を参照して、第１のタイプのセットのＤＡＧノードについてより詳細に説明する。
第１のＤＡＧノードグラフは、ＤＡＧノードへのユーザ入力によって形成され得る。具体的には、いくつかの実施例によれば、第１のＤＡＧノードグラフは、第１のタイプのセットに属する前記ＤＡＧノードをユーザがドラッグすることによって形成される。これにより、容易かつ効率的な可視化プログラミングが実現される。このような実施形態では、ユーザは、異なるタイプのＤＡＧノードをドラッグすることによって、ユーザ固有の有向非巡回グラフを形成し、所望の業務理論を達成する。あるいは、ＤＡＧノードグラフに加えて、ユーザによって入力された構成情報も受信される。
ジョブストリーム記述情報は、ＤＡＧノードを記述する。第１のＤＡＧジョブストリーム記述情報は、ジョブストリームのＩＤ、ジョブストリーム名、ジョブストリーム内の各プラグインの詳細な情報等を含む。以下に説明する変換後のジョブストリーム記述情報又は第２のＤＡＧジョブストリーム記述情報には、Ｆｌｉｎｋストリーミングコンピューティングに対する構成も含まれる。ジョブストリーム記述ファイルでは、ＤＡＧノードのタイプによって分類される。異なるタイプのノードはそれぞれの記述情報を持つ。いくつかの実施例によれば、第１のＤＡＧ記述情報はｊｓｏｎ（ＪａｖａＳｃｒｉｐｔ オブジェクト表記法、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）形式を採用することができ、第２のＤＡＧジョブストリーム記述情報はｊｓｏｎ形式を採用することもできる。Ｊｓｏｎは、直観的、簡潔且つ明確な階層構造の利点を持ち、読み取りやすく、書き込みやすく、機械による分析と生成も容易である、軽量データ交換形式である。
いくつかの実施例によれば、前記第１のＤＡＧジョブストリーム記述情報は、前記第２のＤＡＧジョブストリーム記述情報と同じデータカプセル化を採用して、複雑な業務理論の下でフロントエンドとバックエンドの業務理論がデータ情報を共有できるようにし、ＤＡＧ記述情報の完全性及び信頼性を保証する。一実施形態によれば、データはＤａｔａＲｅｃｏｒｄのデータ構造に一元的にカプセル化され、それによってジョブストリーム内のデータ情報を統一することができる。ＤａｔａＲｅｃｏｒｄには、データのタイプ、データのフォーマット、及びデータ内の各フィールドの詳細な情報が含まれ得る。データの記述情報は、ＤａｔａＲｅｃｏｒｄの形式に従って、ＤＡＧ全体の記述情報にシリアライズして書き込むことができる。
第１のＤＡＧ記述情報は、メッセージキューを介して伝達されてもよく、メッセージキューからサブスクライブすることによって第１のＤＡＧ記述情報がロードされてもよい。たとえば、構成情報のロードでは、ＤａｔａＲｅｃｏｒｄ形式のデータ情報をデシリアライズすることにより、データのメタ情報を得ると、データの変換が完了する。あるいは、ジョブストリームデータに加えて、ジョブストリームデータを記述する底層メタデータをロードして解析することができる。あるいは、第２のＤＡＧジョブストリーム記述情報をジョブ提出モジュールに送信することは、メッセージキューを介してＦｌｉｎｋ実行に適したＤＡＧ情報をジョブ提出モジュールに送信することを含むことができる。
生成されたＤＡＧ実行パッケージは、異なるタイプのノードに対する第２のＤＡＧジョブストリーム記述情報及びノードの演算論理を含むことができる。いくつかの実施例では、前記第２のＤＡＧジョブストリーム記述情報内のすべての異なるノードタイプについて、ＤＡＧ実行パッケージが１つだけ生成される。これにより、提出トラフィックが大幅に削減され、遠隔提出方式の実現が容易になる。
ジョブ実行クラスタに提出する上記ステップＳ１４は、提出モジュールに対して遠隔的に配置されたジョブ実行クラスタに提出することを含んでもよいし、提出モジュールに対してローカルに配置されたジョブ実行クラスタに提出することを含んでもよい。ジョブ実行クラスタはｙａｒｎにすることができる。このような場合、ｔｗｉｌｌを使用してプログラムパッケージの提出を管理し、リソースを割り当てることができる。具体的には、前記第２のＤＡＧジョブストリーム記述情報をＤＡＧ実行パッケージとしてカプセル化するステップ、及び／又は前記ＤＡＧ実行パッケージをジョブ実行クラスタに送信するステップは、ｔｗｉｌｌモジュールによって実現され得る。
本開示では、上記したように、ＤＡＧインタラクションに基づくストリーミングコンピューティング方法は、Ｆｌｉｎｋコンピューティングエンジンに基づいて設計され、実装される。全体の設計は、ジョブストリーム実行グラフ生成、解析及び適合のプロセスとジョブのスケジューリング、管理及び実行のプロセスという２つの部分に大別される。ステップＳ１１～Ｓ１２は、ジョブストリーム実行グラフ生成、解析及び適合のプロセスに対応し、ユーザによって生成されたジョブストリーム実行ＤＡＧグラフをバックエンドに伝達する。バックエンドは、生成されたジョブストリーム実行ＤＡＧグラフを解析し、ＤＡＧの各ノードのタイプを用いてＦｌｉｎｋ内の演算子タイプを決定することにより、ジョブストリーム実行ＤＡＧをＦｌｉｎｋ実行ＤＡＧに変換する。ステップＳ１３～Ｓ１４は、ジョブストリーム実行グラフの生成後のジョブのスケジュール実行過程に対応する。さらに、いくつかの実施例では、ジョブのスケジュール実行中に、底層メタデータの記録及び記憶も含まれ、これについては、図４を参照しながら以下で詳細に説明する。いくつかの実施例によれば、底層メタデータを記録して記憶することは、ＤＡＧジョブストリームの実行のための指標情報を収集し、ｃｏｕｎｔｅｒ及びｇａｕｇｅによって指標計算を行い、計算された指標情報を記憶することを含む。これにより、実行指標情報の一元管理が可能となる。指標情報は、ジョブストリーム名又はジョブストリームＩＤに応じて記憶されていてもよい。いくつかの実施例によれば、底層メタデータを記録して記憶することは、ＤＡＧジョブストリームの実行のための循環データメタ情報をジョブ実行クラスタから受信して記憶することをさらに含み、それにより、循環データメタ情報の一元管理を可能にする。
なお、ここでのステップの説明において、メッセージキューは、異なるモジュールの結合の程度を緩和するために追加されるが、本開示はこれに限定されず、本開示の思想は、メッセージキューに依存しない他の一般的なメッセージ及びデータの伝送方法にも適用できる。
図２は、本開示の例示的なシステムアーキテクチャ２００を示す。
図２に示すように、例示的なシステムアーキテクチャは、ステップＳ１１に記載された方法を実行するためのＤＡＧ生成モジュール２１０と、ステップＳ１２に記載された方法を実行するためのＤＡＧ処理モジュール２２０と、ステップＳ１３及びＳ１４に記載された方法を実行するためのジョブ提出モジュール２３０と、ジョブ実行のためのジョブ実行クラスタ２４０と、ＤＡＧ生成モジュール２１０、ＤＡＧ処理モジュール２２０、及びジョブ提出モジュール２３０をデカップリングするためのメッセージキュー２５０と、実行中の指標を任意に計算するための指標収集システム２６０と、実行データなどを永続化するためのデータ記憶システム２７０と、を備える。
モジュールの分割及び命名は、例示的なものに過ぎない。たとえば、ＤＡＧ処理モジュール２２０は、その機能に応じて、ＤＡＧロードモジュール、解析モジュール、及び処理モジュールと呼ばれてもよい。ジョブ提出モジュール２３０は、プログラム提出モジュール又はサービス提出モジュールと呼ばれてもよい。ジョブ提出モジュール２３０及びジョブ実行クラスタ２４０は、プログラム提出実行モジュールとも呼ばれるジョブ提出実行モジュールとして統合されてもよい。ジョブ実行クラスタ２４０は、プログラム実行クラスタ、業務実行クラスタなどと呼ばれてもよい。ジョブ提出モジュール２３０はローカルに配置され得、ジョブ実行クラスタ２４０は遠隔的に配置され得る。代替的に、ジョブ提出モジュール２３０及びジョブ実行クラスタ２４０は、一緒に配置されてもよい。指標収集システム２６０は、指標システム又は指標処理システムと呼ばれてもよい。当業者に理解されるように、ここでのモジュールの分割は、説明の便宜かつ機能的な表現のために過ぎず、アーキテクチャ上の制限ではない。
上記のステップＳ１２において、ＤＡＧ生成モジュール２１０は、第１のＤＡＧ記述情報をメッセージキュー２５０に発行することができる。このような実施例では、ＤＡＧ処理モジュール２２０は、メッセージキュー２５０からトピック（ｔｏｐｉｃ）をサブスクライブすることによって、生成された第１のＤＡＧ記述情報をロードする。
上記のステップＳ１３において、ジョブ提出モジュール２３０は、たとえばメッセージキューからサブスクライブすることによって、生成されたＦｌｉｎｋに適したジョブストリーム情報を取得することができる。ジョブ提出モジュール２３０は、リソースを一元的に管理するためのモジュールを含むことができる。具体的には、ジョブ実行クラスタ２４０がｙａｒｎである場合、リソース管理モジュールは、ｙａｒｎ上でのアプリケーション開発を簡略化するためのプロジェクトＡｐａｃｈｅ Ｔｗｉｌｌであってもよく、以下、ｔｗｉｌｌと呼ぶ。ジョブ提出モジュール２３０は、プログラムをパッケージ化し、その後、パッケージ化されたジョブをｔｗｉｌｌに提出する。ｔｗｉｌｌは、ジョブパッケージを一元的に管理する。たとえば、ｔｗｉｌｌの実行モジュールは、パッケージ化されたプログラムを受信した後、プログラムパッケージを解凍し、構成情報を利用してプログラムが実行される環境を構成し、その後、Ｆｌｉｎｋ ｒｕｎの方式で業務ジョブをクラスタ２４０に提出する。
さらに、図４を参照して以下で詳細に説明するように、底層メタデータに対して、ＤＡＧ処理モジュールはまた、任意選択に、メッセージキュー２５０によって指標情報を指標収集システム２６０に提出する。指標収集システム２６０は、指標情報を計算し、計算された指標をデータ記憶システム２７０に永続化する。ジョブ提出モジュール２３０はまた、ジョブストリームの循環データメタ情報をデータ記憶システム２７０に提出する。さらに、ジョブが実行された後、実行されたログ情報もデータ記憶システム２７０に永続化される。
次に、ＦｌｉｎｋにおけるＤＡＧのジョブストリームのデータ循環について、図３Ａ～３Ｃを参照して説明し、ＤＡＧをトラバースしてＤＡＧノードをＦｌｉｎｋ演算子に適合させてパッケージして設計する過程を具体的に説明する。
図３Ａは、ＤＡＧ記述情報適合過程のフローチャートである。まず、Ｓ３１において、生成されたユーザ側からのＤＡＧノード記述情報を解析する。このステップは、ＤＡＧ処理モジュール２２０によって行うことができる。一実施例によれば、ユーザ側からのＤＡＧは、データソースタイプ（Ｓｏｕｒｃｅ）、データ変換タイプ（Ｔｒａｎｓｆｏｒｍ）、データ分析タイプ（Ａｎａｌｙｔｉｃ）、及びシンクタイプ（Ｓｉｎｋ）の４種類の共通ノードタイプを含む。図３Ｂに示すように、ブロック３１０は、ユーザ側からのＤＡＧノードグラフの一例である。
Ｓ３２では、第１のタイプのセットに属するＤＡＧノードのうちの異なるＤＡＧノードをＦｌｉｎｋ演算子として適合させる。
いくつかの実施例によれば、第１のタイプのセットに属する前記ＤＡＧノードは、データソース側ノード、データ変換ノード、データ関連付けノード、データ集約ノード、及びシンクノードを少なくとも含み、また、第１のタイプのセットに属する前記ＤＡＧノードをＦｌｉｎｋエンジンに適した第２のタイプのセットに属するＤＡＧノードに適合させることは、第１のタイプのセットに属する前記ＤＡＧノードのうちの異なるタイプのノードをそれぞれ同じデータ構造で対応するＦｌｉｎｋ演算子に適合させることを含む。このようなＤＡＧノードタイプのセットは、ユーザフレンドリーで完全なプログラミング理論をカバーしている。
本開示では、上記のノードタイプのＦｌｉｎｋの演算子への適合について設計を行った。図３Ｃは、本実施例による、異なるＤＡＧノードタイプのフロー図を示し、データ関連付けノード、データ集約ノードをまとめてデータ分析タイプノードと呼ぶ。
いくつかの実施例によれば、第１のタイプのセットに属する前記ＤＡＧノード内のデータソース側ノードを対応するＦｌｉｎｋ演算子に適合させるステップは、データソース側ノードについて、データソース側ノードの構成情報及び記述情報をロードするステップと、データソース側ノードオブジェクトを初期化するステップと、１つのＦｌｉｎｋストリームオブジェクトを割り当てるステップと、を含む。これにより、ＤＡＧグラフ内の初期ノードに対して変換及び適合を行った。
ノードの構成情報は、ユーザ入力から取得することができる。ＤＡＧ実行グラフでは、データソース側ノードの数は、ストリーミングコンピューティングにおける初期化ストリームオブジェクトの数を決定する。
いくつかの実施例によれば、第１のタイプのセットに属する前記ＤＡＧノード内のデータ変換ノードを対応するＦｌｉｎｋ演算子に適合させるステップは、前記データ変換ノードの構成情報及び記述情報をロードするステップと、データ変換ノードオブジェクトを初期化するステップと、前記データ変換ノードオブジェクト内のデータ変換理論を対応するＦｌｉｎｋ演算子にカプセル化するステップと、前記データ変換ノードのコード論理に従って、前記対応するＦｌｉｎｋ演算子をデータ変換するステップと、データ変換されたＦｌｉｎｋ演算子を下流ノードに伝達するステップと、を含む。これにより、データ変換ノードの適合理論が実現される。ノードの構成情報は、ユーザ入力から取得することができる。
データ関連付けノード及びデータ集約タイプノードは、データ分析タイプノードの２つの異なるタイプに属する。いくつかの実施例によれば、第１のタイプのセットに属する前記ＤＡＧノード内のデータ関連付けノードを対応するＦｌｉｎｋ演算子に適合させるステップは、前記データ関連付けノードの構成情報及び記述情報をロードするステップと、データ関連付けノードオブジェクトを初期化するステップと、前記データ関連付けノードに関連するデータストリームに関連付け操作を行う関連付けキーを見つけるステップと、前記関連付けキーに従って、データストリーム内のデータをマージするステップと、を含む。これにより、Ｆｌｉｎｋの実行を容易にする、データに対する関連付け理論が実現される。ノードの構成情報は、ユーザ入力から取得することができる。
いくつかの実施例によれば、第１のタイプのセットに属する前記ＤＡＧノード内のデータ集約ノードを対応するＦｌｉｎｋ演算子に適合させるステップは、前記データ集約ノードの構成情報及び記述情報をロードするステップと、データ集約ノードオブジェクトを初期化するステップと、前記データ集約ノードに関連するデータストリームに集約操作を行う集約キーを見つけるステップと、前記集約キーに従って、データストリーム内のデータを集約するステップと、を含む。これにより、Ｆｌｉｎｋの実行を容易にするデータの集約操作の理論が実現される。
ストリーム情報に集約操作を行う集約キーを見つけることはデータストリームが集約される前に行われる。データストリーム内のデータに対する集約は、データストリームが集約された後に行われる。データ集約ノードとＦｌｉｎｋ演算子との適合過程では、ウィンドウ追加の問題も考慮する必要がある。スクロールウィンドウを使用してウィンドウを追加することができる。代わりに、ウィンドウ追加は構成によってロードされる。ノードの構成情報は、ユーザ入力から取得することができる。
シンクノードは、特殊なノードタイプである。シンクノードは、ジョブストリームデータの循環の端末でありながら、メタデータの書き込みポイントである。いくつかの実施例によれば、第１のタイプのセットに属する前記ＤＡＧノード内のシンクノードを対応するＦｌｉｎｋ演算子に適合させるステップは、前記シンクノードの構成情報及び記述情報をロードするステップと、シンクノードオブジェクトを初期化するステップと、前記シンクノードオブジェクトを実行可能なオブジェクトとしてカプセル化し、スレッドプールに入れるステップと、ＤＡＧノードのトラバースが完了した後、前記スレッドプール内の前記シンクノードオブジェクトをトリガするステップと、前記シンクノードオブジェクトにデータを書き込むステップと、を含む。これにより、ジョブストリームデータの端末を設計し、Ｆｌｉｎｋの実行業務データをより完全なものにする。ノードの構成情報は、ユーザ入力から取得することができる。
ステップＳ３３において、上記した適合処理を経て、Ｆｌｉｎｋ演算子のＤＡＧ実行グラフが生成される。図３Ｂに示すように、ブロック３３０は、Ｆｌｉｎｋ演算子に適合された得られたＤＡＧ実行グラフを変換する一例である。便宜上及び区別のために、本明細書では、Ｆｌｉｎｋ演算子に適合されたＤＡＧ実行グラフは、第２のＤＡＧノードグラフとも呼ばれる。第２のＤＡＧノードグラフは、Ｆｌｉｎｋエンジンに適した一般的なＤＡＧノードタイプで構成されている。便宜上及び区別のために、Ｆｌｉｎｋエンジンに適したＤＡＧノードタイプのセットは第２のノードタイプのセットと呼ばれ得る。いくつかの実施例によれば、第２のノードタイプのセットは、データストリーム（ＤａｔａＳｔｒｅａｍ）ノード、スプリット（ｓｐｌｉｔ）ノード、データマッピング（ｍａｐ）ノード、フラットマッピング（ｆｌａｔ ｍａｐ）ノード、単純データストリーム（ＳｉｍｐｌｅＤａｔａＳｔｒｅａｍ）ノード、統合（ｕｎｉｏｎ）ノード、データシンクノードなどを含むことができるが、本開示はこれらに限定されない。第２のノードタイプのセットは、Ｆｌｉｎｋエンジンによる実行に適した様々なノードタイプを含むことができる。
異なるＤＡＧノードからＦｌｉｎｋ演算子への適合過程に加えて、本開示では、底層メタデータの循環と格納について一元的に設計されている。ＦｌｉｎｋにおけるＤＡＧの底層メタデータの循環については、図４を参照して詳細に説明する。
底層メタデータには、ジョブストリーム全体の指標情報及びデータメタ情報が含まれている。底層メタデータは、ｋｅｙ－ｖａｌｕｅ（キー－値、略してｋｖ）として記憶される。ジョブストリームがＦｌｉｎｋ上で計算された後、指標情報及びデータメタ情報の書き込みが行われる．
ジョブ提出モジュール２３０は、ジョブストリームの実行のための指標情報をシリアライズした後、メッセージキュー２５０に発行する。指標情報は、たとえば、各ノードの入出力データ量、ジョブの実行時間、ジョブストリームのエラー情報などの統計情報を含む。
指標収集システム２６０は、メッセージをサブスクライブした後、メッセージの内容を解析し、異なるデータ情報に基づいて指標のコンピューティング方法を決定する。本開示では、Ｃｏｕｎｔｅｒ及びＧａｕｇｅという２つのコンピューティング方法が提供される。ここで、Ｃｏｕｎｔｅｒとは単調増加する指標の合計であり、例としてサービスの要求数、完了したタスク数、エラー発生回数などを表すことができる。Ｇａｕｇｅは、温度やメモリ使用率、又は現在のコンカレント要求の数など、サンプルデータを任意に変更できる指標に使用される離散型の指標測定である。
各指標のコンピューティングが完了した後、指標収集システム２６０は、ジョブストリーム名又はジョブストリームＩＤ、指標名、及びタイムスタンプ情報に基づいて現在の指標のｋｅｙを形成し、指標を上記のｋｖ形式でデータ記憶システム２７０に記憶する。
ジョブストリームの循環データメタ情報については、ジョブストリーム実行クラスタに提出されたジョブストリームプログラムが実行された後、ジョブストリームの循環データメタ情報は、記憶システム２７０に直接保存され、データ名、データＩＤ、及びタイムスタンプが記憶情報のｋｅｙ値を構成する。
以下では、図５を参照して、ジョブストリーム提出段階の実行の詳細な過程及びデータ循環について説明する。上記したように、ジョブストリーム提出システムは、適合後のＤＡＧ実行情報を取得する。いくつかの実施例によれば、ＤＡＧ処理モジュールは、ノード情報をＦｌｉｎｋ演算子に適合させた後、ジョブストリーム実行情報をメッセージキュー２５０に発行し、その後、ジョブ提出モジュール２３０は、メッセージキューからメッセージ関連トピックをサブスクライブすることによって、メッセージキューから実行情報を受信する。他の実施形態では、処理されたＤＡＧ実行情報は、メッセージキューを介せずにＤＡＧ処理モジュール２３０から直接受信されてもよい。
ジョブ提出モジュール２３０は、受信した実行情報を解析し、ストリーミングコンピューティングのプログラムの実行エントリを決定する。
その後、ジョブ提出モジュール２３０は、メインプログラム、ＤＡＧノードプログラムをパッケージ化する。ジョブ提出モジュール２３０は、リソースを一元的に管理するためのモジュールを含むことができる。具体的には、ジョブ実行クラスタ２４０がｙａｒｎである場合、リソース管理モジュールは、ｙａｒｎ上でのアプリケーション開発を簡略化するためのプロジェクトＡｐａｃｈｅ Ｔｗｉｌｌであってもよく、以下、ｔｗｉｌｌと呼ぶ。ジョブ提出モジュールは、ジョブプログラムパッケージ全体をｔｗｉｌｌモジュールに提出し、ｔｗｉｌｌはプログラムパッケージに対してリソース割り当て及びプログラム管理を一元的に行った後、ジョブ実行クラスタに提出することができる。たとえば、ｔｗｉｌｌの実行モジュールは、パッケージ化されたプログラムを受信した後、プログラムパッケージを解凍し、構成情報を利用して、プログラムが実行される環境を構成し、その後、Ｆｌｉｎｋ ｒｕｎの方式で業務ジョブをクラスタ２４０に提出する。
実施例によって、ジョブ実行クラスタは、ジョブ提出モジュールに対してローカル又は遠隔的に配置され得る。提出方法は、ジョブ実行クラスタの配置に応じて異なり、これにつては、図５を参照して以下で詳細に説明する。
具体的には、ＤＡＧ処理モジュールは、ＤＡＧを解析した後、ジョブ実行グラフをメッセージキューに発行する。ジョブ提出モジュールは、関連トピック（ｔｏｐｉｃ）のメッセージをサブスクライブし、解析することによりメッセージ内の有効な実行情報を抽出し、ジョブプログラムをパッケージ化する。各ジョブストリーム理論の要件が異なるため、実行実例が異なり、割り当てられるリソースのサイズも異なり、ジョブストリーム実行の異機種性を考慮して、プログラムパッケージを一元的に管理して実行し、ジョブストリームジョブをクラスタに提出し、プログラム実行を開始し、ここで、プログラム実行の各指標はメッセージキューを介して指標収集システムにより計算された後、記憶システムに永続化される。プログラム内のジョブストリームデータのメタ情報とプログラム実行のログ情報も記憶システムに永続化され、下流の監視データサービスシステムに供する。
従来技術では、ＤＡＧノードが別々に管理され、それぞれ独立したインターフェースを有する方式は一般的に採用されており、各ノードタイプの記述情報が対応するノード実行理論と結合され、ＤＡＧノードタイプに応じて別々にカプセル化されている。このような独立した管理方式は、プログラミングの分業コラボレーションを容易にするが、このような構造では、実行クラスタに提出する際に、ＤＡＧの不統一のために各ＤＡＧノードが独立して提出する必要があり、このため、遠隔提出シナリオでは大きなオーバーヘッド及び遅いプリロード時間が発生する。さらに、Ｊａｖａで開発されたアプリケーションの場合、プログラムクラスロードのメカニズムはＪＶＭの両親委任モデルに依存しており、ジョブストリーム論理が煩雑なシナリオでは、不適切なクラスロード操作がｊａｒパッケージの競合などの問題を引き起こす可能性がある。
この問題を解決するために、限られたＤＡＧノードがコンピューティング過程に参加するため、ＤＡＧインタラクションのストリーミングコンピューティングシナリオにおいて、プログラムの初期化を高速化し、コンピューティング効率を向上させる。
具体的には、本開示の一実施例によれば、Ｆｌｉｎｋエンジンに必要な異なるタイプのノードのノード実行理論は、統一されたクラス依存性を用いて統一されたコードフレームワークの下にカプセル化される。これにより、プログラムパッケージを作成する際に、ノードごとに独立してカプセル化する必要がなく、異なるタイプのノードのジョブストリーム記述情報を、異なるタイプのノードの演算理論とともにカプセル化することができる。このような設計をすることで、ＤＡＧ実行パッケージ又はプログラムパッケージを完全なｊａｒパッケージとしてクラスタに提出することができ、これにより、タスクを遠隔的に提出する場合のパッケージコピー数及びネットワークオーバーヘッドを削減し、プログラムの初期化を高速化し、また、ネットワークのエラー転送により失敗した場合、完全なパッケージを断続的に転送し、アーキテクチャのフォールトトレランスを向上させることができる。
Ｆｌｉｎｋコンピューティングクラスタと提出システムが１つのクラスタにあるかどうか、具体的には、ジョブ実行クラスタ２４０がジョブ提出モジュール２３０に対してローカルにあるかどうかに基づいて、プログラムが受信された後、プログラムは、遠隔提出及びローカル提出の両方の方式で実行クラスタに提出され得る。
次に、図６を参照しながら、一実施例による遠隔提出の具体的なステップを説明する。Ｆｌｉｎｋコンピューティングクラスタと提出モジュールが１つのクラスタにない場合、遠隔提出方式を使用することができる。
ステップＳ６１では、ジョブ提出モジュールは、たとえばメッセージキューからメッセージ関連トピックをサブスクライブすることにより、実行情報に関連するメッセージをメッセージキューから受信する。
ステップＳ６２では、受信したメッセージを解析し、ＤＡＧ実行情報を抽出する。
ステップＳ６３では、抽出されたＤＡＧ実行情報をパッケージ化する。いくつかの実施例によれば、パッケージ化された実行情報は、ｔｗｉｌｌに提出されて一元的に管理される。
ステップＳ６４では、リソースを割り当てる。いくつかの実施例によれば、リソース割り当てステップは、ｔｗｉｌｌによって実行される。いくつかの実施例によれば、ｔｗｉｌｌは、ジョブストリーム理論の複雑さに応じて、ネットワーク環境における最適な実行マシンと、ｙａｒｎ上の実行キューとを選択する。
ステップＳ６５では、プログラム実行環境の初期化を行う。いくつかの実施例によれば、ｔｗｉｌｌモジュールはｓｓｈの方式でプログラムの実行に必要なｊａｒパッケージ、構成情報などをリソース環境にコピーし、プログラムにローカル実行環境を構築する。いくつかの実施例によれば、ＤＡＧの異なるノードは、統一されたコードフレームワークの下にカプセル化されるので、ＤＡＧ実行情報は、１つの完全なｊａｒパッケージとして提出することができる。
ステップＳ６６では、プログラムの提出実行を実現する。いくつかの実施例によれば、ｔｗｉｌｌモジュールはＦｌｉｎｋ ｒｕｎを利用して、ステップＳ６４において選択された、ｙａｒｎ上の対応するキューにジョブストリームプログラムを最終的に提出して実行する。
ステップＳ６７では、実行ログの返信及び記憶を行う。いくつかの実施例によれば、プログラム実行のログ情報は、プログラム実行後、ポート転送の方式でメッセージキューに返信され、メッセージキューを介して最終的に記憶システムに永続化される。
以下、図７を参照しながら、一実施例に係るローカル提出方式の具体的なステップを説明する。Ｆｌｉｎｋコンピューティングクラスタと提出システムが１つのクラスタにある場合、ローカル提出方式を使用することができる。
ステップＳ７１では、ジョブ提出モジュールは、たとえばメッセージキューからメッセージ関連トピックをサブスクライブすることにより、実行情報に関連するメッセージをメッセージキューから受信する。
ステップＳ７２では、受信したメッセージを解析し、ＤＡＧ実行情報を抽出する。
ステップＳ７３では、抽出されたＤＡＧ実行情報をパッケージ化する。
ステップＳ７５では、プログラム実行環境の初期化を行う。一実施形態では、プログラムの実行に必要な構成ファイル、ｊａｒパッケージなどをローカルの一時ディレクトリにダウンロードする。
ステップＳ６６では、プログラムの提出実行を実現する。いくつかの実施例によれば、Ｆｌｉｎｋ ｒｕｎの方式で、プログラムを実行クラスタに提出する。
ステップＳ６７では、実行ログの返信及び記憶を行う。いくつかの実施例によれば、プログラムの実行中に、プログラム実行ログをメッセージキューに発行し、その後、ｋａｆｋａ ｌｏｇ ａｐｐｅｎｄを介してコンソールに送信し、記憶システムに永続化する。
２つのプログラム提出実行メカニズム、特に遠隔提出の実現は、図６及び図７を参照しながら説明されており、使用シナリオを広げ、分散プログラム実行のコストを削減する。
さらに、ｔｗｉｌｌの導入により、プログラムパッケージを一元的に抽象化して管理することができ、複雑なアーキテクチャの場合、ｙａｒｎに直接提出する場合よりも優れている。すなわち、ｔｗｉｌｌモジュールの導入は、プログラムの実行リソースや環境を一元的に管理できる一方で、ｙａｒｎ上で分散プログラムを開発、実行する複雑さを軽減することができる。
図８は、例示的な実施例によるＤＡＧインタラクションに基づくストリーミングコンピューティングのための装置のブロック図を示している。
この例示的な実施例に係るＤＡＧインタラクションに基づくストリーミングコンピューティング装置８００は、ジョブ生成部８０１と、ジョブ処理部８０２と、ジョブ提出部８０３と、を備えることができる。ジョブ生成部８０１は、第１のタイプのセットに属するＤＡＧノードからなる第１のＤＡＧノードグラフに基づいて、第１のＤＡＧジョブストリーム記述情報を生成するように構成され、ジョブ処理部８０２は、第１のタイプのセットに属するＤＡＧノードをＦｌｉｎｋエンジンに適した第２のタイプのセットに属するＤＡＧノードに適合させることによって、前記第１のＤＡＧジョブストリーム記述情報を第２のＤＡＧジョブストリーム記述情報に変換するように構成され、ジョブ提出部は、前記第２のＤＡＧジョブストリーム記述情報を、第２のＤＡＧジョブストリーム記述情報と、第２のＤＡＧジョブストリーム記述情報内のノードの演算理論とを含むＤＡＧ実行パッケージとしてカプセル化し、ジョブ実行クラスタに送信するように構成される。これにより、効率的なストリーミングコンピューティングを実現することができる。
いくつかの実施例では、前記ジョブ実行クラスタは、遠隔提出シナリオを実現するために、前記ジョブ提出部に対して遠隔的に配置される。いくつかの実施例では、ジョブ実行クラスタの負担を軽減するために、前記ジョブ提出部は、ｔｗｉｌｌモジュールをさらに含み、ここで、前記第２のＤＡＧジョブストリーム記述情報をＤＡＧ実行パッケージとしてカプセル化するステップ、及び／又は、前記ＤＡＧ実行パッケージをジョブ実行クラスタに送信するステップは、前記ｔｗｉｌｌモジュールによって行われる。いくつかの実施例では、システムアーキテクチャの多様性を達成するために、前記ジョブ生成部、前記ジョブ処理部、及び前記ジョブ提出部は、メッセージキューを介して互いにデカップリングされる。
なお、図１～７を参照して行った方法ステップの前述説明は、対応する方法ステップを実行する図８の部にも適用できるので、ここでは詳しく説明しない。
本開示の一態様によれば、プロセッサと、前記プロセッサによって実行されると、前記プロセッサに上記のＤＡＧインタラクションに基づくストリーミングコンピューティング方法を実行させる命令を含むプログラムを記憶したメモリと、を備える電子機器をさらに提供する。
本開示の別の態様によれば、電子機器のプロセッサによって実行されると、前記電子機器に上記のＤＡＧインタラクションに基づくストリーミングコンピューティング方法を実行させる命令を含むプログラムを記憶したコンピュータ読み取り可能な記憶媒体をさらに提供する。
図９に示すように、本開示の様々な態様に適用され得る電子機器の一例であるコンピューティング機器２０００がここで説明される。コンピューティング機器２０００は、処理及び／又はコンピューティングを実行するように構成された任意の機械であってもよく、ワークステーション、サーバ、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、携帯情報端末、ロボット、スマートフォン、車載コンピュータ、又はこれらの任意の組み合わせであってもよいが、これらに限定されない。上記のコンピューティング方法は、コンピューティング機器２０００又は類似した機器又はシステムによって全体的に又は少なくとも部分的に実現されてもよい。
コンピューティング機器２０００は、（場合によっては１つ又は複数のインターフェースを介して）バス２００２に接続されている、又はバス２００２と通信している要素を含んでいてもよい。たとえば、コンピューティング機器２０００は、バス２００２、１つ又は複数のプロセッサ２００４、１つ又は複数の入力機器２００６、及び１つ又は複数の出力機器２００８を含むことができる。１つ又は複数のプロセッサ２００４は、任意のタイプのプロセッサであってもよく、１つ又は複数の汎用プロセッサ及び／又は１つ又は複数の専用プロセッサ（たとえば、特殊処理チップ）を含むことができるが、これらに限定されない。入力機器２００６は、コンピューティング機器２０００に情報を入力することができる任意のタイプの機器であってもよく、マウス、キーボード、タッチスクリーン、マイクロフォン、及び／又は遠隔コントローラを含むことができるが、これらに限定されない。出力機器２００８は、情報を表示することができる任意のタイプの機器であってもよく、ディスプレイ、スピーカ、ビデオ／オーディオ出力端子、バイブレータ、及び／又はプリンタを含むことができるが、これらに限定されない。コンピューティング機器２０００は、非一時的記憶機器２０１０を含むか、又は非一時的記憶機器２０１０に接続されてもよく、非一時的記憶機器は、非一時的であり、データを記憶できる任意の記憶機器であってもよく、ディスクドライブ、光学記憶機器、ソリッドステートメモリ、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープ、又は他の任意の磁気媒体、光学ディスク又は任意の他の光学媒体、ＲＯＭ（読み取り専用メモリ）、ＲＡＭ（ランダムアクセスメモリ）、キャッシュメモリ、及び／又は任意の他のメモリチップ又はカートリッジ、及び／又はコンピュータがデータ、命令、及び／又はコードを読み取ることができる任意の他の媒体を含むことができるが、これらに限定されない。非一時的記憶機器２０１０は、インターフェースから取り外し可能である。非一時的記憶機器２０１０は、上記の方法及びステップを実現するためのデータ／プログラム（命令を含む）／コードを有することができる。コンピューティング機器２０００はまた、通信機器２０１２を含むことができる。通信機器２０１２は、外部機器及び／又はネットワークと通信可能な任意のタイプの機器又はシステムであってもよく、モデム、ネットワークカード、赤外線通信機器、無線通信機器、及び／又はチップセット、たとえば、ＢｌｕｅｔｏｏｔｈＴＭ機器、１３０２．１１機器、ＷｉＦｉ機器、ＷｉＭａｘ機器、セルラー通信機器、及び／又は類似のものを含むことができるが、これらに限定されない。
コンピューティング機器２０００はまた、プロセッサ２００４の動作に有用なプログラム（命令を含む）及び／又はデータを記憶することができる任意のタイプのワーキングメモリ２０１４を含んでもよく、ランダムアクセスメモリ及び／又は読み取り専用メモリデバイスを含むことができるが、これらに限定されない。
ソフトウェア要素（プログラム）は、ワーキングメモリ２０１４中に存在してもよく、オペレーティングシステム２０１６、１つ又は複数のアプリケーション２０１８、ドライバ、及び／又は他のデータ及びコードを含むが、これらに限定されない。上記方法及びステップを実行するための命令は、１つ又は複数のアプリケーションプログラム２０１８に含まれてもよく、上記のコンピューティング方法は、１つ又は複数のアプリケーションプログラム２０１８の命令をプロセッサ２００４によって読み込んで実行することによって実現されてもよい。より具体的には、上記のコンピューティング方法において、ステップＳ１０１～ステップＳ１０３は、たとえば、プロセッサ２００４が、ステップＳ１０１～ステップＳ１０３の命令を有するアプリケーションプログラム２０１８を実行することによって実現されてもよい。さらに、上記したコンピューティング方法における他のステップは、たとえば、プロセッサ２００４が、対応するステップにおける命令を実行するアプリケーションプログラム２０１８を実行することによって実現されてもよい。ソフトウェア要素（プログラム）の命令の実行可能コード又はソースコードは、非一時的なコンピュータ読み取り可能な記憶媒体（たとえば、上記の記憶機器２０１０）に記憶されてもよく、実行時にワーキングメモリ２０１４に記憶されてもよい（コンパイル及び／又はインストールされてもよい）。ソフトウェア要素（プログラム）の命令の実行可能コード又はソースコードは、遠隔地からダウンロードすることもできる。
なお、特定の要件に従って様々な変形が可能である。たとえば、特定の要素は、カスタマイズされたハードウェアを使用することもでき、及び／又は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、又はそれらの任意の組み合わせを使用して実現することができる。たとえば、開示された方法及び機器の一部又は全部は、本開示の論理及びアルゴリズムに従って、ハードウェア（たとえば、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）及び／又はプログラマブル・理論・アレイ（ＰＬＡ）を含むプログラマブル論理回路）をアセンブリ言語又はハードウェア・プログラミング言語（たとえば、ＶＥＲＩＬＯＧ、ＶＨＤＬ、Ｃ＋＋）でプログラムすることによって実現され得る。
なお、前述の方法は、サーバ－クライアントモードによって実現されてもよい。たとえば、クライアントは、ユーザによって入力されたデータを受信し、前記データをサーバに送信することができる。クライアントは、ユーザから入力されたデータを受信し、前述の方法の一部の処理を行い、処理によって得られたデータをサーバに送信することも可能である。サーバは、クライアントからデータを受信し、前述方法又は前述方法の他の部分を実行し、実行結果をクライアントに返信することができる。クライアントは、方法の実行結果をサーバから受信し、たとえば出力機器を介してユーザに表示することができる。
また、なお、コンピューティング機器２０００のコンポーネントは、ネットワーク上に分散されてもよい。たとえば、ある処理は１つのプロセッサを用いて実行されてもよいが、同時に他の処理は１つのプロセッサから離れた別のプロセッサによって実行されてもよい。コンピューティングシステム２０００の他のコンポーネントも同様に分散してもよい。このように、コンピューティング機器２０００は、複数の場所で処理を実行する分散コンピューティングシステムとして解釈することができる。たとえば、コンピューティング機器２０００は、クラウドプラットフォームの一部として実現されてもよい。このクラウドプラットフォームは、クラウドのハードウェア（たとえば、サーバ）とソフトウェアリソースの底層機能を抽象化する。リソースは、コンピューティング機器２０００から離れたサーバ上でコンピュータ処理を実行する際に使用されるアプリケーション及び／又はデータを含むことができる。リソースはまた、インターネット及び／又はセルラー又はＷｉ－Ｆｉネットワークなどの加入者ネットワークを介して提供されるサービスを含むことができる。
本開示の実施例の技術案によれば、ストリーミングコンピューティングの効率を向上させ、ユーザエクスペリエンスを向上させることができる。
図面を参照して本開示の実施例又は例を説明したが、上記した方法、システム、及び機器は例示的な実施例又は例にすぎず、本開示の範囲はこれらの実施例又は例によって限定されるのではなく、授権された特許請求の範囲及びそれらの同等の範囲によってのみ限定されることが理解されるべきである。実施例又は例における様々な要素は、省略されてもよく、又はそれらの同等の要素によって置き換えられてもよい。さらに、各ステップは、本開示で説明されているものとは異なる順序で実行されてもよい。さらに、実施例又は例における様々な要素を様々な方法で組み合わせることができる。また、ここで記載された要素の多くは、技術の進化に伴って、本開示の後に現れる同等の要素によって置き換えられ得る。
本開示において、特に説明されない限り、「第１」、「第２」等の用語で様々な要素を説明する場合に、これらの要素の位置関係、時系列関係、又は重要性関係を限定することを意図しておらず、このような用語は、１つの要素を別の要素から区別することにのみ使用される。いくつかの例では、第１の要素及び第２の要素は、この要素の同じ実例を指すことができ、いくつかの場合では、文脈の記述から、それらは異なる実例を指すこともできる。文脈によって特に明示的に示されない限り、要素の数が特に限定されない場合、この要素は１つでも複数でもよい。さらに、本開示で使用される用語「及び／又は」は、リストされた項目の任意の１つ及び可能な組み合わせのすべてを包含する。
本開示は、パブリッククラウドシナリオにおける企業向けのフロントエンド可視化プログラミングプラットフォームを対象としており、ユーザ側のゼロコードのソリューションを実現し、大量のデータに対するリアルタイムなストリーミング処理を実現し、分散による影響を低減し、コンピューティング精度を向上させることができる。具体的には、本開示は、有向非巡回グラフ（Ｄｉｒｅｃｔｅｄ Ａｃｙｃｌｉｃ Ｇｒａｐｈ、ＤＡＧ）可視化インタラクションに基づくストリーミングコンピューティング方式に関する。
現在、ストリーミングコンピューティングの主要な処理フレームワークは次のとおりである。
(1)Ｓｔｏｒｍ：Ｔｗｉｔｔｅｒ社のオープンソースの一種の分散型リアルタイムビッグデータ処理フレームワークであり、本当のストリーミング処理であり、低遅延、高スループットのコンピューティング特性があるが、状態管理機能がなく、各データがコンピューティングをトリガするので、コンピューティング性能が制限される。
(2)ＳｐａｒｋＳｔｒｅａｍｉｎｇ：ＳｐａｒｋはＵＣ Ｂｅｒｋｅｌｅｙ ＡＭＰ ｌａｂオープンソースのクラスＨａｄｏｏｐ ＭａｐＲｅｄｕｃｅの汎用並列フレームワークであり、弾性分散データセット（Ｒｅｓｉｌｉｅｎｔ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａｓｅｔｓ、ＲＤＤ）を底層のデータ構造とする。ＳｐａｒｋＳｔｒｅａｍｉｎｇはＳｐａｒｋＲＤＤに基づくストリーミングコンピューティングフレームワークであり、マイクロバッチ（ｍｉｃｒｏ ｂａｔｃｈ）の思想を採用して、アンバウンドデータセットをｂａｔｃｈ ｉｎｔｅｒｖａｌを通じて時間次元でバウンドデータに分割して、それを底層ＲＤＤのコンピューティングに変換するものであり、高性能、高スループットのコンピューティング特徴を持っている。しかしながら、ＳｐａｒｋＳｔｒｅａｍｉｎｇのコンピューティングモデルは依然としてオフラインコンピューティングフレームワークに依存しているため、リアルタイム性能があまり高くない場面もある。
(3)Ｆｌｉｎｋ：Ｆｌｉｎｋは現在ストリーミングコンピューティングで比較的人気のある分散エンジンであり、アンバウンドデータストリームとバウンドデータストリームでステートフルコンピューティングを行うことができる。Ｆｌｉｎｋの技術理念では、データはデフォルトでアンバウンドストリームであるとされているが、ウィンドウを追加することでバウンドストリームのコンピューティングが可能になる。ＦｌｉｎｋはＳｐａｒｋとＳｔｏｒｍのいくつかのコンピューティング特徴に加えて、ｅｖｅｎｔ ｔｉｍｅをサポートしてウィンドウ時間を制御し、順序の乱れた時間でのデータフォールトトレランス処理をサポートし、コンピューティングに関してはｅｘａｃｔｌｙ－ｏｎｃｅセマンティクスを保証し、高性能、高スループット、低遅延の特徴を持っている。Ｆｌｉｎｋのコンピューティングフレームワークは非常に人気があるが、Ｆｌｉｎｋ ＡＰＩを介して開発する過程では、問題抽象化を行う必要があり、その各ステップのコンピューティング理論をＡＰＩを介してＦｌｉｎｋの底層演算子のコンピューティング理論に変換する必要があるので、開発者への要求が高く、コード理論も非常に煩雑であり、開発効率をある程度で低下させる。
具体的には、ストリーミングコンピューティングにおいて、Ｆｌｉｎｋはバッチコンピューティングをストリーミングコンピューティングの特例と見なし、遅延に対するフォールトトレランスとデフォールトメカニズムが内部に存在するため、データ量が大きく、シナリオ分布が複雑なリアルタイムコンピューティングシナリオにより適している。
以下、図１を参照しながら本開示の例示的な方法を説明する。
ステップＳ１１では、ＤＡＧノードグラフに基づいてＤＡＧジョブストリーム記述情報を生成する。ここでは、便宜上、区別のために、ここでのＤＡＧノードグラフを第１のＤＡＧノードグラフと呼び、第１のＤＡＧノードグラフに対して生成されるＤＡＧジョブストリーム記述情報を第１のＤＡＧジョブストリーム記述情報と呼ぶことができる。説明の便宜上、「第１のタイプのセット」という用語は、第１のＤＡＧノードグラフ内のノードが属し得るタイプを含むために使用される。
次に、ステップＳ１２では、第１のタイプのセットに属するＤＡＧノードを、Ｆｌｉｎｋエンジンに適した第２のタイプのセットに属するＤＡＧノードに適合させることによって、前記第１のＤＡＧジョブストリーム記述情報を第２のＤＡＧジョブストリーム記述情報に変換する。第２のＤＡＧジョブストリーム記述情報は、Ｆｌｉｎｋによる実行に適したＤＡＧ情報であるため、第２のタイプのセットに属するＤＡＧノードは、Ｆｌｉｎｋに適したノードタイプとなる。
ステップＳ１３では、第２のＤＡＧジョブストリーム記述情報を、前記第２のＤＡＧジョブストリーム記述情報と、前記第２のＤＡＧジョブストリーム記述情報内のノードの演算理論とを含むＤＡＧ実行パッケージとしてカプセル化する。具体的には、ステップＳ１２で生成されたＦｌｉｎｋに適した第２のジョブストリーム情報をさらに処理して、提出実行用のプログラムパッケージを生成してもよい。前記第２のＤＡＧジョブストリーム記述情報をＤＡＧ実行パッケージとしてカプセル化することにより、提出実行用のプログラムパッケージを生成する手順を実現することができる。
Ｓ１４では、ジョブ実行クラスタにプログラムパッケージを提出する。ストリーミングコンピューティングは、ジョブ実行クラスタで実行できる。
以上の方法のステップにより、ストリーミングコンピューティングの処理効率を効果的に改善することができる。
以下、本開示による例示的な方法のいくつかの変形を説明する。
第１のタイプのセットに属するＤＡＧノードは、少なくともデータソースタイプ（Ｓｏｕｒｃｅ）、データ変換タイプ（Ｔｒａｎｓｆｏｒｍ）、データ分析タイプ（Ａｎａｌｙｔｉｃ）、シンクタイプ（Ｓｉｎｋ）を含む。いくつかの実施例によれば、第１のタイプのセットに属する前記ＤＡＧノードは、少なくともデータソースタイプ、データ変換タイプ、データ関連付けタイプ（Ｊｏｉｎ）ノード、データ集約タイプ（Ａｇｇｒｅｇａｔｏｒ）、及びシンクタイプを含み、データ関連付けタイプノード及びデータ集約タイプノードは、データ分析タイプノードの２つの異なるタイプに属する。以下、図３を参照して、第１のタイプのセットのＤＡＧノードについてより詳細に説明する。
第１のＤＡＧノードグラフは、ＤＡＧノードへのユーザ入力によって形成され得る。具体的には、いくつかの実施例によれば、第１のＤＡＧノードグラフは、第１のタイプのセットに属する前記ＤＡＧノードをユーザがドラッグすることによって形成される。これにより、容易かつ効率的な可視化プログラミングが実現される。このような実施形態では、ユーザは、異なるタイプのＤＡＧノードをドラッグすることによって、ユーザ固有の有向非巡回グラフを形成し、所望の業務理論を達成する。あるいは、ＤＡＧノードグラフに加えて、ユーザによって入力された構成情報も受信される。
ジョブストリーム記述情報は、ＤＡＧノードを記述する。第１のＤＡＧジョブストリーム記述情報は、ジョブストリームのＩＤ、ジョブストリーム名、ジョブストリーム内の各プラグインの詳細な情報等を含む。以下に説明する変換後のジョブストリーム記述情報又は第２のＤＡＧジョブストリーム記述情報には、Ｆｌｉｎｋストリーミングコンピューティングに対する構成も含まれる。ジョブストリーム記述ファイルでは、ＤＡＧノードのタイプによって分類される。異なるタイプのノードはそれぞれの記述情報を持つ。いくつかの実施例によれば、第１のＤＡＧ記述情報はｊｓｏｎ（ＪａｖａＳｃｒｉｐｔ オブジェクト表記法、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）形式を採用することができ、第２のＤＡＧジョブストリーム記述情報はｊｓｏｎ形式を採用することもできる。Ｊｓｏｎは、直観的、簡潔且つ明確な階層構造の利点を持ち、読み取りやすく、書き込みやすく、機械による分析と生成も容易である、軽量データ交換形式である。
いくつかの実施例によれば、前記第１のＤＡＧジョブストリーム記述情報は、前記第２のＤＡＧジョブストリーム記述情報と同じデータカプセル化を採用して、複雑な業務理論の下でフロントエンドとバックエンドの業務理論がデータ情報を共有できるようにし、ＤＡＧ記述情報の完全性及び信頼性を保証する。一実施形態によれば、データはＤａｔａＲｅｃｏｒｄのデータ構造に一元的にカプセル化され、それによってジョブストリーム内のデータ情報を統一することができる。ＤａｔａＲｅｃｏｒｄには、データのタイプ、データのフォーマット、及びデータ内の各フィールドの詳細な情報が含まれ得る。データの記述情報は、ＤａｔａＲｅｃｏｒｄの形式に従って、ＤＡＧ全体の記述情報にシリアライズして書き込むことができる。
第１のＤＡＧ記述情報は、メッセージキューを介して伝達されてもよく、メッセージキューからサブスクライブすることによって第１のＤＡＧ記述情報がロードされてもよい。たとえば、構成情報のロードでは、ＤａｔａＲｅｃｏｒｄ形式のデータ情報をデシリアライズすることにより、データのメタ情報を得ると、データの変換が完了する。あるいは、ジョブストリームデータに加えて、ジョブストリームデータを記述する底層メタデータをロードして解析することができる。あるいは、第２のＤＡＧジョブストリーム記述情報をジョブ提出モジュールに送信することは、メッセージキューを介してＦｌｉｎｋ実行に適したＤＡＧ情報をジョブ提出モジュールに送信することを含むことができる。
生成されたＤＡＧ実行パッケージは、異なるタイプのノードに対する第２のＤＡＧジョブストリーム記述情報及びノードの演算論理を含むことができる。いくつかの実施例では、前記第２のＤＡＧジョブストリーム記述情報内のすべての異なるノードタイプについて、ＤＡＧ実行パッケージが１つだけ生成される。これにより、提出トラフィックが大幅に削減され、遠隔提出方式の実現が容易になる。
ジョブ実行クラスタに提出する上記ステップＳ１４は、提出モジュールに対して遠隔的に配置されたジョブ実行クラスタに提出することを含んでもよいし、提出モジュールに対してローカルに配置されたジョブ実行クラスタに提出することを含んでもよい。ジョブ実行クラスタはｙａｒｎにすることができる。このような場合、ｔｗｉｌｌを使用してプログラムパッケージの提出を管理し、リソースを割り当てることができる。具体的には、前記第２のＤＡＧジョブストリーム記述情報をＤＡＧ実行パッケージとしてカプセル化するステップ、及び／又は前記ＤＡＧ実行パッケージをジョブ実行クラスタに送信するステップは、ｔｗｉｌｌモジュールによって実現され得る。
本開示では、上記したように、ＤＡＧインタラクションに基づくストリーミングコンピューティング方法は、Ｆｌｉｎｋコンピューティングエンジンに基づいて設計され、実装される。全体の設計は、ジョブストリーム実行グラフ生成、解析及び適合のプロセスとジョブのスケジューリング、管理及び実行のプロセスという２つの部分に大別される。ステップＳ１１～Ｓ１２は、ジョブストリーム実行グラフ生成、解析及び適合のプロセスに対応し、ユーザによって生成されたジョブストリーム実行ＤＡＧグラフをバックエンドに伝達する。バックエンドは、生成されたジョブストリーム実行ＤＡＧグラフを解析し、ＤＡＧの各ノードのタイプを用いてＦｌｉｎｋ内の演算子タイプを決定することにより、ジョブストリーム実行ＤＡＧをＦｌｉｎｋ実行ＤＡＧに変換する。ステップＳ１３～Ｓ１４は、ジョブストリーム実行グラフの生成後のジョブのスケジュール実行過程に対応する。さらに、いくつかの実施例では、ジョブのスケジュール実行中に、底層メタデータの記録及び記憶も含まれ、これについては、図４を参照しながら以下で詳細に説明する。いくつかの実施例によれば、底層メタデータを記録して記憶することは、ＤＡＧジョブストリームの実行のための指標情報を収集し、ｃｏｕｎｔｅｒ及びｇａｕｇｅによって指標計算を行い、計算された指標情報を記憶することを含む。これにより、実行指標情報の一元管理が可能となる。指標情報は、ジョブストリーム名又はジョブストリームＩＤに応じて記憶されていてもよい。いくつかの実施例によれば、底層メタデータを記録して記憶することは、ＤＡＧジョブストリームの実行のための循環データメタ情報をジョブ実行クラスタから受信して記憶することをさらに含み、それにより、循環データメタ情報の一元管理を可能にする。
なお、ここでのステップの説明において、メッセージキューは、異なるモジュールの結合の程度を緩和するために追加されるが、本開示はこれに限定されず、本開示の思想は、メッセージキューに依存しない他の一般的なメッセージ及びデータの伝送方法にも適用できる。
図２は、本開示の例示的なシステムアーキテクチャ２００を示す。
図２に示すように、例示的なシステムアーキテクチャは、ステップＳ１１に記載された方法を実行するためのＤＡＧ生成モジュール２１０と、ステップＳ１２に記載された方法を実行するためのＤＡＧ処理モジュール２２０と、ステップＳ１３及びＳ１４に記載された方法を実行するためのジョブ提出モジュール２３０と、ジョブ実行のためのジョブ実行クラスタ２４０と、ＤＡＧ生成モジュール２１０、ＤＡＧ処理モジュール２２０、及びジョブ提出モジュール２３０をデカップリングするためのメッセージキュー２５０と、実行中の指標を任意に計算するための指標収集システム２６０と、実行データなどを永続化するためのデータ記憶システム２７０と、を備える。
モジュールの分割及び命名は、例示的なものに過ぎない。たとえば、ＤＡＧ処理モジュール２２０は、その機能に応じて、ＤＡＧロードモジュール、解析モジュール、及び処理モジュールと呼ばれてもよい。ジョブ提出モジュール２３０は、プログラム提出モジュール又はサービス提出モジュールと呼ばれてもよい。ジョブ提出モジュール２３０及びジョブ実行クラスタ２４０は、プログラム提出実行モジュールとも呼ばれるジョブ提出実行モジュールとして統合されてもよい。ジョブ実行クラスタ２４０は、プログラム実行クラスタ、業務実行クラスタなどと呼ばれてもよい。ジョブ提出モジュール２３０はローカルに配置され得、ジョブ実行クラスタ２４０は遠隔的に配置され得る。代替的に、ジョブ提出モジュール２３０及びジョブ実行クラスタ２４０は、一緒に配置されてもよい。指標収集システム２６０は、指標システム又は指標処理システムと呼ばれてもよい。当業者に理解されるように、ここでのモジュールの分割は、説明の便宜かつ機能的な表現のために過ぎず、アーキテクチャ上の制限ではない。
上記のステップＳ１２において、ＤＡＧ生成モジュール２１０は、第１のＤＡＧ記述情報をメッセージキュー２５０に発行することができる。このような実施例では、ＤＡＧ処理モジュール２２０は、メッセージキュー２５０からトピック（ｔｏｐｉｃ）をサブスクライブすることによって、生成された第１のＤＡＧ記述情報をロードする。
上記のステップＳ１３において、ジョブ提出モジュール２３０は、たとえばメッセージキューからサブスクライブすることによって、生成されたＦｌｉｎｋに適したジョブストリーム情報を取得することができる。ジョブ提出モジュール２３０は、リソースを一元的に管理するためのモジュールを含むことができる。具体的には、ジョブ実行クラスタ２４０がｙａｒｎである場合、リソース管理モジュールは、ｙａｒｎ上でのアプリケーション開発を簡略化するためのプロジェクトＡｐａｃｈｅ Ｔｗｉｌｌであってもよく、以下、ｔｗｉｌｌと呼ぶ。ジョブ提出モジュール２３０は、プログラムをパッケージ化し、その後、パッケージ化されたジョブをｔｗｉｌｌに提出する。ｔｗｉｌｌは、ジョブパッケージを一元的に管理する。たとえば、ｔｗｉｌｌの実行モジュールは、パッケージ化されたプログラムを受信した後、プログラムパッケージを解凍し、構成情報を利用してプログラムが実行される環境を構成し、その後、Ｆｌｉｎｋ ｒｕｎの方式で業務ジョブをクラスタ２４０に提出する。
さらに、図４を参照して以下で詳細に説明するように、底層メタデータに対して、ＤＡＧ処理モジュールはまた、任意選択に、メッセージキュー２５０によって指標情報を指標収集システム２６０に提出する。指標収集システム２６０は、指標情報を計算し、計算された指標をデータ記憶システム２７０に永続化する。ジョブ提出モジュール２３０はまた、ジョブストリームの循環データメタ情報をデータ記憶システム２７０に提出する。さらに、ジョブが実行された後、実行されたログ情報もデータ記憶システム２７０に永続化される。
次に、ＦｌｉｎｋにおけるＤＡＧのジョブストリームのデータ循環について、図３Ａ～３Ｃを参照して説明し、ＤＡＧをトラバースしてＤＡＧノードをＦｌｉｎｋ演算子に適合させてパッケージして設計する過程を具体的に説明する。
図３Ａは、ＤＡＧ記述情報適合過程のフローチャートである。まず、Ｓ３１において、生成されたユーザ側からのＤＡＧノード記述情報を解析する。このステップは、ＤＡＧ処理モジュール２２０によって行うことができる。一実施例によれば、ユーザ側からのＤＡＧは、データソースタイプ（Ｓｏｕｒｃｅ）、データ変換タイプ（Ｔｒａｎｓｆｏｒｍ）、データ分析タイプ（Ａｎａｌｙｔｉｃ）、及びシンクタイプ（Ｓｉｎｋ）の４種類の共通ノードタイプを含む。図３Ｂに示すように、ブロック３１０は、ユーザ側からのＤＡＧノードグラフの一例である。
Ｓ３２では、第１のタイプのセットに属するＤＡＧノードのうちの異なるＤＡＧノードをＦｌｉｎｋ演算子として適合させる。
いくつかの実施例によれば、第１のタイプのセットに属する前記ＤＡＧノードは、データソース側ノード、データ変換ノード、データ関連付けノード、データ集約ノード、及びシンクノードを少なくとも含み、また、第１のタイプのセットに属する前記ＤＡＧノードをＦｌｉｎｋエンジンに適した第２のタイプのセットに属するＤＡＧノードに適合させることは、第１のタイプのセットに属する前記ＤＡＧノードのうちの異なるタイプのノードをそれぞれ同じデータ構造で対応するＦｌｉｎｋ演算子に適合させることを含む。このようなＤＡＧノードタイプのセットは、ユーザフレンドリーで完全なプログラミング理論をカバーしている。
本開示では、上記のノードタイプのＦｌｉｎｋの演算子への適合について設計を行った。図３Ｃは、本実施例による、異なるＤＡＧノードタイプのフロー図を示し、データ関連付けノード、データ集約ノードをまとめてデータ分析タイプノードと呼ぶ。
いくつかの実施例によれば、第１のタイプのセットに属する前記ＤＡＧノード内のデータソース側ノードを対応するＦｌｉｎｋ演算子に適合させるステップは、データソース側ノードについて、データソース側ノードの構成情報及び記述情報をロードするステップと、データソース側ノードオブジェクトを初期化するステップと、１つのＦｌｉｎｋストリームオブジェクトを割り当てるステップと、を含む。これにより、ＤＡＧグラフ内の初期ノードに対して変換及び適合を行った。
ノードの構成情報は、ユーザ入力から取得することができる。ＤＡＧ実行グラフでは、データソース側ノードの数は、ストリーミングコンピューティングにおける初期化ストリームオブジェクトの数を決定する。
いくつかの実施例によれば、第１のタイプのセットに属する前記ＤＡＧノード内のデータ変換ノードを対応するＦｌｉｎｋ演算子に適合させるステップは、前記データ変換ノードの構成情報及び記述情報をロードするステップと、データ変換ノードオブジェクトを初期化するステップと、前記データ変換ノードオブジェクト内のデータ変換理論を対応するＦｌｉｎｋ演算子にカプセル化するステップと、前記データ変換ノードのコード論理に従って、前記対応するＦｌｉｎｋ演算子をデータ変換するステップと、データ変換されたＦｌｉｎｋ演算子を下流ノードに伝達するステップと、を含む。これにより、データ変換ノードの適合理論が実現される。ノードの構成情報は、ユーザ入力から取得することができる。
データ関連付けノード及びデータ集約タイプノードは、データ分析タイプノードの２つの異なるタイプに属する。いくつかの実施例によれば、第１のタイプのセットに属する前記ＤＡＧノード内のデータ関連付けノードを対応するＦｌｉｎｋ演算子に適合させるステップは、前記データ関連付けノードの構成情報及び記述情報をロードするステップと、データ関連付けノードオブジェクトを初期化するステップと、前記データ関連付けノードに関連するデータストリームに関連付け操作を行う関連付けキーを見つけるステップと、前記関連付けキーに従って、データストリーム内のデータをマージするステップと、を含む。これにより、Ｆｌｉｎｋの実行を容易にする、データに対する関連付け理論が実現される。ノードの構成情報は、ユーザ入力から取得することができる。
いくつかの実施例によれば、第１のタイプのセットに属する前記ＤＡＧノード内のデータ集約ノードを対応するＦｌｉｎｋ演算子に適合させるステップは、前記データ集約ノードの構成情報及び記述情報をロードするステップと、データ集約ノードオブジェクトを初期化するステップと、前記データ集約ノードに関連するデータストリームに集約操作を行う集約キーを見つけるステップと、前記集約キーに従って、データストリーム内のデータを集約するステップと、を含む。これにより、Ｆｌｉｎｋの実行を容易にするデータの集約操作の理論が実現される。
ストリーム情報に集約操作を行う集約キーを見つけることはデータストリームが集約される前に行われる。データストリーム内のデータに対する集約は、データストリームが集約された後に行われる。データ集約ノードとＦｌｉｎｋ演算子との適合過程では、ウィンドウ追加の問題も考慮する必要がある。スクロールウィンドウを使用してウィンドウを追加することができる。代わりに、ウィンドウ追加は構成によってロードされる。ノードの構成情報は、ユーザ入力から取得することができる。
シンクノードは、特殊なノードタイプである。シンクノードは、ジョブストリームデータの循環の端末でありながら、メタデータの書き込みポイントである。いくつかの実施例によれば、第１のタイプのセットに属する前記ＤＡＧノード内のシンクノードを対応するＦｌｉｎｋ演算子に適合させるステップは、前記シンクノードの構成情報及び記述情報をロードするステップと、シンクノードオブジェクトを初期化するステップと、前記シンクノードオブジェクトを実行可能なオブジェクトとしてカプセル化し、スレッドプールに入れるステップと、ＤＡＧノードのトラバースが完了した後、前記スレッドプール内の前記シンクノードオブジェクトをトリガするステップと、前記シンクノードオブジェクトにデータを書き込むステップと、を含む。これにより、ジョブストリームデータの端末を設計し、Ｆｌｉｎｋの実行業務データをより完全なものにする。ノードの構成情報は、ユーザ入力から取得することができる。
ステップＳ３３において、上記した適合処理を経て、Ｆｌｉｎｋ演算子のＤＡＧ実行グラフが生成される。図３Ｂに示すように、ブロック３３０は、Ｆｌｉｎｋ演算子に適合された得られたＤＡＧ実行グラフを変換する一例である。便宜上及び区別のために、本明細書では、Ｆｌｉｎｋ演算子に適合されたＤＡＧ実行グラフは、第２のＤＡＧノードグラフとも呼ばれる。第２のＤＡＧノードグラフは、Ｆｌｉｎｋエンジンに適した一般的なＤＡＧノードタイプで構成されている。便宜上及び区別のために、Ｆｌｉｎｋエンジンに適したＤＡＧノードタイプのセットは第２のノードタイプのセットと呼ばれ得る。いくつかの実施例によれば、第２のノードタイプのセットは、データストリーム（ＤａｔａＳｔｒｅａｍ）ノード、スプリット（ｓｐｌｉｔ）ノード、データマッピング（ｍａｐ）ノード、フラットマッピング（ｆｌａｔ ｍａｐ）ノード、単純データストリーム（ＳｉｍｐｌｅＤａｔａＳｔｒｅａｍ）ノード、統合（ｕｎｉｏｎ）ノード、データシンクノードなどを含むことができるが、本開示はこれらに限定されない。第２のノードタイプのセットは、Ｆｌｉｎｋエンジンによる実行に適した様々なノードタイプを含むことができる。
異なるＤＡＧノードからＦｌｉｎｋ演算子への適合過程に加えて、本開示では、底層メタデータの循環と格納について一元的に設計されている。ＦｌｉｎｋにおけるＤＡＧの底層メタデータの循環については、図４を参照して詳細に説明する。
底層メタデータには、ジョブストリーム全体の指標情報及びデータメタ情報が含まれている。底層メタデータは、ｋｅｙ－ｖａｌｕｅ（キー－値、略してｋｖ）として記憶される。ジョブストリームがＦｌｉｎｋ上で計算された後、指標情報及びデータメタ情報の書き込みが行われる．
ジョブ提出モジュール２３０は、ジョブストリームの実行のための指標情報をシリアライズした後、メッセージキュー２５０に発行する。指標情報は、たとえば、各ノードの入出力データ量、ジョブの実行時間、ジョブストリームのエラー情報などの統計情報を含む。
指標収集システム２６０は、メッセージをサブスクライブした後、メッセージの内容を解析し、異なるデータ情報に基づいて指標のコンピューティング方法を決定する。本開示では、Ｃｏｕｎｔｅｒ及びＧａｕｇｅという２つのコンピューティング方法が提供される。ここで、Ｃｏｕｎｔｅｒとは単調増加する指標の合計であり、例としてサービスの要求数、完了したタスク数、エラー発生回数などを表すことができる。Ｇａｕｇｅは、温度やメモリ使用率、又は現在のコンカレント要求の数など、サンプルデータを任意に変更できる指標に使用される離散型の指標測定である。
各指標のコンピューティングが完了した後、指標収集システム２６０は、ジョブストリーム名又はジョブストリームＩＤ、指標名、及びタイムスタンプ情報に基づいて現在の指標のｋｅｙを形成し、指標を上記のｋｖ形式でデータ記憶システム２７０に記憶する。
ジョブストリームの循環データメタ情報については、ジョブストリーム実行クラスタに提出されたジョブストリームプログラムが実行された後、ジョブストリームの循環データメタ情報は、記憶システム２７０に直接保存され、データ名、データＩＤ、及びタイムスタンプが記憶情報のｋｅｙ値を構成する。
以下では、図５を参照して、ジョブストリーム提出段階の実行の詳細な過程及びデータ循環について説明する。上記したように、ジョブストリーム提出システムは、適合後のＤＡＧ実行情報を取得する。いくつかの実施例によれば、ＤＡＧ処理モジュールは、ノード情報をＦｌｉｎｋ演算子に適合させた後、ジョブストリーム実行情報をメッセージキュー２５０に発行し、その後、ジョブ提出モジュール２３０は、メッセージキューからメッセージ関連トピックをサブスクライブすることによって、メッセージキューから実行情報を受信する。他の実施形態では、処理されたＤＡＧ実行情報は、メッセージキューを介せずにＤＡＧ処理モジュール２３０から直接受信されてもよい。
ジョブ提出モジュール２３０は、受信した実行情報を解析し、ストリーミングコンピューティングのプログラムの実行エントリを決定する。
その後、ジョブ提出モジュール２３０は、メインプログラム、ＤＡＧノードプログラムをパッケージ化する。ジョブ提出モジュール２３０は、リソースを一元的に管理するためのモジュールを含むことができる。具体的には、ジョブ実行クラスタ２４０がｙａｒｎである場合、リソース管理モジュールは、ｙａｒｎ上でのアプリケーション開発を簡略化するためのプロジェクトＡｐａｃｈｅ Ｔｗｉｌｌであってもよく、以下、ｔｗｉｌｌと呼ぶ。ジョブ提出モジュールは、ジョブプログラムパッケージ全体をｔｗｉｌｌモジュールに提出し、ｔｗｉｌｌはプログラムパッケージに対してリソース割り当て及びプログラム管理を一元的に行った後、ジョブ実行クラスタに提出することができる。たとえば、ｔｗｉｌｌの実行モジュールは、パッケージ化されたプログラムを受信した後、プログラムパッケージを解凍し、構成情報を利用して、プログラムが実行される環境を構成し、その後、Ｆｌｉｎｋ ｒｕｎの方式で業務ジョブをクラスタ２４０に提出する。
実施例によって、ジョブ実行クラスタは、ジョブ提出モジュールに対してローカル又は遠隔的に配置され得る。提出方法は、ジョブ実行クラスタの配置に応じて異なり、これにつては、図５を参照して以下で詳細に説明する。
具体的には、ＤＡＧ処理モジュールは、ＤＡＧを解析した後、ジョブ実行グラフをメッセージキューに発行する。ジョブ提出モジュールは、関連トピック（ｔｏｐｉｃ）のメッセージをサブスクライブし、解析することによりメッセージ内の有効な実行情報を抽出し、ジョブプログラムをパッケージ化する。各ジョブストリーム理論の要件が異なるため、実行実例が異なり、割り当てられるリソースのサイズも異なり、ジョブストリーム実行の異機種性を考慮して、プログラムパッケージを一元的に管理して実行し、ジョブストリームジョブをクラスタに提出し、プログラム実行を開始し、ここで、プログラム実行の各指標はメッセージキューを介して指標収集システムにより計算された後、記憶システムに永続化される。プログラム内のジョブストリームデータのメタ情報とプログラム実行のログ情報も記憶システムに永続化され、下流の監視データサービスシステムに供する。
従来技術では、ＤＡＧノードが別々に管理され、それぞれ独立したインターフェースを有する方式は一般的に採用されており、各ノードタイプの記述情報が対応するノード実行理論と結合され、ＤＡＧノードタイプに応じて別々にカプセル化されている。このような独立した管理方式は、プログラミングの分業コラボレーションを容易にするが、このような構造では、実行クラスタに提出する際に、ＤＡＧの不統一のために各ＤＡＧノードが独立して提出する必要があり、このため、遠隔提出シナリオでは大きなオーバーヘッド及び遅いプリロード時間が発生する。さらに、Ｊａｖａで開発されたアプリケーションの場合、プログラムクラスロードのメカニズムはＪＶＭの両親委任モデルに依存しており、ジョブストリーム論理が煩雑なシナリオでは、不適切なクラスロード操作がｊａｒパッケージの競合などの問題を引き起こす可能性がある。
この問題を解決するために、限られたＤＡＧノードがコンピューティング過程に参加するため、ＤＡＧインタラクションのストリーミングコンピューティングシナリオにおいて、プログラムの初期化を高速化し、コンピューティング効率を向上させる。
具体的には、本開示の一実施例によれば、Ｆｌｉｎｋエンジンに必要な異なるタイプのノードのノード実行理論は、統一されたクラス依存性を用いて統一されたコードフレームワークの下にカプセル化される。これにより、プログラムパッケージを作成する際に、ノードごとに独立してカプセル化する必要がなく、異なるタイプのノードのジョブストリーム記述情報を、異なるタイプのノードの演算理論とともにカプセル化することができる。このような設計をすることで、ＤＡＧ実行パッケージ又はプログラムパッケージを完全なｊａｒパッケージとしてクラスタに提出することができ、これにより、タスクを遠隔的に提出する場合のパッケージコピー数及びネットワークオーバーヘッドを削減し、プログラムの初期化を高速化し、また、ネットワークのエラー転送により失敗した場合、完全なパッケージを断続的に転送し、アーキテクチャのフォールトトレランスを向上させることができる。
Ｆｌｉｎｋコンピューティングクラスタと提出システムが１つのクラスタにあるかどうか、具体的には、ジョブ実行クラスタ２４０がジョブ提出モジュール２３０に対してローカルにあるかどうかに基づいて、プログラムが受信された後、プログラムは、遠隔提出及びローカル提出の両方の方式で実行クラスタに提出され得る。
次に、図６を参照しながら、一実施例による遠隔提出の具体的なステップを説明する。Ｆｌｉｎｋコンピューティングクラスタと提出モジュールが１つのクラスタにない場合、遠隔提出方式を使用することができる。
ステップＳ６１では、ジョブ提出モジュールは、たとえばメッセージキューからメッセージ関連トピックをサブスクライブすることにより、実行情報に関連するメッセージをメッセージキューから受信する。
ステップＳ６２では、受信したメッセージを解析し、ＤＡＧ実行情報を抽出する。
ステップＳ６３では、抽出されたＤＡＧ実行情報をパッケージ化する。いくつかの実施例によれば、パッケージ化された実行情報は、ｔｗｉｌｌに提出されて一元的に管理される。
ステップＳ６４では、リソースを割り当てる。いくつかの実施例によれば、リソース割り当てステップは、ｔｗｉｌｌによって実行される。いくつかの実施例によれば、ｔｗｉｌｌは、ジョブストリーム理論の複雑さに応じて、ネットワーク環境における最適な実行マシンと、ｙａｒｎ上の実行キューとを選択する。
ステップＳ６５では、プログラム実行環境の初期化を行う。いくつかの実施例によれば、ｔｗｉｌｌモジュールはｓｓｈの方式でプログラムの実行に必要なｊａｒパッケージ、構成情報などをリソース環境にコピーし、プログラムにローカル実行環境を構築する。いくつかの実施例によれば、ＤＡＧの異なるノードは、統一されたコードフレームワークの下にカプセル化されるので、ＤＡＧ実行情報は、１つの完全なｊａｒパッケージとして提出することができる。
ステップＳ６６では、プログラムの提出実行を実現する。いくつかの実施例によれば、ｔｗｉｌｌモジュールはＦｌｉｎｋ ｒｕｎを利用して、ステップＳ６４において選択された、ｙａｒｎ上の対応するキューにジョブストリームプログラムを最終的に提出して実行する。
ステップＳ６７では、実行ログの返信及び記憶を行う。いくつかの実施例によれば、プログラム実行のログ情報は、プログラム実行後、ポート転送の方式でメッセージキューに返信され、メッセージキューを介して最終的に記憶システムに永続化される。
以下、図７を参照しながら、一実施例に係るローカル提出方式の具体的なステップを説明する。Ｆｌｉｎｋコンピューティングクラスタと提出システムが１つのクラスタにある場合、ローカル提出方式を使用することができる。
ステップＳ７１では、ジョブ提出モジュールは、たとえばメッセージキューからメッセージ関連トピックをサブスクライブすることにより、実行情報に関連するメッセージをメッセージキューから受信する。
ステップＳ７２では、受信したメッセージを解析し、ＤＡＧ実行情報を抽出する。
ステップＳ７３では、抽出されたＤＡＧ実行情報をパッケージ化する。
ステップＳ７５では、プログラム実行環境の初期化を行う。一実施形態では、プログラムの実行に必要な構成ファイル、ｊａｒパッケージなどをローカルの一時ディレクトリにダウンロードする。
ステップＳ６６では、プログラムの提出実行を実現する。いくつかの実施例によれば、Ｆｌｉｎｋ ｒｕｎの方式で、プログラムを実行クラスタに提出する。
ステップＳ６７では、実行ログの返信及び記憶を行う。いくつかの実施例によれば、プログラムの実行中に、プログラム実行ログをメッセージキューに発行し、その後、ｋａｆｋａ ｌｏｇ ａｐｐｅｎｄを介してコンソールに送信し、記憶システムに永続化する。
２つのプログラム提出実行メカニズム、特に遠隔提出の実現は、図６及び図７を参照しながら説明されており、使用シナリオを広げ、分散プログラム実行のコストを削減する。
さらに、ｔｗｉｌｌの導入により、プログラムパッケージを一元的に抽象化して管理することができ、複雑なアーキテクチャの場合、ｙａｒｎに直接提出する場合よりも優れている。すなわち、ｔｗｉｌｌモジュールの導入は、プログラムの実行リソースや環境を一元的に管理できる一方で、ｙａｒｎ上で分散プログラムを開発、実行する複雑さを軽減することができる。
図８は、例示的な実施例によるＤＡＧインタラクションに基づくストリーミングコンピューティングのための装置のブロック図を示している。
この例示的な実施例に係るＤＡＧインタラクションに基づくストリーミングコンピューティング装置８００は、ジョブ生成部８０１と、ジョブ処理部８０２と、ジョブ提出部８０３と、を備えることができる。ジョブ生成部８０１は、第１のタイプのセットに属するＤＡＧノードからなる第１のＤＡＧノードグラフに基づいて、第１のＤＡＧジョブストリーム記述情報を生成するように構成され、ジョブ処理部８０２は、第１のタイプのセットに属するＤＡＧノードをＦｌｉｎｋエンジンに適した第２のタイプのセットに属するＤＡＧノードに適合させることによって、前記第１のＤＡＧジョブストリーム記述情報を第２のＤＡＧジョブストリーム記述情報に変換するように構成され、ジョブ提出部は、前記第２のＤＡＧジョブストリーム記述情報を、第２のＤＡＧジョブストリーム記述情報と、第２のＤＡＧジョブストリーム記述情報内のノードの演算理論とを含むＤＡＧ実行パッケージとしてカプセル化し、ジョブ実行クラスタに送信するように構成される。これにより、効率的なストリーミングコンピューティングを実現することができる。
いくつかの実施例では、前記ジョブ実行クラスタは、遠隔提出シナリオを実現するために、前記ジョブ提出部に対して遠隔的に配置される。いくつかの実施例では、ジョブ実行クラスタの負担を軽減するために、前記ジョブ提出部は、ｔｗｉｌｌモジュールをさらに含み、ここで、前記第２のＤＡＧジョブストリーム記述情報をＤＡＧ実行パッケージとしてカプセル化するステップ、及び／又は、前記ＤＡＧ実行パッケージをジョブ実行クラスタに送信するステップは、前記ｔｗｉｌｌモジュールによって行われる。いくつかの実施例では、システムアーキテクチャの多様性を達成するために、前記ジョブ生成部、前記ジョブ処理部、及び前記ジョブ提出部は、メッセージキューを介して互いにデカップリングされる。
なお、図１～７を参照して行った方法ステップの前述説明は、対応する方法ステップを実行する図８の部にも適用できるので、ここでは詳しく説明しない。
本開示の一態様によれば、プロセッサと、前記プロセッサによって実行されると、前記プロセッサに上記のＤＡＧインタラクションに基づくストリーミングコンピューティング方法を実行させる命令を含むプログラムを記憶したメモリと、を備える電子機器をさらに提供する。
本開示の別の態様によれば、電子機器のプロセッサによって実行されると、前記電子機器に上記のＤＡＧインタラクションに基づくストリーミングコンピューティング方法を実行させる命令を含むプログラムを記憶したコンピュータ読み取り可能な記憶媒体をさらに提供する。
図９に示すように、本開示の様々な態様に適用され得る電子機器の一例であるコンピューティング機器２０００がここで説明される。コンピューティング機器２０００は、処理及び／又はコンピューティングを実行するように構成された任意の機械であってもよく、ワークステーション、サーバ、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、携帯情報端末、ロボット、スマートフォン、車載コンピュータ、又はこれらの任意の組み合わせであってもよいが、これらに限定されない。上記のコンピューティング方法は、コンピューティング機器２０００又は類似した機器又はシステムによって全体的に又は少なくとも部分的に実現されてもよい。
コンピューティング機器２０００は、（場合によっては１つ又は複数のインターフェースを介して）バス２００２に接続されている、又はバス２００２と通信している要素を含んでいてもよい。たとえば、コンピューティング機器２０００は、バス２００２、１つ又は複数のプロセッサ２００４、１つ又は複数の入力機器２００６、及び１つ又は複数の出力機器２００８を含むことができる。１つ又は複数のプロセッサ２００４は、任意のタイプのプロセッサであってもよく、１つ又は複数の汎用プロセッサ及び／又は１つ又は複数の専用プロセッサ（たとえば、特殊処理チップ）を含むことができるが、これらに限定されない。入力機器２００６は、コンピューティング機器２０００に情報を入力することができる任意のタイプの機器であってもよく、マウス、キーボード、タッチスクリーン、マイクロフォン、及び／又は遠隔コントローラを含むことができるが、これらに限定されない。出力機器２００８は、情報を表示することができる任意のタイプの機器であってもよく、ディスプレイ、スピーカ、ビデオ／オーディオ出力端子、バイブレータ、及び／又はプリンタを含むことができるが、これらに限定されない。コンピューティング機器２０００は、非一時的記憶機器２０１０を含むか、又は非一時的記憶機器２０１０に接続されてもよく、非一時的記憶機器は、非一時的であり、データを記憶できる任意の記憶機器であってもよく、ディスクドライブ、光学記憶機器、ソリッドステートメモリ、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープ、又は他の任意の磁気媒体、光学ディスク又は任意の他の光学媒体、ＲＯＭ（読み取り専用メモリ）、ＲＡＭ（ランダムアクセスメモリ）、キャッシュメモリ、及び／又は任意の他のメモリチップ又はカートリッジ、及び／又はコンピュータがデータ、命令、及び／又はコードを読み取ることができる任意の他の媒体を含むことができるが、これらに限定されない。非一時的記憶機器２０１０は、インターフェースから取り外し可能である。非一時的記憶機器２０１０は、上記の方法及びステップを実現するためのデータ／プログラム（命令を含む）／コードを有することができる。コンピューティング機器２０００はまた、通信機器２０１２を含むことができる。通信機器２０１２は、外部機器及び／又はネットワークと通信可能な任意のタイプの機器又はシステムであってもよく、モデム、ネットワークカード、赤外線通信機器、無線通信機器、及び／又はチップセット、たとえば、ＢｌｕｅｔｏｏｔｈＴＭ機器、１３０２．１１機器、ＷｉＦｉ機器、ＷｉＭａｘ機器、セルラー通信機器、及び／又は類似のものを含むことができるが、これらに限定されない。
コンピューティング機器２０００はまた、プロセッサ２００４の動作に有用なプログラム（命令を含む）及び／又はデータを記憶することができる任意のタイプのワーキングメモリ２０１４を含んでもよく、ランダムアクセスメモリ及び／又は読み取り専用メモリデバイスを含むことができるが、これらに限定されない。
ソフトウェア要素（プログラム）は、ワーキングメモリ２０１４中に存在してもよく、オペレーティングシステム２０１６、１つ又は複数のアプリケーション２０１８、ドライバ、及び／又は他のデータ及びコードを含むが、これらに限定されない。上記方法及びステップを実行するための命令は、１つ又は複数のアプリケーションプログラム２０１８に含まれてもよく、上記のコンピューティング方法は、１つ又は複数のアプリケーションプログラム２０１８の命令をプロセッサ２００４によって読み込んで実行することによって実現されてもよい。より具体的には、上記のコンピューティング方法において、ステップＳ１０１～ステップＳ１０３は、たとえば、プロセッサ２００４が、ステップＳ１０１～ステップＳ１０３の命令を有するアプリケーションプログラム２０１８を実行することによって実現されてもよい。さらに、上記したコンピューティング方法における他のステップは、たとえば、プロセッサ２００４が、対応するステップにおける命令を実行するアプリケーションプログラム２０１８を実行することによって実現されてもよい。ソフトウェア要素（プログラム）の命令の実行可能コード又はソースコードは、非一時的なコンピュータ読み取り可能な記憶媒体（たとえば、上記の記憶機器２０１０）に記憶されてもよく、実行時にワーキングメモリ２０１４に記憶されてもよい（コンパイル及び／又はインストールされてもよい）。ソフトウェア要素（プログラム）の命令の実行可能コード又はソースコードは、遠隔地からダウンロードすることもできる。
なお、特定の要件に従って様々な変形が可能である。たとえば、特定の要素は、カスタマイズされたハードウェアを使用することもでき、及び／又は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、又はそれらの任意の組み合わせを使用して実現することができる。たとえば、開示された方法及び機器の一部又は全部は、本開示の論理及びアルゴリズムに従って、ハードウェア（たとえば、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）及び／又はプログラマブル・理論・アレイ（ＰＬＡ）を含むプログラマブル論理回路）をアセンブリ言語又はハードウェア・プログラミング言語（たとえば、ＶＥＲＩＬＯＧ、ＶＨＤＬ、Ｃ＋＋）でプログラムすることによって実現され得る。
なお、前述の方法は、サーバ－クライアントモードによって実現されてもよい。たとえば、クライアントは、ユーザによって入力されたデータを受信し、前記データをサーバに送信することができる。クライアントは、ユーザから入力されたデータを受信し、前述の方法の一部の処理を行い、処理によって得られたデータをサーバに送信することも可能である。サーバは、クライアントからデータを受信し、前述方法又は前述方法の他の部分を実行し、実行結果をクライアントに返信することができる。クライアントは、方法の実行結果をサーバから受信し、たとえば出力機器を介してユーザに表示することができる。
また、なお、コンピューティング機器２０００のコンポーネントは、ネットワーク上に分散されてもよい。たとえば、ある処理は１つのプロセッサを用いて実行されてもよいが、同時に他の処理は１つのプロセッサから離れた別のプロセッサによって実行されてもよい。コンピューティングシステム２０００の他のコンポーネントも同様に分散してもよい。このように、コンピューティング機器２０００は、複数の場所で処理を実行する分散コンピューティングシステムとして解釈することができる。たとえば、コンピューティング機器２０００は、クラウドプラットフォームの一部として実現されてもよい。このクラウドプラットフォームは、クラウドのハードウェア（たとえば、サーバ）とソフトウェアリソースの底層機能を抽象化する。リソースは、コンピューティング機器２０００から離れたサーバ上でコンピュータ処理を実行する際に使用されるアプリケーション及び／又はデータを含むことができる。リソースはまた、インターネット及び／又はセルラー又はＷｉ－Ｆｉネットワークなどの加入者ネットワークを介して提供されるサービスを含むことができる。
本開示の実施例の技術案によれば、ストリーミングコンピューティングの効率を向上させ、ユーザエクスペリエンスを向上させることができる。
図面を参照して本開示の実施例又は例を説明したが、上記した方法、システム、及び機器は例示的な実施例又は例にすぎず、本開示の範囲はこれらの実施例又は例によって限定されるのではなく、授権された特許請求の範囲及びそれらの同等の範囲によってのみ限定されることが理解されるべきである。実施例又は例における様々な要素は、省略されてもよく、又はそれらの同等の要素によって置き換えられてもよい。さらに、各ステップは、本開示で説明されているものとは異なる順序で実行されてもよい。さらに、実施例又は例における様々な要素を様々な方法で組み合わせることができる。また、ここで記載された要素の多くは、技術の進化に伴って、本開示の後に現れる同等の要素によって置き換えられ得る。
【図1】
【図2】
【図3A】
【図3B】
【図3C】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
