JP6201053B2

JP6201053B2 - 素性データ管理システム、および素性データ管理方法

Info

Publication number: JP6201053B2
Application number: JP2016535600A
Authority: JP
Inventors: 康志宮田; 啓朗室; 室　　啓朗; 茂木　和彦; 和彦茂木
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2014-07-25
Filing date: 2014-07-25
Publication date: 2017-09-20
Anticipated expiration: 2034-07-25
Also published as: WO2016013099A1; JPWO2016013099A1

Description

本発明は、素性データ管理システム、および素性データ管理方法に関する。

データベースに蓄積したデータセットに対して、異常値検出や将来予測などの分析を継続的に行い、その結果得られた知見を業務適用する試みがなされている。分析は複数の処理から構成されており、データセットに対して、データ形式の一致や精度の変更を目的とするクレンジング処理、状態判定のための指標を抽出する統計処理、状態判定のためのモデルを作成するモデル化処理など様々ある。継続的な分析では、分析結果データセットや分析結果に至るための中間データセットを分析内容とともに共有／再利用することで分析作業を効率化できる。ただし、共有／再利用には、結果導出のための処理内容、処理内容に対する入力対象データセット、その抽出条件などを分析の素性である素性データとして管理し、検索可能とすることが求められる。

特開２０１１−１６４６７９

特許文献１では、統計処理を例として、分析結果である処理結果データセットから処理前のデータセットである入力対象データセットを検索して再利用可能としている。再利用方法の一例として、前記入力対象データセットに対して実行する処理内容を変更して、観点の異なる処理結果データセットを取得する方法を開示している。しかし、特許文献１では複数の処理から構成される分析を想定していない。つまり、クレンジング処理や統計処理から構成されるような入力対象データセットを生成するための前処理方法を変更するシステムは開示されていない。従って、入力対象データセットを変更することによる別観点での分析は試行できない。また、別観点で分析を試行する際に変更すべき処理を、特定することもできない。例えば、別観点での分析のためには、分析者自身が集計期間やサンプル数を変更する際には、前処理を実施する前の元データセットや、集計期間やサンプル数から変更すべき値や変更方法を探し出す必要があった。

本発明では、処理内容および入力対象データセットだけでなく、入力対象データセット生成のために必要な前処理に関わる素性データを管理、検索可能とし、検索した素性データを変更することで入力対象データセットを変更して、別観点での分析を可能とする素性データ管理システムを提供することを目的とする。

上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、
結果データを作成するための素性データを管理するシステムであって、結果データを作成するために使用された処理クエリの処理内容、基データ、及び基データを抽出するための抽出条件を結果データの素性データとして抽出する処理解析部と、処理クエリを実行した結果の出力データが他の処理クエリの入力として使用されたかどうかを判断し、他の処理クエリの入力として使用された場合は入力データの素性データ変更回数をカウントアップし、他の処理クエリの入力として使用されなかった場合は出力データを結果データとする処理履歴階層抽出部と、
前記基データ、素性データ、結果データ及び結果データが作成されたときの素性データ変更回数を対応づけて格納する素性データ管理部とを備えることを特徴とする素性データ管理システムを提供する。

本発明によれば、処理内容の入力となる入力対象データセット生成のために必要な前処理に関わる素性データを管理し、検索可能とすることで、観点を変更しての分析で必要な入力対象データセットの変更方法を共有／再利用可能とし、分析作業効率を向上させることができる。上記した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。

素性データ管理システム処理履歴表の例ＳＱＬ実行履歴の例処理履歴抽出フロー素性データ変更頻度抽出フロー素性データ変更回数表の例分析変数管理表の例分析素性データ検索画面の例分析および素性データ検索フローインシデント関連素性データ特定フロー素性データ範囲管理表の例素性データ時間分類管理表の例素性データ地理分類管理表の例素性データ精度分類管理表の例素性データ時間分類処理フロー素性データ精度分類処理フロー処理結果データセットキャッシュ管理システムキャッシュ判定フロー処理結果データセットキャッシュ管理画面例

本実施例では、複数の処理から構成される分析処理から、処理履歴と処理に関わる素性データを抽出して管理する素性データ管理システムの例を説明する。

ここで対象とする分析処理は複数の処理から構成されており、データベースから対象データセットを抽出する抽出処理、前記対象データセットを分析アルゴリズムの入力に適した形式に変換する前処理、前処理されたデータセットに分析アルゴリズムを適用し知見を抽出する分析適用処理から構成される。なお、それぞれの処理は単一だけでなく、複数の処理から構成されることもある。

具体的に、抽出処理ではデータベースに蓄積されたデータセットを期間や、データを生成した機器（センサ）のＩＤにより抽出する。前処理では、データセットに対してサンプリングや欠損値の補間処理などを実施する。分析適用処理では、例えば、前処理を実施したデータセットに対して、ヒストグラム化後に、通常時のデータセットの変動傾向として変動モデルを生成する。また、異常値や特異値を判定するためには、前記の変動モデルと特定期間のデータセットを比較し、値のかい離が一定以上かを検査する処理を実行する場合もある。

これら一連の分析処理では、１回の抽出条件設定や分析のためのパラメータ設定で最終結果まで導出できるとは限らない。変動モデル導出のためにパラメータを変更することや、特異値検出において設定期間や閾値を変更する、などの試行錯誤を伴う。

一方、前処理やその他処理時の条件設定ミスのため、条件を変更して再処理を繰り返すといったやり直しも発生する。この試行錯誤とやり直しでは、処理を繰り返す点では同一であるが、再利用者にとっての価値が変わる。試行錯誤では、観点を変える繰り返しにより分析結果に対する知見を蓄積できるが、やり直しでは、意味のある分析結果を得られておらず知見を蓄積する効果は低い。

そのため、結果から知見を得る分析作業を効率化するには試行錯誤時の変更点を共有／再利用可能とし、処理を失敗して途中で処理を中止してやり直したような、やり直しは除外するか、再利用の優先度を低くすることが望ましい。

以降では、処理履歴から素性データを抽出する際、最終結果となる分析結果に対して、観点を変えて再導出する試行錯誤に関わる素性データの重要度を高く、最終結果となる分析結果に至らないやり直しに関わる素性データの重要度を低く管理する素性データ管理システムの具体的な処理を示す。

以降の説明では、「ｋｋｋ表」の表現にて情報を説明することがあるが、情報は、表以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ｋｋｋ表」を「ｋｋｋ情報」と呼ぶことができる。

また、「プログラム」や各種機能部を主語として処理を説明する場合があるが、プログラムや各種機能部は、プロセッサによって実行されることで、定められた処理を、適宜に記憶資源（例えば、メモリ）及び／又は通信インターフェイスデバイス（例えば、通信ポート）を用いながら行うため、処理の主語がプロセッサとされてもよい。逆に、プロセッサが主語となっている処理は、１以上のプログラムを実行することにより行われると解釈することができる。

図１に、実施形態に係る計算機システムの構成を示す。

計算機システム１００は、１以上の計算機を含んだシステムである。１以上の計算機は、少なくとも１つの物理計算機を含み、１以上の仮想計算機を含んでよい。計算機システム１００は、入力デバイス１１１、出力デバイス１１２、通信インターフェイスデバイス（Ｉ／Ｆ）１１３、記憶資源１０３及びそれらに接続されたプロセッサ１１０を有する。入力デバイス１１１及び出力デバイス１１２のうちの少なくとも１つは、計算機システム１００に接続された遠隔の表示用計算機（図示せず）に存在してもよい。

入力デバイス１１１は、１以上の入力デバイスであり、例えば、キーボード及びポインティングデバイスでよい。出力デバイス１１２は、表示デバイスを含む１以上の出力デバイスであり、例えば、液晶ディスプレイでよい。入力デバイス１１１及び出力デバイス１１２は、タッチパネルのように一体であってもよい。

Ｉ／Ｆ１１３は、１以上の通信インターフェイスデバイスであり、例えば、ＬＡＮ（Local Area Network）コントローラ及びＨＢＡ（Host Bus Adapter）のうちの少なくとも１つでよい。Ｉ／Ｆ１１３に、外部ストレージ装置１１４が接続される。外部ストレージ装置１１４は、ＳＳＤ（Solid State Drive）又はＨＤＤ（Hard Disk Drive）のような記憶デバイスであってもよいし、複数の記憶デバイスで構成された１以上のＲＡＩＤ（Redundant Arrays of Inexpensive （or Independent） Disks）グループを有するストレージ装置であってもよい。外部ストレージ装置１１４が、データ処理の対象となるデータセットを格納するデータベースを保持する。また、外部ストレージ装置１１４が無く、インメモリデータベースのように、データセットを記憶資源１０３に格納してもよい。

記憶資源１０３は、揮発性又は不揮発性メモリを含む１以上の記憶デバイスである。記憶資源１０３は、
データベースに保持したデータセットに対して実行した処理命令の履歴を管理するＳＱＬ実行履歴管理部１７０、ＳＱＬ実行履歴管理部で管理されるＳＱＬ実行履歴を解析する処理解析部１２０、解析された処理命令の履歴を管理する処理履歴管理部１３０、複数の処理履歴から処理経路や処理の階層を抽出する処理履歴階層抽出部１４０、ＳＱＬ実行の結果生成されるデータセットの素性を示す素性データを処理履歴から抽出し管理する素性データ管理部１５０、データセットや処理内容を検索キーとして受信し処理履歴と素性データを検索する分析素性データ検索部１６０、をプログラムとして保持する。

各プログラムのうち、ＳＱＬ実行履歴管理部１７０は、データセットに対して実行した処理命令をＳＱＬ実行履歴表として管理する。なお、ここで管理される処理命令の履歴はデータベースに保持したデータセットに対する処理命令であれば、ＳＱＬに限定せずともよい。また、処理解析部１２０は、実行されるデータ処理クエリを読み込んだ後に処理内容の抽出を行う処理内容抽出部１２１、処理内容に入力されるデータセットを抽出する入力対象データセット抽出部１２２、入力対象データセットの抽出条件を取得する抽出条件取得部１２３を持つ。また、素性データ管理部では、処理履歴から抽出した素性データを複数の表から構成される素性データ管理表群１５１にて管理する。素性データは多種多様であるため、多様な素性データを１つの表で管理する必要はなく、後述する素性データ変更回数表６００、分析変数管理表７００、素性データ範囲管理表１１００、素性データ時間分類管理表１２００、素性データ地理分類管理表１３００、素性データ精度分類管理表１４００といった複数の表により素性データを管理する。

分析素性データ検索部１６０は、受信した検索条件に合致する処理履歴を探索する処理履歴探索部１６１、処理の履歴において生成されるデータセットの素性を検索結果として提示する素性データ提示部１６２、分析に関連するデータと素性データを紐付けるインシデント紐付け部１６３から構成される。

処理履歴管理部１３０では、データセットに対して実行された処理の履歴を管理し、その処理経路を復元できる形式で管理する処理履歴表２００を保持する。その例を、図２の処理履歴表２００で示す。処理履歴表２００では、処理内容に対する入力対象データセット２０１、入力対象データセットに対するデータセット抽出条件である抽出条件２０２、前記抽出条件２０２で抽出したデータセットに対して実行する処理内容である処理内容２０３、前記入力対象データセット２０１、抽出条件２０２、処理内容２０３から一意に決まる出力データセットを示すＩＤ２０４から構成される。前記ＩＤ２０４は入力対象データセットの値として登録することが可能であり、入力対象データセットがＩＤ＝１であれば、ＩＤ＝１で示される処理の結果として出力されたデータセットをＩＤ＝２で示される処理の入力対象データセットとした処理経路を表現できる。さらに、処理内容により複数の入力が必要となる場合には入力対象データセットに複数の値を登録することが可能である。また、ＩＤ２０４で示されるデータセットはキャッシュすることも可能であり、キャッシュされたデータの有無を示すキャッシュ２０５とその実体へのリンク情報を示す実体リンク２０６を情報として持つ。なお、キャッシュ２０５と実体リンク２０６の詳細な説明は後述する。

図３はＳＱＬを用いて電力センサデータの異常値を発見する分析処理を実行した場合のＳＱＬ実行履歴例３００である。

本ＳＱＬでは、クエリＢ３０２に含まれるＭｏｖｉｎｇＡｖｅｒａｇｅやクエリＣ３０３に含まれるｈｉｓｔｏｇｒａｍといったユーザ定義関数を含むことができる。また、各ユーザ定義関数はＳＱＬ結果の複数行から構成されるデータセットを入力として取れることを前提としている。複数行から構成されるデータセットを表現する方法としては、ユーザ定義型の内部表現をデータセットとする方法や、集まり型を利用する方法がある。また、このＳＱＬ実行履歴は、分析を実行する分析者がＳＱＬを記述した履歴を使用してもよいし、分析アプリケーションを利用する際に分析アプリケーションが分析者の要求をデータベースに送付するためのＳＱＬに変換し、実行した履歴を用いてもよい。

このＳＱＬ実行履歴例では、電力センサデータから電力使用量の平均分布を導出し、その平均分布をモデルとして、異常値を導出する分析をクエリＡ３０１からクエリＤ３０４までの一連のクエリで実施している。具体的には、ＴｉｍｅＳｅｒｉｅｓと命名した電力センサデータが格納されたテーブルから２０１４年１月１日のデータセットを抽出するクエリＡ３０１、前記抽出したデータセットの前処理として移動平均を計算したデータセットを抽出するクエリＢ３０２、クエリＢ３０２で抽出したデータセットに対して電力の平均分布を計算するクエリＣ３０３、電力の平均分布から外れ値を探し出すクエリＤ３０４、が履歴として残る。クエリＥ３０５以降では、データセットの抽出期間を変更して同じ分析を繰り返す試行錯誤フェーズでのＳＱＬ実行履歴を示している。例えば、クエリＥ３０５では、クエリＡ３０１で抽出する期間を変更している。また、クエリＦ３０６では、クエリＢ２で移動平均を取得する間隔となるパラメータを変更して異常値を導出する分析を行う経緯がＳＱＬ実行履歴として保存される。

以降では、図３のＳＱＬ実行履歴例３００で示したような分析処理が実行された場合の処理履歴抽出処理と素性データを特定する処理を説明する。まずは、処理解析部１２０と処理履歴抽出部１４０が実行する処理履歴の抽出を図４のフロー図に従って説明する。

まず、処理解析部１２０はデータセットに対する処理命令であるデータ処理クエリを受信する（処理４０１）。受信したデータ処理クエリに対して、処理内容の解析を行うため、抽出対象のデータ処理クエリを一意に示すＩＤ２０４を付与し着目ＩＤとする（処理４０２）。なお、この着目ＩＤはデータ処理クエリが出力する第１のデータセットを一意に示すＩＤとして利用できる。続いて、データ処理クエリから処理内容を抽出し着目ＩＤと紐づける（処理４０３）。この処理内容は例えば、クエリＢ３０２であれば、ＭｏｖｉｎｇＡｖｅｒａｇｅであり、入力と出力を持つ関数である。また、クエリＡ３０１のように関数が無ければ処理内容が存在しないことを示す“−”を付与する。

その後、処理内容の入力となる入力対象データセット記述を特定する（処理４０４）。入力対象データセットは、例えば、クエリＡ３０１ではデータセットを抽出する対象となるＴｉｍｅＳｅｒｉｅｓである。クエリＢ３０２では、関数の入力であるＤａｔａＳｅｔ１である。続いて、存在すれば、データセットの範囲を限定する抽出条件を抽出し着目ＩＤと紐づける（処理４０５）。処理４０６では、ここまで特定した入力対象データセット記述部分を解析し、入力対象データセットが別処理の出力となる第２のデータセットと一致するか判定する。一致すれば、処理４０７に進み、一致しなければ処理４０８に進む。

なお、入力対象データセットと第２のデータセットの一致を判定するには、例えば、クエリ実行結果を一時的に格納する一時表が持つ情報を利用する。具体的には、クエリ実行結果として、一時表に追加したデータセットの行番号の開始と終了をＳＱＬ実行履歴例３００の各クエリと紐付けておき、同じ開始と終了の行番号を持つデータセットが入力となった場合に同一と判定する。もしくは、クエリ実行結果のデータセットをユーザ定義型や集まり型で表現し、それを一意に示すＩＤを付与する。クエリの入力にもユーザ定義型や集まり型で示したデータセットを許可し、同じＩＤを持つユーザ定義型や集まり型で示したデータセットが検知されれば一致したと判定する。

処理４０７では、入力対象データセットとなる第２のデータセットを生成する処理を一意に特定するＩＤを取得し、入力対象データセットに追記し、処理を終了する。処理４０８では、入力対象データセット記述部分に記述された入力対象データセット名を入力対象データセットに追記し処理を終了する。

以上の処理を、処理履歴が増加するごとに実行することで図２に示す処理履歴表を生成する。なお、キャッシュ２０５、実体リンク２０６については後述する。

続いて、素性データ管理部１５０が実行する素性データ変更頻度の抽出処理を図５のフロー図に従って説明する。

まず、処理履歴管理部１３０で管理する処理履歴表２００から１行データを取得する（処理５０１）。次に、取得したデータに含まれる入力対象データセットがＩＤか判定する（処理５０２）。ＩＤであれば、処理５０７に進む。ＩＤでなければ処理５０３に進む。処理５０３では、ＩＤからたどることのできる末端の処理内容を分析目的とし、入力対象データセットと分析目的を組み合わせた情報を分析組合せとして保存し処理５０４に進む。ここで、末端の処理内容とは、その処理内容の出力が他の処理内容の入力となっていない処理内容である。図２の処理履歴表では、入力対象データセットに出現しないＩＤ行に所属する処理内容である。

分析組合せは例えば、素性データ管理表群１５１の一部である図６に示す素性データ変更回数表で保存する。図６の素性データ変更回数表では、分析組合せを「分析目的 - 入力対象データセット」という形式で保持する。処理５０４では、入力対象データセットから分析目的に至る処理履歴に含まれる抽出条件、または引数を含む処理内容を素性データ表現として抽出し保存し、処理５０５に進む。例えば、図６の素性データ変更回数表に保存する場合には、抽出条件、または引数を含む処理内容を素性データ表現６０２に記憶する。この際、素性データの抽出条件や処理内容の引数は変数であり、分析ごとに異なる可能性がある。この変数を分析変数とし、分析変数に代入された値を別途、素性データ管理表群１５１の一部である図７に示すような分析変数管理表で管理する。図７では、素性データ表現６０２に含まれる１または複数の組合せを分析変数７０１に保持し、分析変数７０１の値を素性データ値７０２として管理する。以上の処理により、素性データを記憶していく。

処理５０５では、抽出した分析組合せと素性データ表現の組合せが既に記憶されているか判定する。ここでは、図６の素性データ変更回数表と図７の分析変数管理表を組み合わせて、分析組合せと素性データ表現の組合せを復元して判定する。既に記憶されていれば素性データに変更なしとして、処理５０７に進む。記憶されていなければ、新たな素性データと判定し、処理５０６に進む。処理５０６では、分析変数７０１の素性データ値７０２に値を追加し、素性データ変更回数に１加算した後に処理５０７に進む。

以上の実施例における処理により、処理内容の入力となる入力対象データセット生成のために必要な前処理に関わる素性データを管理できる。分析者は図６で示す分析組合せから実施したい分析を探し出し、素性データ表現および素性データ変更回数を取得できる。分析観点を変更する際には、素性データ表現からデータセットの変更方法を再利用でき、素性データ変更回数から優先または着目すべき変更箇所を特定できる。以上の素性データ管理により、分析を共有して再利用する際の作業効率を向上させることができる。

実施例１の素性データ変更回数６０３を参照することで、試行錯誤の分析を実施する際に分析観点を変更する際の着目箇所を知ることができる。一方、分析観点が決まっている分析では、分析観点と素性データ表現６０２を結びつけ、分析において変更すべき素性データを特定できる必要がある。

例えば、発生した期間と場所が既知の停電に対して、その原因を電力センサデータの分析で特定する場合がある。この原因分析では、特定の期間と場所に着目した電力センサデータに対して、異常値判定を行う。その際に、特定の期間と場所への着目するために変更対象となる素性データを特定する必要がある。

上記課題の解決のため、着目対象の素性データで分析を絞り込む機能を持つ素性データ管理システムを提供する。本実施例に関わるシステム構成は図１である。

図１の素性データ管理システムは、出力デバイス１１２を介して分析を検索するユーザに図８に例示する分析素性データ検索画面を提示する。ユーザは、分析素性データ検索画面で分析の検索要求や素性データによる絞り込み要求を入力し、分析や素性データを取得する。その後、素性データを用いて、分析観点を変更、または再利用する分析を絞り込む。

以降では、図８の分析素性データ検索画面を利用した分析および素性データの検索、または素性データの絞り込みの例を説明する。初めに、分析および素性データの検索について、図８の画面例および図９の処理フローに従って説明する。

なお、図８は分析素性データ検索部１６０が出力デバイス１１２を介して分析者に提供する画面例である。まず、分析者が分析対象データ選択８０１と分析目的（関数選択）８０２の選択フィールドから分析対象データと分析目的を選択する。分析対象データは例えば関係データベースに格納されているデータであれば、テーブル名を選択可能としてもよいし、ファイル形式でデータセットが格納されているのであれば、ファイル名を選択可能としてもよい。また、分析対象データを追加するために、参照ＤＢ追加ボタン８０３を押下し分析対象データが格納されているＤＢを追加してもよい。分析目的は、ユーザが実行したい処理内容を選択する。この処理内容は処理実行のための関数名を表示して選択させてもよい。これら検索条件を設定した後に検索ボタン８０４を押下すると分析素性データ検索部１６０が検索を開始する。

分析素性データ検索部１６０は、分析対象データと分析目的を検索条件として受信することで検索処理を開始し、処理９０２に進む（処理９０１）。処理９０２では、素性データ管理部１５０で管理する素性データ変更回数表６００に分析対象データと分析目的の組合せが一致する分析組合せが存在するか判定する。存在しなければ、検索結果なしとして処理を終了する。存在すれば、処理９０３に進む。処理９０３では、素性データ提示部１６２が分析組合せに対する素性データを素性データ変更回数順に提示する。その後、分析履歴を表示するために処理９０４に進む。処理９０４では、図２の処理履歴表において、分析目的を処理内容として持つレコードを起点とし、入力対象データのＩＤをたどることで到達可能な処理内容と素性データのリストを処理履歴探索部１６１が抽出する。その後、処理９０５では素性データ提示部１６２が前記抽出したリストにおいて、分析対象データが入力対象データとして記憶されている分析履歴を分析内容と素性データとともに表示し処理を終了する。

以上の分析素性データ検索部１６０で検索された分析素性は素性データ提示部１６２が図８の分析素性データ検索画面に表示する。処理履歴の異なる複数の検索結果が存在する場合は、処理履歴が異なる検索結果をタブ選択で切り替えられるように構成してもよい。

図８の例では素性データ提示部１６２が素性データ変更回数表８０５を画面に表示している。素性データ変更回数表８０５では、分析組合せと素性の種類、素性データ変更回数を提示する。さらに、分析において素性データ変更を要求する際のチェックボックスとなる変更も提示する。この変更にチェックを入れると素性データ変更のための変更候補選択８０７が出現する。なお、この画面例では図２、図６、図７で例示した処理履歴や素性データ変更回数で使用される文字列をユーザが理解しやすいよう処理関数名と処理名を変換する辞書を用いて文字列を変換した例を示している。

素性データ変更回数８０５の下部に素性データ提示部１６２が処理履歴チャート８０６を表示する例を示している。この処理履歴チャート８０６では、分析対象データを起点とし、分析目的を終点とした処理チャートを表現している。チャートを構成する各ブロックではデータセットの抽出や実行した処理内容を表現している。なお、素性データ変更回数８０５で素性データを変更するために選択した変更箇所が、処理履歴チャート８０６にもチェックされて表示される例を示している。この例では、電力使用量のデータセットの抽出条件を変更するためにチェックボックスをチェックし、そのチェックが処理履歴チャート８０６に反映され、かつその変更候補選択８０７が提示されている例である。ユーザはこの変更候補選択８０７から変更内容を実施し、表示された分析を再実行することで、素性データを変更した分析を試行できる。この変更候補選択８０７の画面を表示するためには、素性データ管理表群１５１の一部である素性データ範囲管理表１１００や素性データ地理分類管理表１３００を用いる。素性データ範囲管理表１１００を用いた場合には、データセットの抽出条件として変更可能な値範囲を提示できる。素性データ地理分類管理表１３００を用いた場合には、データセットの生成元を地理情報やグループの情報により変更することが可能となる。これら情報の生成方法については後述する。

分析を実施する際には、分析対象データと分析目的の他に、分析を実施する要因となったインシデント情報が存在することがある。インシデント情報とは例えば、電力の停電情報であり、停電が発生した場合に期間や場所情報を保存し、その期間や場所を元に対象のデータセットを特定して、停電の原因を分析する。

図８に分析を実施する際の観点となるインシデント情報８０９を示す。このインシデント情報から着目すべき素性データを提案、または絞り込む処理を図１０のフローに従って説明する。

このインシデント情報は例えば、分析者が図８の画面に示すインシデント登録ボタン８１０を押下して、素性データ管理システムにインシデント情報をアップロードしても良いし、素性データ管理システムの構成情報にインシデント情報を格納するデータベースを登録し、定期的にインシデント情報を取得し、素性データ管理部１５０で管理してもよい。

このインシデント情報を用いた処理では、まず、分析素性データ検索部１６０に含まれるインシデント紐付け部１６３がインシデント情報を取得する（処理１００１）。次に、インシデントに含まれる期間、場所、状態などを示すメタデータを取得する（処理１００２）。期間情報は日時、日付など時刻に関連する情報である。場所情報は、地名を示す辞書情報を参照して場所情報を抽出してもよい。また、データベース設計時に事前に期間、場所、状態に関する辞書を登録し、その情報を用いてメタデータを取得してもよい。

続いて、インシデント紐付け部１６３は検索対象となった分析対象データセットを取得する（処理１００３）。この分析対象データセットに前記取得したメタデータが含まれるか確認する（処理１００４）。含まれていれば、処理１００６に進む。含まれていなければ処理１００５に進む。処理１００５では、インシデントに関連するデータが不足している可能性があると警告し処理を終了する。処理１００６では、メタデータが含まれる分析対象データセットのデータ種類を特定する。データ種類とは、データが関係データベースにおいてテーブルで管理されていれば、テーブルの列名がデータ種類である。特定した後は、そのデータ種類をインシデントに関連する素性データとして提示する（処理１００７）。

例えば、図８においてユーザがインシデント登録ボタン８１０を押下することで電力の停電情報であるインシデント情報８０９を登録する。その後、分析素性データを検索した際に、インシデントに含まれる期間と場所情報と同一のデータが、分析対象データセットに含まれることを検知する。検知したデータを素性データとして変更できる素性として、抽出と記述されたブロックを特定し、ユーザに提示することが可能となる。

以上の実施例における素性データ管理システムにより、分析履歴と素性データを検索可能となるだけでなく、インシデント情報を元に、インシデントを分析するために着目すべき素性データの絞り込みが可能となる。

分析素性データ検索により、分析に関わる処理に含まれるデータセットの抽出条件や引数を含む処理内容を検索できる。他者の分析を利用する際に、他者が設定したデータセットの抽出条件や、引数を含む処理内容を参照しても何を意図しているか把握することは困難な場合がある。

上記課題の解決のため、素性データの理解を支援するメタデータを付与する機能を持つ素性データ管理システムを提供する。本実施例に関わるシステム構成は図１であり、素性データ管理部１５０が、処理履歴抽出部１４０が実施した処理履歴抽出処理の結果として生成した素性データ変更回数表６００の情報を用いて、収集された素性データを分類する。

以降では、素性データ範囲管理表１１００、素性データ時間分類管理表１２００、素性データ地理分類管理表１３００、素性データ精度管理表１４００を生成する処理について説明する。なお、これらの表は素性データ管理部１５０が管理する素性データ変更回数表６００に新たな素性データ表現６０２が追記された契機で、素性データ管理部１５０が素性データ範囲管理表を生成する処理を開始する。

図１１の素性データ範囲管理表は、素性データが取りうる値範囲を管理する例である。素性データ変更回数表で管理する分析組合せに含まれる分析対象データセットであるＴｉｍｅＳｅｒｉｅｓに着目し、素性データ範囲を抽出する。ＴｉｍｅＳｅｒｉｅｓには情報として時間(Time)や機器情報(Sensor)を保持するとする。素性データ管理部１５０が、これら情報が取りうる値を、ＴｉｍｅＳｅｒｉｅｓのデータセットが格納されるデータベースから抽出して、素性データが取りうる値の範囲情報として管理する。これにより素性データの変更可能な値範囲を素性データとして示すことができる。なお、図１１の例では、素性データ種類Ｔｉｍｅは２０１０年１月１日から２０１４年６月１日までのデータを保持することを示す。また、Ｓｅｎｓｏｒは１〜１０００のＩＤが付いたセンサのデータを保持することを示す。

この素性データ範囲管理表の情報は例えば、図８の分析素性データ検索画面で利用される。分析者が分析と素性データを検索し、値に対する素性データを変更するように選択した場合に、変更候補選択８０７に素性データとして取りうる値範囲を表示する。これにより、分析者は分析対象データセットに対して、最大値と最小値の検査をすることなく変更可能な値範囲を知ることができる。

統計処理や分析処理を実施する場合、半日単位、１日単位、１週間単位など、時間を特定範囲に区切って平均値や変動傾向を導出する。データ処理に関わるデータセットの素性データとして時間単位観点で分類して管理する。その分類の具体例を図１５の素性データ時間分類処理フローに従って説明する。

まず、素性データ管理部１５０が、入力対象データセットの抽出条件に時間範囲指定が含まれているか確認する（処理１５０１）。この時間範囲指定は、ＡＡＡ時間からＢＢＢ時間まで、やＣＣＣ時間ごとなど開始と終了時刻が特定できる条件指定方法を示す。これら時間範囲指定が含まれていなければ処理を終了し、含まれれば処理１５０２に進む。処理１５０２では、時間範囲の開始時刻と終了時刻を素性データとして抽出する。次に、開始時刻と終了時刻の差分時間が特定値か判定する（処理１５０３）。例えば、半日、１日、１週間などである。この値は、事前に設定しても良いし、繰り返し同じ差分時間が発生した場合、その差分時間が特定値であると利用実態から判定してもよい。この判定により、特定値でなければ処理を終了し、特定値であれば処理１５０４に進む。処理１５０４では、終了時刻を第２の開始時刻、終了時刻に差分時間を加えた時間を第２の終了時刻、とした素性データとする。この処理を終了時刻が素性データ範囲を超えるまで繰り返す（処理１５０５）。さらに、開始時刻を第３の終了時刻、開始時刻から差分時間を減算した時間を第３の開始時刻とした素性データとする処理も実施する（処理１５０６）。この処理も、開始時刻が素性データ範囲を超えるまで繰り返す（処理１５０７）。

以上の処理により図１２に示す、素性データを時間単位で分類した結果を得られる。なお、この時間単位を組み合わせて、より長い時間単位を合成してもよい。例えば、１日単位の素性データを７日間合成して１週間としてもよい。その情報を管理するため、合成元になった素性データに対して、合成先の素性データを示すＩＤを紐づける。これにより、データセットをどういった時間単位で集計して分析することができるかという観点を提供する素性データ管理を実現できる。

素性データを地理情報で分類することもできる。素性データが時間情報でなく、地理情報に紐付いた情報の場合に素性データを地理情報とともに管理することで、データ処理に利用するデータセットの地理情報に関わる素性を管理可能にする。

例えば、入力データセットの抽出条件として、センサＩＤを指定したとする。素性データ管理部１５０は、前記センサＩＤが含まれる情報を他の地理情報やグループを管理するデータベースから探索する。その結果、センサＩＤが地理情報のデータベースに存在し、センサＩＤ以外の地理情報に紐付くとわかれば、特定の住所や番地に存在するセンサ、または特定のフロアに設置されたセンサとしてグループ化できる。このような地理情報に関わるグループに関しても、素性データ管理部１５０が分類を行い、素性データ管理部で管理可能とする。図１３では、素性データとして個別のセンサがそのＩＤとともに管理され、各センサがどのグループに所属するかの情報をＧｒｏｕｐＩＤに持つ例を示している。例えば、グループ３は特定住所のマンションを示し、グループ１１は、マンションの２階を示す。

以上の管理により、地理情報に紐付いた素性データを、場所観点でのグループごとに分類して管理できる。場所観点で素性データを管理することで、データ分析を行う際に、地理情報によるデータの取捨選択や組合せ作成を検討することが可能となる。

この素性データ地理分類管理表の情報は例えば、図８の分析素性データ検索画面で利用される。分析者が分析と素性データを検索し、素性データであるセンサＩＤを変更するように選択した場合に、変更候補選択８０７に変更対象のセンサＩＤがどのグループに属すかの情報と、他のセンサＩＤのグループ情報を表示する。これにより、分析者は分析対象データセットに対して、同一グループに対象範囲を広げたり、別グループの情報を除外するなど分析観点の変更を行うことができる。

分析では、複数の処理の結果、目的のデータセットを得ることができる。その複数の処理は、処理履歴で管理され、処理履歴に含まれる処理内容自体が最終的に生成したデータセットの素性となる。この複数の処理では、処理内容の種類により最終的に得られたデータセットの信頼性や精度が変わってくる。この最終的に得られるデータセットの信頼性や精度を管理するため、処理過程で生成される中間データセットの信頼性や精度も素性データとして管理する。この処理内容と精度を素性データとして管理するための処理を図１６の素性データ精度分類処理フローに従って説明する。

素性データ管理部１５０が、素性データ表現６０２に処理解析部１２０で抽出した処理内容が含まれるか確認し、含まれれば前記処理内容を抽出する（処理１６０１）。その処理に入力データセット以外のパラメータが存在するか確認する（処理１６０２）。存在しなければ処理１６０４に進み、存在すれば処理１６０３に進む。処理１６０３では、前記パラメータをデータセットの信頼度や精度に影響のある素性データとして素性データ管理部に登録し、処理１６０４に進む。

処理１６０４では、処理内容が分析精度を下げるクレンジング処理であるか判定する。この処理判定では、事前にクレンジング処理と精度の上昇や下降を対応付けておいてもよいし、データセットの件数が減少する処理を精度下降、データセットの件数が上昇する処理を精度上昇、のクレンジング処理としてもよい。

精度下降であれば、処理１６０５に進み、精度が下降する処理として素性データを分類し、図１４の素性データ精度分類管理表に登録して処理を終了する。素性データ精度分類管理表には、入力対象データセット、処理内容、処理内容実施後の精度を下降か上昇かで登録する。

精度上昇であれば、精度が上昇する処理として素性データを分類し、図１４の素性データ精度分類管理表に登録した後に処理を終了する（処理１６０７）。どちらでもなければ、精度に関する素性データを登録せずに処理を終了する。

以上のデータセットの信頼度や精度観点で素性を分類することで、処理結果の信頼性や精度を把握した上で、処理履歴を再利用することが可能となる。

以上の実施例における素性データ管理システムにより、素性データにメタデータを付与することができる。分析を共有／再利用する分析者は素性データに紐付いたメタデータを取得することで、着目すべき素性データを絞り込み、分析作業を効率化することができる。

処理履歴を管理し、処理結果のデータセットや中間データセットも素性データとしてキャッシュしておけば、同一処理を実行した際、キャッシュから読み込むことで繰り返しの処理が不要となり、分析再利用のための時間を短縮できる。しかし、データ処理において出力データセットのサイズが大きいと、キャッシュからデータセットを読み出す処理に時間がかかり、データ処理負荷が低ければ、再び処理を実行する場合と比べて、高速化の効果が得られにくい。

そこで、出力データセットのサイズと出力データセットを導出するための処理負荷も素性データとして考慮し、素性データから高速化効果の高いと判別できるデータセットをキャッシュするキャッシュ管理システムを提供する。本実施形態に係る計算機システムの構成を図１７示す。図１７に示す計算機システムは、図１で示した素性データ管理システムに加えて、外部ストレージ装置に格納されたデータセットに対する処理を実行するデータ処理部１７１０、データ処理の結果を受信するデータアクセス部１７２０、受信したデータ処理の結果のデータセットをキャッシュするか否かを判定するキャッシュ判定部１７３０、を持つ。キャッシュ判定部は、処理負荷を取得する処理負荷取得部１７３１とデータセットのサイズを計測する処理結果データ量取得部１７３２を持つ。これらデータ処理部１７１０、データアクセス部１７２０、キャッシュ判定部１７３０により実施するキャッシュ判定を図１８に示すキャッシュ判定フローに従って説明する。

まず、データ処理部がデータ処理リクエストを受信する（処理１８０１）。この処理リクエストは例えば図３のＳＱＬ実行履歴例で示した各クエリである。前記受信を契機に処理負荷取得部が処理時間の計測を開始する（処理１８０２）。続いて、データ処理部が外部ストレージ装置に格納された処理対象のデータセットに対して処理を実行し、データアクセス部に処理結果データセットを受信させる（処理１８０３）。データアクセス部が処理結果のデータセットを受信した時点で処理負荷取得部は処理時間の計測を終了する（処理１８０４）。その後、キャッシュ判定部の処理結果データ量取得部が処理結果データセットのサイズを測定し、処理結果データセットサイズ、処理時間をキャッシュ判定部に送付する（処理１８０５）。以降では、キャッシュ判定部が処理時間と処理結果データセットのサイズを用いたキャッシュ判定を実施する。

処理１８０６では、処理結果データセットサイズをキャッシュに割り当てられたデータ容量で割り使用率を計算する。そして、その使用率が事前に設定した閾値以下か判定する（処理１８０７）。閾値以下でなければデータセットのサイズが大きすぎるとして、処理をキャッシュせずに処理を終了する。閾値以下であれば、処理１８０８に進む。処理１８０８では処理結果データセットをキャッシュした場合に、キャッシュからデータを読み込む際の予測性能を計算する。この性能の予測は、実測したデータ読み出し性能から計算してもよいし、計算機のカタログスペックから性能予測してもよい。続いて、処理負荷取得部により取得した処理時間を予測性能で割り、高速化率とする（処理１８０９）。この高速化率が閾値以上であれば、処理１８１１に進み、閾値未満であればデータセットをキャッシュせずに処理を終了する（処理１８１０）。処理１８１１では、データ処理内容をキーとして処理結果をキャッシュし、図２に示す処理履歴表に情報を追記して処理を終了する。なお、ここでのデータ処理内容とは、図２で示す入力対象データセット、抽出条件、処理内容から構成される情報であり、この処理結果データセットを示すＩＤとキャッシュされたデータセットを対応付ける。具体的には図２のキャッシュ２０５でキャッシュ有無を管理し、実体リンク２０６にはキャッシュへのアクセスポインタを管理する。以降、データ処理命令となるクエリに対して、処理解析部１２０が処理を入力対象データセット、抽出条件、処理内容と分解し、全てが一致したデータ処理があれば、データ処理部にて処理を実行せずにキャッシュに格納されたデータセットを返却する。

ここまでのキャッシュ判定での閾値判定で必要となった高速化率および使用率を管理する画面例を図１９に示す。本画面はキャッシュ判定部が出力デバイス１１２を介して提供する管理画面である。キャッシュ管理者は本画面を用い、キャッシュ判定部のキャッシュ可否の判定基準や、キャッシュ判定部がキャッシュを格納するデータストアを変更するキャッシュ管理を行う。図１９では、キャッシュルールを複数管理でき、ルール管理タブで、閾値となる高速化率および使用率を変更し、キャッシュ判定部に送付することができる。また、ルールを追加することも可能である。さらに、画面下にはキャッシュ容量を管理する画面を提供する。キャッシュとして利用するストレージはメモリの他、ＳＳＤ、ＨＤＤを利用でき、キャッシュ追加により任意のストレージをキャッシュとして利用できる。各キャッシュ用ストレージの情報が表示されており、全体容量のうち使用済みの容量を示す使用済み欄、キャッシュからデータを読み出す際の予測性能であるＲｅａｄ性能欄を備える。このＲｅａｄ性能欄は編集可能であり、管理者がＲｅａｄ性能を実測した値を入力してもよい。さらに、各ストレージに選択のためのチェックボックスを備え、各ストレージに対してキャッシュ判定ルールを設定できる。これらのキャッシュ管理画面で指定されたキャッシュ判定基準に従って、キャッシュ判定部はキャッシュ可否及びキャッシュ先のデータストアを判定する。

以上のキャッシュ管理システムを提供することで、結果データセットの量が様々ある複数の処理に対して、ストレージ使用量を浪費せずにキャッシュによる高速化効果の高い結果データセットを優先的にキャッシュできる。その結果、試行錯誤の分析において、繰り返し同じ結果データセットや中間データセットが発生する場合に、結果を得るまでの時間を短縮し、試行錯誤の分析作業時間を短縮することができる。

110:プロセッサ、111:入力デバイス、112:出力デバイス、113:I/F、114:外部ストレージ装置、120:解析部、121:処理内容抽出部、122:入力対象データセット抽出部、123:抽出条件取得部、130:処理履歴管理部、140:処理履歴抽出部、150:素性データ管理部、151:素性データ管理表群、160:分析素性データ検索部、161:処理履歴探索部、162:素性データ提示部、163:インシデント紐付け部、170:SQL実行履歴管理部、200:処理履歴表、300:SQL実行履歴表

Claims

結果データを作成するための素性データを管理するシステムであって、
結果データを作成するために使用された処理クエリの処理内容、基データ、及び基データを抽出するための抽出条件を結果データの素性データとして抽出する処理解析部と、
処理クエリを実行した結果の出力データが他の処理クエリの入力として使用されたかどうかを判断し、他の処理クエリの入力として使用された場合は入力データの素性データ変更回数をカウントアップし、他の処理クエリの入力として使用されなかった場合は出力データを結果データとする処理履歴階層抽出部と、
前記基データ、素性データ、結果データ及び結果データが作成されたときの素性データ変更回数を対応づけて格納する素性データ管理部とを備えることを特徴とする素性データ管理システム。
請求項１に記載の素性データ管理システムにおいて、
基データと処理クエリで使用された処理内容を受け付ける検索条件受付け部と、
受け付けた基データと処理内容に基づいて、前記検索条件受付け部により検索された素性データを素性データの変更回数が多い順に出力する素性データ出力部とを備えることを特徴とする素性データ管理システム。
請求項２に記載の素性データ管理システムにおいて、
前記素性データは少なくとも基データを選択するのに用いられた範囲条件と、基データの精度を決める処理に用いられたクレンジング処理条件とを含むことを特徴とする素性データ管理システム。
請求項１に記載の素性データ管理システムにおいて、
データのアクセス速度が速い高速記憶領域と前記高速記憶領域よりデータのアクセス速度が遅い低速記憶領域と、
結果データを作成するための処理負荷と結果データを高速記憶領域から読み出すための処理負荷の比率を計算し、結果データのデータ量に対する高速記憶領域の容量比率を計算し、アクセス高速化率と記憶領域利用割合の少なくとも一方が予め定められた閾値以下の場合に結果データを高速記憶領域に格納するアクセス高速化判定部とを備えることを特徴とする素性データ管理システム。
結果データを作成するための素性データを管理する方法であって、
処理解析部が結果データを作成するために使用された処理クエリの処理内容、基データ、及び基データを抽出するための抽出条件を結果データの素性データとして抽出し、
処理履歴階層抽出部が、出力データが他の処理クエリの入力として使用されたかどうかを判断し、他の処理クエリの入力として使用された場合は入力データの素性データ変更回数をカウントアップし、他の処理クエリの入力として使用されなかった場合は出力データを結果データとし、
素性データ管理部が前記基データ、素性データ、結果データ及び結果データが作成されたときの素性データ変更回数を対応づけて格納することを特徴とする素性データ管理方法。
請求項５に記載の素性データ管理方法において、
検索条件受付け部が基データと処理クエリで使用された処理内容を受け付け、
素性データ出力部が、受け付けた基データと処理内容に基づいて、前記検索条件受付け部により検索された素性データを素性データの変更回数が多い順に出力することを特徴とする素性データ管理方法。
請求項６に記載の素性データ管理方法において、
前記素性データは少なくとも基データを選択するのに用いられた範囲条件と、基データの精度を決める処理に用いられたクレンジング処理条件とを含むことを特徴とする素性データ管理方法。
請求項７に記載の素性データ管理方法において、
データのアクセス速度が速い高速記憶領域と前記高速記憶領域よりデータのアクセス速度が遅い低速記憶領域を備え、
アクセス高速化判定部が、結果データを作成するための処理負荷と結果データを高速記憶領域から読み出すための処理負荷の比率を計算し、結果データのデータ量に対する高速記憶領域の容量比率を計算し、アクセス高速化率と記憶領域利用割合の少なくとも一方が予め定められた閾値以下の場合に結果データを高速記憶領域に格納することを特徴とする素性データ管理方法。