環(huán)境如下：
Centos6.5
Apache Hadoop2.7.1
Apache Hbase0.98.12
Apache Zookeeper3.4.6
JDK1.7
Ant1.9.5
Maven3.0.5

最近在測Hbase的壓縮，Hadoop安裝了lzo和snappy，插入50條文本數(shù)據(jù)，每條數(shù)據(jù)大約4M，來看他們的壓縮率對比，
然后在測的過程中，發(fā)現(xiàn)用java客戶端去scan這50條數(shù)據(jù)時，regionserver頻繁宕機看hbase的log發(fā)現(xiàn)并無明顯異常，查看datanode的log發(fā)現(xiàn)如下異常：

專注于為中小企業(yè)提供網(wǎng)站建設(shè)、成都網(wǎng)站制作服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)翼城免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了超過千家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

Java代碼  

1. java.io.IOException: Premature EOF from inputStream   

2.         at org.apache.hadoop.io.IOUtils.readFully(IOUtils.java:201)   

3.         at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.doReadFully(PacketReceiver.java:213)   

4.         at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.doRead(PacketReceiver.java:134)   

5.         at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.receiveNextPacket(PacketReceiver.java:109)   

6.         at org.apache.hadoop.hdfs.server.datanode.BlockReceiver.receivePacket(BlockReceiver.java:472)   

7.         at org.apache.hadoop.hdfs.server.datanode.BlockReceiver.receiveBlock(BlockReceiver.java:849)   

8.         at org.apache.hadoop.hdfs.server.datanode.DataXceiver.writeBlock(DataXceiver.java:804)   

9.         at org.apache.hadoop.hdfs.protocol.datatransfer.Receiver.opWriteBlock(Receiver.java:137)   

10.         at org.apache.hadoop.hdfs.protocol.datatransfer.Receiver.processOp(Receiver.java:74)   

11.         at org.apache.hadoop.hdfs.server.datanode.DataXceiver.run(DataXceiver.java:251)   

12.         at java.lang.Thread.run(Thread.java:745)  

java.io.IOException: Premature EOF from inputStream
        at org.apache.hadoop.io.IOUtils.readFully(IOUtils.java:201)
        at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.doReadFully(PacketReceiver.java:213)
        at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.doRead(PacketReceiver.java:134)
        at org.apache.hadoop.hdfs.protocol.datatransfer.PacketReceiver.receiveNextPacket(PacketReceiver.java:109)
        at org.apache.hadoop.hdfs.server.datanode.BlockReceiver.receivePacket(BlockReceiver.java:472)
        at org.apache.hadoop.hdfs.server.datanode.BlockReceiver.receiveBlock(BlockReceiver.java:849)
        at org.apache.hadoop.hdfs.server.datanode.DataXceiver.writeBlock(DataXceiver.java:804)
        at org.apache.hadoop.hdfs.protocol.datatransfer.Receiver.opWriteBlock(Receiver.java:137)
        at org.apache.hadoop.hdfs.protocol.datatransfer.Receiver.processOp(Receiver.java:74)
        at org.apache.hadoop.hdfs.server.datanode.DataXceiver.run(DataXceiver.java:251)
        at java.lang.Thread.run(Thread.java:745)

截圖如下，好吧，出異常了，就拿這個異常google查找結(jié)果，發(fā)現(xiàn)并沒有明確的答案，大部分都是說鏈接超時，或者是句柄數(shù)滿了，導(dǎo)致鏈接中斷等等，然后就按這些答案，改了若干配置，發(fā)現(xiàn)依然沒有生效，這領(lǐng)我感到十分奇怪 ，得出一個錯誤的結(jié)論，hbase不支持多種壓縮類型并存的表，然后我去掉了其他類型用來壓縮測試的表，再次測試，發(fā)現(xiàn)問題依舊，這再次令我十分詫異，會不會是環(huán)境的問題？因為我實在想不出來可能的問題所在了，然后就在本機虛擬機上進行測試，
虛擬機的環(huán)境，因為是自己用，所以JDK版本是1.8 和 Centos版本是7，Hbase，Hadoop，Zookeeper版本則保持一致，
搭建完畢后，繼續(xù)測試，發(fā)現(xiàn)問題依舊，這下令人更迷惑了，看的出來非環(huán)境的問題了，不過這次有了點新的線索，由于用的是JDK8，在Hbase的log里面發(fā)現(xiàn)出現(xiàn)了大量的full gc日志，意思就是內(nèi)存嚴重不足，導(dǎo)致垃圾收集時間出現(xiàn)了4,5秒，這下我才有點頭緒，hbase是個吃內(nèi)存的玩意，內(nèi)存給的少，確實有可能導(dǎo)致regionserver掛掉，于是我查看hbase的堆內(nèi)存分配情況，發(fā)現(xiàn)是默認的1G，這下確實跟這個有很大關(guān)系，50條數(shù)據(jù)占存儲200M，如果每次scan一次，hbase會將其緩存在cache里面，第二次繼續(xù)scan不同壓縮類型的表，會導(dǎo)致內(nèi)存膨脹，繼而引發(fā)，regionserver宕機，而給出的異常提示，并不是非常明確，所以才定位問題比較困難，知道了大概原因所在，然后把hbase的堆內(nèi)存調(diào)到4G，并分發(fā)到所有節(jié)點上，再次啟動，用java 客戶端，掃描全表測試，這次非常穩(wěn)定，regionserver沒有出現(xiàn)過再次掛掉的情況。









最后給出測試壓縮的一個結(jié)論：總共測了4種壓縮比較，原始數(shù)據(jù)200M
（1）不用壓縮   占空間 128.1 M 
（2）gz壓縮       占920.3 K
（3）snappy壓縮 占 13.2M
（4）lzo壓縮       占8M

以上可以看出，gz的壓縮比最高，lzo次之，snappy第三，當(dāng)然不同的壓縮適用于不用的業(yè)務(wù)場景，這里不能就簡簡單單的
總結(jié)必須用什么，這里面snappy和lzo在目前大多數(shù)互聯(lián)網(wǎng)公司用的比較多，所以大家可以根據(jù)具體業(yè)務(wù)，來選擇合適的壓縮方案。