マイニング探検会 10回目は Hadoop をはじめとする大規模データ分散処理についての概略を紹介します。

1. 2010年1月28日
マイニング探検会#10
＠東京大学アントレプレナープラザ会議室
データ処理のパラダイムシフト
東京大学情報基盤センター
学術情報研究部門 特任講師／
株式会社リッテル 最高技術責任者
清田 陽司
1

2. 2000年代の大きな変化
• サーチエンジンの急速な普及
• データ処理手法の変化
• …
背景: 扱うデータサイズが飛躍的に増大
＝「情報爆発」
2

3. なぜ「情報爆発」？
• データ発生源の増大
• ストレージ量の増大
• コンピュータへのニーズの変化
• 大規模データが処理できるインフラの普及
3

4. データ発生源の増大
• PCのブラウザ
• 携帯電話／スマートフォン
• 電子マネー／IC乗車券
• GPS
• センサーネットワーク
4

5. ストレージ量の増大
• ハードディスク媒体の急速な進歩
– 記録密度は年率40％で向上中
• 容量あたりのコストの急激な低下
5

6. コンピュータへのニーズの変化
定型処理から非定型処理へ
• 定型処理
– 決まったルールにしたがって完全自動処理
– 厳密な計算が要求される
– 具体例: 給与計算、売り上げ集計、貸出管理
• 非定型処理
– 処理された結果の最終的な解釈を人間に委ねる
– 厳密さよりデータのカバレッジが重視される
– 具体例: サーチエンジン、データマイニング
6

7. 大規模データ処理のインフラ普及
• Googleの社内システムとして開発
– Google File System (2003):
http://labs.google.com/papers/gfs.html
– MapReduce (2004):
http://labs.google.com/papers/mapreduce.html
• Hadoop: Googleのアイディアのオープンソー
ス実装
7

8. Hadoopとは何か？
A large-scale distributed batch processing
infrastracture
• Large-scale = Web規模のデータを扱える
• 1TBytes(1兆バイト)～1PBytes(1000兆バイト)
• Distributed = 分散型システム
• Batch = バッチ処理専用 (高速な処理)
• Infrastructure = インフラとしてのシステム
• つまり意識せずに使える

9. スケール・アップとスケール・アウト
価格 性能を上げようとすると スケール・アップ
価格が飛躍的に
上昇してしまう
スケール・アウト
1台のコンピュータ
この領域をうまく の性能
使いたい

10. スケールアウトの課題
データをたくさんの台数のコンピュータで並列に
処理するのは難しい
• 故障の確率が上がる
– 1台の故障率 1%/1年 => 1000台の故障率は?!
→ 壊れても自動復元できる仕組みが必要
• 有限のリソースを効率的に配分しなければな
らない
– プロセッサ時間、メモリ、ハードディスク空き容量、
ネットワーク帯域

11. スケールアウトの課題(cont.)
• マシン間の同期をとらなければならない
• どこかが故障したときにも計算を続けなけれ
ばならない

12. スケール・アウトのボトルネック
分割されたデータを 台数を増やすほど処理
それぞれのサーバー は速くなるはずだが…
で処理する
処理結果データをそ 集められた処理結
れぞれのサーバー 果の集計処理を行
から集める い、集計結果を出力
巨大な入力データを
分割し、それぞれサー する
バーに配布する
入力 出力
・・
・
スケール・アウトの
必要に応じて繰り返す
ボトルネック

13. スケール・アウトのボトルネックを解消
するには？
3種類の処理を分散できるしくみが必要
1. 処理すべきデータの固まりを分担して扱うし
くみ
2. ばらばらの処理結果を集めて仕分けるしくみ
3. 仕分けられた結果を集計して出力するしくみ

14. 担当
ボトルネックの解消
入力 出力
ファイル ファイル
担当
担当
最初からデータを 仕分け先をマークごとに決めて まとめた結果データ
仕分け用の
それぞれのサーバに 振り分ける もそれぞれのサーバ
マーキング
ばらまいておく 仕分け先はできるだけ均等に が保持

15. Hadoopのボトルネック解消のしくみ
• 2つのシステムのコラボレーション
• 分散ファイルシステム
– HDFS (Hadoop Distributed File System)
– それぞれのサーバのハードディスクを束ねて、ひとつ
の巨大な仮想ディスクとして扱う
– 多重書き込み (cf. RAID0) → 耐障害性
• MapReduce
– map (分担する) → shuffle (仕分ける) → reduce (集計す
る)
– 分散バッチ処理をフレームワーク化
• プログラミングが必要なのは map と reduceのみ
– 仕分けのしくみはHadoopで用意されている

16. Hadoopがスケール・アウトする仕組み
データ本体を扱わないため、 マスタ－・サーバーはシステム
ボトルネックになりにくい 全体のデータの流れをコント
マスター・サーバー ロールする役割を果たす
(親分)
shuffle
仕分け作業のために、ス map, shuffle, reduceは
レーブ・サーバー同士が 必要に応じて繰り返す
データをやりとりする
スレーブ・サーバー reduce
map (子分) 仕分けられたデータを
それぞれのスレーブ・
分散ファイル・システムか サーバーが分担して
らそれぞれのスレーブ・ 集計し、処理結果を分
サーバーが入力データを 散ファイル・システム
読み込み、分担して処理 に書き出す
分散ファイル・システム(HDFS)
スレーブ・サーバーのハードディスクを束ねて構成
巨大な入力データを分 出力データを分散ファイ
散ファイル・システムに ル・システムから読み出
書き込む す
分散ファイル・システムへの読み書き性能、
計算処理性能ともに台数にほぼ比例する

17. スレーブ・サーバー数と処理能力の関係
350GBytesのテキストデータのMapReduce処理
「Bitqull: Data harvesting with MapReduce」
http://www.bitquill.net/blog/?p=17 より引用

18. 理解のポイント
• データマイニングの世界の鉄則
「量が質に転化する」
• システム構築の固定観念が崩れつつある
– いつまでもベンダー任せでやっていけるのか？
• 数十年のスパンでの変化を理解しておく
18

19. TP&Dフォーラム2011
• 整理技術、情報管理に問題意識を持つ研究
者・実務者の集い
– http://tpd.eplang.jp/
• 1991年より毎年開催、今年で21回目
– 委員長は伊藤祥さん＠JST
• 清田も今回発表予定です
• 日時
– 2011年8月19日(金) 昼～20日(土) 昼
– 熱海・金城館
19