用 Python 分析 14 億條資料，就是那麼刺激！

你用 Python 處理過的最大資料集有多大？我想大概不會超過上億條吧，今天分享一個用 Python 處理分析 14 億條資料的案

這份 14 億條資料集來自 Google Books ，由 Google Ngram viewer 生成，根據書本印刷的每一個年份，記錄了一個特定單詞或片語在谷歌圖書的使用量。資料集中有成千上百萬的書，時間上涵蓋了從 16 世紀到 2008 年。可以繪製出單詞使用量隨時間的變化，比如查詢「Python 」在歷史中出現的頻率。

下面使用 Python 的 PyTubes 資料庫來載入上面的資料集，然後分析生成上面這樣一張圖。PyTubes 是一個專門用來載入大資料來源的庫。

1-gram 的資料集在硬碟上可以展開成為 27 Gb 的資料，這在讀入 python 時是一個很大的資料量級。Python可以輕易地一次性地處理千兆的資料，但是當資料是損壞的和已加工的，速度就會變慢而且記憶體效率也會變低。

總的來說，這 14 億條資料（1,430,727,243）分散在 38 個原始檔中，一共有 2 千 4 百萬個（24,359,460）單詞（和詞性標註，見下方），計算自 1505 年至 2008 年。

當處理 10 億行資料時，速度會很快變慢。並且原生 Python 並沒有處理這方面資料的優化。幸運的是，numpy 真的很擅長處理大體量資料。使用一些簡單的技巧，我們可以使用 numpy 讓這個分析變得可行。

在 python/numpy 中處理字串很複雜。字串在 python 中的記憶體開銷是很顯著的，並且 numpy 只能夠處理長度已知而且固定的字串。基於這種情況，大多數的單詞有不同的長度，因此這並不理想。 如果你依然在程式設計的世界裡迷茫，不知道自己的未來規劃可以加入我們的Python秋秋裙去784掉758文214字看看前輩們如何學習的！交流經驗！自己是一名高階python開發工程師，從基礎的python指令碼到web開發、爬蟲、django、資料探勘等，零基礎到專案實戰的資料都有整理。送給每一位python的小夥伴！分享一些學習的方法和需要注意的小細節

下面所有的程式碼/例子都是執行在   8 GB 記憶體   的 2016 年的 Macbook Pro。如果硬體或雲例項有更好的 ram 配置，表現會更好。

1-gram 的資料是以 tab 鍵分割的形式儲存在檔案中，看起來如下：

1Python 1587 4 2
2Python 1621 1 1
3Python 1651 2 2
4Python 1659 1 1

每一條資料包含下面幾個欄位：

11. Word
22. Year of Publication
33. Total number of times the word was seen
44. Total number of books containing the word

為了按照要求生成圖表，我們只需要知道這些資訊，也就是：

11.  這個單詞是我們感興趣的？
22. 釋出的年份
33. 單詞使用的總次數

通過提取這些資訊，處理不同長度的字串資料的額外消耗被忽略掉了，但是我們仍然需要對比不同字串的數值來區分哪些行資料是有我們感興趣的欄位的。這就是 pytubes 可以做的工作：

1import tubes
 2
 3FILES = glob.glob(path.expanduser("~/src/data/ngrams/1gram/googlebooks*"))
 4WORD = "Python"
 5one_grams_tube = (tubes.Each(FILES)
 6    .read_files()
 7    .split()
 8    .tsv(headers=False)
 9    .multi(lambda row: (
10        row.get(0).equals(WORD.encode('utf-8')),
11        row.get(1).to(int),
12        row.get(2).to(int)
13    ))
14)

差不多 170 秒（3 分鐘）之後，   one   grams_ 是一個 numpy 陣列，裡面包含差不多 14 億行資料，看起來像這樣（新增表頭部為了說明）：

1╒═══════════╤════════╤═════════╕
 2│   Is_Word │   Year │   Count │
 3╞═══════════╪════════╪═════════╡
 4│         0 │   1799 │       2 │
 5├───────────┼────────┼─────────┤
 6│         0 │   1804 │       1 │
 7├───────────┼────────┼─────────┤
 8│         0 │   1805 │       1 │
 9├───────────┼────────┼─────────┤
10│         0 │   1811 │       1 │
11├───────────┼────────┼─────────┤
12│         0 │   1820 │     ... │
13╘═══════════╧════════╧═════════╛

下面就可以開始分析資料了。

每年單詞總使用量

谷歌展示了每一個單詞出現的百分比（某個單詞在這一年出現的次數/所有單詞在這一年出現的總數），這比僅僅計算原單詞更有用。為了計算這個百分比，我們需要知道單詞總量的數目是多少。

幸運的是，numpy讓這個變得十分簡單：

 1last_year = 2008
 2YEAR_COL = '1'
 3COUNT_COL = '2'
 4year_totals, bins = np.histogram(
 5    one_grams[YEAR_COL],
 6    density=False,
 7    range=(0, last_year+1),
 8    bins=last_year + 1,
 9    weights=one_grams[COUNT_COL]
10)

繪製出這個圖來展示谷歌每年收集了多少單詞：

很清楚的是在 1800 年之前，資料總量下降很迅速，因此這回曲解最終結果，並且會隱藏掉我們感興趣的模式。為了避免這個問題，我們只匯入 1800 年以後的資料：

 1one_grams_tube = (tubes.Each(FILES)
 2    .read_files()
 3    .split()
 4    .tsv(headers=False)
 5    .skip_unless(lambda row: row.get(1).to(int).gt(1799))
 6    .multi(lambda row: (
 7        row.get(0).equals(word.encode('utf-8')),
 8        row.get(1).to(int),
 9        row.get(2).to(int)
10    ))
11)

這返回了 13 億行資料（1800 年以前只有 3.7% 的的佔比）

Python 在每年佔比百分數

獲得 python 在每年的佔比百分數現在就特別的簡單了。

使用一個簡單的技巧，建立基於年份的陣列，2008 個元素長度意味著每一年的索引等於年份的數字，因此，舉個例子，1995 就只是獲取 1995 年的元素的問題了。

這都不值得使用 numpy 來操作：

1word_rows = one_grams[IS_WORD_COL]
2word_counts = np.zeros(last_year+1)
3for _, year, count in one_grams[word_rows]:
4    word_counts[year] += (100*count) / year_totals[year]

繪製出 word_counts 的結果：

形狀看起來和谷歌的版本差不多

實際的佔比百分數並不匹配，我認為是因為下載的資料集，它包含的用詞方式不一樣（比如：Python_VERB）。這個資料集在 google page 中解釋的並不是很好，並且引起了幾個問題：

• 人們是如何將 Python 當做動詞使用的？

• 'Python' 的計算總量是否包含 'Python_VERB'？等

幸運的是，我們都清楚我使用的方法生成了一個與谷歌很像的圖示，相關的趨勢都沒有被影響，因此對於這個探索，我並不打算嘗試去修復。

效能

谷歌生成圖片在 1 秒鐘左右，相較於這個指令碼的 8 分鐘，這也是合理的。谷歌的單詞計算的後臺會從明顯的準備好的資料集檢視中產生作用。

舉個例子，提前計算好前一年的單詞使用總量並且把它存在一個單獨的查詢表會顯著的節省時間。同樣的，將單詞使用量儲存在單獨的資料庫/檔案中，然後建立第一列的索引，會消減掉幾乎所有的處理時間。

這次探索   確實   展示了，使用 numpy 和 初出茅廬的 pytubes 以及標準的商用硬體和 Python，在合理的時間內從十億行資料的資料集中載入，處理和提取任意的統計資訊是可行的，

Python，Pascal 和 Perl 對比

為了用一個稍微更復雜的例子來證明這個概念，我決定比較一下三個相關提及的程式語言：   Python，Pascal,   和 Perl.

源資料比較嘈雜（它包含了所有使用過的英文單詞，不僅僅是程式語言的提及，並且，比如，python 也有非技術方面的含義！），為了這方面的調整， 我們做了兩個事情：

1. 只有首字母大寫的名字形式能被匹配（Python，不是 python）

2. 每一個語言的提及總數已經被轉換到了從 1800 年到 1960 年的百分比平均數，考慮到 Pascal 在 1970 年第一次被提及，這應該有一個合理的基準線。

結果:

對比谷歌 (沒有任何的基準線調整):

執行時間: 只有 10 分鐘多一點。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69913713/viewspace-2648437/，如需轉載，請註明出處，否則將追究法律責任。