ソフトウェアデザイン2月号はHadoopのはなしです

Riak CSは以前にも紹介したとおり、S3とほぼ同じAPIを持っているのでMapReduceに入っているjets3tがそのまま使えるので、HDFSの代わりにRiak CS使ってみようよという試みです。以前ぼくもHDFSにデータを出し入れしようとしたら結構たいへんだったので、Riak CSが使える場面もまあまああるかもしれない。一方でMapReduceは、分散処理においては他に選択肢がない。最近でこそいろいろ出てきたがやはり鉄板でして…

他に選択肢がないとは、どういうことかというと、自分たちの環境やユースケースに合わず多少使いにくくても我慢して使わなければならないということ *1。特にHDFSバッチ処理のための分散ファイルシステムとしては非常に優れており、高性能で安定していたが、ネームノードを特別扱いする運用が複雑になったり、ユーザー管理の仕組みがあとづけであったり、インターフェースが独自のものであったりと、通常のファイルシステムには、使いやすさは及ばない(当たり前なのだけど)。特に、比較的小さなファイルを大量に管理したい場合にはネームノードのメモリが不足しがちになる。これに対して、市場ではいくつかの分散ファイルシステムが登場した。GlusterFSはその筆頭でしょう。また、AmazonのS3もサービスであるが、これは技術的には分散ファイルシステムで構成される(と想像される)。実際にHadoopが必要な場面で、HDFSである必要がない場合もあります。HDFSが特に有効なのはI/O分散が可能だからで、I/Oインテンシブなワークロードに対して絶対的な優位性を今でも持っている。

実はMapReduceが動くのでHiveも動くと想像されるのだけど、Hive力が足りずなかなか手を動かせていない状態。黄色い象蜂が得意な人誰か試してみてくれないかなあ。

追記

同僚がErlang/OTPの入門記事を書いているので、そちらもどうぞ。まあ言語というよりは処理系の宣伝になってしまっていますが…

追記2: あわせて読みたい

Hadoop 第3版

Hadoop 第3版

*1:もちろん、自分が便利なようにパッチを送る、別のものを自分で作る等の選択肢はあ るし、Hadoopコミュニティは多様なニーズに適応しようと努力している。しかし、これではあまりに時間と手間がかかる場合がある