上周做了一些測試還有改進，這里簡單的總結下。

需求

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

設計與實現

ServerA，B均是Centos7

• B為8核心，8G內存
• A為32核心，64G內存

這種程序也稱為批處理程序，其實就是離線的數據導入，使用Python3.6來實現，熟悉度最多的語言，測試集大概有460多個文件，3.1 GB的日志。

單進程

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

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

這里用CProfile在本地開發環境做了profiling，發現直接采用 datetime.strptime 做日期的解析 , urlparse.parse 做url的解析都比較慢，自己重新實現了，15分鐘不到 完成測試。

多進程

掃描目錄 --> 文件1 ，進程1，每個文件建立一次連接--> 文件2 ，進程2

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

開始的時候是懷疑日志解析的正則表達式拖慢了速度，后來經過對測試環境的再次profiling發現60%的時間都花在clickhouse的交互上，就是插入數據的時間話費很長。為了證實這個結果，我把插入數據庫這一步skip掉，發現果然快了很多，之前的統計解析+插入，單進程比較高的也就是 12000條/s，現在能到40000+/s。

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

這樣改進之后20個進程 1分36秒 不到就能完成3G日志的處理，當前的插入速入10w+/s.

設想

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

大文件chunk 已經實現，插入時間已經縮短到 1分15秒，整體的插入效率 16w/s左右

還有就是把網絡文件系統掛在到新的server，多個機器分配不同的目錄進行處理插入到clickhouse，當然這也要看clickhouse自身的最大吞吐。

這里為啥沒有考慮網絡存儲和數據庫的瓶頸呢，因為這邊內網之間是萬兆網卡，clickhouse之前的測試單進程10w插入應該沒問題，當前的程序還沒到這些瓶頸，所以沒有重點優化

總結

文件處理的優化手段

• profliling
• 多進程
• 文本解析
• 合并入庫
• 大文件分塊
• 使用的類庫要熟悉

后記

后來發現 clickhouse python client有壓縮的選項，結果開啟壓縮之后，整體時間一下子縮短了40%。。。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。