@nokuno なるほど。それはその通りですね。それをふまえた上で。単に DAG って言ってしまうのは、対象によってできることが違ったりするので。大雑把すぎるのでないか、という気がしているわけです。 #hcj2011

posted at 00:07:36

RT @hamadakoichi: Togetter に全ツイート追加しました。凄い量。 「Hadoop Conference Japan 2011 #hcj2011 」 http://togetter.com/li/104169

posted at 00:08:36

仕事を中断して、Hadoop Conference Japan 2011 へ移動中。 #hcj2011

posted at 12:58:17

#event 2011/02/22「Hadoop Conference Japan 2011」<http://hadoop-conference-japan-2011.eventbrite.com/ > : 参加中 #hcj2011

posted at 13:53:26

ソーシャルウェブアプリケーションサービス。利用状況データに対するデータマイニング・機械学習を用いて、サービスの適合化を進める。 #hcj2011

posted at 13:54:23

スタック構成: Hadoop DFS → { Pig → Java, Perl, R }, { Zeba → MR }, { Lucene → DeNa Social MA → Mahaut } #hcj2011

posted at 13:54:33

Pig や Mahaut チューニング。データ分割最適化, 圧縮によるI/O 改善, 独自UDF, 等々。 #hcj2011

posted at 13:57:00

DM・ML で楽しさを。2300満人以上 20億+アクション → 統計的に有意な知見 → 多くの人へ還元 → 利用の活性化。感情まで分かるような詳細行動情報を扱えるようになった。 #hcj2011

posted at 13:59:37

楽しさのマイニング: ソーシャルグラフや日々の活動履歴。どのような体験と口調があった時に楽しさが見られるのか。楽しんでいる人/楽しめてない人/飽きてしまっている人がどのような行動が見られるか。楽しさの数値化、情報推薦、時系列解析、コミュニケーション解析など。 #hcj2011

posted at 14:01:48

楽しさの行動パターン: 夢中になる契機は何かを解析。楽しさのパターンを高頻度に発生させ、より楽しいサービスを体験させる。この知見が蓄積され、初期利用段階へも適用可能になる。 #hcj2011

posted at 14:03:43

辞めてしまう状況パターン: 飽き始める契機や不快な状況を解析 → 発生させないように。飽き始めたユーザの予測・判別 → 新鮮・斬新な体験の提供や他のサービスの推薦。 #hcj2011

posted at 14:05:23

目指すのは。興味のあるゲームやユーザと出会えるプラットフォームにするため、ゲーム推薦やユーザ推薦。一方、健全なプラットフォームにするため、不正書込みや年齢詐称の判別。ユーザ主導のサービス洗練のため、ソーシャルコミュニケーションのテキストマイニング。 #hcj2011

posted at 14:07:17

「コンサルとは違い、解析結果を迅速に反映できる面白さ。数時間から数日で結果が見えて来る。ユーザ行動を機械的に解析してフィードバックできるのは、ソーシャルゲームの特性。 #hcj2011

posted at 14:09:15

「ユーザ行動の時系列を統一記述しデータ処理を容易に。大規模サービスでありがちなのは、サービスごとにログ形式が異なる状況。1. ログ中のパラメータの意味が不明, 2. 個別にデータ処理をしないとならず不便, 3. ログの在処が不明。 →ログ収集や基礎統計できない #hcj2011

posted at 14:13:01

「統一スキーマと Hadoopへの蓄積で解決。実装の再利用、学習コストの軽減、データ収集コストを削減。 #hcj2011

posted at 14:15:19

「ソーシャルプラットッフォームの世界展開。ngCore で iOS, Android の双方へ同時実装可能。サムスン電子の mobage 端末。 →世界中の人々の楽しさマイニング。国民性・文化の違いも抽出できるはず。 / よりよい世界を実現したい仲間を募集中。 #hcj2011

posted at 14:17:45

『Enterprise Batch Processing Framework for Hadoop』 #hcj2011

posted at 14:17:56

「祭ということで、会社の方針とは関係なく、個人的な見解も多々述べるのでよろしくw #hcj2011

posted at 14:19:34

「Asakusa: 幹バッチ処理を Hadoop上で、開発・実行・運用可能にするフレームワーク。時間がかかっていたバッチ処理をごく短時間で実現できる。夜間バッチは、エンジニア・顧客双方にとって最悪。なくしたい。 #hcj2011

posted at 14:21:05

「基幹バッチを書いたことある人……は会場にはほとんどいない。バッチ処理の例。データ取得・クレンジング・処理・保存という一連の処理を多数組み合わせて巨大な処理をする。基本的に BI に似ている。 #hcj2011

posted at 14:24:32

「BI との比較: データの種類が多く、中間データも含めて 1000種類に達することも。処理の組合せ自体は単純で、四則演算やパターンマッチ、フラグ処理が多い。データフローが複雑で、条件分岐・コントロールブレイク、ネスと処理。設計がかなり重要。 #hcj2011

posted at 14:24:39

「Hadoop で(何)が足りないか。MR は十分だが、バッチを書くためにはいろいろと足りない。大規模開発手法がなく、実装は職人芸。"もしかして、普通に帰還バッチを書くとしねる?" "完璧に"。 #hcj2011

posted at 14:26:22

「ロゴ初公開。屋形船! Pig が上位層だが、コアには手を入れていない。DAGベースの多層 DSL。ビルディングブロックを汲み上げて行く方式。トランザクション管理でロールバック制御も。開発方法論まで視野に入れる。 #hcj2011

posted at 14:27:51

「DAGベースでの詳細ブレークダウン。構造化手法 STF やモジュール強度の援用。SPF演算子の考え方。Grasp原則の適用。データモデルの設計は, 静的モデルを渡り歩くスタイル。 #hcj2011

posted at 14:33:41

「MRコンパイラ Ashigel Compiler。モデル生成器: テストのデータ層の自動化をすごく重視。3層の DSL: batchDSL / flowDSL / operatorDSL。ビルディングブロックの構成で処理フローを多層に記述し、見通しよく再利用。 #hcj2011

posted at 14:34:32

「DSL の記述例 .o(見えない)。やっているのは基本的なバッチの記述と変わらない。このサンプルは COBOL プログラマが書いた。MR は表面には一切出てこない。OperatorDSL はさすがに MR 使いが書く必要がある。 #hcj2011

posted at 14:36:47

「デフォルトで準備されているDSLモジュール: データ編成，業務系機能，フロー制御の各種処理，基本的な各種の基本的な演算子。Ashigelコンパイラは Pigに比べても遜色ない。ステージングコンパイラで最適化し、MRプログラム群を生成。下位タスクの共通化が課題。 #hcj2011

posted at 14:40:35

「モデル生成器: HadoopIO は結構面倒。SQL のようにテーブルやビューを定義すれば、入出力演算が可能な MR モジュールを生成してくれる。現場はこういうのが好き (自分は嫌いw)。 #hcj2011

posted at 14:43:57

「テストは非常に重用していて、手厚くサポートしている。モデル生成器がテストシートを生成するので、それを適宜埋めて。 #hcj2011

posted at 14:45:10

「外部連携: デフォルトは sqoop。バルク処理などに対応。 #hcj2011

posted at 14:48:45

「運用スクリプト: Ashigelコンパイラが自動生成。デフォルトでは MonkeyMagic 用の Ruby スクリプト。実績と動的言語らしく制御できるアイテム代わりと自由。クラウド用のライセンス体系。運用監視のコストは無視できない。 #hcj2011

posted at 14:48:52

「Hadoop で ERP を構築中。Hadoop でここまでできる! / Asakusa は 3月目標で OSS 化。βは連絡してくれれば使える段階。 #hcj2011

posted at 14:51:09

「ポイント: (略)www」意訳: 「むずかしいことぜんぜんしらなくてもかけるよ」 「一般業務向けの処理が誰でもかける。マーケットが BI よりも確実に大きい。基幹系でない業務系でも使える。 #hcj2011

posted at 14:52:28

「ターゲットユーザ: ハッカーな人 (技術的に踏み込める)、業務屋な人 (アイデアの検証をできる)、SI屋な人 (少ない工数で実現できる)。 #hcj2011

posted at 14:54:12

「Asakusa 関連の勉強会も 2/25 にある。Asakusa Scala DSL も @asami224 氏が開発中。乞うご期待。 #hcj2011

posted at 14:56:00

.o(あいかわらず盛沢山で忙しいな ^^; 2/25 が楽しみだ。 #hcj2011

posted at 14:56:32

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

posted at 14:57:00

「Ameba ユーザは……会場にはあまりいないようですw 中心ユーザは 20〜30代女性ということで、女性がいないw #hcj2011

posted at 14:59:19

「主なサービス: アメーバブログ, アメーバなう。アメーバPigg は、仮想室内でリアルタイムコミュニケーションができるサービスで 600万人, ARPPU 2,121。他にモバイルゲームも多数。 #hcj2011

posted at 15:01:31

「Hadoop 使用実績。ピグ: HDFS。pico: Amazon EMR, Pig。アクセス解析 (v.0.13.1 w)。 #hcj2011

posted at 15:03:19

「ログ解析基盤 Patriot。2009/11: HCJ2009 で CDH, Hive に触れ。直後の開発合宿で解析基盤の重要性を議論し、局長に相談してゴーサイン。2010/03: 本格運用開始。 #hcj2011

posted at 15:05:17

「各サービスごとので独自解析は効率が悪い。→ ログの集約: HDFS, 集計: MR, ログ構造化: Hive (当時は Pigより書きやすく高速だった), 表示 CIC (Patriot WebUI), アドホック集計・解析: HUE。 #hcj2011

posted at 15:08:32

「開発体制: 会員獲得系, 課金系担当, システム3名, インフラ(都度対応)。 / 解析処理フロー: Hive でログ整形 →Hadoopクラスタでサマリデータを生成 →MySQL に格納 →閲覧。 #hcj2011

posted at 15:18:05

「ファイル形式: 圧縮は gzip でブロック単位圧縮。LZO も。データインポートは SCP, HDFS get で util サーバに入れ、Hive で Hadoop クラスタへ。 #hcj2011

posted at 15:20:12

「ゲーム関連の集計: モバイルゲームはゲームごとにパーティションを作成。Pigg ないゲームは、 UNION ALL でまとめて集計。 / UDF (ユーザ定義関数) も簡単に作れるので重宝。 #hcj2011

posted at 15:23:20

「CIC: 日別・月別サマリ, 性別や年齢などの属性別レポート, タレントブログ解析 (閲覧者属性も)。 #hcj2011

posted at 15:29:28

「CIC: 日別・月別サマリ, 性別や年齢などの属性別レポート, タレントブログ解析 (閲覧者属性も)。 #hcj2011

posted at 15:29:28

「HUE (Python): Beeswax (Java) で HiveQL を Web UI でアドホック集計を直接実行できる。ヒープサイズがきついので注意。HUE 運用では、Hive メタストアを MysQL レプリケーションで複製している。 #hcj2011

posted at 15:29:41

「啓蒙活動が大切。プロデューサなどでも HiveQL でアドホック集計を頻繁にしている。良くない使い方などは失敗から学んでいけばよい。今後はログ収集の改善や、推薦の本格化が課題。なうのグラフ構造を使った解析もしたい。 #hcj2011

posted at 15:32:59

「Ameba Technology Laboratory: 秋葉原ダイビルに 2011/04から開設。研究開発、実験的サービス、産学連携が目的。20-30人の勉強会スペースにも使えるよ。 #hcj2011

posted at 15:33:05

休憩時間。椅子が硬くてつらい >< #hcj2011

posted at 15:34:47

「会場の後ろにある本『Hadoop徹底入門』が売れていないみたいですよ!」.o(だってつい先日買っちゃったし >< #hcj2011

posted at 15:45:24

LT『分散ファイルシステムGfarm上での MapReduce』 #hcj2011

posted at 15:51:43

「HDFSにはファイルシステムとして使えない (POSIX日準拠, マウント不可) という問題点が。Gfarmは汎用の分散FS。HDFS に比べ、ブロック分割しないので単一ファイルへのアクセスがスケールしないし、複製作成が非同期なので複製が存在しない時間がある。 #hcj2011

posted at 15:56:02

「GlusterFS。ローカルFSを束ねて一つのFSにできる。HDFS より遅い理由は、ローカリティを利用できないからか、FUSE のオーバヘッドか。利用しやすさを考えれば十分と考えるべきか。 #hcj2011

posted at 15:59:13

『Sneak Preview of hapurus』 #hcj2011

posted at 15:59:34

「おおざっぱな性能: Grarm = HDFS > Gluster。Ceph は実用にはまだ早い。 #hcj2011

posted at 16:00:15

.o(あ、前後した #hcj2011

posted at 16:00:24

「Hadoopの問題: 最初のハードルが高い。大量セットアップ、MapReduce が理解できない、など。→ hapyrus: Hadoopアプリ実行環境付きマーケットプレースをどうぞ。クラウド環境上で動作し、基本利用は無料。アプリ購入や大量データ処理で課金。 #hcj2011

posted at 16:02:57

「ビデオデモ。ブラウザで簡単に処理ができる。3/下に一般ユーザが利用できるようになる計画。 @hapyrus_ja をよろしく! #hcj2011

posted at 16:07:06

LT『MapReduce JobTraker on MySQL』 #hcj2011

posted at 16:07:49

「丹逸子焦点がない, 任意の M/R タスクを連鎖可能, 複数ユーザ対応, Worker 以外は全て既存システムを利用 (一部見実装)。JobTracker / MySQL / Worker / Storage。 #hcj2011

posted at 16:11:05

「Hadoop のはプッシュ型。このシステムはプル型。暇なワーカがタスクを獲得。RDBMS 上で実現できる。 / 事前に作ったタスクのパーツを繋ぎ合わせることで処理を記述。タスクは Map-Map で連鎖させることもできる。 #hcj2011

posted at 16:13:33

「ストリーミングI/O。データのあるところでの処理ではない → I/O多重化。 / これから, 入力・中間・出力データの構造化と圧縮, (S3への)ログ収集・集約ツール, などなど。 #hcj2011

posted at 16:14:50

LT『Hadoop and HBase for Ranking Processing at Rakuten』 #hcj2011

posted at 16:16:22

「楽天では多言語を対象として商品をランキング。リアルタイム: big, 日週月別: very big, 年: very very big。データは mutable で扱いにくい。 #hcj2011

posted at 16:18:32

「Hadoop以前はRDBMS。Hadoopで短時間・低コストに。HBaseで巨大で mutableなデータの処理が可能に。大量データを処理するには、データの特性やアクセスパターンを理解することが重要。HW，OS資源，Hadoop設定，アプリ設計のバランスも。 #hcj2011

posted at 16:24:45

LT『Bonding とネットワークスループット』 #hcj2011

posted at 16:25:01

「性能が上がっても、ネットワークがボトルネックになって俳味がない。ネットワーク設定で性能計測してみた: {802.3ad, balane-rr} x {src-mac, src-dst-ip, src-dst-ip}。 #hcj2011

posted at 16:26:36

「3位は balance-rr + src-mac: うまく分散させられたのに NIC 1枚の時と変わらなかった。ログから分かった原因は CPU 消費。 #hcj2011

posted at 16:30:06

「2位は 802.3ad + src-mac: NIC 毎にきれいにはばらけていない。NIC 2 枚で NIC 1.3 枚分の性能でびみょー。 #hcj2011

posted at 16:30:11

「1位は 802.3ad + src-dst-ip: 1.8枚分のスループットを得られたので妥当。barance-rr よりも 802.3ad の方が総じてスループットが高かった。 #hcj2011

posted at 16:31:43

LT『Hadoop と MongoDB の美味しい関係』: 司会者がながーいタイトルを頑張って読んだら変更されていた ^^; #hcj2011

posted at 16:33:24

「Hadoop + MongoDB。健保レセプトのデータ解析に利用。データ件数 280万件/年。フォーマットが旧時代的で、可変複数行で 1データを構成し、仕様書の一部が噛みのみ, データが仕様通りになっている保証がない。 #hcj2011

posted at 16:35:37

「＼ぼくと契約して MongoDB を使ってほしいんだ／ フリーなので契約は要りません」(^^; #hcj2011

posted at 16:36:53

「Ruby-mongo で JSON 構造体に展開して MongoDB へ。元ファイルも GridFS に入れておいた。センシティブな個人データが多いので、クラウドサービスを利用できない → ローカルで処理。→ ＼ぼくと契約して Hadoop(ry／ #hcj2011

posted at 16:37:53

/ Patraqushie: Ruby + Streaming。3/1 の Mongo Tokyo で話すよ!」.o(メモとれんかった #hcj2011

posted at 16:41:06

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

posted at 16:41:14

「NTTデータでの Hadoop への取組み。BizXaaS Haddop構築運用ソリューション。Claudera と戦略的協業。教育もしていて、次のトレーニングは 4月頃。 #hcj2011

posted at 16:45:05

「システム構成: Kicstart + Puppert で環境管理、CDH で Hadoopクラスタ、Sqoop で RDMSと連携、HUE から操作、Gangla での確認など。 #hcj2011

posted at 16:45:14

「エピソード1 "ヒープメモリ枯渇": 空ファイルや小さなファイルを置かない。資源見積りが大切。監視する仕組みは重要。 #hcj2011

posted at 16:46:36

「エピソード2 "ライブラリ起因による処理不整合": ライブラリの挙動を把握していないと、出力ファイルの一部が消失するなど。台数によっては発生しないこともある。原因は、Hadoop の投機的実行による同一処理の多重実行だった。応用と基盤の境界は明確ではない。 #hcj2011

posted at 16:49:02

「エピソード3 "クラスタ利用の拡大": いろいろな要望が出て来る。その都度用意すると運用監視体制などで高コストに。複数の目的・利用者で利用する場合の注意点がある。 #hcj2011

posted at 16:50:31

「Hポイント: Hadoopクラスタの構成を利用者に意識させない, アクセス端末を制限, MR処理が順調に実行できるように, HDFS上のデータアクセスを制限。 / その他にもいろいろとある。クラスタ利用者は、他の利用者の動向を知らないという前提が必要。 #hcj2011

posted at 16:53:14

「HDFS: パーミッション (HDFS上での)明確なユーザ/グループ管理, ファイルアクセス権限の厳密化, 共有領域の設定), クォータ (ファイル数やディレクトリ数や格納できるサイズをディレクトリ単位で設定, 最大複製数や最小ブロックサイズの調整), #hcj2011

posted at 16:57:26

「続: HDFS内部通信に関するポリシー (クライアント間通信, クライアント-データノード間通信), 認証・認可 (Kerberos や SASL での認証, Hue などで Hadoop前面での認証)。 #hcj2011

posted at 16:59:11

「MapRedue: スケジューラによる複数ユーザのジョブ制御 (キュー単位/プール単位でのリソース配分 / ジョブが占有される余地はある) #hcj2011

posted at 17:01:16

「続: MR内部通信に関するポリシー (クライアント関係の通信), MRに関する ACL設定 (有効化，キューに投入できるユーザ/グループの指定，ジョブの優先度や停止などの制御，ジョブの確認 / FiarScheduler はプール単位でのACL設定は未対応)。 #hcj2011

posted at 17:09:14

「子プロセスの JVMオプション制御, スケジューラ改良, 占有資源と共有資源の制御, 物理ディスク対策, ユーザとグループ。Hadoop クラスタ利用者に対するルールを定めることも大切。 #hcj2011

posted at 17:09:38

「Q.Hadoop にマルチユーザ対応を求めるのは筋が悪いのでは。A.運用効率の問題があって、試みの一つとして試しにマルチユーザ対応させてみたという位置付けということで解釈してほしい。 #hcj2011

posted at 17:11:59

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

posted at 17:12:10

「DC移行で確保した余剰サーバ35台で検証環境。新規23台で実運用環境。周辺は, Hiveを利用開始 (メタストアは PgSQLでUDFでの拡張性が良い), HBaseも準備中。 / メルマガよう推薦計算バッチや相場表型のクロス分析など、八つの取組みを実施中。 #hcj2011

posted at 17:16:22

「分析屋とシステム屋が協働: 仮説検証・分析→ログデータ取得, 手なり分析不可→分析サポート。目的は同じだが視座が異なることがある。e.g. R vs SQL。→ 道具を共通化する。まず触れるようにし、共通言語を以って共通解釈を可能にする。 #hcj2011

posted at 17:19:55

物事の関係を表現するのは、たいていなんでもグラフ構造と思っていいですね。特殊でなく、むしろ一般的。 #hcj2011

posted at 17:22:53

「KNIME: データ処理ロジックをビジュアルに組み立てられるツール。アニメーションで状況確認できる。ノード間でデータが移送される。 #hcj2011

posted at 17:23:01

「長所: クラスタリングなどのマイニング系機能が充実。処理を Javaでスクリプト的にもかける。 短所: SQL で 1文でかけるものも複数ノードで実現する必要がある。情報が英語。 #hcj2011

posted at 17:25:41

「Hadoopとの連携: 「これまでの分析設計: 分析前にやることが多い, 非力なPCを使うことも多数。→ 狙いたい分析設計: 前処理はサーバ環境で処理 (Hadoop へ), 手元のPCでは分析設計に注力。 #hcj2011

posted at 17:27:27

@nokuno 一般のグラフ構造と比べれば狭くなるけど、DAGで書ける問題のクラスはそれなりに広い気がするですよ。 #hcj2011

posted at 17:31:20

有向・非巡回という制限ゆえに表現できないモデルがあるけれど、その制約ゆえに扱いやすい問題に落とせるという部分もあるね。 / 一般に、表現力と扱いやすさはトレードオフの関係にあるのかしら。 #hcj2011

posted at 17:36:26

.o(椅子が不評すぎるたいむらいん……。(^^; #hcj2011

posted at 17:37:37

分析屋とシステム屋に限らず、対象領域が異なる人の間には、多かれ少なかれ溝が出来やすいよね…… #hcj2011

posted at 17:43:48

HCJ2011 終了。このあと懇親会。 #hcj2011

posted at 17:44:50

懇親会の二次会(三次会?)を途中離脱して帰宅中。今日も、あれやこれやな話が聞けて楽しゅうございました。2/25 も顔を出す予定なので、みなさまよろしくですよー ^^)/ #hcj2011

posted at 23:46:54