HBase最佳实践 – Scan用法大观园-HBase-@太阳城手机版资讯
你好,游客 登录
背景:
阅读新闻

HBase最佳实践 – Scan用法大观园

[日期:2017-10-31] 来源:有态度的HBase  作者: [字体: ]

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请求整个流程可以分为如下几个步骤:

  1. next请求首先会检查客户端缓存中是否存在还没有读取的太阳城行,如果有就直接返回,否则需要将next请求给HBase服务器端(RegionServer)。
  2. 如果客户端缓存已经没有扫描结果,就会将next请求发送给HBase服务器端。默认情况下,一次next请求仅可以请求100行太阳城(或者返回结果集总大小不超过2M)
  3. 服务器端接收到next请求之后就开始从BlockCache、HFile以及memcache中一行一行进行扫描,扫描的行数达到100行之后就返回给客户端,客户端将这100条太阳城缓存到内存并返回一条给上层业务。

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

  1. HBase本身存储了海量太阳城,所以很多场景下一次scan请求的太阳城量都会比较大。如果不限制每次请求的太阳城集大小,很可能会导致系统带宽吃紧从而造成整个集群的不稳定。
  2. 如果不限制每次请求的太阳城集大小,很多情况下可能会造成客户端缓存OOM掉。
  3. 如果不限制每次请求的太阳城集大小,很可能服务器端扫描大量太阳城会花费大量时间,客户端和服务器端的连接就会timeout。

这样的设计有没有瑕疵?

next策略可以避免在太阳城手机版量的情况下发生各种异常情况,但这样的设计对于扫描效率似乎并不友好,这里举两个例子:

  1. scan并没有并发执行。这里可能很多看官会问:扫描太阳城分布在不同的region难道也不会并行执行扫描吗?是的,确实不会,至少在现在的版本中没有实现。这点一定出乎很多读者的意料,我们知道get的批量读请求会将所有的请求按照目标region进行分组,不同分组的get请求会并发执行读取。然而scan并没有这样实现。
  2. 大家有没有注意到上图中步骤3和步骤4之间HBase服务器端扫描太阳城的时候HBase客户端在干什么?阻塞等待是吧。确实,所以从客户端视角来看整个扫描时间=客户端处理太阳城时间+服务器端扫描太阳城时间,这能不能优化?

ScanAPI应用场景

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

ScanAPI最佳实践

  1. 批量OLAP扫描业务建议不要使用ScanAPI,ScanAPI适用于少量太阳城扫描场景(OLTP场景)
  2. 建议所有scan尽可能都设置startkey以及stopkey减少扫描范围
  3. 建议所有仅需要扫描部分列的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最佳实践

  1. TableScanMR设计为OLAP场景使用,因此在离线扫描时尽可能使用该中方式
  2. TableScanMR原理上主要实现了ScanAPI的并行化,将scan按照region边界进行切分。这种场景下整个scan的时间基本等于最大region扫描的时间。在某些有太阳城倾斜的场景下可能出现某一个region上有大量待扫描太阳城,而其他大量region上都仅有很少的待扫描太阳城。这样并行化效果并不好。针对这种太阳城倾斜的场景TableScanMR做了平衡处理,它会将大region上的scan切分成多个小的scan使得所有分解后的scan扫描的太阳城量基本相当。这个优化默认是关闭的,需要设置参数” hbase.mapreduce.input.autobalance ”为true。因此建议大家使用TableScanMR时将该参数设置为true。
  3. 尽量将扫描表中相邻的小region合并成大region,而将大region切分成稍微小点的region
  4. 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 的用法,在此基础上做部分修改即可,如下所示:


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

  1. 从命名来看就知道,SnapshotScanMR扫描于原始表对应的snapshot之上(更准确来说根据snapshot restore出来的hfile),而TableScanMR扫描于原始表。
  2. SnapshotScanMR直接会在客户端打开region扫描HDFS上的文件,不需要发送Scan请求给RegionServer,再有RegionServer扫描HDFS上的文件。是的,你没看错,是在客户端直接扫描HDFS上的文件,这类scanner称之为ClientSideRegionScanner。
  3. 两者切分大scan的策略不尽相同,TableScanMR上节介绍过是基于region的分界进行分解的,但SnapshotScanMR…

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


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

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

  1. 减小对RegionServer的影响。很显然,SnapshotScanMR这种绕过RegionServer的实现方式最大限度的减小了对集群中其他业务的影响。
  2. 极大的提升了扫描效率。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会更加成熟。

这段时间因为忙其他的事情,只能用很早的一篇文章来凑个数,不过后面笔者还会写出更多的技术文章。大家有什么想了解的主题也可以给笔者在评论区留言,笔者尽可能写更多大家普遍关心的博客!





收藏 推荐 打印 | 录入:Cstor | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款