HBase原理解析（转）

本文属于转载，原文链接：http://www.aboutyun.com/thread-7199-1-1.html

前提是大家至少了解HBase的基本需求和组件。

从大家最熟悉的客户端发起请求开始讲起吧，这样大家能够深有体会的逐步了解原理。比如我们发起了一条PUT请求，客户端首先需要查找到需要响应请求的REGIONSERVER。记录region->regionserver映射是由HBASE系统表.META.记录的。所以我们只要知道. META.表的位置就能知道每个region响应的key的范围和region所在机器。但是.META.表又保存在哪些机器上呢？这又是由-ROOT-表记录的 master在分配完-ROOT-表后会将-ROOT-表的位置放到ZOOKEEPER中。所以我们在配置客户端的时候配置的是ZOOKEEPER的位置，而不是MASTER位置。

为什么要分为-ROOT-和.META.呢？这是因为region信息本身很多一个集群中可能会出现成千上万的region 因此.META.表本身也无法在一个region中保存所有用户region的信息，所以本身也会分裂。而.META.表的region数就比较有限了所以-ROOT-是不会分裂的.

综上，客户端首次请求时，先拿-ROOT-然后通过请求范围找对应的.META.，在.META.中找打具体的region server 然后发送请求。-ROOT-和.META.是可以缓存的。

现在，我们解决了客户端应当把PUT发送到哪个rs的问题，接下来就要发送请求了。region server收到请求后会保存PUT数据。这就不得不说HBASE的数据模型了，HBASE使用的列式存储，基本数据结构为LSMT log structure merge tree。简略的思路描述是，将操作记录在树中的节点上然后适时的将节点合并从而使key的删除修改能够最终体现在一个节点上，读取的时候会读取带有key相应操作的节点，返回最终key的值。可以看到lsmt是将随机读写转化为顺序读写的数据结构,读方面更适合扫库那样的顺序读取，不太适合随机读取。

那么一个PUT请求时怎么和LSMT搭上关系的呢？首先region server接到请求时，先将操作(keyvalue 时间戳操作类型)保存为HLog，然后在保存到memstore中，然后即可返回写入成功的请求。其中memstore保存在内存中，写满后flush为hdfs文件。hlog是为了防止rs故障时，memstore数据必然丢失导致的数据丢失，在客户端可以禁用hblog来加快写入速度，但这是用数据不安全换来的。只要每次memstore刷入hdfs后，会判断hdfs刷入的中最早的操作然后由另外的线程根据此记录删除旧的HLog文件。

接下来说说memstore写满时的处理。memstore写满（每个region的列族都有单独的memstore对象但实际上共用一块内存池）时，会将其中的操作分发到对应region的每个列族（store）做处理。然后store将这些操作序列保存为存储文件(storefile)。

从大体上粗略的看 region server这边重要的实体结构是这样：regionserver : region = 1 : n；region : store= 1 ： n；store : storefile = 1 : n。对于每个列族的数据文件,实机上是一个LSMT的叶子节点，每个文件中保存的是最近的对于列族中key的操作。

当一个列族中文件过多的时候，会触发compact，也就是说的文件合并。HBase的compact分为两种 minor和major：minor是小范围内的合并文件，只合并部分。目的在于把小文件积累成大文件。因为没有全量数据，所以对于一个key的删除操作还是需要保留标记，无法物理删除。majorcompact把列族中的所有文件合并为一个，目的在于使key的修改和删除，最终在物理上生效。因为major compact操作的是此列族的全量数据，所以可以做物理删除。但是也由于是全量数据，执行起来耗费时间也会比价长，所以hbase对major compact做了时间间隔限制。

当store的store file集合中总文件长度太大时(超过配置的阈值)，这个region会一分为二，也就是split。由于split是以region为单位的，所以有些列族因为其他列族过大也被连坐般的split。所以从这个流程粗略的看来 put会触发flush，flush会触发compact，compact会触发split。当然这都是在多个线程中执行的，不会明显的阻塞住客户端请求。

store file的大小和memstore大小有关系，一次flush会在一个列族里生成一个store file。所以memstore越大，产生大store file的机会也就越多。put不均匀时，有的列族里会有比较多的长度较小的store file，但是文件多了会触发compact。小文件compact很快，所以不用担心。

store file
------------------------------------------------
|block                      |
|----------------------------------------------|
|block                      |
...
|  meta                   |
|---------------------------------------------|
|block索引，以及一些key范围信息|
|---------------------------------------------|
|布隆过滤                |
-----------------------------------------------

可以粗略的认为一个storefile的结构是这样的，尾部的顺序和细节记不太清楚了。一个block包括多个key value，key在文件内是有序的。一条key value记录如下图：

<ignore_js_op>

读数据的时候我会发送一个get请求,在region server内部会转为一个scan。他会到相关列族中去scan storefile。storefile的尾部包含block索引、布隆过滤器、更新时间等所以这可以加快需要scan的文件过滤。所以针对一个store file读是这样的：判断get请求中的row key是否在文件保存的数据范围内；判断get请求中的row key是否能从布龙过滤器中找到(如果过滤器为row-col过滤器还可以判断是否包括需要get的col)；判断get请求中的时间范围是否在文件保存的数据的时间范围中；获取对应的block index；把block加载到block cache中；然后scan block；从多个store file的结果中 get请求中需要包含的version个数，取前几个从而满足get请求中需要包含的version个数。get可以看做特殊的scan操作。

总得blockcache大小是有限的,会有淘汰的.实际上blockcache对于scan来说更合适,因为scan一般是一个范围的扫,block中的row key又是有序的,所以说顺序读会比随机读快。一般hbase比较难适应高并发的随机读，因为blockcache这个设计的本身，就不适合缓存随机的row key：随机读的特点就是读的key均匀散列,这样会使读操作,落在每个block上，导致读的时候每个block先被加载到内存，然后很快因为其他的block持续加载进来而被淘汰出去，然后就这样换来换去，反而更浪费时间。

最后两个比较重要的操作是open和close region。这两个在容灾和均衡中常用。

先说close吧正常close时会先flush memstore 然后通知master close结束。非正常关闭时，就来不及flush了。master会通过zk和region server之间的心跳这两种途径得知regionsever挂掉的情况。

open 一般由master发起。master先找到包含region操作对应的HLog文件，然后挑选出region对应的操作放到region目录中，然后命令某个region server open之。open时先重演HLog中记录的操作，然后再加载region对应的store和store file。

比较重要的原理就是这样的了。原理清楚了的话，再分析起来代码，就能有一个宏观的了解了。

转载于:https://www.cnblogs.com/hubavyn/p/4617508.html

HBase原理解析（转）相关推荐

hbase原理与实践_JAVA连接HBase客户端及HBase写入数据和读取数据原理解析
JAVA连接HBase客户端接着上篇文章进行代码的实践,从JAVA 客户端对 HBase的客户端进行一系列操作工具类:HbaseUtil 静态代码块一次性创建连接对象并赋值返回连接对象 Con ...
HBase原理深入解析（一）----HBase架构总览
前言:掌握Hbase的重要性不言而喻,掌握Hbase的设计原理更是重中之重.本文是对HBase原理进行讲解系列文章的开篇,尽量详细地从整体上介绍HBase的架构,对每个部分的名词进行初步解释,使我们对 ...
hbase原理与实践_HBase 性能调优第一弹：内存篇
这是使用 HBase 最不可避免的一个话题,就是 HBase 的性能调优,而且通常建立在我们对 HBase 内部运行机制比较了解的基础上进行的,因此无论怎么说,调优这块都是一个相对复杂的事情.这一篇我 ...
云HBase内核解析
摘要:在2018年1月25号数据库直播大讲堂上云HBase技术团队郭泽晖带来"云HBase内核"演讲,比如先讲对HBase做了简介,接着云HBase内核解析,并重点介绍了GC优化和 ...
《ClickHouse原理解析与应用实践》读书笔记（1）
开始学习<ClickHouse原理解析与应用实践>,写博客作读书笔记. 本文全部内容都来自于书中内容,个人提炼. 前言和推荐略过第1章 ClickHouse的前世今生跟ck没多大关系 ...
【Hadoop】HDFS操作、数据上传与下载原理解析、高级特性及底层原理
HDFS操作.数据上传与下载原理解析.高级特性及底层原理 1 HDFS操作 1.1 Web Console网页工具 1.2 命令行 1.2.1 普通的操作命令 1.2.2 管理员命令 1.3 Java ...
ClickHouse原理解析与应用实践--摘录
一.ClickHouse的核心特性 1. 完备的DBMS功能 ClickHouse拥有完备的管理功能,所以它称得上是一个DBMS ( Database Management System,数据库管理系 ...
布隆过滤器（Bloom Filter）原理解析
概述布隆过滤器(Bloom Filter)是布隆在1970年提出的,它可以用来检索一个元素是否在一个集合中.实际上布隆过滤器通过一个二进制向量和一系列随机哈希函数完成元素检索,其优点在于比一般的算法 ...
Spark Shuffle原理解析
Spark Shuffle原理解析一:到底什么是Shuffle? Shuffle中文翻译为"洗牌",需要Shuffle的关键性原因是某种具有共同特征的数据需要最终汇聚到一个计算节 ...

HBase原理解析（转）

HBase原理解析（转）相关推荐

最新文章

热门文章