大数据最全【大数据面试题】HBase面试题附答案_hbase 面试题，2024年最新一年后斩获腾讯T3

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

9.HBase高可用怎么实现的?

**数据复制：**数据能够在不同的ReginServer之间进行复制；

**Zookeeper：**用于检测和管理各个节点的状态，并触发相应的操作；

**RegionServer自动恢复：**出现故障后，上面的数据会被HMaster发到其他ReginServer。

10.为什么HBase适合写多读少业务?

HBase存储引擎使用LSM树实现

• 写的时候先将数据存在内存中，达到阈值后再顺序写到磁盘上，避免了随机写；
• 读的时候，HBase只有rowkey索引，并且很难命中内存中数据，需要访问较多磁盘。

11.列式数据库的适用场景和优势?

适用场景：

a. 查询过程中，可针对各列的运算并发执行，在内存中聚合完整记录集，降低查询响应时间

b. 因为各列独立存储，且数据类型已知，可以针对该列的数据类型、数据量大小等因素动态选择压缩算法，以提高物理存储利用率

优势：

a. 列存模式下，只需要读取参与计算的列即可，极大的减低了IO花费

b. 同一列中的数据属于同一类型，压缩效果显著

适合OLAP系统

12.HBase的rowkey设计原则

（1）长度

Rowkey是一个二进制码流，太长浪费磁盘，并且MemStore中存储数据量也少建议10~100长度，最佳为16，因为64位操作系统内存8字节对齐，为8的整数倍最佳；

（2）散列原则

将RowKey高位字段作为散列字段，避免热点数据集中在一个ReginServer上；

（3）唯一原则

rowkey 是按照字典顺序排序存储的，因此可以将经常读到的数据放在一起。

13.HBase的rowkey为什么要唯一?

因为HBase是k-v存储，重复的话旧数据会被新数据覆盖

14.HBase的大合并、小合并是什么?

• 小合并(Minor Compaction)

合并相邻的StoreFile为一个较大的StoreFile

• 大合并（Major Compartion）

将所有StoreFile合并为一个StoreFile，伴随着数据的删除清理

15.HBase和关系型数据库(传统数据库)的区别(优点)?

(1)数据类型

HBase只有字符串存储，传统的关系型数据有着丰富的存储类型

(2)数据的操作

HBase只有表内数据的操作，没有表之间的关联

(3)存储方式

HBase是列式存储

(4)数据维护

HBase的修改和删除不是马上执行，操作后并不是第一时间内生效

(5)可伸缩性

HBase能够很容易的增加/减少节点

16.HBase为什么随机查询很快?

(1)只需要遍历相关Regin

(2)只需要遍历相关列簇

(3)先内存再磁盘

(4)根据key遍历

17.HBase的Get和Scan的区别和联系?

区别：

a. Get根据RowKey获取唯一值；

b. Scan按照指定的条件和顺序扫描表中的多行数据；

c. Get操作在内部对数据进行缓存，因此适用于对特定行的频繁读取。而Scan操作不会缓存数据，适用于一次性读取大量数据或按顺序遍历数据。

联系：

a. Get和Scan都可以使用过滤器（Filters）进行数据过滤，以便按照特定条件筛选所需的数据；

b. Get和Scan都可以选择返回的列族和列限定符，以获取特定的列数据。

18.HBase数据compact流程

(1) 触发

(2) 选择合并目标

(3) 合并：对选中的StoreFile进行归并排序，并进行合并，合并同时处理文件版本，时间戳等信息

(4) 清理：合并完成后，原有StoreFile会废弃，HBase会将其删除，并释放相应空间

(5) 更新元数据：Compaction完成后，HBase会更新相应的元数据信息

19.MemStore Flush条件

• MemStore达到阈值，所在regin都会flush

达到MemStore的4倍（默认），停止写入MemStore

• ReginServer中MemStore总大小达到阈值，全体flush
• 达到时间阈值，触发flush
• WAL文件数量超过阈值，regin整体flush

20.既然HBase底层数据是存储在HDFS上，为什么不直接使用HDFS，而还要用HBase

• HDFS更多的功能是大文件的存储，创建/删除文件，管理权限，对大文件的数据读取/追加。但是如果要对所存储的数据做修改/删除/插入/随机写，HDFS就做不到了
• HBase是基于HDFS进行超大数据集的分布式存储以及对数据的增删改查

21.HBase和Phoenix的区别

• Phoenix是HBase的开源SQL中间层，允许使用JDBC方式操作HBase上的数据
• HBase创建的表Phoenix看不到，Phoenix创建的表HBase能看到
• Phoenix具备二级索引
• Phoenix支持表之间的Join操作

22.HBase支持SQL操作吗

不直接支持传统SQL语句，使用自身API实现操作数据

23.HBase表设计

• 列簇设计在合理范围内能尽量少的减少列簇就尽量减少列簇数据保留的版本数数据保留时间
• rowkey设计预分区

主要解决热点问题，避免数据吞吐量过大时单个Regin负载过大

• rowkey长度不宜过大
• 唯一性原则

24.Region分配

• 任何时刻，一个Regin只能分给一个ReginServer
• Master记录了有哪些可用的ReginServer，以及当前有哪些Regin分配给了哪些ReginServer。当需要分配新的Regin，并且一个ReginServer有空间时，Master则会向ReginServer发送装载请求，ReginServer开始提供服务。

25.HBase的Region切分

（1）prepare阶段

在内存中初始化两个HReginInfo对象，包含tableName，reginName，startKey，endKey以及transaction journal用来记录切分的进展。

（2）execute阶段

a. RegionServer 更改ZK节点 /region-in-transition 中该Region的状态为SPLITING

b. Master通过watch节点/region-in-transition检测到Region状态改变，并修改内存中Region的状态

c. 在父存储目录下新建临时文件夹.split保存split后的daughter region信息

d. 关闭parent regin（会触发flush操作，确保数据全部落盘）

e. 核心分裂步骤：在.split文件夹下新建两个子文件夹，称之为daughter A、daughter B，并在文件夹中生成reference文件，分别指向父region中对应文件

f. 父region分裂为两个子region后， 将daughter A、daughter B拷贝到HBase根目录下，形成两个新的region

g. parent region通知修改 hbase.meta 表后下线，不再提供服务

h. 开启daughter A、daughter B两个子region。通知修改 hbase.meta 表，正式对外提供服务

(3)rollback阶段

如果execute阶段出现异常，则执行rollback操作

26.介绍下HBase中的LSM树

（1）设计思想

将对数据的修改增量保持在内存中，达到指定的大小限制后将这些修改操作批量写入磁盘，不过读取的时候稍微麻烦，需要合并磁盘中历史数据和内存中最近修改操作，所以写入性能大大提升，读取时可能需要先看是否命中内存，否则需要访问较多的磁盘文件。极端的来说，基于LSM树实现的HBase的写性能比Mysql高了一个数量级，读性能低了一个数量级。

本质是将写入操作全部转化成磁盘的顺序写入，极大地提高了写入操作的性能。

（2）数据写

a. 数据首先会插入到内存中的树，为了防止数据丢失，写内存的同时需要暂时持久化到磁盘(WAL)，即输入数据时数据会以完全有序的形式先存储在日志文件中（对应HBase的MemStore和HLog）。当日志文件被修改时，对应的更新会被先保存在内存中来加速查询。

b. 当内存中树的数据大小达到阈值时，会进行合并操作。合并操作会从左至右遍历内存中的叶子节点与磁盘中树的叶子节点进行合并，当合并的数据量达到磁盘的存储页的大小时，会将合并的数据持久化到磁盘。同时更新父亲节点对叶子节点的指针。

27.HBase写数据流程

a. Client先访问zookeeper，获取hbase:meta表位于哪个RegionServer

b. 访问对应的RegionServer，获取hbase:meta表中数据，查询要写入数据Region所在RegionServer

c. 访问RegionServer，发送写请求

d. ReginServer将数据顺序写入（追加）到HLog（WAL）

e. 将数据写入对应的MemStore，数据会在MemStore进行排序

f. 向客户端发送ack

g. 等达到MemStore的刷写时机后，将数据刷写到HFile

28.HBase读数据流程

a. Client先访问zookeeper，获取hbase:meta表位于哪个Region Server

b. 访问对应的Region Server，获取hbase:meta表，根据读请求的namespace:table/rowkey，查询出目标数据位于哪个Region Server中的哪个Region中。并将该table的region信息以及meta表的位置信息缓存在客户端的meta cache，方便下次访问

c. 与目标RegionServer进行通讯

d. 分别在MemStore、Block Cache和Store File（HFile）中查询目标数据，并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本（time stamp）或者不同的类型（Put/Delete）

e. 将查询到的新的数据块（Block，HFile数据存储单元，默认大小为64KB）缓存到Block Cache

f. 将合并后的最终结果返回给客户端

29.HBase优化

（1）预分区

每一个region维护着startRow与endRowKey，如果加入的数据符合某个region维护的rowKey范围，则该数据交给这个region维护。那么依照这个原则，我们可以将数据所要投放的分区提前大致的规划好，以提高HBase性能

（2）RowKey设计

生成随机数、hash、散列值；

字符串反转；

字符串拼接。

（3）内存优化

适合就好，过大的话虽然性能高，但是GC时候时间特别长。

（4）设置RPC监听数量

默认值为30，用于指定RPC监听的数量，可以根据客户端的请求数进行调整，读写请求较多时，增加此值。

（RPC监听是指Region Compact后的监听器，当一个Region没有被写入新数据，并且仅存在较少的数量的旧数据时，HBase会自动压缩该Region。在这种情况下，HBase将触发rck监听器，以便通知相关进程可以将该Region从内存中卸载，以释放更多的资源。通过这种方式，rck监听器可以帮助保持HBase集群的高性能和稳定性。）

（5）手动控制Major Compaction

默认值：604800000秒（7天）， Major Compaction的周期，若关闭自动Major Compaction，可将其设为0

（6）优化HStore文件大小

默认值10737418240（10GB），如果需要运行HBase的MR任务，可以减小此值，因为一个region对应一个map任务，如果单个region过大，会导致map任务执行时间过长。该值的意思就是，如果HFile的大小达到这个数值，则这个region会被切分为两个Hfile

（7）优化HBase客户端缓存

默认值2097152bytes（2M）用于指定HBase客户端缓存，增大该值可以减少RPC调用次数，但是会消耗更多内存，反之则反之。一般我们需要设定一定的缓存大小，以达到减少RPC次数的目的

（8）指定scan.next扫描HBase所获取的行数

用于指定scan.next方法获取的默认行数，值越大，消耗内存越大

（9）BlockCache占用RegionServer堆内存的比例默认0.4，读请求比较多的情况下，可适当调大

（10）MemStore占用RegionServer堆内存的比例默认0.4，写请求较多的情况下，可适当调大

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

ockCache占用RegionServer堆内存的比例默认0.4，读请求比较多的情况下，可适当调大

（10）MemStore占用RegionServer堆内存的比例默认0.4，写请求较多的情况下，可适当调大

[外链图片转存中…(img-iWPjEa3q-1715039586259)]
[外链图片转存中…(img-qWjgagEe-1715039586259)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！