HBase基本原理，
1、HBase的架构
采用Master/Slave架构搭建集群，由以下节点组成
HMaster节点
1）管理HRegionServer，实现其负载均衡；
2）管理和分配HRegion；
3）实现DDL（增删改）操作。
HRegionServer节点
1）存放和管理本地HRegion；
2）与HDFS进行读写交互；
3）与客户端进行读写交互。
ZooKeeper集群
1）存放整个HBase集群的元数据以及集群的状态信息；
2）实现HBase的高可用。
2、hbase:meta表
在HBase内部保留着名为hbase:meta的特殊目录（catalog table）。该目录维护着当前集群上所有区域的列表、状态和位置。表中的项使用区域名作为键，区域名由所属的表名、区域的起始行、区域的创建时间以及对其整体进行的MD5哈希值（即对表名、起始行、创建时间戳进行哈希后的结果）组成的。
3、Region的划分
HBase自动把表水平的划分成区域（region），每个区域都是表的子集，一个区域是包含其第一行到其最后一行（不包括）。
4、HBase的写流程
1）客户端发起写请求，从hbase:meta表中查到要找的HRegionServer；
2）将请求发送给HRegionServer，将操作写入WAL（Write Ahead Log）日志（flush到磁盘中）；
3）HRegionServer根据请求中的TableName和RowKey找到对应的Region，并根据列族找到对应的HStore；
4）将操作写入到HStore的memStore中，并且将操作结果返回给客户端。
写操作是直接写入到内存中的
5、MemStore的Flush动作
有三种情况触发：
1）当某个MemStore的大小超过了默认值128M，此时该MemStore中的内容会Flush到StoreFile中；
2）当RegionServer服务器上所有的MemStore的大小超过了默认35%的内存使用量，此时当前RegionServer中的MemStore可能都会被Flush，一般从最大的开始；
3）当前RegionServer中WAL的大小超过了1GB（blocksize*logs=32*32），当前RegionServer中的HRegion的MemStore都会Flush。
6、HBase的读流程
对于相同的数据可能存在三个位置：新写入的数据存在于MemStore中、Flush之后存在于StoreFile中、刚读取过的存在于BlockCache中。
所以读取时顺序读取：BlockCache、MemStore、StoreFile（这个顺序减少了磁盘IO）。
放一张来自叶尚青老师的表格图
7、压缩（Compaction）机制
过多的StoreFile文件会引起读的性能问题，为此出现了压缩机制，有两种：Minor Compaction和Major Compaction。
Minor Compaction：是将一些小的、相邻的StoreFile合并成一个更大的StoreFile，不会处理已经Deleted或Expired（过期）的数据；
Major Compaction：是将所有的StoreFile合并成一个StoreFile，会删除掉以被标记为Deleted的数据，丢弃Expired的数据。
补充：HBase默认使用Minor Compaction，因为Major Compaction会产生大量的磁盘IO。
8、HBase中RowKey设计
1）尽量散列：实现负载均衡。避免某些热点数据集中到一个Region；
2）长度尽量短且长度一致：提高内存利用率，保证字典顺序的有序性；
3）唯一；
4）建议使用String类型：保证通用性；
5）设计的有意义
9、Bloom Filter（布隆过滤器）的简要理解（实现原理请自行百度）
实际是一个很长的二机制向量和一系列的随机映射函数（Hash函数）。
使用布隆过滤器可以快速判断某个Key对应的Value是否存在，减少不必要的磁盘IO，但会增加内存消耗。
缺点：误算率
因此，Bloom Filter通常应用在一些需要快速判断某个元素是否属于集合，但是并不严格要求100%正确的场合。此外，引入布隆过滤器会带来一定的内存消耗。