Hbase面试的那些问题

找了一些hbase的面试题，在此汇总一下：

1：什么是HBase：

从最基本的含义说起，hbase就是一个分布式的NoSql数据库，其建立在HDFS分布式文件存储系统的基础之上，HBase的搭建需要依赖于HDFS，从其配置文件就可以看出，其数据存储的底层，也是依赖于Hbase；定义没什么可说的，就是一种建立在HDFS基础之上的分布式数据库：

2：聊一聊MySQL和Hbase的区别

这个问题太泛泛，简单说几点：

MySQL是关系数据库，而HBase是非关系数据库
MySQL，就一张表来说，构建完毕之后，其基本结构不能再改变，其只能存储结构化的数据；而HBase的核心概念是列族，其可以管理很多很多的列，这一点比起MySQL要灵活的多
就容量来说，MySQL并不是天生支持分布式的，所以其存储空间容易受到机器限制，而HBase则不同，依靠于HDFS分布式文件系统，其存储容量可以达到无限大
就Null来说，Hbase是不会存储Null值的，而对于MySQL而言，必须要为空值分配存储空间
HBASE是Master/slave架构，启动之后我们可以看到，其存在HMaster和HRegionServer进程
Hbase必须依托于zookeeper来管理器元数据，而MySQL，当然不需要

3：说一说Hbase和Hive

这两个东西更是扯远了，但也可以聊一聊：

本质来说，Hive实质上是MapReduce作业的作业流，减少了MapReduce作业的开发成本，通过把数据映射成为hive中的表结构，可以轻松地通过类SQL语言，即HQL来完成查询作业，开发成本较低，深受大家欢迎

而Hbase本质上只是数据库而已，其执行过程，完全没有MapReduce作业，不然，hbase的速度得慢成什么样子：

就操作而言，Hive只能查询数据，而无法更新数据，这也是MapReduce作业的特点，只能对固有的数据进行分析；而Hbase则是可以对数据进行更新的，查阅相关API就可以知道：

通常，我们使用Hive来对一段时间内的数据进行分析和汇总，提交作业之后，如果是在Yarn上提交的，可以看到Yarn集群上在运行MapReduce作业

而Hbase则是我们为了交互而设计的，其响应速度比Hive快很多很多：

当然，提一句，现在的Hive可以依靠于Spark作为作业流引擎，速度要快一些：

4：谈一谈重点，那就是RowKey

当然，第一，Rowkey的唯一性，对于Hbase的数据来说，RowKey就是数据的唯一标识符，只有通过RowKey才能查询到一条数据，相同Rowkey的数据则会相互覆盖：

默认来说，Hbase的key是按照字典序来排序的：这在我们的使用中会出现一种问题，比如说，我们的业务频繁地查询最近的数据，毫无疑问，如果以时间戳作为RowKey的话，数据查询会一窝蜂地涌向很少的Region，这就会导致热点问题：

注意，热点问题并不是由于Hbase的设计不合理，而是由于业务的特殊性，需要我们对于RowKey的设计提出一定的要求：

一般来说，我们可以通过加盐的方式，高位设置循环递增的数字或者是UUID字符串，而低位是时间戳或者其他字符串，这样的话，数据就会按照字典序均衡划分到多个Region，从而减少局部热点压力：

同样，我们也可以通过哈希的方式，制造出随机的效果，把数据分布到不同的Region上去：

这里说一下一个面试中问到的有意思的问题：如何快速查询到最近时间段内的数据?

这个问题很有意思，我们可以用Integer.MAX_VALUE减去当前的时间戳，制造出翻转的效果，从而实现快速查询最近版本数据的功能；

5：Hbase的基本架构

6：Hbase搭建过程的一个小问题

hbase默认会自带有zookeeper，而通常来说，我们不推荐使用其自带的zookeeper，而是使用已经搭建好的zookeeper集群，而这带来的问题则是：

HBASE停止的时候会自动关闭zookeeper，所以我们需要在配置文件中指定：

HBASE_MANAGES_ZK=false

这样，即便是Hbase服务停止，也不会影响zookeeper服务的正常运行：

7：JavaAPI如何操作Hbase：

不多说了，简单说下原理吧，其通过连接的zookeeper集群，去获取相应的元数据，然后通过获取到的元数据，去对应的RegionServer去获取真实的数据：

对于客户端来说，其先与zookeeper打交道，然后与HMaster打交道，最后获取数据的时候，则是与HRegionServer打交道，获取真实的数据：

本文随时更新：