回顾2013:HBase的提升与挑战

　　5. HBase的企业级数据库特性（Secondary Index、Join和Transaction）

　　谈到HBase的企业级数据库特性，首先想到的就是Secondary Index、Join、Transaction。不过目前这些功能的实现都是通过外围项目的形式提供的。

　　华为的hindex是目前看到的最好的Secondary Index的实现方式。主要思想是建立Index Table，而且这个Index Table的Region分布跟主表是一致的，也就是说主表中某一Region对应的Index Table对应的Region是在同一个RS上的。而且这个索引表是禁止自动或者手动出发split的，只有主表发生了split才会触发索引表的split。

　　这个是怎么做到的呢？本质上Index Table也是一个HBase的表，那么也只有一个RowKey是可以索引的。这个索引表的RowKey设计就比较重要了，索引表的RowKey=主表 Region开始的RowKey+索引名（因为一个主表可能有多个索引，都放在同一个索引表中）+需要索引的列值+主表RowKey。这样的索引表的 RowKey设计就可以保证索引表和主表对应的Region是在同一台RS上，可以省查询过程中的RPC。每次Insert数据的时候，通过 Coprocessor顺便插入到索引表中。每次按照二级索引列Scan数据的时候，先通过Coprocessor从索引表中获取对应的主表的 RowKey然后就行Scan。在性能上看，查询的性能获得了极大提升，插入性能下降了10%左右。

　　Phoenix也通过另外建一张表的方式实现二级索引

　　Phoenix也实现了一大一小两个表的Join操作。还是老办法把小表broadcast到所有的RS，然后通过coprocessor来做hash join，最后汇总。感觉有点画蛇添足，毕竟HBase设计的初衷就是用大表数据冗余来尽量避免Join操作的。现在又来支持Join，不知道Salesfore的什么业务需求这个场景。 

　　关于Transaction的支持，目前最受关注的还就是Yahoo!的Omid。不过貌似大家对这个特性的热情还不是特别高。

　　6. PrefixTreeCompression

　　由于HBase的KeyValue存储是按照Row/Family/Qualifier/TimeStamp/Value的形式存储的，Row /Family/Qualifier这些相当于前缀，如果每一行都按照原始数据进行存储会导致占据存储空间比较大。HBase 0.94版本就已经引入了DataBlock Encode的概念（HBASE-4218），将重复的Row/Family/Qualifier按照顺序进行压缩存储，提高内存利用率，支持四种压缩方 式FAST_DIFF\PREFIX\PREFIX_TRIE\DIFF。但是这个特性也仅仅是通过delta encoding/compression降低了内存占用率，对数据查询效率没有提升，甚至会带来压缩/解压缩对CPU资源占用的情况。

　　HBASE-4676：PrefixTreeCompression是把重复的Row/Family/Qualifier按照Prefix Tree的形式进行压缩存储的，可以在解析时生成前缀树，并且树节点的儿子是排序的，所以从DataBlock中查询数据的效率可以超过二分查找。（PREFIX_TREE压缩的初步探究及测试）

　　7. 其他变化

• HBASE-5305：为了更好的跨版本的兼容性，引进了Protocol Buffer作为序列化/反序列化引擎使用到RPC中（此前Hadoop的RPC也全部用PB重写了）。因为随着HBase Server的不断升级，有些Client的版本可能还比较旧，所以需要RPC在新旧版本之间兼容。
• HBASE-6055 HBASE-7290：HBase Table Snapshot。创建snaphost对HBase集群没有性能影响，只是生成了snaphost对应的metadata而不会去拷贝数据。用户可以通 过创建snaphost实现backup和disaster recovery，例如用户在创建一个snaphost之后可能会误操作导致一些表出现了问题，这样我们可以选择回滚到创建snaphost的那个阶段而 不会导致数据全都不可用。也可以定期创建snapshot然后拷贝到其他集群用于定时的离线处理。
• HBASE-8015： 在0.96中，ROOT表已经改名为hbase:namespace，META则是hbase:meta。而且hbase:namespace是存在 Zookeeper上的。这个namespace类似于RDBMS里的database的概念，可以更好的做权限管理和安全控制。HBase中table 的META信息也是作为一种Region存放在Region Server上的，那么META表的Region和其他普通Region就会产生明显的资源竞争。为了改善META Region的性能，360的HBase中提出了专属MetaServer，在这个Region Server上只存放META Region
• HBASE-5229：同一个Region内的跨行事务。一次操作中涉及到同一个Region中的所有写操作在获取到的相关Row的所有行锁（按照RowKey的顺序依次取行锁，防止死锁）之后事务执行。
• HBASE-4811：Reverse Scan。过去被问到说如何反向查找HBase中的数据，常常被答道再建一张反向存储的表，而且LevelDB和Cassandra都支持反向扫描。HBase反向扫描比正向扫描性能下降30%，这个和LevelDB是差不多的。
• Hoya — HBase on YARN。可以在一个YARN集群上部署多个不同版本、不同配置的HBase实例，可以参考GitHub。

　　展望2014年，HBase即将release 1.0版本，更好的支持multi-tenancy, 支持Cell级别的ACL控制。 

　　8. 总结

• Cloudera/Hortonworks/Yahoo!/Facebook的人从系统和性能等多方面关注
• Salesfore/huawei的人貌似更关注企业级特性，毕竟他们面对的客户都是电信、金融、证券等高帅富行业
• 来自国内的阿里巴巴/小米/360等公司更加关注系统性能、稳定性和运维相关的话题。国内互联网行业用HBase更加关注的是如何解决业务问题。
• 越来越多的公司把它们的HBase集群构建在云上，例如Pinterest所有的HBase集群都是在AWS上，国外的start up环境太好了，有了AWS自己根本不用花费太多的资源在基础设施上。
• 传统的HBase应用是在线存储，实时数据读取服务。例如支付宝用HBase存放用户的历史交易信息服务用户查询，中国联通也使用 HBase存储用户的上网历史记录信息用于用户的实时查询需求。现在HBase也向实时数据挖掘的应用场景中发展，例如wibidata公司开源的kiji能够在HBase上轻松构建实时推荐引擎、实时用户分层和实时欺诈监控。