最近在线上往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来的要快的多。但是在重新导之前就要好好改进一下了：
这里总结一下这个问题，对于大批量导入数据，1、还是必须让业务方对rowkey进行预分片，对业务数据rowkey进行md5或者其他的hash策略，让数据尽量随机分布而不是顺序写入。2、随时观察region的大小，是否出现大region的情况。
这个问题预防为主，如果出现大region——优先考虑重导数据，其次使用patch。