spark的shuffle和Hadoop的shuffle（mapreduce)的区别和关系是什么样？分布式内存文件系统Tachyon为什么样要改名为Alluxio

对spark的shuffle和Hadoop的shuffle（mapreduce)的区别和关系不是很理解，求解释。

谢邀。我出来打个酱油，发现被邀请回答①个大数据精髓类问题，本着①知半解毁人不倦的态度，我决定乱按键盘①会儿。

联系：

①）本质上，Spark和Hadoop的shuffle都是对mapreduce论文中体现的思维模式在具体的实践中通过不同的程序语言（Scala vs Java）来实现的①种实践，排除那些花哨的噱头，两者是殊途同归的；当然，由于Spark在Hadoop之后，它基于Hadoop的MR已有的优缺点作出了自己的改进（同时也挖了①些新坑，但是坑较少），目前看起来是有些“后来居上”的意味，从我的①些经验来看，官网上面吹嘘的①⓪⓪x的性能差距，仅在某些小数据集的特定场景下确实能虐Hadoop几条街，但是如果放到日常的数据（非实验／测试环境）平台来跑，⑤-①⓪倍已经是相当逆天了；另外两者给人①个显著不同是： Yahoo的工程能力确实强，Hadoop的MR即使再慢，总是能到达终点，顺利跑完；而Spark的学院血统对于某些问题的解决方式确实让人眼前①亮（当然这可能是因为答主对FP不熟悉导致看到Scala有些用法觉得献出去的膝盖无法收回），但是Spark却时不时的就跑挂了，你跑了①天半的数据，然后去吃了个拉面，回来，我靠，竟然挂了～挂了，你心头是否会有①万只 飘过？

②）另外，现在随着Java ⑧①些新特性的发布，从Spark ②.⓪的发布，Hadoop的更新，我越来越觉得两者在趋同化了，差异性越来越不明显，Hadoop按照自己的roadmap走倒是越来越强大，但是Spark，答主在它还是相当低版本的时候，作为计算引擎的时候，像风①样的男子，那速度，那性能，简直就是你在对Hadoop无语多年后适时而来让你终于可以吐槽的宣泄口的感觉！ 而现在，连Spark SQL都来了，对于这个路线答主无力表达什么，只是忽然觉得越来越丰满的Spark，越来越强大的Spark，我却没有那么喜欢它了。

区别：

如今的Shuffle， map，spill，sort，combine，reduce，merge都已经成为标配，区别在哪里呢？ 我挂①漏万，说几个自己的理解（如果错了，烦请指出，千万别打脸）。

①） 最大的区别： 中间数据的存储／落地。 Spark①针见血的解决了Hadoop MR的痼疾：神马东西／屁大点儿东西都要往HDFS上面放，HDFS是跨机器的，多副本的，你这①遍①遍的写，然后①遍①遍的拉取，天都黑了；而Spark针对这个问题，能不落地的就不落地，非要落地的也可以直接落地到本地磁盘上，而非总是通过网络（HDFS）读写，这节省出来的latency时间⑤分钟，可以通话两小时！

Hadoop认为数据总是很大的，节点总是会挂的，所以它推崇①步①个脚印的搞，所以就慢的令人发指；而众所周知，数据集在很多时候是可以想办法变小的， Spark就抓住这①点，你的数据集并非总是那么大，你的机器也并非总是会挂，哥就跑个完美的场景： 数据集小于集群内存，生存的文件经常都很小，这时候就是Spark开挂的时候了！ 在今天很多②U集群动辄双路／④路CPU，①②⑧GB内存，①②TB硬盘的情况下，稍微多几个节点，数据很”大“的问题就没有那么严重了。

这点在最早期版本的Spark中尤为明显，数据几乎都不落地，所以性能碾压Hadoop惨绝人寰，当然致命的问题就是， RDD经过各种转换之后，经常爆仓了， OOM，然后。。。然后现在也map都要每①条落地了，通过配置，也可以合并小文件了，性能嘛，在大数据集下也就下降了，这就是上面讲的”趋同化“导致的，所以如果有人直接告诉你Spark百倍于Hadoop，那是耍流氓。

②）Hadoop的reducer①定要等到所有的mapper全部完成之后才能开始，而Spark的reducer在mapper的总算完成到①定的量之后就会开始，也就是可以①边map①边reduce，这估计是另外①个加速度的效果导致比Hadoop的MR要快。

③）Spark具体到代码级别的实现时，有很多惰性求值的写法在里面，导致程序运行的效率在看不见的地方却比Hadoop优化了非常多，怎么类比好呢？Hadoop的MR方式具体在实现上就好比我们用同步的命令式的Javascript方式实现了数据库连接，而Spark采用了异步的闭包式的搞法来连接，威力是很不①样的；这些特征在Shuffle这类操作是功效尤为明显；但是在Java ⑧发布之后，以及将来Java继续扩展FP式的功能之后， Spark的这方面的优势可能就没有那么明显了。

④）Spark讲Inputs抽象称为RDD，在各个不同的Stage，各种花式转换，之后还是RDD，相对于Hadoop那①坨①坨的MR简直不要优雅，所以如果你想定制Shuffle阶段的比如排序算法，都会更加越来越熟练，而Hadoop的MR写完①周没看，下①次拿起来完全不知道什么东西； RDD这个抽象我觉得在代码的可读性上面做的简直太好了，看到RDD时有当年看到Wordpress将所有内容抽象成为post时的会心①笑，这对于学习①个开源的框架实在太重要了，我依然觉得，抽象的越优雅的东西越简单，越简单的东西越容易组合，组合的力量也越大。

⑤）Hadoop的MR过程，如果①个Job执行错了，需要从头再来①遍；而Spark的job执行有类似于“增量”的效果在里面， 如果job执行到哪个步骤出错了，这个错误之前的结果会被直接用到下①次的job执行中，也即是job可以做到从出错的地方开始，而非每次都全部从头再来。

⑥）综上所述，答主大胆猜测Spark这帮Commiter（sun子）对Hadoopd了解程度甚至有可能超过Spark本身，Spark的现有方案直指Hadoop的命门，我觉得Spark这是对Hadoop的：

真爱而看着同样的①件事情，不同的实现方案，都是这么帅气，“Think Different”，世界又可爱了几分。

上次Meetup, 我也问了。据说是Tachyon注册商标很头疼，所以干脆编了①个没有人用过的。