为何Hadoop开源版本的性能，还可以在提高10到100倍？ 举报 理由 举报 取消 看到星环科技的简介，他们可以将开源版本的Hadoop的性能提升10到100倍！好厉害！ 那么：1.为什么开源版本的Hadoop不做到最好，而是留有如此之大的性能提升余地？ 2.什么方法什么手段可以提升Hadoop的性能？ 3.提升性能用到的是书本上的知识吗？还是工程师自创的提升方法？又或者是顶尖论文里面的方法？ 谢谢！ 2017年8月6日 5 条回复 1137 次浏览 Hadoop,Spark,分布式,并发,并行,数据,系统,计算
回复 ( 5 )
利益相关：星环在职员工。
个人经验有限，如有错误之处烦请指正。
为什么开源版本的Hadoop不做到最好，而是留有如此之大的性能提升余地？
既然题主在问性能问题，那我就尝试回答一下为什么一个优秀的开源系统（Hadoop）还可以有如此大的性能提升空间。
1.
Hadoop要解决的问题
首先要明确Hadoop（或者说当时Google搞那套MapReduce以及相关组件）要解决的问题：如何让没有分布式系统经验的开发者简单地使用分布式系统，并且可以在大规模廉价机器上可伸缩地运行。
可以想象一下，一个设计目标是在（十年前）廉价机器中运行的分布式系统，在一个现今的机器甚至高性能的服务器集群中，能把机器性能压榨多少？
2.
工程系统
作为一个大型的工程系统，它需要在一定的成本内（时间，人力）里完成，它需要作出非常多的tradeoff，这也就注定了它不可能无限制地在所有问题上实施“最好”的解决方案（如果有的话）。更何况如何将机器性能压榨干净并不是Hadoop首要关注的问题，这方面没有解决很好也是自然的。
同时这个系统也会使用优质的三方库。然而同样由于上述理由，这些不可控的三方库也可能带来潜在的性能影响。
3.
技术
从技术角度讲，主要有以下三个方面会影响系统的性能，这三个方面的划分并不绝对，也同时会互相影响。
3.1
架构
单说Hadoop的计算引擎部分，它使用的是MapReduce模型，这个模型非常简单易用，但也限制了它的灵活性。而在其之后的很多分布式计算框架都采用基于DAG的计算模型，而在DAG中可以提供除Map、Reduce外更多的语义选择。举个不恰当的例子，就好比从A地到B地，MapReduce只让你坐飞机，DAG可以让你走路、汽车飞机都可以。当你需要解决的问题就是从家到学校这个距离时，最快的就不见得是飞机了。
3.2
算法实现
除开纯粹地算法未实现为最优的情况外，实际工程中往往有很多不能确定最优方案的情况。
Hadoop毕竟是个general的分布式系统，在它的角度并“不太了解”上层应用如何用它，这也限制了其中算法的选择；它能做的就是尽可能地解决所有已知的问题。
然而在大家都开始用它时，会有很多设计者意想不到的用法出现；同时解决所有的问题也很大可能地意味着每个问题都没解决到最好。
假设有一个任务分发系统需要对任务排序。在算法设计时，觉得同时不会有太多（<10）个任务同时存在，也许就顺手写了个冒泡排序就搞定了。这个系统也许会安然存在很久，直到某天客户需要同时启动10000个任务。
这个故事的另一个版本应该反过来说，算法设计时，预期会有很多的任务需要排序，写了个快排搞定。直到某些场景下，一直只用很少任务的排序，发现冒泡排序都快一些。
这只是一个例子，然而大型的工程系统中总会出现很多类似的问题，不止性能方面，系统稳定性、安全性的坑也很多。
3.3
系统实现
Hadoop是一个十多年前的设计。在开源社区的经营下，它的实现在进步。然而在一个大设计的限定下，要想紧紧跟随系统、硬件的发展脚步，确实有很多挑战。
一个分布式系统并不是运行在一个理想的计算机上的，从写系统的那一层抽象到最终执行它的那一层（只考虑软件层）之间隔了无数个O(1)到O(n^?)，并且算法常数不太确定的组件。抛开之前的架构、算法层面的问题，要如何在这样的系统上高性能的运行又是另外一个故事了。
Hadoop大部分组件都是Java写的，这就无法回避Java虚拟机的性能开销。一般而言，Java虚拟机你轻轻用它，一般没什么性能问题，甚至有号称接近C的性能。然而当你使劲地用它（大数据场景、多个复杂框架\系统同时使用），还是需要花成本认真解决其中的性能坑的（无论你是从Java层解决，还是定制Java虚拟机解决）。GC问题、即时编译器的问题、Java对象膨胀问题，堆外内存问题等等，这些问题在大数据、重压力场景下对性能的影响尤为严重。如果你使用如Scala这种JVM语言，Scala也可能带来不小的性能影响。
Java虚拟机之下还有OS甚至还有VMM（虚拟机监控器），这之下还有很多硬件对软件的特性或抽象。
早期的Apache Spark的在shuffle时会同时写很多个文件，当reduce任务特别多时，shuffle性能很差。而当你考虑到文件系统的特点时，你可以针对这一块做出性能优化。
传统机械硬盘有着顺序读写快，随机读写慢的特点。当设计存储相关系统时，必须考虑到这一特点为之设计算法。有时甚至需要牺牲算法复杂度来迎合硬盘的读写，就是因为硬盘随机访问太慢了。如Hadoop它的初衷就是要在廉价硬盘系统上运行，那么它的算法一定是考虑顺序读写的。然而，在SSD越发廉价的今天，用顺序那套算法理所当然地会更快。但如果你换成一个为随机读写的算法，有可能优化到另外一个量级。
===========
私货分割线 ==============
最后吐槽一下，其实Hadoop并不是一个特别好的性能标尺。
从它出现那天起就有许多的工业界、学术界的分布式框架、产品性能超过它很多倍。
我司作为大数据领域的商业化公司，在这块经过了多年的耕耘。个人认为，在性能、稳定性、易用性等方面超过同类型的开源系统应该是个比较基础的需求。而对比其它的商用方案，我司现有的在各行业的（金融、电信、交通等）实施案例应该能说明一些问题。
先说结论: 任何脱离场景谈性能的事都是耍流氓。
单纯来说，做到10，100倍提升有可能吗？肯定有，但是需要给出具体对比环境。包括集群规模，机器配置，运行的算法，对比指标的max, min ,50th等这些值。否则在技术上对比真的没有意义。
星环使用的是spark作为基础改造的，spark本身就比Hadoop mapreduce快10到100倍。再加上他们自己针对场景的改造以及广告的考虑，这样说也不为怪
其实你可以看到，impala,spark,tez这些都号称比hadoop快10~100倍。漏了一个greenplum( ¯ᒡ̱¯ )
已人肉@了大星环的多位技术大拿，前排分发小板凳