您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
HBase最佳实践 – Scan用法大观园
 
   次浏览      
 2018-1-16  
 
编辑推荐:

本文来自于范欣欣 ,文章主要从原理实践及场景介绍的,图文说明详细,希望对大家有帮助。

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会更加成熟。

   
次浏览       
相关文章

基于EA的数据库建模
数据流建模(EA指南)
“数据湖”:概念、特征、架构与案例
在线商城数据库系统设计 思路+效果
 
相关文档

Greenplum数据库基础培训
MySQL5.1性能优化方案
某电商数据中台架构实践
MySQL高扩展架构设计
相关课程

数据治理、数据架构及数据标准
MongoDB实战课程
并发、大容量、高性能数据库设计与优化
PostgreSQL数据库实战培训