• 原文地址：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、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。