elasticsearch亿级数据量全量索引导入优化方案

Hbase scan读取时候，调大

hbase.client.scanner.timeout.period

超时时间,不然可能会跑异常

org.apache.hadoop.hbase.UnknownScannerException: org.apache.hadoop.hbase.UnknownScannerException: Unknown scanner '479187903508737326'. This can happen due to any of the following reasons: a) Scanner id given is wrong, b) Scanner lease expired because of long wait between consecutive client checkins, c) Server may be closing down, d) RegionServer restart during upgrade.

线程池参数配置，由于是IO密集型任务可将核心线程数调成cpu核数好几倍，保证程序录入不能丢失数据采用
```
ThreadPoolExecutor.CallerRunsPolicy拒绝策略
```
由于是测试环境配置不高(4核7G机器)，一开始我设置的corePoolSize=4，maxPoolSize=8，队列容量200，后来发现还是太慢了，后来经过测试改成corePoolSize=20，maxPoolSize=40，队列容量为4000，最终效果比较好
利用G1收集器，调大jvm堆内存

我从3G->6G,这样做的好处是，1.GC不会太频繁，导致进程频繁停顿影响性能 2.可以增加阻塞队列容量，可以使scan hbase的父线程停顿时间不会太长，导致连接超时
elasticsearch建索引方式改成BulkProcessor，批量提交

注意，BulkProcessor配置成异步、批量、定时刷新等，BulkProcessor#add()方法是一个同步方法，因此在同一时刻只能单线程处理，优化是将BuilkProcessor放在线程池中动态生成，多线程提交，另外，建索引时候先不选择副本等全量录入完成以后再配置副本，选择副本再录全量数据更新比较慢。

BulkProcessor使用注意：

1.使用的时候如果BulkProcessor只有一个实例，由于es批量处理不过来所有的数据都堆积在这个类中会出现OOM，后来领导让我把提交流程改成通过固定的线程池去提交，每次批量提交创建一个实例，这样保证不会出现OOM。

2.BulkProcessor源码中用的Synchronized，如果只有一个实例也就意味着多个线程同时提交一次只能处理一个线程的提交，这样效率太慢了