有人問我，“你在大數據和Hadoop方面有多少經驗？”我告訴他們，我一直在使用Hadoop，但是我處理的數據集很少有大于幾個TB的。
他們又問我，“你能使用Hadoop做簡單的分組和統計嗎？”我說當然可以，我只是告訴他們我需要看一些文件格式的例子。
他們遞給我一個包含600MB數據的閃盤，看起來這些數據并非樣本數據，由于一些我不能理解的原因，當我的解決方案涉及到pandas.read_csv文件，而不是Hadoop，他們很不愉快。
Hadoop實際上是有很多局限的。Hadoop允許你運行一個通用的計算，下面我用偽碼進行說明：
目標：計算圖書館書籍的數量
Map：你統計奇數書架上書的數量，我統計偶數書架上書的數量。（人越多，統計越快）
Reduce：把我們單獨統計后的數據加在一起。
我們所做的只有兩個：F(k,v)和G(k,v)，除開在中間步驟中的性能優化，一切都是固定的。
它會迫使你在Map中進行所有的計算，分組和統計，執行運算的方式像是穿上了緊身衣，其實很多計算更適合選用其它模型。穿上緊身衣的唯一原因是這可能會擴展到非常大的數據集上，而大多數情況下，你的數據量可能會小幾個數量級。
但是由于“大數據”和“Hadoop”這兩個熱門詞，即使很多人實際上不需要Hadoop，他們也愿意穿上“緊身衣”。
一、如果我的數據量是幾百兆，Excel可能沒法加載它對于Excel軟件來說的“很大的數據”并非大數據，其實還有其它極好的工具可以使用——我喜歡的Pandas。Pandas構建于Numpy庫 之上，可以以矢量格式的方式有效地把數百兆的數據載入到內存中。在我購買已3年的筆記本上，它可以用Numpy在一眨眼的功夫把1億的浮點數乘在一起。 Matlab和R也是極好的工具。
對于幾百兆的數據量，典型的做法是寫一個簡單的Python腳本按行讀取文件行，并處理它，向另一個文件寫入。
二、如果我的數據是10GB呢我買了個新筆記本，它有16GB的內存和256GB的SSD。如果你要載入一個10GB的CSV文件到Pandas，它占用的內存實際上是很小的 ——其結果是以數字類型的字符串保存的，如“17284832583”作為4字節貨8字節的整數，或存儲“284572452.2435723”字符串作 為8字節的雙精度浮點數。
最壞的情況是你或許不能把所有的數據都同時載入到內存中。
三、如果我的數據是100GB、500GB或1TB呢買個2TB或4TB的硬盤，在桌面PC或服務器上安裝一個Postgre來解決它。
四、Hadoop遠遠比不上SQL或Python腳本在計算的表達方面，Hadoop弱于SQL，也弱于Python腳本。
SQL是一個很直接的查詢語言，適合做業務分析，SQL的查詢相當簡單，而且還非常快——如果你的數據庫使用了正確的索引，二級查詢或多級查詢另當別論。
Hadoop沒有索引的概念，Hadoop只有全表掃描，Hadoop有高度泄露抽象——我花了很多時間來處理Java的內存錯誤、文件碎片以及集群競爭，這些時間遠大于我花在數據分析上的時間。
如果你的數據并不是像SQL表那樣的結構化數據（比如純文本、JSON對象、二進制對象），通常是直接寫一個小的Python腳本來按行處理你的數據。把數據存儲于文件，處理每一個文件，等等。如果換成是Hadoop就很麻煩。
相比于SQL或Python腳本，Hadoop要慢的多。正確的使用索引后，SQL查詢總是非快——PostgreSQL簡單的查找索引，檢索確 切的鍵值。而Hadoop是全表掃描的，它會把整個表進行重新排序。通過把數據表分片到多臺計算機上后，重排序是很快的。另一方面，處理二進制對 象，Hadoop需要重復往返于命名節點，目的是查找和處理數據。這適合用Python腳本來實現。
五、我的數據超過了5TB你應該考慮使用Hadoop，而無需做過多的選擇。
使用Hadoop唯一的好處是可伸縮性非常好。如果你有一個包含了數TB數據的表，Hadoop有一個適合全表掃描的選項。如果你沒有這樣大數據量的表，那么你應該像躲避瘟疫那樣避免使用Hadoop。這樣使用傳統的方法來解決問題會更輕松。
六、Hadoop是一個極好的工具我并不討厭Hadoop，當我用其它工具不能很好處理數據時我會選擇Hadoop。另外，我推薦使用Scalding，不要使用Hive或Pig。Scalding支持使用Scala語言來編寫Hadoop任務鏈，隱藏了其下的MapReduce。
京公網安備 11010502049343號