オープンソーステクノロジー勉強会に参加してきました

greeさん主催の第16回 オープンソーステクノロジー勉強会に参加してきました。今回はHadoopがお題。greeさんでの勉強会は初めて参加しましたが、定員オーバーの大盛況でした。そんな勉強会のメモを少し残しておきます。発表内容の資料がアップされていますので、そちらを合わせて読まれると分かりやすいかもしれません。

開催前

• 無線LANつながらない
• Ust見ないで！
• 回線圧迫しちゃう
• ボールペン返してください！

太田 一樹さん

• http://kzk9.net
• CTO
• Sedue
• Codeineでもつかってる
• はてなブックマークの全文検索
• hadoop の概要
• Google基盤ソフトウェアクローン
• Google File System
• MapReduce
• Yahoo ResearchのDogue Cuttieさん開発
• preferred.jp/pub/hadoop.html
• NTTレゾナンスと共同での解析
• Webページ
• 200億x20KB- = 400TB
• 1だいでは読み込むだけで１日
• お金だけでは解決できない
• プログラミングが困難
• プロセス起動
• プロセス監視
• プロセス間通信など。。
• 既存の分散／並列プログラミング環境
• MPI
• 並列プログラミングのためのライブラリ
• スパコンの世界では主流
• 　MPIの問題
• 耐障害性の考慮がすくない
• 壊れるたびにチェックポイントから戻すとかやってらんない
• 　MapReduce
• 2006年/Google
• 17万Jobs
• Avg 5/jobくらい死ぬ
• MapReduce側の処理
• Grep
• Sort
• Log Analysis
• Web graph Generation
• Inverted Index Construction
• Machine learning
• Naive Bayes
• K-manas
• Expectation
• SVM ....
• Hadoopの中身
• Hadoop distributed file system
• GFSクローン
• Master/Slave
• ファイルはブロック単位
• Hadoopは64MBごとのブロック
• NameNode
• Madter
• ファイルのメタデータ
• DataNode
• Slave
• NAmeNodeは実際のSingle point of failure
• Master/Slave architecture
• JobTracker
• Master
• Jobをタスクに分割し、Taskを各TaskTracekrに分配
• TaskTracker
• Slave
• 実際の処理を行う
• Hadoop Streaming
• 各プログラミング言語の標準入出力を利用できる
• 使用事例
• Yahoo Inc
• 2000ノードくらい
• 検索、広告、ログ処理、データ解析
• SIGIRなどでもY!Rの論文はHadoopがでてくる
• Amazon, Facebook
• 400ノードくらい
• ログ処理、データ解析
• 行動ターゲティング
• Facebookはファイブ？とかいうSQL的な文でMapReduceをたたける
• はてな
• ログ解析
• はてなブックマーク２の全文検索
• メールで何件か相談
• Lucene, ログ処理系が多い
• Cellクラスタ、EC2(blogeye)なども
• 某キャリア
• ストレージとして使ってる
• 耐障害性はOK
• 数十GBくらいのデータを取り扱うようになると利用を考えたらいいかも
• hBaseはまともに動かない
• GFSはappendできる、Hadoopはできない
• 0.19でappendをサポート
• 今のところレプリケーション（耐障害性）よりも、分散処理としての位置づけのほうが’つよい
• リアルタイムで同期は考えない
• リアルタイムでなくてもOKのような仕組みでないといけない

大倉 務さん

• http://ohkura.com/
• 24歳
• Amazonの営業ではありません
• blogeye
• 日々、日本中のblogを収集
• 属性ごとにランキングなんかがわかる
• 作ったきっかけ
• データマイニングアルゴリズムの研究
• せっかく作ったので公開
• テキストデータで200-300GB
• Blog500万サイト
• 導入コスト０に
• EC2,S3
• EC2
• 10cent/hourのレンタルサーバ
• S3
• 1month 15cent/GB
• EC2からS3の読み書きは無料
• Hadoop
• Hadoopは動的にノードの追加、削除可能
• １時間他にで利用できるEC2との相性がよい
• HadoopからS3を読み書きするライブラリは既に存在
• S3は並列化すればするほど速くなる
• Blogeyeでの利用例
• データストアはS3 + mySQL
• blog記事はS3,
• キャシュやクロール先URLはMySQL
• クロール、著さや属性推定はHadoopで分散
• 普段は４台、重い処理のMAX時は200台
• 重い処理＝著者属性推定とか
• クロール
• クロールはマスターでやらない
• 接続先のれsポンスがわるくなったり
• 巨大なコンテンツがおちてきたり
• データ保管
• とりあえずMySQLに保存
• 重複検知できる
• １日ごとにまとめてS3にストア
• インデックス
• MySQL + Senna
• indexはそれ専用サーバ
• indexのレプリカをフロントエンド(Webサーバ)においてある
• 不可分散用
• 著者属性推定ジョブ
• 扱うデータ
• 週種したBlopg記事すべて
• 日付ごとではなく、サイトごとに扱う
• MapReduce
• Map : サイトをキーにして出力
• Reduce : 記事から著者属性を推定
• 80GBx2日で300GBくらいのテキスト処理
• 4万円くらい
• 複数ジョブのあつかい
• Hadoopのジョブは優先度を設定できる
• pingサーバのクロール
• 流行ワードの計算ジョブ
• ブログ記事のクロール
• 実験用ジョブ
• Tips
• Mapper終了後にReducerも確保できるようにしている
• MapReducerが終わってもReducerが確保できなかったらもったいない
• そのほか
• Amazonの中でもS3ではなくSimpleDBでもいいかも？
• Amazonににみついだ額
• 40万/年くらい
• いまはGoogleで稼働中
• ざっくり構成
• Apache x2
• index x1
• Master + MySQL x1
• Slave x2
• IOが苦手なジョブとCPU使わないとだめなジョブを混ぜたほうが効率がよい
• Slaveのサイズ変更は手元のスクリプトで
• 昔はジョブの優先度がつけられなかった
• 悪かったところ
• ログが超でかくなる場合がある
• １週間くらいで消したり
• Hadoopそんなに悪くないよ！
• 必要なときに必要だけ使えるのがいい
• EC2 + S2 + Hadoop

感想

一番興味深かったのはHadoopの使用事例について。どれくらい使われてるものなのか、全く知らなかったのですが思ったより使われてるのかも、という印象です。大きなサイトではログ解析にHadoopを使うってのがじわじわとデファクトになりつつあるのかな？と感じました。あと、国内の大規模な利用ははてブ２が初？

あと、個人的に大規模分散ネタはこっそりやりたいことがあるのでヒマを見てHadoop触ってみたいと思いました。特にEC2との組み合わせで実現したいのですが、この組み合わせの 新しいマッシュアップサイトはどんどん出てきそうな予感がしますね。