3

テキストの次の段落から-(http://developer.yahoo.com/hadoop/tutorial/module2.html)、シーケンシャルで読み取り可能な大きなファイルはローカルキャッシングには適していないことに言及しています。しかし、ここでローカルが何を意味するのかわかりません...

私の意見では、2つの仮定があります。1つはクライアントがHDFSからデータをキャッシュし、もう1つはデータノードがローカルファイルシステムまたはクライアントがすばやくアクセスできるようにメモリにhdfsデータをキャッシュすることです。もっと説明できる人はいますか?どうもありがとう。


ただし、HDFSは非常にスケーラブルですが、その高性能設計により、特定のクラスのアプリケーションに制限されます。NFSほど汎用的ではありません。HDFSで行われた追加の決定とトレードオフは多数あります。特に:

HDFSを使用するアプリケーションは、ファイルからの長いシーケンシャルストリーミング読み取りを実行すると想定されています。HDFSは、ストリーミング読み取りパフォーマンスを提供するように最適化されています。これには、ファイル内の任意の位置へのランダムなシーク時間が犠牲になります。

データはHDFSに1回書き込まれ、その後数回読み取られます。すでに閉じられた後のファイルの更新はサポートされていません。(Hadoopの拡張機能は、ファイルの末尾に新しいデータを追加するためのサポートを提供します。Hadoop0.19に含まれる予定ですが、まだ利用できません。)

ファイルのサイズが大きく、読み取りがシーケンシャルであるため、システムはデータのローカルキャッシュのメカニズムを提供しません。キャッシュのオーバーヘッドは十分に大きいため、HDFSソースからデータを再読み取りするだけで済みます。

個々のマシンは、永続的および断続的に頻繁に故障すると想定されています。クラスタは、複数のマシンの完全な障害に耐えることができなければなりません。おそらく、同時に多くのマシンが発生します(たとえば、ラックがすべて一緒に障害を起こした場合)。失われたマシンの数に比例してパフォーマンスが低下する可能性がありますが、システム全体が過度に遅くなったり、情報が失われたりしないようにする必要があります。データ複製
戦略はこの問題に対処します。


4

1 に答える 1

4

実際のMapreduceジョブは、おそらくHDFSからのGB(10/100/1000)のデータを処理します。

したがって、1つのマッパーインスタンスは、かなりの量のデータ(構成に応じて通常のブロックサイズは64/128/256 MB)を順次処理する可能性があります(ファイル/ブロック全体を最初から読み取ります)。最後まで。

また、同じマシンで実行されている別のマッパーインスタンスが、近い将来いつでもそのデータブロックを再度処理する可能性は低く、複数のマッパーインスタンスが1つのTaskTrackerでこのマッパーと一緒にデータを処理することもあります(できればデータの実際の物理的な場所に対して「ローカル」であるのはごくわずかです。つまり、マッパーインスタンスが実行されているのと同じマシン上にデータブロックのレプリカも存在します)。

このすべてを念頭に置いて、HDFSから読み取ったデータをキャッシュしても、おそらくそれほど多くは得られません。別のブロックが照会され、最終的にキャッシュ内でデータが置き換えられる前に、そのデータにキャッシュヒットが発生することはほとんどありません。

于 2012-04-11T10:28:19.453 に答える