|
FilterChain
心臓部である FilterChain まわりの構造 / about FilterChain, the central architecture [not finished]
JP基本Cicindelaが受け取るデータのうち，もっとも基本になるのは以下の二つのうちの いずれか一方 。
Id はすべて整数値。従って，cicindela とそれを利用するアプリケーションの間では基本的にidだけがやりとりされるため，シンプルでかつ汎用性が高い。 オプションとして，整数以外のユーザid/アイテムidも扱うことができる。この場合は、user_id_char2int, item_id_char2int という変換テーブルによって，入出力の手前で内部id <=> オリジナルid の変換が行われる。 これに加えて，以下の情報も扱うことができる。
それらのデータを各種フィルタに通して順次変換していき、最終的にアイテム間の類似度データを作るのが解析の心臓部にあたる「filter chain」 結果を返すために参照されるテーブルは，オンライン用 (表) と裏の二つのテーブルがセットになっている。解析は裏側でやっておき，バッチ処理が終了したら一気に rename table で二つのテーブルをいれかえる仕組み。入力バッファも解析バッチからは隔離されているため，web api は，解析用に走っている重いsqlの影響をうけない。 解析のながれ嗜好データ入力 ↓ (Handlers/Record.pm が http経由で受け取ったデータを IncomingData.pm にわたす) 入力バッファ picks_buffer, ratings_buffer, ... ↓ (bin/flush_buffer.pl により定期的にバッファがフラッシュされる) 一次(生)データ picks, ratings, tagged_relations, ... ↓ (batch.pl から FilterChain.pm が呼ばれ，Filters/ 以下の各種プラグインフィルタが順に適用される) 二次(中間)データ converted_ratings, extracted_ratings, iuf, ... 集計結果テーブル item_similarities, slope_one_diffs, ... ↓ (集計がすべて終わったら、rename table により一挙に古いテーブルと入れ替わる) オンラインテーブル converted_ratings_online, item_similarities_online, slope_one_diffs_online, ... ↓ (Handlers/Recommend.pm が Recommender/ 以下の各種レコメンダの結果を http経由で出力) レコメンデーション出力 APIで受信した嗜好データは、それぞれ以下のテーブルに格納される。
※実際には、競合防止のため、いったん picks_buffer などのバッファに格納され、bin/flush_buffers.pl が定期的にバッファの内容を本テーブルに移動している。 ※また、数値ではないuser_id /item_id を内部用の数値idにマッピングする処理もこのバッファ内で行われる。[詳細はあとで書く] 定期的に、config の定義に従って、複数のフィルタが順に起動される。フィルタは Cicindela::Filters の子クラスで、それぞれ「あるテーブルからデータを読み出し、あるテーブルに書き出す」という動作をする。 例えば...
全てのフィルタリングが終了すると、Recommender が利用するテーブル(ここでは、最終段のフィルタが書き出した item_similarities テーブル) は item_similarities_online という名前に変更される。それ以外の中間テーブル、および、それまであった item_similarities_online テーブルの内容は破棄される。 レコメンド出力APIは、Cicindela::Recommender の子クラスのどれかを使って出力される。 例えば Recommender::ItemSimilarities クラスは Filters::ItemSimilarities と対になっており、Filters::ItemSimilarities が書き出した類似度データ (item_similarities_online テーブル) を元に item別のレコメンドを計算する。
現在実装されているフィルタとレコメンダ→ [あとで書く] config の書き方の例→ Examples |
Sign in to add a comment
