环境如下： 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条文本数据，每条数据大约4M，来看他们的压缩率对比， 然后在测的过程中，发现用java客户端去scan这50条数据时，regionserver频繁宕机看hbase的log发现并无明显异常，查看datanode的log发现如下异常：
Java代码
代码语言：javascript复制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查找结果，发现并没有明确的答案，大部分都是说链接超时，或者是句柄数满了，导致链接中断等等，然后就按这些答案，改了若干配置，发现依然没有生效，这领我感到十分奇怪 ，得出一个错误的结论，hbase不支持多种压缩类型并存的表，然后我去掉了其他类型用来压缩测试的表，再次测试，发现问题依旧，这再次令我十分诧异，会不会是环境的问题？因为我实在想不出来可能的问题所在了，然后就在本机虚拟机上进行测试， 虚拟机的环境，因为是自己用，所以JDK版本是1.8 和 Centos版本是7，Hbase，Hadoop，Zookeeper版本则保持一致， 搭建完毕后，继续测试，发现问题依旧，这下令人更迷惑了，看的出来非环境的问题了，不过这次有了点新的线索，由于用的是JDK8，在Hbase的log里面发现出现了大量的full gc日志，意思就是内存严重不足，导致垃圾收集时间出现了4,5秒，这下我才有点头绪，hbase是个吃内存的玩意，内存给的少，确实有可能导致regionserver挂掉，于是我查看hbase的堆内存分配情况，发现是默认的1G，这下确实跟这个有很大关系，50条数据占存储200M，如果每次scan一次，hbase会将其缓存在cache里面，第二次继续scan不同压缩类型的表，会导致内存膨胀，继而引发，regionserver宕机，而给出的异常提示，并不是非常明确，所以才定位问题比较困难，知道了大概原因所在，然后把hbase的堆内存调到4G，并分发到所有节点上，再次启动，用java 客户端，扫描全表测试，这次非常稳定，regionserver没有出现过再次挂掉的情况。
最后给出测试压缩的一个结论：总共测了4种压缩比较，原始数据200M （1）不用压缩 占空间 128.1 M （2）gz压缩 占920.3 K （3）snappy压缩 占 13.2M （4）lzo压缩 占8M 以上可以看出，gz的压缩比最高，lzo次之，snappy第三，当然不同的压缩适用于不用的业务场景，这里不能就简简单单的 总结必须用什么，这里面snappy和lzo在目前大多数互联网公司用的比较多，所以大家可以根据具体业务，来选择合适的压缩方案。
