• BPnet
  • ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • PR

  • PR

  • PR

  • PR

  • PR

ITインフラReport

分散処理フレームワーク「Hadoop 2」(後編)

Hadoop v1の三つの問題

小沢 健史=日本電信電話、猿田 浩輔=NTTデータ、山下 真一=NTTデータ 2014/12/11 日経SYSTEMS
出典:日経SYSTEMS 2014年4月号pp.64-67
(記事は執筆時の情報に基づいており、現在では異なる場合があります)
目次一覧

 Hadoop バージョン1(v1)の問題点を見ていこう。大きく三つの問題がある。うち二つは、各マシンのリソースを管理しているJobTrackerに起因するものだ。

 一つめは、MapReduce以外の分散処理フレームワークを同居させて利用する場合のリソース管理の問題だ。Hadoopの利用が進み、MapReduceに向かない処理がわかってきた。例えば、グラフ処理や機械学習など MapReduceを繰り返し実行するような計算で、分散ファイルシステムに毎回アクセスが生じて性能が出ない。

 そのため、MapReduceとは異なる分散処理フレームワークが多く提案されている。例えば、繰り返し計算を効率的に実行できる「Apache Spark」や、集約演算を高速に実行できる「Cloudera Impala」および「Presto」だ。また、ストリーミング処理向けには「Apache Storm」がある。いずれもオープンソースで提供されている。

 これらの分散処理フレームワークは用途に応じて使い分けることが望ましい。例えば、長時間かかるバッチ処理にMapReduceを使い、アドホッククエリーにはCloudera Impalaを、機械学習など反復処理にはApache Sparkを利用する。このように使い分ける場合、HDFSに保存されている大量データの移動を抑えるにはMapReduce、Cloudera Impala 、Apache Sparkを同一マシンに配置する必要がある。

 しかし、同一マシンに配置することによって新たな問題が生じる(図1)。MapReduce以外のフレームワークも、JobTracker相当のリソース管理機能を独自に備え、独立してリソース管理を行っているので、全体の計算リソースの利用効率を把握できないのだ。

図1●複数の分散処理フレームワークを利用する問題点
[画像のクリックで拡大表示]

ここから先はITpro会員(無料)の登録が必要です。

次ページ 二つめの問題はスケーラビリティーの限界だ。Job...
  • 1
  • 2
  • 3
  • 4
  • 5

あなたにお薦め

連載新着

連載目次を見る

今のおすすめ記事

ITpro SPECIALPR

What’s New!

経営

アプリケーション/DB/ミドルウエア

クラウド

運用管理

設計/開発

サーバー/ストレージ

クライアント/OA機器

ネットワーク/通信サービス

セキュリティ

もっと見る