Mahout in Action Chapter 3 Summary

Mahout in ActionのChapter3についての自分の理解をメモ。

嗜好データの表現

Preferenceオブジェクト

Preferenceオブジェクトは最も基本的な概念で、一つのユーザID、アイテムID、嗜好値で嗜好性を表す
一つのオブジェクトが一人のユーザの一つのアイテムに対する嗜好性を表している
一つのGenericPreferenceは20バイトの有用なデータを保持しており、8バイトのユーザID（Javaのlong型）、8バイトのアイテムID（long）、4バイトの嗜好値（float）から成っている
オブジェクトが存在するためには上記以外に28バイトものオーバーヘッドがかかる

PreferenceArrayと実装

PreferenceArrayはPreferenceのコレクションを配列のように扱うためのインタフェース
例としてGenericUserPreferenceArrayは一つのユーザIDにアイテムIDの配列と嗜好値の配列を持つ
必要なメモリはわずか12バイト（8バイトのアイテムID、4バイトの嗜好値の配列）
Preferenceオブジェクトと比べてメモリは節約できるがパフォーマンスの改善効果は少ない
これはPreferenceArrayでは要素が分散されて配置され、ガベージコレクタによって評価されるため

FastByIDMapとFastIDSet

Mahoutはmapやsetのようなデータ構造を使用するが、JavaのコレクションであるTreeSetやHashMapではなく、FastMap、FastByIDMap、やFastDISetを使用する
これらはMapやSetのようなものであるが、MahoutのRecommenderが必要なものだけのために特化されている
パフォーマンスの劇的な改善というよりむしろメモリの使用量を削減する
Javaのコレクションとの違いは下記のような点
・FastByIDMapはHashMapと同じようにハッシュベースで、ハッシュの衝突の解決には分離連鎖法ではなく線形探査法を使う
・MahoutのRecommenderではキーとメンバーは常にlong型のプリミティブ型でオブジェクトではない。
・longのキーを使うことでメモリの使用量を抑えパフォーマンスを改善する。
・FastByIDMapは最大サイズという考え方があるためキャッシュの様に使用することができ、このサイズを越えた場合は、新しい要素を追加する際に使われていない要素が削除される
FastIDSetは一つの要素ごとに平均14バイト使用する。HashSetは84バイト。
FasByIDMapはエントリごとに28バイト使用する

インメモリデータモデル

GenericDataModel

最もシンプルなインメモリのDataModel実装はGenericDataModel
GenericDataModelは嗜好度の入力としてユーザIDとPreferenceArrayのFastByIDMapを受け取る

   1  FastByIDMap<PreferenceArray> preferences = 
   2      new FastByIDMap<PreferenceArray>();
   3  PreferenceArray prefsForUser1 = 
   4      new GenericUserPreferenceArray(10);
   5  
   6  prefsForUser1.setUserID(0, 1L);
   7  prefsForUser1.setItemID(0, 101L);
   8  prefsForUser1.setValue(0, 3.0f);
   9  prefsForUser1.setItemID(1, 102L);
  10  prefsForUser1.setValue(1, 4.5f);
  11  ... (8 more)
  12  
  13  preferences.put(1L, prefsForUser1);
  14  
  15  DataModel model = new GenericDataModel(preferences);

メモリの使用量は格納される嗜好データの数によるが、いくつかのテストの結果から、嗜好データ1つごとに28バイトのJava heap spaceが使われる。これにはすべてのデータとインデックスなどのデータ構造を含む。

ファイルベースのデータ

FileDataModelはファイルからデータを読み込み、GenericDataModelとしてメモリに格納する
CSVの他にTSVも使用可能。ファイル名の拡張子が.zipや.gzになっていればzipやgzipの圧縮ファイルも使用可能

コンポーネントのリフレッシュ

データをリフレッシュするためには refresh(Collection) というメソッドを使用する。
このメソッドは最新のデータを元にコンポーネントの再読み込み、再計算、状態のリフレッシュを行う
FileDataModelはその時点のファイルを読み込むだけで、パフォーマンスの問題で自動的にデータをリロードするようなことはしないため、refresh()メソッドを使用する

ファイルの更新

FileDataModelはファイルの更新をサポートしている。メインのファイルを読み込んだ後でさらにファイルを読み込むことで先に読み込まれたデータを上書きする
削除は空の嗜好値データを渡すことによって行われる

   1  1,108,3.0
   2  1,103,

上記のデータではユーザ1のアイテム108についての嗜好度データが作成または更新されて嗜好度3.0がセットされ、ユーザ1のアイテム103についての嗜好度データが削除される
このためにはメインのデータファイルと同じディレクトリに格納し、最初のピリオドまでのファイル名を同じにしておく必要がある

DBベースのデータ

MahoutではRDBから嗜好度データを読み込むことができる
DBからデータを読み込んでRecommenderを動かすのはかなり遅い
データの抽出、並び替え、シリアライズ、転送、結果セットのデシリアライズのオーバーヘッドは依然として最適化されたインメモリ構造からデータを読み込むよりかなり大きい

JDBCとMySQL

嗜好度データにはJDBCDataModelの実装を通してJDBCでアクセスする
JDBCDataModelのプライマリサブクラスはMySQL5.x用のMySQLJDBCDataModel
Mahoutの開発バージョンにはPostgreSQL用のJDBCDataModel実装がある
デフォルトではすべての嗜好度データはtaste_preferencesというテーブルに、ユーザIDが格納されるuser_idカラム、アイテムIDが格納されるitem_idカラム、嗜好度データが格納されるpreferenceカラムとともに格納されているとみなされる
このテーブルにはJavaのlong型と互換性のあるtimestampカラムを含むことができる

JNDIによる設定

JDBCDataModelはJNDIにjdbc/tasteという名前で登録されているDataSourceでアクセスできるものとみなされる

プログラムでの設定

JNDIを直接使わなくても、MySQLJDBCDataModelのコンストラクタにDataSourceを直接渡すことができる

   1  MysqlDataSource dataSource = new MysqlDataSource();
   2  dataSource.setServerName("my_database_host");
   3  dataSource.setUser("my_user");
   4  dataSource.setPassword("my_password");
   5  dataSource.setDatabaseName("my_database_name");
   6  JDBCDataModel dataModel = new MySQLJDBCDataModel(
   7      dataSource, "my_prefs_table", "my_user_column",
   8      "my_item_column", "my_pref_value_column");

上記がデータベース内のデータをレコメンドに使うためのすべて
MySQLJDBCDataModelのドキュメントが明確にしているように、効率的にレコメンドを提供するには下記のようなデータベースやドライバに対するコンフィギュレーションが求められる
・ユーザIDとアイテムIDカラムはnullを許容せず、インデックスされていること
・プライマリキーはユーザIDとアイテムIDの複合値であること
・カラムのデータ型はJavaのlongとfloatに対応していること
・バッファやクエリキャッシュのチューニングのためにはMySQLJDBCDataModelのJavadocを参照
・MySQLのConnector/Jドライバを使う場合は、cache-PreparedStatementsパラメータをtrueに設定する

嗜好度データ無しの対処

ユーザとアイテムの関連はあるがつながりの強さを表す値がない嗜好度データを扱うことがある
Mahout-speakではこのようなデータはBoolean preferencesと呼ばれ、”存在する” または ”存在しない” のいずれかの値を持つ
これは”yes”、”no”を表すのではなく、全ての有効なユーザとアイテムの関連において、”好き”、”好きではない”、”なし”の3つの状態を設定する

データを無視する場合

好む、好まないというのが相対的に似たような状態の場合、少なくとも関連が全くないものと比較するケースでは、嗜好度データを無視することは有益である

嗜好度なしのインメモリ表現

嗜好度を持たないことは嗜好データの表現を劇的に単純化し、パフォーマンスの改善と、メモリ使用量の大幅な削減を可能にする
嗜好度を持たないことで一つの嗜好度データごとに4バイト抑えられるはずであるが、実際にテストをした結果では4バイトから24バイト削減された
GenericBooleanPrefDataModelはGenericDataModelとは別のDataModel実装であるが、嗜好度を内部に保持せず、FastIDSetsのように関連のみを保持する
DataModelのgetItemIDsForUser()などのいくつかのメソッドは速くなる
getPreferencesFromUser()などのいくつかのメソッドは遅くなる。
getPreferenceValue()メソッドは全てのケースにおいて1.0を返す。
GenericBooleanDataModelの便利なメソッドであるtoDataMap()を使ってPreferenceArraysを要素としてもつFastByIDMapを、FastIDSetsを要素としてもつFastByIDMapに変換して、GenericBooleanDataModelの入力として渡すことが可能

互換性のある実装の選択

EuclideanDistanceSimilarityなどは嗜好度なしで動かしても役に立つ結果は得られないため、嗜好度無しのデータでは動作しない
二つのデータが同じ値である場合、これらのピアソン相関は定義されない
LogLikelihoodSimilarityは実際の嗜好度データに基づかない実装
FileDataModelは入力データが嗜好度を含まない場合、自動的にGenericBooleanPrefDataModelを使用する
MySQLBooleanPrefDataModelは嗜好度カラムを持たないデータベーステーブルを使用する場合に適している

posted by

akanuma on Tue 8 Nov 2011 at 08:29