Google Ngram viewer是一個有趣且有用的工具，它使用Google從書本中掃描來的海量的資料寶藏，繪製出單字使用量隨時間的變化。舉個例子，單字Python (區分大小寫) ：
這幅圖來自： books.google.com/ngrams… ，描繪了單字'Python' 的使用量隨時間的變化。
它是由Google的n-gram 資料集驅動的，根據書本印刷的每一個年份，記錄了一個特定單字或詞組在Google圖書中的使用量。然而這並不完整（它並沒有包含每一本已經發布的書！），數據集中有成千上萬的書，時間上涵蓋了從 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 只能夠處理長度已知且固定的字串。基於這種情況，大多數的單字有不同的長度，因此這並不理想。
下面所有的程式碼/範例都是運行在 8 GB 記憶體 的 2016 年的 Macbook Pro。如果硬體或雲端實例有更好的 ram 配置，表現會更好。
1-gram 的資料是以tab 鍵分割的形式儲存在檔案中，看起來如下：
每個資料包含下面幾個字段：
為了依照要求產生圖表，我們只需要知道這些信息，也就是：
##╞═════ ══ ══════╡
│ 0 │ 1799 │ 2 │
#├───────────┼────────┼── ───────┤
│ 0 │ 1804 │ 1 │
├───────────┼────────┼─ ────────┤
│ 0 │ 1805 │ 1 │
├───────────┼────────┼ ─────────┤
│ 0 │ 1811 │ 1 │
##│ 0 │ 1811 │ 1 │
├───────────┼──────── ┼─────────┤
│ 0 │ 1820 │ ... │
╘══════════ ═══╧═════════╛
從這開始，就只是一個用numpy 方法來計算一些東西的問題了：
每一年的單字總使用量
Google展示了每個單字出現的百分比（某個單字在這一年出現的次數/所有單字在這一年出現的總數），這比僅僅計算原始單字更有用。為了計算這個百分比，我們需要知道單字總量的數目是多少。
幸運的是，numpy讓這個變得十分簡單：
#繪製出這個圖來展示Google每年收集了多少單字：
很清楚的是在1800 年之前，資料總量下降很迅速，因此這回曲解最終結果，並且會隱藏掉我們感興趣的模式。為了避免這個問題，我們只導入1800 年以後的資料：
這回傳了13 億行資料（1800 年以前只有3.7% 的佔比）
獲得python 在每年的佔比百分數現在就特別的簡單了。
使用一個簡單的技巧，創建基於年份的數組，2008 個元素長度意味著每一年的索引等於年份的數字，因此，舉個例子，1995 就只是獲取1995 年的元素的問題了。
這都不值得使用numpy 來操作：
#繪製出word_counts 的結果：
#形狀看起來和Google的版本差不多
實際的佔比百分數並不匹配，我認為是因為下載的資料集，它包含的用詞方式不一樣（例如：Python_VERB）。這個資料集在 google page 中解釋的並不是很好，並且引起了幾個問題： 們是如何將 Python 當作動詞使用的？ ‘Python’ 的計算總量是否包含 ‘Python_VERB’？等等
幸運的是，我們都清楚我使用的方法產生了一個與Google很像的圖標，相關的趨勢都沒有被影響，因此對於這個探索，我並不打算嘗試去修復。
效能
###Google生成圖片在 1 秒左右，相較於這個腳本的 8 分鐘，這也是合理的。谷歌的單字計算的後台會從明顯的準備好的資料集視圖中產生作用。 ######舉個例子，提前計算好前一年的單字使用總量並且把它存在一個單獨的查找表會顯著的節省時間。同樣的，將單字使用量保存在單獨的資料庫/檔案中，然後建立第一列的索引，會消減掉幾乎所有的處理時間。 ######這次探索確實展示了，使用numpy 和初出茅廬的pytubes 以及標準的商用硬體和Python，在合理的時間內從十億行資料的資料集中加載，處理和提取任意的統計資料是可行的，######語言戰爭######為了用一個稍微更複雜的例子來證明這個概念，我決定比較一下三個相關提及的程式語言： Python，Pascal, 和Perl. ######來源資料比較吵雜（它包含了所有使用過的英文單詞，不僅僅是程式語言的提及，並且，例如，python 也有非技術方面的含義！），為了這方面的調整，我們做了兩個事情：###### 只有首字母大寫的名字形式能被匹配（Python，不是python）###### 每一種語言的提及總數已經被轉換到了從1800 年到1960 年的百分比平均數，考慮到Pascal 在1970 年第一次被提及，這應該有一個合理的基準線。 ######結果:###############比較Google ( 沒有任何的基準線調整 ):###
運行時間: 只有10 分鐘多一點
在這個階段，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 可以輕易的添加，來明顯地提升載入字串資料是的有效性。
以上是使用 Python 分析 14 億條數據的詳細內容。更多資訊請關注PHP中文網其他相關文章！
