hbase读数据用scan，读数据加速的配置参数为：
Scan scan = new Scan();
scan.setCaching(500); // 1 is the default in Scan, which will be bad for MapReduce jobs
scan.setCacheBlocks(false); // don't set to true for MR jobs其中，
public Scan setCacheBlocks(boolean cacheBlocks)//Set whether blocks should be cached for this Scan
默认值为true, 分内存，缓存和磁盘，三种方式，一般数据的读取为内存->缓存->磁盘；setCacheBlocks不适合MapReduce工作：
MR程序为非热点数据，不需要缓存，因为Blockcache is LRU，也就是最近最少访问算法（扔掉最少访问的），那么，前一个请求（比如map读取）读入Blockcache的
所有记录在后一个请求（新的map读取）中都没有用，就必须全部被swap，那么RegionServer要不断的进行无意义的swapping data，也就是无意义的输入和输出BlockCache，增加了无必要的IO。而普通读取时局部查找，或者查找最热数据时，会有提升性能的帮助。
public Scan setCaching(int caching)
//增加缓存读取条数(一次RPC调用返回多行记录)，加快scaners读取速度，但耗费内存增加，设太大会响应慢、超时、或者OOM，
找到RPC操作的数据和内存占用情况的一个折中，默认使用Configuration setting HConstants.HBASE_CLIENT_SCANNER_CACHING，值为1
public void setBatch(int batch) //设置获取记录的列个数，默认无限制，也就是返回所有的列。实际上就是控制一次next()传输多少个columns,如setBatch(5)则每个Result实例返回5个columns，(http://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Scan.html)
setBatch使用场景为，用客户端的scanner缓存进行批量交互从而提高性能时，非常大的行可能无法放入客户端的内存，这时需要用HBase客户端API中进行batching处理。
通过调整setCaching和setBatch这两个参数，可以观察对RPC交互数量的影响，也就是时间性能的影响：
一个简单的例子，一个表含两个column family，每个column family下10个column，10行数据，比较效果的组合
Caching: 1, Batch: 1, Results: 200, RPCs: 201
Caching: 200, Batch: 1, Results: 200, RPCs: 2
Caching: 5, Batch:100, Results: 10, RPCs: 3
Caching: 5, Batch:20, Results: 10, RPCs: 3
Caching: 10, Batch:10, Results: 20, RPCs: 3
计算RPC的次数：将行数result与column数相乘，再除以batch和column数中的较小值，最后除以caching大小。
===================================================
其他的参数优化配置：
参考http://joshuasabrina.iteye.com/blog/1798239
1. Write Buffer Size
HTable htable = new HTable(config, tablename);
htable.setWriteBufferSize(10 * 1024 * 1024);
htable.setAutoFlush(false);
2.map中间结果压缩
参考(
http://blog.csdn.net/yangbutao/article/details/8474731
http://m.blog.csdn.net/blog/u012875880/21874293
http://developer.51cto.com/art/201204/331337.htm
)
老版本中用
conf.setCompressMapOutput(true);
conf.setMapOutputCompressorClass(GzipCodec.class);
新的设置方法为
conf.setBoolean("mapred.compress.map.output", true);
//conf.setClass("mapred.map.output.compression.codec",GzipCodec.class, CompressionCodec.class);
默认使用GzipCodec，可以指定GzipCodec.class,SnappyCodec.class,LzopCodec.class,
其中lzo、snappy需要操作系统安装native库才可以支持。
数据格式为TextFile，Sequence，以及其他用户自定义的文件格式的文件都可以压缩,不同的场合用不同的压缩算法，bzip2和GZIP是比较消耗CPU的，压缩比最高。但GZIP不能被分块并行处理；
Snappy和LZO差不多，稍微胜出一点，cpu消耗的比GZIP少。
comparison between compression algorithms
Algorithm % remaining Encoding Decoding
GZIP 13.4% 21 MB/s 118 MB/s
LZO 20.5% 135 MB/s 410 MB/s
Snappy 22.2% 172 MB/s 409 MB/s
运行时报错处理
1,客户端收到报错
ScannerTimeoutException:org.apache.hadoop.hbase.client.ScannerTimeoutException
这是当从服务器传输数据到客户端的时间，或者客户端处理数据的时间大于了scanner设置的超时时间，scanner超时报错，可在客户端代码中设置超时时间
Configuration conf = HBaseConfiguration.create()
conf.setLong(HConstants.HBASE_REGIONSERVER_LEASE_PERIOD_KEY,120000)
但由于scan超时时间是配在Region Server上的，所以此配置无用。修改该值必须在Region Server上修改hbase-site.xml，重启集群。
2,报错org.apache.hadoop.hbase.regionserver.LeaseException: org.apache.hadoop.hbase.regionserver.LeaseException: lease ” does not exist
首先介绍，租约（Lease）过期或租约不存在，指的是hbase client端每次和regionserver交互时，服务器端会生成一个租约（Lease),其有效期时间由参数hbase.regionserver.lease.period确定。
原理如下：
客户端在regionserver取数据时，如果hbase中存的数据过大且很多region时，客户端请求的region不在内存中，或是没有被cache住，需要从磁盘中加载。而当加载时间超过了hbase.regionserver.lease.period的设置时间，且客户端没有和regionserver报告其还活着，那么regionserver就会认为本次租约已经过期，并从LeaseQueue中删掉本次租约，当regionserver加载完成后，拿已经被删除的租约再去取数据的时候，就会出现如上的错误现象。
解决办法一般是增加租约时间，设置hbase.regionserver.lease.period参数（默认为60000，一分钟）
conf.setLong(HConstants.HBASE_REGIONSERVER_LEASE_PERIOD_KEY,120000)。
如果还报错，则可能是hbase.rpc.timeout的问题，增大hbase.regionserver.lease.period的时候应该同时增大hbase.rpc.timeout，同时hbase.rpc.timeout应该等于或大于hbase.regionserver.lease.period
conf.setLong("hbase.rpc.timeout", 1200000);