业务背景：由于需要将ngix日志过滤出来的1亿+条用户行为记录存入Hbase数据库，以此根据一定的条件来提供近实时查询，比如根据用户id及一定的时间段等条件来过滤符合要求的若干行为记录，满足这一场景的技术包括：Solr，Elasticsearch，hbase等，在此选用了Hbase来实践。
step 1 :
直接hbase建表，然后读取记录文件逐条写入Hbase。由于hbase实际的写入速度远远小于我的提交速度，在写入了1700条记录后，hbase出现了宕机，提交后无响应。查看hbase日志，出现 out of memory异常。
step 2：
考虑在建表的时候没有进行预分区，因此写入的时候会存在热点写的问题，同时数据持续增长，需要不断的对region进行split，实际上这一步相当消耗资源。因此对要写入的Hbase表重新预分区。好在上一步骤中写入的数据不多，因此直接删除表和数据后重新建表并预分区：
create 'user_actions', {NAME => 'info', VERSIONS=> 3},{SPLITS => ['130','140','160','170','180']}设计预分区的时候需要有个预判，rowkey的范围及在各个区间的可能分布情况，由于我这里的rowkey是组合用户的注册电话/时间及其他字段，因此上述的预分区，可以将记录较好的散列在各个region上，对热点写有一定的减缓作用。同时，针对out of memory异常，修改hbase配置文件/conf/hbase-site.xml，将hbase的堆内存增加到3GB(条件有限，如果硬件条件好的话，可以增加到4-8GB)。
继续写入，但是写入速度很慢，维持在数百条/秒的样子，同时写入了20几万条后响应速度越来越慢。
STEP ３：
上述问题的根源在于高频提交小数据，导致Hbase疲于创建线程并进行资源的回收，最终甚至会出现宕机。
之后，将单条put到Hbase改为一次put多条记录到hbase，即批量提交，同时限制一秒内提交的频次。最后顺利写入。由于hbase集群只有三台机器(一台master,2台slave)，进过上述优化后，写入速度基本维持在1w-2w条/秒的水平，基本满足需要了。
总结：在hbase涉及一次性写入大量数据时，有几个地方可以考虑进行优化：(1)建表的同时进行预分区 (2)修改Hbase本身的配置(能够优化写入和读取的配置项远不止修改堆内存这一项，在此不表了) (3)尽量使用批量写入的方法，同样的道理，读取的时候，使用批量读的方法 (4)网络IO/磁盘IO