hadoop conference 2011

勉強 技術

本日はhadoop conference 2011に参加。
http://www.eventbrite.com/event/1278974447/efblike
定員約350人が約4時間で埋まったとのこと。
始まるまで少し時間があったので、参加している人を見渡しながら、ここにいる人が平均１０台のクラスタを利用していると仮定すると、計3500台で、ラック型で１台１ｍの奥行きとすると、3.5km！！とどうでもいいことを考えていました。

ということで、各セッションのメモ

Amazon Elastic MapReduceの紹介 AWS Jef Barrさん

Amazon Elastic MapReduceの紹介(英語)

    • What is big data?
      • まだ新しい言葉。ただ単にでかい容量というだけではない。
      • 課題として、strucuture, demandの発掘もある。
      • また、それらを迅速に解析できる必要がある。
      • これらの手伝いをするのがbig data tool

    • Elastic map reduce overflow
      • EC2, S3をベースに動く
      • 簡単、スケーラブル、安全、コストパフォーマンス良し。
      • 数百TBの実績もあり。
      • 簡単にデプロイ、監視ができる。
      • AWS management consoleというweb UIに加えて、コマンドラインでの操作も可
    • Elastic map reduce 実行まで
      • データをs3にアップロード
      • ジョブフローの作成、実行
      • 処理が完了したら、S3から結果をとりだす。
    • elastic map reduce removes MUCK from Big Data
      • MUCK -> 雨が降った時とかにできる、"ぬかるみ"のこと
      • Big Dataの扱いでのMUCKとは？
      • これらのMUCKを取り除いたのがEMS
    • Use cases
      • 広告配信、ログ解析、遺伝子計算、financial simulation,検索エンジンの生成、データマイニング
      • Data ヘビーか、CPUヘビーかで、ジョブフローの使い分けができる。
      • 前者はデータマイニング、後者は各種分析やシュミレーションなど。
      • Best buy とRazorfish(広告会社)
        • 35億件 per dayのデータ
        • 7100万UU
        • 170万件のターゲット広告配信
      • 100ノードのクラスタを構築し、２日かかっていた処理を8時間に短縮。
      • 解析が行えるようになったことで、広告効果が500%になった。
      • クリック分析の解析を行う会社では、みんな似たような構成を使っている。
      • 広告宣伝や大量データ解析の需要が増えているように思う。

    • Map reduce概要
      • データをインプット
      • データを切り分け
      • ノードに分配
      • 並列で処理を行う
      • 結果を取り出す。

    • EMSの画像デモ
      • ログファイルをバケット(S3のデータの管理単位)に転送。
      • ジョブフローの生成
        • 名前をつける。サンプルプログラムを使うか、自分で開発したプログラムを使うかを選択。
        • ログ分析用のサンプルアプリケーションもあり。
        • Pig を使って処理を行う。
      • インプット、アウトプット先の指定
      • ノード数 EC2の指定
      • デバッグモードの指定
      • Bootstrap を使うことで、起動スクリプトを自作できる。
      • 処理の実行。(数千のインスタンスで使っているお客さんもいる。)
    • その他の特徴
      • コンソールで進捗状況を確認できる。
      • 自分でmap reduce処理を書くことも可。
      • 自由にスケール。処理中に動的に追加できる。
      • R言語のサポートもしている。RHIPEという環境。

    • Q&A
      • スライドにHBaseでシステム構成をしている図(11枚目)があったが？　-> ユーザのほうで構築した環境になる。現在、AWSとしてHBaseをサポートはしていないが、将来的にはサポート予定。
      • 処理時間が短くても時間単位で課金されてしまうのが悲しい。 -> 時間単位での課金に適した処理を組むべし。

後のセッションで、複数ユーザが居る時の云々でリソースやスケジューラの管理の話があったけれど、EMSをベースに開発していれば、そういったことは気にしなくてよくなるし、大規模クラスタになるほど、サーバリソースを使い切るのは難しいように思うので、PaaSとの相性はさらにいいのかな〜と思った。
ログを転送するという点でセキュリティ的な話や、後はやはり料金的な点が気になるところ。調べてみるか。

Hadoopを使った機械学習 PFI 岡野原さん

MapReduceによる大規模データを利用した機械学習

    • 機械学習
      • データから有用な規則、ルール等を抽出すること。
      • 様々な分野の問題に利用可能。
      • タスクと手法の分離が普及の要因。
      • 手法が抽象化されているので、定義された形でデータを準備できれば、誰でも行うことができる。
    • hadoopと機械学習
      • データは増え続けているので、機械学習の分散並列化は必須。
      • Map reduceをベースにした実装が普及してきている。
      • 元は関係ない２つだが、並列処理部分をhadoopに任せて、そこに適した解析ロジックを考えるほうが効率的に開発できるという発想。

    • Apache mahoutの登場。
      • Hadoop baseなのでスケーラブル。活発なコミュニティ。
      • 裏を返せば、まだ枯れた技術ではないので、業務導入にあたっては要検討。
      • クラスタリング、パターンマイニング、分類、行列演算などが行える。
      • EC2上に構築した環境え、100台強で動かしたことがあるが、リニアにスケールした。
      • ドキュメントの不備、ちょっとしたチューニングがしづらいといったあたりが問題。
    • グラフィカルモデル
      • 確率変数を頂点、変数間の依存関係を枝としたグラフ構造。
      • 言語処理、情報抽出、音声認識、画像解析、遺伝子解析 etc...
      • 計算が非常に困難なのに、データが巨大になっている。

    • 共参照解析。
      • 二つの言及が同じ単語を指しているかを解析していく。
      • 僕、君 とか。

    • 数値最適化の並列分散化。
      • Parameter Mixuture -> ダメだった
      • Distributed Grdien -> ノード間のやり取りが多く通信が混雑、収束が遅い
      • Asynchronous Update -> すごい遅い
      • Iterative Parameter Mixture -> これがいい！収束証明ができ、しかもスケーラブルであることが分かった。

    • Dremel
      • 要チェックな新技術
      • 対話的な大規模データ解析基盤
      • 1兆のデータに対するアドホッククエリの結果が数秒で取れる。
      • クエリ言語はSQL
      • データは繰り返しありの木構造。
      • 列指向のデータ格納
      • クエリに必要なオートマトンの生成
      • クエリ処理アーキテクチャは木構造。根から葉に向かって広がり、葉から根に集約されながら帰ってくる。
      • 850億レコード, 87TBのワードカウント,3000ノード を使っての処理 -> Hadoopでは1000秒、Dremelでは10秒程度。
      • 将来的に高速な推論、分類に利用可能では？
    • Q&A
      • Dremelの使用データの生成ではmap reduceを使うのか？ -> 使う。
      • 教師なしの話が多かったように思うが、データが大規模になるにつれ、そのような傾向があるのか？ -> gmailのスパムメールや優先メールの判定のような教師ありの例もあるが、データが大規模になるにつれ、教師なし + ちょっとしたルールによる解析のほうが面白いのではないかと思っている。


機械学習系の話は、知識不足であまりついていけず。。しばらくは定義された通りにデータを準備してみるほうの立場で、これいいよと聞いたのを動かしてみて、知識を深めていくというフローになるかな。。
Dremelの所で出てきた列志向データベースという単語は昔、情報処理系のDB系のやつの勉強をしている時に聞いて、何のためにあるんだ？と思った覚えがあるけど、こんな所ででてきてビックリした。ていうか当時は勉強しながら、使われていないモデルなんか出さずに、データベース = RDBMSでいいじゃねえかと思っていた気がする。。

モバゲーの大規模データマイニング DeNA 濱田さん

『モバゲーの大規模データマイニング基盤におけるHadoop活用』−Hadoop Conference Japan 2011− #hcj2011

    • ソーシャルプラットフォームとしてのモバゲー
      • ゲーム、SNS, 情報発信、作品投稿
      • 有効会員2300万人。20億PV / day
      • Facebook, Zyngaと同レベルの売り上げ、しかしARPUで見れば約30倍！
      • Facebookはリアルな人間関係が軸になる。DeNAには興味軸のソーシャルグラフも存在する。

    • Hadoop DFSに全行動ログが格納されている。
      • Hadoop系列のプロダクト内で処理を完結できる。
      • Pigの利用。javaでのベタ書きもやってる。
      • Zybraによるスキーマ管理。
      • Perlで書かれたゲームをベースに、perlのMRストリームでシュミレーション。
      • R言語、Mahoutも活用。
      • これらの基盤の上に、DeNA独自のData Mining Libraryがのっかる。

    • Hadoopチューニング
      • パラメーターチューニング
      • 中間ファイルをlzo圧縮
      • 出力データサイズの最適化

    • Pigのチューニング
      • Partitioner の実装の最適化
      • 多段map reduceでの中間ファイルの圧縮
      • 独自UDF
      • 共通のログ loader
    • Mahout
      • 用途に応じたデータ変換
      • 一連の処理の実行を定型化
    • 楽しさのマイニング
      • 一日20億以上の行動情報
      • 統計的に優位に立てる
      • 多くの人へ還元することができる

    • 感情がわかる詳細行動情報
      • Webの広告では行動に対する広告に最適化が行われた。
      • ソーシャルゲームでは感情に紐づいたような詳細な行動情報が取得できるようになった。
      • どういった行動パターンがある時に継続の傾向が見られるのか、利用をやめている人との行動パターンとはどこが違うのか。
      • ゲームレコメンデーション
      • コミュミケーション系サービスの解析では自然言語処理も利用
    • 楽しさの行動パターン
      • きっかけを見つける。
      • サービス継続している人の行動特徴
      • どのサービスがユーザに訴求しているかを解明する。
      • そのサービスを新ユーザに早めに提供することで、継続率を増やせる。

    • やめてしまう行動パターン
      • きっかけを見つける。
      • 飽き始めたユーザの予測、判別。
      • 新しい体験、他の楽しみ方の提供。

    • 健全なプラットフォームへ
      • 不正な書き込み判別
      • 年齢詐称の判別
    • 迅速なサービス洗練
      • 数時間から数日スパンで迅速なサービス洗練。
      • サービスを動的に変化できるソーシャルゲームならでは。
    • 統一行動記述
      • Hadoopに解析しやすい形で、全行動ログを格納している。
      • これは物凄く重要！！！
      • サービス毎にログの形式は異なる。
      • そのままいれてしまうと、何を解析すればいい？、値の意味がわからない、類似の解析を個々に実装する必要がある。
      • バラバラに置いていると、ログの運用だけで大変。
      • そうなるとデータマイニングまで手が回らず、定量解析だけで手一杯になってしなう。
      • 統一スキーマにするといいことだらけ！
        • 各種アルゴリズムの再利用
        • 学習コスト (ログの意味とか)の軽減
        • データ探索、収集時間がゼロ。
        • データマイニング、機械学習などのエキスパートがそれぞれの分野の知識をフルに活かした開発が行える。
    • ソーシャルプラットフォームの世界展開
      • NgCore SDKによるクロスプロットフォーム対応
      • サムスンの端末にプレインされることが決まっている


機械学習とか統計とかR言語の所は知識がまだ無いのであれだけど、hadoopのチューニングの所は本に書いてある通りだったり、データの持ち方の所に関しては、自分でもそういうデータの持ち方をできればいいな〜と空想したことはあるし、多くの人がそうなってれば楽だろうなと考えたことはあるんじゃないかと思う。
知識面だけでなく、考えられる全てのことをしっかりと行動に移している（できない理由を考えるのではなく）という点も、エンジニアのあり方として多いに見習うべきと思った。そういう点を全てクリアして初めて次のステップに進めるんだろうな。
デブサミの時の奥一穂さんといい、DeNAは凄い人が集まっているな〜。そういえば、webマイニング勉強会の資料は何度も見たので、知っていたはずなのに、自己紹介の文部大臣の下りで「おおー。」と言ってしまったwww。


Asakusa エンタープライズ ウルシステムズの神林さん

Asakusa Enterprise Batch Processing Framework for Hadoop
View more presentations from okachimachi.

    • Asakusaの目的
      • Hadoopで基幹バッチをやるためのフレームワーク
      • バッチ実行時間の短縮
        • 今まで時間的な制約でできなかった処理を何度も行うことができる。
        • サービスのレベルを上げることができる
        • 夜間バッチもなくしたい。エンジニアの負荷的(夜間対応やだ！)にも、お客さんの要望的にも。

    • 基幹バッチはややこしい！
      • これをBIツールである、hadoopでやるのはハードルが高い。
      • データ量がめちゃめちゃ多い。桁が違う。
      • 処理自体は単純だが、データフローが複雑で種類も多い。
      • 設計が超重要！！

    • Hadoopに何が足りないか？
      • 開発ツールがない。
      • テストフレームワークも貧弱。
      • 運用は考えられていない。

## 基幹で必要なレベルで考えた場合

    • Asakusaの概要
      • Pig, Hiveと同列の位置。hadoopの上位に位置する。
      • DSL, 外部でのトランザクション管理
      • 開発方法論まで検討
      • コンパイラの提供。 AShigeruコンパイラ
      • Model Generator
      • テストのインテグレーション. ## 超重要。基幹系ではテストが工数の八割!?

    • ビルディングブロックの構成による処理フローの構成
      • Pluggableに色んな処理を組み合わせるイメージ

    • 開発方法論
      • DAGベースで詳細ブレークダウン
      • 構造化手法の提供
      • ビジネスロジック部分はMap reduceを知らないCOBOL開発者でも書ける。
      • オペレーター部分は少し難しいので、知ってる人がやろう。
    • その他機能
      • Pig, hiveにはない基幹向けの演算子や機能をデフォルトで提供。
      • チェックポイントもあり。

    • MRコンパイラ
      • 多層DSLを最適なMap Reduceに修練していく。
      • 素人が見ても撃沈する黒魔術が多用されている。

    • Model Generator
      • TableやviewをSQLで作ると、自動でクラスを生成してくれる。
    • テストツール
      • junitで叩けるツールも提供
      • Model generatorからテストシートが自動生成される。
    • 外部連携
      • デフォルトはsqoopになる予定
      • 現在のprjではもっといいやつ使ってるけど、公開するかは未定
      • 運用のためのスクリプトも自動生成。
      • Monkey Magicの使用を前提。(hadoopクラスタ用のツールとしての実績、クラウド用のライセンス提供。)

## 保守系のツールのライセンス問題は、クラウド化を考えた時にけっこうな問題になるよ

    • OSS化
      • 三月目標。
      • β版欲しい人は連絡ください。
    • まとめ
      • Asakusaを使うと基幹バッチがホイホイ書ける
      • マーケットは確実にBIよりも大きい。億単位のビジネス。
      • 普通の業務系、BIでも使えるよ


基幹業務のことは知らないし、DSLやDAGの知識もないので、ついていけない部分もあったけど、目指している所は感じ取ることができた。
テストに関しては皆どこまで検証してんだろうな〜というのは日々疑問に思っていたし、運用に関しても、自分の中で問題発生後の対応でいいべみたいな気持ちがなくはないので、、こういうかっちりした部門のノウハウから吸収できるところは吸収していくべきと思う。


Hiveを用いたAmeba サービスのログ解析 Cyber Agent 福田さん

Hadoop conferencejapan2011
View more presentations from Ichiro Fukuda

    • サービス概要
      • ユーザの女性が六割から七割
      • アメーバ会員数 1300万人 (スマートフォン 367万 UU)
      • アメーバピグは会員数 600万人、有効ユーザでのARPUは\2000 per 月を超えている
      • 「アクセス解析」というサービスがあって、hadoopの0.13が使われている。現役で動いている。
      • picoではEMRを使っている。

    • Patriot開発までの経緯
      • 2009年に hadoop conference Japanに参加し、CDH, Hiveを知る。
      • その２週間後の伊豆合宿での開発合宿で開発もせずに、サービス解析の重要性を語り合う。
      • 上長に相談し、GOサインをもらい開発を開始。

    • 従来の問題点
      • 各サービス毎に独自解析
      • 容量の肥大化
      • 開発担当者では解析部分に手が回らない

    • Patriotの目的
      • 統合的なログの解析基盤
      • HDFS, Map reduce, Hive, webでの集計結果表示, アドホックなクエリ
    • hive概要
      • (略)

    • 開発体制
      • アプリ側三人、プロデューサー、インフラの人が随時
    • クラスタ環境
      • メモリ16GB, HDD1TB で18台構成
      • NamenodeはNFSでバックアップ
      • puppet, nagios, ganglia
      • HUE
      • ファイルフォーマットはSequence file + gzipの組み合わせ
    • 解析概要
      • ログはHDFS上に、サマリーデータはmysqlに入れている。
      • アクティブ率の一覧
      • ブログ毎での訪問者のユーザの属性
      • Beeswax -> Hive QLをweb UIから直接叩ける
      • アドホックな集計
      • ヒープサイズに注意。(実行計画が長期間保存されてしまうため、メモリが足りなくなるが、保存期間を変える方法が不明。)
      • プロデューサー用に読み込み権限のみのスレーブを準備
      • 実際にプロデューサーがたくさんのクエリを投げている！！
      • Join文を使って激重な処理を投げてしまうようなレベル。


今が新卒３年目と言っていたので、これを提案したり作ったりしたのは２年目の時ってことで、その年次でこれを作っちゃったことも凄いし、そういう発案が入社２年目の社員からなされる会社の風土も凄いし、それを認めて作らせちゃう上司も凄いし、その後プロデューサ系の人にHive QLを浸透させたということで、根気よく教えた側、それを拒否せずに学習した側(しかもシステムをハングさせるような複雑なクエリを生成できるレベル！)、みんな凄い。。
技術面もさることながら、そういった企業文化の面で、見習わなければな〜と思う所がたくさんありました。

マルチユーザでのhadoop環境のポイント. NTTデータ 山下さん

    • Hadoopのエピソード
      • その１ ヒープメモリの枯渇
        • 実際に動かして見るとおこることがある。特にマスターノード
        • 空ファイルや小さなファイルを置かない
        • データ量、ファイル数の見積もりは大切。
        • Gangliaによるモニタリング
      • その２ ライブラリ起因による処理の実行
        • 出力ファイルの一部が一部消失。
        • Hadoopの投機的実行、同じ処理の多重実行が原因。
        • Task-id でファイルの削除処理をしてた！！Task-attempt-id で処理しようね
      • その３ hadoopクラスタの利用拡大
        • マルチユーザで使うにあたっての注意点の話が出てくる

    • 概要
      • 利用者にクラスタ構成は意識させない設計
      • 適切なアクセス制限
      • お互いの利用状況を知らないという前提でものごとを考える
      • HDFSは誰かによって領域をおさえられたり、ファイルを削除されたりしまうようなことが起こりえる
      • MapReduceは好き勝手に実行されて、(優先度highばっかりとか)一向に処理が開始しないとか
      • Hadoopのコマンドを意識させない。 HUEの導入。
      • Hadoopのweb画面にはアクセスさせない
      • 特定のクライアントを通してのみのアクセス

    • HDFS
      • ユーザーグループ、パーミッションの設定
      • クオーターの設定、ブロック数の制限
      • HDFS間の通信
      • 認証、認可 Kerberos, 他のアプリケーションの組み合わせとか

    • Map reduce
      • スケジューラによるジョブ制御 。Fair scheduler, capacity task scheduler。それぞれに特徴がある。
      • 内部通信に関するポリシー
      • アクセスコントロールの設定. mapred.acis.enabled

    • もっと使いこなすには、、
      • ChildプロセスのJVMオプション制御
      • スケジューラ改良
      • 共有資源、占有資源の制御
      • 物理ディスク対策
      • ユーザーグループ
    • Q&A
      • hadoopであれこれするのは無理があり、入り口の認証(Gatekeeper?)でマルチユーザを実現するのが一般的だと思うが？？ -> hadoop内で制御できれば、クラスタを統一できコストが減らせるのではないかということでやっている。 (+hadoop内でどこまでできるのかという挑戦的な意味合いも強い。 濱野さんより）


これの直前にLTもあって、この辺から集中力が低下。。
あと、そもそも、複数ユーザの問題に行き当たるほど使い込めてもいないので、もっと利用シーンが広がってきた時に、ああ、これはこういうことを言っていたんだな〜と分かる日が来ると思う。

hadoopとKNIMEを用いた広告配信 リクルート 中野さん

    • 現状
      • 余剰の35台の研修環境、新規に23台のクラスタ環境
      • Hiveの利用開始、HBaseの検証中
      • メルマガ用のリコメンド、相場表のクロス分析などをやりたい
    • 開発に関して
      • 分析屋さんとシステム屋さんが密に連携して開発を行っている。
      • システム屋さん側の仕事としては、分析屋さんから出てきたロジックの移行や、分析屋さんへのデータ提供など。
      • ２者の間で、視点が微妙に異なる。　SQL的 ←→ R言語的
      • 道具を共通化すれば理解が深まるのではないか
      • ただし、ほんとの解析ツールはすげー高くて、全員にってのは、、→KNIMEを知る
    • KNIME
      • データの処理ロジックをビジュアルに組み立てることができる
      • ノード(細かな処理。joinとかソートとか)の組み合わせで実行状況を可視化。
      • ジョブの進み具合もリアルタイム見ることができる。
      • 各ノードをクリックすることで、その時点でのデータの状況を確認することができる。
      • ドイツのコンスタン大学で開発
      • 全世界で約6000人
      • 日本でのサポートもあり
    • やってみた
      • 既存の処理をコンバート
      • いいとこ
      • 悪いとこ
        • 英語。。
        • SQLで簡単にできることがすげー大変だったりする

    • Hadoop + KNIME
      • 前処理をhadoopでしておいて、KNIMEで取り出して解析みたいな。
      • Hive , KNIME間の各種ドライバを作成中。
      • 解析プラットフォームとしたいが、データ取得部分でSQL的な所は出てしまうので、そこは課題。共通で使えるなにかを用意したり？
    • Q&A
      • 可視化ツールときくと破綻しそうな印象があるが？？ ( +Asakusaでも導入しているが、リファクタリング、重複コードの除去はどうするの？？みたいな問題が起こっている。) -> 色々と制約を入れたりすることで防いでいきたいと思っている。


分析専門の人がいれば、簡単に機械学習とかできそうと勘違いしていたけど、そういう人と仕事をするにあたっては、また別の課題があるんだな〜。ただ、そういうことに気付けたり、色々と教授してもらえる人がいるというのは羨ましい。(そういう系列の人は、コミュニケーションが難しそうな印象もありつつ。)
自分の知識不足 + 集中力不足もあって、やろうとしていることの全体像が掴み切れなかったので、次は簡単なデモなど見れるといいなと思った。
あと、Rでも処理フローをビジュアル化して作れるものがあったような無かったような。。



文字書くのに疲れたのでTL部分はまた明日。。