上周我遇到一個需要處理大文件的場景，需要遍歷大文件，并且對數據進行一定的處理。由于這批數據對時效性要求較高，所以當時我編寫的程序是希望運行地越快越好，所以我在編程的過程中對程序進行一次一次的優化，最終從開始時需要運行8小時到現在只需運行50分鐘，算是達到了需求。當然，你可能會說一開始的程序寫得太爛，所以導致運行太緊，無所謂啦，這并不是重點。實際上，很多人第一次寫程序都很難按預想那樣寫出簡單高效的代碼片段，只是有的場景對性能要求并不高，所以有的人看著自己的程序能運行后就不再進行優化了。其實，絕大多數程序都是有優化空間的，并且還有很大的優化空間，這個空間指的是時間和空間。

廢話不多說，我把這次優化的過程和思路總結為8個點，分享出來，希望能對大家有所幫助。

1 需求

大數據時代，處理大量數據成為了不少程序員的家常便飯。那么多大的數據可以稱為大數據呢？對于數據量，很難用一個確定的量去描述其界限，我理解大數據不僅僅是數據量大，還應該具有數據復雜的特性，比如維度高、字段多。我平時處理的數據并不是大到磁盤都存不下那種，最多就是億的量級。此次處理的數據是一個文本的大文件，數據量不到一億，占用磁盤空間幾百GB，它是行列結構，即每一行數據用tab鍵分割，有不到100個字段，其中有部分字段是json，且這個json異常復雜，一條大的數據可能會占用好幾MB的空間。

我要做的事情很簡單，最費勁的就是在每一條數據的大json串中增加一個字段，這個字段經過了一些復雜的計算。簡單來說就是寫程序遍歷一遍這個文件，然后對每條數據做一些計算，其中包含了把一個字段塞到大json串中。

2 Python

說到處理數據，我個人覺得Python是最好用的，當然它最caodan的地方是對中文編碼不夠支持，不過這還算是一個可以克服的缺點。和往常一樣，我用Python編寫了一版，試著跑了一下數據，大約每一萬條數據需要大約耗費5秒。算下來，大概需要跑8到10小時，這是不能接受的，所以我開始了一系列的優化。

另外多說一點，我們在測試自己的程序的時候，并不用全量的數據去測，比如從正式數據中去head(Linux命令，可以取文件頭部的n行數據)出200萬條數據來進行測試，跑完測試用例就可以大致估算出整個程序耗時了。

3 并發

因為程序中包含了一定的計算邏輯，即消耗CPU的邏輯片段(說個題外話，有的程序可能是計算型的，比較耗CPU，有的是內存型的，比較耗內存，還有些是IO型的，大多數情況下磁盤讀寫會成為瓶頸)，可能是受之前慣性思維的影響，對于優化的方法，我首先想到的就是增加程序的并發，開多個線程，開多個進程。多線程最簡單，一是好實現，二是代碼相對好控制。三下兩下把代碼改成了多線程，這里我使用的是線程池而不是每來一條數據新創建一個線程去處理它，這樣可以減少程序的運行時間。所謂線程池就是，事先，一般在程序啟動的時候先創建一定數量的線程，然后每次有處理需求時，就從線程池中撈一個線程來處理它，因為線程的創建和消亡是會消耗資源和時間的，所以，理論上，使用線程池就可以減少這部分創建和消亡的時間。

我一開始創建了8個線程，運行了一下，程序并沒有快多少，所以我又把線程數提到了16，最后提到了128，運行速度反而減慢了。還是因為慣性思維，因為Python的線程模型是N:1模型。所謂N:1模型就是所有線程都跑在了一個物理核上，不同線程實際上是在同一個核上頻繁切換。我認為多線程已經把一個核給榨干了，要提升程序的運行速度只能采取多進程。如果在CPU相對空閑時，不同的進程幾乎是可以獨占不同的物理核的，準確來說就是切換不太頻繁，可以實現真正意義上的并發。說到多進程，對于處理大文件，程序運行最快的方法是將一個大文件按行平均切割成m份，然后開啟m個進程獨立地跑這些數據。不過按照之前的經驗，使用Linux下的文件切割命令split來切割這么一個大文件，大概需要3個小時，這屬于程序員的額外時間消耗，所以我放棄了。我還是選擇了進程池，在程序啟動的時候主進程fork出許多子進程，即master/worker模式，并且自己實現了一個生產者消費者，否則任務等待隊列會被撐爆的。代碼寫好了以后，根據我的以往實驗，在開啟5個進程的時候程序運行得最快，并且總的運行時間是之前的80%左右。優化效果并不好，因為進程池也會存在進程的切換，和真正獨立的進程是有區別的。這幾個進程不是一直在running狀態，也是會經歷進程的狀態切換，running、wait、ready等狀態。從8個小時縮短為6個多小時是遠遠不達標的，至少要在兩個小時內才能接受。

4 瓶頸

瞎搞了這么久，我終于想著去理性地尋找瓶頸，一種最好的方式就是在程序運行的時候實時監控計算機的狀態，比如大家熟知的命令top，第三方工具htop。我這里使用的是公司內部的監控工具，可以查看內存、CPU、IO的實時狀態。還有另一種方式就是計算程序每個部分的耗時，如果你的程序封裝或者抽象得足夠好，我們是很容易計算某個代碼片段的耗時的，比如計算在程序流程中某個函數需要運行多長時間，我們只用在調用函數之前打印一下Unix時間戳，然后在函數運行結束的時候打印時間戳，最后做個差就能算出耗時了。所以說我們的程序要高內聚、低耦合，這樣后期維護起來是很爽的。經查看，我發現，在單線程的情況下，每處理一萬條數據大致耗時5秒，其中計算只花費了不到一秒，中文編碼解碼耗時不到一秒，IO耗時差不多兩秒，其中最耗時的就是解大json(json的decode和encode的步驟)，耗時兩秒多一點。通過監控計算機狀態，在程序運行的時候我讀寫的那塊磁盤的IO被打滿了，原因是服務器上還有很多其他進程在讀寫這塊磁盤。

所以這里有兩個優化點，第一點就是優化IO，第二點就是把大json解包封包的時間縮短。

5 換磁盤

說到IO，很多同學第一時間想到的就是換塊SSD。換塊SSD當然是個很好的解決辦法，但是如果每次編寫程序遇到IO問題都要通過硬件來優化，公司豈不是得破產？程序員寫代碼并不是想要啥就有啥的，要用最小的預算達到目的。我所使用的服務器上并沒有掛載SSD磁盤，倒是掛載了很多機械盤，并且很多盤都沒有讀寫操作。在大多數情況下，我們所說的IO基本上都指的是某一塊磁盤的IO。這里有一個優化點就是，我把讀寫的磁盤分離開，還是從之前的那塊磁盤讀數據，但是往另外一塊磁盤寫數據。還是原來的單線程代碼，什么也沒有改變，程序的運行時間一下降低了四分之一。從8小時縮短為6小時。

6 算法

IO進行了一定的優化，接下來就該優化最耗時的json解包封包了。我使用的是Python的官方工具，json.loads和json.dumps。事實上，有時候官方的工具并不一定是最好的，就拿json處理的相關工具來說，同一種語言可能有很多不同的工具，它們的處理效率可能會相差10倍以上。接下來的操作是不是該換個json解包封包工具了？我并不想這么做，因為有更快的方式，不知道大家還記得我前文提到的一句話嗎？我是想在json串中增加一個字段，在多數情況下，增加比減少容易得多。既然是增加，那完全沒有必要解包，正常情況下，我們從文件中讀取的json串實際上是一個字符串，解包會把它變為一個dict，處理完，又把這個dict轉化為一個字符串，然后再寫入文件。實際上，我們可以省略string轉dict再從dict轉string的步驟，因為json字符串的末尾是一個}符號，那么我們直接在}插入想要添加的字段即可。舉個例子：加入原始的json字符串是：{"key1":"value1"} ,我們想要加上一個字段key2，那么可以直接對字符串做切片操作(切片是Python中的一個操作)。即可以直接把這個過程變成 {"key1":"value1" + "key2":"value2" + }。這么一做，程序運行從之前的6小時縮短為3小時，處理時間減少了一倍，這算是在算法上的提升。

7 語言

3小時雖然已經比最開始的8小時快很多了，但我還是嫌棄它太長。Python雖然比較適合處理數據，寫起來也比較容易，不過比較偏上層，無法進行更底層的控制，比如內存、線程、進程等。都說Go語言的運行效率接近C++，開發效率接近Python，所以我也準備嘗嘗鮮。Go語言是編譯型語言，并且其語言本身就支持進程線程等特性。當然，這里我并沒使用并發，我只是用Go把之前的Python代碼重新寫了一遍，不過還是做了適當的優化。

1. 為了讓IO充分使用，我將Python一行一行的讀寫改為了Go語言一塊一塊的讀寫，即之前是一次讀一行，現在是一次讀一塊固定大小的二進制，然后用換行符來區分這一塊里面的每一行，誰快誰慢一下就能見分曉。

2. 我給文件的讀寫各添加了一個30MB的緩存，構成兩個生產者消費者。對寫操作來說，生產者是代碼處理邏輯，消費者是IO寫。經測試，生產者的速度是快于消費者的(所以這里提高并發已經沒有什么意義了，瓶頸在IO)。

在這種情況下，最后整個程序運行完成只需要50分鐘，已經在兩個小時內了，符合了最初的需求。

8 Todo

其實這個程序還有優化的空間，因為已經符合我最開始的需求，我就沒有繼續再優化下去。我剛說到，程序的瓶頸在于IO寫。那么我們可以同時往掛載在同一臺機器上的多個磁盤循環寫，這樣就能分散每塊磁盤的IO了。不過，寫程序不能為了優化而優化，在開發效率和運行效率上我們要選擇一個折中點。再盲目繼續優化，代碼的復雜度就該上升了。