Hbase框架介绍

HBase是一个分布式的、面向列的开源数据库。

不同点：

l 和一般的关系数据库不同，hbase是一个适合于非结构化数据存储的数据库。

l Hbase是基于列而不是基于行的模式。

在分布式的生产环境中，HBase 需要运行在 HDFS 之上，以 HDFS 作为其基础的存储设施。HBase上层提供了访问的数据的 Java API 层，供应用访问存储在 HBase 的数据。在 HBase 的集群中主要由 Master 和 Region Server 组成，以及 Zookeeper，具体模块如下图所示：

Hbase表的逻辑视图

基本概念：

l RowKey

是Byte array，是表中每条记录的“主键”，方便快速查找，Rowkey的设计非常重要；

l Timestamp

版本号，类型为Long，默认值是系统时间戳，可由用户自定义

l ColumnFamily

列族，拥有一个名称(string)，包含一个或者多个相关列

l Column

属于某一个columnfamily，familyName:columnName，每条记录可动态添加

l Value(Cell)

单元格由行键、列族、时间戳唯一决定

单元格的数据是没有类型的，全部以字节码形式存储

Hbase组成

示意图

l Master

Hmaster用于调整多个regionServer，侦测各个regionServer之间的状态，并平衡regionServer之间的负载。Hmaster还有一个职责就是分配region给regionServer。

Hmaster允许多个Hmaster节点共存，但是这需要Zookeeper的协助。不过当多个Hmaster节点共存时，只有一个Hmaster是提供服务的，其它的Hmaster节点处于待命的状态。当正在工作的Hmaster节点宕机时，其它的Hmaster则会接管Hbase集群。

l RegionServer

对于一个regionServer而言，其包括了多个region。regionServer的作用只是管理表格，以及实现读写操作。Client直接连接regionServer，并通信获取Hbase中的数据。

l Region

Region是hbase中分布式存储和负载均衡的最小单位，但不是最小的存储单元。如个一个表格很大，并由多个CF组成时，那个表的数据将存放在多个region中，并且每个region会关联多个存储单元store。表在行方向分割为多个region，region是按大小分割的，随着region不断增大，当增大到一个阀值的时候，region就会分成两个region。

l Store

每个region中包含了多个store对象，一个store包含一个memstore和若干个storefile，storefile中包含一个或多个hfile。Memstore存放在内存中，storefile存放在hdfs上。

l Hfile

Hfile由很多个数据块(block)组成，并且有一个固定的结尾块。其中的数据块是由一个header和多个key-value的键值对组成。在结尾块中包含了数据相关的索引信息，系统也是通过结尾块的索引信息找到hfile中的数据。

Hbase读写流程

写数据

Hbase使用memstore和storefile存储对表的更新。数据在更新时首先写入hlog和memstore，memstore中的数据是排序的，当memstore累计到一定的阀值时，就会创建一个新的memstore，并将老的memstore添加到flush队列，由单独的线程flush到磁盘上，成为一个filestore。与此同时，系统会在zookeeper中记录一个checkpoint，表示这个时刻之前的数据变更已经持久化了。当系统出现意外时，可能导致memstore中的数据丢失，此时使用hlog来恢复checkpoint之后的数据。

Storefile是只读的，一旦创建之后就不可修改。因此hbase的更新就是不断追加的操作。当一个store的storefile达到一定的阀值后，就会进行一次合并操作，将对同一个key的修改合并到一起，同时进行版本合并和数据删除，形成一个大的storefile。当storefile的大小达到一定的阀值后，又会对storefile进行切分操作，等分为两个storefile。

Hbase中只有增添数据，所有的更新和删除操作都是在后续的合并中进行的，使得用户的写操作只要进入内存就可以立刻返回，实现了hbase的高速存储。

(1) Client通过Zookeeper的调度，向RegionServer发出写数据请求，在Region中写数据。
(2) 数据被写入Region的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的所有region元数据被存储在.META表中，随着region的增多，.META表中的数据也会增大，并分裂成多个新的region。为了定位.META表中各个region的位置，把.META表中的所有region的元数据保存在-ROOT-表中，最后由zookeeper记录-ROOT-表的位置信息。所有的客户端访问数据之前，需要首先访问zookeeper获取-ROOT-的位置，然后访问-ROOT-表获得.META表的位置，最后根据.META表中的信息确定用户数据存放的位置。

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

client–>Zookeeper–>-ROOT-表–>.META.表–>RegionServer–>Region–>client

(1) Client访问Zookeeper，查找-ROOT-表，获取.META.表信息。
(2) 从.META.表查找，获取存放目标数据的Region信息，从而找到对应的RegionServer。
(3) 通过RegionServer获取需要查找的数据。
(4) Regionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。

高可用性

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

我们理解下HLog的作用。HBase中的HLog机制是WAL的一种实现，而WAL（一般翻译为预写日志）是事务机制中常见的一致性的实现方式。每个RegionServer中都会有一个HLog的实例，RegionServer会将更新操作（如 Put，Delete）先记录到 WAL（也就是HLog）中，然后将其写入到Store的MemStore，最终MemStore会将数据写入到持久化的HFile中（MemStore 到达配置的内存阀值）。这样就保证了HBase的写的可靠性。如果没有 WAL，当RegionServer宕掉的时候，MemStore 还没有写入到HFile，或者StoreFile还没有保存，数据就会丢失。或许有的读者会担心HFile本身会不会丢失，这是由 HDFS 来保证的。在HDFS中的数据默认会有3份。因此这里并不考虑 HFile 本身的可靠性。

组件高可用

Master容错：Zookeeper重新选择一个新的Master。如果无Master过程中，数据读取仍照常进行，但是，region切分、负载均衡等无法进行；
RegionServer容错：定时向Zookeeper汇报心跳，如果一旦时间内未出现心跳，Master将该RegionServer上的Region重新分配到其他RegionServer上，失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer；
Zookeeper容错：Zookeeper是一个可靠地服务，一般配置3或5个