Hadoop Streaming模式的優缺點？

01-15

Hadoop Streaming是臨時任務最常使用的模式，理論上適於數據規模較小、業務邏輯簡單的小M-R。在實際的工業應用中，使用Python等簡單腳本語言寫成、規模較大的Streaming任務也很常見，比如我就很無恥的用Python寫了一個數據規模很大（每個集群的原始數據都在幾十TB級別），複雜度也不能算低（13個節點）的例行DAG任務，每個Mapper佔用1000個Task Tracker，Reducer也要佔用300～500個。。可它真的是個streaming

優點:

1，直接：在TaskTracker上執行時直接以stdin/stdout作為數據傳輸媒介，意味著你可以用任何語言編寫Map-Reduce任務。Hadoop是用來處理以文件形式保存和輸出的超大規模半結構化數據的，這種數據一般隨機性強，Linux Shell、Python這種能直接運行的腳本語言本身就是最佳選擇。一些原先在單機上跑的、基於文件的任務腳本，可以輕易修改為Map-Reduce任務，從而在分散式集群上跑。

2，方便靈活：對於一些邏輯不複雜的任務，可以使用簡單腳本語言（Python, Shell, Perl等等）編寫和提交任務，不需要編譯，不用打jar包，只要Task Tracker上有相應的環境即可立即執行，而執行語句也可以在提交時指定，這對於平時經常使用Linux的同學來說實在太方便了，pipeline, cat, 甚至awk都可以自如使用，因為它的執行者就是shell本身

缺點：

1，慢，這是使用了標準輸入/輸出的緣故，數據交換過程不如Java API直接（不過，過多或過少Mapper數量，以及分桶不均等問題也會造成數據IO極不正常的慢）

2，無法避免的數據類型轉換：還是因為stdin/out的緣故，數據以文本類型在節點之間交互，這點暫不必說；而Java API則使用了專門封裝過的數據類型

3，那個關於Key的故事：作為分桶和Reduce前排序的依據，Streaming模式貌似只能支持以第一個之前的那一坨為key。我們自行開發的Hadoop分支已經支持多key排序，不知當前社區版的情況如何

4，習慣OO同學，您還是用Java吧：如果文件比較多，而且帶有目錄結構的話呢，使用Streaming模式只有一種選擇：archive，使用時請注意如果壓縮一定要用gzip，後綴使用tgz或者tar.gz，否則可能悲劇。

5，關於字典：一定要用archive，用file在分發任務的時候會將字典文件上傳到每台task tracker上，字典大的話IO壓力會比較大

說了這麼多，也摻雜一些自己平時的使用體會和閑扯。因為平時使用的是公司自行開發時間較長的Hadoop分支，一些敘述不見得和社區版相符，還請各位指正。

優點：只要是支持stdin stdout的語言都可以用來實現MapReduce演算法，這對於非Java程序員來編寫MapReduce程序非常友好。但是有了Hive這樣的類SQL的介面（並且內置的函數也越來越全了），除了要滿足比較複雜的需求之外，這種Streaming的優勢也不是那麼明顯了。

缺點：慢。在以前的工作中用過last.fm的Dumbo框架（Python實現）用來寫MapReduce程序，寫起程序來非常爽，Java幾十行的WordCount，用Dumbo只需要4、5行的代碼即可，也可以正常執行；可是執行的效率不敢恭維，與對應的Java實現相去甚遠。

優點自然是它支持多種語言編寫mapreduce程序了，包括Bash、PHP、Ruby、Python、C/C++等等，甚至可以使用Java類作為map/reduce。

它用UNIX的標準流作為介面，stdin輸入，stdout輸出。

缺點可能就是靈活性上有些限制，用起來不如提交jar作業方便些，比如它默認的輸入輸出格式（按行切割，分割key/value，文本輸入輸出格式）等，都需要額外參數調整。好像在作業運行時的實時信息顯示也不充足。

優點是任何語言都可以寫，缺點是細節無法控制，比如不能寫自定義的partitioner, combiner,writablecomparable等，而java可以完成。streaming的執行都是阻塞的，java執行可以非阻塞。

最致命的缺陷--性能，最大的優點-本地調試，，，我倒覺得應該強推這個，把邏輯從hadoop裡面徹底釋放出來

優點：上手容易

缺點：功能有限，不能自己寫partitioner