用Python玩?zhèn)€“小小的”大數(shù)據(jù)

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

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

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

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

挑戰(zhàn)

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

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

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

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

Loading the data

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

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

Python158742

Python162111

Python165122

Python165911

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

1.Word

2.Year of Publication

3.Total number of times the word was seen

4.Total number of books containing the word

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

1. 這個(gè)單詞是我們感興趣的？

2. 發(fā)布的年份

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

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

import tubes

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

WORD = "Python"

one_grams_tube = (tubes.Each(FILES)

.read_files()

.split()

.tsv(headers=False)

.multi(lambda row: (

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

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

row.get(2).to(int)

))

)

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

╒═══════════╤════════╤═════════╕

│ Is_Word │ Year │ Count │

╞═══════════╪════════╪═════════╡

│ 0 │ 1799 │ 2 │

├───────────┼────────┼─────────┤

│ 0 │ 1804 │ 1 │

├───────────┼────────┼─────────┤

│ 0 │ 1805 │ 1 │

├───────────┼────────┼─────────┤

│ 0 │ 1811 │ 1 │

├───────────┼────────┼─────────┤

│ 0 │ 1820 │ ... │

╘═══════════╧════════╧═════════╛

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

每一年的單詞總使用量

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

幸運(yùn)的是，numpy讓這個(gè)變得十分簡單：

last_year = 2008

YEAR_COL = '1'

COUNT_COL = '2'

year_totals, bins = np.histogram(

one_grams[YEAR_COL],

density=False,

range=(0, last_year+1),

bins=last_year + 1,

weights=one_grams[COUNT_COL]

)

繪制出這個(gè)圖來展示谷歌每年收集了多少單詞：

很清楚的是在 1800 年之前，數(shù)據(jù)總量下降很迅速，因此這回曲解最終結(jié)果，并且會(huì)隱藏掉我們感興趣的模式。為了避免這個(gè)問題，我們只導(dǎo)入 1800 年以后的數(shù)據(jù)：

one_grams_tube = (tubes.Each(FILES)

.read_files()

.split()

.tsv(headers=False)

.skip_unless(lambda row: row.get(1).to(int).gt(1799))

.multi(lambda row: (

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

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

row.get(2).to(int)

))

)

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

Python 在每年的占比百分?jǐn)?shù)

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

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

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

word_rows = one_grams[IS_WORD_COL]

word_counts = np.zeros(last_year+1)

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

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

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

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

實(shí)際的占比百分?jǐn)?shù)并不匹配，我認(rèn)為是因?yàn)橄螺d的數(shù)據(jù)集，它包含的用詞方式不一樣（比如：Python_VERB）。這個(gè)數(shù)據(jù)集在 google page 中解釋的并不是很好，并且引起了幾個(gè)問題：

人們是如何將 Python 當(dāng)做動(dòng)詞使用的？

'Python' 的計(jì)算總量是否包含 'Python_VERB'？等

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

性能

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

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

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

語言戰(zhàn)爭

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

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

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

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

結(jié)果:

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

運(yùn)行時(shí)間: 只有 10 分鐘多一點(diǎn)

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

以后的 PyTubes 提升

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

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

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

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