hbase partition split 源码读后感

随着数据量的增加，单个partition serve的数据越来越多，性能会逐渐变的糟糕，这时候partition split就闪亮登场了。

HBase的partition split可以通过命令行出发，实现在client/HBaseAdmin.java里面，其参数包含region，split pointer（Oracele里面的list partition定制化更强，允许指定PK list来进行partition，不过一般情况下用不到那么细的水平）

HRegionServer收到partition split 请求后，compactSplitThread.requestSplit会开启线程尝试进行split（compaction and split 看起来很像，有共同的入口，但是我想这这两者是不是直接能结合起来？），具体过程如下:

1.    Client发送split request到region server
2.    Region server收到split request后：首先做有效性检查，并选出split point
       a)    检查是否允许做split：如果文件中包含reference file（意味着刚刚发生过split），则不允许再次split
       b)    如果允许split，则挑选split point：挑选size最大的store file（相当于youchao文件），然后选择其middle-key，middle-key不是读一遍文件，而是直接从文件的index里面去找, Items[length/2]
       c)    确保parent region的状态不是close or closing，确保split point是有效的（min(key) < split point < max(key)）
3.    通过有效性检查并选出split point之后，正式开始split过程：
       a)    在zookeeper上创建ephemeral的entry指示parent region正在splitting
       b)    在parent region的文件夹中创建临时split dir
       c)    关闭parent region（会flush 所有memory store（memory file），等待active compaction结束），从现在开始parent region 不可服务
       d)    从本地server上offline parent region，每个region server都维护了一个valid region的list，该步将parent region从该list中移除
       e)    Split所有的store file（youchao file），这一步为每个文件做一个reference file，reference file由两部分组成：
              i.    第一部分是源文件的路径，第二部分是新的reference file引用源文件split key以及引用上半截还是下半截；
              ii.    举个例子：源文件是Table1/storefile.11，split point 是key1, 则split 成两个子文件可能可能是Table1/storefile.11.bottom.key1,

              Table1/storefile.11.up.key1，表示从key1切开storefile.11后，两个引用文件分别引用源文件的下半部分和上半部分
       f)    创建child region：
              i.    设置各种属性，比如将parent region的访问指标平分给child region，每人一半
              ii.    将上面在parent 文件夹中生成的临时文件夹（里面包含对parent region的文件reference）move到表目录下，现在在目录层次上，child region已经跟parent region平起平坐了
       g)    向系统meta server中写入parent region split完毕的信息，并将child region的名字一并写入（split状态在meta层面持久化）
       h)    分别Open 两个child region，主要包含以下几个步骤：
              i.    将child region信息写入meta server
              ii.    Load 所有store file，并replay log等
              iii.    如果包含reference文件，则做一次compaction（类似merge），直到将所有的reference文件compact完毕，这里可以看到parent region的文件是会被拆开写入各个child regions的。
       i)    将parent region的状态由SPLITTING转为SPLIT，zookeeper会负责通知master开始处理split事件，master开始offline parent region，并online child regions
       j)    Worker等待master处理完毕之后，确认child regions都已经online，split结束

Split整个过程其实可以分为两个大步骤：一是将parent region分裂为child regions的信息记录到meta中；二是child regions online之前做compaction直到将所有的reference 文件过滤一遍，以便parent region的文件夹可以删除

但是其将所有store file直接分为两份，我觉得写入的量大了，其实parent region可以保留的，每次只生成一个daughter region就可以了，然后parent region里面的无效数据可以在major compaction的时候过滤掉。