摘要：大多數字段都是統計數據，無法區分哪些發生了變化，所以不能增量更新。于是做了一些寫入優化。之前寫業務代碼數據量一般不是很大，采用的是一次性把數據讀取到內存中。用查看刷數據機器的性能可以看到開啟的個線程占用內存。

背景: 有1億多的用戶畫像中數倉需要導入ES。大多數字段都是sql統計數據，無法區分哪些發生了變化，所以不能增量更新。只能每天全量刷數據。在刷數據的過程中出現了更新緩慢、內存問題。于是做了一些寫入優化。

*

首先要從數倉讀取出數據到內存。然后再組裝對象去ES刷數據字段比較多而且都需要查詢。嘗試了一下，即使limit 10，也需要耗時2分鐘。所以第一步導數據不能直接查詢。采用的是數倉到分布式文件系統分片存儲。這一步已經有現成工具。1億數據導入到分片耗時3分鐘左右

將分片的數據讀到java內存中。再構造請求參數刷ES

`問題：1.刷數據ES報413錯誤。ES建議每次bulk5~15M數據，這里我每次批量提交5000條，bulk的時候發生的413 requets too large錯誤，google了一下，說是索引的時候段合并內存不夠。于是調整indices.breaker.fielddata.limit為60%，增大堆內存，結果沒什么用；也有說要調整 client_max_body_size 的，但是我們的es是云服務，沒法改配置參數最終加大es的內存為16G,不再報這個錯誤。

2.之前寫業務代碼數據量一般不是很大，采用的是一次性把數據讀取到內存中。再做業務處理。但是這次在數據塞到一半的數據，先是系統響應變慢了，后來測試環境的系統掛了。通過過命令排查，發現List對象占用了很多空間。于是復查代碼。發現是for循環一直往list填對象導致的內存泄露。于是限制了單個文件大小為20M,一個文件一個文件地處理。
`

剛開始刷數據預計需要20個小時。今天的數據如果明天才更新完，意義不大。于是想辦法提高索引效率。網上都說"refresh_interval": "-1"；調整number_of_replicas=0。我調整了結果沒什么變化。于是采用多線程刷數據

問題：1.一開始使用size為20的無界隊列，導致耗盡資源，任務線程占用的內存占用了80+%的內存，其他任務可能被拖垮。后來線程的核心線程數和最大線程數統一設置為10。并采用future模式，一個任務完成后再去添加其他任務。解決了線程耗盡資源和內存的問題。

可以看到開啟的10個線程占用42%內存。主線程cpu偶爾接近100%，這不是io密集型嗎？怎么會耗cpu。cpu變高可能是復雜的技術或者死循環。這里循環每次讀取量有50000條，并且組裝對象的邏輯。而且有10個線程，猜想可能是這個原因。

ES的索引速率

最后原來需要20小時才能完成的刷數據任務，只耗時約100分鐘。當然中間遇到的坑不止這些