HBase 常见问题

HBase 在大数据技术领域中占据了重要的作用，整理了一些面试问题，大家收藏，文末可以获取 PPT。

面试题一：讲一下 Hbase 架构

Hbase 主要包含 HMaster、HRegionServer、Zookeeper。

1、HRegionServer 负责实际数据的读写. 当访问数据时, 客户端直接与 RegionServer 通信.

HBase 的表根据 Row Key 的区域分成多个 Region, 一个 Region 包含这这个区域内所有数据. 而 Region server 负责管理多个 Region, 负责在这个 Region server 上的所有 region 的读写操作.

2、HMaster 负责管理 Region 的位置, DDL(新增和删除表结构)

• 协调 RegionServer

• 在集群处于数据恢复或者动态调整负载时,分配 Region 到某一个 RegionServer 中

• 管控集群,监控所有 Region Server 的状态

• 提供 DDL 相关的 API, 新建(create),删除(delete)和更新(update)表结构.

3、Zookeeper 负责维护和记录整个 Hbase 集群的状态

zookeeper 探测和记录 Hbase 集群中服务器的状态信息.如果 zookeeper 发现服务器宕机,它会通知 Hbase 的 master 节点.

面试题二：hbase 如何设计 rowkey

1、RowKey 长度原则

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

原因如下：

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

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

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

2、RowKey 散列原则

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

3、RowKey 唯一原则

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

面试题三：讲一下 hbase 的存储结构,这样的存储结构有什么优缺点

Hbase 的优点及应用场景:

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

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

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

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

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

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

Hbase 的缺点：

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

• 不适合于大范围扫描查询

• 不直接支持 SQL 的语句查询

面试题四：hbase 的 HA 实现,zookeeper 在其中的作用

HBase 中可以启动多个 HMaster，通过 Zookeeper 的 Master Election 机制保证总有一个 Master 运行。配置 HBase 高可用，只需要启动两个 HMaster，让 Zookeeper 自己去选择一个 Master Acitve 即可。

zk 的在这里起到的作用就是用来管理 master 节点,以及帮助 hbase 做 master 选举。

面试题五：HMaster 宕机的时候,哪些操作还能正常工作

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

面试题六：讲一下 hbase 的写数据的流程

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

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

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

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

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

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

面试题七：讲一下 hbase 读数据的流程

• 首先，客户端需要获知其想要读取的信息的 Region 的位置，这个时候，Client 访问 hbase 上数据时并不需要 Hmaster 参与（HMaster 仅仅维护着 table 和 Region 的元数据信息，负载很低），只需要访问 zookeeper，从 meta 表获取相应 region 信息(地址和端口等)。【Client 请求 ZK 获取.META.所在的 RegionServer 的地址。】

• 客户端会将该保存着 RegionServer 的位置信息的元数据表.META.进行缓存。然后在表中确定待检索 rowkey 所在的 RegionServer 信息（得到持有对应行键的.META 表的服务器名）。【获取访问数据所在的 RegionServer 地址】

• 根据数据所在 RegionServer 的访问信息，客户端会向该 RegionServer 发送真正的数据读取请求。服务器端接收到该请求之后需要进行复杂的处理。

• 先从 MemStore 找数据，如果没有，再到 StoreFile 上读(为了读取的效率)。