MapReduce ワークフロー
生データファイル
1T データはブロックに分割されて HDFS に保存され、各ブロックのサイズは 128M です
データブロック ブロック
HDFS 上のデータ ストレージの単位であり、同じファイル内のブロックのサイズは同じです。HDFS
ではデータ ストレージは不変であるため、ブロックの数がクラスターの計算能力と一致しない可能性があります。動的なデータ ストレージが必要です。計算に参加するための調整。ノード数の単位。
スライス分割
スライスは論理的な概念です。
現在のデータ ストレージを変更せずに、計算に参加するノードの数を制御できます。計算ノードの数を制御する目的は、スライスのサイズによって達成できます。スライスの数と同じだけあります
。 、同じ数の Map タスクが実行されます。
一般に、スライス サイズは、冗長作成と多数のデータ接続を防ぐために、ブロック (2 1/2) の整数倍です。
分割>ブロックの場合、計算ノードは少なくなります。
分割<ブロックの場合、計算ノードは増えます
。デフォルトでは、スライス サイズはブロックの整数倍です。 , 分割スライスのサイズはブロックと同じです。サイズ、デフォルトは 128M です。スライスは MapTask に対応します。
マップタスク
Map はデフォルトでスライスからデータを読み取り、一度に 1 行 (デフォルトのリーダー) をメモリに読み取ります。
独自の記述に従って、単語分割ロジック (スペースで区切って) を作成できます。各単語の出現数を計算します。生成されます (Map <String,Integer>) メモリに保存される一時データですが、
メモリ サイズには制限があります。複数のタスクが同時に実行されると、メモリ オーバーフロー (OOM) が発生する可能性があります。ハードディスクに直接保存すると、効率が低すぎます。OOM の間で保存する必要があります。効率の
低い間に効果的な解決策を提供します。
今、一部をメモリに書き込んでから、ハードディスクに書き出すことができます
リングデータバッファ
このメモリ領域は、データがオーバーフローした場合のマップの停止時間を短縮するために再利用できます。
各マップはメモリ領域を排他的に使用できます。
メモリ内にリング データ バッファ (kvBuffer) を構築します。デフォルトのサイズは 100M で、しきい値は 100M です
。バッファが 80% に設定されている場合、バッファ内のデータが 80M に達すると、オーバーフローが開始され、ハードディスクに書き込まれます。
オーバーフロー書き込みの場合でも、使用できるスペースはまだ 20M あり、効率が低下することはなく、データはループでハードディスクに書き込まれるため、OOM の問題を心配する必要はありません。
パーティション
対応する Reduce
パーティションの数は Key に従って直接計算され、Reduce の数は等しい
hash(key) % Partition = num
デフォルトのパーティション アルゴリズムは Hash で、
残りのオブジェクトの hashCode() を取得します --- 等しい()
2 つのオブジェクトが等しい場合、2 つのオブジェクトのハッシュコードは等しくなければなり
ません 2 つのオブジェクトのハッシュコードが等しい場合、オブジェクトは必ずしも等しいとは限りません
並べ替え 並べ替え
上書きするデータを
Partation、Keyの順に並べ替え(QuickSort) --> 同じパーティションが集まっている、同じKeyが集まっている
今後上書きする小さなファイルも順番に並べる
流出
OOM の問題を気にすることなく、メモリ内のデータをループでハードディスクに書き込みます。
毎回 80M のファイルが生成されます。
このマップ内に大量のデータが生成されると、複数のファイルが上書きされる可能性があります。
マージ
オーバーフロー書き込みでは、順序付けられた (パーティション キーの) 小さなファイルが多数生成され、小さなファイルの数が不確実であるため、後で
削減するデータを転送する際に大きな問題が発生する
ため、小さなファイルは 1 つの大きなファイルにマージされます。将来的にプルされるデータは、大きなファイルから直接プルされるだけであり、
小さなファイルをマージする場合、それらもソートされ (マージとソート)、最終的に順序付けられた大きなファイルが生成されます。
コンバイナ コンバイナ
クラスターの帯域幅によって MapReduce ジョブの数が制限されるため、Map タスクと Reduce タスク間のデータ転送は可能な限り回避する必要があります。Hadoop を使用すると、ユーザーはマップの出力データを処理できます。ユーザーはコンバイナー関数 (マップ関数やリデュース関数など) をカスタマイズできます。そのロジックは通常、リデュース関数と同じです。コンバイナーの入力はマップの出力、コンバイナーの出力はリデュースの入力として使用されます。多くの場合、リデュース関数はコンバイナー関数として直接使用できます
(job.setCombinerClass(FlowCountReducer.class);)。
コンバイナーは最適化スキームであるため、コンバイナー関数が何回呼び出されるかを決定することはできません。コンバイナー関数は、リング バッファーがファイルをオーバーフローしたときに呼び出される場合もあれば、オーバーフローした小さなファイルがマージされたときに呼び出される場合もあります。大きなファイル。ただし、コンバイナー関数が何回呼び出されても、最終結果が影響を受けないことを確認する必要があるため、すべての処理ロジックがコンバイナー コンポーネントを使用できるわけではありません。一部のロジックでは、使用後に最終的な rerduce の出力が変更されます。コンバイナー関数 (複数の数値の平均値を見つけるなど)。コンバイナーを使用して各マップの出力結果の平均値を計算し、これらの平均値の平均値を計算することはできません。これにより、間違った結果が得られます。 ）。
コンバイナーの意味は、各マップタスクの出力をローカルで要約して、ネットワーク送信量を削減することです。最初のコンバイナーの組み合わせが {1,1,1,1,..} になった後、 reduce に最初に渡さ
れたデータは a1 a1 a1 a1 a1 です。2 番目のコンバイナーの組み合わせが {4,2 ,3,5 になった後、reduce に渡されたデータです。 ...}
プルフェッチ
Map の一時的な結果を Reduce ノードにプルする必要があります。
原則:
同じキーは同じ Reduce ノードにプルする必要があります
が、Reduce ノードには複数のキーを持つことができます。ソート
を解除する前にデータをプルする場合、マップの最終的なマージが行われます。ファイルの全順序トラバーサルを実行する
と、各 Reduce は全順序トラバーサルを実行する必要が
ある マップによって生成された大きなファイルが適切な場合、各 Reduce はファイルから必要なものを読み取るだけで済みます
マージ
Reduce がプルされると、データは複数のマップからプルされ、
各マップは小さなファイルを生成します。これらの小さなファイル (ファイル間で無秩序で、ファイル内で順序付けられている) は、計算の便宜のためです (N 個の小さなファイルを読み取る必要はありません) )、ファイルを結合して同じキー
を持つ 2 つのファイルに結合する必要があります。
マージ・リデュース
ファイル内のデータをメモリに読み込み、
同じキーをすべてメモリに一度に読み込み、
同じキーで結果を直接取得 --> 最終結果
書き込み出力
各reduceは独自の計算の最終結果をHDFSに保存します。