第16回オープンソーステクノロジー勉強会＠GREE

第16回オープンソーステクノロジー勉強会に行ってきました。初参加です。
Hadoop関連ネタでした。

名前は、開発者Doug Cuttingの子供の持っている、ぬいぐるみの名前から。ロゴがかわいくない。
国内での使用事例も増えてきた。
今のところ、データ処理が中心で分散ファイルシステムとしての事例は少ない。
某キャリアが分散ファイルシステムとして、ある程度の評価をしているらしい。
最新版の0.19はまだ安定していないが、ファイルのappendをサポートした。
想定しているデータサイズとしては、数十GB程度から。
- 1台で処理するのが厳しいときとか。
- 小さいサイズのデータ処理は、JobTrackerやTaskTrackerの起動オーバーヘッドが大きいため、有効ではない。
  - オーバーヘッドが10〜20秒程度あるため、100kのワードカウントとかでも時間がかかる。
NameNode(Master)がSingle Point of Failureとなる。
- Googleでは、Shadow NameNodeなるものがあるらしい。
大規模データ処理では、リアルタイム性(同期)はあまり考慮しない。
- 既存のDBデータとかは、1時間に1度ダンプして取り込むとか。
Hadoop上でhBaseはまだ動いていない。

500万サイトのブログを解析
- 2億記事
- 60万記事/日で増加
- テキストデータで200〜300GB
Amazon EC2 + Hadoopは相性が良い
- EC2による動的サーバ増加、Hadoopによる動的クラスタノードの追加/削除。
- HadoopからS3への読み書きライブラリがある。
クロール
- Hadoopのマスタでやらない。
- データはとりあえずMySQLへ、1日ごとにまとめてS3へストア。
インデックス
- MySQL + Senna
- このタイミングで、できるだけ多くの処理をこなす。
Mapper起動と同時にReducerが確保
- 待ちが発生してもったいないので、Mapper処理完了を待ってから、Reducerを確保するようにカスタマイズ。
  - 今後のバージョンでサポートしてほしい。
1年間の運用で、データロストはなかった。
ログが大きくなり、ローカルディスクを圧迫するので、定期的なログ削除が必要。
1年間で40万円くらいAmazonへ貢いだ。

ログ解析とかに使ったら、面白そうだなと思いました。
すぐに仕事(実務)では難しいと思いますが、数十台で試してみたいです。
懇親会では、いろいろな方とお話できて勉強になりました。
消費電力の話とか、勉強になりました。
参加された皆さん、ありがとうございました。
トラックバックを打つまでが勉強会です。