Hbase写入量大致使region过大没法split问题

 最近在线上往hbase导数据，由于hbase写入能力比较强，没有太在乎写的问题。让业务方进行历史数据的导入操做，中间发现一个问题，写入速度太快，而且业务数据集中到其中一个region，这个region没法split掉，处于不可用状态。这里描述一整个过程——

        事情的原由：业务方按照userid和商品id做为rowkey前缀，并无进行hash散列。我当时咨询过业务方，认为：1.业务方式按照oracle的rowid顺序来进行迁移的，相对来讲对应到rowkey里面就不会集中化；2.即便出现部分集中的状况，hbase也可以经过自动split来hold住写入。

        结果线上写入的时候，12台机器的状况下业务方写入达到50~60w tps，基本上5w tps每台的写入速度。开始的时候region还可以自动split，比较好，写入速度也可以保持，可是到了次日，发现写入在region维度的分布很不均衡，因而查看表的region size 状况，有一个region数据量特别大——800GB，700+个文件。

       这里也分析一下为何hbase会让这么大的region存在，其实这块hbase的控制机制也是值得商榷的。首先，大量的写入会刷大量的HFile，一个region就会对这大量的hfile进行compact操做。若是这时候触发了split操做，这个region会成为父region，而两个子region会保留父region的引用文件。而在这其间，子region会继续写入数据。那么又可能触发子region的compact，这里的关键点来了——子region若是作compact的文件都是新写入的文件，而迟迟不去compact父region 引用的文件，会致使一个问题——就是这个子region没法被split掉了（由于含有父region引用的region是不能被split的）。那么子region愈来愈大，因为写入文件数量急剧增加，父region的ref文件总也得不到机会compact，就造成了大region的恶性循环状况——因为region太大，compact没法完成，可是因为compact没法完成致使region没法split，没法分摊compact的压力给其余regionserver。固然还得加上最后一点外部大量的写入没有中止——这里咱们一般理解，hbase有一个参数hbase.hstore.blockingStoreFiles=30,当region下的hfile达到30个的时候是会阻塞写的。那我都bolck住写了，为何region里hfile会到700这么多呢？原来还有另外一个参数hbase.hstore.blockingWaitTime=30000.hbase考虑到对应用的影响不会长时间block住写，30秒后会恢复。

      这里天梧有提一个改进的compact算法，优先去compact从父region引用过来的hfile，让region有split的可能，能在必定程度上缓解这个问题http://kelude.taobao.net/issues/543434 ，这个方法我使用过，只能在必定程度上缓解问题，对于800G大小的region，一天都没有compact掉。因此只适合100G之内的region，而且这时候业务方还不能有大量的写操做。但有趣的是通常如此程度的写入压力都是在业务方新导入数据的时候形成的，因此和业务方沟通一下让他们重导数据比本身慢慢郁闷的compact这个大region来的要快的多。可是在从新导以前就要好好改进一下了：

      这里总结一下这个问题，对于大批量导入数据，一、仍是必须让业务方对rowkey进行预分片，对业务数据rowkey进行md5或者其余的hash策略，让数据尽可能随机分布而不是顺序写入。二、随时观察region的大小，是否出现大region的状况。

      这个问题预防为主，若是出现大region——优先考虑重导数据，其次使用patch。