データ処理のパラダイムシフト

東京大学情報基盤センター

学術情報研究部門 特任講師／

株式会社リッテル 最高技術責任者

清田 陽司

2010年1月28日マイニング探検会#10＠東京大学アントレプレナープラザ会議室

1

2000年代の大きな変化

• サーチエンジンの急速な普及

• データ処理手法の変化

• …

背景: 扱うデータサイズが飛躍的に増大

＝「情報爆発」

2

なぜ「情報爆発」？

• データ発生源の増大

• ストレージ量の増大

• コンピュータへのニーズの変化

• 大規模データが処理できるインフラの普及

3

データ発生源の増大

• PCのブラウザ

• 携帯電話／スマートフォン

• 電子マネー／IC乗車券

• GPS• センサーネットワーク

4

ストレージ量の増大

• ハードディスク媒体の急速な進歩

– 記録密度は年率40％で向上中

• 容量あたりのコストの急激な低下

5

コンピュータへのニーズの変化

定型処理から非定型処理へ

• 定型処理

– 決まったルールにしたがって完全自動処理

– 厳密な計算が要求される

– 具体例: 給与計算、売り上げ集計、貸出管理

• 非定型処理

– 処理された結果の最終的な解釈を人間に委ねる

– 厳密さよりデータのカバレッジが重視される

– 具体例: サーチエンジン、データマイニング6

大規模データ処理のインフラ普及

• Googleの社内システムとして開発

– Google File System (2003): http://labs.google.com/papers/gfs.html

– MapReduce (2004): http://labs.google.com/papers/mapreduce.html

• Hadoop: Googleのアイディアのオープンソース実装

7

Hadoopとは何か？

A large-scale distributed batch processing infrastracture

• Large-scale = Web規模のデータを扱える

• 1TBytes(1兆バイト)～1PBytes(1000兆バイト)

• Distributed = 分散型システム

• Batch = バッチ処理専用 (高速な処理)• Infrastructure = インフラとしてのシステム

• つまり意識せずに使える

価格

1台のコンピュータの性能

性能を上げようとすると価格が飛躍的に上昇してしまう

この領域をうまく使いたい

スケール・アップ

スケール・アウト

スケール・アップとスケール・アウト

スケールアウトの課題

データをたくさんの台数のコンピュータで並列に処理するのは難しい

• 故障の確率が上がる

– 1台の故障率 1%/1年 => 1000台の故障率は?!

→ 壊れても自動復元できる仕組みが必要

• 有限のリソースを効率的に配分しなければならない

– プロセッサ時間、メモリ、ハードディスク空き容量、ネットワーク帯域

スケールアウトの課題(cont.)

• マシン間の同期をとらなければならない

• どこかが故障したときにも計算を続けなければならない

巨大な入力データを分割し、それぞれサー

バーに配布する

分割されたデータをそれぞれのサーバー

で処理する処理結果データをそれぞれのサーバー

から集める

集められた処理結果の集計処理を行い、集計結果を出力

する

スケール・アウトのボトルネック

・・・

必要に応じて繰り返す

入力 出力

台数を増やすほど処理は速くなるはずだが…

スケール・アウトのボトルネック

スケール・アウトのボトルネックを解消するには？

3種類の処理を分散できるしくみが必要

1. 処理すべきデータの固まりを分担して扱うしくみ

2. ばらばらの処理結果を集めて仕分けるしくみ

3. 仕分けられた結果を集計して出力するしくみ

仕分け用のマーキング

最初からデータを

それぞれのサーバにばらまいておく

仕分け先をマークごとに決めて振り分ける

仕分け先はできるだけ均等に

担当

担当

担当

入力ファイル

出力ファイル

まとめた結果データもそれぞれのサーバ

が保持

ボトルネックの解消

Hadoopのボトルネック解消のしくみ

• 2つのシステムのコラボレーション

• 分散ファイルシステム– HDFS (Hadoop Distributed File System)– それぞれのサーバのハードディスクを束ねて、ひとつの巨大な仮想ディスクとして扱う

– 多重書き込み (cf. RAID0) → 耐障害性

• MapReduce– map (分担する) → shuffle (仕分ける) → reduce (集計する)

– 分散バッチ処理をフレームワーク化• プログラミングが必要なのは map と reduceのみ

– 仕分けのしくみはHadoopで用意されている

データ本体を扱わないため、ボトルネックになりにくい

分散ファイル・システムへの読み書き性能、計算処理性能ともに台数にほぼ比例する

分散ファイル・システム(HDFS)スレーブ・サーバーのハードディスクを束ねて構成

巨大な入力データを分散ファイル・システムに

書き込む

map分散ファイル・システムからそれぞれのスレーブ・サーバーが入力データを読み込み、分担して処理

出力データを分散ファイル・システムから読み出

す

shuffle仕分け作業のために、スレーブ・サーバー同士がデータをやりとりする

reduce仕分けられたデータをそれぞれのスレーブ・サーバーが分担して集計し、処理結果を分散ファイル・システム

に書き出す

マスタ－・サーバーはシステム全体のデータの流れをコントロールする役割を果たす

map, shuffle, reduceは必要に応じて繰り返す

スレーブ・サーバー(子分)

マスター・サーバー(親分)

Hadoopがスケール・アウトする仕組み

スレーブ・サーバー数と処理能力の関係

「Bitqull: Data harvesting with MapReduce」http://www.bitquill.net/blog/?p=17 より引用

350GBytesのテキストデータのMapReduce処理

理解のポイント

• データマイニングの世界の鉄則

「量が質に転化する」

• システム構築の固定観念が崩れつつある

– いつまでもベンダー任せでやっていけるのか？

• 数十年のスパンでの変化を理解しておく

18

TP&Dフォーラム2011

• 整理技術、情報管理に問題意識を持つ研究者・実務者の集い– http://tpd.eplang.jp/

• 1991年より毎年開催、今年で21回目– 委員長は伊藤祥さん＠JST

• 清田も今回発表予定です

• 日時– 2011年8月19日(金) 昼～20日(土) 昼– 熱海・金城館

19