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

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

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

怎么樣把兩個(gè)壓縮文件壓到一起？

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

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

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

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

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

常用壓縮算法：

壓縮算法的工作原理？

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