Apache Hadoop

Apache Hadoop
開発元	Apacheソフトウェア財団
初版	2006年4月1日 (18年前)
最新版	3.3.1 / 2021年6月15日 (3年前)
リポジトリ	git-wip-us.apache.org/repos/asf/hadoop.git;
プログラミング; 言語	Java
対応OS	クロスプラットフォーム
サポート状況	Active
種別	分散ファイルシステム
ライセンス	Apache License 2.0
公式サイト	http://hadoop.apache.org/
	テンプレートを表示

Apache Hadoopは大規模データの分散処理を支えるオープンソースのソフトウェアフレームワークであり、Javaで書かれている。Hadoopはアプリケーションが数千ノードおよびペタバイト級のデータを処理することを可能としている。HadoopはGoogleのMapReduceおよびGoogle File System(GFS)論文に触発されたものである。

HadoopはApacheのトップレベルプロジェクトの1つであり、世界規模の開発貢献者コミュニティによって開発され、使用されている。^[2]

アーキテクチャ

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

Hadoop Common: 他のモジュールから共通して利用されるライブラリ群。
Hadoop Distributed File System (HDFS): Hadoop独自の分散ファイルシステム。
Hadoop YARN: Hadoopクラスタのリソース管理や、Hadoop上で動作するアプリケーションのスケジューリングを担当する。
Hadoop MapReduce: Hadoop上で動作するMapReduceフレームワークの実装。

また、HadoopではHDFS以外のファイルシステムもサポートしている。2015年5月現在では、下記のファイルシステムをサポートしている。

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

Hadoop Distributed File System (HDFS)

→「Google File System」も参照

Hadoop Distributed File System (HDFS)はHadoop独自の分散ファイルシステムである。HDFSでは大きなファイルを複数のブロック単位(デフォルトで128MB)に分割して、それらを複数のノードにまたがり格納する。そして、そのブロックの複製(レプリカ)を複数の異なるノードに格納することで信頼性を確保している。そのため、各ホストはRAIDを必要としない。レプリケーション数のデフォルトは3で、この場合、2つのデータを同じラック内のノードに、残り1つを異なるラック内のノードに保存する。

HDFSはマスタースレーブ型の構成で、マスターの役割を担当するのがNameNode、スレーブの役割を担当するのが複数のDataNodeである。NameNodeはHDFSに関するメタ情報(ファイルとブロックの対応関係など)を保持し、各DataNodeが実データをブロック単位で保持する。任意のDataNodeが故障した場合は、NameNodeが自動でそれを検知し、故障したDataNodeの保持ブロックを別のDataNodeが持つ同一な保持ブロックから参照するよう命令する。このようにしてDataNodeが故障した場合も自動的にレプリケーション数が維持されるため、DataNodeが故障してもサービスに影響は発生しない。

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

NameNodeは単一障害点であったが、Hadoop 2.2でHA機能が実装されたため単一障害点ではなくなった。また、通常のオペレーティングシステムにマウントできないことは制限のひとつであったが、Hadoop 2.2以降のバージョンではNFSv3マウントに対応している。

Yet Another Resource Negotiator (YARN)

Yet Another Resource Negotiator (YARN)は、Hadoopクラスタのリソース管理、ジョブスケジューリングを担当する。Hadoop 1系まで、Hadoopを構成するモジュールはHDFSとMapReduceの2つであったが、以下の課題を達成するためにYARNが開発され、Hadoop 2.2から利用可能である。

クラスタ規模の拡大: Hadoop 1系までのMapReduceエンジンにおけるマスター(JobTracker)が、クラスタのリソース管理、クラスタ内で実行されるMapReduceジョブのスケジューリング、また、MapReduceジョブ自体のスケジューリング(各タスクに対する入力データの割り当てや進捗管理)の3つを担当する必要があったため、JobTrackerの負荷が大きい。そのため、Hadoopクラスタの台数は1000台程度が限界であった。
リソース管理の効率化: Hadoop 1系までのMapReduceエンジンにおけるスレーブ(TaskTracker)ではMapタスク用、Reduceタスク用にそれぞれスロットが用意されており、そこにMapReduceの各タスクが割り当てられる。ここで、Mapタスク用のスロットに空きがない場合は、Reduceタスク用のスロットに空きがあったとしてもMapタスクをこれ以上割り当てることができず、TaskTrackerのリソース使用率が低下する問題があった。
MapReduce以外の分散処理の実行: Hadoopで分散処理するためには、必ずMapReduceの仕組みに当てはめる必要があった。MapReduceが2回以上連続するような処理を実行する場合、前段のMapReduceジョブの処理結果をHDFSに書き込み、それを後続のMapReduceで読み込む、という流れになるが、ここでHDFSに中間データを書き込むため、処理が非効率である。多段のMapReduceとなるような処理を高速化するために、MapReduceフレームワークとは異なる分散処理が必要であった。

YARNは、Hadoop 1系までのMapReduceからクラスタのリソース管理、ジョブスケジューリングを分離したものである。YARNもHDFSと同様に、マスタースレーブ型の構成で、マスターの役割(リソース管理、ジョブスケジューリング)を担当するのがResourceManager、スレーブの役割(割り当てられた処理の実行)を担当するのがNodeManagerである。MapReduceを含む各アプリケーション用にそれぞれ専用のApplicationMasterが実行され、アプリケーション自体のスケジューリングはApplicationMasterが担当する。NodeManagerはMapReduce用に特化したスロットではなく、より汎用化したコンテナ単位でリソースを割り当てる。ApplicationMasterもそのコンテナ上で動作する。また、YARN上ではMapReduce以外にも、Apache Spark(英語版)、Apache Storm(英語版)、Apache Tez^[3] などの様々な分散処理フレームワークが動作する。

Hadoop MapReduce

→「MapReduce」も参照

Hadoop 2系以降では、YARN上でMapReduce上が動作する。これは、MRv2と呼ばれる。従来のJobTracker、TaskTrackerによるMapReduceはMRv1と呼ばれ、これらは区別される。Hadoop 2系以降では、MRv1をサポートしていない。MapReduceでは、可能な限り入力データを保持するDataNodeと同一ノードでMapタスクが実行されるようにスケジューリングされる。これにより、大規模データ処理においてもネットワークの負荷を抑えることが可能である。

MRv2

クライアントがYARN上でMapReduceを実行する場合、ResourceManagerにジョブを投入する。ジョブが投入されると、ResourceManagerはApplicationMasterをNodeManager上で立ち上げる。ApplicationMasterは、Mapタスク、Reduceタスクの割り当てやタスクの進捗管理を担当し、タスクの実行に必要なリソースは都度ResourceManagerに問い合わせて払いだしてもらう。

MRv1

MapReduceエンジンはひとつのJobTrackerを持ち、クライアントはこのJobTrackerに向けてMapReduceジョブを投入する。ジョブが投入されると、JobTrackerはクラスタ中の利用可能なTaskTrackerに仕事を依頼する。TaskTrackerが停止するか、実行中のタスクがタイムアウトすると、その部分のタスクは再スケジュールされる。何らかの異常によってJobTrackerが停止すると、実行中のMapReduceジョブも停止する。その場合は、JobTrackerを再起動してMapReduceジョブを再実行する必要がある。

主要なユーザ

普及

上記のようなWeb系のテック企業はHadoopを利用している一方で、その他大部分の大企業はHadoopに落胆しているという意見もある^[4]。これはデータ量が10 TB以下と比較的少ない場合にメリットを見出せない事にあるとされる。

また、ガートナーの調査によれば、自社の抱える問題に対してHadoopは過剰であり、I/O比が低いという意見もある^[5]。実際に同社の調査によると回答者の半数強は投資を計画しておらず、2年以内の投資予定も18％とした。

参考書籍

Arun C. Murthy, Vinod Kumar Vavilapalli, Doug Eadline, Joseph Niemiec, Jeff Markham『Apache Hadoop YARN: Moving beyond MapReduce and Batch Processing with Apache Hadoop 2』Addison-Wesley Professional、2014年。ISBN 978-0321934505
太田一樹, 岩崎正剛, 猿田浩輔, 下垣徹, 藤井達朗, 山下真一, 濱野賢一朗『Hadoop徹底入門第2版』翔泳社、2013年。ISBN 978-4798129648
Tom White, 玉川竜司, 兼田聖士『Hadoop 第3版』オライリーメディア、2013年。ISBN 978-4873116297

脚注

^ “Hadoop Releases”. Hadoop.apache.org. 2021年6月15日閲覧。
^ Hadoop Users List
^ Apache Tez
^ “Hadoop Is Falling – Why?”. 2018年1月3日閲覧。
^ “「Hadoop」導入、当面伸び悩みか--ガートナー調査”. 2018年1月3日閲覧。

外部リンク

この項目は、FLOSSに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（Portal:FLOSS）。

[Hadoop_Releases-1] “Hadoop Releases”. Hadoop.apache.org. 2021年6月15日閲覧。

[2] Hadoop Users List

[3] Apache Tez

[4] “Hadoop Is Falling – Why?”. 2018年1月3日閲覧。

[5] “「Hadoop」導入、当面伸び悩みか--ガートナー調査”. 2018年1月3日閲覧。

[1]

[2]

[3]

[4]

[5]