自分が初めて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といったプロダクトも、陰ながら応援しています。
