hbase

一.如何去学习一个组件、服务、框架？

分3步走：

1.一张图：描述数据在这个组件里是如何流动的

2.它的api：描述外界开发人员是如何与它进行交互的

3.配置文件：描述如何与其他组件进行集成、如何调优、理解属性含义。

二. 学习Hbase

1.hbase的一张图：

ØZookeeper

Zookeeper中记录了-ROOT-表的location。

Ø-ROOT-

表包含.META.表所在的region列表，该表只会有一个Region；

Ø.META.

表包含所有的用户空间region列表，以及RegionServer的服务器地址。

Ø-ROOT-和.META.表结构是相同的：rowkey+info+history info

Øinfo里面包含三个Column：regioninfo, server, serverstartcode。

regioninfo就是Region的详细信息，包括StartKey, EndKey 以及每个Family的信息等等。

server存储的就是管理这个Region的RegionServer的地址。

一般新建一个hbase表时，region数如果没有事前使用hbase shell来明示定义的话，算上系统的region数，一般只有3个：

1. hbase:meta

2. hbase:namespace

3. userRegion

因为默认的region大小是10G，一般小型的环境下，数据量很难快速达到数据分裂的阈值。

2. 文字解读数据的是如何一步步被存储到hdfs的hfile上的？

假设在默认namespace新建一个hbase表tableA，有列簇cf1,cf2，列id,name,age 属于cf1，同时默认在一个节点上建立一个region叫region1,需要向其写入值：id:1-20 ,name:name1-name20,age:30-50，

hbaseclient->zookeeper->ROOT表-META表（包含所有的用户空间region信息(列表)，以及RegionServer的服务器地址。等 第一次读过来然后缓存到本地)--->HMaster-->HregionServer1--->Hregion1--->region1--->cf1_store,cf2_store-->memStore-->storeFile1,storeFile2,storeFile3.......storeFileN---->StoreFile1_2,storeFile3....storeFileN(将storeFile1,storeFile2合并为               StoreFile1_2)----------------->split region

    (hfile1,hfile2,hfile3......hfileN)-------------------------->HFile1_2,HFile3.....HFileN

（块由block数据(hfile)+block index+version信息组成，1个块存放一个hfile）

最终一个region中，有多少个列簇就有多少个store，有多少个块就有多少个hfile，1个store可以有1个或者多个块（hfile/storeFile）

从上也可以看出hbase的存储是不需要指定分区的（倒是可以指定region的个数，这里的一个region就相当于一个分区），它存储时小文件过多会自动合并，region对应的hfile总大小超过阀值时会自动分裂，查询会根据块索引，且查询速度非常快。

分步详解：

HMaster-->HregionServer1：

HMaster会根据在META表中所得region信息以及RegionServer的服务器地址，向HregionServer1发起请求，希望HregionServer1给他已经在建表时建立的那个region的实际地址

HregionServer1--->Hregion1--->region1：

HregionServer1在众多的Hregion对象中找到了相关的对象Hregion1，Hregion1管理着相关的那个region地址，就是region1

region1--->cf1_store,cf2_store:

hbase连接找到这个region1后,Region检查数据是否与schema一致,如果客户端没有指定版本，则获取当前系统时间作为数据版本,将更新写入WAL log,将更新写入Memstore，在region1中存储数据时，会把同一个cf的列放到同一个store，这里会将id,name,age的值都放到cf1_store里面,当系统出现意外时，可能导致内存（MemStore）中的数据丢失，此时使用Log（WAL log）来恢复检查点之后的数据.

cf1_store,cf2_store-->memStore-->storeFile1,storeFile2,storeFile3.......storeFileN：

数据在cf1_store里面分为两步走，先将所有列的数据一行一行地往memStore（内存缓冲区）放数据，等memStore满了以后，

就会创建一个新的MemStore，并且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。于此同时，系统会在Zookeeper中记录一个redo point，表示这个时刻之前的变更已经持久化了。

当系统出现意外时，可能导致内存（MemStore）中的数据丢失，此时使用Log（WAL log）来恢复检查点之后的数据。

多次溢出就出现了storeFile1,storeFile2,storeFile3.......storeFileN 多个文件。StoreFile是只读的，一旦创建后就不可以再修改。因此HBase的更新其实是不断追加的操作

storeFile1,storeFile2,storeFile3.......storeFileN(每一个storeFile都包含该列簇所有的列)---->StoreFile1_2,storeFile3....storeFileN：

为了防止hfile（storeFile）越来越多，hbase的管家机制会将多个文件合并为1个文件，合并的方式有两种：minor和major压缩合并，但是也是要到了一定数量（或者一定总大小byte）的小文件才会合并，如果小文件数量(总大小)没到这个阀值是不会触发合并的，即一般情况下最终一个store还是会有多个hfile，但不会过多.特殊情况下可以只有1个。

maxStoreFile----------------->split region

当region内的所有storeFiles（包括cf1_store的maxHFile,cf2_store的maxHFile.......）之和的大小超过阀值

设定的值时，会将当前region1 分为：region1_1,region1_2 ，这两个region 都包含cf1的所有列，只是数据被均分成了两部分而已，且还是在之前那个节点上，但是可能会被分配给不同的HRegionServer管理也可能会被分配给相同的HRegionServer管理。

上图表示，某tableA,当前已经被split为了6个region，其中每两个region被一个HRegionServer管理

 

存储目录结构：hdfs dfs -ls /hbase/data/default/tableName/regionName/regionInfo、cf1、cf2....

cf1/hfile1、hfile2、hfile3..........................

例如：

[greesj2b@slave8 ~]$ hdfs dfs -ls /hbase/data/default/realTimeHPPro_autoDiagnostic/b475568146a9eb0c383a1d117e993e7b/cf1
Found 7 items
-rw-r--r--   3 hbase supergroup      81689 2018-09-11 21:34 /hbase/data/default/realTimeHPPro_autoDiagnostic/b475568146a9eb0c383a1d117e993e7b/cf1/2071d7beb9f64c989fa9112624534b1c
-rw-r--r--   3 hbase supergroup      15072 2018-09-11 20:30 /hbase/data/default/realTimeHPPro_autoDiagnostic/b475568146a9eb0c383a1d117e993e7b/cf1/4a096dd6cea44d5fa43bab1f1b920f95
-rw-r--r--   3 hbase supergroup      26455 2018-09-11 22:32 /hbase/data/default/realTimeHPPro_autoDiagnostic/b475568146a9eb0c383a1d117e993e7b/cf1/4c7dd0dbbd314bae96710a5f6547fd46
-rw-r--r--   3 hbase supergroup      69856 2018-09-11 18:17 /hbase/data/default/realTimeHPPro_autoDiagnostic/b475568146a9eb0c383a1d117e993e7b/cf1/73a93b86034249d7adc719f66dc56d00
-rw-r--r--   3 hbase supergroup      48422 2018-09-11 19:24 /hbase/data/default/realTimeHPPro_autoDiagnostic/b475568146a9eb0c383a1d117e993e7b/cf1/ae1834182f6649979d56225819eded44
-rw-r--r--   3 hbase supergroup      58480 2018-09-11 10:52 /hbase/data/default/realTimeHPPro_autoDiagnostic/b475568146a9eb0c383a1d117e993e7b/cf1/daa6755728ca4c39a30e9c6351504545
-rw-r--r--   3 hbase supergroup      26051 2018-09-11 09:53 /hbase/data/default/realTimeHPPro_autoDiagnostic/b475568146a9eb0c383a1d117e993e7b/cf1/e5a5b21569ab4992bef1fb69861fc3d8

3.hbase的API

读API

scan，get，scanFilter，sc.newAPIHadoopRDD

由于对表的更新是不断追加的，处理读请求时， 需要访问Store中全部的StoreFile和MemStore，将他们的按照行键进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，合并的过程还是比较快。

读取速度快是因为它使用了LSM树型结构，而不是B或B+树。磁盘的顺序读取速度很快，但是相比而言，寻找磁道的速度就要慢很多。HBase的存储结构导致它需要磁盘寻道时间在可预测范围内，并且读取与所要查询的rowkey连续的任意数量的记录都不会引发额外的寻道开销。比如有5个存储文件，那么最多需要5次磁盘寻道就可以。而关系型数据库，即使有索引，也无法确定磁盘寻道次数。而且，HBase读取首先会在缓存（BlockCache）中查找，它采用了LRU（最近最少使用算法），如果缓存中没找到，会从内存中的MemStore中查找，只有这两个地方都找不到时，才会加载HFile中的内容，而上文也提到了读取HFile速度也会很快，因为节省了寻道开销。且 他是按key-value 存储到hfile中的。

实时查询，可以认为是从内存中查询，一般响应时间在1秒内。HBase的机制是数据先写入到内存中，当数据量达到一定的量（如128M），再写入磁盘中， 在内存中，是不进行数据的更新或合并操作的，只增加数据，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能

写API

table.put(put)，table.put(seqAsJavaList(partionRecords.toSeq)),table.put(list)

rdd.map(convert).saveAsHadoopDataset(jobConf)，BulkLoad

由于BulkLoad是绕过了Write to WAL，Write to MemStore及Flush to disk的过程，所以并不能通过WAL来进行一些复制数据的操作

优点：1.导入过程不占用Region资源 2.能快速导入海量的数据  3.节省内存

缺点：使用bulk load时 需求将hbase/lib/* 包，在 hadoop-env.sh中添加:

export HADOOP_CLASSPATH=/opt/cloudera/parcels/CDH/lib/hbase 包所在位置。

具体见相关项目代码

4.hbase配置文件

hbase-site.xml，hbase-env.sh

可参考：https://www.cnblogs.com/nexiyi/p/hbase_config_94.html

需要注意的是配置参数生效的优先级：
hconf.set(key,value)>hbase-site.xml，hbase-env.sh,default.conf

 

三、Region分配

任何时刻，一个Region只能分配给一个Region Server。Master记录了当前有哪些可用的Region Server、当前哪些Region分配给了哪些Region Server以及哪些Region还没有分配。

当存在未分配的Region，并且有一个Region Server上有可用空间时，Master就给这个Region Server发送一个装载请求，把Region分配给这个Region Server。Region Server得到请求后，就开始对此Region提供服务。

四、Region Server上线

Master使用Zookeeper来跟踪 Region Server状态。当某个Region Server启动时，会首先在Zookeeper上的Server目录下建立代表自己的文件，并获得该文件的独占锁。

由于Master订阅了Server 目录上的变更消息，当Server目录下的文件出现新增或删除操作时，Master可以得到来自Zookeeper的实时通知。因此一旦Region Server上线，Master能马上得到消息。

五、Region Server下线

当Region Server下线时，它和Zookeeper的会话断开，Zookeeper而自动释放代表这台Server的文件上的独占锁。而Master不断轮询 Server目录下文件的锁状态。

如果Master发现某个Region Server丢失了它自己的独占锁（或者Master连续几次和Region Server通信都无法成功），Master就尝试去获取代表这个Region Server的读写锁，一旦获取成功，就可以确定以下两种情况必至少发生一种：1、Region Server和Zookeeper之间的网络断开了；2、Region Server挂了。

无论哪种情况，Region Server都无法继续为它的Region提供服务了，此时Master会删除Server目录下代表这台Region Server的文件，并将这台Region Server的Region分配给其它还活着的同志。

如果网络短暂出现问题导致Region Server丢失了它的锁，那么Region Server重新连接到Zookeeper之后，只要代表它的文件还在，它就会不断尝试获取这个文件上的锁，一旦获取到了，就可以继续提供服务。

六、Master上线

Master启动进行以下步骤：

1. 从Zookeeper上获取唯一一个代码Master的锁，用来阻止其它Master成为Master。
2. 扫描Zookeeper上的Server目录，获得当前可用的Region Server列表。
3. 和2中的每个Region Server通信，获得当前已分配的Region和Region Server的对应关系。
4. 扫描.META.region的集合，计算得到当前还未分配的Region，将他们放入待分配Region列表。

七、Master下线

由于Master只维护表和Region的元数据，而不参与表数据I/O的过程，Master下线仅导致所有元数据的修改被冻结（无法创建删除表，无法修改表的schema，无法进行Region的负 载均衡，无法处理Region上下线，无法进行Region的合并，唯一例外的是Region的split可以正常进行，因为只有region server参与），表的数据读写还可以正常进行。因此Master下线短时间内对整个HBase集群没有影响。

从上线过程可以看到，Master保存的信息全是可以冗余信息（都可以从系统其它地方收集到或者计算出来），因此，一般HBase集群中总是有一个master在提供服务，还有一个以上的“Master”在等待时机抢占它的位置。