例によって私の取得してきたメモを公開したいと思います。
目次
- どんな感じのセミナーだったのか？（写真）
- 09:00-09:30 「BigDataに効く！Amazonの持つHadoopサービス、Elastic MapReduce」
- 09:30-10:10 「パネルログ分析onAWS」
- 10:20-11:00 「AmazonEMRの活用事例紹介」
- 感想
- 関連エントリ
どんな感じだったのか？（写真）
開催場所は、渋谷（東急南口付近：写真右）。Amazon さんの渋谷オフィス、クロスタワー（旧東邦生命ビル：写真下左）7Fでした。わたしは部屋の真ん中より少し後ろに座っていました。
いただいた「いろはす」（写真：左上）。 Amazon さんのオフィスはHELLOWEEN一色でした（写真：右上）。
09:00–09:30 「BigDataに効く！Amazonの持つHadoopサービス、ElasticMapReduce」 AWSソリューションアーキテクト 大谷晋平さん
- @shot6
- ohtani@amazon.co.jp
Amazon Web Service とは？
- EC2
- クラウドフロント、EMR
- セキュリティ
- 開発ツール
なぜBig Dataはそんなに大変なのか？
- 3つの課題
- データの保存、管理
- 解析・集計のためのサーバー調達と準備
- 解析・集計のトライ＆エラーがためしにくくなる
実際に解析・集計の結果を出しても実際のサービスに役立てるまでに時間がかかりすぎてしまう
Hadoop
- Big Dataを扱うための分散処理フレームワーク
- HDFS＆Mapreduce
エンドユーザが受けるメリット
- 誰でも入手可能
- スケーラブル
- 柔軟性
- 実績も多く、pbオーダーまでリニアにスケールすることがわかっている
RDBMSとHadoopの違い
- 代替ではない
- RDBMS
→OLTP、リアルタイム処理 - Hadoop
→DSS、大規模処理
Hadoopの課題
- スケーラビリティを活かすためには大量のサーバが必要
- 購入してしまうと拡張も困難。
- 自由にノードを追加・縮小できない
Hadoopのスタック
- Hiveのユーザー多し
EMR
- 大規模データ処理基盤をあらゆる開発者に
- Hadoopをオンデマンドで利用可能
- 分析・解析にアプリケーションを集中できる
- S3による入力・出力を保存
Big Data処理のための猥雑なことを肩代わり
- 解析にtry＆Errorができる→Adhoc性
- AWSの他のサービスとのインテグレーション
EMRのサポートするHadoopのバージョン
- 0.18
- 0.20
EMR全体のアーキテクチャ
- InとOutのデータはS3に。
EMRを支えるAWSプラットフォーム
- EC2
- S3
- SimpleDB
→Config情報など
処理の流れ
- Upload data to Amazon S3 Bucket
- Create a job flow on Amazon Elastic Mapreduce
- Get result from Amazon S3 Bucket.
好きな言語で利用可能
- Webブラウザ上の管理コンソール
EMRでのアプリケーション記述
- Hadoop Streaming
- Hive
- MapReduce Application
EMRのデモ
- Suggest where the datas are and where to output?
- input location, output location
- Suggest the number of servers.
- master instance group
- core instance group
- task instance group
#Also can be conducted by the CLI.
- elastic-mapreduce command.
- Can easily suggest each parameters.
- So actually if you want to use EMR, using CLI brings you more efficiency.
- Sample(Demo) program was written in Python.
#Any program language can be acceptable.
EMR 機能
- 稼働中、ジョブフローの拡張
- 途中で稼働ノード数を変更できる（上げ下げ可能）
※上げれば、もちろん余計にお金はかかるのだが。
★EMR＋Spotインスタンス、”ランデヴー”
- EMRを活用し始めると、更にAdhocなクエリをどんどん実行したくなる現象が起こり始める
- Spotインスタンスは、指定価格で従量課金。オークション形式き。
- 拡張＋Spotインスタンス
事例
クリックストリーム分析 RazorFish
- 巨大小売店向け
- 4,000 万かかっていた解析→初期費用0、運営100万円
SoNet
- 広告配信のログの解析に使用
- 1日平均10GB、年間3．６５TB
- EMR＋S3＋SQS
Fourcsquare
- スマートフォンのチェックインデータ
- 機会学習、データ分析、トレンド分析、レポーティング
- 平均40ノードEMR
- 基本的には Ruby on Rails でできている
- Apache Flume でログ収集
- ログ保存、S3
Etsy
- 年商30M＄の巨大小売
- 434GBのログ解析
- Akamai経由でログを取得し、解析に回す
- cookpad, hatena, NETFLIX...
EMR のロードマップ
- より最新のHadoopサポート
まとめ
- Big Dataのためのキラーソリューション
- EMRはHadoopの煩わしさをカバーする
- 解析をより手軽に、を実現する
- S3によるデータの堅牢性
QA
S3への上げ方
- LZOやtar で圧縮可能
- 定期的に1時間に1回とかUploadする
- ログ集中のライブラリを利用する
→e.g. Flume(java), Scribe(C++), fluent(Ruby)
EC2を使う
料金としては、ネットワークの帯域等も、通常のEC2のインスタンスとShareする
HPCタイプを使用するという選択肢もある
09:45–10:30 「パネルログ分析onAWS」 株式会社ブレインパッド サービスイノベーション室 小林 隆さん
博報堂からのプレスリリースが出ているデータマイニング、最適化、レコメンドエンジンをやっている会社
EMRの連載中 gihyo.jp
パネルログ
★Hadoop Conference 2011 fall とかぶる
- パネル＝人
- すべてのサイトでの人の行動をロギングできる
- 通常のログと違って行動を追うことができる
分析用APIを用意している
- 分析したいユーザーはAPIを叩くだけで良い
- Hadoopの知識は必要ない
一次加工
- データのノイズ除去
- ブラウズIDでまとめる
- Aさんのネット接続の目的が理解できる
処理の流れ
- Client、RESTのAPIでリクエスト
→キューサーバ
→管理サーバ
→EMRもしくはオンプレミスなHadoop
実際の処理
- Fair Schedulerに任せている
- EMRはJobをステップごとに処理
- キューの上限値を設け、キュー毎にEMR起動
- EC2はインスタンスの上限があるので、事前に解除の必要あり
- すべてのJobが終了し、キューがない場合にはEMRを落とす（コスト下げるために）
- 分析のMRは Java MRで。
- HiveやPigではできなかったから。
- 1段のMRの中でもパフォーマンスを考えて複数回処理している
例えば、こんなものがあります。
- サイトの時系列、リピート分析、サイト間分析、検索キーワード分析、流入流出分析、プロセス一覧取得API、…
- サービスの構成はSaaSとして提供している
- 現在、博報堂、自社分析等に使用している。
- 2011/10/28 10:08:16 はやめに終わった。
QA.
Q1,A1. SSLには対応している
Q2, オンプレミスと双方使う理由、ノウハウ
- オンプレミスは制限あり。待ち時間かかる。
- EMR、Adhocなクエリに強し
Q3, オンプレミスはなにか？
- CDH
- Apache Hadoop より patch あたる頻度高い
Q4, パネル分析について
- 全部PCの分析
- いろいろな収集方法（Cookie, gadget）があるので、どうつなげるのかが課題
10:20–11:00 「AmazonEMRの活用事例紹介」 株式会社野村総合研究所 サービスシステム事業二部 矢治 健吾さん/先端技術開発部 西村 高行さん
自己紹介
- @yajikenz
- NRI→金融 x 産業 x IT基盤 x コンサルティング
- インフラエンジニアからアプリエンジニアへ
- 箱の面倒をみてきた
- 大学でバナナの研究、SNS運用のアルバイト
EMRを使おうとしたきっかけ
- 2010、某ユーザー企業（住宅情報）
- うちのサイトにやってくるユーザーの行動分析や商品のレコメンドをすぐにやりたい
- 1000-1500 万レコード日
- 約20GB日、7.3TB/year
- オンプレミス側のRDBには直近1ヶ月分しか保存できない
- すぐやりたい、でもやめるかも
→まさにクラウド向きなのでは？
処理規模が大きい
→Hadoop
→0からの環境をつくるのはキツい - 早くやりたいので、工数をできるだけ減らさないといけない
- 購買フローの時間がかかりすぎる
- 費用だけでなくスピードの問題
- 運用の問題→Hadoopのスペシャリストを集めるのは当時困難
- AWSがサポートしてくれてしかも安い
- 最終的にEMRを選択
→★バッチ用途、コストメリット - もし、処理が失敗しても、やりなおせばいい。
事例紹介
1. 物件情報のレコメンド：協調フィルタリング
- 類似処理をRDBでつくったら1日たっても終わらなかった
- 相関物件導出
- オンプレミスとAmazonクラウド（東京リージョン）
- 1日たっても終わらなかった処理を30分で
- m2.4large x 5(master1, slave4)
- PerlでHadoop Streaming
- 運用、半年、EMR専用のエンジニアはいない
2. Webサイト上でのユーザー行動分析
- Adhoc
- コンバージョンに結びつく効果的な広告施策の発見分析
- SEO、Listing、CM…
- 統計学に詳しい分析者がより掘り下げたユーザー行動分析を実施
- 非定型、アドホック分析、使用頻度がよみにくい
- いちからシステムをつくっている時間はない
- ログはS3上にはたまっていた
- SQLやPerlくらいはかける人たちだった
- 準備で1ヶ月かかっていたが、話をきいて翌日開始
その他
- ターゲティングメルマガ
- S3の行動ログ、メルマガ登録、ユーザー属性
- 商品閲覧数、コンバージョン数集計
- 某会員制SNSでおすすめメンバーの推奨ロジック
EMR環境構築時のポイント
1. EMRを呼び出す共通処理の準備
- バッチ開発をチームで行う場合
- なぜ共通化すべき？
- EMR起動停止の仕組み化
- EMRは普通に使うと
- クラスター起動、ジョブ実行、クラスタ停止
→クラスター起動、たくさんジョブ実行、クラスター停止がお得
- 起動命令
- 状態ポーリング x n回
- 正常、異常判定して終了
- 注意事項：
- あまり頻繁にポーリングするとEMR側からエラーが返るので注意
- 10秒に一回
- まれに原因不明で起動命令すらエラーで帰ってくる rerun すると成功、数回 auto rerun するようにしている。
- あまり頻繁にポーリングするとEMR側からエラーが返るので注意
2 クラウド上へのデータ配置時の注意
- 性能観点
- Hadoopはファイルサイズが小さいと性能がでない64MBを推奨
- S3の場合、S3におくファイル単位でMap
3 EMRのIN、OUTデータのチェック
- なぜ？
- 後続処理に影響
- EMRの処理中でエラーがあっても、EMRはそうそうエラーにならない
- データのエラーは無視して正常終了でつきぬける
- 処理前後でチェック処理をしたほうがよい
4. オンプレミス＿クラウド間のジョブ制御
- オンプレミス側に何らかのジョブ管理ソフトが入っていることが多い
→クラウド下も同じ管理下におきたい - たとえば
- VPC経由でそのエージェント、クラウドをコントロール
- 環境またぎでSSHが許可されるならばSSH経由でジョブキック
- HTTP経由でジョブ連携する独自機能をクラウド側につくって使いまわしている（やり過ぎ感はあると）
★ジョブは並列ではなく、直列に組んだほうが安いことがある
5. その他 Tips
5-1 MRを使いこなせる人はすくない。
- 頑張って完成しても保守はなれる
- 設計はシンプルに極限の性能はめざさない
5-2 導入障壁の崩し方
- SQLならかけるぞという人は多いので、HiveQLをつかってもらい、効果を実感してもらう
5-3 海外エンジニアでも慣れて使いこなせるようになる
- 中国はシンガポールリージョンのほうが近い。
5-4 EMRは最初20台いか、申請必要
5-1 SQLチューニングと同じだといい、HiveQLのチューニングを覚えてもらう
- ただし多段ジョブになるという怖さは啓蒙する
- RDBのネステッドループジョイン
今後の展望
- BI用途だけでなく、業務バッチの高速化に取り組みたい
課題
- エラーデータがあってもつきぬける
- 開発者の保護
AWSその他の mashup してリアルタイムのストリーミングの世界を描いてみたい。
- 2011/10/28 11:00:39 終了
感想
- EMR そのものについては既知だったので、新しい発見はあまりありませんでした。より最新の Hadoop を採用するという点は期待したいと思います。
- 追記：どうも EMR の話も Hadoop Conference 2011 Fall での内容とほとんど同じだったみたいです。
- パネル分析の話は、Hadoop Conference 2011 Fall と同じだったので、申し訳ないですが、がっかりしました。
- 最後の野村総研さんの話が一番有用だったという印象を受けました。コストをいかにして下げているかという知見がかなり参考になりました。
