Amazon Elastic MapReduceの勉強会『第1回EMR勉強会（Hadoop on AWS）』に参加しましたので、そのメモです。（Twitterのタグ→#emrstudy_jp、他の人のメモ→くろのさん）
（会場の最寄り駅はテレコムセンター駅。ゆりかもめは国際展示場正門以外で初めて降りたかもｗ）
最初はクリエーションライン株式会社の李さん。
まずAmazon Web Service（AWS）の簡単な紹介として、AWSはWeb系・業務系・Highパフォーマンス（並列）・BigData等、色々な分野で使われている。
EMRはクラウド型Hadoopサービス。
プログラムや入出力ファイル・ログはS3に格納する。（HiveのメタデータはRDSに置く）
プログラムはStreaming・Hive・Pig・Custom JAR（自作Map/Reduce）・Cascadingが使える。
◆●初めてEMRのコマンドを見たけど、自分のローカルPC上にEMRのコマンドをインストールしておくのかな？
「elastic-mapreduce --create ～」を実行するとHadoopクラスターが構成される。その引数に入出力ファイルのパスとかプログラムのファイル名を指定する。
実行するプログラムや入出力ファイル名をJSON形式のファイルに書いておき、それを指定することも出来る。
◆●ファイルは、「s3://～」で直接S3の場所が指定できるんだねぇ。
運用面は、ジョブ管理にAWSコンソール・Ruby CLI（コマンドライン）・APIが使える。
Gangliaで統計情報も見られる。
EC2インスタンスタイプによりインスタンス当たりのMapper数・Reducer数が決まっている。
BootStrapにより、Hadoopの個別の設定をすることも出来る（起動前に設定が読み込まれる）。
次に、Amazon Data Services Japanの大谷（shot6）さん。EMR利用事例。
- Foursquare（スマートフォン）
- 機械学習・データ分析・トレンド分析等に使用
- 平均40ノード（増減する）
- RubyでStreaming
- ログ収集はApache Flume、ログ保存はS3、ログ解析はEMR、結果を見るときはHive
- Razorfish（広告のSI）
- 1日35億レコード、170万広告
- 100ノード
- 処理時間：2日かかっていたのが8時間に
- HBaseを使ってるみたい
- Sonet
- 広告配信ログの分析
- 1日平均10GB、年3.65TB
- Etsy（巨大小売業）
- 434GB
- Ruby（Sinatra）
- Yelp（地理データ）
- 1日400GB
- 全部EMR。1週間毎にノード数を変更している
- 名前は明かせないけど、金融系
- 100％AWS
- 60年分のデータ（100万ロケーション）
- 1200～1800インスタンス
- Hatena
- Perl
Streaming・Hiveが多く使われていて、MapReduce直接は少ない。
Cascadingもけっこう使われている（日本では少ないが）。
Hadoopクラスターを起動したら、最初にS3からHDFSへデータをコピーする必要がある。
（EMRを起動しないと何も存在しない状態だから）
EMRを起動させっぱなしであれば、HDFS上にずっとデータを置いておくことも可。
次はクックパッドの佐々木（sasata299）さん。→資料（からあげ！ｗ）
“たべみる”で1年分の検索データを分析。
2009/09：MySQLのGROUP BYを使って処理しようとしたら、7000時間（約1年）かかるという見積もりｗ
2009/10：Hadoop（CDH1）のStreaming（Ruby）をEC2上で実行、30時間で出来た。
2010/07：CDH1のバグに遭遇（大きいデータを扱うとSocketTimeoutExceptionが頻発）。解決策はCDH2かEMRを使うこと。比較した結果、コストはEMRの方が少し高いが安定性やバージョンアップが自動で行われる点でEMRを選択。
「環境構築をしたいのではなく、データ分析をしたい」
2010/08：EMR使用
2010/4にブログで「EMRを使わない3つの理由」を書いたが、「使う理由」に訂正したいとのこと(笑)
MySQLで出来ることはMySQLでやり、出来ないことをEMRでやる。
クックパッドさんの中では、各エンジニア（全エンジニアは40人で、その中の10人くらい）がRubyでそれぞれEMRを使っている。（クックパッドのエンジニアは皆Rubyを使える。EMRの使い方ドキュメントは用意してある）
また、エンジニア以外でも使えるようにI/Fを用意している。
次はヴェルク株式会社の津久井（quarterkota）さん（インフラ設計）・石田（o918）さん（アプリ設計）。→資料
ログ解析で、アクセスログをS3に転送し、EMRで処理して集計結果をS3に格納する。
集計管理サーバー（ELB/EC2/EBS/RDS）でEMRを監視している。
利用時のみ起動しているので、運用コストが安い。1時間8.8円なので、8台2時間で140円程度。
アプリとしては、Hiveを使用。
EMRを常時起動させてはいないので、CREATE TABLE・INSERTでデータを保持しておく方法は使えない。
S3上にHiveが認識できる形でディレクトリーを作り、データを格納しておく。
- バケット/ACCESS_LOG ←テーブル用ディレクトリー
- ACCESS_YM=201111 ←パーティション用ディレクトリー
- ACCESS_YM=201112
- ログ1 ←パーティション項目は入っていない
- ログ2
パーティションは、「パーティション項目名=値」というディレクトリー名にする。
そして、elastic-mapreduceコマンドでHadoopクラスターを作成する。同時にHiveのスクリプトを指定して実行する。
まず「CREATE EXTERNAL TABLE ～ LOCATION 's3://～'」でS3上のディレクトリーを指定したテーブルを作成する。
ただしそれだけだとパーティションが認識されないので、「ALTER TABLE テーブル名 RECOVER PARTITION」でパーティションを認識させる。
そしてINSERT DIRECTORY ～ SELECTでHQLを実行する。
◆●Hiveのパーティションは使ったことが無かったけど、RECOVERなんて命令があるのか。
最後は株式会社gumiの本間（CkReal）さん。ソーシャルゲームのEMR活用事例。→資料
今までのgumiの課題として、
- ユーザーが（GREE経由で）カスタマーサポート（CS）に問い合わせをする。
- CSはエンジニアに調査を依頼する。
- エンジニアはNFSサーバーにあるログを調査する。
しかし、NFSサーバー上のログは毎日ギガバイト単位（最大18GB、圧縮して2.4GB）で発生するので、grepするのも大変。
そこで、MongoDBにJSON形式で格納することとし、EMRで変換している。
gumiは全てAWSを使っているので、EMRにするかEC2にするかという問題もあったが、EC2で構築するのは大変（あと、たまにEC2が再起動されたりする）なので、EMRに。
使用している言語はPython。（gumiのアプリは全てPythonで動いているし）
（Pigは習得コストがかかる。HiveはSELECTする為にある程度ログが整形されている必要があり、最終的にJSONに変換するという目的に合わない）
◆●Hiveを選択しなかった理由が「目的に合致しているかどうか」なのはいいね。
◆●Pigは自分も覚えるの面倒だと思ってたけど、やってみたらそんなに難しくは無かったけど…。
システム構成は、
- NFSサーバー（複数）からバッチサーバーへログを転送
- バッチサーバーでgzip圧縮し、S3に溜めておく（2千万件）
- EMRで処理（2時間くらい）し、S3に集計ログ（30万件）を保存
（EMR起動時にBootStrapでPython2.7をインストールしている） - バッチサーバーでS3からMongoDBへ格納
EMRの感想としては
- S3上のファイルをいつでも利用できる（EC2⇔S3は20MB/sで転送できる）
- Hadoopクラスターを管理する必要が無い
- 変化する要件に対応しやすい（データはS3上にあるので、そのまま使える）
- たまにジョブが失敗する（Reduceが終わらない？集計ログを回収しきれない？）
- CPU使用率：リニアにスケールさせるのは難しい
※チューニング方法模索中（Hadoopにあまり詳しくない）
◆●Reduceが終わらないというのは自分も経験したことあるけど、仮想環境の設定がおかしかった為だからなぁ。EMRがそのレベルで設定が足りないとは思えないけど。
BigDataの各自の定義
大谷さん：持っているのが苦しくなってきたらBigData
津久井さん：MySQLが動かなくなる数千万レコード（少ないならMySQLを使う方が楽）
EMRの説明だけでなく、具体的な（細かい）使い方を知ることが出来たので面白かった。
ただ、Hadoopはちょっとかじっているので少しは分かっているつもりだけど、AWS用語は不勉強で分からないものがあった(汗) EC2やS3は有名なので知っていたが、RDSって何だろう？けっこう頻繁に出てきてた感じがするが…。
「elastic-mapreduce」コマンドは初めて見たが、分かりやすかった(笑)（自分は実際に見てみないと理解できないんだな(苦笑)）
最後に、VELCの銘が入ったチロルチョコおいしかったです(笑)
ありがとうございました。
