HBase原理-数据读取流程解析

和写流程相比,HBase读数据是一个更加复杂的操作流程,这主要基于两个方面的原因:其一是因为整个HBase存储引擎基于LSM-Like树实现,因此一次范围查询可能会涉及多个分片、多块缓存甚至多个数据存储文件;其二是因为HBase中更新操作以及删除操作实现都很简单,更新操作并没有更新原有数据,而是使用时间戳属性实现了多版本。删除操作也并没有真正删除原有数据,只是插入了一条打上”deleted”标签的数据,而真正的数据删除发生在系统异步执行Major_Compact的时候。很显然,这种实现套路大大简化了数据更新、删除流程,但是对于数据读取来说却意味着套上了层层枷锁,读取过程需要根据版本进行过滤,同时对已经标记删除的数据也要进行过滤。

总之,把这么复杂的事情讲明白并不是一件简单的事情,为了更加条理化地分析整个查询过程,接下来笔者会用两篇文章来讲解整个过程,首篇文章主要会从框架的角度粗粒度地分析scan的整体流程,并不会涉及太多的细节实现。大多数看客通过首篇文章基本就可以初步了解scan的工作思路;为了能够从细节理清楚整个scan流程,接着第二篇文章将会在第一篇的基础上引入更多的实现细节以及HBase对于scan所做的基础优化。因为理解问题可能会有纰漏,希望可以一起探讨交流,欢迎拍砖~

Client-Server交互逻辑

运维开发了很长一段时间HBase,经常有业务同学咨询为什么客户端配置文件中没有配置RegionServer的地址信息,这里针对这种疑问简单的做下解释,客户端与HBase系统的交互阶段主要有如下几个步骤:



795841

  1. 客户端首先会根据配置文件中zookeeper地址连接zookeeper,并读取/<hbase-rootdir>/meta-region-server节点信息,该节点信息存储HBase元数据(hbase:meta)表所在的RegionServer地址以及访问端口等信息。用户可以通过zookeeper命令(get /<hbase-rootdir>/meta-region-server)查看该节点信息。
  2. 根据hbase:meta所在RegionServer的访问信息,客户端会将该元数据表加载到本地并进行缓存。然后在表中确定待检索rowkey所在的RegionServer信息。
  3. 根据数据所在RegionServer的访问信息,客户端会向该RegionServer发送真正的数据读取请求。服务器端接收到该请求之后需要进行复杂的处理,具体的处理流程将会是这个专题的重点。

通过上述对客户端以及HBase系统的交互分析,可以基本明确两点:

  1. 客户端只需要配置zookeeper的访问地址以及根目录,就可以进行正常的读写请求。不需要配置集群的RegionServer地址列表。
  2. 客户端会将hbase:meta元数据表缓存在本地,因此上述步骤中前两步只会在客户端第一次请求的时候发生,之后所有请求都直接从缓存中加载元数据。如果集群发生某些变化导致hbase:meta元数据更改,客户端再根据本地元数据表请求的时候就会发生异常,此时客户端需要重新加载一份最新的元数据表到本地。

-----------------此处应有华丽丽的分隔线----------------

RegionServer接收到客户端的get/scan请求之后,先后做了两件事情:构建scanner体系(实际上就是做一些scan前的准备工作),在此体系基础上一行一行检索。举个不太合适但易于理解的例子,scan数据就和开发商盖房一样,也是分成两步:组建施工队体系,明确每个工人的职责;一层一层盖楼。

构建scanner体系-组建施工队

scanner体系的核心在于三层scanner:RegionScanner、StoreScanner以及StoreFileScanner。三者是层级的关系,一个RegionScanner由多个StoreScanner构成,一张表由多个列族组成,就有多少个StoreScanner负责该列族的数据扫描。一个StoreScanner又是由多个StoreFileScanner组成。每个Store的数据由内存中的MemStore和磁盘上的StoreFile文件组成,相对应的,StoreScanner对象会雇佣一个MemStoreScanner和N个StoreFileScanner来进行实际的数据读取,每个StoreFile文件对应一个StoreFileScanner,注意:StoreFileScanner和MemstoreScanner是整个scan的最终执行者

对应于建楼项目,一栋楼通常由好几个单元楼构成(每个单元楼对应于一个Store),每个单元楼会请一个监工(StoreScanner)负责该单元楼的建造。而监工一般不做具体的事情,他负责招募很多工人(StoreFileScanner),这些工人才是建楼的主体。下图是整个构建流程图:



818160

  1.  RegionScanner会根据列族构建StoreScanner,有多少列族就构建多少StoreScanner,用于负责该列族的数据检索

       1.1 构建StoreFileScanner:每个StoreScanner会为当前该Store中每个HFile构造一个StoreFileScanner,用于实际执行对应文件的检索。同时会为对应Memstore构造一个MemstoreScanner,用于执行该Store中Memstore的数据检索。该步骤对应于监工在人才市场招募建楼所需的各种类型工匠。

       1.2  过滤淘汰StoreFileScanner:根据Time Range以及RowKey Range对StoreFileScanner以及MemstoreScanner进行过滤,淘汰肯定不存在待检索结果的Scanner。上图中StoreFile3因为检查RowKeyRange不存在待检索Rowkey所以被淘汰。该步骤针对具体的建楼方案,裁撤掉部分不需要的工匠,比如这栋楼不需要地暖安装,对应的工匠就可以撤掉。

       1.3  Seek rowkey:所有StoreFileScanner开始做准备工作,在负责的HFile中定位到满足条件的起始Row。工匠也开始准备自己的建造工具,建造材料,找到自己的工作地点,等待一声命下。就像所有重要项目的准备工作都很核心一样,Seek过程(此处略过Lazy Seek优化)也是一个很核心的步骤,它主要包含下面三步:

  • 定位Block Offset:在Blockcache中读取该HFile的索引树结构,根据索引树检索对应RowKey所在的Block Offset和Block Size
  • Load Block:根据BlockOffset首先在BlockCache中查找Data Block,如果不在缓存,再在HFile中加载
  • Seek Key:在Data Block内部通过二分查找的方式定位具体的RowKey

整体流程细节参见《HBase原理-探索HFile索引机制》,文中详细说明了HFile索引结构以及如何通过索引结构定位具体的Block以及RowKey

       1.4  StoreFileScanner合并构建最小堆:将该Store中所有StoreFileScanner和MemstoreScanner合并形成一个heap(最小堆),所谓heap是一个优先级队列,队列中元素是所有scanner,排序规则按照scanner seek到的keyvalue大小由小到大进行排序。这里需要重点关注三个问题,首先为什么这些Scanner需要由小到大排序,其次keyvalue是什么样的结构,最后,keyvalue谁大谁小是如何确定的:

  • 为什么这些Scanner需要由小到大排序?

最直接的解释是scan的结果需要由小到大输出给用户,当然,这并不全面,最合理的解释是只有由小到大排序才能使得scan效率最高。举个简单的例子,HBase支持数据多版本,假设用户只想获取最新版本,那只需要将这些数据由最新到最旧进行排序,然后取队首元素返回就可以。那么,如果不排序,就只能遍历所有元素,查看符不符合用户查询条件。这就是排队的意义。

工匠们也需要排序,先做地板的排前面,做墙体的次之,最后是做门窗户的。做墙体的内部还需要再排序,做内墙的排前面,做外墙的排后面,这样,假如设计师临时决定不做外墙的话,就可以直接跳过外墙部分工作。很显然,如果不排序的话,是没办法临时做决定的,因为这部分工作已经可能做掉了。

  • HBase中KeyValue是什么样的结构?

          HBase中KeyValue并不是简单的KV数据对,而是一个具有复杂元素的结构体,其中Key由RowKey,ColumnFamily,Qualifier ,TimeStamp,KeyType等多部分组成,Value是一个简单的二进制数据。Key中元素KeyType表示该KeyValue的类型,取值分别为Put/Delete/Delete Column/Delete Family等。KeyValue可以表示为如下图所示:



99091

        了解了KeyValue的逻辑结构后,我们不妨再进一步从原理的角度想想HBase的开发者们为什么如此对其设计。这个就得从HBase所支持的数据操作说起了,HBase支持四种主要的数据操作,分别是Get/Scan/Put/Delete,其中Get和Scan代表数据查询,Put操作代表数据插入或更新(如果Put的RowKey不存在则为插入操作、否则为更新操作),特别需要注意的是HBase中更新操作并不是直接覆盖修改原数据,而是生成新的数据,新数据和原数据具有不同的版本(时间戳);Delete操作执行数据删除,和数据更新操作相同,HBase执行数据删除并不会马上将数据从数据库中永久删除,而只是生成一条删除记录,最后在系统执行文件合并的时候再统一删除。

        HBase中更新删除操作并不直接操作原数据,而是生成一个新纪录,那问题来了,如何知道一条记录到底是插入操作还是更新操作亦或是删除操作呢?这正是KeyType和Timestamp的用武之地。上文中提到KeyType取值为分别为Put/Delete/Delete Column/Delete Family四种,如果KeyType取值为Put,表示该条记录为插入或者更新操作,而无论是插入或者更新,都可以使用版本号(Timestamp)对记录进行选择;如果KeyType为Delete,表示该条记录为整行删除操作;相应的KeyType为Delete Column和Delete Family分别表示删除某行某列以及某行某列族操作;

  • 不同KeyValue之间如何进行大小比较?

        上文提到KeyValue中Key由RowKey,ColumnFamily,Qualifier ,TimeStamp,KeyType等5部分组成,HBase设定Key大小首先比较RowKey,RowKey越小Key就越小;RowKey如果相同就看CF,CF越小Key越小;CF如果相同看Qualifier,Qualifier越小Key越小;Qualifier如果相同再看Timestamp,Timestamp越大表示时间越新,对应的Key越小。如果Timestamp还相同,就看KeyType,KeyType按照DeleteFamily -> DeleteColumn -> Delete -> Put 顺序依次对应的Key越来越大。

2. StoreScanner合并构建最小堆:上文讨论的是一个监工如何构建自己的工匠师团队以及工匠师如何做准备工作、排序工作。实际上,监工也需要进行排序,比如一单元的监工排前面,二单元的监工排之后… StoreScanner一样,列族小的StoreScanner排前面,列族大的StoreScanner排后面。

scan查询-层层建楼

构建Scanner体系是为了更好地执行scan查询,就像组建工匠师团队就是为了盖房子一样。scan查询总是一行一行查询的,先查第一行的所有数据,再查第二行的所有数据,但每一行的查询流程却没有什么本质区别。盖房子也一样,无论是盖8层还是盖18层,都需要一层一层往上盖,而且每一层的盖法并没有什么区别。所以实际上我们只需要关注其中一行数据是如何查询的就可以。

对于一行数据的查询,又可以分解为多个列族的查询,比如RowKey=row1的一行数据查询,首先查询列族1上该行的数据集合,再查询列族2里该行的数据集合。同样是盖第一层房子,先盖一单元的一层,再改二单元的一层,盖完之后才算一层盖完,接着开始盖第二层。所以我们也只需要关注某一行某个列族的数据是如何查询的就可以。

还记得Scanner体系构建的最终结果是一个由StoreFileScanner和MemstoreScanner组成的heap(最小堆)么,这里就派上用场了。下图是一张表的逻辑视图,该表有两个列族cf1和cf2(我们只关注cf1),cf1只有一个列name,表中有5行数据,其中每个cell基本都有多个版本。cf1的数据假如实际存储在三个区域,memstore中有r2和r4的最新数据,hfile1中是最早的数据。现在需要查询RowKey=r2的数据,按照上文的理论对应的Scanner指向就如图所示:



544501

这三个Scanner组成的heap为<MemstoreScanner,StoreFileScanner2, StoreFileScanner1>,Scanner由小到大排列。查询的时候首先pop出heap的堆顶元素,即MemstoreScanner,得到keyvalue = r2:cf1:name:v3:name23的数据,拿到这个keyvalue之后,需要进行如下判定:

  1. 检查该KeyValue的KeyType是否是Deleted/DeletedCol等,如果是就直接忽略该列所有其他版本,跳到下列(列族)
  2. 检查该KeyValue的Timestamp是否在用户设定的Timestamp Range范围,如果不在该范围,忽略
  3. 检查该KeyValue是否满足用户设置的各种filter过滤器,如果不满足,忽略
  4. 检查该KeyValue是否满足用户查询中设定的版本数,比如用户只查询最新版本,则忽略该cell的其他版本;反正如果用户查询所有版本,则还需要查询该cell的其他版本。

现在假设用户查询所有版本而且该keyvalue检查通过,此时当前的堆顶元素需要执行next方法去检索下一个值,并重新组织最小堆。即图中MemstoreScanner将会指向r4,重新组织最小堆之后最小堆将会变为<StoreFileScanner2, StoreFileScanner1, MemstoreScanner>,堆顶元素变为StoreFileScanner2,得到keyvalue=r2:cf1:name:v2:name22,进行一系列判定,再next,再重新组织最小堆…

不断重复这个过程,直至一行数据全部被检索得到。继续下一行…

----------------此处应有华丽丽的分隔符----------------

本文从框架层面对HBase读取流程进行了详细的解析,文中并没有针对细节进行深入分析,一方面是担心个人能力有限,引入太多细节会让文章难于理解,另一方面是大多数看官可能对细节并不关心,下篇文章笔者会揪出来一些比较重要的细节和大家一起交流~

文章最后,贴出来一个一些朋友咨询的问题:Memstore在flush的时候会不会将Blockcache中的数据update?如果不update的话不就会产生脏读,读到以前的老数据?

这个问题大家可以思考思考,我们下一篇文章再见~

范欣欣

就职于网易杭州研究院后台技术中心数据库技术组,从事HBase开发、运维,对HBase相关技术有浓厚的兴趣。邮箱:libisthanks@gmail.com

在 “HBase原理-数据读取流程解析” 上有 44 条评论

        1. 安全性个人理解主要包括权限隔离、资源隔离两个部分。权限隔离主要解决租户之间不能互相访问的问题,目前hbase的权限管理比较简单,基于kerberos的角色权限认证,可以参考kerberos相关的文章。(如果有兴趣也可以了解下ranger,可以更加细粒度的处理HBase的权限问题,不过目前还不普及);资源隔离主要解决租户业务之间不会相互干扰的问题,目前HBase还没有很有效的方案,后续应该在2.0版本会推出rsgroup方案,可参考HBase-6721

  1. 博主你好,Hbase动态添加的regionserver节点一定要部署在hdfs节点上吗?如果不需要的话,hdfs是配置成HA的,core-site.xml中配置是:

    fs.defaultFS
    hdfs://mycluster

    hdfs-site.xml的配置是:


    dfs.nameservices
    mycluster


    dfs.ha.namenodes.mycluster
    nn1,nn2

    hbase-site.xml对应配置是:

    hbase.rootdir
    hdfs://mycluster/hbase

    若regionserver部署在一个和hdfs不相关的节点上,regionserver不识别mycluster要怎么办呢?

    1. 我试过在动态添加的regionserver节点上,把master节点的别名配成mycluster添加到hosts中去,这样是可以的。不过mycluster应该是主备两个节点的,这样只添加一个节点是不是有问题的?原来的Hbase集群各节点和HDFS集群各节点是一一对应的。

      1. 恩恩。博主再问您个问题:为什么增大memstore会造成插入性能的下降呢?测试好多次,几乎都是线性下降的。

        1. 增大memstore是指增大参数“hbase.regionserver.global.memstore.size”还是”hbase.hregion.memstore.flush.size”?线性下降是什么意思?

          1. 1、增大JVM是指:我的block cache配置成LRU模式,保持memstore的上线水线和hfile.block.cache.size不变,通过增大JVM大小达到增大memstore的目的。
            2、线性下降是指:JVM配置的越大,插入吞吐越低。
            3、我也试过JVM不变只改变memstore上下水线,这样测出的结果是改变memstore大小对插入吞吐影响不大。

  2. 1、增大memstore是指:我的block cache配置成LRU模式,保持memstore的上线水线和hfile.block.cache.size不变,通过增大JVM大小达到增大memstore的目的。
    2、线性下降是指:JVM配置的越大,插入吞吐越低。
    3、我也试过JVM不变只改变memstore上下水线,这样测出的结果是改变memstore大小对插入吞吐影响不大。

    1. 这是因为写入性能瓶颈基本不在内存大小,而在hlog。增大jvm反而会使得gc性能变差,进而会使得写入性能降低。

  3. 不是特别最小堆那里,同一行的数据,Memstore刚开始不是最大吗?为什么会排前面,还是最小堆负责维护Rowkey从小到大,然后在同一Rowkey里,按时间戳从大到小读?

  4. 噢,谢谢。还有一点不是特别明白,HFile是针对一个列族的,里面所有数据都是同样列族,KeyValue里为何还需要把列族重复存那么多次,为何不直接把列族名放在HFile的描述信息里。

    1. 这个问题以前也思考过 不过没有想到特别合理的解释 个人感觉这样设计在cf很小的情况下可以更加方便地执行各种操作

    2. 我也特别纠结这个地方,如果考虑数据压缩,列族名确实是可以提出来放到每个Hfile的公共描述信息里,构造查询结果时加上相关值即可,压缩成本一点不大,为何HFile中每个KeyValue中都要加上列族名,一直迷惑不解!!!

    1. hbase-client访问不需要配置hosts映射 只需要配置文件中配置ZK地址就可以 配置hosts映射可能是因为你的域名访问有问题吧

  5. 博主你好,”客户端会将hbase:meta元数据表缓存在本地”这里,是将meta表整张表数据缓存到本地,还是将表内对应的某几条记录缓存到本地?

  6. 读取过程中,通过PriorityQueue以小顶堆的形式组织scanner,实现对各个数据分片的顺序扫描和读取,这招确实很妙!
    这个思路其实在很多具有数据分片形式的分布式系统中都有用到,确实是一个比较好的实践。

  7. 题主您好,请教几个问题:
    1.memstore flush是否更新blockcache ?

    2.hbase的L1 ,L2 cache 是指什么意思?为什么我配置了blockcache, offheap,combinedbucket 0.8,发现lru 特别大,offheap 好像没有多少?是没成功还是需要另外配置?如何看这个off heap ?
    3.offheap 是否在jvm xmx 堆内存中,我理解应该不在。那么rs 占用内存是不是xmx +offheap ?
    4.keyvalue 的设计问题:hbase 一行数据200列的话,我看代码存储就是200个kv,每个kv 包含了row, cf, timestamp 等。很多情况下是一次put 一行,很多列,这些列时间戳也都相同,这样存储感觉很浪费。特别是列值比较短的情况下,设计200列与将200列拼接在一起设计为一列对比,可能数据膨胀20倍。性能差距也很明显。这个是出于什么考虑?还是我理解错误?这个我一直没想明白。

  8. 题主您好,请教几个问题:
    1.memstore flush是否更新blockcache ?

    2.hbase的L1 ,L2 cache 是指什么意思?为什么我配置了blockcache, offheap,combinedbucket 0.8,发现lru 特别大,offheap 好像没有多少?是没成功还是需要另外配置?如何看这个off heap ?
    3.offheap 是否在jvm xmx 堆内存中,我理解应该不在。那么rs 占用内存是不是xmx +offheap ?
    4.keyvalue 的设计问题:hbase 一行数据200列的话,我看代码存储就是200个kv,每个kv 包含了row, cf, timestamp 等。很多情况下是一次put 一行,很多列,这些列时间戳也都相同,这样存储感觉很浪费。特别是列值比较短的情况下,设计200列与将200列拼接在一起设计为一列对比,可能数据膨胀20倍。性能差距也很明显。这个是出于什么考虑?还是我理解错误?这个我一直没想明白。

    谢谢您。

    1. 1. flush不会更新blockcache
      2. L1 cache主要存储元数据(索引、bloomfilter等),L2 cache主要存储实际数据块。offheap好像没办法直接看,只能去top看当前regionserver内存总申请内存与jvm heap的差值
      3. offheap不在xmx配置里面。rs占用内存=xmx+offheap
      4. 这个问题目前我也解释不清楚。。。。

    2. 第4个问题,我们应用也碰到过。我觉得主要看应用的实际情况,进行取舍吧。
      1. 设计200列
      【优点】:适合较复杂的检索,比如在列/列值上加filter,建二级索引,还有就是动态列(有值才会真正保存数据)适合稀疏矩阵数据的存储;
      【缺点】:如果每行每列 都有值(比如默认值是特定值,而不是空),也就是说不是稀疏矩阵类型的数据,这样的话,确实比较浪费空间。
      2. 200列拼接在一起
      【优点】:节省空间,比如你的需求就是根据rowkey查value,可以将value设计成json串,取回客户端自己解析;
      【缺点】:对比1,只能进行相对简单的查询,也没办法在列(业务列,200列)上进行二级索引,更加灵活的filter之类的。

  9. 博主您好,HBase作为列式存储,为什么它的scan性能这么低呢,列式存储不是更有利于scan操作么?Parquet格式也是列式,但它的scan这么优秀,他们的性能差异并不是因为数据组织方式造成的么?谢谢啦

    1. 这个问题是这样的:
      1. HBase不完全是列式存储,确切的说是列族式存储,HBase中可以定义一个列族,列族下可以有都个列,这些列的数据是存在一起的。而且通常情况下我们建议列族个数不大于2个,这样的话每个列族下面必然会有很多列。因此HBase并不是列式存储,更有点像行式存储。
      2. HBase扫描本质上是一个一个的随即读,不能做到像HDFS(Parquet)这样的顺序扫描。试想,1000w数据一条一条get出来,性能必然不会很好。问题就来了,HBase为什么不支持顺序扫描?
      3. 这是因为HBase支持更新操作以及多版本的概念,这个很重要。可以说如果支持更新操作以及多版本的话,扫描性能就不会太好。原理是这样的,我们知道HBase是一个类LSM数据结构,数据写入之后先写入内存,内存达到一定程度就会形成一个文件,因此HBase的一个列族会有很多文件存在。因为更新以及多版本的原因,一个数据就可能存在于多个文件,所以需要一个文件一个文件查找才能定位出具体数据。

      所以HBase架构本身个人认为并不适合做大规模scan,很大规模的scan建议还是用Parquet,可以把HBase定期导出到Parquet来scan

      1. 第一点理解,但是第二点有点不太理解,不知道博主有没有研究过Kudu,kudu也是采用的类LSM数据结构,但是却能达到parquet的扫描速度(kudu是纯列式的),kudu的一个列也会形成很多文件,但是好像并没影响它的性能

        1. 个人对Kudu不是很懂,不过旁边有Kudu大神。我的理解是这样的:
          1. kudu性能并没有达到parquet的扫描速度,可以说介于HBase和HDFS(Parquet)之间
          2. kudu比HBase扫描性能好,是因为kudu是纯列存,扫描不会出现跳跃读的情况,而HBase可能会跳跃seek,这是本质的区别。
          3. 但kudu扫描性能又没有Parquet好,就是因为kudu是LSM结构,它扫描的时候还是会同时顺序扫描多个文件,并比较key值大小。而Parquet只需要顺序对一个block块中的数据进行扫描即可。这个是两者的区别。

          所以说hbase相比parquet,这两个方面都是scan的劣势。

  10. 根据hbase:meta所在RegionServer的访问信息,客户端会将该元数据表加载到本地并进行缓存。然后在表中确定待检索rowkey所在的RegionServer信息

    关于这点,有个问题。如果client将整个hbase:meta表缓存到本地,那么假如这个表很大,则就非常占用本地jvm的内存大小了。能否按需加载呢。只缓存这个table的meta表数据呢。否则hbase:meta的元数据表则会占用client很多业务需要应有的内存空间了

  11. 你好,博主! 我最近在学习hbase, 看完该文章后有一点不明白,在《scan查询-层层建楼》一节中r2的数据为什么会存在hfile1和hfile2中呢?

    1. 两个值的版本不一样,比如现在r2写进去一个值,这个值写到了hfile1。过一段时间又对这个值进行了更新,原来的值变成了老版本,这个值写到了hfile2。

      1. 一个HFile对应一个列族, 如果这个r2同时存在两个HFile中, 那就是说一个列族可以对应多个HFile吗?

        1. 不是一个HFile对应一个列族。一个列族的所有文件存储在一起,并不是一个一个文件,是一堆文件。

发表评论

电子邮件地址不会被公开。 必填项已用*标注