你的數據根本不夠大，別老扯什么Hadoop了

jopen 10年前發布 | 33K 次閱讀 Hadoop 分布式/云計算/大數據

  </span>本文原名“Don’t use Hadoop when your data isn’t that big ”，出自有著多年從業經驗的數據科學家Chris Stucchio，紐約大學柯朗研究所博士后，搞過高頻交易平臺，當過創業公司的CTO，更習慣稱自己為統計學者。對了，他現在自己創業，提供數據分析、推薦優化咨詢服務，他的郵件是：stucchio@gmail.com 。

      有人問我，“你在大數據和Hadoop方面有多少經驗？”我告訴他們，我一直在使用Hadoop，但是很少處理幾TB以上數據的任務 。我基本上只是一個大數據新手——知道概念，寫過代碼，但是沒有大規模經驗。

      他們又問我，“你能使用Hadoop做簡單的group by(分組)和sum(統計)嗎？”我說當然可以，但我會說需要看具體的文件格式。

他們給我一個U盤，里面存儲600MB數據（他們所有的數據，而不是樣本數據）。不知道為什么，我用pandas.read_csv（Pandas是一種Python數據分析庫）解決方案，而不是Hadoop完成了這個任務后，他們顯得很不滿意。
      Hadoop實際上是有很多局限性的。Hadoop可以運行一個通用的計算，下面我用偽碼進行說明：
Scala風格的偽碼：
  1. collection.flatMap( (k,v) => F(k,v) ).groupBy( _._1 ).map( _.reduce( (k,v) => G(k,v) ) )    
使用SQL風格的偽碼表示：
  1. SELECT G(...) FROM table GROUP BY F(...)    
      或者想我多年解釋一樣：
  1. 目標：統計計算圖書館書籍的數量  
  2. Map：你統計奇數書架上書的數量，我統計偶數書架上書的數量。（做統計的人越多，統計出結果越快，就是機器越多，效率越高）  
  3. Reduce：把我們每個人單獨統計的結果數據加在一起。  
        我們所做的只有兩個：F(k,v)和G(k,v)，除非要在中間步驟中做性能優化，其他一切都是固定的。

    在Hadoop里，所有計算都必須按照一個map、一個group by、一個aggregate或者這種計算序列來寫。這和穿上緊身衣一樣，多憋得慌啊。許多計算用其他模型其實更適合。穿上緊身衣（使用hadoop）的唯一原因就是，可以擴展到極大的數據集。可大多數情況，你的數據集很可能根本遠遠夠不上那個數量級。

    可是呢，因為Hadoop和大數據是熱詞，世界有一半的人都想穿上緊身衣，即使他們實際不需要Hadoop。

一、如果我的數據量是幾百兆，Excel可能沒法加載它
        對于Excel來說的“很大的數據”并非大數據，其實還有其它極好的工具可以使用——我喜歡的是基于Numpy庫之上Pandas。它可以將幾百MB數據以高效的向量化格式加載到內存，在我購買已3年的筆記本上，一眨眼的功夫，Numpy就能完成1億次浮點計算。Matlab和R也是極好的工具。
      Pandas構建于Numpy庫之上，可以以矢量格式的方式有效地把數百兆的數據載入到內存中。在我購買已3年的筆記本上，它可以用Numpy在一眨眼的功夫把1億的浮點數乘在一起。Matlab和R也是極好的工具。
       因此，對于幾百兆的數據量，典型的做法是寫一個簡單的Python腳本逐行讀取，處理，然后寫到了一個文件就行了

二、可我的數據是10GB呢？
       我買了臺新筆記本，它有16GB的內存（花$141.98）和256GB的SSD(額外200美元)。，如果在Pandas里加載一個10GB的csv文件，實際在內存里并沒有那么大（內存不是占有10G）——可以將 “17284932583” 這樣的數值串存為4位或者8位整數，“284572452.2435723”存為8位雙精度。
    最壞的情況下你還可以不同時將所有數據都一次加載到內存里。

三、可我的數據是100GB、500GB或1TB呢？

     一個2T的硬盤才94.99美元，4T是169.99。買一塊，加到桌面PC或者服務器上，然后裝上PostgreSQL來解決它

四、Hadoop << SQL或Python腳本

       在計算的表達能力來說，Hadoop比SQL差。Hadoop里能寫的計算，在SQL或者簡單的Python腳本都可以更輕松地寫出來。
       SQL是一個直觀的查詢語言，適合做業務分析，業務分析師和程序員都很常用。SQL查詢非常簡單，而且還非常快——只有數據庫使用了正確的索引，要花幾秒鐘的sql查詢都不太常見。
     Hadoop沒有索引的概念，Hadoop只有全表掃描，而且Hadoop抽象層次太多了——我之前的項目盡在應付Java內存錯誤（ java memory errors）、內存碎片和集群競用了，而這些時間遠多于實際的數據分析工作。
      如果你的數據并不是像SQL表那樣的結構化數據（比如純文本、JSON對象、二進制對象），通常是直接寫一個小的Python腳本或者Ruby腳本逐行處理更直接。保存到多個文件，然后逐個處理即可，SQL不適用的情況下，從編程來說Hadoop也沒那么糟糕，但相比Python腳本仍然沒有什么優勢。
    除了難以編程，Hadoop還一般總是比其他技術方案要慢。只要索引用得好，SQL查詢非常快。比如要計算join，PostgreSQL只需查看索引（如果有），然后查詢所需的每個鍵。而Hadoop呢，必須做全表掃描，然后重排整個表。排序通過多臺機器之間分片可以加速，但也帶來了跨多機數據流處理的開銷。如果要處理二進制文件，Hadoop必須反復訪問namenode。而簡單的Python腳本只要反復訪問文件系統即可。

五、我的數據超過了5TB

     只能使用Hadoop，而無需做過多的選擇。

    你的命可真苦——只能苦逼地折騰Hadoop了，沒有太多其他選擇（可能還能用許多硬盤容量的高富帥機器來扛），而且其他選擇往往貴得要命（腦海中浮現出IOE等等字樣……）。

    用Hadoop唯一的好處是擴展。如果你的數據是一個數TB的單表，那么全表掃描是Hadoop的強項。此外的話（如果你沒有這樣大數據量的表），請關愛生命，盡量遠離Hadoop。它帶來的煩惱根本不值，用傳統方法既省時又省力。

六、Hadoop是一個極好的工具

         我并不討厭Hadoop，當我用其它工具不能很好處理數據時我會選擇Hadoop。另外，我推薦使用Scalding，不要使用Hive或Pig。Scalding支持使用Scala語言來編寫Hadoop任務鏈，隱藏了其下的MapReduce。
 本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！