第14回　Hadoopの設計と実装～並列データ処理フレームワークHadoop MapReduce［2］

はじめに

今回は、Hadoopの構成要素である並列データ処理フレームワークMapReduceにおける実装アーキテクチャの特徴について解説します。加えて、類似のシステムである並列データベースを取り上げ、想定するワークロードなどの違いについて解説します。

Apache Hadoopの実装における特徴

現在、Apache Hadoopは、MapReduceの一実装であるHadoop MapReduceと、Googleの分散ファイルシステムGFSのクローンであるHadoop Distributed File System（HDFS⁠）⁠、そしてリソース管理を行うYet Another Resource Negotiator（YARN）から構成されます。ここでは、それぞれのコンポーネント間に存在するアーキテクチャの特徴と、各コンポーネントの実装について述べます。

これら3つのコンポーネントは、すべてマスタ・スレーブ型のアーキテクチャを採ります。マスタ・スレーブ型のシステムは、クラスタ全体を管理・統括するマスタと、マスタから命令に従い実際の仕事を行うスレーブから構成されます。当該アーキテクチャにおいては、マスタが単一障害点（SPoF：Single Point of Failure）となり可用性が低下する場合や、マスタがボトルネックとなり高いスケーラビリティが実現できない場合があります（図1⁠）⁠。

Apache Hadoopのマスタとスレーブの間においては、クラスタ内の管理情報の交換や死活監視などのごく少数のやりとりを行い、加えて、マスタが単一障害点にならないよう、第12回でかんたんに解説したApache Zookeeperや専用のストレージを利用してマスタの冗長構成を取ることで、システムの可用性を高める取り組みが行われています。これらにより、数千台から数万台規模まで性能をスケールすることが可能となっています。以降において、各コンポーネントの実装について述べます[1]⁠。

HDFS、YARN、MapReduceの実装

HDFSの実装

HDFSの概要を図2に示します。HDFSは、データの位置などのメタデータを管理するNameNodeと、実際にデータを保持するDataNodeから構成されます。たとえば、HDFSを用いてファイルにアクセスする場合は、ファイルを構成するデータの塊（ブロック）の位置情報などをNameNodeに問い合わせ、当該情報を用いてDataNodeにブロックのアクセスを依頼し、ブロックを取得します。NameNodeとDataNodeは定期的に情報を交換し、その際にDataNodeの死活監視や、ディスク容量の検査などを行います。DataNodeに保存されるブロックは、DataNodeが故障しても失われないよう、基本的に複数の計算機にコピーして配置されます。なお、前回述べたように、HDFSでは、ファイル走査において高い性能を実現するために、ファイルを数十MBから数百GBからなるブロックに分割して管理を行います。

NameNodeにおいて発生する状態変更は、ファイルおよびディレクトリの作成や削除の際に発生し、大量の一貫性を要するトランザクションとなることが想定されます。このため、当該状態変更処理においては、既存のApache Zookeeperを用いず、Paxos（第12回を参照）の改良版（Multi Paxos）を実装して用いることにより、メッセージ数の削減による高性能化を実現しています（［1］、※2⁠）⁠。

YARNの実装

次に、YARNの概要を図3に示します。YARNは、ResourceManagerなるマスタと、NodeManagerなるスレーブから構成されます。YARNでは、マスタはスレーブからクラスタ全体の計算リソースの情報を収集し、その情報を元に、クライアントからの計算リソースの要求に応じて、スレーブにおけるリソース確保のスケジューリングを行います。一方スレーブは、各ノードのローカルの保持する計算リソースを管理します。現在使用中の計算リソースと未使用の計算リソースを逐次マスタに報告し、マスタからの計算リソースの要求に応じて計算リソースを確保します。YARNのマスタも高可用構成を取ることができます。YARNのマスタが任意のタイミングで切り替わっても動作が停止しないようにするために、管理情報（ジョブの投入状況および進捗状況の変更）をZooKeeperに保持します。マスタが保持している管理情報は投入されるジョブ数に比例して増加はするものの、一般的にApache ZooKeeperで捌ききれる範囲であるため、Apache ZooKeeper内に保存されます。

MapReduceの実装

Hadoop MapReduceでは、マスタはジョブの進捗状況を管理し、ジョブを分割し、部分ジョブ（タスク）をスレーブに割り当てます（図4⁠）⁠。また、YARNに対してリソースの要求を行うことに加えて、プロセス故障や計算機故障に備えて、タスクを再実行するために必要な情報なども管理します。実際には、マスタとスレーブは定期的にheartbeatと呼ばれるデータを交換します。heartbeatの中には、スレーブ内の進捗情報や、スレーブ内で動作しているプロセスの生存情報に加えて、マスタからスレーブへの指示などが含まれます。Hadoop MapReduceの高可用性のための仕組みおよびHadoop MapReduceとYARNとの関係については、次回にて詳しく述べます。

MapReduceと並列データベース

MapReduceは、第一部で述べたように、並列データベースの技術を基本としているため、並列データベースの設計や実装において類似している特徴が多く見られます。しかし、必ずしもすべてが類似しているわけではありません。たとえば、想定するジョブのワークロードを見てみると、並列データベースはいわゆる分析クエリに代表されるようなデータを絞り込んで詳細に見ていくような処理を想定しているのに対し、MapReduceは、いわゆるETL（Extract-Transform-Load）と称される、データを加工する処理を想定しています。すなわち、データを分析する工程においては、非構造化データなる、構造を持たないフラットなファイルなどをETLで加工し、当該データをスキーマ（構造）を有するデータベースにロードし、データベース上の構造化されたデータを用いて細かい分析を行う、という方法が一般的ですが、この観点では、Hadoop MapReduceは前者をおもな対象として設計されており、並列データベースは後者をおもな対象として設計されていると見ることができます。

用途が異なるため、当然、それぞれの目的は異なり、MapReduceはおもに処理のスループットの向上を目的として設計されているのに対し、並列データベースは処理のレイテンシの低下を目的として設計されていることが一般的です。たとえば、MapReduceを用いたETLでは、レコードのすべての要素を処理することが通例であるため、HDFSにおいてはレコードごとにデータを管理し、すなわちレコード指向（行指向）のデータレイアウトを用います。一方、並列データベースにおいては、レコードにおけるすべての要素（属性）を必ずしもすべて必要としないため、列ごとにデータを構成する列指向データレイアウトを用い、問い合わせに必要なレコードのみの入出力を行います。

ETLと分析においては、明確な定義や境界があるわけではなく、それらの中間的なものも存在します。MapReduceでは、そのようなワークロードに対応すべく、たとえば、Apache Parquet（［2］）やApache ORCFile（［3］）のようなHDFS上の列指向データレイアウトを採用する取り組みが見られます。一方、並列データベースにおいても、JSONのような構造が緩いデータ（準構造化データ）を管理する機能を取り込む流れも見られつつあり、双方において多様なワークロードに対応する取り組みが広く見られます。

おわりに

今回は、Hadoop MapReduceにおける実装の特徴について説明しました。次回は、Hadoopのリソース管理フレームワークであるYARNについて説明する予定です。

参考文献: ［1］Todd Lipcon, Quorum-Journal Design; ［2］Apache Parquet; ［3］Apache ORCFile