Hadoop Conference Japan 2011 Fallに行ってきた

技術

Hadoop Conference Japan 2011 Fallに行ってきた。

eventbrite

http://hadoop-conference-japan-2011-fall.eventbrite.com/

リクルートのMIT作成のQAやら講演資料のサイト (現状、一部の資料がアップされているのみ。)

http://mit.recruit.co.jp/hadoop/conference2011fall/info/archive.html


午前中のセッションに関しては、ITProのニュースになってたり、他のブログでも書かれていたり、技術的にはこれといった話が無かったりだったので略。
午後はずっとCommyunity Trackのセッションを聞いていたので、そのまとめ。

Elastic MapReduce: Amazon Web Serviceが提供するhadoopサービス　　@shot6

Amazon Elastic MapReduce@Hadoop Conference Japan 2011 Fall
View more presentations from Shinpei Ohtani

  • アマゾンの三つのビジネス
    • Eコマース
    • マーケットプレイス
    • AWS
      • AWSは2006年から始まっている。
      • 低レベルな階層のインフラから、高い階層のツールまでをレゴのように組み立てながら作っていく。
  • AWSが提供するElastic map-reduce とは
    • 大規模データ分析をあらゆる開発者に。
    • インフラでAWSを利用することで、解析業務に集中できる。
    • 高い堅牢生を誇るS3の利用。
      • これまでにデータロストしたことや、アタック等でデータが流出したことはない。
    • Big dataはほんとにビジネスとして成立するのか？
      • 成立することが分かったらすさまじいスピードでの拡張、成立しないなら素早い撤退が必要となる。
      • リアルサーバであれば、初期投資が難しいし、大きく拡張していくことも難しい。
      • AWSでこの柔軟性を実現できる！！
  • Elastic map-reduce 概要
    • EC2、S3、Simple DB がEMRを支えている。
    • Job実行中の動的なノードの追加が可能。
    • 時間帯に応じてノード数を調整することも可能。
    • Spotインスタンスという課金方法。
      • 入札によって空いてるリソースを利用できる。
      • 動的な追加部分をSpotインスタンスで補えれば、時間、料金ともにコスト削減が可能に！！
      • 入札価格より高値での落札者が現れた場合、自分のインスタンスは停止されてしまう。
    • ブートストラップアクション
      • hadoopの実行起動引数を指定。
  • 導入事例
    • Razorfish
      • 広告の費用対効果が500%改善された。
    • Sonet
    • 一日10GBのアクセスログ解析
    • 普通に構築すると初期費用だけで数千万かかりそうなところを、年間600万で運用できている。
  • hadoopと比較して
    • 物理ハードウェア vs 仮想マシン
      • 確かに仮想マシンによる実行ではオーバーヘッドが存在し、物理マシンで実行するほうが速い。
      • でも、EMRのもたらす拡張性、柔軟性はそれに勝る魅力であると考える。
      • 何事もトレードオフ。
    • 価格に関しては、hadoopは１ラックを超えると高くなる傾向がある。
      • ネットワーク機器等の費用が増える & 結構な値段がする。
      • AWSではインスタンス単位での課金なので、リニアにスケールすることができる。
  • クラウド上のデータの安全性？
    • S3がデータをロストしたことは無い。アタック等による流出もない。
  • QA
    • 他のユーザのジョブにより、ネットワーク負荷があがり、自分が影響を受けることはあるのか？
      • ありえるが、テナント単位での帯域の上限は決まっている。また、M1 X-Large以上のインスタンスであれば、インバウンドの回線は専有となるので、ちょっとお高いがこれを利用すれば確実。

基本、他のセッションはbig dataにチャンスが眠っているというスタンスでしたが、このセッションはほんとにbig dataはビジネスにつながるのか？？という問いかけがある所が新鮮でした。(だから、初期費用もかからず、すぐに撤退できるEMRを使いましょうというセールストークな面もありますが。)
最近はTech ChrunchとかでもBig dataの解析をする会社が投資を受けたとかでニュースになっていたり、何となくbig data系がバブルになっている気がしますが、Data Ware House的なものはもっと前から存在するわけで、hadoopの登場によって参入障壁が下がった分、そこで差別化を測るのがどんどん難しくなっていったり、Map-Reduceのデザパタ本では、高度な解析よりもデータ量を集めることに注力するほうが良い結果を産み出す可能性が高いと書いてあり、そうなると、今リードしている会社が有利な戦いになってしまうので、果たして今後big dataを巡る争いはどうなっていくんだろうか？？と思いを馳せ巡らせたりしました。

LT

Hadoop and subsystems in livedoor　　　 @tagomoris

Hadoop and subsystems in livedoor #Hcj11f
View more presentations from tagomoris

  • livedoorのシステム概要
    • 2800 server
    • 3200 host
    • 今は15Gbpsくらい。
      • ↓が出たのが、2009/8なので、２年ちょいで３倍以上。

4Gbpsを超えるWebサービス構築術

Lightweight wrapper for Hive on Amazon EMR 　　　@stanaka

Lightweight wrapper for Hive on Amazon EMR
View more presentations from Shinji Tanaka

  • はてなでのhadoop利用
    • Amazon EMRとHiveを使っている。
    • 自前のクラスターを使っていたが、ジョブが溢れた。
    • 生のmap-reduceを使うと、実装者が偏ってしまい、ノウハウも偏る。
  • EMRの利用へ
    • データをS3に置かないといけない。
    • 一連(インスタンス起動-データのプット-処理の実行-実行結果のゲット-インスタンス停止)の動作を自動でやるのが大変。
  • 自動化した！
    • log2ec2.pl
      • ログを吐き出す部分と回収する部分は別の仕組みにすべし。
      • 昔、回収部分用の設定をapacheに入れたところ、それが原因で動作がおかしくなったことがあった。
      • でもやっぱりS3にデータを置くのはちょっと大変。
    • Hive実行用のpl
      • クラスタの停止を失敗すると課金が発生し続けるので、要注意。
HBaseでグラフ構造を扱う(開発中) 　　　Ameba 鈴木さん

HBaseでグラフ構造を扱う(開発中)

今はMySQLを使っているが、SPOFがあったり、シャーディング管理が面倒だったりで、HBaseへの移行を実装中。

Large-scale Graph processing 　　　@doryokujin

Large-Scale Graph Processing〜Introduction〜(完全版)
View more presentations from Takahiro Inoue

  • Map-reduce デザパタ本の五章にも載ってるよ！
  • Map-reduce
    • Graph構造も一緒にreduceに送る必要があるため、shuffleがえらいことになる。
    • そもそも本来のgraphの仕組みとmap-reduceでは相性が悪い。
  • Googleのpregelモデル
    • シンプルなアルゴリズム。
    • ネットワーク通信はメッセージのみ。
  • Pregelにインスパイアされたプロジェクトたち
    • Hama
    • GoldenOrb
    • Giraph
      • hadoopのインフラ上で動く
  • データの増大とともに計算方法の選択が求められる時代

大規模分散処理でもGraphの扱いが問題になり、最近のトレンドである所謂ソーシャルな分野でもGraph構造が取りざたされ、DB界でも@doryokujin さん主催で勉強会が開催される Graph DBが出てきて、webは元々Graphだしということで、IT業界はどこを見てもGraphに到達するんだな〜と思いました(笑)。ただ、全然キャッチアップできておらず、このLTの話もチンプンカンプンだったので、しっかりキャッチアップせねばww。

リクルート式hadoopの使い方 　　石川さん

  • リクルート自体は部門(ゼクシィ、じゃらん、carセンサー etc..)ごとに別会社な存在だが、MITは全社横断な組織。
  • 解決したかった課題。
    • バッチが終わらない。。
    • hadoop使いたかっただけな面もあり。
  • 導入への障壁
    • 現行システムに影響は与えたくない。開発工数をかけたくない。
    • エコシステムを上手く活用すべし。
  • エコシステムの活用
    • web Hiveというツールを作成した。
      • リクルートのシステム自体がSQLを駆使しており、Hiveとの親和性が高かった。
    • ツール群：https://github.com/recruitcojp/
  • 効果
    • 飲食ぐるメール
      • Hot pepperのメールマガジンのおすすめ店舗。CTR、CVRが1.6倍に！
      • 集計期間、配信人数ともに増やすことができた。
  • Mahoutの利用
    • Parallel freauent pattern mining. アソシエーション分析
      • カーセンサの同時に参照されることの多い車種表示。
    • Non distributed recommenders. あなたにおすすめの、、、
    • 分析専門の人もいるが、簡単なマイニングはMahoutをそのまま利用している。
  • hadoopの構成に関して
    • 現在は全部で118台。
    • Azkabanという監視ツール
      • USのYahooの人におすすめされて、勝手に導入したww。
      • Jobフローを図で確認。
      • 失敗時のメール送信、リトライなどの設定が可能。
  • MapRの検証も本格的にやる予定
    • スナップショット機能
    • ボリューム機能を利用したアクセス管理
      • リクルートのようなマルチテナントの会社には良さそう。

今回のイベントのメインスポンサーのリクルートさんの発表。前回のconferenceの発表では、まだ実用には至っていなさそうな感じ？でしたが、今回は実例がバンバン出てきて、ちょっとびっくりしました。現状、そんなにびっくりするようなサービスは無いですが、結婚やらグルメやら就職・転職やら習い事やら中古車購入やらマイホーム購入まで、人生の一大イベントからちょっとしたことまで、各サービス間で個人を結びつけられれば、データの量は半端ないと思うので、日本で一番データの掘りがいのある会社なのかもしれないな〜とセッションを聞きながら思いました。エンジニアで年収○○万の人におすすめの結婚式場とか！？
あと、Azkabanは聞いたこともなかったので、けっこう気になった。

Hadoop and Event collection 　　　Terjeさん

  • Flume
    • ログ転送用のミドルウェア
    • Master, agent, collector が存在する。
    • Decoratorを使って、実際に保存するデータのFilterなどが行える。
    • plugingが使える。
    • 多機能すぎて使いづらい時がある。
    • セキュリティの問題。
  • パッチを作っている
    • Master lessのAck 機能
    • OSSにコミット済み or コミット待ち。
    • どんどんOSSに貢献していくよ！
  • QA
    • なぜHBaseではなく、cassandraをチョイスしたのか？
      • HBaseは初期導入コストが高い。hadoopのインフラにコストをかけられない場合は、cassandraで作ってしまうという方法もありだと思う。

Flume知らない上に、英語だったので、あまり理解できず。。。

マーケティング向け大規模ログ解析事例紹介 NTT コミュニケーションズ 原さん

  • Hadoopワールドで発表予定の内容
  • BizストレージとBizマーケティングというクラウドサービスを展開中。
  • Bizマーケティング
    • アクセスログの解析
    • 口コミ情報の抽出
    • リッチインデクシング技術を使って口コミを解析
      • NTT研究所が開発した技術
      • ワード抽出、関連語抽出、ポジネガ抽出、位置情報抽出
  • Map-reduceの高速化
    • Map multi reduce, local reduce
    • PJoin
      • ともにNTT研究所が作成。

ミクシィにおけるhadoopの利用 　@takahi_i

Hadoop conference Japan 2011
View more presentations from Takahiko Ito

  • mixiにおけるhadoopの利用
    • 複数クラスタがあるが、いずれもデータノードの数は4-5程度。
    • ログデータ、DBコンテンツをHDFSに投入している。
  • 推薦機能
    • ニュース、チェック、レビュー等に推薦機能を導入したいと思っている。
    • Googleニュースのレコメンドタブ的な。(この機能はUSロケール限定)
    • 類似インスタンスを集めることで実現可能。
    • 文書の場合 -> 同一単語を多く含む
    • ユーザの場合 -> 同一の商品を購買した、同一のニュースを参照したetc..
    • 総当たりでの類似オブジェクトを検索しようとすると、オブジェクト数の二乗の計算量になり、効率が悪い。
  • LSH
    • 効率はいいが、精度に問題があると言われている。
    • Google ニュースで導入されているらしい。
    • インスタンス毎にベクトルを生成する。
    • ECサイトであれば、商品IDを次元とした多次元ベクトル。
    • これに関数(後述)を適用し、ユーザ毎の値を決定。
    • 関数が肝となる！
  • 実験
    • mixiニュースで推薦記事の作成を試験した
      • ニュース記事は閲覧頻度がベキ分布になってしまっているが、あまり見られていないものも見られるようにしたい。
      • 移り変わりが激しいので、高速に動作することが重要。
    • 結果
      • ニュースでは参照するニュースがカテゴリを横断してしまい、あまりいい結果がえられず。。
      • カテゴリを適用してみたら、結果がよくなった。
  • その他、作ったツール

WEB+DB PRESSで大規模データ分析が取り上げられた時の伊藤さんの記事がかなり分かり易く、likelikeを触ったり、コードを見たりしながら、知識を膨らますことができたので、今回、一番期待していたセッションでしたが、意外にもlikelikeはほとんど進化していませんでしたww。(他のツールを作ったりされていたようです。)
WEB+DB PRESS Vol.59
map-reduceのデザパタ本もhadoopを始めた人の次の一歩的な位置づけとありましたが、統計とか機械学習とかの素人な状態な自分にとって、ベタのMap-Reduce×統計処理とかデータ抽出とかっていうのは、かなり参考になる有り難いプロジェクトなので、今後、発展していくといいな〜と思う分野でした。また、likelikeのように○○のためのプロジェクトとはっきり用途が限定されていると分かり易くて良いなと思います。
(Mahoutも出てきていますが、やはり、そもそもの知識がないとMahout使っても、、、という所があったり、色々できすぎてソースコードを元にあれこれ勉強するのには不向きだったりするのかなと思ったり。)

  • 収穫物

会場で↓が先行値引き販売していて\2500円でゲット。玉川さんのLTを聞きながら、これは売れるに違いないと思い、途中離脱して買いに走りました。（LT後はやはり大行列）
おまけでビックリマンサイズの象さんのキラキラシールもGET。

Hadoop MapReduce デザインパターン ―MapReduceによる大規模テキストデータ処理

Hadoop MapReduce デザインパターン ―MapReduceによる大規模テキストデータ処理


まだ、２章までしか読んでいませんが、かなりの良書の予感。（ちなみに、@okachimachizさんのブログによると、３章が最も大事な模様。）
そして、比較的薄い本なので、気合いを入れなくても何回も読みなおす気になりそうな所も好印象です(笑)。
mixiの人やリクルートの人の発表の中でもデータの導出についての解説がありましたが、mahoutが国内でホットになっていったり、機械学習のサイトに大量にブクマがついたりと、そういう分野とhadoopとの架け橋的な存在を多くの人が求めているような気がするので、スマッシュヒットな一冊になるんじゃないかな〜と勝手に思ったりしました。