这个更新频率可以吧，话不多说，看正文。
黑色字体是正经答案，灰色字体是我小声BB。
HBase 有哪些优化点？
这是个相对开放的问题，问题没有那么得细，面对这种问题千万不要乱了阵脚，其实这种问题答得好是很加分的，可以从几个不同的方向来回答，这样显得有条理，而且可以向面试官展现你的多维度思考和总结的能力。
两个角度，一个从使用者的角度，一个从维护者的角度。
1. 从使用者的角度,可以优化存储模型的设计，包括以下几个方面：
rowkey设计：高位用散列，长度不宜过长，可以适当地把需要检索的条件拼接在rowkey里。查询时尽量用get，scan时要指定start/end key。
列族的设计：列族尽量少，且不同列族的数据量要尽量均匀。
列族尽量少是因为列族对应的底层存储的一个文件目录，文件目录少有助于提高文件检索速度。
数据量要均匀是因为，当一个cf量大到一定程度，memstore会刷盘，而刷盘这个动作不是只针对单个cf，而是整个服务器，这个时候如果另一个cf的数据量很小那也会跟着刷盘，这就造成了会有大量小文件生成，HDFS是最忌讳小文件的，同时小文件的过多也会影响检索的效率，需要从多个文件中检索目标。
预分区：在写比较频繁的场景下，数据增长太快，split的次数也会增多，额外的资源消耗也会增大，另外数据分布不均匀会造成热点问题，这些都是需要预分区的原因。
2. 从系统维护者的角度来说，可以对系统优化，包括以下几个方面：
内存优化：HBase有两块主要的内存memstore和blockCache的配置
BlockCache，如果写比读少很多，可以开到0.4-0.5。如果读写较均衡，0.3左右。如果写比读多，就默认0.2。设置这个值的时候，也要参考hbase.regionserver.global.memstore.upperLimit，该值是memstore占heap的最大百分比，两个参数一个影响读，一个影响写。如果两值加起来超过80-90%，会有OOM的风险。具体就不说了，看我之前的文章 HBase篇(4)-你不知道的HFile
GC优化：默认cms，可以优化为G1。
压缩：默认未开启，建议使用Snappy和LZO，压缩比，压缩解压速率，资源消耗都是比较平衡的。
BloomFilter：默认未开启，需要在建立表的时候加入。用布隆过滤可以节省读磁盘过程，可以有助于降低读取延迟。具体就不说了看我之前的文章 HBase篇(5)- BloomFilter
其实还有一些其他零零散散的点，就不说了，说这么多对于这个问题来说已经回答地很完美了。说这些的过程中的某些点面试官很有可能是会追问下去的，比如内存优化，bloomfilter等，所以可以看得深入一点，回答的时候也能更加从容一点。
HRegionServer宕机后系统是怎么保证可用性的 ？
宕机恢复的过程也是面试中的常见问题，重点是wal机制。
1. ZooKeeper会监控HRegionServer的上下线情况，当ZK发现某个HRegionServer宕机之后会通知HMaster进行失效备援；
2. 该HRegionServer会停止对外提供服务，就是它所负责的region暂时停止对外提供服务
3. HMaster会将该HRegionServer所负责的region转移到其他HRegionServer上，并且会对HRegionServer上存在memstore中还未持久化到磁盘中的数据进行恢复
4. 这个恢复的工作是由WAL重播来完成，这个过程如下：
- wal实际上就是一个文件，存在/hbase/WAL/对应RegionServer路径下。
- 宕机发生时，读取该RegionServer所对应的路径下的wal文件，然后根据不同的region切分成不同的临时文件recover.edits。
- 当region被分配到新的RegionServer中，RegionServer读取region时会进行是否存在recover.edits，如果有则进行恢复。
说说HBase 的 compaction 过程和作用？
在hbase中每当有memstore数据flush到磁盘之后，就形成一个storefile，当storeFile的数量达到一定程度后，就需要将 storefile 文件来进行 compaction 操作。
compaction 的作用：
- 合并文件
- 清除过期，多余版本的数据
- 提高读写数据的效率
另外可以再说下compaction的两种方式。
HBase 中实现了两种 compaction 的方式：minor and major. 这两种 compaction 方式的区别是：
1. Minor 操作只用来做部分文件的合并操作以及包括 minVersion=0 并且设置 ttl 的过期版本清理，不做任何删除数据、多版本数据的清理工作。
2. Major 操作是对 Region 下的HStore下的所有StoreFile执行合并操作，最终的结果是整理合并出一个文件。
