Google Ngram viewer是一個有趣和有用的工具，它使用谷歌從書本中掃描來的海量的數據寶藏，繪製出單詞使用量隨時間的變化。

舉個例子，單詞 Python (區分大小寫) ：

這幅圖來自：books.google.com/ngrams… ，描繪了單詞 ‘Python’ 的使用量隨時間的變化。

它是由谷歌的n-gram 數據集驅動的，根據書本印刷的每一個年份，記錄了一個特定單詞或片語在谷歌圖書的使用量。然而這並不完整（它並沒有包含每一本已經發佈的書！），數據集中有成千上百萬的書，時間上涵蓋了從 16 世紀到 2008 年。數據集可以免費從這裡下載。

我決定使用 Python 和我新的數據載入庫 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，有時候不知道怎麼學，從哪裡開始學。掌握了基本的一些語法或者做了兩個案例後，不知道下一步怎麼走，不知道如何去學習更加高深的知識。
# 那麼對於這些大兄弟們，我準備了大量的免費視頻教程，PDF電子書籍，以及源代碼！
# 還會有大佬解答！
# 都在這個裙里了：708525271
# 歡迎加入，一起討論 一起學習！

Loading the data

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

1-gram 的數據是以 tab 鍵分割的形式儲存在文件中，看起來如下：

每一條數據包含下麵幾個欄位：

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

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

差不多 170 秒（3 分鐘）之後， one_grams 是一個 numpy 數組，裡面包含差不多 14 億行數據，看起來像這樣（添加表頭部為了說明）：

從這開始，就只是一個用 numpy 方法來計算一些東西的問題了：

每一年的單詞總使用量

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

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

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

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

這返回了 13 億行數據（1800 年以前只有 3.7% 的的占比）

Python 在每年的占比百分數

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

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

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

繪製出 word_counts 的結果：

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

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

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

‘Python’ 的計算總量是否包含 ‘Python_VERB’？等

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

性能

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

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

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

語言戰爭

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

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

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

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

結果:

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

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

以後的 PyTubes 提升

在這個階段，pytubes 只有單獨一個整數的概念，它是 64 比特的。這意味著 pytubes 生成的 numpy 數組對所有整數都使用 i8 dtypes。在某些地方（像 ngrams 數據），8 比特的整型就有點過度，並且浪費記憶體（總的 ndarray 有 38Gb，dtypes 可以輕易的減少其 60%）。

我計劃增加一些等級 1，2 和 4 比特的整型支持( github.com/stestagg/py… )

更多的過濾邏輯 - Tube.skip_unless() 是一個比較簡單的過濾行的方法，但是缺少組合條件（AND/OR/NOT）的能力。這可以在一些用例下更快地減少載入數據的體積。

更好的字元串匹配 —— 簡單的測試如下：startswith, endswith, contains, 和 is_one_of 可以輕易的添加，來明顯地提升載入字元串數據是的有效性。