如今我们拥有广泛的数据处理系统选择：Hadoop, Spark, Naiad, PowerGraph, Metis 和 GraphChi 等，这些不同框架的最佳性能其实高度依赖于高阶的工作流程，其次，没有某个单个系统总是会比其他系统性能高，也就是说，几乎每个系统都有自己特定场景下的最好性能表现。
所以，选择一个数据处理系统应该将其工作负载贴近其最佳设计点，但是我们很容易忽视这点，导致宗教式的争论：哪个数据处理系统是最好的，这些争论往往没有背景前提。
选择一个正确的并行数据处理系统是困难的，它需要大量的关于编程范式、设计目标和许多可用性的实现等专家知识。
影响系统性能的四个关键因素有：
1.输入数据的大小，对于较小的数据输入，单机架构要优于分布式架构。
2.数据的结构，这会影响I/O性能和工作分发。
3.数据处理系统的自身建设中的工程决策，比如它是如何有效率的加载数据
4.计算类型，因为越专业的系统会更有效的运作。
所有系统数据来源与最终目地都是在HDFS文件中。
下图横坐标是数据量大小，纵坐标是时间。可见数据输入量小于0.5GB，其中紫红的Metis单机MapReduce性能最好：
对于40-80%的job提交到MapReduce系统，最好选择是运行在单机系统。一个大型的join产生29GB的系统采取Hadoop比较合适。
一旦数据规模增长，Hive, Spark 和 Hadoop都会优于单机的Metis，至少是因为他们都能将HDFS的进出数据并行流化处理，但是不管如何，因为在工作流程中没有数据重用,Spark性能会更差于Hadoop，它在进行计算前会将所有数据都加载到分布式内存RDD。
对于涉及图的迭代计算时，毫不奇怪特定的图形处理系统会更好。面向图的范式有很强的优势，运行在Naiad上的GraphLINQ会明显优于其他系统，PowerGraph也表现得很好，因为它的vertex-centric分片会降低通信开销，它在PageRank领域一直占据主导。当然，最快的系统并不总是最有效的。
总结：实验表明，对于一个工作流变化很大的系统最好的选择取决于，这个最好是指最快或最有效的系统，这些依赖于工作流本身、输入数据大小和并行规模。
==================================================================================
Spark只比Hadoop快19% ？
Spark比Hadoop并没有想象得那么快，以前号称快100倍，实际只快19%，这是Making Sense of Performance in Data Analytics Frameworks.结论。
这个结论出乎我们意料，他们发现：分析job的性能瓶颈在CPU，而不是I/O，网络性能对于job的完成时间只有稍微影响，提高网络性能能够提高job的完成时间，平均提高约2%;大部分造成性能落后的原因都能发现并且解决。
他们发现job任务运行时间通过优化磁盘I/O性能提高不可能超过19%，他们比较了任务在运行时资源利用率，发现CPU将近100%，而磁盘利用率也只不过25%。
一个原因是分析负载导致高CPU利用率，包括反序列化和压缩，通过迁移复杂的序列化和压缩格式已经降低了I/O，提高了分析框架的CPU使用需求。
因为超高的CPU使用时间，通过硬件优化比如使用更多磁盘，使用闪存或者将序列化数据保存在内存中不会显著提高分析job的完成时间，缓存反序列化数据因为消除了反序列化耗费的时间有潜在的大的性能提高。
因此，以前号称Spark因为使用了内存避免了磁盘I/O而比Hadoop提高100倍，是要打问号的，因为该研究表明，这些分析框架的主要瓶颈在CPU，而不是磁盘I/O，使用大量的内存和快速网络，虽然避免磁盘I/O和网络瓶颈的问题，但是不会对性能有100倍那么大的效果。
参考：Spark Only 19% Faster Than Hadoop? - Rose Business
banq注：大数据分析是一种计算，重点在计算上，也就是CPU使用上，而不是空间结构的存储。所以，从逻辑上看，CPU提升才应该是计算性能提升的关键。
==========================================================================
188
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
