開発者ドキュメント

Hadoopの概要

getdocs

序章

Apache Hadoopは、ワールドワイドウェブの台頭とともに蓄積された、すぐに利用できる大量のデジタルデータを保存および処理するための最も初期の最も影響力のあるオープンソースツールの1つです。 これは、Webをクロールするためのより優れたオープンソースの方法を見つけようとしたNutchというプロジェクトから発展したものです。 Nutchの作成者は、Googleの2つの主要な論文の考え方に大きく影響され、元々はNutchに組み込まれていましたが、最終的には保存と処理の作業がHadoopプロジェクトに分割され、Nutchを独自のWebクロールプロジェクトとして開発し続けました。

この記事では、データシステムと、ビッグデータシステムの特定の特徴的なニーズについて簡単に説明します。 次に、これらのニーズに対応するためにHadoopがどのように進化したかを見ていきます。

データシステム

データは、紙切れ、本、写真、マルチメディアファイル、サーバーログ、Webサイトなど、いたるところに存在します。 そのデータが意図的に収集されると、データシステムに入ります。

生徒が毎日近くの小川の水位を測定する学校のプロジェクトを想像してみてください。 彼らはクリップボードのフィールドに測定値を記録し、教室に戻って、そのデータをスプレッドシートに入力します。 十分な量を集めたら、分析を開始します。 彼らは、異なる年の同じ月を比較し、最高水位から最低水位まで並べ替えることができます。 彼らは傾向を探すためにグラフを作成するかもしれません。

この学校のプロジェクトは、データシステムを示しています。

このプロジェクトは、スペクトルの小さな端にあります。 1台のコンピューターで、1つの小川の毎日の水位測定値を保存、分析、および表示できます。 スペクトルのもう一方の端に向かって、世界中のすべてのWebページのすべてのコンテンツがはるかに大きなデータセットを形成します。 最も基本的なのはビッグデータです。1台のコンピューターに収まらないほど多くの情報があります。

ドットコム時代にWebコンテンツが爆発的に増加したため、検索エンジン企業はこの特定の問題に直面していました。 2003年、Googleは影響力のある論文 Google File System をリリースし、独自のソフトウェアが検索エンジンで処理されている大量のデータのストレージをどのように処理したかを説明しました。 その後、2004年にGoogleの MapReduce：大規模クラスターでのデータ処理の簡素化が行われ、このような大量のデータの処理がどのように簡素化されたかが詳しく説明されました。 これらの2つの論文は、Hadoopのアーキテクチャに強く影響しました。

ビッグデータはどう違うのですか？

Googleの論文とHadoopによるこれらのアイデアの実装は、大量のデータに対応するために必要なデータについての考え方における4つの大きな変化に基づいていました。

  1. ビッグデータシステムは、データが配布されることを受け入れる必要がありました。 マシンのクラスター全体でデータセットを分割して保存することは避けられませんでした。

  2. クラスターがストレージ基盤になると、ソフトウェアはハードウェア障害を考慮する必要がありました。これは、クラスターで数百または数千のマシンを実行する場合、ハードウェア障害が避けられないためです。

  3. マシンはに失敗するため、相互に通信するための新しい方法が必要でした。 日常のデータコンピューティングでは、特定のマシンに慣れています。通常、IPアドレスまたはホスト名によって識別され、特定のデータを別の特定のマシンに送信します。 この明示的通信は暗黙的通信に置き換える必要がありました。この場合、あるマシンが他のマシンに特定のデータを処理する必要があることを通知します。 そうでなければ、プログラマーは少なくともデータ処理の問題自体と同じくらい大きな検証の問題に直面するでしょう。

  4. 最後に、コンピューティングでは、大量のデータをネットワーク上で移動するのではなく、データにアクセスして分散マシンで処理する必要があります。

2007年にリリースされたJavaベースのプログラミングフレームワークのバージョン1.0であるHadoopは、これらの考え方の変化を取り入れた最初のオープンソースプロジェクトでした。 その最初の反復は、次の2つの層で構成されます。

  1. HDFS：Hadoop分散ファイルシステム。複数のマシンにデータを保存します。
  2. MapReduce：各マシンでデータを適切かつ並行して処理し、タスクをスケジュールし、それらを監視し、失敗したタスクを再実行するためのソフトウェアフレームワーク。

HDFS 1.0

Hadoop分散ファイルシステム（HDFS）は、Hadoopがデータを分散し、高可用性のために適切に保存されるようにするために使用する分散ストレージレイヤーです。

HDFS1.0のしくみ

HDFSは、ブロックレプリケーションを使用して、ファイルシステムの名前空間とクライアントアクセスを管理するNameNodeサーバーと、読み取りおよび書き込み要求の処理とブロックを担当するDataNodeの2つの異なるソフトウェアを使用して、複数のマシン間で非常に大きなファイルを確実に保存します。作成、削除、および複製。 レプリケーションパターンの基本的な理解は、開発者とクラスター管理者に役立ちます。これは、一般的にはうまく機能しますが、データの分散の不均衡がクラスターのパフォーマンスに影響を与え、調整が必要になる可能性があるためです。

HDFSは、各ファイルを一連のブロックとして保存します。各ファイルは、最後のファイルを除いて同じサイズです。 デフォルトでは、ブロックは3回複製されますが、ブロックのサイズとレプリカの数の両方をファイルごとに構成できます。 ファイルはライトワンスであり、高スループットのデータアクセスを可能にし、データの一貫性の問題を単純化するために、いつでも1つのライターしかありません。

NameNodeは、クラスター内の各DataNodeから受信するハートビートとブロックレポートに基づいて、ブロックレプリケーションに関するすべての決定を行います。 ハートビートはDataNodeが正常であることを示し、ブロックレポートはDataNode上のすべてのブロックのリストを提供します。

新しいブロックが作成されると、HDFSはライターが実行されているノードに最初のレプリカを配置します。 2番目のレプリカは、最初のレプリカが書き込まれたラックを除く任意のラックのランダムに選択されたノードに書き込まれます。 次に、3番目のレプリカがこの2番目のラックのランダムに選択されたマシンに配置されます。 構成でデフォルトの3つを超えるレプリカが指定されている場合、残りのレプリカはランダムに配置されますが、1つのノードに配置されるレプリカは1つ以下、同じラックに配置されるレプリカは2つ以下という制限があります。

HDFS1.0の制限

HDFS 1.0は、ビッグデータを保存するための初期のオープンソースリーダーとしてHadoopを確立しました。 その成功の一部は、分散ストレージの複雑さの一部を方程式から取り除いたアーキテクチャ上の決定に起因していましたが、それらの選択にはトレードオフがありました。 バージョン1.0バージョンの主な制限は次のとおりです。

これらの制限にもかかわらず、HDFSはビッグデータの操作に大きく貢献しました。

MapReduce 1.0

Hadoopの2番目のレイヤーであるMapReduceは、HDFSに保存されているデータのバッチ処理を担当します。 HadoopによるGoogleのMapReduceプログラミングモデルの実装により、開発者は、並列および分散システムの経験を必要とせずに、HDFSによって提供されるリソースを使用できます。

MapReduce1.0の仕組み

テキストのコレクションがあり、各単語がコレクションに何回出現するかを知りたいとします。 テキストは多くのサーバーに分散されるため、マッピングタスクは、コレクション内のデータのブロックを持つクラスター内のすべてのノードで実行されます。 各マッパーは適切なファイルをロードして処理し、出現ごとにキーと値のペアを作成します。

これらのマップには単一ノードからのデータしか含まれていないため、同じキーを持つすべての値をレデューサーに送信できるように、それらを一緒にシャッフルする必要があります。 レデューサーが完了すると、出力はレデューサーのディスクに書き込まれます。 この暗黙の通信モデルにより、Hadoopユーザーは情報をあるマシンから別のマシンに明示的に移動する必要がなくなります。

これをいくつかの文で説明します。

彼女は6つの海岸で貝殻を販売しています。 彼女は確かに貝殻をよく売っています。

MAPPING			SHUFFLING			REDUCING
{she, 1}		{she, 1, 1} 		{she, 2}
{sells, 1}		{sells, 1, 1}		{sells, 2}
{seashells, 1}	{seashells, 1, 1}	{seashells, 2}
{by, 1}			{by, 1} 			{by, 1}
{six, 1}		{six, 1}			{six, 1}
{seashores, 1}	{seashores, 1, 1}	{seashores, 2}
{she, 1}		{sure, 1}			{sure, 1}
{sure, 1}		{well, 1}			{well, 1}
{sells}
{seashells, 1}
{well, 1}

このマッピングが大規模なデータセットに対して順番に実行された場合、時間がかかりすぎますが、並行して実行されてから削減されると、大規模なデータセットに対してスケーラブルになります。

上位レベルのコンポーネントは、MapReduceレイヤーにプラグインして、追加機能を提供できます。 たとえば、Apache Pigは、SQLがリレーショナルデータベースに対して行うのと同様に、Java MapReduceイディオムをより高いレベルに抽象化することにより、データ分析プログラムを作成するための言語を開発者に提供します。 Apache Hiveは、HDFSへのSQLのようなインターフェイスを使用してデータ分析とレポートをサポートします。 MapReduce Java APIクエリを抽象化して、開発者に高レベルのクエリ機能を提供します。 Hadoop 1.xには多くの追加コンポーネントが利用可能ですが、エコシステムはMapReduceのいくつかの重要な制限によって制約されていました。

MapReduce1の制限

Hadoop2.xの改善

2011年12月にリリースされたHadoopの2.xブランチでは、バージョン1の4つの主要な改善が導入され、主要な制限が修正されました。 Hadoop 2.0はHDFSフェデレーションを導入しました。これにより、パフォーマンスの制約と単一障害点の両方としてNameNodeが削除されました。 さらに、YARN（Yet Another Resource Negotiator）の導入によりMapReduceをHDFSから切り離し、MapReduce以外の処理モデルがHDFSと対話し、MapReduceレイヤーをバイパスできるようにすることで、アドオン製品のエコシステムを開きます。

1 —HDFSフェデレーション

HDFSフェデレーションにより、名前空間とストレージが明確に分離され、クラスター内の複数の名前空間が可能になります。 これにより、いくつかの重要な改善が提供されます。

HDFSフェデレーションの仕組み

フェデレーションNameNodeは、ファイルシステムの名前空間を管理します。 それらは独立して動作し、互いに調整しません。 代わりに、クラスター内のDataNodeはすべてのNameNodeに登録され、ハートビートとブロックレポートを送信し、NameNodeからの着信コマンドを処理します。

ブロックは、Hadoop1.xで見たのと同じランダム複製で共通ストレージ全体に分散されます。 単一の名前空間に属するすべてのブロックは、ブロックプールと呼ばれます。 このようなプールは独立して管理されるため、名前空間は、他の名前空間と調整することなく、新しいブロックのブロックIDを生成できます。 名前空間とそのブロックプールの組み合わせは名前空間ボリュームと呼ばれ、自己完結型のユニットを形成します。そのため、フェデレーションされたNameNodeの1つが削除されると、そのブロックプールも削除されます。

NameNodeフェデレーションの導入によって提供されるスケーラビリティ、パフォーマンス、および分離の向上に加えて、Hadoop2.0はNameNodeの高可用性も導入しました。

2 —NameNodeの高可用性

Hadoop 2.0より前では、NameNodeに障害が発生した場合、クラスター全体は、再起動されるか、新しいマシンで起動されるまで使用できませんでした。 NameNodeのソフトウェアまたはハードウェアへのアップグレードは、同様にダウンタイムのウィンドウを作成しました。 これを防ぐために、Hadoop 2.0はアクティブ/パッシブ構成を実装して、高速フェイルオーバーを可能にしました。

NameNodeHAのしくみ

2台の別々のマシンがNameNodeとして構成され、1つはアクティブで、もう1つはスタンバイです。 これらは共有ストレージデバイス上の共通ディレクトリへのアクセスを共有し、アクティブノードによって変更が実行されると、その共通ディレクトリに保存されているログファイルに変更が記録されます。 スタンバイノードは常にディレクトリを監視し、編集が行われると、それらの編集を自身の名前空間に適用します。 アクティブノードに障害が発生した場合、スタンバイは未適用の編集を共有ストレージから読み取り、それ自体をアクティブにプロモートします。

3 —毛糸

Hadoop 2.0は、MapReduceをHDFSから切り離しました。 ワークロード、マルチテナンシー、セキュリティ制御、および高可用性機能の管理は、YARN（Yet Another Resource Negotiator）にスピンオフされました。 YARNは、本質的に、ビッグデータアプリケーション向けの大規模な分散オペレーティングシステムであり、HadoopをMapReduceと、バッチ処理の完了を待つことができない他のアプリケーションの両方に最適です。 YARNは、I / Oを多用する、高レイテンシのMapReduceフレームワークを介して作業する必要をなくし、新しい処理モデルをHDFSで使用できるようにしました。 分離されたMapReduceは、本来のタスクであるバッチ処理の実行に専念するユーザー向けのフレームワークとして残りました。

以下は、Hadoop2.xのユーザーが利用できる処理モデルの一部です。

これらは、代替の処理モデルとツールのほんの一部です。 MapReduce以外の処理モデルを含む、オープンソースのHadoopエコシステムの包括的なガイドについては、Hadoopエコシステムテーブルを参照してください。

4 —ResourceManagerの高可用性

最初にリリースされたとき、YARNには独自のボトルネックがありました。それはResourceManagerです。 MapReduce 1.xの単一のJobTrackerは、リソース管理、ジョブスケジューリング、およびジョブ監視を処理しました。 YARNの初期リリースでは、グローバルResourceManagerとアプリケーションごとのApplicationMasterの間で責任を分割することにより、これを改善しました。 ResourceManagerは、クラスターリソースを追跡し、MapReduce Jobsなどのアプリケーションをスケジュールしましたが、アクティブ/スタンバイアーキテクチャを導入した2.4リリースまでは単一障害点でした。

Hadoop 2.4では、単一のリソースマネージャーが単一の activeResourceManagerと1つ以上のスタンバイに置き換えられました。 アクティブなResourceManagerに障害が発生した場合、管理者はスタンバイからアクティブへの移行を手動でトリガーできます。 また、Apache Zookeeperをスタックに追加することで、自動フェイルオーバーを有効にすることもできます。 Zookeeperの他のタスク調整の責任の中で、YARNノードのステータスを追跡し、障害が発生した場合にスタンバイへの移行を自動的にトリガーできます。

Hadoop 3.x

この記事の執筆時点では、Hadoop3.0.0-alpha1をテストに使用できます。 3.xブランチは、ディスクスペースを節約するためのHDFSイレイジャーエンコーディング、スケーラビリティ、信頼性、使いやすさを向上させるためのYARNのタイムラインサービスの改善、3つ以上のNameNodeのサポート、データノード内バランサーなどの改善を提供することを目的としています。 詳細については、主な変更点の概要をご覧ください。

結論

この記事では、ますます大規模なデータセットのニーズを満たすためにHadoopがどのように進化したかを見てきました。 Hadoopの実験に興味がある場合は、 Ubuntu16.04でのスタンドアロンモードでのHadoopのインストールをご覧ください。 一般的なビッグデータの概念の詳細については、ビッグデータの概念と用語の概要を参照してください。

モバイルバージョンを終了