(57)【要約】      （修正有）【課題】複数の分析パターンを並列実行するためのデプロイを効率化し、単位時間に実施す分析パターン数を増やす。【解決手段】データ処理システムは、分析フローとパラメータの組合せを含む分析パターン設定ファイルを管理する第１管理サーバ１０１と、分析アプリケーションが動作するコンテナまたはＶＭのイメージである分析プリケーションイメージを管理する第２管理サーバ１０２と、複数の分析パターンを並列実行する複数の分析サーバ１０５とを含む。第１管理サーバは、複数の分析サーバのリソースと稼働状況に基づいてリソースに空きのある分析サーバに、第２管理サーバから分析アプリケーションイメージをデブロイする。第１管理サーバは、リソースに空きがある複数の分析サーバに対して分析パターンを割り当てるクラスタを形成する。分析サーバは、分析アプリケーションを実行して分析パターン設定ファイルに規定された分析フローを実行する。【選択図】図１
2019106031.tif 000002
【特許請求の範囲】
【請求項１】
複数の分析サーバがデータ分析を実行するデータ処理システムであって、
分析フローとパラメータの組合せを含む分析パターンを規定する分析パターン設定ファイルを管理する第１の管理サーバと、
分析アプリケーションのプロセスが動作するコンテナまたはＶＭのイメージである分析プリケーションイメージを管理する第２の管理サーバと、
複数の前記分析パターンを並列実行することができる前記複数の分析サーバと、を有し、
第１の管理サーバは、前記複数の分析サーバに係るリソースと稼働状況に基づいてリソースに空きのある前記複数の分析サーバに、前記第２の管理サーバから前記分析プリケーションイメージをデブロイし、
前記第１の管理サーバは、前記分析パターン設定ファイルに従い、該リソースに空きがある前記複数の分析サーバに対して、前記分析パターンを割り当てるクラスタを形成し、
前記分析パターンごとにクラスタを形成した前記複数の分析サーバは、前記第１の管理サーバからの実行命令に従って、前記分析アプリケーションを実行して、前記分析パターン設定ファイルに規定された分析フローを実行する、
ことを特徴とするデータ処理システム。
【請求項２】
請求項１に記載のデータ処理システムにおいて、
前記分析サーバが持つリソースを管理するサーバ情報テーブルと、
分析アプリケーションが割り当てられた前記分析サーバにおける、前記リソース及び割当済みの分析アプリケーションコンテナ数に関する稼働状況を管理する稼働情報テーブルと、を有し、
前記第１の管理サーバは分析管理プログラムを実行して、前記分析パターン設定ファイルを読み込み、前記サーバ情報テーブルと前記稼働情報テーブルとを参照して、前記分析パターン設定ファイルに記載された不正値をチェックすることを特徴とする
ことを特徴とする請求項１に記載のデータ処理システム。
【請求項３】
請求項１に記載のデータ処理システムにおいて、
前記分析サーバが持つリソースを管理するサーバ情報テーブルと、
前記分析アプリケーションが割り当てられた前記分析サーバにおける、前記リソース及び割当済みの分析アプリケーションコンテナ数に関する稼働状況を管理する稼働情報テーブルと、
前記分析パターンの実行の状況を管理する分析ステータステーブルと、を有し、
前記第１の管理サーバは、前記分析パターン設定ファイルに含まれる前記分析パターンに記載されたリソースについて、前記分析ステータステーブルと、前記サーバ情報テーブルと、前記稼働情報テーブルとを参照して、前記分析サーバのリソースに空きがある前記分析サーバにデプロイ可能な分析アプリケーションを順次デプロイする
ことを特徴とする請求項１に記載のデータ処理システム。
【請求項４】
請求項１に記載のデータ処理システムにおいて、
前記第１の管理サーバは、前記稼働情報テーブルと、前記分析パターンに規定されたディスクアクセス優先度に基づき、優先度の高い分析に多くのリソースを配分する
ことを特徴とする請求項１に記載のデータ処理システム。
【請求項５】
前記管理サーバに接続される入出力装置を有し、
該入出力装置は、前記分析パターンの設定のための、分析フロー、パラメータ、及び必要とする分析サーバのリソースに関する情報を含む画面を表示し、
前記管理サーバは、該入出力装置からの指示に従って、該画面により指定された情報に基づいて前記分析パターン設定ファイルを作成して、記憶部に保持する
ことを特徴とする請求項１に記載のデータ処理システム。
【請求項６】
前記分析プリケーションイメージは、分析パターンに含まれる分析フローと、分析フローの分析を実行する処理手段と、分析アプリケーションコンテナ内で前記分析フローに従って前記分析エンジンの呼び出しなどを行う分析連携アプリケーションを含む
ことを特徴とする請求項１に記載のデータ処理システム。
【請求項７】
前記分析パターンの実行履歴を管理する分析パターン履歴テーブルと、分析の実行ステータスを管理する分析ステータステーブルと、前記分析サーバのリソースを管理するサーバ情報テーブルと、前記分析サーバの稼働状況を管理する稼働情報テーブルと、を保管する第３の管理サーバと、
分析対象となるデータと、前記分析サーバによる分析処理結果を格納するデータレイクサーバと、を更に有する
ことを特徴とする請求項１に記載のデータ処理システム。
【請求項８】
複数の分析サーバでデータ分析を実行するデータ分析処理方法であって、
第１の管理サーバが、分析フローとパラメータの組合せを含む分析パターンを規定する分析パターン設定ファイルを管理する第１ステップと、
第２の管理サーバが、分析アプリケーションのプロセスが動作するコンテナまたはＶＭのイメージである分析プリケーションイメージを管理する第２ステップと、
前記複数の分析サーバに係るリソースと稼働状況に基づいて、リソースに空きのある前記複数の分析サーバに、前記第２の管理サーバから前記分析プリケーションイメージをデブロイする第３ステップと、
前記第１の管理サーバが、前記分析パターン設定ファイルに従い、前記リソースに空きがある前記複数の分析サーバに対して、前記分析パターンを割り当てるクラスタを形成する第４ステップと、
前記分析パターンごとにクラスタを形成した前記複数の分析サーバが、前記アプリケーションを実行して、前記分析パターン設定ファイルに規定された分析フローを実行する第５ステップと、を有する
ことを特徴とするデータ分析処理方法。
【請求項９】
前記第１の管理サーバは、前記第１ステップにおいて、前記分析パターン設定ファイルを記憶部に格納して管理しており、
前記第１の管理サーバは、前記第３ステップの前に、該記憶部から読み込まれた分析パターン設定ファイルに規定された分析パターンに不正値が含まれるかを判断する第６ステップを有し、
前記第６ステップにおいて、前記第１の管理サーバが、前記分析パターンに不正値が含まれないと判断した場合、前記第３ステップの処理を行う
ことを特徴とする請求項８のデータ分析処理方法。
【請求項１０】
前記第１の管理サーバは、前記複数の分析サーバに関するリソース及び稼働状況を参照して、前記分析パターン設定ファイルに規定された前記分析サーバのリソースが充足するかの判断を、前記分析パターン設定ファイルに規定された分析パターンの数だけ行い、
該判断の結果、充足する場合は、前記分析パターン設定ファイルに規定された該分析パターンの履歴をデータベースに記憶する
ことを特徴とする請求項８のデータ分析処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理システム及びデータ分析処理方法に係り、特に、多量のデータ分析に好適な、分析アプリケーションの割当及び分析フローの並列実行に関する。
【背景技術】
【０００２】
ＩｏＴ（Internet of Things）のような多量のデータが扱われる環境において種々のデータ分析が試みられているが、何れの場合も分析の目的に対して効果的なアルゴリズムとパラメータをあらかじめ決定することは困難である。効果的な分析結果を得るための分析フローとパラメータは試行錯誤の繰り返しによって決定される。すなわち、ある分析フローとパラメータの組み合わせである分析パターンによる分析を行ってその分析結果を評価し、また別の分析パターンで再度分析を行うという手法が一般的である。そのため、事前に準備した分析パターンの全ての実行結果を得るためには多くの時間が費やされている。
【０００３】
また、分析対象のデータは膨大な量であり、一回の分析に多くの時間が費やされるため、複数のサーバによる分散処理が行われる。分散処理の場合、一つの分析パターンを実行するには複数のサーバに分析アプリケーションをデプロイする必要があり、分析を開始するまでに時間がかかる。さらに、分析パターンによって必要なマシンリソースが異なり、リソースを効率的に使用するように分析アプリケーションをデプロイする必要がある。
【０００４】
例えば、特許文献１には、系列データ並列分析基盤を用いてビックデータなどの大量のデータの分析処理する技術が開示されている。この系列データ並列分析基盤は、計算機器毎にデータブロックに対して処理を行う少なくとも一つ以上のデータブロック処理サーバと、計算機器毎にデータブロック処理サーバの結果を処理する少なくとも一つ以上のブロック処理集約サーバとを備える、としている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】ＷＯ２０１５／００１５９６公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１に記載の系列データ並列分析基盤によれば、系列データを柔軟に分散処理することができる、としている。然しながら、特許文献１には、複数の分析パターンをクラスタとして並列実行する場合、如何に複数のリソースを効率的に使用して分析アプリケーションをデプロイするか、単位時間に実施できる分析パターンの数を如何に増やすか、については言及されていない。
【０００７】
本発明の目的は、複数の分析パターンを並列実行するためのデプロイを効率化して、単位時間に実施できる分析パターンの数を増やすことにある。
【課題を解決するための手段】
【０００８】
本発明に係るデータ処理システムの好ましい例によれば、
複数の分析サーバがデータ分析を実行するデータ処理システムであって、
分析フローとパラメータの組合せを含む分析パターンを規定する分析パターン設定ファイルを管理する第１の管理サーバと、
分析アプリケーションのプロセスが動作するコンテナまたはＶＭのイメージである分析プリケーションイメージを管理する第２の管理サーバと、
複数の前記分析パターンを並列実行することができる前記複数の分析サーバと、を有し、
第１の管理サーバは、前記複数の分析サーバに係るリソースと稼働状況に基づいてリソースに空きのある前記複数の分析サーバに、前記第２の管理サーバから
前記分析プリケーションイメージをデブロイし、
前記第１の管理サーバは、前記分析パターン設定ファイルに従い、該リソースに空きがある前記複数の分析サーバに対して、前記分析パターンを割り当てるクラスタを形成し、
前記分析パターンごとにクラスタを形成した前記複数の分析サーバは、前記第１の管理サーバからの実行命令に従って、前記分析アプリケーションを実行して、
前記分析パターン設定ファイルに規定された分析フローを実行する、ことを特徴とするデータ処理システム、として構成される。
【０００９】
本発明はまた、上記データ処理システムにおいて実現されるデータ分析処理方法としても把握される。
【発明の効果】
【００１０】
本発明によれば、複数の分析パターンを並列実行し、そのデプロイを効率化して、単位時間に実施できる分析パターンの数を増やすことが可能となる。
【図面の簡単な説明】
【００１１】
【図１】一実施例におけるデータ処理システムの全体構成を示す図。
【図２】分析管理サーバの構成を示す図。
【図３】分析アプリケーションイメージ管理サーバの構成を示す図。
【図４】分析アプリケーションイメージの構成を示す図。
【図５】管理ＤＢサーバの構成を示す図。
【図６】データレイクサーバの構成を示す図。
【図７】分析アプリケーションサーバの構成を示す図。
【図８】分析パターン設定ファイルの例を示す図。
【図９】分析管理プログラムが実行する処理のフローチャートを示す図。
【図１０】分析パターン設定ファイル読込処理のフローチャートを示す図。
【図１１】不正値チェック処理のフローチャートを示す図。
【図１２】デプロイ／分析実行処理のフローチャートを示す図。
【図１３】クラスタ作成処理のフローチャートを示す図。
【図１４】クラスタ内における分析実行処理のフローチャートを示す図。
【図１５】分析パターン履歴テーブル１５０１の構成を示す図。
【図１６】分析ステータステーブル１５０２の構成を示す図。
【図１７】サーバ情報テーブル１５０３の構成を示す図。
【図１８】稼働情報テーブル１５０４の構成を示す図。
【図１９】分析管理サーバの入出力装置に表示される表示画面の例を示す図。
【図２０】一実施例おけるデータ処理システムを概略説明するための図。
【発明を実施するための形態】
【００１２】
以下、本発明の実施例を、図面を用いて詳細に説明する。
なお、以下の実施例の説明において使用される用語を次の通り定義する。
「コンテナ」とは仮想的なプロセス実行環境をいう。
「ＶＭ」とは仮想的なマシン環境をいう。
「データレイク」とは大量のデータを格納するためのデータ蓄積基盤をいう。
「分析パターン」とは分析フローとパラメータの組合せをいう。
【実施例１】
【００１３】
図１は、一実施例におけるデータ処理システムの全体構成を示す図である。
データ処理システムは、分析管理サーバ１０１と、分析アプリケーションイメージ管理サーバ１０２と、管理ＤＢ（Date Base）サーバ１０３と、データレイクサーバ１０４と、複数の分析アプリケーションサーバ１０５が、通信設備網１０７を介して接続されて構成される。
【００１４】
分析管理サーバ１０１は、分析管理プログラムを実行して、本発明によって導入される分析パターン設定ファイルを読み込み、分析アプリケーションを分析アプリケーションサーバ１０５にデプロイし、分析アプリケーションクラスタ１０６に対して分析の実行命令を行うサーバである。なお、分析管理サーバ１０１の構成については図２を参照して後述する。本実施例では、分析管理サーバ１０１がコンテナ型仮想化技術を使用する。
【００１５】
分析アプリケーションサーバ１０５は、例えばＩｏＴデータの分析処理を実行するサーバである。分析アプリケーションサーバ１０５は、実行する分析パターン毎にクラスタリングされ、複数の分析アプリケーションサーバ１０５により分析パターンクラスタ１０６が構成される。分析パターンクラスタ１０６は互いに分析アプリケーションサーバ１０５のリソースを共有することがある。すなわち、一つの分析アプリケーションサーバ１０５上で複数の分析パターンによる分析が実行されることがある。なお、分析アプリケーションサーバ１０５の構成については図７を参照して後述する。
【００１６】
分析アプリケーションイメージ管理サーバ１０２は、分析フローごとの分析アプリケーションイメージを保管して管理するサーバである。その詳細は図３を参照して後述する。分析アプリケーションイメージとは、分析アプリケーションのプロセスを実行するコンテナまたはＶＭのイメージであり、その詳細は図４を参照して後述する。
【００１７】
管理ＤＢサーバ１０３は、分析パターン及び分析アプリケーションサーバ１０５の状況等に関する管理情報を保管するサーバである。その詳細は図５を参照して後述する。データレイクサーバ１０４はＩｏＴデータと分析結果を格納するサーバである。その詳細は図６を参照して後述する。
【００１８】
各サーバの詳細を説明する前に、図２０を参照して、データ処理ステムの概要を説明する。
入出力装置から、分析パターンを規定する分析パターン設定ファイル２１２を作成するためのデータを入力して、分析管理サーバ１０１が分析パターン設定ファイル２１２を作成する。作成された分析パターン設定ファイル２１２は管理サーバ１０１の記憶装置（記憶部）に格納される。また、分析アプリケーションイメージ管理サーバ１０２には予め分析フローごとの分析アプリケーションイメージが保管されている。
【００１９】
データの分析に際して、分析管理サーバ１０１は分析管理プログラムを実行して、分析パターン設定ファイル２１２を記憶部から読み込み、さらに分析アプリケーションサーバ１０５のリソース情報（コア数やメモリ容量）を取得する。分析パターン設定ファイルの内容、分析アプリケーションサーバ１０５の稼働状況やリソース情報に基づいて、空きがある複数の分析アプリケーションサーバ１０５に、分析アプリケーションイメージ管理サーバ１０２から分析アプリケーションイメージをデプロイする。そして、分析管理サーバ１０１は、分析パターンごとに複数の分析アプリケーションサーバ１０５に亘ってクラスタを形成する。
【００２０】
その後、分析管理サーバ１０１は、分析パターンごとに、クラスタを形成した複数の分析アプリケーションサーバ１０５に実行命令を発する。すると、クラスタごとの複数のアプリケーションサーバは、分析パターンに係るデータ分析処理を並列に実行する。実行時にはパラメータを読み込んで処理し、処理の状態（分析ステータス）を分析ステータステーブルに書き込む。分析アプリケーションサーバ１０５による分析結果は、データレイクサーバ１０６に格納され、その時の分析パターンの履歴は管理ＤＢサーバ１０３に格納される。
【００２１】
図２０は、３つの分析パターン（１）〜（３）に対応して複数のサーバに亘って３つのクラスタが形成されて、各クラスタの分析アプリケーションサーバ１０５で分析アプリケーションイメージがデプロイされ、データ分析処理が実行される例を示している。
【００２２】
図２は、分析管理サーバ１０１の構成を示す図である。
分析管理サーバ１０１は、入出力回路インタフェース２０１と、プロセッサ２０２と、入出力装置２０３と、記憶装置２０４と、これらを接続する内部通信線（たとえばバス）を有して構成される。入出力回路インタフェース２０１は、通信設備網１０７と通信するためのインタフェースである。プロセッサ２０２は、記憶装置２０４に格納された分析管理プログラム２１１を実行し、分析パターン設定ファイル２１２を読み込み、分析アプリケーションをコンテナとして分析アプリケーションサーバ１０５にデプロイする。なお、プロセッサ２０２は、演算装置或いは制御装置と称してもよい。分析パターン設定ファイル２１２の詳細は図８を参照して後述する。
【００２３】
入出力装置２０３は、種々のデータの入力を受け付け及びデータを出力する装置であり、例えば入力を受け付けるキーボードやマウスなどの入力器と、プロセッサ２０２による処理に関わる情報を可視表示する表示器である。本例では、入力器から分析パターン設定ファイル２１２を作成するためのデータ（分析パターン）が入力され、表示器に分析アプリケーションサーバのリソースや分析パターンの設定に関する情報が表示される（図１９参照）。記憶装置２０４は、ＤＲＡＭ（Dynamic Access Random Memory）などの揮発性の記憶装置やＨＤＤやＳＳＤ等の不揮発性の記憶装置である。
【００２４】
図３は分析アプリケーションイメージ管理サーバ１０２の構成を示す図である。
分析アプリケーションイメージ管理サーバ１０２は、入出力回路インタフェース３０１と、プロセッサ３０２と、入出力装置３０３と、記憶装置３０４と、これらを接続する内部通信線を有する。入出力回路インタフェース３０１は、通信設備網１０７と通信するためのインタフェースである。記憶装置３０４には、分析アプリケーションのプロセスを実行するコンテナまたはＶＭのイメージである分析アプリケーションイメージ３１１が保管されている。分析アプリケーションイメージ３１１の詳細は図４を参照して後述する。入出力装置３０３は、データの入力を受け付けたり、データを出力したり、あるいはその両方を行うための装置である。記憶装置３０４は揮発性の記憶装置や不揮発性の記憶装置である。
【００２５】
図４は、分析アプリケーションイメージの構成を示す図である。
分析アプリケーションイメージ３１１は、分析アプリケーションのプロセスを実行するコンテナまたはＶＭのイメージであり、分析連携アプリケーション４０１と、分析フロー４０２と、分析エンジン４０３を有する。ここで、分析フロー４０２は、分析パターンに含まれる分析対象となるフローないしアルゴリズムであり、本例では分析パターン設定ファイル２１２に定義される。分析フローごとに固有のＩＤが付与されている。分析エンジン４０３は分析フローの分析を実行するハードウェアやソフトウェア等の処理手段である。分析連携アプリケーション４０１は、分析アプリケーションコンテナ内で分析フロー４０２に従って分析エンジン４０３の呼び出しなどを行うプログラムである。本例では、分析アプリケーションイメージは、例えばＤｏｋｅｒの仮想化イメージである（Ｄｏｃｋｅｒはドッカー社の登録商）。
【００２６】
図５は、管理ＤＢサーバ１０３の構成を示す図である。
管理ＤＢサーバ１０３は、入出力回路インタフェース５０１と、プロセッサ５０２と、入出力装置５０３と、記憶装置５０４と、これらを接続する内部通信線を有する。入出力回路インタフェース５０１は、通信設備網１０７と通信するためのインタフェースである。プロセッサ５０２はプログラムを実行する。記憶装置５０４は管理ＤＢ５１１を有する。入出力装置５０３はデータの入力を受け付け及びデータを出力する装置である。記憶装置５０４は揮発性の記憶装置や不揮発性の記憶装置である。
【００２７】
ここで、管理ＤＢ５１１は、分析パターンの実行履歴を管理する分析パターン履歴テーブル１５０１と、分析の実行ステータスを管理する分析ステータステーブル１５０２と、分析アプリケーションサーバ１０５のリソースを管理するサーバ情報テーブル１５０３と、分析アプリケーションサーバ１０５の稼働状況を管理する稼働情報テーブル１５０４とを保持する。分析パターン履歴は図１０ステップＳ１００６の結果である。上記各テーブルの構成は、図１５乃至図１８を参照して後述する。
【００２８】
ここで、図１５乃至図１８を参照して、各テーブルの構成について説明する。
分析パターン履歴テーブル１５０１は、図１５に示すように、分析パターンを管理するものであり、分析パターンＩＤと、分析フローＩＤと、分析パラメータと、割当サーバ数と、割当コア数と、割当メモリ量と、ディスク優先度を登録する。例えば、分析パターンＩＤが「Ｘ」のものは、分析パターンの分析フローＩＤが「００１」であり、その際に用いられる２つの分析パラメータ「Ｐ１」及び「Ｐ２」がそれぞれ「２００」、「１００」である。その分析の実行のために割り当てられる「サーバ数」、「コア数」、「メモリ数」がそれぞれ「３」、「２」、「４ＧＢ」であり、分析のために用いられるディスクの優先度が「７」であることを示している。
【００２９】
分析ステータステーブル１５０２は、図１６に示すように、分析パターンの実行状況を管理するものであり、分析パターンＩＤと、分析ステータスを登録する。例えば、分析パターンＩＤが「Ｘ」である分析パターンの分析ステータスが「実行中」であることを示している。
【００３０】
サーバ情報テーブル１５０３は、図１７に示すように、サーバの構成情報を管理するものであり、サーバＩＤと、総コア数と、総メモリ量、等のリソース情報を登録する。例えば、サーバＩＤが「００１」であるサーバの総コア数、総メモリ量がそれぞれ「２」、「２ＧＢ」であることを示している。
【００３１】
稼働情報テーブル１５０４は、図１８に示すように、割当られたサーバにおける分析アプリケーションの稼働状況を管理するものであり、サーバＩＤと、割当済みＣＰＵコア数と、割当済みメモリ量と、稼働中分析アプリケーションコンテナ数を登録する。例えば、サーバＩＤ「００１」であるサーバで係る分析の実行のために割当済みであるコア数、メモリ量それぞれが「２」、「１ＧＢ」である。「稼働中分析アプリケーションコンテナ数」は、サーバ上で既に稼働しているアプリケーションコンテナ数を意味し、その数が「１」であることを示している。
【００３２】
図６はデータレイクサーバ１０４の構成を示す図である。
データレイクサーバ１０４は、入出力回路インタフェース６０１と、プロセッサ６０２と、入出力装置６０３と、記憶装置６０４と、これらを接続する内部通信線を有する。入出力回路インタフェース６０１は、通信設備網１０７と通信するためのインタフェースである。プロセッサ５０２はプログラムを実行する。記憶装置６０４にはデータレイク６１１が格納されている。データレイク６１１には、ＩｏＴのセンサ等から収集されたデータの集合である分析対象データと、分析対象データの分析結果である分析結果データが格納される。入出力装置６０３はデータの入力を受け付け及びデータを出力する装置である。記憶装置６０４は揮発性の記憶装置や不揮発性の記憶装置である。
【００３３】
図７は分析アプリケーションサーバ１０５の構成を示す図である。
分析アプリケーションサーバ１０５は、入出力回路インタフェース７０１と、プロセッサ７０２と、入出力装置７０３と、記憶装置７０４と、これらを接続する内部通信線を有する。入出力回路インタフェース７０１は、通信設備網１０７と通信するためのインタフェースである。プロセッサ７０２は、演算装置及び制御装置である。入出力装置７０３はデータの入力を受け付け及びデータを出力する装置である。記憶装置７０４は、揮発性の記憶装置や不揮発性の記憶装置である。
【００３４】
プロセッサ７０２が記憶装置７０４に格納された分析アプリケーションコンテナ７１１を実行する。分析アプリケーションコンテナ７１１は分析アプリケーションイメージ３１１をプロセスとして実行した形態である。分析アプリケーションコンテナ７１１の内部では、分析連携アプリケーション４０１が分析フロー４０２に従って、分析エンジン４０３を用いて分析を実行する。なお、分析アプリケーションは必ずしもコンテナである必要はなく、ＶＭであってもよい。
【００３５】
図８は分析パターン設定ファイルの一例を示す図である。
分析パターン設定ファイル２１２には、複数の分析パターン８０１の設定が記載される。各分析パターン８０１の設定には、分析フローＩＤ８０２と、複数の分析パラメータ８０３と、割当サーバ数８０４と、サーバ１台あたりの割当コア（ＣＰＵ）数８０５と、サーバ１台あたりの割当メモリ量８０６と、ディスクアクセス優先度８０７が含まれる。ディスクアクセス優先度８０７は、一つの分析アプリケーションサーバ上で複数の分析アプリケーションコンテナ７１１が稼働する場合のディスクアクセスの優先度合を意味し、値が大きいほど優先度が高い。分析パターン設定ファイル２１２に記述される情報は、図１０及び図１１を参照する不正値チェック処理の演算に使用される。
【００３６】
次に、図９乃至図１４を参照して、分析管理サーバ１０１におけるプロセッサ２０２による分析管理プログラム２１１の実行動作について説明する。
図９において、ステップS９０１は、記憶装置２０４に格納された分析パターン設定ファイル２１２をプロセッサ２０２に読み込む処理である。ステップＳ９０２は、ステップＳ９０１の読み込み処理の結果、エラーが発生したか否かを判断する処理である。ステップＳ９０２においてエラーが存在すると判断された場合は処理を終了する。一方、エラーが存在しない場合はステップＳ９０３に進む。ステップＳ９０３は分析アプリケーションをデプロイして分析処理を実行する処理である。なお、ステップＳ９０１及びステップ９０３の詳細は図１０及び図１２を参照してそれぞれ後述する。
【００３７】
図１０は、分析パターン設定ファイルの読込み処理（S９０１）の詳細を示す図である。
図１０において、Ｓ１００１は分析パターン設定ファイル２１２を読み込む処理である。ステップＳ１００２は、Ｓ１００１の読み込み処理が成功したか否かを判断する処理である。ステップＳ１００２において、分析パターン設定ファイル２１２の読込みが成功と判断された場合はステップＳ１００３へ進み、読込みが失敗した場合は、Ｓ１００４でエラー応答を行って処理を終了する。
【００３８】
ステップＳ１００３は、分析パターン設定ファイル２１２の不正値チェックを行う処理である。ステップＳ１００３の詳細は図１１を参照して後述する。ステップＳ１００５はステップＳ１００３の結果、不正値が存在するかどうかを判断する処理である。ステップＳ１００５において、不正値が存在すると判断された場合はＳ１００４でエラー応答を行って処理を終了し、不正値が存在しない場合はステップＳ１００６に進む。ステップＳ１００６では、分析パターン設定ファイル２１２に記載した設定を分析パターン履歴として分析パターン履歴テーブル１５０１に記録する。
【００３９】
図１１は、不正値チェック処理（Ｓ１００３）の詳細を示す図である。
図１１において、ステップＳ１１０１は、サーバ情報を取得する処理である。すなわち、プロセッサ２０２はサーバ情報テーブル１５０３から分析アプリケーションサーバ１０５の台数と、各分析アプリケーションサーバ１０５のコア数と、メモリ量の情報を取得する。ステップＳ１１０２は、分析パターン設定ファイル２１２に設定した分析パターン８０１の数だけ内部の処理（ステップ１１０２〜ステップ１１０８）を繰り返す。ステップＳ１１０３は、分析フローＩＤ８０２が不正でないかを判断する処理である。例えば、分析フローＩＤ８０２が存在しないＩＤであるので、不正であると判断された場合はＳ１１０４でエラー応答を行って処理を終了し、不正がない場合はステップＳ１１０５に進む。
【００４０】
ステップＳ１１０５は、サーバ情報テーブル１５０３を参照して、サーバ数が不正でないかを判断する処理である。例えば、割当サーバ数８０４がシステムの全分析アプリケーションサーバ数を超えるので、不正であると判断された場合はＳ１１０４でエラー応答を行って処理を終了し、不正がない場合はステップＳ１１０６に進む。ステップＳ１１０６は、サーバ情報テーブル１５０３を参照して、割当コア数が不正でないかを判断する処理である。例えば、サーバ１台あたりの割当コア数８０５が負の数である場合や、設定した割当コア数で割当可能なサーバが存在しない場合等の、不正である場合と判断された場合はＳ１１０４でエラー応答を行って処理を終了し、不正がない場合はステップＳ１１０７に進む。ステップＳ１１０７は、サーバ情報テーブルを参照して、割当メモリ量８０６が不正でないかを判断する処理である。例えば、割当メモリ量８０６が負の数である場合や、設定した割当メモリ量で割当可能なサーバが存在しない場合等の、不正である場合と判断された場合はＳ１１０４でエラー応答を行って処理を終了し、不正がない場合は繰り返し処理Ｓ１１０２の初めに戻るか、または処理を終了する。
【００４１】
なお、エラー応答処理Ｓ１１０４は、不正の種別に応じて異なる応答になるよう構成してもよい。例えば、一サーバ当たりの割当メモリ量を１６ＧＢに設定したが、総メモリ量が１６ＧＢのサーバが存在しない場合は、その旨と割当メモリ量を適切な値に設定するように促すエラーメッセージを入出力装置２０３に出力してもよい。
【００４２】
図１２は、デプロイ／分析実行処理（Ｓ９０３）の詳細を示す図である。
図１２において、ステップＳ１２０１では、分析パターン設定ファイル２１２に設定した分析パターン８０１の数だけ内部の処理（ステップＳ１２０２〜ステップＳ１２１２）を繰り返す。ステップＳ１２０２は、分析パターン８０１を一つ取得する処理である。ステップＳ１２０３は、分析ステータステーブル１５０２を参照して、ステップＳ１２０２で取得された分析パターンが既に実行開始済みか（すなわち実行完了か実行中）否かを判断する処理である。実行開始済であればステップＳ１２０４に進んで次の分析パターン８０１を一つ取得してステップＳ１２０３に戻り、実行開始済でない場合はステップＳ１２０５に進む。
【００４３】
ステップＳ１２０５は、各分析アプリケーションサーバ１０５の使用中コア数と使用中メモリ量を取得する処理である。ステップＳ１２０６は、サーバ情報テーブル１５０３と稼働情報テーブル１５０４を参照して、総コア数−割当済コア数が割当コア数（８０５）以上であるサーバを全て選出する処理である。ステップＳ１２０７は、サーバ情報テーブル１５０３と稼働情報テーブル１５０４を参照して、総メモリ量−割当済メモリ量が割当メモリ量（８０６）以上であるサーバを全て選出する処理である。ステップＳ１２０８は、選出されたサーバ数と割当サーバ数とを比較する処理である。具体的には、ステップＳ１２０６とステップＳ１２０７で選出したサーバの部分集合の数が分析パターンに設定された割当サーバ数（８０５）以上であればステップＳ１２０９へ進み、割当サーバ数（８０５）以上でなければＳ１２０４に進む。ステップＳ１２０９では空リソース量が大きい順に割り当てるサーバを選択する処理である。空リソース量は（総コア数−割当済コア数）／総コア数＋（総メモリ量−割当済メモリ量）／総メモリ量で定義される。ステップＳ１２０５〜ステップＳ１２０９の処理により、リソースに空きがあるサーバに割り当て可能な分析パターンが順次、自動的に割り当てられるため、デプロイに関する作業時間が削減される。さらに、サーバ間の負荷が平準化される。
【００４４】
ステップＳ１２１０は、分析パターンのクラスタを作成する処理である。ステップＳ１２１１は、分析パターンに設定したパラメータ８０３を取得する処理である。ステップＳ１２１２は、ステップ１２１１で取得したパラメータを用いて分析実行コマンドを実行する処理である。ステップＳ１２１３では分析パターン設定ファイル２１２に設定した全ての分析パターンが実行開始済みであれば処理を終了し、そうでなければ繰り返し処理の始めに戻る。
【００４５】
図１３はステップＳ１２１０（クラスタ作成処理）の詳細を示す図である。
ステップＳ１３０１は、分析パターン設定ファイル２１２に設定した割当サーバ数（８０４）の数だけ内部の処理（ステップＳ１３０２〜ステップＳ１３０７）を繰り返す。ステップＳ１３０２は、割当サーバがステップＳ１３０１の繰り返しの先頭サーバであるかどうかを判断する処理である。ステップＳ１３０２の判断の結果、先頭のサーバであればステップ１３０３に進んで分析パターンクラスタ１０６の作成コマンドを実行し、先頭のサーバでない場合はステップＳ１３０４に進んで分析パターンクラスタ１０６へのクラスタ参加コマンドを実行する。ステップＳ１３０５は、稼働情報テーブル１５０４を参照して、割当サーバにおいて既に他の分析アプリケーションコンテナが稼働しているかどうかを判断する処理である。既に他のアプリケーションコンテナが稼働している場合（すなわち稼働中の分析アプリケーションコンテナ数が「１」以上）はステップＳ１３０６に進み、そうでない場合はステップＳ１３０１に戻るか、または処理を終了する。
【００４６】
ステップＳ１３０６は、分析パターン設定ファイル２１２に設定したディスクアクセス優先度８０７に基づいて、分析アプリケーションサーバ１０５における各分析アプリケーションコンテナ７１１のディスクアクセス比率を再設定する処理である。各コンテナのディスクアクセス比率は、コンテナのディスクアクセス優先度／同一サーバ上の全コンテナのディスクアクセス優先度の総和で計算される。ステップＳ１３０６の処理により、同一サーバ上で複数のコンテナが稼働する場合でも、優先度の高い分析パターンがディスクを優先して使用することが可能になる。
【００４７】
図１４は分析パターンクラスタ１０６における分析実行処理のフローチャートを示す図である。ステップＳ１４０１は、分析フローを実行する処理である。ステップＳ１４０２は、分析ステータステーブル１５０２の分析ステータスを実行中に更新する処理である。ステップＳ１４０３は、分析フローによる分析が完了したかどうかを判断する処理である。完了である場合はステップＳ１４０４に進み、完了でない場合はステップＳ１４０３を繰り返す。ステップ１４０４、分析ステータステーブルの分析ステータスを完了に更新する処理である。
【００４８】
図１９は、分析アプリケーションサーバのリソースの表示と、分析パターンの設定を行う表示画面の例を示す。
表示画面１６０１は、領域１６０２〜１６０４から構成される。領域１６０２は分析アプリケーションサーバ１０５のリソース情報、例えば、分析パターンが使用するコア数と、メモリ量と、ステップＳ１３０６でコンテナに設定されたディスクアクセス比率を表示する。領域１６０３は分析パターンの設定をする領域である。領域１６０３の設定は入出力装置２０３からの入力によるが、分析パターン設定ファイル２１２の生成によって行うこともできる。領域１６０４は、ステップＳ１００４の処理によって出力されるエラーの内容をメッセージとして表示する領域である。
なお、この画面は、分析管理サーバ１０１が有する入出力装置の表示器に表示させずに、分析管理サーバ１０１以外の他の装置に表示されてもよい。
【００４９】
以上述べたように、本発明の好ましい実施例によれば、１つのサーバ上で複数の分析アプリケーションが稼働する状況でも合理的なリソースの配分が可能となる。これにより、複数の分析パターンを並列実行するためのデプロイが効率化され、単位時間に実施できる分析パターンの数を増やすことができる。
【００５０】
なお、本発明は上記実施例に限定されることなく、種々変形して実施できる。
例えば、図１に示すデータ処理システムでは、分析管理サーバ１０１、分析アプリケーションイメージ管理サーバ１０２、管理ＤＢサーバ１０３、データレイクサーバ１０６、等をそれぞれ個別のサーバとして構成しているが、変形例によれば、これらのサーバを統合することが可能である。例えば分析アプリケーションイメージ管理サーバ１０２と管理ＤＢサーバ１０３を１つのサーバに統合することも可能である。また、他の例として、管理ＤＢサーバ１０３が持つテーブル類を分析管理サーバ１０１に持たせてもよい。
【００５１】
更に他の変形例として、分析パターン２１２が規定する内容は一例であって、種々変形が可能である。例えば、上記分析パターンでは、リソースとして、サーバ１台あたりの割当コア（ＣＰＵ）数８０５、割当メモリ量８０６と、ディスクアクセス優先度８０７を規定しているが、必ずしもこれら全ての要素を必要としない場合にはその要素を減らすことができる。一方、必要な場合には他の要素を追加してもよい。
【００５２】
更に他の変形例として、分析パターンを作成するための入出力装置は、必ずしも分析管理サーバ１０１が備えるものに限らず、ネットワークを介して分析管理サーバに繋がる端末装置であってもよい。
【符号の説明】
【００５３】
１０１：分析管理サーバ
１０２：分析アプリケーションイメージ管理サーバ
１０３：管理ＤＢサーバ
１０４：データレイクサーバ
１０５：分析アプリケーションサーバ
１０６：分析パターンクラスタ
１０７：通信設備網
２１１：分析管理プログラム
２１２：分析パターン設定ファイル
３１１：分析アプリケーションイメージ
４０１：分析連携アプリケーション
４０２：分析フロー
４０３：分析エンジン
６１１：データレイク
７１１：分析アプリケーションコンテナ
８０１：分析パターン
８０２：分析フロー
８０３：分析パラメータ
８０４：割当サーバ数
８０５：割当コア数
８０６：割当メモリ量
８０７：ディスクアクセス優先度
１５０１：分析パターンテーブル
１５０２：分析ステータステーブル
１５０３：サーバ情報テーブル
１５０４：稼働情報テーブル
【図１】
2019106031.tif 000003
【図２】
2019106031.tif 000004
【図３】
2019106031.tif 000005
【図４】
2019106031.tif 000006
【図５】
2019106031.tif 000007
【図６】
2019106031.tif 000008
【図７】
2019106031.tif 000009
【図８】
2019106031.tif 000010
【図９】
2019106031.tif 000011
【図１０】
2019106031.tif 000012
【図１１】
2019106031.tif 000013
【図１２】
2019106031.tif 000014
【図１３】
2019106031.tif 000015
【図１４】
2019106031.tif 000016
【図１５】
2019106031.tif 000017
【図１６】
2019106031.tif 000018
【図１７】
2019106031.tif 000019
【図１８】
2019106031.tif 000020
【図１９】
2019106031.tif 000021
【図２０】
2019106031.tif 000022