hbase 是hadoop生态圈的一员，在数据服务应用中具有举足轻重的地位，我们当然有必要掌握，hbase日常的大部分应用在数据查询服务中，因此查询的时候必然涉及到scan操作，因此在建表的时候就要对htable 进行优化，比如设置块缓存，设置过期时间等，设置保留的版本号，这些为什么如此重要？下面详细说，很多时候感觉hbase很多东西，单深入下去之后就会发现hbase设计实在太为精妙，很多东西都是具有强关联性和一致性。

HBASE 优化

• HBASE的优化分为通用型的优化和定制型的优化，通用型的优化部分就是不针对具体的业务场景，都会有好的优化效果，定制型的优化需要结合具体的使用场景。

先说下hbase的读流程:

1. 客户端向Zookeeper(ZK)发起请求，从ZK获取meta表中region所在的位置，根据表的信息找到对应的RegionServer(RS)信息，
2. 首先从RS的memstore缓存中读取数据，如果存在直接返回，如果查找不到从StoreFile中查找。

hbase的写流程:

1. 客户端向发起写请求，根据写请求类型不同，如果是修改表结构，创建或者删除表，会与HMaster(HM)交互，如果是更新或者插入操作，则会与zk交互，从ZK获取meta表中region所在的位置，从
2. 数据会写两份，一份到memstore中，一份到Hlog中，
   1. 当memstore中的文件大小超过阈值时，会把数据flush到storefile中，当storefile中文件数超过一定数目时，会按照某种文件合并策略触发compact操作，把多个storefile合并为一个大的storefile,当形成的storefile超过region 分裂的阈值，又回出发split操作，分裂成2个小的region
   2. 当memstore数据丢失，会从hlog中恢复，同样会执行compact和split操作。

关于compact的触发时机，大家可以看下源码，也有网友分享：

HBase源码分析之compact请求发起时机、判断条件等详情（一）_大数据_辰辰爸的博客-CSDN博客​blog.csdn.net

后面我也会参照源码和自己的理解去写一篇文章，这个点很重要，面试经常问到。

现在读写流程已经分析了，那么开始讲如何优化了。

通用型的优化方法：

1.预先分区： 创建hbase表的时候自动创建多个region分区

2.rowkey优化：rowkey优化结合业务进行设计，考虑查询，

要遵循的几个原则，

• rowkey长度越小越好，减少存储空间，提高hbase存储效率，
• rowkey 按照字典排序存储，把经常访问的数据存放在一起，
• 如果涉及时间的查找，rowkey需要带上时间戳的
• 前缀加盐处理，写入性能提升，但是读性能会受到影响，主要看如何进行加盐处理（hash处理）。

3. 减少column family 数量，无论是从读和写角度，column family都不要超过2个。

关于这部分的优化，可以参考这篇文章：

HBase 优化，columnFamily和qualifierColumn的设计原则​my.oschina.net

4. 缓存策略

创建表的时候，可以通过HColumnDescriptor.setInMemory(true)将表放在RS的缓存中，保证在读取的时候被cache命中

5. 设置存储生命周期

创建表的时候，可以通过 HColumnDescriptor.setTimeToLive(int timeToLive) 设置表中数据的存储生命期，过期数据将自动被删除，但是也有负作用，这样会导致major compaction的触发，影响regionserver的性能

6. 硬盘配置合理，提供更细粒度的冗余备份，更快速的单盘故障恢复，

每台 RegionServer 管理 10~1000 个 Regions，每个 Region 在 1~2G，则每台 Server 最少要 10G，最大要 1000*2G=2TB，考虑 3 备份，则要 6TB。方案一是用 3 块 2TB 硬盘，二是用 12 块 500G 硬盘，带宽足够时，后者能提供更大的吞吐率，更细粒度的冗余备份，更快速的单盘故障恢复。

7. 分配合适的内存给RS ,在不影响其他服务的情况下，越大越好。

例如在 HBase 的 conf 目录下的 hbase-env.sh 的最后添加 export HBASE_REGIONSERVER_OPTS="-Xmx16000m $HBASE_REGIONSERVER_OPTS”

8. 写备份数

备份数与读性能成正比，与写性能成反比，

且备份数影响高可用性。有两种配置方式，一种是将 hdfs-site.xml 拷贝到 hbase 的 conf 目录下，然后在其中添加或修改配置项 dfs.replication 的值为要设置的备份数，这种修改对所有的 HBase 用户表都生效，另外一种方式，是改写 HBase 代码，让 HBase 支持针对列族设置备份数，在创建表时，设置列族备份数，默认为 3，此种备份数只对设置的列族生效。

8. 批量写，增打客户端一次从服务器拉取的数量，当然要考虑到客户端的内存大小。

1）在 HBase 的 conf 配置文件中进行配置 hbase.client.scanner.caching；

2）通过调用 HTable.setScannerCaching(int scannerCaching) 进行配置；

3）通过调用 Scan.setCaching(int caching) 进行配置。三者的优先级越来越高。

9. RegionServer 的请求处理 IO 线程数

针对不同业务查询需求，设置合理的IO线程数

较少的 IO 线程适用于处理单次请求内存消耗较高的 Big Put 场景 (大容量单次 Put 或设置了较大 cache 的 Scan，均属于 Big Put) 或 ReigonServer 的内存比较紧张的场景。

较多的 IO 线程，适用于单次请求内存消耗低，TPS 要求 (每秒事务处理量 (TransactionPerSecond)) 非常高的场景。设置该值的时候，以监控内存为主要参考。

在 hbase-site.xml 配置文件中配置项为 hbase.regionserver.handler.count。

10. Region 大小设置

再配合 RegionSplitter 这个工具，在需要 split 时，手动 split。手动 split 在灵活性和稳定性上比起自动 split 要高很多，而且管理成本增加不多，比较推荐 online 实时系统使用

其他参数优化可参考：

https://www.ibm.com/developerworks/cn/java/j-lo-HBase/index.html​www.ibm.com

定制化优化方法参考这篇文章：

HBase Rowkey 设计指南​www.iteblog.com

一般我们自己做业务，主要是预先分区，设计rowkey，调整缓存大小，加盐处理，手动split和compact尚未尝试过。