两个角度，一个从利用者的角度，一个从掩护者的角度。
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实行合并操作，终极的结果是整理合并出一个文件。
