上周做了一些測(cè)試還有改進(jìn)，這里簡(jiǎn)單的總結(jié)下。

需求

需求是這樣的：網(wǎng)絡(luò)存儲(chǔ)Gluserfs每天的日志文件大概有400多G的樣子，全是類似nginx的默認(rèn)格式的web日志，文件的大小分布不一定，幾kb也有，幾個(gè)G的也有，目錄深度3～4層的樣子。 現(xiàn)在把網(wǎng)絡(luò)存儲(chǔ)掛載到ServerA上，需要做的就是掃描昨天的所有日志文件，然后解析日志，存儲(chǔ)到另外的ServerB上，B上是一個(gè)單機(jī)的Clickhouse。

設(shè)計(jì)與實(shí)現(xiàn)

ServerA，B均是Centos7

• B為8核心，8G內(nèi)存
• A為32核心，64G內(nèi)存

這種程序也稱為批處理程序，其實(shí)就是離線的數(shù)據(jù)導(dǎo)入，使用Python3.6來實(shí)現(xiàn)，熟悉度最多的語(yǔ)言，測(cè)試集大概有460多個(gè)文件，3.1 GB的日志。

單進(jìn)程

掃描目錄 --> 循環(huán)讀取文件 --> 解析煤航日志，每1000條插入一次clickhouse

這種是最原始的最簡(jiǎn)單的思路，測(cè)試集跑20分鐘完成數(shù)據(jù)解析倒入，ServerA上可以看到Python程序的CPU一直是100%

這里用CProfile在本地開發(fā)環(huán)境做了profiling，發(fā)現(xiàn)直接采用 datetime.strptime 做日期的解析 , urlparse.parse 做url的解析都比較慢，自己重新實(shí)現(xiàn)了，15分鐘不到 完成測(cè)試。

多進(jìn)程

掃描目錄 --> 文件1 ，進(jìn)程1，每個(gè)文件建立一次連接--> 文件2 ，進(jìn)程2

從上面的觀察來看，這個(gè)是CPU型的任務(wù)，于是采用 multiprocess.Pool 來實(shí)現(xiàn)多進(jìn)程，每個(gè)文件進(jìn)行讀取，建立數(shù)據(jù)庫(kù)連接，1000條批量插入，20個(gè)進(jìn)程大概能縮短到 2分半 左右

開始的時(shí)候是懷疑日志解析的正則表達(dá)式拖慢了速度，后來經(jīng)過對(duì)測(cè)試環(huán)境的再次profiling發(fā)現(xiàn)60%的時(shí)間都花在clickhouse的交互上，就是插入數(shù)據(jù)的時(shí)間話費(fèi)很長(zhǎng)。為了證實(shí)這個(gè)結(jié)果，我把插入數(shù)據(jù)庫(kù)這一步skip掉，發(fā)現(xiàn)果然快了很多，之前的統(tǒng)計(jì)解析+插入，單進(jìn)程比較高的也就是 12000條/s，現(xiàn)在能到40000+/s。

優(yōu)化的思考是更多的合并插入，從1000條一次插入，改成10000條一次插入，然后之前是每個(gè)文件10000條合并插入，對(duì)于比較小的文件，如果就幾千條幾百條也要插入，還是會(huì)增加時(shí)間消耗，于是就做了一個(gè)進(jìn)程級(jí)別的合并，一個(gè)進(jìn)程內(nèi)積累到10000條再插入。

這樣改進(jìn)之后20個(gè)進(jìn)程 1分36秒 不到就能完成3G日志的處理，當(dāng)前的插入速入10w+/s.

設(shè)想

后來繼續(xù)觀察發(fā)現(xiàn)10個(gè)進(jìn)程的情況下，由于文件的大小不一，1分鐘的時(shí)候其實(shí)只剩下3個(gè)進(jìn)程在工作了，其他進(jìn)程已經(jīng)沒有負(fù)載了，然后還要快1分鐘才能完全結(jié)束處理。也就是說文件大小的不均衡，導(dǎo)致每個(gè)進(jìn)程的負(fù)載不均衡，導(dǎo)致復(fù)雜最大的進(jìn)程拖慢了整個(gè)處理流程，所以后面還可以把做文件的切割處理，把大文件進(jìn)程分塊處理，例如30M一個(gè)task，分配給進(jìn)程去解析插入。

大文件chunk 已經(jīng)實(shí)現(xiàn)，插入時(shí)間已經(jīng)縮短到 1分15秒，整體的插入效率 16w/s左右

還有就是把網(wǎng)絡(luò)文件系統(tǒng)掛在到新的server，多個(gè)機(jī)器分配不同的目錄進(jìn)行處理插入到clickhouse，當(dāng)然這也要看clickhouse自身的最大吞吐。

這里為啥沒有考慮網(wǎng)絡(luò)存儲(chǔ)和數(shù)據(jù)庫(kù)的瓶頸呢，因?yàn)檫@邊內(nèi)網(wǎng)之間是萬(wàn)兆網(wǎng)卡，clickhouse之前的測(cè)試單進(jìn)程10w插入應(yīng)該沒問題，當(dāng)前的程序還沒到這些瓶頸，所以沒有重點(diǎn)優(yōu)化

總結(jié)

文件處理的優(yōu)化手段

• profliling
• 多進(jìn)程
• 文本解析
• 合并入庫(kù)
• 大文件分塊
• 使用的類庫(kù)要熟悉

后記

后來發(fā)現(xiàn) clickhouse python client有壓縮的選項(xiàng)，結(jié)果開啟壓縮之后，整體時(shí)間一下子縮短了40%。。。

總結(jié)

以上是生活随笔為你收集整理的Python日志解析入库优化的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。