hadoopのバージョンの進化とその他
8055 ワード
http://blog.csdn.net/feitongxunke
以下の資料はすべてネット上から収集され、リンクは一番下にあります.
1.まずHadoopの公式説明を貼ります
Apache Hadoop公式バージョンの説明を先に貼り付けます(これまで2014-07-07):
1.2.X - current stable version, 1.2 release
2.4.X - current stable 2.x version
0.23.X - similar to 2.X.X but missing NN HA.
しかし、ネット上で大きな0.20.Xと0.23.Xを検索すると、どんな違いがありますか?前の公式バージョンの説明を貼り続けます.
1.0.X - current stable version, 1.0 release
1.1.X - current beta version, 1.1 release
2.X.X - current alpha version
0.23.X - simmilar to 2.X.X but missing NN HA.
0.22.X - does not include security
0.20.203.X - old legacy stable version
0.20.X - old legacy version
2.2本の支線
ここでの0.20.xと0.23.xはそれぞれ1.xと2.xに発展した.
ここに2本の線0.20と0.23があるのに、どうして2本の線があるのですか?第1世代のHadoopには、0.20.x、0.21.x、0.22.xの3つのバージョンがあり、後の2つはNameNode HAなどの重要な特性が含まれているためです.第2世代のHadoopは、それぞれ0.23.xと2.xの2つのバージョンを含み、Hadoop 1.0とは全く異なり、ここではHDFS FederationとYARNの2つのシステムを含む新しいフレームワークです.さらに0.23.xに比べて2.xはNaneNode HAとWire−compatibilityの2つの重要な特性を増加させた.
ここを見て分かるように、Hadoop 1.2.1とHadoop 2.4.0を構成すると、2.4.0にyarn-site.xmlというファイルがあり、mapper.xmlには次のような問題があります.
ここからも見えます.では、YARNは何ですか.
3.YARNについて
YARNについて話す前に、元Hadoop MapReduceフレームワークについて質問しなければなりません.フレーム図は下図のように、図からいくつかの点を見ることができます.
ユーザープログラムJobClientはjobを提出し、jobはJobTrackerに情報を送り、JobTrackerはクラスタ内のマシンタイミング通信(heartbeat)を担当し、どのプログラムがそれらのマシン上で走るべきか、すべてのjobの失敗、再起動などの操作を管理する必要がある.
TaskTrackerは各クラスタにある各マシンの一部であり,自分のマシン上のリソース状況の監視を担当する.現在のマシンのtasks運転状況を同時に監視します.TaskTrackerは、これらの情報をheartbeatを介してJobTrackerに送信する必要があります.JobTrackerは、新しくコミットされたjobにどのマシンで実行されているかを割り当てるために、これらの情報を収集します.
では、この時も問題が明らかになりました.以下のいくつかの問題があります.ここには一部しか書かれていません.
JobTrackerはMap-reduceの集中的な処理ポイントであり,単一の障害がある.
JobTrackerは多くのタスクを完了し、リソースの消費量が多すぎるため、map-reduce jobが非常に多い場合、メモリのオーバーヘッドが大きくなり、潜在的にはJobTracker failのリスクも増加し、業界では古いHadoopのMap-Reduceが4000ノードホストしかサポートできないという上限をまとめています.
TaskTracker側では、map/reduce taskの数をリソースとして表すのは簡単すぎて、cpu/メモリの占有状況を考慮せず、2つの大きなメモリ消費taskが1つにスケジューリングされると、OOMが発生しやすい.
ここで省略します(多くの不足はウェブサイトを参考にして下を参照してください....)
分散システムの変化傾向とhadoopフレームワークの長期的な発展を満たすために,このとき〜フレームワークの性能エネルギーボトルネックを根本的に解決する必要がある.バージョン0.23.0から、HadoopのMapReduceフレームワークが完全に再構築され、根本的な変化が発生しました.新しいフレームワークはMapReduceV 2またはYarnと命名され、フレーム構造図は以下の通りである.
この時私たちのYARN(Yet Another Resource Negotiator)が出てきました!!!
YARNで最も重要なのは、Hadoop 1.0のJobTrackerのリソース管理とジョブ制御機能を分離し、コンポーネントResourceManagerとApplicationMasterによって実現されます.前者はすべてのアプリケーションのリソース割り当てを担当し、後者は1つのアプリケーションのみを管理します.
このときYARNで最も重要なのはResourceManager、ApplicationMaster、NodeManagerの3つの部分です.
次に、この3つの部分を詳しく説明します.まず、ResourceManagerはセンターのサービスであり、ジョブごとに所属するApplicationMasterをスケジューリングし、起動し、ApplicationMasterの存在状況を監視します.また、古いフレームワークのジョブの中にあるtaskの監視、再起動などの内容も消えてしまった.これもAppMstが存在する理由です.ResourceManagerは、ジョブとリソースのスケジュールを担当します.JobSubmitterから送信されたジョブを受信し、ジョブのコンテキスト情報、およびNodeManagerから収集されたステータス情報に従ってスケジューリングプロセスを開始し、App MstrとしてContainerを割り当てます.NodeManagerの機能は、Container状態の維持を担当し、RMに心拍数を維持することです.ApplicationMasterは、古いフレームワークのJobTrackerのようなJobライフサイクル内のすべての作業を担当します.ただし、Jobごとに(それぞれではない)ApplicationMasterがあり、ResourceManager以外のマシンで実行できることに注意してください.
Yarnフレームワークは古いMapReduceフレームワークに比べてどのようなメリットがありますか?次のように見えます.
この設計はJobTracker(現在のResourceManager)のリソース消費を大幅に削減し、Jobサブタスクのステータスを監視するプログラムを分散化し、より安全で、より美しくします.
新しいYarnでは、ApplicationMasterは変更可能な部分であり、ユーザーは異なるプログラミングモデルに対して自分のAppMstを書くことができ、より多くのタイプのプログラミングモデルがHadoopクラスタで走ることができ、hadoop Yarnの公式構成テンプレートのmapred-site.xml構成を参照することができる.
リソースの表示はメモリ単位(現在のバージョンのYarnではcpuの占有は考慮されていません)で、これまでの残りのslot数よりも合理的です.
古いフレームワークの中で、JobTrackerの大きな負担はjobの下のtasksの運行状況を監視することです.今、この部分はApplicationMasterに捨てられましたが、ResourceManagerにはApplicationsMasters(ApplicationMasterではないことに注意)というモジュールがあります.これはApplicationMasterの運行状況を監視しています.問題が発生したら、他のマシンで再起動します.
Containerは,Yarnが将来のリソース分離のために提案したフレームワークである.この点はMesosの仕事を参考にすべきで、現在は1つのフレームワークで、java仮想マシンのメモリの隔離だけを提供して、hadoopチームの設計構想は後続してもっと多くのリソースのスケジューリングと制御をサポートすることができて、リソースがメモリ量を表す以上、それまでのmap slot/reduce slotが分離してクラスタのリソースが閑散とする気まずい状況をもたらしました.
4.その他の計算フレームワーク
こんなにたくさん書いてあって、私にも読めないものもありますが、大丈夫です.印象があればいいものがたくさんあります.カンフーをすれば自然にできるものがたくさんあります.そして、これらもほらを吹く素材ですね.
次に、Spark、Stormなど、現在人気のある他の計算フレームワークを挙げます.最近、微博や国内のインターネット情報は朝から晩まで大きなデータを話していますが、今は会社が大きなデータと関係を結ばないと上場できないように、でたらめなものです.この間、グーグルI/O大会はMapReduceを何年も使わなかったと言っていましたが、今ではCloud Data flowを使っています.それはデータストリーム全体を処理することができます.この时、MapReduceを学ぶのはもう遅れていると思いますが、実はいいことを言っています.多くの人の努力の程度では、まだ天賦の資格を持っていません.
MapReduce:このフレームワークは誰もが知っているように、オフライン計算フレームワークであり、1つのアルゴリズムをMapとReduceの2段階に抽象化して処理し、データ密集型計算に非常に適しています.
Spark:MapReduce計算フレームワークが適切ではない(できないのではなく、不適切で、効率が低すぎる)反復計算(PageRankなどのmachine learning分野でよく見られる)とインタラクティブ計算(SQLクエリーなどのdata mining分野)、MapReduceはディスク計算フレームワークであり、Sparkはメモリ計算フレームワークであることを知っています.反復アプリケーションとインタラクティブアプリケーションの計算効率を向上させるために、できるだけメモリにデータを配置します.公式ホームページ:http://spark-project.org/
Storm:MapReduceは、広告クリック計算などのストリーミング計算やリアルタイム分析にも適していませんが、Stormはこの計算が得意で、MapReduce計算フレームワークよりもリアルタイム性が優れています.公式ホームページ:http://storm-project.net/
S 4:Yahooが開発したフロー計算フレームワークは,Stormと比較的類似している.公式ホームページ:http://incubator.apache.org/s4/
Open MPI:非常に古典的なメッセージ処理フレームワークであり、高性能コンピューティングに非常に適しており、現在も広く使用されている.
HAMA:BSP(bulk-synchronous parallel model)モデルに基づく分散計算フレームワークは、GoogleのPregelと同様に、マトリクス、図アルゴリズム、ネットワークアルゴリズムなどの大規模な科学計算に使用できます.公式トップページ:http://hama.apache.org/.
Cloudera Impala/Apache Drill:Hadoopベースのより速いSQLクエリーエンジン(Hiveよりずっと速い)、Google Dremelの模倣者.Cloudera Impala公式ホームページ:https://github.com/cloudera/impala,Apache Drill公式ホームページ:http://incubator.apache.org/drill/
Giraph:図アルゴリズム処理フレームワーク、BSPモデルを採用し、pagerank、shared connections、personalization-based popularityなどの反復クラスアルゴリズムの計算に使用できる.公式ホームページ:http://giraph.apache.org/
参考サイト:
http://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-yarn/
http://dongxicheng.org/mapreduce-nextgen/how-to-select-hadoop-versions/
http://dongxicheng.org/mapreduce-nextgen/hadoop-2-0-terms-explained/
http://dongxicheng.org/mapreduce-nextgen/understand-hadoop-yarn-from-os-view/
http://dongxicheng.org/mapreduce-nextgen/hadoop-yarn-problems-vs-solutions/
以下の資料はすべてネット上から収集され、リンクは一番下にあります.
1.まずHadoopの公式説明を貼ります
Apache Hadoop公式バージョンの説明を先に貼り付けます(これまで2014-07-07):
1.2.X - current stable version, 1.2 release
2.4.X - current stable 2.x version
0.23.X - similar to 2.X.X but missing NN HA.
しかし、ネット上で大きな0.20.Xと0.23.Xを検索すると、どんな違いがありますか?前の公式バージョンの説明を貼り続けます.
1.0.X - current stable version, 1.0 release
1.1.X - current beta version, 1.1 release
2.X.X - current alpha version
0.23.X - simmilar to 2.X.X but missing NN HA.
0.22.X - does not include security
0.20.203.X - old legacy stable version
0.20.X - old legacy version
2.2本の支線
ここでの0.20.xと0.23.xはそれぞれ1.xと2.xに発展した.
ここに2本の線0.20と0.23があるのに、どうして2本の線があるのですか?第1世代のHadoopには、0.20.x、0.21.x、0.22.xの3つのバージョンがあり、後の2つはNameNode HAなどの重要な特性が含まれているためです.第2世代のHadoopは、それぞれ0.23.xと2.xの2つのバージョンを含み、Hadoop 1.0とは全く異なり、ここではHDFS FederationとYARNの2つのシステムを含む新しいフレームワークです.さらに0.23.xに比べて2.xはNaneNode HAとWire−compatibilityの2つの重要な特性を増加させた.
ここを見て分かるように、Hadoop 1.2.1とHadoop 2.4.0を構成すると、2.4.0にyarn-site.xmlというファイルがあり、mapper.xmlには次のような問題があります.
<name>mapreduce.framework.name</name><value>yarn</value>
ここからも見えます.では、YARNは何ですか.
3.YARNについて
YARNについて話す前に、元Hadoop MapReduceフレームワークについて質問しなければなりません.フレーム図は下図のように、図からいくつかの点を見ることができます.
ユーザープログラムJobClientはjobを提出し、jobはJobTrackerに情報を送り、JobTrackerはクラスタ内のマシンタイミング通信(heartbeat)を担当し、どのプログラムがそれらのマシン上で走るべきか、すべてのjobの失敗、再起動などの操作を管理する必要がある.
TaskTrackerは各クラスタにある各マシンの一部であり,自分のマシン上のリソース状況の監視を担当する.現在のマシンのtasks運転状況を同時に監視します.TaskTrackerは、これらの情報をheartbeatを介してJobTrackerに送信する必要があります.JobTrackerは、新しくコミットされたjobにどのマシンで実行されているかを割り当てるために、これらの情報を収集します.
では、この時も問題が明らかになりました.以下のいくつかの問題があります.ここには一部しか書かれていません.
JobTrackerはMap-reduceの集中的な処理ポイントであり,単一の障害がある.
JobTrackerは多くのタスクを完了し、リソースの消費量が多すぎるため、map-reduce jobが非常に多い場合、メモリのオーバーヘッドが大きくなり、潜在的にはJobTracker failのリスクも増加し、業界では古いHadoopのMap-Reduceが4000ノードホストしかサポートできないという上限をまとめています.
TaskTracker側では、map/reduce taskの数をリソースとして表すのは簡単すぎて、cpu/メモリの占有状況を考慮せず、2つの大きなメモリ消費taskが1つにスケジューリングされると、OOMが発生しやすい.
ここで省略します(多くの不足はウェブサイトを参考にして下を参照してください....)
分散システムの変化傾向とhadoopフレームワークの長期的な発展を満たすために,このとき〜フレームワークの性能エネルギーボトルネックを根本的に解決する必要がある.バージョン0.23.0から、HadoopのMapReduceフレームワークが完全に再構築され、根本的な変化が発生しました.新しいフレームワークはMapReduceV 2またはYarnと命名され、フレーム構造図は以下の通りである.
この時私たちのYARN(Yet Another Resource Negotiator)が出てきました!!!
YARNで最も重要なのは、Hadoop 1.0のJobTrackerのリソース管理とジョブ制御機能を分離し、コンポーネントResourceManagerとApplicationMasterによって実現されます.前者はすべてのアプリケーションのリソース割り当てを担当し、後者は1つのアプリケーションのみを管理します.
このときYARNで最も重要なのはResourceManager、ApplicationMaster、NodeManagerの3つの部分です.
次に、この3つの部分を詳しく説明します.まず、ResourceManagerはセンターのサービスであり、ジョブごとに所属するApplicationMasterをスケジューリングし、起動し、ApplicationMasterの存在状況を監視します.また、古いフレームワークのジョブの中にあるtaskの監視、再起動などの内容も消えてしまった.これもAppMstが存在する理由です.ResourceManagerは、ジョブとリソースのスケジュールを担当します.JobSubmitterから送信されたジョブを受信し、ジョブのコンテキスト情報、およびNodeManagerから収集されたステータス情報に従ってスケジューリングプロセスを開始し、App MstrとしてContainerを割り当てます.NodeManagerの機能は、Container状態の維持を担当し、RMに心拍数を維持することです.ApplicationMasterは、古いフレームワークのJobTrackerのようなJobライフサイクル内のすべての作業を担当します.ただし、Jobごとに(それぞれではない)ApplicationMasterがあり、ResourceManager以外のマシンで実行できることに注意してください.
Yarnフレームワークは古いMapReduceフレームワークに比べてどのようなメリットがありますか?次のように見えます.
この設計はJobTracker(現在のResourceManager)のリソース消費を大幅に削減し、Jobサブタスクのステータスを監視するプログラムを分散化し、より安全で、より美しくします.
新しいYarnでは、ApplicationMasterは変更可能な部分であり、ユーザーは異なるプログラミングモデルに対して自分のAppMstを書くことができ、より多くのタイプのプログラミングモデルがHadoopクラスタで走ることができ、hadoop Yarnの公式構成テンプレートのmapred-site.xml構成を参照することができる.
リソースの表示はメモリ単位(現在のバージョンのYarnではcpuの占有は考慮されていません)で、これまでの残りのslot数よりも合理的です.
古いフレームワークの中で、JobTrackerの大きな負担はjobの下のtasksの運行状況を監視することです.今、この部分はApplicationMasterに捨てられましたが、ResourceManagerにはApplicationsMasters(ApplicationMasterではないことに注意)というモジュールがあります.これはApplicationMasterの運行状況を監視しています.問題が発生したら、他のマシンで再起動します.
Containerは,Yarnが将来のリソース分離のために提案したフレームワークである.この点はMesosの仕事を参考にすべきで、現在は1つのフレームワークで、java仮想マシンのメモリの隔離だけを提供して、hadoopチームの設計構想は後続してもっと多くのリソースのスケジューリングと制御をサポートすることができて、リソースがメモリ量を表す以上、それまでのmap slot/reduce slotが分離してクラスタのリソースが閑散とする気まずい状況をもたらしました.
4.その他の計算フレームワーク
こんなにたくさん書いてあって、私にも読めないものもありますが、大丈夫です.印象があればいいものがたくさんあります.カンフーをすれば自然にできるものがたくさんあります.そして、これらもほらを吹く素材ですね.
次に、Spark、Stormなど、現在人気のある他の計算フレームワークを挙げます.最近、微博や国内のインターネット情報は朝から晩まで大きなデータを話していますが、今は会社が大きなデータと関係を結ばないと上場できないように、でたらめなものです.この間、グーグルI/O大会はMapReduceを何年も使わなかったと言っていましたが、今ではCloud Data flowを使っています.それはデータストリーム全体を処理することができます.この时、MapReduceを学ぶのはもう遅れていると思いますが、実はいいことを言っています.多くの人の努力の程度では、まだ天賦の資格を持っていません.
MapReduce:このフレームワークは誰もが知っているように、オフライン計算フレームワークであり、1つのアルゴリズムをMapとReduceの2段階に抽象化して処理し、データ密集型計算に非常に適しています.
Spark:MapReduce計算フレームワークが適切ではない(できないのではなく、不適切で、効率が低すぎる)反復計算(PageRankなどのmachine learning分野でよく見られる)とインタラクティブ計算(SQLクエリーなどのdata mining分野)、MapReduceはディスク計算フレームワークであり、Sparkはメモリ計算フレームワークであることを知っています.反復アプリケーションとインタラクティブアプリケーションの計算効率を向上させるために、できるだけメモリにデータを配置します.公式ホームページ:http://spark-project.org/
Storm:MapReduceは、広告クリック計算などのストリーミング計算やリアルタイム分析にも適していませんが、Stormはこの計算が得意で、MapReduce計算フレームワークよりもリアルタイム性が優れています.公式ホームページ:http://storm-project.net/
S 4:Yahooが開発したフロー計算フレームワークは,Stormと比較的類似している.公式ホームページ:http://incubator.apache.org/s4/
Open MPI:非常に古典的なメッセージ処理フレームワークであり、高性能コンピューティングに非常に適しており、現在も広く使用されている.
HAMA:BSP(bulk-synchronous parallel model)モデルに基づく分散計算フレームワークは、GoogleのPregelと同様に、マトリクス、図アルゴリズム、ネットワークアルゴリズムなどの大規模な科学計算に使用できます.公式トップページ:http://hama.apache.org/.
Cloudera Impala/Apache Drill:Hadoopベースのより速いSQLクエリーエンジン(Hiveよりずっと速い)、Google Dremelの模倣者.Cloudera Impala公式ホームページ:https://github.com/cloudera/impala,Apache Drill公式ホームページ:http://incubator.apache.org/drill/
Giraph:図アルゴリズム処理フレームワーク、BSPモデルを採用し、pagerank、shared connections、personalization-based popularityなどの反復クラスアルゴリズムの計算に使用できる.公式ホームページ:http://giraph.apache.org/
参考サイト:
http://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-yarn/
http://dongxicheng.org/mapreduce-nextgen/how-to-select-hadoop-versions/
http://dongxicheng.org/mapreduce-nextgen/hadoop-2-0-terms-explained/
http://dongxicheng.org/mapreduce-nextgen/understand-hadoop-yarn-from-os-view/
http://dongxicheng.org/mapreduce-nextgen/hadoop-yarn-problems-vs-solutions/