Java（HashMap版）WordCount

各種言語によるWordCountの速度比較で、Awkで連想配列を使ったバージョンが速かったので、JavaでHashMapを使ったバージョンを作ってみた。
すると、予想通り（データ量が少ないので実行速度の差は僅差だが）Java版の方が最速になった。

意外だったのは、単独環境と分散環境でHadoopの処理方式がだいぶ異なるようだ、ということ。

160MB程度のデータ量では、分散させずに単独環境で実行した方が速い！
以前『Hadoop Conference Japan 2011 秋』で御徒町さんが名古屋の流通業の事例で「分散しないHadoop」で動かしている（単独環境で動かした方が速い、データ量が増えてきたら分散させる、プログラム修正は要らないし）という話をしていたけど、（データ量次第だろうけど）その通りのようだ＾＾；

また、ヒープサイズ不足で落ちるかどうかというのも異なる。
単独環境で落ちなかったからと言って分散環境で大丈夫とは言えないようなので、油断は禁物。
（環境が違えば扱えるデータ量や速度に違いが出るのは当然だけど。チューニングは本番環境でやらないと意味が無いってやつですね(苦笑)）

AsakusaFW版WordCount修正

AsakusaFWの演算子リファレンスを見ていたら、抽出演算子（Extract）というのがあるのを発見！
Mapタイプで、入力1レコードに対し複数レコードの出力が出来る！
これが無いと思ってたからWordCountの単語分割をCoGroupでやってたんだよーorz
（batchapp版WordCountとWindGate版WordCountのサンプルを修正した）

これで、以前速度を測定したときに遅かったWordCountが速くなるかな？！
と期待したのだが、しかしほとんど変わらなかった…orz

でもログを見てみると、Combinerの出力件数が0件！（もっと早く気付けよ自分orz）
Summarized演算子にPARTIALを追加したら、劇的に速くなった。
（まだデフォルトではCombinerを使うようになっていないみたい）

AsakusaFWはepilogue.fileioというジョブを最後に実行するから、その所為でMapReduce APIを直接使ったWordCountには勝てないが、PigやHiveは上回ったし、いい感じの速度は出るようになったと思う。

Java7新文法

ちょっと時間が出来たので、気になっていたJDK1.7の新文法をちょっとだけ試してみた。

try～catchを除けば、やはりちょっとした変更ばっかりという感じかな。

クラスライブラリーの変更は使ってみないと分からないので、当面気付かないだろう(苦笑)

Apache Hadoop on Windows Azureの片鱗

蒼の王座というサイトにApache Hadoop on Windows Azureの操作例その１という記事が載っているのを発見。

マイクロソフトがDryadを諦めてAzure上でHadoopを使えるようにすると聞いて どんな風になるのか興味があったんだけど、この記事のおかげで片鱗が分かった気がする。

円周率算出やWordCountのサンプルを実行するコマンドが
call hadoop.cmd jar hadoop-examples-0.20.203.1-SNAPSHOT.jar pi 16 10000000
call hadoop.cmd jar hadoop-examples-0.20.203.1-SNAPSHOT.jar wordcount /example/data/davinci.txt DaVinciAllTopWords
という具合。

やはりJavaだから、基本はUNIX版と同じ。
Hadoopのバージョンは0.20.203がベースっぽい。
ファイルシステムもHDFSであることは変わらないようだし、ブラウザーから参照する為の管理用ポートも50030・50070で、同じだ(笑)
Azureの「call」がDOSと同じ意味のコマンドなら、hadoop.cmdはバッチファイルかな。
UNIX版ならhadoopシェルを使って起動するところだから、さすがにCygwinを使ったりせず(笑)、ちゃんとWindows用に置き換えているわけだ。

Azure用のHadoop本体のソースはきっと公開されていないと思うけど、Windows向けに色々改造しているんだろうなぁ。
そもそも元のHadoopがWindowsで動かす際にCygwinを使う必要があったのは、内部でchmodやdfといったUNIXコマンドを呼び出しているからだと思う。他にも色々あるだろうけど、そういった所を全部洗い出して修正するのは、個人ではやる気がしないが＾＾；、マイクロソフトが本気を出せばちょろい事だよなーきっと。

ダイスの目の散らばり方

ダイス（さいころ）って、ある面とその真裏の面の数字を足したら必ず「面数+1」になるものだと思ってたんだけど。6面ダイスはまず間違いなくそうなってるよね。

ところが8面ダイスを見ていたら、どうもそうなっていない。つーか、手持ちのダイスを見てみたら、10面から20面のどれもそーなってないじゃん！

という訳で、どんな風に数値が並んでいたらいいのかちょっと考えてみた。

そもそも、隣り合った面の数値は近い方がいいのか、離れていた方がいいのか？
値が近い場合、例えば1が出そうな状態で1つずれたら、やはり小さい数のまま。
逆に値が離れている場合、1つずれたら大きい数になる。
前者だと、100面ダイスとかを考えたときに、1の周りが小さい数で埋まり100の周りが大きい数で埋まってる感じが顕著になるはず。ダイスの転がり方を制御できるような技能の持ち主にとっては狙いやすいダイスになってしまうので、よくないな。
という訳で、隣り合った数値は差が大きい方が良いようだ。

あとは、各面の値割り当ての全パターンを試してみて、隣り合った数値の差を計算してみればいい。
という訳で8面ダイスで計算してみた。左側が真裏との合計が一定数になるもので、右側はそういう縛りは無いもの。（この図は、8面ダイスを頂点から眺めて、真ん中で切ってスライドしたようなイメージ）

＼ 3／ 5× 7 ／ 1＼ ＼ 8／ 2× 4 ／ 6＼

＼ 3／ 8× 6 ／ 1＼ ＼ 5／ 2× 4 ／ 7＼

右側のパターンだと、1の周りは6,7,8で固まっている。分かりやすいな＾＾；
左側のパターンでも、1の周りは8以外の最大の数で固まっている。
隣り合った数値の散らばり具合を評価する式（隣の数値との差を2乗して全て合算した値が最大のものを抽出）がこれでいいのかどうか、ちょっと自信ないなぁ。