【2021持续更新】大数据面试题整理-HBase篇

导语

本专栏博文会整理日常工作与面试中最常用到的大数据相关组件与Java语言的架构、概念、知识点，方便大家进行查阅。
涉及到的面试题以及答案均为博主搜罗整理，并加上自己的理解编写而成。同时博主会在部分题目的下方添加管遇此题深入理解的博文连接，方便读者的深入理解。
希望大家可以通过此篇博文对于大数据相关概念有一个更深入的理解
还有哪些想看的面试题，读者可以在评论区补充，博主会在一天内进行更新！！！
最后预祝大家新的一年升职加薪，工资涨涨涨！

基础问题：

Hbase是什么

1. Hbase一个分布式的基于列式存储的数据库,基于Hadoop的hdfs存储，zookeeper进行管理。
2. Hbase适合存储半结构化或非结构化数据，对于数据结构字段不够确定或者杂乱无章很难按一个概念去抽取的数据。
3. Hbase为null的记录不会被存储.
4. 基于的表包含rowkey，时间戳，和列族。新写入数据时，时间戳更新，同时可以查询到以前的版本.
5. hbase是主从架构。hmaster作为主节点，hregionserver作为从节点。

深入阅读：可能是最易懂的Hbase架构原理解析

Hbase和hive的区别

Hbase和Hive在大数据架构中处在不同位置，Hbase主要解决实时数据查询问题，Hive主要解决数据处理和计算问题，一般是配合使用。

Hbase： Hadoop database 的简称，也就是基于Hadoop数据库，是一种NoSQL数据库，主要适用于海量明细数据（十亿、百亿）的随机实时查询，如日志明细、交易清单、轨迹行为等。

Hive：Hive是Hadoop数据仓库，严格来说，不是数据库，主要是让开发人员能够通过SQL来计算和处理HDFS上的结构化数据，适用于离线的批量数据计算。

深入阅读：一篇文章让你了解Hive和HBase的区别

Hbase特点

1. 大：一个表可以有数十亿行，上百万列；
2. 无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一
   张表中不同的行可以有截然不同的列；
3. 面向列：面向列（族）的存储和权限控制，列（族）独立检索；
4. 稀疏：空（null）列并不占用存储空间，表可以设计的非常稀疏；
5. 数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元
   格插入时的时间戳；
6. 数据类型单一：Hbase 中的数据都是字符串，没有类型。

深入阅读：可能是最易懂的Hbase架构原理解析

RowKey的设计原则

1. 唯一性原则
   rowkey在设计上保证其唯一性。rowkey是按照字典顺序排序存储的，因此，设计rowkey的时候，要充分利用这个排序的特点，将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。
2. 长度原则
   rowkey是一个二进制码流，可以是任意字符串，最大长度 64kb ，实际应用中一般为10-100bytes，以byte[] 形式保存，一般设计成定长。建议越短越好，不要超过16个字节，原因如下：数据的持久化文件HFile中是按照KeyValue存储的，如果rowkey过长，比如超过100字节，1000w行数据，光rowkey就要占用100*1000w=10亿个字节，将近1G数据，这样会极大影响HFile的存储效率；MemStore将缓存部分数据到内存，如果rowkey字段过长，内存的有效利用率就会降低，系统不能缓存更多的数据，这样会降低检索效率。目前操作系统都是64位系统，内存8字节对齐，控制在16个字节，8字节的整数倍利用了操作系统的最佳特性。
3. 散列原则
   如果rowkey按照时间戳的方式递增，不要将时间放在二进制码的前面，建议将rowkey的高位作为散列字段，由程序随机生成，低位放时间字段，这样将提高数据均衡分布在每个RegionServer，以实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息，所有的数据都会集中在一个RegionServer上，这样在数据检索的时候负载会集中在个别的RegionServer上，造成热点问题，会降低查询效率

深入阅读：HBase之rowkey设计原则和方法

HBase 读写流程

HBase数据的写入过程：
① Client 先访问 zookeeper，找到 Meta 表，并获取 Meta 表元数据。
② 确定当前将要写入的数据所对应的 HRegion 和 HRegionServer 服务器。
③ Client 向该 HRegionServer 服务器发起写入数据请求，然后 HRegionServer 收到请求
并响应。
④ Client 先把数据写入到 HLog，以防止数据丢失。
⑤ 然后将数据写入到 Memstore。
⑥ 如果 HLog 和 Memstore 均写入成功，则这条数据写入成功
⑦ 如果 Memstore 达到阈值，会把 Memstore 中的数据 flush 到 Storefile 中。
⑧ 当 Storefile 越来越多，会触发 Compact 合并操作，把过多的 Storefile 合并成一个大
的 Storefile。
⑨ 当 Storefile 越来越大，Region 也会越来越大，达到阈值后，会触发 Split 操作，将
Region 一分为二。

HBase数据的读取过程：
① HRegionServer 保存着 meta 表以及表数据，要访问表数据，首先 Client 先去访问zookeeper，从 zookeeper 里面获取 meta 表所在的位置信息，即找到这个 meta 表在哪个HRegionServer 上保存着。
② 接着 Client 通过刚才获取到的 HRegionServer 的 IP 来访问 Meta 表所在的HRegionServer，从而读取到 Meta，进而获取到 Meta 表中存放的元数据。
③ Client 通过元数据中存储的信息，访问对应的 HRegionServer，然后扫描所在HRegionServer 的 Memstore 和 Storefile 来查询数据。
④ 最后 HRegionServer 把查询到的数据响应给 Client。

深入阅读：Hbase的数据读写流程

HBase中Zookeeper的作用

1. hbase regionserver向zookeeper注册，提供hbase regionserver状态信息（是否在线）。
2. 存放HMaster管理的表的META元数据信息；表名、列名、key区间等。
3. Client访问用户数据之前需要首先访问zookeeper中的META.表，根据META表找到用户数据的位置去访问，中间需要多次网络操作，不过client端会做cache缓存。
4. HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的事件处理确保整个集群只有一个正在运行的HMaster。
5. 当HRegionServer意外终止后，HMaster会通过Zookeeper感知到。

Hbase中compact的用途

在HBase中，每当memstore的数据flush到磁盘后，就形成一个storefile，当storefile的数量越来越大时，会严重影响HBase的读性能 ，HBase内部的compact处理流程是为了解决MemStore Flush之后，文件数目太多，导致读数据性能大大下降的一种自我调节手段，它会将文件按照某种策略进行合并，大大提升HBase的数据读性能。

compact主要起到如下几个作用：

1. 合并文件
2. 清除删除、过期、多余版本的数据
3. 提高读写数据的效率

HBase中实现了两种compaction的方式：minor and major，这两种compaction方式的区别是：

1. Minor操作只用来做部分文件的合并操作以及包括minVersion=0并且设置ttl的过期版本清理，不做任何删除数据、多版本数据的清理工作。
2. Major操作是对Region下的HStore下的所有StoreFile执行合并操作，最终的结果是整理合并出一个文件。

故障排查与调优：

Hbase数据热点问题

一、出现热点问题原因

1. hbase的中的数据是按照字典序排序的，当大量连续的rowkey集中写在个别的region，各个region之间数据分布不均衡；
2. 创建表时没有提前预分区，创建的表默认只有一个region，大量的数据写入当前region；
3. 创建表已经提前预分区，但是设计的rowkey没有规律可循

二、如何解决热点问题

1. 随机数+业务主键，如果想让最近的数据快速get到，可以将时间戳加上
2. Rowkey设计越短越好，不要超过10-100个字节
3. 映射regionNo，这样既可以让数据均匀分布到各个region中，同时可以根据startKey和endKey可以get到同一批数据。

HBase 优化

1. 高可用
   在 HBase 中 Hmaster 负责监控 RegionServer 的生命周期，均衡 RegionServer 的负载，如果 Hmaster 挂掉了，那么整个 HBase 集群将陷入不健康的状态，并且此时的工作状态并不会维持太久。所以 HBase 支持对 Hmaster 的高可用配置。
2. 预分区
   每一个 region 维护着 startRow 与 endRowKey，如果加入的数据符合某个 region 维护的rowKey 范围，则该数据交给这个 region 维护。那么依照这个原则，我们可以将数据所要投放的分区提前大致的规划好，以提高 HBase 性能 .
3. RowKey 设计
   一条数据的唯一标识就是 rowkey，那么这条数据存储于哪个分区，取决于 rowkey 处于哪个一个预分区的区间内，设计 rowkey 的主要目的 ，就是让数据均匀的分布于所有的 region中，在一定程度上防止数据倾斜。接下来我们就谈一谈 rowkey 常用的设计方案
4. 内存优化
   HBase 操作过程中需要大量的内存开销，毕竟 Table 是可以缓存在内存中的，一般会分配整个可用内存的 70%给 HBase 的 Java 堆。但是不建议分配非常大的堆内存，因为 GC 过程持续太久会导致 RegionServer 处于长期不可用状态，一般 16~48G 内存就可以了，如果因为框架占用内存过高导致系统内存不足，框架一样会被系统服务拖死。

深入阅读：HBase性能优化完全版

HBase 宕机恢复流程

宕机分为 Master 宕机和 regionServer 宕机
Master 宕机恢复
1、Master主要负责实现集群的负载均衡和读写调度，没有单点问题，所以集群中可以存在多个Master节点。
2、通过热备方式实现Master高可用，并在zookeeper上进行注册
3、active master会接管整个系统的元数据管理任务，zk以及meta表中的元数据，相应用户的管理指令，创建、删除、修改，merge region等
regionServer宕机恢复
1、RegionServer宕机，HBase会检测到。由于数据和日志都持久在 HDFS中，RegionServer宕机不会导致数据丢失
2、Master将宕机RegionServer上所有管理的region重新分配到集群中其它正常的RegionServer上
3、根据HLog进行丢失数据恢复，恢复之后对外提供服务

深入阅读：HBase宕机恢复

为什么不建议在 HBase 中使用过多的列族

在 Hbase 的表中，每个列族对应 Region 中的一个Store，Region的大小达到阈值时会分裂，因此如果表中有多个列族，则可能出现以下现象：

• 一个Region中有多个Store，如果每个CF的数据量分布不均匀时，比如CF1为100万，CF2为1万，则Region分裂时导致CF2在每个Region中的数据量太少，查询CF2时会横跨多个Region导致效率降低。
• 如果每个CF的数据分布均匀，比如CF1有50万，CF2有50万，CF3有50万，则Region分裂时导致每个CF在Region的数据量偏少，查询某个CF时会导致横跨多个Region的概率增大。
• 多个CF代表有多个Store，也就是说有多个MemStore(2MB)，也就导致内存的消耗量增大，使用效率下降。
• Region 中的 缓存刷新 和 压缩 是基本操作，即一个CF出现缓存刷新或压缩操作，其它CF也会同时做一样的操作，当列族太多时就会导致IO频繁的问题。

深入阅读：为什么不建议在 HBase 中使用过多的列族