JP6341205B2 - データ圧縮システム - Google Patents

データ圧縮システム Download PDF

Info

Publication number
JP6341205B2
JP6341205B2 JP2015530803A JP2015530803A JP6341205B2 JP 6341205 B2 JP6341205 B2 JP 6341205B2 JP 2015530803 A JP2015530803 A JP 2015530803A JP 2015530803 A JP2015530803 A JP 2015530803A JP 6341205 B2 JP6341205 B2 JP 6341205B2
Authority
JP
Japan
Prior art keywords
data
correlation
statistics
rules
predetermined
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2015530803A
Other languages
English (en)
Other versions
JP2016524821A (ja
Inventor
ドミニク ボロヴィエツ
ドミニク ボロヴィエツ
ミーハウ ヴェウニーツキ
ミーハウ ヴェウニーツキ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Publication of JP2016524821A publication Critical patent/JP2016524821A/ja
Application granted granted Critical
Publication of JP6341205B2 publication Critical patent/JP6341205B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24553—Query execution of query operations
    • G06F16/24561—Intermediate data storage techniques for performance improvement
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/174—Redundancy elimination performed by the file system
    • G06F16/1744—Redundancy elimination performed by the file system using compression, e.g. sparse files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2465—Query processing support for facilitating data mining operations in structured databases
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/3068—Precoding preceding compression, e.g. Burrows-Wheeler transformation
    • H03M7/3079—Context modeling
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/60—General implementation details not specific to a particular type of compression
    • H03M7/6064—Selection of Compressor

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Computational Linguistics (AREA)
  • Fuzzy Systems (AREA)
  • Mathematical Physics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)

Description

本発明は、データ圧縮システム、データ圧縮方法、データ圧縮用相関関係抽出装置、プログラムに関する。
スケーラブルストレージなどの分散システムでは、バグが発生した場合の対処やパフォーマンスの改善などを行うために、各ソフトウェア部品の動作状況やハードウェアリソースなどのシステムの状態を統計情報として一定間隔で採取することが行われている。
上記統計情報は膨大な数のデータである。そして、例えば顧客の側から取得した統計情報を用いてシステムにおける問題の分析を行うためには、出来る限り大量の統計情報を収集することが望ましい。一方で、セキュリティ上の問題などから、ダウンロード可能なデータ数が制限されている場合がある。そのため、パッケージのサイズを大きくすることなくより多くの統計情報を送信するために、データを圧縮した上で当該圧縮したデータの送信を行うことが必要となっていた。
このように、収集したデータに基づいて何らかの分析を行うなどの所定の目的を達成するために、大量のデータを保存したり転送したりすることがある。このような場合には、上記のようなセキュリティ上の問題、コスト面などから、データを圧縮することが望ましい。
このようなデータを圧縮するための技術として、例えば、特許文献１が知られている。特許文献１には、圧縮対象のデータ群のデータを項目の情報の一致の分布によってグループ分けをし、設定された情報制度に応じて情報を書き換えたデータを圧縮する技術が記載されている。
特開２０１２−１６８６７１号公報
上述したように、調査などの目的のためデータを入手する場合には、大量のデータを入手することが極めて重要である。しかしながら、上記のような技術を用いた圧縮だけでは、必ずしも望ましい圧縮効率を達成することが出来ない場合があった。
また、このような調査のためのデータの転送などの処理に伴うデータの圧縮を行う場合、高い信頼性を保ちつつデータを圧縮することが必要となる。しかしながら、高い信頼性を維持しつつデータを効率的に圧縮することは、単にデータを圧縮することよりも難しい。
以上のように、高い信頼性を維持しつつデータを効率的に圧縮することが難しい、という問題が生じていた。
そこで、本発明の目的は、上述した課題である、高い信頼性を維持しつつデータを効率的に圧縮することが難しい、という問題を解決することの出来るデータ圧縮システムを提供することにある。
かかる目的を達成するため本発明の一形態であるデータ圧縮システムは、
収集した所定のデータの集合から当該所定のデータの集合を構成する各データの値の相関関係の候補を少なくとも１つ抽出する相関関係抽出手段と、
前記所定のデータの集合が、前記相関関係抽出手段が抽出した前記相関関係を満たすか否かを検証する相関関係検証手段と、
前記相関関係検証手段による検証結果に基づいて、前記相関関係を用いて前記所定のデータの集合を圧縮するデータ圧縮手段と、
を備える、
という構成を採る。
また、本発明の他の形態であるデータ圧縮方法は、
収集した所定のデータの集合から当該所定のデータの集合を構成する各データの値の相関関係の候補を少なくとも１つ抽出し、
前記所定のデータの集合が前記相関関係を満たすか否かを検証し、
前記検証の結果に基づいて、前記相関関係を用いて前記所定のデータの集合を圧縮する、
という構成を採る。
また、本発明の他の形態であるデータ圧縮用相関関係探索装置は、
所定のデータを圧縮するための相関関係を抽出するデータ圧縮用相関関係抽出装置であって、
収集した前記所定のデータの集合から当該所定のデータの集合を構成する各データの値の相関関係の候補を少なくとも１つ抽出する相関関係抽出部と、
前記所定のデータの集合が、前記相関関係抽出部が抽出した前記相関関係を満たすか否かを検証する相関関係検証部と、
を備える、
という構成を採る。
また、本発明の他の形態であるプログラムは、
情報処理装置に、
収集した所定のデータの集合から当該所定のデータの集合を構成する各データの値の相関関係の候補を少なくとも１つ抽出する相関関係抽出手段と、
前記所定のデータの集合が、前記相関関係抽出手段が抽出した前記相関関係を満たすか否かを検証する相関関係検証手段と、
を実現させるためのプログラムである。
本発明は、以上のように構成されることにより、高い信頼性を維持しつつデータを効率的に圧縮可能なデータ圧縮システムを実現することが出来る。
本発明の第１の実施形態に係るデータ圧縮システム全体の構成を示すブロック図である。 図１で示すストレージシステムの構成の一例を示すブロック図である。 図１で示す統計値マイニング装置の構成の一例を示すブロック図である。 図３で示す統計値マイニング装置が記憶する統計値の一例の示す表である。 図３で示すウィンドウ生成手段が生成するウィンドウの一例を示す表である。 図３で示す相関関係抽出手段により行われる相関関係の抽出の一例を示す図である。 図３で示す相関関係抽出手段により行われる相関関係の抽出の一例を示す図である。 図３で示す相関関係抽出手段により行われる相関関係の抽出の一例を示す図である。 図３で示す相関関係検証手段により行われる検証処理の一例を示す図である。 図３で示す規則ファイルが相関関係を記憶する際の記憶の仕方を説明するための図である。 図１で示す統計値圧縮装置の構成の一例を示すブロック図である。 図１で示す統計値マイニング装置の動作の一例を示すフローチャートである。 図１で示す統計値マイニング装置がウィンドウ内の相関関係を探索する際の動作の一例を示すフローチャートである。 図１で示す統計値圧縮装置の動作の一例を示すフローチャートである。 本発明の第２の実施形態におけるＺｓｔａｔファイルの一例を示す図である。 本発明の第２の実施形態における全体の構成の概略を示す図である。 ＳｔａｔｓＭｉｎｅｒでのマイニング動作を説明するための図である。 ＳｔａｔｓＭｉｎｅｒでの検証動作を説明するための図である。 図１５で示すＺｓｔａｔｓファイルに基づいてＳｔａｔｓＭｉｎｅｒが生成するウィンドウの構成の一例を示す図である。 ツリー形式でＳｔａｔｓＭｉｎｅｒが発見した規則を記憶する際の一例を示す図である。 ＳｔａｔｓＭｉｎｅｒのパフォーマンス結果の一例を示す表である。 異なるタイプの規則の最小有意性の割合の一例を示すグラフである。 ＳｔａｔｓＣｏｍｐｒｅｓｓｏｒの平均圧縮率とＳｔａｔｓＣｏｍｐｒｅｓｓｏｒのパフォーマンス結果の一例を示す表である。 絶対圧縮率の一例を示す表である。 外部コンプレッサのパフォーマンスの一例を示す表である。 ＳｔａｔｓＣｏｍｐｒｅｓｓｏｒでの圧縮動作を説明するための図である。 リナンバリングを不能にしてＬＲＴ＿Ａについて発見された規則を用いてＬＲＴ＿Ａ集合を圧縮した結果の一例を示す表である。 抽象クラスの平坦化を不能にして、ＬＲＴ＿Ａについて発見された規則を用いてＬＲＴ＿Ａ集合を圧縮した結果の一例を示す表である。 定数の圧縮のみを実行したＳｔａｔｓＣｏｍｐｒｅｓｓｏｒでの実験結果の一例を示す表である。 トランスフォーマットを唯一の圧縮方法として用いてＬＲＴ＿Ａ集合を圧縮する際のＳｔａｔｓＣｏｍｐｒｅｓｓｏｒの圧縮率の一例を示す表である。 トランスフォーマットが具体的に使用された回数の一例を示す表である。 偏差ベクトルが不能な場合（厳密な相関のみが許容された場合）の、ＳｔａｔｓＣｏｍｐｒｅｓｓｏｒの圧縮率の一例を示す表である。 ＬＲＴ＿Ａ集合に対して発見された規則でＬＲＴ＿Ａ集合を圧縮する際に、規則ファイルからロードされた規則の使用の統計値の一例を示す表である。 ＬＲＴ＿Ａ集合について発見された同一性規則のみを用いてＬＲＴ＿Ａ集合の圧縮を行った場合の、ＳｔａｔｓＣｏｍｐｒｅｓｓｏｒの圧縮率の一例を示す表である。 使用する和の規則の割合を変化させた場合の圧縮率の差の一例を示す表である。 ＳｔａｔｓＭｉｎｅｒで発見された規則を使用しない場合の、ＬＲＴ＿Ａの圧縮のためのＳｔａｔｓＣｏｍｐｒｅｓｓｏｒの圧縮率の一例を示す表である。 ＬＲＴ＿Ａ集合について発見された規則を用いてＬＲＴ＿Ｂ集合を圧縮した場合のＳｔａｔｓＣｏｍｐｒｅｓｓｏｒの圧縮率の一例を示す表である。 所定の最小有意性を有する規則の割合を変化させた場合のＳｔａｔｓＣｏｍｐｒｅｓｓｏｒの平均圧縮率の差の一例を示す表である。 既にＬＲＴ＿Ａ集合の圧縮に使用した規則のみでＬＲＴ＿Ｂ集合を圧縮した場合のＳｔａｔｓＣｏｍｐｒｅｓｓｏｒの圧縮率の一例を示す表である。 顧客のサイトでＳｔａｔｓＭｉｎｅｒとＳｔａｔｓＣｏｍｐｒｅｓｓｏｒの両方を実行した際の結果を示す表である。 ＣＬ＿２集合に対して設計したソリューションを異なるモデルで実行した場合のＳｔａｔｓＣｏｍｐｒｅｓｓｏｒの平均圧縮率の一例を示す表である。 ＣＬ＿２集合に対して設計したソリューションを異なるモデルで実行した場合の結果の標準偏差の一例を示す表である。
＜実施形態１＞
本発明の第１の実施形態では、ストレージシステム２上で動作する各ソフトウェアユニットの動作状況やハードウェアリソースなどを所定の間隔で採取することで生成される統計値（データ、データ群）を、当該統計値の相関関係を利用して圧縮するデータ圧縮システム１（データ圧縮システム）について説明する。
図１を参照すると、本実施形態におけるデータ圧縮システム１は、ストレージシステム２と、統計値マイニング装置３（データ圧縮用相関関係抽出装置）と、統計値圧縮装置４と、を有している。また、ストレージシステム２と統計値マイニング装置３と統計値圧縮装置４とはネットワークを介して互いに通信可能なよう接続されている。そして、ストレージシステム２と統計値圧縮装置４とは、互いに通信可能なよう接続されている。
ストレージシステム２は、複数のサーバコンピュータが接続された構成を採っている。図２を参照すると、ストレージシステム２は、アクセラレータノード２１（２１ａ、２１ｂ、…。以下、特に区別しない場合はアクセラレータノード２１とする）と、ストレージノード２２（２２ａ、２２ｂ、…。以下、特に区別しない場合はストレージノード２２とする）と、を有している。また、ストレージノード２２は、すべてネットワークを介して接続されている。一方で、アクセラレータノード２１は、全てのストレージノード２２と接続されているが、アクセラレータノード２１間での接続はない。また、アクセラレータノード２１は、顧客のサーバや統計値マイニング装置３、統計値圧縮装置４に接続されている。
アクセラレータノード２１は、ストレージシステム２自体における記憶再生動作を制御するサーバコンピュータである。アクセラレータノード２１は、ストレージシステム２へのゲートウェイとして機能しており、データアクセスＡＰＩを提供する機能を有している。
ストレージノード２２は、データを格納する記憶装置を備えたサーバコンピュータである。ストレージノード２２は、アクセラレータノード２１を介して取得したデータを保持することになる。
なお、ストレージシステム２は、アクセラレータノード２１の代わりに、アクセラレータノード２１としての特徴とストレージノード２２としての特徴とを組み合わせたハイブリッドノードを有していても構わない。
また、アクセラレータノード２１の数と、ストレージノード２２の数とは、図２で示したものに限定されない。ストレージシステム２は、図２で示すよりも多くのアクセラレータノード２１、ストレージノード２２により構成されていても構わないし、少ないアクセラレータノード２１、ストレージノード２２により構成されていても構わない。
本実施形態におけるストレージシステム２は、上記のように、アクセラレータノード２１と、ストレージノード２２と、を有している。そして、アクセラレータノード２１及びストレージノード２２の両方のサーバで実行されるプロセスは、様々な統計値を収集している。具体的には、例えば、上記各サーバ上で動作する複数のソフトウェアユニットのそれぞれが統計値を収集する。ここで、本実施形態のストレージシステム２のようなシステムでは、各ユニット間で情報の送受信を行っている場合など、複数のユニットで同じような統計値が出現することがある。つまり、各ユニットは互いに協調して動作するため、あるユニットが収集した統計値と別のあるユニットが収取した統計値との間には相関関係がある場合がある。本実施形態におけるデータ圧縮システム１は、このような相関関係を利用して統計値を圧縮することになる。
なお、上記のように、アクセラレータノード２１の動作とストレージノード２２の動作とは異なる。そのため、アクセラレータノード２１で収集される統計値とストレージノード２２で収集される統計値とは必ずしも同じものではない。そこで、以下においては、ストレージノード２２から収集された統計値を圧縮する場合について説明する。
この場合、ストレージシステム２は、アクセラレータノード２１を介して、各ストレージノード２２から収集した統計値を統計値マイニング装置３へと送信することになる。
なお、データ圧縮システム１が圧縮する対象は、ストレージノード２２から収集した統計値に限定されない。データ圧縮システム１は、アクセラレータノード２１から収集した統計値を圧縮するよう構成されていても構わないし、アクセラレータノード２１及びストレージノード２２から収集した統計値の両方を圧縮するように構成されていても構わない。
また、本実施形態におけるストレージシステム２は、ノード毎に統計値を収集して統計値マイニング装置３へと送信するよう構成されている。つまり、統計値マイニング装置３へと送信される統計値を含む１つのファイルには、１つのストレージノード２２上の各ユニットが収集した統計値が含まれていることになる。しかしながら、本発明を実施する場合には、必ずしも上記のように構成されていなくても構わない。つまり、統計値マイニング装置３へと送信する統計値を含む１つのファイルには、複数のノード上の各ユニットが収集した統計値が含まれていても構わない。
統計値マイニング装置３は、ストレージシステム２から送信される統計値の集まりをマイニングして、異なる統計値の間の相関関係や１つの統計値の内的相関などの所定の相関関係（数的相関など）を探索する情報処理装置である。統計値マイニング装置３は、図示しない中央演算装置（ＣＰＵ、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、記憶装置（メモリ及びハードディスク）と、を備えている。統計値マイニング装置３は、記憶装置が備えるプログラムをＣＰＵが実行することで、後述する機能を実現するように構成されている。
図３を参照すると、統計値マイニング装置３は、データ送受信手段３１と、統計値データベース３２と、ウィンドウ生成手段３３（相関関係抽出手段と相関関係検証手段の一部でも構わない）と、相関関係抽出手段３４と、相関関係検証手段３５と、規則ファイル３６と、を有している。
データ送受信手段３１は、ストレージシステム２や統計値圧縮装置４と統計値や後述する規則の送受信を行う機能を有している。データ送受信手段３１は、例えば、ストレージシステム２（統計値圧縮装置４を介していても構わない）から、当該ストレージシステム２の各ストレージノード２２から収集された統計値（を含むファイル）を受信する。そして、データ送受信手段３１は、受信した統計値を統計値データベース３２に記憶する。また、データ送受信手段３１は、例えば、後述する規則ファイル３６が記憶する規則（検証された規則）を統計値圧縮装置４へと送信する。データ送受信手段３１による規則の送信は、例えば、予め定められた周期が経過する毎に行われる。
統計値データベース３２は、メモリやハードディスクなどの記憶装置である。統計値データベース３２は、データ送受信手段３１が受信した統計値を記憶している。そのため、統計値データベース３２は、様々な異なる種類の統計値をファイルごと（ノードごと）に記憶していることになる。なお、統計値データベース３２は、複数のファイルを一つにまとめて記憶しても構わない。
図４は、統計値データベース３２が記憶する統計値の一例である。図４を参照すると、統計値データベース３２は、例えば１つのファイル内に、ユニットＡが収集した統計値Ａ、統計値Ｂ、統計値Ｃ、統計値Ｄと、ユニットＢが収集した統計値Ｅ、統計値Ｆ、統計値Ｇと、を記憶している。このように、統計値データベース３２は、複数のユニットが収集した統計値を１つのファイル内に記憶している。
また、統計値データベース３２は、例えば統計値Ａのサンプル（データの値）として、１０、２０、１０、１５、１２、１３、１４、１６、１５、１４、を記憶している。一方で、統計値データベース３２は、例えば統計値Ｅのサンプルとして、６、１６、１１、１２、１３、１４、１５、１５、１５、１０、１０、１２、１４、１６、２、１、３１、を記憶している。つまり、統計値データベース３２は、統計値Ａとして１０個のサンプルを記憶する（統計値Ａは１０個のサンプルを有するデータ群である）一方で、統計値Ｅとして１７個のサンプルを記憶している（統計値Ｅは１７個のサンプルを有するデータ群である）。このように、統計値データベース３２が記憶する各統計値のサンプルの数は、統計値ごとに異なっていても構わない。
ウィンドウ生成手段３３は、統計値データベース３２が記憶する統計値（を含むファイル）から相関関係を探索する対象となる範囲であるウィンドウ（局所化探索範囲）を生成する機能を有している。ここで、ウィンドウとは、すべての利用可能な統計値のサンプルの、一連の比較可能な同じ長さのシーケンスのことである。つまり、ウィンドウとは、各統計値に同数のサンプルがあるよう（データ群を構成するデータの値の個数がそれぞれ同数になるよう）に、相関関係の探索範囲を局所化したものである。そのため、ウィンドウの長さはそれぞれの統計値で同一のサンプルの数（例えば、１０〜２０。予め定められた数になる）であり、ウィンドウの幅は統計値の種類の数になることになる。なお、ウィンドウは、各サンプルを収集した時間に関する情報を含んでいても構わないし、含んでいなくても構わない。
ウィンドウ生成手段３３は、例えば、図４で示す統計値を用いて、図５で示すウィンドウを生成する。図５を参照すると、ウィンドウ生成手段３３は、図４で示す統計値を用いて、例えば長さ１０で幅７のウィンドウを生成する。つまり、ウィンドウ生成手段３３は、例えば、７種類の統計値のそれぞれが１０個のサンプルを含むウィンドウを生成する。このように、ウィンドウ生成手段３３は、１つのファイルを複数のウィンドウに分割することが出来る。そして、ウィンドウ生成手段３３は、生成したウィンドウを相関関係抽出手段３４と相関関係検証手段３５へと送信する。
なお、ウィンドウ生成手段３３は、例えば、各統計値を入手順に所定の数取得することで、ウィンドウを生成する。つまり、ウィンドウ生成手段３３は、各統計値のサンプルのタイムスタンプを全く考慮せず、統計値データベース３２に記憶されている順番に各統計値のサンプルを取得してウィンドウを生成する。このような方法によりウィンドウを生成することが考えられる。また、ウィンドウ生成手段３３は、例えば、タイムスタンプを考慮してウィンドウを生成しても構わない。このように、ウィンドウ生成手段３３は様々な方法を用いて統計値データベース３２が記憶する統計値を用いてウィンドウを生成することが出来る。
また、ウィンドウ生成手段３３は、過去に生成したウィンドウを再利用することが出来るように構成することが出来る。つまり、ウィンドウ生成手段３３は、過去に生成した複数のウィンドウからランダムに統計値（サンプルの列）を取得し、当該取得したサンプルの列を用いて新しいウィンドウを生成するように構成することが出来る。さらに、ウィンドウ生成手段３３は、統計値の種類の数を制限したウィンドウを生成するように構成することも出来る。
相関関係抽出手段３４は、ウィンドウ生成手段３３が生成したウィンドウ内の各統計値の関係に基づいた相関関係を抽出する機能を有する。また、相関関係抽出手段３４は、各統計値から相関関係を抽出する際に、様々なヒューリスティックな手法を用いるように構成することが出来る。
具体的には、本実施形態における相関関係抽出手段３４は、ウィンドウ内の各統計値のサンプルから定数の相関と同一性の相関と和の相関とを抽出する。また、相関関係抽出手段３４は、定数の相関と同一性の相関を探索した際にヒューリスティックな手法を実行する。
以下、図５で示すウィンドウの一例を用いて、相関関係抽出手段３４が相関関係を抽出する際の動作の一例を説明する。
まず、相関関係抽出手段３４は、定数の相関を抽出する。図６を参照すると、統計値Ｇの各サンプルは全て７である。つまり、統計値Ｇは定数であると考えられる。そこで、相関関係抽出手段３４は、統計値Ｇに定数の相関を発見する（統計値Ｇ＝定数の規則があることを発見する）。また、相関関係抽出手段３４は、ヒューリスティックな手法の一つとして、当該発見した定数の相関を有する統計値Ｇをウィンドウから除去する。つまり、相関関係抽出手段３４は、予め定められた種類の相関関係として定数の相関を見つけた場合、当該定数の相関を有する統計値をウィンドウから除去する。これにより、ウィンドウ内には統計値Ａから統計値Ｆの６つの統計値が残ることになる。
次に、相関関係抽出手段３４は、同一性の相関を抽出する。具体的には、相関関係抽出手段３４は、例えば、図７で示すような方法を用いて同一性の相関を抽出する。図７を参照すると、相関関係抽出手段３４は、まず、ウィンドウ内の各統計値のサンプルの列を辞書的な順番に並び替える。つまり、相関関係抽出手段３４は、ウィンドウの左に位置するサンプルの数から順番にみて、より小さな数を持つ統計値がより上に来るように各統計値のサンプルの列を並び替える。そして、相関関係抽出手段３４は、ある統計値のサンプルの列と一つ下に位置する統計値のサンプルの列とを比較することで、予め定められた基準に基づいて同一であると判断される統計値の組を発見する。ここで、同一であると判断される予め定められた基準とは、例えば、統計値を構成する各サンプルと別の統計値を構成する各サンプルとが完全に同一である場合を指す。また、同一であると判断される予め定められた基準としては、例えば、ある統計値のサンプルの列と別の統計値のサンプルの列の隣り合うサンプルの有限差分とが等しい場合を含むことが出来る。例えば、図７で示すように、統計値Ａと統計値Ｂとは各サンプルの値が全て等しい。そのため、相関関係抽出手段３４は、統計値Ａと統計値Ｂとに同一性の相関があると判断する（統計値Ａ＝統計値Ｂの規則があることを発見する）。また、例えば、図７で示すように、統計値Ｂ又はＡの各サンプルの値と統計値Ｃの有限差分であるｄ統計値Ｃの値は等しい。そこで、相関関係抽出手段３４は、統計値Ｂ又はＡとｄ統計値Ｃとの間に同一性の相関があると判断する（統計値Ｂ＝ｄ統計値Ｃ、統計値Ａ＝ｄ統計値Ｃの規則があることを発見する）。
上記のような処理により、相関関係抽出手段３４は、同一性の相関を抽出する。その後、相関関係抽出手段３４は、ヒューリスティックな手法の一つとして、ウィンドウ内に抽象クラスの代表値のみを残す処理をする。例えば、図７で示す場合においては、上記のように、統計値Ａと統計値Ｂの値は等しいことになる。そこで、相関関係抽出手段３４は、統計値Ａ又は統計値Ｂのいずか一方のサンプルを消去する。これにより、ウィンドウ内には統計値Ａ又は統計値Ｂのいずか一方のサンプルのみが残ることになる。
その後、相関関係抽出手段３４は、和の相関を抽出する。具体的には、相関関係抽出手段３４は、２つの統計値ごとにサンプルを合計して、その結果が既存の統計値のサンプルと等しいかどうかを確認する（３つ以上の和を確認するように構成しても構わない）。また、相関関係抽出手段３４は、和の相関を探索する際に、各統計値のサンプルの有限差分を用いることも出来る。例えば、図８を参照すると、統計値Ｄは統計値Ｅと統計値Ｆの有限差分であるｄ統計値Ｆとの和であることが分かる。そこで、相関関係抽出手段３４は、統計値Ｄと統計値Ｅとｄ統計値Ｆとの間に和の相関関係があることを発見する（統計値Ｄ＝統計値Ｅ＋ｄ統計値Ｆの規則があることを発見する）。
このような方法により、相関関係抽出手段３４は、ウィンドウ生成手段３３が生成したウィンドウ内の各統計値のサンプルから相関関係を抽出する。そして、相関関係抽出手段３４は、抽出した相関関係を説明する規則（検証前の規則）を相関関係検証手段３５に送信する。相関関係抽出手段３４は、例えば、統計値Ｇ＝定数、統計値Ａ＝統計値Ｂ、統計値Ｂ＝ｄ統計値Ｃ、統計値Ａ＝ｄ統計値Ｃ、統計値Ｄ＝統計値Ｅ＋ｄ統計値Ｆ、という検証前の規則を相関関係検証手段３５に送信する。
なお、相関関係抽出手段３４は、抽出した相関関係を説明する規則（検証前の規則）を相関関係検証手段３５に送信する代わりに規則ファイル３６に記憶するように構成しても構わない。
また、相関関係抽出手段３４が相関関係を抽出する方法は、上述した場合に限定されない。相関関係抽出手段３４は、例えば、予め定められた相関関係を満たすサンプルがウィンドウ内に存在するか探索することで相関関係を抽出するように構成することが出来る。また、相関関係抽出手段３４が抽出する相関関係も、上述した場合に限定されない。相関関係抽出手段３４は、例えば、統計値間の線形結合や回帰に基づく規則を抽出するように構成することが出来る。
相関関係検証手段３５は、相関関係抽出手段３４から受信した検証前の規則（若しくは、規則ファイル３６が記憶する規則）を各ウィンドウに適用することで、当該検証前の規則が各ウィンドウに適用可能であるか否かを検証する機能を有している。
具体的には、相関関係検証手段３５は、図９（Ａ）（Ｂ）で示すように、相関関係抽出手段３４から受信した検証前の規則（若しくは、規則ファイル３６が記憶する規則）をウィンドウ生成手段３３が生成した各ウィンドウに適用することで、当該規則の有意性を検証する。例えば、相関関係検証手段３５は、各ウィンドウに規則が適用できるか否かをそれぞれ検証し、適用に成功したウィンドウの数を計測する。そして、相関関係検証手段３５は、適用に成功したウィンドウの数に基づいて、規則の有意性を算出する。例えば、相関関係検証手段３５は、適用に成功したウィンドウの数を対象となる全てのウィンドウの数で除算することで有意性を算出する。
そして、相関関係検証手段３５は、検証済みの規則を規則ファイル３６に記憶する。
なお、このようにして算出された有意性は、例えば、相関関係検証手段３５が検証済みの規則を規則ファイル３６に記憶する際に用いることが出来る。つまり、相関関係検証手段３５は、予め定められた記憶用閾値を超える有意性を備える検証済みの規則のみを規則ファイル３６に記憶するように構成することが出来る。また、有意性は、例えば、データ送受信手段３１が規則を統計値圧縮装置４に送信する際に用いることが出来る。つまり、データ送受信手段３１は、予め定められた送信用閾値を超える有意性を備える規則のみを統計値圧縮装置４に送信するように構成することが出来る。
規則ファイル３６は、メモリやハードディスクなどの記憶装置である。規則ファイル３６は、相関関係検証手段３５から送信された検証済みの規則を記憶するよう構成されている。具体的には、規則ファイル３６は、相関関係検証手段３５から検証済みの規則を受信する。そして、規則ファイル３６は、当該受信した検証済みの規則を記憶する。また、規則ファイル３６が記憶する検証済みの規則は、データ送受信手段３１を介して統計値圧縮装置４へと送信されることになる。なお、規則ファイル３６は、検証前の規則（相関関係抽出手段３４から送信された規則）も記憶するように構成することが出来る。
図１０は、規則ファイル３６が記憶する検証された規則の記憶方法の一例である。規則ファイル３６は、例えば、図１０（Ａ）で示すように、組み合わせによるアプローチとして、各規則の組み合わせを網羅的に記憶する（相関関係を満たすデータを網羅的に列挙する）構成することが出来る。また、規則ファイル３６は、例えば、１０（Ｂ）で示すように、抽象クラスに基づくアプローチとして、抽象的な概念として規則を記憶するように構成することが出来る。また、規則ファイル３６は、例えば、図１０（Ｃ）で示すように、相関関係を示す一般的な規則とその例外との組み合わせであるツリー型の方法で規則を記憶するように構成しても構わない。規則ファイル３６は、上記説明した３つ以外の方法を用いて規則を記憶するように構成しても構わない。
統計値圧縮装置４は、統計値マイニング装置３が発見して検証した規則を用いて統計値を圧縮する情報処理装置である。統計値圧縮装置４は、図示しない中央演算装置（ＣＰＵ、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、記憶装置（メモリ及びハードディスク）と、を備えている。統計値圧縮装置４は、記憶装置が備えるプログラムをＣＰＵが実行することで、後述する機能を実現するように構成されている。
図１１を参照すると、統計値圧縮装置４は、データ送受信手段４１と、統計値ファイル４２と、検証された規則ファイル４３と、統計値圧縮手段４４と、を有している。
データ送受信手段４１は、ストレージシステム２や統計値マイニング装置３と統計値や検証された規則の送受信を行う機能を有している。データ送受信手段４１は、例えば、ストレージシステム２が送信する統計値（を含むファイル）を受信する。そして、データ送受信手段４１は、受信した統計値を統計値ファイル４２に記憶する。また、データ送受信手段４１は、例えば、統計値マイニング装置３が送信する検証された規則を受信する。そして、データ送受信手段４１は、当該受信した検証された規則を規則ファイル４３に記憶する。
統計値ファイル４２は、メモリやハードディスクなどの記憶装置である。統計値ファイル４２は、ストレージシステム２から送信された（データ送受信手段４１が受信した）統計値を記憶する。統計値ファイル４２が記憶する統計値は、後述するように、統計値圧縮手段４４により、統計値マイニング装置３が発見した規則を用いて圧縮されることになる。
検証された規則ファイル４３は、メモリやハードディスクなどの記憶装置である。検証された規則ファイル４３は、データ送受信手段４１が受信した検証された規則を記憶している。検証された規則ファイル４３が記憶する検証された規則は、後述するように、統計値圧縮手段４４がデータの圧縮を行う際に用いられることになる。
統計値圧縮手段４４は、規則ファイル４３が記憶する検証された規則を用いて統計値ファイル４２が記憶する統計値を圧縮する機能を有する。統計値圧縮手段４４は、規則ファイル４３から規則を取得する。また、統計値圧縮手段４４は、統計値ファイル４２から統計値を取得する。そして、統計値圧縮手段４４は、規則ファイル４３から取得した規則を用いて、統計値ファイル４２から取得した統計値を圧縮する。その後、統計値圧縮手段４４は、例えば図示しない圧縮後統計値記憶部に、圧縮した統計値を記憶する。
なお、統計値圧縮手段４４は、上記のように検証された規則を用いて統計値を圧縮した後に、外部の一般的な圧縮装置を用いて再度圧縮処理を行うように構成することが出来る。
また、統計値圧縮手段４４は、定数の相関などの簡易な相関を自身で発見するように構成することが出来る。この場合には、統計値圧縮手段４４は、自身が発見した相関を用いて圧縮を行うよう構成することが出来る。
また、統計値圧縮手段４４は、予め定められた基準に従って圧縮を行う際に使用する検証された規則を選別するように構成することが出来る。統計値圧縮手段４４は、抽象クラスの平坦化や統計値によって使用される識別子を交換するリナンバリングを行うように構成されていても構わない。
以上が、データ圧縮システム１の構成についての説明である。次に、データ圧縮システム１の動作について説明する。最初に、図１２を参照して統計値マイニング装置３の動作の一例について説明する。
図１２を参照すると、まず、データ送受信手段３１がストレージシステム２内の各ストレージノード２２が収集した統計値を取得する（ステップＳ１０１）。すると、データ送受信手段３１は、当該取得した統計値を統計値データベース３２に記憶する。
次に、ウィンドウ生成手段３３は、統計値データベース３２が記憶する統計値を用いてウィンドウを生成する（ステップＳ１０２）。なお、ウィンドウ生成手段３３は、過去に自身が生成した複数のウィンドウから統計値を抜き出すことで新たなウィンドウを生成しても構わない。このようにして、ウィンドウ生成手段３３は、複数のウィンドウを生成する。
続いて、相関関係抽出手段３４がウィンドウ内の相関関係を抽出する（ステップＳ１０３）。これにより、相関関係抽出手段３４は、相関関係を説明する規則（検証前の規則）を取得する。そして、相関関係抽出手段３４は、検証前の規則を相関関係検証手段３５へと送信する。
その後、相関関係検証手段３５は、ウィンドウ生成手段３３が生成した各ウィンドウに、相関関係抽出手段から受信した検証前の規則が適用可能であるか検証する（ステップＳ１０４）。例えば、相関関係検証手段３５は、検証前の規則が適用可能なウィンドウの数を計測する。そして、相関関係検証手段３５は、計測した規則が適用可能なウィンドウの数に基づいて規則の有意性を算出する。また、相関関係検証手段３５は、検証された規則を規則ファイル３６へと記憶する（ステップＳ１０５）。その後、規則ファイル３６が記憶する検証された規則は、例えば予め定められた周期が経過する毎にデータ送受信手段３１を介して統計値圧縮装置４へと送信されることになる。
以上が、統計値マイニング装置３の動作の一例である。次に、相関関係抽出手段３４により行われる相関関係の抽出の一例について、図１３を参照してより詳細に説明する。
図１３を参照すると、相関関係抽出手段３４は、まず、定数の相関関係を抽出する（ステップＳ２０１）。具体的には、相関関係抽出手段３４は、各サンプルの値が一定である統計値を定数の相関関係があるとして抽出する。その後、相関関係抽出手段３４は、定数の相関関係を有する統計値を、相関関係を抽出する対象となるウィンドウ内から除去する（ステップＳ２０２）。
次に、相関関係抽出手段３４は、同一性の相関関係を抽出する（ステップＳ２０３）。具体的には、相関関係抽出手段３４は、ウィンドウ内の各統計値を辞書的な順番で並び替えた後に隣り合う統計値の各サンプルを比較することで、予め定められた基準に基づいて同一であると判断される統計値の組を抽出する。その後、相関関係抽出手段３４は、ウィンドウ内に各抽象クラスの代表値を１つだけ残す処理を行う（ステップＳ２０４）。つまり、例えば、Ａ＝Ｂの相関関係が抽出された場合には、相関関係抽出手段３４は、Ａ又はＢのいずれか一方のサンプルの値をウィンドウから排除する。これにより、ウィンドウ内には、Ａ又はＢのいずれか一方のサンプルのみが残ることになる。
その後、相関関係抽出手段３４は、和の相関関係を抽出する（ステップＳ２０５）。具体的には、相関関係抽出手段３４は、２つの統計値ごとにサンプルを合計して、その結果が既存の統計値のサンプルと等しいかどうかを確認する。また、相関関係抽出手段３４は、和の相関を探索する際に、各統計値のサンプルの有限差分を用いる。これにより、相関関係抽出手段３４は、和の相関関係を有する統計値の組み合わせを抽出することになる。
以上が、相関関係抽出手段３４の動作の一例である。次に、統計値圧縮装置４により行われる統計値の圧縮処理の一例について、図１４を参照して説明する。
図１４を参照すると、統計値圧縮装置４のデータ送受信手段４１は、例えば定期的に（又は必要に応じて）、ストレージシステム２から統計値を取得する（ステップＳ３０１）。そして、データ送受信手段４１は、取得した統計値を統計値ファイル４２に記憶する。
また、統計値圧縮装置４のデータ送受信手段４１は、統計値マイニング装置３から、例えば定期的に、検証された規則を取得する（ステップＳ３０２）。そして、データ送受信手段４１は、取得した検証された規則を検証された規則ファイル４３に記憶する。
上記２つの動作により、統計値ファイル４２には統計値が記憶され、検証された規則ファイルには検証された規則が記憶されていることになる。そこで、統計値圧縮手段４４は、検証された規則ファイル４３が記憶する検証された規則を用いて統計値ファイル４２が記憶する統計値の圧縮処理を行う（ステップＳ３０３）。
以上が、統計値圧縮装置４により行われる統計値の圧縮処理の一例である。
このように、本実施形態におけるデータ圧縮システム１は、相関関係抽出手段３４を備える統計値マイニング装置３と、統計値圧縮装置４と、を備えている。このような構成により、データ圧縮システム１は、相関関係抽出手段３４が抽出した相関関係に基づいて統計値の圧縮処理を行うことが出来るようになる。一般に、各ソフトウェアユニットは互いに協調して動作している。そのため、各ソフトウェアユニットが取得する統計値には、相関関係がある場合が少なくない。従って、このような相関関係を利用して統計値を圧縮することで、高い信頼性を維持しつつより効率的に統計値の圧縮を行うことが出来るようになる。
また、本実施形態における統計値マイニング装置３は、ウィンドウ生成手段３３を有している。このような構成により、ウィンドウ生成手段３３が生成したウィンドウ内で相関関係を抽出することが出来るようになる。一般に、相関関係を抽出する各統計値のサンプルの数は必ずしも同数ではない。そのため、相関関係を抽出する際には、異なるサンプルの数の統計値間の相関関係を抽出することが必要になり、そのアルゴリズムは複雑なものになる。一方で、ウィンドウを用いることで、各統計値に同数のサンプルを有する状態で相関関係を抽出することが出来るようになる。その結果、相関関係を抽出する際のアルゴリズムを簡素化することが出来るようになる。また、結果を比較する際に明確な基準を持つことが出来るようになる。
また、本実施形態における統計値マイニング装置３は、相関関係抽出手段３４と、相関関係検証手段３５と、を有している。このような構成により、相関関係抽出手段３４による相関関係の抽出作業と相関関係検証手段３５による検証作業とを分けることが出来るようになる。その結果、計算の並列化をより効率的に行うことが出来るようになる。
また、本実施形態における相関関係抽出手段３４は、幾つかのヒューリスティックな方法を用いることが出来るよう構成されている。具体的には、相関関係抽出手段３４は、定数の相関関係を抽出した後に、当該定数の相関関係を有する統計値をウィンドウ上から除去するように構成されている。また、相関関係抽出手段３４は、同一性の相関関係を抽出した後に、各抽象クラスの代表値のみをウィンドウ内に残すように構成されている。このような構成により、定数の相関関係を有する統計値を除去したウィンドウ内で同一性の抽出作業を行うことが出来るようになる。また、定数の相関関係を有する統計値を除去し、抽象クラスの代表値以外の統計値も除去したウィンドウ内で和の相関関係を抽出することが出来るようになる。一般に、定数の相関関係を抽出する作業は、同一性の相関関係を抽出する作業よりも軽い作業である。また、同一性の相関関係を抽出する作業は、和の相関関係を抽出する作業よりも軽い作業である。そのため、上記のようなヒューリスティックな方法を用いることで、軽い相関が重い相関を隠すことが出来るようになる。
なお、本実施形態においては、ストレージシステム２が収集する統計値を圧縮する場合について説明した。しかしながら、本発明は、ストレージシステム２が収集した統計値を圧縮する場合に限定されず実施可能である。本発明は、例えば、グリッドサーバ間で収集する統計値を圧縮するような場合に適用しても構わない。
また、データ圧縮システム１が圧縮する対象は、必ずしも統計値に限定されない。データ圧縮システム１は、相関関係を有する様々なデータを圧縮する際に用いることが可能である。
また、本実施形態では、統計値マイニング装置３と統計値圧縮装置４とは異なる情報処理装置であるとした。しかしながら、本発明の実施は、上記場合に限定されない。本発明は、統計値マイニング処理部と統計値圧縮処理部とを備える情報処理装置により実施されても構わない。また、本発明は、ストレージシステム２上で実施されても構わない。
＜実施形態２＞
本発明の第２の実施形態を、以下の論文形式にて説明する。
第１章 序章
分散システムは、現在広く利用されるようになっている。その複雑さゆえにオンラインでの監視が難しいため、遅延型の調査のためのシステムの状態を収集する方法が開発されている。大量のデータを入手することがきわめて重要であることから、圧縮アルゴリズムが開発されている。本論文では、商用の二次記憶分散システムであるNECのHYDRAstorによって生成された統計値の圧縮のための、新たなアプローチを提示し、これを評価する。統計値は、HYDRAstorに組み込まれた数千の測定基準の、頻繁に探索される値であり、システムの現状を表すことを目的としている。
統計値の圧縮を改善する必要性が、実際の使用から出現した。顧客のデータセンターで動作しているHYDRAstorに関する問題を調査するには、統計値を取得する必要がある。しかし、セキュリティ上の問題から、ダウンロードできるデータ量を著しく制限している機関もある。当然ながら、統計値のサンプル量が少なければ、そのシステムにおける問題の分析に費やす時間と努力は劇的に増える。そのため、渡されるパッケージのサイズを大きくすることなく、顧客から入手する統計値のサンプルの数を大きくする必要がある。一方で、ここで提案するソリューションは、無損失でなければならない。なぜなら、解凍後のサンプル値にゆがみがあれば、その統計値の分析から得られる結論が誤ったものになる恐れがあるからだ。
この論文の目的は、効率的で無損失な統計値の圧縮方法であり、NECのHYDRAstorシステムと密接に協働するように調整された圧縮方法を提供することである。提案するソリューションは実装されているため、この作成されたソフトウェアについて、達成可能な圧縮率とパフォーマンスを測定するための様々な実験が行われた。この論文で述べるソリューションは、ダウンロードするデータを増やすことなく、エンジニアが顧客の施設から統計値のサンプルをより多く取得できるようにすることをサポートすることができる。その結果、HYDRAstorの状態の調査がよりシンプルになるため、HYDRAstorのサービス品質が向上する。
この論文は、次の６つの章から構成される。
２．「背景」では、NECのHYDRAstorについて簡単に説明する。これは、ソリューションを作成する上での決定を理解するために重要である。
３．「相関に基づく圧縮の分散モデル」では、提案するソリューションの概念について述べる。
４．「相関マイナー」では、StatsMinerという、実装した２つのツールのうちの１つ目について説明し、評価する。人為的なデータと顧客から受け取ったデータの両方について、評価を行う。
５．「コンプレッサ」では、StatsCompressorという、２つ目の実装したツールについて説明する。この章では人為的なデータに対するツールの評価を行い、StatsMinerとStatsCompressorとの協働に関するいくつかのモデルについて述べる。
６．「顧客から取得した実際の統計値での評価」では、顧客から受け取った統計値に対する、実装したソフトウェアとその使用に関する様々なモデルの評価を行う。
７．「関連研究」では、この論文に関連する分野で実施された、他の研究について概説する。それに基づいて、将来の研究についての提案も行う。
第２章 背景
本論文で解決を試みる問題は、NECのHYDRAstorシステムを使用する中で出現したものであるため、その解決策はHYDRAstorの具体的な要件に対応しなければならない。そのため、開発するソリューションに対して課されるこのシステムの制約について、簡単に説明する必要がある。HYDRAstorの包括的な仕様は[DGH＋09]に記載されている。
本章は、次の３つのセクションから構成される。
2.1 「HYDRAstorの概要」では、HYDRAstorシステムを説明する。後の章で使用する様々な重要な用語について、ここで定義する。
2.2 「システムの監視」では、HYDRAstorの観点を含む、ログの収集と分析の問題について述べる。このセクションでは、この論文で述べる研究が重要である大まかな理由についても説明する。
2.3 「HYDRAstorでの統計値の収集」では、HYDRAstorシステムでの統計値の収集プロセスの技術的な詳細と、統計値の記憶に使用するファイルのフォーマットについて述べる。なぜなら、ここで説明するソリューションは、フレームワークに適合したものでなければならないからだ。
2.1. HYDRAstorの概要
NECが提供するHYDRAstorは、企業レベルの、拡張性を持つ２次記憶システムであり、テープドライブではなくハードドライブを使用する。バックアップデータの書込みを、高スループットかつ少ない待ち時間でサポートするものであり、これはこの種のソフトウェアにとっては極めて重要な要件である。バックアップオペレーションは、バックアップされるシステムの効率を劇的に低下させることがあるため、バックアップウィンドウは常に非常に限られた長さしかないからだ。これが、本論文で述べるソリューションの主な制約である。つまり、HYDRAstorと併せて動作するソフトウェアは、書込みパフォーマンスに悪影響を与えてはならない。
書込みはHYDRAstorで行われる主なオペレーションであるため、少し詳しく説明する。バックアップデータのバイト列は、多様なサイズの不変のチャンクに分割されてこのシステムに入力される。システム内に、すでにチャンクが存在する場合は、チャンクのコンテンツハッシュを使用して発見することができ、そのチャンクは二度書き込まれることはない。このプロセスをインライン重複排除といい、このコンセプトの使用はHYDRAstorのパフォーマンスにとって極めて重要である。チャンクを記憶する必要がある場合、どこに入れるかという判断が行われる。HYDRAstorは、サーバ群から構成されるフォールト・トレラント分散システムである。サーバまたはディスクに障害が発生した場合にデータの一貫性を保つため、各チャンクはリード・ソロモン符号が適用され、消去訂正符号化(erasure-coded)されている。コード化されたチャンクのSHA-1ハッシュと、Distributed Hash Table概念を用いて、チャンクの記憶場所が決定される。最後に、データは内部ネットワークによって、前のステップで選択された論理ノードに対応する物理ノードに転送される。
当然、HYDRAstorからデータを読み出すことも可能だが、このプロセスはあまり一般的ではなく書込みほど重要でもないため、このシステムは読出しよりも書込みについて最適化された。基本的に読出しは頻繁には行われない。
また、HYDRAstorからデータを削除することができる。高速かつ少ない待ち時間で書込みを行うためのトレードオフとして、削除のプロセスが非常に複雑であり、ガーベジコレクション機能として動作する。３つの段階に分かれており、各々がシステムに与える影響が異なる。まず、データをシステムから除去する命令を受けると、内部のメタデータのみが影響を受け、実際のデータはドライブ上に存在する。物理的に記憶されたどのチャンクを消去するのかを判断するために、削除という特別なプロセスが実行されなければならない。これは、いくつかのチャンクに「削除される」というマークを付けることを目的としている。削除は、複雑な分散アルゴリズムであり、ここでは説明を省略するが、参考文献[SAHI+13]に完全な説明が記載されている。しかし、削除に関して、統計値の圧縮を開発する上で考慮すべき事実がいくつかある。まず、削除は周期的に実行されるものであり、このツールはめったに使用されないほうが好ましい。つまり、このプロセスの統計値は長時間一定である。次に、動作中はかなりのリソースを消費するため、削除が行われている間は、HYDRAstorが違う動作をすることがある。削除は、書込みと同時に実行できる。前述のとおり、削除は物理的なチャンクに「使用しない」というマークを付けるだけである。ディスクのスペースを取り戻すためには、スペース再生プロセスを実行する必要がある。削除プロセスとは異なり、スペース再生はHYDRAstorにそれほど影響を与えることはなく、バックグラウンドタスクといわれる、適宜行われる多くのプロセスの１ついすぎない。
2.1.1. バージョン
HYDRAstorシステムには、Ｈ２、Ｈ３、Ｈ４、という３つの主なバージョンがある。Ｈ２が商用に使用される最も古いもので、Ｈ３は顧客に最も人気があり、Ｈ４は現在市場に導入されているものである。これらの番号はハードウェアとソフトウェアの両方を表している。なぜなら、HYDRAstorは、特別に設計されたサーバとインストールされた上記のソフトウェアから成る、完全なソリューションとして販売されているからだ。
当然、ＮＥＣはこの製品のパッチと更新を出している。このシステムは大企業でよく利用されているため（HYDRAstorの主要対象グループである）、パッチを適用するのは非常に難しく、時間のかかるプロセスである。すべてのメンテナンスを行える規模のサービス窓口が必要である。そのため、消費者は、本当に必要なパッチしかインストールしない。その結果、あらゆるバージョンのHYDRAstorに様々なサブバージョンが存在する。驚くことではないが、各バージョンはわずかに違う動作することがあるため、統計値の圧縮のために設計するソリューションも、それに応じて柔軟なものでなければならない。さらにHYDRAstorは、特定の顧客のニーズに応じたパフォーマンスの調整に使用する、様々な構成のパラメータがある。
相関に基づく統計値の圧縮は少なくともＨ４システムで使用されるが、以前のバージョンに簡単にポートできれば、必ずプラスになるであろう。
2.1.2. 物理的なアーキテクチャ
各HYDRAstorは、２つの異なるタスクを実行する２つの専用のサーバで構成される。このシステムの中心は、データを保持するストレージノード（Storage Nodes(ＳＮ)）である。ストレージノードはすべてネットワークを介して接続されている。もう１つのサーバは、HYDRAstorへのゲートウェイとして機能しデータアクセスＡＰＩを提供する、加速ノード（Acceleration Nodes(ＡＮ)）である。各ＡＮはすべてのＳＮと接続されているが、ＡＮ間にはリンクはない。ＡＮは顧客のサーバにも接続されている（ＳＮは接続されていない）。
ＡＮとＨＮの区別は、統計値の圧縮にとって重要である。なぜなら、両方のサーバで実行されているプロセスが統計値を収集するが、これらの統計値は同じではなく、ノードの動作も異なるからだ。Ｈ３バージョンでは、ＡＮとＨＮのプロセスは各々約５００００の統計値を有するが、ＡＮノード上で実行されるプロセスの統計値の方が定数を多く含んでいる。
Ｈ４バージョンでは、ＡＮのかわりに、旧ＡＮとＳＮの特徴を組み合わせたハイブリッドノード（Hybrid Nodes (ＨＮ)）がある。この構成では、旧ＡＮとＳＮからのプロセスは同じマシン上で同時に実行される。
本論文で述べるすべての実験を、ＳＮまたはＨＮノードから収集した統計値上で実行することに決定した（ＨＮの場合は、記憶プロセスからの統計値のみを考慮する）。これには技術的理由がいくつかある。またこのアプローチは、実験結果がより一貫性を持つ。ＡＮからのプロセスによって収集される統計値の圧縮率は、ＳＮから収集された統計値の圧縮率よりも、幾分良いものになると考えられる。
2.1.3. ソフトウェアのアーキテクチャ
単一ノードのアーキテクチャ
HYDRAstorは並列アプリケーションであり、メッセージ受け渡しコミュニケーションを多く利用する。ＯＯＳＦフレームワーク（オブジェクト指向のサーバ・フレームワーク）のおかげで、HYDRAstorの異なるサブシステム（ユニットという）間で互いにメッセージを交換する。さらに、ＯＯＳＦフレームワークは、自身のスレッドでユニットコードの実行スケジュールを立てる（これはユーザ・スペース・スレッドのアイデアを意味する）。特定のユニットに向けたメッセージがあると、このユニットはそれをキューに入れて、アイドルのスケジューラのスレッドがそれを実行するのを待つ。スケジューラは、いかなる形式のプリエンプション（preemption）も提供しないため、制御がスケジューラに戻ってくるまで、または走っているスレッドがメッセージを送るまで、コードは実行される。すぐにわかると思うが、スケジューラは、１つのコードの実行時間について何の制約も提供しない。ＯＯＳＦフレームワークの概念は、統計値の取集プロセスを説明する際に重要となる。
各ユニットは独自の特徴と、自身が生成する、一連の特定の統計値を有する。ここでは、この統計値の各々については説明しない。なぜならこれは非常に特殊なもので、また数が多すぎるからだ。一方、ある現象について述べておく。まず、ユニットは、受信および送信するメッセージ数を数えることがよくあるため、他のものの和と等しい何らかの統計値が存在すると思われる。次に、統計値の中には同一のものもある。例えば、２つのユニット間のみで特定のタイプのメッセージが送信されると、これらのメッセージは両ユニットで数えられる。また、あるメッセージが（数えられる）ある行動のトリガーとなる場合、または別の種類のメッセージを送信するトリガーとなる場合、同様の状況が発生する。この２つの例をもっと高い観点から見ると、もう１つの「社会学的な」同一性のソースが発見される。つまり、エンジニアリング的な理由により、同じことがいくつかの場所でカウントされる場合がある、ということだ。まず、同じことが２つの場所でカウントされると（つまり２つの名前を持つ）システムのメンテナンスにおいて、より便利になることがある。HYDRAstorはパフォーマンス・クリティカルなソフトウェアだが、メンテナンスが容易であることはさらに重要である。また、別箇のユニットの開発者は、同僚が同じイベントのログを取るコードを既に作成していること、場合によっては数年前に作成していることを、知らない場合がある。この原因は、チーム間のコミュニケーションが不足していること、または単に、コードのひとつひとつに関する非常に詳細な知識を交換しないという事実があること、が考えられる。このため、非常に大きなシステムでは、統計値またはログの繰り返しがあるという仮説が成り立つ。何らかの規則に基づいて、欠けているものを生成できるツールを作成すれば、統計値の繰り返しを簡単に削減できると思われる。唯一問題となるのは、この規則をどこから取得するかである。専門家の知識に基づく規則の作成はコストが高すぎる場合が多い。なぜなら、ソフトウェアのコードを読み出し、２つの統計値が常に同一なのか、それとも例外が存在するのかどうか、という判断をする作業が含まれるからだ。
分散システムの視点
前述したとおり、HYDRAstorは拡張性のある、フォールト・トレラント分散システムである。各物理ノードは「コンポーネント」と言われる複数の論理サーバのホストとなる。コンポーネントは、様々な状況において、あるノードから他のノードへと移動させることができる。例えば、故障したディスクが発見された場合、または拡張のためにシステムにリバランスが必要になった場合、などである。さらにコンポーネントの数は時がたてば変わる。データ量が増えると、パフォーマンスを向上させるためにコンポーネントの分割が必要になることがある。当然、コンポーネントの展開の変更はよくあることではないが、このようなイベントからの統計値は頻繁に分析される。なぜなら、これらの統計値は、システムのまれなケースを表しているからだ。各コンポーネントと結びついている統計値は複数あり、そのコンポーネントが実際に存在しているノード上で収集される。つまり、物理ノード間でコンポーネントの移動があると、古いノード上での収集が中止され、別のノード上で記録されるようになる統計値もある。
2.2. システムの監視
2.2.1. モチベーション
文献[OGX12]は、ログの収集に関する５つの理由を特定している。
１．デバッグ
２．パフォーマンス
３．セキュリティ
４．レポートとプロファイリング
５．予測
最初の２つの理由であるデバッグとパフォーマンスは、HYDRAstorにとって最も重要である。前述したとおり、この設計したソリューションは、バグが発生した場合の、またはパフォーマンスの改善を期待して、顧客のサイトでのHYDRAstorの設置に関するメンテナンスの品質を改善する必要がある。この目的を達成するために、特定のハードウェアまたはソフトウェアの構成およびシステムの現状に関する知識のソースとして、統計値が用いられることがよくある。この使用は、上記のリストの「レポートとプロファイリング」の項目をある程度活用している。しかし、[OGX12]の著者はさらに進めて、システムに関するレポートを半自動的に生成するための、人口知能（例えばクラスタリング・ツール）の使用について記載している。HYDRAstorのメンテナンスにこの種のツールは利用不能かどうか、特に、問題のある領域の予備的な視覚化を助けるものか、を検討することは合理的だと思われる。「予測」については、HYDRAstorは既に変則性検出ツールを備えている。システムの誤りを発見する、専門家の知識に基づく規則を利用している。上記リストの、まだ言及していない最後の項目は「セキュリティ」である。セキュリティの問題（潜入または侵入工作と認識されるもの）は、HYDRAstorには適用されない。なぜなら、このシステムは「極めて」バックエンドなソリューションであり、セキュリティについては、より高い層のソフトウェアで対処されている（特にソフトウェアが作成するバックアップ）。
2.2.2. ログと統計値
ここまでは「ログ」と「統計値」という用語は交換可能に用いられていたが、ここで明確に区別し、統計値がHYDRAstorで広範に使用される理由を説明する。
従来から、「ログ」は複数のラインで構成され、各々がタイムスタンプを有し、例えばメッセージの受信といったシステム内の単一のイベントを記述する。ログは一般的に極めて冗長で、プラスの面とマイナスの面の両方がある。単一のログメッセージは（一般的に）単一のイベントにマップされるため、ログに基づくデバッグは簡単である。なぜなら、そのイベントのすべての詳細を得られるからだ。同時に、大きなシステムでは膨大な量のログを収集するため、パフォーマンスに対して目に見える悪影響を及ぼす。さらに、特定の状況と結びついた一連のメッセージを得るために、膨大なフィルタリングと変換を行う必要がある。また、システムの行動の完全なイメージを得るには、ログからデータの解析と収集をしなければならず、さらに複雑である。
HYDRAstorで使用される意味において、統計値は周期的に収集されたサンプルのシーケンスである。例えば、２０秒ごとに、各ディスクに渡された複数のリクエストがダンプされる。リクエストの数はわかるが、リクエストのソースまたは具体的なタイプに関する知識は失われる。そのためデバッグがさらに複雑になる。しかし、HYDRAstorの例からわかるように、経験豊富なメンテナンス担当者にとっては問題ではないと思われる。一方、統計値はシステム全体のイメージを得るプロセスを容易にする。なぜなら、そこからプロットを作るのに最小限の量の解析と変換しか必要としないからだ。このアプローチの最大の利点は、ディスクスペースが節約されるため、パフォーマンスに与える影響が最小限になることである。統計値はより高度なレベルのログとして扱うことができる。データの収集によって詳細を削減することと引き換えに、全体像を提供する。メッセージをログから統計値に変換することは可能だが、逆はできない。統計値はログの不可逆圧縮である。
HYDRAstorはログおよび統計値の両方を収集するが、統計値の方が重要である。古典的なログは最も重要な状況、例えば失敗したアサーション、をカバーする。レガシーコードの中には、相変わらず一般的な状況を記録するものもあるが、パフォーマンスに強い影響を与えため、そのようなコードは統計値の使用に変換される。HYDRAstorにおいて、統計値は、現在のシステムの状態に関するあらゆる情報を保存するために使用される。前述したとおり、各マシンは約５００００個の異なる統計値を生成する。この数はインストールとソフトウェアのバージョンにおける役割の違いによって異なる。
2.3. HYDRAstorにおける統計値の収集
2.3.1. 統計値の収集プロセス
HYDRAstorにおける統計値の収集はいくつかのフェーズに分割できる。
最初のフェーズは、「ユニット・ローカル」というものである。各ユニットは統計値を表すカウンタのマップを有し、これらのカウンタ上で該当するイベントが動作のトリガーとなる。このカウンタにはタイムスタンプは含まれていない。
２番目のフェーズは「ノード・ローカル」というものである。ある特殊なユニットが周期的に他の複数のユニットにメッセージを送り（MessageRequestStats）、それらの統計値の現在の値（カウンタの値）を戻す。このメッセージを受信すると、何らかの統計値をリセットすることになる場合がある。例えば、「最近の」変更に関する情報などである。回答メッセージは、ディスクへのデータの記憶を担当するStatsGatherモジュールにリダイレクトされる。StatsGatherはフォーマットの１つに統計値をダンプする。これについては次のセクションで説明する（２．３．２項参照）。
「ノード・ローカル」フェーズには、本論文で述べるソリューションの設計において考慮された、特別な特徴がある。最も重要な問題は、スケジューラがいかなるメッセージ（特に、送信したMessageRequestStatsのいかなる部分集合）についても、受信者に共時的に提供することを保証しない、ということである。つまり、常に同一だが別々のユニットに存在する２つの統計値がある場合、これらの値がわずかに異なる恐れがある。その差異はたいてい非常に小さなものだが、それによって相関探索の問題がさらに難しくなる。また圧縮にも影響を与える。この問題については後で述べる。一方、この問題は、同じユニットから発生した統計値には何の影響も与えない。
統計値の収集に関する「ノード・ローカル」フェーズにおけるもう１つの障害は、異なるユニットから異なる頻度で統計値が要求される場合があることである。現在、すべてのユニットは２０秒ごとに統計値を要求するが、ユニットの中には、５秒ごとに問い合わせを受けるよう設計されているものもある。その結果、本論文で設計したソフトウェアは、異なる頻度で収集されたサンプルを比較できなければならない。
ディスク上に記憶された統計値は、ユーザがそれを要求するまで（ダウンロード・フェーズ）、または古くなりスペースの節約のために削除されるまで、待つ。現在、HYDRAstorでは統計値を他に利用する方法はない。確かに変則性検出ツールがあるが、これはオンラインで動作する。
なお、異なるノードからの統計値が１つのファイルに統合されることは決してない。このような行為は、多くのネットワークトラフィックを必要とし、ダウンロードのフェーズに何ら利益を与えることはないと思われる。なぜなら、もしユーザが統計値をダウンロードしなければならないなら、１つのノードからのデータのダウンロードと、いくつかのノードからのデータのダウンロードに、何ら違いがなく、とくにこのプロセスを自動化するスクリプトがあるからだ。一方、１つのファイルには、そのノード上で動作するすべてのユニットから収集された統計値が含まれる。
2.3.2. HYDRAstorにおける統計値の記録ファイルのフォーマット
HYDRAstorは、おそらく市場で広い存在感を持つ他のあらゆる商用ソフトウェアと同様に、統計値を記憶するためのフォーマットがいくつかあり、システムの様々なバージョンにおいて、フォーマットの進化が見られると思われる。当然、統計値のファイルが満たすべき期待値がいくつかある。統計値は特別なツール（StatsViewerという）を用いてたいてい視覚化されるが、手動でファイルの操作をしなければならない場合もある。このため、良いフォーマットは、grep、cut、sort etc等の標準的なunixツールを用いて簡単に操作できる必要がある。一方、このようなファイルはそれほど多くのスペースを使わず、これらの収集は動作中のシステムに影響を与えることはない（ＣＰＵまたはメモリ消費量もいずれも）。
ＸＭＬファイル
ＸＭＬファイルは、HYDRAstorで統計値の記憶に使われる最も古いものである。ファイルは、メタデータを記述するいくつか（約２０）のマークアップから構成され、ファイルの残りの部分はマークアップで、ライン１つごとに１つ、各々が１つの統計値についての情報を有し、名前、時間オフセット、収集頻度、サンプルのシーケンスがある。このようなデータ構造には様々な利点がある。人間が読み取れ、ファイルの収集プロセスが複雑でなく、市場には既存のＸＭＬ解析ツールがある。一方、ＸＭＬファイルは多くのディスクスペースを使用する。この問題はgzipツールを用いてファイルを圧縮すれば緩和される。しかし、Ｈ４バージョンではＸＭＬファイルはもう使用されていない。そのため、ここで設計するソリューションはこのフォーマットのファイルを直接読むことを想定していない。
Ｚｓｔａｔファイル
Zstatファイルフォーマットは、Ｈ３の更新の１つによって導入され、それ以来、統計値の記憶にとって最適なフォーマットとなった。これは、統計値収集モジュールの機能拡張の一部として導入された。このフォーマットはスペース利用に優れており、今ではサンプル収集にかかる時間が節約されている。しかしハンドメイドであるため、特別な解析ツールが提供された。ＸＭＬファイルの場合と同様に、Zstatファイルは外部のコンプレッサを使用して圧縮されている。この問題は本論文で後述する。
ここで設計されるソフトウェアはZstatファイルをサポートする必要がある。その実践的な側面は後述するが、理論上、このフォーマットは、作成されるソリューションに実際上のあらゆる制約を課す。まず、利用される圧縮は、Zstatファイルの観点から、無損失圧縮でなければならない。圧縮および解凍されたZstatファイルは、もとのものと同一構造でなければならない。また、圧縮されたファイルをもとのZstatファイルと比較して圧縮率が判断される。そのため、StatsCompressorによって作成されるファイルのフォーマットは、これらの２つの要件を強調するためにZplusという。
Zstatファイルは２つにセクションから構成され、各々が同数のラインを有する（図１５参照）。最初のセクションでは、各ラインには、１つの統計値の名前、そのメタデータ、および数値的な識別子が含まれ、これはそのファイル特有のものである。２番目のセクションでは、各ライン（タイムスタンプのシーケンスであるものを除く）には、統計値の識別子と、そのサンプルのシーケンスが含まれる。なお、本論文ではタイムスタンプについての詳細な説明は省略する。タイムスタンプは、この設計されたソリューションでは使用しないため、メタデータの一種として扱い、Zplusファイルにコピーするだけである。重要なのは、ファイル内の各統計値は違う数のサンプルを含む場合がある、ということである。Zstatファイルはgzipコンプレッサを用いて圧縮される。
Pack 統計値
Pack統計値フォーマットは、ダウンロードするデータの容量を制限している顧客からZstatファイルダウンロードする場合に、Zstatファイルのサイズを最小にするという問題を解決するため、設計された。Pack 統計値のファイルは、 通常のZstatファイルから特定のツールによってダウンロードのフェーズで作成される。Pack統計値をZstat fileに戻す変換をする同様のプログラムもある。
このファイルフォーマットはZstatファイルのフォーマットと似ているが、ファイルを小さくするために様々なシンプルなトリックを使用している。まず、このファイルは、すべての統計値の部分集合しか含まない。ユーザは、手動で定義するか、またはHYDRAstorの開発者が手動で定めた所定のカットスキームを利用する。またZstatファイルがgzipを用いるのに対して、Pack 統計値のファイルはbzip2ツールを用いて圧縮される。
Zstatファイルは２つの主な部分から構成される（２．３．２を参照）。これらは、統計値の名前の数値的識別子へのマッピング、および前述の識別子のサンプル「シーケンス」値へのマッピング、である。統計値の本当の名前は、長い共通のプレフィックス（例えばMETRIC::DataSynch::DiskRequestManager::RequestsCount::total::requestsInProgress::RecentMax and METRIC::DataSynch::DiskRequestManager::RequestsCount::cannotExecuteBecauseOfLimit::Current)である。Pack 統計値ファイルでは、名前から識別子へのマッピングはツリー形式で記述され、内部ノードには幹（METRIC、DataSynch、DiskRequestManager、等)があり、葉には識別子がある。このアプローチによってスペース使用量は約２０−３０％削減される。
ここで設計されるソリューションは、製品化の過程でPack 統計値ツールと統合することも可能である。上記のアイデアはすべて、ここで設計されたStatsCompressorによって使用することができる。名前−識別子のマッピングを圧縮する方法は非常に効果的だと思われ、特に、本論文はサンプルの圧縮の問題に焦点を当てているため、現時点では改良は行わない。ファイル内の統計値の数を制限するというアイデアは、ユーザが、どの統計値が本当に必要であるかを正確にわかっている場合には意味があるが、バグの調査を始めるときに、実際はこれはあまり一般的ではない。その場合、任意に定めた「重要な」統計値の所定の集合をダウンロードする。これらのファイルを使用するのは難しい。なぜなら、多くの統計値が不足することになり、それらは特定の状況においては興味深いものであるからだ。ここで設計したソリューションでは、統計値ファイルのコンテンツの制限が必要な場合にこのような状況がめったに起こらないようにする。
データベースファイル
これまでに述べたフォーマットはすべて、顧客のサイトで統計値を記憶し、それをサポートチームに転送するために使用するものである。統計値からプロットを作るために使用するツールであるStatsViewerは、上記のフォーマットを読むことができるが（ただしPack 統計値を除く。これは最初に変換が必要）すべてのデータをメモリに取り込む必要がある。長期間からの統計値を分析する場合、これを開くのに時間がかかる。この問題から、オンデマンドの統計値ローディングのニーズが発生した。このソリューションは、（異なるフォーマットの）統計値のファイルを、１つの標準化されたデータベースフォーマットに変換することである。実際、データベースファイルは、すでに解析されたデータを保有するsqliteデータベースであり、StatsVieverですぐに使用できる。なお、データベースはサポートチームのマシン上でしか作成されない。サイズや特定のアプリケーションを必要とすることから、顧客のサイトで作成されることはなく、またインターネットを介して転送されることもない。
この研究されたソリューションの観点から見ると、データベースファイルは、作成されたツールのための入力として興味深い。なぜなら、ＸＭＬまたはZstatファイルのあらゆるバージョンからデータベースを作成するコンバータがあるため、プログラムを、１つのフォーマットのみのファイルを読めるようにするからだ。
第３章 相関に基づく圧縮の分散モデル
本論文では、顧客からダウンロードされる統計値を含むファイルのサイズを最小化する新たな方法を提案する。この方法は、無損失で、顧客のマシンで動作するHYDRAstorシステムに悪影響を与えないものでなければならない。第２．１．３項で述べたとおり、統計値は相関関係を持つものが多いと考えられており、本論文ではこの事実を利用した圧縮方法について述べる。一方、本論文で述べる方法は、HYDRAstorと協働するよう設計されているため、圧縮ファイルのフォーマットと内容に関するドメイン知識を用いることができる。
本論文の中心的な概念は相関である。相関とは、いくつかの統計値のサンプル間の関係である。例えば、あるファイルに、同じサンプル値のシーケンスを持つ２つの統計値（統計値ｆとｇ）がある場合（ｆ（０）＝５、ｆ（１）＝３、ｆ（２）＝８、ｇ（０）＝５、ｇ（１）＝３、ｇ（２）＝８）、これらは相関関係にある、つまり、これらの間には同一性がある（ｆ＝ｇとなる）。このような相関は、ファイルの圧縮時に利用することができる（相関に基づく圧縮）。なぜなら、統計値ｇのサンプルのシーケンスを捨てても、統計値ｆがありｆ＝ｇであることから、情報を節約できる。当然ながら、同一性は非常にシンプルな相関例に過ぎない。もっと複雑なものは、例えば和の例に関するものである（ｈ＝ｊ＋ｋ、ただしｈ、ｊ、ｋは統計値）。
技術的には、「厳密な相関」と「弱い相関」の２つのタイプがある。前の段落では厳密な相関ｆ＝ｇを示した。弱い相関の例としては、次のようなものがある。統計値ｆｗとｇｗがあり、ｆｗ（０）＝５、ｆｗ（１）＝３、ｆｗ（２）＝８、ｇｗ（０）＝５、ｇｗ（１）＝６、ｇｗ（２）＝８であり、かつｆｗ＝ｇｗ＋ｄ、ただしｄ＝[０、３、０]、これを偏差ベクトルという。実際に、どんな統計値の集合でも常に弱い相関がある。当然、弱い相関が優れていれば、より小さな数の偏差ベクトルを含む。偏差ベクトルの概念は、StatsCompressorに関する章（第５章）で重要となる。本論文では、相関という概念を用いる場合は常に厳密な相関を意味する（弱い相関と明示する場合を除く）。
相関に基づくアプローチは、StatsCompressorという名前の、独立型ツールのフォームで実装されている。このツールは顧客のマシン上で動作し、統計値を含むZstatフォーマットのファイルを圧縮し（第２．３．２章参照）、Zstatフォーマットの拡張バージョンであるZplusフォーマットでファイルを出力する。StatsCompressorは、相関に基づくアプローチと、Zstatファイルのフォーマットおよびコンテンツに関するいくつかのドメイン知識とを利用する。
１つのZstatファイルには数千もの統計値が含まれており、各統計値は多数のサンプを持つ。したがって、統計値間には多数の相関が存在し得る。顧客のマシン上で相関を発見することは、それと同時に動作しているHYDRAstorのパフォーマンスに大きな悪影響を与える恐れがあるため、StatsMinerという別のツールを作成することにした。StatsMinerは、サポートサイトのマシン上で動作して、相関の探索に使用するものである。このツールはデータベースファイルを読み、「規則」を含むファイルを作成する。１つの規則は、統計値間の１つの相関を説明するものである。規則は、例えばその相関が何回発見されたか、といった相関の数量に関するメタデータで強化される。StatsCompressorは、StatsMinerで作成された規則を用いて、相関に基づく圧縮を処理する。
StatsMinerとStatsCompressorは、図１６に示す分散圧縮モデルを形成する。この図は、顧客から統計値をダウンロードし、この設計されたソフトウェアを用いて圧縮するために処理すべき、継続的な作業を示している。
StatsMinerはサポートチームのサイトで動作し、StatsCompressorは顧客のサイトで動作する。サポートチームは、一連のファイル例上でStatsMinerを動作させて規則のファイルを作成する。このツールの、現在実装されているバージョンは、まだ完全に設計された機能に達していない。中には、本論文で提案されてはいるが時間がなくて実装されていないアルゴリズムもある。しかし、現時点で、StatsMinerによって作成された規則は数が多すぎて、そのすべてをそのまま顧客にアップロードできないため、規則に関して何らかの選択をしなければならない。このように限定された一連の規則を、例えば一連のパッチと更新を含むパッケージなどにして、時々顧客に転送し、顧客のマシンのハードドライブに記憶した。
サポートチームが顧客から統計値をダウンロードする必要がある場合は、Zstatフォーマットの選択されたファイルがStatsCompressorを用いて圧縮される。当然、すべてのZstatファイルを作成時に自動的に圧縮することができるが、それは資源の無駄だと思われる。この研究の目的は、利用可能な帯域幅が限られる場合にサポートによってダウンロードされるサンプル数を増やすことであった。StatsCompressorはドメイン知識のみを利用し、バイトレベルで何らかのアルゴリズムを動作させることはない、と決められていた。この前提の目的は、高レベルの統計値間の相関に焦点を当てることであり、低い、バイトレベルではなかった。この種の圧縮は、既存の汎用コンプレッサの方が早く、より良く実行できると考えられていた。また、このようなアルゴリズムを実装すると、非常にエラーが発生しやすい。準備ができたZplusファイルは、顧客からダウンロードされる。
取得したZplusファイルは、解凍してオリジナルのZstatファイルを再生する（使用した圧縮方法は無損失なので）。本研究を行っている間、時間がなかったためデコンプレッサは実装しなかったが、オリジナルのZstatファイルと解凍したZstatファイルは同一であると思われる。圧縮方法が無損失であることを証明するために、実装した圧縮アルゴリズムについては綿密なレビューを行った。また、StatsCompressorが仕様に沿ったZplusファイルを作成するかどうかをチェックする機能性テストも行った。
ここで述べるStatsMinerとStatsCompressorの協働の分散モデルは最も一般的なものである。他のモデルについては、５．１０章で述べる。
以降の章では、参考文献[GKP94]で定義される有限差分の演算子数１の概念を広く用いる：
数２。
なお、以下においては、下記数３で示すように、数１（Δ）の代わりにｄを用いるものとする。
第４章 相関マイナー（マイニングツール）
本章ではStatsMinerの説明と評価を述べる。StatsMinerは統計値の相関を発見するためのツールである。発見された相関を説明する規則を用いて、後述するStatsCompressorで統計値を含むファイルの圧縮を行う。
本章には以下のセクションが含まれる。
4.1 「概要」では、StatsMinerの概念、つまりStatsMinerが解決すべき問題、高度なアーキテクチャ、主な前提、および選択された技術、について述べる。
4.2 「テストベッド」では、StatsMinerのテストの方法論、およびこのプロセスで使用するデータについて述べる。
4.3 「ウィンドウ」では、StatsMinerで使用する最も重要なエンティティの１つである、「ウィンドウ」について定義する。この定義とは別に、ウィンドウを生成するための複数のアルゴリズムを提示しており、その内の１つを実装した。
4.4 「発見された規則の記憶」では、発見された規則のＲＡＭへの保存に関する問題点を取り上げる。これは本ツールの性能にとって不可欠であることがわかっている。
4.5 「相関の種類」では、相関発見アルゴリズムの分類を紹介する。
4.6-4.8 「グローバルインターアルゴリズム」、「ローカルインターアルゴリズム」、「イントラアルゴリズム」では、具体的なマイニングアルゴリズムについて述べる。これらは４．５章でカテゴライズされている。なお、StatsMinerについて考え得る特徴の包括的なイメージを構築するために、すべての概念に関して述べているが、すべての概念を実装したわけではない（特にローカルインターアルゴリズムは全く実装していない）。
4.1. 概要
「StatsMiner」という相関マイニングツールは、本論文で述べる研究の一部として作成されたデータマイニングツールであり、統計値間の相関の捜索に使用された。これは、少なくともプロジェクト全体の実験フェーズで、開発者のマシン上で実行されるツールとして作成された。リソースの消費量に応じて、製品化の際に一部または全部のアプリケーションをStatsCompressorと統合させてもよい（５．１０．４項を参照）。迅速な製品化を可能にするために、StatsMinerのコードは、コーディング基準と優良実践を順守し、オブジェクト指向で記述された。
このツールはデータベースファイルを読み出し（２．３．２項を参照）、規則を含むＣＳＶファイルを出力する。
4.1.1. 問題の提示
統計値間のいかなる相関も、方程式を用いて記述することができる。 分析された統計値のほぼすべての関係は、一次方程式で記述することができると考えられている（ただし統計の有限差分は許容される）。この前提は、他のジャンルの相関（つまり二次）が出現することを想定しない、HYDRAstor開発者の専門知識に基づくものである。線形代数は、線形依存性を発見するための、いくつかのツールを提供するが（例えばガウス消去法）、２つの欠陥がある。第１の問題点は、分析した統計値の数が、すべての統計のサンプル数と同じでなければならないことである。約５００００の統計値があり、さらにそれらの有限差分が含まれている場合、各統計に１０００００のサンプルが必要になる。また、通常、統計は２０秒ごとに収集されるため、２３日間に収集されたサンプルが必要なる。この手法における第２の問題点は、ガウス消去法はO(n３)の複雑性を有するため、１０００００の統計値を使用する場合、その計算には許容できないほどの時間がかかると思われる。これ以外に、メモリ消費量に関する制約もある。Ｃ++のダブルスを含む１０００００×１０００００のサイズの行列を記憶するのに、メモリの７５ギガバイトを消費する。
線形依存性のためのマイニングは不可能であるため、問題を容易にして解決可能にするためには、いくつかの要件を緩和しなければならない。まず、明らかなこととして、相関係数が整数であることがあげられる。これは、統計値が事象の離散空間を記述する性質であることに由来する。残念ながら、整数の係数を持つ、線形依存性を捜索するのは、NP困難な問題である。部分集合−和の問題からのシンプルな削減がある、研究対象の問題は、より制約のあるものに限定することはできないため、別のアプローチを選択した。入力データに対して実行されるシンプルなアルゴリズムは多数あり、その各々によって、統計値間の詳細に定義される様々な関係性が発見される。このアプローチの結果は、線形相関に関する真の捜索から得られる結果の部分集合だが、前述のサブセットの計算は達成可能である。
4.1.2. フェーズ
StatsMinerの主な機能は、統計値における相関を発掘することである。このツールをまず何回か実行したところ、数十億もの相関が発見されることがわかったため、相関に関する詳細な定量的情報の必要性がすぐに明らかになった。さらに、探索するデータ量が膨大であったため（一度に１０００００個の統計値）、マイニングのプロセスを迅速化するためのヒューリスティックをいくつか用いた。その中で最も重要であったのは、いくつかの統計値に関してある種の相関が発見された場合、それ以外の種類の相関を探索する前に、それらを作業対象集合から除外することであった。これについては、具体的なアルゴリズムについて扱う際に詳細に説明するが、このアプローチの効果の１つは、軽い相関が重い相関を隠すことができる点である。
この状況に対処するため、このツールの作業を２つのフェーズに分けた。第１のフェーズはマイニングフェーズであり（図１７）、このフェーズでは統計値集合における相関を一から発掘する。当然ながら、このフェーズは時間がかかるプロセスである。例えば１００００００の統計値について採掘する場合、各々が２０のサンプルを有すると、約３００秒かかる。当然、すべての加速ヒューリスティックが使用される。第２のフェーズは検証である（図１８）。このフェーズでは、先に発見された（またはファイルからロードされた）相関の発生を探索し、その相関が作業対象の集合に適用されるかどうかのみをチェックする。前述のデータ集合について、約３０秒かかる。
このように複数のフェーズに分割することにより、計算の並列化をより良い方法で行うことが可能となる。マップ−削減（map-reduce）パラダイムは、このツールの使用パターンに適合する。マイニングと検証のフェーズにおいて、研究対象のデータベースファイル集合を複数のマシンに分散し（マッピングステップ）、削減ステップで、生成された規則を含む複数のファイルを簡単に１つに統合することができる。
実際には、マイナー（マイニングツール）と検証ツールは２つの別々のプログラムでもよい。このアプローチは開発費と維持費は高くなるが、双方のパフォーマンスを向上させることができる（各々が、より特定化され調整されるため）。
4.1.3. プログラミング言語の選択
このプログラムは、すべてのHYDRAstorのソフトウェアと同様にLinuxで実行することができ、C++で記述されている。この言語を選択した理由は複数あるが、実際的な理由は、HYDRAstorの開発者がC++とPythonを使用しているため、これら２つのいずれかを選択すれば、既存のコードデータベースが利用でき、また他のプログラマーの助けを得られるため、開発が容易になるからである。また、このプログラムは多くのＣＰＵとメモリを消費することが想定された。Pythonを使用すれば第１の要件は満たすことができると思われるが（C++の方が当然速いが開発プロセスは遅くなる）、第２の要件によってＣ＋＋を選択した。これは良い判断であった。なぜなら前提が正しいことが証明されたからである。標準構成で実行されるStatsMinerはＲＡＭの数ギガバイトを消費し、もしこのソフトウェアがPythonで記述されていれば、Pythonのガーベジコレクションは劣っているためアプリケーションは使用不能になっていたと思われる。
4.2. テストベッド
4.2.1. テストデータ
StatsMinerのテストはすべて、以下のデータ集合に対して実行された。
１．LRT_A−Ｈ４（１つのＨＮと４つのＳＮがあった）上でのLong Running Testからランダムに選択した５０個のZstatファイル（５３２７個の利用可能なファイルから選択）。このテストは約２週間継続して行い、HYDRAstorの通常利用およびいくつかの窮状を刺激することを目的とした。上記のファイルはデータベースのフォーマットに変換されたものである。各ファイルは約５０ ０００個 の統計値から構成され、各々が６０〜１００個のサンプルを有する（ただし１つのファイル内のすべての統計値がほぼ同数のサンプルを有する）。
２．CL−HYDRAstorの実際のユーザ（顧客）から受け取ったファイルの中からランダムに選択した３０個のＸＭＬファイル。これらのファイルはHYDRAstorシステムの様々なバージョンで生成されたものであり、様々なパッチと更新が実行されている。このテストには、容量が２ＭＢから４ＭＢでＳＮで生成されたファイルのみが使用を認められる。選択されたファイルはデータベースフォーマットに変換されている。ファイルは約５０ ０００ 個の統計値を含み、各々が１４０〜２４０個のサンプルを有する（ただし１つのファイル内のすべての統計値がほぼ同数のサンプルを有する）。
CLとLRT_Aのテストセットでは含まれるファイル数が異なる（３０および５０）。なぜなら、CLで５０個のファイルを使用すると、発見される規則の数が膨大でＲＡＭ不足となり実験が成功しない恐れがあるからである。
4.2.2. パフォーマンスの測定
すべてのテストは、Ｉｎｔｅｌ Ｘｅｏｎｓ５６４５のＣＰＵを２つと、４８ＧＢのＲＡＭを備える開発マシンで実行した。テストにかかる時間と費用はタイムプログラムを用いて測定し、パラメータ％Ｕ（ユーザモードで行われるプロセスのＣＰＵ秒数）および％Ｍ（その寿命中のプロセスの最大常駐集合サイズ）で実行された。メモリ消費量の結果は修正されたため、既知の計数バグの影響は受けていない[com13]。
4.3. ウィンドウ
「ウィンドウ」はStatsMinerの中心的なコンセプトであり、すべての利用可能な統計値のサンプルの、一連の比較可能な同じ長さのシーケンスとして説明することができる。ウィンドウの長さは個々のシーケンスのサンプル数であり、ウィンドウの幅は統計値の数である。実際のところ、ウィンドウはマトリクスである。なおウィンドウは、それに含まれるサンプルを収集した時間に関する情報を全く含んでいない。これはウィンドウの使用を簡素化する前提である。
図１９に、長さ１０、幅７のウィンドウの例を示す。１つのファイルを複数をウィンドウに分割することもできる（Zstatファイルの例を示す図１５と、前述のファイルから生成された１つのウィンドウを示す図１９を比較）。相関を探索する各アルゴリズムは、ウィンドウを入力と想定する。ウィンドウの特性（各統計値に同数のサンプル）のおかげで、マイニングアルゴリズムの実装が簡素化される。ウィンドウを使用するもう一つの利点は、結果の比較に明確な基準があることである。特定数の、きちんと定義されたウィンドウには、常に規則が適用される。一方、このツールで分析されたファイルは統計値ごとに異なる数のサンプルを含むことがある。そのため、「３つのウィンドウで規則が発見された」と言うよりも、「３つのファイルで規則が発見された」という方が、はるかに不明確である。ウィンドウの概念は、検証の際に広範囲に渡って使用される。相関とウィンドウを説明する規則があり、相関がウィンドウに適用できるか（すべての予想統計値が存在するか）、およびサンプルが本当に相関を満たしているか、という２つの事実を確認して、各規則について保存する（図１８を参照）。
マイニングアルゴリズムのための入力としての、ウィンドウの内容は、発見された相関の数と種類に重要な影響を与える。ウィンドウのサイズ、およびそれを生成するためのアルゴリズム（データベースファイルからロードした統計値からウィンドウを生成する）、という独立した２つの点が重要である。
ウィンドウの生成は平凡なものに見えるが、このプロセスで直面する問題がいくつかあるため、かなり複雑なものとなっている。前述したとおり、HYDRAstorでは、 統計値は様々な頻度で収集することができ、収集プロセスはユニットのレベルで非同期であり、統計値はどの瞬間にも出現したり消滅する場合があり、最終的にサンプルが可変長のファイル（Zstat）に記憶される。次のセクションでは、ウィンドウを生成するための２つのアルゴリズムについて述べる。
ウィンドウのサイズは、与えられたデータベースファイルにおいて発見される相関の数と品質に非常に大きな影響を与える。 実験により、ウィンドウが小さすぎると発見される相関が偶発的になるため正しい結果を得られない恐れがあるが、ウィンドウが長すぎると、多数の相関を見逃す可能性がある。なぜなら、統計値の収集プロセスが非同期である性質から、厳密な相関が消滅するという点でサンプルが阻害されるからだ。厳密な相関を探すことは弱い相関を探すよりもはるかに容易であるため、厳密な相関は興味深い（４．７．５項を参照）。
相関の品質の測定基準は、その「有意水準」である。相関Ｃは次の数４で示すように定義される。
ここで、
適用（Ｃ）＝相関Ｃが厳密に適用されるウィンドウ数
出現（Ｃ）＝相関Ｃによって予測されるすべての統計値が出現するウィンドウ数
を表す。
異なる相関タイプの有意のプロットを４．９章に示す。
明示的な記述がない限り、本論文で述べるすべての規則は長さ１０〜２０サンプルのウィンドウ上で生成されたものである。
なお、各ウィンドウには、そのすべての統計値の有限差分も含まれており、ｆとｇが統計値である場合、ｄｆ＝ｇのような何らかの相関があると考えられる。この前提は、何らかの「最近の」統計値があり、それらが最後の数秒間に何らかのパラメータの変化を測定するという事実に基づく。
4.3.1. ウィンドウ生成アルゴリズム
ウィンドウ生成は、マイニングアルゴリズムのためのデータを作成することである。相関を捜索するすべてのアルゴリズムは複数のウィンドウ上で動作するため、データベースからロードされた統計値のサンプルは、複数のウィンドウに分割する必要がある。
本項では、ウィンドウを作成する３つのアプローチを説明する。２つの代替可能なアルゴリズム（グリーディ（貪欲）アルゴリズムとタイムスタンプ認識アルゴリズム）と、ウィンドウのより高度なソースのアイデア（ランダムウィンドウ）である。ただし、実装したのはグリーディアルゴリズムのみであり、これについてのみ詳細に説明する。残りの２つはグリーディアルゴリズムがうまく作動しなかった場合（実際には作動した）に実装可能な拡張（extension）として提示する。
グリーディ（貪欲）アルゴリズム
ウィンドウ生成のためのグリーディアルゴリズムは、最初に実装されたアルゴリズムである。このアルゴリズムのアイデアは基本的に非常にシンプルなものであり、各統計値について、アルゴリズムがデータベースファイルからサンプルをロードし、これらのデータを無制限のサイズの内部サンプルキューに入れる。各統計値は自身のサンプルキューを持つ。すべての統計値のサンプルのキュー（空のものを除く）のサイズが、少なくとも最小ウィンドウ長（Ｍ）に等しい場合、まず各統計値のＭサンプルが、そのキューから新たなウィンドウに移される。当然、１つのウィンドウは所望する最大長より長くなることはできない。しかし、これらのキューの１つに、最小ウィンドウ長よりも少ないサンプル（Ｎ）しか含まれていない場合は、データベースから、さらにサンプルがロードされる。データベースの中にそれ以上サンプルがない場合は、最初のサンプル（Ｎ）の数がすべてのバッファから落とされる。
このアルゴリズムが「グリーディ（貪欲）」の言われるのは、サンプルのタイムスタンプを使用しないからである。ウィンドウ が作成された時間について、間違いを起こしやすい状況を招く恐れがあるが、サンプルのタイムスタンプはシフトするため、理論的には、カラム内では比較不能である（つまり、２つの統計値ｆとｇがあり、かつｉ−ｔｈサンプルを分析する場合、ｆ（ｉ）をｇ（ｉ）と比較することはできない）。幸運なことに、１つのユニットの統計値のｉ−ｔｈサンプルは同じタイムスタンプを有するため、重要なのはユニット間相関である。当然ながら、サンプルのタイムスタンプを考慮しない場合、マイニングアルゴリズムでは２つのユニット間の不適切な相関が発見されることがあるが、このような相関は検証フェーズで低グレードが与えられる。このアルゴリズムに関するもう１つの問題は、多数の統計値が同時に出現または消滅することが発生することである。なぜなら、いかなるウィンドウを作成することも不可能になるからである。
このアルゴリズムの欠点は、主に速度に関する利点によって補われている。計算に使用するサンプル総数がｎである場合、アルゴリズムの複雑性はＯ（ｎ）である。このように生成された相関の使いやすさが、このアルゴリズムのもう１つの良い点である。なぜなら、StatsMinerがタイムスタンプを使用しない場合、StatsCompressorもこれを必要としないため、このツールがより速く、よりシンプルになり、わずかなサンプルのシーケンスを使って相関の適用を試みることができる。最後に、このアルゴリズムの実装は非常に迅速に行われ、また発見された相関数が十分に多いため、非常に利用しやすい。
タイムスタンプ認識アルゴリズム
グリーディアルゴリズムの主な問題点は、サンプルのタイムスタンプを考慮しないことである。この問題に対処するため、タイムスタンプ認識アルゴリズムの設計を計画した。しかし、その一方で、データベースフォーマットにおけるファイルの生成装置が改良され、グリーディアルゴリズムが以前よりも良い動作をするようになった（より多くのウィンドウが作成された）。さらに、StatsCompressorによって良い圧縮率が達成される一方、グリーディ（貪欲）な方法で作成されたウィンドウに含まれる規則によって、ウィンドウ生成においてタイムスタンプを使用することが以前ほど不可欠ではないことがわかった。そのため、タイムスタンプ認識アルゴリズムは作成せず、また実装されたいずれのアルゴリズムでもタイムスタンプは使用されていないため、本論文ではサンプルのタイムスタンプに関する詳細な説明は省略する。
ランダムウィンドウ
ランダムウィンドウは、前述のアルゴリズムによって生成されたウィンドウを再利用（あるいは「リサイクル」）するというアイデアである。前述のとおり、StatsGatherプロセスは非同期であるため、２つのユニットからの統計値間に相関が客観的に存在する場合でも、比較するサンプル間にわずかな偏差があれば、相関が発見されない可能性がある。このような現象は理論上だけのものではなく、現実のデータにおいても観測された。ウィンドウのサイズは１０から２０サンプルに設定され、明らかに同一の２つの統計値には１０％の確率で偏差があった。残念ながら、生成された各ウィンドウに少なくとも１つの偏差があったため、相関は発見されなかった。ランダムウィンドウはこの問題を解決する。
そのアイデアは、古典的な方法で生成された複数のウィンドウからランダムに取得したサンプルのいくつかの列から、ウィンドウを作成する、というものである。例えば、第１のウィンドウの４番目、６番目、７番目のサンプルと、第２のウィンドウの１番目、６番目、８番目のサンプルを新たなランダムウィンドウに移行する。これらのサンプルはもはや連続するものではないが、この新たなウィンドウは、当然、ウィンドウの定義によるすべての期待値を満たすものである。
一連のサンプルを取り出したウィンドウの長さの合計によって、ランダムウィンドウの概念はサンプルにおける偏差の問題の助けとなる。当然、偏差の確率は同様に存在するが、１つのデータベースから、通常のウィンドウに比べてより多くのランダムウィンドウを生成することができ、生成するランダムウィンドウの数が多いほど、偏差のないランダムウィンドウを得る可能性が高くなる。したがって、これまで隠れていた厳密な相関が含まれる。さらに、ランダムウィンドウの生成にかかる費用は非常に安い。なぜなら、すべてのサンプルが既にメモリに記憶されており（データベースからデータを読み出す必要がない）、古いウィンドウと新たなランダムウィンドウとの間でサンプルをコピーしないようにプログラムすることができるからである。
時間がなかったため、このアルゴリズムは実装しなかったが、これはStatsMinerの容易かつ効率的な拡張になると思われる。
4.3.2. まとめ
ウィンドウは、統計値およびそのサンプルを入れる便利な容器であり、これによって、マイニングアルゴリズムの実装が非常に簡単になる。ウィンドウの作成方法は、StatsMinerによって発見される規則に大きな影響を与える。１つのパラメータはウィンドウの長さであり（幅はデータベースからロードされるデータによって異なる）、もう１つはサンプルのウィンドウへの挿入に使用するアルゴリズムである。本章で述べた概念の中で唯一実装したのはグリーディアルゴリズムである。実際に、このアルゴリズムはよく動作した（この方法で作成したウィンドウで多くの規則が発見された）が、タイムスタンプ認識アルゴリズムを使用すれば、より現実的な相関が得られる可能性がある。一方、ランダムウィンドウは、弱い相関の発見が不可能であるという、膨大な マイニングアルゴリズムの限界に対処する手段である。
4.4. 発見された規則の記憶
StatsMinerは統計値間の相関を発見し、取得した知識を保存するための規則を作成する。この規則は何らかの方法でメモリに記憶され、その後ハードドライブに記憶される。これをシンプルな方法で行うための２つの相対する方法（組み合わせによるアプローチと、抽象クラス（abstract-class）に基づくアプローチ）と、よりシンプルな方法からの最善のアイデアに基づく複雑な方法（ツリーを使用）が１つある。本章では、f、g、等は異なる統計値を表す。
規則を記憶するための「組み合わせ法」において、特定の統計値の各相関は別々に記憶される。例えば、相関ｆ＝ｇがある場合、ｆとｇの同一性を説明する規則が記憶される
しかし、相関ｆ１＝ｇ１＝ｈ１を保存するためには、３つの同一性規則を用いる必要があり、この３つの同一性規則の各々は２つの特定の統計値間の関係を説明するものである。「抽象クラス法」では、相関ｆ＝ｇの記憶に規則を１つだけ用い、相関ｆ１＝ｇ１＝ｈ１の記憶に規則をもう一つだけ用いる。
組み合わせ法を使用するとメモリの消費量が多くなる。例えば、単純和ｐ＝ｑ＋ｒ（ただし、ｐ＝ｐ１、ｑ＝ｑ１＝ｑ２、ｒ＝ｒ１＝ｒ２＝ｒ３）を扱う場合、すべての相関を記憶するためには２４もの規則が作成されることになる、抽象クラス法では、各抽象クラスに１つずつ、単純和に１つ、計４つの規則が作成されるだけである。ここで問題となるのは、ｐ、ｑ、ｒの抽象クラスを説明する他の規則のコンテクストにおいて、ｐ＝ｑ＝ｒを保存してこの規則をしようするのか、それとも、（（ｐ＝ｐ１）＝（ｑ＝ｑ１＝ｑ２）＋（ｒ＝ｒ１＝ｒ２＝ｒ３））として和を保存するのか、である。メモリ消費量という観点からは、抽象クラスに基づくアプローチの方が確実に優れていると思われるが、複数のウィンドウを扱う場合、状況はより複雑になる。
ウィンドウＷ１において、前記の相関（和）は発見されたと仮定する。ただし、ウィンドウＷ２は類似しているが同じ相関ではなくｐ＝ｐ１、ｑ＝ｑ１＝ｑ２、ｒ１＝ｒ２＝ｒ３（数５）である。組み合わせ方が用いられた場合、この変化によって新たな規則が作成されることはなく、既存の規則の使用カウンタ（有意性の計算に使用）を更新するだけでよい。同時に、抽象クラスのアプローチには良い解決策がない。１つのアイデアとして、クラスｒ１＝ｒ２＝ｒ３（ｏｒ（ｐ＝ｐ１）＝（ｑ＝ｑ１＝ｑ２）＋（ｒ１＝ｒ２＝ｒ３））を説明する新たな規則を加える方法があるが、規則ｐ＝ｑ＝ｒをどうするのか、つまり、ｐ＝ｑ＝ｒ１を加えるのか？と言う問題がある。もしそうなら、Ｗ１の場合、同じ相関が２回表されることになる（したがって検証フェーズでカウントされる）。この問題は、規則（ｐ＝ｐ１）＝（ｑ＝ｑ１＝ｑ２）＋（ｒ＝ｒ１＝ｒ２＝ｒ３）を、（ｐ＝ｐ１）＝（ｑ＝ｑ１＝ｑ２）＋（ｒ１＝ｒ２＝ｒ３）、および（ｐ＝ｐ１）＝（ｑ＝ｑ１＝ｑ２）＋（ｒ）という２つの規則に分割すれば解決される可能性がある。これにより、使用カウンタの誤った値の問題は解決するが、（ｐ，ｐ１）、（ｑ，ｑ１，ｑ２）、（ｒ，ｒ１，ｒ２，ｒ３）の部分集合のあらゆる組み合わせが発生するため、規則の総数が指数関数的に大きくなる。一方、規則ｐ＝ｑ＝ｒを使用することもできるが、クラスｒ１＝ｒがあり、推移閉包の概念が利用されることがある。しかし、この場合、抽象クラスの数とサイズが大きくなるにつれて、すべてのウィンドウにすべての規則が適用され、その結果、規則の使用カウンタはまったく誤った結果を導くものとなる。
要するに、抽象クラスに基づく方法は、メモリ消費量と使用カウンタの正確性との間でトレードオフの関係にある。加えて、組み合わせ方では、検証の前後での規則数が同じであるが、抽象クラス法では、カウンタ問題に対する救済措置として規則の分割が選択された場合、検証後の規則数が劇的に増加する可能性がある。
この２つの方法の利点を合わせると、各規則をツリーとして記憶し、すべての規則で森を作成することになる。本論文ではこの方法のドラフトのみを記載する。ツリーの根には相関の最も一般的な形式が含まれ（例えば、（ｐ＝ｐ１）＝（ｑ＝ｑ１＝ｑ２）＋（ｒ＝ｒ１＝ｒ２＝ｒ３）、図２０参照）、内部ノードには抽象クラスの分割に関する情報のリストが含まれ（例えば数６ａｎｄｒ）、葉には使用カウンタが含まれる。根から葉まで辿ると、訪問した内部ノードから根に存在する規則までのカット（ｃｕｔｓ）を適用することによって作成された一連の相関の使用カウンタの値がわかる。この表し方で使用するメモリは、シングルトンの抽象クラスしか存在しない場合は、少なくとも抽象クラスの方法で使用するメモリ（内部ノードがない場合）と同量で、組み合わせ法よりも少ない（ツリーの実装の詳細に関して）。このデータ構造の複雑な点は、メモリ効率のコストである。なお、この記載はあくまでもこの方法のドラフトであり、実際のテストは行っていない。
設計上の解決策としては、組み合わせ法を選択した。なぜなら、組み合わせ法の方が実装がシンプルで、動作が速く（抽象クラスの分割は費用が高いと思われる）、十分に正確で、メモリ消費量が予測可能だからである（ただし消費量は多い）。さらに、組み合わせ法で記憶される規則は視覚化または合計することが簡単で、いくつかのオペレーションをカウンタに作ればいいだけである。規則がハードドライブに降ろされると、これらはＣＳＶフォーマットで記憶されるため、LibreOffice、Microsoft Excel、または単なるbashスクリプト等のツールを用いて簡単に操作することができる。
抽象クラスに基づく方法は、規則を消費者のサイトに記憶する場合にそのサイズを縮小する方法となる可能性がある。すべてのマイニングを組み合わせ法で行い、その後、実際にクライアントに送信するデータを抽象クラスのフォームに変換してもよい（特にその時点で使用カウンタが必要ない場合）。これは、ある種の、規則ファイルの無損失圧縮と考えることができる。
4.5. 相関のタイプ
相関は、２つの主なカテゴリーである「内（intra）」と「間（inter）」に分けられる。最も興味深いのは「値間相関（inter correlations）」であり、これは２つの異なる統計値間の関係を表現する。このタイプの基本的な例は同一性（identity）である（fとgが２つの統計値である場合、f= g）。これとまったく異なるのが「内的相関（intra correlations）」であり、１つの統計値にのみ影響し、その統計値の再現可能な特性を表す。内的相関の最もシンプルな例は定数である。
これ以外の相関の分類は、大規模な統計値の集合における相関を探索する能力である、マイニングアルゴリズムの技術的制約と関連するものである。シンプルな相関（同一性のようなもの）のほとんどのタイプを探すには、すべての利用可能な統計値（定数の統計値を除き７００００）を含む集合において、探索を実行すればよい。このような相関（およびそのマイニングアルゴリズム）を「グローバルな（全体）相関」（global correlations）と言う。一方、一次結合のような、より些細な相関は、一度に複数の統計値間では効果的に発見することはできない（例えば、一度に１０００以下）。このような相関（およびアルゴリズム）を「ローカルな（局所）相関」（local correlations）という。ローカルマイニングアルゴリズムを使用するには、まず、そのアルゴリズムが動作する、すべての利用可能な統計値のうちの部分集合を選択する必要がある。これが、全体的なマイニングアルゴリズムと局所的なマイニングアルゴリズムの主な違いである。
圧縮という観点では、値間相関は最も有益である。全体的か局所的かを区別する意味はないが、全体相関の方が局所相関よりも数が多いことが望ましい。一方、全体相関のためのマイニングの方が、よりシンプルでコストが安いと考えられ、この種の分析は、もしＣＰＵとメモリ消費量が許容レベルであれば顧客側で行ってもよい。
なお、第３章では「厳密な相関」と「弱い相関」の区別について述べたが、基本的に本論文で述べている相関はすべて厳密なものである。
4.6. グローバル・インター・アルゴリズム（全体的値間アルゴリズム）
前述のとおり、一般的な一次結合の探索はコストが高すぎるが、一次結合のいくつかのクラスを簡単に発見することもできる。インターアルゴリズムは、ウィンドウ内の異なる統計値間における、このような特別な種類の関係を探索する。本章および後続の章では、nはウィンドウ内の統計値数（ウィンドウの幅）、kは各統計値のサンプル数（ウィンドウの長さ）を表す。
なお、提示したアルゴリズムのうち、実際に実装して評価したのは、同一性発見のためのソートアルゴリズムと、単純和発見のためのブルートアルゴリズムだけである。これ以外のアルゴリズムは、パフォーマンスが満足できるものでなかった場合の代替案として扱うべきである。いくつかのアルゴリズムには、前述した拡張が可能なものもある。これらの拡張は、発見される規則の数を増加させる可能性がある。
4.6.1 同一性のためのマイニング
同一性は値間相関の最も基本的な例である。同一性の数は極めて多いと考えられる。なぜなら、システムの異なるレイヤーにおいて、例えば受信または送信したメッセージ数などの、同じ事象が独立してしばしば記録されるからである。
同一性を探索するアルゴリズムは、ウィンドウ内のサンプルのベクトルの抽象クラスを発見する。後続のマイニングアルゴリズムの動作時間を短くするために（図１７参照）、ウィンドウ内には各抽象クラスの代表１つしか残さず、残りのメンバーは除去される。平均的に、IdentityMiner は、入力として２０３６６個の統計値を含むウィンドウを取得し、１２２３６個の統計値を含むウィンドウを出力する（これらの値はLRT_Aデータ集合用に計算された）。
同一性発見のためのソートアルゴリズム
説明
このアルゴリズムのアイデアは極めてシンプルで、各統計値をサンプルのベクトルとして扱うことで、統計値は、サンプル値の辞書式のコンパレータを用いてソートされる、というものである。アルゴリズムのこのステップは、Merge Sortのような標準的なアルゴリズムを使用した場合は、O(kn log n)の複雑性を有する。複雑性(数７)の下限は意思決定ツリー分析（参考文献[Knu98] ）に由来し、この複雑性は、参考文献[FG05]に記載するアルゴリズムによって達成されている。 しかし、StatsMinerではサンプルのベクトルはポインタでアクセスされているため、上記論文の著者は、古典的なQuick Sortも複雑性O(nk + n log n)を持ってもよいと提案している。
サンプルのベクトルをソートした後、後続のベクトルが同一であり同一性相関が登録できるかどうかを確認するのにO(nk)時間かかる。要するに、実装されたアルゴリズムは複雑性O(nk log n)を有しており、最適なケースの複雑性O(nk + n log n)は論理上達成可能だが、より多くの努力が必要である。
当然ながら、２つの統計値ｆとｇがウィンドウ内で同一であれば、それらの有限差分も同一である（ｄｆ＝ｄｇ）。しかし、その反対はない（数８）。StatsMinerの目的は、StatsCompressorのための規則を作成して規則ｆ＝ｇを保存することである。実際のパフォーマンス上の理由により、規則ｄｆ＝ｄｇが作成されることはない。なぜなら（ｄｆ＝ｄｇかつ数９）の例はそれほど多くないという全体に基づくヒューリスティックだからである。
テスト結果
このアルゴリズムは高速で（理論上、最適なものではないが）、多数の規則を作成する。ウィンドウの例（図１９）では、次の規則が作成される：
１．stat_alpha = stat_beta.
２．stat_beta = d stat_gamma.
３．stat_alpha = d stat_gamma.
真のHYDRAstorの統計値（これらの名称の意味の説明にはシステム内部の詳細な説明が必要となるため、省略する）において発見される同一性のいくつかは次のとおり：
１．DISK::sdb8::readsMergedPerSec = DISK::sdb8::readsPerSec
２．METRIC::Aio::aioCtx-shred::AioStat::numberReqsStarted = METRIC::Aio::aioCtx-shred::AioStat::numberReqsCompleted
３．METRIC::transaction::FP::05DM::tl::syncs::req::NumStarted = METRIC::transaction::FP::05DM::tl::creations::req::NumStarted
Customers’ Logs上でアルゴリズムを実行したら（計）２１秒かかり、７７６８１４個の規則が作成された（分析したウィンドウ１つ当たり平均５７２１０個）。（なお１つの規則が複数のウィンドウで発見される場合があるため、個別のウィンドウごとの場合は「分析したウィンドウ１つ当たりの平均規則数」に影響を与えるが、生成された規則の「総数」に関する議論では一度しかカウントされない。）LRT_Aデータに関する分析の結果、５４秒間に５６１５６０個の規則を発見した（分析したウィンドウ１つ当たり平均２９０２６個）。この結果については４．９章で述べる。発見された規則の有意性についても４．９章で述べる。
同一性発見のためのハッシュアルゴリズム
説明
前記のアルゴリズムの主な問題点は、最悪のシナリオの場合、一連のベクトルに対して、各ベクトル内のすべてのサンプルの値を比較して順序付ける必要があることである。ソートアルゴリズムの速度を改善する最もシンプルな方法の１つは、まずベクトルのハッシュを比較し、ハッシュが等しい場合のみベクトル値の比較に戻る、という方法である。前述のアルゴリズムのこれ以外の部分については、変更はない。ハッシュの方法は自由に選択してよい。
このアルゴリズムにおける最悪のケースの複雑性には、依然としてO(nk log n)があるが、平均的なケースの複雑性はO(nk + n log n)である。重要なのは、ベクトルのハッシュが既に実装されていれば、通常のソートアルゴリズムをハッシュバージョンにアップグレードするのは非常にシンプルだ、ということである。
同一性発見のためのソートアルゴリズムはうまく機能したため、ハッシュバージョンは実行していない。
4.6.2. 単純和（simple sums）のためのマイニング
単純和は、すべての係数が１に等しい（ｆ＝ｇ＋ｈ＋．．．）統計値の和である。この種の関係は、統計値の間では非常に一般的だと思われる。なぜなら、イベントのクラスの数を表すカウンタと、それ以外の、サブクラスのイベント数を表すカウンタの両方があるからだ。より具体的には、HYDRAstorからの例は次のとおりである：
METRIC::transaction::FI::State::opened::NumStarted = METRIC
::transaction::FI::State::opened::NumOutstanding + METRIC
::transaction::FI::State::opened::NumFinished.
和にエレメントが多いほどアルゴリズムの複雑性が高くなる。下記に示すアルゴリズムは２つの統計値の和（ｆ＝ｇ＋ｈ）を探すために設計された。なぜなら、これ以外では、理論上の複雑性があまりにも高かったからである。実際には、そのパフォーマンスが許容できるものであれば、これらのアルゴリズムを利用して、もっと多くのエレメントの和を探索することも可能である。なぜなら、これに代わる既知のものは完全な一次結合（４．７．４項参照）を探索するものだけであり、それもやはりコストが高く、また局所的な方法だけだからである。
単純和のためのマイニングは非常にコストがかかるため、この時点であらゆる不要な作業を避ける必要がある。和のためのマイニングを、同一性のためのマイニングと同時に実行する場合は、ウィンドウ内の同一性のためのマイニングのアルゴリズムによって発見された抽象クラスはすべて、１つの代表値のみに減らすことができる。もしこの代表値がいずれかの和の中に出現したら、その抽象クラスの各メンバーが同じ場所に出現する可能性がある。前述のとおり、StatsMinerは組み合わせの形式で規則をメモリに記憶する。そのため、１つの抽象クラスの代表値が出現する規則を探すことによって、 そのデータベースに複数の新たな規則を追加することになる。そのため、StatsMinerは膨大な量（多くのギガバイト）のメモリを使用し、さらに、パフォーマンスの低下が観測される（データ構造を横断するため）。当然、一般的には、多数の和の規則が作成されることは良いことだが、圧縮の観点では、和の規則よりも同一性の規則が優先され、あまりにも多くの和の規則を作成することは、単なる資源の無駄である。なぜなら、これらは実際には役に立たないからだ。メモリ消費をわずかに削減するために、有限差分のみで構成される和の捜索は行わないことに決定した（これらは発見されるが廃棄する。）この種の関係は、実際には一般的でないが、ときどき出現することもあると考えらえる。これによってStatsMinerのパフォーマンスが実質的に向上したため、幸運な決定であった。以前は開発者のマシンのメモリがすぐに不足したが、約３０ＧＢのメモリの使用でLRT_A集合におけるマイニングを終了することができた。
平均すると、本章で述べたクラスのアルゴリズムはいずれも、入力として１２２３６個の統計値を含むウィンドウを得ている（LRT_A集合用に）。
単純和の発見のためのブルートアルゴリズム
説明
ブルートアルゴリズムはあまり洗練されたものではなく、２つ統計値ごとに、そのサンプルを合計して、その結果が既存の統計値と等しいかどうかを確認する。このアルゴリズムのコストはO(kn2+kn2 log n) = O(kn2 log n)である。その理由は、計算する統計値の数は下記（数１０）対あり、１対の計算はkまで線上であり、その結果が既存の統計値と等しいかどうか確認するということは、記憶されている統計値の集合の中で二分探索を行うことであり、O(k log n)の複雑性がある。
上記の計算モデルは、加算には可換性があることを示している。浮動小数点数については、２つ以上の要素のシーケンスを合計する場合、その代表値が異なる指数を用いている場合は、これは正しくない。さらに、わずか２つの要素の合計を求めただけだが、結果の切り上げ（数値誤差）は、このアルゴリズムの実装において実際に問題となった。解決策として、サンプルの記憶に（通常のダブルスではなく）長いダブルスを使用した。
テスト結果
このアルゴリズムは、Customer Logs用に（計）２５８０３５５５個の規則を作成し、６１３７秒間作動した（分析したウィンドウ１つ当たり平均４６０１５９０個）。LRTにおけるマイニングの結果、２０ ４０２秒（３４０分）間に（計）１３７３８７３２個の規則が発見され、平均すると、分析されたウィンドウ１つ当たり４３１ ３２４個の規則が発見された。アルゴリズムを長時間動かすことになった理由は、規則の記憶に組み合わせ形式を使用したため、規則のデータベースを更新したからである。この結果については４．９章で述べる。発見された規則の有意性についても４．９章で述べる。
このアルゴリズムは、ウィンドウ例（図１９）において次の規則を発見すると思われる：stat_delta=stat_epsilon+ｄstat_zeta.
真のHYDRAstorの統計値（これらの名称の意味の説明にはシステム内部の詳細な説明が必要となるため、省略する）において発見される和の規則には、次のようなものがある：
１．METRIC::dci::NumFinisedGetReqs = METRIC
::dci::HintVector@WI::NumNegHintHits(finitdifference)
+ METRIC::dci::NumHashArrayGetReqs(finitdifference)
２．DISK::sdl2::totalBandwidth = DISK::sdl::writeBandwidth
+ DISK::sdl::readBan dwidth
３．DISK::sdb6::writesMergedPerSec = DISK::sdb12::readsMergedPerSec
+ METRIC::ackCollector::dataLocs::dataLocCacheSize::RecentAvg
可能な拡張
この素朴なアルゴリズムは非常にコストがかかり、３つの要素の和を探索するのは、まったく良い考えでなないと思われる。その一方で、シンプルなヒューリスティックを行ってリーズナブルにすることができる。いくつかの統計値（lhss、左項）が、他の統計値の和と等しいことがわかった後で、lhssを合計して、その結果が他の既存の統計値と同じではないのかどうかを確認してみればよい。このアイデアは、カウンタには階層が存在し、イベントの数量について知らせるゼロレベルのカウンタと、ゼロレベルのカウンタなどの和である第１レベルのカウンタがある、という考えに基づいている。
単純和を発見するためのハッシュアルゴリズム
加法的ハッシュ
StatsMinerのＣＰＵ消費量を説明する方法としてのハッシュについては、同一性を発見するためのハッシュアルゴリズムについて述べることで、すでに提案した（４．６．１項参照）。和を発見するプロセスでもこの方法を利用することができるが、加法的ハッシュという特別なハッシュ関数を用いる必要がある。
加法的ハッシュ関数は次のような特性を有する：
数１１
ここで、
数１２、１３
を表す。
実際のところ、このような機能は、線形代数の観点から見るとある種の「弱められた」線形機能である。
良いハッシュ関数には、次の２つの特性が必要である（参考文献[Knu98]による）：
１．ハッシュ値の計算が速いこと。
２．衝突の回数が最小限であること。
下記の関数は本章で述べた基準をすべて満たす（「良いハッシュ関数」であり線形でもある）：
数１４
ここで、
数１５、１６
ｂ：大きな自然数
を表す。
上記の関数Hは付加的なものである。なぜなら、使用するすべての演算は付加的だからである。高速で計算され、SIMD命令を使用して計算速度を上げることができる（コンパイラが自動的にベクトル化できるような方法でこの関数を実行するのは簡単である）。この関数にはプロトタイプ実現があり、ｂができる限り大きく（素数が好ましいが、６４ビットのマシンでは２６４の方が現実的）cが十分に大きい素数である場合、衝突の回数が許容できるレベルであることが分かった。そのため、下記数１８のほとんどの値については、数１７が成り立つ。一方、Hはある種のモジュラーハッシュ関数を表し、このような関数は良い特性を持つと考えられる（参考文献[Knu98]による）。
前述の関数は（アルゴリズム全体として）暫定的に実装されている。ＩＥＥＥ７５４の浮動小数点について作業はしているもののハッシュの浮動小数点値が不可能であるため（四捨五入するとすべてのアイデアが利用不能になる）、これ以上の作業（および実験）は中断されている。固定小数点数演算を用いればこの問題を解決できるが、結果として、これは行われていない。そのため、このアルゴリズムがよく機能したのは整数値に関してのみであった。
説明
ハッシュアルゴリズムはブルートアルゴリズムと似ているが、和と比較について改善された方法を用いている。加法的ハッシュのおかげで、素朴なアルゴリズムの複雑性から因数ｋを除去することができたため、ハッシュアルゴリズムはO(kn + n2+ n2log n) = O(kn + n2log n)の平均時間複雑性を持つ。ブルートアルゴリズムの複雑性における因数ｋはサンプルの比較と和から得られるものであるが、前述のハッシュ法を使用する場合、両方の演算は(O(1))時間で送られる。当然、すべての統計値のハッシュがまず計算され、このステップは(O(kn))の複雑性を持つが、その一方で、メモリへのデータのロードにも同様の複雑性があるため、実際にはこのコストを無視することができる。
テスト結果
このアルゴリズムでは、パフォーマンス実験結果は何も得られなかった。なぜなら、これは部分的に行われただけで十分に調整されておらず、また前述のとおり、浮動小数点のサンプルでは適切に機能しないからである。
可能な拡張
当然ながら、ブルートアルゴリズムを示して説明したヒューリスティックは、このハッシュにも利用できる。欠点は、カウンタの階層の現象が整数値のカウンタにしか現れないと思われることである。そのため、弱いハッシュ法（小数値をサポートしないもの）でも十分だと考えられる。そのため、ブルートアルゴリズムを用いて第１レベルのカウンタを探し、ハッシュアルゴリズムを使って上位のカウンタを探すという、ハイブリッドなアプローチが考えられる。カウンタの階層が整数値の統計値に現れるという考えは、一般的に時間を説明するのに分数値の統計値が使用されており、これらが合計されることはあまりない、という前提に基づいている。さらに、分数値の上位カウンタがあったとしても、おそらく浮動小数点の性質により既に何らかの数値誤差が含まれている可能性があるため、これらの和を出すことは極めて難しいと思われる。
4.6.3. まとめ
グローバルインターアルゴリズムはStatsMinerの規則の最も重要なソースである。上述した概念のうち、同一性発見のためのソートアルゴリズムと単純和発見のためのブルートアルゴリズムは完全に実装され、（機能性の）テストと評価が行われた。その結果、これらのアルゴリズムは膨大な数の相関を発見することができ、また主な問題点は規則を記憶する方法であることがわかった。
4.7. ローカル・インター・アルゴリズム（局所的値間アルゴリズム）
本章で説明するアルゴリズムは、その性質または複雑性により、すべてのウィンドウ上で実行することはできない。残念ながら、ここで示すアイデアは前記のソフトウェアでは実行されていない。なぜなら、プロジェクトの時間的な制約があったため、これらのアイデアは将来のためのドラフトとして扱わなければならなかった。
4.7.1. ウィンドウ幅の制限
ランダムな選択
ウィンドウの幅を制限する最もシンプルな方法（「削減されたウィンドウ」という）は、所望する統計値の数をランダムに選択することである。
十分な大きさの集合上でマイニングアルゴリズムがよく動作するなら、これは良いアイデアであろう。例えば、LRT_A集合上でマイニングを行う場合、ローカルインターアルゴリズムの動作が予定されている場合、ウィンドウには一度に約15 000個の統計値がある（図１７参照）。ローカルインターアルゴリズムが、ウィンドウのサイズを１０００個の統計値まで削減することを許容するなら、これらのウィンドウのコンテンツをランダムに選択することは良いアイデアだと思われる（ただし実際したテストする必要がある）。一方、３０個の統計値しか含まないウィンドウで、このアルゴリズムが動作する場合（こちらの方が好ましい）、何等かの知識に基づく統計値の選択方法を考慮する必要があるため、ウィンドウ内の統計値に関係性がある可能性が高い。
4.7.2. 知識に基づく選択
データマイニングにおいて、類似する対象をグループ分けするための古典的なアプローチは、クラスタリングである。この分野では多くの研究が行われており、様々なクラスタリングの方法が提案されている。参考文献[Sch07]は、現時点における最新技術を概説している。最適なアルゴリズムの選択に関する提案が出される前は、相関の可能性がある統計値を選択する上での問題は、クラスタリングという用語に変換された。
統計値のグラフ
アルゴリズムのクラスタリングには、入力として加重グラフが必要となる。統計値のクラスタリングの場合、頂点は統計値を表し、エッジのウエイトは統計値の類似性を説明する。この時点では、グラフが方向性を持つかどうかを述べるのは難しい。方向性を持つグラフは、方向性を持たないものよりも２倍のエッジを含むため、クラスタリングは遅くなるが、より多くの情報を保存することができる。問題なのは、方向性を持つグラフのこのような性質が、クラスタの中で発見される真の相関の数に関して効率的に使用できるかどうか、という点である。これは実験で確認できるである。統計値の類似性を評価するヒューリスティックはすべて、両バージョンのグラフに適用できる。
エッジのウエイトの決定
エッジのウエイトは、接続する頂点（統計値を表す）の類似性を表す。類似性を評価する各ヒューリスティック（後に簡単に説明する）は、範囲[0; 1]から浮動小数点を返す。問題なのは、異なる値を返すヒューリスティックがある場合に、エッジのウエイトがどうなるか、である。これには、主に、
１．ヒューリスティックによって返された値の加重平均、
２．ヒューリスティックによって返された値の最小値または最大値の選択
という２つのアプローチがあり、これらは、ある程度は組み合わせることができる。
エッジのウエイトをどのように決めるかは、いくつかの実験結果に基づいて判断する。
4.7.3. 類似性のヒューリスティック
本章で提案するヒューリスティックは、入力として与えられた２つの統計値の類似性を評価する。分析用の一連の統計値を作成することは分析自体よりも時間がかからないため、パフォーマンスが重大な要件である。ここではヒューリスティックの概念のみを述べる。
ヒューリスティックは、静的および動的という２つの相対するカテゴリーに分類される。静的ヒューリスティックは、動的なものとは異なり、分析される統計値のサンプルの実際の値を使用しない。主に統計値の名前を分析し、開発者がその中に残した知識の回復を試みる。この手法は、人間は組織的な方法で物事に名前を付けるものであり、類似する実体に名前を付けるにはいくつかの方法しかない、という考えに基づく。一方、動的ヒューリスティックは統計値の値に基づくものであり、現在のウィンドウ内に存在する類似性の発見を試みる。
ウィンドウ内の統計値間の類似性の包括的なイメージを得るためには、どちらのヒューリスティックも使用するべきである。なぜなら、いずれのヒューリスティックにも欠点があり、これらは他方によって（ある程度は）緩和されるからだ。静的ヒューリスティックは、一般的な知識を統合する。これは特定の状況には適用することができない。これに対し、動的ヒューリスティックは、その結果に局所的な視点を追加する。その一方で、動的な統計値は、何ら共通性のない統計値の偶然の類似性によってバイアスされる可能性が高いが、これは静的ヒューリスティックでしか発見されない。
静的ヒューリスティック
同一プリフィックス
Names of 統計値 in HYDRAstor内の統計値の名前は用語リストで構成されており、これらの用語は一般的なものから専門的なものへと並んでいる。実際、統計値の名前はツリーを構成する（２．３．２．項を参照）。名前のツリーの統計値におけるパスが短いほど（共通プリフィクスが長いほど）、類似性は高い。非常に類似する統計値の例は次のものがある。
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は、統計値が収集されたユニット（統計値の送信者）に関する情報を含む。これは以下のヒューリスティックの基本となる。すなわち、同じユニットからの統計値は、別のユニットからのものよりも、類似性が高い、ということである。この手法は、１つのユニットは詳細に定義された幅の狭い起泡性を持つため、２つの統計値ら相関のある事象を測定する機会が多い、という考察に基づく。一方、異なるユニットからの統計値間の関係の方が（理論的な観点では）より興味深いと思われる（HYDRAstor内における予期しない依存関係が明らかになるからだ）。
同一タイプ
Zstat filesには、統計値のタイプ（フロート、割合、カウンタ、等）に関する情報が含まれる。一般的に、相関は同じタイプの統計値間の方が発見される。ただし、いくつかの例外も知られている。（特に、１秒当たりの事象数を測定するタイマーについては、例外も知られている。例えば、METRIC::flowControl::node::SlotsComputer::Bandwidth::duplicateWriteCountPerSec）。
動的ヒューリスティック
相関
ウィンドウ内ですでに相関関係にある統計値は、非常に類似性があるもｔのとして扱うべきである。同一性の場合は、頂点を統合することもできるが、統合された頂点を他のものと連結するエッジのウエイトの問題がある。このため、「完全な類似性」を意味するウエイトを有するエッジが好ましい。一方。相関により多くの統計値が関与していると、それらの間の類似性は低くなる（例えば、相関ｆ０＝ｆ１＋ｆ２とｇ０＝ｇ１＋ｇ２＋ｇ３がある場合、ｆ０、ｆ１、ｆ２はｇ０、ｇ１、ｇ２、ｇ３よりも類似性が高い）。
同数の値の変化
すべての統計値が、サンプルとして取得されるたびに値が変化するわけではない。統計値の１つが、いくつかの和（ｆ＝ｇ＋ｈ＋ｋ）であると仮定すると、ｆの値は、最も多い場合で、g、h、kの値が変化するのと同じ回数だけ変化する。当然、ｆの値は変わらないが（g = −h、k = 一定の場合）、このような状況はめったに起こらないと考えられる。
g、h、kのサンプルと同時にのみ、ｆのいくつかのサンプルの値が変化すると仮定すると、前述のヒューリスティックを拡張することができる。残念ながら、統計値は非同期に収集されるため、時間のずれがあり、実際には全体の概念が利用不能になる場合がある。しかし、これは実験で確認する。
クラスタリングアルゴリズム
サーベイ[Sch07]には、利用可能な汎用クラスタリングアルゴリズムに関する包括的な記載がある。選択するアルゴリズムは、次の特性を持つものでなければならない。
１．クラスタのマトリクスのサイズの制御が可能であること。
２．多くのクラスタで、単一の頂点が出現すること（クラスタは重なる）。
３．アルゴリズムが高速でメモリ消費量が多くないこと。
３つ目の点は非常に重要である。なぜなら、クラスタリングアルゴリズムがあまりにも遅いと、ウィンドウのサイズを制限するプロセスが役に立たなくなるからだ。そのため、グラフの構築とクラスタの選択は十分に早くなるよう、アルゴリズムの選択はパフォーマンスの実験に基づくものでなければならない。前述の要件に適用可能なアルゴリズムで最もシンプルなものは、この時点で残っている統計値の数だけウィンドウ数を削減すること、つまり統計１つにつき１つのウィンドウに削減することである。統計値ｆについて作成される、かかるウィンドウには、頂点ｆの、定められた数の最隣値が含まれる。
4.7.4 一次結合
一次結合は、統計値間で探索される関係において、最も一般的であり、最も興味深いものである。ウィンドウを有し、線形従属した統計値は、線形代数の方法を用いて計算される。本理論の言語では、ウィンドウはマトリクス数１９として表すことができ、ｍはウィンドウの長さ（サンプル数）、ｎはウィンドウの幅（統計値の数）である。なお、ここでウィンドウは転置される。ｍ＝ｎであると想定され、そうでない場合は、少なくとも|ｍ−ｎ|従属ベクトルがあり、さらには結果の解釈の問題が起こる。前記の要件は、ウィンドウ全体で線形結合のマイニングを動作させない最も重要な理由である。この期待を満たすには大量のサンプルが必要となるため、不可能だと思われるからだ。
Ｗからのどのベクトルが線形従属しているかを判断する古典的な方法はガウス消去法である。前述の問題は、下記数２０の形式で表すことができため、一次方程式を解くためにいかなるアルゴリズムも適用することができる。自明でないxは、いくつかのベクトルが線形従属であることを意味する。ただし、xから係数を得ることは難しく、カラムを削減した階段形が必要である。
マニュアルでコード化されたガウス消去法は効率的でなく（キャッシュ利用の観点などから）、数値誤差によってバイアスされていることがある。そのため、ここでは線形代数ライブラリの使用が好ましい。実際、純粋なガウス消去法の代わりに、ソフトウェアがLU分解の例を用いて計算することができる。
ガウス消去法を選択するか他の一般的な分解方法を選択するかにかかわらず、与えられたウィンドウでの統計値間の一次結合を探索する複雑性は(O(n3))である。
4.7.5. 回帰
一次結合は、StatsMinerが探索する最も強力な関係性である。しかし、StatsCompressorは弱い相関を使用するだけの柔軟性がある。この特性は、統計値の収集が非同期であるという問題を緩和するために導入され、また、これによってStatsCompressorは、マイニングのフェーズにおいても十分に適用されない規則を使用できる。このような規則は、参考文献[SE02]で概説されている多次元回帰分析を用いて発見することができる。実際、この分野では多くの研究が行われており、回帰規則のマイニングのための最適な方法を選択するには、さらなる調査が必要となる。現時点でわかっていることは、この種のアルゴリズムは、複雑性が高いため((O(n3)またはそれ以上)、数を削減したウィンドウ上で動作させる必要がある、ということである。
4.7.6. まとめ
時間がなかったため、このセクションで述べたアイデアはいずれも実装していない。十分にテストされていない新たなアルゴリズムを導入するよりも、既存のアルゴリズムを丹念に作り上げる方がより重要だと思われるからだ。特にクラスタリングに伴う作業をまず行うべきである。その一方で、統計間の一次結合（厳密なものと、回帰ベースの弱いものとの双方）を発見する能力は、StatsCompressorが達成する圧縮率を大きく改善する可能性がある。これは、変則性の発見にとっても重要なものとなり得る。
4.8. イントラアルゴリズム（内的アルゴリズム）
イントラアルゴリズムは、１つの統計値の再現可能な特性を探索する。異なる統計値間でサンプルを比較する必要がないので、このようなアルゴリズムは統計値のすべてのサンプル上で実行することができるため、サンプルを複数のウィンドウに分割する必要がないと思われる。イントラアルゴリズムはこのような特徴があるため、インターアルゴリズムのための探索スペースを削減するヒューリスティックのための知識の源となる可能性が十分にある。
4.8.1. 定数の発見
定数関数は、イントラ（内的）相関（および他のあらゆる相関）の最もシンプルな例である。驚くことに、HYDRAstorの統計値の多くは長期間にわたり一定である。平均すると、LRT（約８３サンプルを含む）からのZstatファイルは、約４８９４０個の統計値を含み、その内の１１８６０個は値が全く変化しなかった（約２５％）。
定数を発見するのはシンプルな手順である。与えられた統計値のすべてのサンプルが同じ数値を持つかどうかを確認すればよい。この探索は、各ウィンドウで個別に、統計値に対して行われる。これは、サンプルが複数のウィンドウに分割されていない場合にのみイントラアルゴリズムの検索が合理的だとする前提の、例外である。実際、定数はStatsMinerで発見されるが、その規則は、StatsCompressorによって規則ファイルからロードされるわけではない。StatsCompressorは自身で定数を発見する（５．８．１項参照）。
定数統計値（例えば和）間の相関を発見するのは、値が変化する統計値の場合と比べると非常にシンプルな作業だが、そのような内的相関は、圧縮という観点からはあまり有用ではない。さらに、定数統計値間の相関を説明する規則の数は膨大になる。そのため、StatsMinerでは、ウィンドウの生成直後に定数統計値を発見し、そのウィンドウ上では、それ以上その統計値をマイニングに用いることはない。
ウィンドウの例（図１９）では、 stat_etaという定数が発見される。
このアルゴリズムは、８秒間動作して、Customer Logs用に（計）１５４０２３個の規則を作成した（分析されたウィンドウ１つ当たり平均３３１５２個）。LRTにおけるマイニングの結果、３８秒間で（計）１１７３１０個、分析されたウィンドウ１つ当たり３６６３３ 個の規則が発見された。この結果については４．９項で述べる。発見された規則の有意性についても４．９項で述べる。
4.8.2. 共通する部分列の発見
統計値の中には、サンプルの同一の部分列が定期的に出現するものがあり、これらは良い圧縮対象である。一方で、このような分析は、gzip、bzip2、 xz等のあらゆる汎用コンプレッサですでに行われているため、圧縮という観点からは、StatsMinerでこのような関係性を掘り起こしても意味がない。しかし、もし規則が圧縮以外の手段に利用できるのであれば、共通する部分列を探す価値があると思われる。これは、前述のコンプレッサと同様に辞書を使って行うことができる（LZ77、LZMAアルゴリズム）。
4.8.3. まとめ
イントラアルゴリズムは、本論文ではあまり論じていない。しかし、値間の相関を探すアルゴリズムが迅速かつ効率的に動作するために、定数を発見することは極めて重要である。
4.9. まとめ
図２１は、StatsMinerのパフォーマンス結果をまとめたものである。
なお、ＣＬ集合の分析では、約２４９のウィンドウが生成されるはずだったが、発見された規則が利用可能なすべてのメモリを使用する可能性があった。そのため、（予定していた５０個ではなく）３０個のデータベースしか使わなかった。３３番目のデータベースの分析で、マシンのメモリ（４８ＧＢ）を交換してStatsMinerがだめになった。
ＣＬ集合について作成された規則の数は、LRT_A集合よりも２倍多かったが、分析されたウィンドウの数は５分の１だった。この理由は複合的なものである。まず、LRT_A集合はテスト中に作成された統計値に基づいて構築され、これは正常なHYDRAstorの動作をシミュレートしたものである。しかし、ＣＬ集合は顧客からの実際のデータで構成されており、顧客のシステムは異なる動作をする場合もある。さらに、顧客ごとに独自のHYDRAstor使用パターンがあるため、２つの同様なインストールであっても、それぞれ固有の相関を持つ大きなグループとなる可能性がある。また、ＣＬ集合は、様々なパッチを適用した異なるバージョンの HYDRAstorによって収集された統計値を含む。この観点から、LRT_A集合に関する結果は、特定のバージョンのHYDRAstorからの統計値を分析した場合にStatsMinerがどのように行動するかを示し、ＣＬ集合での実験は、異なるバージョンのシステム上での相関の発見を行うものである。
興味深いことに、CL集合におけるウィンドウ１つ当たりに作成された同一性規則の数は、LRT_Aと比べて２倍の大きさである。さらに、分析されたウィンドウの数が両集合で同一の場合、CL集合での同一性の発見は約１００秒かかるため、 LRT_A集合と比べて２倍の時間がかかる。CL集合で、これほど多くの同一性が発見された理由はよくわからない。HYDRAstorで実際に利用されているのは、Long Running Testによってシミュレートされた動作の小さな部分集合だけなのだろうか? 幸いなことに、同一性が多いことは間違いなく正しい。なぜなら、同一性の圧縮が最も効果的だからである（５．９．３項参照）。
和の規則の数量は、他の相関を合わせた数量よりもはるかに大きい。しかしこれは、保存の規則の組み合わせを用いた結果としての錯覚である。ウィンドウ内に同一性が多く発見されるほど、多くの和の規則が作成される。このことはＣＬ集合から明らかである。
発見された規則の分析を完全なものにするために、図２２について説明する。このプロットは異なるタイプの規則の最小限の有意性を示しており、Ｘ軸が最小限の有意性を表し（定義については４．３章を参照）、Ｙ軸は所定の最小限の有意性を持つ規則の割合を表している。このプロットは次のように理解される：最小限の有意性が０．３で規則４０％の点があるとすると、これは発見された規則の４０％が数２１を持つことを意味する。このような情報は、有意性が最も高い規則のみを顧客のサイトに移すといった場合に、非常に役に立つ（１参照）。
全般的に、図２２を見ると、有意性がなだらかに減少しており、確かに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集合の値は８５９９１４０だったが、CL集合はわずか６７７４３９０だった（２１％少ない）。
StatsMiner（全体）のパフォーマンスは、現在のところ期待を下回っている（ＣＰＵおよびメモリ使用量の両方で）。しかし、このソフトウェアはプロファイルされておらず、十分な調整すらされていない。最大のボトルネックは、規則を保存する方法である。組み合わせのアプローチを用いるということは、膨大な数の規則をメモリに記憶することを意味する。残念ながら、内部のデータ構造の効率が十分でないことがわかった。StatsMinerはセミプロトタイプのソフトウェアとして作成されたものであるため、問題があることに驚きはない。
まとめると、StatsMinerは期待に沿うものであった。実際には、設計されたマイニングアルゴリズムの小さな部分集合しか実装されていないが、その規則の数と有意性により、このツールのコンセプトが正しいことがわかる。興味深いのは、メモリがStatsMinerのボトルネックだということだ。現在は、これらの制約にぶつからないようにするために、１つのバージョンのHYDRAstorによって収集された統計値について、分析を行う必要がある。さらに、各顧客の統計値間の相関に関するマイニングを別々に行うことで、最も良い結果が出るかもしれないが、当然、多くの資源が必要となるため、現実的ではない。規則の保存方法をより良いものにすれば、メモリ消費量を減らすこともできるだろう。この問題は、新たなタイプの相関を発見できるようにしたり、ランダムウィンドウのコンセプトを導入するといった、このツールの機能性の拡張を行う前に、解決するべきである。
第５章 コンプレッサ
本章ではStatsCompressorの説明と評価について述べる。StatsCompressorはHYDRAstorシステムで作成された統計値を含むファイルを、相関に基づくアプローチとドメイン知識を用いて圧縮するためのツールである。
本章は次のセクションで構成される。
５．１ 「概要」ではStatsCompressorの全体概念と前提を述べる。
５．２ 「テストベッド」では、本章で用いるテストデータとテスト方法について述べる。多くの実験結果を示しており、これは重要である。
５．３ 「StatsCompressorの基本結果」では、テストデータに対してStatsCompressorを用いて達成可能な最も良い結果を提示する。他の実験結果と比較する、基本となる結果である。
５．４ 「外部コンプレッサ」では、StatsCompressorによって生成されたファイルをさらに圧縮処理するために使用できると思われるツールについて説明する。このツール自体は相関に基づく圧縮しか行わないからだ。
５．５−５．９ これらのセクションではStatsCompressorが使用する圧縮方法の説明と評価を述べる。
５．１０ 「相関に基づく圧縮の使用の他のモデル」では、StatsMinerとStatsCompressorの協働方法について概説する。その目的は、別のバージョンのHYDRAstorで取集された統計値を圧縮するために一連の規則を使えるようにすることである。第３章で触れたモデルにおける使用と、新たなアプローチとの双方の方針について述べる。
5.1 概要
StatsCompressorという、設計され実装されたコンプレッサは、Zstatファイルの無損失圧縮のためのツールであり（２．３．２項を参照）、本論文で述べる研究の一部として作成されたものである。通常のZstatファイルを入力として受け取り、出力としてZplusファイルを作成する。ZplusファイルはZstatファイルと非常に似ており、両者は比較可能なものである。このツールが行う圧縮は、バイトレベルの方法を使用しない高度なものであり、ドメイン知識（主に統計値間の相関）と、圧縮ファイルのシンプルなテキスト変換に基づく。作成されたZplusファイルは、外部の汎用コンプレッサを用いて更に圧縮する必要がある。
このツールはＣ＋＋で記述され、Linuxのオペレーティングシステムで動作する。Ｃ＋＋を使用する理由は、このコンプレッサは正常に動作している顧客のマシン（Ｌｉｎｕｘのオペレーティングシステムで動いている）上で動作することからＣ＋＋で高いパフォーマンスが期待できるからである。特に、バックアップデータをシステムに書き込む間に動作するため、ＣＰＵとメモリの消費量を最小限にする必要がある、一方、研究の過程で効果の高いソフトウェアを作成するのは難しいため、当初のコードはプロトタイプとして扱った。製品化の段階で書き直す（実質的には一から書き直す）必要がある。Ｃ＋＋でプロトタイプを作成するという手法は、リソースの最大利用という点で、最大限達成可能な圧縮率の測定を可能にした。ここで示す実験結果はすべて、この前提の観点から評価する必要がある。
5.2. テストベッド
5.2.1. テストデータ
StatsCompressorのパフォーマンステストはすべて、以下のデータ集合に対して実行された（StatsMinerの場合と同様）。
１．LRT_A−H4バージョン上でのLong Running Testからランダムに選択した５０個のZstatファイル。
２．LRT_B−H4バージョン上でのLong Running Testからランダムに選択した５０個のZstatファイルで、数２２。
LRTはLong Running Testの略で、このテストには約２週間かかり、HYDRAstorの正常な使用と窮状での使用との双方をシミュレートした。このシステムはバージョンH4で、１つのHNと４つのSNで構成される。このデータのソースはすでに選択されている。なぜなら、H4バージョンを使用している顧客からのデータはまだなく、これらのZstatファイルはHYDRAstorのモデルバージョンのスナップショットして扱うことができるからだ。以前のバージョンのHYDRAstorを使用した、顧客から取得したランダムに選択された統計値のファイルに関する結果は、第６章で説明する。
5.2.2. パフォーマンスの測定
StatsCompressorのテストは、StatsMinerと同じマシン、同じ方法で行われた（４．２．２項を参照）。
5.3. StatsCompressorの基本結果
図２３は、最大限達成可能な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ファイルの圧縮結果を示している。２．３．２項で説明したとおり、各Zstatファイルのラインの半分は既存の統計値の名前とメタデータを含む。メタデータの効率的な表示の問題はすでの解決されているため（２．３．２項を参照）、StatsCompressorは、サンプルの圧縮のみに焦点を当てている。「本体のみ」のセクションは、StatsCompressorの実際のパーフォーマンスに関する情報を提供する（ただし、StatsCompressorはメタデータを明示的に圧縮することはないが、少し異なる順序でメタデータをダンプし、統計値の識別子に多少の変更が伴うことがある（５．７．１項を参照））。
StatsCompressorの圧縮率は、−９パラメータでbzip2コンプレッサで動作させたときに最も良い圧縮率に達し、平均すると、Zstatファイル全体では４７．７８％（スペース節約は５２．２２％）、本体のみでは４２．７２％（スペース節約は５７．２８％）である。最も良い結果は、ファイル全体では４３．８％（スペース節約は５６．２％）、本体のみでは３３．４％（スペース節約は６６．６％）である。プロジェクト開始時はスペース節約２０％〜３０％を予想していたことから、これらの結果はすべての期待を超えるものであった。
しかし、StatsCompressorの圧縮率が最も良かったのは外部コンプレッサとしてbzip2を使用した場合であり、最も小さいファイルは、StatsMinerとxzコンプレッサの組み合わせにより出力された。
一方、現在のCPUとメモリの使用量は、StatsCompressorを顧客のサイトで実際に動作させるには大きすぎる。パフォーマンスを向上させる方法については、本章で後述する。
外部コンプレッサを使用しなかった場合の圧縮率（「noComp」の行）は大変興味深い。ファイル全体の場合、平均圧縮率は６４．４４％（スペース節約は３５．５６％）である。この結果は、特に、StatsCompressorがビットレベルで圧縮を提供せず、ZstatファイルとZplusファイルのフォーマットは冗長なテキスト表示を使用していたことから考えると、かなり良い結果に見える。この効果は、本体のみの場合の圧縮ではさらに強く、平均圧縮率は３０．６１％（スペース節約は６９．３９％）である。
ファイル全体の結果について、平均圧縮率に関する以下の現象が起こった。
bzip2 < gzip < noComp < xz
これは、StatsCompressorがZstatファイルのある部分を、gzipまたはbzip2がアクセスできない方法で圧縮することを暗示している、と解釈することができる。なぜなら、Zplusファイルをgzipまたはbzip2で圧縮した後はスペース節約が大きくなるからである。一方、xzの場合、zxはStatsCompressorが行った変換を、独自に処理できると考えられる。xzとbzip2との違いは統計的には重要でないが、図２４に示すように、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. 比較
図２４に、絶対圧縮率（下記数２４を示す。「StatsCompressorのみ」の行の値から、外部コンプレッサの使用が必須であることがわかる。図２５は、LRT_A集合からの生のZstatファイルを圧縮する、検討された外部コンプレッサの圧縮率とパフォーマンスを示している。これらは、StatsCompressorを使用しない場合の、正常な結果である。
図２５は、外部コンプレッサのパフォーマンスを示している。まず、xzツールが最も良い圧縮率を示しており、その優位性は圧倒的である。しかし、これは極めて高いメモリ消費量を使用して達成されたものであり、HYDRAstorで使用するには、この点が障害になる恐れがある。なぜならメモリは貴重な資源だからだ。一方、gzipは最もパフォーマンスの悪いツールである（ただし使用コストは安い）。この実験ではgzipとbzip2によって達成された圧縮率に大きな違いはない。ただしZplusファイルの圧縮では違いが大きい（図２４と比較）。この観点から、外部コンプレッサの最善の選択はbzip2と考えられる。xzはコストが高すぎるし、gzipの圧縮率は満足できるものではないからだ。なお、興味深い事実として、平均すると、フラグ-9はbzip2に対して所有する最も良い圧縮方法を使用するよう命令しているが、bzip2 -9はbzip2 -6よりも悪い結果となっている。
5.5. StatsCompressorのスキーマ
図２６はStatsCompressorを示す図である。このソフトウェアの各部は、以降のセクションで包括的に説明する。この図は、単一のZstatファイルに対して実行される動作のシーケンスを示している。構成要素の使用はプログラム引数または規則ファイルの制限によって制御することができる（例えば同一性の相関のみ使用）。
この図には「コスト」の概念が含まれる。本章でコストとは、まだ外部コンプレッサで圧縮されていないZplusファイルにおいて、特定の方法を用いて特定の情報を保存するのに必要なバイト数である。例えば、あるサンプルの値が「１２３４５」で、圧縮方法が選択されていない場合、このサンプルのコストは５である（このサンプルは「１２３４５」という人間が読める形式でダンプされるから）。コストを計算するこの方法には、基本的な欠点が１つある。Zplusファイルは外部の汎用コンプレッサで圧縮されることを考慮していないことだ。残念ながら、StatsCompressorでは、情報のダンプにかかる最終的な（外部圧縮後の）コストを決定することはできない。なぜなら、特定のデータに対する外部コンプレッサの圧縮率は、常にそのコンテキストデータによって決まるからだ。つまり、外部コンプレッサは、より大きなデータ表現（例えば「１＿２＿３＿４＿５」）を、より小さな表現（「１２３４５」）に対するものよりも小さなビット数に圧縮することはめったにない、という前提のもとで、StatsCompressorは構築されている。
圧縮のプロセスは以下の３段階から成る。
１．統計値の圧縮に様々な方法を試みる（５．８章および５．９章を参照）。
２．統計値の圧縮に最適な方法を選択する（５．６章を参照）。
３．符号化を最適化する（５．７章を参照）。
5.6. 相関に基づく圧縮
StatsCompressorの最も重要な部分は、圧縮い使用する規則を選択するためのアルゴリズムである。規則には２つのタイプがあり、それは、発見されたルールを含むファイルからロードされるもの（５．９章を参照）と、StatsCompressor自身で発見したもの（５．８章を参照）である。実装されるアルゴリズムは最もシンプルなもので、次の２つのステップから成る：規則をスコア化し、スコア化した規則のどれを圧縮に使用するかを選択すること、である。
5.6.1. 規則のスコア化
規則をスコア化する最初のステップは、各統計に適用する最適な「トランスフォーマット（transformat）を選択することである。トランスフォーマットとは、StatsCompressor自身が発見した内的相関のことである（５．８．２項を参照）。わかりやすく説明すると、圧縮方法を使用せず、統計値のサンプルを明示的に書き込むことを、「０−トランスフォーマット」という。Zplusファイルでは、１つの統計値に１つのフォランスフォーマットのみを適用することができる（コストが最小限）。
次のステップでは、値間相関のコストを計算し、スコア化する。この「スコア」とは、所有するすべての規則間の線形順序の導入に使用される数値である。所定の統計値の圧縮に値間相関を使用することが合理的となるのは、相関のコストが最適なトランスフォーマットのコストよりも小さい場合のみである。この条件が満たされれば、規則がスコア化される。これには２つのアプローチがあり、それについて、これから説明する。説明を明確にするために、以下のように仮定する。２つの規則「ｒ１」と「ｒ２」があり、各々が異なる統計値を圧縮し、かつ
10 = cost(r1), cost(t1) = 15, cost(r1) < cost(t1)
12 = cost(r2), cost(t2) = 30, cost(r2) < cost(t2)
ここで、ｔ１とｔ２は、対応するｒ１およびｒ２と同じ統計値に適用されるトランスフォーマットである。
規則をスコア化する絶対コスト法
規則のスコアは次のとおり：
score(ri) = cost(ri)
上記の例では、ｓｃｏｒｅ（ｒ１）＝１０、およびｓｃｏｒｅ（ｒ２）＝１２。これらのスコアは次のオーダーを導入する：
規則をスコア化する相対コスト法
規則のスコアは次のとおり：
ここで、tiはriが圧縮の対象とする統計と同じ統計のトランスフォーマットである。上記の例の場合、
score(r1) = 0.625 and score(r2) = 0.4
となる。これらのスコアは次のオーダーを導入する：
実験から、相対コスト法の方がわずかに良く、平均的なStatsCompressorの圧縮率は、外部コンプレッサの使用に応じて、０．３％から０．６％ポイント高いことがわかった。
規則のスコア化には、平均５９３秒かかった（LRT_A/LRT_Aモデルの実験で）。このプロセスが長かったのは、スコア化すべき規則の数が多いことが原因である。Zstat１つ当たり平均で２７０９５９００個の規則をチェックした（図３３を参照）。なお、相関f = g + hは以下の３つのフォームで出現した（３つの異なる「規則」として）：ｆ＝ｇ＋ｈ、ｇ＝ｈ−ｆ、およびｈ＝ｇ−ｆ。チェックした規則のうち、４５２３４２０個（Zstat１つ当たりの平均）は、対応するトランスフォーマットよりもコストが低かった（したがって多くの規則が完全にスコア化された）。つまり、適用される規則のわずか１７％だけが（なぜならすべての予想された統計値がZstatファイルに出現する）、圧縮に利用することができる。さらに、図３３には別の結果が示されており、これについては５．９．２項で述べる。StatsCompressorの資源の利用を最小限にする方法については、５．９．４項と５．１０項でさらに掘り下げる。
5.6.2. 使用するスコア化された規則の選択
当初は、このステップは非常にシンプルなものだと思われた。スコア化された規則があれば、各統計について、最もスコアの低い規則を選べばいいからだ。特定の統計値に規則が適用されない場合は、トランスフォーマット（少なくとも「０−トランスフォーマット」）を使用すればよいと思われた。しかし、このアプローチには罠がある。ｆ＝ｇ、ｇ＝ｈ、ｈ＝ｆが選択されたらどうなるか？この場合、すべての統計値のサンプルの値がなくなり（ｆ＝ｇ等のため、ｆのサンプルは保存されない）相関に関する情報だけが残る。
StatsCompressorは、上記のアプローチの、より繊細なバージョンを使用する。スコアが最小の規則から始めて、すべての規則を調べる（スコアの線形順序が存在するため、可能である）。使用する規則は、以下の基準を満たす必要がある。
１．有向規則の左辺（統計値、この特定の規則を用いて圧縮することができる）が、他の規則によって圧縮されていない（より小さなスコアを有する）。
２．規則の使用により、適用される規則の有向グラフに循環を導入しない。グラフの頂点は統計値であり、エッジが統計値間の依存関係を表す。例えば、規則ｆ＝ｇを使用する場合、グラフにはエッジ数２８がある。したがって、和の規則ｐ＝ｑ＋ｒが、エッジ数２９と数３０を導入する。グラフはメモリに保存され、縦型探索アルゴリズムを使って循環の存在が検出される。
このアルゴリズムはグリーディである。実験により、許容レベルの圧縮を提供することはわかっているが、これがうまく機能しない例を構築するのは非常に簡単である。将来的には、この目的のためのより良いアルゴリズムを発見するために、もう少し研究する必要がある（または既存のものにヒューリスティックを追加する）。この問題はＮＰ完全ではないかと思われる。ただし、それを証明するものは構築されていない。グラフ理論言語でこの問題を表すのは難しいからだ。１つの試みとして、加重マルチグラフＧがある。Ｇから、いくつかのエッジを除去すると（所定の可能性リストに従って行う）、Ｇｔは非循環式で複数のエッジがなく、連結されてエッジのウエイトの和が最小になる。なお、個別に除去できないエッジもある（なぜなら全体として和の相関を使用すべきであり、これは少なくとも２つのエッジが存在することを意味する）。グラフGは１つの理論上存在する頂点を持つため、そこから他のすべての頂点へのエッジは、対象となる頂点（当然、統計値を表す）のトランスフォーマットのコストに等しいウエイトを有する。
実装されたグリーディアルゴリズムの実行には、Zstatファイル１つにつき平均１８秒かかった。つまり、このステップは規則の評価よりもはるかに速い。
5.7. 選択した相関の後処理
5.7.1 リナンバリング
リナンバリングは、圧縮率を改善するために、Zstatファイル内の統計値によって使用される識別子を交換するプロセスである。図２６によると、これは圧縮の最終段階である。ただし、これは抽象クラスの平坦化（flattering）の問題に触れる前に説明しておく。なぜなら、平坦化はリナンバリングを改良するために導入されたものだからだ。
Zstatファイル（Zplusも同様）内の各統計値は、自然数である独自の識別子を持つ。Zstatファイルにおいて、各識別子は確実に２回使用される（統計値の名前をそのサンプルにマッピングするため）。Zplusファイルでは、相関を保存する際に識別子が利用される。そのため、頻繁に出現するものもある。リナンバリングの目的は頻繁に出現する統計値に、より短い識別子をつけることである（つまりコスト削減となる）。LRT_Aの場合、最も頻繁な統計値の識別子は２５ ６７８回ダンプされた（平均で）。リナンバリングの時間は測定しなかったが、パフォーマンスに与える影響は無視できる程度である。なぜなら、このステップの複雑性はO(n log(n))だからだ（nは統計値の数）。
図２７は、リナンバリングを不能にしてLRT_Aに対して探索された規則を用いてLRT_A集合を圧縮した結果を示している。これによると、リナンバリングは非常に重要なステップである。なぜなら、これがないとStatsCompressorの圧縮率が大きく下がるからだ（少なくとも１１パーセントポイント）。相変わらず、xzはこの問題に苦しめられることがない。本体のみの圧縮の場合、統計値の名前を有する行がないという事実により、この問題は見えなくなる。驚くことに、リナンバリングを不能にすると、平均のＣＰＵ使用率がわずかに大きくなるのだが、これを説明するのは困難だ。
実際には、このステップは解凍で回復することができない２つの内の１つである。なぜなら、Zplusファイルには、古い識別子を新しいものにマッピングする辞書が含まれないからだ（必要がなかった）。一方、ZstatにZplusと互換性を持たせるために、すでにZstatファイルで使用された古い識別子から、新たな識別子が選択される。すべてのZstatファイルにおいて、最小の識別子はせいぜい５６８であることは興味深い。StatsCompressorの製品化バージョンでは、新たな識別子は１から始めるべきである。
5.7.2. 抽象クラスの平坦化
抽象クラスの平坦化の目的を説明するには、新たな概念を取り入れる必要がある。ｆ、ｇが異なる統計値を表すとする。ｉｄ（ｆ）＝ｘは、統計値ｆがＺｐｌｕｓファイル内で識別子ｘを得ることを意味する。
第２の規則（５．６．２項参照）を選択するためのアルゴリズムが機能する方法は、例えば抽象クラスＡ＝ｆ０，ｆ１，ｆ２，ｆ３の圧縮には、以下の規則が選択されることを意味する：ｆ１＝ｆ０、ｆ２＝ｆ１、ｆ３＝ｆ２。しかし、これは最適ではない。なぜなら、ｘ、ｙ、ｚおよびｘ＝ｉｄ（ｆ０）、ｙ＝ｉｄ（ｆ１）、ｚ＝ｉｄ（ｆ２）＝ｉｄ（ｆ３）という、少なくとも３つの異なる識別子を使用する必要があるからだ。最適なアプローチは、抽象クラス全体を以下のようにコード化することである：ｆ１＝ｆ０，ｆ２＝ｆ０，ｆ３＝ｆ０。なぜなら、ｔ＝ｉｄ（ｆ０）という１つの識別子だけが後で使用されるからだ。ｔ＝ｉｄ（ｆ０）＝ｉｄ（ｆ１）＝ｉｄ（ｆ２）＝ｉｄ（ｆ３）となる。なお、その場合は、統計値ｆ１、ｆ２、ｆ３の当初の識別子を得ることはできない。しかし、それは必要ではない。
抽象クラスの表現を最適化するプロセスを「平坦化」という。なぜなら、その目的は、抽象クラスの符号化に使用する規則のツリーの高さを低くすることだからである。最適なツリーの高さは１なので、各抽象クラスは１つの代表値を持つ。これを処理するために、Find-Unionアルゴリズムを使用する。最初に、各統計値がシングルトンの集合を形成する。統計値間に厳密な同一性がある場合は、適切な集合同士（この統計値の代表的な抽象クラス）が結合される。最後に、各集合は１つだけ代表値を有し、これが使用される（前段落に記載の例ではｆ０）。これ実際にはBoost Disjoint Sets ライブラリが使用された。この複雑性はO(数３１)であり、数３２は逆アッカーマン関数、ｎは統計値の数、m＝O（１）で、分析される規則の集合に依存する。完全なLRT_A/LRT_Aを用いた実験では、このステップには平均０．７秒かかった。
図２８に、抽象クラスの平坦化を不能にして、LRT_Aについて発見された規則を用いてLRT_A集合を圧縮した結果を示す。スペース節約は非常に小さく、平均２〜３パーセントポイントである。xzコンプレッサにとって、平坦化を可能にすることが非常に重要であることは興味深い。抽象クラスの平坦化には、Find-Unionアルゴリズム用のデータ構成を構築する必要があるため、ＲＡＭを約１４ＭＢ使用する。
5.8. 内部知識に基づくアルゴリズム
StatsCompressorは、自身である種の相関を探索する。高速でマイニングを行うため、パフォーマンスに悪影響を与えることはない（このソフトウェアにとっては極めて重要である）。
5.8.1. 定数の圧縮
すべてのZstatファイルに含まれる統計値の約２４％は定数である。この種の（内的）相関は、規則ファイルには入らないため、StatsCompressorは自身でこれらを探さなければならない。このプロセスは４．８．１項で述べたものと同様である。
すべての定数統計値が識別されると、抽象クラスにグループ化される（その値に基づく）。例えば、クラスｆ＝ｇ＝ｈがある。各クラスは１つの代表値を持つが、それはサンプルが最も少ない統計値である（例えばｆ）。抽象クライスの各メンバーについて、統計値と抽象クラスの代表値との間の関係を説明する、同一性規則（規則ファイルからロードされた同一性の場合と同じ）が作成さる（この例ではｆ＝ｇとｆ＝ｈ）。なお、代表値でない統計値間には規則は存在しない（規則ｇ＝ｈはない）。このアプローチは、このステップで作成される規則の数を最小限にするために用いられた（抽象クラスは非常に大きいため、実際の規則を記憶する方法の組み合わせを用いると数千もの規則が生成されることになるが、そのわずかな割合しか使用されない）。
定数の発見にかかった時間は平均してわずか０．６１秒だったが、StatsCompressorの圧縮率に重大な影響を与えた。図２９は、定数の圧縮のみを実行したStatsCompressorでの実験結果を示す（他の圧縮方法は使用しなかったが、後処理はアクティブだった）。スペース節約は、外部コンプレッサの使用に応じて変動があり、ファイル全体の圧縮の場合は９．６１％から１２．６９％まで様々であり、本体のみの圧縮の場合は６．４８％から８．６７％まで様々であった。スペース節約については、後処理として統計値のリナンバリングを用いるためファイル全体の方が大きかった。そのため、Zplusファイルの最初のセクションからの、名前から識別子へのマッピングにはエントロピーが少ししか含まれておらず、異なる識別子の数が少なかった。
5.8.2. トランスフォーマット
すでに述べたとおり、内的相関を用いて統計値のサンプルを圧縮する方法を「トランスフォーマット」という。このような相関は、現在StatsCompressor自身によって発見される。各統計は、１つのトランスフォーマットを用いて圧縮することができる。これは、他の圧縮方法が使えない場合に行われる（詳細については５．６．１項を参照）。StatsCompressorは、各統計値について常にすべてのトランスフォーマットを計算し、最適なトランスフォーマットを決定する。これらの計算は非常に速い。
トランスフォーマットの説明には以下の概念を用いる：
ｓ：統計のサンプルのシーケンス
ｓｉ：シーケンスｓのｉ番目のサンプル
Ｔｉ（ｓ）：トランスフォーマットｔをシーケンスｓのｉ番目のサンプルに適用した結果
０−トランスフォーマット
０−トランスフォーマットは、明確性のみの目的で導入され、次のステートメントが常に正になる：「ある統計値のサンプルをZplusファイルに（明示的に）ダンプする必要がある場合は、トランスフォーマットを使用する」。０−トランスフォーマットはいかなる方法でもサンプルを変換することはなく、Zstatファイル内に存在するのと同じように、値がそのまま保存される。
Ti(s) = si
差異トランスフォーマット
差異トランスフォーマットは、統計値の値は徐々に変化するため、現在のサンプルと以前のものとの差を保存すれば、両サンプルの値を保存するよりもコストが安い、という前提に基づく。差異は小さい場合が多いため、コストも小さくなる。また、同じ値が差異として現れることが多いため、外部コンプレッサで効率的に圧縮される。差異の計算を可能にするために、統計値の最初のサンプルより前の値は０と仮定する。この手法は、StatsCompressorにおける有限差分に対するあらゆる計算を利用し、例えば、統計値ｇのサンプルがあらかじめわかっている場合は、規則ｄｆ＝ｇを用いて圧縮された統計値ｆの解凍が可能となる。
T0(s) = s0 - 0 = s0
Ti(s) = si - si-1 i>0
ドミナント・トランスフォーマット（Dominant transformat）
ドミナントトランスフォーマットは、統計値の中にはほとんど値が変わらないものがあり、これらの統計値については、ドミナント値（dominant value）と偏差ベクトルを保存すればよい、という考えによって開発された。後者は、わずかな偏差ベクトルの符号化を利用すれば効率的に行うことができる（付表Ａを参照）。ドミナントトランスフォーマットの計算には、統計値のサンプルを２回読む必要がある。１回目のパスではドミナント（最も共通する値）を発見し、２回目に偏差を決定する。しかし、このパフォーマンスの結果からわかるように、シーケンスを２回スキャンしてもStatsCompressorのパフォーマンスに目に見える影響を与えることはない。
c − シーケンスのドミナント − sのサンプルのシーケンスで最も共通する値
Ti(s) = si−1 − c
トランスフォーマットの評価
図３０は、トランスフォーマットを唯一の圧縮方法として用いてLRT_A集合を圧縮する際のStatsCompressorの圧縮率を示している。スペース節約は素晴らしく、ファイル全体では１８．０６％−３０．８９％（外部コンプレッサの使用に応じて変動する）、本体のみでは２１．９１％−３６．２８％である。この論文で提案するドミナントトランスフォーマットと差異トランスフォーマットは非常にシンプルな方法であり、いかなる外部コンプレッサも、これと同じメカニズムをこれほど効率的な方法で利用していない。当然、前述のツールは、バイトファイルよりもテキストファイルで機能するよう調整されているが、まだ改良すべき点がある。なぜなら、スペース節約の潜在能力は莫大であり、今では、プレーンテキストを含むファイルはより一層一般的になっているからだ（例えばJSONフォーマット）。
差異トランスフォーマットは、ドミナントのものよりも、より頻繁に使用される。これはすでに予測されていた。図３１を参照。しかし、驚くべきことに、ドミナントトランスフォーマットは、理論上は差異トランスフォーマットと非常に類似する条件のもとで使用されると思われるのだが、ドミナントの方が最良である場合が多い。良く機能すればするほど、偏差の数が小さくなる。もう１つの興味深い事実として、０−トランスフォーマットは、ほとんど使用されることがなかった。つまり、膨大な変動がある統計値は、ほんのわずかであったということだ。
差異トランスフォーマットおよびドミナントトランスフォーマットのいずれも、同じ方法で構築される。サンプルの値と、実際の値と予測値との差異の予測に使用する機能がある。当然、予測には他にも多くの機能ファミリーがあり、機能ファミリーのどれを使用すべきかの決定をStatsMinerがチェックし、StatsCompressorは数値的方法を用いてこれらの機能の係数を計算する。実際のところ、機能を現実のサンプル値に合わせるという全般的なアイデアは新しいものではなく、例えばFree Lossless Audio Codec (FLAC)（参考文献[CF13]）に記載されているように、すでに圧縮に使用されている。
5.9. 外部知識の使用
規則のファイルは、外部知識のソース、すなわちStatsMinerによって発見された相関である。このセクションでは、これらの規則の使用に関する分析、つまり、StatsCompressorのパフォーマンスにどのような影響があり、将来的にどのような問題を解決する必要があるのか、という点について述べる。
5.9.1. 偏差ベクトル
StatsCompressorの最も重要な特徴の１つは、数値的に合わないものでも相関を使用する能力があることである。そのため、サンプルの実際の値と、相関の使用による予測との間に偏差がある。これは、StatsMinerは厳密な相関のみを発見するが（特に実装されたバージョンでは）、StatsCompressorは弱い相関を用いることができることを意味する。そのような偏差の符号化方法については付表Aに記載する。図３２は、偏差ベクトルが不能な場合、したがって厳密な相関のみが許容された場合の、StatsCompressorの圧縮率を示している。これはトランスフォーマットが切られていることを意味する（０−トランスフォーマットを除く）。なぜなら、偏差ベクトルがきちんと動作する必要があるからだ。ここからわかるとおり、StatsCompressorが良好な圧縮率を達成するためには、特に外部コンプレッサを用いる場合は、偏差ベクトルの使用が極めて重要である。一方、この結果から、（本論文で述べている）相関に基づく圧縮というアイデアが合理的であることも証明される。なぜなら、最良の外部コンプレッサ（xz -9）を使用しても、スペース節約はゼロではなく、ファイル全体では１４．９％、本体のみでは１２．６８％となっているからだ。実は、２番目の結果が、さらに重要である。なぜなら、サンプルのシーケンスのみを含むZstatファイルの一部に該当するからだ。この点はStatsCompressorにとっては最も興味深い。
偏差ベクトルの使用は、ＣＰＵ消費量にはそれほど影響しない。反対に、メモリ使用量は影響を受けるが、これは実装に依存するため削減することができる。現在のバージョンのStatsCompressorでは、規則のスコア化の際に計算される偏差ベクトルは、たとえ使用できるものであってもメモリに保存されている。
5.9.2. 外部知識規則の使用のパフォーマンス
StatsMinerは数百万もの数の規則を簡単に作成することができる（４．９章参照）。そのため、これらの知識をStatsCompressorがどれくらいうまく利用できるのか、興味深い。図３３は、LRT_A集合に対して発見された規則でLRT_A集合を圧縮する際に、規則ファイルからロードされた規則の使用の統計値を示している。
なお、同一性に関する結果には、定数の圧縮のためにStatsCompressorが内部で生成した規則が含まれる。これは、StatsCompressorは定数統計値の同一性規則を作成しないという事実によるものである。そのため、この種の規則を含まないとStatsCompressorの誤ったイメージができてしまう恐れがある。なぜなら、統計値の中には、前述の同一性規則がないと圧縮が極めて非効率的になるものもあるからだ。例えば、数３３、数３４の場合、ｆ＝ｇの符号化」ではなく規則ｆ＝ｇ＋ｄｇを使用することがある。定数の符号化のためにStatsCompressorが作成する規則の数は比較的小さく、統計値の数と同じぐらいしか規則はない。そのため、外部知識の規則の評価をそれほど混乱されるものではないが、これらがないと、結果が全く真実ではなくなってしまう。
図３３の説明
結果について述べるまえに、図３３で使用したカテゴリーについて説明する。
・All statics（全統計値）−分析されたZstatファイル内の平均統計値数。
・Non-const static（定数でない統計値）−分析されたZstatファイル内の定数でない統計値の平均数。
・Loaded rules（ロードされた規則）−規則ファイルからロードされ、圧縮に使用されると思われる、Zstatファイル１つ当たりの平均規則数。Zstatファイルに、ある規則が使用するすべての統計値が含まれている場合、その規則を使用することができる。
・Tried to apply（適用を試みた）−スコア化された規則の数（５．６．１項を参照）。適用を試みた規則＞ロードされた規則。定数の圧縮のための生成された同一性規則は含まれるが、まず第一に、左辺と右辺を変えることで、既存の規則のほかに新たな規則が作成される（例えばf = g + hという規則がある場合、次の規則が作成される：f = g + h、g = h − f、h = g − f ）。このような規則を有向規則という。各有向規則は、１つの統計値（左辺にあるもの）を圧縮することができる。
・Having a good cost（コストが良い）−実際に統計値を圧縮することができる、Zstat１つ当たりの平均有向規則数、そのため前述の規則を用いて統計値を符号化するコストの方が、最良のトランスフォーマット（５．６．１項を参照）を用いて統計値を圧縮するコストよりも小さい。
・Not applied, cycling（適用なし、循環）−統計値のグラフに循環を導入するために用いられ、統計値の実際の値を回復することができない（統計値間の関係のみわかる）、Zstat１つ当たりの平均有向規則数。５．６．２項を参照。
・Not applied, lhs described（適用なし、lhs説明ずみ）−統計値の圧縮用にすでに他の規則が選択されているため使用されなかった、Zstatファイル１つ当たりの平均有向規則数。５．６．２項を参照。
・Applied（適用）−圧縮に使用された、Zstat１つ当たりの平均有向規則数。同一性規則の列のカッコ内の数字は、規則ファイルから実際にロードされた同一性規則の平均適用数を示す（定数の圧縮のためにStatsCompressor自身が生成したものではない）。
・Evaluation time（評価時間）−Zstatファイル１つ当たりの、有向規則のスコア化にかかった平均時間（単位は秒）（５．６．１項を参照）。
・Choosing the rules（規則の選択）−Zstatファイル１つ当たりの、圧縮に使用する有向規則の選択にかかった平均時間 （５．６．２項を参照）。
なお、有向規則間には次の関係が保たれる：
Having a good cost = Applied + Not applied...
外部知識に基づく規則の使用のパフォーマンスの分析
まず、大変多くの規則が規則ファイルからロードされ、（平均）Zstatファイルに適用されることは、非常に有望なことである。しかし、有向和規則の数が著しく多くなり、和の評価にかかる時間が、同一性規則に対する同様の作業にかかる時間の８０倍長くなることから、これはStatsCompressorのパフォーマンスにおいて主な問題点になると思われる。驚くべきことに、圧縮に使用する規則の選択は、評価よりも複雑だと思われたが、和の規則の評価よりもはるかに速く実行できる。これは、ＣＰＵのキャッシュの利用の向上、SIMD命令の利用などによって、評価フェーズのコードが改良されたものと考えられる。
コストが良好な（適用する価値がある）規則の数も印象的であり、相関に基づく圧縮には大きな潜在能力があることがわかる。同一性規則の４４％、和の規則の１６％にすぎないことから、圧縮率をそれほど下げなくても、規則ファイルのサイズを小さくすることができると思われる。この点については５．９．４項で述べる。（有向）規則が適用できない主な理由は、対象となる統計値がすでに他の規則によって圧縮されていることである。この状況は重要な意味を持つ。まず、規則を選択するアルゴリズムを改良すれば（５．６．２項を参照）圧縮率が向上する可能性がある。その一方で、同じ統計値を圧縮するのに様々な方法があることが多いため（他の様々な統計値と相関がある）、統計値間に大きな抽象クラスがあることも意味する。循環が出現することで、規則の適用に比較的少数の失敗が発生することは、少数の抽象クラスに関する情報と解釈することができるが、実際には、左辺がまだ圧縮されていない限り、規則はこの条件でしかチェックされないため、この値を解釈するのは難しい。しかし、この結果の値がどんなに大きくても、このチェックがなければ、適切に解凍できない統計値が数多く存在することになる。
当初は、適用される規則の数がZstat file１つ当たり平均４２０１０個、平均４８９４０個の統計値を含むことから（つまり統計値の８６％は相関を用いて圧縮される）、膨大な数だと思われた。一方、平均４１００８個の規則が定数統計値を圧縮し、これらはStatsCompressor自身によって生成された。しかし、これはなかなか良いニュースである。なぜなら、StatsMinerで定数を落とすのは正しい決定であったことが証明されるからだ。そうでなければ、規則ファイルは膨大な数になり、StatsCompressorは今よりもはるかに遅くなる。したがって、ファイルからロードされる規則の適用数（計６５９８）を、定数でない統計値の数（１４５２８）と比較し、統計値の４５％はその相関を用いて圧縮されている。確かに、より多くの種類を相関を探索してStatsMinerを拡張したり、またはウィンドウの生成において、提案された理論的により良いアルゴリズムを実装すれば（４．３．１項参照）、この結果は改善される可能性がある。適用される規則の数は増えるが、現在、和は統計値の７％に適用されており、どの程度増えるかを予測するのは難しい。この種の和（３つの統計値のみで構成される）はあまり洗練されたものではなく、より多くの統計値の和があると考えられる。その一方で、相関の方程式が複雑になればなるほど、そのような規則の適用にかかるコストが高くなる。なぜなら、その規則もZplusファイルに記憶する必要があるからだ。
まとめ
外部知識の規則（ファイルからロードしたもの）は、圧縮に利用されることが多いため、StatsCompressorにとって重要である。StatsMinerでより多くの種類の相関が発見されれば（または既存のアルゴリズムを改良するだけでも）、StatsCompressorによる圧縮率が必ず改善されるであろう。なぜなら、今は、圧縮されていない統計値のグループがあるからだ。しかし、現在、StatsCompressorにはパフォーマンスの問題がある。評価する規則があまりにも多く（特に和の規則）、これらはもっと効率的に使用できると思われる。使用する和の規則数を減らす可能性について、５．９．４項で述べる。また、新たなシステムのアプローチについて、５．１０項で述べる。問題のあるStatsCompressorの内部アルゴリズムについては、５．６章で述べた。
5.9.3. 同一性および和の規則の重要性
前のセクションで、StatsCompressorのパフォーマンスを改善するために、使用する和の規則の数を減らすことを提案した。図３４は、LRT_A集合について発見された同一性規則のみを用いてLRT_A集合の圧縮を行った場合の、StatsCompressorの圧縮率を示している。カッコ内の値は達成された値と、全ての規則を使用した場合に得られる値との差を示す（完全なLRT_A/LRT_A実験にて。図２３を参照）。したがって、これらは圧縮にとって和の規則が重要であることを示している。
図３４に示すStatsCompressorの圧縮率を見ると、和の規則は、そのツールが達成する圧縮率に非常に小さな影響しか与えていないことがわかるが（ファイル全体で１．８％ 、本体のみでは２．３７％）、これを使用しないと、パフォーマンスが著しく改善される（ＣＰＵとメモリの使用量が許容範囲になるが、これはコンプレッサのプロトタイプにすぎない）。さらに、パフォーマンス結果の標準偏差が著しく減少するため、StatsCompressorの要件を簡単に予測できる。本体のみの圧縮の場合、xzコンプレッサは他のコンプレッサに比べて和の使用が最も重要であることは、興味深い。しかし、驚くべきことではない。この種の相関は外部コンプレッサ自身では発見できないため、何らかのデータを合計できるとは想定しないだろう。和を使用しない場合、StatsCompressorは影響を受ける統計値の圧縮に別の方法を使用し、xzはこの作業のいくつかを自身で行うことができると思われる。
和が使用されないため、そのかわりにStatsCompressorは同一性規則を適用する。平均して、通常よりも４１０個多くの同一性規則が適用される。このことは、和の規則が重要である証拠にもなる。なぜなら、すべて（平均１００２）が置換されるわけではないからだ。さらに、和の規則は統計値の２％にしか適用されないが、これがStatsCompressorの圧縮率を２％改善する。これは、他の相関も使用してみるべきだということを意味する結果である。もちろん、和の規則の利用に関連するパフォーマンスの低下は、現時点では受け入れられないものであり、改善されるべきである。
5.9.4. 和の規則数のランダムな削減
和の規則を使用しつつStatsMinerの時間とメモリ消費量を削減する、もっともシンプルなアイデアは、この規則の特定の量をランダムに削除することである。図３５は、すべての規則を使用した場合、すべての同一性を使用した場合、および和の規則数をランダムに選択した場合の、StatsCompressorの平均圧縮率とパフォーマンス結果の違いを示している。
図３５の結果から、当初に発見された和の規則のわずかな割合を用いることで、StatsCompressorの圧縮率をわずかに失うだけでStatsCompressorのパフォーマンスを著しく改善する可能性があることがわかる。和の規則の２０％を残すことは、良いトレードオフだと思われる。和の規則を使うことによってスペース節約の約４５％を失うという犠牲のもとで、ＣＰＵとメモリの消費量を減らすことができるため、和の規則を全く使わなかった場合よりも、６％高いだけである。削除された規則がＣＰＵおよびメモリの消費量と線形な関係がない、というStatsCompressorの奇妙な動作は、記憶の規則の組み合わせの形式を用いる影響だと思われる。規則のファイルは、各和の規則に含まれるすべての統計値の抽象クラスの積を含むからである。一方、このような良い結果が得られたことによって、圧縮に使用する規則の選択のために実装されたアルゴリズムは、シンプルなものだが、非常に効果的であることが証明される。
5.9.5. まとめ
外部知識に基づく規則を使用することの重要性を、図３６に示す。この表は、ファイルから規則をロードしない場合の、LRT_Aの圧縮のためのStatsCompressorの圧縮率を示している。カッコ内の数字は、類似しているがLRT_A（「完全なLRT_A/LRT_A」）において発見されたすべての規則のロードを可能にした実験結果との差異である。別の観点からみると、この表は、前述のソリューションの別のモデルの説明の一部と考えることもできる（５．１０を参照）。「StatsMinerがなかったらどうなるか？」という質問の答えである。
図３６の結果から、ファイルからロードした規則（つまりStatsMinerによって発見されたもの）を使用することで、StatsCompressorの圧縮率が改善され、ファイル全体では、外部コンプレッサの使用に応じて変動するが、平均６．７６％−１２．２２％ポイント、本体のみの場合は平均８．６５％−１４．３３％ポイント改善されることがわかる。興味深いことに、gzipよりもbzip2コンプレッサの方が、ロードされた規則の使用がはるかに重要である。なおxzによって生成されたファイルは依然として小さい。
このアプローチにおいて、このツールは素晴らしいパフォーマンスを見せており、StatsCompressorを注意深く実装することでさらに改善されると思われる。特に、メモリ消費量は著しく減るであろう。現在、多くのデータがメモリに保存されているが、要求に応じて簡単に計算することができるからだ。
要するに、外部知識に基づく規則を使用するとStatsCompressorの圧縮率を高めることができるが、スペース節約は、他のビルトインアルゴリズムの場合のように大きくはない。しかし、StatsMinerを改良するために様々な作業を行うことができると思われるため、結果もはるかに良いものになるだろう。１０パーセントポイントは実現可能だと考えられる。さらに、StatsCompressorのコードには、最適化が必要な部分があることがすでにわかっており、パフォーマンスも向上すると思われる。最後に、現在の結果は、現時点での研究としては満足できるものであると思われる。
5.10. 相関に基づく圧縮の使用の他のモデル
第３章で、この設計したソリューションの使用に関する、最も基本的な分散モデルについて述べた。顧客に送る規則を選択する方法、および外部コンプレッサの使用、という２つの点で、方針を採用すべきである。外部コンプレッサについては５．４章で述べた。５．１０．２項、５．１０．３項、および５．９．４項では、規則ファイルの作成に関する３種類のアプローチを述べる。そして、５．１７では、StatsMinerをStatsCompressorと統合するという、まったく異なるアプローチについて述べる。そこでは、規則の発見は顧客のサイトで、圧縮の直前に行うことになる。なお、StatsCompressorをまったく使用しない、というもう１つのアプローチについては５．９．５で既に述べている。
このセクションでは、相関に基づく圧縮の使用に関する別のモデルについて、簡単に説明する。
5.10.1. 圧縮の現実的な分散モデル
これまでのところ、結果はすべて、LRT_A集合について発見された規則を用いた（あるいは用いない場合もある）LRT_A集合の圧縮に関するものであった。この前提は、あまり現実的ではない。なぜなら実際のZstatファイルは、同じデータについて発見されたものではない規則を用いて圧縮されるからだ（このようなアプローチについては５．１７で説明する）。そのため、すでの分析した結果は「現在達成可能な最高のもの」と考えることができる。
図３７は、LRT_A集合について発見された規則を用いてLRT_B集合を圧縮するためのStatsCompressorの圧縮率を示している。これは現実をシミュレートしているが、設計されたソリューションの最も楽観的な使用ケースでもある。顧客のサイトでのデータ（LRT_B集合）が「練習用の集合」（LRT_A集合）について発見された規則を用いて圧縮され、双方が同じバージョンのHYDRAstorで生成されたものである。
図３７で示される結果は非常に良い。なぜなら、この現実的なモデルで達成されたStatsCompressorの圧縮率が、最良のモデルでの分析結果に極めて似ているからだ。０．５パーセントポイントしか悪くなっていない。当然、標準偏差は増加しているが、これは驚くことではない。入力データのエントロピーが増加しているからだ（同じファイルが探索されて圧縮されたわけではない）。このような良い結果を得るためには、偏差が許容されるされるものであることが有用だ。パフォーマンスは予想通りであった。ＣＰＵの使用量は増えたが（分析する偏差が多かった）、メモリ消費量は少なかった。なぜならLRT_B集合からのZstatファイルでは、LRT_A集合にみられる統計値のいくつかが存在しない場合があるからだ。
これらの結果は、前述したすべての実験の評価にとって非常に重要である。なぜなら、これまでに示した楽観的な結果がStatsMinerとStatsCompressorの使用に関する現実的なモデルの特性を述べる上でも、使用できると思われるからである。
5.10.2. 重要な規則の使用
StatsMinerは、最初に規則を探索し、その後、各規則が何回データに適用されるか、また統計値間の与えられた関係が正である頻度、についてチェックする。このチェックの結果を規則の有意性という（４．３章を参照）。この値は、相関がどの程度「良好」か、つまり、それが正である頻度、を示す。StatsMinerによって作成される規則は膨大な数になるため、すべてを顧客に送信することはできない。また前述のとおり、使用する規則が多すぎるとStatsMinerのパフォーマンスに悪影響を及ぼす。したがって、最高の有意性ファクタを持つ、最良の規則のみを顧客のマシンに転送することが合理的であると思われる。図３８は、使用する規則の有意性とStatsCompressorの圧縮率（達成可能な最良の結果と比較）との相関およびそのツールのパフォーマンスを示している。
図３８の結果によれば、所定の有意性を持つ規則を用いると、ＣＰＵとメモリ消費量の両方が著しく減っており、StatsMinerのパフォーマンスに強い影響を与えている。残念ながらStatsCompressorの圧縮率も低いが、リソース消費量の低下は、圧縮率の低下よりも、はるかに速い。この圧縮率の値を、StatsMinerによって発見された規則の使用の全般的な影響に関する情報を示す図３６と比較すると、優位性が８０％以上の規則を用いることが、規則ファイルのサイズ制限の方針にとって良い選択であると思われる。
なお、「最良の」規則が選択されているため、このような方法で作成された規則ファイルは、別のバージョンのHYDRAstorで収集された統計値を効率的に圧縮するために使うこともできる。
5.10.3. 既に使用された規則の使用
StatsMinerは数百万もの規則を作成するが、実際には、StatsCompressorは１つのZstatファイル当たり約６３％の規則しか圧縮に使用しない。規則の有意性に基づく規則ファイルの制限（５．１０．２項で説明した）は、StatsMinerからの知識に基づくものであった。図３９は同様のアプローチを示しているが、これはStatsCompressorの使用経験に基づくものである。サポートのサイトで、StatsMinerは練習用の集合（LRT_A）における規則を発見し、StatsCompressorは同じ集合上で動作して、発見された規則のどれを実際に使用するかを決定する。その規則だけが顧客に転送される。このアプローチの品質は、LRT_B集合を圧縮することで測定される。
図３９は、すでにLRT_A集合の圧縮に使用した規則のみでLRT_B集合を圧縮した場合のStatsCompressorの圧縮率を示している。カッコ内の値は、LRT_A/LRT_Aでの完全な実験から得た最良の達成可能率と比較した場合の圧縮率の低下を示しており、これらは非常に良いと評価することができる。なぜなら、圧縮率の低下は約１パーセントポイント程度だがパフォーマンスは著しく向上しているからだ。これはHYDRAstorのバージョンが似ているものであれば、StatsCompressorは別のZstatファイルの圧縮に同様の規則を用いていることを示している。しかし、標準偏差は５０％まで上昇しているため、このアプローチを使ってZplusファイルのサイズを予測するのは難しいが、それでもわずか３％−４％である。規則ファイルのサイズを制限する前記の方法は、非常に期待が持てる、現実的なものだと思われる。
なお、このような良い結果が出たのは、偏差ベクトルの存在が許容されたからであろう。規則は、弱い相関を表すものとして扱われた。使用された規則選択方法は、StatsCompressorが、サポートのサイトで実験用のファイルを作成したHYDRAstorと同じバージョンのHYDRAstorによって生成されたZstatファイルを圧縮する場合に、最も良く機能すると考えられる。一方、StatsCompressorは、優位性が最も高い規則を用いるよりも、この手法を用いて選択された規則の場合の方が、はるかに良いパフォーマンスを示す。
5.10.4. StatsMinerとStatsCompressorの統合
図１６に示すStatsMinerとStatsCompressorとの協働モデルは基本的なものであり、StatsMinerはＣＰＵ時間とメモリを多く必要とする。しかし、アルゴリズムはすでにStatsMinerからStatsCompressorへ移されており（定数の発見、５．８．１項を参照）、それほどパフォーマンスを損なうことなくStatsCompressorの圧縮率が向上するという結果を得ている。図４０は、より革新的なアプローチを示している。Zstatファイルごとに、顧客のサイトでStatsMinerのStatsCompressorの両方を実行する、というものである。両ツールが統合された状況を（ある程度）シミュレートしている。
図４０は、マイニングと圧縮の段階を結合し、顧客のサイトで各ファイルについてこの手順を個別に行った結果を示している。この結果を解釈する上で考慮する必要があるのは、StatsMinerとStatsCompressorはこのモデルを実行するために設計されたものではないため、パフォーマンス結果は非常に悪いということである。一方、StatsCompressorの圧縮率は、この方法において達成可能な最良ものものである。なぜならStatsMinerはまずすべての規則を発見し、最適なものを選択するからだ。これらのツールが統合されると、圧縮とマイニングがインターリーブされるため、同一性規則を用いて完璧に圧縮された統計値間の和の規則をマイニングすることはない。しかし、パフォーマンス結果が本来得られるはずのものより悪くても、顧客のサイトでのＣＰＵとメモリの使用が半分に減る。これは、StatsCompressorによって使用される規則の数に何らかの制限を設けなければならない理由を示す、もう一つの証拠である。このモデルでは、StatsCompressorの圧縮率は、達成可能な最良のもの（LRT_A/LRT_Aの完全な実験から得られるもの）と比較して約１．５−２．５パーセンテージポイント下がった。興味深いのは、この結果が、圧縮に使用された規則を用いて達成される結果（５．１０．３項を参照）よりも、わずかに悪いことである。ここからわかるのは、弱い規則を使用する可能性が、StatsCompressorにとっていかに重要であるか、ということだ。なぜなら、現時点では、StatsMinerは厳密な規則しか発見しない。結論は、StatsMinerにおけるランダムウィンドウの実装（４．３．１項参照）の優先度を高くするべきだ、ということである。標準偏差については、依然として低く、LRT_A/LRT_Aの完全な実験と比べてもそれほど違いがなかった。これは、Zplusファイルのサイズの予測が可能となるため、良い兆候である。
5.10.5. まとめ
このセクションでは、顧客のサイトに送信する規則の選択に関して（３．１章参照）、以下の様々な方針について説明し、評価した。
１．最も重要な規則の使用（５．１０．２）。
２．StatsCompressorで既に使用された規則の使用（５．１０．３）。
３．和の規則のランダムな選択（５．９．４）．
前述の方針を組み合わせて、規則ファイルが期待する特性を持つようにしてもよい（わずかに異なるバージョンのHYDRAstor（１）とはよく機能する、特定のバージョンのHYDRAstor（２）または最小サイズのものとは最も良い結果を出す（３）。
一方、StatsMinerとStatsCompressorとの協働に関するまったく異なるモデルについて、以下の研究を行った。
１．相関に基づく圧縮の分散モデル（５．１０．１）。
２．StatsMinerを全く使用しない（５．９．５）。
３．StatsMinerとStatsCompressorの統合（５．１７）。
各モデルは、達成可能な圧縮率とパフォーマンスとの間で、異なるトレードオフを必要とする。設計されたソリューションに課される制限によって異なるため、一番良いものを選ぶのは非常に難しい。また、作成されたソフトウェアは実験用のものであり、そのパフォーマンスは十分調整されていない。
最後に、LRT_A/LRT_Aの完全な実験の結果は他の実験結果との比較のベースとして使用できることが証明された。なぜなら、実際に用いられる場合のStatsCompressorの圧縮率とパフォーマンスは、これらの理想的なものと、それほど大きく変わらないからである（５．１０．１を参照）。
5.11. まとめ
StatsCompressorは、統計値を含むファイルを圧縮するための強力なツールである。特別なファイルからロードした相関（５．９章）または自身で発見した相関を用いて、データを圧縮する。このツールは、Zstatファイルのサイズを平均して半分に縮小する（最大で６６．６％）。残念ながら、このプロセスのパフォーマンスは非常に良いわけではなく、ＣＰＵとメモリの消費量が非常に高い。この点は、もっと慎重に実装して最適化し、より効率的な内部アルゴリズムの選択（５．９．５で概説した）またはStatsCompressorの使用に対するアプローチ全体の変更（５．１０）、によって改善することができる。
実装したソフトウェアの具体的な性質にかかわらず、圧縮に相関を用いることが良いアイデアだということが証明された。なぜなら、最も一般的なコンプレッサ（gzip、bzip2、xz）はこのような可能性を用いていないからだ。スペース節約は、StatsMiner（および適当な場合はStatsCompressor）の機能を拡張することで、向上すると思われる。
第６章 顧客から取得した実際の統計値での評価
相関に基づく圧縮は、Long Running Test(LRT)において収集された人為的な統計値だけでなく、実際の顧客から受け取った統計値（Customer Logs）でもテストされた。前述のとおり、このような統計値は、システムのパフォーマンスをチェックする必要がある場合、またはシステムが期待通りの動作をしないため潜在的なバグを調査する必要がある場合に、随時ダウンロードされる。そのため、このような統計値は特定のものであることが多い。本研究で設計されたソリューションは、主にこのような状況で使用されるものだが、あらゆる状態で使用することができる。このような理由から、Long Running Testの結果、およびCustomer Logの最も重要なものに限り、詳細な実験を行うことにした。このアプローチを行ったもう１つの理由は、顧客から受け取る統計値の量が非常に大きくても、すべてのファイルが適切なサイズのものではないからだ（小さすぎるものも、かなりある）。最後に、顧客から取得した利用可能な統計値は、HYDRAstorシステムの別のバージョンで生成されたものであった。このような一貫性のないデータで行った実験は、システムの特定のバージョンで作成された統計値で実験を行った場合よりも、少し悪い結果になると思われる。
6.1. テストベッド
6.1.1. テストデータ
テストはすべてCL_2というテストデータ集合に対して行われた。第４章ではCL集合を分析したが、数３６である。CL_2集合は、実際のユーザ（顧客）から受け取ったファイルの中からランダムに選択された５０個のXMLファイルを含む（CLは３０）。これらのファイルは、様々なパッチとアップデートがインストールされた、様々なバージョンのHYDRAstorシステムから生成された。このテストには、サイズが２MBから４MB、SNから生成されたものだけが認められた。選択されたファイルはZstatフォーマットに変換されており、これらのファイルは５００００個の統計値を含み、各々が１４０−２４０のサンプルを含む（ただし、１つのファイル内の統計値はほぼ同数のサンプルを有する）。
6.1.2. パフォーマンスの測定
テストは、StatsMinerのテストと同じマシン、同じ方法で行われた（４．２．２項を参照）。
6.2. 実験結果
図４１と図４２は、CL_2集合に対して、設計したソリューションを異なるモードで実行した結果を示している。１つ目の表（図４１）はStatsCompressorの平均圧縮率を示しており、２つ目の表（図４２）は結果の標準偏差を示している。カッコ内には、CL_2集合に対する実験の値と対応するLRT_A集合に対する実験との差を示す。列の名前は５．１０章で述べたモデルに対応する。
・楽観的−CL集合全体について探索された規則を用いたCL_2集合の圧縮。なお、数３７かつ|CL| = 30、|CL_2| = 50。規則はCL集合に対して発見された。なぜならCL_2上でStatsMinerを実行するとメモリ消費量が大きすぎるからだ（４０ＧＭ超）。同様の実験が、完全なLRT_A/LRT_Aで行われた−図２３。
・現実的−LRT_A集合全体について探索された規則を用いたCL_2集合の圧縮。類似する実験の結果が図３７に示されている。
・使用済み−LRT_A集合で発見された規則でLRT_A集合の圧縮に使用された規則を用いた、CL_2集合の圧縮。類似する実験の結果が図３９に示されている。
・規則なし−StatsMinerで作成した規則を使用しないCL_2集合の圧縮。類似する実験の結果が図３６に示されている。
・統合−現時点で圧縮されたファイルにおけるStatsMinerによって発見された規則を用いたCL_2集合の圧縮。類似する実験の結果が図４０に示されている。
パフォーマンス結果はStatsCompressorにのみ適用される。ただし、StatsMinerとStatsCompressorのパフォーマンスの和である「統合」モデルを除く。
6.3. 実験結果の分析
顧客から取得した統計値に対する実験結果は満足できるものである。前述のとおり、LRT_A集合とは違い、CL_2集合は様々なバージョンのHYDRAstorによって収集されたデータを含む。そのため、LRT_A集合に対する実験よりも結果が悪くなって当然である。しかし、損失はそれほど大きくなかった。ファイル全体では１．９２−７．４８パーセントポイント、本体のみでは３．９８−９．２３パーセントポイントであった。なお、CL_2集合からの統計値は、LRT_A集合からの統計値のサンプル（６０-１００）よりも、より多くのサンプル（１４０-２４０）を含む。そのため、ファイル全体の場合と本体のみの場合の圧縮結果の比率は異なる。達成された結果から、設計されたソリューションは、実際に使用されるケースでも合理的であることがわかった。
楽観的な結果は、達成可能な仮説的最高結果を示す。実際のところ、CL集合は、その部分集合（CL_2）から発見された規則のみを用いて圧縮された。完全なCL集合で規則が発見されていれば、StatsCompressorの圧縮率がそれほど向上することはないと思われるが（図３５、３８）パフォーマンスは著しく下がると思われる。現在のところ、「統合」モデルは「楽観的」モデルよりも結果の低下が少ないという特徴があり、もし「楽観的」アプローチにおける規則が完全なCL集合で発見されれば、これは逆になる可能性がある。
StatsCompressorの圧縮率の低下という点で最高の結果は、「統合モデル」で達成されている。これらは、最高の絶対結果でもある（ただし「楽観的」モデルを除く。楽観的モデルは、規則ファイルのサイズがあまりにも大きすぎて全く現実的でない。）使用するコンプレッサに応じて変動するが、最終的にZplusファイルはZstatファイルよりも２８％−４９％小さい。これは非常に良い結果である。残念ながら、パフォーマンスは非常に悪い。CL集合からのZstatファイルにおけるサンプル数が大きいことと関係があると思われる。一方、前述のとおり、StatsMinerとStatsCompressorは、（パフォーマンスに関して）このモデルで効率的に動作するよう設計されたものではないため、さらなる最適化を行うことができる。
「現実的な」モデルの結果は平凡だが、許容できるものである。しかし、損失がかなりあり、パフォーマンスが悪い（LRT_A集合に対する同じ実験よりは良いが）。本体のみの場合の低下があまりにも大きいことが気がかりである。外部コンプレッサ用のあらゆるモデルの中で最も大きかった。一方、「使用済み」モデルでの実験結果は満足できるものである。StatsCompressorの圧縮率の低下は実に大きいが、「現実的な」モデルよりわずかに小さく、パフォーマンスは非常によい。使用する規則数の制限に対するこのアプローチは、規則の作成とファイルの圧縮とでHYDRAstorシステムのバージョンが違う場合はうまくいかないが、最終的な結果は十分許容できるものである。このモデルの標準偏差が、使用した各外部コンプレッサとリソース消費のカテゴリーで低下したことは、興味深い。これは非常に良いことだ。標準偏差が低ければ低いほど、最終的なZplusファイルのサイズの予測が正確になるからだ。
「規則なし」のモデルに関する結果は、少し落胆するものである。このアプローチにおいて、StatsCompressorは各ファイルについて個別に分析を行ったのだが、ファイル全体での低下は５．０４−６．３１％であった。これは、各Zstatファイルのサンプルの量が多かったことと関係があると思われ、例えば定数の捜索がうまく機能しなかったのだろう。その一方で、顧客のHYDRAstorが、LRT_A集合についてのZstatファイルの生成に使用したものよりも以前のバージョンであったために起こった結果という可能性もある。最後に、HYDRAstorは、顧客の通常使用では、人為的なLong Running Testの場合と違う動作をする可能性がある。しかし、「規則なし」のアプローチの結果は、さらに、この論文で提案した方法はすべて、実際のな例においても良い圧縮率を得るために重要であり、StatsCompressorだけを使用したのでは十分でないことを証明している。
すべての実験結果の標準偏差は良いものである。圧縮されたファイルは異なるバージョンのHYDRAstorからきたものであったが、それほど増加することもなかった。これは、どのバージョンが使用されたとしても、このシステムで生成された統計値は類似していることを意味する。つまり、統計値の分析に基づく変則性の発見は合理的であることを意味する（少なくともStatsMinerで発見された相関を用いる場合）。
外部コンプレッサの選択については、StatsCompressorの圧縮率はbzip2ツールが最も高かった。
6.4. まとめ
顧客から受け取った統計値の圧縮に使用される、この設計されたソリューションで行った実験により、相関に基づく圧縮は実際にうまく利用できることがわかった。達成された結果は、例としての統計値を圧縮した場合よりもわずかに悪かったが、それでも満足できるものである。次の２つのアプローチが、他のものよりも著しく良い結果を出すことがわかった。１つはStatsMinerとStatsCompressorとの統合であり、２番目は、練習用の集合の圧縮にすでに使用した規則の使用である。最初の方法は、結果は良いが、パフォーマンスが悪かった。これを使用するには、このような動作をするために最適化された新たなツールを作る必要がある。２番目の方法は、パフォーマンスおよび圧縮率の両方が改善される可能性があると思われるため、さらに調査する必要がある。例えば、優位性が最も高い規則（ただし圧縮に使用されていないもの）で規則ファイルを拡張することを確認するべきである。
まとめると、この設計されたソリューションは実用的である。
第７章 関連研究
この論文は、発見された相関とドメイン知識を用いて、特定の種類のログの圧縮率を改善する方法を提案するものである。ここで提案したアプローチ、特に、サポートのサイトで相関を発見し、この知識を顧客のサイトで使用するというアイデアは、文献では提案されていないと思われる。しかし、この設計されたソリューションは、コンピュータサイエンスにおける、データマイング、圧縮、ログ分析、といった十分に研究されたいくつかの領域の交点に位置すると考えられる。
ログの圧縮は長い間研究されており、特に、スーパーコンピュータ（文献[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で使用する規則の数を制限する方法を改善するために採用できる可能性がある。実際、本論文で使用される有意性の概念は「信頼性」と非常に似たものであり、信頼性は関連性規則の世界に由来するものである。さらに、「サポート」という用語は、すべてのウィンドウ数に対する、相関が発生する可能性のあるウィンドウ（なぜなら予想統計値が存在するから）の割合に対応する。
まとめると、データマイニングツールによって発見された数値的相関を使用して、別の（または同じ）一連のデータを圧縮するというアイデアは、新しいものであると思われる。
第８章 まとめ
本論文は、統計値の圧縮に対する、分散型のデータマイニングに基づくアプローチを示したもので、その統計値はある種の集合ログである。２つのツールが実装されており、それらは、統計値間の相関を探索するStatsMinerと、StatsMinerによって作成された規則を用いて統計値を含むファイルを効率的に圧縮するStatsCompressorである。両プログラムは、分散モデルで動作すること意図している。StatsMinerはサポートのサイトでデータ例に対して動作することで相関を発見し、StatsCompressoは顧客のサイトで動作する。これらのツールの協働に関するその他のモデル、例えば顧客のマシンのみでソフトウェア全体を動作させるモデル、も評価した。
達成された圧縮率は、あらゆる期待に沿うものである。平均すると、最も楽観的なモデルで、StatsCompressorはスペース節約を増やすことができ、bzip2コンプレッサと併用した場合は約５０％、gzipコンプレッサと併用した場合は約４５％、xzコンプレッサと併用した場合は約３０％、増えた。より多くの種類の相関の発見を目的とする、StatsMinerのための拡張を実装することによって、この結果をさらに向上させることが可能だと思われる。一方、実装されたソフトウェアのパフォーマンスは期待を下回るものである。ただし、これはプロトタイプのバージョンであり、パフォーマンスのボトルネックが特定され、予備的なソリューションがいくつか提案された。
統計値間の相関を発見するためのツールであるStatsMinerは、変則性検出のソフトウェアの基礎としても使用することができる。
この論文に記載した結果のいくつかは、NECのHYDRAstorに導入する計画がある。このプロジェクトでの研究は、HYDRAstorサポートチームが実際に直面した問題によって開始され、その問題はここで提案したアイデアを用いることで解決できると思われる。
＜付記＞
上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明におけるデータ圧縮システムなどの概略を説明する。但し、本発明は、以下の構成に限定されない。
（付記１）
収集した所定のデータの集合から当該所定のデータの集合内のデータの関係に基づいた相関関係の候補を少なくとも１つ抽出する相関関係抽出手段と、
前記所定のデータの集合内のデータが、前記相関関係抽出手段が抽出した前記相関関係を満たすか否かを検証する相関関係検証手段と、
前記相関関係検証手段による検証結果に基づいて、前記相関関係を用いて前記所定のデータの集合を圧縮するデータ圧縮手段と、
を備える、
データ圧縮システム。
（付記２）
付記１に記載のデータ圧縮システムであって、
前記所定のデータの集合内の各データのそれぞれは、少なくとも１つ以上のデータの値を有するデータ群であり、
前記相関関係抽出手段は、前記所定のデータの集合内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出する、
データ圧縮システム。
（付記３）
付記２に記載のデータ圧縮システムであって、
前記相関関係抽出手段は、複数の前記データ群を構成するデータの値の個数がそれぞれ同数である局所化探索範囲を少なくとも１つ生成して、当該生成した局所化範囲内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出し、
前記相関関係検証手段は、前記相関関係抽出手段が生成した複数の局所化探索範囲内のそれぞれのデータ群が、前記相関関係を満たすか否か検証する、
データ圧縮システム。
（付記４）
付記２又は３に記載のデータ圧縮システムであって、
前記相関関係抽出手段は、予め定められた種類の相関関係の候補を抽出した後、当該相関関係を有するデータ群を前記局所化探索範囲から排除し、当該排除後の局所化探索範囲内で前記データ群の関係に基づいた相関関係を再度抽出する、
データ圧縮システム。
（付記５）
付記２乃至４の何れかに記載のデータ圧縮システムであって、
前記相関関係抽出手段は、前記所定のデータの集合からデータの値が定数である前記データ群を抽出した後、定数である前記データ群を前記局所化探索範囲から排除し、当該排除後の局所化探索範囲内でデータ群の関係に基づいた相関関係を再度抽出する、
データ圧縮システム。
（付記６）
付記２乃至５の何れかに記載のデータ圧縮システムであって、
前記相関関係抽出手段は、前記所定のデータの集合内のデータ群のうち、予め定められた基準に基づいて同一と判断されるデータ群の組み合わせを抽出する、
データ圧縮システム。
（付記７）
付記１乃至６の何れかに記載のデータ圧縮システムであって、
前記相関関係検証手段は、前記データごとに網羅的に列挙した前記相関関係を満たすデータを記憶して、前記所定のデータの集合が、当該網羅的に列挙したそれぞれの相関関係を満たすか否かを検証する、
データ圧縮システム。
（付記８）
付記１乃至６の何れかに記載のデータ圧縮システムであって、
前記相関関係検証手段は、前記相関関係を表す数式を生成し、前記所定のデータの集合が、当該生成した一般則を満たす場合と満たさない場合とを分けて検証する、
データ圧縮システム。
（付記９）
収集した所定のデータの集合から当該所定のデータの集合内のデータの関係に基づいた相関関係の候補を少なくとも１つ抽出し、
前記所定のデータの集合内のデータが前記相関関係を満たすか否かを検証し、
前記検証の結果に基づいて、前記相関関係を用いて前記所定のデータの集合を圧縮する、
データ圧縮方法。
（付記９−１）
付記９に記載のデータ圧縮方法であって、
前記所定のデータの集合内の各データのそれぞれは、少なくとも１つ以上のデータの値を有するデータ群であり、
前記所定のデータの集合内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出する、
データ圧縮方法。
（付記９−２）
付記９−１に記載のデータ圧縮方法であって、
複数の前記データ群を構成するデータの値の個数がそれぞれ同数である局所化探索範囲を少なくとも１つ生成して、当該生成した局所化範囲内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出し、
生成した複数の局所化探索範囲内のそれぞれのデータ群が、前記相関関係を満たすか否か検証する、
データ圧縮方法。
（付記１０）
所定のデータを圧縮するための相関関係を抽出するデータ圧縮用相関関係抽出装置であって、
収集した所定のデータの集合から当該所定のデータの集合内のデータの関係に基づいた相関関係の候補を少なくとも１つ抽出する相関関係抽出部と、
前記所定のデータの集合内のデータが、前記相関関係抽出部が抽出した前記相関関係を満たすか否かを検証する相関関係検証部と、
を備える、
データ圧縮用相関関係抽出装置。
（付記１０−１）
付記１０に記載のデータ圧縮用相関関係抽出装置であって、
前記所定のデータの集合内の各データのそれぞれは、少なくとも１つ以上のデータの値を有するデータ群であり、
前記相関関係抽出部は、前記所定のデータの集合内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出する、
データ圧縮用相関関係抽出装置。
（付記１０−２）
付記１０−１に記載のデータ圧縮用相関関係抽出装置であって、
前記相関関係抽出部は、複数の前記データ群を構成するデータの値の個数がそれぞれ同数である局所化探索範囲を少なくとも１つ生成して、当該生成した局所化範囲内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出し、
前記相関関係検証部は、前記相関関係抽出部が生成した複数の局所化探索範囲内のそれぞれのデータ群が、前記相関関係を満たすか否か検証する、
データ圧縮用相関関係抽出装置。
（付記１１）
情報処理装置に、
収集した所定のデータの集合から当該所定のデータの集合内のデータの関係に基づいた相関関係の候補を少なくとも１つ抽出する相関関係抽出手段と、
前記所定のデータの集合内のデータが、前記相関関係抽出手段が抽出した前記相関関係を満たすか否かを検証する相関関係検証手段と、
を実現させるためのプログラム。
（付記１１−１）
付記１１に記載のプログラムであって、
前記所定のデータの集合内の各データのそれぞれは、少なくとも１つ以上のデータの値を有するデータ群であり、
前記相関関係抽出手段は、前記所定のデータの集合内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出する、
プログラム。
（付記１１−２）
付記１１−１に記載のプログラムであって、
前記相関関係抽出手段は、複数の前記データ群を構成するデータの値の個数がそれぞれ同数である局所化探索範囲を少なくとも１つ生成して、当該生成した局所化範囲内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出し、
前記相関関係検証手段は、前記相関関係抽出手段が生成した複数の局所化探索範囲内のそれぞれのデータ群が、前記相関関係を満たすか否か検証する、
プログラム。
なお、上記各実施形態及び付記において記載したプログラムは、記憶装置に記憶されていたり、コンピュータが読み取り可能な記録媒体に記録されている。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。
以上、上記各実施形態を参照して本願発明を説明したが、本願発明は、上述した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解しうる様々な変更をすることが出来る。
１ 統計値圧縮システム
２ ストレージシステム
２１ アクセラレータノード
２２ ストレージノード
３ 統計値マイニング装置
３１ データ送受信手段
３２ 統計値データベース
３３ ウィンドウ生成手段
３４ 相関関係抽出手段
３５ 相関関係検証手段
３６ 規則ファイル
４ 統計値圧縮装置
４１ データ送受信手段
４２ 統計値ファイル
４３ 検証された規則ファイル
４４ 統計値圧縮手段

Claims (11)

  1. 収集した所定のデータの集合から当該所定のデータの集合内のデータの関係に基づいた相関関係の候補を少なくとも１つ抽出する相関関係抽出手段と、
    前記所定のデータの集合内のデータが、前記相関関係抽出手段が抽出した前記相関関係を満たすか否かを検証する相関関係検証手段と、
    前記相関関係検証手段による検証結果に基づいて、前記相関関係を用いて前記所定のデータの集合を圧縮するデータ圧縮手段と、
    を備え、
    前記所定のデータの集合内の各データのそれぞれは、少なくとも１つ以上のデータの値を有するデータ群であり、
    前記相関関係抽出手段は、前記所定のデータの集合内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出し、
    前記相関関係抽出手段は、複数の前記データ群を構成するデータの値の個数がそれぞれ同数である局所化探索範囲を少なくとも１つ生成して、当該生成した局所化探索範囲内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出し、
    前記相関関係検証手段は、前記相関関係抽出手段が生成した複数の局所化探索範囲内のそれぞれのデータ群が、前記相関関係を満たすか否か検証する、
    データ圧縮システム。
  2. 請求項１に記載のデータ圧縮システムであって、
    前記相関関係抽出手段は、予め定められた種類の相関関係の候補を抽出した後、当該相関関係を有するデータ群を前記局所化探索範囲から排除し、当該排除後の局所化探索範囲内で前記データ群の関係に基づいた相関関係を再度抽出する、
    データ圧縮システム。
  3. 請求項１又は請求項２に記載のデータ圧縮システムであって、
    前記相関関係抽出手段は、前記所定のデータの集合からデータの値が定数である前記データ群を抽出した後、定数である前記データ群を前記局所化探索範囲から排除し、当該排除後の局所化探索範囲内でデータ群の関係に基づいた相関関係を再度抽出する、
    データ圧縮システム。
  4. 請求項１乃至３の何れかに記載のデータ圧縮システムであって、
    前記相関関係抽出手段は、前記所定のデータの集合内のデータ群のうち、予め定められた基準に基づいて同一と判断されるデータ群の組み合わせを抽出する、
    データ圧縮システム。
  5. 請求項１乃至４の何れかに記載のデータ圧縮システムであって、
    前記相関関係検証手段は、前記データごとに網羅的に列挙した前記相関関係を満たすデータを記憶して、前記所定のデータの集合が、当該網羅的に列挙したそれぞれの相関関係を満たすか否かを検証する、
    データ圧縮システム。
  6. 請求項１乃至５の何れかに記載のデータ圧縮システムであって、
    前記相関関係検証手段は、前記相関関係を表す数式を生成し、前記所定のデータの集合が、当該生成した数式を満たす場合と満たさない場合とを分けて検証する、
    データ圧縮システム。
  7. 収集した所定のデータの集合から当該所定のデータの集合内のデータの関係に基づいた相関関係の候補を少なくとも１つ抽出し、
    前記所定のデータの集合内のデータが前記相関関係を満たすか否かを検証し、
    前記検証の結果に基づいて、前記相関関係を用いて前記所定のデータの集合を圧縮し、
    前記所定のデータの集合内の各データのそれぞれは、少なくとも１つ以上のデータの値を有するデータ群であり、
    前記所定のデータの集合内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出し、
    複数の前記データ群を構成するデータの値の個数がそれぞれ同数である局所化探索範囲を少なくとも１つ生成して、当該生成した局所化探索範囲内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出し、
    生成した複数の局所化探索範囲内のそれぞれのデータ群が、前記相関関係を満たすか否か検証する、
    データ圧縮方法。
  8. 所定のデータを圧縮するための相関関係を抽出するデータ圧縮用相関関係抽出装置であって、
    収集した所定のデータの集合から当該所定のデータの集合内のデータの関係に基づいた相関関係の候補を少なくとも１つ抽出する相関関係抽出部と、
    前記所定のデータの集合内のデータが、前記相関関係抽出部が抽出した前記相関関係を満たすか否かを検証する相関関係検証部と、
    を備え、
    前記所定のデータの集合内の各データのそれぞれは、少なくとも１つ以上のデータの値を有するデータ群であり、
    前記相関関係抽出手段は、前記所定のデータの集合内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出し、
    前記相関関係抽出手段は、複数の前記データ群を構成するデータの値の個数がそれぞれ同数である局所化探索範囲を少なくとも１つ生成して、当該生成した局所化探索範囲内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出し、
    前記相関関係検証手段は、前記相関関係抽出手段が生成した複数の局所化探索範囲内のそれぞれのデータ群が、前記相関関係を満たすか否か検証する、
    データ圧縮用相関関係抽出装置。
  9. 情報処理装置に、
    収集した所定のデータの集合から当該所定のデータの集合内のデータの関係に基づいた相関関係の候補を少なくとも１つ抽出する相関関係抽出手段と、
    前記所定のデータの集合内のデータが、前記相関関係抽出手段が抽出した前記相関関係を満たすか否かを検証する相関関係検証手段と、
    を実現させ、
    前記所定のデータの集合内の各データのそれぞれは、少なくとも１つ以上のデータの値を有するデータ群であり、
    前記相関関係抽出手段は、前記所定のデータの集合内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出し、
    前記相関関係抽出手段は、複数の前記データ群を構成するデータの値の個数がそれぞれ同数である局所化探索範囲を少なくとも１つ生成して、当該生成した局所化探索範囲内のデータ群の関係に基づいた相関関係の候補を少なくとも１つ抽出し、
    前記相関関係検証手段は、前記相関関係抽出手段が生成した複数の局所化探索範囲内のそれぞれのデータ群が、前記相関関係を満たすか否か検証する、
    プログラム。
  10. 収集した所定のデータの集合から当該所定のデータの集合内のデータの関係に基づいた相関関係の候補を少なくとも１つ抽出する相関関係抽出手段と、
    前記所定のデータの集合内のデータが、前記相関関係抽出手段が抽出した前記相関関係を満たすか否かを検証する相関関係検証手段と、
    前記相関関係検証手段による検証結果に基づいて、前記相関関係を用いて前記所定のデータの集合を圧縮するデータ圧縮手段と、
    を備え、
    前記相関関係検証手段は、前記データごとに網羅的に列挙した前記相関関係を満たすデータを記憶して、前記所定のデータの集合が、当該網羅的に列挙したそれぞれの相関関係を満たすか否かを検証する、
    データ圧縮システム。
  11. 収集した所定のデータの集合から当該所定のデータの集合内のデータの関係に基づいた相関関係の候補を少なくとも１つ抽出する相関関係抽出手段と、
    前記所定のデータの集合内のデータが、前記相関関係抽出手段が抽出した前記相関関係を満たすか否かを検証する相関関係検証手段と、
    前記相関関係検証手段による検証結果に基づいて、前記相関関係を用いて前記所定のデータの集合を圧縮するデータ圧縮手段と、
    を備え、
    前記相関関係検証手段は、前記相関関係を表す数式を生成し、前記所定のデータの集合が、当該生成した数式を満たす場合と満たさない場合とを分けて検証する、
    データ圧縮システム。
JP2015530803A 2013-05-30 2014-05-29 データ圧縮システム Active JP6341205B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201361828953P 2013-05-30 2013-05-30
US61/828,953 2013-05-30
PCT/JP2014/002844 WO2014192299A1 (en) 2013-05-30 2014-05-29 Data compression system

Publications (2)

Publication Number Publication Date
JP2016524821A JP2016524821A (ja) 2016-08-18
JP6341205B2 true JP6341205B2 (ja) 2018-06-13

Family

ID=51988350

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015530803A Active JP6341205B2 (ja) 2013-05-30 2014-05-29 データ圧縮システム

Country Status (5)

Country Link
US (1) US10078669B2 (ja)
EP (1) EP3005571A4 (ja)
JP (1) JP6341205B2 (ja)
CN (1) CN105103452B (ja)
WO (1) WO2014192299A1 (ja)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3033729B1 (en) * 2013-08-16 2021-03-31 Intuitive Surgical Operations, Inc. System and method for logging and replay among heterogeneous devices
US9665625B2 (en) * 2014-06-25 2017-05-30 International Business Machines Corporation Maximizing the information content of system logs
US10592473B2 (en) * 2014-09-11 2020-03-17 Infosys Limited Method for improving energy efficiency of map-reduce system and apparatus thereof
US10037374B2 (en) * 2015-01-30 2018-07-31 Qualcomm Incorporated Measuring semantic and syntactic similarity between grammars according to distance metrics for clustered data
US10509695B1 (en) * 2015-03-30 2019-12-17 ThetaRay Ltd. System and method for anomaly detection in dynamically evolving data using low rank matrix decomposition
US9852012B2 (en) * 2015-08-26 2017-12-26 International Business Machines Corporation Scheduling mapReduce tasks based on estimated workload distribution
CN106919578B (zh) * 2015-12-24 2021-04-20 创新先进技术有限公司 一种确定互联网资源的关联资源值的方法及装置
US9959097B2 (en) 2016-03-09 2018-05-01 Bank Of America Corporation SVN interface system for heterogeneous development environments
US9996526B2 (en) * 2016-10-19 2018-06-12 International Business Machines Corporation System and method for supplementing a question answering system with mixed-language source documents
US9996525B2 (en) * 2016-10-19 2018-06-12 International Business Machines Corporation System and method for supplementing a question answering system with mixed-language source documents
JP6794782B2 (ja) 2016-11-02 2020-12-02 富士通株式会社 情報処理装置、情報処理プログラム、及び情報処理方法
CN109144957B (zh) * 2017-06-28 2020-12-08 北京嘀嘀无限科技发展有限公司 网格数据压缩方法和网格数据压缩装置
CN109086202B (zh) * 2018-07-19 2021-05-14 北京计算机技术及应用研究所 基于关联规则的fpga/ip核代码规则检查方法
CN111859405A (zh) * 2020-07-31 2020-10-30 深信服科技股份有限公司 一种威胁免疫框架、方法、设备及可读存储介质
CN113364465B (zh) * 2021-06-04 2022-11-22 上海天旦网络科技发展有限公司 基于百分位的统计数据压缩方法和系统
CN113452378B (zh) * 2021-06-28 2024-07-05 国网北京市电力公司 孪生数据的压缩方法、装置与计算机可读存储介质
US20230229633A1 (en) * 2022-01-18 2023-07-20 Dell Products L.P. Adding content to compressed files using sequence alignment
US11977517B2 (en) 2022-04-12 2024-05-07 Dell Products L.P. Warm start file compression using sequence alignment
CN115277123B (zh) * 2022-07-12 2024-01-19 上海交通大学 车用can总线注入攻击异常检测方法及系统
CN115001148B (zh) * 2022-08-03 2022-11-22 杭州轻舟科技有限公司 一种储能电站数据全量高频实时采集方法及系统
CN116600135B (zh) * 2023-06-06 2024-02-13 广州大学 基于无损压缩的溯源图压缩方法及系统
CN116934358B (zh) * 2023-09-13 2023-12-15 澳润(山东)药业有限公司 基于信息验证的阿胶质量追溯方法及系统

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6125348A (en) * 1998-03-12 2000-09-26 Liquid Audio Inc. Lossless data compression with low complexity
DE60204039T2 (de) * 2001-11-02 2006-03-02 Matsushita Electric Industrial Co., Ltd., Kadoma Vorrichtung zur kodierung und dekodierung von audiosignalen
CN100390790C (zh) * 2002-05-10 2008-05-28 甲骨文国际公司 存储和访问数据,以及提高数据库查询语言语句性能的方法和机制
JP2009187293A (ja) * 2008-02-06 2009-08-20 Nec Corp 時系列データ解析システム、方法およびプログラム
JP5549177B2 (ja) * 2009-10-22 2014-07-16 富士通株式会社 圧縮プログラム、方法及び装置、並びに解凍プログラム、方法及び装置
JP5682354B2 (ja) 2011-02-14 2015-03-11 富士通株式会社 データ圧縮装置，データ圧縮方法，およびデータ圧縮プログラム
WO2013007185A1 (zh) * 2011-07-14 2013-01-17 电信科学技术研究院 一种数据压缩方法和设备

Also Published As

Publication number Publication date
CN105103452A (zh) 2015-11-25
CN105103452B (zh) 2018-03-13
JP2016524821A (ja) 2016-08-18
EP3005571A1 (en) 2016-04-13
EP3005571A4 (en) 2017-01-18
WO2014192299A1 (en) 2014-12-04
US10078669B2 (en) 2018-09-18
US20150331913A1 (en) 2015-11-19

Similar Documents

Publication Publication Date Title
JP6341205B2 (ja) データ圧縮システム
Liu et al. Logzip: Extracting hidden structures via iterative clustering for log compression
Pelkonen et al. Gorilla: A fast, scalable, in-memory time series database
Apiletti et al. Frequent itemsets mining for big data: a comparative analysis
CN105075222B (zh) 采用动态压缩的数据复制
Tarasov et al. Generating realistic datasets for deduplication analysis
Jensen et al. Modelardb: Modular model-based time series management with spark and cassandra
CN111949633B (zh) 一种基于并行流处理的ict系统运行日志分析方法
US8667032B1 (en) Efficient content meta-data collection and trace generation from deduplicated storage
Sallinen et al. Graph colouring as a challenge problem for dynamic graph processing on distributed systems
Chen et al. Adaptive performance anomaly detection for online service systems via pattern sketching
Yao et al. A study of the performance of general compressors on log files
Wang et al. Exalt: Empowering Researchers to Evaluate {Large-Scale} Storage Systems
CN117827850B (zh) 一种数据存储方法及系统
Petermann et al. DIMSpan: Transactional frequent subgraph mining with distributed in-memory dataflow systems
Mostafa et al. SciTS: a benchmark for time-series databases in scientific experiments and industrial internet of things
CN112988741A (zh) 实时业务数据合并方法、装置及电子设备
Nagdive et al. Overview on performance testing approach in big data
CN116010452A (zh) 基于流式计算引擎的工业数据处理系统和方法、介质
Li et al. Logshrink: Effective log compression by leveraging commonality and variability of log data
US9256503B2 (en) Data verification
Lytvyn et al. Development of Intellectual System for Data De-Duplication and Distribution in Cloud Storage.
Carns et al. Impact of data placement on resilience in large-scale object storage systems
Underwood et al. LibPressio-Predict: Flexible and Fast Infrastructure For Inferring Compression Performance
Borowiec Correlation-based compression of the statistics generated by the distributed, secondary storage system

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170404

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20171107

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171220

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180417

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180430

R150 Certificate of patent or registration of utility model

Ref document number: 6341205

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150