Datastream一直以来在使用HBase分流日志，每天的数据量很大，日均大概在80亿条，10TB的数据。对于像Datastream这种数据量巨大、对写入要求非常高，并且没有复杂查询需求的日志系统来说，选用HBase作为其数据存储平台，无疑是一个非常不错的选择。
HBase是一个相对较复杂的分布式系统，并发写入的性能非常高。然而，分布式系统从结构上来讲，也相对较复杂，模块繁多，各个模块之间也很容易出现一些问题，所以对像HBase这样的大型分布式系统来说，优化系统运行，及时解决系统运行过程中出现的问题也变得至关重要。正所谓：“你”若安好，便是晴天；“你”若有恙，我便没有星期天。
历史现状
HBase交接到我们团队手上时，已经在线上运行有一大段时间了，期间也偶尔听到过系统不稳定的、时常会出现一些问题的言论，但我们认为：一个能被大型互联网公司广泛采用的系统(包括Facebook，twitter，淘宝，小米等)，其在性能和可用性上是毋庸置疑的，何况像Facebook这种公司，是在经过严格选型后，放弃了自己开发的Cassandra系统，用HBase取而代之。既然这样，那么，HBase的不稳定、经常出问题一定有些其他的原因，我们所要做的，就是找出这些HBase的不稳定因素，还HBase一个“清白”。“查案”之前，先来简单回顾一下我们接手HBase时的现状(我们运维着好几个HBase集群，这里主要介绍问题最多那个集群的调优)：
名称
数量
备注
服务器数量
17
配置不同，HBase、HDFS都部署在这些机器上
表数量
30+
只有部分表的数据量比较大，其他基本没多少数据
Region数量
600+
基本上都是数据量较大的表划分的region较多
请求量
50000+
服务器请求分布极其不均匀
应用反应经常会过段时间出现数据写入缓慢，导致应用端数据堆积现象，是否可以通过增加机器数量来解决？
其实，那个时候，我们本身对HBase也不是很熟悉，对HBase的了解，也仅仅在做过一些测试，了解一些性能，对内部结构，实现原理之类的基本上都不怎么清楚。于是刚开始几天，各种问题，每天晚上拉着一男一起摸索，顺利的时候，晚上8，9点就可以暂时搞定线上问题，更多的时候基本要到22点甚至更晚(可能那个时候流量也下去了)，通过不断的摸索，慢慢了解HBase在使用上的一些限制，也就能逐渐解决这一系列过程中发现的问题。后面挑几个相对比较重要，效果较为明显的改进点，做下简单介绍。
调优
首先根据目前17台机器，50000+的QPS，并且观察磁盘的I/O利用率和CPU利用率都相当低来判断：当前的请求数量根本没有达到系统的性能瓶颈，不需要新增机器来提高性能。如果不是硬件资源问题，那么性能的瓶颈究竟是什么？
Rowkey设计问题
现象
打开HBase的Web端，发现HBase下面各个RegionServer的请求数量非常不均匀，第一个想到的就是HBase的热点问题，具体到某个具体表上的请求分布如下：
HBase表请求分布
上面是HBase下某张表的region请求分布情况，从中我们明显可以看到，部分region的请求数量为0，而部分的请求数量可以上百万，这是一个典型的热点问题。
原因HBase出现热点问题的主要原因无非就是rowkey设计的合理性，像上面这种问题，如果rowkey设计得不好，很容易出现，比如：用时间戳生成rowkey，由于时间戳在一段时间内都是连续的，导致在不同的时间段，访问都集中在几个RegionServer上，从而造成热点问题。
解决
知道了问题的原因，对症下药即可，联系应用修改rowkey规则，使rowkey数据随机均匀分布，效果如下：
Rowkey重定义后请求分布
建议
对于HBase来说，rowkey的范围划定了RegionServer，每一段rowkey区间对应一个RegionServer，我们要保证每段时间内的rowkey访问都是均匀的，所以我们在设计的时候，尽量要以hash或者md5等开头来组织rowkey。
Region重分布
现象