摘要：大多數(shù)字段都是統(tǒng)計(jì)數(shù)據(jù)，無法區(qū)分哪些發(fā)生了變化，所以不能增量更新。于是做了一些寫入優(yōu)化。之前寫業(yè)務(wù)代碼數(shù)據(jù)量一般不是很大，采用的是一次性把數(shù)據(jù)讀取到內(nèi)存中。用查看刷數(shù)據(jù)機(jī)器的性能可以看到開啟的個線程占用內(nèi)存。

背景: 有1億多的用戶畫像中數(shù)倉需要導(dǎo)入ES。大多數(shù)字段都是sql統(tǒng)計(jì)數(shù)據(jù)，無法區(qū)分哪些發(fā)生了變化，所以不能增量更新。只能每天全量刷數(shù)據(jù)。在刷數(shù)據(jù)的過程中出現(xiàn)了更新緩慢、內(nèi)存問題。于是做了一些寫入優(yōu)化。

*

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

將分片的數(shù)據(jù)讀到j(luò)ava內(nèi)存中。再構(gòu)造請求參數(shù)刷ES

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

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

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

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

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

ES的索引速率

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