夜行録 - 酔歩.net

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はまだ）。

gfarm の gfrep が、リンク先のない symlink などにぶつかるとあっさり死ぬので、深いサブディレクトリを持つディレクトリをまとめて move できない。 symlink 何てそんなもんじゃんよもー

しょうがないので、こんな場当たりコードで再帰して無理やり move 。/work/MYNAME/Gfarm/に一旦全体をマウントしておいて、そこを辿りながら、パスの前の方をぶった切って Gfarm のパスにする。それも echo と sed で。２０年ぐらい前からずっとこんなやり方だな

#! /bin/bash

GFREP="gfrep -m -N 2 -H $HOME/gfarmdst -h $HOME/gfarmsrc"
GFMON="/work/MYNAME/Gfarm"
function rec () {
        GFPATH=`echo $1 | sed -e "s@${GFMON}@@"`
        ${GFREP} $GFPATH
        if [ $? -ne 0 ];
        then
                if [ -d $1 ];
                then
                        cd $1
                        for i in *;
                        do
                                rec $1/$i
                        done
                fi
        fi
}

rec $@

サーバ放置してたら大変酷い目にあった。トラブル３連発。しかもまだ未解決

その１：gfarm のメタデータサーバのバックエンドを、ldapにして放置していたら、

> sudo du -sh /var/gfarm-ldap
77G /var/gfarm-ldap

とかなっていて、/ に 100G とか割り当ててあったのに 95% くらい使い切っていて焦る。

一応この件の問題は、/var/gfarm-ldap/DB_CONFIG に

set_flags DB_LOG_AUTOREMOVE

と指定するのみならず、/etc/gfarm-ldap/slapd.conf で

checkpoint  512  15

としておいてやらないと bdb のトランザクションログがちゃんと消えてくれないよ、ということで、ちゃんとそこまで書いておいて欲しいものである。
AUTOREMOVE だけは設定しておいたんだけどなー、これでいいのかどうか判らないから放置して様子みようとほったらかしにしたんだった。

[read more]

行き当たりばったりに甲府まで。
行き当たりばったりすぎて、バスの時間がうまくなくって遅い時間について、天気も悪くなってあまり回れなかった。

新米が届いたので、元気よく1.5合炊いて、結局全部食べてしまうなど

ササニシキは炊きたてより、ちょっと冷めてぽそぽそっとなってる方が美味しいね

しかし、米が美味しい！と言って米ばかりばくばく食べてるのって、ドーナツ美味しいと言ってドーナツ食べまくってるのと大して変わらない気もする。

急に寒くなったので、寝具の準備をするなど

日当たり悪くなってきたら、急にひょろひょろ伸び出した多肉。植物は勝手に伸びるから困る。ずっとちっちゃいまんまでいいのに。

それぞれ秩父と軽井沢へ