HBase进阶
RegionServer简易版本架构
在我们的Hbase中，一个Region的概念，我们HBase中的每个表进行横向拆分，拆分完毕之后呢，形成分区的概念，我们成为Region
Region当中应该有什么呢？一个Region当中应该有几个Store呢？有几个Store是列族决定的
下图中我们有四个Region，说明一个表，分成了四个Region。两个列族。每一个但愿交给一个Store存储。每一个Region中有两个Store
按照我们之前理解的，Store是存储数据的东西，我们Store下面应该有什么呢？是不是文件呢？就是StoreFile。
那么Store在哪里呢？Store其实是在HDFS上。
我们的Region，是一个逻辑结构，一个分区，那这个Region落实到HBase框架上面，那这个Region应该在什么地方？说白了，谁来管理这个Region呢？这里牵扯出一个概念，就是RegionServer。
我们和HDFS上做对比，HDFS上有什么？有NameNode，DataNode，那么我们HBase上有什么呢？有Master，有RegionServer，有这个服务。
那么Region有什么作用呢？它有两类作用，一类是对数据的作用，还有一类就是对这个Region的作用。
那么它对数据有什么作用呢？有get，put，delete，实际上就是对数据的操作，get查数据，put插入，放数据，delete删除数据，说白了就是对数据进行增删改查。那么它对数据增删改查的时候它到底是怎么发挥作用的呢？我甭管增删改查我都得有RowKey，拿数据需要RowKey，放的时候也要，他是这样的，首先我判断数据在哪个Region，怎么判断的呢？是因为RowKey都有自己的范围，我们根据范围来找到对应的RowKey。找到Region之后，他会看一看这个Region是哪个RegionServer在管理，RegionServer会根据Region中的列族，列名，来找这个数据，后面我们会详细的说。
他对Region有什么作用呢？有SplitRegion分裂Region，还有CompactRegion，CompactRegion我们回头说，先说一下这个分裂。我们知道，HBase中的Region是分开的，那它是怎么分的呢？是HBase自己分的？还是怎么分的呢？
两种，一种是HBase自动分裂，我们在HBase种建立一张表，默认只有一个Region,随着数据的增加，达到一定的阈值之后呢，HBase会自动的将一个Region分裂成两个Region。两个Region各有原来Region一半的数据。谁给它分的呢？就是RegionServer负责的。第二种，建表的时候，我们指定这张表有几个Region。这个就是预分区，建表的时候有几个Region。
我们每个RegionServer都会管理多个Region，每个Region下面都会有多个Store，每个Store中都会有StoreFile，那么这个StoreFile数存储数据的，它与RegionSrever有没有什么必然的关系呢？实际上是没有的，我们说过了StoreFile存储在HDFS上了。
我们顺带着说一下高可用问题，我们既然是一个架构，那必然会有可靠的性能才行，我们设想一个问题，RegionServer会不会挂掉，我们挂掉之后，HBase还能正常工作么？如果挂了我们HBase又是怎么做的呢？他会将这个RegionServer中的Region分配到其他的RegionServer当中。当我们再查挂掉的RegionServer中的Region就不会向老的RegionServer发送请求，因为都被转移走了，会给新的RegionServer发送请求。那我如果将RegionServer中的Region转移走之后会不会对StoreFile这个数据有影响？不会的，因为它存储再HDFS上了，还有副本策略，所以我们的数据是非常可靠的。
那么谁来完成这个Region的转移工作呢？又要引出一个角色，就是Master。
Master是我们HBase中的另外一个服务，它也有两个操作，一个是对表的操作，create，alter，delete，还有一个是RegionServer，监控RegionServer的状态，分配Region到哪个RegionServer中去。他是怎么完成这两个功能的呢？通过ZK来完成。RegionServer会去zk中进行注册，Master会监控zk上面对应的RegionServer节点，一旦RegionServer挂掉，zk上面的RegionServer临时节点将消失，Master会立刻发现，采取相应的措施。
那么我们Master挂了怎么办？我们HBase支持高可用，会预备多个Master的。
RegionServer详细版本架构
我们上面已经讲了一个简单的架构，为什么显得不完整呢？主要体现在哪里不完整呢？主要体现在RegionServer不完整，我们的RegionServer架构远比我们之前上面画的那个架构复杂的多，里面好多组件我们都没有提，我们现在提一下。
我们RegionServer在我们的集群中可能又多台，这次我们只用一个RegionServer来表达我们想要的效果，看图： 一个RegionServer中又多个Region，因为一个表中可能会有多个列族，有几个列族就有几个Store，所以每个Region中又有多个Store，Store下面又有Store File。StoreFile存储在哪里了？存储在HDFS上了
我们之前的最上面的那个图，有些地方还是自相矛盾的，哪里矛盾了呢？
我们HBase中表的数据是按照RowKey字典顺序进行排序的，如图：
我们如果修改一条数据，直接再它最后面追加一条数据就够了，而不是直接修改数据。我可能在最后面追加一条row_key1,或者row_key2，那我们文件中的Rowkey还是有序的么？那就不是有序的了呀。会出现两个row_key1,或者两个row_key2等等这种情况，还不算，一个在开头，一个在末尾，所以我们之前的哪个图，是有些矛盾的，但是为了方便大家的理解，就画了个简单的图，了解完毕之后，我们来深入探讨一下，纠正一下，来稳固一下。矛盾的原因也是因为还有一些HBase的组件没有见到，我们一起来看一下。
首先我们来认识一个新的组件叫做MemStore。
我们这个MemStore画在哪里了呢？是不是都画在了每一个Store中了呢？我们的每个Store是我们的Region中的一个列族，每一个Store中都有一个MemStore，Mem代表内存的意思，也就是说这是一个内存组件，我们称之为，写缓存。也就是说，我们向这个HBase写入数据的时候，实际上不是直接追加到StoreFile这个文件当中的，而是先进入到写缓存MemStore中，那什么时候从我们的MemStore写入到我们的StoreFile文件当中呢？首先，我们的数据回先写道MemStore中，对应的列族写道对应的Store中的MemStore中，MemStore它并不是无穷大的，它是有一个阈值的，比如说128兆，假如我的数据在MemStore中达到了128兆，我就会干什么呢？就会flash(刷写)，将数据从内存中刷写道StoreFile中，在内存当中，我们的数据是能够排序的，也就是说，我们的数据写到MemStore中的时候，它就是有序的了，按照RowKey排序，排完序，到达一定阈值之后，就会刷写到StoreFile中。
我们注意一下，我们的这个MemStore在进行数据刷写到StoreFile中的这个过程，会不会Flash(刷写)很多次？只要一满了就会刷，一满了就会刷。注意！！！每次刷写，都会形成新的StoreFile。也就是说，我们的一个Store下是会有多个StoreFile的，而且牢牢记住StoreFile就是HDFS上的一个文件。它存储在HDFS上。
它这么设计会有什么好处呢？完试在内存当中排好序，然后批量的写，100多兆数据我一次性写道磁盘文件上。机械硬盘有个特点，就是我们批量顺序写入的时候，我的写是非常快的，随机的去写那就比较慢，所以我们不用担心写的速度。
那么这么设计的话，我们想一想会不会有什么问题？我们写数据时向内存中写，假设写了128兆，这128兆都在内存中，满了就写入磁盘，那么大家想一想，我100多兆数据放内存中是不是不太安全呢？每次我们写到一定程度进行Flash，假如我们还没有达到128，就写了110兆，还没来得及Flash，RegionServer就故障了，数据是不是就丢了呀，那我们怎么办呢？我们这时，会有一个预写日志这样一个东西。它会记录我们的操作，我们往HBase中写数据的时候，谁负责？是不是RegionServer负责，其实我们RegionServer它还维护着一个文件， 这个文件叫做WAL，全称Write-Ahead logfile
预写日志。也就是说，我们真正写入数据的时候，第一时间现在不是写入MemStroe了，而时写入到WAL中先记录一下操作比如put、delete、get这些操作，会顺序的追加到我们的WAL当中，每来一个操作就会追加到这个文件里，每来一个操作就追加到这个文件里，我们记录这些操作之后，这个数据就相当于完成写操作了。已经变的可靠了。这时候我才会根据WAL预写日志中的操作写到对应的MemStore中，然后达到阈值之后，再进行Flash到我的StoreFile中。
我们设想一下，我们已经将数据写入到MemStore中，但是还没有Flash，我的RegionServer又挂了，这个时候我们是不是不用慌了？因为我有WAL记录，打不拉我将预写日志再回放一遍就可以了。这就是RegionServer中预写日志中的作用。WAL也是文件，它也在HDFS上存放。当然这个也是可以自己配置的，也可以配置到自己的本地磁盘文件上。我们通常就用HDFS。比较可靠
我们梳理一下：我们写入数据的时候第一时间写入WAL中，形式是追加，速度非常快，不是随机的写入，写完之后，再向对应的MemStore去写，MenStore达到了一定大小一定的时机才会进行Flash写入到HDFS中的磁盘文件上，每次Flash都会生成一个新文件。
我们还有一个组件叫做Block Cache，我们的Block Cache也是一个内存组件，我们称之为读缓存
MemStore是写缓存，我们的Block Cache是读缓存，那它为什么叫做Block Cache呢？Block是块的意思，这个Block 与我们之前学过的HDFS中的Block有没有什么关系？可以很负责的说，毛关系都没有，一点关系都没有，别整错了。这个Block Cache是我们HFile也就是StoreFile中的一个重要的组件。
我们简单的说一下StoreFile内部结构大体是什么样的。一个HFile也就是StoreFile它每部会有很多很多个小块儿，这些小块叫做Block
那么一个Block的默认大小是多少呢？是64KB，这个大小我们也可以自己调，每个小块里面存储的都是KV键值对儿。
那为什么内部会有这么多小块儿呢？实际上是为了加速我们的一个查询效率。有了小块儿我们就可以有索引了，索引里面也是有KV的，其中的V，就是我们文件中对应的小块儿，而K对应的就是我们RowKey的一个范围。都会有相应的索引指向我们的小块儿
那我们设想一下，我们再找数据的时候，也就是读取数据的时候，扫描HFile的时候，拿着我们手中的RowKey，先拿到HFile的索引，然后对比手中的RowKey，看看我手中的RowKey再哪一个小块儿当中，然后找到小块儿，根据索引一次性定位到小块儿，将小块儿的数据读出来，读出来就是我们想要的数据。当然这个图是我们简化了的，HFile中还有什么布隆过滤器我们没画，晚点我们再说。
那么我们的Block Cache到底是干什么的呢？它主要干了这么一件事，我们的HBase再读取HFile的时候，定位到文件中的某一个块儿之后，它不会直接去读取这个文件的块儿，他会先去Block Cache内存中看看，有没有我想要的这个块儿，如果有说明我命中缓存了，直接从内存中拿，如果没有我就只能去读取文件了，但是，读取文件读出来之后我第一件事要做的是，将这个文件放到我的Block Cache缓冲中，方便下一次读取这个文件，可以直接从内存中拿，这样会提高效率。Block Cache中的Block指的是我们文件中的Block，这一点要记住。
我们还有一个问题，就是我们的Block Cache毕竟是内存组件，如果每次我们读取文件都往里面放，我总有一天会放满了，这可怎么办呢？其实我们的Block Cache有一个策略的叫做LRU策略，这个策略是清除的一个策略，他会将Block Cache中访问最少的，放进去最早的Block 定时清除，将访问次数比较高的，刚放进去的这样的块儿，给它留下。
以上就是RegionServer完整架构，每个RegionServer都是这样的架构。
三里屯的回忆
我们再次梳理一下：我们写入数据的时候第一时间写入WAL中，形式是追加，速度非常快，不是随机的写入，写完之后，再向对应的MemStore去写，MenStore达到了一定大小一定的时机才会进行Flash写入到HDFS中的磁盘文件上，每次Flash都会生成一个新文件。每个RegionServer服务多个Region，每个RegionServer中有多个Store，1个WAL、1个Block Cache，每个Store对应一个列族，包含MemStore和StoreFile。