TOC

Hadoopの概要

前書き

Apache Hadoopは、World Wide Webの台頭に伴い蓄積された膨大な量の容易に利用可能なデジタルデータを保存および処理するための、最も早く最も影響力のあるオープンソースツールの1つです。 それは、ウェブをクロールするためのより良いオープンソースの方法を見つけることを試みたNutchと呼ばれるプロジェクトから発展しました。 Nutchのクリエイターは、Googleの2つの重要な論文の考え方に大きな影響を受け、当初それらをNutchに組み込みましたが、最終的にストレージと処理の作業はHadoopプロジェクトに分割され、Nutchを独自のウェブクロールプロジェクトとして開発し続けました。

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

データシステム

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

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

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

  • 情報はさまざまな場所に存在します（さまざまな学生のフィールドノート）

  • システムに収集されます（スプレッドシートに手入力されます）

  • 保存されます（教室のコンピューターのディスクに保存されます。フィールドノートブックは、データの整合性を検証するためにコピーまたは保持される場合があります）

  • 分析（集約、ソート、またはその他の操作）

  • 処理されたデータが表示されます（テーブル、チャート、グラフ）

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

ドットコム時代にWebコンテンツが爆発的に増加したため、検索エンジン企業はこの特定の問題に直面していました。 2003年、Googleは影響力のある論文The Google File Systemをリリースしました。これは、独自のソフトウェアが検索エンジン用に処理されている大量のデータのストレージをどのように処理したかを説明しています。 2004年にはGoogleのMapReduce: Simplified Data Processing on Large Clustersが続き、このような大量のデータの処理をどのように簡素化したかが詳しく説明されています。 これら2つの論文は、Hadoopのアーキテクチャに大きな影響を与えました。

ビッグデータの違いは何ですか？

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

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

  2. クラスターがストレージ基盤になると、software had to account for hardware failureになります。これは、クラスター内で数百または数千のマシンを実行することについて話している場合、ハードウェア障害が避けられないためです。

  3. マシンwillは故障するため、相互に通信する新しい方法が必要でした。 日常のデータコンピューティングでは、通常、特定のデータを別の特定のマシンに送信するIPアドレスまたはホスト名によって識別される特定のマシンに慣れています。 このexplicit communication had to be replaced with implicit communicationは、あるマシンが他のマシンに特定のデータを処理する必要があることを通知します。 そうでなければ、プログラマーは少なくともデータ処理の問題自体と同じくらい大きな検証問題に直面するでしょう。

  4. 最後に、ネットワーク全体で大量のデータを移動するのではなく、computing would need to go to the data and process it on the distributed machinesを使用します。

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

  1. HDFS:Hadoop分散ファイルシステム。複数のマシン間でデータを保存します。

  2. MapReduce:各マシンでデータを適切に並行して処理し、タスクをスケジュールし、それらを監視し、失敗したタスクを再実行するためのソフトウェアフレームワーク。

HDFS 1.0

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

HDFS 1.0の仕組み

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

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

NameNodeは、クラスター内の各DataNodeから受信するハートビートおよびブロックレポートに基づいて、ブロック複製に関するすべての決定を行います。 ハートビートはDataNodeが正常であることを通知し、ブロックレポートはDataNode上のすべてのブロックのリストを提供します。

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

HDFS 1.0の制限

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

  • No Control over the Distributions of Blocks
    HDFSのブロックレプリケーションパターンは、高可用性のバックボーンです。 これは非常に効果的であり、管理者と開発者がブロックストレージレベルで心配する必要がなくなりますが、スペース使用率やノードのリアルタイム状況を考慮しないため、クラスター管理者はバランサーユーティリティプログラムを使用する必要がありますブロックを再配布します。

  • The NameNode: A Single Point of Failure
    ブロックの分散よりも重要な制限である、NameNodeは単一障害点を表します。 プロセスまたはマシンに障害が発生した場合、NameNodeサーバーが再起動されるまでクラスター全体が利用できず、再起動してもクラスター内のすべてのノードからハートビートメッセージを受信して​​から実際に利用できるようにする必要があります。クラスター。

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

MapReduce 1.0

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

MapReduce 1.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のいくつかの重要な制限によって制約されていました。

MapReduce 1の制限

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

  • Static Slots for Data Analysis
    マッピングとリデューシングはデータノードで実行されます。これはビッグデータを処理するための鍵ですが、各データノードで使用できる単一目的スロットの数は限られています。 マッピングスロットはマッピングのみが可能で、縮小スロットは縮小のみ可能です。 数値は動的に調整するための容量がない構成で設定され、アイドル状態であるため、クラスターのワークロードが構成に適合しない場合に無駄になります。 スロット割り当ての厳格さにより、MapReduce以外のアプリケーションが適切にスケジュールすることも難しくなります。

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

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

  • Namespace scalabilityクラスターにNameNodeを追加する機能により、水平方向のスケーリングが可能になります。 大きなクラスターまたは小さなファイルが多数あるクラスターでは、NameNodeを追加するとメリットが得られます。

  • Performance gains 1.xの単一のNameNodeは、ファイルシステムの読み取り/書き込みスループットを制限しました。 複数のNameNodeにより、ファイルシステム操作に関するこの制約が緩和されます。

  • Isolation between namespaces単一のNameNodeを使用するマルチテナント環境では、1つのノイズの多いネイバーがシステム上の他のすべてのユーザーに影響を与える可能性がありました。 フェデレーションにより、システムの居住者を隔離することが可能になりました。

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

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

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

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

2 — NameNode高可用性

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

NameNode HAの仕組み

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

3 —ヤーン

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

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

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

    Where batch processing shines:データのインデックス作成、Webのクロール、およびデータの処理

    Some programs that can do this for Hadoop: MapReduce、Tez、Spark、Hive、およびFlink

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

    Where interactive processing shines:インタラクティブ処理はデータ探索をサポートします。

    Some programs that do this for Hadoop: Impala、Drill、HAWQ、Presto、Vortex、およびVertica SQL、Tez

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

    Where stream processing shines:デジタルデータが継続的に生成されているときはいつでも。 例としては、ソーシャルメディアの問題、イベント、または製品に対する世論を監視して、新しいトレンドを追跡したり、サーバーログを監視したりします。

    Some programs that do this for Hadoop: Spark Stream、Storm

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

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

    Some programs that do this for Hadoop: Apache Giraph、Apache SparkのGraphX、Hama、Titan

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

4 — ResourceManager高可用性

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

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

Hadoop 3.x

この記事の執筆時点では、Hadoop 3.0.0-alpha1をテストに使用できます。 3.xブランチの目的は、ディスクスペースを節約するHDFS消去エンコーディング、スケーラビリティ、信頼性、使いやすさを向上させるYARNのタイムラインサービスの改善、3つ以上のNameNodes、Intra-datanodeバランサーなどの改善を提供することです。 詳細については、major changesの概要をご覧ください。

結論

この記事では、ますます大規模なデータセットのニーズを満たすためにHadoopがどのように進化したかを見てきました。 Hadoopの実験に興味がある場合は、Installing Hadoop in Stand-Alone Mode on Ubuntu 16.04を確認することをお勧めします。 一般的なビッグデータの概念の詳細については、An Introduction to Big Data Concepts and Terminologyを参照してください。

Related