转载自：HBase基本架构及原理_newchitu的博客-CSDN博客_hbase架构https://blog.csdn.net/newchitu/article/details/87101125

1、HBase框架简单介绍

        HBase是一个分布式的，面向列的开源数据库。它不同于一般的关系数据库,是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。HBase使用和 BigTable非常相同的数据模型。用户存储数据行在一个表里。一个数据行拥有一个可选择的键和任意数量的列，一个或者多个列组成ColumFamily，一个Fammily下的列位于一个HFile中，易于缓存数据。表是稀松存储的，因此用户可以给行定义各种不同的列。在HBase中数据按主键排序，同时表按主键划分为多个Region。

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

        HBase的

简单介绍一下HBase中相关模块的作用： 

•  Master        
   HBase Master用于协调多个Region Server，侦测各个Region Server之间的状态，并平衡Region Server之间的负载。HBase Master还有一个职责就是复杂分配Region给Region Server。HBase允许多个Master结点共存，但这需要zk的帮助。不过当多个Master结点共存时，只有一个Master是提供服务的，其他的Master结点处于待命的状态。当正在工作的Master结点宕机时，zk会选举另一个Master来接管HBase集群。更多参考：HMaster是什么？
• Region Server
  一个Region Server包含多个Region。Region Server的作用只是管理表格，，以及实现读写操作。Client直接连接Region Server，并通信获取HBase中的数据。对于Region而言，则是真实存放HBase数据的地方，也就是说Region是HBase可用性和分布式的基本单位。如果当一个表格很大，并由多个CF组成时，那么表的数据将存放在多个Region之间，并且在每个Region中会关联多个存储单元(Store).
• Zookeeper
  对于 HBase 而言，Zookeeper的作用是至关重要的。首先Zookeeper是作为HBase Master的HA解决方案。也就是说，是Zookeeper保证了至少有一个HBase Master 处于运行状态。并且Zookeeper负责Region和Region Server的注册。其实Zookeeper发展到目前为止，已经成为了分布式大数据框架中容错性的标准框架。不光是HBase，几乎所有的分布式大数据相关的开源框架，都依赖于Zookeeper实现HA。

2、HBase数据模型

2.1 逻辑视图

基本概念：

• RowKey：是Byte array，是表中每条记录的主键，方便快速查找，RowKey的设计非常重要
  
• Column Family： 列簇，拥有一个名称String，包含一个或多个相关列；
• Column：属于某一个ColumFamily，familyName:columnName，每条记录可动态添加；
• Version Nunber：类型为Long，默认是系统时间戳，可由用户自定义；
• Value(cell):Byte array
  

 2.2 物理模型

• 每个column family存储在HDFS上的一个单独文件中，空值不会被保存。
• key和Version number在每个column family中均有一份
• HBase为每个值维护了多级索引：<key,columnfamily,columnname,timestamp>
• 表在行的方向上分割为多个Region
• Region是HBase中分布式存储和负载均衡的最小单元，不同Region分布在不同的Region Server上
• Region按大小分割的，随着数据增多，Region不断增大，当增大到一个阈值的时候，Region就会分成两个新的Region
• Region虽然是分布式存储的最校单元，但并不是存储的最下单元，每个Region包含着都许多哥Store对象。每个Store包含一个MemStore或者若干个StoreFile，StoreFile包含一个或多个HFile。MemStore存放在内存中，StoreFile存储在HDFS上

 疑问：每一个Region都只存储一个ColumnFamily的数据，并且是该CF中的一段（按Row的区间分成多个 Region）？这个需要查证，每个Region只包含一个ColumnFamily可以提高并行性？然而，我只知道每个Store只包含一个ColumnFamily的数据。

2.3 ROOT表和META表

        HBase的所有Region元数据被存储在.META.表中，随着Region的增多，.META.表中的数据也会增大，并分裂成多个新的Region。为了定位.META.表中各个Region的位置，把.META.表中所有Region的元数据保存在-ROOT-表中，最后由zk记录-ROOT-表的位置信息。所有客户端访问用户数据前，需要首先访问zk获得-ROOT-的位置，然后访问-ROOT-表获得.META.的位置，最后根据.META.表中的信息确定用户数据存放的位置，如下图所示

截图出处为下面这个连接，可以查看更多结构hbase 默认目录_查看HBase表在HDFS中的文件结构_weixin_39869378的博客-CSDN博客 

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

一个完整分布式的HBase的组成示意图如下，后面我们再详细谈其工作原理

3、高可用

3.1 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中的数据默认会有三分。因此这里并不考虑HFIile本身的可靠性。

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

3.2 组件高可用

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

4、HBase读写流程

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

4.1 写操作流程

参考：Hbase_Hbase的读写流程&Region管理&Master工作机制__WeiA的博客-CSDN博客

1. RegionServer保存着.META.表以及表数据，要访问表数据，首先Client要先去访问zk，从zk里面获取.META.表所在的位置信息，即找到这个.META.表在那个RegionServer上保存着在哪一个RegionServer上保存着
2. 接着client通过刚才获取的RegionServer上的.META.获取到元数据，访问对应的Region
3. 数据被写入到Region的MemStore，知道MemStore达到预设阈值
4. MemStore中的数据被Flush成一个StoreFile
5. 随着StoreFile文件的不断增多，档期数量增长到一定阈值后，出发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除
6. StoreFiels通过不断Compact合并操作，足部形成越来越大的StoreFile
7. 单个StoreFile大小超过一定阈值后，出发Split操作，把当前Region Split成2个新的Region，父Region会下线，新Split出的2个子Region会被Master分配到相应的RegionServer上，是的原先一个Region的压力得以分流到2个Region上

可以看出HBase只有添加数据，所有的更新和删除操作都是在后续的Compact历程中举行的，使得用户的写操作只要进入内存就可以立刻返回，实现了HBase IO高机能

4.2 读操作流程

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

寻址过程：client-->Zookeeper-->-ROOT-表-->.META.表-->RegionServer-->Region-->client