HBase原理－数据读取流程解析.docxVIP

HBase原理－数据读取流程解析 2021-07-06 和写流程相比，HBase读数据是一个愈加简单的操作流程，这次要基于两个方面的缘由：其一是由于整个HBase存储引擎基于LSM-Like树实现，因而一次范围查询可能会涉及多个分片、多块缓存甚至少个数据存储文件；其二是由于HBase中更新操作以及删除操作实现都很简约，更新操作并没有更新原有数据，而是使用时间戳属性实现了多版本。删除操作也并没有真正删除原有数据，只是插入了一条打上”deleted”标签的数据，而真正的数据删除发生在系统异步执行Major_Compact的时候。很明显，这种实现套路大大简化了数据更新、删除流程，但是对于数据读取来说却意味着套上了层层枷锁，读取过程需要依据版本进行过滤，同时对已经标记删除的数据也要进行过滤。 总之，把这么简单的事情讲明白并不是一件简约的事情，为了愈加条理化地分析整个查询过程，接下来笔者会用两篇文章来讲解整个过程，首篇文章次要会从框架的角度粗粒度地分析scan的全体流程，并不会涉及太多的细节实现。大多数看客通过首篇文章基本就可以初步了解scan的工作思路；为了能够从细节理清楚整个scan流程，接着其次篇文章将会在第一篇的基础上引入更多的实现细节以及HBase对于scan所做的基础优化。由于理解问题可能会有纰漏，期望可以一起探讨沟通，欢迎拍砖~ Client-Server交互规律 运维开发了很长一段时间HBase，经常有业务同学询问为什么客户端配置文件中没有配置RegionServer的地址信息，这里针对这种疑问简约的做下解释，客户端与HBase系统的交互阶段次要有如下几个步骤： 客户端首先会依据配置文件中zookeeper地址连接zookeeper，并读取//meta-region-server节点信息，该节点信息存储HBase元数据（hbase:meta）表所在的RegionServer地址以及访问端口等信息。用户可以通过zookeeper命令(get //meta-region-server)查看该节点信息。 依据hbase:meta所在RegionServer的访问信息，客户端会将该元数据表加载到本地并进行缓存。然后在表中确定待检索rowkey所在的RegionServer信息。 依据数据所在RegionServer的访问信息，客户端会向该RegionServer发送真正的数据读取恳求。服务器端接收到该恳求之后需要进行简单的处理，具体的处理流程将会是这个专题的重点。 通过上述对客户端以及HBase系统的交互分析，可以基本明确两点： 客户端只需要配置zookeeper的访问地址以及根名目，就可以进行正常的读写恳求。不需要配置集群的RegionServer地址列表。 客户端会将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）担任该单元楼的建筑。而监工一般不做具体的事情，他担任招募很多工人（