使用 pytubes，numpy 和 matplotlib

Google Ngram viewer是一個有趣和有用的工具，它使用谷歌從書本中掃描來的海量的數(shù)據(jù)寶藏，繪制出單詞使用量隨時間的變化。舉個例子，單詞 Python (區(qū)分大小寫)：

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

它是由谷歌的 n-gram 數(shù)據(jù)集驅(qū)動的，根據(jù)書本印刷的每一個年份，記錄了一個特定單詞或詞組在谷歌圖書的使用量。然而這并不完整(它并沒有包含每一本已經(jīng)發(fā)布的書!)，數(shù)據(jù)集中有成千上百萬的書，時間上涵蓋了從 16 世紀到 2008 年。數(shù)據(jù)集可以免費從這里下載。

我決定使用 Python 和我新的數(shù)據(jù)加載庫 PyTubes 來看看重新生成上面的圖有多容易。

挑戰(zhàn)

1-gram 的數(shù)據(jù)集在硬盤上可以展開成為 27 Gb 的數(shù)據(jù)，這在讀入 python 時是一個很大的數(shù)據(jù)量級。Python可以輕易地一次性地處理千兆的數(shù)據(jù)，但是當數(shù)據(jù)是損壞的和已加工的，速度就會變慢而且內(nèi)存效率也會變低。

總的來說，這 14 億條數(shù)據(jù)(1,430,727,243)分散在 38 個源文件中，一共有 2 千 4 百萬個(24,359,460)單詞(和詞性標注，見下方)，計算自 1505 年至 2008 年。

當處理 10 億行數(shù)據(jù)時，速度會很快變慢。并且原生 Python 并沒有處理這方面數(shù)據(jù)的優(yōu)化。幸運的是，numpy 真的很擅長處理大體量數(shù)據(jù)。 使用一些簡單的技巧，我們可以使用 numpy 讓這個分析變得可行。

在 python/numpy 中處理字符串很復(fù)雜。字符串在 python 中的內(nèi)存開銷是很顯著的，并且 numpy 只能夠處理長度已知而且固定的字符串。基于這種情況，大多數(shù)的單詞有不同的長度，因此這并不理想。

Loading the data

下面所有的代碼/例子都是運行在 8 GB 內(nèi)存 的 2016 年的 Macbook Pro。 如果硬件或云實例有更好的 ram 配置，表現(xiàn)會更好。

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

1. Python 1587 4 2

2. Python 1621 1 1

3. Python 1651 2 2

4. Python 1659 1 1

每一條數(shù)據(jù)包含下面幾個字段：

1. Word

2. Year of Publication

3. Total number of times the word was seen

4. Total number of books containing the word

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

1. 這個單詞是我們感興趣的?

2. 發(fā)布的年份

3. 單詞使用的總次數(shù)

通過提取這些信息，處理不同長度的字符串數(shù)據(jù)的額外消耗被忽略掉了，但是我們?nèi)匀恍枰獙Ρ炔煌�字符串的�?shù)值來區(qū)分哪些行數(shù)據(jù)是有我們感興趣的字段的。這就是 pytubes 可以做的工作：

1. import tubes

2. FILES = glob.glob(path.expanduser("~/src/data/ngrams/1gram/googlebooks*"))

3. WORD = "Python"

4. one_grams_tube = (tubes.Each(FILES)

5. .read_files()

6. .split()

7. .tsv(headers=False)

8. .multi(lambda row: (

9. row.get(0).equals(WORD.encode('utf-8')),

10. row.get(1).to(int),

11. row.get(2).to(int)

12. ))

13. )

差不多 170 秒(3 分鐘)之后， onegrams_ 是一個 numpy 數(shù)組，里面包含差不多 14 億行數(shù)據(jù)，看起來像這樣(添加表頭部為了說明)：

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 方法來計算一些東西的問題了：

每一年的單詞總使用量

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

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

1. last_year = 2008

2. YEAR_COL = '1'

3. COUNT_COL = '2'

4. year_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 年之前，數(shù)據(jù)總量下降很迅速，因此這回曲解最終結(jié)果，并且會隱藏掉我們感興趣的模式。為了避免這個問題，我們只導(dǎo)入 1800 年以后的數(shù)據(jù)：

1. one_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 億行數(shù)據(jù)(1800 年以前只有 3.7% 的的占比)

Python 在每年的占比百分數(shù)

獲得 python 在每年的占比百分數(shù)現(xiàn)在就特別的簡單了。

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

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

1. word_rows = one_grams[IS_WORD_COL]

2. word_counts = np.zeros(last_year+1)

3. for _, year, count in one_grams[word_rows]:

4. word_counts[year] += (100*count) / year_totals[year]

繪制出 word_counts 的結(jié)果：

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

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

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

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

幸運的是，我們都清楚我使用的方法生成了一個與谷歌很像的圖標，相關(guān)的趨勢都沒有被影響，因此對于這個探索，我并不打算嘗試去修復(fù)。

性能

谷歌生成圖片在 1 秒鐘左右，相較于這個腳本的 8 分鐘，這也是合理的。谷歌的單詞計算的后臺會從明顯的準備好的數(shù)據(jù)集視圖中產(chǎn)生作用。

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

這次探索 確實 展示了，使用 numpy 和 初出茅廬的 pytubes 以及標準的商用硬件和 Python，在合理的時間內(nèi)從十億行數(shù)據(jù)的數(shù)據(jù)集中加載，處理和提取任意的統(tǒng)計信息是可行的，

語言戰(zhàn)爭

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

源數(shù)據(jù)比較嘈雜(它包含了所有使用過的英文單詞，不僅僅是編程語言的提及，并且，比如，python 也有非技術(shù)方面的含義!)，為了這方面的調(diào)整， 我們做了兩個事情：

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

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

結(jié)果:

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

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

代碼: gist.github.com/stestagg/91…

以后的 PyTubes 提升

在這個階段，pytubes 只有單獨一個整數(shù)的概念，它是 64 比特的。這意味著 pytubes 生成的 numpy 數(shù)組對所有整數(shù)都使用 i8 dtypes。在某些地方(像 ngrams 數(shù)據(jù))，8 比特的整型就有點過度，并且浪費內(nèi)存(總的 ndarray 有 38Gb，dtypes 可以輕易的減少其 60%)。 我計劃增加一些等級 1，2 和 4 比特的整型支持(github.com/stestagg/py…)

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

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

一如既往，非常歡迎大家 patches!

標簽： Google 代碼 谷歌 腳本 數(shù)據(jù) 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。