Hadoop Conference Japan 2011 で取得してきたメモを共有します。
- 日時: 2011年2月22日（火） 11:15-18:00 （受付開始：10:45）
- 会場: NTTデータ本社ビル内 カンファレンスルーム
豊洲センタービル （東京メトロ有楽町線 改札出てすぐ）
http://www.nttdata.co.jp/corporate/profile/outline/map.html
11:30-12:05 『Hadoop on クラウド / Amazon Elastic MapReduceの真価』（Amazon Web Services, Jeff Barr）
Background
- Evangelist
- twitter: @jeffbarr
- Web site in the cloud -> transfer to japanese.
What is the big data.
- Doesnt refer just to volume
- You can benefit from Big data infrastructure without having a ton of data.
- いかにつかっていくか？
- 早急に迅速な結果がほしいという課題
Elastic MR overview
- EC2, S3 の上の階層
- 用意にセキュアな環境で大量データを使用できる
- 数百TBのデータを扱える
- Hadoop をつかえるプラットフォームも。
- Launch and monitor job flows
- WAS management console
- command line interface
- REST API
- S3 にUpload
- Elastic MRにジョブフローを
- ジョブが完了するとS3からデータを取得できる
- MUCK
- なんでElastic MRを使うのか？
- どろくさい作業から顧客を開放する
- Hard to manage compute clusters
- Hard to tune Hadoop
- Hard to monitor running job flows
- Hard to debug Hadoop jobs
- Hadoop issues prevent smooth operation in the cloud.
- さまざまな問題解決のためにつかう
- Ads
- log analysis
- DWH
- Bio-interface
- Financial simulation
- Web Indexing
- Datamining and BI
- HW requirement for use case
- Data of IO intensive m1/m2 instances
- DWH
- Data mining
- -> click stream, logs, events, etc.
- Compute or IO intensive (c1,cc1/HPC instances)
Example Use case
- Best Buy came to Razorfish
- 3.5 billion records, 71 million unique cookies, 1.78 million targeted ads required per day
- Leveraged AWS and Elastic MR
- 100 node cluster on demand
- Processing time dropped from 2+ day to 8 hours.
- Increased ROAS by 500%
- 財務のあたりがでてくる
- 大量データを扱うことの意義
- What is MR?
- 技術者なら知っておくべき標準知識になってきた
- take input data
- break into sub-problems
- distribute to worker nodes
- worker nodes process sub problems in parallel
- take output of worker nodes and reduce to answer
- →Image
- →Elastic MRのImage
- 大量データを扱うためには、とても有用
- スケールアウトすることのメリットを享受できる
- S3 に Log data をつっこむ
- Step1 prepare the job flow
- Step2 select you use your MR program or use Sample program
- Step3 Use sample program this time and, sample program use apache Pig language. Input input-data name and suggest where to output.
- Step4 Enter the infra specifications.
- Step5 You can use the startup tutorial.
- Step6 Confirm your suggestions.
- Step7 Committing MR jobs. You can commit the job in 100 or more jobs in parrallel
- Notes/ attributes
- mapper and Reducer in java JAR file
- scale as large as needed
- data
- processing
- add nodes
- Hadoop+R also supported on RHIPE
QA
- HBase support も考えていく
- Debug 時に ssh のコネクションができるようになっている
- EMRをつかうことでインプット、アウトプット双方のデータをみることができる
- 株式市場の予測を行うことができる
- シミュレーション
- 課金のしかた
- 10分で終わっても1時間の課金
- 分単位での課金体系はできないのか？
- 今現在は、時間単位で付加価値がでるお客様につかってもらうことを考えていた
12:05 - 12:40 『MapReduceによる大規模データを利用した機械学習』（株式会社Preferred Infrastructure, 岡野原 大輔）
自己紹介
- 専門分野、自然言語処理
- 機械学習、統計処理、
- 圧縮データ
- 有用な技術を新規開発
MRと機械学習
- 機械学習
- Wikipediaの定義の引用
- 様々な分野の問題に利用可能
- レコメンデーション、クラスタリング、分類、市場予測…
- データがあるところ、どこでもつかえる
- タスクと手法の分離
- 分野に依存しないような抽象化されたデータ形式
- 様々な手法、理論を適用可能になる(分類、クラスタリング)
- 機会学習とMR
- データの急激な増加
- 2009 0.8ZB
- 2020 35ZB
- →機会学習の分散並列化は必須
- →機会学習がMR向けでなくても、分散並列処理をいちからつくるよりはるかに生産的
- Apache Mahout
- Hadoop上でうごく機械学習ライブラリ
- スケーラブルであることを最優先
- →100台超でもうごくように
- Apacheプロジェクトでも活発に
- →枯れていない
- サポートする技術
- クラスタリング
- パターンマイニング
- 文字列データ処理
- 分類
- →ロジスティック回帰
- 行列演算
- →特異値分解、主成分分析
- Mahoutの感想
- 数台から数百台でうごかしてスケールすることを確認
- 各挙動についてドキュメントは不足
- →詳細はコードをみる必要があった
大規模並列分散処理の最前線
- Google、MS、Yahooなどを中心に
- より強力なモデルを利用した機械学習
- →高精度で理論的な保証のある手法
- グラフィカルモデル
- 確率変数を頂点、変数間の依存関係を枝としたグラフ構造
- →言語処理、情報抽出、音声認識、画像解析、遺伝子解析、
- 構造予測で利用
- グラフィカルモデルの推論はいっぱんに困難、にもかかわらずデータは肥大化
- →さまざまな並列化アルゴリズムが提案されつつある
- GraphLab
- Residual Splash
- グラフィカルモデルの分散並列による結果
- 共参照解析：2つの言及は同じ対象をしめしているか？
- 数値最適化の並列分散化
- 多くの機械学習は数値最適化問題に帰着する
- →MRを使えば簡単に実装することができると考えた
- →4つの方法
- x 1 Parameter Mixture
- x 2 Distributed Gradient
- x 3 Asynchronous Update
- o 4 Iterative Parameter Mixture
- 実験1 S.Petrov, LCCC 2010
- 2 S.Petrov, LCCC 2010
今後注目の技術
- Dremel:
- 対話的な大規模データ解析基盤
- クエリ言語はSQL
- 1兆のデータに対するアドホッククエリの結果が数秒で得られる
- 各データは繰り返しありのツリー構造
- →JSONのような
- 列指向のデータ格納
- 列指向DBの考えをツリー構造に応用
- 圧縮レコードの復元
- クエリに関係するフィールドだけを復元するオートマンが形成される
- クエリー処理アーキテクチャ
- ツリー構造
- クエリーは根から葉に向かって広がる
- 結果は葉から根に
- 実験結果
- 各単語の出現回数を数える
- 一部のノードで時間がかかる
- 列指向＋必要な列だけ復元＋ツリー構造クエリーサーバで大幅な高速化が可能
まとめ
- 機械学習＋大規模分散並列処理は実用的
- Mahoutを利用して機械学習を試せる
- MRの補助にDremel
- →将来的には、高速な推論、分類が求められてくる
- MRは、レイテンシーが遅い
- 特定カラムだけ取得するのは苦手
- 教師ありと教師なしのデータ
13:40-14:15 『モバゲーの大規模データマイニング基盤におけるHadoop活用』（株式会社ディー・エヌ・エー, 濱田 晃一）
自己紹介
- データマイニング、機械学習
- 理論物理博士
- 文部大臣に褒められた
- 数理解析手法の実ビジネスへの適用
- アカデミックの領域にも貢献
- DeNAでソーシャルメディアのデータマイニング
ソーシャルプロットフォームとしてのモバゲータウン
- モバイルソーシャルプラットフォーム
- 2300万人以上のユーザー数
- 1日20億を超える行動情報
- →ソーシャルの中でも群を抜く
- 独自の位置づけ、高い収益性
- →エンターテイメント性、楽しさのマイニング
- →高いARPU
- 興味を軸としたソーシャルグラフ
- こういったことに興味がある
- 興味があることをやったほうが楽しい
- 個々の興味にあったサービスを提供することに価値
大規模データマイニング基盤
- データマイニングおよび機械学習
- DataMining Infrastructure
- KPI 定常算出、共有
- 経営判断、
- サービスを洗練を行うためのデータマイニングの実行
- データマイニング、機械学習 結果のサービス活用→より楽しめるサービスへ、どういう人か？何をしたら楽しんでくれるか
- Hadoopにデータを格納→Hadoopの上で全ての解析が行われるようにされている
- Pigも使用
- Zibraでスキーマ管理
- ダイレクトにMRを書くこともしている→時系列データの解析
- Perl、Java
- R も用いる
- Mahoutの活用→サービスに活用
- DeNA Social MA
- Lucene
- DeNA Data Mining Libraries
- Hadoop Tuning
- NW、HWに合わせたパラメタチューニング
- MR間のTemporary圧縮
- Pig
- 環境にあわせた Partitionar 実装の最適化
- キー値による効率的な分散がなされるように。
- 多段MR間のTemporary圧縮IO負荷低減ん
- 独自UDF→日時処理、文字列処理
- 共通ログ→loader
- Mahout
- 各種Mahout用データ変換
楽しさのマイニング
- 1日20億超の行動情報
- 統計的有意
- データマイニング、機械学習による有意義な情報を得られる
- 多くの人への還元
- 多くのユーザー体験へ還元できる
- 感情がわかる詳細行動情報
- ソーシャルに特化したことにより、感情に直結する情報を得られるを得られるようになった。
- 楽しさを喚起するにはどういったパターンがあるのか
- 中毒性
- 楽しさのデータマイニング
- 日々の行動の法則をみていく
- どういった行動パターンがあったときに継続性が認められるのか？
- 今、飽きそうな人達はどういう人なのか？
- Pattern mining
- Clustering
- Classification
- Regression
- Recommendation
- timeseriesanalysis
- statistical analysys
- 楽しさの行動パターン
- 夢中になるきっかけ
- →夢中になる行動を体験してもらう
- 楽しんでサービス継続している行動特徴
- →楽しさのパターンを高頻度発生。より楽しいサービス体験
- →楽しさのパターンをサービス初期で体験、楽しさを理解。
- やめてしまう状況パターン
- 飽き始めるきっかけ・不快な状況
- →やめるきっかけを発生させないようにする
- 飽き始めたユーザーの予測・判別
- →新鮮、斬新な体験を提供する
- →他の楽しみ方の提供
- 興味のあるゲーム、ユーザーと出会えるプラットフォームへ
- ゲームレコメンデーション
- ユーザーレコメンデーション
- →ソーシャルグラフ解析、機械学習、最適化を組み合わせ
- 健全なプラットフォームへ
- 不正書き込みの判別
- 年齢詐称の判別
- ユーザーの声によるサービス洗練
- ソーシャルコミュニケーションのテキストマイニング
- 迅速なサービス洗練
- 解析結果を反映した数時間〜数日スパンで迅速なサービス洗練
- コンサルの場合は、提案しても反映してもらえるかはお客様次第、自社サービスの強み、面白み。
- サービスを動的に変化していく
- DeNAの風土
統一行動記述
- ログフォーマットを統一する
- データがすべてHadoop上にあるということのメリット
- 大規模サービスでよく生じる問題
- サービスごとにログフォーマットが異なる
- →何を解析すればよいかわからない
- →パラメタのあたいの意味がわからない
- ログの場所がバラバラ・分散
- どこにあるかわからない
- 解析時間より収集に時間がかかってしまっている
- データマイニング、機械学習よりもログ収集、基礎集計作業がメインになってしまう
- データマイニング、機械学習、活用までできない
- 統一行動記述で解決
- 統一スキーマ
- データマイニング、機械学習実装の再利用が可能、
- サービス横断歩行
- 学習コストの低減
- データ形式・値の意味を調べる必要がない
- Hadoopにすべてのログがある
- データ探索、収集時間ゼロ
- 解析したいデータがすべてのある
- ↓
- 大規模データ処理技術
- データマイニング、機械学習それぞれ技術が利用できる
世界へ
- ソーシャルプラットフォームの世界展開
- デバイスによらないサービス展開・授受
- サムスン電子 mobage 搭載 →世界の1/3のシェア
14:15-14:50 『Enterprise Batch Processing Framework for Hadoop』（ウルシステムズ株式会社, 神林 飛志）
自己紹介
- 基幹系システム
- 会社の方針とは関係のない個人的意見
Asakusa
- Hadoopで基幹系バッチを行うためのプラットフォーム
- 何がうれしいか
- バッチ処理時間の短縮
- サービスレベルがあがる、価値があがる
- 年次、週次を日次に
- 夜間バッチなど必要ない
- 基幹系バッチとはどんなものか
- →Image
- →複雑、多層構造になっていることが普通
- →ゆえに本当はHadoopでやるのはつらい
- 基幹系バッチ、BIと比べると
- データの種類が多い
- 処理の組み合わせは単純
- データフローは複雑
- 割と設計が重要
- なにが足りないのか
- MRには不足ない
- 自作MR
- 謹製Writable
- 根性デバッグ
- 大規模の開発方法論はない
- Pig、Hiveでも足りない
- ↓
- 素のままで基幹系をMRするのは、愚行。
- Asakusa は Pig、Hiveのさらに上層にあるものだと思ってもらえばよい。
- フルスタック型
- OSS
- DAGベースの多層DSL構造
- →Hadoopの外側でトランザクション管理も可能
- MRコンパイラ
- ModelGenerator
- →テストが抜けてしまう欠点を補う
- 外部との一体統合
- →Import、export
- 構造化を行うための多層DSL
- 3層のDSL
- Batch
- Flow
- Operator
- ビルディングブロックの構成により処理フローの記述
- トランザクション管理〜ロールバック制御
- TXをDSLで指定することで、
- データをDBに保全する
- HDFSはぶっこわれる前提、キャッシュと思ってる
- 開発方法論
- プロセスの設計
- DAGベース
- 構造化手法
- SPF演算子
- GRASP原則の適用
- データモデルの設計
- 静的なモデルを渡り歩くスタイル
- Join
- DSLの記述例
- Batch
- とりあえずなにもなくてもかける
- フローの組み合わせを記述していく
- Flow
- フローを記述していく
- Javaで記述
- MRは知らなくてもかけてしまう
- Operator DSL
- 最下層DSL
- DAGでいうと頂点にあたる部分の記述
- ここはMRを知っている人が書いたほうがよい
- Batch
- Defaultで用意されているDSLの紹介
- Checkpoint これを実行するとトランザクションがきれる
- MR(AShigel)コンパイラ
- @ashigeru
- 日本人若手ハッカーによるMRコンパイラ
- ステージングコンパイラ
- DSLを順番にコンパイルする
- Asakusa 実行構成のイメージ
- TRX制御 バウンダリー管理
- Model Generator
- Hadoop IOはめんどくさい
- Table Viewをつくると自動的に Classができる
- Testツール
- JUnit から実行可能
- 外部連携
- Default は Sqoop
- →プロジェクトではより高性能のものを使っている
- 運用のためのスクリプトが自動生成される
- Monkey Magic用の rb
- 運用ツール
- 現時点ではDefaultは Monkey Magic
- ASAKUSA 自体には experimental shell script を準備
- ERP on Hadoop
- を現在つくっている
- OSS化
- 3月目標
- β版使用希望者は連絡まつとのこと
- 数学しらなくても Hadoop つかえるようにすることが目標。
- なんと言ってもお金になる。
- アイデア勝負である。
- マーケットはBIよりも大きい
- クラウド時代
- インフラ
- →Amazonでいいんじゃないの？
- ソフト
- 使い方
- Hackerな人
- 中身をみてくれ
- 業務屋
- プロトを自分で作れる
- 考え方を検証できる
- SIer
- 大規模開発が可能
- ツールがそろっている
- 工数の見積もりもできる
- Hadoopをつかえる人間が3人いれば通常の見積もりができるつくり
- Asakusa Scala DSL
- @asami224 がプロトタイピング
- 文字コード問題
- これからフレームワークふくめて対策をこうじていく
14:50〜15:25 『Hiveを用いたAmebaサービスのログ解析共通基盤』（株式会社サイバーエージェント, 福田 一郎）
- エンジニアではない人がいかにデータを解析するのか？
自己紹介
-
- @toutou
アメーバについて
- 数字
- 20-30代女性が使用
- 1300万人ユーザー
- pv 200億 per month
- スマートフォンユーザー増えている
- Pigg
- 600万人
- ARPPU 2121 yen
- Amebaサービス
- ブログ
- なう
- Pigg
- アメーバピグ
- Flash
- アバターサービス
- Android サービス開始
- モバイルゲーム
- AmebaとHadoop
- 使用実績
- アメーバピグ → HDFS
- アクセス解析サービス
- pico → Amazon EMR ＆ Pig
ログ解析基盤 Patriot
- Hadoop Conference Japan 2009 で Hadoop を知る
- 統合解析システムで使うアイデア起案
- Go
- 201003末、本格検証開始
- 標準的なサービス開発体制
- プロデューサー
- アプリエンジニア
- インフラエンジニア
- 課金担当
- 会員獲得担当
- 問題点
- 各サービスごとに解析
- ログデータの肥大化
- 解析まで手が回らない
- 目的
- Amebaサービス全体の統合的な現状把握
- ログの集約→HDFS
- ログの集計→MR
- ログの構造化→Hive
- 集計結果の表示→ Patriot Web UI
- Hive
- Hadoopのサブプロジェクト
- HiveQL
- →SQL like に MR
- MetastoreにMySQL
- データストア
- テーブル
- Partition
- Bucket
- データモデル
- Primitive
- Complex
- DDL
- create table を使う
- データの load
- dfs command の mv や put
- HiveQL
- UDF
- UDAF
- count, sum, max, min, avg
- percentile
- Hiveのwiki
- SerDe
- serialization / deserialization
- カラムの区切り
- 解析のフロー
- ログ転送、ログ整形、サマリー化、DB格納、Web参照
- システム構成
- Master Slave 20 台ほど
- CDH3
- ext JS3.2.1
- HUE 1.0.1
- Nagios, Ganglia, Puppet
- Hinemos 3.2
- Namenode は NFSでバックアップ
- ファイルフォーマット
- gzip, bzip, LZO
- Hadoopクラスタには正規表現で必要ものだけをフィルタリングしていれる
- ゲーム関連の集計
- モバイルゲーム
- →ゲームごとにパーティションをきる
- 運用上の数字
- ログ容量
- Pig、4.5GB
- タレントブログ 5.5GB
- 処理時間 3-4時間
- どれだけログインしてくれているかを統計
- 属性のレポート
- →タレントブログ解析、一ヶ月ほどの工期
- Beeswax
- HiveをWebUIから直接たたける
- アドホックな集計
- ヒープサイズには注意
- Pythonベース
- 実行計画を保持してしまう
- Bugかもしれない
- HUEの運用
- Hive Metastore、MySQLのレプリケーションで冗長化
- 啓蒙活動
- 非エンジニアでも大量データを活用できるプラットフォームを提供。
- 集計サマリーをいつでも確認できる。
- Webアプリ上でHiveQLがたたける
- 今後の展開
- HBase
- →CDH3b4の登場待ち
- ログ収集の改善
- →Flume
- レコメンデーションの本格化
- なうのグラフ解析
- Ameba Techinology Laboratory
- →秋葉原
- →20110401 から
- →勉強会スペースも提供する
15:40-16:30 ライトニングトーク
分散ファイルシステム Gfarm 上での Hadoop MR
- shun0102@gmail.com
- あとでslide は uploadする
- HDFS問題点
- POSIXに準拠してない
- 他のFilesystemをつかいたいニーズはあるはず
- Gfram
- GlasterFS etc...
- Gfram
- 汎用的な分散ファイルシステム
- メタデータサーバ1台
- ビジネスでも使われるようになってきた
- HDFSと比較した欠点
- ブロック分割しない
- 単一ファイルへのアクセスがスケールしない
- 複製作成が非同期
- レプリカがひとつしかない時間がある
- 他のファイルシステムを使う方法
- JNIのlayerをはさむか、マウントしてアクセス
- HDFS vs Gfarm
- 書き込み優位、読み込み同等
- メモリにのる分、性能差がでた
- GlasterFS
- ローカルファイルシステム
- GlasterFS vs HDFS
- GlasterFSのほうが遅い結果
- ローカリティを利用できないから？
- FUSEのオーバーヘッド？
- まとめ
- GframはHDFSと同等
- GlasterFS は HDFS より劣るが仕様からみたらよいといえる
- Cephはまだ実用ベースではない
Sneak Preview of hapyrus
- 自己紹介
- @fujibee
- 藤川幸一
- Hadoop開発の問題点
- 最初の敷居が高い
- サーバ、サービスの大量データセットアップ
- MR
- どれだけ工数がかかるのか
- 最初の敷居が高い
- hapyrus
- Hadoop アプリの実行環境付きのホスティングサービス
- マーケットプレイス
- クラウド環境上で動作
- 基本利用は無料
- アプリの購入で課金
- デモビデオ
- ユーザー登録と実行だけですむ
- hapyrus.com
MySQLにMRジョブトラッカを実装する
- 自己紹介
- 古橋さん、kumofs
- mysqlをJobTrackerにつかったAWSむけ
- 単一障害点がない
- MapタスクやReduceタスクを連鎖可能
- マルチユーザー対応
- Worker以外はすべて既存のシステムを利用
- MySQL は Database。comやAmazon RDSを使えばいいと考えている
- タスクの取り出し
- Taskテーブルが重要
- 比較
- HadoopのJobTrackerと比べて
- HadoopのJobTrackerはPush型
- このシステムはPull型
- タスクの連鎖
- Code、タスクとタスクの間をつなぐ
- MapとReduceをさまざまなパーツとして組み合わせることができるようになる
- ストリーミングIO
- データのあるところの処理ではない
- IOと計算を多重化して遅延を隠蔽
- Future Work
- 入力、中間、出力データの構造化と圧縮
- ログの集約用のツール
- →S3などを使えばよいが、データを集める処理時間が必要
Hadoop and HBase for ranking processing at rakuten
- @uprush
- 8000 ジャンルのランキングを集計
- 大量のデータ
- 基幹軸
- →年次、月次、日次
- →リアルタイムランキング
- すべてのデータが変更される可能性があるという特徴
- ログデータではない
- Hadoop前はRDBMS
- Hadoopをつかい純粋なJavaのMRジョブで処理
- Hadoop、HBAseをつかった効用
- 40倍のスピードで処理できるようになっていた
- DBに一度格納してからHadoopにのせていたがDBがボトルネックに。
- HBaseを使うことで最初からHBaseにいれられるようになった
- 15k rows insert per sec
- データの特徴を事前に知ることが大切
- データの分布状況を把握し間違えるとデータがかたよりスケールしなくなる
- バランス
- HW
- OS
- Hadoop configuration
- application design
Bondingとネットワークスループット
- Bondingの設定を変えてスループットを測ってみた
- どういったネットワークの設定をかえるとスループットがでるのか
- server側設定;
- 802.3ad
- balancer-rr
- balancer側設定;
- src-mac
- src-dst-ip
- src-dst-mac
- NIC x1
- 110MB/sec = 880 Mbps
- NIC x2 にして、Bonding の設定を変えていく
- 性能Top3の結果
- 3rd. balancer-rr & src-mac
- balancer-rr のスループットが低い
- 大量に出力し、CPU使用率を確認する
- 2nd. 802.3ad & src-mac
- 150Mbps くらい
- 設定を調整
- 1st. 802.3ad & src-dst-ip
- 3rd. balancer-rr & src-mac
HadoopでMongoDBの美味しい関係
- @yuunyyan_m
- meta programmer
- product manager
- MongoDB 日本語翻訳
- Hadoop＋MongoDB
- 健保レセプトのデータ解析に利用
- 280万件 per year
- フォーマットがすごく旧時代的
- 可変複数行で1データが構成
- Ruby-mongo をつかってJSONの構造体に展開してMongoDBに保存
- 元ファイルもGridFSにいれて保存することにした
- レセプトの集計データがほしい
- トップレベルの個人データなのでEC2などの外部PCには保存できない
- MongoDBからHadoopにデータをどうするのか
- MongoDB
- GridfsInputFormat.class
- Ruby+Streaming=Patraqushie
- 3/1 のMongo Tokyoで詳しく
16:30-17:05 『マルチユーザーでHadoop環境を利用するためのポイント』（株式会社NTTデータ, 山下 真一）
自己紹介
- OSS
- PostgreSQL
- Tomcat
- HeartBeat
- Ultramonkey
- 最近は、Hadoop
- 今後の増え続けるデータを処理するための案件
NTTデータにおけるHadoopのとりくみ
- BizXaas
- Clouderaとの提携
- サブスクリプション販売 Hadoop Distribution
- 教育トレーニング
- サポート
- 技術開発
- 日頃利用するHadoop環境
- kickstart + puppert unnyoukanh
- CDH
- Sqoop
- Hue
- Ganglia
Hadoopにかんするエピソード
- マスターヒープメモリ枯渇
- 小規模クラスタだとあまりおこらないが
- 100台規模でおこった
- →からファイルや小さなファイルはおかない
- →見積もりが大切
- →→ヒープサイズ、GC実行方式、OSレベルでの設定
- →モニタリングする仕組みが重要
- ライブラリ起因による処理の不整合
- これもクラスタ規模が小さいと起こりにくい
- MRでとあるライブラリと組み合わせて実行したら出力ファイルの中身が消えていた
- 原因
- Hadoopの投機的実行によるおなじ処理の多重実行
- Hadoopはアプリと基盤の境界があいまい、両方をみれることが大切
- Hadoopクラスタ利活用の拡大
- Hadoopクラスタを複数の目的・利用者で利用する場合の注意点や対策について考える
- 都度用意は妥当ではない、監視の仕組みもかんがえないといけない
- Hadoopをマルチユーザーで利用するために考える
- 前提
- Hadoopクラスタの構成を意識させない
- Hadoopクラスタへのアクセス端末を制限
- MR処理
- HDFS上のデータアクセス制限
- HDFS
- だれかにかってにしようされるとか
- だれかによってメタ情報が利用される
- 誰かがかってにファイルはを操作する
- MR
- だれかの処理がおそろしく時間かかる
- だれかが優先度
- その他
- だれが何をしているのか筒抜け
- だれがどんなデータを格納しているか筒抜け
- 対策案
- Hadoopコマンドを直接実行させない→Hue
- HadoopクライアントをかいさないとHadoopにアクセスできない
- Hadoopに限られた人しかアクセスできない
- HDFSの構造を意識させない
- HadoopのWebインターフェイスにアクセスさせない
- 監査
- 前提
みんなでゾウにのろう
- HDFS
- パーミッション
- →supergroupは使わない
- HDFS上での明確なユーザーグループ定義
- →750、640、Sticky bit、をたてるなど
- 共有領域の設定
- クオータ
- ファイル数やディレクトリ数
- 格納できるサイズ制限
- HDFSの内部通信に関するポリシー
- hadoop-policy.xml
- client DFS Client
- Client Datanode
- 認証認可
- kerberos
- Hue
- MRとしてやらないといけないこと
- スケジューラによる複数ユーザーのジョブ制御
- capacity task scheduler
- キュー単位のリソース配分、
- キュー内はFIFO
- fair task scheduler
- プール単位のリソース配分
- プール内のジョブは設定状況により公平にリソースを割り当てられる
- ACLとの組み合わせ
- MR の内部通信に関するポリシー
- hadoop-policy.xml
- security.job.submission.protocol.acl
- MR に関するACL設定
- mapred.acls.enabled
もっと上手にゾウにのるために
- ChildプロセスのJVMオプションの制御→想定しないオプションが指定されたらそもそも起動させない
- スケジューラ改良→Contribute版スケジューラのスループット向上が必要
- 占有資源と共有資源の制御
- 物理ディスク対策→暗号化
- ユーザーとグループ→LDAP
- Hadoop クラスタの利用者がわに対するルールを明確に定めることが必要。
- できること
- ユーザーグループの管理
- パーミッション
- クオータ
- クライアントクラスタ間の内部通信制御
- ジョブスケジューリング
- ジョブ単位のアクセスコントロール
- クライアントクラスタ間の内部通信
- 認証認可
- 今後に期待
- スケジューラの改良
- パーミッションの細かな制御
- リミッターの追加改良 HDFS、MapReduceともに
- 占有資源と共有資源の考え方
17:05-17:40 『Hadoopと分析統計ソフトKNIMEを用いた効率的データ活用』（株式会社リクルート, 中野 猛）
リクルートの体制とHadoopの活用
- 社内体制
- カンパニー制
- 横断的マーケティング＆テクノロジーユニット
- インフラ担当グループのアプリ立ち寄りいち
- Hadoop環境
- DC移行で確保した余剰35台のマシン
- 新規サーバ23台
- Hive利用開始
- Metastore は PostgreSQL
- UDFの拡張に魅力
- HBaseの利用も検討中
- 半リアルタイムのデータ集計
- データ設計がむずかしい
データの活用にむけて
- 8つのとりくみ
- メルマガ用リコメンド計算バッチの処理時間短縮
- 相場表型のクロス分析などなど
- 取り組みの分類
- 既存の処理を高速化する
- 今、不可能とされていた処理の実現
- 前提を変えて挑戦
- 分析屋とシステム屋
- 一緒に活動している
- ロジックを設計→システムに実装
- 仮説を検証、分析ーログデータ取得
- てなりでは分析不可能
- 人ベースの話
- 視線を合わせる
- お互いに正義とするところがことなる
- SQL的に、R言語的に考えるかたち
- 物ベースの話
- まず触ってもらえるようにする
- 共通の言語素子となりお互い解釈が可能に
- 分析屋さんの商用ツールは高価
KNIMEとは
- データの処理ロジックをビジュアルに組み立てることの出来いるツール
- →分析屋さんのツール
- 処理ロジックはノードを繋ぐことで組み立てることで行う
- icon
- →Joiner, Cell Replacer
- アニメーションで実行の進捗状況がわかる
- ノード間をデータが遷移
- 発信元
- ドイツのコンスタンツ大学
- 日本でもサポートあり
- 類似品
- Spoon(Pentaho)/Orange
- KNIMEの検討
- 商用アプリから2つの処理を移行
- よいところ
- クラスタリング等マイニング系充実
- 処理をJavaでスクリプト的に記述も可能
- そうでもないところ
- SQLは結局必要
Hadoop＋KNIME
- これまでの分析
- データを集めてくるだけで疲弊する
- 連携させる意味
- 前処理はサーバ環境で
- 一箇所にあつまったデータを即座に利用
- HiveをつかってJDBCで接続
- 一部のマスターは手元で編集
- モジュールの作り方
- メタノード→ノードをくみあわせ
- JavaSnippet
- Plugin SDKをつかってノードを作成
- Modelクラスのexecuteメソッドに処理を記述
- テーブル型で結果をもどす
- 連携モジュール
- 標準jdbcノードはHive接続が△
- 独自実装
- HiveReader
- HiveWriter
- HiveLoader
- HiveConnector
- HiveConExecuter
- HiveConReader
- その他連携の可能性
- 大規模データの試行錯誤にどう対応するか
- RESTでのシステム連携
- AWSにつなげる？
まとめ
- ビジュアル的に処理ロジックを考える
- Hadoopを利用したデータの活用
- →分析屋とシステム屋の距離を縮める
- →分析＆設計の共有を楽にする
![【楽天ブックスならいつでも送料無料】Hadoop徹底入門 [ 太田一樹 ]](http://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/2335/9784798122335.jpg?_ex=128x128 "【楽天ブックスならいつでも送料無料】Hadoop徹底入門 [ 太田一樹 ]")
