夜行録 - 酔歩.net

数えてみると、10年ぶり7度目らしい

しかし、詰めても詰めても終わらない。この部屋だけで何箱使うんだ？
とりあえず本だけとかで一箱にならないよう上半分には違うものを詰めているんだが、それでも自分じゃ持ち上がるか不安

なお、前回引っ越し時の空箱だの梱包材の残りだのが大量に発掘された…。今回はさっさと捨てよう
しかしその前回の箱を活用しても、箱足りなくなるんじゃないか疑惑。まあ、積み替えなしだからトラックに放り込みさえできればあとはなんとかなりそう

ここ1、2年、あまりにも会社にやることがなかったのと、会社の進路修正が自分とマッチしてない感じがして転職することにしました。

まあ、一度やって見たかった、というのも大きいのですが、やはり会社辞める時は理由は一つじゃないよね

有給が有り余っているので、これから年内は遊んで暮らす日々です。

次の勤務先はアキバ。通勤時間は短くしよう。

6月は紫陽花撮りに出かけてたり。

開成町のあじさい祭り。地元の農家がテントで露店開いてるのがメインの祭りだったけど、まあまあ楽しかった。

[read more]

連休も終わってしまった。

フィルムの分の現像がまだだけど、そっちはいつの日になることやら。

[read more]

まあ、もう咲き始めてるんですけどね。<

都内まで行ってみるかなぁ

Sparkで距離計算をしてみる。 データは (key, [v1, v2,..., vn]) というタプルのリストであるとする

＃直積で全ペアの作成（AはRDDで上のようなリスト）

B = A.cartesian(A)

＃ ((a, a), (a, b), (a, c)...) が生成され、aが上の(key, [val])
＃キーと値をそれぞれタプルに分離

C=B.map(lambda x: ((x[0][0], x[1][0]), (x[0][1], x[1][1])))

＃自分との距離は無視

D=C.filter(lambda x: x[0][0] != x[0][1])

＃numpy でベクトルの引き算、内積、sqrt

E=D.map(lambda x: (x[0], np.array(x[1][0])-np.array(x[1][1])))
F=E.map(lambda x: (x[0], np.sqrt(np.dot(x[1], x[1]))))
F.persist()

＃((i, j), r_ij) の形になっている

＃ (i, r_ij) に変換

G=F.map(lambda x: (x[0][0], x[1]))

＃同じキーの距離をリストにまとめる

H=G.groupByKey()

＃（イテレータからリストへ変換するおまじない）

I=H.map(lambda x: (x[0], list(x[1])))

＃ある要素からの距離が全てリストにまとめられている

＃最大最小の探索
＃値（距離）だけ抽出

J=F.map(lambda x: x[1])
J.persist()

＃RDDのStatsCounter object

j=J.stats()
print j.max(), j.min(), j.mean(), j.stdev()

＃ヒストグラムも自前でかける from RDD

Q=J.histogram(50)

In [17]: ?Q
Type:        tuple
String form: ([0.056793451016426098, 6.482786133784419, 12.908778816552413, 19.334771499320404, 25.76076418208 <...> 406, 27434, 17670, 11478, 7324, 4280, 2550, 2038, 1316, 346, 328, 210, 34, 10, 8, 6, 8, 2, 0, 2])
Length:      2
Docstring:
tuple() -> empty tuple
tuple(iterable) -> tuple initialized from iterable's items

If the argument is a tuple, the return value is the same object.

In [18]: print Q[0]
[0.056793451016426098, 6.482786133784419, 12.908778816552413, 19.334771499320404, 25.760764182088398, 32.186756864856392, 38.612749547624382, 45.03874223039238, 51.46473491316037, 57.890727595928361, 64.316720278696366, 70.742712961464363, 77.168705644232347, 83.594698327000344, 90.020691009768342, 96.446683692536325, 102.87267637530432, 109.29866905807232, 115.7246617408403, 122.1506544236083, 128.5766471063763, 135.0026397891443, 141.42863247191229, 147.85462515468026, 154.28061783744826, 160.70661052021626, 167.13260320298426, 173.55859588575225, 179.98458856852025, 186.41058125128822, 192.83657393405622, 199.26256661682422, 205.68855929959221, 212.11455198236021, 218.54054466512821, 224.96653734789621, 231.39253003066418, 237.81852271343217, 244.24451539620017, 250.67050807896817, 257.09650076173614, 263.52249344450411, 269.94848612727213, 276.3744788100401, 282.80047149280813, 289.2264641755761, 295.65245685834407, 302.07844954111209, 308.50444222388006, 314.93043490664809, 321.35642758941606]

In [19]: print Q[1]
[3246, 4956, 6868, 11482, 24108, 53192, 114492, 228950, 413436, 661572, 948358, 1224238, 1446794, 1585532, 1642804, 1615678, 1519618, 1365182, 1186784, 1000046, 829116, 666752, 533750, 419492, 321666, 247242, 183192, 135116, 95748, 66502, 44406, 27434, 17670, 11478, 7324, 4280, 2550, 2038, 1316, 346, 328, 210, 34, 10, 8, 6, 8, 2, 0, 2]

この先が思いつかないなぁ

必要なもの

jdk

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html から拾ってきてインストール（8u72 (1.8.0_72)）

spark

http://spark.apache.org/downloads.html からダウンロードして、適当なところに展開（spark-1.6.0-bin-without-hadoop.tgz）。

hadoop

https://hadoop.apache.org/releases.html からダウンロードして、適当なところに展開（hadoop-2.7.1.tar.gz）。

環境変数

## Hadoop
export PATH=$HOME/data/hadoop-2.7.1/bin:${PATH}
export JAVA_HOME=`/usr/libexec/java_home`

## Spark
export PATH=$HOME/data/spark-1.6.0-bin-without-hadoop/bin:${PATH}
export SPARK_DIST_CLASSPATH=`hadoop classpath`
export HADOOP_CONF_DIR=$HOME/data/hadoop-2.7.1/etc/hadoop

osxでJAVA_HOMEを適切に設定するには、/usr/libexec/java_homeを用いると簡便で良い。 うっとおしいので、spark-1.6.0-bin-without-hadoop/conf/log4j.propertiesを作成し、 log4j.rootCategory=WARN, consoleとしておく。

osxの場合、普通に実行すると snappy が云々という例外投げられて死ぬ。これは

1. Sparkは通信の為にデータを圧縮する
2. 幾つかのコーデックが使えるがデフォルトがsnappy
3. osxのjava環境にはこれがない（pure javaではなくnative libraryが必要）

pyspark --driver-java-options -Dspark.io.compression.codec=lzfとするとエラーとならない

env PYSPARK_PYTHON=ipython-2.7 pyspark --driver-java-options -Dspark.io.compression.codec=lzf --master 'local[*]'として、iPython-2.7 をフロントエンドに、pythonから4並列でデータ処理ができた。

話題になってから半年遅れくらいだが、やっと時間が取れて試してみた。

python のフロントエンドがあるわけだが、これをむしろ spark のフロントエンドではなく python に対して spark の RDD が追加されたものと考えると大変使いやすくてよい。

もともと python で分散処理させようと思ったら multiprocssing あたりで明示的に書いてやらないとだめだったところが、 見かけ上一つのオブジェクトである RDD に処理を割り当てて実行すれば、勝手に裏で分散処理される。
しかもノード間でも分散できる、と考えると python で上手くできてなかったところをきれいに埋めてるように見える。

R も分散処理苦手だった気がするけど、 python + RDD でデータ解析環境とすると今時点では最強なんじゃないだろうか？

1. hadoopのクラスライブラリは必要だが、hadoop自体は動いている必要はない
2. yarnに投げなくても、sshが通れば自前でクラスタ構築できる（standalone mode）
3. 1ノードでも、コアの数で分散処理ができる
4. iPython とも連携できる

gfarm をガリガリに使うと、 syslog が gfarm のログで埋まってどうしようもなくなるので、ログレベルを変更。
デフォルトでこんなに何もかもログ出力しないでいいと思うけどね。

/etc/gfmd.conf で

log_level warning

hadoop もログうるさすぎる系だよなぁ…。あっちもいずれどうにかしないと

2T と 3T のディスクにまたがって、2.7T の logical volume があったんだが、用途が gfarm のストレージだったおかげで、 gfrep で他のノードに追っ払えて、 30G くらいになったところで xfsdump して、 unmount して、その他の lovical volume も pvmove で動かせて、すかさず fdisk してパーティション切れた（2T のディスクの方）。

昔、 2T に 2T 追加した時にパーティションきらなかった方で、切ってあった方が怪しくなった時に 3T なんかつけたらそっちから起動できなくて、どうしてもパーティション切り直さなきゃならなかったのがやっと何とかなった。 しかも、リモートからオンラインで。ああ苦しいお手玉だった。

ディスクに余裕があると、リカバリのために一旦バックアップとか出来て助かる。 学生の頃はそんなリソースなかったから、何を諦めるとかそんなのばっかだった気がする。

最後に新しい root を mount しておいて、 chroot して grub-install 。成功。素晴らしい（rebootはまだ）。