360 hbase二级索引总结

1、查询

  客户端并行的向表的所有region发一个请求，然后每个region在server端会对数据进行检索和查询以及数据获取并把最终结果返回给客户端。客户端获取到各个region上检索的结果之后，会对结果进行合并和排序。

2、建索引

  客户端把请求发给各个region，各个region根据索引说明构建好索引，并将索引存储进去。

整体的过程都是分布式和并发式的构建。

3、采用了数据与索引在同一个表的同一个region上
   华为的方案是数据和索引在不同的表里，但是数据region和索引region要一一对应并且在同一个regionserver上。
   
   华为这种方案的缺点：
       （1）、splite是必须保证数据region和索引region的切分点逻辑上必须一样。
  （2）、在region分配的时候保证数据region与索引region在同一台server上，才能高效的本地取数据。
  （3）、分成两张表写数据时要考虑一致性问题（数据和索引的一致）。
所以360选择了将数据和索引放在一个表里，并且数据和索引在同一个region上。

4、索引的说明

  保存在表的schema中，用单独的一个family存储（index）。

动态增加索引是通过索引重建的方式来做的。

5、写路径        

 在插入数据时根据表对应的索引说明构建出索引数据，然后和数据一起放在一个put对象中，后续的流程和hbase原始的一样。

  这样的设计不存储索引和原始数据一致性问题，要么一个put全成功要么全失败。

6、读路径
    总共两个步骤，第一步创建一个scanner，第二步取数据。

下面ppt讲的是创建scnner的过程
第一步构建scnner把rowkey找到，这里会设置cache，检索一批（避免一个一个检索的低效）
当客户端想做查询的时候，首先创建一个scanner(360扩展了scanner对象，让其支持了conditions set),指定一个condition。然后客户端发现请求给regionserver，regionserver接收到请求后首先构建一棵检索树（构建书的规则是，首先是条件直接关系，比如下图，首先是or条件，然后下面挂了两个Leaf,这个两个Leaf分别对应不同的条件。这种关系可以继续往上累加。这棵树的数据是在index family里面，和原有的数据没有关系。每个Leaf的数据下面会挂一个ss(store scanner),这样可以针对每个ss做一个start row和end row查询。每个scanner把他相应的数据取到之后会做一个逻辑的or关系，最后返回给用户）。

第二步查询：
根据rowkey去seek原始数据。

7、分裂
   分裂后在compaction的时候，讲第二个daugther的索引的rowkey调整一下就好了。
   分裂后在compaction前，只是建立的daugther的引用，这个时候如果查询daugther的时候，做一个转换，将查询转换为parent上的查询就可以了（这里的转换包括数据rowkey的调整）。
   
8、索引重建
    索引是有垃圾数据的，hbase支持对行的覆盖写，如果version是3的话，一行覆盖了4，，那么最早的那个数据它的索引是会残留的。
因为索引数据都是展成row-key了，他的版本只是1，他没有被覆盖，只是产生了4个key-value.其中有一个key-value是无效的。需要清理这个无效的key-value.
最后的解决方案是，定期的给索引慢慢的rebuild一次。也能解决这个垃圾问题。
它的重建流程就像compaction一样，在重建之前记录当前的所以索引文件，将原有的数据扫描一遍（以region为单位），对于有索引的列，把它的索引重建出来，最后把之前记录原有的索引文件删除掉，这样这个索引重建过程就结束了。
这个重建过程是比较耗时的，数据越大耗时越长，这个状态是用单独的hbase表跟踪，以防止有问题的时候的一个恢复问题。还有一个可视化界面查看重建过程。比如有1000个region，有一半的region重建完成它的状态就是50%。

9、优化
   （1）、因为360的查询基本都会带有时间范围，所以建立索引时他们字段会给建立的索引后再加上时间字段。
   （2）、索引的所以查询都是scan，用不上filter。这里引入的一个新的type：indexrow,这样在scan索引时就可以用到这个filter去过滤一些无用的文件。