Hbase相关面试题

他人真实面试问题

版权声明：本文为博主原创文章，转载请注明出处，欢迎交流。QQ911283415

1.HBase的架构和基本原理

Hbase以表的方式组织数据，
表由行（Row）以及列（Column）组成，行由row key和一个或多个列及其值组成（存储是按照row key的字典顺序排序，row key的设计非常重要！！），
列必须属于某一列族（Column family），一个列族可以有一各或多个列（一列由列簇和列修饰符组成，他们通常由冒号（：） 分隔），其在存储架构中就是一个Hfile。
Hbase中的列可以达到百万级，列中的数据可以是稀疏的，空值并不占用存储空间。
数据按主键排序，同时表按主键划分为多个Region。底层是LSM树（Long-Structed Merge Tree）。

对于以上叙述，表的简略结构：(逻辑模型)

注1：建议把Hbase理解为一个多维Map

Hbase简略架构图如下：

接下来对Zookeeper、HMaster、HRegionServer、HRegion、Store、MemStore、StoreFile、HFile、HLog等做个简单叙述：

Zookeeper

• 保证任何时候，集群中只有一个master（负责多HMaster的选举）
• 存贮所有Region的寻址入口
• 实时监控RegionServer的状态、将RegionServer的上线和下线信息实时通知给Master（服务器之间状态同步）
• 存储Hbase的schema（元数据信息）。包括有哪些table、每个table有哪些column family等

HMaster
(主要负责table和region的管理工作)

• Region分裂后，为RegionServer分配新的Region
• 负责RegionServer的负载均衡，调整region的分配
• 发现失效的region server并重新分配其上的region
  (Region自动切分是HBase能够拥有良好扩张性的最重要因素之一，见转载文章：http://developer.51cto.com/art/201708/549419.htm）
• 管理用户对table的增、删、改、查操作
• 监听zk,基于zookeeper感应rs的上下线
• 监听zk,基于zookeeper来保证HA
• 处理schema更新请求 （管理用户对表的增删修改）
• 不参与对表的读写访问
• 负载很低
• 无SPOF(单点故障)
• 在一个RegionServer死机后，负责失效节点的Region的迁移

HRegionServer
(主要负责响应用户对其上region的I/O请求，向HDFS读写数据，HbasHBase核心模块)

• HRegionSserver维护Master分配给它的region
• 维护region的cache
• 处理region的flush、compact、split
• 内部管理一系列的HRegion对象
• 一个HRegionServer会有多个HRegion和一个HLog。

Region
（图中为Hregion，也就是指一个Table的分区）

• 每一个HRegion又由很多的Store组成，每一个Store存储的实际上是一个列簇（ColumnFamily）下所有的数据。此外，在每一个Store（又名HStore）中有包含一块MemStore。MemStore驻留在内存中，数据到来时首先更新到MemStore中，当到达阈值之后再flush（默认64M）到对应的StoreFile（又名HFile）中，所以每一个Store包含多个StoreFile，StoreFile负责的是实际数据存储，为HBase中最小的存储单元。
• 达到某个阈值时，分裂（默认256M）。所以一个HRegionServer管理多个表，一个表下有多个Region，一个HRegion有多少个列族就有多少个Store,Store下有多个StoreFile文件，是HBase中最小的存储单元
• 以Region为单位管理, region(startKey,endKey)；【默认情况下，刚创建一个表时，并不知道startkey和endkey】
• 每个Column Family单独存储：storeFile；（ storefile的数量一多（到达阀值），就合并（同时合并版本以及删除之前要删除的数据）；合并后大小到达阀值就split）
• 当某个Column Family累积的大小（具体的数据量） > 某阈值时，自动分裂成两个Region；合并之后，旧数据也不是立即删除，而是复制一份并同内存中的数据一起写到磁盘，在之后，LSM-Tree会提供一些机制来回收这些空间。[4]
• 如何找到某行属于哪个region呢？两张特殊的表：
  -NAMESPACE- 和.META.

StoreFile
（底层存储格式是HFile，HBase中最小的存储单元）

memStore内存中的数据写到文件后就是StoreFile，StoreFile底层是以HFile的格式保存。

HFile[1]
（HFile基于Hadoop的TFile类实现，模仿Google的BIgTable论文中的SSTable格式。）

• HBase中KeyValue数据的存储格式，是hadoop的二进制格式文件。
• HFile文件是不定长的，长度固定的只有其中的两块：Trailer和FileInfo。
• Trailer中有指针指向其他数据块的起始点，FileInfo记录了文件的一些meta信息。 - Data Block是hbase io的基本单元，为了提高效率，HRegionServer中有基于LRU的block cache机制。
• 每个Data块的大小可以在创建一个Table的时候通过参数指定（默认块大小64KB），大号的Block有利于顺序Scan，小号的Block利于随机查询。
• 每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成
• Magic内容就是一些随机数字，目的是防止数据损坏
  

HLog(WAL log)
（HLog是WAL的核心实现类）

• WAL意为write ahead log，HBase中的预写日志，用来做灾难恢复使用，底层实现是HLog，HLog记录数据的所有变更。使用WAL的原因：因为MemStore存储的数据是驻留在内存中的，是不稳定的（比如宕机时），所以采用了WAL预写日志来解决这个问题。（运行MApReduce作业时，可以通过关闭WAL功能来获得性能的提升——setWriteToWAL(boolean)）
• 其实HLog文件就是一个普通的Hadoop Sequence File， Sequence File的value是key时HLogKey对象，其中记录了写入数据的归属信息，除了table和region名字外，还同时包括sequence number和timestamp，timestamp是写入时间，sequence number的起始值为0，或者是最近一次存入文件系统中的sequence number。 Sequence File的value是HBase的KeyValue对象，即对应HFile中的KeyValue。[1]

2.HBase与传统关系型数据库(如MySQL)的区别

• 数据类型：没有数据类型，都是字节数组（有一个工具类Bytes，将java对象序列化为字节数组）。
• 数据操作：HBase只有很简单的插入、查询、删除、清空等操作，表和表之间是分离的，没有复杂的表和表之间的关系，而传统数据库通常有各式各样的函数和连接操作。
• 存储模式：Hbase适合于非结构化数据存储，基于列存储而不是行。
• 数据维护：HBase的更新操作不应该叫更新，它实际上是插入了新的数据，而传统数据库是替换修改
• 时间版本：Hbase数据写入cell时，还会附带时间戳，默认为数据写入时RegionServer的时间，但是也可以指定一个不同的时间。数据可以有多个版本。
• 可伸缩性，Hbase这类分布式数据库就是为了这个目的而开发出来的，所以它能够轻松增加或减少硬件的数量，并且对错误的兼容性比较高。而传统数据库通常需要增加中间层才能实现类似的功能
• [3]

3.读写性能对比（读快还是写快）

4.Hbase的设计有什么心得？

5.Hbase的操作是用的什么API还是什么工具？

6.你们hbase里面是存一些什么数据

7.知道spark怎么读hbase吗？

8.做过hbase的二级索引吗？

9.Hbase的PUT的一个过程

---

---

以下是我自己想的问题

1.描述一下Region切分的过程？

HBase原理–所有Region切分的细节都在这里了

2.Hbase读取数据的流程？

HBase读写流程

3.HBase的缺点？（优点已经在4中体现）

• 单一RowKey固有的局限性决定了它不可能有效地支持多条件查询[2]
• 不适合于大范围扫描查询
• 不直接支持 SQL 的语句查询

4.什么时候适合使用HBase（应用场景）

• 半结构化或非结构化数据:
  对于数据结构字段不够确定或杂乱无章非常难按一个概念去进行抽取的数据适合用HBase，因为HBase支持动态添加列。
• 记录很稀疏：
  RDBMS的行有多少列是固定的。为null的列浪费了存储空间。而如上文提到的，HBase为null的Column不会被存储，这样既节省了空间又提高了读性能。
• 多版本号数据：
  依据Row key和Column key定位到的Value能够有随意数量的版本号值，因此对于须要存储变动历史记录的数据，用HBase是很方便的。比方某个用户的Address变更，用户的Address变更记录也许也是具有研究意义的。
• 仅要求最终一致性：
  对于数据存储事务的要求不像金融行业和财务系统这么高，只要保证最终一致性就行。（比如HBase+elasticsearch时，可能出现数据不一致）
• 高可用和海量数据以及很大的瞬间写入量：
  WAL解决高可用，支持PB级数据，put性能高
• 索引插入比查询操作更频繁的情况。比如，对于历史记录表和日志文件。（HBase的写操作更加高效）
• 业务场景简单：
  不需要太多的关系型数据库特性，列入交叉列，交叉表，事务，连接等。

---

2018/3/12增

5.Client会缓存.META.的数据,该数据更新了怎么办？

（参考自[5]）

其实，Client的元数据缓存不更新，当.META.的数据发生更新。比如因为region重新均衡，某个Region的位置发生了变化，Client再次根据缓存去访问的时候，会出现错误，当出现异常达到最大重试次数后，client就会重新去.META.所在的RegionServer获取最新的Region信息，如果.META.所在的RegionServer也变了，Client就会重新去ZK上获取.META.所在的RegionServer的最新地址。

注

注1：对应上文的表结构的多维度Map映射表形式理解

{
"com.cnn.www": {
    contents: {
      t6: contents:html: "..."
      t5: contents:html: "..."
      t3: contents:html: "..."
} 
    anchor: {
      t9: anchor:cnnsi.com = "CNN"
      t8: anchor:my.look.ca = "CNN.com"
} 
    people: {}
} 
"com.example.www": {
    contents: {
      t5: contents:html: "..."
} 
    anchor: {}
    people: {
      t5: people:author: "John Doe"
        }
    }
}

参考

[1]对于HFile和Hlog更为细致的讲解见：深入学习HBase架构原理
[2]文章可能会有点旧：HBase高性能复杂条件查询引擎
[3]Hbase与传统关系型数据库对比
[4]《Hbase企业应用开发实战》第270页
[5]简书-飞鸿无痕：Hbase技术详细学习笔记