[譯] 使用 python 分析 14 億條數據

• 原文地址：Analysing 1.4 billion rows with python
• 原文做者：Steve Stagg
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：Ryden Sun
• 校對者：luochen1992 allen

使用 python 分析 14 億條數據

使用 pytubes，numpy 和 matplotlib

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"

# Set up the data load pipeline
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)
    ))
)

# 將數據讀入一個 numpy 數組。經過設置一個大概的精準度
# 預估行數，pytubes 優化分配模式 
# fields=True 這裏是冗餘的，可是確保了返回的 ndarray
# 使用字段，而不是一個單獨的多維數組 one_grams = one_grams_tube.ndarray(estimated_rows=500_000_000, fields=True)
複製代碼

差很少 170 秒（3 分鐘）以後， one_grams 是一個 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 來操做：

# 找到匹配的行 (column 是 Ture)
word_rows = one_grams[IS_WORD_COL]
# 建立一個空數組來保存每一年佔比百分數的值 
word_counts = np.zeros(last_year+1)
# 迭代至每條匹配的數據 （匹配一個單詞時，應該只有幾千行數據）
for _, year, count in one_grams[word_rows]:
    # 設置相關的 word_counts 行爲計算後的數值
    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 也有非技術方面的含義！），爲了這方面的調整， 咱們作了兩個事情：

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

結果:

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

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

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

之後的 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 能夠輕易的添加，來明顯地提高加載字符串數據是的有效性。

一如既往，很是歡迎你們 patches！

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。