GREE Labs 第16回 オープンソーステクノロジー勉強会 にいって来ました

http://labs.gree.jp/Top/Study/20081125.htmlにいってきました
メモ書きです、ほとんど資料の板書に近いです。。。

Hadoopの概要と最新の動向

自己紹介
Hadoop概要

Googe基盤のclone

Yahoo Research Doug Cutting
が丸ぱくりで実装

MapReduceとは
  • 大規模データを集める
    • 200億Page 400TB
  • 大量のマシン
  • プロセス起動,監視,通信,debug,最適化
  • MPI
    • 並列プログラミングのライブラリ
    • プログラマは各プロセスの挙動を実現
    • 利点
      • ?
    • 問題点
      • 耐障害性への考慮なし
      • 通信コードをたくさん書かないといけない
  • MapReduce
MapReduceのつかいみち
Hadoopの実装
  • Master/Slaveアーキテクチャ
  • ファイルはブロックという単位で保存
  • name nodeはSPOF
    • namenodeがどのデータがどこにあるのか管理
Hadoop MapReduce
  • Master/Slave
  • JobTracker
    • Master
    • Jobをtakに分割し、MapとReduceのタスクに分割
    • tasktruckerにpingをうって監視
HadoopStreaming
  • いくつもの言語でmap,reduceプログラムを走らせることができる
事例
国内
  • はてな
  • メールで相談
    • 検索系(lucene),ログ処理
    • 100ノード
  • 某キャリア
    • Hadoopを分散FSとして使ってる
    • 最新バージョンだと安定しない?
その他
  • hBaseの位置づけ
    • Hadoopで動かない
    • 開発は進んでない
  • 素のテキストデータで使われる事例が多い
  • hive facebookSQLのようにHadoopを触れるものをリリース
  • データ量
    • 10Gから20Gを検索したり
    • 40Gのindexをlucineだと数十時間
  • GFSはfileの追加ができるが、Hadoopは対応してない
    • ログは追記では?
    • 1G,2Gでログロテート
    • v1.9でファイル追記がサポートされた
  • MapReduceの事例が多いのでは?
    • ストレージの可溶性よりは計算目的?
      • 目的としては両方ある
      • 現状データ処理目的で使ってる
  • データのリフレッシュタイムはどれくらいが適切?
    • 数時間に一回DBからdumpする位の頻度
  • 100kbくらいのテキスト処理とかだとオーバーヘッド
  • 一台で処理できないデータ量、サイズに有効

HadoopとEC2による、『安くて簡単』大規模データ処理

blogeye
  • 日本中にのblogを収集
  • 書いている人の年齢、性別、都道府県を推定
  • 各属性のキーワードランキングを出す
  • http://blogeye.jp/
作ったきっかけ
  • DMのアルゴリズムを研究
  • 適応対象が必要
  • せっかく作ったので公開
データ状況
  • blogは500万サイト
  • 2億記事
  • 60万記事/day
  • 200-300GB
AmazonEC2
  • 大量のデータを処理するときはおおくのinstanceを借りる
  • HadoopからS3を読み書きライブラリあり
  • 通常4台 最大80台
blogeyeでの利用例
  • データストアはS3+MySQL
  • ブログはS3、キャッシュ、クロール、URL等の一時データはMySQL
  • クロール、属性推定はHadoop
クロール
  • クロールは重要なサーバで行わない
    • 巨大なコンテンツ、接続先が落ちている
  • データの保管
    • とりあえずMySQL
    • 一日ごとにまとめてS3にストア
      • Hadoopは小さいデータをあつかうのが不得意
インデックス
  • MySQL+Senna
  • Indexは専用サーバ
  • Webサーバにもindexのコピー
  • できるだけ多くの処理をindexPhaseで行う
著者属性推定
  • 収集したブログ記事全て
  • 日付毎ではなくてサイト毎に行う
  • MapReduce
    • Map:サイトをキーにして出力
    • Reduce:記事から著者属性を推定
  • 全記事を形態素解析してカウント
  • 80台x2日で300GB
複数jobの扱い
  • Hadoopのjobは優先度を設定可能
    • pingサーバのクロール
    • 流行ワード計算job
    • blog記事のクロール
    • 実験用job
  • 複数jobのtips
    • mapperと同時にreducerが確保されるのはもったいないので,mapper終了後にreducerが確保されるようにする
その他
  • Amazonnの中でもS3ではなくSipleDB等でもよいかも(10GB制限あり)
質問
  • 記事のまとまりを入れる際に
    • ファイルはキーと値が羅列された形なので大丈夫?(。。理解できませんでした)
  • なぜReduceフェーズを?
    • 日付毎のファイルからサイト毎の形式に変換するため
    • Reduceを一度にできる
  • Reducerは必要なふぁいるがあるかmapper(masterに問い合わせて)HTTPで引っ張ってくる
  • 秘密の機械学習
    • 単語の頻度で分類
      • この単語ああればこの属性というのをReducerで判断
    • 文体で判断してる?
      • 形容詞の使い方等
    • 論文は
  • 80台のノードでEC2とS3のバランス
    • 300GくらいだったらEC2だけでよくない?
      • EC2だとinstanceを落としたらデータが消えてしまうためS3
  • いままでAmazonに払った金額
    • 40万円/年
    • 現在はEC2ではなくて企業からサーバを借りてる
  • 環境
  • Amazonのinstanceは何を選びました?
    • 1年前は一種類しかなかった
  • EC2を80台に増やすのは簡単?
    • Javaのコマンドで簡単に増やせる
  • Hadoopのネガティブな点
    • Hadoopのrebootは2回
      • クロール処理を1台で行っていた
    • 以前は優先度設定ができなかった(
    • Reducerの開始をMapperの終了まで待たせるオプションがないこと
      • 実用上これがあるといい
    • ログが巨大になる
      • localdiskを圧迫
      • logには重要な情報はない(debug情報とかはあり)
  • Hadoop,EC2を採択した理由
    • 必要な計算力パワーに差があるためEC2
    • プログラムを書くのが便利だったのでHadoop

トラックバック一覧