例子中设置了6MBbuffer容量。设置buffer容量。

*必需禁止autoflush

可以上下微调以适应不同的写场景。*6MB经验值。

原理

HBaseClient会在数据累积到设置的阈值后才提交RegionServer这样做的好处在于可以减少RPC连接次数。

2.RPCHandler

快速配置

修改hbase-site.xmlhbase.regionserver.handler.count配置项：

Xml代码  

原理

handler数量也不是越大越好，     该配置定义了每个RegionServer上的RPCHandler数量。RegionServer通过RPCHandler接收外部请求并加以处理。所以提升RPCHandler数量可以一定水平上提高HBase接收请求的能力。当然。这要取决于节点的硬件情况。

3.Compression

快速配置

Java代码  

原理

边压边写也会提升性能的终究IO大数据的最严重的瓶颈，     数据量大。哪怕使用了SSD也是一样。众多的压缩方式中，推荐使用SNA PPY从压缩率和压缩速度来看，性价比最高。

4.WA L

快速配置

原理

以保证在异常情况下，     其实不推荐关闭WA L不过关了确可以提升性能...因为HBase写数据前会先把操作耐久化在WA L中。HBase可以依照WA L记录来恢复还未持久化的数据。

5.Replication

一般会把replica降低到2当然也不推荐随便降低replica虽然推荐replica=3不过当数据量很夸张的时候。

6.Compaction

打开HMasterweb界面，    插数据时。检查每个regionserverrequest数量。确保大部分时间，写请求在regionserver层面大致平均分布。此前提下，再考虑compact问题。继续观察request数量，会发现在某个时间段，若干regionserver接收的请求数为0当然这也可能是client根本没有向这个regionserver写数据，所以之前说，要确保请求在各regionserver大致平均分布）这很有可能是regionserver做compact导致。compact过程会block写。优化的思路有两种，一是提高compact效率，二是减少compact发生的频率。

以增加执行compact线程数：提高以下两个属性的值。

hbase.regionserver.thread.compaction.large

hbase.regionserver.thread.compaction.small

推荐设置为2

优化Client设计

以上都是些常见的参数调整。但是写性能差一般是源于Client端的糟糕设计。

1.防止regionsplit

regionsplit提升写性能的一大障碍。减少regionsplit次数可以从两方面入手。首先是预分配region不得不说。

预分配region

请参见http://blog.sina.com.cn/s/blog_9cee0fd901018vu2.html按数据量，rowkei规则预先设计并分配好region可以大幅降低regionsplit次数,   不在此重复regionsplit原理。甚至不split这点非常重要。

适当提升hbase.hregion.max.filesize

region数量，    提升regionfile容量也可以减少split次数。具体的值需要按照你数据量。rowkei分布等情况具体考量。一般来说，3~4G不错的选择。

2.均匀分布每个RegionServer写压力

每个handler忙，     之前也提到RPCHandler概念。好的DataLoader需要保证每个RPCHandlder都有活干。但不至超载。注意region压力不能过大，否则会导致反复重试，并伴有超时异常(可以提高超时的时间设置)

startKei设计，如何保证每个RegionServer压力均衡呢？这和region数量。client数据插入顺序有关。

简单的数据插入顺序应该是多线程实现。让每个线程负责一部分的rowkei范围，     一般来说。而rowkei范围又和region相关，所以可以在数据插入时，顺序控制每个region压力，不至于有些region闲着没事干。

如何设计rowkei呢？举个比较实际的例子，    那么。如果有张HBase表来记录每天某城市的通话记录，惯例思路下的rowkei由电话号码 +yyyyMMddHHmmSS+...组成。按电话号码的规律来划分region但是这样很容易导致数据插入不均匀(因为电话通话呈随机性)但是如果把电话号码倒序，数据在region层面的分布情况就大有改观。

3.分布式的数据插入顺序

即使使用多线程，     HBase客户端在单节点上运行。也受限于单节点的硬件资源，写入速度不可能很快。典型的思路是将客户端部署在多个节点上运行，提高写的并发度。MapReduc个很好的选择。使用MapReduc把写入顺序分布到集群的各个节点上，并在每个mapper中运行多线程的插入顺序。这样可以很好的提高写并发度。

不要使用reducmapperreduc需要走网络，    注意。受限于集群带宽。其次，实际的应用场景一般是用户从关系型数据库中导出了文本类型的数据，然后希望能把导出的数据写到HBase里。这种情况下，需要小心谨慎地设计和实现filesplit逻辑。

4.HBaseClient太慢？BulkLoad!

HFileOutputFomart里有个叫configureIncrementalLoad方法。API这么介绍的请拿出HBaseAPI读读。

ConfiguraMapReducJobtoperformanincrementloadintothegiventable.This

Inspectthetabltoconfiguratotalorderpartitioner

UploadthepartitfiletotheclusterandaddittotheDistributedCache

Setthenumberofreductasktomatchthecurrentnumberofregions

Settheoutputkey/valuclasstomatchHFileOutputFormat'requirements

SetthereducuptoperformtheapproprisorteitherKeyValueSortReducorPutSortReduc

TheusershouldbesuretosetthemapoutputvaluclasstoeitherKeyValuorPutbeforrunthifunction.

完美地绕过了HBaseClient上一节的分布式插入方法也是用mapreduc实现的不过实质上还是用hbaseclient来写数据）这是HBase提供的一种基于MapReduc数据导入方案。

网上有不少文章叙述了使用命令行方式运行BulkLoad比方

实际生产环境上很难使用这种方式。终究源数据不可能直接用来写HBase数据迁移的过程中会涉及到数据清洗、整理归并等许多额外的工作。这显然不是命令行可以做到事情。依照API描述，可行的方案是自定义一个Mappermapper中清洗数据，Mapper输出valu为HBasePut类型，Reduc选用PutSortReduc然后使用HFileOutputFormat#configureIncrementalLoadJob,     但是不得不说。HTabl;解决剩余工作。

这种实现也存在局限性。终究MapperReduc比较吃网络。不过。