最近，我加入了Cloudera，在這之前，我在計算生物學/基因組學上已經(jīng)工作了差不多10年。我的分析工作主要是利用Python語言和它很棒的科學計算棧來進行的。但Apache Hadoop的生態(tài)系統(tǒng)大部分都是用Java來實現(xiàn)的，也是為Java準備的，這讓我很惱火。所以，我的頭等大事變成了尋找一些Python可以用的Hadoop框架。

在這篇文章里，我會把我個人對這些框架的一些無關科學的看法寫下來，這些框架包括:

最終，在我的看來，Hadoop的數(shù)據(jù)流(streaming)是最快也是最透明的選項，而且最適合于文本處理。mrjob最適合于在Amazon EMR上快速工作，但是會有顯著的性能損失。dumbo 對于大多數(shù)復雜的工作都很方便(對象作為鍵名(key))，但是仍然比數(shù)據(jù)流(streaming)要慢。

請繼續(xù)往下閱讀，以了解實現(xiàn)細節(jié)，性能以及功能的比較。

一個有趣的問題

為了測試不同的框架，我們不會做“統(tǒng)計詞數(shù)”的實驗，轉而去轉化谷歌圖書N-元數(shù)據(jù)。 N-元代表一個n個詞構成的元組。這個n-元數(shù)據(jù)集提供了谷歌圖書文集中以年份分組的所有1-，2-，3-，4-，5-元記錄的統(tǒng)計數(shù)目。 在這個n-元數(shù)據(jù)集中的每行記錄都由三個域構成：n-元，年份，觀測次數(shù)。(您能夠在http://books.google.com/ngrams取得數(shù)據(jù))。

我們希望去匯總數(shù)據(jù)以觀測統(tǒng)計任何一對相互臨近的詞組合所出現(xiàn)的次數(shù)，并以年份分組。實驗結果將使我們能夠判斷出是否有詞組合在某一年中比正常情況出現(xiàn)的更為頻繁。如果統(tǒng)計時，有兩個詞在四個詞的距離內出現(xiàn)過，那么我們定義兩個詞是“臨近”的。 或等價地，如果兩個詞在2-，3-或者5-元記錄中出現(xiàn)過，那么我們也定義它們是”臨近“的。 一次，實驗的最終產(chǎn)物會包含一個2-元記錄，年份和統(tǒng)計次數(shù)。

有一個微妙的地方必須強調。n-元數(shù)據(jù)集中每個數(shù)據(jù)的值都是通過整個谷歌圖書語料庫來計算的。從原理上來說，給定一個5-元數(shù)據(jù)集，我可以通過簡單地聚合正確的n-元來計算出4-元、3-元和2-元數(shù)據(jù)集。例如，當5-元數(shù)據(jù)集包含
 

(the, cat, in, the, hat)    1999   20(the, cat, is, on, youtube)  1999   13(how, are, you, doing, today) 1986  5000

時，我們可以將它聚合為2-元數(shù)據(jù)集以得出如下記錄
 

(the, cat) 1999  33   // 也就是, 20 + 13

然而，實際應用中，只有在整個語料庫中出現(xiàn)了40次以上的n元組才會被統(tǒng)計進來。所以，如果某個5元組達不到40次的閾值，那么Google也提供組成這個5元組的2元組數(shù)據(jù)，這其中有一些或許能夠達到閾值。出于這個原因，我們用相鄰詞的二元數(shù)據(jù)，隔一個詞的三元組，隔兩個詞的四元組，以此類推。換句話說，與給定二元組相比，三元組多的只是最外層的詞。除了對可能的稀疏n元數(shù)據(jù)更敏感，只用n元組最外層的詞還有助于避免重復計算。總的來說，我們將在2元、3元、4元和5元數(shù)據(jù)集上進行計算。