一、Hbase原理
逻辑视图
Hbase 表的特点
LSM三层存储
hbase会将数据先写到内存中，内存满了会将数据刷写到文件中。
但是如果数据量大的话，时间一长，就会有很多次的刷写，带来大量的磁盘操作的IO。这个问题怎么解？
Hbase会定期将磁盘上的小文件进行合并，合并成大文件。这样的话，小文件会慢慢变成大文件，这样的大文件就适合存储在HDFS中了。
就跟洗袜子一样，袜子先放盆里，盆满了放桶里面，桶满了才去洗衣机洗；Hbase是数据先写内存，到一定大小写到文件中，将多个小文件合并成大文件后再写入到HDFS中进行实际存储。
数据一开始存在内存中，如果机器突然挂了，数据不就丢失了么，这个问题Hbase是怎么解的？
这里Hbase采用了跟HDFS类似的原理，他运用到了wal预写日志的思想：hbase也会将数据的操作先写日志，然后存到内存，哪天机器挂了，内存丢了，还能从WAL日志中将数据恢复。
Hbase的WAL机制通过日志恢复策略，保证了内存中的数据不会丢失。
Hbase集群架构
一个 HBase 集群一般由一个 Master 和多个 RegionServer 组成。
- 客户端库：可以通过 HBase 提供的各式语言API 库访问集群。
- API 库也会维护一个本地缓存来加快对 HBase 对访问，比如缓存中记录着 Region 的位置信息。
- Maste 节点：主要为各个 RegionServer 分配 Region，负责 RegionServer 对负载均衡，管理用户对于 Table 对 CRUD 操作。
- RegionServer：维护 Region，处理对这些 Region 对IO 请求，负责切分在运行过程中变过大的 Region。
下图是Hbase集群中的组件图：
下图是Hbase的架构图，双HMaster组成高可用，HRegionServer存储数据。
hbase的架构似乎也是master-slave架构，和hdfs有点像，HMaster是用来管理集群，HRegionServer是真正存储数据的地方。
Hbase在数据查询和写入的时候，其实并不是像hdfs那样询问HMaster。在hbase中，每一张表都会有元信息，这些信息也是被存储为hbase表，称为元信息表，也叫meta表，这是一种系统表。所以hbase总是先查询meta表，然后就知道数据存储在哪个HRegionServer上了。
既然meta表也是存储在hbase上，那么hbase又如何知道meta表存在哪个HRegionServer上呢？这岂不是一个鸡生蛋蛋生鸡的问题？
meta表是hbase表，是指meta表也是用rowkey和value的键值存储，但是并没有说meta表在hbase上啊。其实meta表不是存储在HRegionServer上，而是存储在那个分布式协调服务zookeeper上面。
所以meta表其实是在一个固定地方读取，然后根据meta表就知道数据在哪个HRegionServer上。但是zookeeper又是啥呢？
zookeeper是分布式系统中非常重要的组件，主要用于分布式系统间的协调选主，还有一些公共的集群元信息的存储。
Hbase 中的Master有什么作用？
HMaster的任务相对不繁重，但是却比较重要，它主要是通过调整和管理Region分布来实现HRegionServer的负载均衡。
HRegionServer架构
Region是hbase在rowkey上的切分，每个Region都可以通过startKey和endKey来确定rowkey的范围，一个HRegionServer上可能会有多个Region。
把Rowkey分成几块，每一块会形成一个Region，每一个Region分布在一个RegionServer上。
表的横向切分
- Table中所有的行都是按照row key的字典序排列的。例如，rowkey 1,2,10的排列顺序为1，10，2。
- Table在行的方向上分为多个region。
- Region具有最大值，达到阈值会等分为两个region。
- Region是Hbase实现横向扩展和负载均衡功能的基本单元，不同的Region分布到不同的RegionServer，Region与RegionServer之间是多对多的关系。
数据是根据rowkey和一定的哈希规则，分散到不同的Region上面，而Region又是属于某一个HRegionServer上的。通过这里其实可以得出rowkey设计的另一个原则，就是散列性，rowkey的头几个字母，最好不要是一样的，不然会分布在同一个HRegionServer上面，导致这个HRegionServer的负载非常高，累死累活，其他HRegionServer却没事干。一般可以根据一定规则算一个数据的摘要，比如md5，把md5的头几位拼在rowkey的前面。
下图是RegionServer中的主要组件及其架构图：
一个 Region 是由一个或多个 Store 组成。每一个 Store 其实就是一个列族。每个Store 又是由一个 memStore 和 0 个或者多个 storeFile 组成。memStore 是存储在内存中，是LSM中的第一层，storeFile 是存储在 HDFS 中，这里StoreFile只是一个名字，它是以HFile的格式存储在hdfs上，HFile是一个存储格式，在新版本的HFile存储格式中，它就是一个类似B+树的索引索引形式。数据都会先写入memStore，一旦 memStore 超过给的的最大值之后，HBase 就会将memStore 持久化为 storeFile。Hlog是借鉴了之前提到的WAL的思想，防止机器挂掉以后，memStore内存中的文件丢失。
Hbase读写流程
Hbase写流程
1、hbase client要写输入了，先从zookeeper中拿到meta表信息，根据数据的rowkey找到应该往哪个RegionServer写
2、然后hbase会将数据写入对应RegionServer的内存MemStore中，同时记录操作日志WAL
3、当MemStore超过一定阈值，就会将内存MemStore中的数据刷写到硬盘上，形成StoreFile
4、在触发了一定条件的时候，小的StoreFile会进行合并，变成大的StoreFile，有利于hdfs存储
Hmaster的作用是什么？
当大量rowkey相近的数据都被分配到一个Region中，导致这个Region数据过大的时候，Region进行拆分，HMaster会对拆分后的Region重新分配RegionServer，这是HMaster的负载均衡策略。
Hbase读流程
1、hbase client要读数据了，先从zookeeper中拿到meta表信息，根据要查的rowkey找到对应的数据在哪些RegionServer上
2、分别在这些RegionServer上根据列簇进行StoreFile和MemStore的查找，得到很多key-value结构的数据
3、根据数据的版本找到最新数据进行返回
二、Hbase的优缺点与适用场景分析
优点：
- 十万行、百万类的海量数据存储
- 支持百万级别高并发写入
- 支持实时查询
- 适合稀疏数据的存储
缺点：
- Hbase对于事务的支持比mysql差多了。
OLAP VS OLTP
- OLTP应用做联机事务处理应用，就是类似银行转账类的业务，对于事务要求比较高，适合mysql这一类的数据库；
- OLAP应用叫联机分析处理应用，比如推荐系统，是在收集了大量用户行为后进行分析，再得出结论的应用，主要侧重分析，对事务要求非常低，适合hbase这一类的数据库。
三、总结
1、hbase是列式存储，和mysql的行式存储不一样
2、hbase中有列簇概念，同一个列簇下的列存储在一起，在Region的一个StoreFile中
3、hbase是按照rowkey进行查找，要查询的字段要想办法放到rowkey中
4、hbase内部使用LSM三层模型进行存储，数据先写到内存MemStore中，内存达到一定阈值再刷写到硬盘StoreFile中，再满足一定条件时，小的StoreFile会合并为大的StoreFile
5、hbase适合OLAP类的应用
