笔者在经历由Sql server数据处理，转型到hadoop数据处理整个过程，日处理数据量级在10亿左右，

总结一些自己的想法

1，在一个job内，整个拓扑集群在map，reduce阶段要涉及大量磁盘I/O和网络读写。

从map阶段读入数据，到输出数据到磁盘，进行分区，洗牌分发各个reduce阶段，

这期间无时无刻不在消耗的机器的资源。

虽然可以通过map 简单条件判断，distributecache，bloomfilter，combiner

等等方案来极少I/O和网络传输的数据量，但是对于大数据来说，根本就没有触及到完全处理大数据的能力,

如果存在大表join的情况，天生的结构注定了，mapreduce没有hash join 

或者merge join 只有嵌套循环join,这种方式性能不会高，

mysql 就是只有这种方式，所以mysql行内join普遍的最佳实践最多俩表join。

2，整个拓扑依赖遵循木桶短板理论，不管是从整个job来看，

还是单看map,copy sort,reduce各个阶段，都依照这个理论。

不幸的是真实的业务场景数据倾斜是常见的事，导致单个节点负载远远大于其他节点，拖慢整个job。

数据倾斜解决方式，一般也就划分出一个特定的节点让那个阶段专门跑这个拥有大数据的维度，

或者对业务更加细粒度的拆分，

也就是将原先一个job,拆分成多个小job去完成。但是同样的治标不治本，

而且要对业务数据非常熟悉，一般的RD是接触不到真实的业务数据，也是比较难做到的。

3，在设计要简单算法mapreducer已经足够，通过key-value模式，

这也是我最长用的模式,但是写起来和后起维护都是一件麻烦的事，

笔者在实际业务场景下更加倾向于使用hive,

但是hive的带来便利的同时也带来解释计划的冗余性能想比于写mapreducer有一定差距，

简而言，hive容易维护，但是解释计划太糟糕，mr性能由开发者来决定，但是维护成本高。

4）处理复杂业务逻辑蛋疼，考验每个RD的水平(技术水平，思维能力）,笔者统计过用户功能路径统计，

描绘整个APP，用户使用的路径图，以及在各个功能点之间活跃留存率，前期只考虑构建DAG情形。

5）hadoop天生就出于离线事务的处理，难以进行实时数据的处理也不能说是他的缺点，毕竟定位不同，所以spark，storm出来了。。。。

--------------------------end-----------------------

Google已经放弃hadoop,更加蛋疼的是我们的业务数据量没有增加，珍爱生命，请远离hadoop!