干货分享 | HBase底层存储结构，HBase快速读取，Hadoop的高可用和zk作用

       最近看了好多粉丝的面试题，于是总结出关于HBase相关的面试题，今天分享给大家，认真阅读，记得收藏。

一、讲一下 Hbase 架构

Hbase主要包含HMaster/HRegionServer/Zookeeper

Client：

访问数据的入口，包含访问hbase的API接口,维护着一些cache来加快对hbase的访问

Zookeeper：

1.zookeeper的选举机制保证任何时候，集群中只有一个master

2.实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master

3.存储Hbase的schema

4.存贮所有Region的寻址入口

Master：

1.为Region server分配region

2.负责region server的负载均衡

3.发现失效的region server并重新分配其上的region

4.处理schema（元数据）更新请求

说明：Hmaster短时间下线，hbase集群依然可用，长时间不行。

Region server：

1.Region server维护Master分配给它的region，处理对这些region的IO请求

2.Region server负责切分在运行过程中变得过大的region

二、hbase 如何设计rowkey

• RowKey长度原则

  Rowkey是一个二进制码流，Rowkey的长度被很多开发者建议说设计在10~100个字节，不过建议是越短越好，不要超过16个字节。

  原因如下：

• 数据的持久化文件HFile中是按照KeyValue存储的，如果Rowkey过长比如100个字节，1000万列数据光Rowkey就要占用100*1000万=10亿个字节，将近1G数据，这会极大影响HFile的存储效率；

• MemStore将缓存部分数据到内存，如果Rowkey字段过长内存的有效利用率会降低，系统将无法缓存更多的数据，这会降低检索效率。因此Rowkey的字节长度越短越好。

• 目前操作系统是都是64位系统，内存8字节对齐。控制在16个字节，8字节的整数倍利用操作系统的最佳特性。

• RowKey散列原则

  如果Rowkey是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位作为散列字段，由程序循环生成，低位放时间字段，这样将提高数据均衡分布在每个Regionserver实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息将产生所有新数据都在一个RegionServer上堆积的热点现象，这样在做数据检索的时候负载将会集中在个别RegionServer，降低查询效率。

• RowKey唯一原则

  必须在设计上保证其唯一性。

三、讲一下hbase的存储结构,这样的存储结构有什么优缺点

Hbase的优点及应用场景:

1. 半结构化或非结构化数据: 对于数据结构字段不够确定或杂乱无章非常难按一个概念去进行抽取的数据适合用HBase，因为HBase支持动态添加列。

2. 记录很稀疏：RDBMS的行有多少列是固定的。为null的列浪费了存储空间。HBase为null的Column不会被存储，这样既节省了空间又提高了读性能。

3. 多版本号数据：依据Row key和Column key定位到的Value能够有随意数量的版本号值，因此对于须要存储变动历史记录的数据，用HBase是很方便的。比方某个用户的Address变更，用户的Address变更记录也许也是具有研究意义的。

4. 仅要求最终一致性：对于数据存储事务的要求不像金融行业和财务系统这么高，只要保证最终一致性就行。（比如HBase+elasticsearch时，可能出现数据不一致）

5. 高可用和海量数据以及很大的瞬间写入量：WAL解决高可用，支持PB级数据，put性能高 适用于插入比查询操作更频繁的情况。比如，对于历史记录表和日志文件。（HBase的写操作更加高效）

6. 业务场景简单：不需要太多的关系型数据库特性，列入交叉列，交叉表，事务，连接等。

Hbase的缺点：

1. 单一RowKey固有的局限性决定了它不可能有效地支持多条件查询

2. 不适合于大范围扫描查询

3. 不直接支持 SQL 的语句查询

四、flush机制

全局的memstore的flush机制默认为堆总大小（多个memstore 多个region）的40%，超过该大小会触发flush到磁盘的操作，会阻塞客户端读写，flush将所有的memstore全部flush。

单个的memstore默认为数据达到128M或1h或者数据为堆大小 0.95倍将会flush. memstore默认将会先提前flush 5M.(先flush一小部分，等后面数据达到阈值在flush后 面的数据) 这样会比一次flush效率高

hbase

不建议配置过多列族：过多的列族会消耗大量的内存，同时数据在flush时消耗磁盘IO. 一个regionserver读写操作可用堆内存的80%，读取占用40% ，写入占用40%。这两个参数直接 影响hbase读写性能。

五、HMaster宕机的时候,哪些操作还能正常工作

对表内数据的增删查改是可以正常进行的,因为hbase client 访问数据只需要通过 zookeeper 来找到 rowkey 的具体 region 位置即可. 但是对于创建表/删除表等的操作就无法进行了,因为这时候是需要HMaster介入, 并且region的拆分,合并,迁移等操作也都无法进行了

六、讲一下hbase的写数据的流程

1. Client先访问zookeeper，从.META.表获取相应region信息，然后从meta表获取相应region信息

2. 根据namespace、表名和rowkey根据meta表的数据找到写入数据对应的region信息

3. 找到对应的regionserver 把数据先写到WAL中，即HLog，然后写到MemStore上

4. MemStore达到设置的阈值后则把数据刷成一个磁盘上的StoreFile文件。

5. 当多个StoreFile文件达到一定的大小后(这个可以称之为小合并，合并数据可以进行设置，必须大于等于2，小于10——hbase.hstore.compaction.max和hbase.hstore.compactionThreshold，默认为10和3)，会触发Compact合并操作，合并为一个StoreFile，（这里同时进行版本的合并和数据删除。）

6. 当Storefile大小超过一定阈值后，会把当前的Region分割为两个（Split）【可称之为大合并，该阈值通过hbase.hregion.max.filesize设置，默认为10G】，并由Hmaster分配到相应的HRegionServer，实现负载均衡

七、讲一下hbase的写数据的流程

1. Client先访问zookeeper，找到Meta表，并获取Meta表元数据。确定当前将要写入的数据所对应的HRegion和 HRegionServer服务器。

2.Client向该HRegionServer服务器发起写入数据请求。

3.Client先把数据写入到HLog，以防止数据丢失，然后将数据写入到Memstore。

4.Memstore达到阈值，会把Memstore中的数据flush到Storefile中

5.当Storefile越来越多，达到一定数量时，会触发Compact合并操作，将多个小文件合并成一个大文件。

6.Storefile越来越大，Region也会越来越大，达到阈值后，会触发Split操作，变成两个文件。

说明：hbasez 支持数据修改（伪修改），实际上是相同rowkey数据的添加。hbase只显示最后一次的添加

八、讲一下hbase读数据的流程

---

meta表是hbase系统自带的一个表。里面存储了hbase用户表的元信息。

元信息为meta表内记录一行数据是用户表一个region的start key 到endkey的范围。

meta表存储在regionserver里。 具体存储在哪个regionserver里？zookeeper知道。

过程:

1.客户端到zookeeper询问meta表在哪

2.客户端到meta所在的节点（regionserver）读取meta表的数据

3.客户端找到region 获取region和regionserver的对应关系，直接到regionserver读取region数据

九、Hbase 和 hive 有什么区别hive 与 hbase 的底层存储是什么？hive是产生的原因是什么？habase是为了弥补hadoop的什么缺陷？共同点：

---

共同点：        

hbase与hive都是架构在hadoop之上的。都是用hadoop作为底层存储

区别：

HIVE

1、Hive是建立在Hadoop之上为了减少MapReducejobs编写工作的批处理系统 

2、Hive本身不存储和计算数据，它完全依赖于HDFS和MapReduce，Hive中的表纯逻辑。

3、hive借用hadoop的MapReduce来完成一些hive中的命令的执行 

4、hive需要用到hdfs存储文件，需要用到MapReduce计算框架

HBASE

1、HBase是为了支持弥补Hadoop对实时操作的缺陷的项目 。

2、想象你在操作RMDB数据库，如果是全表扫描，就用Hive+Hadoop,如果是索引访问，就用HBase+Hadoop 。

3、HBase是非常高效的，肯定比Hive高效的多。

4、hbase是物理表，不是逻辑表，提供一个超大的内存hash表，搜索引擎通过它来存储索引，方便查询操作。

5、hbase是列存储。

6、hdfs作为底层存储，hdfs是存放文件的系统，而Hbase负责组织文件。

十、直接将时间戳作为行健，在写入单个 region 时候会发生热点问题，为什么呢？

         region 中的 rowkey 是有序存储，若时间比较集中。就会存储到一个 region 中，这样一个 region 的数据变多，其它的 region 数据很少，加载数据就会很慢，直到 region 分裂，此问题才会得到缓解。

十一、解释下 hbase 实时查询的原理

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