你用 Python 處理過的最大數據集有多大?我想大概不會超過上億條吧,今天分享一個用 Python 處理分析 14 億條數據的案python
這份 14 億條數據集來自 Google Books ,由 Google Ngram viewer 生成,根據書本印刷的每個年份,記錄了一個特定單詞或詞組在谷歌圖書的使用量。數據集中有成千上百萬的書,時間上涵蓋了從 16 世紀到 2008 年。能夠繪製出單詞使用量隨時間的變化,好比查詢「Python 」在歷史中出現的頻率。web
下面使用 Python 的 PyTubes 數據庫來加載上面的數據集,而後分析生成上面這樣一張圖。PyTubes 是一個專門用來加載大數據源的庫。數據庫
1-gram 的數據集在硬盤上能夠展開成爲 27 Gb 的數據,這在讀入 python 時是一個很大的數據量級。Python能夠輕易地一次性地處理千兆的數據,可是當數據是損壞的和已加工的,速度就會變慢並且內存效率也會變低。django
總的來講,這 14 億條數據(1,430,727,243)分散在 38 個源文件中,一共有 2 千 4 百萬個(24,359,460)單詞(和詞性標註,見下方),計算自 1505 年至 2008 年。編程
當處理 10 億行數據時,速度會很快變慢。而且原生 Python 並無處理這方面數據的優化。幸運的是,numpy 真的很擅長處理大致量數據。使用一些簡單的技巧,咱們可使用 numpy 讓這個分析變得可行。數組
在 python/numpy 中處理字符串很複雜。字符串在 python 中的內存開銷是很顯著的,而且 numpy 只可以處理長度已知並且固定的字符串。基於這種狀況,大多數的單詞有不一樣的長度,所以這並不理想。less
你們在學python的時候確定會遇到不少難題,以及對於新技術的追求,這裏推薦一下咱們的Python學習扣qun:784758214,這裏是python學習者彙集地!!同時,本身是一名高級python開發工程師,從基礎的python腳本到web開發、爬蟲、django、數據挖掘等,零基礎到項目實戰的資料都有整理。送給每一位python的小夥伴!每日分享一些學習的方法和須要注意的小細節編程語言
點擊:python技術分享交流性能
下面全部的代碼/例子都是運行在 8 GB 內存 的 2016 年的 Macbook Pro。若是硬件或雲實例有更好的 ram 配置,表現會更好。學習
1-gram 的數據是以 tab 鍵分割的形式儲存在文件中,看起來以下:
1Python 1587 4 2 2Python 1621 1 1 3Python 1651 2 2 4Python 1659 1 1
每一條數據包含下面幾個字段:
11. Word 22. Year of Publication 33. Total number of times the word was seen 44. Total number of books containing the word
爲了按照要求生成圖表,咱們只須要知道這些信息,也就是:
11. 這個單詞是咱們感興趣的? 22. 發佈的年份 33. 單詞使用的總次數
經過提取這些信息,處理不一樣長度的字符串數據的額外消耗被忽略掉了,可是咱們仍然須要對比不一樣字符串的數值來區分哪些行數據是有咱們感興趣的字段的。這就是 pytubes 能夠作的工做:
1import tubes 2 3FILES = glob.glob(path.expanduser("~/src/data/ngrams/1gram/googlebooks*")) 4WORD = "Python" 5one_grams_tube = (tubes.Each(FILES) 6 .read_files() 7 .split() 8 .tsv(headers=False) 9 .multi(lambda row: ( 10 row.get(0).equals(WORD.encode('utf-8')), 11 row.get(1).to(int), 12 row.get(2).to(int) 13 )) 14)
差很少 170 秒(3 分鐘)以後, one grams_ 是一個 numpy 數組,裏面包含差很少 14 億行數據,看起來像這樣(添加表頭部爲了說明):
1╒═══════════╤════════╤═════════╕ 2│ Is_Word │ Year │ Count │ 3╞═══════════╪════════╪═════════╡ 4│ 0 │ 1799 │ 2 │ 5├───────────┼────────┼─────────┤ 6│ 0 │ 1804 │ 1 │ 7├───────────┼────────┼─────────┤ 8│ 0 │ 1805 │ 1 │ 9├───────────┼────────┼─────────┤ 10│ 0 │ 1811 │ 1 │ 11├───────────┼────────┼─────────┤ 12│ 0 │ 1820 │ ... │ 13╘═══════════╧════════╧═════════╛
下面就能夠開始分析數據了。
谷歌展現了每個單詞出現的百分比(某個單詞在這一年出現的次數/全部單詞在這一年出現的總數),這比僅僅計算原單詞更有用。爲了計算這個百分比,咱們須要知道單詞總量的數目是多少。
幸運的是,numpy讓這個變得十分簡單:
1last_year = 2008 2YEAR_COL = '1' 3COUNT_COL = '2' 4year_totals, bins = np.histogram( 5 one_grams[YEAR_COL], 6 density=False, 7 range=(0, last_year+1), 8 bins=last_year + 1, 9 weights=one_grams[COUNT_COL] 10)
繪製出這個圖來展現谷歌每一年收集了多少單詞:
很清楚的是在 1800 年以前,數據總量降低很迅速,所以這回曲解最終結果,而且會隱藏掉咱們感興趣的模式。爲了不這個問題,咱們只導入 1800 年之後的數據:
1one_grams_tube = (tubes.Each(FILES) 2 .read_files() 3 .split() 4 .tsv(headers=False) 5 .skip_unless(lambda row: row.get(1).to(int).gt(1799)) 6 .multi(lambda row: ( 7 row.get(0).equals(word.encode('utf-8')), 8 row.get(1).to(int), 9 row.get(2).to(int) 10 )) 11)
這返回了 13 億行數據(1800 年之前只有 3.7% 的的佔比)
得到 python 在每一年的佔比百分數如今就特別的簡單了。
使用一個簡單的技巧,建立基於年份的數組,2008 個元素長度意味着每年的索引等於年份的數字,所以,舉個例子,1995 就只是獲取 1995 年的元素的問題了。
這都不值得使用 numpy 來操做:
1word_rows = one_grams[IS_WORD_COL] 2word_counts = np.zeros(last_year+1) 3for _, year, count in one_grams[word_rows]: 4 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 分鐘多一點。