hbase壓縮lzo和snappy的區(qū)別？LZO是一個壓縮文件。Linux下的壓縮一般是流壓縮，即只能壓縮一個文件。無法查看此類文件的內(nèi)容，因此只能直接對其進行解壓縮。雙擊圖形界面。怎么樣把兩個壓縮文

hbase壓縮lzo和snappy的區(qū)別？

LZO是一個壓縮文件。Linux下的壓縮一般是流壓縮，即只能壓縮一個文件。無法查看此類文件的內(nèi)容，因此只能直接對其進行解壓縮。雙擊圖形界面。

怎么樣把兩個壓縮文件壓到一起？

在設(shè)計軟件時要考慮很多問題。

1. 算法的局限性。如常用的LZ77、gzip和snappy等，在匹配同一字符串時受歷史緩沖區(qū)大小和最大匹配長度的限制。以你提到的例子為例。當(dāng)你遇到第二個100米的時候，你需要找到100米的位置來找到匹配，但是匹配100米需要一個成本（包括消耗100米內(nèi)存和匹配100米長度所需的時間）。這將使壓縮過程非常緩慢！二是最大匹配長度問題。同樣，你也不能在有限的時間內(nèi)要求更長的匹配時間。有一個門檻。一般情況下，匹配窗口的大小通常為幾KB到幾MB（snappy為64KB），最大匹配長度較小?；谠~典的系統(tǒng)如LZ78和LZW也存在詞典大小和最大匹配長度的問題，這些問題不會重復(fù)。

2. 壓縮率和壓縮速度之間的折衷。總之，壓縮比越大，壓縮速度越快，反之亦然。這主要取決于平衡。即使我們一味追求壓縮率，使用一種算法100米的壓縮代價仍然很高。最好使用多層壓縮。例如，gzip使用了Huffman和LZ77的組合。當(dāng)然，也可以使用文件對文件的重復(fù)檢查算法（從云端一秒鐘上傳電影的各種例子），但這種方法只適用于云備份，不適合多文件（太小，不實用，浪費資源）的壓縮和打包。

3. 多文件壓縮傾向于單獨壓縮每個文件，這主要取決于性能。例如，您有16個文件要壓縮。如果一開始單獨壓縮，可以調(diào)動16個線程一起壓縮，時間會縮短16倍。然后花一點時間將壓縮文件粘在一起并添加元數(shù)據(jù)。如果壓縮在一起，因為壓縮算法很難并行，基本上是線程工作（很多多線程也會先把文件切成多個副本，原理同上），速度會慢很多。減壓也是一樣的。單獨壓縮的文件可以由多個線程同時解壓。另外，在解壓縮時，如果我只需要其中一個文件，這種壓縮方法有更多的優(yōu)點。我只需要讀取元數(shù)據(jù)并解壓縮我需要的部分文件，而不是解壓縮所有文件。

如何在Hive中進行數(shù)據(jù)壓縮以實現(xiàn)高效存儲？

常用壓縮算法：

壓縮算法的工作原理？

壓縮算法是一種非常簡單的無損壓縮算法。它使用重復(fù)字節(jié)的簡單描述和替換重復(fù)字節(jié)的次數(shù)。雖然對于普通壓縮來說簡單且效率低下，但它有時非常有用。