社団法人 電子情報通信学会THE INSTITUTE OF ELECTRONICS,INFORMATION AND COMMUNICATION ENGINEERS

信学技報TECHNICAL REPORT OF IEICE.

広域ネットワークにおける計算機資源とネットワーク資源を考慮したHadoopタスク割り当て方式

松野 伴拓† Bijoy Chand Chatterjee† Nattapong Kitsuwan† 大木 英司†

Malathi Veeraraghavan††

岡本 聡††† 山中 直明†††

† 電気通信大学 情報理工学研究科 情報・通信工学科〒 182-8585 東京都調布市調布ヶ丘 1-5-1

†† Dept. of Electrical and Computer Engineering, University of Virginia, USA

††† 慶應義塾大学 理工学部 情報工学科E-mail: †{t.matsuno,bijoycc,kitsuwan,eiji.oki}@uec.ac.jp, ††mv5g@virginia.edu, †††okamoto@ieee.org,

††††yamanaka@ics.keio.ac.jp

あらまし 本論文では, 計算資源とネットワーク資源に応じた Hadoopタスク割当方式の性能を, Hadoopのシステムに実装し評価する. タスク割り当て方式は, 適切な分割比を用いて各ジョブをタスクへ分割し, サーバ処理性能とネットワーク資源に基づいて, スレーブサーバにタスクを割り当てる. 異種混合な Hadoopクラスタの場合は, 各スレーブサーバの処理能力に基いて, 低性能のスレーブサーバよりも高性能なスレーブサーバへより多くのタスクを与えるようなタスク割り当てを行う. つまり, 高性能のスレーブサーバが低性能のものよりも多くの処理を実行する環境を作り出す. テストベッドでの実験結果を用いて, タスク割り当て方式が有効であることを示す.

キーワード Hadoop、実装、ブロックサイズ、線形計画法

A Task Allocation Scheme in Hadoop Clusters Considering

Computational and Network Resources for Wide Area Networks

Tomohiro MATSUNO†, Bijoy CHAND CHATTERJEE†, Nattapong KITSUWAN†, Eiji OKI†,

Malathi VEERARAGHAVAN††, Satoru OKAMOTO†††, and Naoaki YAMANAKA†††

† Dept. of Communication Engineering and Informatics, The University of Electro-Communications

1-5-1 Chofugaoka, Chofu, Tokyo 182-8585 Japan

†† Dept. of Electrical and Computer Engineering, University of Virginia, USA

††† Dept. of Information and Computer Science, Keio University, Japan

E-mail: †{t.matsuno,bijoycc,kitsuwan,eiji.oki}@uec.ac.jp, ††mv5g@virginia.edu, †††okamoto@ieee.org,

††††yamanaka@ics.keio.ac.jp

Abstract Hadoop has swiftly been accepted in both industry and academia in order to offer enormous storage

for any kind of data, massive processing power and the capability to manage virtually jobs. This paper designs a

Hadoop system, which considers both slave server’s processing capacity and network delay for wide area networks

in order to reduce the job processing time. The demonstrated testbed results designate that the task allocation

scheme in our designed Hadoop system is effective.

Key words Hadoop, implementation, block size, linear programming

— 1 —Copyright ©201 by IEICE 6

This article is a technical report without peer review, and its polished and/or extended version may be published elsewhere. - 31 -

1. は じ め に

今日, ビッグデータ解析において, テラバイトやペタバイト規模のデータ処理が必要となってきている [1]. そのようなビッグデータ処理の効果的な方法が多くのユーザにとって必要である [2]. Hadoop [3] とは, 学術・産業分野にて共に急速に採用されているビッグデータ処理のフレームワークである.

Hadoop は Apache Software Foundation によって, データ分析やデータマイニングを行う目的で開発されたオープンソースのシステムアーキテクチャである [4,5]. Hadoopのモジュールは開発者がアプリケーションに焦点を合わすことができるように, 難しくなく簡易的に扱うことが出来る. これは分散システムの基本的なオペレーションのための考え方であり, 結果的にサービス提供者の Facebook, Twitter, Yahoo等にて利用されている [6].

Hadoopは管理者がサーバを追加することによって簡単にシステムのパフォーマンスを向上させることが可能なスケールアウトシステムを採用している. Hadoopは, (i) MapReduce,

(ii) Hadoop distributed file system (HDFS) という 2 つの要素から成り立っている. MapReduce [7–10] とは大規模クラスタ内で並列処理を行うフレームワークである. MapReduceの処理の流れは, 図 1 にて示されている. ユーザから依頼された処理を効率的に実行するために, Hadoop には効率的なタスクスケジューリングが必要である. それぞれ job と task とは,

Hadoopの異なる概念である [6]. ユーザが処理を依頼したとき,

Hadoopはジョブを作り出し, ジョブをキューに格納する. ジョブは並列に扱うことが可能ないくつかのタスクによって構成される. タスクは計算機の CPUへと割り当てられるとき, 実行される. ジョブからタスクへの分割は, システムリソースの効率的な利用を可能にする. HDFSは Hadoopのファイル管理の要素として実装されているファイルシステムである. HDFS [11,12]

は大きなファイルを高速な読み取り・書き込み操作のために, いくつかのブロックに分割して保管する.

図 1 Workflow of MapReduce.

従来の Hadoop フレームワーク [4, 5]では, 入力されたジョ

ブが同じ比率のタスクとして分割され, スレーブサーバに割り当てられている。もし計算機資源の性能が異なるのであれば,

全体の計算時間は, たとえ全体の計算機の数を増やしたとしても減少しない. つまり, 低性能な計算機が Hadoop クラスタに含まれる場合, Hadoop のメリットを適切に活かすことが出来ないのである.

この欠点を克服するために, T. Matsuno et al. [13, 14] はHadoop のジョブを計算機資源とネットワーク資源に基づいて,

適切なタスク比率に分割し割り当てるタスク割当方式を提案している. [14] では, 結果として性能が悪い計算機を使用した場合でも計算時間は低下している. 文献 [14] では, スレーブサーバの最大計算時間を最小化するという理論研究が行われており,

シミュレーションにてその効果が検証されている. それぞれのスレーブサーバやネットワークの能力はシミュレーションを行うという目的で, 仮定のもと実施されている. 文献 [14] にて提案されている方式は, テストベッドを用いた実験での評価は行われていない.

本論文は, Hadoopによる分散処理を異種混合な Hadoop クラスタにおいて, 尚かつネットワークの状況に差がある広域ネットワークの場合においても効率的に処理できるタスク割り当て方式を実装し評価する. デザインする Hadoopシステムのタスク割り当て方式は, それぞれのジョブを計算機の性能とネットワーク資源を基に適切な比率に分割し, スレーブサーバへ割り当てる. 本稿は, [15] の内容を拡張したものである. 具体的には, スケールアウトシステムの実験規模を拡張している. [15]では, スレーブサーバを 5 台用いて性能評価を行っているが, 本稿では, 13台のスレーブサーバを使用し, その内 3台は遠隔地に設置しているスレーブサーバを使用する. また, ネットワークの影響を考慮するため, 電気通信大学, NICT, 慶應大学, 米国のバージニア大学間に L2VPNを構築している. 分割比率をいくつかの場合に分けて, 提案方式を処理時間の観点から評価する. 実験結果がスレーブサーバの処理能力やネットワークの状況に応じて, タスク割り当てのブロックサイズを変更することにより, 分散処理全体での処理時間を短縮することを示す.

2. Hadoop の概要

Hadoop とは分散処理とデータストレージを実現するためのオープンソースソフトウェアである. Hadoop では性能向上の方法として, サーバを追加することで能力を増強させるスケールアウトの方式を採用している. スケールアウトを実施することで, 数千台規模まで能力増強が可能である. また、Hadoop の主な構成要素として, 「HDFS」という分散ファイルシステムと「MapReduce」という分散処理フレームワークの 2 つから成り立っている.

2. 1 MapReduce

MapReduce [7,8,16]とは, 並列可能な処理に関して, 多数のコンピュータ・ノードの集合であるコンピュータ・クラスターやグリッドを用いて並列処理させるためのフレームワークである.

MapReduce のジョブ [7] は, クライアントが実行を要求する作業単位であり, Hadoop はジョブを並列処理可能なタスクに分

— 2 —- 32 -

割して実行する. そして, このタスクを空いた CPU に順次割り当てることにより, 計算機資源を効率よく利用し高速に処理を行う. ジョブの実行プロセスを制御するノードは 2種類存在する. ジョブのスケジューリングを行ったり, ジョブの進捗状況を把握するなど, ジョブの実行全体を管理する jobtracker [17] と,

タスクを実際に実行する tasktracker [18] である. MapReduce

では, データの処理を map 処理と reduce 処理の 2段階に分けて行う [8]. map 処理は, 分割されたデータの断片に何らかの加工を施し, 必要な情報を抽出する. reduce 処理では, map 処理で抽出した情報を束ねて, データ全体についての処理結果を返す. MapReduce フレームワークには, 分散処理に必要とされる共通機能（巨大なファイルを分割して多数のスレーブ・サーバに配布する機能, 処理結果を集約する機能, 障害が発生した場合に処理をやり直す機能等）がシステム側にあらかじめ実装されている. MapReduce が実装されている Hadoop により, 処理する場所にデータを移動させることなく, 置かれている場所で処理を行うことができる. このため, データストレージと処理機能がクラスタ内の同じ物理ノードに置かれることになる. 大規模なデータ処理を行う場合は, map と reduce の処理内容を定義して MapReduce システムに処理を依頼する. MapReduce

システムはデータを分割し, 必要な数のコンピュータを使って並列に map と reduce を実行し, 処理結果を返す.

2. 2 Hadoopの問題点Hadoop は, 同一性能の計算機群を同一クラスタ内で使用す

ることを前提に設計がなされているため, 異種混合な Hadoop

クラスタ内での処理において, タスクを割り当てする際にはタスクの割り当て量が等しく分割される. このため, Hadoop の分散処理を性能の異なる計算機群や, ネットワークの遅延やスループットに差異がある環境下では, 各スレーブノードの処理時間に差が出てくることにより全体での処理時間が長くかかってしまうため非効率である.

図 2 に示す 2 台の高性能スレーブノードと 2 台の低性能スレーブノードを組み合わせた環境において, 割り当てるタスクサイズを同一にした状態で分散処理を行った. 実験の結果を図 3

に示す. この結果から, 性能差のあるスレーブノードを追加した場合に, 分散処理時間が増加する場合があることが示された.

3. 異種混合クラスタ内での計算機資源に応じたタスク割り当て方式

3. 1 提案方式の概要[14] にて提案されているタスク割当方式は, 性能の悪い計算

機資源を使用することによって, 計算時間の観点から処理能力を最大化するものであった. もし複数の異なる性能のクライアントサーバを使用するならば, ジョブを計算機資源とネットワーク資源にしたがって適切なタスク比率に分割することが, 全体の計算処理時間を削減することになる. 処理時間の削減は全体のスレーブサーバの最大計算時間を最小化することで達成される。[14] にて提案されている方式は, 計算機資源にしたがってジョブからタスクへの適切な分割比率を決定している.

図 4 は, 計算機資源とネットワーク資源に応じてジョブを適

図 2 Hadoop ノード構成

0

5

10

15

20

25

30

35

1 2 3 4

Proc

essi

ng ti

me

(min

)

Number of slaves

図 3 同一ブロックサイズ分散処理の処理時間

表 1 使用されている記号リスト記号 意味I 1 つのジョブにおけるタスクの集合r 全てのタスク i ∈ I における最大計算時間xi 範囲が 0 <= xi <= 1 のタスク i ∈ I の分割比率mi 計算機資源 i を使うか否か, つまり xi > 0 のと

き mi = 1 , その他 mi = 0

ci 計算機資源 i の計算処理能力D ネットワーク遅延,つまりD = {d1, d2, d3, ..., dN}R マスターノードからスレーブノードへのネ

ットワークを経由した経路, つまり R =

{χ1, χ2, χ3, ..., χN}M 使用可能なスレーブノードの最大数f(xi, ci, di) タスク i ∈ I の計算処理時間U 十分大きい数

切なタスクサイズへ分割し, 異なる比率のタスクをスレーブサーバへ割り当てる方式の概要である.本線形計画問題で使用されている記号のまとめが表 1 である.

3. 2 数式モデルこの項では, 提案されている最適化問題 [19] を示す. 目的は,

スレーブサーバの最大計算時間を最小化することである. 目的関数は以下で定義されている.

— 3 —- 33 -

1

2

M

3

Servers Job

Network

図 4 紹介されているタスク割当方式の概要

min r (1a)

s.t. D = y(R) (1b)

f(xi, ci, di) <= r ∀i ∈ I (1c)

∑

i∈Ixi = 1 (1d)

∑

i∈Imi <= M (1e)

xi <= mi ∀i ∈ I (1f)

mi <= Uxi ∀i ∈ I (1g)

0 <= xi <= 1 ∀i ∈ I (1h)

mi ={0, 1} ∀i ∈ I (1i)

多数の計算機資源同士で分散処理するために, 適切な経路選択が必要である。式 (1b) はマスターサーバとスレーブサーバの間でのネットワーク遅延が適切な経路選択に依存するものだということを示している. 式 (1c) はタスク i の計算時間が最大計算時間 r を超えないことを示している. タスク i の計算時間 f(xi, ci, di) ∀i ∈ I を縮小するために, 計算機資源とネットワーク資源に応じた適切な比率でジョブを分割する. 式 (1d)

は分割したタスクの割合の合計が 1 となることを示している.

式 (1e) は使用されるスレーブサーバの合計数が M 以下となることを示している. 式 (1f) と (1g) は線形計画法で xi > 0

のとき mi が 1, xi = 0のとき mi が 0となることを表している. 式 (1h) が示すのは, 分割比率が 0から 1の間であることである. 最後の式 (1i) はmi が 0もしくは 1であることを表している.

4. Hadoopシステムの構築

4. 1 Hadoopシステムの構造図 5 は, マスターノードとスレーブノードの間で経路構築

する概要を示している. OpenFlow スイッチが両サイドに設置されており, それらは Software-Defined Network (SDN) コントローラに接続されている. SDN コントローラは 経路選択の計算を行うためのモジュール: Path Computation Element

(PCE) [20] に繋がっている. マスターノードと PCE は適切なジョブ・タスクスケジューリングを行うために, Hadoop スケジューラに接続されている. また, 適切な経路選択のために,

マスターノードが Hadoopクラスタと通信するとき, 両サイドに位置する 2 つの SDN スイッチは光パス, レイヤ 2 Virtual

Private Network (VPN), もしくは インターネットのどれかを経由して接続される. SDN コントローラはマスターノードからスレーブノードへの経路を動的に決定する. そして、マスターノードはスレーブノードと通信を行うのである. それぞれのスレーブノードは自身のための SDN スイッチを保持し, それらはマスターノード側に設置されている SDN スイッチに繋がっている. PCE はトラヒックの状況に応じた経路選択を行うものである.

InternetSDN SW SDN SW

Master Slave

L2 VPN

Optical path

SDN controller

PCEHadoop scheduler

Slave

SDN controller

PCE Network manager

図 5 マスターノードとスレーブノード間での経路構築の概要

ジョブを計算機資源とネットワーク資源にしたがって適切なタスクサイズに分割する為に, 我々は Hadoopシステムを実装した. ソースコード [21] には、数多のディレクトリが存在している. 例えば, client, mapreduce, HDFS, や assemblies などである. ここで HDFS ディレクトリ内にある jobtracker とtasktrackerのコンフィグレーションに焦点を当てた. タスクのブロックサイズを変更するために,“DFSConfigKeys.java” というファイルを修正した.“DFSConfigKeys.java” 内に記されているデフォルトのタスクのブロックサイズは 64 MB である.

図 6 は修正を行った“DFSConfigKeys.java” ファイルを表している. 黒く縁取られた部分のコードが修正箇所である.

4. 2 実験環境の構築VMware Player [22,23] を利用して, 14台の計算機が存在す

る仮想環境を構築した. 14 台の計算機内で、図 7 に示すように, 1台はマスターサーバ, 残り 13台はスレーブサーバとして設定を行った. この実験では, 図 5 の 1 部分を、図 7 として構築した. ホスト OSとして Windows 7 を使用した。ゲストOS として Ubuntu 14.04 を使用した. この実験では Hadoop

のジョブとして円周率計算を行うプログラムを使用した. 1台のマスターサーバと 13台のスレーブサーバで 1億桁までの円周率を決定するものである.

— 4 —- 34 -

図 6 “DFSConfigKeys.java” 内の修正したソースコード

slave01

master01

slave02

slave03

slave04

slave05

slave06

slave07

slave08

slave09

slave10

UEC

Slave11 at NICT

Slave12 at Keio

Slave13 at UVA

図 7 ネットワーク図

提案されているタスク割当方式と, 使用するスレーブサーバの計算能力を考慮せずにジョブを全て同じ大きさに分割して割り当てる従来方式を比較するために, 以下の 5つのケースに分けて実験を行った. Case 1: 従来の Hadoop システムにて全て同一処理能力の Hadoop クラスタ. 計算機に割り当てられるタスクのブロックサイズは全て 64 MB である. Case 2: 従来のHadoop システムにて Hadoop クラスタ内で計算機に性能差がある場合. タスクのブロックサイズは全て 64 MB. Case 3: 提案方式を実装した Hadoop システムにおいて Hadoop クラスタ内で計算機に性能差がある状況. タスクのブロックサイズは,

1台目と 2台目は 128 MB, 3台目と 4台目は 64 MB とブロックサイズが計算機毎に分かれている. Case 4: 提案方式を実装した Hadoop システムにおいて Hadoop クラスタ内で計算機に性能差がある場合. タスクのブロックサイズは, 1台目と 2台目は 64 MB, 3台目と 4台目は 32 MB. Case 5: 提案方式を実装した Hadoop システムにおいて Hadoop クラスタ内で計算機に性能差がある場合. タスクのブロックサイズは, 1台目と 2

台目は 128 MB, 3台目は 64 MB, 4台目は 32 MB. 図 8 にて,

それら 5つの実験ケースを示している.

4. 3 異なるキャンパス間での実験電気通信大学, 慶應大学, NICT,米国のバージニア大学間にレ

イヤ 2ネットワークを構築した. 電通大は SINET5と JGN-X

を経由して NICTに接続している. また, 慶應大学へは NICT

を経由して接続されている. バージニア大学へは慶應大学を

図 8 5 つのケースの実験の概要図

経由して接続されている. このネットワークでは各所へダイレクトに L2ネットワークを接続していない. この構築の理由は,

UEC から UVA への接続にてネットワーク遅延などが含まれるような実験環境を構築するためである. 図 9にて, 概要図を示す.

Slave node

Ten slave nodesMaster node

Slave node

Slave node

UEC

NICT

Keio

UVA

Access point

Access Point

l d

l

SINET 5

JGN-X

JGN-X

JGN-X

INTERNET 2

図 9 ネットワークトポロジー

4. 4 5台のスレーブサーバでの実験結果この項では, 我々が実装した提案方式の実験結果を計算時間

の観点から述べる. 図 10 は, ケース 1, 2, 3, 4, 5 を比較したグラフである. ケース 1では, スレーブサーバの数を増やすほど, 計算時間は減少している. これは, 従来のタスク割当の方式が適切なブロックサイズの為に Hadoop のクラスタ内でスレーブサーバに, 負荷が正しく分配されているからである. 反対に

— 5 —- 35 -

ケース 2の場合は, スレーブサーバを 3台, 4台と増やした時,

計算時間は増加している. これは 3 台目と 4 台目のスレーブサーバへの負荷が大きく, タスク割当が適切に行われていないためである. つまり, Hadoop のスケールアウトが 4台の計算機で適切に行われていないことを示している. ケース 3ではこの問題を解決している. ジョブを計算機資源にしたがって適切なタスクサイズに分割するケース 3では, スレーブサーバへ異なるブロックサイズのタスクを割り当てた. ケース 3の計算時間は, スレーブサーバを増やせば増やすほど減少している. 全て同一処理能力の Hadoop クラスタにて, 従来の Hadoop システムを使用した時, ケース 2では計算時間が増加していた. 従来方式の性能は, スレーブサーバが 3台, 4台目と使用された時低下している. ケース 4も同様にスレーブサーバを増やせば増やすほど, 計算時間は減少している. ケース 5の実感環境での結果は, スレーブサーバの増加に伴い計算時間は短縮している.

これら 3つのケースは, スレーブサーバ内で提案方式を実装した Hadoop が適切なタスク割当による負荷の分散を行っているからである, さらに, ケース 4では, Hadoop クラスタ内で計算機に性能差がある他のどの場合よりも計算時間が短い. つまり,

タスクの割当が 4台のスレーブサーバ内で最も適切に行われている. したがって, 低性能の計算機へより少ないタスクを割り当てることで, 提案方式は Hadoop の利点を活かしていることがわかる.

0

5

10

15

20

25

30

35

1 2 3 4

Proc

essi

ng ti

me

(min

)

Number of slaves

Case 1

Case 2

Case 3

Case 4

Case 5

図 10 5 つのケースを比較した実験結果

4. 5 13台のスレーブノードを用いた実験結果この項は, 前項のケース 1, 2, 4 において既存の Hadoop シ

ステムと提案する Hadoopシステムを比較し評価する. ここでは, 1 台のマスターノードと, 13 台のスレーブノードにて実験を行って結果を評価する. マスターノード 1台と, 最初の 10台は電通大に位置する. 11台目は NICT, 12台目は慶應大学, 13

台目はバージニア大学にそれぞれ設置されている.

図 11 は実装した Hadoopシステムの実験結果を示している.

ケース 1では, 他拠点の計算機が追加されたとき, 計算時間は減少している. これは各スレーブノードへ適切なタスク割当が行

われているからである. ケース 2は, 異種混合なクラスタ環境である; 3 番目以降の計算機が低性能のマシンにすることで異種混合環境を作り出している. このケースでは以下の 3種の特徴があった. (i) 3番目から 6番目を追加したとき, 計算時間は増加している. これは 3番目から 6番目のスレーブノードが高負荷となっているからである. つまり, 1,2番目のノードは早く処理が終わっても, 高負荷によって処理が遅い他のノードの処理の終了を待つ必要があるため, 処理時間が増加していると考えられる. (ii) 7番目から 10番目を追加した時, 計算時間は減少している. これは, 先ほどの処理がその他の追加されたノードにも分配されて, 1台当たりの処理が減るため, 結果的に処理時間が減少している. (iii) 11番目から 13番目へスレーブノードを追加した時, 計算時間は増加している. これはネットワークによる遅延の影響だと考えられる. ケース 4は, 提案方式を実装した Hadoopシステムを用いている. 1台目と 2台目へは64MB, その他の 3-13台目へは 32MBとしてタスク量を調節している. 適切なタスク割り当てが行われている他拠点のスレーブノードの追加によって, 全体の計算時間が減少していると考えられる.

0

5

10

15

20

25

30

35

1 2 3 4 5 6 7 8 9 10 11 12 13

Proc

essi

ng ti

me

(min

)

Number of slaves

Case 1 Case 2 Case 4

図 11 ケース 1, 2, 4 の結果の比較

5. ま と め

本論文は, Hadoop による分散処理をスレーブノードの処理能力に差があり, 尚且つネットワークの状況に差がある場合においても, 効率的に実行するタスク割り当て方式を実装し評価した. Hadoop のソースコードを修正することにより, 実装環境でスレーブノードの処理能力に応じてタスク割り当てのブロックサイズを変更した. 実験環境での性能評価より, 提案方式は分散処理全体での処理時間を短縮することを示した.

謝 辞

本研究の成果は，国立研究開発法人情報通信研究機構，及び，NSF grant (CNS-1405171), USAの委託研究の一部である．

文 献[1] S. Manikandan and S. Ravi, “Big Data Analysis Using

— 6 —- 36 -

Apache Hadoop,” in IT Convergence and Security (IC-

ITCS), 2014 International Conference on, Oct. 2014, pp.

1–4.

[2] F. Dong and S. G. Akl, “Scheduling algorithms for grid com-

puting: State of the art and open problems,” Tech. Rep.,

2006.

[3] “Apache Hadoop,” http://hadoop.apache.org/, Last Ac-

cessed: 2016-01-24.

[4] M. Adnan, M. Afzal, M. Aslam, R. Jan, and A. Martinez-

Enriquez, “Minimizing Big Data Problems using Cloud

Computing Based on Hadoop Architecture,” in High-

capacity Optical Networks and Emerging/Enabling Tech-

nologies (HONET), 2014 11th Annual. IEEE, 2014, pp.

99–103.

[5] “Cloudera Impala Project,” http://impala.io/, Last Ac-

cessed: 2016-01-24.

[6] X. Xu, L. Cao, and X. Wang, “Adaptive Task Schedul-

ing Strategy Based on Dynamic Workload Adjustment for

Heterogeneous Hadoop Clusters,” Systems Journal, IEEE,

vol. PP, no. 99, pp. 1–12, 2014.

[7] B. Palanisamy, A. Singh, and L. Liu, “Cost-effective Re-

source Provisioning for MapReduce in a Cloud,” IEEE

Transactions on Parallel and Distributed Systems, 2014.

[8] Y. Zhao, J. Wu, and C. Liu, “Dache: A data aware caching

for big-data applications using the MapReduce framework,”

Tsinghua Science and Technology, vol. 19, no. 1, pp. 39–50,

Feb. 2014.

[9] H. Jung and H. Nakazato, “Dynamic Scheduling for Spec-

ulative Execution to Improve MapReduce Performance in

Heterogeneous Environment,” in Distributed Computing

Systems Workshops (ICDCSW), 2014 IEEE 34th Interna-

tional Conference on, June 2014, pp. 119–124.

[10] J. Hsiao and S. Kao, “A usage-aware scheduler for im-

proving MapReduce performance in heterogeneous environ-

ments,” in Information Science, Electronics and Electrical

Engineering (ISEEE), 2014 International Conference on,

vol. 3, April 2014, pp. 1648–1652.

[11] T. White, Hadoop: The Definitive Guide. O’Reilly Media,

Inc., 2012.

[12] B. Martin, “SARAH-Statistical Analysis for Resource Allo-

cation in Hadoop,” in Trust, Security and Privacy in Com-

puting and Communications (TrustCom), 2014 IEEE 13th

International Conference on. IEEE, 2014, pp. 777–782.

[13] T. Matsuno, B. C. Chatterjee, E. Oki, S. Okamoto, N. Ya-

manaka, and M. Veeraraghavan, “”Task Allocation Scheme

for Hadoop in Campus Network Environment”,” in IEICE

Society Conference, Sendai, Japan, pp. B–12–20.

[14] ——, “”Resource Allocation Scheme for Hadoop in Campus

Networks”,” in 2015 21st Asia-Pacific Conference on Com-

munications (APCC) (APCC 2015), Kyoto, Japan, 2015,

pp. 596–597.

[15] ——, “”Task Allocation Scheme Based on Computational

and Network Resources for Heterogeneous Hadoop Clus-

ters”,” in 2016 IEEE 17th International Conference on

High Performance Switching and Routing (HPSR) (IEEE

HPSR’16), Yokohama, Japan, 2016, pp. 200–205.

[16] N. Singh and S. Agrawal, “A review of research on MapRe-

duce scheduling algorithms in Hadoop,” in Computing,

Communication Automation (ICCCA), 2015 International

Conference on, May 2015, pp. 637–642.

[17] K. Yamazaki, R. Kawashima, S. Saito, and H. Matsuo, “Im-

plementation and Evaluation of the JobTracker Initiative

Task Scheduling on Hadoop,” in Computing and Network-

ing (CANDAR), 2013 First International Symposium on,

Dec. 2013, pp. 622–626.

[18] J. Manjaly and V. Chooralil, “TaskTracker Aware Schedul-

ing for Hadoop MapReduce,” in Advances in Computing

and Communications (ICACC), 2013 Third International

Conference on, Aug. 2013, pp. 278–281.

[19] E. Oki, Linear Programming and Algorithms for Commu-

nication Networks. CRC Press, 2013.

[20] Le Roux, J-L, “Path Computation Element Communica-

tion Protocol (PCECP) Specific Requirements for Inter-

Area MPLS and GMPLS Traffic Engineering,” IETF RFC

4927, June 2007.

[21] “Apache Hadoop source code,” http://www.apache.org/dyn/closer

hadoop/common/hadoop-2.7.1/hadoop-2.7.1-src.tar.gz/, Last

Accessed: 2016-01-24.

[22] M. Ishii, J. Han, and H. Makino, “Design and Performance

Evaluation for Hadoop Clusters on Virtualized Environ-

ment,” in Information Networking (ICOIN), 2013 Inter-

national Conference on. IEEE, 2013, pp. 244–249.

[23] “VMware solution,” http://www.vsolution.jp/, Last Ac-

cessed: 2016-01-24.

— 7 —- 37 -