<実施形態1>
本発明の第1の実施形態では、ストレージシステム2上で動作する各ソフトウェアユニットの動作状況やハードウェアリソースなどを所定の間隔で採取することで生成される統計値(データ、データ群)を、当該統計値の相関関係を利用して圧縮するデータ圧縮システム1(データ圧縮システム)について説明する。
図1を参照すると、本実施形態におけるデータ圧縮システム1は、ストレージシステム2と、統計値マイニング装置3(データ圧縮用相関関係抽出装置)と、統計値圧縮装置4と、を有している。また、ストレージシステム2と統計値マイニング装置3と統計値圧縮装置4とはネットワークを介して互いに通信可能なよう接続されている。そして、ストレージシステム2と統計値圧縮装置4とは、互いに通信可能なよう接続されている。
ストレージシステム2は、複数のサーバコンピュータが接続された構成を採っている。図2を参照すると、ストレージシステム2は、アクセラレータノード21(21a、21b、…。以下、特に区別しない場合はアクセラレータノード21とする)と、ストレージノード22(22a、22b、…。以下、特に区別しない場合はストレージノード22とする)と、を有している。また、ストレージノード22は、すべてネットワークを介して接続されている。一方で、アクセラレータノード21は、全てのストレージノード22と接続されているが、アクセラレータノード21間での接続はない。また、アクセラレータノード21は、顧客のサーバや統計値マイニング装置3、統計値圧縮装置4に接続されている。
アクセラレータノード21は、ストレージシステム2自体における記憶再生動作を制御するサーバコンピュータである。アクセラレータノード21は、ストレージシステム2へのゲートウェイとして機能しており、データアクセスAPIを提供する機能を有している。
ストレージノード22は、データを格納する記憶装置を備えたサーバコンピュータである。ストレージノード22は、アクセラレータノード21を介して取得したデータを保持することになる。
なお、ストレージシステム2は、アクセラレータノード21の代わりに、アクセラレータノード21としての特徴とストレージノード22としての特徴とを組み合わせたハイブリッドノードを有していても構わない。
また、アクセラレータノード21の数と、ストレージノード22の数とは、図2で示したものに限定されない。ストレージシステム2は、図2で示すよりも多くのアクセラレータノード21、ストレージノード22により構成されていても構わないし、少ないアクセラレータノード21、ストレージノード22により構成されていても構わない。
本実施形態におけるストレージシステム2は、上記のように、アクセラレータノード21と、ストレージノード22と、を有している。そして、アクセラレータノード21及びストレージノード22の両方のサーバで実行されるプロセスは、様々な統計値を収集している。具体的には、例えば、上記各サーバ上で動作する複数のソフトウェアユニットのそれぞれが統計値を収集する。ここで、本実施形態のストレージシステム2のようなシステムでは、各ユニット間で情報の送受信を行っている場合など、複数のユニットで同じような統計値が出現することがある。つまり、各ユニットは互いに協調して動作するため、あるユニットが収集した統計値と別のあるユニットが収取した統計値との間には相関関係がある場合がある。本実施形態におけるデータ圧縮システム1は、このような相関関係を利用して統計値を圧縮することになる。
なお、上記のように、アクセラレータノード21の動作とストレージノード22の動作とは異なる。そのため、アクセラレータノード21で収集される統計値とストレージノード22で収集される統計値とは必ずしも同じものではない。そこで、以下においては、ストレージノード22から収集された統計値を圧縮する場合について説明する。
この場合、ストレージシステム2は、アクセラレータノード21を介して、各ストレージノード22から収集した統計値を統計値マイニング装置3へと送信することになる。
なお、データ圧縮システム1が圧縮する対象は、ストレージノード22から収集した統計値に限定されない。データ圧縮システム1は、アクセラレータノード21から収集した統計値を圧縮するよう構成されていても構わないし、アクセラレータノード21及びストレージノード22から収集した統計値の両方を圧縮するように構成されていても構わない。
また、本実施形態におけるストレージシステム2は、ノード毎に統計値を収集して統計値マイニング装置3へと送信するよう構成されている。つまり、統計値マイニング装置3へと送信される統計値を含む1つのファイルには、1つのストレージノード22上の各ユニットが収集した統計値が含まれていることになる。しかしながら、本発明を実施する場合には、必ずしも上記のように構成されていなくても構わない。つまり、統計値マイニング装置3へと送信する統計値を含む1つのファイルには、複数のノード上の各ユニットが収集した統計値が含まれていても構わない。
統計値マイニング装置3は、ストレージシステム2から送信される統計値の集まりをマイニングして、異なる統計値の間の相関関係や1つの統計値の内的相関などの所定の相関関係(数的相関など)を探索する情報処理装置である。統計値マイニング装置3は、図示しない中央演算装置(CPU、Central Processing Unit)と、記憶装置(メモリ及びハードディスク)と、を備えている。統計値マイニング装置3は、記憶装置が備えるプログラムをCPUが実行することで、後述する機能を実現するように構成されている。
図3を参照すると、統計値マイニング装置3は、データ送受信手段31と、統計値データベース32と、ウィンドウ生成手段33(相関関係抽出手段と相関関係検証手段の一部でも構わない)と、相関関係抽出手段34と、相関関係検証手段35と、規則ファイル36と、を有している。
データ送受信手段31は、ストレージシステム2や統計値圧縮装置4と統計値や後述する規則の送受信を行う機能を有している。データ送受信手段31は、例えば、ストレージシステム2(統計値圧縮装置4を介していても構わない)から、当該ストレージシステム2の各ストレージノード22から収集された統計値(を含むファイル)を受信する。そして、データ送受信手段31は、受信した統計値を統計値データベース32に記憶する。また、データ送受信手段31は、例えば、後述する規則ファイル36が記憶する規則(検証された規則)を統計値圧縮装置4へと送信する。データ送受信手段31による規則の送信は、例えば、予め定められた周期が経過する毎に行われる。
統計値データベース32は、メモリやハードディスクなどの記憶装置である。統計値データベース32は、データ送受信手段31が受信した統計値を記憶している。そのため、統計値データベース32は、様々な異なる種類の統計値をファイルごと(ノードごと)に記憶していることになる。なお、統計値データベース32は、複数のファイルを一つにまとめて記憶しても構わない。
図4は、統計値データベース32が記憶する統計値の一例である。図4を参照すると、統計値データベース32は、例えば1つのファイル内に、ユニットAが収集した統計値A、統計値B、統計値C、統計値Dと、ユニットBが収集した統計値E、統計値F、統計値Gと、を記憶している。このように、統計値データベース32は、複数のユニットが収集した統計値を1つのファイル内に記憶している。
また、統計値データベース32は、例えば統計値Aのサンプル(データの値)として、10、20、10、15、12、13、14、16、15、14、を記憶している。一方で、統計値データベース32は、例えば統計値Eのサンプルとして、6、16、11、12、13、14、15、15、15、10、10、12、14、16、2、1、31、を記憶している。つまり、統計値データベース32は、統計値Aとして10個のサンプルを記憶する(統計値Aは10個のサンプルを有するデータ群である)一方で、統計値Eとして17個のサンプルを記憶している(統計値Eは17個のサンプルを有するデータ群である)。このように、統計値データベース32が記憶する各統計値のサンプルの数は、統計値ごとに異なっていても構わない。
ウィンドウ生成手段33は、統計値データベース32が記憶する統計値(を含むファイル)から相関関係を探索する対象となる範囲であるウィンドウ(局所化探索範囲)を生成する機能を有している。ここで、ウィンドウとは、すべての利用可能な統計値のサンプルの、一連の比較可能な同じ長さのシーケンスのことである。つまり、ウィンドウとは、各統計値に同数のサンプルがあるよう(データ群を構成するデータの値の個数がそれぞれ同数になるよう)に、相関関係の探索範囲を局所化したものである。そのため、ウィンドウの長さはそれぞれの統計値で同一のサンプルの数(例えば、10〜20。予め定められた数になる)であり、ウィンドウの幅は統計値の種類の数になることになる。なお、ウィンドウは、各サンプルを収集した時間に関する情報を含んでいても構わないし、含んでいなくても構わない。
ウィンドウ生成手段33は、例えば、図4で示す統計値を用いて、図5で示すウィンドウを生成する。図5を参照すると、ウィンドウ生成手段33は、図4で示す統計値を用いて、例えば長さ10で幅7のウィンドウを生成する。つまり、ウィンドウ生成手段33は、例えば、7種類の統計値のそれぞれが10個のサンプルを含むウィンドウを生成する。このように、ウィンドウ生成手段33は、1つのファイルを複数のウィンドウに分割することが出来る。そして、ウィンドウ生成手段33は、生成したウィンドウを相関関係抽出手段34と相関関係検証手段35へと送信する。
なお、ウィンドウ生成手段33は、例えば、各統計値を入手順に所定の数取得することで、ウィンドウを生成する。つまり、ウィンドウ生成手段33は、各統計値のサンプルのタイムスタンプを全く考慮せず、統計値データベース32に記憶されている順番に各統計値のサンプルを取得してウィンドウを生成する。このような方法によりウィンドウを生成することが考えられる。また、ウィンドウ生成手段33は、例えば、タイムスタンプを考慮してウィンドウを生成しても構わない。このように、ウィンドウ生成手段33は様々な方法を用いて統計値データベース32が記憶する統計値を用いてウィンドウを生成することが出来る。
また、ウィンドウ生成手段33は、過去に生成したウィンドウを再利用することが出来るように構成することが出来る。つまり、ウィンドウ生成手段33は、過去に生成した複数のウィンドウからランダムに統計値(サンプルの列)を取得し、当該取得したサンプルの列を用いて新しいウィンドウを生成するように構成することが出来る。さらに、ウィンドウ生成手段33は、統計値の種類の数を制限したウィンドウを生成するように構成することも出来る。
相関関係抽出手段34は、ウィンドウ生成手段33が生成したウィンドウ内の各統計値の関係に基づいた相関関係を抽出する機能を有する。また、相関関係抽出手段34は、各統計値から相関関係を抽出する際に、様々なヒューリスティックな手法を用いるように構成することが出来る。
具体的には、本実施形態における相関関係抽出手段34は、ウィンドウ内の各統計値のサンプルから定数の相関と同一性の相関と和の相関とを抽出する。また、相関関係抽出手段34は、定数の相関と同一性の相関を探索した際にヒューリスティックな手法を実行する。
以下、図5で示すウィンドウの一例を用いて、相関関係抽出手段34が相関関係を抽出する際の動作の一例を説明する。
まず、相関関係抽出手段34は、定数の相関を抽出する。図6を参照すると、統計値Gの各サンプルは全て7である。つまり、統計値Gは定数であると考えられる。そこで、相関関係抽出手段34は、統計値Gに定数の相関を発見する(統計値G=定数の規則があることを発見する)。また、相関関係抽出手段34は、ヒューリスティックな手法の一つとして、当該発見した定数の相関を有する統計値Gをウィンドウから除去する。つまり、相関関係抽出手段34は、予め定められた種類の相関関係として定数の相関を見つけた場合、当該定数の相関を有する統計値をウィンドウから除去する。これにより、ウィンドウ内には統計値Aから統計値Fの6つの統計値が残ることになる。
次に、相関関係抽出手段34は、同一性の相関を抽出する。具体的には、相関関係抽出手段34は、例えば、図7で示すような方法を用いて同一性の相関を抽出する。図7を参照すると、相関関係抽出手段34は、まず、ウィンドウ内の各統計値のサンプルの列を辞書的な順番に並び替える。つまり、相関関係抽出手段34は、ウィンドウの左に位置するサンプルの数から順番にみて、より小さな数を持つ統計値がより上に来るように各統計値のサンプルの列を並び替える。そして、相関関係抽出手段34は、ある統計値のサンプルの列と一つ下に位置する統計値のサンプルの列とを比較することで、予め定められた基準に基づいて同一であると判断される統計値の組を発見する。ここで、同一であると判断される予め定められた基準とは、例えば、統計値を構成する各サンプルと別の統計値を構成する各サンプルとが完全に同一である場合を指す。また、同一であると判断される予め定められた基準としては、例えば、ある統計値のサンプルの列と別の統計値のサンプルの列の隣り合うサンプルの有限差分とが等しい場合を含むことが出来る。例えば、図7で示すように、統計値Aと統計値Bとは各サンプルの値が全て等しい。そのため、相関関係抽出手段34は、統計値Aと統計値Bとに同一性の相関があると判断する(統計値A=統計値Bの規則があることを発見する)。また、例えば、図7で示すように、統計値B又はAの各サンプルの値と統計値Cの有限差分であるd統計値Cの値は等しい。そこで、相関関係抽出手段34は、統計値B又はAとd統計値Cとの間に同一性の相関があると判断する(統計値B=d統計値C、統計値A=d統計値Cの規則があることを発見する)。
上記のような処理により、相関関係抽出手段34は、同一性の相関を抽出する。その後、相関関係抽出手段34は、ヒューリスティックな手法の一つとして、ウィンドウ内に抽象クラスの代表値のみを残す処理をする。例えば、図7で示す場合においては、上記のように、統計値Aと統計値Bの値は等しいことになる。そこで、相関関係抽出手段34は、統計値A又は統計値Bのいずか一方のサンプルを消去する。これにより、ウィンドウ内には統計値A又は統計値Bのいずか一方のサンプルのみが残ることになる。
その後、相関関係抽出手段34は、和の相関を抽出する。具体的には、相関関係抽出手段34は、2つの統計値ごとにサンプルを合計して、その結果が既存の統計値のサンプルと等しいかどうかを確認する(3つ以上の和を確認するように構成しても構わない)。また、相関関係抽出手段34は、和の相関を探索する際に、各統計値のサンプルの有限差分を用いることも出来る。例えば、図8を参照すると、統計値Dは統計値Eと統計値Fの有限差分であるd統計値Fとの和であることが分かる。そこで、相関関係抽出手段34は、統計値Dと統計値Eとd統計値Fとの間に和の相関関係があることを発見する(統計値D=統計値E+d統計値Fの規則があることを発見する)。
このような方法により、相関関係抽出手段34は、ウィンドウ生成手段33が生成したウィンドウ内の各統計値のサンプルから相関関係を抽出する。そして、相関関係抽出手段34は、抽出した相関関係を説明する規則(検証前の規則)を相関関係検証手段35に送信する。相関関係抽出手段34は、例えば、統計値G=定数、統計値A=統計値B、統計値B=d統計値C、統計値A=d統計値C、統計値D=統計値E+d統計値F、という検証前の規則を相関関係検証手段35に送信する。
なお、相関関係抽出手段34は、抽出した相関関係を説明する規則(検証前の規則)を相関関係検証手段35に送信する代わりに規則ファイル36に記憶するように構成しても構わない。
また、相関関係抽出手段34が相関関係を抽出する方法は、上述した場合に限定されない。相関関係抽出手段34は、例えば、予め定められた相関関係を満たすサンプルがウィンドウ内に存在するか探索することで相関関係を抽出するように構成することが出来る。また、相関関係抽出手段34が抽出する相関関係も、上述した場合に限定されない。相関関係抽出手段34は、例えば、統計値間の線形結合や回帰に基づく規則を抽出するように構成することが出来る。
相関関係検証手段35は、相関関係抽出手段34から受信した検証前の規則(若しくは、規則ファイル36が記憶する規則)を各ウィンドウに適用することで、当該検証前の規則が各ウィンドウに適用可能であるか否かを検証する機能を有している。
具体的には、相関関係検証手段35は、図9(A)(B)で示すように、相関関係抽出手段34から受信した検証前の規則(若しくは、規則ファイル36が記憶する規則)をウィンドウ生成手段33が生成した各ウィンドウに適用することで、当該規則の有意性を検証する。例えば、相関関係検証手段35は、各ウィンドウに規則が適用できるか否かをそれぞれ検証し、適用に成功したウィンドウの数を計測する。そして、相関関係検証手段35は、適用に成功したウィンドウの数に基づいて、規則の有意性を算出する。例えば、相関関係検証手段35は、適用に成功したウィンドウの数を対象となる全てのウィンドウの数で除算することで有意性を算出する。
そして、相関関係検証手段35は、検証済みの規則を規則ファイル36に記憶する。
なお、このようにして算出された有意性は、例えば、相関関係検証手段35が検証済みの規則を規則ファイル36に記憶する際に用いることが出来る。つまり、相関関係検証手段35は、予め定められた記憶用閾値を超える有意性を備える検証済みの規則のみを規則ファイル36に記憶するように構成することが出来る。また、有意性は、例えば、データ送受信手段31が規則を統計値圧縮装置4に送信する際に用いることが出来る。つまり、データ送受信手段31は、予め定められた送信用閾値を超える有意性を備える規則のみを統計値圧縮装置4に送信するように構成することが出来る。
規則ファイル36は、メモリやハードディスクなどの記憶装置である。規則ファイル36は、相関関係検証手段35から送信された検証済みの規則を記憶するよう構成されている。具体的には、規則ファイル36は、相関関係検証手段35から検証済みの規則を受信する。そして、規則ファイル36は、当該受信した検証済みの規則を記憶する。また、規則ファイル36が記憶する検証済みの規則は、データ送受信手段31を介して統計値圧縮装置4へと送信されることになる。なお、規則ファイル36は、検証前の規則(相関関係抽出手段34から送信された規則)も記憶するように構成することが出来る。
図10は、規則ファイル36が記憶する検証された規則の記憶方法の一例である。規則ファイル36は、例えば、図10(A)で示すように、組み合わせによるアプローチとして、各規則の組み合わせを網羅的に記憶する(相関関係を満たすデータを網羅的に列挙する)構成することが出来る。また、規則ファイル36は、例えば、10(B)で示すように、抽象クラスに基づくアプローチとして、抽象的な概念として規則を記憶するように構成することが出来る。また、規則ファイル36は、例えば、図10(C)で示すように、相関関係を示す一般的な規則とその例外との組み合わせであるツリー型の方法で規則を記憶するように構成しても構わない。規則ファイル36は、上記説明した3つ以外の方法を用いて規則を記憶するように構成しても構わない。
統計値圧縮装置4は、統計値マイニング装置3が発見して検証した規則を用いて統計値を圧縮する情報処理装置である。統計値圧縮装置4は、図示しない中央演算装置(CPU、Central Processing Unit)と、記憶装置(メモリ及びハードディスク)と、を備えている。統計値圧縮装置4は、記憶装置が備えるプログラムをCPUが実行することで、後述する機能を実現するように構成されている。
図11を参照すると、統計値圧縮装置4は、データ送受信手段41と、統計値ファイル42と、検証された規則ファイル43と、統計値圧縮手段44と、を有している。
データ送受信手段41は、ストレージシステム2や統計値マイニング装置3と統計値や検証された規則の送受信を行う機能を有している。データ送受信手段41は、例えば、ストレージシステム2が送信する統計値(を含むファイル)を受信する。そして、データ送受信手段41は、受信した統計値を統計値ファイル42に記憶する。また、データ送受信手段41は、例えば、統計値マイニング装置3が送信する検証された規則を受信する。そして、データ送受信手段41は、当該受信した検証された規則を規則ファイル43に記憶する。
統計値ファイル42は、メモリやハードディスクなどの記憶装置である。統計値ファイル42は、ストレージシステム2から送信された(データ送受信手段41が受信した)統計値を記憶する。統計値ファイル42が記憶する統計値は、後述するように、統計値圧縮手段44により、統計値マイニング装置3が発見した規則を用いて圧縮されることになる。
検証された規則ファイル43は、メモリやハードディスクなどの記憶装置である。検証された規則ファイル43は、データ送受信手段41が受信した検証された規則を記憶している。検証された規則ファイル43が記憶する検証された規則は、後述するように、統計値圧縮手段44がデータの圧縮を行う際に用いられることになる。
統計値圧縮手段44は、規則ファイル43が記憶する検証された規則を用いて統計値ファイル42が記憶する統計値を圧縮する機能を有する。統計値圧縮手段44は、規則ファイル43から規則を取得する。また、統計値圧縮手段44は、統計値ファイル42から統計値を取得する。そして、統計値圧縮手段44は、規則ファイル43から取得した規則を用いて、統計値ファイル42から取得した統計値を圧縮する。その後、統計値圧縮手段44は、例えば図示しない圧縮後統計値記憶部に、圧縮した統計値を記憶する。
なお、統計値圧縮手段44は、上記のように検証された規則を用いて統計値を圧縮した後に、外部の一般的な圧縮装置を用いて再度圧縮処理を行うように構成することが出来る。
また、統計値圧縮手段44は、定数の相関などの簡易な相関を自身で発見するように構成することが出来る。この場合には、統計値圧縮手段44は、自身が発見した相関を用いて圧縮を行うよう構成することが出来る。
また、統計値圧縮手段44は、予め定められた基準に従って圧縮を行う際に使用する検証された規則を選別するように構成することが出来る。統計値圧縮手段44は、抽象クラスの平坦化や統計値によって使用される識別子を交換するリナンバリングを行うように構成されていても構わない。
以上が、データ圧縮システム1の構成についての説明である。次に、データ圧縮システム1の動作について説明する。最初に、図12を参照して統計値マイニング装置3の動作の一例について説明する。
図12を参照すると、まず、データ送受信手段31がストレージシステム2内の各ストレージノード22が収集した統計値を取得する(ステップS101)。すると、データ送受信手段31は、当該取得した統計値を統計値データベース32に記憶する。
次に、ウィンドウ生成手段33は、統計値データベース32が記憶する統計値を用いてウィンドウを生成する(ステップS102)。なお、ウィンドウ生成手段33は、過去に自身が生成した複数のウィンドウから統計値を抜き出すことで新たなウィンドウを生成しても構わない。このようにして、ウィンドウ生成手段33は、複数のウィンドウを生成する。
続いて、相関関係抽出手段34がウィンドウ内の相関関係を抽出する(ステップS103)。これにより、相関関係抽出手段34は、相関関係を説明する規則(検証前の規則)を取得する。そして、相関関係抽出手段34は、検証前の規則を相関関係検証手段35へと送信する。
その後、相関関係検証手段35は、ウィンドウ生成手段33が生成した各ウィンドウに、相関関係抽出手段から受信した検証前の規則が適用可能であるか検証する(ステップS104)。例えば、相関関係検証手段35は、検証前の規則が適用可能なウィンドウの数を計測する。そして、相関関係検証手段35は、計測した規則が適用可能なウィンドウの数に基づいて規則の有意性を算出する。また、相関関係検証手段35は、検証された規則を規則ファイル36へと記憶する(ステップS105)。その後、規則ファイル36が記憶する検証された規則は、例えば予め定められた周期が経過する毎にデータ送受信手段31を介して統計値圧縮装置4へと送信されることになる。
以上が、統計値マイニング装置3の動作の一例である。次に、相関関係抽出手段34により行われる相関関係の抽出の一例について、図13を参照してより詳細に説明する。
図13を参照すると、相関関係抽出手段34は、まず、定数の相関関係を抽出する(ステップS201)。具体的には、相関関係抽出手段34は、各サンプルの値が一定である統計値を定数の相関関係があるとして抽出する。その後、相関関係抽出手段34は、定数の相関関係を有する統計値を、相関関係を抽出する対象となるウィンドウ内から除去する(ステップS202)。
次に、相関関係抽出手段34は、同一性の相関関係を抽出する(ステップS203)。具体的には、相関関係抽出手段34は、ウィンドウ内の各統計値を辞書的な順番で並び替えた後に隣り合う統計値の各サンプルを比較することで、予め定められた基準に基づいて同一であると判断される統計値の組を抽出する。その後、相関関係抽出手段34は、ウィンドウ内に各抽象クラスの代表値を1つだけ残す処理を行う(ステップS204)。つまり、例えば、A=Bの相関関係が抽出された場合には、相関関係抽出手段34は、A又はBのいずれか一方のサンプルの値をウィンドウから排除する。これにより、ウィンドウ内には、A又はBのいずれか一方のサンプルのみが残ることになる。
その後、相関関係抽出手段34は、和の相関関係を抽出する(ステップS205)。具体的には、相関関係抽出手段34は、2つの統計値ごとにサンプルを合計して、その結果が既存の統計値のサンプルと等しいかどうかを確認する。また、相関関係抽出手段34は、和の相関を探索する際に、各統計値のサンプルの有限差分を用いる。これにより、相関関係抽出手段34は、和の相関関係を有する統計値の組み合わせを抽出することになる。
以上が、相関関係抽出手段34の動作の一例である。次に、統計値圧縮装置4により行われる統計値の圧縮処理の一例について、図14を参照して説明する。
図14を参照すると、統計値圧縮装置4のデータ送受信手段41は、例えば定期的に(又は必要に応じて)、ストレージシステム2から統計値を取得する(ステップS301)。そして、データ送受信手段41は、取得した統計値を統計値ファイル42に記憶する。
また、統計値圧縮装置4のデータ送受信手段41は、統計値マイニング装置3から、例えば定期的に、検証された規則を取得する(ステップS302)。そして、データ送受信手段41は、取得した検証された規則を検証された規則ファイル43に記憶する。
上記2つの動作により、統計値ファイル42には統計値が記憶され、検証された規則ファイルには検証された規則が記憶されていることになる。そこで、統計値圧縮手段44は、検証された規則ファイル43が記憶する検証された規則を用いて統計値ファイル42が記憶する統計値の圧縮処理を行う(ステップS303)。
以上が、統計値圧縮装置4により行われる統計値の圧縮処理の一例である。
このように、本実施形態におけるデータ圧縮システム1は、相関関係抽出手段34を備える統計値マイニング装置3と、統計値圧縮装置4と、を備えている。このような構成により、データ圧縮システム1は、相関関係抽出手段34が抽出した相関関係に基づいて統計値の圧縮処理を行うことが出来るようになる。一般に、各ソフトウェアユニットは互いに協調して動作している。そのため、各ソフトウェアユニットが取得する統計値には、相関関係がある場合が少なくない。従って、このような相関関係を利用して統計値を圧縮することで、高い信頼性を維持しつつより効率的に統計値の圧縮を行うことが出来るようになる。
また、本実施形態における統計値マイニング装置3は、ウィンドウ生成手段33を有している。このような構成により、ウィンドウ生成手段33が生成したウィンドウ内で相関関係を抽出することが出来るようになる。一般に、相関関係を抽出する各統計値のサンプルの数は必ずしも同数ではない。そのため、相関関係を抽出する際には、異なるサンプルの数の統計値間の相関関係を抽出することが必要になり、そのアルゴリズムは複雑なものになる。一方で、ウィンドウを用いることで、各統計値に同数のサンプルを有する状態で相関関係を抽出することが出来るようになる。その結果、相関関係を抽出する際のアルゴリズムを簡素化することが出来るようになる。また、結果を比較する際に明確な基準を持つことが出来るようになる。
また、本実施形態における統計値マイニング装置3は、相関関係抽出手段34と、相関関係検証手段35と、を有している。このような構成により、相関関係抽出手段34による相関関係の抽出作業と相関関係検証手段35による検証作業とを分けることが出来るようになる。その結果、計算の並列化をより効率的に行うことが出来るようになる。
また、本実施形態における相関関係抽出手段34は、幾つかのヒューリスティックな方法を用いることが出来るよう構成されている。具体的には、相関関係抽出手段34は、定数の相関関係を抽出した後に、当該定数の相関関係を有する統計値をウィンドウ上から除去するように構成されている。また、相関関係抽出手段34は、同一性の相関関係を抽出した後に、各抽象クラスの代表値のみをウィンドウ内に残すように構成されている。このような構成により、定数の相関関係を有する統計値を除去したウィンドウ内で同一性の抽出作業を行うことが出来るようになる。また、定数の相関関係を有する統計値を除去し、抽象クラスの代表値以外の統計値も除去したウィンドウ内で和の相関関係を抽出することが出来るようになる。一般に、定数の相関関係を抽出する作業は、同一性の相関関係を抽出する作業よりも軽い作業である。また、同一性の相関関係を抽出する作業は、和の相関関係を抽出する作業よりも軽い作業である。そのため、上記のようなヒューリスティックな方法を用いることで、軽い相関が重い相関を隠すことが出来るようになる。
なお、本実施形態においては、ストレージシステム2が収集する統計値を圧縮する場合について説明した。しかしながら、本発明は、ストレージシステム2が収集した統計値を圧縮する場合に限定されず実施可能である。本発明は、例えば、グリッドサーバ間で収集する統計値を圧縮するような場合に適用しても構わない。
また、データ圧縮システム1が圧縮する対象は、必ずしも統計値に限定されない。データ圧縮システム1は、相関関係を有する様々なデータを圧縮する際に用いることが可能である。
また、本実施形態では、統計値マイニング装置3と統計値圧縮装置4とは異なる情報処理装置であるとした。しかしながら、本発明の実施は、上記場合に限定されない。本発明は、統計値マイニング処理部と統計値圧縮処理部とを備える情報処理装置により実施されても構わない。また、本発明は、ストレージシステム2上で実施されても構わない。
<実施形態2>
本発明の第2の実施形態を、以下の論文形式にて説明する。
第1章 序章
分散システムは、現在広く利用されるようになっている。その複雑さゆえにオンラインでの監視が難しいため、遅延型の調査のためのシステムの状態を収集する方法が開発されている。大量のデータを入手することがきわめて重要であることから、圧縮アルゴリズムが開発されている。本論文では、商用の二次記憶分散システムであるNECのHYDRAstorによって生成された統計値の圧縮のための、新たなアプローチを提示し、これを評価する。統計値は、HYDRAstorに組み込まれた数千の測定基準の、頻繁に探索される値であり、システムの現状を表すことを目的としている。
統計値の圧縮を改善する必要性が、実際の使用から出現した。顧客のデータセンターで動作しているHYDRAstorに関する問題を調査するには、統計値を取得する必要がある。しかし、セキュリティ上の問題から、ダウンロードできるデータ量を著しく制限している機関もある。当然ながら、統計値のサンプル量が少なければ、そのシステムにおける問題の分析に費やす時間と努力は劇的に増える。そのため、渡されるパッケージのサイズを大きくすることなく、顧客から入手する統計値のサンプルの数を大きくする必要がある。一方で、ここで提案するソリューションは、無損失でなければならない。なぜなら、解凍後のサンプル値にゆがみがあれば、その統計値の分析から得られる結論が誤ったものになる恐れがあるからだ。
この論文の目的は、効率的で無損失な統計値の圧縮方法であり、NECのHYDRAstorシステムと密接に協働するように調整された圧縮方法を提供することである。提案するソリューションは実装されているため、この作成されたソフトウェアについて、達成可能な圧縮率とパフォーマンスを測定するための様々な実験が行われた。この論文で述べるソリューションは、ダウンロードするデータを増やすことなく、エンジニアが顧客の施設から統計値のサンプルをより多く取得できるようにすることをサポートすることができる。その結果、HYDRAstorの状態の調査がよりシンプルになるため、HYDRAstorのサービス品質が向上する。
この論文は、次の6つの章から構成される。
2.「背景」では、NECのHYDRAstorについて簡単に説明する。これは、ソリューションを作成する上での決定を理解するために重要である。
3.「相関に基づく圧縮の分散モデル」では、提案するソリューションの概念について述べる。
4.「相関マイナー」では、StatsMinerという、実装した2つのツールのうちの1つ目について説明し、評価する。人為的なデータと顧客から受け取ったデータの両方について、評価を行う。
5.「コンプレッサ」では、StatsCompressorという、2つ目の実装したツールについて説明する。この章では人為的なデータに対するツールの評価を行い、StatsMinerとStatsCompressorとの協働に関するいくつかのモデルについて述べる。
6.「顧客から取得した実際の統計値での評価」では、顧客から受け取った統計値に対する、実装したソフトウェアとその使用に関する様々なモデルの評価を行う。
7.「関連研究」では、この論文に関連する分野で実施された、他の研究について概説する。それに基づいて、将来の研究についての提案も行う。
第2章 背景
本論文で解決を試みる問題は、NECのHYDRAstorシステムを使用する中で出現したものであるため、その解決策はHYDRAstorの具体的な要件に対応しなければならない。そのため、開発するソリューションに対して課されるこのシステムの制約について、簡単に説明する必要がある。HYDRAstorの包括的な仕様は[DGH+09]に記載されている。
本章は、次の3つのセクションから構成される。
2.1 「HYDRAstorの概要」では、HYDRAstorシステムを説明する。後の章で使用する様々な重要な用語について、ここで定義する。
2.2 「システムの監視」では、HYDRAstorの観点を含む、ログの収集と分析の問題について述べる。このセクションでは、この論文で述べる研究が重要である大まかな理由についても説明する。
2.3 「HYDRAstorでの統計値の収集」では、HYDRAstorシステムでの統計値の収集プロセスの技術的な詳細と、統計値の記憶に使用するファイルのフォーマットについて述べる。なぜなら、ここで説明するソリューションは、フレームワークに適合したものでなければならないからだ。
2.1. HYDRAstorの概要
NECが提供するHYDRAstorは、企業レベルの、拡張性を持つ2次記憶システムであり、テープドライブではなくハードドライブを使用する。バックアップデータの書込みを、高スループットかつ少ない待ち時間でサポートするものであり、これはこの種のソフトウェアにとっては極めて重要な要件である。バックアップオペレーションは、バックアップされるシステムの効率を劇的に低下させることがあるため、バックアップウィンドウは常に非常に限られた長さしかないからだ。これが、本論文で述べるソリューションの主な制約である。つまり、HYDRAstorと併せて動作するソフトウェアは、書込みパフォーマンスに悪影響を与えてはならない。
書込みはHYDRAstorで行われる主なオペレーションであるため、少し詳しく説明する。バックアップデータのバイト列は、多様なサイズの不変のチャンクに分割されてこのシステムに入力される。システム内に、すでにチャンクが存在する場合は、チャンクのコンテンツハッシュを使用して発見することができ、そのチャンクは二度書き込まれることはない。このプロセスをインライン重複排除といい、このコンセプトの使用はHYDRAstorのパフォーマンスにとって極めて重要である。チャンクを記憶する必要がある場合、どこに入れるかという判断が行われる。HYDRAstorは、サーバ群から構成されるフォールト・トレラント分散システムである。サーバまたはディスクに障害が発生した場合にデータの一貫性を保つため、各チャンクはリード・ソロモン符号が適用され、消去訂正符号化(erasure-coded)されている。コード化されたチャンクのSHA-1ハッシュと、Distributed Hash Table概念を用いて、チャンクの記憶場所が決定される。最後に、データは内部ネットワークによって、前のステップで選択された論理ノードに対応する物理ノードに転送される。
当然、HYDRAstorからデータを読み出すことも可能だが、このプロセスはあまり一般的ではなく書込みほど重要でもないため、このシステムは読出しよりも書込みについて最適化された。基本的に読出しは頻繁には行われない。
また、HYDRAstorからデータを削除することができる。高速かつ少ない待ち時間で書込みを行うためのトレードオフとして、削除のプロセスが非常に複雑であり、ガーベジコレクション機能として動作する。3つの段階に分かれており、各々がシステムに与える影響が異なる。まず、データをシステムから除去する命令を受けると、内部のメタデータのみが影響を受け、実際のデータはドライブ上に存在する。物理的に記憶されたどのチャンクを消去するのかを判断するために、削除という特別なプロセスが実行されなければならない。これは、いくつかのチャンクに「削除される」というマークを付けることを目的としている。削除は、複雑な分散アルゴリズムであり、ここでは説明を省略するが、参考文献[SAHI+13]に完全な説明が記載されている。しかし、削除に関して、統計値の圧縮を開発する上で考慮すべき事実がいくつかある。まず、削除は周期的に実行されるものであり、このツールはめったに使用されないほうが好ましい。つまり、このプロセスの統計値は長時間一定である。次に、動作中はかなりのリソースを消費するため、削除が行われている間は、HYDRAstorが違う動作をすることがある。削除は、書込みと同時に実行できる。前述のとおり、削除は物理的なチャンクに「使用しない」というマークを付けるだけである。ディスクのスペースを取り戻すためには、スペース再生プロセスを実行する必要がある。削除プロセスとは異なり、スペース再生はHYDRAstorにそれほど影響を与えることはなく、バックグラウンドタスクといわれる、適宜行われる多くのプロセスの1ついすぎない。
2.1.1. バージョン
HYDRAstorシステムには、H2、H3、H4、という3つの主なバージョンがある。H2が商用に使用される最も古いもので、H3は顧客に最も人気があり、H4は現在市場に導入されているものである。これらの番号はハードウェアとソフトウェアの両方を表している。なぜなら、HYDRAstorは、特別に設計されたサーバとインストールされた上記のソフトウェアから成る、完全なソリューションとして販売されているからだ。
当然、NECはこの製品のパッチと更新を出している。このシステムは大企業でよく利用されているため(HYDRAstorの主要対象グループである)、パッチを適用するのは非常に難しく、時間のかかるプロセスである。すべてのメンテナンスを行える規模のサービス窓口が必要である。そのため、消費者は、本当に必要なパッチしかインストールしない。その結果、あらゆるバージョンのHYDRAstorに様々なサブバージョンが存在する。驚くことではないが、各バージョンはわずかに違う動作することがあるため、統計値の圧縮のために設計するソリューションも、それに応じて柔軟なものでなければならない。さらにHYDRAstorは、特定の顧客のニーズに応じたパフォーマンスの調整に使用する、様々な構成のパラメータがある。
相関に基づく統計値の圧縮は少なくともH4システムで使用されるが、以前のバージョンに簡単にポートできれば、必ずプラスになるであろう。
2.1.2. 物理的なアーキテクチャ
各HYDRAstorは、2つの異なるタスクを実行する2つの専用のサーバで構成される。このシステムの中心は、データを保持するストレージノード(Storage Nodes(SN))である。ストレージノードはすべてネットワークを介して接続されている。もう1つのサーバは、HYDRAstorへのゲートウェイとして機能しデータアクセスAPIを提供する、加速ノード(Acceleration Nodes(AN))である。各ANはすべてのSNと接続されているが、AN間にはリンクはない。ANは顧客のサーバにも接続されている(SNは接続されていない)。
ANとHNの区別は、統計値の圧縮にとって重要である。なぜなら、両方のサーバで実行されているプロセスが統計値を収集するが、これらの統計値は同じではなく、ノードの動作も異なるからだ。H3バージョンでは、ANとHNのプロセスは各々約50000の統計値を有するが、ANノード上で実行されるプロセスの統計値の方が定数を多く含んでいる。
H4バージョンでは、ANのかわりに、旧ANとSNの特徴を組み合わせたハイブリッドノード(Hybrid Nodes (HN))がある。この構成では、旧ANとSNからのプロセスは同じマシン上で同時に実行される。
本論文で述べるすべての実験を、SNまたはHNノードから収集した統計値上で実行することに決定した(HNの場合は、記憶プロセスからの統計値のみを考慮する)。これには技術的理由がいくつかある。またこのアプローチは、実験結果がより一貫性を持つ。ANからのプロセスによって収集される統計値の圧縮率は、SNから収集された統計値の圧縮率よりも、幾分良いものになると考えられる。
2.1.3. ソフトウェアのアーキテクチャ
単一ノードのアーキテクチャ
HYDRAstorは並列アプリケーションであり、メッセージ受け渡しコミュニケーションを多く利用する。OOSFフレームワーク(オブジェクト指向のサーバ・フレームワーク)のおかげで、HYDRAstorの異なるサブシステム(ユニットという)間で互いにメッセージを交換する。さらに、OOSFフレームワークは、自身のスレッドでユニットコードの実行スケジュールを立てる(これはユーザ・スペース・スレッドのアイデアを意味する)。特定のユニットに向けたメッセージがあると、このユニットはそれをキューに入れて、アイドルのスケジューラのスレッドがそれを実行するのを待つ。スケジューラは、いかなる形式のプリエンプション(preemption)も提供しないため、制御がスケジューラに戻ってくるまで、または走っているスレッドがメッセージを送るまで、コードは実行される。すぐにわかると思うが、スケジューラは、1つのコードの実行時間について何の制約も提供しない。OOSFフレームワークの概念は、統計値の取集プロセスを説明する際に重要となる。
各ユニットは独自の特徴と、自身が生成する、一連の特定の統計値を有する。ここでは、この統計値の各々については説明しない。なぜならこれは非常に特殊なもので、また数が多すぎるからだ。一方、ある現象について述べておく。まず、ユニットは、受信および送信するメッセージ数を数えることがよくあるため、他のものの和と等しい何らかの統計値が存在すると思われる。次に、統計値の中には同一のものもある。例えば、2つのユニット間のみで特定のタイプのメッセージが送信されると、これらのメッセージは両ユニットで数えられる。また、あるメッセージが(数えられる)ある行動のトリガーとなる場合、または別の種類のメッセージを送信するトリガーとなる場合、同様の状況が発生する。この2つの例をもっと高い観点から見ると、もう1つの「社会学的な」同一性のソースが発見される。つまり、エンジニアリング的な理由により、同じことがいくつかの場所でカウントされる場合がある、ということだ。まず、同じことが2つの場所でカウントされると(つまり2つの名前を持つ)システムのメンテナンスにおいて、より便利になることがある。HYDRAstorはパフォーマンス・クリティカルなソフトウェアだが、メンテナンスが容易であることはさらに重要である。また、別箇のユニットの開発者は、同僚が同じイベントのログを取るコードを既に作成していること、場合によっては数年前に作成していることを、知らない場合がある。この原因は、チーム間のコミュニケーションが不足していること、または単に、コードのひとつひとつに関する非常に詳細な知識を交換しないという事実があること、が考えられる。このため、非常に大きなシステムでは、統計値またはログの繰り返しがあるという仮説が成り立つ。何らかの規則に基づいて、欠けているものを生成できるツールを作成すれば、統計値の繰り返しを簡単に削減できると思われる。唯一問題となるのは、この規則をどこから取得するかである。専門家の知識に基づく規則の作成はコストが高すぎる場合が多い。なぜなら、ソフトウェアのコードを読み出し、2つの統計値が常に同一なのか、それとも例外が存在するのかどうか、という判断をする作業が含まれるからだ。
分散システムの視点
前述したとおり、HYDRAstorは拡張性のある、フォールト・トレラント分散システムである。各物理ノードは「コンポーネント」と言われる複数の論理サーバのホストとなる。コンポーネントは、様々な状況において、あるノードから他のノードへと移動させることができる。例えば、故障したディスクが発見された場合、または拡張のためにシステムにリバランスが必要になった場合、などである。さらにコンポーネントの数は時がたてば変わる。データ量が増えると、パフォーマンスを向上させるためにコンポーネントの分割が必要になることがある。当然、コンポーネントの展開の変更はよくあることではないが、このようなイベントからの統計値は頻繁に分析される。なぜなら、これらの統計値は、システムのまれなケースを表しているからだ。各コンポーネントと結びついている統計値は複数あり、そのコンポーネントが実際に存在しているノード上で収集される。つまり、物理ノード間でコンポーネントの移動があると、古いノード上での収集が中止され、別のノード上で記録されるようになる統計値もある。
2.2. システムの監視
2.2.1. モチベーション
文献[OGX12]は、ログの収集に関する5つの理由を特定している。
1.デバッグ
2.パフォーマンス
3.セキュリティ
4.レポートとプロファイリング
5.予測
最初の2つの理由であるデバッグとパフォーマンスは、HYDRAstorにとって最も重要である。前述したとおり、この設計したソリューションは、バグが発生した場合の、またはパフォーマンスの改善を期待して、顧客のサイトでのHYDRAstorの設置に関するメンテナンスの品質を改善する必要がある。この目的を達成するために、特定のハードウェアまたはソフトウェアの構成およびシステムの現状に関する知識のソースとして、統計値が用いられることがよくある。この使用は、上記のリストの「レポートとプロファイリング」の項目をある程度活用している。しかし、[OGX12]の著者はさらに進めて、システムに関するレポートを半自動的に生成するための、人口知能(例えばクラスタリング・ツール)の使用について記載している。HYDRAstorのメンテナンスにこの種のツールは利用不能かどうか、特に、問題のある領域の予備的な視覚化を助けるものか、を検討することは合理的だと思われる。「予測」については、HYDRAstorは既に変則性検出ツールを備えている。システムの誤りを発見する、専門家の知識に基づく規則を利用している。上記リストの、まだ言及していない最後の項目は「セキュリティ」である。セキュリティの問題(潜入または侵入工作と認識されるもの)は、HYDRAstorには適用されない。なぜなら、このシステムは「極めて」バックエンドなソリューションであり、セキュリティについては、より高い層のソフトウェアで対処されている(特にソフトウェアが作成するバックアップ)。
2.2.2. ログと統計値
ここまでは「ログ」と「統計値」という用語は交換可能に用いられていたが、ここで明確に区別し、統計値がHYDRAstorで広範に使用される理由を説明する。
従来から、「ログ」は複数のラインで構成され、各々がタイムスタンプを有し、例えばメッセージの受信といったシステム内の単一のイベントを記述する。ログは一般的に極めて冗長で、プラスの面とマイナスの面の両方がある。単一のログメッセージは(一般的に)単一のイベントにマップされるため、ログに基づくデバッグは簡単である。なぜなら、そのイベントのすべての詳細を得られるからだ。同時に、大きなシステムでは膨大な量のログを収集するため、パフォーマンスに対して目に見える悪影響を及ぼす。さらに、特定の状況と結びついた一連のメッセージを得るために、膨大なフィルタリングと変換を行う必要がある。また、システムの行動の完全なイメージを得るには、ログからデータの解析と収集をしなければならず、さらに複雑である。
HYDRAstorで使用される意味において、統計値は周期的に収集されたサンプルのシーケンスである。例えば、20秒ごとに、各ディスクに渡された複数のリクエストがダンプされる。リクエストの数はわかるが、リクエストのソースまたは具体的なタイプに関する知識は失われる。そのためデバッグがさらに複雑になる。しかし、HYDRAstorの例からわかるように、経験豊富なメンテナンス担当者にとっては問題ではないと思われる。一方、統計値はシステム全体のイメージを得るプロセスを容易にする。なぜなら、そこからプロットを作るのに最小限の量の解析と変換しか必要としないからだ。このアプローチの最大の利点は、ディスクスペースが節約されるため、パフォーマンスに与える影響が最小限になることである。統計値はより高度なレベルのログとして扱うことができる。データの収集によって詳細を削減することと引き換えに、全体像を提供する。メッセージをログから統計値に変換することは可能だが、逆はできない。統計値はログの不可逆圧縮である。
HYDRAstorはログおよび統計値の両方を収集するが、統計値の方が重要である。古典的なログは最も重要な状況、例えば失敗したアサーション、をカバーする。レガシーコードの中には、相変わらず一般的な状況を記録するものもあるが、パフォーマンスに強い影響を与えため、そのようなコードは統計値の使用に変換される。HYDRAstorにおいて、統計値は、現在のシステムの状態に関するあらゆる情報を保存するために使用される。前述したとおり、各マシンは約50000個の異なる統計値を生成する。この数はインストールとソフトウェアのバージョンにおける役割の違いによって異なる。
2.3. HYDRAstorにおける統計値の収集
2.3.1. 統計値の収集プロセス
HYDRAstorにおける統計値の収集はいくつかのフェーズに分割できる。
最初のフェーズは、「ユニット・ローカル」というものである。各ユニットは統計値を表すカウンタのマップを有し、これらのカウンタ上で該当するイベントが動作のトリガーとなる。このカウンタにはタイムスタンプは含まれていない。
2番目のフェーズは「ノード・ローカル」というものである。ある特殊なユニットが周期的に他の複数のユニットにメッセージを送り(MessageRequestStats)、それらの統計値の現在の値(カウンタの値)を戻す。このメッセージを受信すると、何らかの統計値をリセットすることになる場合がある。例えば、「最近の」変更に関する情報などである。回答メッセージは、ディスクへのデータの記憶を担当するStatsGatherモジュールにリダイレクトされる。StatsGatherはフォーマットの1つに統計値をダンプする。これについては次のセクションで説明する(2.3.2項参照)。
「ノード・ローカル」フェーズには、本論文で述べるソリューションの設計において考慮された、特別な特徴がある。最も重要な問題は、スケジューラがいかなるメッセージ(特に、送信したMessageRequestStatsのいかなる部分集合)についても、受信者に共時的に提供することを保証しない、ということである。つまり、常に同一だが別々のユニットに存在する2つの統計値がある場合、これらの値がわずかに異なる恐れがある。その差異はたいてい非常に小さなものだが、それによって相関探索の問題がさらに難しくなる。また圧縮にも影響を与える。この問題については後で述べる。一方、この問題は、同じユニットから発生した統計値には何の影響も与えない。
統計値の収集に関する「ノード・ローカル」フェーズにおけるもう1つの障害は、異なるユニットから異なる頻度で統計値が要求される場合があることである。現在、すべてのユニットは20秒ごとに統計値を要求するが、ユニットの中には、5秒ごとに問い合わせを受けるよう設計されているものもある。その結果、本論文で設計したソフトウェアは、異なる頻度で収集されたサンプルを比較できなければならない。
ディスク上に記憶された統計値は、ユーザがそれを要求するまで(ダウンロード・フェーズ)、または古くなりスペースの節約のために削除されるまで、待つ。現在、HYDRAstorでは統計値を他に利用する方法はない。確かに変則性検出ツールがあるが、これはオンラインで動作する。
なお、異なるノードからの統計値が1つのファイルに統合されることは決してない。このような行為は、多くのネットワークトラフィックを必要とし、ダウンロードのフェーズに何ら利益を与えることはないと思われる。なぜなら、もしユーザが統計値をダウンロードしなければならないなら、1つのノードからのデータのダウンロードと、いくつかのノードからのデータのダウンロードに、何ら違いがなく、とくにこのプロセスを自動化するスクリプトがあるからだ。一方、1つのファイルには、そのノード上で動作するすべてのユニットから収集された統計値が含まれる。
2.3.2. HYDRAstorにおける統計値の記録ファイルのフォーマット
HYDRAstorは、おそらく市場で広い存在感を持つ他のあらゆる商用ソフトウェアと同様に、統計値を記憶するためのフォーマットがいくつかあり、システムの様々なバージョンにおいて、フォーマットの進化が見られると思われる。当然、統計値のファイルが満たすべき期待値がいくつかある。統計値は特別なツール(StatsViewerという)を用いてたいてい視覚化されるが、手動でファイルの操作をしなければならない場合もある。このため、良いフォーマットは、grep、cut、sort etc等の標準的なunixツールを用いて簡単に操作できる必要がある。一方、このようなファイルはそれほど多くのスペースを使わず、これらの収集は動作中のシステムに影響を与えることはない(CPUまたはメモリ消費量もいずれも)。
XMLファイル
XMLファイルは、HYDRAstorで統計値の記憶に使われる最も古いものである。ファイルは、メタデータを記述するいくつか(約20)のマークアップから構成され、ファイルの残りの部分はマークアップで、ライン1つごとに1つ、各々が1つの統計値についての情報を有し、名前、時間オフセット、収集頻度、サンプルのシーケンスがある。このようなデータ構造には様々な利点がある。人間が読み取れ、ファイルの収集プロセスが複雑でなく、市場には既存のXML解析ツールがある。一方、XMLファイルは多くのディスクスペースを使用する。この問題はgzipツールを用いてファイルを圧縮すれば緩和される。しかし、H4バージョンではXMLファイルはもう使用されていない。そのため、ここで設計するソリューションはこのフォーマットのファイルを直接読むことを想定していない。
Zstatファイル
Zstatファイルフォーマットは、H3の更新の1つによって導入され、それ以来、統計値の記憶にとって最適なフォーマットとなった。これは、統計値収集モジュールの機能拡張の一部として導入された。このフォーマットはスペース利用に優れており、今ではサンプル収集にかかる時間が節約されている。しかしハンドメイドであるため、特別な解析ツールが提供された。XMLファイルの場合と同様に、Zstatファイルは外部のコンプレッサを使用して圧縮されている。この問題は本論文で後述する。
ここで設計されるソフトウェアはZstatファイルをサポートする必要がある。その実践的な側面は後述するが、理論上、このフォーマットは、作成されるソリューションに実際上のあらゆる制約を課す。まず、利用される圧縮は、Zstatファイルの観点から、無損失圧縮でなければならない。圧縮および解凍されたZstatファイルは、もとのものと同一構造でなければならない。また、圧縮されたファイルをもとのZstatファイルと比較して圧縮率が判断される。そのため、StatsCompressorによって作成されるファイルのフォーマットは、これらの2つの要件を強調するためにZplusという。
Zstatファイルは2つにセクションから構成され、各々が同数のラインを有する(図15参照)。最初のセクションでは、各ラインには、1つの統計値の名前、そのメタデータ、および数値的な識別子が含まれ、これはそのファイル特有のものである。2番目のセクションでは、各ライン(タイムスタンプのシーケンスであるものを除く)には、統計値の識別子と、そのサンプルのシーケンスが含まれる。なお、本論文ではタイムスタンプについての詳細な説明は省略する。タイムスタンプは、この設計されたソリューションでは使用しないため、メタデータの一種として扱い、Zplusファイルにコピーするだけである。重要なのは、ファイル内の各統計値は違う数のサンプルを含む場合がある、ということである。Zstatファイルはgzipコンプレッサを用いて圧縮される。
Pack 統計値
Pack統計値フォーマットは、ダウンロードするデータの容量を制限している顧客からZstatファイルダウンロードする場合に、Zstatファイルのサイズを最小にするという問題を解決するため、設計された。Pack 統計値のファイルは、 通常のZstatファイルから特定のツールによってダウンロードのフェーズで作成される。Pack統計値をZstat fileに戻す変換をする同様のプログラムもある。
このファイルフォーマットはZstatファイルのフォーマットと似ているが、ファイルを小さくするために様々なシンプルなトリックを使用している。まず、このファイルは、すべての統計値の部分集合しか含まない。ユーザは、手動で定義するか、またはHYDRAstorの開発者が手動で定めた所定のカットスキームを利用する。またZstatファイルがgzipを用いるのに対して、Pack 統計値のファイルはbzip2ツールを用いて圧縮される。
Zstatファイルは2つの主な部分から構成される(2.3.2を参照)。これらは、統計値の名前の数値的識別子へのマッピング、および前述の識別子のサンプル「シーケンス」値へのマッピング、である。統計値の本当の名前は、長い共通のプレフィックス(例えばMETRIC::DataSynch::DiskRequestManager::RequestsCount::total::requestsInProgress::RecentMax and METRIC::DataSynch::DiskRequestManager::RequestsCount::cannotExecuteBecauseOfLimit::Current)である。Pack 統計値ファイルでは、名前から識別子へのマッピングはツリー形式で記述され、内部ノードには幹(METRIC、DataSynch、DiskRequestManager、等)があり、葉には識別子がある。このアプローチによってスペース使用量は約20−30%削減される。
ここで設計されるソリューションは、製品化の過程でPack 統計値ツールと統合することも可能である。上記のアイデアはすべて、ここで設計されたStatsCompressorによって使用することができる。名前−識別子のマッピングを圧縮する方法は非常に効果的だと思われ、特に、本論文はサンプルの圧縮の問題に焦点を当てているため、現時点では改良は行わない。ファイル内の統計値の数を制限するというアイデアは、ユーザが、どの統計値が本当に必要であるかを正確にわかっている場合には意味があるが、バグの調査を始めるときに、実際はこれはあまり一般的ではない。その場合、任意に定めた「重要な」統計値の所定の集合をダウンロードする。これらのファイルを使用するのは難しい。なぜなら、多くの統計値が不足することになり、それらは特定の状況においては興味深いものであるからだ。ここで設計したソリューションでは、統計値ファイルのコンテンツの制限が必要な場合にこのような状況がめったに起こらないようにする。
データベースファイル
これまでに述べたフォーマットはすべて、顧客のサイトで統計値を記憶し、それをサポートチームに転送するために使用するものである。統計値からプロットを作るために使用するツールであるStatsViewerは、上記のフォーマットを読むことができるが(ただしPack 統計値を除く。これは最初に変換が必要)すべてのデータをメモリに取り込む必要がある。長期間からの統計値を分析する場合、これを開くのに時間がかかる。この問題から、オンデマンドの統計値ローディングのニーズが発生した。このソリューションは、(異なるフォーマットの)統計値のファイルを、1つの標準化されたデータベースフォーマットに変換することである。実際、データベースファイルは、すでに解析されたデータを保有するsqliteデータベースであり、StatsVieverですぐに使用できる。なお、データベースはサポートチームのマシン上でしか作成されない。サイズや特定のアプリケーションを必要とすることから、顧客のサイトで作成されることはなく、またインターネットを介して転送されることもない。
この研究されたソリューションの観点から見ると、データベースファイルは、作成されたツールのための入力として興味深い。なぜなら、XMLまたはZstatファイルのあらゆるバージョンからデータベースを作成するコンバータがあるため、プログラムを、1つのフォーマットのみのファイルを読めるようにするからだ。
第3章 相関に基づく圧縮の分散モデル
本論文では、顧客からダウンロードされる統計値を含むファイルのサイズを最小化する新たな方法を提案する。この方法は、無損失で、顧客のマシンで動作するHYDRAstorシステムに悪影響を与えないものでなければならない。第2.1.3項で述べたとおり、統計値は相関関係を持つものが多いと考えられており、本論文ではこの事実を利用した圧縮方法について述べる。一方、本論文で述べる方法は、HYDRAstorと協働するよう設計されているため、圧縮ファイルのフォーマットと内容に関するドメイン知識を用いることができる。
本論文の中心的な概念は相関である。相関とは、いくつかの統計値のサンプル間の関係である。例えば、あるファイルに、同じサンプル値のシーケンスを持つ2つの統計値(統計値fとg)がある場合(f(0)=5、f(1)=3、f(2)=8、g(0)=5、g(1)=3、g(2)=8)、これらは相関関係にある、つまり、これらの間には同一性がある(f=gとなる)。このような相関は、ファイルの圧縮時に利用することができる(相関に基づく圧縮)。なぜなら、統計値gのサンプルのシーケンスを捨てても、統計値fがありf=gであることから、情報を節約できる。当然ながら、同一性は非常にシンプルな相関例に過ぎない。もっと複雑なものは、例えば和の例に関するものである(h=j+k、ただしh、j、kは統計値)。
技術的には、「厳密な相関」と「弱い相関」の2つのタイプがある。前の段落では厳密な相関f=gを示した。弱い相関の例としては、次のようなものがある。統計値fwとgwがあり、fw(0)=5、fw(1)=3、fw(2)=8、gw(0)=5、gw(1)=6、gw(2)=8であり、かつfw=gw+d、ただしd=[0、3、0]、これを偏差ベクトルという。実際に、どんな統計値の集合でも常に弱い相関がある。当然、弱い相関が優れていれば、より小さな数の偏差ベクトルを含む。偏差ベクトルの概念は、StatsCompressorに関する章(第5章)で重要となる。本論文では、相関という概念を用いる場合は常に厳密な相関を意味する(弱い相関と明示する場合を除く)。
相関に基づくアプローチは、StatsCompressorという名前の、独立型ツールのフォームで実装されている。このツールは顧客のマシン上で動作し、統計値を含むZstatフォーマットのファイルを圧縮し(第2.3.2章参照)、Zstatフォーマットの拡張バージョンであるZplusフォーマットでファイルを出力する。StatsCompressorは、相関に基づくアプローチと、Zstatファイルのフォーマットおよびコンテンツに関するいくつかのドメイン知識とを利用する。
1つのZstatファイルには数千もの統計値が含まれており、各統計値は多数のサンプを持つ。したがって、統計値間には多数の相関が存在し得る。顧客のマシン上で相関を発見することは、それと同時に動作しているHYDRAstorのパフォーマンスに大きな悪影響を与える恐れがあるため、StatsMinerという別のツールを作成することにした。StatsMinerは、サポートサイトのマシン上で動作して、相関の探索に使用するものである。このツールはデータベースファイルを読み、「規則」を含むファイルを作成する。1つの規則は、統計値間の1つの相関を説明するものである。規則は、例えばその相関が何回発見されたか、といった相関の数量に関するメタデータで強化される。StatsCompressorは、StatsMinerで作成された規則を用いて、相関に基づく圧縮を処理する。
StatsMinerとStatsCompressorは、図16に示す分散圧縮モデルを形成する。この図は、顧客から統計値をダウンロードし、この設計されたソフトウェアを用いて圧縮するために処理すべき、継続的な作業を示している。
StatsMinerはサポートチームのサイトで動作し、StatsCompressorは顧客のサイトで動作する。サポートチームは、一連のファイル例上でStatsMinerを動作させて規則のファイルを作成する。このツールの、現在実装されているバージョンは、まだ完全に設計された機能に達していない。中には、本論文で提案されてはいるが時間がなくて実装されていないアルゴリズムもある。しかし、現時点で、StatsMinerによって作成された規則は数が多すぎて、そのすべてをそのまま顧客にアップロードできないため、規則に関して何らかの選択をしなければならない。このように限定された一連の規則を、例えば一連のパッチと更新を含むパッケージなどにして、時々顧客に転送し、顧客のマシンのハードドライブに記憶した。
サポートチームが顧客から統計値をダウンロードする必要がある場合は、Zstatフォーマットの選択されたファイルがStatsCompressorを用いて圧縮される。当然、すべてのZstatファイルを作成時に自動的に圧縮することができるが、それは資源の無駄だと思われる。この研究の目的は、利用可能な帯域幅が限られる場合にサポートによってダウンロードされるサンプル数を増やすことであった。StatsCompressorはドメイン知識のみを利用し、バイトレベルで何らかのアルゴリズムを動作させることはない、と決められていた。この前提の目的は、高レベルの統計値間の相関に焦点を当てることであり、低い、バイトレベルではなかった。この種の圧縮は、既存の汎用コンプレッサの方が早く、より良く実行できると考えられていた。また、このようなアルゴリズムを実装すると、非常にエラーが発生しやすい。準備ができたZplusファイルは、顧客からダウンロードされる。
取得したZplusファイルは、解凍してオリジナルのZstatファイルを再生する(使用した圧縮方法は無損失なので)。本研究を行っている間、時間がなかったためデコンプレッサは実装しなかったが、オリジナルのZstatファイルと解凍したZstatファイルは同一であると思われる。圧縮方法が無損失であることを証明するために、実装した圧縮アルゴリズムについては綿密なレビューを行った。また、StatsCompressorが仕様に沿ったZplusファイルを作成するかどうかをチェックする機能性テストも行った。
ここで述べるStatsMinerとStatsCompressorの協働の分散モデルは最も一般的なものである。他のモデルについては、5.10章で述べる。
以降の章では、参考文献[GKP94]で定義される有限差分の演算子数1の概念を広く用いる:
数2。
なお、以下においては、下記数3で示すように、数1(Δ)の代わりにdを用いるものとする。
第4章 相関マイナー(マイニングツール)
本章ではStatsMinerの説明と評価を述べる。StatsMinerは統計値の相関を発見するためのツールである。発見された相関を説明する規則を用いて、後述するStatsCompressorで統計値を含むファイルの圧縮を行う。
本章には以下のセクションが含まれる。
4.1 「概要」では、StatsMinerの概念、つまりStatsMinerが解決すべき問題、高度なアーキテクチャ、主な前提、および選択された技術、について述べる。
4.2 「テストベッド」では、StatsMinerのテストの方法論、およびこのプロセスで使用するデータについて述べる。
4.3 「ウィンドウ」では、StatsMinerで使用する最も重要なエンティティの1つである、「ウィンドウ」について定義する。この定義とは別に、ウィンドウを生成するための複数のアルゴリズムを提示しており、その内の1つを実装した。
4.4 「発見された規則の記憶」では、発見された規則のRAMへの保存に関する問題点を取り上げる。これは本ツールの性能にとって不可欠であることがわかっている。
4.5 「相関の種類」では、相関発見アルゴリズムの分類を紹介する。
4.6-4.8 「グローバルインターアルゴリズム」、「ローカルインターアルゴリズム」、「イントラアルゴリズム」では、具体的なマイニングアルゴリズムについて述べる。これらは4.5章でカテゴライズされている。なお、StatsMinerについて考え得る特徴の包括的なイメージを構築するために、すべての概念に関して述べているが、すべての概念を実装したわけではない(特にローカルインターアルゴリズムは全く実装していない)。
4.1. 概要
「StatsMiner」という相関マイニングツールは、本論文で述べる研究の一部として作成されたデータマイニングツールであり、統計値間の相関の捜索に使用された。これは、少なくともプロジェクト全体の実験フェーズで、開発者のマシン上で実行されるツールとして作成された。リソースの消費量に応じて、製品化の際に一部または全部のアプリケーションをStatsCompressorと統合させてもよい(5.10.4項を参照)。迅速な製品化を可能にするために、StatsMinerのコードは、コーディング基準と優良実践を順守し、オブジェクト指向で記述された。
このツールはデータベースファイルを読み出し(2.3.2項を参照)、規則を含むCSVファイルを出力する。
4.1.1. 問題の提示
統計値間のいかなる相関も、方程式を用いて記述することができる。 分析された統計値のほぼすべての関係は、一次方程式で記述することができると考えられている(ただし統計の有限差分は許容される)。この前提は、他のジャンルの相関(つまり二次)が出現することを想定しない、HYDRAstor開発者の専門知識に基づくものである。線形代数は、線形依存性を発見するための、いくつかのツールを提供するが(例えばガウス消去法)、2つの欠陥がある。第1の問題点は、分析した統計値の数が、すべての統計のサンプル数と同じでなければならないことである。約50000の統計値があり、さらにそれらの有限差分が含まれている場合、各統計に100000のサンプルが必要になる。また、通常、統計は20秒ごとに収集されるため、23日間に収集されたサンプルが必要なる。この手法における第2の問題点は、ガウス消去法はO(n3)の複雑性を有するため、100000の統計値を使用する場合、その計算には許容できないほどの時間がかかると思われる。これ以外に、メモリ消費量に関する制約もある。C++のダブルスを含む100000×100000のサイズの行列を記憶するのに、メモリの75ギガバイトを消費する。
線形依存性のためのマイニングは不可能であるため、問題を容易にして解決可能にするためには、いくつかの要件を緩和しなければならない。まず、明らかなこととして、相関係数が整数であることがあげられる。これは、統計値が事象の離散空間を記述する性質であることに由来する。残念ながら、整数の係数を持つ、線形依存性を捜索するのは、NP困難な問題である。部分集合−和の問題からのシンプルな削減がある、研究対象の問題は、より制約のあるものに限定することはできないため、別のアプローチを選択した。入力データに対して実行されるシンプルなアルゴリズムは多数あり、その各々によって、統計値間の詳細に定義される様々な関係性が発見される。このアプローチの結果は、線形相関に関する真の捜索から得られる結果の部分集合だが、前述のサブセットの計算は達成可能である。
4.1.2. フェーズ
StatsMinerの主な機能は、統計値における相関を発掘することである。このツールをまず何回か実行したところ、数十億もの相関が発見されることがわかったため、相関に関する詳細な定量的情報の必要性がすぐに明らかになった。さらに、探索するデータ量が膨大であったため(一度に100000個の統計値)、マイニングのプロセスを迅速化するためのヒューリスティックをいくつか用いた。その中で最も重要であったのは、いくつかの統計値に関してある種の相関が発見された場合、それ以外の種類の相関を探索する前に、それらを作業対象集合から除外することであった。これについては、具体的なアルゴリズムについて扱う際に詳細に説明するが、このアプローチの効果の1つは、軽い相関が重い相関を隠すことができる点である。
この状況に対処するため、このツールの作業を2つのフェーズに分けた。第1のフェーズはマイニングフェーズであり(図17)、このフェーズでは統計値集合における相関を一から発掘する。当然ながら、このフェーズは時間がかかるプロセスである。例えば1000000の統計値について採掘する場合、各々が20のサンプルを有すると、約300秒かかる。当然、すべての加速ヒューリスティックが使用される。第2のフェーズは検証である(図18)。このフェーズでは、先に発見された(またはファイルからロードされた)相関の発生を探索し、その相関が作業対象の集合に適用されるかどうかのみをチェックする。前述のデータ集合について、約30秒かかる。
このように複数のフェーズに分割することにより、計算の並列化をより良い方法で行うことが可能となる。マップ−削減(map-reduce)パラダイムは、このツールの使用パターンに適合する。マイニングと検証のフェーズにおいて、研究対象のデータベースファイル集合を複数のマシンに分散し(マッピングステップ)、削減ステップで、生成された規則を含む複数のファイルを簡単に1つに統合することができる。
実際には、マイナー(マイニングツール)と検証ツールは2つの別々のプログラムでもよい。このアプローチは開発費と維持費は高くなるが、双方のパフォーマンスを向上させることができる(各々が、より特定化され調整されるため)。
4.1.3. プログラミング言語の選択
このプログラムは、すべてのHYDRAstorのソフトウェアと同様にLinuxで実行することができ、C++で記述されている。この言語を選択した理由は複数あるが、実際的な理由は、HYDRAstorの開発者がC++とPythonを使用しているため、これら2つのいずれかを選択すれば、既存のコードデータベースが利用でき、また他のプログラマーの助けを得られるため、開発が容易になるからである。また、このプログラムは多くのCPUとメモリを消費することが想定された。Pythonを使用すれば第1の要件は満たすことができると思われるが(C++の方が当然速いが開発プロセスは遅くなる)、第2の要件によってC++を選択した。これは良い判断であった。なぜなら前提が正しいことが証明されたからである。標準構成で実行されるStatsMinerはRAMの数ギガバイトを消費し、もしこのソフトウェアがPythonで記述されていれば、Pythonのガーベジコレクションは劣っているためアプリケーションは使用不能になっていたと思われる。
4.2. テストベッド
4.2.1. テストデータ
StatsMinerのテストはすべて、以下のデータ集合に対して実行された。
1.LRT_A−H4(1つのHNと4つのSNがあった)上でのLong Running Testからランダムに選択した50個のZstatファイル(5327個の利用可能なファイルから選択)。このテストは約2週間継続して行い、HYDRAstorの通常利用およびいくつかの窮状を刺激することを目的とした。上記のファイルはデータベースのフォーマットに変換されたものである。各ファイルは約50 000個 の統計値から構成され、各々が60〜100個のサンプルを有する(ただし1つのファイル内のすべての統計値がほぼ同数のサンプルを有する)。
2.CL−HYDRAstorの実際のユーザ(顧客)から受け取ったファイルの中からランダムに選択した30個のXMLファイル。これらのファイルはHYDRAstorシステムの様々なバージョンで生成されたものであり、様々なパッチと更新が実行されている。このテストには、容量が2MBから4MBでSNで生成されたファイルのみが使用を認められる。選択されたファイルはデータベースフォーマットに変換されている。ファイルは約50 000 個の統計値を含み、各々が140〜240個のサンプルを有する(ただし1つのファイル内のすべての統計値がほぼ同数のサンプルを有する)。
CLとLRT_Aのテストセットでは含まれるファイル数が異なる(30および50)。なぜなら、CLで50個のファイルを使用すると、発見される規則の数が膨大でRAM不足となり実験が成功しない恐れがあるからである。
4.2.2. パフォーマンスの測定
すべてのテストは、Intel Xeons5645のCPUを2つと、48GBのRAMを備える開発マシンで実行した。テストにかかる時間と費用はタイムプログラムを用いて測定し、パラメータ%U(ユーザモードで行われるプロセスのCPU秒数)および%M(その寿命中のプロセスの最大常駐集合サイズ)で実行された。メモリ消費量の結果は修正されたため、既知の計数バグの影響は受けていない[com13]。
4.3. ウィンドウ
「ウィンドウ」はStatsMinerの中心的なコンセプトであり、すべての利用可能な統計値のサンプルの、一連の比較可能な同じ長さのシーケンスとして説明することができる。ウィンドウの長さは個々のシーケンスのサンプル数であり、ウィンドウの幅は統計値の数である。実際のところ、ウィンドウはマトリクスである。なおウィンドウは、それに含まれるサンプルを収集した時間に関する情報を全く含んでいない。これはウィンドウの使用を簡素化する前提である。
図19に、長さ10、幅7のウィンドウの例を示す。1つのファイルを複数をウィンドウに分割することもできる(Zstatファイルの例を示す図15と、前述のファイルから生成された1つのウィンドウを示す図19を比較)。相関を探索する各アルゴリズムは、ウィンドウを入力と想定する。ウィンドウの特性(各統計値に同数のサンプル)のおかげで、マイニングアルゴリズムの実装が簡素化される。ウィンドウを使用するもう一つの利点は、結果の比較に明確な基準があることである。特定数の、きちんと定義されたウィンドウには、常に規則が適用される。一方、このツールで分析されたファイルは統計値ごとに異なる数のサンプルを含むことがある。そのため、「3つのウィンドウで規則が発見された」と言うよりも、「3つのファイルで規則が発見された」という方が、はるかに不明確である。ウィンドウの概念は、検証の際に広範囲に渡って使用される。相関とウィンドウを説明する規則があり、相関がウィンドウに適用できるか(すべての予想統計値が存在するか)、およびサンプルが本当に相関を満たしているか、という2つの事実を確認して、各規則について保存する(図18を参照)。
マイニングアルゴリズムのための入力としての、ウィンドウの内容は、発見された相関の数と種類に重要な影響を与える。ウィンドウのサイズ、およびそれを生成するためのアルゴリズム(データベースファイルからロードした統計値からウィンドウを生成する)、という独立した2つの点が重要である。
ウィンドウの生成は平凡なものに見えるが、このプロセスで直面する問題がいくつかあるため、かなり複雑なものとなっている。前述したとおり、HYDRAstorでは、 統計値は様々な頻度で収集することができ、収集プロセスはユニットのレベルで非同期であり、統計値はどの瞬間にも出現したり消滅する場合があり、最終的にサンプルが可変長のファイル(Zstat)に記憶される。次のセクションでは、ウィンドウを生成するための2つのアルゴリズムについて述べる。
ウィンドウのサイズは、与えられたデータベースファイルにおいて発見される相関の数と品質に非常に大きな影響を与える。 実験により、ウィンドウが小さすぎると発見される相関が偶発的になるため正しい結果を得られない恐れがあるが、ウィンドウが長すぎると、多数の相関を見逃す可能性がある。なぜなら、統計値の収集プロセスが非同期である性質から、厳密な相関が消滅するという点でサンプルが阻害されるからだ。厳密な相関を探すことは弱い相関を探すよりもはるかに容易であるため、厳密な相関は興味深い(4.7.5項を参照)。
相関の品質の測定基準は、その「有意水準」である。相関Cは次の数4で示すように定義される。
ここで、
適用(C)=相関Cが厳密に適用されるウィンドウ数
出現(C)=相関Cによって予測されるすべての統計値が出現するウィンドウ数
を表す。
異なる相関タイプの有意のプロットを4.9章に示す。
明示的な記述がない限り、本論文で述べるすべての規則は長さ10〜20サンプルのウィンドウ上で生成されたものである。
なお、各ウィンドウには、そのすべての統計値の有限差分も含まれており、fとgが統計値である場合、df=gのような何らかの相関があると考えられる。この前提は、何らかの「最近の」統計値があり、それらが最後の数秒間に何らかのパラメータの変化を測定するという事実に基づく。
4.3.1. ウィンドウ生成アルゴリズム
ウィンドウ生成は、マイニングアルゴリズムのためのデータを作成することである。相関を捜索するすべてのアルゴリズムは複数のウィンドウ上で動作するため、データベースからロードされた統計値のサンプルは、複数のウィンドウに分割する必要がある。
本項では、ウィンドウを作成する3つのアプローチを説明する。2つの代替可能なアルゴリズム(グリーディ(貪欲)アルゴリズムとタイムスタンプ認識アルゴリズム)と、ウィンドウのより高度なソースのアイデア(ランダムウィンドウ)である。ただし、実装したのはグリーディアルゴリズムのみであり、これについてのみ詳細に説明する。残りの2つはグリーディアルゴリズムがうまく作動しなかった場合(実際には作動した)に実装可能な拡張(extension)として提示する。
グリーディ(貪欲)アルゴリズム
ウィンドウ生成のためのグリーディアルゴリズムは、最初に実装されたアルゴリズムである。このアルゴリズムのアイデアは基本的に非常にシンプルなものであり、各統計値について、アルゴリズムがデータベースファイルからサンプルをロードし、これらのデータを無制限のサイズの内部サンプルキューに入れる。各統計値は自身のサンプルキューを持つ。すべての統計値のサンプルのキュー(空のものを除く)のサイズが、少なくとも最小ウィンドウ長(M)に等しい場合、まず各統計値のMサンプルが、そのキューから新たなウィンドウに移される。当然、1つのウィンドウは所望する最大長より長くなることはできない。しかし、これらのキューの1つに、最小ウィンドウ長よりも少ないサンプル(N)しか含まれていない場合は、データベースから、さらにサンプルがロードされる。データベースの中にそれ以上サンプルがない場合は、最初のサンプル(N)の数がすべてのバッファから落とされる。
このアルゴリズムが「グリーディ(貪欲)」の言われるのは、サンプルのタイムスタンプを使用しないからである。ウィンドウ が作成された時間について、間違いを起こしやすい状況を招く恐れがあるが、サンプルのタイムスタンプはシフトするため、理論的には、カラム内では比較不能である(つまり、2つの統計値fとgがあり、かつi−thサンプルを分析する場合、f(i)をg(i)と比較することはできない)。幸運なことに、1つのユニットの統計値のi−thサンプルは同じタイムスタンプを有するため、重要なのはユニット間相関である。当然ながら、サンプルのタイムスタンプを考慮しない場合、マイニングアルゴリズムでは2つのユニット間の不適切な相関が発見されることがあるが、このような相関は検証フェーズで低グレードが与えられる。このアルゴリズムに関するもう1つの問題は、多数の統計値が同時に出現または消滅することが発生することである。なぜなら、いかなるウィンドウを作成することも不可能になるからである。
このアルゴリズムの欠点は、主に速度に関する利点によって補われている。計算に使用するサンプル総数がnである場合、アルゴリズムの複雑性はO(n)である。このように生成された相関の使いやすさが、このアルゴリズムのもう1つの良い点である。なぜなら、StatsMinerがタイムスタンプを使用しない場合、StatsCompressorもこれを必要としないため、このツールがより速く、よりシンプルになり、わずかなサンプルのシーケンスを使って相関の適用を試みることができる。最後に、このアルゴリズムの実装は非常に迅速に行われ、また発見された相関数が十分に多いため、非常に利用しやすい。
タイムスタンプ認識アルゴリズム
グリーディアルゴリズムの主な問題点は、サンプルのタイムスタンプを考慮しないことである。この問題に対処するため、タイムスタンプ認識アルゴリズムの設計を計画した。しかし、その一方で、データベースフォーマットにおけるファイルの生成装置が改良され、グリーディアルゴリズムが以前よりも良い動作をするようになった(より多くのウィンドウが作成された)。さらに、StatsCompressorによって良い圧縮率が達成される一方、グリーディ(貪欲)な方法で作成されたウィンドウに含まれる規則によって、ウィンドウ生成においてタイムスタンプを使用することが以前ほど不可欠ではないことがわかった。そのため、タイムスタンプ認識アルゴリズムは作成せず、また実装されたいずれのアルゴリズムでもタイムスタンプは使用されていないため、本論文ではサンプルのタイムスタンプに関する詳細な説明は省略する。
ランダムウィンドウ
ランダムウィンドウは、前述のアルゴリズムによって生成されたウィンドウを再利用(あるいは「リサイクル」)するというアイデアである。前述のとおり、StatsGatherプロセスは非同期であるため、2つのユニットからの統計値間に相関が客観的に存在する場合でも、比較するサンプル間にわずかな偏差があれば、相関が発見されない可能性がある。このような現象は理論上だけのものではなく、現実のデータにおいても観測された。ウィンドウのサイズは10から20サンプルに設定され、明らかに同一の2つの統計値には10%の確率で偏差があった。残念ながら、生成された各ウィンドウに少なくとも1つの偏差があったため、相関は発見されなかった。ランダムウィンドウはこの問題を解決する。
そのアイデアは、古典的な方法で生成された複数のウィンドウからランダムに取得したサンプルのいくつかの列から、ウィンドウを作成する、というものである。例えば、第1のウィンドウの4番目、6番目、7番目のサンプルと、第2のウィンドウの1番目、6番目、8番目のサンプルを新たなランダムウィンドウに移行する。これらのサンプルはもはや連続するものではないが、この新たなウィンドウは、当然、ウィンドウの定義によるすべての期待値を満たすものである。
一連のサンプルを取り出したウィンドウの長さの合計によって、ランダムウィンドウの概念はサンプルにおける偏差の問題の助けとなる。当然、偏差の確率は同様に存在するが、1つのデータベースから、通常のウィンドウに比べてより多くのランダムウィンドウを生成することができ、生成するランダムウィンドウの数が多いほど、偏差のないランダムウィンドウを得る可能性が高くなる。したがって、これまで隠れていた厳密な相関が含まれる。さらに、ランダムウィンドウの生成にかかる費用は非常に安い。なぜなら、すべてのサンプルが既にメモリに記憶されており(データベースからデータを読み出す必要がない)、古いウィンドウと新たなランダムウィンドウとの間でサンプルをコピーしないようにプログラムすることができるからである。
時間がなかったため、このアルゴリズムは実装しなかったが、これはStatsMinerの容易かつ効率的な拡張になると思われる。
4.3.2. まとめ
ウィンドウは、統計値およびそのサンプルを入れる便利な容器であり、これによって、マイニングアルゴリズムの実装が非常に簡単になる。ウィンドウの作成方法は、StatsMinerによって発見される規則に大きな影響を与える。1つのパラメータはウィンドウの長さであり(幅はデータベースからロードされるデータによって異なる)、もう1つはサンプルのウィンドウへの挿入に使用するアルゴリズムである。本章で述べた概念の中で唯一実装したのはグリーディアルゴリズムである。実際に、このアルゴリズムはよく動作した(この方法で作成したウィンドウで多くの規則が発見された)が、タイムスタンプ認識アルゴリズムを使用すれば、より現実的な相関が得られる可能性がある。一方、ランダムウィンドウは、弱い相関の発見が不可能であるという、膨大な マイニングアルゴリズムの限界に対処する手段である。
4.4. 発見された規則の記憶
StatsMinerは統計値間の相関を発見し、取得した知識を保存するための規則を作成する。この規則は何らかの方法でメモリに記憶され、その後ハードドライブに記憶される。これをシンプルな方法で行うための2つの相対する方法(組み合わせによるアプローチと、抽象クラス(abstract-class)に基づくアプローチ)と、よりシンプルな方法からの最善のアイデアに基づく複雑な方法(ツリーを使用)が1つある。本章では、f、g、等は異なる統計値を表す。
規則を記憶するための「組み合わせ法」において、特定の統計値の各相関は別々に記憶される。例えば、相関f=gがある場合、fとgの同一性を説明する規則が記憶される
しかし、相関f1=g1=h1を保存するためには、3つの同一性規則を用いる必要があり、この3つの同一性規則の各々は2つの特定の統計値間の関係を説明するものである。「抽象クラス法」では、相関f=gの記憶に規則を1つだけ用い、相関f1=g1=h1の記憶に規則をもう一つだけ用いる。
組み合わせ法を使用するとメモリの消費量が多くなる。例えば、単純和p=q+r(ただし、p=p1、q=q1=q2、r=r1=r2=r3)を扱う場合、すべての相関を記憶するためには24もの規則が作成されることになる、抽象クラス法では、各抽象クラスに1つずつ、単純和に1つ、計4つの規則が作成されるだけである。ここで問題となるのは、p、q、rの抽象クラスを説明する他の規則のコンテクストにおいて、p=q=rを保存してこの規則をしようするのか、それとも、((p=p1)=(q=q1=q2)+(r=r1=r2=r3))として和を保存するのか、である。メモリ消費量という観点からは、抽象クラスに基づくアプローチの方が確実に優れていると思われるが、複数のウィンドウを扱う場合、状況はより複雑になる。
ウィンドウW1において、前記の相関(和)は発見されたと仮定する。ただし、ウィンドウW2は類似しているが同じ相関ではなくp=p1、q=q1=q2、r1=r2=r3(数5)である。組み合わせ方が用いられた場合、この変化によって新たな規則が作成されることはなく、既存の規則の使用カウンタ(有意性の計算に使用)を更新するだけでよい。同時に、抽象クラスのアプローチには良い解決策がない。1つのアイデアとして、クラスr1=r2=r3(or(p=p1)=(q=q1=q2)+(r1=r2=r3))を説明する新たな規則を加える方法があるが、規則p=q=rをどうするのか、つまり、p=q=r1を加えるのか?と言う問題がある。もしそうなら、W1の場合、同じ相関が2回表されることになる(したがって検証フェーズでカウントされる)。この問題は、規則(p=p1)=(q=q1=q2)+(r=r1=r2=r3)を、(p=p1)=(q=q1=q2)+(r1=r2=r3)、および(p=p1)=(q=q1=q2)+(r)という2つの規則に分割すれば解決される可能性がある。これにより、使用カウンタの誤った値の問題は解決するが、(p,p1)、(q,q1,q2)、(r,r1,r2,r3)の部分集合のあらゆる組み合わせが発生するため、規則の総数が指数関数的に大きくなる。一方、規則p=q=rを使用することもできるが、クラスr1=rがあり、推移閉包の概念が利用されることがある。しかし、この場合、抽象クラスの数とサイズが大きくなるにつれて、すべてのウィンドウにすべての規則が適用され、その結果、規則の使用カウンタはまったく誤った結果を導くものとなる。
要するに、抽象クラスに基づく方法は、メモリ消費量と使用カウンタの正確性との間でトレードオフの関係にある。加えて、組み合わせ方では、検証の前後での規則数が同じであるが、抽象クラス法では、カウンタ問題に対する救済措置として規則の分割が選択された場合、検証後の規則数が劇的に増加する可能性がある。
この2つの方法の利点を合わせると、各規則をツリーとして記憶し、すべての規則で森を作成することになる。本論文ではこの方法のドラフトのみを記載する。ツリーの根には相関の最も一般的な形式が含まれ(例えば、(p=p1)=(q=q1=q2)+(r=r1=r2=r3)、図20参照)、内部ノードには抽象クラスの分割に関する情報のリストが含まれ(例えば数6andr)、葉には使用カウンタが含まれる。根から葉まで辿ると、訪問した内部ノードから根に存在する規則までのカット(cuts)を適用することによって作成された一連の相関の使用カウンタの値がわかる。この表し方で使用するメモリは、シングルトンの抽象クラスしか存在しない場合は、少なくとも抽象クラスの方法で使用するメモリ(内部ノードがない場合)と同量で、組み合わせ法よりも少ない(ツリーの実装の詳細に関して)。このデータ構造の複雑な点は、メモリ効率のコストである。なお、この記載はあくまでもこの方法のドラフトであり、実際のテストは行っていない。
設計上の解決策としては、組み合わせ法を選択した。なぜなら、組み合わせ法の方が実装がシンプルで、動作が速く(抽象クラスの分割は費用が高いと思われる)、十分に正確で、メモリ消費量が予測可能だからである(ただし消費量は多い)。さらに、組み合わせ法で記憶される規則は視覚化または合計することが簡単で、いくつかのオペレーションをカウンタに作ればいいだけである。規則がハードドライブに降ろされると、これらはCSVフォーマットで記憶されるため、LibreOffice、Microsoft Excel、または単なるbashスクリプト等のツールを用いて簡単に操作することができる。
抽象クラスに基づく方法は、規則を消費者のサイトに記憶する場合にそのサイズを縮小する方法となる可能性がある。すべてのマイニングを組み合わせ法で行い、その後、実際にクライアントに送信するデータを抽象クラスのフォームに変換してもよい(特にその時点で使用カウンタが必要ない場合)。これは、ある種の、規則ファイルの無損失圧縮と考えることができる。
4.5. 相関のタイプ
相関は、2つの主なカテゴリーである「内(intra)」と「間(inter)」に分けられる。最も興味深いのは「値間相関(inter correlations)」であり、これは2つの異なる統計値間の関係を表現する。このタイプの基本的な例は同一性(identity)である(fとgが2つの統計値である場合、f= g)。これとまったく異なるのが「内的相関(intra correlations)」であり、1つの統計値にのみ影響し、その統計値の再現可能な特性を表す。内的相関の最もシンプルな例は定数である。
これ以外の相関の分類は、大規模な統計値の集合における相関を探索する能力である、マイニングアルゴリズムの技術的制約と関連するものである。シンプルな相関(同一性のようなもの)のほとんどのタイプを探すには、すべての利用可能な統計値(定数の統計値を除き70000)を含む集合において、探索を実行すればよい。このような相関(およびそのマイニングアルゴリズム)を「グローバルな(全体)相関」(global correlations)と言う。一方、一次結合のような、より些細な相関は、一度に複数の統計値間では効果的に発見することはできない(例えば、一度に1000以下)。このような相関(およびアルゴリズム)を「ローカルな(局所)相関」(local correlations)という。ローカルマイニングアルゴリズムを使用するには、まず、そのアルゴリズムが動作する、すべての利用可能な統計値のうちの部分集合を選択する必要がある。これが、全体的なマイニングアルゴリズムと局所的なマイニングアルゴリズムの主な違いである。
圧縮という観点では、値間相関は最も有益である。全体的か局所的かを区別する意味はないが、全体相関の方が局所相関よりも数が多いことが望ましい。一方、全体相関のためのマイニングの方が、よりシンプルでコストが安いと考えられ、この種の分析は、もしCPUとメモリ消費量が許容レベルであれば顧客側で行ってもよい。
なお、第3章では「厳密な相関」と「弱い相関」の区別について述べたが、基本的に本論文で述べている相関はすべて厳密なものである。
4.6. グローバル・インター・アルゴリズム(全体的値間アルゴリズム)
前述のとおり、一般的な一次結合の探索はコストが高すぎるが、一次結合のいくつかのクラスを簡単に発見することもできる。インターアルゴリズムは、ウィンドウ内の異なる統計値間における、このような特別な種類の関係を探索する。本章および後続の章では、nはウィンドウ内の統計値数(ウィンドウの幅)、kは各統計値のサンプル数(ウィンドウの長さ)を表す。
なお、提示したアルゴリズムのうち、実際に実装して評価したのは、同一性発見のためのソートアルゴリズムと、単純和発見のためのブルートアルゴリズムだけである。これ以外のアルゴリズムは、パフォーマンスが満足できるものでなかった場合の代替案として扱うべきである。いくつかのアルゴリズムには、前述した拡張が可能なものもある。これらの拡張は、発見される規則の数を増加させる可能性がある。
4.6.1 同一性のためのマイニング
同一性は値間相関の最も基本的な例である。同一性の数は極めて多いと考えられる。なぜなら、システムの異なるレイヤーにおいて、例えば受信または送信したメッセージ数などの、同じ事象が独立してしばしば記録されるからである。
同一性を探索するアルゴリズムは、ウィンドウ内のサンプルのベクトルの抽象クラスを発見する。後続のマイニングアルゴリズムの動作時間を短くするために(図17参照)、ウィンドウ内には各抽象クラスの代表1つしか残さず、残りのメンバーは除去される。平均的に、IdentityMiner は、入力として20366個の統計値を含むウィンドウを取得し、12236個の統計値を含むウィンドウを出力する(これらの値はLRT_Aデータ集合用に計算された)。
同一性発見のためのソートアルゴリズム
説明
このアルゴリズムのアイデアは極めてシンプルで、各統計値をサンプルのベクトルとして扱うことで、統計値は、サンプル値の辞書式のコンパレータを用いてソートされる、というものである。アルゴリズムのこのステップは、Merge Sortのような標準的なアルゴリズムを使用した場合は、O(kn log n)の複雑性を有する。複雑性(数7)の下限は意思決定ツリー分析(参考文献[Knu98] )に由来し、この複雑性は、参考文献[FG05]に記載するアルゴリズムによって達成されている。 しかし、StatsMinerではサンプルのベクトルはポインタでアクセスされているため、上記論文の著者は、古典的なQuick Sortも複雑性O(nk + n log n)を持ってもよいと提案している。
サンプルのベクトルをソートした後、後続のベクトルが同一であり同一性相関が登録できるかどうかを確認するのにO(nk)時間かかる。要するに、実装されたアルゴリズムは複雑性O(nk log n)を有しており、最適なケースの複雑性O(nk + n log n)は論理上達成可能だが、より多くの努力が必要である。
当然ながら、2つの統計値fとgがウィンドウ内で同一であれば、それらの有限差分も同一である(df=dg)。しかし、その反対はない(数8)。StatsMinerの目的は、StatsCompressorのための規則を作成して規則f=gを保存することである。実際のパフォーマンス上の理由により、規則df=dgが作成されることはない。なぜなら(df=dgかつ数9)の例はそれほど多くないという全体に基づくヒューリスティックだからである。
テスト結果
このアルゴリズムは高速で(理論上、最適なものではないが)、多数の規則を作成する。ウィンドウの例(図19)では、次の規則が作成される:
1.stat_alpha = stat_beta.
2.stat_beta = d stat_gamma.
3.stat_alpha = d stat_gamma.
真のHYDRAstorの統計値(これらの名称の意味の説明にはシステム内部の詳細な説明が必要となるため、省略する)において発見される同一性のいくつかは次のとおり:
1.DISK::sdb8::readsMergedPerSec = DISK::sdb8::readsPerSec
2.METRIC::Aio::aioCtx-shred::AioStat::numberReqsStarted = METRIC::Aio::aioCtx-shred::AioStat::numberReqsCompleted
3.METRIC::transaction::FP::05DM::tl::syncs::req::NumStarted = METRIC::transaction::FP::05DM::tl::creations::req::NumStarted
Customers’ Logs上でアルゴリズムを実行したら(計)21秒かかり、776814個の規則が作成された(分析したウィンドウ1つ当たり平均57210個)。(なお1つの規則が複数のウィンドウで発見される場合があるため、個別のウィンドウごとの場合は「分析したウィンドウ1つ当たりの平均規則数」に影響を与えるが、生成された規則の「総数」に関する議論では一度しかカウントされない。)LRT_Aデータに関する分析の結果、54秒間に561560個の規則を発見した(分析したウィンドウ1つ当たり平均29026個)。この結果については4.9章で述べる。発見された規則の有意性についても4.9章で述べる。
同一性発見のためのハッシュアルゴリズム
説明
前記のアルゴリズムの主な問題点は、最悪のシナリオの場合、一連のベクトルに対して、各ベクトル内のすべてのサンプルの値を比較して順序付ける必要があることである。ソートアルゴリズムの速度を改善する最もシンプルな方法の1つは、まずベクトルのハッシュを比較し、ハッシュが等しい場合のみベクトル値の比較に戻る、という方法である。前述のアルゴリズムのこれ以外の部分については、変更はない。ハッシュの方法は自由に選択してよい。
このアルゴリズムにおける最悪のケースの複雑性には、依然としてO(nk log n)があるが、平均的なケースの複雑性はO(nk + n log n)である。重要なのは、ベクトルのハッシュが既に実装されていれば、通常のソートアルゴリズムをハッシュバージョンにアップグレードするのは非常にシンプルだ、ということである。
同一性発見のためのソートアルゴリズムはうまく機能したため、ハッシュバージョンは実行していない。
4.6.2. 単純和(simple sums)のためのマイニング
単純和は、すべての係数が1に等しい(f=g+h+...)統計値の和である。この種の関係は、統計値の間では非常に一般的だと思われる。なぜなら、イベントのクラスの数を表すカウンタと、それ以外の、サブクラスのイベント数を表すカウンタの両方があるからだ。より具体的には、HYDRAstorからの例は次のとおりである:
METRIC::transaction::FI::State::opened::NumStarted = METRIC
::transaction::FI::State::opened::NumOutstanding + METRIC
::transaction::FI::State::opened::NumFinished.
和にエレメントが多いほどアルゴリズムの複雑性が高くなる。下記に示すアルゴリズムは2つの統計値の和(f=g+h)を探すために設計された。なぜなら、これ以外では、理論上の複雑性があまりにも高かったからである。実際には、そのパフォーマンスが許容できるものであれば、これらのアルゴリズムを利用して、もっと多くのエレメントの和を探索することも可能である。なぜなら、これに代わる既知のものは完全な一次結合(4.7.4項参照)を探索するものだけであり、それもやはりコストが高く、また局所的な方法だけだからである。
単純和のためのマイニングは非常にコストがかかるため、この時点であらゆる不要な作業を避ける必要がある。和のためのマイニングを、同一性のためのマイニングと同時に実行する場合は、ウィンドウ内の同一性のためのマイニングのアルゴリズムによって発見された抽象クラスはすべて、1つの代表値のみに減らすことができる。もしこの代表値がいずれかの和の中に出現したら、その抽象クラスの各メンバーが同じ場所に出現する可能性がある。前述のとおり、StatsMinerは組み合わせの形式で規則をメモリに記憶する。そのため、1つの抽象クラスの代表値が出現する規則を探すことによって、 そのデータベースに複数の新たな規則を追加することになる。そのため、StatsMinerは膨大な量(多くのギガバイト)のメモリを使用し、さらに、パフォーマンスの低下が観測される(データ構造を横断するため)。当然、一般的には、多数の和の規則が作成されることは良いことだが、圧縮の観点では、和の規則よりも同一性の規則が優先され、あまりにも多くの和の規則を作成することは、単なる資源の無駄である。なぜなら、これらは実際には役に立たないからだ。メモリ消費をわずかに削減するために、有限差分のみで構成される和の捜索は行わないことに決定した(これらは発見されるが廃棄する。)この種の関係は、実際には一般的でないが、ときどき出現することもあると考えらえる。これによってStatsMinerのパフォーマンスが実質的に向上したため、幸運な決定であった。以前は開発者のマシンのメモリがすぐに不足したが、約30GBのメモリの使用でLRT_A集合におけるマイニングを終了することができた。
平均すると、本章で述べたクラスのアルゴリズムはいずれも、入力として12236個の統計値を含むウィンドウを得ている(LRT_A集合用に)。
単純和の発見のためのブルートアルゴリズム
説明
ブルートアルゴリズムはあまり洗練されたものではなく、2つ統計値ごとに、そのサンプルを合計して、その結果が既存の統計値と等しいかどうかを確認する。このアルゴリズムのコストはO(kn2+kn2 log n) = O(kn2 log n)である。その理由は、計算する統計値の数は下記(数10)対あり、1対の計算はkまで線上であり、その結果が既存の統計値と等しいかどうか確認するということは、記憶されている統計値の集合の中で二分探索を行うことであり、O(k log n)の複雑性がある。
上記の計算モデルは、加算には可換性があることを示している。浮動小数点数については、2つ以上の要素のシーケンスを合計する場合、その代表値が異なる指数を用いている場合は、これは正しくない。さらに、わずか2つの要素の合計を求めただけだが、結果の切り上げ(数値誤差)は、このアルゴリズムの実装において実際に問題となった。解決策として、サンプルの記憶に(通常のダブルスではなく)長いダブルスを使用した。
テスト結果
このアルゴリズムは、Customer Logs用に(計)25803555個の規則を作成し、6137秒間作動した(分析したウィンドウ1つ当たり平均4601590個)。LRTにおけるマイニングの結果、20 402秒(340分)間に(計)13738732個の規則が発見され、平均すると、分析されたウィンドウ1つ当たり431 324個の規則が発見された。アルゴリズムを長時間動かすことになった理由は、規則の記憶に組み合わせ形式を使用したため、規則のデータベースを更新したからである。この結果については4.9章で述べる。発見された規則の有意性についても4.9章で述べる。
このアルゴリズムは、ウィンドウ例(図19)において次の規則を発見すると思われる:stat_delta=stat_epsilon+dstat_zeta.
真のHYDRAstorの統計値(これらの名称の意味の説明にはシステム内部の詳細な説明が必要となるため、省略する)において発見される和の規則には、次のようなものがある:
1.METRIC::dci::NumFinisedGetReqs = METRIC
::dci::HintVector@WI::NumNegHintHits(finitdifference)
+ METRIC::dci::NumHashArrayGetReqs(finitdifference)
2.DISK::sdl2::totalBandwidth = DISK::sdl::writeBandwidth
+ DISK::sdl::readBan dwidth
3.DISK::sdb6::writesMergedPerSec = DISK::sdb12::readsMergedPerSec
+ METRIC::ackCollector::dataLocs::dataLocCacheSize::RecentAvg
可能な拡張
この素朴なアルゴリズムは非常にコストがかかり、3つの要素の和を探索するのは、まったく良い考えでなないと思われる。その一方で、シンプルなヒューリスティックを行ってリーズナブルにすることができる。いくつかの統計値(lhss、左項)が、他の統計値の和と等しいことがわかった後で、lhssを合計して、その結果が他の既存の統計値と同じではないのかどうかを確認してみればよい。このアイデアは、カウンタには階層が存在し、イベントの数量について知らせるゼロレベルのカウンタと、ゼロレベルのカウンタなどの和である第1レベルのカウンタがある、という考えに基づいている。
単純和を発見するためのハッシュアルゴリズム
加法的ハッシュ
StatsMinerのCPU消費量を説明する方法としてのハッシュについては、同一性を発見するためのハッシュアルゴリズムについて述べることで、すでに提案した(4.6.1項参照)。和を発見するプロセスでもこの方法を利用することができるが、加法的ハッシュという特別なハッシュ関数を用いる必要がある。
加法的ハッシュ関数は次のような特性を有する:
数11
ここで、
数12、13
を表す。
実際のところ、このような機能は、線形代数の観点から見るとある種の「弱められた」線形機能である。
良いハッシュ関数には、次の2つの特性が必要である(参考文献[Knu98]による):
1.ハッシュ値の計算が速いこと。
2.衝突の回数が最小限であること。
下記の関数は本章で述べた基準をすべて満たす(「良いハッシュ関数」であり線形でもある):
数14
ここで、
数15、16
b:大きな自然数
を表す。
上記の関数Hは付加的なものである。なぜなら、使用するすべての演算は付加的だからである。高速で計算され、SIMD命令を使用して計算速度を上げることができる(コンパイラが自動的にベクトル化できるような方法でこの関数を実行するのは簡単である)。この関数にはプロトタイプ実現があり、bができる限り大きく(素数が好ましいが、64ビットのマシンでは264の方が現実的)cが十分に大きい素数である場合、衝突の回数が許容できるレベルであることが分かった。そのため、下記数18のほとんどの値については、数17が成り立つ。一方、Hはある種のモジュラーハッシュ関数を表し、このような関数は良い特性を持つと考えられる(参考文献[Knu98]による)。
前述の関数は(アルゴリズム全体として)暫定的に実装されている。IEEE754の浮動小数点について作業はしているもののハッシュの浮動小数点値が不可能であるため(四捨五入するとすべてのアイデアが利用不能になる)、これ以上の作業(および実験)は中断されている。固定小数点数演算を用いればこの問題を解決できるが、結果として、これは行われていない。そのため、このアルゴリズムがよく機能したのは整数値に関してのみであった。
説明
ハッシュアルゴリズムはブルートアルゴリズムと似ているが、和と比較について改善された方法を用いている。加法的ハッシュのおかげで、素朴なアルゴリズムの複雑性から因数kを除去することができたため、ハッシュアルゴリズムはO(kn + n2+ n2log n) = O(kn + n2log n)の平均時間複雑性を持つ。ブルートアルゴリズムの複雑性における因数kはサンプルの比較と和から得られるものであるが、前述のハッシュ法を使用する場合、両方の演算は(O(1))時間で送られる。当然、すべての統計値のハッシュがまず計算され、このステップは(O(kn))の複雑性を持つが、その一方で、メモリへのデータのロードにも同様の複雑性があるため、実際にはこのコストを無視することができる。
テスト結果
このアルゴリズムでは、パフォーマンス実験結果は何も得られなかった。なぜなら、これは部分的に行われただけで十分に調整されておらず、また前述のとおり、浮動小数点のサンプルでは適切に機能しないからである。
可能な拡張
当然ながら、ブルートアルゴリズムを示して説明したヒューリスティックは、このハッシュにも利用できる。欠点は、カウンタの階層の現象が整数値のカウンタにしか現れないと思われることである。そのため、弱いハッシュ法(小数値をサポートしないもの)でも十分だと考えられる。そのため、ブルートアルゴリズムを用いて第1レベルのカウンタを探し、ハッシュアルゴリズムを使って上位のカウンタを探すという、ハイブリッドなアプローチが考えられる。カウンタの階層が整数値の統計値に現れるという考えは、一般的に時間を説明するのに分数値の統計値が使用されており、これらが合計されることはあまりない、という前提に基づいている。さらに、分数値の上位カウンタがあったとしても、おそらく浮動小数点の性質により既に何らかの数値誤差が含まれている可能性があるため、これらの和を出すことは極めて難しいと思われる。
4.6.3. まとめ
グローバルインターアルゴリズムはStatsMinerの規則の最も重要なソースである。上述した概念のうち、同一性発見のためのソートアルゴリズムと単純和発見のためのブルートアルゴリズムは完全に実装され、(機能性の)テストと評価が行われた。その結果、これらのアルゴリズムは膨大な数の相関を発見することができ、また主な問題点は規則を記憶する方法であることがわかった。
4.7. ローカル・インター・アルゴリズム(局所的値間アルゴリズム)
本章で説明するアルゴリズムは、その性質または複雑性により、すべてのウィンドウ上で実行することはできない。残念ながら、ここで示すアイデアは前記のソフトウェアでは実行されていない。なぜなら、プロジェクトの時間的な制約があったため、これらのアイデアは将来のためのドラフトとして扱わなければならなかった。
4.7.1. ウィンドウ幅の制限
ランダムな選択
ウィンドウの幅を制限する最もシンプルな方法(「削減されたウィンドウ」という)は、所望する統計値の数をランダムに選択することである。
十分な大きさの集合上でマイニングアルゴリズムがよく動作するなら、これは良いアイデアであろう。例えば、LRT_A集合上でマイニングを行う場合、ローカルインターアルゴリズムの動作が予定されている場合、ウィンドウには一度に約15 000個の統計値がある(図17参照)。ローカルインターアルゴリズムが、ウィンドウのサイズを1000個の統計値まで削減することを許容するなら、これらのウィンドウのコンテンツをランダムに選択することは良いアイデアだと思われる(ただし実際したテストする必要がある)。一方、30個の統計値しか含まないウィンドウで、このアルゴリズムが動作する場合(こちらの方が好ましい)、何等かの知識に基づく統計値の選択方法を考慮する必要があるため、ウィンドウ内の統計値に関係性がある可能性が高い。
4.7.2. 知識に基づく選択
データマイニングにおいて、類似する対象をグループ分けするための古典的なアプローチは、クラスタリングである。この分野では多くの研究が行われており、様々なクラスタリングの方法が提案されている。参考文献[Sch07]は、現時点における最新技術を概説している。最適なアルゴリズムの選択に関する提案が出される前は、相関の可能性がある統計値を選択する上での問題は、クラスタリングという用語に変換された。
統計値のグラフ
アルゴリズムのクラスタリングには、入力として加重グラフが必要となる。統計値のクラスタリングの場合、頂点は統計値を表し、エッジのウエイトは統計値の類似性を説明する。この時点では、グラフが方向性を持つかどうかを述べるのは難しい。方向性を持つグラフは、方向性を持たないものよりも2倍のエッジを含むため、クラスタリングは遅くなるが、より多くの情報を保存することができる。問題なのは、方向性を持つグラフのこのような性質が、クラスタの中で発見される真の相関の数に関して効率的に使用できるかどうか、という点である。これは実験で確認できるである。統計値の類似性を評価するヒューリスティックはすべて、両バージョンのグラフに適用できる。
エッジのウエイトの決定
エッジのウエイトは、接続する頂点(統計値を表す)の類似性を表す。類似性を評価する各ヒューリスティック(後に簡単に説明する)は、範囲[0; 1]から浮動小数点を返す。問題なのは、異なる値を返すヒューリスティックがある場合に、エッジのウエイトがどうなるか、である。これには、主に、
1.ヒューリスティックによって返された値の加重平均、
2.ヒューリスティックによって返された値の最小値または最大値の選択
という2つのアプローチがあり、これらは、ある程度は組み合わせることができる。
エッジのウエイトをどのように決めるかは、いくつかの実験結果に基づいて判断する。
4.7.3. 類似性のヒューリスティック
本章で提案するヒューリスティックは、入力として与えられた2つの統計値の類似性を評価する。分析用の一連の統計値を作成することは分析自体よりも時間がかからないため、パフォーマンスが重大な要件である。ここではヒューリスティックの概念のみを述べる。
ヒューリスティックは、静的および動的という2つの相対するカテゴリーに分類される。静的ヒューリスティックは、動的なものとは異なり、分析される統計値のサンプルの実際の値を使用しない。主に統計値の名前を分析し、開発者がその中に残した知識の回復を試みる。この手法は、人間は組織的な方法で物事に名前を付けるものであり、類似する実体に名前を付けるにはいくつかの方法しかない、という考えに基づく。一方、動的ヒューリスティックは統計値の値に基づくものであり、現在のウィンドウ内に存在する類似性の発見を試みる。
ウィンドウ内の統計値間の類似性の包括的なイメージを得るためには、どちらのヒューリスティックも使用するべきである。なぜなら、いずれのヒューリスティックにも欠点があり、これらは他方によって(ある程度は)緩和されるからだ。静的ヒューリスティックは、一般的な知識を統合する。これは特定の状況には適用することができない。これに対し、動的ヒューリスティックは、その結果に局所的な視点を追加する。その一方で、動的な統計値は、何ら共通性のない統計値の偶然の類似性によってバイアスされる可能性が高いが、これは静的ヒューリスティックでしか発見されない。
静的ヒューリスティック
同一プリフィックス
Names of 統計値 in HYDRAstor内の統計値の名前は用語リストで構成されており、これらの用語は一般的なものから専門的なものへと並んでいる。実際、統計値の名前はツリーを構成する(2.3.2.項を参照)。名前のツリーの統計値におけるパスが短いほど(共通プリフィクスが長いほど)、類似性は高い。非常に類似する統計値の例は次のものがある。
METRIC:DataSynch::SynchronizerTask::SCC_RECONSTRUCTION::numTasksStartedおよび
METRIC::DataSynch::SynchronizerTask::SCC_RECONSTRUCTION::numTasksFinished.
同一ステム(stems)
常に述べているように、統計値の名前は用語リストで構成される。さらに、これらの各用語は、CamelCaseの表記法でかかれた単語(ステムという)から構築される。そのため、長い名前から単一のステムを簡単に抽出することができる。自然の言語は、名前の付けるという点で非常に柔軟性があるが、類似する物事に名前を付けるのに利用できる単語には制限がある。例えば
METRIC::DataSynch::SccCache::SccChunksCount
およびMETRIC::memory::PerClass::DataSynch::SingleSccCache::SUM
は、わずかに異なる名前だが、実際には同じものをあらわしており、またこれらの名前は同様のステムを共有している。この考察は、類似性を持つ統計値の発見のためのスマートなヒューリスティックの構築に利用することができる。つまり、類似性を持つ統計値は、その名前に多くの共通するステムを含む、ということである。
同一送信者
Zstat filesは、統計値が収集されたユニット(統計値の送信者)に関する情報を含む。これは以下のヒューリスティックの基本となる。すなわち、同じユニットからの統計値は、別のユニットからのものよりも、類似性が高い、ということである。この手法は、1つのユニットは詳細に定義された幅の狭い起泡性を持つため、2つの統計値ら相関のある事象を測定する機会が多い、という考察に基づく。一方、異なるユニットからの統計値間の関係の方が(理論的な観点では)より興味深いと思われる(HYDRAstor内における予期しない依存関係が明らかになるからだ)。
同一タイプ
Zstat filesには、統計値のタイプ(フロート、割合、カウンタ、等)に関する情報が含まれる。一般的に、相関は同じタイプの統計値間の方が発見される。ただし、いくつかの例外も知られている。(特に、1秒当たりの事象数を測定するタイマーについては、例外も知られている。例えば、METRIC::flowControl::node::SlotsComputer::Bandwidth::duplicateWriteCountPerSec)。
動的ヒューリスティック
相関
ウィンドウ内ですでに相関関係にある統計値は、非常に類似性があるもtのとして扱うべきである。同一性の場合は、頂点を統合することもできるが、統合された頂点を他のものと連結するエッジのウエイトの問題がある。このため、「完全な類似性」を意味するウエイトを有するエッジが好ましい。一方。相関により多くの統計値が関与していると、それらの間の類似性は低くなる(例えば、相関f0=f1+f2とg0=g1+g2+g3がある場合、f0、f1、f2はg0、g1、g2、g3よりも類似性が高い)。
同数の値の変化
すべての統計値が、サンプルとして取得されるたびに値が変化するわけではない。統計値の1つが、いくつかの和(f=g+h+k)であると仮定すると、fの値は、最も多い場合で、g、h、kの値が変化するのと同じ回数だけ変化する。当然、fの値は変わらないが(g = −h、k = 一定の場合)、このような状況はめったに起こらないと考えられる。
g、h、kのサンプルと同時にのみ、fのいくつかのサンプルの値が変化すると仮定すると、前述のヒューリスティックを拡張することができる。残念ながら、統計値は非同期に収集されるため、時間のずれがあり、実際には全体の概念が利用不能になる場合がある。しかし、これは実験で確認する。
クラスタリングアルゴリズム
サーベイ[Sch07]には、利用可能な汎用クラスタリングアルゴリズムに関する包括的な記載がある。選択するアルゴリズムは、次の特性を持つものでなければならない。
1.クラスタのマトリクスのサイズの制御が可能であること。
2.多くのクラスタで、単一の頂点が出現すること(クラスタは重なる)。
3.アルゴリズムが高速でメモリ消費量が多くないこと。
3つ目の点は非常に重要である。なぜなら、クラスタリングアルゴリズムがあまりにも遅いと、ウィンドウのサイズを制限するプロセスが役に立たなくなるからだ。そのため、グラフの構築とクラスタの選択は十分に早くなるよう、アルゴリズムの選択はパフォーマンスの実験に基づくものでなければならない。前述の要件に適用可能なアルゴリズムで最もシンプルなものは、この時点で残っている統計値の数だけウィンドウ数を削減すること、つまり統計1つにつき1つのウィンドウに削減することである。統計値fについて作成される、かかるウィンドウには、頂点fの、定められた数の最隣値が含まれる。
4.7.4 一次結合
一次結合は、統計値間で探索される関係において、最も一般的であり、最も興味深いものである。ウィンドウを有し、線形従属した統計値は、線形代数の方法を用いて計算される。本理論の言語では、ウィンドウはマトリクス数19として表すことができ、mはウィンドウの長さ(サンプル数)、nはウィンドウの幅(統計値の数)である。なお、ここでウィンドウは転置される。m=nであると想定され、そうでない場合は、少なくとも|m−n|従属ベクトルがあり、さらには結果の解釈の問題が起こる。前記の要件は、ウィンドウ全体で線形結合のマイニングを動作させない最も重要な理由である。この期待を満たすには大量のサンプルが必要となるため、不可能だと思われるからだ。
Wからのどのベクトルが線形従属しているかを判断する古典的な方法はガウス消去法である。前述の問題は、下記数20の形式で表すことができため、一次方程式を解くためにいかなるアルゴリズムも適用することができる。自明でないxは、いくつかのベクトルが線形従属であることを意味する。ただし、xから係数を得ることは難しく、カラムを削減した階段形が必要である。
マニュアルでコード化されたガウス消去法は効率的でなく(キャッシュ利用の観点などから)、数値誤差によってバイアスされていることがある。そのため、ここでは線形代数ライブラリの使用が好ましい。実際、純粋なガウス消去法の代わりに、ソフトウェアがLU分解の例を用いて計算することができる。
ガウス消去法を選択するか他の一般的な分解方法を選択するかにかかわらず、与えられたウィンドウでの統計値間の一次結合を探索する複雑性は(O(n3))である。
4.7.5. 回帰
一次結合は、StatsMinerが探索する最も強力な関係性である。しかし、StatsCompressorは弱い相関を使用するだけの柔軟性がある。この特性は、統計値の収集が非同期であるという問題を緩和するために導入され、また、これによってStatsCompressorは、マイニングのフェーズにおいても十分に適用されない規則を使用できる。このような規則は、参考文献[SE02]で概説されている多次元回帰分析を用いて発見することができる。実際、この分野では多くの研究が行われており、回帰規則のマイニングのための最適な方法を選択するには、さらなる調査が必要となる。現時点でわかっていることは、この種のアルゴリズムは、複雑性が高いため((O(n3)またはそれ以上)、数を削減したウィンドウ上で動作させる必要がある、ということである。
4.7.6. まとめ
時間がなかったため、このセクションで述べたアイデアはいずれも実装していない。十分にテストされていない新たなアルゴリズムを導入するよりも、既存のアルゴリズムを丹念に作り上げる方がより重要だと思われるからだ。特にクラスタリングに伴う作業をまず行うべきである。その一方で、統計間の一次結合(厳密なものと、回帰ベースの弱いものとの双方)を発見する能力は、StatsCompressorが達成する圧縮率を大きく改善する可能性がある。これは、変則性の発見にとっても重要なものとなり得る。
4.8. イントラアルゴリズム(内的アルゴリズム)
イントラアルゴリズムは、1つの統計値の再現可能な特性を探索する。異なる統計値間でサンプルを比較する必要がないので、このようなアルゴリズムは統計値のすべてのサンプル上で実行することができるため、サンプルを複数のウィンドウに分割する必要がないと思われる。イントラアルゴリズムはこのような特徴があるため、インターアルゴリズムのための探索スペースを削減するヒューリスティックのための知識の源となる可能性が十分にある。
4.8.1. 定数の発見
定数関数は、イントラ(内的)相関(および他のあらゆる相関)の最もシンプルな例である。驚くことに、HYDRAstorの統計値の多くは長期間にわたり一定である。平均すると、LRT(約83サンプルを含む)からのZstatファイルは、約48940個の統計値を含み、その内の11860個は値が全く変化しなかった(約25%)。
定数を発見するのはシンプルな手順である。与えられた統計値のすべてのサンプルが同じ数値を持つかどうかを確認すればよい。この探索は、各ウィンドウで個別に、統計値に対して行われる。これは、サンプルが複数のウィンドウに分割されていない場合にのみイントラアルゴリズムの検索が合理的だとする前提の、例外である。実際、定数はStatsMinerで発見されるが、その規則は、StatsCompressorによって規則ファイルからロードされるわけではない。StatsCompressorは自身で定数を発見する(5.8.1項参照)。
定数統計値(例えば和)間の相関を発見するのは、値が変化する統計値の場合と比べると非常にシンプルな作業だが、そのような内的相関は、圧縮という観点からはあまり有用ではない。さらに、定数統計値間の相関を説明する規則の数は膨大になる。そのため、StatsMinerでは、ウィンドウの生成直後に定数統計値を発見し、そのウィンドウ上では、それ以上その統計値をマイニングに用いることはない。
ウィンドウの例(図19)では、 stat_etaという定数が発見される。
このアルゴリズムは、8秒間動作して、Customer Logs用に(計)154023個の規則を作成した(分析されたウィンドウ1つ当たり平均33152個)。LRTにおけるマイニングの結果、38秒間で(計)117310個、分析されたウィンドウ1つ当たり36633 個の規則が発見された。この結果については4.9項で述べる。発見された規則の有意性についても4.9項で述べる。
4.8.2. 共通する部分列の発見
統計値の中には、サンプルの同一の部分列が定期的に出現するものがあり、これらは良い圧縮対象である。一方で、このような分析は、gzip、bzip2、 xz等のあらゆる汎用コンプレッサですでに行われているため、圧縮という観点からは、StatsMinerでこのような関係性を掘り起こしても意味がない。しかし、もし規則が圧縮以外の手段に利用できるのであれば、共通する部分列を探す価値があると思われる。これは、前述のコンプレッサと同様に辞書を使って行うことができる(LZ77、LZMAアルゴリズム)。
4.8.3. まとめ
イントラアルゴリズムは、本論文ではあまり論じていない。しかし、値間の相関を探すアルゴリズムが迅速かつ効率的に動作するために、定数を発見することは極めて重要である。
4.9. まとめ
図21は、StatsMinerのパフォーマンス結果をまとめたものである。
なお、CL集合の分析では、約249のウィンドウが生成されるはずだったが、発見された規則が利用可能なすべてのメモリを使用する可能性があった。そのため、(予定していた50個ではなく)30個のデータベースしか使わなかった。33番目のデータベースの分析で、マシンのメモリ(48GB)を交換してStatsMinerがだめになった。
CL集合について作成された規則の数は、LRT_A集合よりも2倍多かったが、分析されたウィンドウの数は5分の1だった。この理由は複合的なものである。まず、LRT_A集合はテスト中に作成された統計値に基づいて構築され、これは正常なHYDRAstorの動作をシミュレートしたものである。しかし、CL集合は顧客からの実際のデータで構成されており、顧客のシステムは異なる動作をする場合もある。さらに、顧客ごとに独自のHYDRAstor使用パターンがあるため、2つの同様なインストールであっても、それぞれ固有の相関を持つ大きなグループとなる可能性がある。また、CL集合は、様々なパッチを適用した異なるバージョンの HYDRAstorによって収集された統計値を含む。この観点から、LRT_A集合に関する結果は、特定のバージョンのHYDRAstorからの統計値を分析した場合にStatsMinerがどのように行動するかを示し、CL集合での実験は、異なるバージョンのシステム上での相関の発見を行うものである。
興味深いことに、CL集合におけるウィンドウ1つ当たりに作成された同一性規則の数は、LRT_Aと比べて2倍の大きさである。さらに、分析されたウィンドウの数が両集合で同一の場合、CL集合での同一性の発見は約100秒かかるため、 LRT_A集合と比べて2倍の時間がかかる。CL集合で、これほど多くの同一性が発見された理由はよくわからない。HYDRAstorで実際に利用されているのは、Long Running Testによってシミュレートされた動作の小さな部分集合だけなのだろうか? 幸いなことに、同一性が多いことは間違いなく正しい。なぜなら、同一性の圧縮が最も効果的だからである(5.9.3項参照)。
和の規則の数量は、他の相関を合わせた数量よりもはるかに大きい。しかしこれは、保存の規則の組み合わせを用いた結果としての錯覚である。ウィンドウ内に同一性が多く発見されるほど、多くの和の規則が作成される。このことはCL集合から明らかである。
発見された規則の分析を完全なものにするために、図22について説明する。このプロットは異なるタイプの規則の最小限の有意性を示しており、X軸が最小限の有意性を表し(定義については4.3章を参照)、Y軸は所定の最小限の有意性を持つ規則の割合を表している。このプロットは次のように理解される:最小限の有意性が0.3で規則40%の点があるとすると、これは発見された規則の40%が数21を持つことを意味する。このような情報は、有意性が最も高い規則のみを顧客のサイトに移すといった場合に、非常に役に立つ(1参照)。
全般的に、図22を見ると、有意性がなだらかに減少しており、確かにHYDRAstorシステムの統計値間に相関が多くその頻度が低いわけではないことから、この論文で研究したアプローチが合理的であることがわかる。定数の規則の有意性が最もなだらかに減少しており、また多くの統計値において、値の変化の発生頻度が低いこと(例えば、まれに起こる削除のとき)は驚くことではない。LRT_A集合からの規則についての結果がCL集合よりも良くない(定数および他の種類の場合でも)ことは、LRTが、HYDRAstorの使用法の別のシナリオを確認した集約的なテストであったという事実と結びつく。このプロットからわかる最も楽観的な結果は、CL集合からの同一性および和の規則の有意性が非常に類似しており、さらに、これらが高い値を持つ。これは非常に幸運なことである。なぜなら、顧客から受け取ったファイルにおいて発見された規則は、(おそらく)高品質なものであると思われるからだ。なお、CL集合は異なるバージョンのHYDRAstorで生成されたファイルを含んでおり、このような良い結果が得やすいものではなかった。残念ながら、LRT_A集合で発見された同一性および和の規則の有意性は、CL集合で発見された同一性と同じ性質ではないため、圧縮という観点からは、あまり役に立つものではないと思われる。
最後に、StatsMinerのパフォーマンスという点では、マイニングよりも検証の方が常に速い。このフェーズの導入はそのような前提に基づいていたため、これは歓迎すべき展開である。マイニング時間対検証時間の比率は、CL集合よりもLRT_A集合の方が高い。なぜなら、検証は規則の全データベースを用いて開始されるが、マイニングはそうではないからだ。一方、ウィンドウごとの、マイニング時間および検証時間はCL集合の方が短いが、最終的に保存された規則の数は、CL集合の方がLRT_A集合よりもはるかに多い。このことは、CL集合のデータベースには、LRT_A集合からのファイルよりも、より多くの(名前が)固有の統計値が含まれている(HYDRAstorは様々なバージョンがある、等の理由で)といった事実から説明できる。この結論は、検証フェーズでの、各ファイルの適用可能な相関の平均数によって証明されるであろう。適用可能とは、その相関によって予想されるすべての統計値がファイルに存在する、という意味である。LRT_A集合の値は8599140だったが、CL集合はわずか6774390だった(21%少ない)。
StatsMiner(全体)のパフォーマンスは、現在のところ期待を下回っている(CPUおよびメモリ使用量の両方で)。しかし、このソフトウェアはプロファイルされておらず、十分な調整すらされていない。最大のボトルネックは、規則を保存する方法である。組み合わせのアプローチを用いるということは、膨大な数の規則をメモリに記憶することを意味する。残念ながら、内部のデータ構造の効率が十分でないことがわかった。StatsMinerはセミプロトタイプのソフトウェアとして作成されたものであるため、問題があることに驚きはない。
まとめると、StatsMinerは期待に沿うものであった。実際には、設計されたマイニングアルゴリズムの小さな部分集合しか実装されていないが、その規則の数と有意性により、このツールのコンセプトが正しいことがわかる。興味深いのは、メモリがStatsMinerのボトルネックだということだ。現在は、これらの制約にぶつからないようにするために、1つのバージョンのHYDRAstorによって収集された統計値について、分析を行う必要がある。さらに、各顧客の統計値間の相関に関するマイニングを別々に行うことで、最も良い結果が出るかもしれないが、当然、多くの資源が必要となるため、現実的ではない。規則の保存方法をより良いものにすれば、メモリ消費量を減らすこともできるだろう。この問題は、新たなタイプの相関を発見できるようにしたり、ランダムウィンドウのコンセプトを導入するといった、このツールの機能性の拡張を行う前に、解決するべきである。
第5章 コンプレッサ
本章ではStatsCompressorの説明と評価について述べる。StatsCompressorはHYDRAstorシステムで作成された統計値を含むファイルを、相関に基づくアプローチとドメイン知識を用いて圧縮するためのツールである。
本章は次のセクションで構成される。
5.1 「概要」ではStatsCompressorの全体概念と前提を述べる。
5.2 「テストベッド」では、本章で用いるテストデータとテスト方法について述べる。多くの実験結果を示しており、これは重要である。
5.3 「StatsCompressorの基本結果」では、テストデータに対してStatsCompressorを用いて達成可能な最も良い結果を提示する。他の実験結果と比較する、基本となる結果である。
5.4 「外部コンプレッサ」では、StatsCompressorによって生成されたファイルをさらに圧縮処理するために使用できると思われるツールについて説明する。このツール自体は相関に基づく圧縮しか行わないからだ。
5.5−5.9 これらのセクションではStatsCompressorが使用する圧縮方法の説明と評価を述べる。
5.10 「相関に基づく圧縮の使用の他のモデル」では、StatsMinerとStatsCompressorの協働方法について概説する。その目的は、別のバージョンのHYDRAstorで取集された統計値を圧縮するために一連の規則を使えるようにすることである。第3章で触れたモデルにおける使用と、新たなアプローチとの双方の方針について述べる。
5.1 概要
StatsCompressorという、設計され実装されたコンプレッサは、Zstatファイルの無損失圧縮のためのツールであり(2.3.2項を参照)、本論文で述べる研究の一部として作成されたものである。通常のZstatファイルを入力として受け取り、出力としてZplusファイルを作成する。ZplusファイルはZstatファイルと非常に似ており、両者は比較可能なものである。このツールが行う圧縮は、バイトレベルの方法を使用しない高度なものであり、ドメイン知識(主に統計値間の相関)と、圧縮ファイルのシンプルなテキスト変換に基づく。作成されたZplusファイルは、外部の汎用コンプレッサを用いて更に圧縮する必要がある。
このツールはC++で記述され、Linuxのオペレーティングシステムで動作する。C++を使用する理由は、このコンプレッサは正常に動作している顧客のマシン(Linuxのオペレーティングシステムで動いている)上で動作することからC++で高いパフォーマンスが期待できるからである。特に、バックアップデータをシステムに書き込む間に動作するため、CPUとメモリの消費量を最小限にする必要がある、一方、研究の過程で効果の高いソフトウェアを作成するのは難しいため、当初のコードはプロトタイプとして扱った。製品化の段階で書き直す(実質的には一から書き直す)必要がある。C++でプロトタイプを作成するという手法は、リソースの最大利用という点で、最大限達成可能な圧縮率の測定を可能にした。ここで示す実験結果はすべて、この前提の観点から評価する必要がある。
5.2. テストベッド
5.2.1. テストデータ
StatsCompressorのパフォーマンステストはすべて、以下のデータ集合に対して実行された(StatsMinerの場合と同様)。
1.LRT_A−H4バージョン上でのLong Running Testからランダムに選択した50個のZstatファイル。
2.LRT_B−H4バージョン上でのLong Running Testからランダムに選択した50個のZstatファイルで、数22。
LRTはLong Running Testの略で、このテストには約2週間かかり、HYDRAstorの正常な使用と窮状での使用との双方をシミュレートした。このシステムはバージョンH4で、1つのHNと4つのSNで構成される。このデータのソースはすでに選択されている。なぜなら、H4バージョンを使用している顧客からのデータはまだなく、これらのZstatファイルはHYDRAstorのモデルバージョンのスナップショットして扱うことができるからだ。以前のバージョンのHYDRAstorを使用した、顧客から取得したランダムに選択された統計値のファイルに関する結果は、第6章で説明する。
5.2.2. パフォーマンスの測定
StatsCompressorのテストは、StatsMinerと同じマシン、同じ方法で行われた(4.2.2項を参照)。
5.3. StatsCompressorの基本結果
図23は、最大限達成可能なStatsCompressorの平均圧縮率(以下に定義)と、StatsCompressorのパフォーマンス結果を示す。この結果は、LRT_A集合全体用に事前に生成された規則を用いて、LRT_A集合からの各Zstatファイルを圧縮して得たものである。StatsCompressorは利用可能なすべてのアルゴリズムで動作したため、ここに示す結果は最も達成可能なものである。
この論文で、「StatsCompressorの圧縮率(ScCR)」とそれをサポートする「スペース節約」は、次の方法で計算される。
スペース節約(Compressor, Zstat) = 1-ScCR(Compressor, Zstat)
ここで、
Compressor(Zplus)のサイズ = StatsCompressorで圧縮され、その後Compressorで圧縮されるZstatファイルのサイズ
Compressor(Zstat)のサイズ = Compressorのみで圧縮されるZstatファイルのサイズ(通常のHYDRAstorの方法)
StatsCompressorの圧縮率は、StatsCompressorの圧縮品質に関する情報を提供する。これは単に理論上存在するものではない。なぜなら、この提案するツールを用いる場合に、最終的にStatsCompressorを使用しなかった場合と同じサイズの圧縮ファイルを得るには、どれほどの大きさのZstatファイルが使用可能か、を判断するため利用することができるからだ。これは、実際には、StatsCompressorが製品化された場合に、顧客からダウンロードする統計値の収集時間をどれ位長くできるか、ということを意味する。
コンプレッサの「noComp」は、外部のコンプレッサの使用がないことの略である。これは、StatsCompressorのみのパフォーマンスがいかに優れているかを示す。「本体のみ」のセクションは、サンプルのみのラインを含むZstatファイルの圧縮結果を示している。2.3.2項で説明したとおり、各Zstatファイルのラインの半分は既存の統計値の名前とメタデータを含む。メタデータの効率的な表示の問題はすでの解決されているため(2.3.2項を参照)、StatsCompressorは、サンプルの圧縮のみに焦点を当てている。「本体のみ」のセクションは、StatsCompressorの実際のパーフォーマンスに関する情報を提供する(ただし、StatsCompressorはメタデータを明示的に圧縮することはないが、少し異なる順序でメタデータをダンプし、統計値の識別子に多少の変更が伴うことがある(5.7.1項を参照))。
StatsCompressorの圧縮率は、−9パラメータでbzip2コンプレッサで動作させたときに最も良い圧縮率に達し、平均すると、Zstatファイル全体では47.78%(スペース節約は52.22%)、本体のみでは42.72%(スペース節約は57.28%)である。最も良い結果は、ファイル全体では43.8%(スペース節約は56.2%)、本体のみでは33.4%(スペース節約は66.6%)である。プロジェクト開始時はスペース節約20%〜30%を予想していたことから、これらの結果はすべての期待を超えるものであった。
しかし、StatsCompressorの圧縮率が最も良かったのは外部コンプレッサとしてbzip2を使用した場合であり、最も小さいファイルは、StatsMinerとxzコンプレッサの組み合わせにより出力された。
一方、現在のCPUとメモリの使用量は、StatsCompressorを顧客のサイトで実際に動作させるには大きすぎる。パフォーマンスを向上させる方法については、本章で後述する。
外部コンプレッサを使用しなかった場合の圧縮率(「noComp」の行)は大変興味深い。ファイル全体の場合、平均圧縮率は64.44%(スペース節約は35.56%)である。この結果は、特に、StatsCompressorがビットレベルで圧縮を提供せず、ZstatファイルとZplusファイルのフォーマットは冗長なテキスト表示を使用していたことから考えると、かなり良い結果に見える。この効果は、本体のみの場合の圧縮ではさらに強く、平均圧縮率は30.61%(スペース節約は69.39%)である。
ファイル全体の結果について、平均圧縮率に関する以下の現象が起こった。
bzip2 < gzip < noComp < xz
これは、StatsCompressorがZstatファイルのある部分を、gzipまたはbzip2がアクセスできない方法で圧縮することを暗示している、と解釈することができる。なぜなら、Zplusファイルをgzipまたはbzip2で圧縮した後はスペース節約が大きくなるからである。一方、xzの場合、zxはStatsCompressorが行った変換を、独自に処理できると考えられる。xzとbzip2との違いは統計的には重要でないが、図24に示すように、Zplusファイル上でxzを使用すると、最小に圧縮されたZplusファイルができる。本体のみの圧縮の場合に同じ関係性を分析すると、不等式は次のようになる。
noComp < bzip2 < gzip << xz
これは、実はStatsCompressorが、メタデータの圧縮以外の、他のあらゆる外部コンプレッサが行っているステップを繰り返しており、bzip2とgzipの能力を著しく悪化させていることを意味する。
StatsCompressorの圧縮率の標準偏差は、ファイル全体の圧縮および本体のみの圧縮のいずれの場合でも、非常に小さい。これは非常に良いことである。なぜなら、開発したソフトウェアの動作が予測可能だからだ。ファイル全体の場合は特に重要で、このソリューションを顧客のサイトで利用する場合に、所望するサイズのZplusファイルを得るために入力するZstatファイルのサイズを正確に選択することが可能となる。
ここで述べる結果は、以降のセクションでも参照され(モデル、ベース、または「完全なLRT_A/LRT_A」として)、StatsCompressorに組み込まれたアルゴリズムのいくつかを利用不能にして収集した結果と比較する。これにより、特定のアルゴリズムの重要性がわかる(StatsCompressorの圧縮率という意味で)。
5.4. 外部コンプレッサ
StatsCompressorは、相関の利用のみに基づくツールの開発に焦点を当てるために、外部のコンプレッサのサポートを受けるものと決定された。アルゴリズム論と情報理論との融合であるデータ圧縮は何年にも渡り研究されており、現在は膨大な数のデータ圧縮方法が提供されている。最も実践的なものは、一般的なツールに既に実装されており、Linuxではgzipとbzip2だが、参考文献[Vei13] [Jr13]にあるように、他にも多様なツールがある。7zaツールの改良バージョンであるxzコンプレッサは、Linuxのコミュニティで人気が出てきていることから、これをテストすることに決定した。xzがHYDRAstorの環境でどのように動作するかをチェックした。gzipとbzip2は、すでに利用に成功している。
5.4.1. 比較
図24に、絶対圧縮率(下記数24を示す。「StatsCompressorのみ」の行の値から、外部コンプレッサの使用が必須であることがわかる。図25は、LRT_A集合からの生のZstatファイルを圧縮する、検討された外部コンプレッサの圧縮率とパフォーマンスを示している。これらは、StatsCompressorを使用しない場合の、正常な結果である。
図25は、外部コンプレッサのパフォーマンスを示している。まず、xzツールが最も良い圧縮率を示しており、その優位性は圧倒的である。しかし、これは極めて高いメモリ消費量を使用して達成されたものであり、HYDRAstorで使用するには、この点が障害になる恐れがある。なぜならメモリは貴重な資源だからだ。一方、gzipは最もパフォーマンスの悪いツールである(ただし使用コストは安い)。この実験ではgzipとbzip2によって達成された圧縮率に大きな違いはない。ただしZplusファイルの圧縮では違いが大きい(図24と比較)。この観点から、外部コンプレッサの最善の選択はbzip2と考えられる。xzはコストが高すぎるし、gzipの圧縮率は満足できるものではないからだ。なお、興味深い事実として、平均すると、フラグ-9はbzip2に対して所有する最も良い圧縮方法を使用するよう命令しているが、bzip2 -9はbzip2 -6よりも悪い結果となっている。
5.5. StatsCompressorのスキーマ
図26はStatsCompressorを示す図である。このソフトウェアの各部は、以降のセクションで包括的に説明する。この図は、単一のZstatファイルに対して実行される動作のシーケンスを示している。構成要素の使用はプログラム引数または規則ファイルの制限によって制御することができる(例えば同一性の相関のみ使用)。
この図には「コスト」の概念が含まれる。本章でコストとは、まだ外部コンプレッサで圧縮されていないZplusファイルにおいて、特定の方法を用いて特定の情報を保存するのに必要なバイト数である。例えば、あるサンプルの値が「12345」で、圧縮方法が選択されていない場合、このサンプルのコストは5である(このサンプルは「12345」という人間が読める形式でダンプされるから)。コストを計算するこの方法には、基本的な欠点が1つある。Zplusファイルは外部の汎用コンプレッサで圧縮されることを考慮していないことだ。残念ながら、StatsCompressorでは、情報のダンプにかかる最終的な(外部圧縮後の)コストを決定することはできない。なぜなら、特定のデータに対する外部コンプレッサの圧縮率は、常にそのコンテキストデータによって決まるからだ。つまり、外部コンプレッサは、より大きなデータ表現(例えば「1_2_3_4_5」)を、より小さな表現(「12345」)に対するものよりも小さなビット数に圧縮することはめったにない、という前提のもとで、StatsCompressorは構築されている。
圧縮のプロセスは以下の3段階から成る。
1.統計値の圧縮に様々な方法を試みる(5.8章および5.9章を参照)。
2.統計値の圧縮に最適な方法を選択する(5.6章を参照)。
3.符号化を最適化する(5.7章を参照)。
5.6. 相関に基づく圧縮
StatsCompressorの最も重要な部分は、圧縮い使用する規則を選択するためのアルゴリズムである。規則には2つのタイプがあり、それは、発見されたルールを含むファイルからロードされるもの(5.9章を参照)と、StatsCompressor自身で発見したもの(5.8章を参照)である。実装されるアルゴリズムは最もシンプルなもので、次の2つのステップから成る:規則をスコア化し、スコア化した規則のどれを圧縮に使用するかを選択すること、である。
5.6.1. 規則のスコア化
規則をスコア化する最初のステップは、各統計に適用する最適な「トランスフォーマット(transformat)を選択することである。トランスフォーマットとは、StatsCompressor自身が発見した内的相関のことである(5.8.2項を参照)。わかりやすく説明すると、圧縮方法を使用せず、統計値のサンプルを明示的に書き込むことを、「0−トランスフォーマット」という。Zplusファイルでは、1つの統計値に1つのフォランスフォーマットのみを適用することができる(コストが最小限)。
次のステップでは、値間相関のコストを計算し、スコア化する。この「スコア」とは、所有するすべての規則間の線形順序の導入に使用される数値である。所定の統計値の圧縮に値間相関を使用することが合理的となるのは、相関のコストが最適なトランスフォーマットのコストよりも小さい場合のみである。この条件が満たされれば、規則がスコア化される。これには2つのアプローチがあり、それについて、これから説明する。説明を明確にするために、以下のように仮定する。2つの規則「r1」と「r2」があり、各々が異なる統計値を圧縮し、かつ
10 = cost(r1), cost(t1) = 15, cost(r1) < cost(t1)
12 = cost(r2), cost(t2) = 30, cost(r2) < cost(t2)
ここで、t1とt2は、対応するr1およびr2と同じ統計値に適用されるトランスフォーマットである。
規則をスコア化する絶対コスト法
規則のスコアは次のとおり:
score(ri) = cost(ri)
上記の例では、score(r1)=10、およびscore(r2)=12。これらのスコアは次のオーダーを導入する:
規則をスコア化する相対コスト法
規則のスコアは次のとおり:
ここで、tiはriが圧縮の対象とする統計と同じ統計のトランスフォーマットである。上記の例の場合、
score(r1) = 0.625 and score(r2) = 0.4
となる。これらのスコアは次のオーダーを導入する:
実験から、相対コスト法の方がわずかに良く、平均的なStatsCompressorの圧縮率は、外部コンプレッサの使用に応じて、0.3%から0.6%ポイント高いことがわかった。
規則のスコア化には、平均593秒かかった(LRT_A/LRT_Aモデルの実験で)。このプロセスが長かったのは、スコア化すべき規則の数が多いことが原因である。Zstat1つ当たり平均で27095900個の規則をチェックした(図33を参照)。なお、相関f = g + hは以下の3つのフォームで出現した(3つの異なる「規則」として):f=g+h、g=h−f、およびh=g−f。チェックした規則のうち、4523420個(Zstat1つ当たりの平均)は、対応するトランスフォーマットよりもコストが低かった(したがって多くの規則が完全にスコア化された)。つまり、適用される規則のわずか17%だけが(なぜならすべての予想された統計値がZstatファイルに出現する)、圧縮に利用することができる。さらに、図33には別の結果が示されており、これについては5.9.2項で述べる。StatsCompressorの資源の利用を最小限にする方法については、5.9.4項と5.10項でさらに掘り下げる。
5.6.2. 使用するスコア化された規則の選択
当初は、このステップは非常にシンプルなものだと思われた。スコア化された規則があれば、各統計について、最もスコアの低い規則を選べばいいからだ。特定の統計値に規則が適用されない場合は、トランスフォーマット(少なくとも「0−トランスフォーマット」)を使用すればよいと思われた。しかし、このアプローチには罠がある。f=g、g=h、h=fが選択されたらどうなるか?この場合、すべての統計値のサンプルの値がなくなり(f=g等のため、fのサンプルは保存されない)相関に関する情報だけが残る。
StatsCompressorは、上記のアプローチの、より繊細なバージョンを使用する。スコアが最小の規則から始めて、すべての規則を調べる(スコアの線形順序が存在するため、可能である)。使用する規則は、以下の基準を満たす必要がある。
1.有向規則の左辺(統計値、この特定の規則を用いて圧縮することができる)が、他の規則によって圧縮されていない(より小さなスコアを有する)。
2.規則の使用により、適用される規則の有向グラフに循環を導入しない。グラフの頂点は統計値であり、エッジが統計値間の依存関係を表す。例えば、規則f=gを使用する場合、グラフにはエッジ数28がある。したがって、和の規則p=q+rが、エッジ数29と数30を導入する。グラフはメモリに保存され、縦型探索アルゴリズムを使って循環の存在が検出される。
このアルゴリズムはグリーディである。実験により、許容レベルの圧縮を提供することはわかっているが、これがうまく機能しない例を構築するのは非常に簡単である。将来的には、この目的のためのより良いアルゴリズムを発見するために、もう少し研究する必要がある(または既存のものにヒューリスティックを追加する)。この問題はNP完全ではないかと思われる。ただし、それを証明するものは構築されていない。グラフ理論言語でこの問題を表すのは難しいからだ。1つの試みとして、加重マルチグラフGがある。Gから、いくつかのエッジを除去すると(所定の可能性リストに従って行う)、Gtは非循環式で複数のエッジがなく、連結されてエッジのウエイトの和が最小になる。なお、個別に除去できないエッジもある(なぜなら全体として和の相関を使用すべきであり、これは少なくとも2つのエッジが存在することを意味する)。グラフGは1つの理論上存在する頂点を持つため、そこから他のすべての頂点へのエッジは、対象となる頂点(当然、統計値を表す)のトランスフォーマットのコストに等しいウエイトを有する。
実装されたグリーディアルゴリズムの実行には、Zstatファイル1つにつき平均18秒かかった。つまり、このステップは規則の評価よりもはるかに速い。
5.7. 選択した相関の後処理
5.7.1 リナンバリング
リナンバリングは、圧縮率を改善するために、Zstatファイル内の統計値によって使用される識別子を交換するプロセスである。図26によると、これは圧縮の最終段階である。ただし、これは抽象クラスの平坦化(flattering)の問題に触れる前に説明しておく。なぜなら、平坦化はリナンバリングを改良するために導入されたものだからだ。
Zstatファイル(Zplusも同様)内の各統計値は、自然数である独自の識別子を持つ。Zstatファイルにおいて、各識別子は確実に2回使用される(統計値の名前をそのサンプルにマッピングするため)。Zplusファイルでは、相関を保存する際に識別子が利用される。そのため、頻繁に出現するものもある。リナンバリングの目的は頻繁に出現する統計値に、より短い識別子をつけることである(つまりコスト削減となる)。LRT_Aの場合、最も頻繁な統計値の識別子は25 678回ダンプされた(平均で)。リナンバリングの時間は測定しなかったが、パフォーマンスに与える影響は無視できる程度である。なぜなら、このステップの複雑性はO(n log(n))だからだ(nは統計値の数)。
図27は、リナンバリングを不能にしてLRT_Aに対して探索された規則を用いてLRT_A集合を圧縮した結果を示している。これによると、リナンバリングは非常に重要なステップである。なぜなら、これがないとStatsCompressorの圧縮率が大きく下がるからだ(少なくとも11パーセントポイント)。相変わらず、xzはこの問題に苦しめられることがない。本体のみの圧縮の場合、統計値の名前を有する行がないという事実により、この問題は見えなくなる。驚くことに、リナンバリングを不能にすると、平均のCPU使用率がわずかに大きくなるのだが、これを説明するのは困難だ。
実際には、このステップは解凍で回復することができない2つの内の1つである。なぜなら、Zplusファイルには、古い識別子を新しいものにマッピングする辞書が含まれないからだ(必要がなかった)。一方、ZstatにZplusと互換性を持たせるために、すでにZstatファイルで使用された古い識別子から、新たな識別子が選択される。すべてのZstatファイルにおいて、最小の識別子はせいぜい568であることは興味深い。StatsCompressorの製品化バージョンでは、新たな識別子は1から始めるべきである。
5.7.2. 抽象クラスの平坦化
抽象クラスの平坦化の目的を説明するには、新たな概念を取り入れる必要がある。f、gが異なる統計値を表すとする。id(f)=xは、統計値fがZplusファイル内で識別子xを得ることを意味する。
第2の規則(5.6.2項参照)を選択するためのアルゴリズムが機能する方法は、例えば抽象クラスA=f0,f1,f2,f3の圧縮には、以下の規則が選択されることを意味する:f1=f0、f2=f1、f3=f2。しかし、これは最適ではない。なぜなら、x、y、zおよびx=id(f0)、y=id(f1)、z=id(f2)=id(f3)という、少なくとも3つの異なる識別子を使用する必要があるからだ。最適なアプローチは、抽象クラス全体を以下のようにコード化することである:f1=f0,f2=f0,f3=f0。なぜなら、t=id(f0)という1つの識別子だけが後で使用されるからだ。t=id(f0)=id(f1)=id(f2)=id(f3)となる。なお、その場合は、統計値f1、f2、f3の当初の識別子を得ることはできない。しかし、それは必要ではない。
抽象クラスの表現を最適化するプロセスを「平坦化」という。なぜなら、その目的は、抽象クラスの符号化に使用する規則のツリーの高さを低くすることだからである。最適なツリーの高さは1なので、各抽象クラスは1つの代表値を持つ。これを処理するために、Find-Unionアルゴリズムを使用する。最初に、各統計値がシングルトンの集合を形成する。統計値間に厳密な同一性がある場合は、適切な集合同士(この統計値の代表的な抽象クラス)が結合される。最後に、各集合は1つだけ代表値を有し、これが使用される(前段落に記載の例ではf0)。これ実際にはBoost Disjoint Sets ライブラリが使用された。この複雑性はO(数31)であり、数32は逆アッカーマン関数、nは統計値の数、m=O(1)で、分析される規則の集合に依存する。完全なLRT_A/LRT_Aを用いた実験では、このステップには平均0.7秒かかった。
図28に、抽象クラスの平坦化を不能にして、LRT_Aについて発見された規則を用いてLRT_A集合を圧縮した結果を示す。スペース節約は非常に小さく、平均2〜3パーセントポイントである。xzコンプレッサにとって、平坦化を可能にすることが非常に重要であることは興味深い。抽象クラスの平坦化には、Find-Unionアルゴリズム用のデータ構成を構築する必要があるため、RAMを約14MB使用する。
5.8. 内部知識に基づくアルゴリズム
StatsCompressorは、自身である種の相関を探索する。高速でマイニングを行うため、パフォーマンスに悪影響を与えることはない(このソフトウェアにとっては極めて重要である)。
5.8.1. 定数の圧縮
すべてのZstatファイルに含まれる統計値の約24%は定数である。この種の(内的)相関は、規則ファイルには入らないため、StatsCompressorは自身でこれらを探さなければならない。このプロセスは4.8.1項で述べたものと同様である。
すべての定数統計値が識別されると、抽象クラスにグループ化される(その値に基づく)。例えば、クラスf=g=hがある。各クラスは1つの代表値を持つが、それはサンプルが最も少ない統計値である(例えばf)。抽象クライスの各メンバーについて、統計値と抽象クラスの代表値との間の関係を説明する、同一性規則(規則ファイルからロードされた同一性の場合と同じ)が作成さる(この例ではf=gとf=h)。なお、代表値でない統計値間には規則は存在しない(規則g=hはない)。このアプローチは、このステップで作成される規則の数を最小限にするために用いられた(抽象クラスは非常に大きいため、実際の規則を記憶する方法の組み合わせを用いると数千もの規則が生成されることになるが、そのわずかな割合しか使用されない)。
定数の発見にかかった時間は平均してわずか0.61秒だったが、StatsCompressorの圧縮率に重大な影響を与えた。図29は、定数の圧縮のみを実行したStatsCompressorでの実験結果を示す(他の圧縮方法は使用しなかったが、後処理はアクティブだった)。スペース節約は、外部コンプレッサの使用に応じて変動があり、ファイル全体の圧縮の場合は9.61%から12.69%まで様々であり、本体のみの圧縮の場合は6.48%から8.67%まで様々であった。スペース節約については、後処理として統計値のリナンバリングを用いるためファイル全体の方が大きかった。そのため、Zplusファイルの最初のセクションからの、名前から識別子へのマッピングにはエントロピーが少ししか含まれておらず、異なる識別子の数が少なかった。
5.8.2. トランスフォーマット
すでに述べたとおり、内的相関を用いて統計値のサンプルを圧縮する方法を「トランスフォーマット」という。このような相関は、現在StatsCompressor自身によって発見される。各統計は、1つのトランスフォーマットを用いて圧縮することができる。これは、他の圧縮方法が使えない場合に行われる(詳細については5.6.1項を参照)。StatsCompressorは、各統計値について常にすべてのトランスフォーマットを計算し、最適なトランスフォーマットを決定する。これらの計算は非常に速い。
トランスフォーマットの説明には以下の概念を用いる:
s:統計のサンプルのシーケンス
si:シーケンスsのi番目のサンプル
Ti(s):トランスフォーマットtをシーケンスsのi番目のサンプルに適用した結果
0−トランスフォーマット
0−トランスフォーマットは、明確性のみの目的で導入され、次のステートメントが常に正になる:「ある統計値のサンプルをZplusファイルに(明示的に)ダンプする必要がある場合は、トランスフォーマットを使用する」。0−トランスフォーマットはいかなる方法でもサンプルを変換することはなく、Zstatファイル内に存在するのと同じように、値がそのまま保存される。
Ti(s) = si
差異トランスフォーマット
差異トランスフォーマットは、統計値の値は徐々に変化するため、現在のサンプルと以前のものとの差を保存すれば、両サンプルの値を保存するよりもコストが安い、という前提に基づく。差異は小さい場合が多いため、コストも小さくなる。また、同じ値が差異として現れることが多いため、外部コンプレッサで効率的に圧縮される。差異の計算を可能にするために、統計値の最初のサンプルより前の値は0と仮定する。この手法は、StatsCompressorにおける有限差分に対するあらゆる計算を利用し、例えば、統計値gのサンプルがあらかじめわかっている場合は、規則df=gを用いて圧縮された統計値fの解凍が可能となる。
T0(s) = s0 - 0 = s0
Ti(s) = si - si-1 i>0
ドミナント・トランスフォーマット(Dominant transformat)
ドミナントトランスフォーマットは、統計値の中にはほとんど値が変わらないものがあり、これらの統計値については、ドミナント値(dominant value)と偏差ベクトルを保存すればよい、という考えによって開発された。後者は、わずかな偏差ベクトルの符号化を利用すれば効率的に行うことができる(付表Aを参照)。ドミナントトランスフォーマットの計算には、統計値のサンプルを2回読む必要がある。1回目のパスではドミナント(最も共通する値)を発見し、2回目に偏差を決定する。しかし、このパフォーマンスの結果からわかるように、シーケンスを2回スキャンしてもStatsCompressorのパフォーマンスに目に見える影響を与えることはない。
c − シーケンスのドミナント − sのサンプルのシーケンスで最も共通する値
Ti(s) = si−1 − c
トランスフォーマットの評価
図30は、トランスフォーマットを唯一の圧縮方法として用いてLRT_A集合を圧縮する際のStatsCompressorの圧縮率を示している。スペース節約は素晴らしく、ファイル全体では18.06%−30.89%(外部コンプレッサの使用に応じて変動する)、本体のみでは21.91%−36.28%である。この論文で提案するドミナントトランスフォーマットと差異トランスフォーマットは非常にシンプルな方法であり、いかなる外部コンプレッサも、これと同じメカニズムをこれほど効率的な方法で利用していない。当然、前述のツールは、バイトファイルよりもテキストファイルで機能するよう調整されているが、まだ改良すべき点がある。なぜなら、スペース節約の潜在能力は莫大であり、今では、プレーンテキストを含むファイルはより一層一般的になっているからだ(例えばJSONフォーマット)。
差異トランスフォーマットは、ドミナントのものよりも、より頻繁に使用される。これはすでに予測されていた。図31を参照。しかし、驚くべきことに、ドミナントトランスフォーマットは、理論上は差異トランスフォーマットと非常に類似する条件のもとで使用されると思われるのだが、ドミナントの方が最良である場合が多い。良く機能すればするほど、偏差の数が小さくなる。もう1つの興味深い事実として、0−トランスフォーマットは、ほとんど使用されることがなかった。つまり、膨大な変動がある統計値は、ほんのわずかであったということだ。
差異トランスフォーマットおよびドミナントトランスフォーマットのいずれも、同じ方法で構築される。サンプルの値と、実際の値と予測値との差異の予測に使用する機能がある。当然、予測には他にも多くの機能ファミリーがあり、機能ファミリーのどれを使用すべきかの決定をStatsMinerがチェックし、StatsCompressorは数値的方法を用いてこれらの機能の係数を計算する。実際のところ、機能を現実のサンプル値に合わせるという全般的なアイデアは新しいものではなく、例えばFree Lossless Audio Codec (FLAC)(参考文献[CF13])に記載されているように、すでに圧縮に使用されている。
5.9. 外部知識の使用
規則のファイルは、外部知識のソース、すなわちStatsMinerによって発見された相関である。このセクションでは、これらの規則の使用に関する分析、つまり、StatsCompressorのパフォーマンスにどのような影響があり、将来的にどのような問題を解決する必要があるのか、という点について述べる。
5.9.1. 偏差ベクトル
StatsCompressorの最も重要な特徴の1つは、数値的に合わないものでも相関を使用する能力があることである。そのため、サンプルの実際の値と、相関の使用による予測との間に偏差がある。これは、StatsMinerは厳密な相関のみを発見するが(特に実装されたバージョンでは)、StatsCompressorは弱い相関を用いることができることを意味する。そのような偏差の符号化方法については付表Aに記載する。図32は、偏差ベクトルが不能な場合、したがって厳密な相関のみが許容された場合の、StatsCompressorの圧縮率を示している。これはトランスフォーマットが切られていることを意味する(0−トランスフォーマットを除く)。なぜなら、偏差ベクトルがきちんと動作する必要があるからだ。ここからわかるとおり、StatsCompressorが良好な圧縮率を達成するためには、特に外部コンプレッサを用いる場合は、偏差ベクトルの使用が極めて重要である。一方、この結果から、(本論文で述べている)相関に基づく圧縮というアイデアが合理的であることも証明される。なぜなら、最良の外部コンプレッサ(xz -9)を使用しても、スペース節約はゼロではなく、ファイル全体では14.9%、本体のみでは12.68%となっているからだ。実は、2番目の結果が、さらに重要である。なぜなら、サンプルのシーケンスのみを含むZstatファイルの一部に該当するからだ。この点はStatsCompressorにとっては最も興味深い。
偏差ベクトルの使用は、CPU消費量にはそれほど影響しない。反対に、メモリ使用量は影響を受けるが、これは実装に依存するため削減することができる。現在のバージョンのStatsCompressorでは、規則のスコア化の際に計算される偏差ベクトルは、たとえ使用できるものであってもメモリに保存されている。
5.9.2. 外部知識規則の使用のパフォーマンス
StatsMinerは数百万もの数の規則を簡単に作成することができる(4.9章参照)。そのため、これらの知識をStatsCompressorがどれくらいうまく利用できるのか、興味深い。図33は、LRT_A集合に対して発見された規則でLRT_A集合を圧縮する際に、規則ファイルからロードされた規則の使用の統計値を示している。
なお、同一性に関する結果には、定数の圧縮のためにStatsCompressorが内部で生成した規則が含まれる。これは、StatsCompressorは定数統計値の同一性規則を作成しないという事実によるものである。そのため、この種の規則を含まないとStatsCompressorの誤ったイメージができてしまう恐れがある。なぜなら、統計値の中には、前述の同一性規則がないと圧縮が極めて非効率的になるものもあるからだ。例えば、数33、数34の場合、f=gの符号化」ではなく規則f=g+dgを使用することがある。定数の符号化のためにStatsCompressorが作成する規則の数は比較的小さく、統計値の数と同じぐらいしか規則はない。そのため、外部知識の規則の評価をそれほど混乱されるものではないが、これらがないと、結果が全く真実ではなくなってしまう。
図33の説明
結果について述べるまえに、図33で使用したカテゴリーについて説明する。
・All statics(全統計値)−分析されたZstatファイル内の平均統計値数。
・Non-const static(定数でない統計値)−分析されたZstatファイル内の定数でない統計値の平均数。
・Loaded rules(ロードされた規則)−規則ファイルからロードされ、圧縮に使用されると思われる、Zstatファイル1つ当たりの平均規則数。Zstatファイルに、ある規則が使用するすべての統計値が含まれている場合、その規則を使用することができる。
・Tried to apply(適用を試みた)−スコア化された規則の数(5.6.1項を参照)。適用を試みた規則>ロードされた規則。定数の圧縮のための生成された同一性規則は含まれるが、まず第一に、左辺と右辺を変えることで、既存の規則のほかに新たな規則が作成される(例えばf = g + hという規則がある場合、次の規則が作成される:f = g + h、g = h − f、h = g − f )。このような規則を有向規則という。各有向規則は、1つの統計値(左辺にあるもの)を圧縮することができる。
・Having a good cost(コストが良い)−実際に統計値を圧縮することができる、Zstat1つ当たりの平均有向規則数、そのため前述の規則を用いて統計値を符号化するコストの方が、最良のトランスフォーマット(5.6.1項を参照)を用いて統計値を圧縮するコストよりも小さい。
・Not applied, cycling(適用なし、循環)−統計値のグラフに循環を導入するために用いられ、統計値の実際の値を回復することができない(統計値間の関係のみわかる)、Zstat1つ当たりの平均有向規則数。5.6.2項を参照。
・Not applied, lhs described(適用なし、lhs説明ずみ)−統計値の圧縮用にすでに他の規則が選択されているため使用されなかった、Zstatファイル1つ当たりの平均有向規則数。5.6.2項を参照。
・Applied(適用)−圧縮に使用された、Zstat1つ当たりの平均有向規則数。同一性規則の列のカッコ内の数字は、規則ファイルから実際にロードされた同一性規則の平均適用数を示す(定数の圧縮のためにStatsCompressor自身が生成したものではない)。
・Evaluation time(評価時間)−Zstatファイル1つ当たりの、有向規則のスコア化にかかった平均時間(単位は秒)(5.6.1項を参照)。
・Choosing the rules(規則の選択)−Zstatファイル1つ当たりの、圧縮に使用する有向規則の選択にかかった平均時間 (5.6.2項を参照)。
なお、有向規則間には次の関係が保たれる:
Having a good cost = Applied + Not applied...
外部知識に基づく規則の使用のパフォーマンスの分析
まず、大変多くの規則が規則ファイルからロードされ、(平均)Zstatファイルに適用されることは、非常に有望なことである。しかし、有向和規則の数が著しく多くなり、和の評価にかかる時間が、同一性規則に対する同様の作業にかかる時間の80倍長くなることから、これはStatsCompressorのパフォーマンスにおいて主な問題点になると思われる。驚くべきことに、圧縮に使用する規則の選択は、評価よりも複雑だと思われたが、和の規則の評価よりもはるかに速く実行できる。これは、CPUのキャッシュの利用の向上、SIMD命令の利用などによって、評価フェーズのコードが改良されたものと考えられる。
コストが良好な(適用する価値がある)規則の数も印象的であり、相関に基づく圧縮には大きな潜在能力があることがわかる。同一性規則の44%、和の規則の16%にすぎないことから、圧縮率をそれほど下げなくても、規則ファイルのサイズを小さくすることができると思われる。この点については5.9.4項で述べる。(有向)規則が適用できない主な理由は、対象となる統計値がすでに他の規則によって圧縮されていることである。この状況は重要な意味を持つ。まず、規則を選択するアルゴリズムを改良すれば(5.6.2項を参照)圧縮率が向上する可能性がある。その一方で、同じ統計値を圧縮するのに様々な方法があることが多いため(他の様々な統計値と相関がある)、統計値間に大きな抽象クラスがあることも意味する。循環が出現することで、規則の適用に比較的少数の失敗が発生することは、少数の抽象クラスに関する情報と解釈することができるが、実際には、左辺がまだ圧縮されていない限り、規則はこの条件でしかチェックされないため、この値を解釈するのは難しい。しかし、この結果の値がどんなに大きくても、このチェックがなければ、適切に解凍できない統計値が数多く存在することになる。
当初は、適用される規則の数がZstat file1つ当たり平均42010個、平均48940個の統計値を含むことから(つまり統計値の86%は相関を用いて圧縮される)、膨大な数だと思われた。一方、平均41008個の規則が定数統計値を圧縮し、これらはStatsCompressor自身によって生成された。しかし、これはなかなか良いニュースである。なぜなら、StatsMinerで定数を落とすのは正しい決定であったことが証明されるからだ。そうでなければ、規則ファイルは膨大な数になり、StatsCompressorは今よりもはるかに遅くなる。したがって、ファイルからロードされる規則の適用数(計6598)を、定数でない統計値の数(14528)と比較し、統計値の45%はその相関を用いて圧縮されている。確かに、より多くの種類を相関を探索してStatsMinerを拡張したり、またはウィンドウの生成において、提案された理論的により良いアルゴリズムを実装すれば(4.3.1項参照)、この結果は改善される可能性がある。適用される規則の数は増えるが、現在、和は統計値の7%に適用されており、どの程度増えるかを予測するのは難しい。この種の和(3つの統計値のみで構成される)はあまり洗練されたものではなく、より多くの統計値の和があると考えられる。その一方で、相関の方程式が複雑になればなるほど、そのような規則の適用にかかるコストが高くなる。なぜなら、その規則もZplusファイルに記憶する必要があるからだ。
まとめ
外部知識の規則(ファイルからロードしたもの)は、圧縮に利用されることが多いため、StatsCompressorにとって重要である。StatsMinerでより多くの種類の相関が発見されれば(または既存のアルゴリズムを改良するだけでも)、StatsCompressorによる圧縮率が必ず改善されるであろう。なぜなら、今は、圧縮されていない統計値のグループがあるからだ。しかし、現在、StatsCompressorにはパフォーマンスの問題がある。評価する規則があまりにも多く(特に和の規則)、これらはもっと効率的に使用できると思われる。使用する和の規則数を減らす可能性について、5.9.4項で述べる。また、新たなシステムのアプローチについて、5.10項で述べる。問題のあるStatsCompressorの内部アルゴリズムについては、5.6章で述べた。
5.9.3. 同一性および和の規則の重要性
前のセクションで、StatsCompressorのパフォーマンスを改善するために、使用する和の規則の数を減らすことを提案した。図34は、LRT_A集合について発見された同一性規則のみを用いてLRT_A集合の圧縮を行った場合の、StatsCompressorの圧縮率を示している。カッコ内の値は達成された値と、全ての規則を使用した場合に得られる値との差を示す(完全なLRT_A/LRT_A実験にて。図23を参照)。したがって、これらは圧縮にとって和の規則が重要であることを示している。
図34に示すStatsCompressorの圧縮率を見ると、和の規則は、そのツールが達成する圧縮率に非常に小さな影響しか与えていないことがわかるが(ファイル全体で1.8% 、本体のみでは2.37%)、これを使用しないと、パフォーマンスが著しく改善される(CPUとメモリの使用量が許容範囲になるが、これはコンプレッサのプロトタイプにすぎない)。さらに、パフォーマンス結果の標準偏差が著しく減少するため、StatsCompressorの要件を簡単に予測できる。本体のみの圧縮の場合、xzコンプレッサは他のコンプレッサに比べて和の使用が最も重要であることは、興味深い。しかし、驚くべきことではない。この種の相関は外部コンプレッサ自身では発見できないため、何らかのデータを合計できるとは想定しないだろう。和を使用しない場合、StatsCompressorは影響を受ける統計値の圧縮に別の方法を使用し、xzはこの作業のいくつかを自身で行うことができると思われる。
和が使用されないため、そのかわりにStatsCompressorは同一性規則を適用する。平均して、通常よりも410個多くの同一性規則が適用される。このことは、和の規則が重要である証拠にもなる。なぜなら、すべて(平均1002)が置換されるわけではないからだ。さらに、和の規則は統計値の2%にしか適用されないが、これがStatsCompressorの圧縮率を2%改善する。これは、他の相関も使用してみるべきだということを意味する結果である。もちろん、和の規則の利用に関連するパフォーマンスの低下は、現時点では受け入れられないものであり、改善されるべきである。
5.9.4. 和の規則数のランダムな削減
和の規則を使用しつつStatsMinerの時間とメモリ消費量を削減する、もっともシンプルなアイデアは、この規則の特定の量をランダムに削除することである。図35は、すべての規則を使用した場合、すべての同一性を使用した場合、および和の規則数をランダムに選択した場合の、StatsCompressorの平均圧縮率とパフォーマンス結果の違いを示している。
図35の結果から、当初に発見された和の規則のわずかな割合を用いることで、StatsCompressorの圧縮率をわずかに失うだけでStatsCompressorのパフォーマンスを著しく改善する可能性があることがわかる。和の規則の20%を残すことは、良いトレードオフだと思われる。和の規則を使うことによってスペース節約の約45%を失うという犠牲のもとで、CPUとメモリの消費量を減らすことができるため、和の規則を全く使わなかった場合よりも、6%高いだけである。削除された規則がCPUおよびメモリの消費量と線形な関係がない、というStatsCompressorの奇妙な動作は、記憶の規則の組み合わせの形式を用いる影響だと思われる。規則のファイルは、各和の規則に含まれるすべての統計値の抽象クラスの積を含むからである。一方、このような良い結果が得られたことによって、圧縮に使用する規則の選択のために実装されたアルゴリズムは、シンプルなものだが、非常に効果的であることが証明される。
5.9.5. まとめ
外部知識に基づく規則を使用することの重要性を、図36に示す。この表は、ファイルから規則をロードしない場合の、LRT_Aの圧縮のためのStatsCompressorの圧縮率を示している。カッコ内の数字は、類似しているがLRT_A(「完全なLRT_A/LRT_A」)において発見されたすべての規則のロードを可能にした実験結果との差異である。別の観点からみると、この表は、前述のソリューションの別のモデルの説明の一部と考えることもできる(5.10を参照)。「StatsMinerがなかったらどうなるか?」という質問の答えである。
図36の結果から、ファイルからロードした規則(つまりStatsMinerによって発見されたもの)を使用することで、StatsCompressorの圧縮率が改善され、ファイル全体では、外部コンプレッサの使用に応じて変動するが、平均6.76%−12.22%ポイント、本体のみの場合は平均8.65%−14.33%ポイント改善されることがわかる。興味深いことに、gzipよりもbzip2コンプレッサの方が、ロードされた規則の使用がはるかに重要である。なおxzによって生成されたファイルは依然として小さい。
このアプローチにおいて、このツールは素晴らしいパフォーマンスを見せており、StatsCompressorを注意深く実装することでさらに改善されると思われる。特に、メモリ消費量は著しく減るであろう。現在、多くのデータがメモリに保存されているが、要求に応じて簡単に計算することができるからだ。
要するに、外部知識に基づく規則を使用するとStatsCompressorの圧縮率を高めることができるが、スペース節約は、他のビルトインアルゴリズムの場合のように大きくはない。しかし、StatsMinerを改良するために様々な作業を行うことができると思われるため、結果もはるかに良いものになるだろう。10パーセントポイントは実現可能だと考えられる。さらに、StatsCompressorのコードには、最適化が必要な部分があることがすでにわかっており、パフォーマンスも向上すると思われる。最後に、現在の結果は、現時点での研究としては満足できるものであると思われる。
5.10. 相関に基づく圧縮の使用の他のモデル
第3章で、この設計したソリューションの使用に関する、最も基本的な分散モデルについて述べた。顧客に送る規則を選択する方法、および外部コンプレッサの使用、という2つの点で、方針を採用すべきである。外部コンプレッサについては5.4章で述べた。5.10.2項、5.10.3項、および5.9.4項では、規則ファイルの作成に関する3種類のアプローチを述べる。そして、5.17では、StatsMinerをStatsCompressorと統合するという、まったく異なるアプローチについて述べる。そこでは、規則の発見は顧客のサイトで、圧縮の直前に行うことになる。なお、StatsCompressorをまったく使用しない、というもう1つのアプローチについては5.9.5で既に述べている。
このセクションでは、相関に基づく圧縮の使用に関する別のモデルについて、簡単に説明する。
5.10.1. 圧縮の現実的な分散モデル
これまでのところ、結果はすべて、LRT_A集合について発見された規則を用いた(あるいは用いない場合もある)LRT_A集合の圧縮に関するものであった。この前提は、あまり現実的ではない。なぜなら実際のZstatファイルは、同じデータについて発見されたものではない規則を用いて圧縮されるからだ(このようなアプローチについては5.17で説明する)。そのため、すでの分析した結果は「現在達成可能な最高のもの」と考えることができる。
図37は、LRT_A集合について発見された規則を用いてLRT_B集合を圧縮するためのStatsCompressorの圧縮率を示している。これは現実をシミュレートしているが、設計されたソリューションの最も楽観的な使用ケースでもある。顧客のサイトでのデータ(LRT_B集合)が「練習用の集合」(LRT_A集合)について発見された規則を用いて圧縮され、双方が同じバージョンのHYDRAstorで生成されたものである。
図37で示される結果は非常に良い。なぜなら、この現実的なモデルで達成されたStatsCompressorの圧縮率が、最良のモデルでの分析結果に極めて似ているからだ。0.5パーセントポイントしか悪くなっていない。当然、標準偏差は増加しているが、これは驚くことではない。入力データのエントロピーが増加しているからだ(同じファイルが探索されて圧縮されたわけではない)。このような良い結果を得るためには、偏差が許容されるされるものであることが有用だ。パフォーマンスは予想通りであった。CPUの使用量は増えたが(分析する偏差が多かった)、メモリ消費量は少なかった。なぜならLRT_B集合からのZstatファイルでは、LRT_A集合にみられる統計値のいくつかが存在しない場合があるからだ。
これらの結果は、前述したすべての実験の評価にとって非常に重要である。なぜなら、これまでに示した楽観的な結果がStatsMinerとStatsCompressorの使用に関する現実的なモデルの特性を述べる上でも、使用できると思われるからである。
5.10.2. 重要な規則の使用
StatsMinerは、最初に規則を探索し、その後、各規則が何回データに適用されるか、また統計値間の与えられた関係が正である頻度、についてチェックする。このチェックの結果を規則の有意性という(4.3章を参照)。この値は、相関がどの程度「良好」か、つまり、それが正である頻度、を示す。StatsMinerによって作成される規則は膨大な数になるため、すべてを顧客に送信することはできない。また前述のとおり、使用する規則が多すぎるとStatsMinerのパフォーマンスに悪影響を及ぼす。したがって、最高の有意性ファクタを持つ、最良の規則のみを顧客のマシンに転送することが合理的であると思われる。図38は、使用する規則の有意性とStatsCompressorの圧縮率(達成可能な最良の結果と比較)との相関およびそのツールのパフォーマンスを示している。
図38の結果によれば、所定の有意性を持つ規則を用いると、CPUとメモリ消費量の両方が著しく減っており、StatsMinerのパフォーマンスに強い影響を与えている。残念ながらStatsCompressorの圧縮率も低いが、リソース消費量の低下は、圧縮率の低下よりも、はるかに速い。この圧縮率の値を、StatsMinerによって発見された規則の使用の全般的な影響に関する情報を示す図36と比較すると、優位性が80%以上の規則を用いることが、規則ファイルのサイズ制限の方針にとって良い選択であると思われる。
なお、「最良の」規則が選択されているため、このような方法で作成された規則ファイルは、別のバージョンのHYDRAstorで収集された統計値を効率的に圧縮するために使うこともできる。
5.10.3. 既に使用された規則の使用
StatsMinerは数百万もの規則を作成するが、実際には、StatsCompressorは1つのZstatファイル当たり約63%の規則しか圧縮に使用しない。規則の有意性に基づく規則ファイルの制限(5.10.2項で説明した)は、StatsMinerからの知識に基づくものであった。図39は同様のアプローチを示しているが、これはStatsCompressorの使用経験に基づくものである。サポートのサイトで、StatsMinerは練習用の集合(LRT_A)における規則を発見し、StatsCompressorは同じ集合上で動作して、発見された規則のどれを実際に使用するかを決定する。その規則だけが顧客に転送される。このアプローチの品質は、LRT_B集合を圧縮することで測定される。
図39は、すでにLRT_A集合の圧縮に使用した規則のみでLRT_B集合を圧縮した場合のStatsCompressorの圧縮率を示している。カッコ内の値は、LRT_A/LRT_Aでの完全な実験から得た最良の達成可能率と比較した場合の圧縮率の低下を示しており、これらは非常に良いと評価することができる。なぜなら、圧縮率の低下は約1パーセントポイント程度だがパフォーマンスは著しく向上しているからだ。これはHYDRAstorのバージョンが似ているものであれば、StatsCompressorは別のZstatファイルの圧縮に同様の規則を用いていることを示している。しかし、標準偏差は50%まで上昇しているため、このアプローチを使ってZplusファイルのサイズを予測するのは難しいが、それでもわずか3%−4%である。規則ファイルのサイズを制限する前記の方法は、非常に期待が持てる、現実的なものだと思われる。
なお、このような良い結果が出たのは、偏差ベクトルの存在が許容されたからであろう。規則は、弱い相関を表すものとして扱われた。使用された規則選択方法は、StatsCompressorが、サポートのサイトで実験用のファイルを作成したHYDRAstorと同じバージョンのHYDRAstorによって生成されたZstatファイルを圧縮する場合に、最も良く機能すると考えられる。一方、StatsCompressorは、優位性が最も高い規則を用いるよりも、この手法を用いて選択された規則の場合の方が、はるかに良いパフォーマンスを示す。
5.10.4. StatsMinerとStatsCompressorの統合
図16に示すStatsMinerとStatsCompressorとの協働モデルは基本的なものであり、StatsMinerはCPU時間とメモリを多く必要とする。しかし、アルゴリズムはすでにStatsMinerからStatsCompressorへ移されており(定数の発見、5.8.1項を参照)、それほどパフォーマンスを損なうことなくStatsCompressorの圧縮率が向上するという結果を得ている。図40は、より革新的なアプローチを示している。Zstatファイルごとに、顧客のサイトでStatsMinerのStatsCompressorの両方を実行する、というものである。両ツールが統合された状況を(ある程度)シミュレートしている。
図40は、マイニングと圧縮の段階を結合し、顧客のサイトで各ファイルについてこの手順を個別に行った結果を示している。この結果を解釈する上で考慮する必要があるのは、StatsMinerとStatsCompressorはこのモデルを実行するために設計されたものではないため、パフォーマンス結果は非常に悪いということである。一方、StatsCompressorの圧縮率は、この方法において達成可能な最良ものものである。なぜならStatsMinerはまずすべての規則を発見し、最適なものを選択するからだ。これらのツールが統合されると、圧縮とマイニングがインターリーブされるため、同一性規則を用いて完璧に圧縮された統計値間の和の規則をマイニングすることはない。しかし、パフォーマンス結果が本来得られるはずのものより悪くても、顧客のサイトでのCPUとメモリの使用が半分に減る。これは、StatsCompressorによって使用される規則の数に何らかの制限を設けなければならない理由を示す、もう一つの証拠である。このモデルでは、StatsCompressorの圧縮率は、達成可能な最良のもの(LRT_A/LRT_Aの完全な実験から得られるもの)と比較して約1.5−2.5パーセンテージポイント下がった。興味深いのは、この結果が、圧縮に使用された規則を用いて達成される結果(5.10.3項を参照)よりも、わずかに悪いことである。ここからわかるのは、弱い規則を使用する可能性が、StatsCompressorにとっていかに重要であるか、ということだ。なぜなら、現時点では、StatsMinerは厳密な規則しか発見しない。結論は、StatsMinerにおけるランダムウィンドウの実装(4.3.1項参照)の優先度を高くするべきだ、ということである。標準偏差については、依然として低く、LRT_A/LRT_Aの完全な実験と比べてもそれほど違いがなかった。これは、Zplusファイルのサイズの予測が可能となるため、良い兆候である。
5.10.5. まとめ
このセクションでは、顧客のサイトに送信する規則の選択に関して(3.1章参照)、以下の様々な方針について説明し、評価した。
1.最も重要な規則の使用(5.10.2)。
2.StatsCompressorで既に使用された規則の使用(5.10.3)。
3.和の規則のランダムな選択(5.9.4).
前述の方針を組み合わせて、規則ファイルが期待する特性を持つようにしてもよい(わずかに異なるバージョンのHYDRAstor(1)とはよく機能する、特定のバージョンのHYDRAstor(2)または最小サイズのものとは最も良い結果を出す(3)。
一方、StatsMinerとStatsCompressorとの協働に関するまったく異なるモデルについて、以下の研究を行った。
1.相関に基づく圧縮の分散モデル(5.10.1)。
2.StatsMinerを全く使用しない(5.9.5)。
3.StatsMinerとStatsCompressorの統合(5.17)。
各モデルは、達成可能な圧縮率とパフォーマンスとの間で、異なるトレードオフを必要とする。設計されたソリューションに課される制限によって異なるため、一番良いものを選ぶのは非常に難しい。また、作成されたソフトウェアは実験用のものであり、そのパフォーマンスは十分調整されていない。
最後に、LRT_A/LRT_Aの完全な実験の結果は他の実験結果との比較のベースとして使用できることが証明された。なぜなら、実際に用いられる場合のStatsCompressorの圧縮率とパフォーマンスは、これらの理想的なものと、それほど大きく変わらないからである(5.10.1を参照)。
5.11. まとめ
StatsCompressorは、統計値を含むファイルを圧縮するための強力なツールである。特別なファイルからロードした相関(5.9章)または自身で発見した相関を用いて、データを圧縮する。このツールは、Zstatファイルのサイズを平均して半分に縮小する(最大で66.6%)。残念ながら、このプロセスのパフォーマンスは非常に良いわけではなく、CPUとメモリの消費量が非常に高い。この点は、もっと慎重に実装して最適化し、より効率的な内部アルゴリズムの選択(5.9.5で概説した)またはStatsCompressorの使用に対するアプローチ全体の変更(5.10)、によって改善することができる。
実装したソフトウェアの具体的な性質にかかわらず、圧縮に相関を用いることが良いアイデアだということが証明された。なぜなら、最も一般的なコンプレッサ(gzip、bzip2、xz)はこのような可能性を用いていないからだ。スペース節約は、StatsMiner(および適当な場合はStatsCompressor)の機能を拡張することで、向上すると思われる。
第6章 顧客から取得した実際の統計値での評価
相関に基づく圧縮は、Long Running Test(LRT)において収集された人為的な統計値だけでなく、実際の顧客から受け取った統計値(Customer Logs)でもテストされた。前述のとおり、このような統計値は、システムのパフォーマンスをチェックする必要がある場合、またはシステムが期待通りの動作をしないため潜在的なバグを調査する必要がある場合に、随時ダウンロードされる。そのため、このような統計値は特定のものであることが多い。本研究で設計されたソリューションは、主にこのような状況で使用されるものだが、あらゆる状態で使用することができる。このような理由から、Long Running Testの結果、およびCustomer Logの最も重要なものに限り、詳細な実験を行うことにした。このアプローチを行ったもう1つの理由は、顧客から受け取る統計値の量が非常に大きくても、すべてのファイルが適切なサイズのものではないからだ(小さすぎるものも、かなりある)。最後に、顧客から取得した利用可能な統計値は、HYDRAstorシステムの別のバージョンで生成されたものであった。このような一貫性のないデータで行った実験は、システムの特定のバージョンで作成された統計値で実験を行った場合よりも、少し悪い結果になると思われる。
6.1. テストベッド
6.1.1. テストデータ
テストはすべてCL_2というテストデータ集合に対して行われた。第4章ではCL集合を分析したが、数36である。CL_2集合は、実際のユーザ(顧客)から受け取ったファイルの中からランダムに選択された50個のXMLファイルを含む(CLは30)。これらのファイルは、様々なパッチとアップデートがインストールされた、様々なバージョンのHYDRAstorシステムから生成された。このテストには、サイズが2MBから4MB、SNから生成されたものだけが認められた。選択されたファイルはZstatフォーマットに変換されており、これらのファイルは50000個の統計値を含み、各々が140−240のサンプルを含む(ただし、1つのファイル内の統計値はほぼ同数のサンプルを有する)。
6.1.2. パフォーマンスの測定
テストは、StatsMinerのテストと同じマシン、同じ方法で行われた(4.2.2項を参照)。
6.2. 実験結果
図41と図42は、CL_2集合に対して、設計したソリューションを異なるモードで実行した結果を示している。1つ目の表(図41)はStatsCompressorの平均圧縮率を示しており、2つ目の表(図42)は結果の標準偏差を示している。カッコ内には、CL_2集合に対する実験の値と対応するLRT_A集合に対する実験との差を示す。列の名前は5.10章で述べたモデルに対応する。
・楽観的−CL集合全体について探索された規則を用いたCL_2集合の圧縮。なお、数37かつ|CL| = 30、|CL_2| = 50。規則はCL集合に対して発見された。なぜならCL_2上でStatsMinerを実行するとメモリ消費量が大きすぎるからだ(40GM超)。同様の実験が、完全なLRT_A/LRT_Aで行われた−図23。
・現実的−LRT_A集合全体について探索された規則を用いたCL_2集合の圧縮。類似する実験の結果が図37に示されている。
・使用済み−LRT_A集合で発見された規則でLRT_A集合の圧縮に使用された規則を用いた、CL_2集合の圧縮。類似する実験の結果が図39に示されている。
・規則なし−StatsMinerで作成した規則を使用しないCL_2集合の圧縮。類似する実験の結果が図36に示されている。
・統合−現時点で圧縮されたファイルにおけるStatsMinerによって発見された規則を用いたCL_2集合の圧縮。類似する実験の結果が図40に示されている。
パフォーマンス結果はStatsCompressorにのみ適用される。ただし、StatsMinerとStatsCompressorのパフォーマンスの和である「統合」モデルを除く。
6.3. 実験結果の分析
顧客から取得した統計値に対する実験結果は満足できるものである。前述のとおり、LRT_A集合とは違い、CL_2集合は様々なバージョンのHYDRAstorによって収集されたデータを含む。そのため、LRT_A集合に対する実験よりも結果が悪くなって当然である。しかし、損失はそれほど大きくなかった。ファイル全体では1.92−7.48パーセントポイント、本体のみでは3.98−9.23パーセントポイントであった。なお、CL_2集合からの統計値は、LRT_A集合からの統計値のサンプル(60-100)よりも、より多くのサンプル(140-240)を含む。そのため、ファイル全体の場合と本体のみの場合の圧縮結果の比率は異なる。達成された結果から、設計されたソリューションは、実際に使用されるケースでも合理的であることがわかった。
楽観的な結果は、達成可能な仮説的最高結果を示す。実際のところ、CL集合は、その部分集合(CL_2)から発見された規則のみを用いて圧縮された。完全なCL集合で規則が発見されていれば、StatsCompressorの圧縮率がそれほど向上することはないと思われるが(図35、38)パフォーマンスは著しく下がると思われる。現在のところ、「統合」モデルは「楽観的」モデルよりも結果の低下が少ないという特徴があり、もし「楽観的」アプローチにおける規則が完全なCL集合で発見されれば、これは逆になる可能性がある。
StatsCompressorの圧縮率の低下という点で最高の結果は、「統合モデル」で達成されている。これらは、最高の絶対結果でもある(ただし「楽観的」モデルを除く。楽観的モデルは、規則ファイルのサイズがあまりにも大きすぎて全く現実的でない。)使用するコンプレッサに応じて変動するが、最終的にZplusファイルはZstatファイルよりも28%−49%小さい。これは非常に良い結果である。残念ながら、パフォーマンスは非常に悪い。CL集合からのZstatファイルにおけるサンプル数が大きいことと関係があると思われる。一方、前述のとおり、StatsMinerとStatsCompressorは、(パフォーマンスに関して)このモデルで効率的に動作するよう設計されたものではないため、さらなる最適化を行うことができる。
「現実的な」モデルの結果は平凡だが、許容できるものである。しかし、損失がかなりあり、パフォーマンスが悪い(LRT_A集合に対する同じ実験よりは良いが)。本体のみの場合の低下があまりにも大きいことが気がかりである。外部コンプレッサ用のあらゆるモデルの中で最も大きかった。一方、「使用済み」モデルでの実験結果は満足できるものである。StatsCompressorの圧縮率の低下は実に大きいが、「現実的な」モデルよりわずかに小さく、パフォーマンスは非常によい。使用する規則数の制限に対するこのアプローチは、規則の作成とファイルの圧縮とでHYDRAstorシステムのバージョンが違う場合はうまくいかないが、最終的な結果は十分許容できるものである。このモデルの標準偏差が、使用した各外部コンプレッサとリソース消費のカテゴリーで低下したことは、興味深い。これは非常に良いことだ。標準偏差が低ければ低いほど、最終的なZplusファイルのサイズの予測が正確になるからだ。
「規則なし」のモデルに関する結果は、少し落胆するものである。このアプローチにおいて、StatsCompressorは各ファイルについて個別に分析を行ったのだが、ファイル全体での低下は5.04−6.31%であった。これは、各Zstatファイルのサンプルの量が多かったことと関係があると思われ、例えば定数の捜索がうまく機能しなかったのだろう。その一方で、顧客のHYDRAstorが、LRT_A集合についてのZstatファイルの生成に使用したものよりも以前のバージョンであったために起こった結果という可能性もある。最後に、HYDRAstorは、顧客の通常使用では、人為的なLong Running Testの場合と違う動作をする可能性がある。しかし、「規則なし」のアプローチの結果は、さらに、この論文で提案した方法はすべて、実際のな例においても良い圧縮率を得るために重要であり、StatsCompressorだけを使用したのでは十分でないことを証明している。
すべての実験結果の標準偏差は良いものである。圧縮されたファイルは異なるバージョンのHYDRAstorからきたものであったが、それほど増加することもなかった。これは、どのバージョンが使用されたとしても、このシステムで生成された統計値は類似していることを意味する。つまり、統計値の分析に基づく変則性の発見は合理的であることを意味する(少なくともStatsMinerで発見された相関を用いる場合)。
外部コンプレッサの選択については、StatsCompressorの圧縮率はbzip2ツールが最も高かった。
6.4. まとめ
顧客から受け取った統計値の圧縮に使用される、この設計されたソリューションで行った実験により、相関に基づく圧縮は実際にうまく利用できることがわかった。達成された結果は、例としての統計値を圧縮した場合よりもわずかに悪かったが、それでも満足できるものである。次の2つのアプローチが、他のものよりも著しく良い結果を出すことがわかった。1つはStatsMinerとStatsCompressorとの統合であり、2番目は、練習用の集合の圧縮にすでに使用した規則の使用である。最初の方法は、結果は良いが、パフォーマンスが悪かった。これを使用するには、このような動作をするために最適化された新たなツールを作る必要がある。2番目の方法は、パフォーマンスおよび圧縮率の両方が改善される可能性があると思われるため、さらに調査する必要がある。例えば、優位性が最も高い規則(ただし圧縮に使用されていないもの)で規則ファイルを拡張することを確認するべきである。
まとめると、この設計されたソリューションは実用的である。
第7章 関連研究
この論文は、発見された相関とドメイン知識を用いて、特定の種類のログの圧縮率を改善する方法を提案するものである。ここで提案したアプローチ、特に、サポートのサイトで相関を発見し、この知識を顧客のサイトで使用するというアイデアは、文献では提案されていないと思われる。しかし、この設計されたソリューションは、コンピュータサイエンスにおける、データマイング、圧縮、ログ分析、といった十分に研究されたいくつかの領域の交点に位置すると考えられる。
ログの圧縮は長い間研究されており、特に、スーパーコンピュータ(文献[BS06])または分散システム([RL04]、[SS07])で研究されている。上記の論文は、追加的かつ専用のコンプレッサの使用を提案しており、これらを汎用のものと合わせて使用する。本論文で述べる設計されたソリューションは、同じアプローチに基づく。しかし、StatsCompressorは入力として統計値を有する。統計値は、すでに解析され圧縮された、ある種のログである。一方、引用した論文の著者は、自身を解析するログと戦っており、同一性を捜索してファイルのサイズを縮小しようと試みている。[BS06]の著者はバイトレベルで機能するアルゴリズムを開発し、[SS07]のソリューションは、ログのラインを比較することによって機能する。[RL04]は、別々の最も有効なアルゴリズムを用いて、ログの各列を圧縮することを提案している。これら前述のすべての論文の著者は、そのツールのリソース消費量を最小限にすることに大変な努力をしており、この点については、StatsMinerもStatsCompressorも改善すべきである。
調査[OGX12]に記載されるように、ログは、様々な方法で利用できるシステムの状態に関する知識の非常に重要なソースである。データマイニング法は、ログの分析[HBK+03]または変則性の検出[OKA10]、[BKK01]、[FRZ+12]において、よく利用される。これらはすべて、何らかの方法で相関を利用しているが、著者によって、この用語の理解も異なる。[HBK+03]は、「包括的なログの圧縮」を提案しており、その目的はデータの圧縮ではなく(テキスト)パターンの発見によるログの分析においてシステム管理者を助けることである。この観点から、StatsMinerによって生成される規則もシステム管理者にとっては重要な知識のソースになり得る。[FRZ+12]の著者は、「ボトルネック変則性」の概念について述べており、これはシステムを調整する上で興味深い。特定のバージョンのHYDRAstorのためにStatsMinerによって生成された規則のモデル集合を、特定のZstatファイルで発見されたものと比較することにより、一連のシンプルなスクリプトがそのような状況を発見する助けになると思われる。非結合統計値間での例外的な同一性の相関(「統計値ファイルにおける変則性」)は、パフォーマンスのボトルネックの存在を警告することがある。興味深いことに、[FRZ+12]の著者は、StatsMinerと同様の、ウィンドウと似ている概念を既に紹介している。その一方で、分析には洗練されたデータマイニング技術を用いた。本段落で取り上げた論文はすべて、変則性検出のためのツールを提案しており、これらはStatsMinerによって生成された規則を用いることで(おそらく)拡張および改良されると思われる。なぜなら、これらはすべて依存性または相関に基づくものだからである。[OKA10]は「影響の構造のグラフ」を提案しており、[BKK01]はオペレーションの依存性に焦点を当てており、[FRZ+12]はイベント予測のツールについて述べている。この最後の論文には、包括的な参考文献一覧も含まれている。最後に、[Say04]はStatsMinerで用いたものと非常に似ているアプローチでのデータ分析について述べている。[Say04]は、データストリームにおける時間の相関の検出に焦点を当てており、StatsMinerも非常に似たことを行っているが、[Say04]に記載されている方法は、興味を持った単一のイベントを探索するのではなく、そこに記載されているアルゴリズムが全般的な関係を発見しようとしている。
データマイニングの観点から見ると、本論文で用いられている相関の概念は、特定の関連性規則と類似性を持つ。関連性規則の発見には様々な方法があるが、それらはあまりにも一般的であり、StatsMinerで使用するには速度が遅すぎると思われる。特に、このツールの目的は、正確な数値的関係性の探索だからだ。興味深いことに、[BMS97]では、数学的な観点から関連性規則をアップグレードして相関にするという点で、問題に直面している。この論文で述べられている数学的なアプローチは、StatsCompressorで使用する規則の数を制限する方法を改善するために採用できる可能性がある。実際、本論文で使用される有意性の概念は「信頼性」と非常に似たものであり、信頼性は関連性規則の世界に由来するものである。さらに、「サポート」という用語は、すべてのウィンドウ数に対する、相関が発生する可能性のあるウィンドウ(なぜなら予想統計値が存在するから)の割合に対応する。
まとめると、データマイニングツールによって発見された数値的相関を使用して、別の(または同じ)一連のデータを圧縮するというアイデアは、新しいものであると思われる。
第8章 まとめ
本論文は、統計値の圧縮に対する、分散型のデータマイニングに基づくアプローチを示したもので、その統計値はある種の集合ログである。2つのツールが実装されており、それらは、統計値間の相関を探索するStatsMinerと、StatsMinerによって作成された規則を用いて統計値を含むファイルを効率的に圧縮するStatsCompressorである。両プログラムは、分散モデルで動作すること意図している。StatsMinerはサポートのサイトでデータ例に対して動作することで相関を発見し、StatsCompressoは顧客のサイトで動作する。これらのツールの協働に関するその他のモデル、例えば顧客のマシンのみでソフトウェア全体を動作させるモデル、も評価した。
達成された圧縮率は、あらゆる期待に沿うものである。平均すると、最も楽観的なモデルで、StatsCompressorはスペース節約を増やすことができ、bzip2コンプレッサと併用した場合は約50%、gzipコンプレッサと併用した場合は約45%、xzコンプレッサと併用した場合は約30%、増えた。より多くの種類の相関の発見を目的とする、StatsMinerのための拡張を実装することによって、この結果をさらに向上させることが可能だと思われる。一方、実装されたソフトウェアのパフォーマンスは期待を下回るものである。ただし、これはプロトタイプのバージョンであり、パフォーマンスのボトルネックが特定され、予備的なソリューションがいくつか提案された。
統計値間の相関を発見するためのツールであるStatsMinerは、変則性検出のソフトウェアの基礎としても使用することができる。
この論文に記載した結果のいくつかは、NECのHYDRAstorに導入する計画がある。このプロジェクトでの研究は、HYDRAstorサポートチームが実際に直面した問題によって開始され、その問題はここで提案したアイデアを用いることで解決できると思われる。
<付記>
上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明におけるデータ圧縮システムなどの概略を説明する。但し、本発明は、以下の構成に限定されない。
(付記1)
収集した所定のデータの集合から当該所定のデータの集合内のデータの関係に基づいた相関関係の候補を少なくとも1つ抽出する相関関係抽出手段と、
前記所定のデータの集合内のデータが、前記相関関係抽出手段が抽出した前記相関関係を満たすか否かを検証する相関関係検証手段と、
前記相関関係検証手段による検証結果に基づいて、前記相関関係を用いて前記所定のデータの集合を圧縮するデータ圧縮手段と、
を備える、
データ圧縮システム。
(付記2)
付記1に記載のデータ圧縮システムであって、
前記所定のデータの集合内の各データのそれぞれは、少なくとも1つ以上のデータの値を有するデータ群であり、
前記相関関係抽出手段は、前記所定のデータの集合内のデータ群の関係に基づいた相関関係の候補を少なくとも1つ抽出する、
データ圧縮システム。
(付記3)
付記2に記載のデータ圧縮システムであって、
前記相関関係抽出手段は、複数の前記データ群を構成するデータの値の個数がそれぞれ同数である局所化探索範囲を少なくとも1つ生成して、当該生成した局所化範囲内のデータ群の関係に基づいた相関関係の候補を少なくとも1つ抽出し、
前記相関関係検証手段は、前記相関関係抽出手段が生成した複数の局所化探索範囲内のそれぞれのデータ群が、前記相関関係を満たすか否か検証する、
データ圧縮システム。
(付記4)
付記2又は3に記載のデータ圧縮システムであって、
前記相関関係抽出手段は、予め定められた種類の相関関係の候補を抽出した後、当該相関関係を有するデータ群を前記局所化探索範囲から排除し、当該排除後の局所化探索範囲内で前記データ群の関係に基づいた相関関係を再度抽出する、
データ圧縮システム。
(付記5)
付記2乃至4の何れかに記載のデータ圧縮システムであって、
前記相関関係抽出手段は、前記所定のデータの集合からデータの値が定数である前記データ群を抽出した後、定数である前記データ群を前記局所化探索範囲から排除し、当該排除後の局所化探索範囲内でデータ群の関係に基づいた相関関係を再度抽出する、
データ圧縮システム。
(付記6)
付記2乃至5の何れかに記載のデータ圧縮システムであって、
前記相関関係抽出手段は、前記所定のデータの集合内のデータ群のうち、予め定められた基準に基づいて同一と判断されるデータ群の組み合わせを抽出する、
データ圧縮システム。
(付記7)
付記1乃至6の何れかに記載のデータ圧縮システムであって、
前記相関関係検証手段は、前記データごとに網羅的に列挙した前記相関関係を満たすデータを記憶して、前記所定のデータの集合が、当該網羅的に列挙したそれぞれの相関関係を満たすか否かを検証する、
データ圧縮システム。
(付記8)
付記1乃至6の何れかに記載のデータ圧縮システムであって、
前記相関関係検証手段は、前記相関関係を表す数式を生成し、前記所定のデータの集合が、当該生成した一般則を満たす場合と満たさない場合とを分けて検証する、
データ圧縮システム。
(付記9)
収集した所定のデータの集合から当該所定のデータの集合内のデータの関係に基づいた相関関係の候補を少なくとも1つ抽出し、
前記所定のデータの集合内のデータが前記相関関係を満たすか否かを検証し、
前記検証の結果に基づいて、前記相関関係を用いて前記所定のデータの集合を圧縮する、
データ圧縮方法。
(付記9−1)
付記9に記載のデータ圧縮方法であって、
前記所定のデータの集合内の各データのそれぞれは、少なくとも1つ以上のデータの値を有するデータ群であり、
前記所定のデータの集合内のデータ群の関係に基づいた相関関係の候補を少なくとも1つ抽出する、
データ圧縮方法。
(付記9−2)
付記9−1に記載のデータ圧縮方法であって、
複数の前記データ群を構成するデータの値の個数がそれぞれ同数である局所化探索範囲を少なくとも1つ生成して、当該生成した局所化範囲内のデータ群の関係に基づいた相関関係の候補を少なくとも1つ抽出し、
生成した複数の局所化探索範囲内のそれぞれのデータ群が、前記相関関係を満たすか否か検証する、
データ圧縮方法。
(付記10)
所定のデータを圧縮するための相関関係を抽出するデータ圧縮用相関関係抽出装置であって、
収集した所定のデータの集合から当該所定のデータの集合内のデータの関係に基づいた相関関係の候補を少なくとも1つ抽出する相関関係抽出部と、
前記所定のデータの集合内のデータが、前記相関関係抽出部が抽出した前記相関関係を満たすか否かを検証する相関関係検証部と、
を備える、
データ圧縮用相関関係抽出装置。
(付記10−1)
付記10に記載のデータ圧縮用相関関係抽出装置であって、
前記所定のデータの集合内の各データのそれぞれは、少なくとも1つ以上のデータの値を有するデータ群であり、
前記相関関係抽出部は、前記所定のデータの集合内のデータ群の関係に基づいた相関関係の候補を少なくとも1つ抽出する、
データ圧縮用相関関係抽出装置。
(付記10−2)
付記10−1に記載のデータ圧縮用相関関係抽出装置であって、
前記相関関係抽出部は、複数の前記データ群を構成するデータの値の個数がそれぞれ同数である局所化探索範囲を少なくとも1つ生成して、当該生成した局所化範囲内のデータ群の関係に基づいた相関関係の候補を少なくとも1つ抽出し、
前記相関関係検証部は、前記相関関係抽出部が生成した複数の局所化探索範囲内のそれぞれのデータ群が、前記相関関係を満たすか否か検証する、
データ圧縮用相関関係抽出装置。
(付記11)
情報処理装置に、
収集した所定のデータの集合から当該所定のデータの集合内のデータの関係に基づいた相関関係の候補を少なくとも1つ抽出する相関関係抽出手段と、
前記所定のデータの集合内のデータが、前記相関関係抽出手段が抽出した前記相関関係を満たすか否かを検証する相関関係検証手段と、
を実現させるためのプログラム。
(付記11−1)
付記11に記載のプログラムであって、
前記所定のデータの集合内の各データのそれぞれは、少なくとも1つ以上のデータの値を有するデータ群であり、
前記相関関係抽出手段は、前記所定のデータの集合内のデータ群の関係に基づいた相関関係の候補を少なくとも1つ抽出する、
プログラム。
(付記11−2)
付記11−1に記載のプログラムであって、
前記相関関係抽出手段は、複数の前記データ群を構成するデータの値の個数がそれぞれ同数である局所化探索範囲を少なくとも1つ生成して、当該生成した局所化範囲内のデータ群の関係に基づいた相関関係の候補を少なくとも1つ抽出し、
前記相関関係検証手段は、前記相関関係抽出手段が生成した複数の局所化探索範囲内のそれぞれのデータ群が、前記相関関係を満たすか否か検証する、
プログラム。
なお、上記各実施形態及び付記において記載したプログラムは、記憶装置に記憶されていたり、コンピュータが読み取り可能な記録媒体に記録されている。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。
以上、上記各実施形態を参照して本願発明を説明したが、本願発明は、上述した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解しうる様々な変更をすることが出来る。