序章

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のブロック複製パターンは、高可用性のバックボーンです。 これは非常に効果的であり、管理者や開発者がブロックストレージレベルで心配する必要がなくなりますが、スペース使用率やノードのリアルタイムの状況を考慮しないため、クラスター管理者はバランサーユーティリティプログラムを使用する必要があります。ブロックを再配布します。

  • NameNode：単一障害点ブロックの分散よりも重要な制限である、NameNodeは単一障害点を表します。 プロセスまたはマシンに障害が発生した場合、NameNodeサーバーが再起動されるまでクラスター全体が使用できなくなり、再起動した後でも、実際に使用可能になる前にクラスター内のすべてのノードからハートビートメッセージを受信する必要があります。これにより、特に大規模な場合、停止が長くなります。クラスター。

これらの制限にもかかわらず、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の制限

  • MapReduceとHDFS間の緊密な結合1.xの実装では、MapReduceレイヤーの責任はデータ処理を超えて、クラスターリソース管理を含み、HDFSと緊密に結合されます。 つまり、1.xのアドオン開発者は、タスクに適しているかどうかに関係なく、マルチパスMapReduceプログラムを作成する必要があります。これは、MapReduceがファイルシステムにアクセスする唯一の方法だからです。

  • データ分析用の静的スロットマッピングと削減はデータノードで行われます。これはビッグデータを操作するための鍵ですが、各データノードで使用できる単一目的のスロットの数は限られています。 マッピングスロットはマッピングのみが可能で、リデューススロットはリデュースのみが可能です。 この数は、動的調整の容量がない構成で設定されており、アイドル状態であるため、クラスターのワークロードが構成に適合しない場合は常に無駄になります。 スロット割り当ての硬直性により、MapReduce以外のアプリケーションが適切にスケジュールすることも困難になります。

  • JobTracker：単一障害点 HadoopアプリケーションはMapReduceタスクをJobTrackerに送信し、JobTrackerは、使用可能なスロットがあるか、データの地理的に近い場所にTaskTrackerを配置することで、これらのタスクを特定のクラスターノードに分散します。 TaskTrackerは、タスクが失敗した場合にJobTrackerに通知します。 JobTrackerは、ジョブを再送信したり、レコードを将来の処理から除外するようにマークしたり、信頼性の低いTaskTrackerをブラックリストに登録したりする場合がありますが、何らかの理由でJobTrackerに障害が発生した場合、すべてのMapReduceタスクが停止します。

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

  • 名前空間のスケーラビリティクラスターにNameNodeを追加する機能により、水平方向のスケーリングが可能になります。 大きなクラスターまたは小さなファイルが多数あるクラスターは、NameNodeを追加することでメリットが得られます。
  • パフォーマンスの向上1.xの単一のNameNodeは、ファイルシステムの読み取り/書き込みスループットを制限していました。 複数のNameNodeは、ファイルシステム操作に対するこの制約を緩和します。
  • ネームスペース間の分離単一のNameNodeを使用するマルチテナント環境では、1つのノイズの多いネイバーがシステム上の他のすべてのユーザーに影響を与える可能性がありました。 フェデレーションにより、システムの居住者を隔離することが可能になりました。

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のユーザーが利用できる処理モデルの一部です。

  • バッチ処理バッチ処理システムは非対話型であり、処理が開始される前にすべてのデータにアクセスできます。 さらに、処理中に調査される質問は、処理を開始する前に知っておく必要があります。 バッチ処理は通常、待ち時間が長く、ビッグデータのバッチジョブの速度は通常数分以上で測定されます。

    バッチ処理が優れている点：データのインデックス作成、Webのクロール、およびデータの処理

    Hadoopでこれを実行できるいくつかのプログラム： MapReduce、Tez、Spark、Hive、およびFlink

  • インタラクティブ処理事前にすべての質問を知らない場合は、インタラクティブ処理システムが必要です。 代わりに、ユーザーはクエリに対する回答を解釈してから、新しい質問を作成します。 この種の探索をサポートするには、通常のMapReduceジョブよりもはるかに迅速に応答を返す必要があります。

    インタラクティブ処理が優れている点：インタラクティブ処理はデータ探索をサポートします。
    Hadoop用にこれを行ういくつかのプログラム： Impala、Drill、HAWQ、Presto、Vortex、およびVertica SQL、Tez

  • ストリーム処理ストリーム処理システムは、大量の個別のデータポイントを取得し、連続クエリを実行して、新しいデータがシステムに到着したときにほぼリアルタイムの結果を生成します。

    ストリーム処理が優れている点：すでにデジタルデータが継続的に生成されている場合。 例としては、ソーシャルメディアの問題、イベント、または製品に対する世論を監視して、新たな傾向を追跡したり、サーバーログを監視したりすることが含まれます。

    Hadoop用にこれを行ういくつかのプログラム： Spark Stream、Storm

  • グラフ処理グラフアルゴリズムは通常、1つの頂点から別の頂点にエッジを移動するために頂点またはホップ間の通信を必要とし、1.xMapReduceを通過するときに多くの不要なオーバーヘッドを必要としました。

    グラフの魅力：グラフは、Facebookの友達関係、Twitterのフォロワー、ソーシャルメディアサイトのコアのような分散グラフデータベースなど、物事間の非線形の関係を示すのに理想的です。

    Hadoop用にこれを行ういくつかのプログラム： Apache Giraph、Apache SparkのGraphX、Hama、Titan

これらは、代替の処理モデルとツールのほんの一部です。 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のインストールをご覧ください。 一般的なビッグデータの概念の詳細については、ビッグデータの概念と用語の概要を参照してください。