原文地址：Analysing 1.4 billion rows with python
原文作者：Steve Stagg
譯文出自：掘金翻譯計畫
本文永久連結：github.com/xitu/gold-m…
譯者：Ryden Sun
校對者：luochen1992 allen
Google Ngram viewer是一個有趣和有用的工具， 它使用谷歌從書本中掃描來的海量的資料寶藏，
這幅圖來自：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 真的很擅長處理大體量資料。
在 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. 單詞使用的總次數
通過提取這些資訊， 處理不同長度的字串資料的額外消耗被忽略掉了， 但是我們仍然需要對比不同字串的數值來區分哪些行資料是有我們感興趣的欄位的。
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 分鐘多一點
代碼: 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, 和 isoneof 可以輕易的添加，來明顯地提升載入字串資料是的有效性。
一如既往，非常歡迎大家 patches！
題圖：pexels，CC0 授權。
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 分鐘多一點
代碼: 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, 和 isoneof 可以輕易的添加，來明顯地提升載入字串資料是的有效性。
一如既往，非常歡迎大家 patches！
題圖：pexels，CC0 授權。