4

私の仕事は、静止画像/動画ファイル用の分散システムを設計することです。データのサイズは約数十テラバイトです。これは主に HTTP アクセス用です (したがって、データの処理はありません。または、サイズ変更などの単純な処理のみです。ただし、アプリケーションで直接実行できるため、重要ではありません)。

もう少し明確にするために、それは次のシステムです。

  1. データの合計サイズが非常に大きいため、分散 (水平スケール) する必要があります。
  2. 主にHTTP経由で小さな静的ファイル (画像、サムネイル、短い動画など) を提供します。
  3. 通常、データの処理に関する要件はありません (したがって、MapReduce は必要ありません)。
  4. データへの HTTP アクセスの設定は簡単に行うことができます。
  5. (持つべき) 良好なスループット。

私は考えています：

  1. ネイティブ ネットワーク ファイル システム: しかし、データが 1 台のマシンに収まらないため、実現可能ではないようです。

  2. Hadoop ファイルシステム。以前は Hadoop mapreduce を使用していましたが、Hadoop を HTTP 要求の静的ファイル リポジトリとして使用した経験はありません。したがって、それが可能かどうか、または推奨される方法かどうかはわかりません。

  3. MogileFS. 有望に思えますが、MySQL を使用して (1 台のマシンで) ローカル ファイルを管理すると、オーバーヘッドが大きくなりすぎると思います。

何か提案はありますか？

4

4 に答える 4

8

Weed-FS の作者です。あなたの要件には、WeedFS が理想的です。Hadoop は多くの小さなファイルを処理できません。理由に加えて、各ファイルにはマスターにエントリが必要です。ファイル数が多い場合、hdfs マスター ノードはスケーリングできません。

Weed-FS は、最新の Golang リリースでコンパイルすると高速になります。

最近、Weed-FS に対して多くの新しい改善が行われました。組み込みのアップロード ツールを使用して、非常に簡単にテストおよび比較できるようになりました。これは、すべてのファイルをディレクトリの下に再帰的にアップロードします。

weed upload -dir=/some/directory

これで、"du -k /some/directory" で比較してディスク使用量を確認でき、"ls -l /your/weed/volume/directory" で Weed-FS のディスク使用量を確認できます。

そして、データセンター、ラック対応などでのレプリケーションが必要になると思います。それらは今あります!

于 2013-07-17T07:57:09.493 に答える
3

Hadoop は大きなファイル用に最適化されています。たとえば、デフォルトのブロック サイズは 64M です。多くの小さなファイルは無駄が多く、Hadoop では管理が困難です。

GlusterFSなどの他の分散ファイル システムを調べることができます。

于 2013-06-02T07:15:39.000 に答える
2

Hadoop には、ファイルにアクセスするための REST API があります。ドキュメントのこのエントリを参照してください。Hadoop は、多数の小さなファイルを保存するためのものではないと感じています。

  • HDFS は、小さなファイルへの効率的なアクセスには対応していません。主に、大きなファイルへのストリーミング アクセス用に設計されています。通常、小さいファイルを読み取ると、各小さいファイルを取得するために多数のシークとデータ ノードからデータ ノードへの多数のホッピングが発生します。これらはすべて、非効率的なデータ アクセス パターンです。
  • HDFS のすべてのファイル、ディレクトリ、およびブロックは、namenode のメモリ内のオブジェクトとして表され、それぞれが 150 バイトを占有します。ブロックサイズは64MBです。したがって、ファイルが 10kb であっても、64mb のブロック全体が割り当てられます。それは無駄なディスク容量です。
  • ファイルが非常に小さく、それらが多数ある場合、各マップ タスクはほとんど入力を処理せず、より多くのマップ タスクが存在し、それぞれが余分な簿記のオーバーヘッドを課します。64MB ブロックの 16 個のファイルに分割された 1GB のファイルと、10,000 個ほどの 100KB のファイルを比較してください。10,000 個のファイルはそれぞれ 1 つのマップを使用し、ジョブ時間は、単一の入力ファイルを使用した同等のジョブよりも数十倍または数百倍遅くなる可能性があります。

「Hadoop Summit 2011」で、 Karthik Ranganathan による Facebook Messaging についての講演があり、彼は次のビットを公開しました。Facebook は HDFS を介してデータ (プロファイル、メッセージなど) を保存しますが、画像とビデオには同じインフラストラクチャを使用しません。彼らは、画像用にHaystackという名前の独自のシステムを持っています。オープンソースではありませんが、抽象的な設計レベルの詳細を共有しました。

weed-fsは、Haystacks の設計に触発されたオープン ソース プロジェクトです。ファイルを保存するために作られたそのテーラー。私は今までそれを使用していませんが、一見の価値があるようです。

于 2013-06-02T06:03:23.940 に答える
0

ファイルをバッチ処理でき、HDFS に追加した後にバッチを更新する必要がない場合は、複数の小さなファイルを 1 つの大きなバイナリ シーケンス ファイルにコンパイルできます。これは、小さなファイルを HDFS に格納するためのより効率的な方法です (Arnon が上で指摘したように、HDFS は大きなファイル用に設計されており、小さなファイルを扱う場合は非常に非効率になります)。

これは、私が Hadoop を使用して CT 画像を処理する際に取ったアプローチです (詳細は、Hadoop での画像処理 を参照)。ここでは、CT スキャンの 225 スライス (それぞれが個別の画像) が、処理のために Hadoop に長いストリーミング読み取りを行うために、1 つのはるかに大きなバイナリ シーケンス ファイルにコンパイルされています。

お役に立てれば！

G

于 2013-06-13T21:31:07.133 に答える