HBase最佳实践 – Scan用法

HBase从用法的角度来讲其实乏陈可善，所有更新插入删除基本一两个API就可以搞定，要说稍微有点复杂的话，Scan的用法可能会多一些说头。而且经过笔者观察，很多业务对Scan的用法可能存在一些误区(对于这些误区，笔者也会在下文指出)，因此有了本篇文章的写作动机。也算是Scan系列的其中一篇吧，后面对于Scan还会有一篇结合HDFS分析HBase数据读取在HDFS层面是怎么一个流程，敬请期待。

HBase中Scan从大的层面来看主要有三种常见用法：ScanAPI、TableScanMR以及SnapshotScanMR。三种用法的原理不尽相同，扫描效率也当然相差甚多，最重要的是这几种用法适用于不同的应用场景，业务需要根据自己的使用场景选择合适的扫描方式。接下来分别对这三种用法从工作原理、最佳实践两个层面进行解析，最后再纵向对三种用法进行一下对比，希望大家能够从用法层面对Scan有更多了解。

ScanAPI

scan客户端设计原理

最常见的scan用法，见官方API文档。scan的原理之前在多篇文章中都有提及，为了表述方便，有必要在此简单概述一番。HBase中scan并不像大家想象的一样直接发送一个命令过去，服务器就将满足扫描条件的所有数据一次性返回给客户端。而实际上它的工作原理如下图所示：

 

 

上图右侧是HBase scan的客户端代码，其中for循环中每次遍历ResultScanner对象获取一行记录，实际上在客户端层面都会调用一次next请求。next请求整个流程可以分为如下几个步骤：

next请求首先会检查客户端缓存中是否存在还没有读取的数据行，如果有就直接返回，否则需要将next请求给HBase服务器端(RegionServer)。

如果客户端缓存已经没有扫描结果，就会将next请求发送给HBase服务器端。默认情况下，一次next请求仅可以请求100行数据(或者返回结果集总大小不超过2M)

服务器端接收到next请求之后就开始从BlockCache、HFile以及memcache中一行一行进行扫描，扫描的行数达到100行之后就返回给客户端，客户端将这100条数据缓存到内存并返回一条给上层业务。

上层业务不断一条一条获取扫描数据，在数据量大的情况下实际上HBase客户端会不断发送next请求到HBase服务器。有的朋友可能会问为什么scan需要设计为多次next请求的模式?个人认为这是基于多个层面的考虑：

HBase本身存储了海量数据，所以很多场景下一次scan请求的数据量都会比较大。如果不限制每次请求的数据集大小，很可能会导致系统带宽吃紧从而造成整个集群的不稳定。

如果不限制每次请求的数据集大小，很多情况下可能会造成客户端缓存OOM掉。

如果不限制每次请求的数据集大小，很可能服务器端扫描大量数据会花费大量时间，客户端和服务器端的连接就会timeout。

这样的设计有没有瑕疵?

next策略可以避免在大数据量的情况下发生各种异常情况，但这样的设计对于扫描效率似乎并不友好，这里举两个例子：

scan并没有并发执行。这里可能很多看官会问：扫描数据分布在不同的region难道也不会并行执行扫描吗?是的，确实不会，至少在现在的版本中没有实现。这点一定出乎很多读者的意料，我们知道get的批量读请求会将所有的请求按照目标region进行分组，不同分组的get请求会并发执行读取。然而scan并没有这样实现。

大家有没有注意到上图中步骤3和步骤4之间HBase服务器端扫描数据的时候HBase客户端在干什么?阻塞等待是吧。确实，所以从客户端视角来看整个扫描时间=客户端处理数据时间+服务器端扫描数据时间，这能不能优化?

ScanAPI应用场景

根据上面的分析，scan API的效率很大程度上取决于扫描的数据量。通常建议OLTP业务中少量数据量扫描的scan可以使用scan API，大量数据的扫描使用scan API，扫描性能有时候并不能够得到有效保证。

ScanAPI最佳实践

批量OLAP扫描业务建议不要使用ScanAPI，ScanAPI适用于少量数据扫描场景(OLTP场景)

建议所有scan尽可能都设置startkey以及stopkey减少扫描范围

建议所有仅需要扫描部分列的scan尽可能通过接口setFamilyMap设置列族以及列

TableScanMR

ScanAPI仅适用于OLTP场景，那OLAP场景下需要从HBase中扫描大量数据进行分析怎么办呢?现在有很多业务需求都需要从HBase扫描大量数据进行分析，比如最常见的用户行为分析业务，通常需要扫描某些用户最近一段时间的网络行为数据进行分析。

对于这类业务，HBase目前提供了两种基于MR扫描的用法，分别为TableScanMR以及SnapshotScanMR。首先来介绍TableScanMR，具体用法可以参考官方文档。TableScanMR的工作原理其实很简单，说白了就是ScanAPI的并行化。如下图所示：

 

 

TableScanMR会将scan请求根据目标region的分界进行分解，分解成多个sub-scan，每个sub-scan本质上就是一个ScanAPI。假如scan是全表扫描，那这张表有多少region，就会将这个scan分解成多个sub-scan，每个sub-scan的startkey和stopkey就是region的startkey和stopkey。

TableScanMR最佳实践

TableScanMR设计为OLAP场景使用，因此在离线扫描时尽可能使用该中方式

TableScanMR原理上主要实现了ScanAPI的并行化，将scan按照region边界进行切分。这种场景下整个scan的时间基本等于最大region扫描的时间。在某些有数据倾斜的场景下可能出现某一个region上有大量待扫描数据，而其他大量region上都仅有很少的待扫描数据。这样并行化效果并不好。针对这种数据倾斜的场景TableScanMR做了平衡处理，它会将大region上的scan切分成多个小的scan使得所有分解后的scan扫描的数据量基本相当。这个优化默认是关闭的，需要设置参数”hbase.mapreduce.input.autobalance”为true。因此建议大家使用TableScanMR时将该参数设置为true。

尽量将扫描表中相邻的小region合并成大region，而将大region切分成稍微小点的region

TableScanMR中Scan需要注意如下两个参数设置：

Scan scan = new Scan();
scan.setCaching(500); // 1 is the default in Scan, which will be bad for MapReduce jobs
scan.setCacheBlocks(false); // don't set to true for MR jobs
SnapshotScanMR

SnapshotScanMR与TableScanMR相同都是使用MR并行化对数据进行扫描，两者用法也基本相同，直接使用TableScanMR的用法，在此基础上做部分修改即可，如下所示：

 

 

但两者在实现上却有多个非常大的区别：

从命名来看就知道，SnapshotScanMR扫描于原始表对应的snapshot之上(更准确来说根据snapshot restore出来的hfile)，而TableScanMR扫描于原始表。

SnapshotScanMR直接会在客户端打开region扫描HDFS上的文件，不需要发送Scan请求给RegionServer，再有RegionServer扫描HDFS上的文件。是的，你没看错，是在客户端直接扫描HDFS上的文件，这类scanner称之为ClientSideRegionScanner。

下图是SnapshotScanMR的工作原理图(注意和TableScanMR工作原理图对比)：

 

 

这是一个相对简单的示意图，其中省略了很多处理snapshot的过程以及切分scan的过程。总体来看和TableScanMR工作流程基本一致，最大的不同来自region扫描HDFS这个模块，TableScanMR中这个模块来自于regionserver，而SnapshotScanMR中客户端直接绕过regionserver在客户端借用region中的扫描机制直接扫描hdfs中数据。

有些朋友可能要问了，为什么要这么玩?总结起来，之所以这么玩主要有两个原因：

减小对RegionServer的影响。很显然，SnapshotScanMR这种绕过RegionServer的实现方式最大限度的减小了对集群中其他业务的影响。

极大的提升了扫描效率。SnapshotScanMR相比TableScanMR在扫描效率上会有2倍～N倍的性能提升(下一小节对各种扫描用法性能做个对比评估)。有人又要问了，为什么会有这么大的性能提升?个人认为主要有如下两个方面的原因：

扫描的过程少了一次网络传输，对于大数据量的扫描，网络传输花费的时间是非常庞大的，这主要可能牵扯到数据的序列化以及反序列化开销。

TableScanMR扫描中RegionServer很可能会成为瓶颈，而SnapshotScanMR扫描并没有这个瓶颈点。

在最后说一个TableScanMR和SnapshotScanMR都存在的问题，两者实际上都是按照region对scan进行切分，然而对于很多大region(大于30g)，单个region的扫描粒度还是太大。另外，很多scan扫描可能并没有涉及多个region，而是集中在某一个region上，举个例子，扫描某个用户最近一个月的行为记录，如果rowkey设计为username+timestamp的话，待扫描数据通常会集中存储在一个region上，这种扫描如果使用MR的话，在当前的策略下只会生成一个Mapper。因此有必要提供一些其他策略可以将scan分解的粒度做的更细。

基本性能对比

针对TableScanMR和SnapshotScanMR两种扫描方式，笔者做过一个简单测试，同样扫描1亿条单行1K的记录(region有15个)，SnapshotScanMR所需要的时间基本是TableScanMR的一半。前些天笔者刚好看到一个分享，里面有对使用ScanAPI、ClientSideRegionScannerAPI、TableScannMR以及SnapshotScanMR进行了性能对比，如下图所示：

 

 

 

 

从上图中可以看出，使用ScanAPI的性能最差，SnapshotScanMR的性能最好。SnapshotScanMR的性能相比TableScanMR(ScanMR)也有3倍的性能提升。然而在实际应用中，和小米committer争神之前聊过，SnapshotScanMR目前可能还有很多不是很完善的地方，他们也在不断的修复，相信在之后的版本中SnapshotScanMR会更加成熟。