Memstore存在的意义
HBase在WAL机制开启的情况下，不考虑块缓存，数据日志会先写入HLog，然后进入Memstore，最后持久化到HFile中。HFile是存储在hdfs上的，WAL预写日志也是，但Memstore是在内存的，增加Memstore大小并不能有效提升写入速度，为什么还要将数据存入Memstore中呢？
- Memstore在内存中维持数据按照row key顺序排列，从而顺序写入磁盘
- 由于hdfs上的文件不可修改，为了让数据顺序存储从而提高读取率，HBase使用了LSM树结构来存储数据，数据会先在Memstore中整理成LSM树，最后再刷写到HFile上
需要注意一点：数据读取不一定都是先读取Memstore，再读取磁盘。一般在读取HBase数据时，我们会开启缓存机制BlockCache，读取数据时会先读取该缓存，获取不到数据时会读Memstore和HFile。
这也是笔者一直强调为什么HBase数据最终持久化到hdfs上，但读写性能却优于hdfs的主要原因之一：HBase通过多种机制将磁盘随机读写转为顺序读写。
多列族引起的问题和设计
HBase集群的每个region server会负责多个region，每个region又包含多个store，每个store包含Memstore和StoreFile。HBase表中，每个列族对应region中的一个store。默认情况下，只有一个region，当满足一定条件，region会进行分裂。如果一个HBase表中设置过多的列族，则可能引起以下问题：
- 一个region中存有多个store，当region分裂时导致多个列族数据存在于多个region中，查询某一列族数据会涉及多个region导致查询效率低（这一点在多个列族存储的数据不均匀时尤为明显）
- 多个列族则对应有多个store，那么Memstore也会很多，因为Memstore存于内存，会导致内存的消耗过大
- HBase中的压缩和缓存flush是基于region的，当一个列族出现压缩或缓存刷新时会引起其他列族做同样的操作，列族过多时会涉及大量的IO开销
所以，我们在设计HBase表的列族时，遵循以下几个主要原则，以减少文件的IO、寻址时间：
- 列族数量，要尽可能的少
- 列族名字可读性好，但不能过长。原因可类比于HBase row key设计原则
关联文章：
关注微信公众号：大数据学习与分享，获取更对技术干货
