8.1Hadoopの最適化と開発
- Hadoop1.0不備と限界
- 抽象化のレベルが低いです
- 発現する能力を制限
- 開発者は、ジョブ間、自分の依存関係を管理します
- 全体的なプログラムロジックを参照してくださいすることは困難
- 反復の実装の効率が低いです
- 資源の無駄
- 悪いリアルタイム
- 改善とHadoopののアップグレード
- 1.0つのノード名は、単一障害点が存在し、ホットバックアップ機構HDFS HAノード名を提供するように設計され
- 単一の名前空間のリソースの分離は、設計HDFS連盟、複数の名前空間の管理を達成することはできません
- 低MapReduceのリソース管理効率化のために、新しいリソース管理フレームワーク糸の設計
- 豚は、大規模データ処理スクリプト言語は、抽象化の低レベルの問題を解決するために
- Oozie、ワークフローエンジンとコラボレーションサービス、ヘルプ実行Hadoopの異なるタスクには、解決するには、依存関係の管理メカニズムを提供していません。
- TEZ、支持計算フレームワークDAGジョブ、分解及び再組立動作のための仕事は、動作が異なるタスク間のMapReduceを解決するために繰り返されます。
- 通常のHadoopエコ様々な部品や製品間の均一なデータの不足に対処するためのさまざまなコンポーネント間のデータの異なる種類の効率的な交換のための交換ハブのビッグデータ分析のためのエンタープライズ・データ・プラットフォームとして、パブリッシュ・サブスクライブ・メッセージングシステムを分散カフカは、仲介交換します。
8.2HDFS2.0の新機能
HDFS HDFS HAおよび連邦増加
HDFS HA
- 第2のノードは、定期的に、画像ファイルの名前空間ノード（FsImage）の名前から得られるロール名HDFS1.0、に存在し、原稿を交換し、マージノード名に送信されるログ（EditLog）を、変更します第二も、ノード名を維持しながら、FsImageは、ログファイルが大きすぎないようにします。あなたはコールドバックアップをすることができるように。
- 単一点HAアーキテクチャを使用して活性である二つの名前のノードを、問題を解決するためにHDFS2.0。これは、熱がバックアップすることができています。ノードの2人の同期状態名は、共有システムによって実現することができ、NFS、QJMまたは飼育係は、飼育係管理を使用して、2つのバトラーを防ぎます。
HDFS連盟
- HDFS1.0のみノード名、水平に延びていない、全体的な性能は、単一のノード名のスループットによって制限されます。HDFS HA問題を解決するための単一障害点ではなく、アドレススケーラビリティ、パフォーマンス、分離株の問題を行います。
- 連盟の建築設計では、他の複数
独立のノード名の、ネーミングサービスHDFSは互いに、必要同士が協調しないように、連邦関係、それぞれ、水平方向のノードおよび名前空間の管理ブロックの名前をそれぞれ延びるように。 - 連邦ノードの名前では、名前空間とブロック管理機能を提供し、すべてのノードの名前は、データは、基礎となるストレージ・リソースをノード共有しています。
- HDFS連邦のアクセス方法は、クライアントテーブルのデータ共有をマウントするために使用することができます。
- 1.0利点と比較すると：
- HDFSクラスタのスケーラビリティ、ディレクトリの一部を担当する各
- 高いパフォーマンス
- グッド分離
- HDFS Federationが不良の問題単一点を解決しないことに注意してくださいは、独立した理由は、各ノードのバックアップノード名を展開するために必要であると推定されます。
8.3リソース管理スケジューリングフレームワークの新世代
- マスタ/スレーブ・アーキテクチャを使用してMapReduce1.0、およびJobTracker TaskTracker、以下の欠点を複数含みます。
- 単一障害点
- 先導的な役割の過負荷（三つの機能、リソース管理、タスクスケジューリングとタスクの監視）「のすべてに取って」JobTracker
- メモリオーバーフローを起こしやすいです
- リソースは不合理分割します
- YARN（もう一つのリソース交渉）デザインのアイデア
- 基本的な考え方は、元の関数の分割、分散化です
- アプリケーションの監視を開始;クライアントの要求に対処するためのリソースを管理する責任のResourceManagerノードマネージャを監視し、リソースの割り当てとスケジューリング
- ApplicationMasterスケジューリングの責任とアプリケーションのリソースのアプリケーションを監視し、内部に割り当てられ、タスクスケジューリング、監視、およびフォールトトレランス
- 単一ノード上の元のタスクの実装、リソース管理を担当するノードマネージャTaskTracker;のResourceManagerからの処理コマンド、ApplicationMasterからのコマンドの処理
- 糸は、動的リソース割当部としての容器（コンテナ）であります
- YARNのResourceManagerのコンポーネントと最上位ノードに展開HDFSネームノード
- YARNザApplicationMasterとノードマネージャHDFSとデータノードが一緒に展開されています
YARNのワークフロー
- ライトユーザーのクライアントアプリケーションなどApplicationMasterプログラム、開始コマンド、ユーザプログラムを含む、糸にプログラムを提出
- YARNザ・ResourceManagerがクライアントからのリクエストを受信して処理。ApplicationMasterを開始
- ApplicatioMasterは、最初に登録した後に作成されたのResourceManager
- アプリケーションリソースのResourceManager RPCプロトコルによるApplicationMasterポーリング方式
- ApplicationMasterの容器の形で資源のResourceManager割り当ては、取得したノードマネージャリソース一度容器の内部と通信します。
- ApplicationMasterコンテナが、彼は仕事のための優れた動作環境を設定するタスクを開始する時期は、タスクの開始コマンドは、タスクを開始するには、コンテナでこのスクリプトを実行するスクリプトを書きました。
- 個々のタスクは、ApplicationMaster RPCプロトコルを介して実行するために、各タスクのステータスの後れを取らないことができ、タスクが失敗した場合は、タスクを再起動することができます。
- アプリケーションが完成し実行すると、ApplicationMasterはログアウトしてアプリケーションマネージャのあなたのResourceManagerを閉じます。
MapReduce1.0に比べ利点の糸枠組み
- 大幅クマセンターサービスのリソース消費を減らすのResourceManager
- MapReduceは、計算フレームワークでなく、リソース管理、スケジューリングフレームワークですが、唯一のMapReduceプログラミングモデルをサポートすることができます。糸の枠組みを計算する様々なを実行することができ、純粋なリソーススケジューリングフレームワーク。
- YARNリソース管理がより効率的に
YARN開発目標
