elasticsearch億級資料量全量索引導入優化方案

1. 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.
              

2. 線程池參數配置，由于是IO密集型任務可将核心線程數調成cpu核數好幾倍，保證程式錄入不能丢失資料采用

   ThreadPoolExecutor.CallerRunsPolicy拒絕政策
              

   由于是測試環境配置不高(4核7G機器)，一開始我設定的corePoolSize=4，maxPoolSize=8，隊列容量200，後來發現還是太慢了，後來經過測試改成corePoolSize=20，maxPoolSize=40，隊列容量為4000，最終效果比較好

3. 利用G1收集器，調大jvm堆記憶體

   我從3G->6G,這樣做的好處是，1.GC不會太頻繁，導緻程序頻繁停頓影響性能 2.可以增加阻塞隊列容量，可以使scan hbase的父線程停頓時間不會太長，導緻連接配接逾時

4. elasticsearch建索引方式改成BulkProcessor，批量送出

   注意，BulkProcessor配置成異步、批量、定時重新整理等，BulkProcessor#add()方法是一個同步方法，是以在同一時刻隻能單線程處理，優化是将BuilkProcessor放線上程池中動态生成，多線程送出，另外，建索引時候先不選擇副本等全量錄入完成以後再配置副本，選擇副本再錄全量資料更新比較慢。

   BulkProcessor使用注意：

   1.使用的時候如果BulkProcessor隻有一個執行個體，由于es批量處理不過來所有的資料都堆積在這個類中會出現OOM，後來上司讓我把送出流程改成通過固定的線程池去送出，每次批量送出建立一個執行個體，這樣保證不會出現OOM。

   2.BulkProcessor源碼中用的Synchronized，如果隻有一個執行個體也就意味着多個線程同時送出一次隻能處理一個線程的送出，這樣效率太慢了