2011/02/24

Hadoop Conference Japan 2011行ってきました

Hadoop Conference Japan 2011 に行ってきました。ニュースサイトでよく Hadoop についての記事を見かけ、「Googleなどの巨大サイトで稼働するシステムのオープンソース実装」という程度の認識しかありませんでしたが、「大規模分散」という響きに惹かれて興味本位だけで参加してきました。メモも満足にとれていませんので公開された資料とともにチラシの裏的にまとめます。

正直なところ予備知識があまりにもなさ過ぎたため、講演された内容についてはほとんど理解できませんでした。当日の講演内容について正しい情報を知りたい方は他のページとあわせてご確認ください。

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

Amazon Web Services, Jeff Barr さま。（ @jeffbarr ）Amazon Elastic MapReduce (EMR) についてのそのサービス概要、メリット、使用事例について。

  • 講演資料：Amazon Elastic MapReduceの紹介(英語)
  • What is Big Data
    • Does'nt refer just to volume
  • What is Amazon Elastic MapReduce
    • Enables custom to easily, securely and cost-effectively process vast amounts of data
    • Elastic MapReduce removes "MUCK" from Big Data Processing
Big Data、MUCK という単語が印象に残りました。Amazon（に限りませんが）のクラウドについて知識はありませんが、Hadoop はその実行環境を構築・運用するだけでもたいへんだと思いますので、データ解析、データマイニングなど、必要に応じてクラウドサービスとして使用できるのは便利そうだなと思いました。それと同時通訳の正確さに驚きました。TL みてると何回もペアを組んでいるそうですね。リハなしでこれはスゴイ。

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

株式会社 Preferred Infrastructure, 岡野原 大輔さま。（ @hillbig ）

  • 講演資料：MapReduceによる大規模データを利用した機械学習
  • 機械学習とMapReduce
    • 機械学習の普及の要因。タスクと手法の分離。特徴ベクトル、グラフィカルモデル。
    • 各タスク固有の問題を抽象化し、学習手法とタスクを分離することが出来た。
    • 解析対象データの急激な増加。解析アルゴリズムは最低でも線形の計算量が必要。
    • 世界で作成されるデータ量は、2009 年で 0.8ZB(前年比 62% 増) 2020 年では 35ZB(予想)
    • 機械学習処理が MapReduce 向けでなくても、分散並列システムを一から作り直すより遙かに生産的。
    • 多くの機械学習問題が、データごとに求まる関数値の和を求める問題に帰着。
    • 線形回帰、K-Means、ロジスティック回帰、SVM 等多くの手法が実装可能。
  • 大規模並列分散処理の最前線：Apache Mahout
    • Hadoop で動く機械学習ライブラリ。
    • スケーラブルであることを最優先（百台超でも動くように）
    • 盛んに新しい手法が取り込まれている。
  • 今後の注目技術：Dremel
    • 対話的なアドホッククエリ。大規模データ解析基盤。
    • 一兆のデータに対するアドホッククエリの結果が数秒で得られる。
    • MapReduce とくらべて低レイテンシ、簡素な統計処理のみ。
    • クエリ言語は SQL。各データは繰り返しありの木構造。(nested representation) JSONのような。
    • Google で 2006 年から利用。クロールデータ解析、障害分析、スパム解析 etc。
    • 列指向 DB の考えを木構造に応用。各属性の値は木中の同じ位置、値ごとに連続した領域に格納される。
    • 一部の属性しかクエリに関係ない場合、大部分を読まずに済む。
    • クエリに関するフィールドだけを復元するオートマトンをその場で構築。クエリ処理アーキテクチャ。
    • Dremel 実験結果
      • 各単語の出現回数を数える。850 億レコード、87TB、270 フィールド、3000 ノード
      • MapReduce 行指向 … 約3,000秒
      • MapReduce 列指向 … 約1,000秒
      • Dremel … 約10秒強
    • 一部のノードで時間がかかる。99%の結果は 5秒以内。残りは数分かかる。
    • 列指向＋必要な列だけ復元＋木構造クエリサーバで大幅な高速化が可能。
    • MapReduce の補助に Dremel。MR で索引を作るような感覚で、Dremel はそれを使った検索みたいなもの。
    • MapReduce 以外にも最近は HBase などもある。
前置きにあるとおり学術的な内容が多かったので私には理解できませんでした。。。名前だけ聞いたことのある Apache Mahout がどのようなものであるかを知ることができました。

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

株式会社ディー・エヌ・エー, 濱田 晃一さま。( @hamadakoichi )

  • 講演資料：『モバゲーの大規模データマイニング基盤におけるHadoop活用』－Hadoop Conference Japan 2011－ #hcj2011
  • ソーシャルプラットフォーム：モバゲータウン
    • ユーザ数 2300万人以上、1日 20億の行動情報
    • Facebook はリアルを軸としたもの。モバゲータウンは興味を軸としたソーシャルグラフ。
  • 大規模データマイニング基盤
    • データマイニング・機械学習の活用により迅速なサービス洗練を実現。
    • KPI 定常算出して共有。ビジネスサービス変化を検知。
    • Hadoop DFS: 全行動ログ・サービスデータ投入。
    • Pig: Java でダイレクトに組むより手軽に扱える。
    • Zebra: 一次集計データのスキーマ管理。
    • MapReduce: Perl/Java/R。時系列処理、ゲーム分散シミュレーションなど。
      • ゲームは Perl で書かれている。
      • Hadoop Streaming を用いて R でも MapReduce は実装できる。
    • Mahout: 大規模なデータマイニング・機械学習
  • 楽しさのマイニング
    • 1日20億超の行動情報: 統計的有意。感情が分かる詳細行動情報。
    • 楽しさのマイニング。ユーザー体験への還元。
    • 楽しさの行動パターン
      • 夢中になるきっかけ。夢中になる体験をして貰い、そのサービスを維持している行動、特徴。
    • やめてしまう状況パターン
      • 飽き始めるきっかけ、不快な状況。→止めるきっかけを発生させないようにする。飽き始めたユーザー予測判別。
    • データマイニング、機械学習の解析結果を反映した数時間〜数日スパンでの迅速なサービス洗練。
  • 統一行動記述
    • サービスごとにログフォーマットが異なる。ログの場所が分散されている
    • ログの収集や基礎集計作業で手一杯になってしまい、データマイニング・機械学習の活用までできない。
    • 統一行動記述で解決
      • 統一スキーマ。再利用、サービスを横断した解析。
      • Hadoop に全てのログがある。データ探索、収集時間ゼロ。
  • 世界へ
実装よりの具体的な話はありませんでしたが、大規模サイトにおける Hadoop 適用領域について知ることができました。

Enterprise Batch Processing Framework for Hadoop

ウルシステムズ株式会社, 神林 飛志さま。（ @okachimachiorz1 ）基幹系業務システムのバッチ処理の高速化を Hadoop 上で実現する、モデル生成、設計、DSL、コンパイラ、トランザクション制御、外部 API まで揃っているフルスタックの OSS、Asakusa Framework の紹介。

基幹系、業務系ともに知識の浅い私にとって非常に興味深いセッションでした。その巧みな会話と所々に散りばめられたキーワードにことごとく反応してしまい、ほとんどメモできていません。。。他の方のつぶやきなどを参考にして覚えている範囲のキーワードをピックアップします。
  • 講演資料：Asakusa Enterprise Batch Processing Framework for Hadoop
  • 「夜間バッチは、エンジニア・顧客双方にとって最悪。なくしたい。」「夜間バッチが落ちて夜中に呼び出されるなんていやでしょ？」
  • 「高度な数学は要りません」「もっとも高度なアルゴリズムは割り算」「かわりにデータフローが複雑」
  • Hadoop に足りないもの
    • MapReduce に不足はないが、バッチを書くためにはいろいろ足りない。
    • 大規模開発手法がなく、実装は職人芸。
    • 自作 MapReduce。ここは普通に作れる。
    • 謹製 Writable。ここも何とか作れる。
    • 根性デバッグ
    • シャーロックホームズな運用
    • God Modeしかないメンテ「責任者出てこい！」
    • →「もしかして、普通に基幹バッチを書くと、しねる？」「ええ、もう完璧に」
  • Asakusa は Pig/Hive の上層にあるもの
  • Ashigel コンパイラ
    • 日本の若手ハッカー(@ashigeru)による初の MapReduce コンパイラ。
    • DSL から MapReduce プログラムを生成。MapReduce チェインの最適化など。
    • 運用スクリプトも生成。
    • 「わりといろんな黒魔術を使っています」
    • Ashigelコンパイラの勉強会 : ATND
  • DAG ベースの多層 DSL 構造
    • Operator DSL → Flow DSL → Batch DSL
    • Batch DSL の例は MapReduce を知らない COBOL 屋さんが書いたもの。
  • 大事なのは、トランザクション
    • 「HDFSはぶっ壊れるもの（＝キャッシュ）」
    • トランザクションを DSL で指定することで、データを DB に保全する。
    • 外側で必要に応じてロールバックする。
    • TX 単位は MapReduce ではなく、その上位の業務の塊で処理する。
    • 「Hadoop 自体がぶッ壊れても、大ジョブだ、心配ない」
  • テスト自動化
    • JUnit で実行可能なテストドライバが作成される。
  • 運用ツール
    • 現時点でデフォルトは、MonkeyMagic
    • 運用のためのスクリプトが生成される。MonkeyMagic 用の ruby スクリプトの生成。
  • ERP on Hadoop
    • 実案件として新会計、受発注を行っている。
  • OSS 化は 3月を予定(Asakusa 適用案件が 2/E の C/O)

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

株式会社サイバーエージェント, 福田 一郎さま。（ @toutou ）

  • 講演資料：Hadoop conferencejapan2011
  • アメーバについて
    • 会員数: アメーバ全体 1300万人 、アメーバピグ 600万人
    • サービス: ブログ、なう、アメーバピグ、モバイルゲーム
  • アメーバと Hadoop
    • アメーバピグ(HDFS)
    • アクセス解析(Hadoop 0.13.1)
    • pico(Amazon EMR、Pig)
  • ログ解析基盤Patriot
    • 開発までの経緯
      • Hadoop Conference Japan 2009 で CDH、Hive などを知る
      • 同月の開発合宿で統合ログ解析基盤が必要との結論に至る
      • 上長へ上申→即決で 2010/3 から本格検証開始、2010/7 に第 1 弾リリース
    • 目的
      • Ameba サービス全体の統合的な現状把握と未来予測
      • 各サービスのデータを集約。サービス開発支援。
    • 方法
      • ログの集約: HDFS
      • ログの集計: Map/Reduce
      • ログの構造化: Hive
      • 集計結果の表示: Patriot WebUI(CIC)
      • アドホックな集計、解析: HUE
  • Hive
    • Hadoop サブプロジェクト。Facebookで開発された。
    • SQL ライクな言語(HiveQL)で MapReduce を実行。
      • 同様の試みにスクリプト言語 Pig がある。
    • メタストア
      • テーブルのカラム情報などを保持
      • デフォルトは Apache Derby
      • Patriot では MySQL を使用
    • 行単位での更新ができない
      • Partition(HDFS 上のディレクトリ)を使う
    • データストア
      • (例) login テーブル
        • date=2011-02-22
          • dev=pc
            • Bucket
          • dev=mb
        • date=2011-02-23
        • ...
    • データモデル
      • Primitive
        • int, float, double, string
      • Complex
        • map<key-type, value-type>
        • list<element-type>
        • struct<field-name:field-type>
    • DDL
      CREATE TABLE pigg_login (
   time     STRING
 , ameba_id STRING
 , ip       STRING
)
PARTITIONED BY (time STRING)                   …パーティションカラムを指定
ROW FORMAT DELIMITED FIELDS TERMINATED BY '¥t' …カラムの区切り文字を指定
STORED AS SEQUENCEFILE;                        …ファイル形式を指定
    • データのロード
      LOAD DATA (LOCAL) INPATH '/tmp/pigg_login.log'
INTO TABLE pigg_login
PARTITION (time='2011-02-22'); …dfs mv、put をする形
    • HiveQL
      • SELECT * FROM t1 JOIN t2 ON (t1.a2 = t2.b2);
      • UDF - Hive User Defined Functions
        • cast, abs, substr
      • UDAF
        • count, sum, max, min, avg
        • percentile(col, p)
      • SerDe
        • Serialization/Deserialization
        • カラムの区切り文字などを定義
          CREATE TABLE test(c1 string, c2 int)
FOR FORMAT DELIMITED
    FIELDS TERMINATED BY '\t'
    LINES TERMINATED BY '\n'
        • 正規表現で定義（例：Apache ログ）
          add jar 'hive_contrib.jar'
CREATE TABLE apachelog (host STRING, identity STRING, user STRING, time STRING, method STRING, resource STRING, proto STRING, status STRING, size STRING, referer STRING, agent STRING, proctime STRING)
ROW FORMAT SERDE 'org.apache.hadoop.hive.contrib.serde2.RegexSerDe'
WITH SERDEPROPERTIES ("input.regex" = "^(.*?) (.*?) (.*?) ¥¥[(.*?)¥¥] ¥"(¥¥S+?)(?: +(.*?) +(¥¥S*?))?¥" (.*?) (.*?) ¥"(.*?)¥" ¥"(.*?)¥" (.*?)$"
 , "output.format.string" = "%1$s %2$s %3$s %4$s %5$s %6$s %7$s %8$s %9$s %10$s %11$s %12$s");
  • Patriotの構成と運用
    • ファイルフォーマットの検討
      • フォーマット: TextFile, SequenceFile
      • 圧縮形式: gzip, bzip2, LZO
        • 圧縮率: bzip2 > gzip > LZO
        • インポート時間: LZO > 無圧縮 > gzip > bzip2
        • 計算時間: 無圧縮 > LZO > gzip > bzip2
      • →Patriot では gzip, SequenceFile, ブロック単位の圧縮、を使用中
      • →MapOutput は LZO で圧縮
    • インポート処理 DSL
      import {
  service    "gyaos"
  backup_dir "/data/log/gyaos" 
  data { 
    type    "scp" ← その他に「mysql」、「hdfs」
    servers ["172.xxx.yyy.zzz", "172.xxx.yyy.zzz"] 
    user    "cy_httpd" 
    path    "/home/cy_httpd/logs/tomcat/lifelog/*.#{$dt}*" 
    limit   10000
  }
  load {
    type "hive" ← 「mysql」
    table {
      name      "game_login"
      regexp    "^[^¥¥t]*¥¥t([^¥¥t]*)¥¥tlogin" 
      output    "$1" 
      partition :dt => "#{$dt}", :service => "gyaos" 
    } 
    table {
      name      "game_user"
      regexp    "^([^¥¥t]*)¥¥t([^¥¥t]*)¥¥tregist_game"
      output    "$2¥t$1"
      partition :dt => "#{$dt}", :service => "gyaos"
    }
  }
}
    • 集計・解析処理 DSL
      mysql {
  host     "localhost"
  port     3306
  username "patriot-batch"
  password "xxx"
  database "gyaos"
}
analyze {
  name    "gyaos_new_user_num_daily"
  primary "dt"
  hive_ql "select count(1), #{$dt} from game_user where dt=#{$dt} and service=gyaos"
}
analyze {
  name    "gyaos_unregist_user_num_daily"
  primary "dt"
  hive_ql "select count(1), #{$dt} from game_user g join ameba_member a on(g.ameba_id = a.ameba_id) where a.unregist_date <> and to_date(a.unregist_date)=#{$dt} and g.service=gyaos"
}...
    • ゲーム関連の集計
      • モバイルゲーム: ゲームごとにパーティションを作る
      • Pigg 内ゲーム: 釣り、カジノゲーム→UNION ALLで合わせて集計
    • 運用上の数字
      • HiveQL クエリ
        • デイリー（定型）: 約600
        • マンスリー（定型）: 約700
      • 会員データレコード数: 1300万以上
      • ログ容量（デイリー）
        • Pigg: 4.5GB(圧縮後)
        • タレントブログ関連: 5.3GB(圧縮後)
      • 処理時間（全集計）: 3〜4時間
    • Web インターフェース(CIC)
      • デイリー、マンスリーサマリ
      • 属性レポート（性別、年齢などの割合）
      • タレントブログ解析（大和）
    • HUE
      • Beeswax
        • HiveQL を Web UI から直接叩ける
        • アドホックな集計が可能
        • ヒープサイズに注意
      • Hue の運用
        • Hive メタストア（マスター）
          • HDFS への書き込み権限のある HUE ユーザ
          • 管理者用
        • ↓MySQL レプリケーション
        • Hive メタストア（スレーブ）
          • HDFS への書き込み権限なし
          • プロデューサー用（≠エンジニア）
    • 啓蒙活動
      • 集計サマリをいつでも確認できる
      • Web アプリ上で HiveQL が叩ける
      • プロデューサなどエンジニアでないひとも HiveQL を書く
        • 毎日、多くのアドホックな集計が走っている（でも落ちない）
        • 失敗から学ぶ
    • 今後の展開
      • HBase CDH3b4
      • ログ収集の改善: Flume など
      • レコメンドなど実験的に行っているものを本格化
      • 「なう」などグラフ構造を使った解析
運用の話で実コードが出てくると俄然興味がわいてきます。前提知識はありませんが、ディレクトリによるパーティションプルーニングなどの考え方は RDBMS と一緒だなと思いました。それにしてもエンジニア層ではない方々もバンバン HiveQL などを使って独自の分析を行っているというのがスゴイです。

ライトニングトーク

はじめてライトニングトークを体感したのですが、短い時間に講演者からの密度の濃い情報が展開されていました。濃縮されすぎててとても理解が追いつきませんでした。。。一部分だけ反応します。

Shunsuke Mikami: 「分散ファイルシステムGfarm上でのHadoop MapReduce」

HDFS の問題点。POSIX に準拠していない。追記以外の再書き込み不可、複数ライターからの書き込み不可。

  • Gfarm
    • 汎用的な分散ファイルシステム
    • サーバの余っているローカルファイルシステムを束ねて分散共有ストレージにできる
    • Better NFS
    • メタデータサーバ1台
  • GlusterFS
    • マスターがない
    • FUSEベース
    • 複製ある／なし、ストライピングする／しない、を選択可能
  • Ceph
    • 負荷かけると固まる...
  • Lustre
  • PVFS2
    • 今後調べたい
GlusterFS というのは以下のページで知りましたが、分散共有ファイルシステムとしてローカルストレージも無駄なく使うという考え方は非常に参考になります。

Fujikawa Koichi: 「Sneak Preview of "Hapyrus" ~ Hadoopアプリ開発＆共有サービス on the CLOUD」

Hadoop アプリ実行環境付きマーケットプレイスの紹介。

Sadayuki Furuhashi: 「MySQLにMapReduceジョブトラッカを実装する」

kumofs や MessagePack 作者の古橋さま。(@frsyuki) MySQL を JobTracker に使うクラウド環境(AWS)向けの新しい MapReduce 処理系のプロトタイプ実装のお話。内容にはついて行けませんでしたが、デモでターミナルから MySQL に対するクエリ実行とその結果確認の操作で GNU Screen による淀みない画面切り替えが行われているのを見て、ああやっぱりこういう使い方するよな普通、と妙に嬉しくなりました。

Yifeng Jiang: 「Hadoop and HBase for ranking processing at Rakuten」

HBase での処理速度向上のお話。

  • Performance tuning is all about the balance
    • hardware
    • OS resources
    • Hadoop configuration
    • application design

Takahiro Kaneko: 「Bonding とネットワークスループット」

bonding とかネットワークスループットとかよく聞く単語が出てくると安心できます。NIC 単体の性能と、bonding とスイッチ設定の組み合わせでの各種計測結果の発表。以下はスループットを計測した結果、性能がよかった順。

  1. 802.3ad & src-dst-ip
  2. 802.3ad & src-mac
  3. balancer-rr & src-mac
    • balancer-rrのスループットはあまり良くない。スイッチの CPU ネックになる。

Yuuna Kurita: 「Hadoop+MongoDBでRで出力する時にRubyでミドルウェアを使う」

健保レセプトのデータ解析についてのお話。

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

株式会社NTTデータ, 山下 真一さま。Hadoop をマルチテナント向けに展開するための取り組み、という趣ではなくマルチユーザでも使うことができるのでその場合に考慮すべき事項についてのお話。

とてもまとめられた資料で情報量が多く、ほとんどメモできませんでしたので気づいたところだけ。

  • 発生しうるトラブル
    • HDFS
      • 誰かによって領域がすべて使用される
      • 誰かによってメタ情報がすべて使用されている
      • 誰かがかってにファイルを操作する
    • MapReduce
      • 誰かの処理がものすごく時間がかかる
      • 誰もが VERY_HIGH でずっと処理を実行する
      • 誰かの処理でリソースが枯渇する
    • その他
      • 誰が何を実行しているか筒抜け
      • 誰がどんなデータを格納しているか筒抜け
  • 対策
    • Hadoop のコマンドを直接実行させない(例：Hue)
    • Hadoop の Web インターフェースにアクセスさせない
    • 監査ログ、モニタリング
  • アプリケーションを実行する利用者に対するルールを決めることも大切！
    • MapReduce アプリケーション内に不正な処理を埋め込むことは可能であるため
セキュリティと利便性は相反しますしコンピュータ資源も有限ですので、そのあたりを利用者に理解していただくことも重要なところですね。

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

株式会社リクルート, 中野 猛さま。

  • リクルート＋Hadoop
    • Hive は利用開始。各種案件への適用中。メタストアは PostgreSQL。UDF の拡張性が便利。
    • HBase も利用準備中。半リアルタイムなデータ集計。Hive のテーブルを格納する。
    • メルマガ用リコメンド計算バッチ処理時間短縮
    • 相場表型のクロス分析
  • これまでの活動
    1. 既存の処理を高速化する
    2. 今不可能とされていた処理を実現する
    3. 前提を変えて挑戦する
  • トライに向けて
    • 1は加速してきたので2と3にトライしたい
  • 分析屋さん＋システム屋さん
    • 人の話: 視線を合わせる
      • 正義は微妙に異なる（目的は同じ、視座が異なる）
      • SQL 的に考える／R 言語的に考える
    • モノの話: 道具を共通化する
      • まず触ってみられるようにしたい
      • 共通の言語素子となりお互いに解釈可能に
      • 分析屋さんの商用ツールはきわめて高価
  • KNIME とは
    • KNIME - Konstanz Information Miner
    • データの処理ロジックをビジュアルに組み立てることができるツール（＝分析屋さんのツール）
    • 処理ロジックは、ノードを繋いで組み立てることで行う。分析屋さん、製薬屋さんが使っていた。
    • よいところ
      • クラスタリングなどマイニング系は妙に充実
      • 処理を Java でスクリプト的に記述も可能
    • そうでもないところ
      • SQL なら一文で書ける処理も複数ノードで複雑になる
      • 完全に英語（ネットの情報もほぼ英語）
    • Hadoop との連携
  • その他 OSSに対する取り組み
    • PostgreSQL
    • Solr
    • TokyoTyrant
    • JMeter+VisualVM

おわりに

「データを活用する。」言うのは簡単ですが、情報爆発時代においてはそれらの収集だけでも大変ですし分析となると言うに及ばず。これからの情報爆発時代をきのこるには、データを活用する術を身につけなければ行けないなと感じた一日でした。

本カンファレンスは、Hadoop 徹底入門の出来上がったばかりの二刷りの壮大な即売会だったようですが、参加者の多くはすでに初版を購入されている方が多いのではないかなーと思いましたｗ

at 17:36
このエントリーをはてなブックマークに追加

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)