Apache Spark による MapReduce の基礎

分散処理実践セミナー

小町守 首都大学東京システムデザイン学部 情報通信システムコース 2014年12月12日（金）

このスライドは Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States ライセンスによって公開されています。詳しくは http://creativecommons.org/licenses/by-nc-sa/3.0/

http://cl.sd.tmu.ac.jp/~komachi/ でスライドを公開します

本セミナーに関して

¢  スケーラブルな処理に焦点を当てます

¢  MapReduce の「デザインパターン」を学びます

¢  基本的な直観を話します。数学はありません

¢  Hadoop プログラミングのチュートリアルではありません

¢  GPGPU とも関係ありません

¢  右の本の入門版（PDF が GitHub で無料公開されています）です

¢  Jimmy Lin, Large-Scale Data Processing with MapReduce. AAAI Tutorial, 2011 のスライドをベースにしています

どれくらいデータがある？

6.5 PB のユーザデータ + 50 TB/日 (2009/5)

の処理するデータ量＝20 PB/日 (2008)

36 PB のユーザデータ + 500 TB/日 (2012)

Wayback Machine: 3 PB + 100 TB/月 (2009/3)

12 TB/日 (2011)

640K あれば十分だよ！（ビル・ゲイツ）

データ量に上限はない！

(Banko and Brill, ACL 2001) (Brants et al., EMNLP 2007)

s/知識/データ/g;

Google にいない我々はどうやったら こんな規模のデータを使うことができる？

並列コンピューティングはたいへん！

メッセージパッシング

P1 P2 P3 P4 P5

共有メモリ

P1 P2 P3 P4 P5

メモ

リ

いろいろなプログラミングモデル

いろいろなプログラミングのコンポーネント mutex、バリア、… master/slave、producer/consumer、ワークキュー、…

原理的な問題 スケジューリング、データ分散、同期、プロセス間通信、頑健性、フォールトトレランス、…

共有に関する問題 デッドロック、飢餓状態、 優先順位の逆転、… 食事する哲学者、居眠り床屋、…

アーキテクチャの問題 SIMD、MIMD、… ネットワークの構造、帯域幅 UMA vs. NUMA、キャッシュコヒーレンス

現実: プログラマが平行性の管理の責任を負う。。。 （競合状態のデバッグに苦しむか、新しいアルゴリズムを考案するために時間を使うか）

master

slave

producer consumer

producer consumer

ワーク キュー

「ビッグデータ」の理想現実と現実

¢  並列処理は難しい l  データセンターのスケールだと特に。（データセンターをまたぐことすら） l  故障が存在する l  複数の相互に連携するサービスが存在する

¢  現実は？ l  その場限りの対処ばかり。カスタマイズされたソースコード。 l  特化したライブラリを書いて、それを使ってプログラミング。 l  全てを明示的に管理するようプログラマが気をつけなければならな

い。。。

Source: Ricardo Guimarães Herrmann

Source: NY Times (6/14/2006)

データセンターこそがコンピュータ

「世界にコンピュータは5台あれば足りる」 （トーマス・J・ワトソン、IBM初代社長）

何が問題？？？

¢  どのように抽象化するか、の問題

¢  エンジニアからシステムレベルの詳細を隠蔽する l  リソースの競合、ロック、などなど。。。

¢  対象と手法を分離する l  エンジニアは処理すべき計算を書くだけでよい l  処理フレームワーク（ランタイム）が実際の処理を担当する

データセンターこそがコンピュータ

大規模データ処理の「哲学」

¢  スケール「アウト」する。（スケール「アップ」ではなく） l  マルチプロセッサ（SMP）と大規模共有メモリマシンの限界

¢  データ中心の処理を行う l  クラスタは限られた帯域しかない

¢  データを順番に処理する。ランダムアクセスしない。 l  データのシークは高コスト。ディスクのスループットは常識的な速度。

¢  シームレスなスケーラビリティ l  人月の神話から、測定・購入可能な計算機時間へ

+ 単純な分散プログラミングモデル 安いコモディティ化されたクラスタ

= 誰でもできる大規模データ処理！

MapReduce の基礎

MapReduce の基礎 MapReduce のアルゴリズムデザイン MapReduce を超えて

典型的な大規模データ処理

¢  多数のレコードに対して反復する

¢  それぞれに対してなにか抽出する

¢  中間結果をシャッフルし、ソートする

¢  中間結果を集約する

¢  最終出力を生成する

ポイント: これら2つの操作に対する 機能的な抽象化を提供する

Map

Reduce

(Dean and Ghemawat, OSDI 2004)

g g g g g

f f f f f Map

Fold (Reduce)

関数型プログラミングの基本

MapReduce

¢  プログラマは2つの関数を指定する。 map (k, v) → <k’, v’>* reduce (k’, v’) → <k’, v’>* l  同じキーを持つ値は全て同じ reducer に送られる

¢  処理フレームワークが残り全部やってくれる。

map map map map

シャッフルとソート: キーで値を集約

reduce reduce reduce

k1 k2 k3 k4 k5 k6 v1 v2 v3 v4 v5 v6

b a 1 2 c c 3 6 a c 5 2 b c 7 8

a 1 5 b 2 7 c 2 3 6 8

r1 s1 r2 s2 r3 s3

MapReduce

¢  プログラマは2つの関数を指定する。 map (k, v) → <k’, v’>* reduce (k’, v’) → <k’, v’>* l  同じキーを持つ値は全て同じ reducer に送られる

¢  処理フレームワークが残り全部やってくれる。

「残り全部」って何？

MapReduce の実行時の動作

¢  スケジューリング l  worker に map と reduce タスクを割り当てる

¢  データの分配 l  プロセスをデータに移動する

¢  処理の同期 l  中間結果を集め、シャッフルし、ソートする

¢  エラー処理 l  worker の失敗を検出し、リスタートする

¢  分散ファイルシステムの管理

MapReduce ホントのところ

¢  プログラマは2つの関数を指定する。 map (k, v) → <k’, v’>* reduce (k’, v’) → <k’, v’>* l  同じキーを持つ値は全て同じ reducer に送られる

¢  処理フレームワークが残り全部やってくれる。

¢  実際は、プログラマは他にもいくつか指定しなければならない。 partition (k’, 分割数) → k’ のパーティション l  キーのハッシュが用いられることが多い e.g., hash(k’) mod n l  キーの空間を並列 reduce 操作のために分割する combine (k’, v’) → <k’, v’>* l  map フェーズのあとにインメモリで実行される mini-reducer l  reduce のネットワーク通信の最適化に使われる

combine combine combine combine

b a 1 2 c 9 a c 5 2 b c 7 8

partition partition partition partition

map map map map

k1 k2 k3 k4 k5 k6 v1 v2 v3 v4 v5 v6

b a 1 2 c c 3 6 a c 5 2 b c 7 8

シャッフルとソート: キーによる値の集約

reduce reduce reduce

a 1 5 b 2 7 c 2 9 8

r1 s1 r2 s2 r3 s3

c 2 3 6 8

MapReduce に関する補足2点

¢  map と reduce のフェーズの間の障壁 l  事前に中間データをコピーするところから始められる

¢  各 reducer にやってくるキーはソートされている l  reducer をまたぐと順番には何の制約もない

MapReduce的 “Hello World”: 単語カウント

MapReduce という単語の多義性

¢  プログラミングモデル

¢  処理フレームワーク（ランタイム）

¢  特定の実装

どれを意味するかは 文脈から明らかであることが多い。

MapReduce の実装

¢  Google は C++ によるプロプライエタリな実装がある l  Java と Python のバインディングがある

¢  Hadoop は Java によるオープンソースの MapReduce 実装 l  初期は Yahoo が開発を主導 l  現在は Apache オープンソースプロジェクト

l  ビッグデータ処理業界におけるデファクトスタンダード l  ソフトウェアの「生態系」が急速に拡大

¢  Spark は Scala による MapReduce 実装 l  UC Berkeley で開発されていたが、現在は Apache OSS

l  インメモリでの処理に特化し高速化

l  Scala と Python のバインディングがある

今回のセミナーでは Apache Spark を使用

split 0 split 1 split 2 split 3 split 4

worker

worker

worker

worker

worker

Master

User Program

output file 0

output file 1

(1) submit

(2) schedule map (2) schedule reduce

(3) read (4) local write

(5) remote read (6) write

入力 ファイル

Map フェーズ

中間結果 （ローカルディスク）

Reduce フェーズ

出力 ファイル

Adapted from (Dean and Ghemawat, OSDI 2004)

データをどのように worker に移動するの？

計算ノード

NAS

SAN

なにか問題がある？？？

分散ファイルシステム

¢  データを worker に移動するのではなく、worker をデータに移動させる l  クラスタのノードのローカルディスクにデータを保持 l  ローカルにデータを持っているノードで worker を開始

¢  分散ファイルシステムで解決！ l  GFS (Google File System): Google の MapReduce l  HDFS (Hadoop Distributed File System): Hadoop

GFS: 仮定

¢  高価な（特注の）ハードウェアではなく、安価な（コモディティ化された）ハードウェア l  スケール「アップ」ではなくスケール「アウト」

¢  ハードウェア故障の率が高い l  安価なコモディティのハードウェアは常に壊れる

¢  そこそこの数の巨大なファイル l  数 GB のファイルは普通

¢  ファイルは1回書き込むだけで、大部分は追記 l  同時に書き込み・追記されることも

¢  ランダムアクセスではなく大規模なストリーム処理 l  レイテンシは低いがスループットは高い

GFS slides adapted from material by (Ghemawat et al., SOSP 2003)

GFS: デザインのポリシー

¢  ファイルをチャンクとして保存 l  固定長 (64MB)

¢  複製することにより信頼性の確保 l  各チャンクは3台以上の chunkserver をまたいで複製される

¢  アクセス制御には1つの master を置き、メタデータを保

l  単純な集中管理

¢  データのキャッシュはしない l  巨大なデータ集合をストリーム処理で読むなら、キャッシュしてもあま

り意味がない

¢  API を単純化 l  問題のいくつかはクライアントに丸投げ（例: データのレイアウト）

HDFS = GFS クローン（基本アイデアは同じ）

GFS から HDFS へ

¢  用語の違い: l  GFS master = Hadoop namenode l  GFS chunkserver = Hadoop datanode

¢  機能の違い: l  HDFS におけるファイルの追記は比較的新しくサポートされた機能 l  HDFS の性能は遅い（ことが多い）

以降のスライドでは Hadoop の用語を使用

Adapted from (Ghemawat et al., SOSP 2003)

(file name, block id)

(block id, block location)

instructions to datanode

datanode state (block id, byte range)

block data

HDFS namenode

HDFS datanode

Linux ファイルシステム

…

HDFS datanode

Linux ファイルシステム

…

ファイル名前空間 /foo/bar

block 3df2

アプリケーション

HDFS クライアント

HDFS のアーキテクチャ

Namenode の役割

¢  ファイルシステムの名前空間を管理 l  ファイル/ディレクトリ構造、メタデータ、ファイルからブロックへの対

応表、アクセス権限などを保持

¢  ファイル操作を管理 l  クライアントが datanode を介して読み書きするよう指示 l  namenode を通じたデータの移動はない

¢  全体の整合性を管理 l  datanode と定期的に通信 l  ブロックの再複製と再バランシング l  ガベージコレクション

HDFS の全体像

datanode デーモン

Linux ファイルシステム

…

tasktracker

slave ノード

datanode デーモン

Linux ファイルシステム

…

tasktracker

slave ノード

datanode デーモン

Linux ファイルシステム

…

tasktracker

slave ノード

namenode

namenode デーモン

job submission node

jobtracker

MapReduce のアルゴリズムデザイン

MapReduce の基礎 MapReduce のアルゴリズムデザイン MapReduce を超えて

MapReduce の復習

¢  プログラマは2つの関数を指定する。 map (k, v) → <k’, v’>* reduce (k’, v’) → <k’, v’>* l  同じキーを持つ値は全て同じ reducer に送られる

¢  以下も指定することがある。 partition (k’, 分割数) → k’ のパーティション l  キーのハッシュが用いられることが多い e.g., hash(k’) mod n l  キーの空間を並列 reduce 操作のために分割する combine (k’, v’) → <k’, v’>* l  map フェーズのあとにインメモリで実行される mini-reducer l  reduce のネットワーク通信の最適化に使われる

¢  処理フレームワークが残り全部やってくれる。

combine combine combine combine

b a 1 2 c 9 a c 5 2 b c 7 8

partition partition partition partition

map map map map

k1 k2 k3 k4 k5 k6 v1 v2 v3 v4 v5 v6

b a 1 2 c c 3 6 a c 5 2 b c 7 8

シャッフルとソート: キーによる値の集約

reduce reduce reduce

a 1 5 b 2 7 c 2 9 8

r1 s1 r2 s2 r3 s3

c 2 3 6 8

「残り全部」

¢  処理フレームワークが残り全部やってくれる↓ l  スケジューリング: worker に map と reduce タスクを割り当てる l  データの分配: プロセスをデータに移動する l  処理の同期: 中間結果を集め、シャッフルし、ソートする l  エラー処理: worker の失敗を検出し、リスタートする

¢  データと実行フローに関する制御は限られている l  アルゴリズムは map, reduce, combine, partition で記述されなけれ

ばならない

¢  まだ説明していないこと: l  どこで mapper と reducer が実行されるか l  いつ mapper あるいは reducer が開始・終了するか l  特定の mapper が処理する入力はどれか l  特定の reducer が処理する中間結果はどれか

同期するための MapReduce の仕組み

¢  賢く構築されたデータ構造 l  部分的な結果をまとめる

¢  中間キーの順番をソートする l  reducer がキーを処理する順番をコントロールする

¢  partitioner l  どの reducer がどのキーを処理するかコントロールする

¢  mapper と reducer に状態を保存する l  複数のキーと値をまたいだ依存関係を捉える

状態を保存する

Mapper オブジェクト

設定

map

終了処理

状態 1タスク1オブジェクト

Reducer オブジェクト

設定

reduce

終了処理

状態

キー＝バリューの入力ペア に対し1回実行される

中間キー に対し1回実行される

API 初期化フック

API クリーンアップフック

スケーラブルな Hadoop アルゴリズム: 課題

¢  オブジェクトを極力作らない l  そもそも高コストな操作 l  ガベージコレクションされる

¢  バッファリングしない l  ヒープサイズが限られている l  小さなデータに対しては役に立つが、スケールしない！

ローカル集約の重要性

¢  スケールするシステムの理想的な特徴: l  データが2倍になれば処理時間が2倍 l  リソースが2倍になれば処理時間は半分

¢  どうしてそんなシステムが作れないの？ l  同期するために通信が必要

l  通信によって性能がガタ落ち

¢  つまり、通信を避ける。 l  ローカルに集約することで中間データを reduce する l  combiner が役に立つ

シャッフルとソート

Mapper

Reducer

他の mapper

他の reducer

リングバッファ （インメモリ）

データ （オンディスク）

マージされたデータ （オンディスク）

中間ファイル （オンディスク）

Combiner

Combiner

単語カウント: ベースライン

combiner の意味は？

単語カウント: バージョン1

combiner はまだ必要？

単語カウント: バージョン2

combiner　はまだ必要？

ローカル集約のデザインパターン

¢  mapper の中で combine する l  複数の map 呼び出しをまたいで状態を保存することで、combiner

の機能を mapper に埋め込む

¢  利点 l  速度 l  combiner より速い理由？

¢  欠点 l  明示的にメモリ管理をしなければならない l  処理の順番に依存するバグを埋め込んでしまうことも

Combiner の設計

¢  combiner と reducer は同じメソッドシグネチャ（メソッド名、引数の数・順序・型、返り値の型、…）を共有 l  reducer が combiner の役割を果たすこともある

¢  combiner は最適化のために用いられるオプション l  アルゴリズムの正しさに影響を与えてはいけない l  0回、1回、複数回走らせてもよい

¢  例: 同じキーに関連付けられた全ての整数の平均を求める

平均値の計算: バージョン1

reducer を combiner として使えない理由は？

平均値の計算: バージョン2

どうしてこれは動かない？

平均値の計算: バージョン3

直った？

平均値の計算: バージョン4

combiner はまだ必要？

数え上げと正規化

¢  多くのアルゴリズムが相対頻度の計算に帰着される:

l  EMアルゴリズムだと、実際の頻度ではなく期待頻度

¢  これを含む大きなクラスのアルゴリズムも、複雑さが異なるだけで直観は同じ

¢  この直観から始めると…

∑==

')',(count),(count

)(count),(count)|(

BBABA

ABAABf

アルゴリズムデザイン: 実例

¢  テキスト集合の単語共起行列 l  M = N x N 行列（N = 語彙数） l  Mij: i と j がある文脈で共起した数

（具体的にはたとえば文脈＝文）

¢  何に使うの？ l  意味的な距離を測るために分布類似度を用いる l  意味的な距離は多くの言語処理タスクで役に立つ

MapReduce: 巨大な数え上げ問題

¢  テキスト集合の単語共起行列 = 巨大数え上げ問題のひとつ l  巨大な事象空間（語彙の数） l  たくさんの観測（数え上げそのもの） l  ゴール: 調べたい事象の統計量を保持する

¢  基本的なアプローチ l  Mapper が部分頻度を生成 l  Reducer が部分頻度を集約

効率的に部分頻度を集約するためにはどのようにすれば？

とりあえず: 「ペア」

¢  各 mapper は文を引数に取る。 l  共起する単語ペアを全て生成する l  全ペアに対し、emit (a, b) → count

¢  reducer はペアにひも付けられた頻度を合計する

¢  combiner を使おう！

ペア: 疑似コード

「ペア」分析

¢  利点 l  実装が簡単

l  理解しやすい

¢  欠点 l  たくさんのペアをソート・シャッフルしなければならない（上限値？） l  combiner を使う機会があまりない

「ペア」から「ストライプ」へ

¢  アイデア: ペアを連想配列にグループ化する

¢  各 mapper は文を引数に取る。

l  共起する単語ペアを全て生成する l  各単語に対し、emit a → { b: countb, c: countc, d: countd … }

¢  reducer は連想配列の要素ごとの合計を計算

(a, b) → 1 (a, c) → 2 (a, d) → 5 (a, e) → 3 (a, f) → 2

a → { b: 1, c: 2, d: 5, e: 3, f: 2 }

a → { b: 1, d: 5, e: 3 } a → { b: 1, c: 2, d: 2, f: 2 } a → { b: 2, c: 2, d: 7, e: 3, f: 2 }

+

ポイント: 賢く構築されたデータ構造

と部分的な結果を組み合わせる

ストライプ: 疑似コード

「ストライプ」分析

¢  利点 l  キー＝バリューペアのソートとシャッフルの回数を激減 l  combiner を効果的に使える

¢  欠点 l  実装が難しい l  裏で用いられるオブジェクトがもっと重たくなる l  事象空間のサイズという観点で、原理的な制約がある

クラスタサイズ: 38 コア データ: English Gigaword Corpus (v3) の Associated Press Worldstream (APW) から、 227 万文書（1.8 GB compressed, 5.7 GB uncompressed）

単語共起行列計算の「ペア」と「ストライプ」の比較

ストライプアルゴリズムにおけるクラスタサイズの影響

相対頻度の計算

¢  頻度から相対頻度を計算するには？

¢  なんでこれを計算したい？

¢  MapReduce でどのようにやる？

∑==

')',(count),(count

)(count),(count)|(

BBABA

ABAABf

f(B|A) の計算: 「ストライプ」を使えば簡単！

¢  簡単！ l  1パス目で (a, *) を計算 l  2バス目で直接 f(B|A) を計算

a → {b1:3, b2 :12, b3 :7, b4 :1, … }

順番を逆転させて考える

¢  共通するデザインパターン l  相対頻度の計算には周辺化された頻度が必要 l  しかし周辺化の計算には全ての頻度を知らなければならない l  バッファリングしたくない l  コツ: 周辺化された頻度が同時頻度の前に reducer に来るようにする

f(B|A) の計算: 「ペア」でも可能

¢  このようにするためには: l  mapper で各 bn のたびに余分に (a, *) を emit l  全ての a を同じ reducer に送る（partitioner を使う） l  (a, *) が最初に来るように（ソートの順番を定義する） l  異なるキー＝バリューペアをまたいで reducer 内で状態を保持

することが必要

(a, b1) → 3 (a, b2) → 12 (a, b3) → 7 (a, b4) → 1 …

(a, *) → 32

(a, b1) → 3 / 32 (a, b2) → 12 / 32 (a, b3) → 7 / 32 (a, b4) → 1 / 32 …

Reduce がメモリ上にこの値を保持

順番を逆転させて考える

¢  共通するデザインパターン l  相対頻度の計算には周辺化された頻度が必要 l  しかし周辺化の計算には全ての頻度を知らなければならない l  バッファリングしたくない l  コツ: 周辺化された頻度が同時頻度の前に reducer に来るようにする

¢  最適化 l  周辺化された頻度を集約するために、インメモリで combine するパ

ターンを適用する l  combiner を使うべき？

同期: ペア対ストライプ

¢  アプローチ 1: 同期を順序問題に落とし込む l  キーをソートして正しい計算順序にしておく l  キー空間を分割して各 reducer が適切な結果の部分集合を受け取

るようにしておく l  計算するために複数のキー＝バリューペアをまたいで reducer に状

態を保持する l  「ペア」アプローチで見た

¢  アプローチ 2: 部分的な結果を統合するデータ構造を構築

l  各 reducer が計算を完成させるために必要な全データを受け取る

l  「ストライプ」アプローチで見た

情報検索

MapReduce の基礎 MapReduce のアルゴリズムデザイン 情報検索 MapReduce を超えて

抽象的な情報検索のアーキテクチャ

文書 クエリ （検索語）

適合文書

表現（特徴量抽出） 関数

表現（特徴量抽出） 関数

クエリ（特徴量）表現 文書（特徴量）表現

比較関数 インデックス （索引）

オフライン オンライン 文書獲得

（例: ウェブクローリング）

MapReduce したい？

¢  インデクシング問題

l  スケーラビリティが重要

l  比較的速くないといけないが、リアルタイルである必要はない l  本質的にバッチ操作 l  差分をインクリメンタルに更新するのは重要かもしれないし、重要じゃ

ないかもしれない l  ウェブに関しては、クローリング自体が大きなテーマ

¢  検索問題 l  秒以下の応答時間でなければならない l  ウェブに関しては、いくつかの結果さえあればよい

MapReduce でバッチリ！

あまり嬉しくない。。。

2

1

1

2

1

1

1

1

1

1

1

転置インデックス（ストップワードは除去）

2

1

2

1

1

1

1 2 3

1

1

1

4

1

1

1

1

1

1

2

1

tf df

blue

cat

egg

fish

green

ham

hat

one

1

1

1

1

1

1

2

1

blue

cat

egg

fish

green

ham

hat

one

1 1 red

1 1 two

1 red

1 two

one fish, two fish Doc 1

red fish, blue fish Doc 2

cat in the hat Doc 3

green eggs and ham Doc 4

3

4

1

4

4

3

2

1

2

2

1

[2,4]

[3]

[2,4]

[2]

[1]

[1]

[3]

[2]

[1]

[1]

[3]

2

1

1

2

1

1

1

1

1

1

1

転置インデックス: 位置情報つき

2

1

2

1

1

1

1 2 3

1

1

1

4

1

1

1

1

1

1

2

1

tf df

blue

cat

egg

fish

green

ham

hat

one

1

1

1

1

1

1

2

1

blue

cat

egg

fish

green

ham

hat

one

1 1 red

1 1 two

1 red

1 two

one fish, two fish Doc 1

red fish, blue fish Doc 2

cat in the hat Doc 3

green eggs and ham Doc 4

3

4

1

4

4

3

2

1

2

2

1

MapReduce によるインデックス作成

¢  全文書で map する

l  term をキーとして、(文書番号, 単語頻度＝tf) を値として emit l  必要な情報（例: 単語の位置）があれば emit

¢  ソートとシャッフル: 単語で位置（ポスティング）をグループ化

¢  reduce l  ポスティングを集めてソート（例: 文書番号あるいは tf） l  ポスティングをディスクに書く

¢  MapReduce が重たい処理を全部面倒見てくれる！

1

1

2

1

1

2 2

1 1

1

1 1

1

1

1

2

MapReduce による転置インデックスの作成

1 one

1 two

1 fish

one fish, two fish Doc 1

2 red

2 blue

2 fish

red fish, blue fish Doc 2

3 cat

3 hat

cat in the hat Doc 3

1 fish 2

1 one 1 two

2 red

3 cat 2 blue

3 hat

シャッフルとソート: キーで値を集約

Map

Reduce

MapReduce を超えて

MapReduce の基礎 MapReduce のアルゴリズムデザイン MapReduce を超えて

MapReduce のホットトピック

¢  他のプログラミングモデルの探求

l  バッチ vs. リアルタイムデータ処理

¢  さまざまな実装（例: Microsoft DryadLINQ）

¢  MapReduce 自身がツールでもある

¢  Hadoop 生態系の拡大

¢  MapReduce と分散データベースの進化

高水準言語の要求

¢  Hadoop は大規模データ処理には適している l  ただ、なにをするにも Java プログラムを書かないといけないのは冗

長だし、遅い。。。 l  アナリストは Java を書きたくない（書けないことも）

¢  解決策: 高水準のデータ処理用の言語を開発する l  Hive: HQL は SQL のような言語 l  Pig: Pig Latin がデータフロー言語

Hive と Pig

¢  Hive: Hadoop のデータウェアハウス構築環境 l  クエリ言語は SQL の一種の HQL l  テープルはフラットファイルの形で HDFS に記憶 l  Facebook が開発し、現在はオープンソース

¢  Pig: 大規模データ処理システム l  データフロー言語の Pig Latin でスクリプトを書く l  Yahoo! が開発し、現在はオープンソース l  Yahoo! 内部のジョブのだいたい 1/3 は Pig

¢  共通するアイデア: l  大規模データ処理を行うための高水準言語を提供する l  高水準言語は Hadoop ジョブに「コンパイル」される

まとめ: 大規模データ処理の「哲学」

¢  スケール「アウト」する。（スケール「アップ」ではなく）

¢  データ中心の処理を行う

¢  データを順番に処理する。ランダムアクセスしない。

¢  シームレスなスケーラビリティ

Source: NY Times (6/14/2006)

データセンターこそがコンピュータ！ MapReduce = 適切なレベルの抽象化