hbase数据原理及基本架构

第一：hbase介绍

hbase是一个构建在hdfs上的分布式列存储系统；

hbase是apache hadoop生态系统中的重要一员，主要用于海量结构化数据存储

从逻辑上讲，hbase将数据按照表、行和列进行存储

hbase表特色：

　　1.大：一个表能够有数十亿行，上百万列；

　　2.无模式：每行都有一个可排序的主键和任意多的列，列能够根据须要动态的增长，同一张表中不一样的行能够有大相径庭的列；

　　3.面向列：面向列（族）的存储和权限控制，列（族）独立检索；

　　4.稀疏：对于空（null）的列，并不占用存储空间，表能够设计的很是稀疏；

　　5.数据多版本：每一个单元中的数据能够有多个版本，默认状况下版本号自动分配，是单元格插入时的时间戳；

　　6.数据类型单一：hbase中的数据都是字符串，没有类型

hbase与hdfs的对比：

　　1.二者都具备良好的容错性和扩展性，均可以扩展到成百上千个节点。

　　2.hdfs适合批处理场景,不支持数据随机查找，不适合增量数据处理，不支持数据更新。

行存储与列存储：

　　传统行式数据库：

　　　　1.数据是按行存储的

　　　　2.没有索引的查询使用大量I/O

　　　　3.创建索引和物化视图须要花费大量时间和资源

　　　　4.面向查询的需求，数据库必须被大量膨胀才能知足性能要求

　　列式数据库:

　　　　1.数据是按列存储-每一列单独存放

　　　　2.数据便是索引

　　　　3.指访问查询涉及的列-大量下降系统I/O

　　　　4.每一列由一个线索来处理-查询的并发处理

　　　　5.数据类型一致，数据特征类似-高效压缩

第二：hbase数据模型

hbase是基于Google BigTable模型开发的，典型的key/value系统

 

hbase数据模型术语：

Table（表）

一个hbase包含多个行，是在schema声明的时候定义的

Row（行）

行键是不可分割的字节数组。行是按字典排序由低到高存储在表中的。一个空的数组是用来标识表空间的起始或者结尾。

Row Key 

　　1）Byte array

　　2）表中每条记录的“主键”

　　3）方便快速查找  

Column Family

　　1）拥有一个名称（string）

　　2）包含一个或者多个相关的列，是一些列的集合

　　3）一个列簇全部列成员具备相同的前缀

Column 

　　1）属于某一个column family

　　2）包含在某一列中

Cell（value）

　　1）A {row, column, version} 元组就是一个HBase中的一个 cell。

　　2）Cell的内容是不可分割的字节数组。

　　3）能够为空

Timestamp（时间戳）

 version number（版本号）

　　1）每一个rowkey惟一

　　2）默认值-----》 系统时间戳

　　3）类型为Long 

　　4）无需递增插入

 数据模型操做

1. 全部操做均是基于rowkey的；

2. 支持CRUD（Create、Read、Update和Delete）和 Scan；

3. 单行操做 Put Get Scan

　多行操做 Scan MultiPut

4. 没有内置join操做，可以使用MapReduce解决

第三：hbase物理模型

每一个column family存储在HDFS上的一个单独文件中；

Key和Version number在每一个column family中均有一份

空值不被保存

eg:

 info Column Family:

 

roles Column Family

数据物理存储：

1.Table中全部的行都按照row key的字典序列排列；

2.Table在行的方向上被分割为多个Region；

 

3.Region按照大小分割的，每一个表开始只有一个region，随着数据的增多，region不断的增大，当增大到一个阀值的时候，region就会等分红两个新的region，以后会有愈来愈多的region；

4.Region是Hbase中分布式存储和负载均衡的最小单元，不一样的region分布在不一样RegionServer上；

5.Region虽然是分布式存储的最小单元，但并非存储的最小单元。

　　1）Region是由一个或者多个Store组成，每一个store保存一个columns family；

　　2）每一个Store又由一个memStore和0或多个StoreFile组成

　　3）memStore存储在内存中，StoreFile存储在HDFS上。

第四：hbase基础架构

Hbase架构：

在分布式的生产环境中，HBase 须要运行在 HDFS 之上，以 HDFS 做为其基础的存储设施。在 HBase 的集群中主要由 Master 和 Region Server 组成，以及 Zookeeper

Hbase相关的组件：

Clinet：

　　包含访问Hbase的接口，并维护cache来加快对Hbase的访问。

zookeeper:

　　保证任什么时候候，集群中只有一个master

　　存储全部Region的寻址入口

　　实时监控Region Server的上线或者下线信息，并实时通知给Master

　　存储HBase的schema和table元数据

　　zookeeper做用：

　　　　HBase依赖zk；

　　　　默认状况下Hbase管理zk实例，eg：启动或者中止zk

　　　　Master与RegionServers启动时会向zk注册

　　　　Zookeeper的引入使得Master不在是单点故障

Master:

　　为Region Server分配region

　　负责Region Server的负载均衡

　　发现失效的Region Server并从新分配他上面的region

　　管理用户对table的增删改查操做

Region Server:

　　维护region，处理对这些region的IO请求

　　负责切分在运行过程当中变得过大的region

 -ROOT-表与-META-表：

-ROOT-表：

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

　　zookeeper中记录了-ROOT-表的位置

-META-表：

　　包含全部的用户空间region列表，以及RegionServer的服务器地址

详解：

1.HBase的全部Region元数据被存储在.META.表中，随着Region的增多，.META.表中的数据也会增大，并分裂成多个新的Region。为了定位.META.表中各个Region的位置，把.META.表中全部Region的元数据保存在-ROOT-表中，最后由Zookeeper记录-ROOT-表的位置信息。全部客户端访问用户数据前，须要首先访问Zookeeper得到-ROOT-的位置，而后访问-ROOT-表得到.META.表的位置，最后根据.META.表中的信息肯定用户数据存放的位置，如上图所示。

2.-ROOT-表永远不会被分割，它只有一个Region，这样能够保证最多只须要三次跳转就能够定位任意一个Region。为了加快访问速度，.META.表的全部Region所有保存在内存中。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。若是客户端根据缓存信息还访问不到数据，则询问相关.META.表的Region服务器，试图获取数据的位置，若是仍是失败，则询问-ROOT-表相关的.META.表在哪里。最后，若是前面的信息所有失效，则经过ZooKeeper从新定位Region的信息。因此若是客户端上的缓存所有是失效，则须要进行6次网络来回，才能定位到正确的Region。

高可用

Write-Ahead-Log（WAL）保障数据高可用

理解高可用首先：必须理解下HLog的做用，HBase中的Hlog机制是WAL的一种实现，而WAL是事务机制中常见的一致性的实现方式。每一个RegionServer中都会有一个HLog的实例，RegionServer会将更新操做（put，delete等），先记录到WAL（也就是HLog中），而后再将其写入到Store的MemStore，最终Memstore达到必定的阀值后，在写入到HFile中，这样就保证了HBase的写的可靠性，若没有WAL，当RegionServer挂掉的时候，MemStore尚未写到HFile的数据，或者说StoreFile没有保存的时候，数据会丢失。（说到这里或许有人会问，假如HFile自己丢失了怎么办，这是由HDFS来保证的。在HDFS中的数据默认会有3份）

HFile是由不少个数据块（Block）组成，而且有一个固定的结尾块，其中的数据块是由一个Header和多个Key-Value的键值对组成，在结尾的数据块中包含了数据相关的索引信息，系统也是经过结尾的索引信息找到HFile中的数据。

上图是RegionServer数据存储关系图。上文提到，HBase使用MemStore和StoreFile存储对表的更新。数据在更新时首先写入HLog和MemStore。MemStore中的数据是排序的，当MemStore累计到必定阈值时，就会建立一个新的MemStore，而且将老的MemStore添加到Flush队列，由单独的线程Flush到磁盘上，成为一个StoreFile。与此同时，系统会在Zookeeper中记录一个CheckPoint，表示这个时刻以前的数据变动已经持久化了。当系统出现意外时，可能致使MemStore中的数据丢失，此时使用HLog来恢复CheckPoint以后的数据。
StoreFile是只读的，一旦建立后就不能够再修改。所以Hbase的更新实际上是不断追加的操做。当一个Store中的StoreFile达到必定阈值后，就会进行一次合并操做,将对同一个key的修改合并到一块儿，造成一个大的StoreFile。当StoreFile的大小达到必定阈值后，又会对 StoreFile进行切分操做，等分为两个StoreFile。

详解

组件的高可用

Master容错：Zookeeper从新选择一个新的Master

　　无Master过程当中，数据读取任然照常进行

　　无Master过程当中，region切分、负载均衡等没法进行

RegionServer容错：

　　定时向Zookeeper汇报心跳，若是一旦一段时间内未出现心跳，Master将该RegionServer上的Region从新分配到其余的RegionServer上；

　　失效的服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer上

zookeeper容错：zookeeper是一个可靠的服务

　　通常是3到5个zookeeper实例

读写流程

　　写操做：

　　　　1）client经过zookeeper的调度，向regionserver发出写数据的请求，在Region中写数据

　　　　2）数据首先记录在HLog中，而后再将其写入到Store的MemStore，直到MemStore达到预约阀值

　　　　3）MemStore中的数据被Flush成一个StoreFile

　　　　4）随着StoreFile文件的不断增多，当其数据增加到必定阀值后，触发Compact合并操做，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除

　　　　5）StoreFiles经过不断的Compact合并操做，逐步造成愈来愈大的StoreFile

　　　　6）单个StoreFile大小超过必定阀值后，触发Split操做，把当前Region Split成2个新的Region，父Region会下线，新Split出的2个子Region会被HMaster分配到相应的RegionServer上，使原先1个Region的压力得以分流到2个Region上面

　　经过上述的写流程能够发现，HBase更新、删除等操做都是在后续Compact历程中进行的，使得用户的写操做只要进入内存就能够马上返回，实现可HBase I/0的高性能。

　　读操做：

　　　　1）client访问zk，查找-ROOT-表，获取.META.表的信息。

　　　　2）从.META.表查找，获取存放目标数据的Region信息，从而找到对应的RegionServer。

　　　　3）经过RegionServer获取须要查找的数据

　　　　4）RegionServer的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据，读请求先到MemStore中查数据，查不到就到BlockCache中查，在查不到就会到StoreFile上读，并把读的结果放入BlockCache中。

　　读取流程：client-->zookeeper-->-ROOT-表-->.META.表-->RegionServer-->Region-->client