転職します

このたび、今の会社を辞め、新しいところへ移ることになりました。
今まで一緒に仕事をさせていただいた方々、ありがとうございました。
この業界を離れるわけではありませんので、また縁がありましたら、よろしくお願いします。

---

 自分は他人に説教できるような偉い人間ではないので、特に教訓の様なものは書けないんだけど。でもこれは役に立つかも？と思うことがあるので、それだけ書いておきます。

「やりたい事は、やっておけ」

将来やりたいと思っている事があるなら、今のうちから少しでもやっておいた方が（実績を作っておいた方が）いいよ、という意味です。

例えばTwitter4Jの作者の方は、Twitter社に入るに当たり、「Twitterのライブラリーを作っていた」というのはかなりのアピールになっただろうと思います。

社内でも、新しいプロジェクトの担当者を決める場合、やる気が無い人よりやりたがっている人を割り当てると思います。でも顧客や上司の立場としては、やはりプロジェクトを失敗させるわけにもいかないので、経験者の方が割り当てやすいでしょう。
つまり、何か将来やりたいと思っている事があるなら、それを上司に日頃からアピールしておく。そして少しでもそれをやっておいた方がアサインされやすいだろう、という事です。
自分も「○ ○ をやってました」「じゃあ大丈夫だね」みたいな事が何度かありました。
（まぁ、大抵はその時たまたま空いている人がアサインされるんだけど(苦笑)）

---

せっかくなので、前職の事も少し書いておこうかな。悪い点は思い出すのも読む方も気分が良くないだろうから、良い点だけ(笑)

• 二次SIerである
• 基本的にみんな真面目である
• 寮があるｗ

自分が所属していた部署は、業態としては紛れも無くSIerだが、大手の一次SIerから仕事を請ける立場だった。自分のイメージとしては、
一次SIerは要件定義・基本設計・進捗管理・総合テストを主導する。
二次SIerは、基本設計辺りから詳細設計・製造（コーディング・単体テスト）・結合テスト、総合テスト辺りの担当。
三次SIerは詳細設計・製造・結合テストが主。

自分はプログラミングをやりたかったので、二次SIerの立場というのは非常に良かった。
一次SIerではプログラミングはほとんど出来ないし、三次SIerは、割り当てられた1本ずつの範囲内でしかプログラミング（最適化）できない。
二次SIerは製造の統括を行う立場なので、フレームワークを決めたり（一次SIerに指定される事もあるが）、さらにそのフレームワークを使った業務プログラムのスケルトンやテンプレートを作ったり、つまりアーキテクチャーを決める事が出来る。また、ソースレビューを行って、全体を統一する。

自分がプロジェクトを任された時は、仕様を一通り押さえた（設計書を書いて内部レビューしてるんだから当然だが）上でソースの雛形を作り、各メンバーにはそれを真似してもらった。そして作られたソースをレビューしたので、プログラム間のデータ連携の視点からもバグを抽出することが出来た。（仕様を押さえてない人がソースレビューをした場合、詳細設計レベルのバグや仕様の誤解によるコーディングミスは見つけにくいと思う）
（こういうやり方が出来たのは、小さいプロジェクトだからだろうけど） 

まぁそう書くとすごそうに見えるかもしれないが、色々沢山ミスもしているorz
例えば工数見積もりを誤って（画面の複雑度がテストに与える影響を過小に見ていた）、メンバーが夜遅くまで残業する羽目になってしまった事もあった。あれは本当に申し訳なかったし、しかしメンバー全員が協力してくれてちゃんと完成し、本当に有り難かった。

このように、（当然会社には色々な人が居るんだけど、）基本的にみんな真面目で良い人ばかりだった。
会社としてもブラック企業ではなかった。ISMSなんちゃらとかを取って、セキュリティーとかコンプライアンスの教育も毎月やってるし、メールの添付ファイルにはパスワードを付けるし、…むしろここまで真面目にやってる会社って他にあるんかな、って思うぐらい(爆)

そしてよくある話だが、SIerとして収益を上げる為に、いわゆる上流を目指すというのが会社や部署の方針であり、したがってプロジェクトマネージャーを育成するとかマネージメント力を強化するという事に重点が置かれている。
なので、プログラミング・技術を強化することはほとんど眼中に無いような気がした。（面と向かって訊ねれば、きっと「そんなことはない」という回答だと思うけど、そもそも上の人がどう考えているかを聞く機会があまり無いし。それに、セキュリティー事故を起こさない為の情報共有は毎月の様にやっているが、技術的な情報共有は…）

個人的には、二次SIerとして「アーキテクト」レベルのプログラマーの育成を考えてもいいんじゃないかと思うんだけど、会社の方針とは違うし。マネージメントも向いてないし、肩身が狭い思いをしている感じだった。
（そもそもリーダーとかが向いてないのは、学生の頃から分かっていたんだよー。高校では数学部の部長をやっていたが、兼部じゃないのが自分だけだったからであり(爆)
ちなみに数学部というのは、一部の人が思うようなものではなく、パソコンやTRPGで遊ぶ部ですｗ） 

---

次の会社では、またプログラマーとして働きます。

人数は少なめながらもすごい人達ばかりで、しかもほとんどの人は自分より年下。果たしてこの中で、自分の生半可で古い知識がどこまで通用するのか、戦々恐々であります(汗)

一方、ツールというかプロダクトの開発に携わる予定であり、開発手法等で新しい知識も得られる（身に付けなければならない）ので非常に楽しみでもあります(笑)

どうぞよろしくお願いします。 

P.S.
Twitterにも理解がある会社なので、日中につぶやくことが増えるかもしれません。
（どれくらい理解があるかと言うと、アイコンがデフォルトのままだと残念な目で見られそうな感じ(爆)）

Hadoopに興味をもった理由

自分が初めてHadoopの名を聞いたのは、2010年2月。営業の人がお客さんから問い合わせを受けて、何故か僕のところへ聞きに来たのだった。
「はどぅーぷって知ってる？」「知りません」

で、知らないままなのも気持ち悪いのでググってみたところ、最初に目に留まったのがYahoo!JAPANの吉田さんのブログ。
6時間の処理が5分ですと？！ なんと約60倍の短縮。

その頃自分が担当していたシステムでは、夜間バッチの遅さが問題になっていた。
8時間の処理が「3時間にならない？」とか言われて、小手先の最適化で多少は速くなるとしても、結局RDBがネックなのでそこまで速くなる訳が無い。

と思っていたところへ、60倍。20台のマシンで処理しているから理屈上は20倍、話半分に聞いて10倍だったとしても、8時間の処理が50分で終わる計算…！

しかし、俄然興味を持って続き（のMapReduceの説明）を見るも、WordCountの例で「なんで1を出力するの？（直接カウントした方が速そう…）」「1行ずつ読み込んでReducerへ出力するようなやり方で、どうやって（複雑な）バッチ処理をするの？」てな感じで、どうにもピンと来ない。 

次にハッとひらめいたのは、（どのサイトだったかは忘れたけど）ニューヨークタイムズが画像をPDFに変換したという話を見たとき。
どのようなプログラムだったかまでは載ってなかったけど、画像データをテキストで1行ずつ読み込むはずは無いし、PDF変換ならけっこう複雑な処理をしているはず。「Map処理で画像を1ファイルずつ読み込んで変換するようなやり方なら、プログラムは書けるんじゃないか」と。
つまり、Mapの中に変換ロジックを全て書いてしまう。
そういうやり方なら、複雑なロジックも書ける！
（今なら、複数のMapReduceで1つの業務処理を行うこともあると分かっているが、そのときは1つのMapReduceで完結させなければならないと思い込んでいた） 

しかし誤解にしても何にしても、自分の業務で使えるかもしれないと思い、継続的にHadoopについて調べるようになった。
（そしてHadoopの勉強会の存在を知り、それに参加したいと思ってTwitterのアカウントを取得し…） 

その過程でHBaseの存在も知った。
HBaseはHDFS上で動くので、MapReduceへの親和性が高いのではないかと期待。
オンラインではRDBの様にランダムアクセスしてレコードを取得・更新し、夜間バッチでの集計処理をMapReduceで高速化できれば万々歳！
（購入履歴のようなデータは、毎日顧客が入り混じって発生する。しかし集計を顧客毎に行うならば、キーを顧客にしておけば、HBaseでは顧客毎にデータが配置されることになるから、Map処理で分散しやすいのではないかと思う。店舗毎の集計なら、普通に全データを分散走査すればいいし）

---

ここまで書いてきた通り、自分の興味は「バッチを高速化する」ことであって、ビッグデータとか分析・ログ解析とかは全然関係ない。
（担当システムのRDBが遅かったのは1億件超のデータを持っていたからだけど、バイト数に直したら1TBにも満たないと思う）

「ビッグデータ」はバズワード化しつつあるような気がするけど、Hadoopはビッグデータとは関係なしに、バッチ処理を高速化することに使えると思う。

---

そこへ登場したAsakusa Frameworkは驚きだった。（特にそれが日本から出たということが）
そして、Hadoopをバッチ処理の高速化に使うという考えが自分にフィットした。

MapReduceを隠蔽して便利に扱うツールとしては、HiveやPigが有名。
しかしHiveの様にファイル操作をSQLで書くというのはいまいちな気がする。（そもそも既存のRDBMSでも、SQLを文字列で書いて、実行時に解析するという無駄が気に入らない。コンパイル型の言語で扱う場合、構文の解析はコンパイル時にやって欲しい。（って言うとPro*Cみたいになっちゃうのか(苦笑)））
また、Pigは関数型言語に似ている気がするので、個人的にはHiveよりはPigを推したい。（CSVファイルの集計の例では、Pigの方が速かったしｗ）

象本にはCascadingも載っていたが、日本のSIerではプログラミングは忌避される傾向にあるので、自分はプログラミングが好きだけど、あまり推せない気分。

やはり日本発のプロダクトとして、AsakusaFWが気に入っている。
同様に、自分では触っていないけれども、日本発であるJubatusやFluent・MessagePackといったプロダクトも、陰ながら応援しています。

HadoopでCSVファイルを集計するサンプル

HadoopでCSVファイルの色々な項目をキーとして集計するサンプルを作ってみた。
Hadoopでというか、Pig・Hive・AsakusaFW（WindGate）・Cascadingでも作ってみたんだけど。

前回のWordCountの速度比較ではAsakusaFWは残念な結果になっていたけれど、今回はAsakusaFWの実行速度が一番速かった。
AsakusaFWの複数ジョブにまたがる最適化が効いた感じ。素晴らしい！（ステマｗ） 

ちなみにWindGateではローカルにファイルが出力できるんだけど、UNIX上で動かしたのに、なぜか改行コードがCRLFになってた…。
なもんで、他プロダクトの結果とdiffをとっても一致しない(苦笑)
おかげで改行コードCRを無視する「diff --strip-trailing-cr」というオプションがある事を知ったよｗ

あと、Hiveはパラメーター渡しが出来ないとかカンマ区切りでの出力を直接はサポートしてないとか、細かいところが気になる(苦笑)
簡単に対応できそうな気がするんだけどな。カンマ区切りとか、需要無いんだろうか？
select文は今までのRDBMSの知識で直感的に書けるから、対話型で使うには便利。やはりバッチで使おうとするのが間違いか。
対話型で使うなら、パラメーター渡しの必要なんてないし。

Hadoopソースコードリーディング第8回の感想

2012/2/8のHadoopソースコードリーディング第8回に行ってきました！
（→Togetter、他の人のメモ：johtaniさん、taro_xさん） 

今回の最初は、@muddydixonさんの『オレオレMultipleInputを作る方法』（→資料）。
MongoDBからデータを読み込むMongoMultipleInputsを作ったという話。
「Mongoパス（URL）と読み込む条件とそれを処理するMapperクラス」を複数指定し、別々のMapTaskとして同時に処理できるということのようだ。
ただ、現状ではMongoDBのチャンク（分散場所の情報かな？）を見ているわけではないので、ネットワークの負荷はかかりそうな感じ。
キーと値にはBSONWritableが指定できる。
ソースコードも見せてもらって、「ソースコードリーディング」らしかった(笑)

あと、TaggedInputSplitがprivateクラスなので直接扱えないという話があった。
自分も昔AntのCopyTaskを拡張したかったときにprivateだったりfinalだったりにやられたことがあるので、残念な気持ちは分かる。
オブジェクト指向には反するけど、privateやfinalを使うのはやめて欲しいな（←暴言）

---

次は、リクルートさん…の前に、急遽EMCの草薙さんからMapRの説明。

製品名が最近『Greenplum MR』（このMRはMapRのこと？）に変わったが、「MapR M5 Edition」と同じ。
MapR社が約2年間ステルスモードで開発し、2011年5月に発表。EMC社は分散DBをやっていたので、MapRと協業することになったらしい。

MapRはOSSではない。HDFSをMapR FSに置き換えた。
MapReduceは100％互換で、Javaのプログラムがそのまま動く。
MapR1.2はHadoop0.20.2にパッチを当てたもので、CDH3u2に近いらしい。
（「近い」ということは「同じではない」ということなので、本番環境がMapRで開発環境がApache HadoopやCDHというのは、やめた方がいいだろうなぁ） 

---

で、@tf0054さん・@tatakabaさん・@tsubo0423さん達のMapR検証結果報告。（→資料）

まずは性能検証ということで、中古車サイトで実際に使われているデータを使って検証。スレーブは4台。
言語は、リクルートさんの中で一番使われているHive。（MapR自体はPigもサポートしているらしい）
「パーティション・ビルトイン圧縮」でCDH3の1.3倍、「非パーティション・非圧縮」で1.76倍。MapRはHDFSの2～5倍と宣伝していたと思うけど、そこまでは行かなかったとのこと。まぁ、環境・対象データ・アプリケーションが違えば差も変わるよね＾＾；
（MapRの推奨構成では、1台当たりのディスク数が多いらしい） 

次いで、マルチテナント検証。
つまり複数のユーザーで1つのクラスターを共有して、セキュリティーや運用コスト（余剰リソースの有効活用）が大丈夫かという話。
しかしMapRのユーザーはLinuxユーザー準拠で、特にMapR独自のユーザー体系は無く、データアクセス権はApache Hadoopと同じらしい。
パーミッションはクラスターパーミッション・ボリュームパーミッション。
ボリュームのポリシーはユーザー毎の使用量やレプリケーション数、トポロジー制限（ラック指定）が出来る。
ファイルのパーミッションについてはhadoop fsコマンドで指定するらしい。
結論として、思ったほどセキュリティーが強いわけではなかったとのこと。

MapRのスケジューラーは、FairScheduler。
複数のプールを持つジョブスケジューラーらしい。
プール毎に設定された（タスク実行のスロット数の）MIN/MAXの遵守を基本とした上で、プール毎の割当量を平等に保とうとする。
割り当てられたスロット数に応じて課金するとか考えられるんじゃないかとのこと。

MapRのサーバー構成では、HDFSのようなMaster/Slaveは意識する必要が無いらしい。
全体を管理しているCLDBは3台まで同時に稼動できる（マニュアルを無視して11台全部に入れても動いたらしいが、サポート対象外となる）。
JobTrackerは1台だけで稼動し、2台はスタンバイしている。
（CLDBやJobTrackerの情報など、Hadoopならローカル（temp）に置くようなデータでも、MapRは全てMapR FS上の専用のボリュームに持つ）
フェイルオーバーすると、Job実行中のものは引き継いで再実行してくれる。
JobTracker障害の検知まで30秒、次のJobTrackerを決めるまで1分、引継ぎが完了する（次のジョブが受け付けられるようになる）まで5分、ジョブが再開するまで15分くらいだったそうだ。（いずれの時間も、最初の障害発生からの経過時間）
（そういえば、HDFSのNameNodeはDRBDやHeartbeat（Pacemaker）で冗長化するという話があるが、これの切り替えはどれくらいの時間がかかるものなんだろうな？）

速度が速いことで注目を集めているNFSマウントは、NFSゲートウェイをサーバー側に置く方法とクライアント側に置く方法の2種類がある。
クライアントが1台しか無いと差はあまり無いが、クライアント3台から同時に200MBのファイルを500個転送したら、サーバー側だと18分、クライアント側だと9分。
サーバー側だとNIC（ネットワークカード）が1つしか使われないのに対し、クライアント側だとNICが全部使われるし、データを圧縮してから転送するのでネットワークの効率が良いらしい。
ただしクライアント側にもMapRをインストールする必要があるので、その分のライセンスは必要だとか＾＾；

---

最後に、（MapRとは関係ないと思うけど）Mesosの環境も作ってみたそうだ。
まさかここでMesosの名前を聞くとは思わなかった！日本語の情報がほとんど無いので、どういうものか知りたかったんだよね～。 

MesosはApache Incubatorのプロジェクト（Apacheのトップレベルプロジェクトではない）で、リソース共有機能を持つクラスターマネージャー。C++で書かれている。
Mesos上で動く対象は、Hadoop、MPI、Spark、Hypertable。
（Hypertableと言えば、GoogleのBigTableを模したNoSQLだったような。HBaseもBigTableがモデルだけど、HypertableはC++で書かれていたはず）
（Sparkは、Scalaで分散処理を記述できるライブラリー（フレームワーク）。単独環境ではMesosは不要だが、実際に分散させるにはMesosが必要）

Mesosはmaster/slave/application（framework）という3つの役割の構成で、マスターがリソースを管理する。アプリがマスターに問い合わせ、スレーブで動かすという感じだろうか。

MesosをダウンロードするとHadoopも入っているそうで、Mesos上でHadoopが動く。
MesosマスターがJobTrackerの代わりとして動き、TaskTrackerはMesosから指示されて起動するんだそうだ。
（通常のHadoopのJobTracker・TaskTrackerの動作と違うから、Apache Hadoopそのものとは思えないんだけど、どうなんだろう？あ、confのxmlファイルでMesos独自のクラスを指定しているということかな？）

この仕組みを利用して、Mesos上でHadoopインスタンスを2つ実行させてみたそうだ。（Sparkとも共存できるらしい）
ユーザー管理はMapRと同じくOSユーザーを使用する。
お互いのHadoopインスタンスにはアクセスできないので、セキュリティー的にはOK。
ただしsudoを使ったりconfを切り替えたりすると見えてしまう…。
また、CPUやメモリーの使用率に制限をかけることは出来ない。

---

結論として、リクルートさんの評価は、性能や運用面ではMapRが良いが、サポート・将来性・ドキュメントではCDH。
やはり大企業で使う場合、サポート体制を重視する人が居るものらしい(苦笑)
CDH（Cloudera）はNTTDさんがサポートについているしね～。と持ち上げられて、@hamakenさんも困惑気味だったけど＾＾；

そういえば、質疑ではClouderaの@shiumachiさんがいつもより盛んに質問していた。やっぱり興味あるんだろうな(笑)

また、何かの書籍の執筆も進んでいる模様。
CDH3u3でHDFSが速くなった、という要因にも触れられているとかで、楽しみ＾＾ 

何はともあれ、思っていた以上に面白かったです。ありがとうございました。

AsakusaFW人力車

なんかAsakusa Frameworkに関して「Jinrikisha」っていうのが出ていて驚いた。
どういうネーミングで来るか油断も隙も無いなｗ

Jinrikishaは、AsakusaFW開発環境のインストーラー。
自分は既にAsakusaFWをインストールしているからスルーしてもいいかなーと思いつつ、せっかくなので新しいVMイメージを作って使ってみた。 

今までのインストール方式は、事前に環境変数ASAKUSA_HOMEを定義しておいて、Mavenをインストールして…と色々な手順を踏む必要があったが、Jinrikishaは必要なソフトを全てインストールしてくれる。setup.shを起動したら最初にいくつか選択肢に答えるだけで、後は勝手にやってくれるので、とても便利。

しかもインストール先は1つのディレクトリー内に全てかたまるので、あちこちに入ってどこに行ったか分からなくなるようなことがない。
既に同じソフトをインストールしていた場合は二重に入ってしまうことになるが、完全に独立した環境に出来るので、これはこれで便利だ。
（特に通常のMavenのリポジトリーは、ピリオドから始まる隠しディレクトリーに入っているから、Eclipseでソースの添付に指定できなかったりして、不便だったんだよね）