【實戰】使用 Python 分析 14 億條資料

英文 / Steve Stagg，翻譯 / Ryden Sun，編輯 / 昱良

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

這幅圖來自：books.google.com/ngrams/grap…，描繪了單詞 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 隻能夠處理長度已知而且固定的字元串。基于這種情況，大多數的單詞有不同的長度，是以這并不理想。

Loading the data

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

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

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

複制

每一條資料包含下面幾個字段：

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. 釋出的年份
3. 單詞使用的總次數

複制

通過提取這些資訊，處理不同長度的字元串資料的額外消耗被忽略掉了，但是我們仍然需要對比不同字元串的數值來區分哪些行資料是有我們感興趣的字段的。這就是 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_ 是一個 numpy 數組，裡面包含差不多 14 億行資料，看起來像這樣（添加表頭部為了說明）：

╒═══════════╤════════╤═════════╕
│   Is_Word │   Year │   Count │
╞═══════════╪════════╪═════════╡
│         0 │   1799 │       2 │
├───────────┼────────┼─────────┤
│         0 │   1804 │       1 │
├───────────┼────────┼─────────┤
│         0 │   1805 │       1 │
├───────────┼────────┼─────────┤
│         0 │   1811 │       1 │
├───────────┼────────┼─────────┤
│         0 │   1820 │     ... │
╘═══════════╧════════╧═════════╛

複制

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

每一年的單詞總使用量

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

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

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]
)

複制

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

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

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 億行資料（1800 年以前隻有 3.7% 的的占比）

Python 在每年的占比百分數

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

使用一個簡單的技巧，建立基于年份的數組，2008 個元素長度意味着每一年的索引等于年份的數字，是以，舉個例子，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 的結果：

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

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

人們是如何将 Python 當做動詞使用的？
Python 的計算總量是否包含 Python_VERB ？等

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

性能

谷歌生成圖檔在 1 秒鐘左右，相較于這個腳本的 8 分鐘，這也是合理的。谷歌的單詞計算的背景會從明顯的準備好的資料集視圖中産生作用。

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

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

語言戰争

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

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

隻有首字母大寫的名字形式能被比對（Python，不是 python）
每一個語言的提及總數已經被轉換到了從 1800 年到 1960 年的百分比平均數，考慮到 Pascal 在 1970 年第一次被提及，這應該有一個合理的基準線。

結果:

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

運作時間: 隻有 10 分鐘多一點

代碼: https://gist.github.com/stestagg/910859576f44f20e509822365414290d

以後的 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, 和 isoneof 可以輕易的添加，來明顯地提升加載字元串資料是的有效性。

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