前の記事のMapReduceのコメント（小学校）のHadoopの私たちは、プロセスを理解し、実装プロセスのMapReduceのシャッフル、この記事では主に、入力と出力の構成部品とのMapReduceの側面から詳述。
、MapReduceのジョブ制御モジュール、およびその他の機能
MapReduceはジョブ制御モジュール、プログラミング・モデル、データ処理エンジンを含みます。ここでは、作業制御モジュールMRAppMasterに焦点を当てています。
1.1、MRAppMaster組成
以下に示すようにMRAppMaster本体は、以下の構成を有します。
。1、ContainerAllocator：のResourceManagerは、アプリケーションのMapReduceリソースに必要なリソースと通信<優先順位、ホスト名、能力、容器として説明された動作 、relax_locality> 5 それぞれタプルフォーマット、ジョブの優先度、所望のノードのリソース、リソース量、数コンテナ、たるみ産地。ContainerAllocator定期的なRPC経由のResourceManagerとの通信、およびハートビート応答がなどを完了するために必要なコンテナ、コンテナリスト情報のリストを返すのResourceManagerを介して。
ContainerAllocatorワークフロー：
ステップ1：RMにリソース需要地図タスクを送信し、
ステップ2：あなたはスケジューリング条件は、タスクの削減に達した場合は、[タスクを削減するためのリソースを適用し始めた;
ステップ3：タスクのためのリソースへのアプリケーションならば、他のアプリケーションは、重複するリソースをキャンセル。HDFSは、データのどの部分が、通常3つのバックアップを持っており、タスクのために、地域の自然のラックと任意のレベルを考えると、それは7つのリソース要求に対応することができますのでことは
ステップ4：タスクが失敗した場合は、再度ましますそのタスク用のアプリケーションのリソース;
ステップ5：タスクが遅すぎる実行されている場合（投機実行機能が有効になっている場合）、それはバックアップジョブを開始するために追加のリソースのために適用されます。
ステップ6：タスクの過剰な数のノード障害であれば、それはすべてのリソースのノードのアプリケーションに対する要求を撤回します
2、ClientServer上：実現MRClientprotocolプロトコル（のResourceManager経由せず）は、ジョブのプロトコルの実行状態に介して取得することができ、クライアントと制御動作は、（キルジョブとして、仕事などの優先順位を変更します）
3、ジョブ：ジョブのMapReduce、運用ステータス監視ジョブの責任は、様々なジョブの状態機械の動作、実装依存の操作の非同期実行を維持します
4、タスク：タスクの動作状態を監視する責任のMapReduceジョブタスク、さまざまなタスクを実行するために関連する非同期操作を実装してステートマシンを維持する作業。
5、TaskAttemptは：実行中のインスタンスを表します。
6、TaskCleaner：暫定結果はクリーンアップを担当する任務に失敗したか、ディレクトリのタスクを殺すと、スレッドプール、共有キューを生成し、維持、タスクによって生成されたジャンク非同期データを削除します
7、Speculatorの：他のタスクよりも実行速度上のタスクが大幅に低下する場合、完全には、その執行機能を推測する場合、Speculatorのは、実行が終了していない仕事をオフに殺すのタスクを実行し、タスクの同じ機能を開始します。
8、ContainerLauncher：ノードマネージャとの通信を担当し、コンテナを起動します
9は、TaskAttempListener：ハートビートのさまざまなタスクを担当し、タスクの期間内に情報を報告していない場合は、ハートビートは、タスクが死んだとみなされ、それがシステムから削除されます。
10は、JobHistoryEventHandler：など雇用創出、操作、など様々な仕事、担当のイベントログは、仕事に便利を再開し、指定したディレクトリHDFSの下に書かれています。
1.2、MapReduceのクライアント
そして、糸は、ユーザーがクライアントを介して、通信する唯一の方法は、ユーザーが、糸にジョブを送信することができますジョブの動作状態を取得するために、ジョブ制御（ジョブまたはタスクを殺す）、クライアントは2つの通信プロトコルを設計することです。
ApplicationClientProtocol：このResourceManager契約を実装するには、クライアントは、ジョブを殺す、合意を通じてジョブを送信操作と他の操作の優先順位を変更する必要があります
MRClientProtocol：ジョブがアプリケーションマスターを開始し、ユーザが直接アプリケーションマスターと通信することを可能にする、MRClientProtocolプロトコルを実装MRClientServerサービスを開始、のResourceManagerの圧力を低下させる、直接プロトコルのジョブの実行状況と動作制御を取得します。
1.3、MRAppMasterワークフロー
仕事に実行することです非ユーバーモードのユーバーパターンのローカルモード、糸と糸：
選択ローカルモードと糸のモードを初めて目：クライアントは、動的にJavaの標準ライブラリServerloaderを介してすべてのClientProtocolProviderを達成ロードされ、JobClient使用してジョブをサブミットします。LocalClientProcotolProviderとYarnClientProcotolProvider：デフォルトでは2つの実装があります。構成パラメータが糸をmapreduce.framework.modeに設定されている場合、クライアントは、メソッドのYarnRunner.submitJobによって糸にジョブを送信できるように、真のクライアントとしてYarnRunnerオブジェクトを作成し、YarnClientProcotolProviderを採用します。この方法はさらに、呼び出し内部に実装submitApplication方法ApplicationClientProcotolは、このResourceManagerにジョブを送信します。ソースの詳細を見つけることができます：ジョブ投入のhadoop2.7は説明（上）
非ユーバーユーバーモードモードの選択：
ユーバー最適化モデルは、小さな仕事である、MrAppMasterはもはや、各タスクのための資金調達のために適用されませんが、容器を再利用することができ、マップや同じリソース上のシリアル実行を削減します。
ユーバーモード条件：
mapreduce.job.ubertask.enable＃のユーバーモードが有効になっている
mapreduce.job.ubertask.maxmapsマップの最大数（デフォルト9）#ubertask
mapreduce.job.ubertask.maxreduces #ubertask（デフォルト1）削減の最大数
mapreduce.jobを。 ubertask.maxbytesが最大ジョブサイズを#ubertask（デフォルトはblock.sizeある）
リソースマップと使用可能なリソースを超えてはならない使用を減らすMRAppMaster
糸ユーバーモードの実行を使用して、上記の条件を満たし、または非実行モードユーバー
糸走行のMapReduceジョブは二つの問題解決する必要がある場合：
1を、仕事シャシ侯は、より適切な開始削減
パラメータmapreduce.job.reduce.slowstart.completedmapsによって制御されて、それがこの値に達した後のマップ作業完了の割合は、タスクのリソースを削減するために適用されるとき、デフォルトは0.05であることを示しています。
2、どのようにシャッフルプロセスを完了するために
ユーザは、糸中のMapReduceアプリケーションを送信すると、糸二相は、アプリケーションを実行する：
第一段階は、このResourceManagerによってMRAppMasterを開始することであり、
第二段階は、そのアプリケーションのリソースのために、MRAppMasterてアプリケーションを作成することであり、そして操作が完了するまで、その全体の動作を監視します。
次のように具体的な動作のフローチャートです。
ステップ1：プログラムMRAppMasterを含むアプリケーションに提出したユーザ糸、MRAppMasterコマンド、ユーザプログラムなどを起動する;
ステップ2：このResourceManagerが容器のアプリケーションのために割り当てられ、対応するノードマネージャと通信し、それがことが要求されますコンテナはMRAppMasterアプリケーションを起動する;
ステップ3：MRAppMasterは、ユーザーが、このResourceManagerから直接アプリケーションを実行しているのステータスを表示することができ、その後、それは内部業務アプリケーションのリソースであり、その運用状況を監視するようにこのResourceManagerを登録する最初を開始した後、ランの終わりまで、すなわち、繰り返し4-7ステップ;
ステップ4：RPCプロトコルによってMRAppMasterポーリング方法は、要求とリソースのResourceManagerを取得する;
ステップ5：リソースMRAppMasterアプリケーションと、対応するノードマネージャと通信し、それを開始するために必要とされますタスク;
ステップ6：ノードマネージャは、タスクのために（などの環境変数、JARパッケージ、バイナリを含む）動作環境を設定した後、タスクの開始コマンドは、スクリプトを書き込み、スクリプトがタスクを実行することによって開始し、
ステップ7：さまざまなタスクRPC協会 会議MRAppMasterは、タスクが失敗した場合、タスクを再起動することができ、各タスクを、実行し続ける作るために自分のステータスと進行状況をMRAppMasterするレポート;
ステップ8：アプリケーションの実行が終了したら、MRAppMasterはログアウトし、あなたのResourceManagerを閉鎖します
1.4、投機的実行
分散クラスタ環境では、ソフトウェアのバグ、負荷の不均衡やリソース及び他の理由の偏在するので、ジョブの速度で複数のタスク間の不整合をもたらす、いくつかのタスクは、いくつかの点で、例えば他のタスク（より有意に遅い実行します、ジョブのタスクの進行状況のみ10％、他のすべてのタスクが実行を終了しているが）、これらのタスクは、ジョブの全体的な実装の進行が遅くなります。このような状況、投機的実行（投機的実行）メカニズムの使用を避けるために、Hadoopのは、タスクのためのバックアップタスクを開始しますので、データ処理タスクの元のコピーを使用してバックアップジョブが同時に、最初は、結果として、意志の実行を完了するために最終的な結果。
アルゴリズムの投機的実行コアのアイデアは、次のとおりです。時間は、バックアップジョブが完了するまでの時間を見積もることができ、それは、バックアップタスクを開始することを前提とし、アプローチがあり、ドラッグタスクかどうか、バックアップタスクが開始、それは価値があるかどうかを判断しますestimatedEndTime2;差estimatedEndTime1のestimatedEndTime2大きいが、タスクの値が大きいほど傾向、バックアップタスクを開始することを示したように、同様に、現時点で算出された速度は、タスクに応じて、タスクは、最も可能性の高い完了時間estimatedEndTime1を推定することができる場合タスクへのバックアップタスクを開始します。
このアルゴリズムの最大の利点は、効率が有効なバックアップタスクの数と、すべてのバックアップタスクの数の比率でバックアップタスクの効率を最大化することで、タスクが有効なバックアップの完了時間は、（元のタスク完了時間のバックアップタスクよりも早いですそれは）バックアップタスクの真のメリットをもたらします。より効率的なバックアップタスクは、アルゴリズムのそれより優れた実行、メリットも大きいことを示唆、があります。
投機的実行機構は、実際に古典的な最適化手法である：時間のためのスペースは、それが同じデータの処理を開始し、これらのタスクは、データ処理時間の競争を減らすことができるように、同時に同じタスクの詳細です、明らかにこのアプローチは、より多くを必要としますコンピューティング・リソースを、クラスタリソースが不足している場合には、計算時間の偉大な仕事を減らし、資源量の少ないマルチ戦いで、このメカニズムを使用するのが妥当でなければなりません。
制御パラメータ：
mapreduce.map.speculative
mapreduce.reduce.speculative
二、MapReduceの入力と出力フォーマット
2.1入力フォーマット
2.1.1、フラグメンテーション
FileInputFormatでは、計算されたスライスは、ソースを参照してください：ファイルのスライスのhadoop2.7ジョブ投入説明
論理セクションのサイズを計算する：Math.max（に、minSize、Math.min（maxSizeの 、のblockSize））
デフォルトに、minSizeは1であり、デフォルト値は最大長maxSizeのタイプデフォルトのサイズはのblockSize（スライスされる有することができます128M）
ブロックサイズパラメータよりmaxSizeのトーン小型、その後、チップが小さくなりましょう、そしてそれは、このパラメータの設定の値に等しい場合
に、minSizeパラメータ調整のblockSizeよりも大きい場合、あなたはスライスを持つことができますがブロックサイズより大きくなりました
コンピュータの強い性能は複数のデータ片を扱うことができるため、データの複数のスライスに並列に処理されるマップのタスクを構築するために、各スライスについてのHadoop、プロセス全体は、よくデータのロード・バランシングであろう、フラグメンテーションは、ジョブ全体の実行時間を決定する時間を構築する複数のタスクをマップ、小さすぎる切断、または管理との間の伝送時間の複数の断片化マップデータを削減することができない。（ほとんどの時間ではなく計算に）ファイルサイズが128M未満である場合には、ファイルがmaptaskプロセスに関係なく、ファイルは単一のスライスになりますどのように小さな、スライスしないことはありません。がある場合は、小さなファイルが多数maptaskの数が多い、大幅に削減クラスタのパフォーマンスになります。
注：断片自体はデータ自体が、データへの参照、ローカリゼーション・タスクできるだけMapReduceのマップデータを有効にするシステムのための記憶場所を含み、断片の大きさは、大きい断片を優先するために、ソートするために使用される
、それによって小さなジョブの実行時間の。
2.1.2、小さなファイル処理
小さなファイルは、唯一のストレージ圧力名前ノードを増やすだけでなく、ジョブを実行する際に、アドレスの数を増やし、高ボリュームマップの増加の原因となりますので、小さなファイルを扱うことが必要であることはありません。
1、フロントエンドは、すなわち、後のMapReduceは、小さな多数のファイルを扱う使う小さなファイルを格納するのに適していない欠点のHDFSを避けるため、だけでなく、問題を回避するために、大規模なファイルにデータ処理の統合の小さなファイルで、その後、HDFSにアップロードされます。（ほとんどの提唱アプローチ）
図2は、差があるスライス（CombineFileInputFormat）、その論理チップFileInputFormat（デフォルト）を行い、それがスライスに論理プログラミングに小さな複数のファイルであってもよい別のInputFormatを使用することができ、HDFS小さなファイルにされていますmaptaskプロセスへ。
スライスを避けるために、どのように2.1.3
図1に示すように、動的に調整ブロックサイズ
2、isSplitable書き換え（）メソッドがfalseを返します
2.1.4、格納されたテキストデータ片の行全体
テキストレコードの行が格納されている2つのスライスにスライスされますが、また、データが失われないと、データが繰り返されないことを確実にする方法。
実際には、二つの断片を横切る行のHadoopのケースは特別な治療でした。
InputSplitは、通常のHadoop FileSplit三のFileSplit主記憶情報<パス、開始、スライスの長さ>を用いています。：断片サイズは100を分割した後、次いで、250バイトのファイルが提供されているように、我々は以下FileSplitを取得するものとする
<パス、0、100>
<経路、100、100>
、<パス、200は、50>
（特定セグメンテーションアルゴリズムはFileInputFormatを参照して実施することができます）
したがって、実際には、各だけのMapReduceプログラム類似<パス、0、100>情報を得ます。MapReduceのプログラムが実行を開始すると、開始するように配置パスFSDataInputStream、に従って構築し、データの読み取りを開始。FileSplitの最後の文字を読むときにブレークを行いない場合は、最初の改行は次のFileSplitを読むまでFileSplitの最後の行に対処するには、、、それは次のFileSplitの内容を読み取るしていきます。このように、我々は不完全な行を取得することはできませんことを保証します。
そして、ときFileSplitの過程でMapReduceは、どのようにFileSplitがない知っています。このFileSplitの最初の行を扱ってきましたか？
私たちは前に改行FileSplitないが、もしそうなら、スプリットの現在の最初の行が処理されていない、とされていない場合、現在の分割の最初の行が処理された、我々はスキップすべき最後の文字をチェックする必要があります。
LineRecordReaderにおいて、還元の現在FileSplit開始を前述のロジックを実装するための非常に巧妙な方法を使用して、その後、（これは、以下のコードフラグメントである）最初の行をスキップ
} 他{ 場合（開始！= 0 ）{ skipFirstLine = 真; - スタート。 fileIn.seek（スタート）。 } で = newLineReader（fileIn、ジョブ、recordDelimiter）。 } 場合（skipFirstLineは）{ // 最初の行をスキップして「スタート」を再確立します。 + = in.readLineは（をnewText（）、0開始、 （INT）Math.min（（長い）Integer.MAX_VALUEでは、エンド開始します））。 }
2.1.5共通の入力フォーマット
二つの機能を提供し、そのデータソースのInputFormatベースクラスとして使用されているすべてのファイルFileInputFormat、一方はジョブ入力ファイルの場所は、入力ファイルは、グリーンシートのコンポーネント符号であることが指摘されています。スライスは、その実装を完了し記録サブクラスに分割され、以下のように、FileInputFormat階層構造は以下の通りであります：
2.2、出力フォーマット
入力フォーマットの一つは、次のようにOUTPUTFORMAT階層構造であり、対応する入力フォーマットを有するであろう。
一般的な出力形式：
より多くのHadoopの生態の記事を参照してください： Hadoopのエコシリーズ
参考：
https://blog.csdn.net/appstore81/article/details/15027767
https://www.cnblogs.com/52mm/p/p15.html
https://blog.csdn.net/u011812294/article/details/ 63262624
https://blog.csdn.net/penggougoude/article/details/82432802#commentBox
「Hadoopの第4版のビッグデータストレージおよび分析にDefinitive Guideの」
「の原則の糸アーキテクチャの設計と実装のHadoopの技術インサイダーの詳細な分析」