save/load 対象

gistfile1.txt

save/load の仕組み/大枠に対する議論(https://gist.github.com/9a4586bde31047ec96db)から切り出しました。


保存対象へ影響をあたえる可能性のある議論は以下の 1 つであるが、データ量の膨大さからも、大々的な実装を要するため、長期的な方針も含めて検討する必要がある。本議論については、別途行うこととし、各サーバープロセスで save を行う、既存踏襲の仕組みのなかでsave 対象の拡張を整理する。
* 各々のサーバープロセスが save をするか、管理ノードがすべてのモデルを取りまとめるかという議論
   * Jubatus の方向性、コンセプト としてどうかという議論が必要。
   * 個人的には、将来的に、外付けのプロセスとして jubatus-save-manager とかで実現するのが良いと思う。


まずは、現状の保存対象の拡張を実施し、その後、save 全体の動きの改善を行うという進め方し、この gist では 保存対象の拡張 について整理する。


保存対象
--------
 1. モデル ... 学習の状態
     - 現状は以下
      * classifier, regression: inear_function_mixer, mixable_weight_manager
      * recommender: rcmdr, mixable_weight_manager
      * stat: mixable_stat
      * anomaly: mixable_anomaly, mixable_wight_manager
      * graph: mixable_graph
 2. fv_converter の状態
     - 状態を管理しているもの
 3. config
     - get_config を server_base に共通化し、config_ を吐き出す。
 4. クラスタ構成
     - zk から membership を取る
 5. その他、状態を保持するもの (global_id など)
     - zk からとる?
 6. save 実行した時の情報
     - jubatus バージョン
     - id
     - プロセス名
   　- type (classifier, recommender ...)
     - name
     - タイムスタンプ
     - 

入出力形式
----------

* 上記 3, 4, 6 はまとめて1ファイルに出力 ... サマリ情報
   -> ユーザーが内容確認できるように、エディタ等で覗ける方が良いと想定。archive は苦しい。
   -> key/value をネストで表現できる形式である必要がある
   => JSONを想定していたが、JSONの仕様上の問題から回避したほうが良い。
   => 2013/01/22 形式は再考中。
       - そのまま読めるものだと yaml, xml。
       - msgpack 形式でデシリアライズするツールを用意するというのもある。
* 上記 1 は 現行踏襲 ... モデル情報
   => archive形式
* 上記 2 は 拡張の実装次第であるが、上記 1 の包括されるのでは?
* 上記 5 は リロードする必要も含めて検討が必要
   -> サマリ情報に含める方向で調査中。



サマリ情報を JSON形式 での入出力とした際の例
--------------------------------------------

===
"id" : "id of specificated",
"version" : "0.4.0",
"process_name" : "jubaclassifier",
"type" : "classifier",
"name" : "name of cluster",
"timestamp" : "2013-01-11 16:39:45 +0900",
"membership": [
  "ip:port",
  "ip:port",
  "ip:port"
]
"config" : {
  "method" : "PA1",
  "converter" : {
    ...
  },
  "parameter" : {
    ...
  }
}
===

以下にまとめました
https://gist.github.com/4633358