由Kaggle競賽wiki文章流量預測引起的pandas內存優化過程分享

pandas內存優化分享

原因

最近在作Kaggle上的wiki文章流量預測項目，這裏因爲我的電腦配置問題，我一直都是用的Kaggle的kernel，可是咱們知道kernel的內存限制是16G，以下：

在處理數據過程當中發現會超出，雖然咱們都知道對於大數據的處理有諸如spark等分佈式處理框架，可是依然存在下面的問題：

1. 對於我的來講，沒有足夠的資源讓這些框架發揮其優點；
2. 從處理數據的庫豐富程度上，仍是pandas等更具備優點；
3. 不少時候並非pandas沒法處理，只是數據未經優化；

因此這裏仍是考慮針對數據進行內存方面的優化，以達到減小內存佔用，並在kernel上正常運行爲最終目的；

整個嘗試的過程

只加載當前用到的

這個不用多說，雖然通常爲了省事，都是開頭一塊兒load到內存中，可是特殊狀況下，這裏仍是要注意的，以下：

能夠看到，雖然可用數據文件不少，可是因爲當前處理須要的僅僅是train2.csv，因此只加載其便可，不要小看這一步，這裏每一個文件加載過來都是幾百M的；

類型轉換

這裏是在預處理部分能作的對內存影響最大的一部分，基本思路以下：

1. object考慮是否須要轉換爲category；
2. numeric，即各類數值類型，是否在容許範圍內下降類型，例如假如某一列爲整型且最大值爲100，那麼就是用用int8類型來描述；
3. 對於日期類型，能夠先不着急轉爲datetime64，咱們直到datetime類型佔用內存是比object還多的，能夠先考慮轉爲category，後續處理完釋放了沒用對象後再轉回來便可（這種方式比較少用，可是對於這個項目仍是挺有用的，由於最終內存峯值也就在那幾G上）；

以下是未作轉換前的DataFrame信息：

以下是我對原始數據各字段的類型轉換以及轉換後的DataFrame信息：

看到內存佔用直接降了一半，不要小看這幾百M，在DataFrame進行各類apply、groupby運算時，臨時佔用的內存是很是多的，也很容易超過峯值致使kernel重啓；

PS：固然，這裏若是直接加載時指定數據類型也是能夠的，我這邊爲了展現轉換先後效果，因此直接指定，實時上更常見的作法時，先直接加載，info或者describe看數據信息，而後判斷數據應該的類型，修改代碼爲直接指定；

使用union_categoricals代替pd.concat實現表的鏈接

作過期序數據預測的朋友應該直到，時序數據構建時，一個特色是須要鏈接訓練和測試數據，而後同時針對這些數據作時序上的延遲特徵、各類維度的統計特徵等等，所以這裏就涉及到數據鏈接，必定要注意要用union_categoricals代替pd.concat，若是直接使用concat，那麼category類型的列會被轉爲object，那麼在鏈接的過程當中，內存就會超過峯值，致使kernel重啓，那就悲劇了。。。。

以下，是對數據作reshape的操做，這個是該競賽數據的一個特色，因爲其把每一天對應的訪問數據都放到了一塊兒，也就是一行中包含了一篇文章的每一天的訪問量，而這是不利於後續作延遲特徵構建的，須要將每一天的信息單獨做爲一行，所以須要reshape：

以下這種鏈接、即時銷燬的方式雖然看着醜，可是效果仍是能夠的：

以下是採起這種方式連接後的DataFrame信息，其實難點不在於DataFrame多大，而是它在運算過程當中的內存峯值會超過限制：

注意

1. 即時del掉不用的對象；
2. 對於category列的鏈接，使用union_categoricals；
3. 在不一樣類型的列鏈接時，結果類型會取大的那個，好比int8鏈接int64，那麼結果就都是int64；
4. 關於category類型，不只能夠下降內存佔用，並且還能加快運算速度，關鍵在於特徵的取值可能數量是否遠小於行數；

Kaggle競賽連接

https://www.kaggle.com/c/web-traffic-time-series-forecasting

Kaggle kernel連接，該kernel已經設置爲public，你們能夠隨意copy

https://www.kaggle.com/holoong9291/web-traffic-time-series-forecasting

最後

你們能夠到個人Github上看看有沒有其餘須要的東西，目前主要是本身作的機器學習項目、Python各類腳本工具、數據分析挖掘項目以及Follow的大佬、Fork的項目等：
https://github.com/NemoHoHaloAi