• 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

あなたにお薦め

連載新着

連載目次を見る

今のおすすめ記事

  • 【IoTで快適オフィス】

    二酸化炭素濃度まで見える化、IoTで「快適空調」

     トイレや会議室と並んで、社員の不満が出やすいオフィス設備の一つが空調機器だ。温度や湿度など空気の状態は部屋の人数や動きによって変化しやすく、感じ方も人によって異なる。IoTの技術を使って空気の状態などを見える化し、空調設備などの制御を最適化するシステムの開発が活発になってきた。

  • 【記者の眼】

    「空気を読む」ばかりでは強くなれない

     「空気を読めよ」。こんな言葉で失言や失態を指摘された記憶はあるだろうか。器用だったり人好きのする性格だったりすれば、記憶にないかもしれない。筆者もときどき言われるが、あまり気にしていない。

ITpro SPECIALPR

What’s New!

経営

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

クラウド

運用管理

設計/開発

サーバー/ストレージ

クライアント/OA機器

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

セキュリティ

もっと見る