最近は仕事終えて、速攻で帰宅してから家事と育児の手伝いをしていたりして、どうしてもゆっくりとPCに向かう時間がなくってとっても久しぶりなブログの更新になりました。

今日は午後からHadoop Conferenceというイベントに参加したのですが、参加されている人達の層は自分の予想に反して意外とスーツ来た人が（含む自分）多いなぁというのが率直な所ですが、内容は前半が技術色が強く後半にビジネス的な側面の話という感じがして、自分のような立場の人間からするととってもバランス良く話が聞けて、かつ中身も濃かったので、参加してよかったです。
※今回会場の提供や運営に関わった皆様、おつかれさまでした＆こういう濃い内容のものを実施していただきありがとうございます！

Macbook AIrのバッテリが持つ限りでメモを取ったのでいくつか気になった所をピックアップします（長文エントリでごめんなさい）

■Hadoop入門より

■楽天市場の Hadoop利用事例について

■楽天研究所

■Scala on Hadoop

■Elastic Map Reduceでお手軽 Wikipediaマイニング

■Hadoop Worldの紹介

■Hadoop入門より
このセッション以外でも他の方もお話されていましたが、Hadoopと既存のRDBを、適材適所使い分けをしていくということをお話されていました。Hadoopはバッチ処理が得意。その場でリアルタイムで処理するのが苦手なのでOLAP的な処理はRDBMSが得意。２つをくっつけて大量データ、非構造的なデータをHadopで処理し、対話的なBI処理はRDBMSっていう感じのすみわけっていう感じとのことで、どんなものでも銀の弾丸っていうのは無いっていうことを改めて意識させられました。


■楽天市場の Hadoop利用事例について

すでに利用が始まっているのでそのあたりの話が出て後半については楽天研究所での取り組みの紹介。全部では無いですがここは事前に期待していたセッションなのでちょっと多めに取り上げます

- 楽天の紹介
楽天市場の常用（２００８年度）
売上6638億円
会員5000万人突破
受注件数8447万件

-楽天市場の課題
楽天会員は20万ID/月増加
大規模データの解析処理というのは言うは易し、行うは難しい
-楽天の内部の経緯
楽天研究所で関連技術の検証
社内のエンジニアで勉強会実施
データ管理に着いてはROMAが選択肢
データ処理は Hadoopを検討
-楽天の Hadoopの環境
2009年3月からトライアルで運用開始。マスタ1台、スレーブ13台。スモールスタート。
2009年より一部で本番運用開始。現在はログ解析なんかに集中している
MapReduceはビジネスロジックに集中出来るのが良いとのこと。
-利用用途
データ解析（ex.レコメンデーションなど）
-利用事例１’広告のユニークユーザの分析
行動ターゲティング広告のユーザ分析で利用。分析結果をマーケティングへ
導入背景としては広告の配信料が爆発的に増加しており、リアルタイム性の向上などが要求されている

※最後の質疑応答でこんな話題がでました。
Q.　Hadoopはバッチ処理だと思うが、リアルタイム性というのはどうなのか？
A.　単純に時間がかかっていたのが解決した
（以前は１日かかっていたのが短くなったという意味で、最近の状況がリアルタイムに把握出来るという意味ではないみたい）

導入効果としてはスケーラビリティの確保。（以前はPerlで独自のスクリプト　24時間かかっていたのが６時間に短縮はできたが今後のスケーラビリティが確保出来たのが何よりも大きい）
-利用事例２：レコメンデーション
裏側で Hadoopが利用。
複数のステップのMap Reduceを行い商品の類似度を算出
購買ログが２億件が10G程度存在しており、Map Reduceで算出
    

■楽天研究所

-Hadoopで集合知プログラミング

利用者のデータを利用して計算を行い、ユーザがもっと便利にもっと楽しく
もっとも簡単な例としてはランキング
※具体的な手法としてはオライリーの集合知プログラミングを

K-meansが実際に Hadoopで利用出来るのか？
楽天の商品を2000万件をk-meansでクラスタリング（数GB単位のデータ）
がんばっても１週間ほどかかりそうだったので、Apache Mahoutをトライ。Hadoopで動くように別のアルゴリズムを試して１日（17時間）で終了
※最後の質疑応答でこんな質問がでました
Q. k-meansでクラスタリングする時に何度か演算処理が発生するので実際にそこのオーバーヘッドは無いか？
A.そこまでは無いみたい
                 

■ Scala on Hadoop

-はてなでの Hadoop
自作サーバ10台。オフィスにおいて電源代節約。結構ゆるい感じで運用しているとのこと。蓄積されるデータははてダで7G/day、はてブで5G/day、うごめもで3G/day※ジョブは300/day

利用実績としては、2008年5月頃から調査開始して、2008年8月に稼働。
- Hadoop streaming
設定はYAMLで行う。営業やマーケティングの人向けを想定してWebUIも作ったがあまり完成度が高くないので利用されていないみたい

限界が出て来た。遅い（Perlの問題？）ジョブをKILLしてもプロセスが残ることがある。HDFS操作が遅い

ここでScalaの採用！
※最後の質疑応答でこんな質問がでました。
Q. カカクコムの方からの質問でHadoop streamingとScalaとの比較
A. ログのフォーマットが変更になった事も有り単純な比較が出来ないが、数倍に速度があがったと思う


■ Elastic Map Reduceでお手軽 Wikipediaマイニング

数百行程度のpythonスクリプトで大規模データ処理を実現する例を紹介。90万記事程度のwikipediaの日本語を題材に
AmazonEC2/S3とElastic Map Reduceを活用。

結構実践的な話が多く、実際に試した人ならではの話（S3は頻繁な入出力が想定されていないインフラのようなので頻繁に読み書きがされる用途ではパフォーマンス面ではオススメできないとのこと）とか、実際の分析結果（年、国名とかが上位にくるがこれを除外するようにフィルタリングすると、明治、神部天皇とかがPagerankとして高い...）という話は面白かったなぁ。

AmazonEC2/S3、Elastic Map Reduce良い/悪い部分もまとめてくださいました。
-良い点：かんたん。小規模なジョブならMasterの値段分安い。お手軽。１時間１台0.1ドルなので、１時間100台1000円
-悪い所：多数のジョブを走らせる事を考えるともったいない。ログが見にくい（開発時には生産性低下につながる？）。独自のディスクイメージが利用出来ない。

Q.amazonのサービスは時間によってパフォーマンスの差があると聞いた事があるが、実際にそのような事があったのか？
A.ある程度台数をつかっているからかもしれないが、時間によって差があるというのはかんじられなかった。（せいぜい2,3分）
※アメリカの昼時間帯に実際にジョブを実行していたとのこと。


■ Hadoop Worldの紹介

ネットワンUSAの柳下さんがシリコンバレーで新規商材の開発なんかをやっているそうです。場慣れしていて、話がとっても面白く、事前にそこまで期待してなかった（ごめんなさい！）のですが、実は一番収穫多かったのがこのセッション。

Hadoop Worldという所でのユーザ事例をいくつかお話いただき、yahoo、facebookというわかりやすい所はもちろん、予想してなかったエンタープライズ系の事例で金融（JPモルガン）とかテレコム（CHinaMobile）関連の話。

Yahooとfacebookのはちょっと割愛して、エンタープライズの所をピックアップします
- JPモルガンの事例
背景：経済的理由と選択肢として利用（web2.0系の技術を企業へ、RBDのoveruse、NO SQL への盛り上がり、金融業界固有のコンプライアンスニーズとして大量のデータをアーカイブしないといけないという事情）

JPモルガンのでのHadoopの今後の課題：SQLフロントエンドツールの進化と相互接続性とか、企業の既存環境、コンテンツを活かせる仕組み。あとはやっぱりセキュリティとか。

- China Mobileの事例
５億人のユーザ！（日本とは比較にならない）。CDR（Calling data Record）というのが支社レベル（5000万人）音声で100GB/day、SMSで100-200GB/dayもあるようなデータ量

現在のシステムの限界。高すぎるHWへの投資。62%の投資がHW。スケールできないため、こういうのを解決するために、トライアルではあるがすでに運用開始されている。