夜行録 - 酔歩.net

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

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

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

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

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 とも連携できる

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

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

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

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

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

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

開発で使って遊んでいた EC2 の GPU インスタンスが、急に使えなくなった。

なにか変な操作した挙句、うっかり CUDA-7.0 の上に CUDA-7.5 入れてしまって、どうもドライバを変に上書きしてしまった模様。 なにせ nvidia-smi が kill されるとか、２回目はプロセスが刺さるとか、自分のコードでもデバイスチェックしに行って刺さるとかそのまま load av. が果てしなく上昇するとか全然使えない。

問題は、ここからどうやっても元に戻せなくなったこと。最後は新しいインスタンス作ってクリーンなところからインストールし直したけどどうしてもダメ。

というか、 CUDA のインストールを local repo 版でやったんだが、どうもそれが駄目で、

に従って、 .run を手でインストールしたらこれはちゃんと動くようになった。納得いかん

最初に動いてた環境も local repo 版からのインストールだったはずなんだがなぁ。

半月ぐらい空費したが、なんとか開発続行できるようになり、判りにくいバグをなんとか半日かけて解析して、８月中に終わらせたかった開発はやっと１段落である。

懸案だった機種変更にやっと踏み切った。
前機種はもう、メモリに対して動いてるアプリのメモリ要求が大きすぎて、タスクスイッチは遅いわレスポンスは遅いわタップは２、３回に１回無視されるわ酷いもんだった。

しかし小さい機種ないよね。一番小さくてもこの有様。重い。持ちにくい。

[read more]

アホほど伸びたヒポエステス。
小さな鉢がなかったので余っていたのに適当に植えたら一瞬でぴゅーーと伸びて、そのまま放置したらこの有様。

そうか、こいつは伸びたら即伐らんとダメか

流石にさっき斬った

[read more]

ホームセンターで売っててなんとなく買ったタニクシヨクフ゛ツ

買った時はちっちゃかったのに…

[read more]