Skip to content

DNET_Hadoop

Jump to bottom
nishi_74322014 edited this page Sep 11, 2026 · 1 revision

Hadoop

概要

  • Apache Hadoopは
    • Javaで書かれている。
    • 数千ノードおよびペタバイト級の分散処理を支えるOSSフレームワーク。
    • Google MapReduceおよびGoogle File System(GFS)論文に触発されたもの。
    • 実行プラン作成の観点において、手続き型言語と宣言型言語の中間的なもの。

※ 参考：

Hadoop MapReduce（概要）

特性（MapReduce）

  • ワークロード

    • 非構造化データを対象としたETL（Extract-Transform-Load）処理を想定。
    • 並列データベースの構造化データに対する分析クエリのような処理は想定していない。

  • 高い

    • 耐障害性
    • スケーラビリティ

  • 抽象化インターフェース

構成（MapReduce）

処理系（MapReduce）

  • 複数の計算機上で効率的に処理を行う、
    データ処理用のプログラミング・モデル

  • プログラミング・モデルが動作する処理系

Hadoop YARN（概要）

  • Hadoop YARN（Yet Another Resource Negotiator）
  • Hadoop 2.2から利用可能なリソース管理コンポーネント

特性（YARN）

旧管理コンポーネントとの違い

構成（YARN）

マスタ・スレーブ型の構成

処理系（YARN）

  • マスタも高可用（HA）構成を取ることができる。
  • マスタが任意のタイミングで切り替わっても動作が停止しない
    • マスタが保持している管理情報は投入されるジョブ数に比例して増加はするが、
    • 管理情報（ジョブの投入状況および進捗状況の変更）を Apache ZooKeeperに保持して捌く。

詳細

リソース管理基盤システム

計算リソースを管理する基盤システム（リソース管理基盤システム）

懸念

計算機クラスタを複数用いることは必ずしも容易ではない。

  • １つの計算機クラスタ上で複数の処理系を用いる場合
    複数の処理系の間で計算資源（計算リソース）を分離できない

  • 処理系毎に計算機クラスタを用意する場合

    • データの一貫性の管理や運用による手間が余計にかかる。
    • データが巨大である場合、計算機クラスタ間におけるデータの
      移動や同期による性能的なオーバーヘッドが大きくなる。

方式

  • Apache Mesos、Apache YARN、Google Borgが
    広く普及しつつあり、いずれもマスタ・スレーブ型のアーキテクチャを採る。

  • マスタ・スレーブ型は、

    • スケーラビリティよりも一貫性や単純さを重視する傾向がある。

    • 反面、マスタが

      • 単一障害点となり可用性が低下する場合
      • ボトルネックとなり高いスケーラビリティが実現できない場合

    がある。

機能（リソース管理基盤システム）

（マスタ・スレーブ型の機能概要）

  • マスタ

    • スレーブからクラスタ全体の計算リソースの情報を収集する。
    • その情報を元に、クライアントからの計算リソース要求に応じ
      どのスレーブのリソースを確保するかをスケジューリングする。

  • スレーブ
    スレーブが稼働する各ローカルノードが保持する計算リソースを管理する。

    • 現在使用中の計算リソースと未使用の計算リソースを逐次マスタに報告する。
    • マスタからの計算リソースの要求に応じて計算リソースを確保する。

Hadoop MapReduce（詳細）

耐障害性設計

  • 分散ファイルシステムのレプリケーションによりブロックの高い可用性を実現。
  • 中間データを二次記憶に適宜書き出すことにより、ジョブのリランが可能。

スケーラビリティ設計

  • ディスク入出力性能を最大限に活用する。

    • 大きなブロック単位の入出力
      従来のNFSなどの分散ファイルシステムと比較し、
      高いシーケンシャルアクセス性能を活用できる。

    • 無共有型のアーキテクチャ

      • 並列ディスク走査
      • 高いスケーラビリティを実現可能

  • ネットワーク入出力を最小限に抑える。

    • 近年におけるコモディティサーバでは、
      ネットワークスイッチのI/O性能が各計算機のI/O性能よりも低い。

    • 従って、種々の効率化技法が用いられる。

      • 転送データ圧縮

      • 集約処理
        ・通常の処理
        　Map側で集約キーによって出力データを分割、
        　ネットワークを介して分配し、Reduce側でキー毎の集約を行う。

        ・可換則と結合則を満たす集約処理
        　Map側で集約処理（部分集約）を行い、
        　ネットワークへのデータ転送量の削減を試みる。

抽象化インターフェース設計

  • map()とreduce()なる2つの関数だけをプログラマに定義させる。
  • その他の処理はすべて処理系で行う。

Hadoop YARN（詳細）

課題

  • クラスタ規模の拡大
    Hadoop 1系までのMapReduceエンジンにおける１つのマスタ（JobTracker）が
    以下の「クラスタのリソース管理」を担当する必要があったため、
    負荷が大きく、Hadoopクラスタの台数は1000台程度が限界であった。

    • クラスタ内で実行されるMapReduceジョブのスケジューリング
    • MapReduceジョブの各タスクに対する入力データの割り当てや進捗管理

  • MapReduce以外の分散処理の実行
    Hadoopで分散処理するためには、必ずMapReduceの仕組みに当てはめる必要があった。

    • MapReduceが2回以上連続するような処理を実行する場合、
      • 前段のMapReduceジョブの処理結果をHDFSに書き込み、
      • それを後続のMapReduceで読み込む、という流れになる。
    • ここでHDFSに中間データを書き込むため、処理が非効率である。
      多段のMapReduceとなるような処理を高速化するために、
      MapReduceフレームワークとは異なる分散処理が必要であった。

  • リソース管理の効率化

    • Hadoop 1系までのMapReduceエンジンにおけるスレーブ（TaskTracker）ではMapタスク用、
      Reduceタスク用にそれぞれスロットが用意されており、そこにMapReduceの各タスクが割り当てられる。
    • ここで、Mapタスク用のスロットに空きがない場合は、Reduceタスク用のスロットに空きがあったとしても
      Mapタスクをこれ以上割り当てることができず、TaskTrackerのリソース使用率が低下する問題があった。

機能（YARN）

動作フロー

スケジューリング・アルゴリズム

  • FIFO（First-In-First-Out）
    投入された順番にジョブを実行する。

    • スケジューリングの挙動が運用者にとって理解しやすい。
    • 投入されるジョブの数に比例して、後のジョブの実行完了時間が遅くなる。

  • Fair
    稼働中のアプリケーションそれぞれに平等にリソースを配分する。

    • ジョブは、投入されたジョブの順番に関わらず計算リソースを利用できる。
    • 特定の条件にマッチしたジョブの優先順位を上げることができる。

  • Capacity
    グループ毎にリソースを配分する。

    • グループごとに運用者が定義した割合でリソースを分配できる。

    • 以下の状況を回避できる。

      • 特定の組織が計算リソースを占有してしまう。
      • 優先順位の低いアプリケーションが大量に立ち上がることにより優先順位の高いジョブが動作できない。

アーキテクチャ

Hadoopは、以下のモジュールによって構成されている。

Hadoop Common

他のモジュールから共通して利用されるライブラリ群。

Hadoop MapReduce

  • MapReduceの実装。

    • 可能な限り入力データを保持するDataNodeと同一ノードでMapタスクが実行されるようにスケジューリングされる。
    • これにより、大規模データ処理においてもネットワークの負荷を抑えることが可能である。

  • JobTracker、TaskTrackerによるMapReduceはMRv1と呼ばれる。

  • Hadoop 2系以降は、MRv1をサポートしていない。
    YARN上でMapReduceが動作し、MRv2と呼ばれる。

ファイル・システム

HDFS以外のファイル・システムもサポートしている。

  • Amazon Simple Storage Service (S3)
  • OpenStack Swift
  • Microsoft Azure
  • FTP、HTTP、およびHTTPS経由で
    アクセス可能なファイル・システム

MRv1

MapReduceエンジンはひとつのJobTrackerを持ち、
クライアントはこのJobTrackerに向けてMapReduceジョブを投入する。

MRv2

Hadoop Distributed File System (HDFS)

HDFS：Hadoop独自の分散ファイル・システム。

  • Googleの分散ファイルシステム、Google File System(GFS)のクローン

  • シンプルなアーキテクチャで、膨大なデータ量をライトワンスで格納

  • データスループット指向で、低レイテンシーではない。

    • 大きなファイルを複数のブロック単位(デフォルトで128MB)に分割して、それらを複数のノードにまたがり格納する。

    • そのブロックの複製（レプリカ）を複数の異なるノードに格納することで信頼性を確保している（標準で3重化、RAID不要）。

  • HDFSはマスタ・スレーブ型の構成

  • HDFSクライアントを使ってアクセスする。
    HTTP、FTP、Fuseなどからもアクセスできる（専用のHDFSクライアント経由）。

  • 通常のFSにマウントできなかったが、Hadoop 2.2以降はNFSv3マウントに対応。

NameNode

マスタの役割を担当する。

  • HDFSに関するメタ情報(ファイルとブロックの対応関係など)を保持し、各DataNodeが実データをブロック単位で保持する。

  • 任意のDataNodeが故障した場合は、自動でそれを検知し、故障したDataNodeの保持ブロックを別のDataNodeから参照するよう命令する。

  • このようにしてDataNodeが故障した場合も自動的にレプリケーション数が維持されるため、DataNodeが故障してもサービスに影響は発生しない。

  • 単一障害点であったが、Hadoop 2.2でHA機能が実装されたため単一障害点ではなくなった。

    • 状態変更は既存の Apache ZooKeeperを用いずMulti Paxosを実装して用いることにより、
    • メッセージ数の削減による高性能化を実現する。

DataNode

スレーブの役割を担当する。

  • 実データをブロック単位で保持する。

  • レプリケーション数のデフォルトは3で、この場合、

    • 2つのデータを同じラック内のノードに、
    • 残り1つを異なるラック内のノードに

    保存する。

  • 数1000台規模までスケールアウト可能。
    その場合、数10PB規模のデータを格納できる。

旧管理コンポーネント

Hadoopクラスタの

  • リソース管理
  • ジョブ・スケジューリング

を担当。

JobTracker

旧マスタ（リソース管理、ジョブ・スケジューリング）ノード

TaskTracker

旧スレーブ（割り当てられた処理の実行）ノード

  • １筐体上でDataNodeとTaskTrackerが動く。
  • TaskTrackerが停止するか、実行中のタスクがタイムアウトすると、その部分のタスクは再スケジュールされる。

Hadoop Yet Another Resource Negotiator (YARN)

ResourceManager

NodeManager

  • 処理ノードを管理するスレーブ・ノード

  • １筐体上でDataNodeとNodeManagerが動く。

  • MapReduceタスクの実行コンテナ。

    • 計算リソース（CPU、メモリ、ネットワーク / ディスク帯域, etc.）の集合をコンテナと称する。

    • ApplicationMasterもそのコンテナ上で動作する。

    • 汎用化したコンテナ単位でリソースを割り当てるので、
      MapReduce以外のアプリケーションにもリソースを配分できる。

ApplicationMaster

  • アプリケーションを管理するノード

  • MapReduceを含む各アプリケーション用に
    それぞれ専用のApplicationMasterが実行される。

エコシステム

分散処理フレームワーク

Hadoop MapReduceと比べて

分散処理エンジン

アプリケーションの記述性が柔軟で、より高効率な実行が可能。

SQLクエリエンジン

クエリを低い遅延（レイテンシ）で実行可能

分散ストリーム処理

大量のストリームデータを低い遅延（レイテンシ）で処理可能

DWH、データストア

Apache Hive（DWH）

Apache Hive

Apache Impala（DWH）

Apache Impala

HBase、Kudu

Asakusa Framework

Asakusa Framework

ノーチラス・テクノロジーズが開発した、
Hadoop用の開発・運用フレームワーク。

参考

Wikipedia

MapReduce

Google File System(GFS)

gihyo.jp … 技術評論社

Hadoopはどのように動くのか

Hadoop MapReduce（記事）

Hadoopの設計と実装～並列データ処理系Hadoop MapReduce

Hadoop YARN（記事）

計算機クラスタのためのリソース管理基盤 Hadoop YARN

Hadoopの

歴史

エコシステム（記事）

Qiita

Hadoop（記事）

YARN（記事）

移行メモ

  • 「MRv2」の節に「MapReduceジョブが停止した場合、JobTrackerを再起動して MapReduceジョブを再実行する必要がある」とあったが、 MRv2（YARN）には JobTracker が存在せず、同ページの他の記述とも矛盾するため、 「JobTracker は存在せず、ジョブ毎の ApplicationMaster が再起動される」旨に改めた。
  • 「NodeManager」の「汎用化したコンテナ単位でリソースを割り当てるので、」で 文が途切れていたため、「MapReduce 以外のアプリケーションにもリソースを配分できる。」 と結びを補った。
  • 誤記・脱字を修正した。「分析クエリような処理」→「分析クエリのような処理」、 「コモディティサーバはでは」→「コモディティサーバでは」、 「YARN上でMapReduce上が動作し」→「YARN上でMapReduceが動作し」、 「クエリを低い（レイテンシ）で実行可能」→「低い遅延（レイテンシ）で実行可能」、 「計算リソースの管理する基盤システム」→「計算リソースを管理する基盤システム」、 「NodeManagerヘの」（カタカナのヘ）→「への」、 「進捗管理)」の余分な閉じ括弧を除去した。
  • 元の PukiWiki は「Hadoop MapReduce」「Hadoop YARN」「特性」「構成」「処理系」 「機能」などの同名見出しをページ内で繰り返しており、 GitHub Wiki ではアンカが衝突するため、括弧で文脈を補って一意にした。

Tags: 移行, Hadoop, MapReduce, YARN, HDFS, 分散処理, ビッグデータ, NameNode, DataNode, ResourceManager

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally