Hadoopの概要

前書き

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

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

データシステム

データはあらゆる場所に存在します。紙の切れ端、書籍、写真、マルチメディアファイル、サーバーログ、Webサイトなどです。 そのデータが意図的に収集されると、データシステムに入ります。

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

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

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

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

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

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

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

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

ドットコム時代にWebコンテンツが爆発的に増加したため、検索エンジン企業はこの特定の問題に直面していました。 2003年、Googleは独自のソフトウェアが検索エンジンで処理される大量のデータのストレージをどのように処理したかを説明した有力な論文http://research.google.com/archive/gfs.html[The Google File System]をリリースしました。 2004年のGoogleのhttp://research.google.com/archive/mapreduce.html[MapReduce:大規模クラスターでのデータ処理の簡素化]で続いており、このような大量のデータの処理をどのように簡素化したかが詳しく説明されています。 これら2つの論文は、Hadoopのアーキテクチャに大きな影響を与えました。

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

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

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

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

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

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

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

  1. * HDFS:* Hadoop Distributed File System。複数のマシンにデータを保存します。

  2. * MapReduce:*各マシンでデータを所定の場所で並列処理し、タスクをスケジュールし、監視し、失敗したタスクを再実行するためのソフトウェアフレームワーク。

HDFS 1.0

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

HDFS 1.0の仕組み

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

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

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

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

HDFS 1.0の制限

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

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

  • * NameNode:単一障害点*
    ブロックの配布よりも重要な制限である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の制限

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

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

  • * JobTracker:単一障害点*
    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-federation]] === 1-HDFSフェデレーション

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

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

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

  • *名前空間間の分離*単一のNameNodeを備えたマルチテナント環境では、1人の騒々しい隣人がシステム上の他のすべてのユーザーに影響を与える可能性がありました。 フェデレーションにより、システムの居住者を隔離することが可能になりました。

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

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

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

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

[[2---namenode-high-availability]] === 2-NameNode高可用性

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

NameNode HAの仕組み

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

[[3---yarn]] === 3-糸

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

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

  • バッチ処理
    バッチ処理システムは非対話型であり、処理を開始する前にすべてのデータにアクセスできます。 さらに、処理を開始する前に、処理中に調査される質問を知っておく必要があります。 通常、バッチ処理は待ち時間が長く、ビッグデータバッチジョブの速度は通常数分以上で測定されます。 + バッチ処理が輝く場所:_データのインデックス作成、Webのクロール、データのクランチ+ _Hadoopでこれを実行できるプログラム: MapReduce、Tez、Spark、Hive、Flink

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

    Hadoop用にこれを行うプログラム: Impala、Drill、HAWQ、Presto、Vortex、およびVertica SQL、Tez

  • ストリーム処理
    ストリーム処理システムは、大量の個別のデータポイントを取得し、連続クエリを実行して、システムに新しいデータが到着するとほぼリアルタイムの結果を生成します。 + ストリーム処理が輝く場所:_すでにデジタルデータが継続的に生成されている場合。 例としては、ソーシャルメディアの問題、イベント、または製品に対する世論を監視して、新しいトレンドを追跡したり、サーバーログを監視したりします。 + _Hadoop向けにこれを行うプログラム: Spark Stream、Storm

  • グラフ処理
    通常、グラフアルゴリズムは、1つの頂点から別の頂点にエッジを移動するために、頂点またはホップ間の通信を必要とします。 + グラフが輝く場所:_グラフは、Facebookの友人関係、Twitterのフォロワー、ソーシャルメディアサイトのコアのような分散グラフデータベースなど、物事間の非線形関係を示すのに最適です。 + _Hadoop用にこれを行うプログラム: Apache Giraph、Apache SparkのGraphX、Hama、Titan

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

[[4---resourcemanager-high-availability]] === 4-ResourceManager高可用性

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

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

Hadoop 3.x

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

結論

この記事では、ますます大規模なデータセットのニーズを満たすためにHadoopがどのように進化したかを見てきました。 Hadoopの実験に興味がある場合は、https://www.digitalocean.com/community/tutorials/how-to-install-hadoop-in-stand-alone-mode-on-をご覧ください。 ubuntu-16-04 [Ubuntu 16.04へのスタンドアロンモードでのHadoopのインストール]。 一般的なビッグデータの概念の詳細については、https://www.digitalocean.com/community/tutorials/an-introduction-to-big-data-concepts-and-terminology [ビッグデータの概念と用語の紹介]を参照してください。

前の投稿:Ubuntu 16.04でLet’s Encryptを使用してRancher Webアプリを保護する方法
次の投稿:MySQLクエリのトラブルシューティング方法