4

質問から導き出せるように、入力ファイルを圧縮形式 (gzip など) にすることが理にかなっている場合と、入力ファイルを非圧縮形式にすることが理にかなっている場合を知りたいです。

圧縮ファイルのオーバーヘッドはどのくらいですか? ファイルを読むときはずっと遅いですか？大きな入力ファイルに対して行われたベンチマークはありますか?

どうも！

4

3 に答える 3

6

開発を行っていて、作業のために HDFS からローカル ファイル システムにデータを頻繁に読み取る必要がある場合を除き、入力ファイルを圧縮形式にすることはほとんどの場合理にかなっています。

圧縮形式には大きな利点があります。別の方法で設定しない限り、データはすでに Hadoop クラスターに複製されています。レプリケートされたデータは冗長性に優れていますが、より多くのスペースを消費します。すべてのデータが 3 倍で複製される場合、データの保存に必要な容量の 3 倍を消費することになります。

ログデータなどのテキストデータの圧縮は、圧縮率が高いため非常に効果的です。これは、Hadoop クラスターで通常よく見られる種類のデータでもあります。

ベンチマークはありませんが、適切なサイズのクラスターとデータに重大なペナルティは見られませんでした。

ただし、当面は gzip よりも LZO を選択してください。

参照: LZO 圧縮と gzip に対する重要性

Gzip は LZO よりも圧縮率が高くなります。LZO は、圧縮と解凍が高速です。Lzo ファイルを分割することは可能です。分割可能な Gzip は利用できませんが、同じ Jira タスクを見たことがあります。(bzip2 の場合も同様)

于 2012-06-27T15:24:56.650 に答える
2

圧縮する理由と圧縮しない理由を比較してみましょう。

為に：

a) データはほとんど保存され、頻繁に処理されることはありません。通常の DWH シナリオです。この場合、スペースの節約は、処理のオーバーヘッドよりもはるかに重要になる可能性があります
。b) 圧縮係数が非常に高く、そのため、多くの IO を節約できます。
c) 解凍は非常に高速 (Snappy のように) であり、そのためわずかなコストである程度の利益が得られます
d) データは既に圧縮されて到着しています

に対して：

a) 圧縮データは分割できません。多くの最新の形式は、ファイルの分割やその他の部分的な処理を可能にするために、ブロック レベルの圧縮で構築されていることに注意する必要があります。b) クラスター内にデータが作成され、圧縮にかなりの時間がかかります。通常、圧縮は解凍よりもはるかに CPU を集中的に使用することに注意してください。
c) データには冗長性がほとんどなく、圧縮による利点はほとんどありません。

于 2012-06-27T18:13:24.970 に答える
1

1) 入力ファイルの圧縮 入力ファイルが圧縮されている場合、HDFS から読み取られるバイト数が減ります。つまり、データを読み取る時間が短くなります。この時間の節約は、ジョブ実行のパフォーマンスにとって有益です。

入力ファイルが圧縮されている場合は、ファイル拡張子を使用して使用するコーデックを決定し、MapReduce によって読み取られるときに自動的に解凍されます。たとえば、.gz で終わるファイルは gzip 圧縮ファイルとして識別されるため、GzipCodec で読み取ることができます。

2) 出力ファイルの圧縮 多くの場合、出力を履歴ファイルとして保存する必要があります。1 日あたりの出力量が膨大で、将来の使用のために履歴結果を保存する必要がある場合、これらの蓄積された結果は大量の HDFS スペースを必要とします。ただし、これらの履歴ファイルはあまり頻繁に使用されない可能性があり、その結果、HDFS スペースが浪費されます。したがって、HDFS に保存する前に出力を圧縮する必要があります。

3) マップ出力の圧縮 MapReduce アプリケーションが圧縮されていないデータを読み書きする場合でも、マップ フェーズの中間出力を圧縮することでメリットが得られる場合があります。マップ出力はディスクに書き込まれ、ネットワークを介してレデューサー ノードに転送されるため、LZO や Snappy などの高速コンプレッサーを使用すると、転送するデータの量が減るため、パフォーマンスが向上します。2. 共通入力フォーマット

gzip: gzip は Hadoop で当然サポートされています。gzip は、LZ77 とハフマン コーディングを組み合わせた DEFLATE アルゴリズムに基づいています。

bzip2: bzip2 は、無料で入手でき、特許フリー (下記参照) の高品質データ圧縮プログラムです。通常、利用可能な最良の技術 (PPM ファミリの統計圧縮) の 10% から 15% 以内にファイルを圧縮しますが、圧縮時は約 2 倍、解凍時は 6 倍高速です。

LZO: LZO 圧縮形式は、圧縮されたデータの多数の小さい (~256K) ブロックで構成されているため、ブロック境界に沿ってジョブを分割できます。さらに、速度を考慮して設計されています。gzip の約 2 倍の速さで解凍できます。つまり、ハード ドライブの読み取り速度についていくのに十分な速さです。gzip ほどには圧縮されません — gzip で圧縮されたバージョンよりも 50% 程度大きいファイルが予想されます。しかし、これは圧縮をまったく行わない場合でも、ファイルのサイズの 20 ～ 50% です。つまり、IO バウンド ジョブはマップ フェーズを約 4 倍速く完了します。

Snappy: Snappy は圧縮/解凍ライブラリです。最大の圧縮、または他の圧縮ライブラリとの互換性を目的としていません。代わりに、非常に高速で適度な圧縮を目指しています。たとえば、zlib の最速モードと比較すると、Snappy はほとんどの入力で 1 桁高速ですが、結果の圧縮ファイルは 20% から 100% 大きくなります。64 ビット モードの Core i7 プロセッサのシングル コアでは、Snappy は約 250 MB/秒以上で圧縮し、約 500 MB/秒以上で解凍します。Snappy は、BigTable や MapReduce から社内の RPC システムに至るまで、Google 内で広く使用されています。

いくつかのトレードオフ: すべての圧縮アルゴリズムは、スペースと時間のトレードオフを示します。通常、圧縮と圧縮解除の速度が速いほど、スペースの節約が少なくなります。上記の表にリストされているツールは通常、9 つの異なるオプションを提供することで、圧縮時のこのトレードオフをある程度制御します。–1 は速度の最適化を意味し、-9 はスペースの最適化を意味します。

ツールが異なれば、圧縮特性も大きく異なります。Gzip は汎用のコンプレッサーであり、スペースと時間のトレードオフの中間に位置します。Bzip2 は gzip よりも効果的に圧縮しますが、速度は遅くなります。Bzip2 の解凍速度は圧縮速度よりも高速ですが、それでも他の形式よりは遅くなります。一方、LZO と Snappy はどちらも速度を最適化し、gzip よりも約 1 桁高速ですが、圧縮効果は低くなります。Snappy は、解凍に関しても LZO よりも大幅に高速です。3. 圧縮と入力分割に関する問題 MapReduce で処理されるデータを圧縮する方法を検討する場合、圧縮形式が分割をサポートしているかどうかを理解することが重要です。サイズが 1 GB の圧縮されていないファイルが HDFS に格納されているとします。HDFS ブロック サイズが 64 MB の場合、

ファイルが、圧縮サイズが 1 GB の gzip 圧縮ファイルであるとします。以前と同様に、HDFS はファイルを 16 ブロックとして保存します。ただし、ブロックごとに分割を作成しても機能しません。gzip ストリームの任意のポイントで読み取りを開始することは不可能であり、マップ タスクが他の分割とは無関係にその分割を読み取ることは不可能だからです。gzip 形式は、DEFLATE を使用して圧縮データを格納し、DEFLATE はデータを一連の圧縮ブロックとして格納します。問題は、各ブロックの開始が、ストリーム内の任意のポイントに位置するリーダーが次のブロックの開始に進むことを可能にする方法で区別されないことです。これにより、それ自体をストリームと同期させます。このため、gzip は分割をサポートしていません。

この場合、MapReduce は正しいことを行い、gzip 圧縮されたファイルを分割しようとはしません。これは、入力が (ファイル名拡張子を調べることで) gzip 圧縮されており、gzip が分割をサポートしていないことがわかっているためです。これは機能しますが、ローカル性が犠牲になります。1 つのマップが 16 の HDFS ブロックを処理し、そのほとんどはマップに対してローカルではありません。また、マップが少ないと、ジョブの粒度が低くなるため、実行に時間がかかる場合があります。

架空の例のファイルが LZO ファイルである場合、基本的な圧縮形式ではリーダーがストリームと同期する方法が提供されないため、同じ問題が発生します。ただし、Hadoop LZO ライブラリに付属のインデクサー ツールを使用して LZO ファイルを前処理することは可能です。このツールは分割ポイントのインデックスを作成し、適切な MapReduce 入力形式が使用されている場合に効果的に分割可能にします。

一方、bzip2 ファイルは、ブロック間の同期マーカー (pi の 48 ビット近似) を提供するため、分割をサポートします。4. IO バウンドおよび CPU バウンド HDFS に圧縮データを格納すると、ハードウェアの割り当てをさらに進めることができます。これは、圧縮データが元のデータのサイズの 25% になることが多いためです。さらに、MapReduce ジョブはほぼ常に IO バウンドであるため、圧縮されたデータを保存すると、実行する全体的な IO が少なくなり、ジョブがより高速に実行されます。ただし、これには 2 つの注意点があります。一部の圧縮形式は並列処理用に分割できず、解凍時にジョブが CPU バウンドになり、IO の利点が失われるほど遅いものもあります。

gzip 圧縮形式は、最初の警告を示しています。1.1 GB の gzip ファイルがあり、クラスターのブロック サイズが 128 MB であるとします。このファイルは、約 128 MB のサイズの 9 つのチャンクに分割されます。これらを MapReduce ジョブで並行して処理するために、異なるマッパーが各チャンクを担当します。ただし、これは、2 番目のマッパーがファイル内の約 128MB の任意のバイトから開始されることを意味します。gzip が入力を解凍するために使用するコンテキスト辞書は、この時点で空になります。これは、gzip 解凍プログラムがバイトを正しく解釈できないことを意味します。結果として、Hadoop の大きな gzip ファイルは単一のマッパーで処理する必要があり、並列処理の目的が無効になります。

Bzip2 圧縮形式は、ジョブが CPU バウンドになる 2 番目の警告を示しています。Bzip2 ファイルは圧縮率が高く、分割も可能ですが、解凍アルゴリズムは遅く、Hadoop ジョブで一般的なストリーミング ディスク読み取りに対応できません。Bzip2 圧縮には、ストレージ スペースを節約できる利点がありますが、実行中のジョブは、CPU でデータの解凍が完了するまでの待機に時間を費やしているため、速度が低下し、他の利点が相殺されます。5. 要約 圧縮する理由: a) データはほとんど格納されており、頻繁に処理されるわけではありません。通常の DWH シナリオです。この場合、スペースの節約は、処理のオーバーヘッドよりもはるかに重要になる可能性があります。b) 圧縮率が非常に高く、そのため、多くの IO を節約できます。

圧縮しない理由 a) 圧縮されたデータは分割できません。多くの最新の形式は、ファイルの分割やその他の部分的な処理を可能にするために、ブロック レベルの圧縮で構築されていることに注意する必要があります。b) クラスター内にデータが作成され、圧縮にかなりの時間がかかります。圧縮は通常、解凍よりもはるかに CPU を集中的に使用することに注意してください。c) データには冗長性がほとんどなく、圧縮による利点はほとんどありません。

于 2015-09-03T17:14:46.883 に答える