一、前言

      近期有個專案用spark向es(版本5.x)寫入資料，該專案是離線任務，每天建立一個index存資料，隨著資料量的增大(2億+，峰值有5億+)。效能出現問題：寫入時間過長，es響應不過來等

二、 調整策列

      1.由於該專案是離線任務，並不是需要實時查詢，可以將es中的near real-time search屬性 設定為-1 。預設情況下寫入到es的資料並不是馬上就刷到磁碟，而是先buffer起來（記憶體），但是這個時候客戶端是讀取不到該資料，為了實時查詢，需要定期（預設1s）將該資料刷寫到介於es和磁碟之間的filesystem cache (記憶體)，寫入到filesystem cache 是可以被客戶端讀取到的， 預設屬性由於快速的刷資料導致很多小量的filesystem cache，該屬性是在建立表的時候設定的 （關於near real-time search 原理 見連結：

2.index.translog.durability 預設值是request，該屬性類似於hbase 中的WAL,是為了防止寫入的資料丟失，在index或者delete的時候需要將“改變”寫入到translog中。在每個請求提交後，就將寫在translog中的“改變”重新整理到磁碟中。可以設定為async，該值表示先將“改變”寫入到記憶體  滿足下面其中一個條件再刷到磁碟 condition1：快取資料達到512M（default） condition2 : 快取時間達到5s(default) 。當然設定為async後犧牲了一定的資料安全性。設定詳情見官網連結：點選開啟連結

          3. 設定es.batch.size.bytes 以及es.batch.size.entries的數值，該數值表示es bulk操作中的batch大小和條數。這些設定對應到每個task中。（hadoop/spark 配置資訊見連結：

          4. 其他設定： 不需要分詞可以設定為not_analyzed ，自動生成id ，根據叢集的資訊適當的增加shard num ，spark 獲取的資料是否存在資料傾斜等

三、 最後

        調整上面的配置後，速度提升了5倍多，而且很還少出現es響應不過來的資訊。由於本人能夠有限，對上面的描述有誤的地方歡迎提出，同時有其他優化方案也可以分享！