Hadoop Conference Japan 2011 参加メモ

私の記事は個人的なメモで、間違った部分も多いため関連リンクを併読することをおすすめします。
特に今回は twitter と並行して読み書きしてたので、結構書き漏れてる箇所多いです。
網羅性とか正確性は期待しないように。

概要

イベント名 Hadoop Conference Japan 2011
URL http://hadoop-conference-japan-2011.eventbrite.com/
日時 2011/02/22 11:15 - 18:00
場所 NTTデータ本社ビル内 カンファレンスルーム

Hadoop on クラウド / Amazon Elastic MapReduceの真価』

Amazon Web Services, Jeff Barr)

  • web service evangelist
    • 著書"Host Your Web Site in the Cloud"
      • 先週翻訳された
Big Data
  • big data は大容量というだけではない
  • 重要な課題
    • ボリューム
    • データ構造
    • どういう需要があるか
    • 早く結果がほしい
Amazon Elastic MapReduce
  • EC2, S3 の上にある
  • 容易、安全、高い費用対効果で big data をさばける
  • 数百TB data をさばける
  • GUI, CUI, REST を備える
    • S3にデータをアップロード
    • EMR上でjob flow を作成
    • S3から結果を取得
  • EMR removes ”MUCK" from Big Data processing
    • 泥に脚をとられてぬかるんだ状態
    • IT の世界における MUCK とは下流の泥臭い処理
    • manage compute clusters
    • tune Hadoop
    • monitor running Job Flows
    • debug Hadoop jobs
    • Hadoop issues prevent smooth operation in the cloud. this is why we created EMR
Customers
  • Target ad/clickstream analysis
  • DWH
  • Bio-informatics
  • Financial Simulations (monte carlo)
  • File Processing
  • Web Indexing
  • Data mining and BI
HW Req for Use cases
  • Data or I/O intensive m1/m2 instances
    • DWH
    • DM
      • Click stream, logs, events, etc
  • Compute or I/O intensive c1, cc1/HPC instances
    • Credit Ratings
    • Fraud Models
    • Portfolio analysis
Razorfish and Best Buy
  • 3.5B record 71M uniq cookies 1.7M targeted ads request/day
  • 100 node clusters on demand
  • Processing time dropped 2+ days to 8 hours
  • increase ROAS Return on Advertising Spend by over 500%
    • ROAS:広告宣伝費
  • click stream アーキテクチャ 割と似てる
  • 日本の顧客も同じらしい
MapReduce
  • 業界の標準になってきている
  • 開発者は理解してて当たり前
  • take input data
  • break in to sub-problems
  • Distribute to worker nodes
  • Worker nodes process sub-problems in parallel
  • Take output of worker nodes and reduce to answer
EMR
  • mapper reducer can use JAR
  • Scale as large as needed
  • support RHIPE
    • 「りぺー」と読むらしい
  • 将来的には HBase を直接サポートする
  • EMR を使うことにより一番いい結果を見つけることが可能だからシミュレーションに適している

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

(株式会社Preferred Infrastructure, 岡野原 大輔)

MapReduce と機械学習
  • 機械学習普及の原因
    • タスクと手法の分離
    • 各タスク固有の問題を、抽象化して分離
  • 解析対象データの急激な増加
    • 解析アルゴリズムは最低でも線形の計算量が必要
    • それでも不十分でデータ増加量が上回る
  • 機械学習がMR向けでなくても、分散並列システムを一から
    • つくり直すよりははるかに生産的
  • 2006 Stanford、いくつかの機械学習はそのまま MR に使える
    • これが Mahout につながる
Mahout
  • スケーラビリティ最優先
    • 100台でも動くように
  • 開発が活発
  • その代わり品質はまちまち
  • クラスタリング
    • k-means
    • ディリクレ過程
    • LDA
  • パターンマイニング
    • Parallel FP growth algorithm
  • 文字列データ処理
  • 分類
  • 行列演算
  • 感想
    • 100台強でもちゃんとスケール
    • EC2上で構築
    • ドキュメントが不足している場合が多く、詳細の挙動についてはソースを参照する必要あり
    • パラメータ調整とかは難しい
大規模並列分散処理の最前線
  • Google, MS, Yahoo! などが中心
  • より強力なモデルを利用した機械学習
    • 新しい技術がその年に並列処理化される
  • グラフィカルモデル
    • 確率変数を頂点、変数間の依存関係を枝としたグラフ構造
    • ベイジアンネットワーク、MRF, CRF, HMM
    • MAP 推定
    • 問題があったらグラフィカルモデルに落として、確率が最大になる変数を求めたりとかする
    • 言語処理、情報抽出、音声認識、画像解析、遺伝子解析、構造予測で応用
  • グラフィカルモデルの分散並列処理
    • グラフィカルモデルの推論は一般に困難
    • 様々な並列化アルゴリズムが提案されつつある
    • MCMC のような方法でやる
    • 頂点を相互排他的な酒豪で色分け、色ごとに更新
  • 共参照解析(Google, 2010)
    • 二つの言及は同じ実体を指しているか?
      • 文中に出てくる「彼」と「Aさん」が同じかどうか
    • NYT 20年分の記事中に含まれる述べ100万の人名参照
    • 250台でもスケール
  • 数値最適化問題
    • 多くの機械学習は数値最適化問題に帰着
    • 分散させるには
      • データを分割して求め、それらの結果の平均をとるか
      • 勾配情報だけを分割して求めるか
      • どれも同じようにみえるが実は精度に大きな違いがあり、理論的に解析可能
  • Parameter mixture
    • データを分割して計算し、平均をとる
    • 性能も精度もいまいち
  • Distributed Gradient
    • 毎回パラメータを全ノード間で計算する必要あり
    • 収束は遅い
  • Asyncronous Update
    • 収束保証できるが遅い
  • Iterative parameter mixture
    • データを分割し配る
    • 最適化
    • 平均をとる
    • また全体に配る
    • 収束証明ができ、実際に高性能
今後注目の技術
  • Dremel
    • 対話的大規模データ解析基盤
    • 1兆件のデータが数秒で返ってくる
    • 簡単なクエリだけに特化
    • クエリ言語は SQL
    • データは繰り返しありの木構造
  • Google では 2006 年から利用
  • 列指向のデータ格納
    • 列指向DBの考えを木構造に応用
  • データは圧縮レコード
    • クエリに関係するフィールドだけを復元するオートマトンを生成して効率よく復元
  • クエリ処理アーキテクチャ
    • クエリは根から葉に向かって広がる
    • 結果は葉から根に向かって集約しながら伝わる
  • 実験結果
    • ワードカウント
    • 85bレコード 87Tb 270 field 3000 node
    • MapReduce 行指向 3000s
    • 列指向 1000s
    • Dremel 10s 強
  • 一部のノードでは時間がかかる
  • MapReduce の補助に Dremel は使える
    • 将来的に高速な推論、分類に利用可能
質疑応答とか
  • 大規模だと今後は教師なし学習に未来があるのではないかと

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

(株式会社ディー・エヌ・エー, 濱田 晃一)

モバゲー
大規模データマイニング基盤構成
  • KPI を定常的に算出
    • 皆が数字を共有できるようにする
    • こうできるように基盤構築
  • ビジネスプラン作成の材料としてデータマイニング活用
  • ユーザの「楽しさ」の特徴を機械学習で分析
    • その結果をサービス側で見れるようにする
  • Hadoop に全行動ログを決められた構造で投入
    • Hadoop の上で全て解析が閉じる
  • Pig
    • 一次的な集計、簡易 KPI 算出
  • Zebra
  • MapReduce/Perl/Java
    • 時系列処理
    • ゲームの分散シミュレーション
  • R
  • Mahout
  • DeNA Data Mining Libraries
  • Hadoop チューニング
    • HW/NW 周りの最適化
    • 中間データの圧縮
    • Reducer のデータ取得法のチューニング
    • Pig
      • Pig の Partitioner 実装の最適化
      • テンポラリ圧縮
      • 独自UDFの実装による1次集計の簡易化
      • 共通ログ Loader
    • Mahout
楽しさのマイニング
  • 大規模ユーザ
    • 統計的有意性を示しやすい
    • 多くの人に還元できる
  • 感情が分かる詳細行動情報
  • 楽しさのマイニング
    • ユーザ体験へ還元
  • 楽しさの行動パターン
    • 夢中になるきっかけ
    • 楽しんでサービス継続している行動特徴
  • やめてしまう状況パターン
  • 興味のあるゲーム/ユーザと出会えるプラットフォームへ
  • 健全なプラットフォームへ
    • 不正書きこみ
    • 年齢詐称
  • ユーザの声によるサービス洗練
大規模サービスで生じる問題
  • サービスごとにLogFormatが異なる
  • ログの場所がバラバラ
  • 統一行動記述での解決
世界展開
  • iOS/Android対応
  • Samsung に mobage 搭載
  • 国民性・民族性にあった楽しさ提供

『Enterprise Batch Processing Framework for Hadoop

 (ウルシステムズ株式会社, 神林 飛志)

Asakusa の目的
  • 期間バッチ処理を Hadoop 上で開発・実行・運用すること
  • Hadoop 上で基幹を動かすことの狙い
    • バッチ処理時間の短縮
基幹バッチの特徴
  • データの種類が多い
  • 処理の組み合わせは単純
    • 四則演算とかパターンマッチングとか
  • データフローが複雑
    • 設計の失敗がすごい大きい
hadoop の不足点
  • MapReduce 自体に不足はない
  • デバッグ・運用などは貧弱
Asakusa
DSL
  • 3層の DSL
    • BatchDSL
    • FlowDSL
      • ビルディングブロックを記述する言語
    • OperatorDSL
      • 処理の最小単位を記述する言語
  • ビルディングブロックの構成による処理フローの記述
  • トランザクション管理 - ロールバック制御

(以下ソースを元に解説)

  • BatchDSL, FlowDSL は誰でも書ける
    • 例に出したコードは COBOL 屋さんが書いた
  • OperatorDSL だけは Hadoop 知ってる人が書いたほうがいいかも
コンパイラ
ModelGenerator
  • Table/View を作ると自動的にクラスを生成
  • SQL もどきではなく、普通に SQL が使える
テスト
  • ModelGenerator からテストシートが自動生成される
  • 普通に JUnit から実行可能
外部連携
  • デフォルトは Sqoop で連携している
運用
  • MonkeyMagic用rbを自動生成
まとめ
  • 基幹バッチがほいほい書ける
    • 誰でも書けるのでアイデア勝負
  • なんと言っても「お金になる」
    • 基幹系は億単位
  • 使い方
    • Hackerな人
      • いじったりツール作ったり
    • 業務屋
      • プロトタイプを自分で作れる
    • SI屋な人
      • 大規模開発
      • 工数の見積もりができる
      • hadoopをコアで使える人が3人入れば通常と同等の工数で回せる

『Hiveを用いたAmebaサービスのログ解析共通基盤』

 (株式会社サイバーエージェント, 福田 一郎)

アメーバについて
  • ボリュームゾーン 20-40代女性
  • サービス規模
    • 1300万人
    • PV 200億PV
    • PC 100億PV
    • MB 95億PV
    • SP 367万UU
  • アメーバPigg
    • 600万人
    • ARPU 2,121円
  • サービス
    • アメーバピグ
    • モバイルゲーム
Ameba と Hadoop
    • アメーバピグ(HDFS)
    • アクセス解析サービス(Hadoop0.13.1)
    • pico(Amazon EMR, Pig)
Patriot
  • Hadoop Conference japan 2009
    • CDH, Hive などを知る
  • 開発合宿
    • 統合ログ解析基盤が必要という結論に至る
  • 2010/3 本格検証開始
  • 2010/7 リリース
  • 今までの問題点
    • サービスごとに独自に解析
    • ログ容量の肥大化
    • サービス開発担当者が解析部分にまで手が回らない
データストア
  • 以下のような形式でパーティショニング
  • login
    • date=2011-02-22
      • dev=pc (さらにこの下に複数の Bucket)
      • dev=mb
  • game
    • 日付
      • ゲームID
Hiveの紹介

(省略)

Patriotの運用
  • マスタ2台
  • ノード18台
  • Web/AP 2台
  • CDH3b3
  • Puppet, Nagios, Ganglia
  • Web/AP
  • ジョブ管理
    • hinemos
  • Namenode は NFS でバックアップ
  • 圧縮は gzip, SequenceFile, ブロック単位
  • 中間圧縮は lzo
  • UDF
    • 年齢によるグルーピング
  • HiveQL クエリ
    • デイリー 600
    • マンスリー 700
  • ログ容量
    • Pigg 4.5GB
    • タレントブログ関連 5.5GB
    • 処理時間3-4時間
  • デイリー、マンスリーサマリ
    • グラフにして表示
    • 属性レポート
  • Hue
    • Beeswax
      • ここはjava
      • HiveQLをWebUIから直接叩ける
      • アドホックな集計
      • ヒープサイズに注意(デフォルト1GB)
  • 啓蒙活動
    • 集計サマリをいつでも確認できる
    • Webアプリ上でHiveQLが叩ける
    • プロデューサなどエンジニアでない人も HiveQL を書く
  • 今後の展開
  • ログ収集の改善
    • Flumeなど
  • レコメンドなど実験的にやっているものを本格化
  • グラフ構造を使った解析

ライトニングトーク

Shunsuke Mikami: 「分散ファイルシステムGfarm上でのHadoop MapReduce」
  • Gfarm
    • 性能評価
    • teragen, grep でも HDFS に負ける
    • Fuse のせいかもしれない
  • Ceph
    • まだ運用では使えない
Fujikawa Koichi: 「Sneak Preview of "Hapyrus" ~ Hadoopアプリ開発&共有サービス on the CLOUD」
Sadayuki Furuhashi: 「MySQLにMapReduceジョブトラッカを実装する」
  • クラウド環境向けの新しい処理系
  • 特徴
    • SPOFがない
    • 任意のMap/Reduceタスクを連鎖可能
    • マルチユーザ対応
    • Worker 以外はすべて既存のシステムを利用
  • Hadoop JobTracker との違い
    • pull型
      • ストアドプロシージャで実装
  • Future work
    • データの構造化と圧縮
    • ログ収集
Yifeng Jiang: 「Hadoop and HBase for ranking processing at Rakuten」
  • Ranking Proces Engine
    • 8000 categories
  • huge data
    • realtime ranking
    • Daily, weekly, monthly ranking
    • yearly ranking
  • Mutable data
    • all of our data is mutable
  • using Hadoop
    • 100 job per day
  • Ranking meets HBase
  • Hadoop benefits
    • process 40x rankings
  • Hbase benefits
    • 15k rows insert / s
    • 0.3M rows scan / s
  • Something we learned
    • know the data
    • balance
Takahiro Kaneko: 「Bonding とネットワークスループット
  • bonding の設定を変えてスループットを測定
  • 参考値:NIC 1枚
    • 110MB/sec 880Mbps
  • balance-rr/src-mac
  • 802.3ad/src-mac
    • そこそこ
  • 802.3ad/src-dst-ip
    • 1.8倍くらいは出る
Yuuna Kurita: 「Hadoop+MongoDBでRで出力する時にRubyでミドルウェアを使う」
  • Hadoop+MongoDB
  • データ件数:280万件/年
  • フォーマットがすごく旧時代
  • ruby-mongo を使い、GridFS に保存
  • 統計屋さんの書く R コードは Hadoop Streaming にするのが非常に困難
  • Ruby + Streaming
    • Dumbo の ruby
    • msgpack で固めてる

『マルチユーザーでHadoop環境を利用するためのポイント』

 (株式会社NTTデータ, 山下 真一)

  • Hadoop環境
    • kickstart + puppet
    • CDH
    • Sqoop による RDBMS 連携
    • Hue からの操作
    • Ganglia
Hadoop で起きたエピソード
  • (1) ヒープメモリ枯渇
    • 空ファイルや小さなファイルを置かないこと
    • 見積もりは大切
    • モニタリングする仕組みは重要
  • (2) ライブラリ起因による処理の不具合
    • MapReduce 実行時、出力ファイルの一部が消失
    • Hadoop の投機的実行による同じ処理の多重実行が原因
    • ライブラリ内で HDFS 上のファイル名を変更するロジックが、

投機的実行によって"重複実行→不整合"な状況となって発生

  • (3) Hadoop クラスタ利活用の拡大
    • もっと色々な用途で利用したい
    • 社内の複数の部門の人たちでそれぞれのデータを利用して処理したい
マルチユーザ環境
  • Hadoopのコマンドを直接実行させない(Hueとかで)
  • 認証・認可
  • /user/は見せない
  • Hadoop のWebインタフェースにアクセスさせない
  • Hadoopクライアントを介さないとHadoopクラスタにアクセスできない
  • Hadoopクラスタに限られた人しかアクセスできない
  • 監査ログ・モニタリング(不正利用者の検出)
    • ログ自体もhadoopで処理
HDFS
  • パーミッション
    • supergroup は利用しない
    • 750, 640 の設定
  • クォータ
    • ファイル数やディレクトリ数
    • 格納できるサイズ
    • どちらもディレクトリ単位で設定
  • HDFSの内部通信に関するポリシー
    • hadoop-policy.xml
      • Client 関係の通信
      • Client と DataNode に関する通信
  • 認証・認可
    • Kerberos, SASL
MapReduce
  • スケジューラによる複数ユーザのジョブ制御
    • デフォルトのスケジューラ
    • FairScheduler
    • CapacityTaskScheduler
  • MapReduce の内部通信に関するポリシー
  • MapReduceに関する ACL 設定
今後の課題
  • ChildプロセスのJVMオプション制御
  • スケジューラ改良
  • 占有資源と共有資源の制御
  • 物理ディスク対策
  • ユーザとグループ

Hadoopと分析統計ソフトKNIMEを用いた効率的データ活用』

 (株式会社リクルート, 中野 猛)

  • Hadoop 環境
    • DC移行で確保した余剰サーバ35台で検証環境
    • 本番環境は新サーバ23台で構築中
    • Hive + PostgreSQL
    • HBase も利用準備中
  • 取り組み
    • メルマガ用リコメンド計算バッチ処理時間短縮
    • 相場表型のクロス分析
  • 取り組みの分類
    • (1)既存の処理(バッチ)を高速化する
      • ここは大分できた
    • (2)今不可能とされていた処理を実現する
    • (3)前提を考えて挑戦する
  • 人の話:視線を合わせる
    • 分析屋さんとシステム屋さん
    • 正義は微妙に異なる
  • 物の話:道具を共通化する
    • まず触ってみられるようにしたい
    • 商用分析ツールはすごく高価
KNIME
  • データのロジック処理をビジュアルに組み立てるツール
  • アニメーションでの状況確認
  • ドイツのコンスタンツ大学が開発元
  • ユーザ
  • 製薬系の研究所→サービス企業
  • 類似には Spoon(Pentaho)/Orange など
    • KNIME の方が 統計/マイニングの統合/充実度
  • クラスタリング等マイニング系は充実
  • まとめ
    • ビジュアル的に処理ロジックを考える
    • オープンな KNIME ってのもあります
    • Hadoop を利用したデータの活用