hadoop hack night vol. 2
DESCRIPTION
新たな情報インフラとしてのHadoopの活用TRANSCRIPT
新たな情報インフラとしてのHadoopの活用
株式会社リッテル 上席研究員
清田 陽司
(兼東京大学情報基盤センター
学術情報研究部門 助教)Twitter: @kiyota_yoji
技術評論社／ヤフー共催Hadoop Hack Night Vol. 22010年8月4日
Hadoop活用の壁
• 実績がまだまだ少ない
• ○○という機能がない• ファイルシステムとして備えるべき機能（アクセス権制御など)
• マスタサーバの多重化
• Hadoopってよくわからないんだけど• RDBMSとの違いは？
• どういう処理でメリットがあるの？
• Hadoopってクラウドなの？(←そもそもクラウドって何よ？)
Agenda
• Hadoopをインフラとして理解する
• Hadoopの使いどころ
– RDBMS、分散KVSとの使い分け
• 開発事例紹介
– Hadoopが効果を発揮する用途
– 開発手法
Hadoopを理解するポイント
インフラとして理解する
• シンプルなインタフェース＋複雑な中身
– ブラックボックスとしてとらえる
• なくてはならない存在
– なぜ必要とされているかを理解する
• 現実的な「割り切り」
– ○○という機能がない理由を理解する
ひねる
水が出る
水を捨てる
課金
蛇口
流し
請求書
ひねる
水が出る
水を捨てる
課金
蛇口
流し
請求書メータ検針
料金集計システム
メータ 水道管 配水施設 浄水施設 取水施設
河川
ダム
水漏れの防止
水質の管理 水位の管理水圧のコントロール
水利権の調整渇水への対処発電・治水との
調整など
インタフェース 中身
マンホール
下水管 沈砂池 沈殿池
河川
詰まりの防止メンテナンス
除砂
汚泥処理
消毒施設
水質の管理
Hadoopスレーブサーバ#N
Hadoopスレーブサーバ#2
Hadoopスレーブサーバ#1
Hadoopマスタサーバ
HDFSAPI
MapReduce
API
NameNodeデーモン
JobTrackerデーモン
DataNodeデーモン
TaskTrackerデーモン
子JVM map/reduce
子JVM map/reduce
HDFSストレージ
ファイルの書き込み
ファイルの読み込み
ファイルの管理(複製、移動、削除、…)
DataNodeデーモン
TaskTrackerデーモン
子JVM map/reduce
子JVM map/reduce
HDFSストレージ
DataNodeデーモン
TaskTrackerデーモン
子JVM map/reduce
子JVM map/reduce
HDFSストレージ
・・・
バッチ処理ジョブの投入
バッチ処理ジョブの状態取得
バッチ処理ジョブの管理(キャンセル、優先度設定、…)
インタフェース 中身
データブロックの送受信NameNodeへの状態通知
HDFSの全体統括データブロックの管理
異常発生時の復元処理
Mapタスク/Reduceタスクの起動JobTrackerへの状態通知
バッチ処理ジョブの進行状況管理Mapタスク/Reduceタスクの割り振り
異常発生時のバックアップタスク実行指示
Hadoopのインタフェースと中身
ブラックボックスとしてとらえる
• インタフェースはシンプル
– ファイルシステム系(HDFS)– ジョブ管理系(MapReduce)
• 中身はイメージで理解する＆伝える
– ファイルシステム系とジョブ管理系が複雑にからみあっている
• お互いが連携していることがHadoopの価値
– 1台のマスタサーバ＋多数台のスレーブサーバ
なぜ必要とされているか
• 定型処理 → 非定型処理への流れ
– 処理すべきデータ量の増大
– スケール・アウトが必然
• 存在の「空気」化
– 水道や電気を使っていることを普段から意識している人はいない
○○という機能がない？！
• アクセス権制御が不十分
• ファイル追記ができない
• マスタサーバが二重化されていない
– SecondaryNameNodeについての誤解
ファイルシステム／バッチ処理システムとして備えるべき機能という観点ではまだまだ不足
インフラとしての「割り切り」
• 既存のインフラとは目的が異なる
– 大量データバッチ処理の高速化に特化した構成
– 組織内システム（インハウス）での利用を想定
• 優先順位が低い機能は潔くあきらめている
• 既存のインフラの役割を完全に置き換えるものではない
– 高速道路は一般道路を代替できない
Hadoopの使いどころ
• Hadoopは何ができて、何ができないのか？
• RDBMSとの使い分けは？
情報インフラとしてのRDBMS
• ブラックボックス化
– あらゆるデータ操作をSQLで標準化
• トランザクション処理
– 複数ユーザによる読み書きが発生する環境でデータの矛盾発生を防ぐ
cf. 銀行口座間の資金移動
• インデックス
– 指定されたデータを一瞬で検索
RDBMSの課題
• データ処理のニーズの変化
– 定型処理から非定型処理へ
• スケールアウトしづらい
– CAP定理
定型処理と非定型処理
• 定型処理
– 給与計算、売上集計、伝票処理など
– 人間が介在しない完全な自動化が可能
– 厳密さが求められる
– データ量はせいぜいGbytesオーダー
• 非定型処理
– 統計データ作成、検索、データ・マイニングなど
– 人間の介在が必要
– 厳密さよりカバレッジ重視 (データ量が重要)
– データ量はTbytes～Pbytesオーダーになり得る
ブリュワーのCAP定理Eric Brewer＠UCBが2000年に提唱
以下の3つのシステム要件を同時に満たすのが不可能であることを証明
• C: Consistency (一貫性) → トランザクション
• A: Availability (可用性) → 耐障害性
• P: Partition Tolerance (分割耐性) → スケール・アウト性
RDBMS: CAを満たすがPを満たさない
Hadoop, 分散KVS: APを満たすがCを満たさない
Hadoopクラスタ（バッチ処理）
RDBMS分散KVS
アプリケーションサーバ（リアルタイム処理）
分散ファイル・システム(HDFS)スレーブ・サーバーのハードディスクを束ねて構成
ログファイル
ユーザインタフェース
リアルタイム処理要求 応答
外部入力ファイル 外部出力ファイル
Hadoopが効果を発揮する用途例
• 検索インデックスの生成
• 大量のテキストデータの継続的解析
– ブログからの急上昇ワード抽出
• 時空間上のバスケット解析
– Webアクセスログを用いたマイニング
– 地図情報マイニング
ブログからの急上昇ワード抽出
• クローリングしたブログを1時間ごとに解析し、急上昇ワードを抽出
• 変化率を計算するため、莫大なデータを毎時処理する必要がある
• Hadoopクラスタ規模
– DataNode 3台 (QuadCore CPU)
• 数十Gbytesのデータを20分ほどで解析
Trend Navigator
時空間上のバスケット分析
(例) あるキーワードで検索してから10分以内に訪れたURLを抽出
キーワード検索
ページ訪問
時空間上のバスケット分析
(例2) A社のコンビニから半径500m以内にある他社のコンビニを全て抽出
(例3) 都内で開催されたコンサート会場近辺で携帯からサイトにアクセスした顧客を抽出
RDBMSでは処理が難しい
→ MapReduceで効率的に処理可能！
処理ロジックの実装
• MapReduceの直接実装
– 習熟するまでが大変
– コスト高
– 自由度が大きい
• HiveやPig Latinなどのメタ言語利用
– 習熟は楽
– コスト安
– 自由度が小さい
まとめ
• Hadoopのメリットの伝え方
– 新しいインフラなのでわかりにくくて当然！
– 詳しい仕組みよりも、具体的な利用方法を
• できることとできないことをきちんと区別する
– 他のソリューションで十分なケースもたくさんある
– 既存手法と組み合わせることで問題解決可能
• DRBD+Heartbeatによるマスタサーバの多重化
• 埋もれているニーズはまだたくさんある