大数据分析工程师面试24题 ◀ HBase

╰半夏微凉° 2023-08-17 17:05 146阅读 0赞

> 作为一个高可靠性、高性能、列存储、可伸缩、实时读写的分布式数据库系统，HBase在大数据生态系统中占据重要的地位。我们必须要了解其基本原理和概念，一方面可以对数据分析工作中排查问题有比较大的帮助，另一方面方便我们与他人沟通交流。

## 1. Hbase的特点是什么？ ##

1.  Hbase是一个分布式的，基于列式存储的数据库，基于hadoop的hdfs存储，zookeeper进行管理。
2.  Hbase 适合存储半结构化或非结构化的数据，比如数据结构字段不够确定或者杂乱无章很难按照一个概念去抽取的数据。
3.  Hbase的存储效率比较高，为null的数据不会被存储。
4.  Hbase的表包含rowKey、列族和列，存储数据的最小单元是单元格，单元格包含数据及其对应的写入时间戳，新写入数据时，附带写入时间戳，可以查询到之前写入的多个版本。
5.  Hbase是主从结构，Hmaster作为主节点，HregionServer作为从节点。

## 2. Hbase的数据存储模型 ##

Hbase 中的每张表都通过行键(rowkey)按照一定的范围被分割成多个子表（HRegion），默认一个 HRegion 超过 256M 就要被分割成两个，由 HRegionServer 管理，管理哪些 HRegion由 Hmaster 分配。HRegion 存取一个子表时，会创建一个 HRegion 对象，然后对表的每个列族（Column Family）创建一个 store 实例，每个 store 都会有 0 个或多个 StoreFile 与之对应，每个 StoreFile 都会对应一个 HFile， HFile 就是实际的存储文件；一个 HRegion 还拥有一个 MemStore 实例。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI2ODExMzc3_size_16_color_FFFFFF_t_70][]

## 3. 描述下HBase的架构 ##

HBase遵守主从架构的技术，由一个主HMaster和若干个从HRegionServer组成。HBase中的一张表的数据由若干个HRegion组成，也就是说每一个HRegion负责管理一张表中的一段数据，HRegion都是分布式的存在于HRegionServer中，所以说HRegion是HBase表中数据分布式存储的单位。那么一个HRegion中又是由若干个column family的数据组成；在HRegion中每个column family数据由一个store管理，每个store包含了一个memory store和若干个HFile组成，HFile的数据最终会落地到HDFS文件中，所以说HBase依赖HDFS。

在HBase中还有一部分元数据信息，比如HMaster的状态信息、HRegionServer的状态信息以及HRegion的状态信息等，这些信息都是存储在zookeeper集群中。请看下图便于理解。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI2ODExMzc3_size_16_color_FFFFFF_t_70 1][]

## 4 描述Hbase中scan和get的功能以及实现的异同 ##

Get的功能是精准查找，按指定RowKey 获取唯一一条记录。Scan的功能是范围查找，按指定的条件获取一批记录。实际上它们的实现是一样的，get操作就是一种特殊的scan（begin和end相同的scan操作）。而且hbase读数据的操作都是scan，代码级别实现的是scan，并没有特别针对get的操作。

## 5. 请详细描述Hbase中一个Cell的结构 ##

cell：由\{row key, column(=<family> + <label>), version\}唯一确定的单元，cell中的数据是没有类型的，全部是字节码形式存储。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI2ODExMzc3_size_16_color_FFFFFF_t_70 2][]

## 6 简述compact ##

**简述HBASE中compact用途是什么，什么时候触发，分为哪两种，有什么区别，有哪些相关配置参数?**

在 hbase 中每当有 memstore 数据 flush 到磁盘之后，就形成一个 storeFile，当 storeFile 的数量达到一定程度后，就需要将 storefile 文件来进行 compaction 操作。

Compact 的作用：

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

HBase 中实现了两种 compaction 的方式：**minor 和 major**。

**这两种 compaction 方式的区别是：**

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

## 7. 描述HBase HMaster HA故障转移过程？ ##

宕机分为 HMaster 宕机和 HRegisoner 宕机，如果是 HRegisoner 宕机， HMaster 会将其所管理的 region 重新分布到其他活动的 RegionServer 上，由于数据和日志都持久在 HDFS中，该操作不会导致数据丢失。所以数据的一致性和安全性是有保障的。如果是 HMaster 宕机，会通过Zookeeper 的 Master Election 机制重新选出一个正在运行的Master 进程作为活跃节点，继续提供服务。

## 8. Hbase读写流程 ##

**读：**

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

**写：**

1.  Client 先访问 zookeeper，找到 Meta 表，并获取 Meta 表元数据。
2.  确定当前将要写入的数据所对应的 HRegion 和 HRegionServer 服务器。
3.  Client 向该 HRegionServer 服务器发起写入数据请求，然后 HRegionServer 收到请求并响应。 
4.  Client 先把数据写入到 HLog，以防止数据丢失。
5.  然后将数据写入到 Memstore。
6.  如果 HLog 和 Memstore 均写入成功，则这条数据写入成功
7.  如果 Memstore 达到阈值，会把 Memstore 中的数据 flush 到 Storefile 中。
8.  当 Storefile 越来越多，会触发 Compact 合并操作，把过多的 Storefile 合并成一个大的 Storefile。
9.  当 Storefile 越来越大，Region 也会越来越大，达到阈值后，会触发 Split 操作，将Region 一分为二。

## 9. HBase适用于怎样的情景？ ##

**1. 半结构化或非结构化数据：**

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

**2. 记录很稀疏：**

关系型数据库的列的数量是相对稳定的，null值也会占据存储位，为null的列浪费了存储空间。HBase为null的Column不会被存储，这样既节省了空间又提高了读性能。

**3. 多版本数据：**

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

**4. 仅要求最终一致性：**

对于数据存储事务的要求不像金融行业和财务系统这么高，只要保证最终一致性就行。

**5. 要求高可用性和支持海量数据以及很大的瞬间写入量：**

1）WAL解决高可用，支持PB级数据，写入性能高。

2）索引插入比查询操作更频繁的情况。比如，对于历史记录表和日志文件。（HBase的写操作更加高效）。

## 10. 描述HBase的rowKey的设计原则 ##

**1. Rowkey 长度原则**

Rowkey 是一个二进制码流，一般是10~100个字节，建议越短越好，不超过16字节为宜。

**2. Rowkey 散列原则**

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

**3. Rowkey 唯一原则**

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

## 11. 如何提高HBase集群的读写性能 ##

1.  **开启 bloomfilter 过滤器。**开启 bloomfilter 比没开启要快 3、4 倍。
2.  Hbase 对于内存有特别的需求，在硬件允许的情况下**配足够多的内存**给它。
3.  **增大 RPC 数量**。通过修改 hbase-site.xml 中的 hbase.regionserver.handler.count 属性，可以适当的放大RPC 数量，默认值为 10 有点小。

## 12. HRegionServer宕机后，此台机器的region数据的转移过程？ ##

1.  ZooKeeper 会监控 HRegionServer 的上下线情况，当 ZK 发现某个 HRegionServer 宕机之后会通知 HMaster 进行失效备援；
2.  HRegionServer 会停止对外提供服务，就是它所负责的 region 暂时停止对外提供服务；
3.  HMaster 会将该 HRegionServer 所负责的 region 转移到其他 HRegionServer 上，并且会对 HRegionServer 上存在 memstore 中还未持久化到磁盘中的数据进行恢复；

**这个恢复的工作是由 WAL重播 来完成，这个过程如下：**

wal实际上就是一个文件，存在/hbase/WAL/对应RegionServer路径下，宕机发生时，读取该RegionServer所对应的路径下的wal文件，然后根据不同的region切分成不同的临时文件recover.edits。当region被分配到新的RegionServer中，RegionServer读取region时会判断是否存在recover.edits，如果有则进行恢复。

## 13. 描述HBase中region太小和region太大带来的问题？ ##

Region过小会发生多次compaction，将数据读一遍并重写一遍到hdfs上，占用io；

Region过大会造成多次split，region 会下线，影响访问服务。

## 14. HBase的关键组件是什么？ ##

1.  Table：可理解为传统数据库中的一个表，但因为SchemaLess的设计，它较之传统数据库的表而言，在设计上更加灵活。
2.  Region：将表横向切割为一个个子表，子表在HBase中被称之为Region。
3.  RegionServer：数据服务进程，Region必须部署在某一个RegionServer上才可以提供读写服务。
4.  HFile：HBase数据库在底层分布式文件系统中的文件组织形式。
5.  Column Family：一些列的集合。不同的Column Family数据被存储在不同的路径中。MemStore：用来在内存中缓存一定大小的数据，达到设定的阈值后批量写入到底层文件系统中。数据是有序的。

**下图清晰的展示了Table，Region，RegionServer，HFile，MemStore，Column Family在HBase的逻辑关系。**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI2ODExMzc3_size_16_color_FFFFFF_t_70 3][]

**除此之外还有：**

6. Zookeeper：HBase集群的调度器，可以用于将HBase RegionServer信息注册到zookeeper中，查询HBase RegionServer状态信息，HMaster启动时会将HBase系统表-ROOT-加载到zookeeper集群中，通过zookeeper集群可以获取当前系统表.META.的存储所对应的RegionServer信息。

7. Master：负责管理表，分配Region到各个RegionServer以及RegionServer Failover的处理。

## 15. Hbase中有哪些数据操作命令类型？ ##

Hbases中的数据操作命令大约有四种类型。

*  get：查询操作
 *  put：插入操作
 *  delete：删除操作
 *  scan：扫描所有记录

## 16. 在HBase中什么是列族？ ##

ColumnFamily: 列族，HBase引入的概念。

将多个列聚合成一个列族。可以理解成MySQL的垂直分区（将一张宽表，切分成几张不那么宽的表）。此机制引入的原因，是因为HBase相信，**查询可能并不需要将一整行的所有列数据全部返回**（就像我们往往在写SQL时不太会写select \*一样）。列族会对应到文件存储结构（不同的ColumnFamily会写入不同的文件）。

## 17. 解释Hbase如何实际删除一行 ##

在Hbase中的删除过程中，主要的压缩过程删除标记，而次要压缩则不会。在正常删除中，它会导致删除逻辑删除标记 - 它们表示的这些删除数据在压缩过程中被删除。

此外，假如删除数据并增加更多数据，但时间戳早于逻辑删除时间戳，则删除/逻辑删除标记可可以会掩盖进一步的获取，因而在主要压缩之前您将不会收到插入的值。

## 18. 介绍下RowFilter ##

RowFilter就是对rowkey进行过滤，那么rowkey的过滤无非就是相等（EQUAL）、大于(GREATER)、小于(LESS)，大于等于(GREATER\_OR\_EQUAL)，小于等于(LESS\_OR\_EQUAL)和不等于(NOT\_EQUAL)几种过滤方式。Hbase中的RowFilter采用比较符结合比较器的方式来进行过滤。

比较器的类型有：BinaryComparator、BinaryPrefixComparator、NullComparator、BitComparator、RegexStringComparator、SubStringComparator

参考示例：

Filter rowFilter = new RowFilter(CompareFilter.CompareOp.EQUAL,
    new BinaryComparator(Bytes.toBytes(rowKeyValue)));
    Scan scan = new Scan();
    scan.setFilter(rowFilter)

在上面例子中，比较符为EQUAL，比较器为BinaryComparator

## 19. Region如何预建分区 ##

预建分区的方法很简单，有以下两种

1）Hbase shell

create 't1', 'f1',SPLITS=>['10','20','30']
    create 't1','f1',SPLITS_FILE =>'splits.txt'

2）Java API

创建一个byte[][] splitKeys = {
       {1,2,3},{4,5,6}}
    admin.createTable(tableDesc,splitKeys)

## 20. Hbase中有多少数据操作命令类型 ##

**在创建表之前先创建一个新的namespace：**

create_namespace 'test_ns'

**在新的namespace中创建表：**

//test表中有2个column familycreate 'test_ns:test','f','e'

**增加数据**

put 'test_ns:test','rowkey-1','f:a','value1'put 'test_ns:test','rowkey-1','e:b','value2'

**删除数据**

//删除一列delete 'test_ns:test','rowkey-1','f:a'
    //删除一行deleteall 'test_ns:test','rowkey-1'

**更新一列的值：**

put 'test_ns:test','rowkey-1','f:a','value1'

**查询一行以及一列的数据：**

get 'test_ns:test','rowkey-1'
    get 'test_ns:test','rowkey-1'，{COLUMN => 'f:a'}

## 21. 使用HBase shell创建一张表，并对其进行增删改查？ ##

HFile是一种文件格式，HBase依赖HDFS，存在HBase中的数据最终都会落地到HDFS中。一个HFile包含了若干个不同类型的Block，每一个Block的大小通常为8K到1M（默认是64K）；Block的类型有Data Blocks、Index Blocks、Bloom filter Blocks以及Trailer Blocks。

## 22. 简述下HBASE中split机制 ##

HBase中为了使得HRegion不至于太大（默认是10G），那么当HRegion太大的时候，就需要对HRegion进行切分（split）。

split有三种方式：

*  pre-split（预切分），可以根据传入的参数计算出HBase表需要存储多大的数据，在创建表的时候预先给表切分好HRegion。如下面的例子：

//根据参数给表预先切分4个HRegioncreate 'test_pre_split','f',split => ['10','20','30']

*  Auto-split（自动切分），当一个Region达到一定的大小的时候，这个Region会自动切分成两个Region。
 *  Force-split（手工切分），通过命令手动的去切分某个需要切分的HRegion。可以在hbase shell中通过命令split table\_name，rowkey；还可以在HBase的Web UI上进行切分。

## 23. Hbase如何借助其他技术实现二级索引 ##

众所周知，在hbase中使用rowKey检索数据是非常快速的，但是如果想要根据某一列进行数据的检索，速度就会慢很多，这是因为hbase没有二级索引，对某一列进行检索就需要做全表扫描。

明白了这一点，那么我们就可以借助其他技术来实现hbase的二级索引功能，最常用的技术手段便是，借助Solr或者ElasticSearch。它的核心思想是，在数据写入hbase的同时，将rowKey以及需要用于检索的列写入Solr或者ElasticSearch建立倒排索引，那么我们在对某一列进行检索时，可以先去Solr或者ElasticSearch中检索出对应的rowKey，然后再去Hbase中进行查找，这样两段式查找，就避免了全表扫描，大大提高了检索的速度。

## 24. RowKey设计实例 ##

**一款视频APP的播放行为统计数据，需要查询每天每个视频类型播放量TopN的视频（播放量从高到低排序），如何设计rowkey？**

**需求分析：**首先我们存储的数据是每个视频在某天的播放量统计数据，我们读取数据的场景是获取某天某个视频类型的播放量TopN（可以是Top10、Top100、Top200等）视频列表，那么我们的设计思路可以是将RowKey分为三段，第一段存储播放日期，第二段存放视频类型，第三段存储倒排的播放量。这样在检索时，我们可以设置过滤RowKey前缀是播放日期+视频类型，然后提取前N条记录。

**参考示例：**key\_day + content\_type + （99999999-play\_num）

**说明：**key\_day是播放日期，content\_type是视频类型，play\_num是视频的播放量，用（9999999999-play\_num）是为了反转排序，将播放量大的视频排在前面。需要注意的是，RowKey每段的长度一定要保持一致，如果长度不够，需要用其他字符补足位数。

这样设计rowkey就可以满足每天每个视频类型的TopN查询，查询的时候要配合前缀过滤器PrefixFilter进行升序排序，得到的就是一个播放量倒排的视频列表。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI2ODExMzc3_size_16_color_FFFFFF_t_70]: /images/20230808/b3f69511709c4fc2be0e0380a1af0fec.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI2ODExMzc3_size_16_color_FFFFFF_t_70 1]: /images/20230808/0a58ae1004f74f6f87b51f203c9b816d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI2ODExMzc3_size_16_color_FFFFFF_t_70 2]: /images/20230808/196623b9f60043b8b796ba878b2b52d5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3NpbmF0XzI2ODExMzc3_size_16_color_FFFFFF_t_70 3]: /images/20230808/8f0386d5f8e04490b0ba4d178af6d0a4.png