新たな情報インフラとしてのHadoopの活用

1. 技術評論社／ヤフー 共催
Hadoop Hack Night Vol. 2
2010年8月4日
新たな情報インフラとしての
Hadoopの活用
株式会社リッテル 上席研究員
清田 陽司
(兼 東京大学情報基盤センター
学術情報研究部門 助教)
Twitter: @kiyota_yoji

2. Hadoop活用の壁
• 実績がまだまだ少ない
• ○○という機能がない
• ファイルシステムとして備えるべき機能（アクセス権制
御など)
• マスタサーバの多重化
• Hadoopってよくわからないんだけど
• RDBMSとの違いは？
• どういう処理でメリットがあるの？
• Hadoopってクラウドなの？(←そもそもクラウドって何
よ？)

3. Agenda
• Hadoopをインフラとして理解する
• Hadoopの使いどころ
– RDBMS、分散KVSとの使い分け
• 開発事例紹介
– Hadoopが効果を発揮する用途
– 開発手法

4. Hadoopを理解するポイント
インフラとして理解する
• シンプルなインタフェース＋複雑な中身
– ブラックボックスとしてとらえる
• なくてはならない存在
– なぜ必要とされているかを理解する
• 現実的な「割り切り」
– ○○という機能がない理由を理解する

5. ひねる
蛇口
水が出る
課金 請求書
水を捨てる 流し

6. ひねる
蛇口 メータ 水道管 配水施設 浄水施設 取水施設
水が出る
水漏れの 水圧の 水質の管理 水位の管理
防止 コントロール
河川
水利権の調整
料金集計 メータ 渇水への対処 ダム
課金 請求書
システム 検針 発電・治水との
調整など
マン
水を捨てる 流し
ホール
下水管 沈砂池 沈殿池 消毒施設
詰まりの防止 除砂 水質の管理
メンテナンス
汚泥処理 河川
インタフェース 中身

7. Hadoopのインタフェースと中身
データブロックの送受信 Hadoopスレーブサーバ#1
NameNodeへの状態通知
HDFSの全体統括 DataNode HDFS
ファイルの データブロックの管理 デーモン ストレージ
書き込み 異常発生時の復元処理 子JVM
TaskTracker map/reduce
ファイルの Mapタスク/Reduceタスクの起動
HDFS デーモン 子JVM
読み込み JobTrackerへの状態通知
API map/reduce
ファイルの
管理 Hadoop Hadoopスレーブサーバ#2
(複製、移動、 マスタサーバ DataNode HDFS
NameNode デーモン ストレージ
削除、…) デーモン
子JVM
TaskTracker map/reduce
JobTracker
バッチ処理 デーモン 子JVM
デーモン map/reduce
ジョブの投入
・・
バッチ処理 ・
ジョブの Map
Reduce Hadoopスレーブサーバ#N
状態取得
API DataNode HDFS
バッチ処理 デーモン ストレージ
ジョブの
子JVM
管理 バッチ処理ジョブの進行状況管理 map/reduce
TaskTracker
(キャンセル、 Mapタスク/Reduceタスクの割り振り
デーモン 子JVM
異常発生時のバックアップタスク実行指示
優先度 map/reduce
設定、…)
インタフェース 中身

8. ブラックボックスとしてとらえる
• インタフェースはシンプル
– ファイルシステム系(HDFS)
– ジョブ管理系(MapReduce)
• 中身はイメージで理解する＆伝える
– ファイルシステム系とジョブ管理系が複雑にから
みあっている
• お互いが連携していることがHadoopの価値
– 1台のマスタサーバ＋多数台のスレーブサーバ

9. なぜ必要とされているか
• 定型処理 → 非定型処理 への流れ
– 処理すべきデータ量の増大
– スケール・アウトが必然
• 存在の「空気」化
– 水道や電気を使っていることを普段から意識して
いる人はいない

10. ○○という機能がない？！
• アクセス権制御が不十分
• ファイル追記ができない
• マスタサーバが二重化されていない
– SecondaryNameNodeについての誤解
ファイルシステム／バッチ処理システムとして備
えるべき機能という観点ではまだまだ不足

11. インフラとしての「割り切り」
• 既存のインフラとは目的が異なる
– 大量データバッチ処理の高速化に特化した構成
– 組織内システム（インハウス）での利用を想定
• 優先順位が低い機能は潔くあきらめている
• 既存のインフラの役割を完全に置き換えるも
のではない
– 高速道路は一般道路を代替できない

12. Hadoopの使いどころ
• Hadoopは何ができて、何ができないのか？
• RDBMSとの使い分けは？

13. 情報インフラとしてのRDBMS
• ブラックボックス化
– あらゆるデータ操作をSQLで標準化
• トランザクション処理
– 複数ユーザによる読み書きが発生する環境で
データの矛盾発生を防ぐ
cf. 銀行口座間の資金移動
• インデックス
– 指定されたデータを一瞬で検索

14. RDBMSの課題
• データ処理のニーズの変化
– 定型処理から非定型処理へ
• スケールアウトしづらい
– CAP定理

15. 定型処理と非定型処理
• 定型処理
– 給与計算、売上集計、伝票処理など
– 人間が介在しない完全な自動化が可能
– 厳密さが求められる
– データ量はせいぜいGbytesオーダー
• 非定型処理
– 統計データ作成、検索、データ・マイニングなど
– 人間の介在が必要
– 厳密さよりカバレッジ重視 (データ量が重要)
– データ量はTbytes～Pbytesオーダーになり得る

16. ブリュワーのCAP定理
Eric Brewer＠UCBが2000年に提唱
以下の3つのシステム要件を同時に満たすのが
不可能であることを証明
• C: Consistency (一貫性) → トランザクション
• A: Availability (可用性) → 耐障害性
• P: Partition Tolerance (分割耐性) → スケール・
アウト性
RDBMS: CAを満たすがPを満たさない
Hadoop, 分散KVS: APを満たすがCを満たさない

17. リアルタイム処理要求 応答
ユーザインタフェース
アプリケーションサーバ（リアルタイム処理）
RDBMS
ログファイル 分散KVS
分散ファイル・システム(HDFS)
スレーブ・サーバーのハードディスクを束ねて構成
外部入力ファイル 外部出力ファイル
Hadoopクラスタ（バッチ処理）

18. Hadoopが効果を発揮する用途例
• 検索インデックスの生成
• 大量のテキストデータの継続的解析
– ブログからの急上昇ワード抽出
• 時空間上のバスケット解析
– Webアクセスログを用いたマイニング
– 地図情報マイニング

19. ブログからの急上昇ワード抽出
• クローリングしたブログを1時間ごとに解析し、
急上昇ワードを抽出
• 変化率を計算するため、莫大なデータを毎時
処理する必要がある
• Hadoopクラスタ規模
– DataNode 3台 (QuadCore CPU)
• 数十Gbytesのデータを20分ほどで解析

20. Trend Navigator

21. 時空間上のバスケット分析
(例) あるキーワードで検索してから10分以内に
訪れたURLを抽出
キーワード ページ
検索 訪問

22. 時空間上のバスケット分析
(例2) A社のコンビニから半径500m以内にある
他社のコンビニを全て抽出
(例3) 都内で開催されたコンサート会場近辺で
携帯からサイトにアクセスした顧客を抽出
RDBMSでは処理が難しい
→ MapReduceで効率的に処理可能！

23. 処理ロジックの実装
• MapReduceの直接実装
– 習熟するまでが大変
– コスト高
– 自由度が大きい
• HiveやPig Latinなどのメタ言語利用
– 習熟は楽
– コスト安
– 自由度が小さい

24. まとめ
• Hadoopのメリットの伝え方
– 新しいインフラなのでわかりにくくて当然！
– 詳しい仕組みよりも、具体的な利用方法を
• できることとできないことをきちんと区別する
– 他のソリューションで十分なケースもたくさんある
– 既存手法と組み合わせることで問題解決可能
• DRBD+Heartbeatによるマスタサーバの多重化
• 埋もれているニーズはまだたくさんある