hbase优化分析

目录:
1.表设计
2.写表操作
3.读表操作
4.HBase服务器端优化
5.Hbase客户端优化
6.HDFS相关优化

1.表设计:

1.1 表预分区(创建预分区)
默认情况下，在创建HBase表的时候会自动创建一个region分区，当导入数据的时候，所有的HBase客户端都向这一个region写数据，直到这个region足够大了才进行切分。一种可以加快批量写入速度的方法是通过预先创建一些空的regions，这样当数据写入HBase时，会按照region分区情况，在集群内做数据的负载均衡。

1.2 RowKey(快速访问习惯)
● 通过单个row key访问：即按照某个row key键值进行get操作；
● 通过row key的range进行scan：即通过设置startRowKey和endRowKey，在这个范围内进行

1.3 Column Family(减少IO压力)
不要在一张表里定义太多的column family。目前Hbase并不能很好的处理超过2~3个column family的表。因为某个column family在flush的时候，它邻近的column family也会因关联效应被触发flush，最终导致系统产生更多的I/O

原因:
由于不同的列族会共享region，所以有可能出现，一个列族已经有1000万行，而另外一个才100行。当一个要求region分割的时候，会导致100行的列会同样分布到多个region中。这样就出现了基数问题。（如果表存在多个列族，列族A有100万行，列族B有10亿行，那么列族A可能会被分散到很多个Region上，这会导致扫描列族A的性能低下）

某个column family在flush的时候，它邻近的column family也会因关联效应被触发flush，最终导致系统产生更多的I/O,  flush同一个region

1.4 Max Version (节省硬盘资源)
创建表的时候，可以通过HColumnDescriptor.setMaxVersions(int maxVersions)设置表中数据的最大版本，如果只需要保存最新版本的数据，那么可以设置setMaxVersions(1)。

1.5 Time To Live (节省硬盘资源)
创建表的时候，可以通过HColumnDescriptor.setTimeToLive(int timeToLive)设置表中数据的存储生命期，过期数据将自动被删除，例如如果只需要存储最近两天的数据，那么可以设置setTimeToLive(2 * 24 * 60 * 60)。

2.写表操作:

2.1多Htable并发写
static final Configuration conf = HBaseConfiguration.create();
static final String table_log_name = “user_log”;
wTableLog = new HTable[tableN];
for (int i = 0; i < tableN; i++) {
wTableLog[i] = new HTable(conf, table_log_name);
wTableLog[i].setWriteBufferSize(5 * 1024 * 1024); //5MB
wTableLog[i].setAutoFlush(false);
}

2.2 Htable参数设置
2.2.1 Auto Flush(批量插入)
通过调用HTable.setAutoFlush(false)方法可以将HTable写客户端的自动flush关闭，这样可以批量写入数据到HBase，而不是有一条put就执行一次更新，只有当put填满客户端写缓存时，才实际向HBase服务端发起写请求。默认情况下auto flush是开启的。

2.2.2 Write Buffer
通过调用HTable.setWriteBufferSize(writeBufferSize)方法可以设置HTable客户端的写buffer大小，如果新设置的buffer小于当前写buffer中的数据时，buffer将会被flush到服务端。其中，writeBufferSize的单位是byte字节数，可以根据实际写入数据量的多少来设置该值。

2.2.3 Wal Flag
在HBae中，客户端向集群中的RegionServer提交数据时（Put/Delete操作），首先会先写WAL（Write Ahead Log）日志（即HLog，一个RegionServer上的所有Region共享一个HLog），只有当WAL日志写成功后，再接着写MemStore，然后客户端被通知提交数据成功；如果写WAL日志失败，客户端则被通知提交失败。这样做的好处是可以做到RegionServer宕机后的数据恢复。
因此，对于相对不太重要的数据，可以在Put/Delete操作时，通过调用Put.setWriteToWAL(false)或Delete.setWriteToWAL(false)函数，放弃写WAL日志，从而提高数据写入的性能。
值得注意的是：谨慎选择关闭WAL日志，因为这样的话，一旦RegionServer宕机，Put/Delete的数据将会无法根据WAL日志进行恢复。

2.3 批量写
通过调用HTable.put(Put)方法可以将一个指定的row key记录写入HBase，同样HBase提供了另一个方法：通过调用HTable.put(List)方法可以将指定的row key列表，批量写入多行记录，这样做的好处是批量执行，只需要一次网络I/O开销，这对于对数据实时性要求高，网络传输RTT高的情景下可能带来明显的性能提升。

2.4 多线程并发写
在客户端开启多个HTable写线程，每个写线程负责一个HTable对象的flush操作，这样结合定时flush和写buffer（writeBufferSize），可以既保证在数据量小的时候，数据可以在较短时间内被flush（如1秒内），同时又保证在数据量大的时候，写buffer一满就及时进行flush。下面给个具体的例子
for (int i = 0; i < threadN; i++) {
Thread th = new Thread() {
public void run() {
while (true) {
try {
sleep(1000); //1 second
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (wTableLog[i]) {
try {
wTableLog[i].flushCommits();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
};
th.setDaemon(true);
th.start();
}

3.读表操作

3.1 多Htable并发读
static final Configuration conf = HBaseConfiguration.create();
static final String table_log_name = “user_log”;
rTableLog = new HTable[tableN];
for (int i = 0; i < tableN; i++) {
rTableLog[i] = new HTable(conf, table_log_name);
rTableLog[i].setScannerCaching(50);
}
setScannerCaching(50),设置每次扫描50行(需要客户端的内存),默认的是10行
hbase-site.xml

hbase.client.scanner.caching
10

3.2 HTable 参数设置
3.2.1 HTable.setScannerCaching(int scannerCahingNum)
可以设置HBase scanner一次从服务端抓取的数据条数,默认情况下一次一条,通过将此设置成一个合理的值,可以减少Scan过程中Next()的时间开销,代价是scanner需要通过客户端的内存来维持这些被cache的行记录,数据量太大导致本地客户端发生OOM
通常情况下，默认的scan缓存设置就可以正常工作的。但是在一些大scan(一次scan可能需要查询几万甚至几十万行数据)来说，每次请求100条数据意味着一次scan需要几百甚至几千次RPC请求，这种交互的代价无疑是很大的。因此可以考虑将scan缓存设置增大，比如设为500或者1000就可能更加合适。笔者之前做过一次试验，在一次scan扫描10w+条数据量的条件下，将scan缓存从100增加到1000，可以有效降低scan请求的总体延迟，延迟基本降低了25%左右。
优化建议：大scan场景下将scan缓存从100增大到500或者1000，用以减少RPC次数

3.2.2 Scan Attribute Selection
Scan 时指定需要的Column Family ,可以减少网络传输数据量,否则默认scan操作会返回整行所有Column Family 的数据
优化原理：HBase是典型的列族数据库，意味着同一列族的数据存储在一起，不同列族的数据分开存储在不同的目录下。如果一个表有多个列族，只是根据Rowkey而不指定列族进行检索的话不同列族的数据需要独立进行检索，性能必然会比指定列族的查询差很多，很多情况下甚至会有2倍～3倍的性能损失。
优化建议：可以指定列族或者列进行精确查找的尽量指定查找

3.2.3
通过scan取完数据后,记得要关闭ResultScanner,否则RegionServer可能会出现问题(对应的Server资源无法释放)

3.3 批量读
通过调用HTable.get(Get)方法可以根据一个指定的row key获取一行记录，同样HBase提供了另一个方法：通过调用HTable.get(List)方法可以根据一个指定的row key列表，批量获取多行记录，这样做的好处是批量执行，只需要一次网络I/O开销，这对于对数据实时性要求高而且网络传输RTT高的情景下可能带来明显的性能提升。
优化原理：HBase分别提供了单条get以及批量get的API接口，使用批量get接口可以减少客户端到RegionServer之间的RPC连接数，提高读取性能。另外需要注意的是，批量get请求要么成功返回所有请求数据，要么抛出异常。
优化建议：使用批量get进行读取请求

离线批量读取请求是否设置禁止缓存?
优化原理：通常离线批量读取数据会进行一次性全表扫描，一方面数据量很大，另一方面请求只会执行一次。这种场景下如果使用scan默认设置，就会将数据从HDFS加载出来之后放到缓存。可想而知，大量数据进入缓存必将其他实时业务热点数据挤出，其他业务不得不从HDFS加载，进而会造成明显的读延迟毛刺
优化建议：离线批量读取请求设置禁用缓存，scan.setBlockCache(false)

3.4 多线程并发读(有点难)
在客户端开启多个HTable读线程，每个读线程负责通过HTable对象进行get操作。下面是一个多线程并发读取HBase，获取店铺一天内各分钟PV值的例子：

4.HBase服务器端优化

　　1. 读请求是否均衡?
　　优化原理：极端情况下假如所有的读请求都落在一台RegionServer的某几个Region上，这一方面不能发挥整个集群的并发处理能力，另一方面势必造成此台RegionServer资源严重消耗(比如IO耗尽、handler耗尽等)，落在该台RegionServer上的其他业务会因此受到很大的波及。可见，读请求不均衡不仅会造成本身业务性能很差，还会严重影响其他业务。当然，写请求不均衡也会造成类似的问题，可见负载不均衡是HBase的大忌。
　　观察确认：观察所有RegionServer的读请求QPS曲线，确认是否存在读请求不均衡现象
　　优化建议：RowKey必须进行散列化处理(比如MD5散列)，同时建表必须进行预分区处理

　　2. Handler设置
　　快速配置， 修改hbase-site.xml的hbase.regionserver.handler.count配置项

  1. <property>  
  2. <name>hbase.regionserver.handler.count</name>  
  3. <value>100</value>  
  4. </property>  

原理:
该配置定义了每个Region Server上的RPC Handler的数量,Region Server通过RPC Handler接收外部请求并加以处理,所以提升RPC Handler 的数量可以在一定程度上提高Hbase接收能力,这个数值取决于节点的硬件情况,需要来回调试

5.Hbase客户端优化

HBase中rowkey是索引，任何对全表的扫描或是统计都需要用到scan接口，一般都是通过next()方法获取数据。而每一个next()调用都会为每行数据生成一个单独的RPC请求，这样会产生大量的RPC请求，性能不会很好。

1.减少RPC调用的方法

如果执行一次RPC请求就可以获取多行数据，那肯定会大大提高系统的性能。这一块主要分为面向行级的缓存以及面向列级的缓存：

1）面向行级的缓存
我们可以通过使用扫描缓存方法来实现，不过这个缓存默认是关闭的，要用得打开。在表的层面使用时，这个表所有的扫描实例的缓存都会生效，在扫描层面也只会影响当前的扫描实例。
用户可以使用HTable.setScannerCaching()方法设置表级的扫描缓存，以及使用Scan.setCaching()方法设置扫描级的缓存。

2）面向列级的批量
用户可以使用Scan.setBatch()方法设置返回多少列。
通过组合使用扫描器缓存和批量大小的方式，可以让用户方便的控制扫描一个范围内的行健时所需要的RPC调用次数。

ps:

scanner需要通过客户端的内存来维持这些被cache的行记录，合理设置catching大小，防止出现OOM；
cache使用的内存计算公式为：并发数×cache数×单个result大小。

6.HDFS相关优化

HDFS作为HBase最终数据存储系统，通常会使用三副本策略存储HBase数据文件以及日志文件。从HDFS的角度望上层看，HBase即是它的客户端，HBase通过调用它的客户端进行数据读写操作，因此HDFS的相关优化也会影响HBase的读写性能。这里主要关注如下三个方面：

　　1. Short-Circuit Local Read功能是否开启?
　　优化原理：当前HDFS读取数据都需要经过DataNode，客户端会向DataNode发送读取数据的请求，DataNode接受到请求之后从硬盘中将文件读出来，再通过TPC发送给客户端。Short Circuit策略允许客户端绕过DataNode直接读取本地数据。
　　优化建议：开启Short Circuit Local Read功能
　　（hdfs-site.xml）

<property>
<name>dfs.client.read.shortcircuit</name>
<value>true</value>
</property>
<property>
<name>dfs.domain.socket.path</name>
<value>/var/lib/hadoop-hdfs/dn_socket</value>
</property>


　　2. Hedged Read功能是否开启?
　　优化原理：HBase数据在HDFS中一般都会存储三份，而且优先会通过Short-Circuit Local Read功能尝试本地读。但是在某些特殊情况下，有可能会出现因为磁盘问题或者网络问题引起的短时间本地读取失败，为了应对这类问题，社区开发者提出了补偿重试机制 – Hedged Read。该机制基本工作原理为：客户端发起一个本地读，一旦一段时间之后还没有返回，客户端将会向其他DataNode发送相同数据的请求。哪一个请求先返回，另一个就会被丢弃。
　　优化建议：开启Hedged Read功能