es寫入性能低問題排查及優化

1、es寫入報錯及寫入性能低問題排查

   使用es的java 客戶端 jestClient 進行bulk批量寫入es 數據時，經過多次調整並行度，bulk批量寫入的條數后，es 寫入性能始終在 2.7w條/s 左右徘徊，並且在寫入用戶檔案時，在大約1億條 左右時，es會報【index has read-only-allow-delete block】

    【index has read-only-allow-delete block】 該錯誤是由於es 部署的數據節點，磁盤存儲使用率超過90%【由用戶自行配置】，為避免集群出現問題，es將數據索引上鎖，無法寫入數據導致的。

     代碼中將寫入es的錯誤信息返回給方法的調用者，方法調用者將該錯誤collect 收集后返回driver 端，當失敗數據太大時，driver端 內存放不下這些數據，就會報oom

   

 在數據寫入任務運行時，查看es集群監控發現，只有單個節點的cpu使用率超過了90%，心想可能任務為單線程寫入，將bulkData方法中的

client.execute(bulk)

修改為異步寫入

client.executeAsync(index, new JestResultHandler<JestResult>() {
                @Override
                public void completed(JestResult result) {
                }

                @Override
                public void failed(Exception e) {
//                e.printStackTrace();
                    LOG.error("寫入失敗：" + e.getMessage());
                    errList.add("寫入失敗：" + e.getMessage());
                }
            });

經測試發現性能沒有明顯提升，且集群依然為單節點寫入。

這時想起了es寫入原理，如下圖

即然不是代碼出現問題，就將問題定位到集群，es是使用寫入數據的id，根據路由規則定位到該數據具體寫入哪個分片的，查看當前寫入數據的分片，發現該索引分片數為1，副本數也為1，由於當前數據索引是在代碼中建立的，將代碼中創建索引的settings 添加如下代碼

"settings":{
    "number_of_shards":8,
    "number_of_replicas":0
},

【當前集群數據節點為8個，所以將該索引的分片數設置為8，為提高寫入性能，將分片副本數設置為0，如果對數據可靠性有要求，可以將分片副本數設置為1，或等待數據寫入完成后，修改副本分片數】

運行寫入任務

數據共寫入2.2億 + 1.4億條，【在寫入  用戶檔案  任務時，同時開啟了  消費數據  寫入任務】

用戶檔案 使用40分鍾寫入成功，消費數據  使用20分鍾寫入成功