HBase读写流程底层原理
读流程1
我们还是以三个RegionServer为例，一个客户端，一个zk。
我们读的时候肯定是要发get请求了。我们要通过Table，RowKey寻找数据，我们通过RowKey就可以判断出在哪个Region，然后通过Region就可以找到哪个RegionServer，然后我们客户端就可以通过RegionServer去读我们想要的数据了。实际上我们读的时候也是获取源数据表的信息，通过谁获取？通过zk，拿到源数据表的信息之后我们还是放到缓存中，方便下一次读取，然后我们根据元数据表中的信息，源数据表中记录了每一个RowKey的范围，也就是我们上一次说的起始位置，以及这个Region在哪个RegionServer上，然后我们就可以寻找到文件的所在位置，这样一来，我们就拿到数据了。
第一步还是客户端向zk去拿meta表所在位置，第二步zk给它返回所在位置信息。
客户端拿到元数据之后，会向对应的RegionServer请求，请求完毕之后我干嘛呢？我仍然继续缓存。这里的步骤和写流程的步骤其实是很像的。
拿到元数据信息后，还是老规矩，判断Region在哪里，数据在哪个Region上，然后我们根据Region判断在哪个RegionServer上。然后向对应的RegionServer发送get请求。
RegionServer收到请求之后，就会去系统中去给它拿想要的数据。我们的数据有可能在BlockCache中存储。所以我们下一步是去BlockCache中去看看。
也有可能在MemStore、或者StoreFile中，他会去这三个地方去找数据。
最后会将结果返回给客户端。
这里我们有一些细节没有体现出来，我们的RegionServer读取数据的时候，到底是怎么读取的，我们一起来看一下
读流程2
我们在读取最后三个组件的时候，是先读取谁后读取谁，我们把细节讲一下，我们这里有一个Merge过程，就是合并的过程。我们一起来看一下是怎么做的。我们下图中有客户端，RegionServer，还有RegionServer中Region下的HDFS文件HFile。
我们这个客户端想要获取数据肯定是要先找到里面的Region，然后看一下Region隶属于哪个RegionServer，我RegionServer接收到Get请求之后会怎么做呢？首先呢，它会去MemStore中以及HDFS的HFile中兆客户端所需要的数据，为什么呢？为什么RegionServer会去这两个地方去找数据呢？假如说，我前一段时间往HBase中插入一条数据，比如9999：info(列)，name里面，前一段时间写的是不是很有可能已经Flash到我的HFile中了呀，在哪个文件中呢？不知道，刚刚，我又往这个表里写了一条数据，9999：info，age这条数据，刚写的是不是应该在MemStore中呢？是不是还没有Flash呢？那么也就是说，写缓存MemStore中也有可能有这条数据里面的内容，那么我Get9999的时候，目标数据是不是有可能在File中也有可能在MemStore中呢，这就是去这两个地方找数据的原因。我们并不知道9999这条数据在哪个HFile中，有可能任意一个，有可能每个文件都有一点，所以我们在读取的时候要去所有的HFile中还有MemStore中读取这个数据。读取完之后，我们会进行一个merge，那么这个merge，它做了哪些操作呢？有可能我们获取一行数据然后发现他们有不同的列，我们合并到一行当中，还有一种可能，就是我查找数据的时候发现同一个列，它有多个版本，有可能修改数据，本来我在一个File中有数据，结果我改了，刚巧Flash到另一个文件中了都是有可能的。我可能查的时候发现同一个列会有多个版本，我们不可能将所有版本都给客户返回，所以我们根据需求返回几个版本的数据。或者发现数据中有删除标记，那么我们就不返回了。
那么，我们这么读文件效率是不是太低了呢，我们在MemStore中读取文件还好说，在HFile那么多文件，我们读取起来相当费劲了，在这里我们的HBase做了优化的，用来加快我们读的过程。
它这里会有一个过滤，过滤的是什么呢，是我们的HFile，根据三个条件去过滤数据，它不会全盘扫描所有的HFile。我们客户端在get也好scan也好，我们是可以指定timeRegion的，时间戳，我获取某一段时间的数据，每个HFile都有自己的属性，其中包括最小时间戳，最大时间戳，我们的RowKey也可以指定范围，那个范围有我想要的数据我就扫描哪里。
布隆过滤器也是过滤HFile的，直接拿RowKey过来交给布隆过滤器，看看HFile里面有没有想要的RowKey。关于布隆过滤器原理，后面会提。每个HFile都有一个自己的布隆过滤器。
我们缩小范围的去找数据，这样就可以提高效率。
我们其实读文件之前回去BlockCache中看看有没有我们想要的数据。有我直接拿，没有才去HFile中拿。
StoreFile Compaction
我们HDFS中的所有的HFile是不是都是MemStore刷写下来的文件呢
我们HDFS中的所有的HFile是不是都是MemStore刷写下来的文件呢，每一次MemStore刷写都会生成一批新文件，那么他这么做就会产生很多很多的小文件，还有一个就是我们读数据的时候会比较慢。我虽然过滤了一部分，但是我还是会扫描多个文件的，我唯一的办法就是让我读的文件少一些，我读的效率才会高一些，我们如果将文件合并，那么文件是不是就少了呢？那么我们合并的时候需要做什么事呢？我们是不是应该对文件排序，因为每个文件内部自己的是有序的，每个文件内部的RowKey是有序的，那么我们得保证合并完的文件整体式有序的，那这里我们用什么算法排序比较好呢？我们学过冒泡，快排等等，那么这里使用归并排序式比较好的，归并排序将有序的几个小集合合并成一个大集合，除此之外，我们还能做什么事呢？过期的数据可以去掉，Delete的版本可以删除
StoreFile Compaction合并压缩的意思，那我们压缩了是不是变相的数据变小了呢？那么这里有两种，Minor Compaction小合并，Major Compaction大合并。
假如我有十几个HFile，Minor Compaction只会挑选几个较小的小文件进行合并。Major Compaction是一个Store下面素有的HFile合并成一个大文件。
Compaction分为两种，分别是 和Major Compaction。Minor Compaction会将临近的若干个较小的HFile合并成一个较大的HFile，并清理掉部分过期和删除的数据。Major Compaction会将一个Store下的所有的HFile合并成一个大HFile，并且会清理掉所有过期和删除的数据
我Region要进行Flush
我Flush之后我都会生成一批小文件，然后我会对每个文件进行判断，看看是都有满足条件的HFile。判断条件为文件大小，文件的个数等等都是判断条件。满足条件就合并。
大合并是周期进行的，多久呢，默认是7天
他会将一个Region种的Store下的所有的HFile进行合并。
这个大合并记住，7天一次。合并的这个操作还是比较消耗性能的。