python hadoop streaming_Hadoop Streaming模式的优缺点？

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模式貌似只能支持以第一个\t之前的那一坨为key。我们自行开发的Hadoop分支已经支持多key排序，不知当前社区版的情况如何

4，习惯OO同学，您还是用Java吧：如果文件比较多，而且带有目录结构的话呢，使用Streaming模式只有一种选择：archive，使用时请注意如果压缩一定要用gzip，后缀使用tgz或者tar.gz，否则可能悲剧。

5，关于字典：一定要用archive，用file在分发任务的时候会将字典文件上传到每台task tracker上，字典大的话IO压力会比较大

说了这么多，也掺杂一些自己平时的使用体会和闲扯。因为平时使用的是公司自行开发时间较长的Hadoop分支，一些叙述不见得和社区版相符，还请各位指正。