Hbase学习之读优化

从客户端和服务端两个方面来深入了解优化的方法

客户端层面

HBase 读数据共有两种方式，Get 与 Scan。

在通用层面，在客户端与服务端建连需要与 zookeeper 通信，再通过 meta 表定位到 region 信息，所以在初次读取 HBase 的时候 rt 都会比较高，避免这个情况就需要客户端针对表来做预热，简单的预热可以通过获取 table 所有的 region 信息，再对每一个 region 发送一个 Scan 或者 Get 请求，这样就会缓存 region 的地址；

rowkey 是否存在读写热点，若出现热点则失去分布式系统带来的优势，所有请求都只落到一个或几个 HRegion 上，那么请求效率一定不会高；

读写占比是如何的。如果写重读轻，浏览服务端 RegionServer 日志发现很多 MVCC STUCK 这样的字样，那么会因为 MVCC 机制因为写 Sync 到 WAL 不及时而阻塞读，这部分机制比较复杂，暂时没有使用到，不考虑。

Get 请求优化

• 将 Get 请求批量化，减少 rpc 次数，但如果一批次的 Get 数量过大，如果遇到磁盘毛刺或者 Split 毛刺，则 Get 会全部失败（不会返回部分成功的结果），抛出异常。
• 指定列族，标识符。这样可以服务端过滤掉很多无用的 scanner，减少 IO 次数，提高效率，该方法同样适用于 Scan。

Scan 请求优化

• 设定合理的 startRow 与 stopRow 。如果 scan 请求不设置这两个值，而只设置 filter，则会做全表扫描。
• 设置合理的 caching 数目， scan.setCaching(100)。 因为 Scan 潜在会扫描大量数据，因此客户端发起一次 Scan 请求，实际并不会一次就将所有数据加载到本地，而是分成多次 RPC 请求进行加载。默认值是100。用户如果确实需要扫描海量数据，同时不做逻辑分页处理，那么可以将缓存值设置到1000，减少 rpc 次数，提升处理效率。如果用户需要快速，迭代地获取数据，那么将 caching 设置为50或者100就合理。

服务端优化

相对于客户端，服务端优化可做的比较多，首先我们列出有哪些点会影响服务端处理读请求。

• gc 毛刺
• 磁盘毛刺
• HFile 文件数目
• 缓存配置
• 本地化率
• Hedged Read 模式是否开启
• 短路读是否开启
• 是否做 高可用

gc 毛刺没有很好的办法避免，通常 HBase 的一次 Young gc 时间在 20~30ms 之内。磁盘毛刺发生是无法避免的，通常 SATA 盘读 IOPS 在 150 左右，SSD 盘随机读在 30000 以上，所以存储介质使用 SSD 可以提升吞吐，变向降低了毛刺的影响。HFile 文件数目因为 flush 机制而增加，因 Compaction 机制减少，如果 HFile 数目过多，那么一次查询可能经过更多 IO ，读延迟就会更大。这部分调优主要是优化 Compaction 相关配置，包括触发阈值，Compaction 文件大小阈值，一次参与的文件数量等等，这里不再详细展开。读缓存可以设置为为 CombinedBlockCache，调整读缓存与 MemStore 占比对读请求优化同样十分重要，这里我们配置 hfile.block.cache.size 为 0.4，这部分内容又会比较艰深复杂，同样不再展开。下面结合业务需求讲下我们做的优化实践。

我们的在线集群搭建伊始，接入了比较重要的粉丝业务，该业务对RT要求极高，为了满足业务需求我们做了如下措施。

异构存储

HBase 资源隔离+异构存储。SATA 磁盘的随机 iops 能力，单次访问的 RT，读写吞吐上都远远不如 SSD，那么对RT极其敏感业务来说，SATA盘并不能胜任，所以我们需要HBase有支持SSD存储介质的能力。
为了 HBase 可以支持异构存储，首先在 HDFS 层面就需要做响应的支持，在