Hbase经验总结

        不知不觉，搞hbase也有一段时间了，期间有痛苦，也有欢乐，不管过程有多么艰难与漫长，但结果还是可喜的。现总结一下hbase在使用过程中的一些经验和看法：

1.源码

在学习的过程中，要敢于碰 源码。虽然不一定所有的源码都要看，但是也要针对自己要解决的问题，查找源代码，其实大牛们写的代码是比较费劲，但是只要静下心来看，还是有很大收获的。另外，不要全部相信源码，有时候源码中会有很多bug，看的时候多试试，如果出现问题，及时修改。

2.英文资料

hbase的中文资料比较少，一般都是介绍和安装部署等等，一旦出现问题，不下功夫是很难处理的，国外的一些网站就要经常光顾了。

3.推荐指南

有时间多看看《HBase The Definitive Guide.pdf》还是很有帮助的。

4.虚心

向大牛请教。曾经碰到过性能问题，请教了支付宝的代志远大牛，有了一些思路。也得到了其他同行的帮助。

下面要将在于hbase为伍的过程中碰到的问题及解决的方法做个总结：

1.关于导入

大家一般都会试着将记录转换成hfile格式的文件，然后再导入hbase中。其中就可能会碰到问题，比如

Added a key not lexically larger than previous  

笔者就曾经碰到过这个问题，后来经过查看src\org\apache\hadoop\hbase\mapreduce\ImportTsv.java代码，进行了一些改进，问题得到解决，性能也提高了将近10倍。（插入性能有10000行/s提高到110000行/s）

2.关于删除

hbase的删除表操作是很快，但删除表中的某些记录数，就比较慢了，尤其是如果一次性删除多个表中的记录，hbase没有提供很好的这方面的工具，将会非常抓狂。为此，笔者专门写了一个删除hbase的工具，可以说是非常的高效，大约100G的数据在几分钟内可以删除，关于这部分的内容，请见我的博客http://blog.youkuaiyun.com/chinalgf/article/details/8472163。

3.hbase表的rowkey规则设计

这个问题其实是个重头戏，因为关系到以后的业务、性能及可能进行的二级索引问题。所以笔者推荐还是慎重一些为好。hbase的索引是建立在rowkey上的，索引设计的好，可以在查询的业务上将响应时间降到最少。笔者所处公司的业务就很独特，设计后的规则也是牺牲了一些硬盘的空间，但是在几十亿行的数据表中完全可以在毫秒级内处理完成，当然还需要进行一系列的优化工作。

4.hbase二级索引

hbase据说一开始提供了二级索引方案，但是后来取消了，后来出了个Coprocessor，可以做一些二级索引的事情，关于二级索引的详细介绍，请参见淘宝的博客文章http://rdc.taobao.com/team/jm/archives/951。

我想说的是，不一定所有的业务都需要hbase的二级索引来做，二级索引带来的负面印象及维护成本的增加可能也是必须要考虑的问题。能避免就不要用了吧，毕竟这方面的技术还不稳定，也不是hbase的强项。在经费充足的情况下，以牺牲一定的空间换时间还是值得考虑的。

5.hbase的filter

不要轻易的相信hbase的filter，除非你已经把它们都熟练掌握了，否则不要随意的使用。提高性能的方法中，Scan.setStartRow()和Scan.setStopRow()是个很好的优化器，尽量想办法从scan的方法中设置，对于filter的源码，性能还是有问题的。

6.hbase不是万能的

根据我的实际经验，hbase的查询速度确实可以在毫秒内 完成，但是啊但是，注意了，这个效率是有一定的业务前提的：即如果查询返回的值非常之大，比如几十上百万行的记录，那么要想达到毫秒也可能是很困难的。这时候我们就要考虑算法的优化问题了，当然了，只能解决一部分的速率问题，要想长久得解决，还需要从其他方面着手，比如前面提到的rowkey的设计、附属统计表、离线统计等等。

7.关于hbase中使用sql语句来查询，你也可以实现

关于这部分的内容，请见我的另一篇文章http://blog.youkuaiyun.com/chinalgf/article/details/8478034。

未完待续...