今更のアップですが、Hadoop Conference Japan 2011 に行ってきました。
概要は以下。
http://hadoop-conference-japan-2011.eventbrite.com/
いつまでアクセスできるかわかりませんが。
最近、技術系のイベントにいくと、Mac 率高いなぁ。しかも Air 。
今回もメモ帳片手に話を聞いていました。
電子化するにあたり、再度見直すことで復習するからいいじゃん、ということにしておこう(負け惜しみ)。
以下、メモからおこしてます。
それぞれのサービスとかを Google さんに問い合わせれば詳細を得られると思います。
あと、敬称略にさせていただきます。
- 『Hadoop on クラウド / Amazon Elastic MapReduceの真価』（Amazon Web Services, Jeff Barr）
Amazon EC2 / S3 上で Hadoop を動かそう！（以下、EMR: Elasic MapReduce です）
1) データをアップロードして
2) Job flow を作って動かし
3) 結果を得る
EMR の利用例
広告、ログ解析、データウェアハウス、遺伝子解析、財務分析、画像処理、サーチエンジンの Indexing、BI、データマイニング・・・
EMR は MUCK な状況にならないようにします。
MUCK な状況にならない、というのはイメージ的に言うと、泥臭いことをしなくても済む、という感じ。
EC2(?) のインスタンスタイプは２タイプある。
data incentive と computer or I/O incentive（メモでは intensive とか書いているんだけど・・・）
データ量に合わせてスケールアウトするか、計算量によってスケールアウトするか、という感じでしょうか。
前者はデータウェアハウスやデータマイニングに向き、後者はレーティングなどに向くとか。
採用例として、Best Buy におけるターゲット広告が紹介されていました。
データ量：3.5 billion record
Cookie：71 million cookies
advertise：1.7 million ads.
EMS に乗り換えることで、計算に２日以上かかっていたのが 8時間に短縮されたとのことです。
アカデミックな話かも、という前置きがあり。
まずは機械学習。
いろいろな問題が機械学習で計算されるようになっているが、これは各々の問題を解析して抽象化すると、同じ土俵で計算できるようになるため、とても有用である。つまり、（大量の）データがあるところ、どこでも使えるわけである。
機械学習と並列処理、という話では、機械学習のアルゴリズムの向上速度よりも、解析対象となるデータ量の増加量のほうが大きいため、分散化が必須となり、分散化っていうことは Hadoop とお友達になれるんじゃない？っていうか、かなり相性抜群？というわけです。
ここで紹介されていたのがApache Mahoutというプロダクト。
Hadoop 上で動作する機械学習ライブラリだそうです。
・スケーラブルを最優先
・いろんな手法をサポート（ベイズとか、ニューラルネットワークとかとかとかとか）
・３ヶ月くらいごとに新しい機能が追加されるとか→ってことは、不安定？なところもある。
数台から数百台で問題なく動いたそうです。
ただ、ドキュメント不足で、場合によってはソースを読まないとわからない部分もあるそうです。
あと、パラメータの変更とか。
２つ目の話題。大規模分散＆機械学習の話。
大規模分散＆機械学習といえば、Google / MS / Yahoo! が有名ですね。
これらで実現されていることで、Mahout には実装されていないものはけっこうあるそうです。
グラフィカルモデルの話。
メモから戻せません・・・
数値最適化の話。
多くの機械学習は数値最適化問題に帰着する→MapReduceと相性が良い。
４つの方法。Iterative Parameter Mixure が一番良かった。これは Parameter Mixture を少し改良したもの。
３つ目の話題。Dremel
対話的大規模データ解析基盤、とのこと。
・1兆データのアドホッククエリが数秒で返る
・クエリ言語はSQL
・2006年から
列指向のデータ格納
圧縮レコードの復元
クエリ処理アーキテクチャ→Tree構造。クエリは根から葉へ。
「途中で計算を打ち切ってやめる（結果をまとめる）こともできる」
Dremel と MapReduce との違いは？との問いへの回答。MapReduce はデータ全体を扱う場合は速いが、一部だけ、という用途に弱い。
Dremel に食わせるデータは MapReduce でつくる？→そうですね。
今後、大規模なデータを扱うということになると、教師なしというのが主流になっていくのでしょうか？→そうなるかと思います。教師ありという点では、クリック行動や Google の Priority Inbox でしょうか。
お昼休みをまたいでモバゲーの話。
記録される行動情報は１日で20億を超えるとか。
DeNA は、サービス規模は Facebook や Zynga の 10 から 15 分の 1 だそうですが、売り上げ的には同じくらいとのことです。
DeNA では、データマイニングのためのインフラがあり、それについて説明されていました。
Hadoop DFS の上に、いろいろなモノが乗っかって、Data Mining インフラを構成していて、その Data Mining インフラで(機械)学習された内容がゲームに生かされたりしているそうです。
20億(一日あたり)もあると、データ量としての統計的意義があり、しかも多くの人(2300万人)に還元できる。
感情がわかる詳細行動情報は楽しさのデータマイニングとなり、ユーザ体験に還元される。
発表されている方は、とても楽しそうに説明されていました。
楽しさの行動パターン：
・夢中になるきっかけ
・楽しんで続けている人の行動パターン
から得られることは、楽しんでいるパターンを、サービスの初期で、また高頻度に体験できれば続けてもらえる可能性が高くなる、ということであり、
やめてしまうパターン：
・飽きはじめる、不快な状況
ということであり、これがわかれば飽きはじめたユーザのピックアップすることができるのではないか、とのこと。
たしかに。
モバゲー？は、
・(良いゲーム、ユーザとの)出会いのあるプラットフォーム
・(不正や年齢詐称のない)健全なプラットフォーム
・ユーザの声によってサービスが洗練されるプラットフォーム
を目指しているようです（メモが中途半端で、ここで何をおっしゃられていたか失念してしまいました。すみません。ただ、上記の条件を満たすプラットフォームが良いプラットフォームであり、モバゲーはそこを目指している、という話だったかと思います）。
大規模サービスでよく生じる課題：
・サービスごとにログの形式がバラバラ
・ログの場所がバラバラ
→集めるのに時間がかかる、解析・データマイニングにたどり着くまえに疲れてしまう
これらの課題は、統一行動記述で解決！
具体的には、
・統一スキーマ → サービスをまたいで解析することができます
・Hadoop にすべて保存してます → 集める手間はかかりません
という感じで終わりました。
時間をオーバーしてしまったため、質疑なし・・・でしたっけ？
つい先日、プレスリリースのあった Asakusa の話。
ちょっと興味あり。
35分くらいでは時間がぜんぜん足りない、という内容をかなり駆け足で紹介されていました。
私は基幹バッチを実際に書いたことはありませんが、基幹バッチの特徴は
1) データの種類が多い
2) 処理は簡単
3) データフローが複雑（コントロールブレイクが何とか、と説明していました）
4) 割と設計が重要 → いかに実装につなげる？という話
(基幹バッチを動かすうえで) Hadoop に足りないものは
・MapReduce に不足はない
・そもそも大規模開発の手法がない → デバック・運用は考えられていない。
何も考えずに Hadoop で基幹バッチを実装しようとしたら確実に死ねるとのことです・・・
ここから内部的な話になっていくのですが。単にメモをおこしても意味がなさそうなので、要点と思うところだけ。
Asakusa は、Hadoop 本体には手を入れていないそうです。
トランザクション管理は、Hadoop の外側で行っているそうです。
あと、HDFS は壊れる前提でいる、とのことです。
実装するためには、
1) Batch DSL
2) Flow DSL
3) Operator DSL
という３レベルのプログラムを作成する必要があるそうです。
1) と 2) は別に MapReduce の知識はいらないそうです。3) については MapReduce を知っている人が書いた方が良いとのことでした。あとで話がでてきましたが、プロジェクト的には 3人くらい MapReduce を知っている人がいれば、これまでと同じ感じで見積もって大丈夫でしょう、とのことです。
それぞれの DSL は、ashigel コンパイラ(作者からとっているそうです)を使って、MapReduce のコードにコンパイルされるそうです。コンパイラについてはコンパイラ屋さんが作るとこうなるんだ、というコードだそうで、作者の方曰く、わりといろいろ黒魔術を使っているとのことだそうです。
Asakusa にはモデルジェネレータがあり、TABLE から自動生成してくれるそうです。
また、テストも充実していて、どういうテストをしたいかを書いて（具体的にどのように書くかは不明）、JUnitを通せば鉄とケースが作成されるそうです。テストシートも。
外部連携については、Sqoop にする予定では考えているが、実際にはもうちょと高機能なもの(OSSではない)を使っているそうです。
運用については、MonkeyMagic 用のスクリプトが生成されるそうです(デフォルト)。
OSS としての公開は３月目標とのことです。現時点でβはだせるよ、ということもおっしゃっていました。
最後のほうは駆け足になったのでこんなところ。
- 『Hiveを用いたAmebaサービスのログ解析共通基盤』（株式会社サイバーエージェント, 福田 一郎）
最初に Ameba サービスを使っている方どれくらいいますか？というところで、ほとんど手があがらなかったのがちょっと意外。メインの利用者は女性のようです（想像通りではありますが）
メモをとる、というところではだいぶ疲れてきたところ。
Hive を用いた Ameba ログ解析システムの紹介。
Ameba は利用者 1300万人、ページビューは月に 200億とのことです。
今回紹介されていたシステムは Patriot という名前だそうです。
構成要素的には、HDFS / MapReduce / Hive / Patriot / HUE というところ。
メタストアには MySQL を使用しているそうです（デフォルトは Derby）
データストア内でのファイルの分け方は、年月日ディレクトリがあって、その下にPC/モバイルのフォルダがあり、その下にそれぞれのログがあるそうです。PCのゲーム？については、ゲームごとにディレクトリがあるというお話だったような気がします。
サーバ構成については、発表スライドがどこかにころがっているか、誰かがきっと描いてくれるだろうということで、割愛。
あっ、もともとの目的について描いていませんでした。
システム部分からはちょっと遠いところにいる企画系やその他の人から、アクセス数などについて出してほしいという要望がシステム部にあがってくるが、人によってほしい情報が微妙に違うので、依頼されたデータを集めてつくるのにもちょっと時間がかかるわけです。なので、システムからちょっと遠い人でも、自分の知りたい形のデータを集めることができるようなシステムを作りたい、ということで着手したそうです。
- LT 集。
(1) 分散ファイルシステムGfarm上でのHadoop MapReduce (Shunsuke Mikami)
Gfarm ：汎用分散FSで、better NFS という感じ。
利用実績：けっこう使われているよ、筑波大とか、KDDIとか。
サポートはベストシステムズ社がされているとのこと。
HDFSと比較した欠点：
・単一ファイルのアクセスはスケールしない
・コピーがないタイミングが存在する。
GlusterFS：マスターなし、FUSEベース、複製ありなしなど設定できる。
Gluster FS と HDFS の比較。
・DFSのほうが速い(ローカルじゃない、FUSE とか、というメモがあるけど・・・)
・利点としては、インストールが楽。
(2) 「Sneak Preview of "Hapyrus" ~ Hadoopアプリ開発＆共有サービス on the CLOUD」(Fujikawa Koichi)
Hadoop 実行環境付きのマーケットプレイスという感じ。
３月に公開予定とのこと。
Hadoop の欠点は、最初の敷居が高すぎる！というわけで、作ってみました、とのことです。
(3) 「MySQLにMapReduceジョブトラッカを実装する」(Sadayuki Furuhashi)
プロトタイプです。
サンドボックスは未実装。
実装は Worker のみ。
タスクが重要。
タスクは開始時間、終了時間、last_heart_beat_time(最後に生きていた時間)を保持。
タスクが死んでしまった場合、last_heart_beat_time が更新されないので、わかる、という仕組み。
Hadoopと本システムにおける JobTracker の違い。
Hadoop は push 型、本システムは pull 型。
デモされてました。
(4) 「Hadoop and HBase for ranking processing at Rakuten」(Yifeng Jiang)
楽天のランキング処理エンジン。
カテゴリは000以上。
データは多量です。
Pig 使ってます（使っていた？）
データを知ろう！→偏ると遅いよ
バランスが重要→H/W, OS, Hadoop config, アプリデザイン
(5) 「Bonding とネットワークスループット」(Takahiro Kaneko)
Bonding の設定を変えて、スループットを測定してみた。
参考：
NIC 1枚：110MB/sec
３位： balance-rr / src_mac → 120MB/sec
２位：802.3ad / src_mac → 150MB/sec
１位：802.3ad / src_dst_ip → 200MB/sec
(6) 「Hadoop + MongoDB の美しい関係」(Yuuna Kurita)
健保レセプトのデータ解析。280万件/年
Ruby - mongo JSON - mongoDB に保存（このへんのメモはちと怪しい）
元ファイルも GridFS に保存
解析 mongoDB → R
トップレベルの個人データなので、Public クラウドは使えない。
統計屋さんの書いた R を Streaming するのは難しい。
patraqushie
以上、LT終わり。
Hadoop よくあるトラブル
(1) MasterNode のメモリ枯渇
空ファイルや小さなファイルを置かない。
見積もりは大切。
モニタリングする仕組みは大切(Ganglia)
(2) ライブラリ起因による処理の不整合
出力ファイルの一部消失→Hadoop の投機的実行により、同じ処理の多重実行が原因
アプリと基盤の両方を考えよう！
Hadoop をマルチユーザで使う
構成を意識せず
データ、アクセス制限
トラブルいろいろ→解決策
Hadoop のコマンドを直接実行させない
Hadoop クライアントを介さないとアクセスさせない
クラスタへのアクセスは限られた人にだけ許す
モニタする
Hadoop の Web I/F にアクセスさせない（最低限は公開）
HDFS
パーミッションを考えよう
Quota もね（ファイル数、ディレクトリ数。ディレクトリ単位で設定）
レプリケーション数とか
ブロックサイズとか
内部通信のポリシー（アクセス可能ユーザ）とか
認証とか
MapReduce
スケジューラ。デフォルトのスケジューラは使いにくいわけですが。
キャパシティ：ユーザとキューを固定で割当
フェア：プールを占有させない
用途ごとに検討する必要がある。
ただし、これらのスケジューラはパフォーマンス悪いかも。
内部通信のポリシーを設定しよう！→ hadoop-policy.xml
MapReduce に関する ACL で設定するとか
もっと上手に使うために
1. child プロセスの JVM オプション制御
2. スケジューラ改良
3. 占有資源と共有資源の制御
4. 物理ディスク対策
5. ユーザとグループ
複数のユーザで使用する場合、使う側のルールを定めるのも大事です。
Hive 使ってます。
HBase 準備中です。
解析屋さんがロジックを考え、システム屋さんが実装する。
システム屋さんが実装し、動作した結果（ログとか）を解析屋さんに返す。
解析屋さんが解析するにあたり、うまくいかない部分（ITでサポートできる）があればシステム屋さんがフォローする
KNIMEはドイツ発。日本ではインフォコムさんが代理店してます。
データの処理ロジックをビジュアル的に組み立てられます。
処理ロジックはいろいろあるよ。
アニメーションで動きもわかります。
Hadoop + KNIME
Hive を使って JDBC 接続
マスタは一部手元でいじりたい。
以上、間違ってたらごめんなさい。
