深度理解篇之HBase结构原理-个人拙见

HBase

HBase是一个存储层，在大数据的储存层里有HDFS，为什么有HBase呢？HDFS是线性的批量的，加载的IO性能会好一点，HDFS不支持修改，不能随机的修改，那么HBase是怎样的一个模型呢？第一它首先支持随机的读和写，你想修改HBase中的某一条数据，只要根据rowkey,立马就可以进行修改，这就说HBase修改能力是有的，在大数据的整个生态当中，一定会有批量计算，一定会有随机读写，所以说HBase和HDFS各自占了大数据的存储层的一部分，基于这点可以开发出基于这两个储存层开发出不同的应用。

HBase来源于Google的BigTable，中文翻译“大表”，大是什么意思呢？数据存储量大，支持千万行、百万列。意味着这个表格会很宽、很大，而且查询速度快，从表面上我们从“大”和速度快感觉是矛盾的，比如说关系型数据库中，表很大很大活着存储数据很多时，并发查询的时候这个性能是急剧下降的。

为什么HBase会解决这个问题呢？

主要有这几个层次来说

第一个层次是他的模型层，就是将这张大的表水平、垂直进行切割，水平切割将这个大表切成了Regoin，Regoin是大表水平切割出来的一个单位，这个Regoin会放到RegoinSever中，好比说是block块，RegoinServer就是datanode。垂直怎么切割的呢？垂直将大表切割成列族ColumnFamily，因为我们在建关系型数据库表的时候，会建表的名字和列的名字，但在建HBase表的时候，是不需要建列的，但一定要给出表名和列族的名称。

在关系型数据库中，垂直切割就是它的范式，就是数据库的三范式，比如说吧一个基本用户信息表，一个用户信息表有很多的列，很宽，比如说这个表中有姓名、住址、身份证号、还有专业，如果这个人的专业有很多，两个或者三个专业，那么在表中数据的表现形式是两到三行，但是就造成了其他列就冗余了，这个表会变大，我们知道关系型数据库变大的话，造成了查询效率会很慢，所以说在关系型数据库中有范一，范二，范三这种概念，所以在关系型数据库中怎么去设计这张表呢？我们会将这张表分成若干表，比如把他基本信息作为一张表，专业作为一张表，那么这里面就有一个关联键就是id,那么在基本信息表中一个人对应的数据都变成了一条了，不会重复了，在专业表里面专业是多个，但对应着同一个人的id,查询的时候速度也就提升了，那么这里面最主要的特征显示在哪呢？就是要解决IO问题，如果只查询基本信息，那么将专业这个信息是不会要的，在关系型数据库中也对表做了一个垂直切割，而这点正好是HBase中列族设计的依据，由于一个列族是对应着一个文件，在公司里，如果把列族设计的非常好，就是把基本信息字段往列族中插，吧其他的冗余字段查到另外一个列族，那么未来使用系统的某个用户查看某个维度的时候，有可能只会读取某个文件，其他文件是不会动的，这就可关系型数据库的范式很相似了，所以说她垂直切的是列族，水平且的是Regoin,如果有一张表，里面的字段有个1-1000，那么可以每100个切成一个Regoin，1-100，100-200...,就会形成很多的Regoin,这些Regoin是要分散地储存在不同的Regoinserver里面，这样体现了分布式，因为将它仍在同一个Regoin中效率会很低，这中方式很像我们的HDFS,HDFS中有很多的数据块，HBase中有很多的Regoin，块会加载到集群，Regoin也会加载到集群，那么并发读写的时候，在读取不同的key的时候，就会联系各自的RegoinServer,所以这点是很好的，抗并发能力是很强的，在这里面还有在查询数据要关注性能和速度，HBase中只做了一级索引rowkey，所以说这点是HBase的一个弊端，没有二级索引,如查询的时候不是查询某一个列的话，他会转换为并行计算，因为查询列的话会全表扫描，并且所有的Regoin会参与进来，所以说这种情况下，性能会降低。这时候我们知道了，在HBase模型当中，会进行水平切分和垂直切分，会达到集群分布式，（这些关系型数据都可以做到的），如果只有这些特点的话HBase会被替代的，那么什么才是他的独特的呢？在存储这个环节领域当中追求的是速度，那么什么数据块速度是最快的呢,当然是内存数据库了，比如说redis,memcache,但是内存数据库有一个天生的不可逆的弊端，就是内存大小是有固定上限的，成本也是硬伤，说白了在分布式的HBase当中，如果集成了内存的优势，能够规避内存的、很成本的话，那么就是比关系型数据库优势的点，是什么呢？内存+磁盘，HBase在存数据的时候，会优先存到内存，内存存满了，达到一定的阈值之后，才会flush到磁盘中，其实可以将Hbase粗略的想成“半内存数据库”,如果HBase中rowkey的设计是非常巧妙的话，用户在读取数据的时候是非常快的，对于经常读的数据，会在内存中，不经常使用的会落地到磁盘中，大部门用户的热访问数据会基于内存的速度是毫秒级的，所以那时就可以将HBase想成内存数据库了，因为只有一小撮人的请求，会触发IO，大部分人是直接通过内存读，不会触发IO的，在做架构师的时候，我们一定会类比实现，oracle、Hbase、redis等等，redis会耗费内存，mysql是将数据先存到磁盘，进行回滚的的数据，那么可以向Hbase是以成功的方案了， 索引没有你关系型数据强，综合查询没有你强，内存有不像redis一样完全基于内存，但是HBase的这种设计一定会在某一个集合内，只做这种简单快速的查询，一定是抗病发，支持数据无线增长，所以说HBase有了一定的优势了。所以说在模型的这个维度就有三点：

1. 垂直且分，列族
2. 水平切分，Regoin，打散到分布式节点这个概念
3. 这个模型是充分利用内存的。

当内存满了之后，内存中的数据会flush持久化到磁盘，准备储存新的数据，那么数据持久化到哪去？HBase这个Regoin比如说一个G,快满了，会flush到哪去了?hdfs,本地文件系统，一般都是那他和HDFS一起使用，那么有一个问题了？是不是意味着HDFS是在HBase之上吗？可以这么说，但是他只是借用了HDFS的存储能力，HDFS存储的特征什么呢？顺序append追加，顺序写，批量加载的能力好，但是不止这点，HDFS还有一个非常强的优势是什么呢？副本放置策略和写流程（写流程中的Pipeline模式），写一个数据块他是优先写到本机了，由于他有副本别的机器也有的，别的机器也有并不是客户端向这个Regoin写一份，向另一个 机器写一份，而是只需要向本机写，本机会通过pipeline向别的RegoinSever去扔，去存，所以本地写完，而副本的拷贝对于客户端就是透明的了。所以说HBase为什么技术选型的时候，为什么选的是HDFS了，因为他要的就是这个特征，当有了这个特征之后，这个特征会解决什么问题呢？数据安全问题，如果当客户端向内存中写入数据，溢写到磁盘，也就是说写到了HDFS中，HDFS会有副本机制，如果这台RegoinServer宕机时，Master由于和RegoinServer保持心跳，那么Master检测到RegoinSever的宕机，那么Master会将挂掉的RegoinSever中的Regoin在其他RegoinServer中进行复活，复活的成本高吗？不高，由于Master知道挂掉的RegoinServer中的Regoin在哪台节点上，知道他的location信息，所以只需要告诉健康状态良好的RegoinServer,去指定目录找Regoin就行了，然后进行恢复Regoin，而在恢复的过程中，会要将RegoinServer加载到内存中吗？不会的！！！这里会有HLog的概念，在每次写数据（向memstore写）的时候，会向HLog中写一份数据，被flush下来的时候会存储到HDFS,flush掉的东西代表原来的数据，新加的东西代表刚写到内存中的数据，则恢复的时候，只需要恢复日志，只需要恢复丢失的那一部分数据就行了，所以说恢复过程也是很快的。

除了HBASE数据恢复还有就是数据的迁移或者说分裂，当一个Regoin存了rowkey1-100,在这个区间之内，存了很多数据，Regoin要一变二，从中间分开了，分开的Regoin一定是1-50和50-100着两个Regoin，分两个Regoin的成本高吗？不高，因为这个数据在HDFS中是flush过了，HDFS有一个offset偏移量的概念，是不是可以偏移到50-100。所以分裂的时候，第一台Regoin指向了1-50，另一个指向副本的51-100，不需要重新加载到内存，如果当用户查询的时候查询到这个数据，要加载到磁盘，只需要根据offset将数据读出来就行了，它的内存里面有个读缓存，还有一个写缓冲，新增的数据直接增加，没有的从查询放到内存.

就是充分利用了HDFS特别重要的几个特点。所以迁移的成本并不是屋里拷贝，如果我这个RegoinServer里存了一个G的数据，我要把它各变成两个500M，并不是本机将它拿出来直接切成500M，把另外500M拷贝到另外一台RegoinSever上，并不是这样的，因为巧妙地利用的HDFS。

物理层面：

模型方面完了，那么物理方面呢？那么抽象的这个表，垂直水平切分的这个Regoin是怎么维护的呢？它的架构当中有那些角色维护的呢？是HBase中的Master这个角色来维护的，维护RegoinServer的生命周期，而对于Master主从架构我们会想到HA高可用，一致性，怎么去维护RegoinServer的健康状态，等信息呢？当然是第三方的分布式协调服务zookeeper了，Master其实就是监控着RegoinSever的声明周期，如果有RegoinServer挂机了，那么Master会监控到，那么Master会触发其他的几个RegoinServer去读写挂掉的那个RegoinServer下的Regoin,直接复活即可，Master起始就是监控这RegoinSever的生命周期,并且管理这些角色。

Master就是维护这RegoinSever的声明周期，告诉其他的RegoinServer去哪加载，复活Regoin，这个架构很像HDFS,namenode和datanode,但是，HDFS中的namenode只存储元数据，但是HBase存储元数据吗？不存的，是存在RegoinServer里面的，所以说HBase和HDFS是由区别的，Master只是维护着RegoinSever的声明周期，是不存元数据的，那么他的元数据在哪呢？他的元数据在某些RegoinServer中，首先明白HBase元数据是什么东西呢？比如数建了一张表，每个Regoin会有自己的区间，数据存储的开始和结束，那么这些开始到结束的记录就是元数据，元数据被HBse默认存在他自己创建的meta表中，也是存在HBase表里面的，HBase坏境搭建的时候就已经创建了，如果新创建了一张表，那么这个meta表中会有记录，如果这个表多了分区，那么meta又多了一条记录，公司了创建了很多的表，有很多的分区，那么元数据表也会很大，只要是HBase表，无论是元数据表还是普通的数据表，都会对应着里层面的Regoin,所以说原数据表也是散落在RegoinServer中的，但是不管怎么样，用户查询速度是很快的，这样可以看出，元数据是以HBase表的形式存储的，而且他也是有Regoin划分的概念，但是这就牵扯到一个问题，这个表是放在哪个RegoinServer呢，怎找到呢？当然是由zookeeper中的节点来记录这个元数据表的寻址，这些原数据表meta表，客户端只要从zookeeper中进行访问，通过zookeeper，来寻找各个表，来取数据。