marblejenkaの日記

2011-12-31

2011年をふりかえってみると

今年は仕事でも仕事以外の活動でもいろいろあった。いろいろなかったのは主に女の子とのおつきあいの方で、それはそれでかなり問題ではあるものの自分のやりたいことができた一年だったと思う。


総評としては例年とぶれることなくこんな感じ。まあ例年と比べると、転職地震左肢麻痺引っ越しとイレギュラーな出来事がおおく、技術的なお遊び方面での活動から距離を置いていたりといろいろあれな感じはあります。

転職、というか会社員というぬるま湯環境への復帰は今年の2月くらいだったので、意外と個人でやってる期間は短かったなあと。まあこの辺は機会の問題でもあるので、タイミングとかは割とよかったと思います。仕事はまあ微妙ですね。思ったより微妙でした。まあ周辺のいろいろなものに対して幻滅しているのは立ち位置的にちょうどいいと思います。ハイプサイクル的な意味も含んで。

地震の影響は主に精神的なほうでダメージを受けたりとかしましたが、結果としては自分が親しくしていた人に生命の害が及ぶことはなかったので、まあ。結構前から大規模な地震が起こるとは言われていて、多少の覚悟はしていたのですが、やっぱり。それと、有事に際しては事前の準備がものをいうところはあり、事が起こってからなんやかんやするというのも醜いなあと。この辺は職業観ですが。

印象的だったのはやはり左肢麻痺で、自分自身の生命の危機は他人の生命の危機より重要ですね。こればっかりは。時間的には今年の三ヶ月分くらいは持って行かれている気分です。発病直後に急快復してそこから落ち込んだりそこから波があったりいろいろ付き合いづらい病気だったので、ベンチャー気分で無理をして無駄に時間を使ってしまった感はありまくりです。普通に数ヶ月は休職すべきだったなあと。たぶん雰囲気的にはもう快復といってよい気がするので、来年からは普通にしたいなあという感じです。煙草はやめて酒の量は若干減ったとか野菜ジュースを飲むようになったとか有酸素運動をするとか、種々交々の精神的肉体的な健全さのハンドリングを意識するようになりましたね。

引っ越し先はわりといい感じです。眺めがいいのと日当たりがいいのとで、体内時計のリセット的なものが比較的ナチュラルに出来るようになった気がします。もともと実家はかなり日当たりのいい部屋だったので、それに近い環境になりました。企業参謀の人が人生変える手段として一番いいものではないけどあげてたものなので、まえからやりたかったんだけどそれができた感じ。テレビとPS3もゲットしたので、堕落できる限界も広がりました。


ところで、僕はだめな人間を見た瞬間識別するだめ人間センサーを搭載していて、それぞれの会社とか人についておおむね事前情報なしの直感と材料出尽くし後の結果は一致しています。今年はなんやかんやで中の人とふれあった会社の数が多いので、センサーがだいぶ活躍していました。

まあ結局、だめなものはだめなわけで。

ちなみに去年はこんな感じ。

そうそう、会社をやめてどうなのかというところも整理しておきたいですね。世の中仕事の仕方はいろいろだと思いますが、純粋に技術だけみたらまあしょぼいんだなあということがわかりました。予想通りでもあり、結局世の中がいかに技術をビジネスにすることを考えていないか、ということでもあり、個人的に思うところはなくはないです。割と予想通りなところはありました。

この点については問題の構造はだいぶ単純で、技術的理解が浅いタイプかValue Proposition的なあれに選択性がなくて口はでるけど手と足がでないタイプの人がほとんどですね。まあベンチャーというならそれなりのアントレプレナーシップは要求されるし、それは経営層についても同じなので、口八丁手八丁なのはともかくとしてもそれだけだとやる気の伸びしろがなくなる感じ。

あと、もといた会社の技術的な水準も世間に比べるとそれほど低くもなく、環境面だとかなりいい線いってるということも確認できました。金がすべてでないにしても、稼いでる金額との相関は一定以上にあるなあと。喉元過ぎればなんとやらとか、思い出補正とか、いろいろありますが。


では去年の目標の達成状況をみてみましょう。

・もっかい英語圏にいく。今年は、ほんとは語学留学でもいこうかなーだったのが仕事になったので、なにげにその分のコストは多少浮いていたり。

この辺はいいわけ抜きというか、電車に乗るのも怖かった時期もあり、まあむりだったのはしょうがないです。

・英語の勉強をする。とりあえず、意思疎通で支障がないとか、ちょっとかっこいい感じでものが言えるとか、そういうレベルを目指したいです。そういやフィリピンの人と話すあれもかえって来てからやってないので、気が向いたらまたやり始めようかなとか。

てへ。

・書き散らかしたコードを整理する。今年の話じゃねーかいまやれって感じがすごくしますが、まあやる気しなかったんだからいいじゃん。的は絞るべきかなと思いますが、まあなんかそこは適当にやりたいものをやろうかと思います。

これなんのことを言ってたのかわからない。今年はあんまりオープンなコードは書いてなかったので、まあ見なかったことにしようかなあと。


来年の目標ですが、まあこういうのは願望を書くものだというのがわかってきたので、適当に。

・英語のお勉強、というか海外旅行がしたいですね。シンガポールとか東南アジア方面をバイクか自転車で回るとか。結構前にジムロジャーズの本を読んで以来やりたいことではあったけど、自分探し的な感じであれかなあと思ってて、とはいえ見聞の狭さは如何ともしがたく。最近は割とまじめに検討中。

・そろそろ20代後半の人生の終盤戦に突入しそうな感じもあるので、身の振り方についてはどこかで再整理したい感じはあります。たぶん30代ではエンジニアはやっていないと思うので、そのへんですね。

・仕事方面はいろいろおろそかすぎるので、どうにかしたい感じです。まあだめだったら会社が潰れるだけなので、それはそれで。僕のセンサー的にはそれなりに成功するはずではあるのですが、いろいろ貧乏籤ですね。


変化の時代においては取捨選択が重要であるので、来年の目標にしないことも。

・技術レベルの向上はとりあえずいいかなあと。どちらかといえば実業方面に舵を切ることになるのと、とはいいつつも技術的な仕事はするけど基本的にここ数年の蓄積を使うだけになる想定。まじめにやるならもうちょっと先をみて技術に対して時間を投資すべきなんだけどエンジニアとしての成功モデルを考えると不要なものに時間を割きすぎているのとで、来年は明確なゴールはつくれなさそう。

・TOIECとかのスコア。まあTOIEC自体どうなのかという話もあるけど、とりあえず来年/再来年くらいだとこのへんの試験勉強とその結果が必要なアクションはとらない予定。再来年はやらないといけないかも。

・彼女とか。よく考えると要らない。


なんやかんやで無欲になるとチャンスが訪れることもあるので、その辺の機会をどう考えるかはタイミング次第ということで。

2011-12-03

hadoop アドベントカレンダー 2011 3日目 疑似分散モードについて

hadoopアドベントカレンダー2011 3日目の12/3を担当する@marblejenkaです。


今日は、スタンドアロンモードと義人分散モード、完全分散モードの違いを調べます。hadopoを使ったアプリケーションを開発していると、だいたいどのモードも試してみたことはあると思いますが、それぞれのモードの挙動の違い、とくに疑似分散モードと完全分散モードの違いはあまり正確には把握していないなあということで。


とりあえず、インストラクション(一台構成複数台構成)で見かける説明を抜粋すると、

・stdalone

By default, Hadoop is configured to run in a non-distributed mode, as a single Java process. This is useful for debugging.

・pseudo

Hadoop can also be run on a single-node in a pseudo-distributed mode where each Hadoop daemon runs in a separate Java process.

・fully distributed

特に記述はないけど、まあ普通にマスター1以上、スレーブ2以上な感じの構成のことを指すものかなあと。

という感じです。


hadoopの設定ファイルをつくる上では、

・stdalone

fs.default.name = file:///

dfs.replication = 指定しない

・pseudo

fs.default.name = hdfs:///

dfs.replication = 1

・fully distributed

fs.default.name = hdfs:///

dfs.replication = 2以上?

という感じで説明されることが多いと思います。



今回はいろいろ裏をとりたいので、

・クライアントからのファイルシステムに対するアクセス

・fs.default.nameの設定毎によるデーモンの挙動の違い

・dfs.replicationの設定毎によるデーモンの挙動の違い

このへんの観点で簡単にソースを洗ってみることにしました。


・クライアントからのファイルシステムに対するアクセス

適当にhadoop fs -lsくらいから追っかけていきます。bin/hadoopあたりをみると、org.apache.hadoop.fs.FsShellに飛んでいることがわかります。

そこからは適当に所与の文字列からPathを生成してファイルシステムを取得していることがわかるので、

standaloneであればローカルファイルシステムをみて、疑似分散・完全分散だとHDFSを見に行っているという感じです。Pathを生成するときのプロトコルに(指定がなければ)fs.default.nameが使用されるので、まあ各モードでそんなにおもしろい違いはないという感じです。



・fs.default.nameの設定毎によるデーモンの挙動の違い

org.apache.hadoop.fs.FileSystem

public static URI getDefaultUri(Configuration conf) {

return URI.create(fixName(conf.get(FS_DEFAULT_NAME_KEY, "file:///")));

}

とかこんな感じのところで使われていますが(FS_DEFAULT_NAME_KEYは文字列の"fs.default.name")、URIで返してるのでファイルシステムをとるところが変わるだけかなあという感じ。これもそんなにおもしろい違いはないなあという感じです。強いて言うと、org.apache.hadoop.fs.CommonConfigurationKeys.DFSConfigKeysがいろいろ泣けてくる感じです。



・dfs.replicationの設定毎によるデーモンの挙動の違い

使われているところは、

org.apache.hadoop.hdfs.server.namenode.FSNamesystem

this.defaultReplication = conf.getInt("dfs.replication", 3);

org.apache.hadoop.hdfs.server.namenode.NamenodeFsck.Result

this.replication = (short)conf.getInt("dfs.replication", 3);

org.apache.hadoop.hdfs.DFSClient

defaultReplication = (short) conf.getInt("dfs.replication", 3);

とかです。


FSNamesystemのdefaultReplicationはorg.apache.hadoop.hdfs.server.namenode.FSImageで使われているようなのですが、

// read file info

short replication = FSNamesystem.getFSNamesystem().getDefaultReplication();

LOG.info("Number of files = " + numFiles);

String path;

String parentPath = "";

INodeDirectory parentINode = fsDir.rootDir;

for (long i = 0; i < numFiles; i++) {

long modificationTime = 0;

long atime = 0;

long blockSize = 0;

path = readString(in);

replication = in.readShort();

replication = FSEditLog.adjustReplication(replication);

こんな感じでFSImageの値で上書きして無視するので、僕も無視します(inはfsimageのファイルのDataInputStream)。

NamenodeFsck.Resultは表示用で情報をとってるだけなので無視します。

DFSClientはファイルを作成する際に、NameNodeにいくつレプリカを複製するか情報を伝えるために使います。あとは、レプリカ数をこいつからとれるような口があって、ジョブの履歴にそのときのレプリケーション数を出したりとか、FileSystemにレプリカ数を伝えたりしているぽいです。

と、FileSystemに

public abstract FSDataOutputStream create(Path f,

FsPermission permission,

boolean overwrite,

int bufferSize,

short replication,

long blockSize,

Progressable progress) throws IOException;

こんな感じのレプリケーション数を指定するインターフェイスがありますが、ローカルファイルでは華麗に無視します。

/** {@inheritDoc} */

public FSDataOutputStream create(Path f, boolean overwrite, int bufferSize,

short replication, long blockSize, Progressable progress)

throws IOException {

if (exists(f) && !overwrite) {

throw new IOException("File already exists:"+f);

}

Path parent = f.getParent();

if (parent != null && !mkdirs(parent)) {

throw new IOException("Mkdirs failed to create " + parent.toString());

}

return new FSDataOutputStream(new BufferedOutputStream(

new LocalFSFileOutputStream(f, false), bufferSize), statistics);

}

また、スタンドアロンモードではレプリカ数をチェックするNameNodeのプロセスも起動させないので、ふつうにふつうのローカルファイルシステムを参照するものとして使えているようです。


と、余談ですが、dfs.replicationって0でも動くかなあと思って試してみました。だめでした。レプリカ数というか、同じブロックをトータルでいくつ持つか数的な感じですかね。

java.io.IOException: failed to create file /user/asakusa/setup.sh on client 127.0.0.1.

Requested replication 0 is less than the required minimum 1

at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startFileInternal(FSNamesystem.java:1177)

at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.startFile(FSNamesystem.java:1120)

at org.apache.hadoop.hdfs.server.namenode.NameNode.create(NameNode.java:585)

at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:557)

at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1434)

at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1430)

at java.security.AccessController.doPrivileged(Native Method)

at javax.security.auth.Subject.doAs(Subject.java:396)

at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1127)

at org.apache.hadoop.ipc.Server$Handler.run(Server.java:1428)

2


ということで、疑似分散モードと完全分散モードには大きな違いはないようで、スタンドアロンモードとは前者のふたつはFileSystemのレイヤで差異を吸収している、という感じでした。思ったよりおもしろくない感じでした。おもむろに、replication < 3とか出てきてもいいなあとか思ったのですが。

明日は @taro_x さんです。

2011-11-08

Macのeclipseでasakusaの*testerのテストを流すとか

mvnとかexperimental.shからは普通に動くけどmacだと環境変数があれでeclipseでテストがうまくうごいてなかった。現実逃避でmacの環境変数周りについてちょろっと調べたら解決したのでメモ。


環境変数周りのちゃんとしたドキュメントはこのへん。ちゃんと読んでないけど、.bash_profileに書くのはMac的にはグローバルな環境変数の設定ということにはならないらしい。よくかんがえると、.bash_profileも適当に使ってるからグローバルなのかわかんないけど。

とりあえず、lionだとlaunchctlで設定するのが筋っぽいので、そうする。hadoopとasakusaのインストールは適当にやっておく。

launchctl setenv HADOOP_HOME hadoopおいたとこ

launchctl setenv ASAKUSA_HOME asakusaおいたとこ

eclipseを落としてあげなおせば普通に環境変数を読んでテストが動く。好みはあるけど、仮想マシンのlinuxは雰囲気linuxだけどmacのキーボードから扱いづらいので、macで完結するのはわりといけてる感じ。もっとはやく現実から逃げるべきだった。

snow leoperd以前の場合、.MacOSX/environment.plistに環境変数を書いておけばいいらしい。それっぽいけど試してない。このへんもご参考まで。


あと、macで開発する人はmacのmysqlでthundergate連携するときは、my.cnfでlower_case_table_names = 0するのを忘れないようにする。